让工具型 Agent 稳定完成任务的工程约束

Agent 演示时连续调用三次工具，看起来就能接管工作；真正上线后，却可能选错工具、拿到空结果后反复重试，或者没查权威数据源就宣布完成。作者的判断是：让 Agent 把任务做完，关键在于工具接口、权限边界和停止条件，选框架反而没有那么重要。

这篇短文没有代码和实测数据，但给出了一份实用的工程检查清单。正在把 AI 从聊天窗口接进业务系统的程序员，可以用它检查：自己的 Agent 究竟能完成任务，还是只能顺利演示。

工具能调用，不代表任务能完成

作者把 2026 年 Agent 的瓶颈归结为工具工程，而非模型智力。这里的「完成」也有明确含义：Agent 必须执行必要操作、核对结果，并满足预先定义的验收要求。

例如，模型给出一个语气肯定的答案，不代表它查询过权威数据源（system of record）。这个词指的是业务事实最终以哪个系统为准。数据库里没有确认的结果，不能靠模型措辞补出来。

作者认为，应该像设计 API 一样设计工具，为它定义参数结构和服务等级约定（SLA），而不是给模型一段描述，就期待它自行理解所有限制。

工具调用成功，只能证明一次调用结束，不能证明整个任务完成。

不过，「瓶颈不在模型智力」是作者的判断。原文没有比较不同模型，也没有提供失败率数据，不能据此认定模型能力已经不影响结果。

把任务做完，需要四道工程约束

第一道是严格的参数结构。每个工具都应使用 JSON Schema 或同类机制，在发生副作用之前拒绝格式不合法的参数。检查必须放在执行入口，等写入发生后再发现参数错误，已经晚了。

第二道是权限分层。读取、写入和不可逆操作应区别处理；涉及资金、删除以及向外部发送信息时，作者主张加入人工审批。模型能生成某个调用，不等于它拥有执行权限。

第三道是明确停止条件，包括最大步骤数（max steps）、预算（budget）和「done when」验收清单。前两项用于限制失控循环，最后一项用于判断任务是否完成。原文没有给出具体步骤上限，也没说明预算按费用、时间还是其他资源计算，需要团队自行定义。

第四道是可观察的执行轨迹。每次工具调用都应记录参数、耗时和结果，支持回放排查。否则，最终答案出了问题，很难区分是模型选错了工具、工具返回异常，还是执行过程漏了一步。

这四项分别管住输入、权限、过程和证据，缺一项都可能让任务停在半路。

MCP 解决工具发现，不能替你设计工具

Model Context Protocol（MCP）及类似工具总线，可以帮助统一工具发现机制，但不会自动提高工具质量。一个难用的 MCP server，依然是一个难用的 API。

作者因此建议，优先提供少量、经过充分测试的工具，避免把庞杂的工具目录全部交给模型。工具多并不天然有益，相似功能和模糊边界反而容易增加误用。

评测也应围绕任务完成情况设计。只测试所有依赖都正常的理想路径，无法回答生产环境里的关键问题：数据库变慢怎么办，工单不存在怎么办，用户在执行循环中改变主意怎么办？

作者提出了这些测试方向，但没有提供评测集、评分规则或对照结果。它是一份检查清单，还不是经过数据验证的可靠性方案。

我的判断

我认同把工具当 API 管理，也认同把「调用成功」和「任务完成」分开。这比继续堆工具、反复修改提示词，更容易形成可检查的工程边界。

但这套做法也有局限。JSON Schema 能检查结构，无法保证参数对应的业务操作正确；最大步骤数能终止循环，无法保证终止时任务已经完成；记录调用轨迹，也需要明确如何回放。原文没有展开这些问题。

「少量工具更好」同样属于经验之谈。合理数量取决于任务范围，作者没有给出不同工具数量下的完成率对照。可以采用这个方向，但别把它当成普适定律。

能拿来做什么

• 给现有 Node 工具执行入口补上 JSON Schema 校验，并确保校验发生在写入、删除等操作之前。
• 为日常 AI 编程任务写清「done when」清单，同时设置最大步骤数和预算，让执行结果具备可核对的完成标准。
• 把读取、写入和不可逆工具分层，对涉及资金、删除和外部发送的调用设置人工审批入口。
• 在 Agent 评测中加入数据库变慢、工单缺失和用户中途改意的场景，记录参数、耗时与结果，检查任务最终是否完成。