工具返回一个“400 Bad Request”，人会去翻日志。代理不会。它只能猜：改个参数再调一次，换个工具试试，有时干脆编一个值绕过去。每一次猜测都在烧token和时间，其中有些猜测是危险的。
给错误起个名字，猜测就没了。命名错误用业务语言告诉代理：哪里错了，下一步该干什么。发票代理能看到的每一个命名错误、对应的动作，以及防止它陷入循环的限制，构成了一份完整的清单。
两类失败，两个处理位置
MCP已经把这两类失败分开了。协议错误，比如未知工具或格式错误的请求，以JSON-RPC错误返回。它们是集成层的bug，代理基本修不了。工具执行错误则放在工具结果里，带isError: true返回，模型能读到，也能纠正方向。
还有第三类值得点名：瞬时失败，比如超时或ERP短暂不可用。这类归集成层管，不归代理管。流程API用退避重试处理它们，和任何像样的集成一样，只有自己的重试次数用尽后，才把失败报给代理。代理不该充当网络的重试引擎。
剩下的就是业务错误。这类才是代理必须理解的，也是这份清单的主题。
十个命名结果
契约里有十个命名结果：九个是错误，一个是信息。
检查输入，重试一次：
- INVOICE_NOT_FOUND：发票ID错了，或者还没进ERP。对照源单据核对ID，用修正后的值重试一次，然后转AP队列。
- PO_NOT_FOUND：通常是笔误，或者从单据里读错了引用。规则相同：修正后重试一次，然后转交。
- SUPPLIER_NOT_FOUND：供应商ID与供应商主数据不匹配。不要猜一个相似的供应商。修正后重试一次，然后转主数据。
等待，不要循环：
- GR_MISSING：货物还没收货。这往往是时间问题，不是错误。把发票挂起，让定时复查去接它。同一次运行里绝不要再调get_goods_receipt
转交给人：
- PO_CLOSED：由采购决定重开还是拒绝。代理汇总证据并转交。
- DUPLICATE_INVOICE：由AP团队确认。代理绝不自行拒绝或删除发票，因为近似重复可能是一次合法的二次交付。
- APPROVER_NOT_FOUND：审批路由对这个类型和金额找不到审批人。这是配置缺口，交给AP负责人，不是退回给代理。
停下，退回一步：
- APPROVAL_MISSING：写入时没有有效的approval_id。唯一正确的动作是request_approval。绝不重试写入，绝不编造ID。
- PERIOD_CLOSED：会计期间已锁定。代理做什么都改变不了。停下，升级给财务。
是信息，不是错误：
- TOLERANCE_EXCEEDED：由run_three_way_match在正常结果里返回，不带isError: true。这正是代理存在的理由。它的下一步是调查，并提出修复方案等待审批。
规律很清楚：只有三个错误允许重试，每个只重试一次，而且必须带修正后的输入。其余全部是等待、转交或停止。
错误长什么样
每个错误都以同一种形状返回，代理能解析，看板能计数。返回体里是一个文本块，装着JSON，包含五个字段：
- code是稳定的。代理、测试和看板都依赖它，一旦发布就不再变。
- message写给模型看：平实的英文，具体，不带堆栈信息或内部主机名。
- retryable说明再调一次有没有可能帮上忙。业务错误几乎总是false。
- next_action点明预期动作：fix_input_and_retryhold_and_recheckroute_to_personrequest_approvalstop_and_escalate
- details携带下一步需要的标识符，代理不用再去查一遍。
文本块里装JSON，是因为MCP的错误结果按内容读取。每个平台都保持这五个字段一致，错误在不同构建之间才可比较。
阻止循环的三道限制
命名错误砍掉了大部分重试，但代理仍可能在工具之间打转。三道限制负责兜住：
- 每张发票、每个工具只允许一次修正重试。第二次调用还失败，就转交。
- 不允许完全相同的重复。同一次运行里，同一个工具带同样的参数出现两次，就是循环。停下并交接。
- 每张发票有工具调用预算。用完了，代理停下，把发现的东西汇总成摘要交给一个人。
预算放在模型之外，在代理运行时或流程层里，理由和审批检查一样：模型能说服自己绕过去的限制，不算限制。
交接时，人应该拿到发票、看到的错误、收集到的证据，以及代理能给出的最好解释。带上下文的交接仍然是有用的工作，哪怕代理没能做完。
每个构建都要核三件事：平台把错误结果原样传给代理，包括isError和JSON字段；代理遵循next_action；循环限制生效。评估集里包含专门触发每种错误的发票，所以统计的是重试和交接次数，不只是答对没有。
热门跟贴