模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第15章 — 智能体编排对比
Token用量: 约 4,700 input + 1,190 output

15.3 智能体专业化

多智能体系统真正的分水岭，不在于“有几个 agent”，而在于这些 agent 是否真的专业化。如果只是复制出多个同样的助手，那只是并发，不是分工。只有当不同智能体拥有不同职责、不同上下文边界、不同工具权限、不同信任等级时，系统才从“多个副本”变成“一个团队”。

OpenCode 本身提供了专业化的基础材料：可以定义 agent、可以选模型、可以接命令、可以配工具。但它整体仍然偏通用平台思路。也就是说，OpenCode 可以让你做专业化，但不会强制你这么做。角色边界更多是开发者约定，而不是宿主强约束。

OMO 则明显更进一步。它把角色专业化做成了系统设计的一部分。最典型的三个角色就是：Oracle、Explore、Librarian。

Oracle 是只读角色。这个设计表面看只是一个权限限制，实际上非常关键。很多 agent 的失败，不是因为它不会分析，而是因为它在分析还没完成时就开始改东西。Oracle 的意义就在于：它可以查、可以想、可以总结，但不能写。这样一来，它更像审计员、代码评审员、仓库导览员，而不是执行者。对于问题定位、架构理解、风险审查，这种只读角色极其有价值。

Explore 则是“快速内部探索者”。它不是为了产出最终报告，也不是为了承担完整执行，而是为了高效率地在仓库内部找线索、扫路径、定位候选文件、汇总发现。对大仓库来说，搜索本身就是一项重劳动。如果让主执行 agent 一边推进任务，一边自己全仓搜索，它的上下文预算很容易在“找路”阶段就消耗掉。Explore 的作用就是把“搜索成本”从主上下文中剥离出去。

Librarian 处理的是外部知识。这个角色的意义在于它维持了“仓库内事实”和“仓库外事实”的边界。代码里有什么，是一回事；官方文档、网络资料、API 外部行为是另一回事。把外部知识检索交给 Librarian，有助于父智能体判断证据来源，也能减少把外部经验误当成本地事实的风险。

真正高明的地方，不只是 prompt 不同，而是 prompt + 权限约束 一起生效。OMO 的角色化不是“请你扮演 Oracle”，而是“你是 Oracle，并且你确实不能做某些事”。这很重要，因为 LLM 的行为具有机会主义倾向：如果工具开着，模型常常会顺手多做一步；如果权限没关死，再严格的提示词也可能慢慢漂移。能力边界比文字描述更硬。

这种“权限支撑的专业化”能防止几个非常典型的问题。

第一是越权扩张。搜索 agent 本来只该找资料，结果因为工具权限没控住，顺手就改了代码。

第二是上下文污染。探索阶段往往包含大量未验证猜测。如果同一个 agent 又负责最后落地执行，这些猜测就可能变成行动依据。

第三是责任模糊。当一个角色天然是只读的，或者天然只负责外部资料时，父智能体和人类开发者就更容易判断：这份结果到底应不应该被直接信任。

Claude Code 也支持一定程度的专业化，比如不同 task、不同 agent 定义、不同工作线程，但它通常更注重产品体验的一致性，而不是像 OMO 那样强烈地命名和制度化角色。换句话说，Claude Code 的专业化更“柔性”，OMO 的专业化更“制度化”。

从更一般的系统设计角度看，专业化出现的条件其实和人类组织很像：当“频繁切换工作模式”的成本，高于“做任务分工和结果整合”的成本时，专业化就值得。搜索、规划、执行、验证、外部检索，本来就是不同心智模式。让一个上下文在这些模式之间来回切换，既贵又容易乱。

当然，专业化不是越多越好。角色太多会导致 handoff 成本上升。这里的 handoff 可以理解为“任务交接成本”——一个角色把中间结果交给另一个角色时，需要重新解释背景、压缩重点、重建信任。角色边界太细，会让系统把大量 token 花在交接上，而不是花在解决问题上。

所以最好的设计原则不是“把所有事情都拆成专门 agent”，而是：只在失败模式不同的地方做专业化。如果某类工作最大的风险是“过早动手”，就给它只读权限；如果某类工作最大的成本是“全仓搜索”，就让它专做探索；如果某类工作最大的问题是“证据来源不清”，就给它外部知识专责角色。

从这个角度看，OMO 的 Oracle、Explore、Librarian 不是命名游戏，而是一种对 agent 失败模式的系统回应。它的核心观点是：编码智能体最容易出错的地方，不在某一个具体模型，而在把搜索、执行、验证、外部知识混在一个不受约束的上下文里。而权限约束，正是把这种观点从提示词提升到架构层的关键一步。