业务与 Agent / PRACTICE NOTE
给 Agent 配工具:三个原则,先于“多 Agent”之前想清楚
工具不是越多越好:少而精、描述即契约、可收回三个原则,加一份上线前自查清单。Anthropic 与 OpenAI 一手实践里的工具配置方法,业务负责人直接可用。
摘要
基于 Anthropic《Building effective agents》(2024-12-19)与 OpenAI《A Practical Guide to Building Agents》(2025-04)的一手实践,讲业务 Agent 的工具配置:少而精、描述即契约、可收回三个原则,附上线前自查清单。
- 体裁
- 实践文章
- 适用对象
- 业务 Agent 负责人、AI 产品经理、业务系统负责人
- 参考来源
- 2 项 · 详见文末
先说答案:三个问题,答不上就别接
给 Agent 配工具之前,先问三个问题:这个工具是不是非它不可、工具的描述够不够让模型在正确的时候选它、出错时能不能安全收回——三个问题有一个答不上,就先别接这个工具,先把答案补齐。
这个顺序来自两份一手实践。Anthropic 在《Building effective agents》里的立场很明确:从最简单的方案开始,只有可验证的提升才值得加复杂度,工具不是越多越好,每多一个工具,模型选错的概率就多一分。OpenAI 的《A Practical Guide to Building Agents》也是同一个方向:工具要配清晰的定义与防护,高风险操作要留人工确认,不能把"能调用"当成"该调用"。
原则一:少而精,一个工具只干一件事
工具箱膨胀是最常见的起点错误。一个"查询订单"工具如果同时能改地址、退单、开发票,那它就不是一个工具,是三个工具穿了一件外套。模型在上下文里看到的工具越多,越容易在相似工具之间选错,排查时也越难定位是哪一步出了问题。
做法是按业务动作拆:查、改、退、开票各一个工具,每个工具的名字就是它的业务动作。拆完数一数:如果一个 Agent 的工具超过两位数,先别急着上线,先问哪些工具在过去一个月的真实任务里根本没被调用过——没被调用的,先下掉,上线后再按需加回来。
原则二:描述就是契约,写给模型看,也写给人看
模型选工具只看描述,不看你的意图。所以描述要写清四件事:这个工具是干什么的、什么时候该用、什么时候不该用、参数里每个字段是什么意思。写"用于查询订单"不够,要写成"当用户问起某笔订单的状态、物流、金额时调用;不要用它改地址或退单;订单号必须是用户提供的完整编号,不要猜测"。
一个检验方法:把描述拿给一个不了解这个系统的新同事看,他能不能在不问你的情况下判断"这个任务该不该调这个工具"。如果他要追问,说明描述还不够,模型到时候也会选错。描述写好之后,还要配两个例子:一个该用的、一个不该用的,放进测试集里,每次改描述都跑一遍。
原则三:可收回,先只读,再谈写
工具按风险分三档,上线顺序不能乱。第一档是只读工具:查状态、查记录、查价格,只读不写,先全量上;第二档是可逆的写操作:改备注、打标签,写错了能改回来,上之前配好回滚路径;第三档是不可逆操作:扣款、退单、对外发送,这一档必须配人工确认或二次校验,不能让 Agent 在无人值守时直接执行。
每档还要配失败预案:工具超时了怎么办、返回空了怎么办、返回了明显离谱的值怎么办。预案写进工具描述旁边的运行手册,而不是等线上出事再现想。自查清单如下:
- [ ] 每个工具都有"该用/不该用"的描述和两个测试例子
- [ ] 只读、可逆、不可逆三档已分清,不可逆操作有人工确认
- [ ] 工具超时、返回空、返回异常值三种失败都有预案
- [ ] 过去一个月没被调用的工具已下掉,不是留在箱子里占位置
- [ ] 每次改描述都跑一遍测试集,选错率有记录
参考来源
常见问题
工具越多,Agent 不是越能干吗?
不是。工具越多,模型选错的概率越大,排查也越难。Anthropic 的立场是从最简单的方案开始,只有可验证的提升才加复杂度。先少后多,按真实调用数据加回来。
工具描述写多细才够?
细到一个不了解系统的新同事能独立判断该不该调它:干什么、什么时候用、什么时候不用、参数含义,外加一个该用和一个不该用的例子。
不可逆操作能不能完全交给 Agent?
不能。扣款、退单、对外发送这类操作要配人工确认或二次校验,这是 OpenAI 指南里明确的防护要求,不是可选项。
工具失败最常见的三种情况是什么?
超时、返回空、返回离谱值。上线前三种都要有预案,写进运行手册,而不是等线上出事再现想。