生产级 Agent 的评估与监控

Context 让模型理解当前任务，Harness 让它能够在工具、状态和边界中行动。但一个 Agent 系统是否真正可用，还要回答第三个问题：如何证明它能够稳定完成真实任务？

Agent Evaluation 很容易被理解成一件很窄的事：找一组题，跑一遍模型，得到一个分数。

如果只是单轮问答，评估对象还算清楚：模型给出一段回答，我们判断它是否正确、相关、符合格式。这个判断当然也会有争议，但边界基本还在“输出质量”里。

但 Agent 的评估对象不再只是一段输出，而是一个在环境中持续运行的系统。它会读取 Context、调用工具、修改外部状态，根据环境反馈调整下一步，也可能在失败后继续尝试。它的错误也不总是停留在文本里。一个客服 Agent 如果误用退款工具，问题会进入订单系统；一个 Coding Agent 如果误改权限逻辑，问题会进入代码库；一个运营 Agent 如果写错客户字段，问题会进入 CRM。

所以评估 Agent，不能只问“模型最后答得对不对”。真正要问的是：

模型与 Harness 共同构成的 Agent 系统，能否在真实业务边界内稳定完成任务？

Anthropic 在 2026 年初发布的 agent eval 实践文章里，把 task、trial、grader、transcript / trace、outcome、evaluation harness 这些概念拆开。OpenAI 在 AgentKit 里，也把 datasets、trace grading、prompt optimization 放进同一个 Evals 平台。它们背后的方向是一致的：eval 不再只是发布前的一次考试，而是 Agent 产品持续改进的反馈回路。

Agent Evaluation 的价值，不在于给某个版本贴上一个漂亮分数，而在于让团队知道：真实任务在哪里失败，失败为什么发生，修复以后是否引入了新的问题。

没有 eval，团队只能靠感觉迭代。新模型好像更聪明，新 prompt 好像更稳，工具描述好像更清楚，但一上线，用户又在另一个边界场景里遇到问题。有了 eval，失败才有机会变成团队可以反复检查的案例。

公开 Benchmark 提供能力参照，不能替代产品标准

公开 benchmark 很重要。

SWE-bench 让 coding agent 有了共同语言。WebArena 和 OSWorld 让浏览器、桌面 Agent 可以在可复现环境里比较。τ-bench 把客服场景里的多轮对话、工具调用和 policy adherence 放进同一个框架。METR Time Horizon 则尝试用人类任务时长来衡量 Agent 能完成多长的工作。

这些 Benchmark 让行业看见前沿在哪里，也让团队大致了解模型与 Harness 的能力边界如何移动。

但公开跑分很容易被误用。

一个模型在榜单上更高，不等于它在你的产品里更可靠。Agent 的表现不只取决于模型，还取决于工具接口怎么设计，环境是否隔离，状态是否持久，权限边界在哪里，失败后是否能恢复，trace 能不能读，grader 是否公平。换一个 Harness，同一个模型可能像换了一个产品。

这就是为什么 agent benchmark 不能只看百分比。一个结果至少要连同模型版本、Agent scaffold、工具定义、运行预算、试验次数、环境配置、grader 和失败处理方式一起读。否则你看到的不是能力，而是一个很难复现的故事。

更现实一点说，一个 coding agent 在 SWE-bench 上解决更多 GitHub issue，不代表它能安全修改你的权限系统。一个 browser agent 在 WebArena 上能完成网页任务，不代表它能稳定操作你的 SaaS 后台。一个客服 Agent 在 τ-bench 上分数更高，也不代表它已经理解你公司的退款政策、升级流程和真实用户分布。

公开 Benchmark 是公共语言，不是企业自己的质量标准。

对产品团队来说，更重要的问题是：你的用户会怎么表达需求，你的工具有哪些危险副作用，你的业务规则有什么例外，哪些任务必须人工接管，哪些错误不能发生第二次。

这些问题，只能靠你自己的 eval 来回答。

私有 Eval 必须覆盖结果、边界与执行过程

很多团队刚开始做 eval，会自然地从“最后结果是否正确”入手。

这没有错。Agent 说航班已经订好，数据库里就应该真的有 reservation。Agent 说退款已经处理，订单系统里就应该有对应退款记录。Agent 说修好了 bug，测试就应该通过，代码也不应该改坏无关路径。

Outcome 必须看。没有最终状态验证，Agent 很容易只是“说自己完成了”。

但只看 outcome 还不够。

一个 Agent 可能最终完成了退款，但没有验证用户身份。它可能让测试通过了，却顺手改坏了没有覆盖到的逻辑。它可能回答正确，但没有读取最新 policy。它可能第六次重试后才成功，而真实用户不会愿意等六次。

这些问题都藏在过程里。

所以 Agent eval 不能只评估结果，也要看 trace。Trace 不是为了把 Agent 绑在某一条固定路线里。过度检查步骤会让 eval 变脆弱，也会惩罚模型找到的有效新路径。Trace 真正的价值，是让团队看见 Agent 如何理解任务、如何选择工具、如何处理失败，以及从哪一步开始偏离。

对一个真实工作流来说，至少要同时看三件事。

第一，最后状态是否正确。数据库、文件、测试、订单、API 副作用都要能验证。

第二，关键边界是否被守住。身份验证、权限、金额上限、业务政策、人工审批点，不能只靠模型记得。

第三，完成过程是否可以接受。工具调用次数、重试次数、成本、延迟、失败恢复方式，都要符合产品风险。

这也是为什么 trace 不应该只属于工程师。产品经理看 trace，才能知道需求边界是否清楚。客服团队看 trace，才能把真实投诉变成测试用例。工程师看 trace，才能判断问题来自模型、prompt、工具接口，还是环境状态。

一个 Agent 的成功，如果解释不了，就很难被信任；如果复现不了，就很难被改进。

Eval 数据集应从真实失败开始

很多团队迟迟不做 eval，是因为觉得自己还没准备好。

任务不够多，rubric 不够完整，评估平台还没搭好，数据也不干净。于是大家继续手工试几个例子，继续靠体感判断版本好坏。

但 Agent 越早期，越需要 eval。不是因为早期就能做出完美套件，而是因为 eval 会迫使团队把“成功”说清楚。一个需求如果无法变成测试任务，往往说明需求本身还不够具体。

第一批 eval 不需要几百个任务。20 到 50 个真实案例就足够开始。它们可以来自客服工单、用户投诉、内部 dogfooding、手工测试、线上异常，或者团队已经见过的典型失败。

比如一个客服 Agent，可以先拿 30 个真实工单：

• 10 个正常退款
• 10 个超出政策、必须拒绝的请求
• 10 个需要升级人工处理的边界情况

每个任务都写清楚初始订单状态、用户话术、可用工具、公司政策、最终数据库应该是什么状态，以及 Agent 必须告知用户哪些信息。

这个规模不大，但已经足够暴露很多问题：模型是否会轻信用户说法，是否会跳过身份验证，是否会编造退款编号，是否会在政策不明确时直接行动，是否知道什么时候该请求人工介入。

好的 task 不一定复杂，但必须清楚。两个熟悉业务的人读完同一个 task，应该能独立判断什么算通过，什么算失败。如果任务本身有歧义，eval 就会变成噪声。

这也是 reference solution 的价值。每个重要任务最好都有一个已知可行的完成方式，用来证明任务可以完成，也证明 grader 没有配置错。否则你可能以为模型能力不够，实际问题却是任务不可解、grader 太僵硬，或者环境本身有 bug。

eval 不是从完美数据集开始的。它通常从一批真实失败开始。

用户投诉一次，变成一个回归任务。线上异常一次，变成一个状态断言。工具误用一次，变成一个 schema 或权限检查。人工审查发现一次质量问题，变成 rubric 里的一个维度。

这才是 eval 的复利：失败不只是被修掉，还会留下来，让团队以后能更早发现同类问题。

确定性检查应优先覆盖可验证边界

很多团队一谈 eval，就先想到 LLM-as-judge。

它当然有用。开放任务很难只靠程序判断。研究报告是否全面，客服语气是否合适，回答是否 grounded，方案取舍是否合理，这些都需要 rubric 和判断力。OpenAI 的 GDPval 就是一个很好的例子：真实工作 deliverable 先由行业专家盲评，再用 rubrics 保持一致性，automated grader 只是帮助扩展评估，不是直接替代专家。

但 LLM judge 不应该成为默认答案。

Agent eval 里，最稳的信号往往来自确定性检查。代码有没有通过测试，数据库状态有没有改变，退款金额有没有超过上限，文件是否写到正确路径，工具参数是否符合 schema，这些不需要另一个模型来猜。能用代码验证，就应该用代码验证。

更好的做法，是让不同 grader 各自负责自己擅长的部分。

程序化检查负责事实和边界：测试、状态断言、权限、schema、静态分析、成本和轮数。

模型 grader 负责开放质量：rubric、coverage、groundedness、pairwise comparison、自然语言约束。

人类 grader 负责校准标准：专家抽样、主观质量、复杂行业判断，以及模型 grader 是否慢慢偏离人的判断。

这样做不是为了把系统变复杂，而是为了让每一种信号更可靠。程序化检查便宜、稳定、可复现。模型 grader 有弹性，能处理开放表达。人类判断昂贵，但能定义和校准什么才算好。

最危险的 eval，不是没有自动化，而是自动化地评估错东西。

如果 LLM judge 的 rubric 很模糊，它会把不确定包装成分数。如果 deterministic grader 写得太僵硬，它会把合理解法判成失败。Anthropic 也提到过，一些 benchmark 被重新审查后发现，低分不一定来自模型能力不足，也可能来自任务歧义、grader bug 或 scaffold 限制。

所以，eval 本身也需要被评估。任务能不能被人理解，reference solution 能不能通过，grader 判分是否稳定，这些都是评估系统的一部分。

生产反馈必须持续扩充离线 Eval

离线 eval 很适合开发阶段。

它可重复、成本低、不会影响用户，可以在每次 prompt 修改、工具变更、模型升级前运行，帮助团队判断是否引入回归。

但离线 eval 只能覆盖你已经想到的任务分布。

生产环境会不断给出你没想到的东西：用户输入更混乱，工具更慢，权限更复杂，数据状态更脏，业务流程组合更奇怪。很多 Agent 的真实失败，不会出现在最初那组测试题里。

因此，生产级质量体系不能只有离线 Eval，还需要生产监控、人工审查和用户反馈共同补充。

离线 eval 是发布前的第一道防线。Production monitoring 是发布后的现实反馈。人工 transcript review 负责补上自动指标看不见的质量问题。A/B test 负责验证重大改动对真实用户结果的影响。专家抽样负责校准模型 grader，防止它慢慢偏离人的判断。

这些东西不是互相替代的。

离线 eval 告诉你改动是否破坏已知能力。生产监控告诉你真实世界正在出现哪些新失败。人工读 trace 告诉你指标背后的原因。用户反馈告诉你哪些失败真的伤害体验。人类校准告诉你自动 grader 有没有评估错方向。

关键是让这些反馈回到同一个循环里。

生产失败要回流到离线 eval。人工审查要改进 rubric。工具误用要改进 schema。权限事故要改进 guardrail。模型升级要重新跑 baseline。

这样，Agent 产品才不是靠感觉变好，而是在每一次运行后变得更可验证。

Eval 将质量判断沉淀为组织记忆

上一篇我们说，智能体需要 Harness，不只是更强的模型。Harness 给模型上下文、工具、状态、边界、验证和纠正。

Eval 是围绕 Harness 建立的质量验证机制。它不仅评估单次运行，也为团队比较模型、Prompt、工具、权限和 Context 策略提供共同基线。

没有 eval，团队很容易陷入反应式开发。用户说 Agent 变差了，团队去翻几条记录，修一个 prompt，再希望没有破坏别的地方。新模型发布了，大家手工试几个例子，觉得不错就升级。某个工具调用出错了，工程师在代码里补一个判断，但同类问题下次可能换个形态回来。

有了 eval，失败会沉淀成任务，任务会沉淀成基线，基线会沉淀成团队共同的质量语言。

产品经理可以把边界场景写成 eval。工程师可以把工具副作用写成断言。客服和客户成功可以把真实投诉转成测试用例。研究和工程团队可以围绕同一组 trace 讨论改进。每次模型、prompt、工具、权限、上下文策略变化，都有一组共同的任务来回答：我们是真的变好了，还是只是在某些例子上看起来更好？

这就是 Agent Evaluation 最值得长期投入的地方。

它不只是跑分，而是在替团队保存判断。哪些任务重要，哪些错误不能接受，哪些边界必须人工接管，哪些模型升级真的值得切换，都会慢慢沉淀进 eval。

真正成熟的 Agent 团队，不会只问“这次跑分是多少”。他们会问：

这次失败，有没有进入我们的评估体系？

如果答案是肯定的，eval 就不再只是测试成本，而是 Agent 产品变可靠的方式。

相关阅读

• 为什么笃定 AI：企业真正需要的是什么 —— 企业为什么需要 AI，以及为什么每个具体场景仍然必须由证据验证。
• 企业 Context 重构：AI 原生转型的基础工程 —— 任务结果如何转化为下一轮判断可以使用的证据。
• 评估环境 —— 更系统的评估方法论和客服 Agent 示例。
• 智能体需要 Harness，不只是更强的模型 —— Agent 为什么不是模型本身，而是模型运行在系统里。
• Agent 长任务的瓶颈，是上下文工程 —— 为什么长任务可靠性取决于每一轮模型看到的状态。

参考来源

• Demystifying evals for AI agents —— Anthropic 对 agent eval 结构、grader 类型、pass@k / pass^k、eval 生命周期的系统梳理。
• Introducing AgentKit —— OpenAI 对 AgentKit、trace grading、datasets、prompt optimization 和 Evals 平台能力的介绍。
• OpenAI Evals: GDPval —— OpenAI 对真实经济任务、专家评分、rubric 和 automated grader 的研究示例。
• SWE-bench 与 SWE-bench-Live —— coding agent 常用 benchmark，以及面向更新任务和污染控制的 live 版本。
• WebArena 与 OSWorld —— web agent 和 computer-use agent 的代表性环境评估。
• τ-bench 与 tau2-bench —— 面向客服工具调用、多轮对话、policy adherence 和数据库最终状态的 agent benchmark。
• METR Time Horizon 与 Clarifying limitations of time horizon —— 用人类任务时长衡量 agent 能力，以及对该指标局限的澄清。
• Build agents you can trust across any framework with open evals and a control standard —— Microsoft 对企业 agent trust、eval、runtime controls 和 production monitoring 的实践方向。