当前阅读：Agentic Eval 设计
不能度量的 Agent，不能稳定进化
Agent 评估的难点在于它既有不确定输出，又有多步骤轨迹和工具调用行为，所以真正有效的 Eval 不能只看最终答案。
一个来自清结算系统的对照
传统清结算系统里，一笔交易的正确性判断是二元的：账对上了就是对，对不上就是错，中间几乎不存在灰色地带。一次批处理跑完，直接核对借贷双边余额即可，出问题也能顺着流水号定位到具体哪一步。
假设有一个负责处理"对账异常"的 Agent：给它一笔金额不平的交易，让它查流水、判断异常类型、决定是否需要人工复核。它可能查对了流水但走了一条效率很低的路径，也可能最终判断正确、但中间多调用了一次不该调用的敏感字段查询接口，触发了额外的合规日志。如果评估只看"最后判断对不对"，这两种情况会被记成同一个分数——但在真实的清结算场景里，"多查了一次不该查的接口"本身就是需要被记录、被追责的行为，不是可以被最终结果掩盖的噪音。
这是 Agent Eval 和传统 QA 的本质区别：传统 QA 问的是输出对不对，Agent Eval 还要问它是不是以可审计、可追责的方式得到这个结果。对强监管场景来说，后一个问题往往比前一个更重要。
Agent 的评估不能只看最后一句回答，而要同时评价步骤、行为和结果——尤其在强监管场景，"过程是否合规"本身就是评估对象，不是结果的附属品。
一个经济学概念：结果偏见如何误导评估
行为经济学里有一个概念叫结果偏见（outcome bias）：人倾向于用结果的好坏去反推决策的对错，而忽略决策当时的信息和过程是否合理。一个赌徒押对了一次高风险赌注，不代表这个决策本身是理性的。
很多团队做 Agent Eval 时会不自觉地掉进同样的陷阱：只要最终答案对了，就判定这次运行是"好"的，完全不管中间过程——工具调用次数是不是异常多、是不是检索了不该检索的字段、是不是靠了一次侥幸的重试才蒙对。这种评估方式本质上是把结果偏见制度化了：它会持续奖励那些偶尔走运的执行路径，这些路径一旦在更大样本量或更复杂任务上运行，出问题只是时间问题。
对应的解法不是抛弃结果层指标，而是把评估拆成多个层次，让"过程是否合理"和"结果是否正确"分开计分，不让后者掩盖前者。
先看一张评估闭环图
如果一套 Eval 不能进入这个闭环，它就更像一次性演示，而不是系统迭代基础设施。
为什么 Agent 评估天然更难
一个普通函数通常是：
输入 -> 处理 -> 输出一个 Agent 更像是：
目标 -> 多步推理 -> 工具调用 -> 状态变化 -> 最终结果这中间至少叠加了 4 类不确定性：输出内容不完全稳定、中间步骤可能变化、工具调用结果依赖外部环境、同一个目标可能存在多条合理路径。只看最终回答是否"像是对的"，往往会错过这四类问题里的大多数。
一个时序图：为什么只看最终答案不够
如果只保留最后一句输出，后面大部分系统质量信号就都丢掉了。
从结果到系统：四个层次
一个更实用的做法，是把评估拆成四层，层层递进：
第一层：结果层
任务是否完成、最终答案是否正确、输出是否满足格式和约束要求。这层最容易量化，但也最容易掩盖问题——就像前面提到的对账 Agent，结果层满分的情况下，行为层可能已经出了问题。
第二层：行为层
Agent 的每一步动作是否合理：是否选择了合适的工具、是否在合适时机做了检索、是否遗漏了必要步骤、是否在错误路径上反复重试。在清结算场景里，这一层等价于"操作是否合规"——即使结果正确，一次不该发生的查询也应该被记录和扣分。
第三层：轨迹层
关注完整执行路径：第一步为什么这么做、工具调用顺序是否合理、中间状态有没有明显漂移、最终输出是否能从轨迹中得到支撑。这一层的价值在于事后审计——如果监管要求说明"系统为什么做出这个判断"，你需要的不是最终答案，而是整条轨迹。这也是为什么强监管场景下，轨迹层往往比结果层更早被要求补齐。
第四层：系统层
延迟、成本、成功率、重试率、工具故障恢复能力。这一层关注的不是单次任务质量，而是系统能不能稳定、经济地跑下去。
四层放在一起，比单一的"最终答案准确率"更接近真实系统质量，也更贴近清结算这类系统原本就熟悉的"事中控制 + 事后审计"思路——只是把审计对象从人的操作换成了 Agent 的执行轨迹。
一张脑图：四层评估到底在看什么
评估对象是整条链路，不是模型本身
一个常见误区是把 Eval 等同于"测模型好不好"。但在真实系统里，你评估的其实是一整条链路：prompt / system 规则、上下文工程、工具描述与参数设计、工具本身的可靠性、重试和停止策略、轨迹记录方式。模型只是这条链路上的一环。
这一点在清结算场景里体现得尤其明显：同一个模型，配合设计糟糕的工具描述（比如一个查询接口的参数说明模糊到 Agent 经常传错交易日期范围），和配合清晰的工具描述，评估结果会完全不同。如果只测模型，会得出"模型能力不够"的错误结论，实际问题出在工具设计上。
数据集设计：警惕"平均分"
Agent Eval 的另一个常见错误，是把测试样本设计成传统问答的样子——随机挑一批问题，跑一遍，出一个平均分。
更合理的做法是按任务类型分层，比如在对账 Agent 的场景里可以分成：常规小额差异核对、跨币种对账、涉及历史冲正记录的复杂差异、需要人工介入的边界案例。分层之后才能看出系统在哪类任务上开始失控，而不是被一个笼统的平均分掩盖真正的短板——这正是统计学里分层抽样要解决的问题：总体异质性越高，一个单一的汇总指标就越没有信息量。
一个具体的反例：如果测试集里 80% 是常规小额差异这种容易题，即使复杂差异全部处理失败，平均分依然可能好看。按任务分桶之后，"复杂差异通过率"和"人工介入触发准确率"这些细分指标才会真正暴露问题：
- 检索任务通过率
- 工具调用任务通过率
- 多轮任务通过率
- 长任务中断率
- 复杂差异 / 边界场景通过率
一个实用建议：先做小而真的任务集
很多团队刚做 Eval 时容易走两个极端：样本太少只能看热闹，样本太大但质量参差不齐、很难分析。更合理的方式通常是先做一小批高价值样本：高频真实任务、容易失败的边界任务、业务上后果较重的关键任务。这样即使数据集不大，也能更早暴露关键问题。
Anthropic 在 2025 年关于 eval 和 harness 的工程文章里也强调，Agent 评估要尽量贴近真实任务，关注基础设施噪声、长任务表现和可复现失败模式，而不是只看一次性总分。Demystifying evals for AI agents Effective harnesses for long-running agents
目标一旦被量化，就会被优化——也会被扭曲
经济学里有一个更尖锐的说法，通常称为古德哈特定律：一旦某个指标变成了被优化的目标，它就不再是一个好的度量。放到 Agent Eval 里，这个警告尤其值得记住——如果只用"最终答案准确率"考核系统，团队很可能会找到让准确率好看、但过程并不健康的路径，比如让 Agent 对不确定的情况一律给出保守但"大概率不算错"的回答，规避复杂判断，短期指标上升，但系统实际处理复杂任务的能力并没有真正提高。
应对方式不是追求一个完美的单一指标，而是保留多个互相牵制的度量——结果、行为、轨迹、成本同时看，任何一个指标被单独优化到极致时，其他指标会先亮红灯。
一个简单示例
假设你在评估前面提到的对账异常 Agent，可以把指标拆成：
| 层次 | 关注点 | 示例指标 |
|---|---|---|
| 结果层 | 差异是否被正确判断 | 分类是否正确、是否触发合规必要的人工复核 |
| 行为层 | 工具调用是否合理 | 是否查询了超出权限的字段、是否遗漏必要核对步骤 |
| 轨迹层 | 执行路径是否稳定、可追溯 | 是否无意义重复查询、判断依据能否从轨迹还原 |
| 系统层 | 成本和稳定性 | 平均耗时、平均轮次、失败重试率 |
这时就不会只盯着"最后分类对不对"，而是能看到整个任务链条的质量，包括监管最终会追问的"这个判断是怎么来的"。
一个更接近落地的评分表
| 维度 | 问题 | 示例评分 |
|---|---|---|
| 任务结果 | 差异分类是否正确 | pass/fail |
| 合规边界 | 是否越权查询了敏感字段 | pass/fail |
| 行为质量 | 是否完成必要核对步骤 | 0-2 |
| 轨迹质量 | 是否出现无意义重复调用 | 0-2 |
| 系统成本 | 轮次和耗时是否过高 | 0-2 |
这样设计的好处是：既保留了不可妥协的硬约束（合规边界），也保留了可比较的软指标。
一个最小评估记录示例
{
"task_id": "recon-mismatch-fx",
"task_success": true,
"audit_trail_complete": true,
"tool_calls": 5,
"unnecessary_queries": 1,
"total_runtime_sec": 38,
"notes": "判断正确，但多触发了一次不必要的敏感字段查询"
}这条记录已经能支撑后续比较：如果下一版本把 unnecessary_queries 降到 0 而 task_success 不变，说明系统在合规成本上有了实质改进，即使结果层指标看起来没有变化。
什么叫"有用的评估"
一个真正有用的 Eval，不是单纯打分，而是能支持下面这些动作：找到失败模式、指导下一轮优化、比较不同版本效果、防止系统回归。如果一套评估只能告诉你"这次好像差不多"，那它很难支撑真正的系统迭代。
OpenAI 在 2025 年关于 AgentKit 和 eval 平台的资料里，也把 dataset、trace grading、自动优化和版本比较放在同一条链路里，本质上就是把 Eval 当作持续优化基础设施，而不是验收表单。Introducing AgentKit Agents SDK
常见失败模式
失败一：只测最终答案
会遗漏过程问题，在强监管场景里，过程问题本身可能就是不可接受的风险。
失败二：任务集过于简单
线下全是容易题，线上暴露的都是没被覆盖的复杂场景。
失败三：没有稳定的基线
没有基线，很难判断这次优化到底是真的变好了，还是只是随机波动。
失败四：评估和真实目标脱节
评估的是"回答像不像"，但真实目标是"任务有没有被合规地完成"，这套评估会越来越偏。
失败五：评估样本和线上环境脱节
线下没有模拟真实工具失败、没有考虑长任务中断、线下环境比线上干净太多——这会让线下看起来"效果不错"，上线后却不断暴露新问题。
设计 Eval 时最值得优先做的事
- 先定义任务成功标准，明确哪些是不可妥协的硬约束（例如合规边界）
- 再拆结果、行为、轨迹和系统层指标
- 按任务类型建立测试集，而不是只做一个平均分
- 对关键失败模式单独保留回归样本，警惕单一指标被过度优化后的失真
你不一定一开始就拥有完美评估体系，但至少要从"可持续迭代"这个目标出发来搭。
Eval 最终服务的是决策
一套好的 Eval，最终应该能回答这些问题：这次改动到底有没有变好、好在哪里坏在哪里、是结果改善了还是只是成本上升、哪些失败样本应该优先进入下一轮优化。如果它回答不了这些问题，那它很可能还只是"统计输出"，而不是"工程工具"。
本节总结
- Agent Eval 不能只看最终答案，要同时看行为、轨迹和系统表现——尤其在强监管场景，行为和轨迹本身就是评估对象，不是结果的附属品
- "结果偏见"和"古德哈特定律"提醒我们：单一指标既会掩盖过程问题，也会在被长期优化后失真，评估体系需要多个互相牵制的维度
- 数据集要按任务类型分层，而不是追求一个笼统的平均分；分层抽样的逻辑同样适用于任务集设计
- 一个好的评估体系最终服务于决策：这次改动是否真的变好、成本是否可控、哪些失败模式需要优先修复
下一步
继续阅读 奖励函数设计，看这里讨论的多维度评估如何进一步转化成可优化、可学习的信号。