Agent 评估：从能跑到能信——给概率性系统装上可信任的判断标准
2026-07-30 Agent 评估：从”能跑”到”能信”——给概率性系统装上可信任的判断标准
📅 学习日期：2026-07-30 | 📚 来源：AI Agent 知识库 | 📝 综合文章数：5 篇
📌 为什么选这个主题
昨天（07-29）刚学完 Multi-Agent 多智能体协作，最后留下的核心悬念是：多 Agent 真的工作吗？怎么知道它没在”看似正确地”跑偏？
这不是新问题——它是 Agent 从 Demo 走向生产最大的拦路虎。今天直接跳进”Agent 评估”这个专题，从 5 篇高密度文章（Anthropic 万字长文 / 阿里云 RCA Benchmark / 评估方案全览 / 你不知道的 Agent / 漂移现象解析）综合出完整的工程化评估体系。
学习链路价值：
- 07-23 架构 → 评估是 Evaluation Harness 的核心组件
- 07-24 记忆 → 跨会话评估验证 MEMORY 整合
- 07-27 Skill → 工具调用参数验证是代码评分器核心
- 07-28 上下文 → 评估是 Context Rot 的检测器
- 07-29 Multi-Agent → 评估从单 Agent 扩展到多 Agent（幻觉会互相放大）
- 07-30 评估 → 把前 5 天的所有子系统都”装上可机器执行的判断标准”
🎯 一句话定位今天：评估不是 Agent 开发的”最后一环”，而是与 Harness/上下文/工具/记忆深度耦合的基础设施——“先修评测，再改 Agent” 是贯穿今天的核心方法论。
🎯 核心要点（5 个）
要点 1：Agent 必须评估——与传统软件的根本差异 + Agent Drift 现象
核心命题：传统软件测试方法对 Agent 几乎完全失效，因为 Agent 是”概率性生成系统”而非”确定性执行系统”。
| 维度 | 传统软件 | LLM-Based Agent |
|---|---|---|
| 执行路径 | 同一输入永远同一输出 | 每次推理都在当前上下文里重新”决策” |
| 失败模式 | 偏离航线=告警，可复现可定位 | 没有报错，但推理路径可能悄悄走偏 |
| 变更影响 | ”不改代码就不会变”是铁律 | 知识库更新、工具微调、上下文噪声等细微变化都可能改变决策方向 |
最危险的失败——Agent Drift 漂移现象：
- 没有崩溃、没有报错、服务正常、响应速度无变化
- 输出格式完整、措辞专业，但答案已经偏离
- 用户难以及时察觉，因为答案”看起来”合理
5 种漂移来源（必须全部监控）：
- Prompt Drift（提示词改了一行效果就变）
- Tool Drift（工具 schema 变化）
- Context Drift（上下文结构变化）
- Knowledge Drift（知识库更新）
- Reasoning Drift（推理路径漂移）
💡 关键洞见：模型基准测的是”在标准化测试题上能答对多少”，而 Agent 做的事是另一个量级的复杂——理解模糊意图、拆解任务、选工具、传参数、处理返回值、自我纠正，每一环都可能独立失败，环之间还有依赖关系。Agent 上了生产，评估和可观测性就是必须配套的基础能力。
要点 2：四个评估维度 + 三层 Grader 架构（生产级评估的”骨架”）
4 个评估维度同时测量，缺少任何一个画面都是不完整的：
| 维度 | 评估问题 | 关键指标 | 工具 |
|---|---|---|---|
| 任务完成率（结果层） | 做完了吗？做对了吗？ | TCR = 成功数/总数 | 代码评分器 |
| 工具调用准确率（执行层） | 调对了吗？传对了吗？ | 工具选择率/参数准确率/完全正确率 | 代码评分器 |
| 轨迹合理性（过程层） | 走对路了吗？有效率吗？ | 步骤效率比/冗余步骤率/质量评分 | LLM Judge/Agent-as-Judge |
| 输出可信度（表现层） | 可信可靠吗？专业吗？ | 格式合规率/幻觉率/专业性得分 | 规则+LLM+人工 |
⚠️ 金融类 Agent 的核心权衡：“格式完美但数字错误 > 格式不规范但数字准确”——这是行业踩过的最大坑。
三层 Grader 架构（“能用规则，就不要用 LLM Judge”）：
| 层级 | 工具 | 覆盖流量 | 成本 | 发现问题类型 |
|---|---|---|---|---|
| 第一层 | 规则检查（格式/必填/数值范围/工具名+参数） | 100% 全量 | 接近于零 | 执行层硬错误 |
| 第二层 | LLM as Judge（意图理解/相关性/专业度） | 抽样 5%-20% | 中等 | 质量层软偏差 |
| 第三层 | Agent-as-Judge + 人工复核（完整轨迹评估） | 少量高价值 | 最高 | 架构层系统性缺陷 |
LLM as Judge 三种评审模式：
- Pointwise（单点评分）：在量表上打分——简单但分数标定易漂移
- Pairwise（两两对比）：给 A/B 输出让 LLM 判断哪个更好——一致性远高于单点评分（适合版本迭代对比）
- Reference-based（参照评分）：提供黄金答案——在有明确预期输出的任务上最可靠
LLM Judge 失效场景与对策（必须知道）：
- 位置偏见：倾向给第一个选项更高评价 → 对策：随机交换 AB 顺序跑两次
- 自我偏好：用同系列模型评审自己会系统性偏高 → 对策：跨系列使用或混用多模型取共识
- 无法验证事实：只能判断”听起来合理”不能核实数字 → 对策：配合规则检查或人工抽查
💡 关键认知：离线评估 + 在线评估缺一不可。很多团队只做离线评估，上线后就不再系统性评估——而 Agent 失败有相当大比例来自评测集里没出现过的真实场景。“两个阶段是不同战场”——离线解决”预期场景能不能用”，在线解决”真实世界有没有漂移”。
要点 3：Transcript × Outcome + Pass@k vs Pass^k（Anthropic 万字长文的核心区分）
这是 Anthropic 整篇评估长文里最值得反复琢磨的两个区分。
区分 1：Transcript（转录）vs Outcome（结果）
| 维度 | 定义 | 价值 | 风险 |
|---|---|---|---|
| Transcript | Agent 的”心路历程”：所有 CoT、工具调用、API 返回值 | 用于 Debug，告诉你 Agent “想”做什么 | 漏掉”说了但没做到” |
| Outcome | 环境的最终状态 | 客观验证（DB 真的多一条记录、文件真的被改） | 漏掉”中间步骤走歪” |
Anthropic 真实案例：Opus 4.5 在订机票任务中违反了预设评估路径却帮用户找到了更便宜的方案——只看 Transcript 会被判失败，只看 Outcome 看不到决策过程。两类必须同时覆盖。
💡 代码 Agent 的核心原则：Outcome 只是及格线，Transcript 才是分水岭——必须用确定性评分器卡功能正确性，同时引入分析工具扫”屎山”+ LLM 裁判盯防暴力试错。
区分 2：Pass@k vs Pass^k（量化非确定性）
| 指标 | 定义 | 适用场景 | 关键警告 |
|---|---|---|---|
| Pass@k | k 次尝试中至少 1 次成功就算赢 | 辅助人类产品：允许模型”发散”（Copilot 给 5 个方案） | 用于回归 → 漏掉问题 |
| Pass^k | k 次尝试中每次都必须成功才算赢 | 替人类干活的产品：稳定性是生命线（银行客服） | 用于能力探索 → 误判天花板 |
⚠️ 数学警示：单次成功率 75% 的 Agent，连续 3 次都成功的概率仅约 42%——随着 k 增加，pass^k 断崖式下跌。这意味着上线前必须用 pass^k 严格把关，不能用 pass@k 自我安慰。
8 步评估实施路线图（Anthropic 工程实践）
| 步骤 | 核心要点 |
|---|---|
| Step 0 | 尽早开始——20-50 个真实失败案例就够了 |
| Step 1 | 从手测开始——把 bug tracker 的”用户报错”直接转为测试用例 |
| Step 2 | 任务无歧义 + 参考答案——两个领域专家各自能稳定通过才算合格 |
| Step 3 | 题集平衡——防 undertrigger（该搜不搜）和 overtrigger（不该搜乱搜） |
| Step 4 | 评估环境稳定——每次从干净环境启动，避免遗留文件/cache/git 历史”作弊” |
| Step 5 | 评分器想清楚——能用确定性就用确定性；LLM Judge 用在主观处；人工只做校准 |
| Step 6 | 必读 transcripts——分数异常往往是 grader bug/题目歧义/harness 卡死 |
| Step 7 | 监控饱和——100% 的 eval 已无法衡量进步，会”压扁”能力提升的信号 |
| Step 8 | 长期维护——专门 eval 团队负责基础设施；最接近用户的人最会定义成功 |
两种评估战略：进攻战 vs 保卫战
| 类型 | 问题 | 策略 | 通过率要求 |
|---|---|---|---|
| Capability Evals（能力评估） | “这个 Agent 能做到什么？“ | 进攻战：挑目前很难、经常翻车的 Task 考 | 低也无所谓（设定”登山目标”） |
| Regression Evals（回归评估） | “这个 Agent 还能做它以前做过的事吗？“ | 保卫战：挑之前做过的题考 | 必须接近 100%（掉分即 Bug） |
要点 4：多 Agent 评估的复杂性（衔接 07-29 Multi-Agent）
多 Agent 评估的关键认知（来自《你不知道的 Agent》）：
多 Agent 下幻觉会互相放大——Agent A 先带偏，Agent B 跟着强化，Agent C 再继续叠加。
多 Agent 评测的顺序（文章明文给出，不能乱）：
- 先有可持久化任务图（每个 Agent 知道自己该做什么）
- 再引入有身份的队友（明确谁负责什么）
- 再引入结构化通信协议（MCP / A2A）
- 最后再加交叉验证或外部反馈（独立 Agent / 单元测试 / 编译器 / 人工审查）
多智能体系统的评估方法（来自《评估方案全览》）：
| 评估对象 | 方法 | 核心 |
|---|---|---|
| 各子智能体独立评估 | 推理层 + 行动层分开评估 | 防止”整体 OK 但局部失败” |
| 跨智能体数据传递 | 验证 Agent A → B 的数据正确性 | 防止数据传递被截断/篡改 |
| 冲突解决机制 | 验证冲突时谁优先 | 防止死锁/无限循环 |
| 整体任务完成 | 端到端评估 | 防止”局部正确但全局失败” |
代表性基准：
- AgentBench：8 类环境（操作系统/数据库/网页购物等），覆盖最广
- MultiAgentBench：专门评估协作与竞争行为
💡 07-29 衔接：昨天学的 Multi-Agent Harness 五大核心模块（架构/评估/记忆/成本/MCP）中的”评估”，在今天有了完整的方法论——多 Agent 评估需要分层、分步、分阶段地推进，不能一上来就端到端评估。
要点 5：业界基准 + 企业级评估框架（从 Demo 到生产的桥梁）
5 类智能体场景的代表基准（覆盖能力/回归/安全）
| 智能体类型 | 核心评估方法 | 代表基准 | 顶尖成绩 |
|---|---|---|---|
| 编程 Agent | 单元测试 + 静态分析 + LLM 代码质量 | SWE-bench Verified / Terminal-Bench | 前沿 87.6% |
| 对话 Agent | 多维度评分 + 状态检查 + LLM 模拟用户 | τ-bench / τ2-bench | — |
| 研究 Agent | 基础性检查 + 覆盖面 + 来源质量 | BrowseComp / GAIA | 前沿 74.6% |
| 计算机使用 Agent | 环境状态检查（URL/文件系统/DB） | WebArena / OSWorld / AndroidWorld | 369+ 任务 |
| 多智能体系统 | 组件独立 + 跨组件一致性 + 端到端 | AgentBench / MultiAgentBench | — |
阿里云 RCA Benchmark（业界首个 Agentic Ops 根因分析开源基准）
为什么重要：根因分析是 Agent 评估中复杂度最高、最难标准化的核心环节——既不能像文本问答那样有标准答案，也不能像代码生成那样有单测。
三大模块：
- 运行环境：可生成真实故障信号的微服务仿真系统（40+ 业务服务，最长 7 层调用链路）
- 结构化样本集：搭载四层结构化真值体系（故障类型/归一化根因实体/因果传播链/关键证据检查点）
- 评估协议：定因(40%) + 定界(30%) + 过程(30%) 三维加权评分，近 7 成评分靠确定性规则计算
四层 GSTO 质量门禁：结构规范 / 信号有效性 / 时间窗口 / 开放适配性——严格过滤故障链路失真的无效样本。
目前规模：200+ 合规样本，划分 L1-L4 四级难度，L2/L3 中高难度场景作为核心评估主场。
💡 关键洞见：RCA Benchmark 的核心创新不是数据集本身，而是四层结构化真值体系 + 三维加权评分——它解决了”复杂任务如何用确定性规则量化评分”这个世界难题。
企业级评估框架
CLEAR 框架（5 维度，企业部署决策用）：
| 维度 | 评估内容 | 核心指标 |
|---|---|---|
| Cost | token 消耗、推理成本、基础设施开销 | 单任务成本 |
| Latency | 首 token 时间、吞吐量、端到端延迟 | P50/P99 |
| Efficacy | 任务完成率、准确率 | 业务完成率 |
| Assurance | 安全性、合规性、可审计性 | 越狱成功率 |
| Reliability | 跨多次运行的一致性 | Pass^k |
四柱框架（学术前沿，arXiv 2512.12791）——评估 Agent 系统的四个核心组件：
- LLM 层：规划质量、指令遵循、推理一致性
- 记忆层：精确率-召回率平衡、决策相关上下文提取
- 工具层：工具选择正确性、参数传递、错误恢复
- 环境层：状态管理、副作用隔离
8 大主流评估工具平台（按场景选）：
| 工具 | 定位 | 适合谁 |
|---|---|---|
| Harbor | 容器化环境运行智能体 | Terminal-Bench 2.0 官方框架 |
| Braintrust | 离线评估 + 生产监控 + 实验追踪 | autoevals 内置评分器 |
| LangSmith | LangChain 生态，追踪 + 离线/在线评估 | LangGraph 用户首选 |
| Langfuse | LangSmith 的开源自托管替代 | 自托管需求 |
| Arize Phoenix | 开源 LLM 追踪、调试、评估 | 偏研究 |
| DeepEval / Confident AI | 开源评估框架，推理层 + 行动层分别评估 | 学术派 |
| Amazon Bedrock AgentCore | AWS 原生，框架无关 | AWS 云原生 |
| OpenAI Evals | 开源，自定义数据集 | OpenAI 生态 |
⚖️ 分歧与讨论
1. “Pass@k vs Pass^k 该用哪个？”
- 主流观点：场景决定——辅助人类产品用 Pass@k，替人类干活的产品用 Pass^k
- 反方观点：能不能两个一起用？能力突破时重跑 Pass@k，每次代码变更都跑 Pass^k
- 我的判断：不能混用，但可以分别建库——能力评估库和回归评估库是两套独立的 eval，必须分得清清楚楚
2. “评估优先还是模型优先？”
- 主流观点（Anthropic）：评估驱动开发——先把评测集建好，再迭代 Agent
- 反方观点：模型能力不够时，建评测集是”先盖房子再住人”
- 共识原则（《你不知道的 Agent》）：“先修评测，再改 Agent”——看到 Agent 表现下降，先检查评测系统是否出问题，再看模型本身。运行环境资源不足、评分器有 bug、测试用例与生产脱节几乎无法从结果数字区分为”模型退化”
3. “代码评分器 vs LLM Judge vs 人工”
- 主流观点：能用规则，就不要用 LLM Judge
- 反方观点：复杂任务（开放式研究、多轮协商）里，模型上限本身仍然更关键——评测能做的有限
- 共识顺序：有明确正确答案 → 优先用代码；需要判断语义质量 → 用模型；拿不准的案例 → 人工标一批用来校准
4. “RCA Benchmark 能否复用到其他 Agent 场景？”
- 阿里云认为：四层结构化真值 + 三维加权评分可推广到任何需要”复杂推理 + 多步决策”的 Agent 场景
- 业界质疑：根因分析的特殊性（多源观测 + 因果传播链）能否简化复用到对话/编程类
- 我的判断：核心思想可复用（“用确定性规则替代 LLM 评审”），具体实现需要根据场景重新设计
🔗 与已学内容的联系
| 已学主题 | 与 Agent 评估的关系 |
|---|---|
| 07-23 架构演进 | 评估是 Evaluation Harness 的核心组件——Harness 负责”怎么跑 Agent”，Evaluation Harness 负责”怎么评 Agent” |
| 07-24 记忆系统 | 跨会话评估（同一任务在不同 session 下的成功率）验证 MEMORY.md 整合是否真的有效；Trace 应支持语义检索 |
| 07-27 Skill 技能 | 工具调用参数验证是代码评分器核心；通过 Trace 统计”Agent 混淆了两种 Skill”的频率，直接驱动 Skill 描述的迭代 |
| 07-28 上下文工程 | Trace 必须记录完整 Prompt 和 messages[]——验证”上下文分层”做得对不对；评分器要能识别 Context Rot 引发的失败模式 |
| 07-29 Multi-Agent | 多 Agent 评估需要”分步推进”（任务图 → 身份 → 通信 → 交叉验证）；多 Agent 幻觉会互相放大——评估门槛比单 Agent 更高 |
| 横向：可观测性 | 可观测性是评估的前置，不是并列——评估只能告诉你对错，可观测性告诉你哪一步出了问题 |
🎯 今天与昨天的关键衔接：07-29 学了 Multi-Agent Harness 五大核心模块（架构/评估/记忆/成本/MCP），今天直接深入”评估”模块——发现多 Agent 评估需要分层、分步、分阶段地推进，不能一上来就端到端评估。这恰好补完了昨天留下的”多 Agent 怎么知道没跑偏”的悬念。
🎯 一句话总结今天：Agent 评估的本质是”给对错装上机器可执行的判断标准”——它既是 Harness 的核心组件，又是验证上下文/工具/记忆设计是否正确的唯一手段，更是避免”在错的方向上越调越差”的安全网。Trace 是评测的前提，Pass@k 与 Pass^k 不能混用，评测系统本身要先于 Agent 被信任、被审查、被修复。
❓ 思考题
- 如果你的 Agent 单次成功率是 80%，你想让用户连续 3 次都拿到正确结果，pass^3 大概是多少？80% 的”看上去不错”在生产中会带来多大问题？这对你的 Agent 上线策略意味着什么？
- Transcript（过程）和 Outcome（结果）何时应该分别给高权重？请你为两个具体业务场景（如”自动生成财报”和”自动写代码”）分别设计评估维度权重，并说明为什么。
🎯 行动项
- 建你的第一个 Eval Set（今天就可以做）
- 从你的项目里挑 3-5 个真实失败案例（不是想象的，是真的报错的）
- 按”验收标准先于数据”原则：让两个领域专家独立判断”这个 case 算通过还是失败”——如果判断不一致，说明你的验收标准还没写清楚，先去解决定义再收集数据
- 每个 case 写明：输入、参考输出、判定标准
- 接入完整 Trace（本周）
- 选一个工具（推荐 LangSmith 或 Langfuse，看你用 LangGraph 还是自研）
- 确保 Trace 至少记录：完整 Prompt + 工具名 + 工具参数 + 工具返回值 + token 消耗 + 推理耗时
- 跑 10 个真实任务，手动读 1-2 个 Trace——你会立刻发现”评分器本身的 bug”（《你不知道的 Agent》反复强调）
- 设计警戒线与停服线（下个迭代）
- 为你的核心评估指标设两条线：警戒线（人工复核，不影响运行）+ 停服线（自动降级或暂停）
- 业务风险越高，停服线越严格——不要用统一标准套所有 Agent
📚 参考文章
- 《Agent 评估：靠什么信任一个概率性的系统》（a72b9ed83e20fbfb8b53dfe8b75332707307200439519008）
- 贡献视角：Agent Drift 现象（5 种漂移来源）+ 4 评估维度 + 规则/LLM Judge/Agent-as-Judge 三层架构 + 警戒线/停服线 + Trace/Span 可观测性
- 《AI 智能体评估方案全览》（0cceacbbb5fd08c800c315987698c8c87307200439519008）
- 贡献视角：5 类智能体场景的完整评估方案（编程/对话/研究/计算机使用/多智能体）+ CLEAR 框架 + 四柱框架 + 8 大工具平台
- 《Anthropic 万字长文：系统化评估 AI Agents 的工程方法》（89309a0fc6c606d6c03aacaa8c3efc1a7307200439519008）
- 贡献视角：Transcript vs Outcome 双轨制 + Pass@k vs Pass^k 区分 + 8 步实施路线图 + 进攻战/保卫战 + 瑞士奶酪模型
- 《你不知道的 Agent：原理、架构与工程实践》（7edf97860f08549115c3b4f20d410b727307200439519008）
- 贡献视角：“先修评测，再改 Agent”方法论 + 多 Agent 评估的 4 步顺序 + 评测系统本身的隐藏 bug + 反模式汇总
- 《阿里云正式发布 RCA Benchmark》（126875988cd00a01333971ac96743f637307200439519008）
- 贡献视角：业界首个 Agentic Ops 开源基准 + 四层结构化真值体系 + 三维加权评分（定因 40% + 定界 30% + 过程 30%）+ 四层 GSTO 质量门禁
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！