Agent 如何验证工具调用结果？

简化版

工具返回成功不代表结果可直接使用。Agent 应分层验证：先检查传输和 Schema，再检查字段范围、业务不变量、来源与新鲜度，最后核对副作用是否真正提交；关键结论要能追溯到原始证据。验证失败时按错误类型重试、换源、澄清或转人工，不能让同一个模型仅凭“看起来合理”自我确认。

详细版

结果校验可分五层：协议层检查状态码、编码和完整性；结构层用 JSON Schema 校验类型与必填项；语义层检查金额非负、结束时间晚于开始时间等规则；证据层核对来源、权限、时间和引用；副作用层用业务 ID 查询真实状态。

raw response
 -> protocol valid?
 -> schema valid?
 -> business invariants hold?
 -> source authorized and fresh?
 -> side effect confirmed?
 -> normalized observation

校验器应是确定性代码、权威数据源或独立审核流程。模型可协助修复格式，却不能绕过业务规则。大结果做抽样时要明确覆盖范围，高风险结果必须全量或由服务端保证。记录验证规则版本、原始响应哈希和失败原因，便于回放与回归测试。

完整版教学

一、工具成功只说明完成了调用

HTTP 200 可能返回缺字段 JSON、过期缓存、空结果或业务错误页面；搜索工具能返回网页，不代表网页支持结论；付款接口响应超时，也不代表付款未发生。工具的“调用成功”和业务的“结果正确”是两层概念。

验证的目标是把不可信原始返回变成可以驱动下一动作的 Observation。每层验证失败都要有明确处置，不能把原始文本直接交给模型自由解释。

验证层	主要问题	典型验证器
协议	是否完整收到且格式匹配	HTTP 客户端、校验和
结构	字段与类型是否合法	JSON Schema
语义	业务关系是否成立	领域规则、计算程序
证据	来源是否可信、授权且新鲜	引用核对、权限过滤
副作用	外部动作是否真实提交	权威状态查询

记忆钩子：先证明结果“读得懂”，再证明“说得通”，最后证明“确实发生”。

二、协议层检查传输是否完整

协议层关注超时、状态码、Content-Type、编码、压缩、分页和截断。服务返回 HTML 登录页却标记 200 时，JSON 解析器应立即拒绝；分页只取第一页时，Observation 必须标注不完整。

还要检查响应大小和校验和。下载文件声明 20 MB，实际只收到 8 MB，即使连接正常关闭也不能当作完整产物。流式响应中途断开要保留已接收范围，但不得将半个 JSON 标为成功。

协议验证最好在工具适配层完成，不消耗模型 token。

三、Schema 只保证形状，不保证事实

JSON Schema 能检查必填字段、类型、枚举和格式。例如价格必须是数值、币种必须来自允许集合。但 price: 999999 仍可能通过 Schema，所以还需要语义规则。

{
  "type": "object",
  "required": ["amount", "currency"],
  "properties": {
    "amount": {"type": "number", "minimum": 0},
    "currency": {"enum": ["CNY", "USD"]}
  }
}

模型输出的“JSON 修复”只适合处理引号或逗号等语法问题。若必需字段不存在，修复模型不能凭空编一个金额，应返回缺失并重新查询。

四、业务不变量捕获语义错误

领域规则定义结果之间必须成立的关系：订单总额等于明细之和，结束时间晚于开始时间，退款不超过已付金额，库存扣减后不能为负。它们通常比模型判断更稳定、可审计。

假设三个明细为 120、80、50 元，返回总额 260 元；类型和范围都合法，但 120+80+50=250，不变量校验能发现 10 元差异。金融场景还要明确舍入规则与小数精度，避免浮点误差。

规则应版本化并记录命中项，因为业务政策会变。不能把旧规则失败简单解释为模型出错。

五、来源、权限和新鲜度同样属于正确性

一条价格可能数值真实，但来自两年前页面；一份文档内容准确，却属于另一个租户。验证要检查来源允许列表、检索时间、数据版本和访问主体，避免“内容正确但使用不合法”。

引用验证至少确认来源确实包含所述事实，而不仅是 URL 可访问。对于多个结论，应建立结论到证据片段的映射；一个笼统引用不能支持整篇回答。

外部网页属于不可信输入，其中的指令不得改变验证规则或工具权限。

六、副作用要向权威系统确认

对付款、发信、部署等动作，工具返回文本“成功”不是最终依据。应使用交易 ID、message ID 或 deployment ID 查询权威状态，并核对目标、参数和版本。

execute(idempotency_key=K) -> timeout
query_by_key(K) -> COMMITTED, transaction_id=T
verify(T.amount == requested_amount)

查询不到时状态是未知，而不是失败。系统进入对账或人工队列，避免重复执行。高风险动作最好由服务端在一个原子接口中执行并返回可验证收据。

七、大数据验证要说明覆盖率

一百万行数据逐行由模型检查既昂贵又不可靠。应把类型、范围、唯一性、行数和聚合校验下推到数据库或计算引擎；必要时分层抽样，并清楚说明抽样不能证明零错误。

若随机抽 1000 行没有发现错误，只能说明样本内零错误。若真实错误率为 0.1%，一次抽样完全没碰到错误的概率约为：

(1 - 0.001)^1000 ≈ 36.8%

因此高风险数据不能因抽样零错误就宣称全量正确，还需校验和、约束或全量程序验证。

八、失败处置和可观测性

语法失败可有限修复，字段缺失应重新查询，来源冲突可换权威源，业务不变量失败要停止副作用，权限问题直接拒绝。不同层级不能统一重试。

记录工具版本、规则版本、原始响应哈希、每层验证结果、修复次数和最终决策。指标包括 Schema 失败率、业务规则失败率、过期数据率、未知副作用数和误接受率。

回归集要包含“格式正确但事实错误”的对抗样例，因为只测坏 JSON 会高估验证能力。

九、常见误区与追问

误区：JSON 能解析就说明工具结果有效。 解析只证明语法，不能证明业务语义和事实。
误区：HTTP 200 一定代表业务成功。 登录页、部分结果和业务错误也可能返回 200。
误区：让模型再审一遍就是独立验证。 同一模型可能重复同一假设，应使用规则或权威数据。
误区：引用了网页就算有证据。 还要确认片段实际支持对应结论且没有过期。
误区：抽样没问题就能宣布全量正确。 抽样有漏检概率，高风险数据需确定性约束。
追问：格式修复可以自动做几次？ 设置很小上限；缺失事实不能靠格式修复生成。
追问：写操作超时怎样验证？ 用幂等键查询权威状态，未知时停止并对账。
追问：验证规则放在哪里？ 靠近工具适配或领域服务，版本化管理，不只写在 Prompt。

十、加强记忆

工具结果验证记住“五层漏斗”：协议层确认完整可读，Schema 层确认结构，业务层检查不变量，证据层检查来源、权限与时效，副作用层向权威系统确认真实提交。模型可以协助理解和格式修复，却不能替代独立规则与真值查询；验证失败按层分类处置，并保留规则版本和原始证据供回放。

简化版

详细版