Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead 章节: 第14章 — 工具系统深度对比 Model: openai/gpt-5.4 Generated: 2026-04-01 Token Usage: 当前API环境不可见
14.4 工具组合模式
真正成熟的工具系统，不能只看“单个工具能做什么”，而要看这些工具能不能被稳定地 组合（composition） 成更高阶的工作流。所谓工具组合，就是把多个小操作拼成一条可重复、可迁移、可积累经验的执行路径。软件工程中的真实任务几乎从来不是一步完成的，它通常包含：调查、规划、检索、阅读、修改、验证、委派、汇总、续跑。于是，工具系统的上限，往往不取决于某一个最炫的工具，而取决于工具之间能否形成可靠的组合模式。
这里最关键的变化，是 Task tool 逐渐从普通能力工具，升级成了“编排原语（orchestration primitive）”。所谓原语，就是构建更复杂行为的最小基础单元。传统编码 Agent 往往把工具理解为“访问外部世界的方法”：读文件、跑 shell、搜代码、改文本。但新的系统开始把一部分工具理解成“创建工作流结构的方法”。Task tool 不再只是去操作环境，它本身就是在创建一个新的工作单元。这个变化非常重要，因为它意味着工具层开始承担控制层的职责。
OMO 在这方面最典型。它的后台代理创建、任务输出读取、session 延续、todo 纪律，这些能力共同构成了一种非常清晰的组合模式：主代理把子问题委派出去，自己继续处理别处，稍后再回收结果并整合。这已经不是“几个工具偶然连起来”，而是一套以工具为载体的编排机制。也正因此，OMO 的工具看上去常常不像传统助手的工具——它们并不主要服务于本地小动作，而是在服务于过程结构本身。某种意义上，OMO 的工具系统已经部分承担了“Agent 操作系统”的角色：有的工具负责创建工作，有的负责跟踪状态，有的负责取回结果，有的负责维持上下文连续性。
Claude Code 也在朝这个方向发展，只是表达方式更产品化。像 SendMessageTool 这类工具，本质上是在承认：大任务不应该都压缩成单线程的单上下文执行，系统需要显式的消息传递、任务协调和上下文切换机制。差别在于，Claude Code 更倾向于把这些组合模式包装进统一且相对平滑的产品体验里，而 OMO 则更直接地把编排控制面暴露给模型和高级操作者。
OpenCode 的位置还是更基础一些。它提供了良好的组合基底：文件、搜索、编辑、bash、patch、web、MCP 等原语都可以被串成工作流，但宿主本身没有像 OMO 那样在工具层上形成重度编排教义。它更像一个可以支撑组合的通用底座，而不是直接替你定义组合范式。也正因为如此，OMO 才能在 OpenCode 之上再造一层更高阶的工具组合体系。
另一种非常关键的组合模式，是 Skill tool 的升级。Skill 在早期往往被理解成“提示词模板”或“任务说明书”，但在更成熟的系统里，它开始演化成一种打包的操作知识。也就是说，skill 不只是告诉模型“说什么”，更是在告诉模型“这类问题通常怎么做、按什么步骤做、需要注意什么约束”。如果 skill 再进一步绑定嵌入式 MCP，那么它甚至会连同外部能力一起打包进来。此时，工具组合就不再是“工具 + 工具 + 工具”，而变成了 工具 + 程序性记忆（procedural memory）。
程序性记忆这个说法，指的是“会做某件事的方法知识”，不同于“知道某件事实”的陈述性知识。把 skill 做成程序性记忆模块，意味着系统可以把专家经验沉淀成可复用工作流，而不必把每一种行为都硬编码进核心。OMO 在这一点上尤其明显：skill 可以从简单 prompt 模板演变成更复杂的操作模块，里面有步骤、约束、流程、甚至嵌入的 MCP 服务。这样一来，skill 已经不只是“文档”，而是在变成一种微型运行时：一部分是说明书，一部分是策略，一部分是能力扩展。
工具组合模式还揭示了另一条重要原则：最好的工具系统，应该尽量减少对某一个单独工具的绝对依赖，而是鼓励形成稳定的复用路径。 比如，一个稳健的代码修改流程，可能经常复用“search → read → analyze → patch → diagnostics → test”；一个更高级的编排流程，则可能是“spawn task → continue local work → retrieve output → integrate results → verify”。当这种模式变稳定时，系统能力就不再依赖某一个孤立工具，而是依赖一组高复用组合。
这也解释了为什么前面我们反复强调“工具膨胀是失败模式”。工具太多、太碎，会让组合反而更困难，因为动作空间被人为切得太细，模型很难形成稳定路径。工具适度、边界清晰，才更利于组合。真正高级的工具设计，不是不断发明彼此孤立的新工具，而是设计那些能够彼此协作、产生高阶行为的工具关系。
从长期看，编码 Agent 的工具系统很可能会越来越像分层操作环境。最底层是原始能力工具：文件系统、shell、搜索、web。上面一层是语义工具：AST、LSP、diagnostics。再往上是编排工具：Task、session 管理、消息传递、续跑控制。旁边还有 skill，作为可复用的程序性知识模块。OpenCode 提供扎实底层，OMO 在其上做出浓重的编排与 skill 层，Claude Code 则把这些模式以更商业化、更产品化的形式整合进体验中。
因此，比较工具系统时，最关键的问题已经不再是“你有多少工具”，而是“你的工具能稳定组合成什么样的工作流”。真正决定 Agent 上限的，不是工具名录，而是组合能力。而在这一点上，Task 与 Skill 从普通工具升级为编排原语，可能正是这一代编码 Agent 架构里最值得注意的变化之一。