配了三个月 AI Agent 评估，今天才发现一直在用错方式——这件事把整个思路全变了

配了三个月 AI Agent 评估，我换过三种框架、调过五套指标，每次发布前跑分还挺好看，到线上还是出问题——今天终于把根子想清楚了，不是指标不够多，是评估方式本身就走偏了。

传统评估的假设是：Agent 吐出一段文字，我拿标准答案去比对。这套逻辑在 Agent 还只是「会聊天的模型」的时候管用。但 2026 年的 Agent 能读文件、写代码、操作数据库——它做完事情之后，留下的是系统状态，不是文字输出。你拿文本比对去判断「代码有没有 bug」，这件事本身就是错的。

从「文本打分」到「环境裁判」

LangChain 在 2026 年 7 月推出了 Harbor 框架，核心思路是把评估方式彻底换了一套：从评分文本对错，变成了裁判沙箱状态。

每个任务在 Harbor 里长这样：一个 Docker 容器，一份 Markdown 指令，一个 test.sh 验证脚本。Agent 在容器里跑，玩成之后脚本检查「文件有没有生成」「数据库有没有写入」「系统状态对不对」。过了就是过了，不过就是不过，没有「写得不错就是有点小 bug」这种模糊空间。

三个基准，测三种能力

Harbor 里跑三个基准，各自测不同的能力维度：

Harbor-Index：从 6000 多个候选任务里精选出 82 个，覆盖软件开发、搜索、数据分析、长链路工具调用。代表场景是「给一个 GitHub issue，Agent 要自己写 patch 并让原有测试全过」。

τ³-bench：30 个多轮对话任务，有模拟用户参与，但评分不看对话文本好不好看，看的是真实业务结果有没有达成。比如「用户要改航班，Agent 有没有真的去数据库里更新了记录」。

ContextBench：30 个检索任务，把完整语料库打包进沙箱里，Agent 必须自己找到信息并拼接出答案，不能靠「训练时背住了」来蒙混。

两层结构：快速迭代层 + 正式发布层

LangChain 自己的经验最有说服力。他们给 Deep Agents 0.7 做发布评估时，先跑了快速迭代层：几十个 Deterministic Unit Test，每个只测一个具体能力，比如「工具有没有选对」「内存有没有一致性」「文件操作有没有副作用」。这层跑得快，每天都能跑，用来抓回归。

结果这层先发现了问题：移除内置的 todo-list 中间件、压缩系统提示词之后，快速测试先报红，比集成测试早了整整两天发现问题。如果只靠集成测试，这两条改动就会带着性能回归上线。

一套代码，随处运行

Harbor 最有价值的设计是环境抽象。写好一套 eval 之后，换执行后端只需要改一个 flag：

本地 Docker 跑：harbor run --agent langgraph --dataset terminal-bench@2.0
切到云端沙箱：harbor run --agent langgraph --dataset terminal-bench@2.0 --env langsmith
再切到另一个云：harbor run ... --env daytona

逻辑完全不变，后端随便换。LangSmith Sandboxes、Daytona、E2B、Modal 都是一等公民。这件事的深层含义是：评估这件事的基础设施正在被标准化，就像 RL 环境有了 OpenAI Gym 一样——以后你 invest 的是任务设计和 Agent 逻辑，执行层变成可替换的细节。

给 AI 编程团队的落地步骤

第一步：把「文本对比」换成「状态检查」
别再让 LLM Judge 给你打分了。写一个 test.sh，检查 Agent 做完之后文件在不在、API 有没有正确调用、数据库有没有正确写入。能自动化的全部自动化。

第二步：至少准备两层 eval
快速层：10-20 条核心路径的 smoke test，每次 push 触发。
正式层：完整的回归集，发版前跑。不求每天跑，只求关键节点跑。

第三步：用 pass@k 而不是 pass@1
Agent 有随机性，跑一次过了不代表稳定。至少跑 3-5 次，看 k 次里有多少通过。生产级别的 SLA 应该基于 pass@k 而不是单次结果。

第四步：把 eval 结果接进 LangSmith
加上 --plugin langsmith，每次任务结果自动进监控台。看的不只是分数，还有轨迹——哪个工具调错了、哪一步决策走偏了，轨迹比分数更有价值。

配了三个月我才理解这件事：评估 Agent 的本质不是打分，是建一条从「写代码」到「生产可用」的质量门禁。框架会越来越成熟，但核心逻辑不变——你要测的是「它能不能把事情做对」，不是「它说的话漂不漂亮」。