feat(asr): 本地语音转写接入为一级路由 + 并行工作流合并提交
按用户指示做**一包提交**，不按工作流拆分。本提交刻意混合了多条并行线：
· 本地 ASR 接管：audio 成为与 chat/embed/image/video 同等的路由类别
（IsLocalRoute 单一判据、audio 健康探测、default_audio_route、
auto 占位、GET /api/ai/routes/audio、回退云端时界面明示「音频已出网」）
· LLM 调用层：ctx 贯穿、ToolCall/ToolSchema、EmptyCompletionError /
TransientUpstreamError（按错误类型而非文案判重试）
· 编排 Agent：general_assistant orchestrate/persistence/spec_driver
· 联网搜索：internal/search（playwright）
· 网盘：backend + 前端
· 前端 UI：导航/路由/工作台若干页
· 交付文档：DELIVERY.md / AR04 / 部署文档的「无 Python」表述据实改写，
新增 eai_agentplatform-asr.service、asr.env、clonezilla-cleanup 清 ~/asr-poc
不分拆的原因：dev 早期，粒度不该打断工作节奏。且实测过——这些改动
**在编译上是同一个单元**（llm.go 的 ctx 签名变更牵动 12 个调用点，
chat_message.go 的 ctx 改动又与编排重写同处一个 hunk），拆出来的中间态编不过。
详见 TOP_CODING_RULES.md G14.5 与 bugs_and_errors.md E09。
Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
eaiadmin
@@ -0,0 +1,49 @@
|
||||
# 通用专员测试归集
|
||||
|
||||
按轮次组织，每次运行一个独立子目录 `run_<序号>`。
|
||||
每个子目录包含：
|
||||
|
||||
| 文件 | 内容 |
|
||||
|---|---|
|
||||
| `request.json` | 发送的请求体 |
|
||||
| `response.json` | 后端完整响应（含正文与产物） |
|
||||
| `summary.md` | 单次结论（意图类别/耗时/字数/是否编排/落库数） |
|
||||
|
||||
覆盖的三类路径：`direct_answer`(直答) / `single_search`(单问联网) / `orchestrated`(多 Agent 编排)。
|
||||
|
||||
## 本轮测试记录（2026-09-25）
|
||||
|
||||
| run | 场景 | 意图 | 结果 | 备注 |
|
||||
|---|---|---|---|---|
|
||||
| `run_01` | 人形机器人行业报告（挂载 task 94） | orchestrated | ✅ 21 子任务/19547字 + details，落库 11 条 | 编排+落库共生验证 |
|
||||
| `run_02` | 具身智能行业事件/融资搜索 | single_search | ⚠️ 搜索空，诚实降级 | SearXNG 上游无结果 |
|
||||
| `run_03` | 周末放松闲聊 | direct_answer | ✅ 302字，无联网 | 快答 |
|
||||
| `run_04` | 宇树/优必选/智元对比 | orchestrated | ✅ 16 子任务/12593字 + details | 公司对比 |
|
||||
| `run_05` | Tesla Optimus 定价（英文） | single_search | ⚠️ 搜索空，诚实降级 | SearXNG 上游无结果 |
|
||||
|
||||
## ⚠️ 阻塞发现：SearXNG 上游引擎失效
|
||||
编排/直答路径正常；但**单问联网搜索几乎必然"无结果"**。根因不在本项目代码，而在 SearXNG 服务器自身：
|
||||
|
||||
- **baidu / sogou**：`Suspended: CAPTCHA`（被中文搜索引擎验证码封锁）
|
||||
- **wikipedia**：`ConnectTimeout`（外网超时）
|
||||
- **bing**：返回 200 但解析 0 条（疑似 CDN/区域校验页）
|
||||
- **google / duckduckgo**：宿主机不可达（`000` 连接超时，已被墙）
|
||||
- **bilibili**：✅ 唯一可用，20 条结果
|
||||
|
||||
→ 可用引擎仅剩 1 个，实时资讯类查询（汇率/行业融资/新闻）在百度/搜狐被封后落到空结果。
|
||||
|
||||
## 修复尝试与最终结论（2026-09-25）
|
||||
|
||||
按用户方向「接入可用的第三方搜索源」，新建 `search/sogou.go` 搜狗兜底源 + `client.Search` 多源回退（SearXNG 空/失败 → 搜狗），并加了验证码页识别与一次退避重试。解析器针对真实搜狗页面结构（`<a href><h3 class="vr-title"><span>标题</span>`）适配，`TestParseSogouFixture` 用真实抓取页断言 6 条干净结果、通过。
|
||||
|
||||
**但最终验证发现：所有免费、墙内可访问的搜索源均对「无头 HTTP 抓取」启用反爬，无法稳定作为生产上游：**
|
||||
|
||||
| 源 | 反爬机制 |
|
||||
|---|---|
|
||||
| baidu / sogou | JS/SNUID/CAPTCHA 人机校验（需执行 JS 或真实浏览器） |
|
||||
| bing (cn) | 非浏览器 UA 返回无关缓存页，不按关键词匹配 |
|
||||
| google / duckduckgo | 宿主机不可达（网络阻断） |
|
||||
| 360 so.com | 302 反爬重定向 |
|
||||
| bilibili（经 SearXNG） | ✅ 唯一可用，但结果是视频类内容，非通用网页 |
|
||||
|
||||
**结论**：SearXNG 空结果并非 SearXNG 自身故障，而是其所有上游引擎均对当前数据中心 IP 的 HTTP 抓取封禁。搜狗兜底代码架构就绪、解析可用，但源在持续探触后升级为 `checkSNUID` JS 校验页，无法由纯 Go HTTP 客户端通过。**要恢复通用联网闭环，需在「付费搜索 API / 真实浏览器(Playwright) / 代理池」三选一投入**（属部署/预算决策，见对话）。
|
||||
@@ -0,0 +1 @@
|
||||
{"message":"拆分多个子任务，撰写2026年人形机器人行业深度报告：市场规模、技术路线、主要厂商、投资建议四部分。","mode":"quick","task_id":94,"specialist_key":""}
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,8 @@
|
||||
# run_01 测试结论
|
||||
- 类型：编排型（挂载到 general-assistant 任务 task_id=94）
|
||||
- 意图分流：orchestrated
|
||||
- 耗时：一轮（curl），约 2-3 分钟
|
||||
- 内容字数：19547
|
||||
- 是否含 <details> 编排折叠块：True
|
||||
- 子任务数：21
|
||||
- 时间戳：2026-09-25 19:21:00
|
||||
@@ -0,0 +1 @@
|
||||
{"message":"帮我搜索一下2026年9月具身智能/人形机器人领域有什么重大行业事件或融资。","mode":"quick","task_id":0,"specialist_key":""}
|
||||
@@ -0,0 +1 @@
|
||||
{"code":0,"data":{"message":{"role":"assistant","content":"我连续尝试了多组中英文关键词检索（「2026年9月 人形机器人 融资」「September 2026 humanoid robot funding」「具身智能 重大事件」等），甚至用最宽泛的「人形机器人」做兜底测试，**搜索结果均返回为空**，无法获取到任何可核实的资料。\n\n因此我无法为你提供2026年9月具身智能/人形机器人领域的具体事件或融资信息。原因可能有几种：\n\n1. **时间问题**：如果当前时间尚未到2026年9月，该月的行业事件和融资自然还不存在，任何\"数据\"都会是编造。\n2. **检索工具异常**：即使是宽泛查询也零结果，可能是搜索服务临时不可用。\n\n我不会凭印象或推测编造事件、公司名和金额——这类信息一旦虚构，对行业研究和决策参考危害很大。\n\n**建议你可以这样做：**\n- 确认一下你要问的时间点（是否是**2025年9月**，或某个已发生的月份？）；\n- 或者告诉我你关注的具体方向（如某家公司、某细分环节、某地区），我可以再针对性地试一次检索。\n\n如果你能补充这两点，我立刻重新帮你搜。","timestamp":"2026-09-25 19:21:32","type":"text"},"is_plan":false,"is_expert":false,"stream":false},"error":null,"message":"success"}
|
||||
@@ -0,0 +1,6 @@
|
||||
# run_02
|
||||
- 类型：单问联网搜索
|
||||
- 意图：single_search
|
||||
- 字数：459
|
||||
- details：False
|
||||
- 时间：19:21:32
|
||||
@@ -0,0 +1 @@
|
||||
{"message":"在吗？能不能简单聊聊周末可以做什么放松。","mode":"quick","task_id":0,"specialist_key":""}
|
||||
@@ -0,0 +1 @@
|
||||
{"code":0,"data":{"message":{"role":"assistant","content":"在的。周末放松可以很简单，按你想要的“安静 / 热闹 / 动 / 静”来选：\n\n- **想彻底躺平**：睡到自然醒、做顿慢早餐、追剧、看书、听歌、拼图。\n- **想出门透气**：公园散步、骑车、爬山、逛市集、咖啡馆坐一下午。\n- **想有点社交**：约朋友吃饭、桌游、看展、看电影、短途周边游。\n- **想恢复能量**：瑜伽、冥想、泡澡、按摩、早睡，顺便整理房间。\n\n一个低门槛组合： \n**周六**：上午公园走走 → 下午咖啡馆看书/发呆 → 晚上看部电影。 \n**周日**：睡饱 → 做顿喜欢的饭 → 简单收拾 → 早点休息。\n\n你更想要“安静宅家”还是“出门走走”？我可以帮你排个具体周末计划。","timestamp":"2026-09-25 19:21:40","type":"text"},"is_plan":false,"is_expert":false,"stream":false},"error":null,"message":"success"}
|
||||
@@ -0,0 +1,6 @@
|
||||
# run_03
|
||||
- 类型：直答（闲聊，无联网）
|
||||
- 意图：direct_answer
|
||||
- 字数：302
|
||||
- details：False
|
||||
- 时间：19:21:40
|
||||
@@ -0,0 +1 @@
|
||||
{"message":"请拆分为多个子任务，分别对比宇树科技、优必选、智元机器人在人形机器人上的技术路线与商业化进展，并给出综合结论。","mode":"quick","task_id":0,"specialist_key":""}
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,7 @@
|
||||
# run_04
|
||||
- 类型：编排型（公司对比）
|
||||
- 意图：orchestrated
|
||||
- 字数：12593
|
||||
- details：True
|
||||
- 子任务数：16
|
||||
- 时间：19:23:16
|
||||
@@ -0,0 +1 @@
|
||||
{"message":"Search for the latest 2026 pricing of Tesla Optimus humanoid robot.","mode":"quick","task_id":0,"specialist_key":""}
|
||||
@@ -0,0 +1 @@
|
||||
{"code":0,"data":{"message":{"role":"assistant","content":"检索未能返回结果（多次尝试均无数据），因此我无法确认 2026 年的最新定价。以下是我在知识范围内的已知信息，**未经实时验证，请以官方渠道为准**：\n\n**关键结论：截至我掌握的公开信息，特斯拉从未公布 Optimus 的正式零售定价，也没有 2026 年官方售价。**\n\n已公开的表态（均为马斯克个人说法，非官方定价）：\n- 在 2024 年 10 月「We, Robot」发布会及此前财报电话会上，马斯克称 Optimus 未来售价目标约 **2 万–3 万美元**，并称\"可能比一辆车还便宜\"。\n- 量产时间表：马斯克多次表示 2025 年起先在特斯拉自家工厂内部使用，**对外销售目标约在 2026 年**，但时间表已多次推迟（\"明年量产\"的说法自 2022 年起反复出现）。\n\n需要提醒的点：\n- 目前没有官方 SKU、配置或价格单，网传的\"3 万美元预售\"\"2026 上市价\"多为媒体推测或二手转述，可信度低。\n- 该品类（人形机器人）尚无成熟消费级定价体系，2026 年实际价格可能因配置（工业版／家用版）差异很大。\n\n**建议获取权威价格的渠道：**\n1. 特斯拉官网 / 官方新闻稿（tesla.com）\n2. 特斯拉季度财报电话会记录（ir.tesla.com）\n3. 马斯克 X（Twitter）账号\n\n如果我需要给出确切数字，建议你允许我再次联网查询，或提供你看到的某条具体报道链接，我来帮你核实出处。","timestamp":"2026-09-25 19:23:43","type":"text"},"is_plan":false,"is_expert":false,"stream":false},"error":null,"message":"success"}
|
||||
@@ -0,0 +1,6 @@
|
||||
# run_05
|
||||
- 类型：单问联网搜索（英文）
|
||||
- 意图：single_search
|
||||
- 字数：614
|
||||
- details：False
|
||||
- 时间：19:23:43
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"message": "请分三部分分别调研具身智能机器人产业链的上游、中游、下游，每部分给出代表性公司名称和最新进展，最后合并成一份结构化报告",
|
||||
"specialist_key": "general-assistant",
|
||||
"mode": "chat",
|
||||
"stream": false
|
||||
}
|
||||
@@ -0,0 +1,8 @@
|
||||
# run_06
|
||||
- 类型：编排型（多部分任务）
|
||||
- 意图：orchestrated
|
||||
- 状态：超时（未返回结果）
|
||||
- 耗时：>300s（无响应，客户端中断）
|
||||
- 时间：2026-09-25 20:04
|
||||
- 说明：请求为「分上中下游调研具身智能机器人产业链」。编排器需拆解多子任务、每子任务走 web_search（三级源）。因本机数据中心 IP（180.158.134.57）触发百度「安全验证」/搜狗「点击验证码」反爬，搜索源持续超时，叠加 LLM 多轮 tool_calls，整体超过客户端等待上限。
|
||||
- 结论：编排链路本身逻辑正常（见 run_01 曾成功返回 43KB 编排结果），但**依赖搜索数据时，在网络反爬未解决前无法稳定跑通**。
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"message": "帮我联网查一下：近期有哪些公司在做人形机器人？给出几家有代表性的公司名字",
|
||||
"specialist_key": "general-assistant",
|
||||
"mode": "chat",
|
||||
"stream": false
|
||||
}
|
||||
@@ -0,0 +1,8 @@
|
||||
# run_07
|
||||
- 类型：联网单问
|
||||
- 意图：single_search
|
||||
- 状态：超时（未返回结果）
|
||||
- 耗时：>180s（无响应，客户端中断）
|
||||
- 时间：2026-09-25 20:10
|
||||
- 说明：请求为「联网查近期做做人形机器人的公司」。单问意图应快速返回，但 web_search 走三级源时：SearXNG 空 → 搜狗HTTP 被 checkSNUID 拦 → 浏览器兜底又被百度/搜狗验证码卡住（见 run_06 同因）。三级源每级都要等超时，单次搜索即 30s+，再叠加 LLM 多轮 tool_calls，导致单问也超时。
|
||||
- 结论：核心阻塞是**数据中心 IP 被所有免费搜索源反爬标记**，非意图分流或编排逻辑问题。对比 run_05（英文单问 19:23 曾成功）可见结果不稳定，取决于当时是否偶发绕过验证码。
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"message": "解释一下大语言模型里的 temperature 参数是什么？它影响模型的什么行为？",
|
||||
"specialist_key": "general-assistant",
|
||||
"mode": "chat",
|
||||
"stream": false
|
||||
}
|
||||
@@ -0,0 +1 @@
|
||||
{"code":0,"data":{"message":{"role":"assistant","content":"Temperature 是大语言模型**推理/采样阶段**的一个参数，不是模型训练出来的权重。它用来调节下一个 token 的概率分布有多“随机”。\n\n原理上，模型先给每个候选 token 一个分数 logits，然后：\n\n\\[\np_i = \\frac{\\exp(z_i / T)}{\\sum_j \\exp(z_j / T)}\n\\]\n\n其中 \\(T\\) 就是 temperature。\n\n- **T \u003c 1，低温**：分布更尖锐，高概率 token 更容易被选中。输出更确定、保守、稳定，适合事实问答、代码、结构化任务。\n- **T = 1**：按模型原始概率采样。\n- **T \u003e 1，高温**：分布更平坦，低概率 token 也有更多机会被选中。输出更多样、发散、有创造性，但也更容易跑题、胡说或幻觉。\n- **T → 0**：接近贪心解码，每次选概率最高的 token；实际实现通常直接特殊处理为 greedy。\n\n它主要影响这些行为：\n\n1. **随机性/多样性**：温度越高，同一 prompt 每次输出差异越大。\n2. **创造性**：高温更容易产生意外组合和新表达。\n3. **稳定性/一致性**：低温输出更可复现、更稳定。\n4. **事实准确性**：高温通常增加幻觉和错误风险；低温更稳，但可能单调、重复。\n5. **解码效果**：它不改变模型知识，只改变从概率分布里怎么选词。\n\n实际使用中，Temperature 常和 top-k、top-p 一起用。经验上：事实问答/代码用 0～0.3，普通对话 0.5～0.8，创意写作可到 0.8～1.2 或更高。","timestamp":"2026-09-25 20:10:40","type":"text"},"is_plan":false,"is_expert":false,"stream":false},"error":null,"message":"success"}
|
||||
@@ -0,0 +1,9 @@
|
||||
# run_08
|
||||
- 类型：纯知识直答
|
||||
- 意图：direct_answer
|
||||
- 状态：成功
|
||||
- 耗时：约 8s
|
||||
- 字数：687
|
||||
- 时间：2026-09-25 20:10:40
|
||||
- 说明：请求为「解释大语言模型里的 temperature 参数」。未触发联网/编排，单轮直答即返回，内容：temperature 是采样阶段参数，给出 softmax 公式（p_i = exp(z_i/T)/Σ...）、T<1 低温确定性高、T=1 原始采样、T>1 高温发散、T→0 贪心解码、并说明与 top_p 的区别。专业准确。
|
||||
- 结论：direct_answer 路径正常（~8s，结构化、专业）。这是三类意图中唯一完全通畅的路径，验证了不依赖外部搜索时通用助手本体能力可靠。这也说明超时问题**不在直答/编排逻辑，而在搜索数据源的反爬**。
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"message": "请解释机器学习中的过拟合（overfitting）问题：它是什么、为什么会发生、有哪些常见的解决方法？给出一个通俗但准确的专业回答。",
|
||||
"specialist_key": "general-assistant",
|
||||
"mode": "chat",
|
||||
"stream": false
|
||||
}
|
||||
@@ -0,0 +1 @@
|
||||
{"code":0,"data":{"message":{"role":"assistant","content":"**一句话**：过拟合是模型在训练集上“考满分”，但换到新数据就“露馅”——它把噪声和偶然规律也当成真规律学进去了。\n\n**是什么** \n- 训练误差很低，验证/测试误差却很高。 \n- 从偏差-方差看，属于**高方差**：模型对训练样本的微小变化过于敏感。 \n- 典型曲线：验证误差先下降，随后随着训练继续反而上升。\n\n**为什么会发生** \n- 模型太复杂：参数太多、网络太深、树太深，容量超过了数据能支撑的信息量。 \n- 数据太少、噪声大、特征维度高，模型容易记住“特例”而非规律。 \n- 训练太久，模型开始拟合残差和噪声。 \n- 反复用同一验证集/测试集调参，或存在数据泄露，也会造成“看起来过拟合/虚高”。\n\n**常见解决方法** \n1. **数据层面**：增加样本、数据增强、加噪声、重采样。 \n2. **模型层面**：降低复杂度，如减少参数、降维、特征选择、决策树剪枝、限制深度。 \n3. **正则化**：L1/L2、权重衰减、Dropout、标签平滑；正则太强会转向欠拟合。 \n4. **早停**：监控验证集误差，在它开始上升前停止训练。 \n5. **可靠评估**：交叉验证，验证集调参，测试集只在最后用一次。 \n6. **集成方法**：Bagging、随机森林、模型平均等可降低方差。 \n7. **其他**：贝叶斯先验、最大间隔思想、批归一化等也有一定正则效果。\n\n**关键点**：过拟合无法完全消除，只能缓解；目标不是训练误差最低，而是**泛化误差最低**。就像学生背答案不如理解规则——模型要学的是规律，不是题面。","timestamp":"2026-09-25 20:33:47","type":"text"},"is_plan":false,"is_expert":false,"stream":false},"error":null,"message":"success"}
|
||||
@@ -0,0 +1,8 @@
|
||||
# run_09
|
||||
- 类型：纯知识直答
|
||||
- 意图：direct_answer
|
||||
- 状态：成功
|
||||
- 耗时：14.4s（后端 ai_call_log: 14415ms）
|
||||
- 时间：2026-09-25 20:33:47
|
||||
- 说明：请求为「解释机器学习里的过拟合」。未触发联网/编排，单轮直答返回，内容：过拟合定义、成因（模型复杂度过高/数据不足/噪声）、三大类解决（数据层/模型层/正则化层）结构化专业回答。
|
||||
- 结论：direct_answer 路径稳定（~14s）。证明在不依赖搜索时通用助手本体能力可靠。这也再次印证：超时问题集中在「联网/编排」路径，与直答逻辑无关。
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"message": "帮我把“系统学习 Rust 语言”拆解成一个分阶段的学习规划，从入门到精通，明确每个阶段应该掌握的核心知识点和推荐的实践方式，最后给出总的学习路线建议。",
|
||||
"specialist_key": "general-assistant",
|
||||
"mode": "chat",
|
||||
"stream": false
|
||||
}
|
||||
@@ -0,0 +1,9 @@
|
||||
# run_10
|
||||
- 类型：分阶段规划编排
|
||||
- 意图：规划 / 编排
|
||||
- 状态：超时（后端未返回结果，客户端 200s 中断）
|
||||
- 耗时：>200s
|
||||
- 时间：2026-09-25 20:33 后
|
||||
- 说明：请求为「把系统学习 Rust 拆成分阶段规划」。被判定为复杂任务进入编排路径，拆解子任务。理论上该任务不需要联网，但编排器对子任务可能同步触发搜索源，而当前未配付费 key、搜索源逐级串行等超时（searxng 25s + sogou 15s + browser 20s+ ≈ 60-80s/轮），叠加编排多子任务与 LLM 多轮，总时长超过客户端上限。
|
||||
- 证据：后端 ai_call_log 未新增记录、请求无完成日志，后端本身健康（最小直答 1.2s 正常），故为长耗时路径超时，非服务故障。
|
||||
- 结论：**除非解决搜索源慢/超时收敛，编排类任务无法稳定跑通**。
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"message": "帮我联网查一下：2026年诺贝尔物理学奖的获奖者是谁？他们因为什么成就获奖？",
|
||||
"specialist_key": "general-assistant",
|
||||
"mode": "chat",
|
||||
"stream": false
|
||||
}
|
||||
@@ -0,0 +1,9 @@
|
||||
# run_11
|
||||
- 类型：联网实时单问
|
||||
- 意图：single_search
|
||||
- 状态：超时（后端未返回结果，客户端 150s 中断）
|
||||
- 耗时：>150s
|
||||
- 时间：2026-09-25 20:35 后
|
||||
- 说明：请求为「联网查 2026 诺贝尔物理学奖得主」。走 web_search 工具。未配付费 key 时，每次搜索都要串行等完 searxng(25s)+sogou(15s)+browser(20s+)≈60-80s。该类实时问答 LLM 常连续调多轮 web_search 工具，每轮 80s，两轮即超 150s，故超时。
|
||||
- 对比：20:28 的同路径单问（人形机器人）耗时 82s 且能诚实降级返回，说明耗时敏感于 LLM 是否多轮调用搜索。
|
||||
- 结论：**搜索源未配付费 key 时，每轮搜索 60-80s 的串行等待是联网路径超时的直接根因**。需并发探测 + 收紧超时 + 配置稳定可用的付费源三者其一才可根治。
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"message": "帮我联网查一下：2026年诺贝尔物理学奖的获奖者是谁？他们因为什么成就获奖？",
|
||||
"specialist_key": "general-assistant",
|
||||
"mode": "chat",
|
||||
"stream": false
|
||||
}
|
||||
@@ -0,0 +1 @@
|
||||
{"code":0,"data":{"message":{"role":"assistant","content":"**截至目前的检索结果：2026年诺贝尔物理学奖尚未揭晓，暂无获奖者。**\n\n**关键信息**\n- 据诺贝尔奖官网，2026年诺贝尔奖各项奖项定于 **2026年10月5日至12日** 陆续公布，其中**物理学奖定于 10月6日（周二）** 揭晓。（来源：央视网、中国新闻网、AiTimeline 等）\n- 在检索到的最新信息中（截至2026年9月17日前后），**没有任何机构公布过2026年的获奖者**，因此网上若出现\"2026诺贝尔物理学奖得主\"的具体名单，多为预测或不实信息。（来源：AiTimeline \"Nobel Prize 2026 Timeline\"）\n- 目前仅有**\"引文桂冠奖\"（Citation Laureates，被称为\"诺奖风向标\"）**名单：2026年度物理学领域为中国科学院院士、南方科技大学校长**薛其坤**获奖，但这是预测性奖项，**不等于诺贝尔奖**。（来源：搜狐、腾讯新闻）\n\n**参考：2025年诺贝尔物理学奖**\n- 获奖者：**John Clarke、Michel H. Devoret、John M. Martinis**（均为美国高校学者）\n- 获奖原因：在**量子力学领域的成果，推动了量子技术的发展**（宏观量子隧穿与电路中的量子化能级研究）。（来源：AP/CBS17、WJLA 等）\n\n**建议**：待 **2026年10月6日** 官方公布后，可到诺贝尔奖官网（nobelprize.org）或权威媒体核实最新得主。如果你需要，我可以届时再帮你查一次。","timestamp":"2026-09-25 20:56:50","type":"text"},"is_plan":false,"is_expert":false,"stream":false},"error":null,"message":"success"}
|
||||
@@ -0,0 +1,11 @@
|
||||
# run_12
|
||||
- 类型：联网实时单问（对比 run_11 超时路径）
|
||||
- 意图：single_search（「联网查 + 单一事实」）
|
||||
- 状态：成功
|
||||
- 耗时：31.9s（HTTP 200）
|
||||
- 时间：2026-09-25 20:56:50（ai_call_log #280，latency 63s/请求 31.9s）
|
||||
- 说明：请求「2026 诺贝尔物理学奖得主」。这是 run_11（150s 超时）的同款回归用例。
|
||||
- 结果：**SerpApi 作为主源生效后，同一任务从「150s 超时无结果」变为「31.9s 返回真实、带来源、诚实」**：
|
||||
- 正确指出 2026 诺奖**尚未揭晓**（物理学奖定于 10月6日），引用央视网、中国新闻网、AiTimeline
|
||||
- 诚实否定了网传预测名单，明确区分「引文桂冠奖」与「诺贝尔奖」，符合项目搜索诚实性
|
||||
- 结论：✅ 付费源彻底修复 single_search 路径的速度与可用性。
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"message": "帮我调研一下具身智能（embodied AI）产业的现状，梳理这条产业链的上游、中游、下游分别有哪些环节和代表厂商，当前的技术瓶颈和商业化进展如何？请整理成一份报告，引用尽量准确。",
|
||||
"specialist_key": "general-assistant",
|
||||
"mode": "chat",
|
||||
"stream": false
|
||||
}
|
||||
@@ -0,0 +1,19 @@
|
||||
# run_13
|
||||
- 类型：编排型综合任务（具身智能产业链报告）
|
||||
- 意图：orchestrated（命中「调研 / 产业链 / 上中下游 / 报告」多信号词）
|
||||
- 状态：超时（HTTP 000，客户端 210s 中断，无响应文件）
|
||||
- 时间：2026-09-25 21:00 前后
|
||||
- 现象：
|
||||
- 后端健康（200）正常，但 chat 请求 210s 无返回
|
||||
- ai_call_log 近 6 分钟出现 4 条 failed 记录（每次约 20-21s），即编排内部多次 LLM 调用**失败**而非成功
|
||||
- 根因（结合代码 + 日志）：
|
||||
1. `orchestrate.go` 的 150s 兜底 ctx **传导失效**：编排里 `judgeIntent`(L180)/`planSubTasks`(L239)/`merge`(L403) 调用的 `ai.GenerateWithFallback(route, msgs)` **不接收 ctx 参数**（signature `GenerateWithFallback(primary, messages)`），内部 `client.Generate` 走自己的 http timeout，完全不受编排 150s ctx 取消控制。LLM 端慢/失败时只能等各自超时，整体远超 150s/210s。
|
||||
2. executeSubTasks 里并发 worker 的 `agent.Run(ctx, ...)` 虽带 ctx，但上游判断/拆解环节（GenerateWithFallback）已不可中断，链路整体失控。
|
||||
3. 编排失败后回收不干净，期间**阻塞后续 chat 请求**（run_14 在 run_13 排障期间也超时）。
|
||||
- 结论：❌ 编排路径依然是超时黑洞，根因是「编排超时兜底未能传导到 LLM 调用链」。SerpApi 解决了搜索速度，但未解决编排超时控制。
|
||||
|
||||
## 横向对照
|
||||
| 路径 | run_12 单问 | run_13 编排 |
|
||||
|------|------------|------------|
|
||||
| SerpApi 前 | run_11 150s 超时 | run_06/07/10 超时 |
|
||||
| SerpApi 后 | ✅ 31.9s 成功 | ❌ 210s 超时（根因非搜索，是编排超时兜底失效） |
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"message": "请对比解释一下 HTTP/2 和 HTTP/3 的区别，重点说明它们各自解决了什么问题、在连接建立和传输效率上的差异，以及分别适合什么场景。",
|
||||
"specialist_key": "general-assistant",
|
||||
"mode": "chat",
|
||||
"stream": false
|
||||
}
|
||||
@@ -0,0 +1,18 @@
|
||||
# run_14
|
||||
- 类型：预期「纯知识直答」（HTTP/2 vs HTTP/3 对比）
|
||||
- 意图误判：本意测直答基线，但 prompt 含「对比」→ 命中 judgeIntent 强规则（编排信号词：对比），被判 **orchestrated**，实际走了编排路径
|
||||
- 状态：超时（HTTP 000，60s 无返回）；两次尝试均失败
|
||||
- 时间：2026-09-25 21:03（第二次，后端已恢复后仍超时）
|
||||
- 证据：近 6 分钟 ai_call_log 有 failed 记录（20s 级），为编排内部 LLM 调用失败
|
||||
- 结论：
|
||||
1. **「对比」被当作编排信号词**是设计使然（judgeIntent 强规则要「对比→orchestrated」产出结构化多段）。这是真实业务需要的强规则，不是 bug。
|
||||
2. 因此 run_14 实际测的是**编排路径**，与 run_13 同根因超时。
|
||||
3. 纯直答基线由 run_09（14s，不触发联网词）单独代表，仍成立。
|
||||
- 教训：测「直答」必须避开编排信号词（对比/分析/报告/上中下游等）；否则会进入编排路径并被当前超时问题拖住。
|
||||
|
||||
## 三次测试小结（SerpApi 接入后）
|
||||
- run_12 联网单问：✅ 31.9s（SerpApi 修复 single_search）
|
||||
- run_13 编排型：❌ 210s 超时
|
||||
- run_14 含「对比」：❌ 60s 超时（同 run_13，被编排路径拖住）
|
||||
|
||||
统一结论：**SerpApi 解决了搜索可用性/速度，但编排路径的「超时兜底失效」仍会导致 150s+ 超时且阻塞后续请求**——这是下一步必须修的结构问题。
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"message": "请对比解释一下 HTTP/2 和 HTTP/3 的区别，重点说明它们各自解决了什么问题、在连接建立和传输效率上的差异，以及分别适合什么场景。",
|
||||
"specialist_key": "general-assistant",
|
||||
"mode": "chat",
|
||||
"stream": false
|
||||
}
|
||||
@@ -0,0 +1 @@
|
||||
{"code":0,"data":{"message":{"role":"assistant","content":"已按子任务完成，但结果为空，请重试。\n\n\u003cdetails\u003e\u003csummary\u003e📋 本次由通用编排拆分执行\u003c/summary\u003e\n\n##### 定义对比框架与输出大纲（维度：解决的问题、连接建立、传输效率、适用场景）\n\n（本子任务结果为空）\n\n##### \n\n（本子任务结果为空）\n\n##### \n\n（本子任务结果为空）\n\n##### \n\n（本子任务结果为空）\n\n##### 整合撰写对比解释文：逐维度对照 HTTP/2 vs HTTP/3，含机制原理与场景建议\n\n（本子任务结果为空）\n\n##### \n\n（本子任务结果为空）\n\n\u003c/details\u003e","timestamp":"2026-09-25 21:32:52","type":"text"},"is_plan":false,"is_expert":false,"stream":false},"error":null,"message":"success"}
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,47 @@
|
||||
# run_15（上下文：编排超时兜底修复回归）
|
||||
|
||||
- 类型：编排型（HTTP/2 vs HTTP/3 对比，「对比」命中编排信号词）
|
||||
- 目的：验证「编排 150s 硬截止兜底」在 ctx 贯穿 + agent 轮次 ctx 检查 + executeSubTasks wall-clock 截止后真正生效
|
||||
- 结果：✅ **HTTP 200，150.0s 收敛**（此前同用例 run_14 为 210s 无限挂起，curl 200s 0 字节）
|
||||
- 时间：2026-09-25 21:30:22 → 21:32:52
|
||||
|
||||
## 修复内容（本回归所验证）
|
||||
1. `llm.go`：所有 LLM 调用（Generate/GenerateFull/GenerateStream/xxxFallback/Embed）加 `context.Context` 参数，`post` 用 `http.NewRequestWithContext`，使上层 ctx（编排 150s 兜底）真正能取消进行中的 HTTP 请求。
|
||||
2. `agent.go RunWithUsage`：每轮 tool_calls 前检查 `ctx.Err()`，ctx 取消立即退出，避免慢 worker 靠单次已发起成功的 HTTP 响应续命拖死 `wg.Wait()`。
|
||||
3. `orchestrate.go executeSubTasks`：分批 worker 的 `wg.Wait()` 改为与 `ctx.Done()` 竞争（select），到点不等最慢 worker，**150s 硬截止返回当前已完成产物**。
|
||||
|
||||
## 效果对照
|
||||
| 维度 | 修复前（run_14） | 修复后（run_15） |
|
||||
|---|---|---|
|
||||
| 请求收敛 | 210s 无限挂起，curl 200s 0 字节 | ✅ 150s HTTP 200 返回 |
|
||||
| 后续请求 | 被阻塞（run_14 曾连带超时） | ✅ 不阻塞 |
|
||||
| ctx 传导 | 失效 | ✅ ai_call_log 出现 `context deadline exceeded` 的快速失败(0ms)|
|
||||
| 产物 | - | 超时兜底返回「已按子任务完成，但结果为空」+ 部分子任务标题 |
|
||||
|
||||
## 多策略修复后 → 成功（2026-09-25 22:02）
|
||||
对「worker 空回复 / tool_calls 死循环」叠加三重策略后重跑同用例（request 见 `request.json`，结果存 `response_success.json`）：
|
||||
|
||||
| 指标 | 结果 |
|
||||
|---|---|
|
||||
| 收敛时长 | ✅ **94s**（无需 150s 兜底，正常完成） |
|
||||
| 产物体量 | ✅ 约 19KB 深度对比正文（含核心判断/共同点/各自问题/RTT/传输效率/选型/来源引用） |
|
||||
| 编排完整性 | ✅ plan(5子任务)→worker 执行→merge→审核 worker 全部跑通 |
|
||||
| ai_call_log | 4 个 worker 1.4-2.1s 极快产出（无工具收敛路径）+ 2 个 worker 21-23s + 主回复 94s |
|
||||
|
||||
### 三重策略明细（`internal/ai/agent.go` + `orchestrate.go`）
|
||||
1. **roundWithEmptyRecovery**：单轮「空响应」→ 带工具重试一次 → 仍空降级「无工具纯文本」重试，兼容「带工具即空、纯文本正常」的路由。
|
||||
2. **tool 死循环收敛**：`RunWithUsage` 统计连续「只发工具调用、无结论文本」轮数，≥3 轮即中断，用无工具纯文本基于已回填的搜索结果重生成结论——直接掐断模型反复搜索不下结论的死循环。
|
||||
3. **worker 级兜底**：`executeSubTasks.runOne` 在 agent 失败/空时，用无工具 `GenerateWithFallback` 再生成一次，保证每个 worker 至少有可拼接内容。
|
||||
|
||||
## 遗留问题（非本次修复范围）
|
||||
- 部分子任务产物仍含模型原样输出的 `｜tool｜` 转义残留（个别 worker 未完全收敛时把工具调用文本化），但最终 merge 正文干净，不影响主交付。
|
||||
|
||||
## 回归确认（修改未误伤其它路径）
|
||||
| 用例 | 路径 | 结果 |
|
||||
|---|---|---|
|
||||
| run_03（周末闲聊） | direct_answer | ✅ HTTP 200，4.2s，内容完整（纯文本直答，无产物） |
|
||||
| run_12（2026 诺贝尔奖联网查） | single_search / orchestrated | ✅ HTTP 收敛返回（ai_call_log 记录 123s success；curl 90s 断开属本端上限，服务端实际 123s 完成，不挂死） |
|
||||
|
||||
## 下一步建议
|
||||
- 单考 worker 空回复：在 `RunWithUsage` 或 worker 侧对「模型最终回复为空」做一次退避重试；或对不兼容 tool_calls 的路由降级为无工具生成。
|
||||
- 已确认修改未误伤 direct_answer / single_search 路径；剩 worker 空回复与单问调用偏慢，根因是当前路由 `deepseek-v4-flash` 对带 web_search 工具的多轮 tool_calls 支持不佳，属独立问题待商定。
|
||||
@@ -0,0 +1 @@
|
||||
{"message": "你好，简单介绍一下你自己，以及你能帮我做哪些事情？","specialist_key":"general-assistant","mode":"chat","stream":false}
|
||||
@@ -0,0 +1 @@
|
||||
{"code":0,"data":{"message":{"role":"assistant","content":"你好！我是一个 AI 通用助手，可以帮你处理各种文字和知识类任务。\n\n我能做的事情包括：\n\n- **问答与解释**：解释概念、查资料、梳理思路\n- **写作与润色**：写文章、邮件、文案、总结、改写\n- **翻译**：中英互译及多语言翻译\n- **学习辅导**：讲题、复习、制定学习计划\n- **编程帮助**：写代码、调试、解释代码、给方案\n- **信息整理**：总结长文、提炼要点、做表格/清单\n- **联网检索**：需要实时信息时，我可以检索并标注来源，不编造数据\n\n有具体问题直接发给我就行。","timestamp":"2026-09-25 22:05:32","type":"text"},"is_plan":false,"is_expert":false,"stream":false},"error":null,"message":"success"}
|
||||
@@ -0,0 +1,15 @@
|
||||
# run_16（直答路径回归）
|
||||
|
||||
- 用例：`message="你好，简单介绍一下你自己，以及你能帮我做哪些事情？"`
|
||||
- 意图：direct_answer（身份/能力问答，无联网、无编排信号）
|
||||
- 目的：验证 ctx 贯穿 + 西南 Ensemble worker 优化后，直答路径无回归
|
||||
- 结果：✅ **HTTP 200，3.6s** 返回，`is_plan=false`，纯文本结构化回答
|
||||
- 时间：2026-09-25 22:05:28
|
||||
|
||||
## 产出观测
|
||||
- 无编排产物（直接 `data.message.content` 文本）；
|
||||
- 回答列出了能力矩阵（问答/写作/翻译/辅导/编程/整理/联网检索）；
|
||||
- 直答路径不受通用助手编排器改造影响。
|
||||
|
||||
## 结论
|
||||
直答单轮路径稳定，未受本次 ctx 贯穿与收敛优化影响。
|
||||
@@ -0,0 +1 @@
|
||||
{"message": "帮我联网查一下：2026年9月，苹果最新发布的那款 iPhone 的起售价是多少人民币？","specialist_key":"general-assistant","mode":"chat","stream":false}
|
||||
@@ -0,0 +1 @@
|
||||
{"code":0,"data":{"message":{"role":"assistant","content":"**结论：截至我检索到的最新公开信息，2026 年 9 月的苹果秋季发布会尚未举行，也还没有官方公布的国行起售价。**所以这个问题目前**没有可核实的确定答案**，我不编造数字。\n\n补充几点可核实的信息：\n\n**1. 最近一次 9 月发布（2025 年）的实际情况**\n- 苹果于 2025 年 9 月发布 iPhone 17 系列，**国行起售价 5999 元**（256GB 起步，6.3 英寸 120Hz 屏）。\n- 来源：腾讯新闻、新浪等多家媒体对 2025 年 9 月发布会的报道（如「苹果发布 iPhone 17 搭载 A19 芯片，国行版起售价为 5999 元」）。\n\n**2. 关于 2026 年的情况（均为传闻，非官方）**\n- 目前网上流传的多是「前瞻/传闻」类文章，例如「九月苹果新品前瞻：iPhone 万元起步」「2026 苹果新品全家桶集体破万」，以及「苹果首款折叠屏 iPhone 或于 2026 年秋季亮相、起售价超 2000 美元」等说法。\n- 这些**属于媒体预测和爆料，不是官方定价**，不同来源数字互相矛盾（有的说涨价、有的说持平），不能当作事实引用。\n\n**建议**\n- 如果你想了解的是**已确定的机型价格**，请以 Apple 中国大陆官网「购买 iPhone」页面的实时标价为准。\n- 如果你确实在关注 2026 年 9 月的新品，建议等发布会（通常为每年 9 月）结束、苹果官网更新定价后再核。\n\n需要的话，我可以帮你**重新联网**查一下苹果官网当前在售机型的最新国行价格，或关注某个具体型号（如 iPhone 17 Pro / Pro Max）的售价。","timestamp":"2026-09-25 22:06:46","type":"text"},"is_plan":false,"is_expert":false,"stream":false},"error":null,"message":"success"}
|
||||
@@ -0,0 +1,16 @@
|
||||
# run_17（单问联网路径回归）
|
||||
|
||||
- 用例：`message="帮我联网查一下：2026年9月，苹果最新发布的那款 iPhone 的起售价是多少人民币？"`
|
||||
- 意图：single_search（实时单点事实 → web_search 工具 → SerpApi 等引擎）
|
||||
- 目的：验证联网单问在多重策略（roundWithEmptyRecovery + tool 死循环收敛）下诚实作答
|
||||
- 结果：✅ **HTTP 200，63.6s** 返回，`is_plan=false`
|
||||
- 时间：2026-09-25 22:05:42
|
||||
|
||||
## 产出观测
|
||||
- **诚实性达标**：明确指出「2026 年 9 月发布会尚未举行、无官方国行定价」，不编造数字；
|
||||
- 提供可核实的**历史事实**（2025 年 9 月 iPhone 17 国行起售价 5999 元，并标注来源）；
|
||||
- **区分官方事实与媒体传闻**（提及折叠屏爆料属于预测、相互矛盾，不作事实引用）；
|
||||
- 结尾给出复核建议（以 Apple 官网实时标价为准），并主动提出可再次联网查询具体型号。
|
||||
|
||||
## 结论
|
||||
联网单问路径在 SerpApi 多引擎 + text_gen worker 收敛优化后稳定，保持「搜索诚实性」项目价值观。
|
||||
@@ -0,0 +1 @@
|
||||
{"message": "请写一份关于\"人形机器人产业链上中下游\"的分析报告，重点包括上游核心零部件、中游整机制造、下游应用场景，并对比国内外主要玩家。","specialist_key":"general-assistant","mode":"chat","stream":false}
|
||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,32 @@
|
||||
# run_18（编排路径 · 重度搜索型 · 预算放宽后）
|
||||
|
||||
- 用例：`message="请写一份关于\"人形机器人产业链上中下游\"的分析报告，重点包括上游核心零部件、中游整机制造、下游应用场景，并对比国内外主要玩家。"`
|
||||
- 意图：**orchestrated**（产业链/上中下游/对比 → 强编排信号）
|
||||
- 跨预算验证：150s → 240s（`overallTimeout` 放宽），并加宽 worker 死循环收敛阈值（`toolRounds >= 5`）
|
||||
- 结果：⚠️ **HTTP 200，240.0s**（踩新的 240s 兜底边界返回），6.4KB
|
||||
- 时间：2026-09-25 22:12:38
|
||||
|
||||
## 两次对比
|
||||
| 项 | 预算150s（run_18首次） | 预算240s（本次） |
|
||||
|---|---|---|
|
||||
| 收敛 | 150s 兜底 | 240s 兜底 |
|
||||
| 产物 | S1 框架 + 4.6KB | S1 框架（更完整、含玩家清单/章节大纲）+ 6.4KB |
|
||||
| worker 报告 | S2-S6 空 | S2-S6 仍空 |
|
||||
|
||||
## ai_call_log（关键诊断）
|
||||
- 338：planSubTasks 拆解 19.3s success；
|
||||
- 339：主编排 240.0s；
|
||||
- **⚠️ worker 一条 `text_gen` 记录都没有**——说明 5 个 worker 的 `agent.Run` 均未跑完返回（runOne 未落日志），worker 卡在首轮/多轮 `generateWithTools` 的 HTTP 等待中，直到编排 ctx 截止。
|
||||
|
||||
## 根因判断（重视）
|
||||
路由 `chat_route_lmuai_deepseek_v4_flash` 的 `timeout_seconds: 90`。run_18 的 worker prompt 属「长输入、报告型」，3 个 worker 并发发起时 LLM 服务端响应极慢/挂起，单次调用逼近 90s 仍无返回，多轮叠加远超编排预算 → worker 无法在预算内写出报告。
|
||||
- 这不是「编排空回复/死循环」逻辑问题（对比 run_14 HTTP 对比 94s 正常完成、run_16/17 优秀）；而是 **LLM 服务端对「长 prompt + 并发报告型」请求的响应能力/排队**导致单次调用卡满 timeout。
|
||||
|
||||
## 编排侧已尽力的优化（本次已改）
|
||||
1. `overallTimeout` 150s → **240s**，给重度搜索型 worker 更多写稿预算；
|
||||
2. `RunWithUsage` tool 死循环收敛由「仅纯工具轮统计」放宽为「工具轮数 >= 5 即收敛」，并在历史含搜索素材时用无工具纯文本重生成结论。
|
||||
|
||||
## 待决策（超出「修」范围）
|
||||
- **调用级超时**：给编排 worker 的每次 `generateWithTools` 设一个更短的调用超时（如 30s），使慢调用快速失败、跳过该类 worker，避免单个慢 LLM 拖死整个编排；
|
||||
- **路由/并发**：评估为编排 worker 换一条对长 prompt 响应更稳的路由，或降低 `maxConcurrent`、减少长 prompt 并发排队；
|
||||
- **预算再放宽**：若接受更长等待，可把编排预算提到 300s+，但需权衡用户体验。
|
||||
Reference in New Issue
Block a user