把一个接口交给 AI，并不等于它已经理解了这个接口。人类开发者可以阅读上下文、询问同事，再猜出某个参数的含义。Agent 在执行任务时，需要从有限的描述中判断该调用什么、填入什么，以及何时停止。
围绕业务动作命名
Anthropic 的工具设计文章强调清晰的功能边界、有意义的返回信息，以及通过评估改进工具。[1] 我们据此建议：工具名称应表达业务动作，避免让模型在大量含义相近的通用接口之间猜测。
例如，“读取指定订单的配送状态”比“处理订单数据”更明确。前者可以说明订单编号格式、允许读取的字段和返回状态；后者很容易同时承担查询、修改和通知，难以判断执行边界。工具数量应当由实际任务决定。
先读、再建议，最后才执行
对于会改变业务状态的流程，可以将读取资料、生成建议和提交动作分开。客服查询物流不需要修改订单权限；起草改期方案也不需要立刻确认改期。拆开之后，权限可以更小，测试也更容易定位问题。
一个提交工具应要求完整而明确的参数：操作对象、拟修改字段以及必要的审批依据。有效身份和权限必须由系统验证，不能只相信模型传入的声明。人工确认时，界面应展示将要发生的具体变化，避免让用户批准一个含糊的“继续”。
返回结果要能支持下一步判断
只返回“成功”通常不够。系统应返回可核对的记录标识、实际状态和完成时间；失败时说明属于参数错误、权限不足、对象不存在还是暂时不可用。错误类别决定下一步是补问、停止还是重试。
假设工单接口超时，模型不应直接认定提交失败并重复创建。对这类动作，可以在应用层使用幂等标识，并通过查询核对上一次执行结果。重复运行同一项请求，不应悄悄变成两份工单。这是接口与业务系统的责任，不能全部转交给提示词。
用真实任务检验描述是否有效
工具文档写得清楚，仍需验证 Agent 是否真的选对工具、传对对象并正确理解返回值。建立一组包含相似订单、缺失字段和接口失败的任务，检查完整执行过程，而不只看最后一句回答。
每次发现错误，先定位是工具命名、参数设计、权限边界还是业务规则的问题。只有确定原因后，再修改说明或实现。长期来看，一组边界清楚、经过任务检验的小工具，比一个能做所有事情却难以解释的接口更容易维护。
检查一个有写入能力的工具：用户能否看懂它将修改什么，失败后能否核对结果，重复调用会不会产生重复业务记录。
参考资料
本文结合公开资料与 Terriva 的方法建议整理。文中的假设场景用于说明设计思路，不代表客户实绩。