编码代理是模型和围绕它构建的一切。工具工程将这种支架视为一个真实的工件，并且每当代理失败时，它就会收紧。大致来说：每当你发现代理犯错时，就花时间去设计一个解决方案，以便代理永远不会再犯同样的错误。我们过去两年一直在争论模型。哪个是最聪明的，哪个写出最干净的 React，哪个幻觉最少。这个讨论没问题，但它缺少了系统的另一半。模型是运行中代理的一个输入。其余的就是工具：提示、工具、上下文政策、钩子、沙箱、副代理、反馈循环和围绕模型的恢复路径，以便它能够实际完成某些事情。一个优秀的模型配上一个优秀的工具胜过一个优秀模型配上一个糟糕的工具。我在自己的工作中反复看到这一点。越来越有趣的工程不在于选择模型，而在于设计围绕它的支架。这种学科现在有了名称。Viv Trivedy创造了“工具工程”这个术语，他的《代理工具的解剖》一文清晰地阐述了工具的实际意义及其每个部分的存在原因。Dex Horthy一直在跟踪这一模式的发展。HumanLayer将大多数代理失败框架为“技能问题”，归结为配置而非模型权重。Anthropic的工程团队发布了我认为是设计长时间运行工作工具的最佳公共解析。而Birgitta Böckeler则提供了用户视角的良好概述。这篇文章是我试图将这些线索汇聚在一起。什么是工具，真的？Viv的那句口号几乎涵盖了所有工作：代理 = 模型 + 工具。如果你不是模型，那么你就是工具。工具是每一行代码、配置和执行逻辑，而不是模型本身。一个原始模型并不是代理。只有当工具赋予它状态、工具执行、反馈循环和可执行约束时，它才会变成代理。具体来说，一个工具包括：系统提示、CLAUDE.md、AGENTS.md、技能文件和副代理提示；工具、技能、MCP 服务器及其描述；打包的基础设施（文件系统、沙箱、浏览器）；协调逻辑（副代理生成、交接、模型路由）；用于确定性执行的钩子和中间件（压缩、继续、lint 检查）；可观察性（日志、跟踪、成本和延迟测量）。Simon Willison将循环部分简化为其本质：代理是一个“在循环中运行工具以实现目标”的系统。技能在于工具和循环的设计。如果听起来有很多表面区域，那是的。而且这是你的表面区域，不是模型提供者的。Claude Code、Cursor、Codex、Aider、Cline：这些都是工具。模型底下有时是相同的，但你体验到的行为主要是由工具决定的。编码代理 = AI 模型 + 工具。这条方程，是Viv表达的，通过HumanLayer的呼应，是实际工作的所在。左侧的辩论声很大。而实际上，大多数真正的杠杆都位于右侧。“技能问题”的重新框架 我看到工程师陷入的一个模式是：代理做了愚蠢的事情，工程师指责模型，而指责归结为“等待下一个版本”。工具工程思维拒绝这一默认思维。失败通常是可以看得懂的。代理不知道某个约定，因此你将其添加到AGENTS.md。代理执行了一个破坏性的命令，所以你添加了一个拦截它的钩子。代理在一个 40 步的任务中迷失，因此你将其拆分为规划者和执行者。代理不断“完成”损坏的代码，因此你在循环中连线一个类型检查的回压信号。HumanLayer说：“这不是模型问题。这是配置问题。”工具工程就是当你认真对待这一点时发生的事情。Viv的文章和HumanLayer中都有一个突出的数据点。在Terminal Bench 2.0中，Claude Opus 4.6 在Claude Code内部运行的得分远低于在自定义工具中运行的相同模型。Viv的团队通过仅仅改变工具，将一个编码代理从前30名移到了前5名。模型在训练后与其所训练的工具耦合。将它们移入另一种工具中，结合更好的代码基础设施、更紧密的提示和更锐利的回压，可以释放原始工具所忽略的能力。这与“只需等待 GPT-6”的叙述正好相反。今天的模型所能做的与你看到的之间的差距主要是工具差距。转轮：每个错误都成为一条规则 在工具工程中，最重要的习惯是将代理的错误视为永久信号。不是一次性故事，也不是“坏运行”的重试。信号。如果代理提交PR时附带了注释掉的测试，而我不小心合并了，那就是一个输入。下一版本我的AGENTS.md写着“永远不要合并”...