摘要

关键词：SkillMoE、Hermes Bot、Agent Profile、专家路由、多智能体

当一个 Agent 同时拥有几百个技能时，“能力更多”不一定意味着“任务完成得更好”。无关技能会增加固定索引，容易造成路由混乱；不同领域的记忆、工具和安全边界也可能互相干扰。SkillMoE 的做法是把技能包封装成独立的 Hermes Bot，让当前对话中的主 Agent 只负责理解需求、选择专家和验收结果。

一、架构是什么

主 Agent 不是一个额外的 Bot

在这套架构中，用户正在对话的 Agent就是主 Agent。它不对应一个新建的 main-agent Profile，也不需要再复制一份主 Agent。

主 Agent负责四件事：

  1. 理解用户的自然语言需求；
  2. 明确目标、背景、限制和验收标准；
  3. 判断由自己完成，还是交给专家 Bot；
  4. 对专家返回的结果做最终复核。

因此，用户不需要学习新的命令，也不需要在消息里显式写“调用专家团”。

一个专家包对应一个 Hermes Bot

Hermes 的 Bot Mode 建立在 Profile 之上。一个 Profile 是一个相对独立的 Agent 运行空间，拥有自己的模型配置、记忆、会话、Skill 和状态[6]。Bot Mode 只是把这些 Profile 组织成可以创建、编辑和删除的 Bot roster[1]。

SkillMoE 不重新实现 Bot，而是直接利用这个原生能力：

SkillHub 专家包
      ↓
独立 Hermes Profile / Bot
      ├─ 包级 Skill
      ├─ 子 Skill
      ├─ 独立 SOUL.md
      ├─ 独立记忆
      ├─ 独立会话
      └─ 独立模型与工具配置

主 Agent 不把专家的完整 Skill 正文复制进自己的系统提示。它只保留路由所需的最小能力卡，例如：

专家：论文检索
能力：论文发现、来源整理、基础事实核查
适合：需要公开资料和学术来源的任务
不适合：生产部署和未经核验的结论
状态：active

这张能力卡是路由标签，不是专家 Skill 的替代品。

一次任务如何流转

用户消息
  ↓
主 Agent 提取真实目标
  ↓
补齐背景、约束、风险和验收标准
  ↓
判断是否匹配专家
  ├─ 无匹配：主 Agent 直接执行
  └─ 有匹配：先告诉用户交给哪个专家及原因
                    ↓
              调用对应 Hermes Bot
                    ↓
              专家返回结果、证据和风险
                    ↓
              主 Agent 最终复核
                    ↓
              回复用户

专家收到的不是用户的一句模糊原话，而是主 Agent整理后的任务：

  • 任务目标；
  • 必要背景；
  • 输入材料；
  • 明确限制；
  • 验收标准；
  • 风险等级；
  • 专家不应执行的动作。

专家团的生命周期

SkillMoE 给每个专家设置状态门禁：

状态 是否自动派发 含义
pending 否 Bot 已创建，但尚未完成验收
validated 否 已通过能力和安全验收，等待启用
active 是 可以自动参与路由
quarantined 否 存在内容、完整性或安全问题

因此，创建 Bot 不等于立即信任 Bot。SkillHub 包需要先检查来源、文件完整性、frontmatter、工具权限、危险命令和能力边界。

在实际部署中，技能包不应直接获得自动调用资格。正确做法是先检查来源、文件完整性、frontmatter、工具权限、危险命令和能力边界，再根据结果进入 pending、validated、active 或 quarantined 状态。SkillHub 的专家包页面可以作为候选能力来源，但不能替代这套准入流程[7]。

二、现有类似架构

SkillMoE 不是凭空出现的全新多智能体理论。它组合了多种成熟模式，但组合重点不同。

Supervisor

Supervisor 模式由一个主管 Agent 负责协调多个 Worker：

Supervisor
  ├─ Worker A
  ├─ Worker B
  └─ Worker C

它和 SkillMoE 最接近。区别在于，普通 Supervisor 往往会给主管暴露较完整的 Worker 描述、工具定义或任务接口；SkillMoE 则尽量只让主 Agent读取最小能力卡，把详细 Skill 留在专家 Profile内部。

Supervisor 更适合专家数量有限、任务需要动态拆解的系统。SkillMoE 更关注专家数量扩大后，如何控制主 Agent的固定上下文和成员生命周期。

Agent-as-Tools

Agent-as-Tools 把另一个 Agent 暴露成主 Agent可以调用的工具。OpenAI Agents SDK 将“Agent 作为工具”和 handoff 都作为多 Agent协作原语[2]。

它的典型形态是：

主 Agent
  ├─ call research_agent(...)
  ├─ call code_agent(...)
  └─ call writing_agent(...)

SkillMoE 可以使用类似的调用方式，但额外强调：

  • 专家是长期存在的 Hermes Profile，而不是临时函数；
  • 专家拥有独立记忆和 Skill；
  • 主 Agent不需要加载专家的完整 Skill；
  • 专家加入和退出需要经过登记和状态管理。

Handoff

Handoff 是把任务控制权从一个 Agent 转移给另一个 Agent。转移后，新的 Agent 可能直接面向用户继续对话。

SkillMoE 默认不把控制权永久转移出去。专家负责执行专业部分，主 Agent仍保留最终验收权：

主 Agent → 专家执行 → 主 Agent验收 → 用户

这样可以保持统一的交互入口，也能避免专家直接发布内容、修改生产环境或给出高风险结论。

LangGraph Supervisor

LangGraph Supervisor 使用状态图和 Supervisor Agent组织多个专业 Agent。LangChain 的文档将 Supervisor 描述为由中央 Supervisor协调专业 Worker 的模式[3]。

两者的关系可以理解为：

  • LangGraph 是编排和状态机框架；
  • SkillMoE 是“技能包如何映射为专家 Profile，以及如何治理专家”的架构约束；
  • LangGraph 可以实现 SkillMoE 的调度流程；
  • SkillMoE 也可以在不引入 LangGraph 的情况下使用 Hermes Bot Mode。

LangGraph 更适合需要显式状态、循环、并行节点和复杂条件分支的工作流。SkillMoE 的基础版本更轻，重点是 Profile 隔离和按需路由。

AutoGen Selector Group Chat

AutoGen 的 Selector Group Chat 允许模型从参与者中选择下一位发言 Agent[4]。它更像一个受选择器控制的多 Agent 群聊：多个参与者共享协作过程，系统根据当前对话选择下一位发言者。

SkillMoE 的默认拓扑不同：

一个需求 → 一个最匹配专家 → 主 Agent验收

只有任务确实需要多领域协作时，才调用多个专家。它不默认让所有专家看到完整的共享对话，也不默认让专家轮流发言。

CrewAI Hierarchical

CrewAI 支持顺序、层级和混合式流程，层级模式通常由 Manager Agent分配任务给不同角色 Agent[5]。

和 SkillMoE 相比：

维度 CrewAI Hierarchical SkillMoE
组织单位 Crew 中的角色 Agent Hermes 原生 Profile/Bot
重点 任务分配和流程执行 Skill 包隔离和专家生命周期
专家状态 由 Crew 配置管理 有 pending、validated、active、quarantined 门禁
记忆隔离 取决于具体配置 Profile 原生隔离
运行环境 Crew 流程内部 Hermes Bot Mode / CLI / Desktop

Hermes Bot Mode

Hermes Bot Mode 是 SkillMoE 的底层运行时，而不是竞争架构。官方文档明确说明，Bot 本质上是 Profile；每个 Bot 有自己的角色、模型、记忆和 Skill，并可以从 Desktop 或 CLI 管理[1]。

SkillMoE 只增加三层约束：

  1. 主 Agent 负责需求明确和最终验收；
  2. 专家只通过最小能力卡参与路由；
  3. SkillHub 包必须经过准入、版本和安全状态管理。

三、SkillMoE 的优势

1. 减少主 Agent 的无关上下文

这是目前有直接实测数据支持的优势。

一次小样本对比实验中，分别测试了“主 Agent携带全量技能索引”和“主 Agent只做隔离路由”两种方式：

指标 全量技能索引 隔离专家路由
平均输入 token 6,780 183
平均总 token 7,639 732
平均延迟 14.27 秒 9.92 秒
路由准确率 33.3% 100%

隔离路由的输入 token 约下降 97.30%，总 token 约下降 90.42%，平均延迟约下降 30.47%。

但这个实验只有 6 个样本，任务领域和触发词都比较清晰，不能据此断言 SkillMoE 在所有任务上都优于单 Agent。它只能支持一个较窄的结论：

当主 Agent携带大量无关技能索引时，减少无关信息可能改善上下文成本和简单任务的路由稳定性。

2. 专家能力和记忆隔离

博客专家不需要携带运维专家的工作流，运维专家也不需要加载医学或论文 Skill。不同 Profile 的记忆不会自动混在一起，专家可以有不同的：

  • 模型；
  • 推理强度；
  • 工具集；
  • 工作目录；
  • SOUL.md；
  • 记忆策略；
  • 外部服务权限。

这比把所有角色说明和工作流堆进一个 Agent 更容易维护。

3. 可以根据任务难度动态选模型

专家不是固定绑定主 Agent的模型。主 Agent可以根据任务难度在调用时选择：

任务 模型 推理强度
简短、确定性任务 gpt-5.6-terra minimal
普通专业任务 gpt-5.6-terra low 或 medium
多步骤、需要深度判断 gpt-5.6-sol high

模型强度不等于安全审查。医疗、法律、生产、支付和删除操作仍需要独立的风险门禁。

4. 专家可独立更新和删除

新增专家不需要修改主 Agent的完整系统提示，只需要：

  1. 创建一个新的 Hermes Fresh Profile；
  2. 安装对应 SkillHub 包；
  3. 写入简短 Description；
  4. 通过 smoke test；
  5. 加入专家登记表。

删除专家也使用 Hermes 原生 Profile 删除能力，不需要改动主 Agent本身。

这使专家团具备类似插件系统的可维护性：专家可以增删，主 Agent保持稳定。

5. 更容易做权限和风险隔离

高风险专家可以单独限制：

  • 可用工具；
  • 可访问目录；
  • 是否允许网络；
  • 是否允许外部写入；
  • 是否允许运行命令；
  • 是否只能返回建议而不能执行动作。

专家输出必须经过主 Agent复核，不应直接被视为权威结论。对 SkillHub 包而言，quarantined 状态尤其重要：包可以先保存、检查和人工测试，但不必立即进入自动路由。

6. 用户交互保持简单

用户不需要知道专家团内部结构，也不需要记住每个 Bot 名称。只要直接描述需求即可：

用户：帮我写一篇技术博客
主 Agent：识别为博客写作任务，交给博客专家，并说明原因
专家：完成文章初稿
主 Agent：复核结构、事实、引用和交付要求

这比让用户自己判断“应该调用哪个 Agent”更自然。

四、限制和还需要完善的地方

SkillMoE 目前是可用的工程架构，但还不是经过大规模评测的成熟产品。

路由能力卡不能过于简略

如果主 Agent只知道专家名称，不知道能力边界，相近专家之间容易误路由。更合理的能力卡至少应该包含：

  • 能处理什么；
  • 不处理什么；
  • 需要什么输入；
  • 返回什么输出；
  • 风险等级；
  • 版本号；
  • 当前状态。

需要更严格的评测

下一轮评测应至少包含：

  • 100 条以上任务；
  • 模糊任务；
  • 跨领域任务；
  • 多跳任务；
  • 多次重复运行；
  • P50/P95 延迟；
  • 实际模型成本；
  • 最终任务成功率；
  • 错误路由和回退效果；
  • 专家版本更新后的漂移。

专家结果可能污染主 Agent

专家返回的文本可能包含错误、过度自信结论，甚至恶意指令。主 Agent必须把专家结果当作不可信输入，不能因为“专家是专家”就跳过：

  • 来源核查；
  • 权限核查；
  • 文件回读；
  • 外部状态验证；
  • 安全检查；
  • 用户确认。

Bot 越多不等于越好

创建 Profile 很容易，但长期维护大量专家仍然有成本：

  • 技能版本会漂移；
  • SkillHub 包可能下架；
  • 多个包可能功能重复；
  • 路由关键词可能冲突；
  • 某些低频 Bot可能不值得常驻维护。

更合理的策略是：

稳定高频专家 → 长期 active
高风险专家   → pending / validated
低频专家     → 按需创建或手动调用
异常包       → quarantine

需要考虑专家数量过多后的路由开销

主 Agent只加载最小登记信息，因此固定上下文不必随专家数量线性增加。但如果把所有专家的完整 Description 都放进每次路由请求，仍然会产生一次性成本。

后续可以增加：

  • 按一级领域分层索引；
  • 本地关键词预筛选；
  • 轻量向量检索；
  • Top-K 候选路由；
  • 低置信度时向用户澄清。

五、结语

SkillMoE 不是一种完全脱离已有研究的新型多智能体理论。它更像是一种工程组合：

Hermes Profile/Bot
+ SkillHub 技能包
+ 极简能力卡
+ 主 Agent 路由
+ 专家隔离
+ 结果复核
+ 状态准入

它和 Supervisor、Agent-as-Tools、LangGraph、AutoGen、CrewAI 等方案共享很多思想，但它的重点不是让更多 Agent 同时讨论，而是让一个大型技能库变成一组可维护、可隔离、可按需调用的专家 Profile。

目前最有把握的优势是上下文隔离和专家生命周期管理。小样本实验已经显示出上下文成本和简单路由稳定性的改善，但最终质量、复杂任务泛化能力和大规模运行成本，仍需要更严格的评测。

因此，对 SkillMoE 最准确的评价不是“它已经全面优于单 Agent”，而是：

当 Agent 的技能数量和领域跨度不断扩大时，把能力拆成原生 Profile，再由当前对话中的主 Agent按需路由，是一条值得继续验证的工程路径。

参考资料

[1] Hermes Agent. Bot Mode

[2] OpenAI Agents SDK. Tools and Agents as Tools

[3] LangChain. Subagents / Supervisor Pattern

[4] Microsoft AutoGen. Selector Group Chat

[5] CrewAI. Documentation

[6] Hermes Agent. Profiles: Running Multiple Agents

[7] Tencent SkillHub. 专家包