让 Agent 每次运行都接受评测与故障检验

Agent 能回答问题，不代表它的运行过程可靠：工具读不到内容时，它可能照样给出答案；预算检查顺序错了，已经付费的调用可能没有记录；评测样本太少，CI 仍可能亮绿灯。grounded-harness 想解决的，就是这些藏在结果背后的问题。

作者把运行循环、轨迹记录和评测门禁接在一起，让每次运行都有可检查的结果。它最值得借鉴的不是功能数量，而是三个约束：未知不能当作零，证据必须达到门槛，门禁必须证明自己能拦住错误。

绿灯可信之前，先让它正确地变红

grounded-harness 是一个 Python 工具调用循环。演示中的 Agent 从知识库回答问题，运行结束时检查四项指标：工具调用是否正确、循环是否高效、回答是否有依据，以及是否遵守预算和结束条件。

正常演示展示了三条轨迹怎样共同通过门禁：

$ grounded-harness demo
  gadget-colours   tool_correctness=ok  loop_efficiency=ok  groundedness=ok  budget_adherence=ok
  rollback-time    tool_correctness=ok  loop_efficiency=ok  groundedness=ok  budget_adherence=ok
  widget-price     tool_correctness=ok  loop_efficiency=ok  groundedness=ok  budget_adherence=ok

  GATE: PASS

要看的是最后一行：单条轨迹通过检查后，还要汇总判断，才能得到整体的 GATE: PASS。

接下来，作者故意破坏读取工具，让它获取的笔记全部为空。这段演示验证门禁能否识别失去证据的回答：

$ grounded-harness demo --sabotage broken-tool
  ! [How long does a rollback take?] claim not grounded: '90 seconds' missing from any tool result
  ! groundedness regressed: 1.0 -> 0.3333
  GATE: FAIL

这里要看 '90 seconds'：答案仍然声称回滚需要这么久，工具结果却不再包含依据，因此 groundedness 从 1.0 降到 0.3333，命令以退出码 1 结束。

另一项破坏测试是 grounded-harness demo --sabotage thin-evidence。它只留下 n=1 条 golden，而门禁要求 >=3，所以拒绝放行。这里失败的原因是证据不足，不能据此判断系统表现良好。

两项破坏测试都进入 CI。如果被故意破坏的演示反而通过，构建就失败。门禁的可信度，需要由它拦住错误的能力来证明。

预算检查放错位置，就会出现付费却没记录的调用

作者早期实现里出现过一个顺序错误：模型调用已经付费，步数检查随后触发，轨迹却还没写入。运行停了，那次调用也从记录里消失了。

修复后的规则分成两部分：步数上限在花钱前检查；费用上限在已付费步骤记录完成后结算。预算耗尽是一个合法的运行结果，应该保留已经执行的步骤，并给出如实的部分摘要。

这两个上限不能共用一个检查时机。下一步是否超过步数，调用前就知道；这一步花了多少，通常要等响应回来才能结算。原文引用 Anthropic 的 Claude Agent SDK 作为参照：它也在模型响应到达后比较费用，触及上限的响应仍会完成并计入记录。因此，这种费用上限不保证每次都能在支出发生前精确截停。

还有一种更容易被忽略的情况：配置了费用上限，供应商却停止返回 token 数。此时框架会以「预算不可验证」为由停止继续执行，而不是把未知费用记成免费。

恢复运行也遵循类似原则。已完成步骤从原子检查点重放，不再重复计费；如果输入发生变化，恢复会被直接拒绝。作者认为，重新跑一次的成本，比错误复用旧状态更可接受。

轨迹重放能防回归，但测不到新的模型表现

这里的 golden，是一份录制下来的运行记录，加上一组预期。重放时，模型轮次从记录中恢复，其余部分真实执行，包括运行循环、工具和工具背后的数据。

四类检查分别关注：工具调用序列是否匹配且全部成功，步数是否在允许范围内，声明的事实是否同时出现在最终答案和某次工具结果中，以及结束状态是否符合预期。门禁再把多条 golden 的结果与已提交的基线比较。

这个边界必须讲清：模型输出已经固定，所以重放主要检查框架、工具和工具数据的回归。要判断模型升级后的回答质量，仍然需要实时运行和评审。原文也没有证明「事实出现在工具结果里」就能保证语义推导正确。

真正有说服力的发现，来自一次跨组件集成测试。演示工具通过 stdio 连接真实的 grounded-mcp server，使用随仓库附带的演示知识库，并非工具桩。

grounded-mcp 原有评测全部在进程内、单线程执行，没有经过传输层。MCP Python SDK Version 2 会把同步工具函数放到工作线程运行，结果主线程创建的 SQLite 索引无法跨线程使用，所有访问数据库的工具调用都失败了，原有门禁却仍然是绿色。

作者称修复当天就提交到了上游，并补上跨线程回归测试。它说明了一件具体的事：断言再多，也覆盖不到测试从未走过的执行路径。

我的判断

我认同把轨迹、预算和门禁放进运行时约束。尤其是费用未知时停止，以及用破坏测试验证门禁，这些做法能直接减少「看起来正常」的假象。

但 >=3 是工程门槛，原文没有给出它具备统计代表性的依据。三个样本足以挡住单样本放行，未必覆盖真实任务的复杂度。作者也没有提供与其他框架的对照数据；截至 2026 年 11 月没找到同类方案，是作者的检索结论，不能据此认定业内没有类似实现。

相比只测试最终答案，这套方案更容易定位工具和运行过程中的退化；相比实时模型评测，它结果更稳定，却无法回答模型是否变聪明、是否更容易胡编。两种测试需要配合使用。

能拿来做什么

• 给现有 AI 编程 Agent 录制一条典型工具调用轨迹，保存调用参数、工具结果和结束状态，在 CI 中重放；按原文这套门禁，积累到至少三条 golden 才能放行。
• 故意让文件读取或知识检索返回空结果，检查 Agent 是否仍给出无依据的具体结论，并确认门禁会失败。
• 检查自己的调用循环，把步数判断放在请求之前，把费用结算放在响应记录之后；供应商缺少用量信息时，明确返回预算不可验证。
• 如果 Node 服务通过 MCP 调用外部工具，补一条经过真实传输层的集成测试，验证工具、存储和运行环境组合起来是否正常。