我的立场：今天的 Agent 表现已经是十几个组件的联合输出——系统提示词、上下文管理、记忆、工具、MCP、技能、子 Agent、重试、规划、会话、沙箱、执行循环。只看最终成功率，等于开着一辆只能看里程表的车：它跑得快不快你知道，哪个轮子在偏你不知道。而 我在 Harness 自我改进那篇里指出过的「回归盲区」——Agent 修得准 bug、却预见不了自己会捅出新窟窿——在人类改 Harness 时同样存在。评测方法从「看分」升级到「看轨迹」，不是锦上添花，是挡住这个盲区唯一便宜的办法。

先看问题长什么样：总分没变，不代表什么都没变

一个真实感很强的例子：某团队给 Coding Agent 的记忆组件从「保留完整路径」改成「保留文件名」——听起来是省 token 的优化，结果在路径相近的项目里，Agent 开始把 README 改到错误的子模块上。最终 benchmark 总分只掉了两个点，看起来「影响不大」；但新增失败的任务聚在同一类根因上。只看总分的团队会得出「问题不大，继续上线」的结论，按轨迹归因的团队会发现：这不是随机噪声，是你刚刚亲手制造的一类新故障模式。

这就是「82% 和 79% 说不清」的根源：总分是一个把十几个自由度压缩成一个数字的指标，信息几乎全被压掉了。

Google 的方法：按组件拆开，按轨迹归因

  • 先给 Harness 建组件清单：System Prompt、Context、Memory、Tool、MCP、Skills、Subagent、Retry、Planning、Session、Sandbox、Execution Loop——一次变更只动一个组件，动多个就分别记账。
  • 看执行轨迹而不是只看终态：任务失败时，翻完整轨迹——它在哪一步调了什么工具、看到了什么、决定了什么。同一个「失败」，死在规划层（任务拆错）、工具层（报错没回灌）、还是上下文层（早期指令被挤出窗口），修法是三个完全不同的方向。
  • 回归对比要落到任务级：改动前后跑同一套任务集，重点不是总分涨跌，是「哪些任务从通过变成不通过」。涨了 2 个点但打挂了 5 个历史稳定任务，是亏的；跌 1 个点但消灭了一类高频失败，是赚的。
  • 组件消融：像本站解读 AHE 论文时强调的那样，单独换进/摘掉一个组件测——组件效果不能线性叠加，只看「全家桶」的总分永远不知道哪个组件在负贡献。

AI Agent 越往生产环境走，传统软件测试的方法反而越重要——只不过被测对象从接口、页面、服务，扩展到了提示词、工具 schema 和执行轨迹。

— 我对 Google 这套方法论的中文翻译

接到本站的落地 SOP 上：三件事今天就能做

不用等大厂工具链成熟，在 AI 落地手册 的框架里，这件事有三步现成的接法：

  • Harness 变更进版本库：系统提示词、AGENTS.md、工具配置、hooks，全部当作代码提 PR、走审查。「随口改了一版 prompt」在这种流程里无处藏身。
  • 验收集复用：落地手册第 3 步那份 50 题验收集，不只是选模型时用——每次骨架变更后前后各跑一遍，就是最便宜的回归测试。这比追任何新评测框架都先决。
  • 失败任务建「金丝雀集」：把历史上真金白银踩过的一类失败（路径混淆、口径丢失、循环卡死）整理成十几道小任务，每次变更先跑它们。做不起全量回归，至少让高频故障模式有固定的报警器。
评论员视角

两个提醒。第一，用 LLM 当评判员（LLM-as-judge）本身也是 Harness 的一部分——评判员有「主角综合症」，它会偏爱更长更自信的答案、看不到自己语境之外的错误。用评测来管骨架，第一件事是把评测器自己也版本化、也跑回归，否则你只是在用一个没测过的东西去测别的东西。这也是为什么 Human in the Loop 在这套方法论里没有被淘汰——它从「逐条看答案」退到「定期审计评判员」，但退场不等于下岗。

第二，给不写 Agent 的读者：这个趋势对你的实际意义是，选编程 Agent 时该问的问题变了——别再只看演示视频和跑分，去问厂商三个问题：变更骨架（提示词/工具/记忆）前跑不跑回归集？失败任务能不能给我看轨迹？新版本上线有没有灰度和回滚？2026 年了，这三个问题正在变成和「支不支持 MCP」同等级的采购必答题。