模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第21章 — 多智能体编排的艺术
Token用量: 约 6,400 input + 2,100 output
21.3 智能体专业化设计
构建多智能体系统最容易走的一条路，是复制几个“通用 agent”，然后在 prompt 里给它们起不同名字。这当然能工作，但专业化程度很浅。真正的 specialization（专业化）不是换个称呼，而是让不同 agent 在权限边界、工具集合、延迟预期、评价标准、输出契约上真的不一样。OMO 的价值恰恰在这里：它的不同 agent 并不只是“人格不同”，而是“运行方式不同”。
最典型的四个角色是 Oracle、Explore、Librarian、Hephaestus。这些名字本身并不重要，重要的是它们对应的工程分工。
Oracle 是只读的。它负责观察、判断、给建议，但不直接改东西。只读约束意味着它更适合架构分析、问题定位、风险评估，因为它不会冲动地把“分析”和“行动”混在一起。
Explore 偏快速搜索和侦察。它的价值不是写出最漂亮的结论，而是尽快找到可能相关的路径、文件、证据、模式。它像一个高机动性的搜索员。
Librarian 面向外部知识，也就是仓库之外的文档、资料、参考实现。它把“本地代码世界”和“外部知识世界”连接起来。
Hephaestus 则偏深度工作，适合更慢、更重、更彻底的实现与复杂推演。它不是先广撒网，而是下沉处理困难任务。
这四种角色最重要的启发是：专业化应当来自任务差异，而不是文案差异。 如果两个 agent 拥有相同权限、相同工具、相同节奏、相同产出要求，那它们本质上不是专业化，只是复制体。真正的专业化，至少要在结构上有一处明确不同。
其中，权限约束尤其关键。权限不是单纯安全控制，它还会改变 agent 的认知姿态。只读的 Oracle 不必想着“顺手改一下”；它会更专注于诊断。快速搜索型 Explore 不应该拥有和深实现型 Hephaestus 一样的越界能力，否则轻量任务会被过度执行。外部研究型 Librarian 可能需要网络访问，但不一定需要写文件权限。这些边界会强迫角色更纯粹，也能降低 overreach（越权扩张）的风险。
OMO 的 category system（类别系统）进一步把这件事做得更好。很多系统其实存在一种隐藏偏差：表面上在“选 agent”，本质上是在“选模型”。开发者常常把贵模型、强模型、快模型直接等同于某种角色，这会让架构决策被 model bias（模型偏见）牵着走。类别系统的价值，在于它先判断“这是什么问题”，再决定“该交给什么角色和什么模型组合”。这就把任务语义和模型经济学分离开了。对于系统设计来说，这是非常健康的做法。
要设计一个真正有用的专业化体系，通常可以从五个维度入手。
第一是 scope（问题范围）。这个 agent 到底负责哪一类问题？仓库搜索、外部检索、代码生成、验证审计、方案比较，还是架构评审？范围需要足够明确，否则路由会混乱。
第二是 authority（权限级别）。它能做什么？只读、可编辑本地文件、可执行 shell、可访问网络、可触及凭证、可触发部署，还是只能给建议？权限边界决定风险边界。
第三是 tempo（工作节奏）。它是追求快、追求广，还是追求深、追求稳？快搜索型与深分析型不应该共用同一时间预算期待。
第四是 artifact style（产物风格）。它应该返回什么？原始证据、文件列表、结构化摘要、可执行计划、代码补丁、还是结论建议？很多 handoff（交接）失败，其实都源于输出风格不匹配。
第五是 handoff contract（交接契约）。它的结果是给谁看的？父 agent、另一个子 agent、还是最终用户？输出格式是否便于后续消费？如果搜索 agent 只返回大段 prose，而父 agent 真正需要的是 file path + confidence + next step，那么这个角色设计就是不合格的。
这也引出一个常见反模式：过早过细地拆角色。很多团队一上来就造十几个窄角色，比如 markdown 修复 agent、yaml 审计 agent、frontend linter agent，看起来很“专业”，但实际上会带来路由混乱、prompt 维护成本上升、工具边界重复描述等问题。更好的做法是先从少数几个粗粒度但真正有结构差异的角色开始：只读顾问、快速搜索员、外部研究员、深执行者、验证者。只有当错误模式已经足够清晰时，再继续细分。
Claude Code 在这方面提供了另一种启发。它的子代理往往工作在更干净、更隔离的上下文窗口里，这让角色边界更清楚，输入输出也更容易审计。OMO 则更强调多角色之间的持续协作、智慧继承与运行时接力。两种做法都可以成功，但共同点是：系统必须能够解释“为什么是这个 agent，而不是另一个”。如果系统自己都说不清楚角色选择逻辑，那么所谓专业化，大概率只是命名游戏。
从组织设计角度看，多智能体专业化很像公司分工。一个健康组织不会让所有人拿同样的权限、做同样的事、写同样的产物。Oracle、Explore、Librarian、Hephaestus 之所以有意义，不是因为名字神话化，而是因为它们分别对应四种长期存在的工程工作模式：观察、搜索、研究、深建造。
所以，专业化设计的核心规则可以浓缩成一句话：按功能、边界和交接契约来设计 agent，而不是按名字和想象来设计 agent。 用权限限制防止越权，用类别系统消除模型偏见，用结构化产物降低交接损耗。否则，多智能体系统很容易退化成“很多同类 agent 轮流说话”，而不是一个真正可运行的分工体系。