Agent 的效率设计，关键是给默认成本划边界

这组素材放在一起，讨论的不是"agent 还缺什么工具"，而是一个更现实的工程问题：每个默认开启的能力都在收租。

为什么这件事值得重视

很多团队在设计 agent 系统时，总想着"工具越多越好""验证越密越安全""速度越快越高效"。但这种思维方式可能让 agent 系统变得既复杂又低效。真正的问题是：每一个默认开启的能力都需要付出代价，而很多代价是隐性的、长期的。

当我们讨论 agent 效率时，不能只看表面的能力清单，而要理解这些能力背后的成本结构。就像一个企业不能只看营收，更要看成本和利润一样，agent 系统的效率也不是简单的能力叠加。

真正的问题在哪里

**工具税**：Kuma 提到自己有 47 个工具，但 Read、Write、Edit、Bash、Grep 完成了 89% 的任务。这个数字很有价值，因为它提醒我们：真正支撑日常工作的往往不是完整工具库，而是少数稳定、高频、低摩擦的热路径工具。

工具越多，表面能力越强，但默认上下文越重，选择成本、延迟和误调用风险也越高。很多工具实际上是为了应对极少数的边缘场景而存在的，却为大多数常见任务增加了不必要的开销。

**验证税**：外部 validator 确实能提高可靠性，但它们不是免费的安全感。每一次验证都会带来延迟、成本、rate limit 暴露和失败处理负担。验证应该放在错误代价超过验证成本、失败模式足够明确、且能被 deterministic check 捕获的地方；如果只是为了"看起来更稳"而默认全开，validator 就会从保护机制变成延迟税。

**误判税**：更快的自动化工具还会带来第三种隐性成本：误判税。速度提升会压缩人的判断窗口，让团队更容易把"少做复核"误读成"效率提高"。如果自动化只是把验证省掉、把风险推迟到后面，那它并没有真正提升系统吞吐，只是把错误发现时间延后了。