AI Agent 工具设计:给模型装上“手脚”,为什么不能只会调用 API?

同样一句“帮我处理这份报告”，普通聊天助手可以告诉你怎么做；AI Agent 则可以在获得相应权限后，自己找到文件、阅读内容、修改文档，再把结果交给你。这里的 Agent，可以理解为“能围绕目标分步骤做事的 AI 助手”。模型负责理解和判断，工具就是它获准使用的搜索、读取、编辑、发送等具体功能。有没有这些“手脚”，决定了它能否从建议走向行动。

理解 Agent 如何做事，可以先把它使用的工具分成五类。不妨想象一位运营同学说：“每周一帮我整理上周用户反馈。”Agent 感知信息，是搜索邮件、读取反馈表；执行动作，是把归纳结果写入报告；协作，是请另一个专门分类投诉的 AI 助手帮忙，或让负责人审核敏感措辞；用户沟通，是把已确认的报告发给提出需求的人；事件触发，则是先设好“每周一启动”，到时间由外部定时事件唤醒它。这只是用于理解分类的假设案例，不代表 Agent 默认拥有邮件或文件权限。

这里有个容易混淆的区别：用户沟通是 Agent 主动把信息送给用户；事件触发则由 Agent 事先登记条件，等时间或新消息到来后再启动。更重要的是，“看十封邮件”和“发十封邮件”不是同一类风险。前者只是读取，后者会对外产生十次真实影响，可能需要逐条检查和批准。

别从 API 端点开始设计

一个常见的早期设计，是把系统里的每一个 API（软件之间相互请求服务的接口）直接包装成一个工具：建文件夹一个、列文件一个、读文件再一个。开发者看得明白，Agent 完成“读一份报告”却要先从许多细碎按钮中找对顺序。这种围绕 Agent 目标设计交互入口的思路叫 ACI，即“Agent 与计算机的交互界面”：先问它要达成什么目标，再决定给它怎样的入口。比如把读取 PDF、Word、PPT 统一成“读取文档”，由一个格式选项区分；这就像服务台设“办理证件”窗口，而不是让办事人逐个寻找打印机、扫描仪和盖章机。

也不能因此把所有能力都交给 bash（电脑上的命令行）。一种做法是提供“专用工具”，例如有固定字段的“创建日历活动”；另一种做法是提供通用命令行，再配一份 Skill——告诉 Agent 遇到某类任务该怎样操作的说明文档。固定字段的规则称为 schema，可以把它看成表单：日期必须按规定格式填写，缺少必填项就不能提交。操作步骤常变化时，改 Skill 文档很方便；涉及付款、复杂表单或精细授权时，专用工具更容易限制和核查。设计时可以先考虑通用能力，但安全、复杂参数、高频使用和平台差异都可能是保留专用入口的理由。

工具说明也不能只写“可搜索相关内容”。如果 Agent 正在整理上周反馈，它得知道：这个搜索工具查的是互联网、邮件标题，还是邮件正文？哪些数据它读不到？返回的是完整结果还是前十条？好的描述会交代何时使用、不能做什么、参数如何填写、结果有什么限制。模型选错入口时，先检查使用说明是否含糊，往往比一上来换更强的模型有用。

还有一种错误更难发现：Agent 看到文档中的中文弯引号，想逐字替换某句话，工具却在执行前悄悄把引号改成英文直引号。就像你按收据上的地址寄件，快递系统却暗中改了门牌号，最后只告诉你“查无此人”。如果工具必须改动输入，应明说改了什么，否则 Agent 连失败原因都无法判断。

工具设计的起点因此不是“我们接了多少 API”，而是：Agent 看见的任务、它可以调用的能力，以及执行后的世界，三者是否对得上。