第 28 课：Agent 评测与生产化｜第一性原理大模型课程

第 28 课：Agent 评测与生产化

这是第四部分（Agent 工程）的最后一课。前面我们把一个 Agent"造出来、接上工具、记住知识、会规划、能训练"——但这一切都还不是交付。怎么证明它真能上生产？这一课把"跑分"与"可用"分开，用可靠性指标（pass^k）替代单次最好成绩，把评测从"看结果"推进到"看轨迹"，再补齐安全、成本与发布门禁——用一套可执行的检查，回答"它到底能不能上"。

🎯 学完这 6 步你将能够：

① 说清"跑分高 ≠ 能用"，并用 pass^k 算出可靠性随试验次数的衰减
② 把评测分成"结果评测"与"过程评测"，定位一条失败轨迹是从哪一步开始歪的
③ 用最小权限、沙箱、发布门禁与四线监控，回答"这个 Agent 能不能上生产"

🗺 本节推理链（6 步逻辑递进：从"为什么跑分不算数"到"怎么守住上线质量"）

1要证明一个 Agent 真能上生产，这就要求先承认一件事：跑分高不等于能用——分数里混着格式适配、蒙对与噪声，而 tokens 与延迟根本不在分数里。跑分不等于可用。

↓

2既然「跑分不等于可用」，所以要看它在同一任务上稳不稳——这就要求用"连续 k 次都对"的可靠性指标（pass^k），而不是单次最好成绩；换个 context 还能不能对，才是生产关心的。要看连续成功率。

↓

3既然「要看连续成功率」，那么单看终态还不够——这就要求评过程：一条轨迹里哪一步开始歪，要能定位到具体动作与当时写进 context 的内容。过程也要能评。

↓

4既然「过程也要能评」，那么评过程时会看清一件事：Agent 的每一步都真的作用于外部世界（改数据、发邮件、调接口），一旦某一步被外部文本诱导，就会越权去改它本不该动的东西——而模型的 context 又分不清"指令"与"被读的数据"——这就要求先用最小权限与沙箱把风险关进笼子。生产先解决安全。

↓

5既然「生产先解决安全」，那么加进来的沙箱、校验与人审都会推高开销——这就要求把账算平：盯住 tokens 与尾部延迟，用缓存与模型路由把成本压住。成本延迟要盯住。

↓

6既然「成本延迟要盯住」，那么最后一步是把上面所有检查变成发布门禁——这就要求灰度上线、质量监控四线、可回滚，每次发布都跑同一套 tokens 账与用例，证明它"真能上生产"而不是"演示能跑"。上线要有发布门禁。

Agent 评测pass^k轨迹评测安全与权限成本与延迟发布门禁

榜单分数高，就代表线上能用吗？分数里混进了什么？

提示：从「换一批数据、再跑一次」两个动作去拆——榜单给你的是一个数，线上要的是长期稳定。

▾

知识背景

Agent 的评测和模型评测一样有构念效度问题（即"测的分数是否真的代表你要测的能力"，第 19 课）：分数 = 真实能力 + 环境适配 + 蒙对 + 噪声。以代码任务为例：SWE-bench（Jimenez 等，arXiv:2310.06770，ICLR 2024）发布时，当时最好模型 Claude 2（用 BM25 检索）约 1.96%；随后 SWE-agent（Yang 等，arXiv:2405.15793）报告 12.47%（其论文自己的对照基线是 3.8%，约 3.3×）。注意这是两篇论文、两套基线，不能直接相除。

上一课我们把"会工具、会规划"训进了权重。现在到了最后一关：榜单分数高，为什么上线还是翻车？

因为榜单测的是"在这套任务、这个环境、这次采样下能不能答对"，而生产关心的是"换一组数据、多跑几百次、还要付得起 tokens 与延迟"——两者不是同一件事。就像驾照场地考 vs 真实马路：场地里倒库满分，不等于雨天晚高峰也能开好。所以先把"跑分"与"可用"的差距摆清楚。

🧮 第一笔账：跑分里的"非能力成分"

Step 1：一个分数由四部分组成

成分	说明	上线后还在吗
真实能力	确实会做	在
环境适配	贴合这套任务格式	换环境就没了
蒙对	瞎猜命中	换数据就没了
噪声	抽样波动	不承载能力

算术无关的一条拆解：上线后真正留下来的只有真实能力——其余三项会在换数据、换环境、重复采样时蒸发。

Step 2：同一榜单上的巨大差距

方案	SWE-bench 解决率
SWE-bench 当时最好模型 Claude 2（BM25 检索，2023）	1.96%（arXiv:2310.06770）
SWE-agent 报告	12.47%（arXiv:2405.15793）
同论文口径	12.47% ÷ 3.8%（其对照基线）≈ 3.3×

算术：两篇论文、两套基线不能直接相除；按 SWE-agent 论文自己的对照基线 3.8%（即 3.79% 的四舍五入），提升约 3.3×。可见"换方法"能改分数，但绝对水位仍然很低：榜单上的高分，往往只是相对进步。

Step 3：人的基线与 AI 的差距

项	数值
GAIA 人类基线（arXiv:2311.12983）	约 92%
同期 AI 系统	明显更低（差距数十个百分点）
含义	任务对人类简单、对 Agent 难

算术：GAIA 的设计目标是"人类约 92% 能做对、对 AI 却很难"。把人类与 AI 的差距摆在台面上，比看单一分数更能说明"离能用还有多远"。

🎯 关键认知

评测的第一步是承认分数不等于能力：只有"真实能力"会跟着你上线，环境适配、蒙对与噪声都会蒸发。所以看 Agent 的分数，先问三件事——换数据还灵吗？换环境还灵吗？重复跑还灵吗？

AI 助教

👋 对"跑分 vs 可用"有疑问？比如「该看哪个榜单」「怎么设计自己的测试集」？

说清你的场景，我帮你判断该补哪一类评测。

同一个任务，怎么保证它每次都能做对？

提示：一次成功说明不了什么——想想要"连续几次都对"才算稳，这个概率会怎么随次数变化？

▾

知识背景

τ-bench（Yao 等，arXiv:2406.12045）用"模拟用户 + 领域 API + 政策文档"评测 Agent，并提出 pass^k：同一任务连续 k 次尝试都成功的概率，用来衡量可靠性而非单次最好成绩。报告显示：即便是当时最好的函数调用 Agent（如 gpt-4o），两域合计的任务成功率也 < 50%（这是两域平均口径；零售单域 pass@1 约 61%、高于此，不应与单域数字直接对撞），零售场景 pass^8 < 25%。

上一张卡片说明跑分不等于可用。那么生产最关心的"稳定"该怎么量？为什么单次成功率不够，要看连续成功率？

因为一次成功可能只是运气；用户会反复用、任务会重复跑，而可靠性是连乘的——单次 90% 看着不错，连做 10 次全对就只剩三成多。就像验枪不能只打一发：要连续打靶都上环，才算枪准；单发命中可能是手气。所以要用 pass^k 把"稳定性"算出来。

🧮 第二笔账：pass^k 与可靠性的衰减

Step 1：pass^k 的定义

指标	含义
pass@k	k 次里有 1 次成功即可（能力上限）
pass^k	每任务 k 次全都成功（可靠性）
严格定义	pass^k = E[(pᵢ)^k]：每个任务 i 的连续 k 次全对率 pᵢ^k，再在任务上取平均
与 p^k 的关系	f(x)=x^k 在 k>1 时为凸，由 Jensen 不等式有 E[(pᵢ)^k] ≥ p^k——所以 p^k 只是下界（保守估计），真实 pass^k 不低于它

算术无关的一条区分：pass@k 回答"能不能做到"，pass^k 回答"能不能每次都做到"——换个 context 还能不能对，才是可靠性真正要回答的；注意 p^k 只是 pass^k 的下界，真实可靠性不会低于它。

Step 2：单次成功率如何随次数衰减

单次 p	连续 8 次全对 ≈ p^8
0.90	0.90⁸ ≈ 0.430
0.70	0.70⁸ ≈ 0.058
0.50	0.50⁸ ≈ 0.0039

算术：单次 50% 时，连续 8 次全对只剩 0.39%；即便单次 90%，8 次全对也只有 43%。这就是 τ-bench 报告"pass^8 < 25%"的含义——它比单次成功率吓人得多。

Step 3：这对发布意味着什么

要求	推论
要 8 次全对 ≥ 99%	单次 p 需 ≈ 0.9987（0.9987⁸ ≈ 0.99）
实际做法	关键动作加重试、幂等与人审
结论	靠"提高单次成功率"很难达标，必须加兜底

算术：要 8 次全对到 99%，单次要 0.9987 以上（0.9987⁸ ≈ 0.99）。注意这是按保守下界 p^k 反推的充分条件——真实 pass^k 不低于 p^k，所以做到 0.9987 一定够、反之未必要这么高。现实中仍很难。所以工程上不追求"单次完美"，而是对关键动作加重试 + 幂等 + 人工确认。

🎯 关键认知

可靠性的正确量法是 pass^k（连续 k 次全对），p^k 是它的下界（真实值不低于 p^k），比单次成功率严格得多。生产上的结论很实在：别指望"单次做到完美"，要给关键动作准备重试、幂等与人审兜底。

AI 助教

👋 对 pass^k 有疑问？比如「k 取多少合适」「怎么提升稳定性」？

说清你的场景与容错要求，我帮你定 k 与兜底策略。

为什么"最终答对"不能证明中间没走弯路？

提示：结果栏只记"最后对不对"——那"怎么走到的"记在哪里？

▾

知识背景

Agent 评测分两层：结果评测（终态是否等于目标态，τ-bench 就是比对对话结束后的数据库状态）与过程评测（每一步动作是否合理、是否违规）。只看结果会漏掉"过程错但终态对"，而真正的生产风险（越权、绕规矩、偶然成功）恰恰藏在过程里。

上一张卡片用 pass^k 量了稳定性。但"对"本身还需要拆开看——为什么最终答对，不能证明中间没走弯路？

因为终态只记录"结果"，不记录"怎么来的"：一次执行可能绕了远路、越了权限、靠偶然一步蒙对，而终态看起来一样。要定位问题，必须回看每一步动作与当时写进 context 的内容。就像看监控回放：只看最后东西到位了不够，要知道是哪一步差点出事。所以评测要分结果与过程两层。

🧮 第三笔账：结果评测 vs 过程评测

Step 1：两层各测什么

层	测什么	能发现	漏掉
结果评测	终态 = 目标态	任务是否完成	过程违规 / 绕路
过程评测	每步动作是否合理	违规、多余调用、越权	整体是否达成目标

算术无关的一条分工：结果评测管"做没做成"，过程评测管"做得对不对"——生产两者都要。

Step 2：定位"从哪一步开始歪"

步	动作	判定
1–7	查询、核对	正常
8	跳过政策校验直接改数据	越规（结果可能仍对）
9–10	收尾	正常

算术：一条 10 步轨迹，终态正确，但第 8 步违规——只做结果评测会判"通过"，做过程评测才能把这 1 步捞出来。定位到步，才谈得上修。

Step 3：过程评测的成本

方法	成本	适用
规则校验	低	可写死的约束（权限、格式）
人工抽检	高	高风险动作的抽查
LLM 当裁判	中	开放性步骤的合理性判断

算术无关的一条选型：先用规则拦硬约束（便宜、确定），再对开放式步骤用 LLM 裁判（需校准），高风险动作才上人工——三层配比，而不是全靠人。

🎯 关键认知

评测要分两层：结果评测回答"做没做成"，过程评测回答"做得对不对"。生产风险大多藏在过程里——所以判据是：先有终态比对，再能定位到具体是第几步、哪个动作出的问题。

AI 助教

👋 对轨迹评测有疑问？比如「怎么记录轨迹」「LLM 裁判怎么校准」？

说清你的任务与风险点，我帮你设计两层评测。

Agent 读到的外部文本，和你的指令在模型眼里有区别吗？

提示：Agent 读进来的外部文本，和你的指令，在模型眼里有区别吗？再想它会"照做"什么。

▾

知识背景

对模型来说，系统指令、用户问题、工具返回的网页内容都是同一套 token 序列——没有类型区分。这正是提示注入（prompt injection）的根源：一段外部文本里写着"忽略以上指令"，模型可能真的照做。MCP 规范也明确：工具描述不可全信，调用前应取得用户同意。

上一张卡片说过程也要能评。但比"评测"更靠前的是"别出事"——为什么必须先解决权限与安全？

因为Agent 会真的执行动作（改数据、发邮件、调接口），而它读进来的外部文本与你的指令在 context 里长得一模一样，无法从"这段来自网页"推出"它不是指令"。就像给小孩一把万能钥匙之前，得先装好锁、划好能进的房间——否则钥匙越强，风险越大。所以要先把威胁与防线摊开。

🧮 第四笔账：威胁与四道防线

Step 1：三类主要威胁

威胁	怎么发生
提示注入	外部文本被当成指令执行
越权调用	Agent 用了不该有的权限
数据外泄	把敏感信息写进外部请求

算术无关的一条分类：三类威胁的共性都是"模型分不清指令与数据"——防御必须做在系统层，而不是指望模型自己识别。

Step 2：攻击面有多大（示意）

项	数值
挂载工具数	10 个
每个工具每次返回外部文本	1 段
可被注入的入口	10 × 1 = 10 个

算术：10 个工具各返回 1 段外部文本，就有 10 个注入入口；只要 1 个被污染，整条链路都可能被劫持。攻击面随工具数线性增长。

Step 3：四道防线

防线	做法
数据 / 指令分区	用结构化标记隔开外部内容
最小权限	只给完成任务所需的权限
沙箱 / 人工确认	高风险动作沙箱执行、需用户同意
输出校验	对写操作做业务校验与审计

算术无关的一条总纲：四道防线是纵深防御——任何一道都不完美，但叠加后能把"一次注入"变成"难以造成不可逆后果"。

🎯 关键认知

安全的前提是承认一条事实：对模型来说，指令和数据都是 token 序列，没有类型之分。因此防御只能在系统层——分区、最小权限、沙箱、输出校验，四道一起上。

AI 助教

👋 对 Agent 安全有疑问？比如「提示注入怎么防」「权限怎么划」？

说清你的工具与数据敏感度，我帮你排优先级。

要让一个跑通的 Agent 上线，token 与延迟的账要怎么算？

提示：算一算一次任务要几次模型调用、多少 token；再想用户能等的延迟上限是多少。

▾

知识背景

Agent 的成本结构与单次问答完全不同：一次任务要多次模型往返、每次都要带上工具定义与历史（承第 20/21 课），所以 tokens 按步数放大；延迟则受"多轮串联"影响，用户感知的是尾部延迟（P95），而不是平均值。

上一张卡片把安全关进了笼子。但一个"又对又安全"的 Agent 仍可能被叫停——为什么成本和延迟能把它拦下来？

因为Agent 的每次任务都是多次模型调用叠加：一次问答约 200 token，10 步 Agent 每步重发一次历史，累计 200 × 55 = 11,000 token；延迟也随轮次串起来，尾部延迟被放大。就像预算有限的项目：方案再好，超支就只能砍。所以要把成本与延迟的账算清楚。

🧮 第五笔账：成本与延迟的来源

Step 1：一次 Agent 任务的 token 账

项	数值（示意：以单次 200 token、10 步为例）
一次问答输入	200 token
10 步任务、每步重发历史	200 × (1+…+10) = 200 × 55 = 11,000 token
倍数	11,000 ÷ 200 = 55×

算术（示意：以单次 200 token、10 步为例）：同一个问题，走 Agent 要 11,000 token，是单次问答的 55 倍（承第 20 课的平方增长口径；此处每步按 200 token 假设，与第 26 课"每步 2,000 token"是不同假设，两处都属示意、不能直接比对）。能力提升是真实的，账单也是真实的。

Step 2：用户感知的是尾部延迟

指标	含义	为什么重要
平均延迟	所有请求的均值	掩盖掉最慢的那批
P95 延迟	95% 请求都不超过它	用户体验由它决定
Agent 特点	多轮串联，尾部被放大	一步慢、整条慢

算术无关的一条提醒：Agent 的每一步都串在一条链上，所以单步的慢会被累加——盯平均延迟会低估用户的真实等待。

Step 3：三种降本手段

手段	做法	代价
缓存	复用相同前缀 / 相同子问题	需判断可否复用
模型路由	简单步走小模型，难步走大模型	需准确分类
减少步数	能一次调用解决就别上循环	可能牺牲能力

算术无关的一条排序：先减步数（最省）、再上缓存与路由——第 20 课"能简单就别复杂"在成本这一维同样成立。

🎯 关键认知

Agent 的成本与延迟不是"附带开销"，而是能否上线的一等约束：token 按步数放大到数十倍、尾部延迟被多轮串起来。降本的顺序是先减步数，再缓存与路由。

AI 助教

👋 对成本延迟有疑问？比如「怎么估一次任务多少钱」「P95 怎么降」？

说清你的步数与模型选型，我帮你估账。

为什么上线必须配一套发布门禁与回滚？

提示：想一想"演示能跑"和"线上稳定"最大的区别——线上出一次大事的代价是什么？怎么把风险控制住？

▾

知识背景

把前面五张卡片串起来，就是一套发布门禁：同一套私有评测集 + 同一提示 + 固定模型版本；质量、可靠性、安全、成本四线同时达标才放量；先灰度、再全量；任何一条越线就回滚。第 19 课的"发布门禁"在这里扩展到了 Agent 的轨迹与动作层。

前面五张卡片分别讲了分数、可靠性、过程、安全、成本。最后一步是把它们变成一道门——为什么上线必须配门禁与回滚？

因为"演示能跑"只证明一次；线上要面对千变万化的输入，一次越权、一次数据泄露的代价远高于拦住的收益。就像飞机起飞前的检查单：不是不信任飞行员，而是用固定流程把"偶发疏忽"变成"每次都拦住"。所以要把检查固化成门禁。

🧮 第六笔账：发布门禁怎么定

Step 1：门禁必须固定四件事

固定项	为什么
同一私有评测集	防污染、可比
同一提示 + 模型版本	排除混淆变量
同一判分口径	分数可跨版本比
同一 tokens 账	成本可回归

算术无关的一条原则：门禁的价值在于可比——四项只要有一项变，历史分数就失去参照。

Step 2：四条监控线同时达线

线	指标	越线动作
质量	任务成功率（完成率）	回滚
可靠性	pass^k、错误率、重试率	回滚
安全	越权 / 注入告警	立即停量
成本延迟	tokens / P95	限流或降级

算术无关的一条纪律：四条线是"与"不是"或"——任何一条不达标都不放量；安全线优先级最高，触发即停。

Step 3：灰度的节奏

阶段	流量	观察
灰度	5%	观察 1 个完整周期
扩量	50%	不复现问题才继续
全量	100%	保持回滚能力

算术：5% → 50% → 100% 的三段放量，让问题在"影响 5% 用户"时暴露，而不是在 100% 时才发现。灰度是把风险切成可控的小块。

🎯 关键认知

第四部分收口：从 Transformer 到 Agent 生产化，主线始终是同一件事——把"看起来行"变成"可验证地行"。Agent 的上线门禁是这条主线的最后一站：固定评测集 + 四线监控 + 灰度回滚，用可执行的检查代替"应该没问题"。这也是第四部分对"把模型造出来、再让它上得了线"这条路给出的回答——全课程还没结束：从下一课起进入第五部分 · 自主研究。

AI 助教

👋 对发布门禁有疑问？比如「灰度多久合适」「指标怎么定阈值」？

说清你的业务与风险容忍度，我帮你定门禁与回滚策略。