模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第19章 — 工具设计的艺术
Token用量: 约 6,800 input + 1,850 output
19.4 工具组合 vs 工具膨胀
在 coding agent 设计里，一个非常关键但经常被误判的问题，是系统到底是在形成 tool composition（工具组合能力），还是正在滑向 tool bloat（工具膨胀）。表面上，二者都可能体现为“工具越来越多”；但本质上，它们是完全不同的两件事。
工具组合，指的是一组少量但边界清晰的工具，可以像语言里的基础语法那样自然拼接，形成大量稳定工作流。工具膨胀，则指的是工具越来越多，但很多只是局部重复、边界模糊、需要额外解释，最终让模型的路由成本不断升高。前者带来杠杆，后者带来摩擦。
因此，单纯比较工具数量并不能直接得出优劣，但数量仍然是一个很好的切入口。Claude Code 某个阶段可能有 61 个工具，OMO 某个阶段可能有 26 个工具。问题不在于 61 是否一定优于 26，而在于：这 61 个工具是否真正形成了更大的可组合能力空间，还是只是增加了选择复杂度？这 26 个工具是否足够构成高杠杆工作流，还是只是因为功能不全而显得精简？
这里 OMO 提供了一个很重要的例子：task 工具作为 orchestration primitive（编排原语）。所谓原语，可以理解为某种“基础操作单元”，它本身并不等同于最终功能，但它能作为更大结构的搭建积木。Task/delegate 这一类工具的价值，不只是“又多了一个工具”，而是它改变了整个系统的行动语法。
在没有 task primitive 的系统里，agent 往往只能在单一上下文里做所有事：查资料、搜代码、验证假设、生成总结、继续推进。加入 task primitive 之后，系统突然多出了一整类新动作：可以把某个子问题切出来，交给更窄上下文、更合适 prompt、甚至后台并行的子 agent 去做，然后在稍后把结果回收回来。这不是单点能力增加，而是工作流维度的扩展。
这就是真正的 composition。一个工具的价值，不只看它直接做了什么，还要看它是否改变了其他工具被组织起来的方式。能放大整个系统组合空间的工具，通常比十个局部 helper 更有价值。
反过来看，tool bloat 往往有几个明显征兆。
第一，多个工具解决的是非常相近的问题，但命名、参数、返回格式又不完全一致，模型需要反复比较。
第二，很多工具只有在 prompt 强行提醒时才会被使用，缺乏自然工作流位置。
第三，新增工具没有打开新的能力空间，只是为原有路径再提供一条差不多的替代路线。
第四，系统文档需要花大量篇幅解释“这个工具和那个工具有什么微妙区别”，这往往意味着边界本身设计得已经不够健康。
Claude Code 的大工具表面展示了一个成熟产品会面临的真实张力：随着功能扩张，工具数量上升是自然的。浏览器交互、任务管理、系统操作、搜索、诊断、扩展、记忆、后台任务，都会推高库存。问题在于，工具一多，系统就必须同步投入更强的 ACI、权限边界、路由提示和输出整形，否则工具数增长很快就会转化成工具膨胀。
OpenCode 的启示则更偏底层：如果宿主本身的注册模型、命名空间、执行语义不清晰，那么上层无论加多少工具，都很难形成高质量组合。也就是说，组合能力不是工具数量自然堆出来的，而是要靠底盘质量托住。
判断一个工具体系更偏“组合”还是更偏“膨胀”，可以看几个信号。
其一，主要工作流是否能被表达成少数清晰工具的短链条。比如搜索 → 读取 → 编辑 → 诊断 → 测试，或者委派任务 → 后台执行 → 结果回收。这种链条如果自然，就说明系统存在组合逻辑。
其二，工具之间是否低重叠。模型是否经常在三个看起来差不多的工具之间犹豫？如果是，说明膨胀风险很高。
其三，系统中是否存在 multiplier tools（乘数型工具）。这类工具不是只能做一件小事，而是能改变其他工具的组合方式。Task、patch、session search、semantic navigation 这类工具通常就属于乘数型。
其四，工具文档整体是否能看出一套系统逻辑，而不是一堆彼此独立的零散说明。真正可组合的工具表，通常会有明显的内部结构。
这里可以借用一个来自线性代数的比喻：basis（基）。在线性代数里，基是一组最小向量集合，可以通过组合生成更大空间。类比到 agent 工具设计，一个好的工具集也应该像“工作流空间的基”。也就是说，不必太多，但应该足够强，足够正交，足够能组合出主要任务路径。
如果一个新工具的加入能显著扩展这个“基”的表达空间，它就值得；如果它只是给已有路径再多添一个差不多的替代物，它更可能是膨胀。
这也解释了为什么“更多不一定更好”。新增工具必须通过更高标准审查：它是否打开了新型工作流？是否替代了笨拙而常见的多步模式？是否降低了别处的认知负担？如果这些问题都答不上来，那它即使看起来有用，也很可能只是复杂度的伪装。
从三套系统里，我们可以提炼出一个很清晰的结论。OpenCode 告诉我们，组合能力首先取决于底层宿主是否清晰。OMO 告诉我们，真正高杠杆的往往是编排原语，而不是单纯工具数。Claude Code 告诉我们，大工具表不是原罪，但必须用相应级别的产品化设计去消化它。
所以，工具设计的最终目标从来不是“库存最大化”，而是单位认知表面积上的杠杆最大化。能组合，就会放大能力；会膨胀，就会抬高摩擦。优秀的 coding agent 平台，看的不是自己暴露了多少工具，而是这些工具能否组成一个清楚、稳定、可扩展的行动语言。这才是工具组合与工具膨胀之间最本质的分界线。