工具为什么总被用错:Agent-Computer Interface
定义
Agent-Computer Interface(ACI)是模型与外部能力交互的界面。工具名称、描述、参数 schema、返回结构和失败语义共同构成这份契约;它既要方便执行端校验,也要帮助模型选对工具、填对参数。
先搭一个心智模型
工具定义像交给新同事的一张表单。名称告诉他该拿哪张表,字段告诉他该填什么,执行端校验则负责拒绝危险或不完整的申请。
说明
与开发者写死调用路径不同,Agent 会根据自然语言动态选择工具并生成参数。工具名称相近、描述含糊或参数语义重叠,都会增加误调用。
好的描述应说明工具做什么、何时使用、何时不使用、每个参数的含义和限制,以及调用后会返回什么。复杂参数可补输入示例,但示例不能替代清楚的契约。
参数设计应减少机械错误:让 schema 表达必填、枚举和约束,并通过绝对路径、明确单位或互斥字段消除歧义。这里借用“防错(poka-yoke)”的思路:让常见错误更难发生,而不是期待模型永不出错。
工具集需要整体评测。新增一个工具可能改变旧工具的选择率;应记录误选、参数错误和失败恢复,而不是只验证单个工具能否被调用。
跟着一个例子走
查询订单与执行退款不能长得一样
Agent 有 get_order 和 issue_refund 两个工具:一个只读,一个会真正改变资金状态。
- 先把用途说开
get_order说明“只读取订单”;issue_refund明确“产生退款,调用前必须已有确认编号”。 - 让参数表达约束
金额使用明确单位,退款原因用枚举,确认编号设为必填,避免靠描述猜。
- 执行前再次检查
服务端核验用户权限、订单状态和确认编号;模型填对 JSON 也不等于自动获准。
边界与误区
为什么 Agent 工具和传统 API 有本质区别: 传统 API 由开发者写死调用路径,执行结果确定;Agent 工具由模型动态决定调用与否、用哪个、参数怎么填,工具设计质量直接影响模型判断。
Poka-yoke 在工具设计中意味着什么: 它意味着通过设计让错误更难发生,而不是期望模型不犯错。例如只接受绝对路径,从源头消除路径歧义。
好的工具描述至少要包含什么: 至少包含工具用途、适用场景、参数名称、类型、含义、是否必填、返回格式和一个简单示例。要说明它在什么条件下不应使用,避免模型把不相关任务也交给该工具。
来源与核验
- [anthropic-tool-definitions] Anthropic Claude Platform:Define tools
核验日期:2026-08-31