41 篇博文 含有标签「tool-use」

在扩展 AI Agent 时，大多数团队都会遇到一个违背直觉的失败模式：Agent 的工具集越强大，它的表现就越差。你为了处理更多场景而增加工具，准确率却下降了。你增加了更优秀的工具，它却变得更慢，并开始选错工具。你加入了编排逻辑来管理工具选择，结果你在原始的复杂性之上又重建了一层复杂性，而整个系统几乎无法运行。

增加工具的本能是错误的。生产环境中 Agent 的性能提升往往源于“删减”。

有一个 100 行代码的 Python Agent，在 SWE-bench Verified 上获得了 74–76% 的评分——仅比资金雄厚的团队构建的最先进系统低 4–6 个百分点。执行循环本身并不是复杂性所在。世界级的团队会投入 6 到 12 个月的时间来围绕该循环构建基础设施。这种基础设施有一个名字：Harness。

公式很简单：Agent = Model + Harness。Model 负责推理，Harness 负责其他一切——工具执行、上下文管理、安全管控、错误恢复、状态持久化以及人在回路（human-in-the-loop）工作流。如果你花了几个月的时间优化 Prompt 和模型选择，却交付了脆弱的 Agent，那么你一直在优化错误的东西。

大多数构建 AI Agent 的团队都犯了同样的错误：在没有证据表明需要复杂架构之前就过度设计。对 47 个 Agent 部署案例的生产分析发现，68% 的案例如果使用设计良好的单 Agent 系统，会获得相同甚至更好的结果。多 Agent 税——更高的延迟、复合的故障模式、运维复杂度——往往在用户感知到收益之前就将其消耗殆尽。

这并不是在反对 Agent，而是主张以构建任何严肃生产系统的方式来构建它们：从能工作的最简单方案开始，监控一切，只有在更简单的版本明显失效时才增加复杂度。

你将智能体连接到 50 个 MCP 工具。它可以查询数据库、调用 API、读取文件、发送电子邮件、浏览网页。理论上，它拥有所需的一切。但在实践中，一半的生产事故都源于工具使用——错误的参数、上下文预算超支、级联重试循环，导致成本是预期的十倍。

这是大多数教程都会跳过的部分：你加载的每个工具定义都是预先支付的 Token 税，甚至在智能体处理单条用户消息之前就开始计算了。连接了 50 多个工具后，仅定义一项就会在每次请求中消耗 70,000–130,000 个 Token。这并非极端情况——这是任何连接到多个 MCP 服务器的智能体的默认状态。

当你的智能体在放弃之前，第三次默默地重试同一个损坏的工具调用时，你就会意识到，“仅仅添加工具”并不是一种生产环境的策略。工具调用解锁了真正的能力——外部数据、副作用、保证格式的输出——但使其工作的智能体循环（agentic loop）具有在演示中不会表现出来的尖锐边缘。

这篇文章将探讨这些边缘：循环实际上是如何运行的，悄悄破坏并行执行的格式规则，如何编写能让模型做出正确选择的工具描述，以及如何处理错误以让模型恢复而不是陷入死循环。