MoA 多引擎搜索与整合流程 — 评审用文档

一、整体架构

本流程解决的核心问题：遇到技术问题后，如何用结构化方式搜索、验证、输出最优方案。

用户问题
  ↓
Phase 1: 问题识别与拆解（Agent 1）
  ↓
Phase 2: 多引擎并行搜索（Agent 2/3/4，各负责一个引擎）
  ↓
Phase 3: 交叉验证与去重（Agent 3）
  ↓
Phase 4: MoA 整合输出（Agent 4）

二、Phase 1：问题识别与拆解

输入：用户描述的问题现象
输出：

问题分类标签（系统/网络/软件/硬件/配置/权限/依赖/性能…）
拆解为 2-4 个独立可搜索的子问题
每类子问题对应的中英文搜索关键词（各 2-3 组）
目标搜索引擎组合

关键原则：

先确认复现条件，不跳结论
用户给的信息可能不全，列出需补充的关键信息
子问题拆解必须互斥（MECE 原则）
中文问题优先知乎 + web_search，技术深度问题加 arxiv

示例（N1 SSH 连不上）：

分类：软件 + 配置 + 硬件
子问题 1：SSH 改密码后自动断开 → 关键词 “armbian 改密码自动退出 SSH”
子问题 2：MAC 地址变化 → 关键词 “armbian MAC address change eth0”
子问题 3：USB 供电不足 → 关键词 “N1 USB power insufficient”

三、Phase 2：多引擎并行搜索

输入：子问题 + 搜索关键词 + 目标搜索引擎组合
输出（每个引擎独立返回）：

至少 3 条不同来源的相关结果
每条结果标注：来源类型/可信度/适用条件/失败案例
提取关键命令/配置/代码片段
标注冲突信息（不同来源给出矛盾方案时）

已注册的搜索引擎

引擎	类型	触发条件	配置依赖
web_search	全网搜索	默认启用，任何问题都搜	无
知乎搜索	中文社区	中文经验、评测、口碑	ZHIHU_API_KEY
微信读书	书籍内容	书籍知识、理论框架	WEREAD_API_KEY
web_extract	页面全文	需要读特定 URL 的全文	无

搜索引擎选择指南

问题类型	首选	备选	理由
报错/bug	web_search → GitHub Issues	知乎	bug 已被报告+修复
配置/操作	web_search + web_extract	知乎	需要读完整文档
中文经验/口碑	知乎搜索	web_search	中文社区深度讨论
书籍理论	微信读书	arxiv	系统知识来自书籍
学术/算法	arxiv	web_search	前沿研究在论文中

搜索引擎调用模板

# 引擎 1: web_search
from hermes_tools import web_search
result = web_search("关键词", limit=5)
# 返回: {"data": {"web": [{"url", "title", "description"}, ...]}}

# 引擎 2: web_extract（读全文）
from hermes_tools import web_extract
result = web_extract(["https://url1"])
# 返回: {"results": [{"url", "title", "content", "error"}]}

# 引擎 3: 知乎搜索
# POST https://developer.zhihu.com/api/v1/content/{endpoint}
# 需要 ZHIHU_API_KEY + 动态 X-Request-Timestamp
# 注意: 参数名 "Query" 大写 Q

# 引擎 4: 微信读书
# POST https://i.weread.qq.com/api/agent/gateway
# 需要 WEREAD_API_KEY (格式 wrk-xxxxxxxx)
# body: {"api_name": "/store/search", "keyword": "...", "skill_version": "1.0.3"}
# scope: 0=全部, 10=电子书, 6=作者, 12=全文, ...

四、Phase 3：交叉验证

输入：所有搜索引擎的搜索结果
处理逻辑：

去重：合并相同方案，保留最完整版本
冲突解决：矛盾方案按以下优先级判断
- 官方文档 > 社区经验
- 近 12 个月内方案 > 旧方案（技术栈可能已变）
- 有失败记录的方案要标注
- 适用环境匹配度（OS/版本/硬件）
成功率排序：标注每个方案的已知失败场景

输出：

按成功率排序的方案列表
每个方案：步骤/预期结果/失败回滚方法/适用条件
冲突说明：哪些方案互斥，为什么

五、Phase 4：MoA 整合输出

输入：交叉验证后的方案列表
输出结构：

## 问题诊断
- 症状：[复述用户问题]
- 根因：[最可能的原因，按概率排序]
- 需要确认：[让用户验证的关键信息]

## 推荐方案（按成功率排序）
### 方案 1：[名称] — 成功率 XX%
- 步骤：
  1. `命令1`
  2. `命令2`
- 适用条件：[什么环境适用]
- 已知失败：[什么情况下不行]
- 回滚：[失败了怎么恢复]

### 方案 2：...

## 其他参考
- 备选方案（成功率较低但有特定优势）
- 相关文档链接

## 预防建议
- 如何避免同类问题再次发生

六、引擎扩展机制

新增搜索引擎只需 3 步：

在注册表加一行（名称/类型/触发条件/配置依赖）
在调用模板加代码（endpoint + auth + 参数格式）
在选择指南加一行（什么情况下用这个引擎）

无需改动 Phase 1/3/4 的任何内容。

七、约束与规则

不伪造信息：找不到就是找不到，不要编造命令或方案
标注来源：每个方案标注来自哪个信息源
标注时效：注明方案适用的软件版本和时间范围
不跳结论：先确认复现条件再下判断
安全警告：涉及 root/刷机的操作必须标注风险
零成本优先：优先推荐免费方案，不接受付费方案
精确描述：涉及硬件操作的描述必须精确到按键/端口/文件路径

八、实际运行示例

完整示例见之前的 N1 SSH 连不上测试结果，包含：

3 个子问题 × 3 个引擎 = 9 路并行搜索
4 个方案，每个含成功率/步骤/回滚/适用条件
80% / 70% / 65% 成功率排序
来源标注（恩山论坛 thread-423624 / GitHub ophub#968 / ZNDS）

九、待评审的关键决策点

请评审以下设计决策的合理性：

9.1 引擎数量 vs 并行效率

当前默认并行 2-4 个引擎
问题：引擎越多搜索越全面，但 token 消耗和延迟也越高。是否有上限？是否需要智能选择引擎数？

9.2 成功率估算

方案按"成功率 XX%“排序
问题：成功率没有量化标准，是主观估算。是否需要改进（比如引用来源数、验证次数、评论反馈）？

9.3 微信读书的整合时机

微信读书搜的是书籍知识，不是技术文档
问题：技术问题用微信读书搜真的有用吗？还是只在涉及理论/算法时才触发？

9.4 Agent 角色划分

当前 4 个 Agent，但实际是同一个 LLM 的顺序调用（非真正的并行多智能体）
问题：4 个角色是否过度复杂？能否合并为 2 个（搜索 Agent + 汇总 Agent）？

9.5 搜索关键词生成

Phase 1 生成中英文各 2-3 组关键词
问题：关键词质量直接影响搜索结果。是否需要引入"关键词优化"子步骤（如去停用词、同义词扩展、技术术语标准化）？

9.6 冲突解决优先级

官方 > 社区，新 > 旧，有失败记录要标注
问题：是否漏了"高赞 > 低赞”（社区质量维度）？“官方文档 vs 社区踩坑"冲突时，实际社区经验往往更实用，优先级是否要调整？

9.7 中文 vs 英文搜索源权重

规则说"英文优先”
问题：对于 N1、路由器、嵌入式等中文社区活跃领域，这个优先级是否正确？是否应该按问题领域动态调整？

MoA 多引擎搜索与整合流程 — 设计评审