错误码说明失败，却未必说明下一步
假设采购助手查询订单，工具要求订单内部编号，员工却提供了采购单展示名称。接口返回“参数错误”，智能体随后重复提交原值，或者自行拼出一个编号。查询虽然没有改动业务数据，却消耗了等待时间，也可能把错误对象带入后续回答。这是假设场景，讨论的是接入层怎样帮助调用方修正输入，不对应真实客户故障。
Anthropic于2025年9月11日发布的工具工程文章建议：输入校验等错误应给出具体、可执行的改进提示，而不只是难以理解的代码或堆栈。本文以这一原则为依据，提出企业工具接入的方法。下文的字段划分、停止条件和测试安排是编辑分析，不代表官方接口规范或产品现成功能。
先说明哪个字段需要改变
设计错误反馈时，可先把三件事写清：失败字段、违反的约束、允许的下一步。例如“order_id需要系统订单编号；当前值是展示名称；请先通过订单查询取得编号”。这里的名称和流程只是示例，实际提示必须与企业真实工具一致。若没有查询入口，就明确要求用户补充，不能建议调用一个不存在的工具。
提示应尽量针对当前问题。日期字段格式不合要求时，给出格式示例；枚举值不在范围内时，给出该身份可用的选项；必填信息缺失时，指出缺少什么。不要一次附上所有接口文档。调用方首先需要理解为什么本次失败，以及如何形成一个合法候选输入，而不是阅读整套系统设计。
可修正的输入与不可继续的请求分开处理
企业应由接口负责人确认哪些失败允许修改参数再调用，哪些失败需要补充业务信息。缺少订单编号不等于可以扩大查询到所有客户；无权限也不等于把查询条件换成另一个部门。纠错提示只能帮助形成符合原任务和当前权限的请求，不能诱导智能体绕过权限或猜测关键身份。
还需单独处理服务超时、依赖不可用与业务对象不存在。超时不能被改写成“输入错误”，未查到对象也不能直接让模型随意换编号。错误类别应与后端实际结果对应；无法判断时保留不确定状态，交由约定的人工或系统路径处理。这样才能避免把运行故障错误归因给用户。
提示中不应泄露完成任务不需要的内容
可执行不等于返回完整数据库结构、内部地址或原始异常堆栈。面向智能体的反馈应保留修正所需约束，排查所需细节则留在受控日志，并通过请求标识关联。若错误来自某个客户字段，展示示例前应使用虚构值，不能把另一客户的真实编号当作可用模板。
也不要把原始输入直接拼进带指令口吻的错误正文。用户上传的文本可能包含无关要求，工具应把输入值作为数据表达，把可信的校验说明单独组织。具体返回结构取决于接入平台，但校验结论由确定的服务规则产生，不能由模型自行解释后冒充后端决定。
验收看修正后的行为，而不只是错误文案
可建立一组受控样本：缺字段、格式错误、不支持的选项、名称与编号混用，以及权限不足。每个样本记录原请求、后端错误类别、智能体看到的反馈、下一次调用与最终状态。期望行为应由业务和接口负责人共同确认，例如缺少关键编号时先查询或询问，而不是填入猜测值。
对比改进前后的同一组任务时，重点检查重复提交原错值是否减少、是否引入越权查询、是否把失败说成成功。不同合法修正路径都可接受，但必须保留原业务对象和用户意图。测试次数和通过要求按任务影响确定，本文没有通用成功率，也没有对某个模型进行效果实验。
把反馈当作接口契约持续维护
接口增加必填字段或收紧枚举范围时，应同步检查错误提示、工具描述和回归样本。否则正文仍让智能体使用旧格式，失败后又收到新约束，调用会反复试探。交付材料可集中保留错误类别、可展示说明、允许下一步和责任人；不必为每条错误再建设一个独立管理系统。
上线前至少走通一次真实客户端到测试服务的完整链路，确认客户端没有把详细错误吞成一句“调用失败”。若平台只能显示摘要，就把最必要的字段约束放进可见部分。纠错反馈解决的是失败后的下一步选择，授权校验、写入防重和依赖恢复仍需各自落实，不能由一段提示替代。
要点总结
- 错误码便于程序分类；面向智能体还应提供当前字段约束及允许的修正路径，具体以真实接口规则为准。
- 不应通过变换条件规避权限；应停止该路径或转入企业约定的授权与人工处理流程。
- 在相同受控任务上观察下一次调用，核对是否修正输入、保留业务对象与权限，并检查是否如实报告最终状态。
参考来源说明
业务场景和字段均为假设；纠错流程与验收办法为编辑建议，未经客户实测，不承诺效果。