《深入理解 AI Agent》精读笔记 ⑥:Agent 的评估——没有评测就没有架构

📖 本文约 10297 字，阅读约需 38 分钟 | 共 8 个章节

本章定位

本章把 Agent 开发从感觉驱动改成评估驱动。没有固定任务、环境、指标和判断标准，就无法知道一次改动是真进步还是偶然成功。对数据科学家而言，本章把熟悉的"模型评估"扩展为系统评估：不只评输出，还要评过程、安全、成本与恢复能力。

1. 章节内容

工具调用型与人机交互型环境

工具调用型环境可以自动验证资源状态，例如文件是否修改、数据库记录是否更新；人机交互型环境还要模拟用户等待、澄清、拒绝、改变需求和人工接管。两类环境不能共用同一套成功判断。

仿真环境

仿真环境将外部世界建模为状态、动作和转移函数，使 Agent 可以低成本重复试错。它的风险是过于理想化，导致在仿真中成功、现实中失败，因此评估报告必须记录仿真与生产环境的差异。

LLM Judge 的校准

Judge 应输出分数、理由、引用证据和置信度；人工标注一批样本后计算一致率，检查是否偏好长答案、是否忽略事实错误、是否被生成模型的措辞影响。Judge 只能作为一个测量器，不能替代硬规则和人工抽样。

模型选型决策

模型选择应是多目标决策：在安全和正确率满足硬门槛后，再比较成本、延迟、上下文长度、工具调用稳定性和长任务恢复能力。不能只用单一平均分选模型。

评估系统由四部分组成：任务数据集、可控环境、运行轨迹和判断器。既要测工具调用型任务，也要测人机交互型任务；既要测最终结果，也要测过程安全、效率和恢复能力。

关键指标包括：完成率、事实准确率、工具调用正确率、错误恢复率、人工接管率、Token、延迟、成本和危险操作率。

配对比较与模型排名

原书还介绍用配对比较（Bradley-Terry 模型）替代绝对打分：对两个候选输出让裁判选"哪个更好"，从两两比较中拟合模型排名。它规避了绝对分数的尺度漂移，但前提是偏好可传递（如果 A>B 且 B>C 则 A>C），而人类偏好常违反传递性——见思考题 5。

评估驱动的模型选型与统计显著性

选型要同时看正确率、成本、延迟、工具稳定性和长任务恢复，且关键指标应给出置信区间而不是一个点估计（成功率标准误 SE = √(p̂(1-p̂)/n)，95% 区间 p̂ ± 1.96·SE）。

可观测性与内部评估基础设施

从外部 benchmark 走向生产系统，需要：消融基础设施（每个特性可单独开关，量化真实贡献）、AB 测试方法论（区分机制与目标）、双层特性开关系统（安全层 + 体验层）、提示词敏感性评估、隐私感知的分析。评估思维的转变：从"发布前测一次"到"生产流量持续评估"。

2. 深入理解

评估题必须对应真实失败模式。一个"能回答"的题不能证明 Agent 能执行；一个成功案例也不能证明系统稳定。评估集应覆盖正常、边界、冲突、工具失败、注入和高风险场景。

LLM-as-a-Judge 可以扩展评估规模，但必须使用明确 rubric、结构化输出、人工抽样和校准，不能把裁判模型当绝对真值。

📐 架构师注记 · 数据科学家 → 架构师的思维切换数据科学家评估"模型答得好不好"；架构师评估"系统敢不敢上线"。架构师要再加三层：过程安全（是否走了越权动作）、成本与延迟（能否撑住业务量）、可回滚（出问题能否止损）。评估从"学术指标"变成"发布门禁"——安全硬失败一票否决，平均分不能掩盖长尾。

术语与机制补漏

• Evaluation Environment：Agent 执行任务时所处的可控世界，包括工具、数据、初始状态和外部反馈；环境版本变化会影响评估结果。

• Benchmark / Dataset：用于比较版本的任务集合。高质量数据集不只是题目列表，还包含成功条件、硬失败条件、参考证据和难度标签。

• Trajectory：一次完整运行的消息、工具调用、参数、结果、状态变化和最终输出。评估 Agent 时必须同时看结果和轨迹。

• Rubric：把开放式质量判断拆成可检查维度的评分规则，例如事实、完整性、引用、安全和沟通。

• LLM-as-a-Judge：用另一个模型按 rubric 评价输出；它是可扩展的测量工具，不是绝对真值。

• Ablation（消融）：只移除或替换一个系统因素，观察性能变化，用于故障归因。

评估的核心是可比性：任务、环境、模型、工具、随机种子和判定器都应版本化，否则"提升"可能只是测试条件变化。

3. 架构设计方案：评估闭环

评估系统应与 Agent 运行时解耦，但复用同一工具接口和事件格式：

任务集 → 可控环境 → Agent Runtime → 轨迹采集  ├→ 规则判定  ├→ LLM Judge  └→ 人工抽样 → 指标看板 → 版本决策

每个任务保存输入、环境版本、模型版本、工具版本、完整轨迹和判定依据。发布门槛至少包含正确率、安全硬约束和成本预算，避免平均分上升却出现严重长尾事故。

📐 架构师注记 · 评估平台的成本模型评估本身有成本：Cost_eval = n(任务数) × m(重复次数) × (t·p + q·cost_judge) + Cost_env + Cost_storage。策略：先用规则判定筛掉机械样本，只对困难/高不确定样本调用昂贵 Judge；安全集与高风险集优先执行；样本不足时标记"不确定"，不允许自动放行。发布门禁要分层：安全硬失败 > 正确率下界 > 成本预算 > 长尾上限，逐层否决。

评估方式取舍

4. 关键取舍

📐 架构师注记 · 取舍表的使用方式评估设计是"成本与可信度"的平衡：迭代期用规则 + 公开集快速跑，发布期用轨迹 + 隐藏/对抗集严格把关。任何评估结论都要回答"样本量够不够"——置信区间过宽视为证据不足，不能自动放行。

5. 失败模式

• 测试集太简单，发布后才暴露边界问题。

• 只测最终答案，不测错误工具调用。

• 评估环境和生产环境差异过大。

• Judge 偏好长答案或漂亮表达。

• 每次换任务集，无法比较版本。

• 指标变好但成本、延迟或安全性恶化。

6. 思考题与参考答案

以下为原书第 6 章的 8 道深度思考题，星级为原书难度标记。参考答案为解读版，建议先独立作答再对照。

题 1（★★）：LLM-as-a-Judge 使用语言模型评估语言模型的输出。这种"自我评估"是否存在系统性盲区——比如模型可能一致地给某种风格的回答打高分，而这种偏好与人类评判不一致？如何检测和校正这种偏差？

结论

存在，而且是有规律的系统性偏差：位置偏好（总是偏爱第一个/最后一个）、长度偏好（偏爱长答案）、自我偏好（偏爱与自身风格相似的输出）、措辞偏好（被华丽表达影响而忽略事实错误）。检测靠人工校准：人工双标一批样本，计算 Judge 与人工的一致率与偏差方向；校正靠结构化 rubric + 反例 + 多判官投票 + 事实硬规则前置。

理由：Judge 是另一个模型，有自己的偏好先验。只要让它输出"分数 + 理由 + 证据位置"，并把事实性检查交给硬规则，就能定位和压制偏差。

设计目标

让 Judge 的分数可校准、可追溯，事实错误不被风格掩盖。成功标准：与人工一致率 ≥90%、偏差可归因、事实硬失败不由 Judge 放行。

方案

要求 Judge 输出等级、理由、证据位置和置信度；事实/引用/权限等硬维度由规则判定器先行裁决（硬失败直接定级，不走 Judge）；开放质量维度用多判官（≥2 个不同模型）投票 + 分歧时人工介入。定期用人工双标样本重算一致率与偏差，偏差超阈值触发校准（调整 rubric 或换 Judge）。

技术细节

Judge 输出 schema：score、rationale、evidence_span、confidence、dimension_scores。校准指标：一致率（Cohen kappa）、长度相关（分数与字数相关系数）、位置相关（候选顺序对胜率影响）、事实漏判率。抽样策略：分层抽样（按难度/答案长度），至少 30 个样本。

边界与取舍

• 多判官增加 token 与延迟；只在开放质量维度用，机械维度走规则。

• 人工标注昂贵：用"规则判定的高风险/争议样本优先人工"降低全量标注成本。

• 偏差会随模型版本漂移：校准不是一次性的，要周期性重跑。

验证

用 30 个以上人工标注样本计算一致率、Cohen kappa、长度偏差、事实漏判率；一致率目标 ≥90%；构造"长而无内容"与"短而正确"对照，Judge 不应偏好前者。

架构师要点

Judge 是"可扩展的测量器，不是裁判"：架构师把事实硬规则前置、主观质量走多判官、用人工校准持续纠偏。把 Judge 当真值，是评估系统最常见的隐性错误。

题 2（★★★）：评估数据集的"防泄漏"设计至关重要。但在开源生态中，benchmark 数据一旦公开，很快就会被纳入训练数据。这场"猫鼠游戏"有终局吗？设计一种从根本上抵抗数据泄漏的评估方法。

结论

没有绝对终局（任何公开数据最终都可能被吸收），但可以设计"失效期更长的评估"：不让"评估数据"与"训练数据"同质。三种抵抗思路：动态生成（程序化生成任务实例，每次变体不同，无法被背）、隐藏/私有集（永不公开，只有权威评估方持有）、时间切分（按时间冻结数据，未来数据天然不可见）。核心原则：评估的判定不是"见过这道题"，而是"能在未见过的变体上泛化"。

理由：猫鼠游戏的本质是"评估数据公开 → 被训练吸收 → 评估失效"。解法不是"藏得更久"，而是让"数据生成器"本身参与评估——只要每次生成变体，模型就永远无法背题。

设计目标

让评估结果抵抗"训练数据污染"，区分记忆公开样例与获得可迁移能力。成功标准：隐藏集下降 >5 个百分点即拒绝发布。

方案

1. 程序化变体：用规则/模板生成任务实例（改数字、改措辞、改实体），保持语义与难度等价，训练看不到同款。

2. 时间冻结隐藏集：按时间切分，过去数据公开、未来数据冻结，发布流水线禁止候选读取隐藏答案。

3. 对抗生成：根据模型在公开集上的表现，自动生成它做错的变体（动态困难度）。

4. 泄漏监控：检测模型在隐藏/变体集上的异常记忆（如对特定措辞敏感）。

技术细节

评估 manifest：data_source、freeze_time、variant_seed、visibility（public/private/heldout）、tuning_log。变体生成保持 semantic_equivalence（用规则保证，不是模型改写）。发布流水线：候选只能访问公开集；隐藏集由独立权限管理，结果以汇总形式呈现。

边界与取舍

• 动态生成的变体可能改变任务本质：需要人工抽样确认语义等价，否则评估的是另一件事。

• 私有隐藏集维护成本高、泄露风险仍在（内部人员）；程序化生成 + 时间切分可降低单点依赖。

• "抵抗泄漏"与"可复现"矛盾：动态生成使结果无法完全复现，需要种子版本化。

验证

模拟"公开集被训练吸收"：训练到公开集过拟合后，公开集提升但隐藏/变体集下降——门禁应拒绝发布；变体集下降超 5 个百分点即拒绝。

架构师要点

防泄漏评估的架构答案是"生成式评估数据"：把数据从静态资产变成程序化生成器。这是评估平台对抗污染的唯一可持续方向，也和持续进化的隐藏集体系天然契合。

题 3（★★）：Scale AI 的四准则（基于专家指导、全面覆盖、标准重要性权重、自包含评估）旨在消除评估的主观性。但某些任务维度（如"回答是否有帮助""语气是否恰当"）天然具有主观性。如何为这些主观维度设计可靠的 Rubric？

结论

主观维度的 Rubric 不能靠"给一个抽象定义"，而要行为化 + 锚定样例 + 分档定义：把"有帮助"拆成可观察的行为（是否回答了问题、是否提供了行动步骤、是否承认不确定性），每个档位配正/反例锚点，让不同裁判看到同样表现给出同分。

理由：主观维度的可靠性来自"判定标准的一致"而非"标准本身客观"。行为化描述 + 锚定样例，把"我认为好"变成"符合这些可检查条件的算这个档"。

设计目标

让主观维度的判定一致率（裁判间）达到可接受水平（如 ≥80%）。成功标准：双标一致率高、争议样本可归因到 rubric 的歧义处。

方案

1. 行为拆解：维度 → 若干可观察行为指标（如"有帮助"拆为"直接回答/行动步骤/边界声明/追问"）。

2. 锚定样例：每档 2-3 个典型样例（从真实评估中挑选并经过专家标注），裁判先校准再看分。

3. 分档定义：明确 1-5 档的行为边界（不是"好/中/差"的抽象词）。

4. 裁判协议：先看锚点，再按行为指标逐项打分，最后给综合分与理由。

5. 争议处理：双标不一致的样本进入讨论，发现 rubric 歧义则修订。

技术细节

Rubric 文档结构：dimension、behavioral_indicators[]、anchor_examples[]（每档）、boundary_notes。校准流程：标注者对锚点样例独立打分 → 不一致时讨论修订 → 通过校准后进入正式标注。质量指标：Cohen kappa、维度内一致率、争议样本的主题聚类（定位 rubric 缺陷）。

边界与取舍

• 行为化会损失部分"直觉质量"（有些好答案难以行为化）；接受这个损失换取一致性。

• 锚点会过时（模型风格演化）：周期性更新锚点样例。

• 主观维度本质上无法做到机器绝对一致：目标是"可接受的一致 + 争议可解释"。

验证

用 30 个"有帮助/语气"样本双标：kappa ≥0.6、一致率 ≥80%；构造边界样本（模板化但有用）确认 rubric 能区分；争议样本全部可归因到具体指标。

架构师要点

主观 Rubric 的工程诀窍是把"质量"翻译成"行为清单 + 锚点"。架构师把 rubric 版本化、纳入标注流程，让它成为可演化的评估资产，而不是一段口头描述。

题 4（★★）：τ-bench 通过模拟真实用户行为来评估 Agent。但模拟用户本身也是一个 LLM——它可能系统性地低估某些边缘场景（如情绪激动、表达不清的用户）。如何验证模拟用户本身的质量？

结论

把"模拟用户"当成被测对象来校准，而不是默认可信：用三组证据验证——覆盖度（模拟用户是否触达了真实对话的边缘场景）、保真度（模拟行为与真实用户分布的差异）、一致性（多次模拟是否稳定、是否被 Agent 的引导带偏）。不达标时注入边缘剧本（脚本化边缘用户行为）补充模拟。

理由：模拟用户的偏差会直接污染评估结论——如果模拟用户从不变通、从不生气，Agent 在"难缠用户"上的缺陷就不会暴露。

设计目标

让模拟用户能代表真实用户的分布，尤其是边缘场景。成功标准：边缘场景覆盖可度量、模拟与真实的差异可量化、评估结论不被模拟偏差主导。

方案

1. 覆盖审计：对照真实对话数据，统计模拟用户触发的事件类型分布（澄清、拒绝、情绪化、信息遗漏、模糊表达）是否有缺口。

2. 脚本化边缘：对覆盖不到的边缘场景，用预写剧本（edge_script）注入，不依赖模拟用户自发产生。

3. 保真度对比：用同一批 Agent 分别对模拟用户与真实用户（抽样）运行，比较行为分布差异。

4. 漂移监控：监控模拟用户被 Agent 引导后是否偏离角色（一致性检查）。

技术细节

模拟用户质量指标：edge_coverage（边缘场景命中数/目标集合）、behavior_distribution_kl（模拟 vs 真实的 KL 散度）、role_consistency（被引导后仍符合角色设定率）。边缘剧本：scenario、scripted_replies、response_policy（何时拒绝、何时情绪化、何时改变需求）。

边界与取舍

• 脚本化边缘用规则替代 LLM 自发生成，保真但覆盖有限；LLM 模拟灵活但偏差不可控——混合使用。

• 真实用户对比成本高、有隐私约束：抽样 + 脱敏。

• 模拟用户永远无法完全替代真实用户：保留"真实小流量评估"作为最终验证。

验证

用"情绪化、信息遗漏、改口、拒绝"四类边缘剧本：边缘覆盖达标、模拟与真实行为 KL 散度报告、被引导后的角色一致性 ≥90%；对覆盖缺口，能明确列出补了哪些剧本。

架构师要点

模拟用户是"评估环境的模型"，同样需要校准。架构师把它当被测组件治理（覆盖度 + 保真度 + 一致性指标），并保留真实流量兜底，防止评估在模拟的舒适区里失真。

题 5（★★）：配对比较（Bradley-Terry 模型）假设偏好是传递的（如果 A > B 且 B > C，则 A > C）。但人类偏好经常违反传递性。在 Agent 评估中，非传递偏好可能出现在哪些场景？这如何影响排名的可靠性？

结论

非传递偏好出现在多维权衡中：A 在正确率上胜 B、B 在速度上胜 C、C 在风格上胜 A——当比较基准随对比对象变化时，传递性就崩了。此外，边界相似的两个输出（A 与 B 难分伯仲，但都明显好/差于 C）也容易产生循环。影响：Bradley-Terry 拟合出的排名可能是"平均效应"而非真实序，小样本下排名不稳。

理由：传递性成立的前提是存在一个"全局效用轴"，而人类偏好是多维且上下文相关的，不存在单一轴。配对比较在大差距上可靠，在边界样本上失效。

设计目标

识别非传递偏好并降低其对排名的污染。成功标准：循环三元组可检测、排名置信区间报告、关键决策不被单一排名驱动。

方案

1. 循环检测：统计 A>B、B>C、C>A 的三元组比例，作为"非传递指数"。

2. 分维度配对：对正确率、成本、延迟等客观维度用规则判定（可传递），只对主观维度用配对比较，缩小非传递空间。

3. 成对一致率报告：不只输出排名，还输出每对胜率的置信区间，边界对标记"无显著差异"。

4. 人工介入：高价值决策（模型选型）对循环涉及的候选做人工详评。

技术细节

非传递指数：cycle_ratio = 循环三元组数 / 总三元组数，>5% 视为显著非传递。Bradley-Terry 拟合输出：每个候选的 score ± CI，并标注 significantly_better_than 列表（排除不显著对）。决策门禁：选型必须基于"显著差异"，不显著的对不算数。

边界与取舍

• 分维度虽好，但"综合体验"本身就是多维不可分的；承认不可分，用"显著差异 + 人工"兜底。

• 配对比较的样本量要求高（n 选 2 的组合数），成本随候选数平方增长；用轮询采样控制。

• 非传递在真实 Agent 评估中常见（不同用户偏好不同用户）：排名只能回答"平均意义上"，无法回答"对谁好"。

验证

构造含已知循环的三候选集：循环检测率 100%；对边界对，置信区间重叠时正确标记"无显著差异"；不把无显著差异的对当排名依据。

架构师要点

配对比较的可靠性取决于传递性假设。架构师要同时报告"排名"与"置信区间/非传递指数"，防止把统计噪声当优势——评估报告的可信度比漂亮数字更重要。

题 6（★★）：本章提出"观察 → 假设 → 实验 → 验证"的科学方法。但在实践中，Agent 的行为空间巨大，验证一个假设可能需要数百次评估运行。如何在有限计算预算下最大化评估的信息量？

结论

用实验设计原则压缩所需运行次数：先做分层定位（先用规则判定/低成本探针筛出问题域，再聚焦验证）、对照最小化（每次只改一个变量，避免多变量排列爆炸）、自适应采样（先小样本探索方差，再决定样本量）、失败优先（先验证高风险/高影响假设，再做低风险优化）。

理由：信息量 = 缩小假设空间的速度。与其平均地跑几百次，不如用"探针 → 聚焦 → 对照"把预算花在能区分假设的样本上。

设计目标

在固定预算（如 500 次评估）内最大化"假设验证的区分度"。成功标准：能正确归因的假设数量、收敛速度、预算利用率。

方案

1. 失败树优先：先按失败类型分层（上下文/工具/编排/模型），用低成本消融定位到层，再深入层内。

2. 顺序对照：单变量改动，前一个结果决定下一个实验，避免并行跑无关联排列。

3. 方差感知采样：先跑 10-20 次估方差，方差大则增加样本，方差小则提前停止。

4. 信息增益路由：预算分配给"最可能改变结论"的实验（贝叶斯式：先验不确定性大的假设优先）。

技术细节

实验清单 schema：hypothesis、layer、variance_estimate、expected_impact、cost、priority。停止规则：置信区间宽度达到阈值或预算耗尽；结论记录 statistical_power。对失败分析，用"故障归因矩阵"（失败样例 → 四层归因）指导下一轮实验。

边界与取舍

• 过度聚焦可能漏掉"组合效应"（两个小改动叠加才有效）；顺序实验留一部分预算做组合验证。

• 提前停止有误判风险：停止规则要保守（置信区间足够窄才停）。

• 信息量最大 ≠ 业务价值最大：优先验证影响面大的假设。

验证

用固定预算（如 500 次）对比"平均采样"与"自适应设计"两组：后者能验证的假设数量更多、归因正确率更高、预算利用率报告。

架构师要点

评估预算是稀缺资源，架构师用实验设计而非"跑得多就好"：失败树定位 + 单变量对照 + 方差感知采样，是"用最少运行得到最多结论"的方法论。

题 7（★）：本章的假设案例中，全局启用思考（H4）虽然提升了总体成功率，却因延迟和成本被否决，最终演化为条件化启用（H7）。哪些信号（任务描述特征、历史失败模式、运行中的不确定性）适合作为"是否启用思考模式"的路由依据？是否存在思考反而有害的 Agent 场景？

结论

适合做路由依据的信号分三类：任务特征（需要多步推理/工具链/规划的任务信号）、历史模式（同类任务过去的失败率、思考是否真的改善了结果）、运行中状态（当前步骤的不确定性、重试次数、工具结果异常）。存在"思考有害"的场景：超时敏感任务（思考延迟导致错过窗口）、简单任务（思考徒增延迟无收益）、需要即时反应的任务（实时对话、快速确认）。

理由：思考模式是有成本的（延迟、token），收益只在"需要推理的任务"上体现。路由的本质是"把思考预算花在值得的地方"。

设计目标

让"启用思考"成为可路由的策略而非全局开关。成功标准：启用思考的任务成功提升、成本可控、无负面场景误启用。

方案

ThinkRouter 接收任务特征、历史统计、运行时状态三类信号，输出 {thinking: enabled|disabled, level: brief|deep}。规则层：超时敏感/即时反应任务强制禁用；推理密集任务强制启用；其余按"历史收益"动态决策，并记录每次启用后的真实收益用于校准。

技术细节

信号输入：task_type、expected_steps、time_budget、history_stats（同类任务思考/不思考的成功率差）、runtime_signal（当前步骤置信度、重试数）。决策输出：mode、reason、confidence。收益校准：记录 thinking_enabled → outcome_delta，定期重算"哪些任务类型思考值得"。

边界与取舍

• 路由本身可能误判：把"未知任务"默认保守（启用浅思考），把已知简单任务明确禁用。

• 延迟敏感与推理需求可能冲突：用"流式输出思考 + 提前返回可确认部分"折中。

• 路由规则会漂移（模型能力变化后思考收益变化）：用收益反馈持续校准。

验证

构造"推理密集、超时敏感、简单即时、实时对话"四类任务：前两类正确启用/禁用、后两类不误启用、整体成本下降且成功不降、每次路由有 reason 可审计。

架构师要点

思考模式是成本可路由的特性，不是全局开关。架构师把"要不要思考"做成带反馈的路由决策，与 AB 测试、特性开关一脉相承。

题 8（★★）：τ-bench 的用户模拟采用了"渐进式信息透露"——不一次性提供所有信息，而是根据 Agent 的提问逐步透露。这种设计如何影响评估结果？如果模拟用户的信息透露策略与真实用户差异较大，评估结论还可靠吗？

结论

渐进式信息透露评估的是 Agent 的主动提问与信息收集能力——它在奖励"会问"的 Agent，惩罚"不问就猜"的 Agent。这会显著影响评估结果：同一个 Agent 在"全量信息"环境下可能成功、在"渐进透露"环境下因不提问而失败。如果模拟用户的透露策略与真实用户差异大（真实用户更主动/更被动、透露顺序不同），评估结论会失真。

理由：评估环境定义了"什么是成功"。渐进式透露把"信息获取"变成 Agent 任务的一部分，测的是检索式提问能力；这既是优点（更真实）也是风险（依赖模拟用户设计的忠实度）。

设计目标

让信息透露策略贴近目标用户分布，并量化其对评估结论的影响。成功标准：透露策略的差异影响可测量、评估结论可归因。

方案

1. 分层模拟：为不同用户画像配置不同透露策略（主动型全量透露、被动型按问透露、模糊型语焉不详）。

2. 敏感性分析：同一 Agent 在"全量/渐进/被动"三种模拟下运行，测量成功率差异，明确"信息收集能力"在结论中的贡献。

3. 真实校准：抽样真实对话统计透露模式（用户多久主动补充信息），反向校准模拟策略。

4. 报告披露：评估报告必须注明信息透露策略，避免结论被误读为"通用能力"。

技术细节

模拟配置：reveal_policy（eager | on_ask | reluctant）、reveal_order、max_info_per_turn。敏感性指标：delta(全量 vs 渐进)、question_requirement（需要多少次提问才能拿全信息）。真实校准：从真实对话统计 avg_reveal_turns、info_omission_rate，调整模拟参数。

边界与取舍

• 更真实的模拟成本更高（需要校准数据）；用敏感性分析决定"投入多少保真度"。

• 渐进式透露会把"不擅长提问"误判为"能力差"：报告要区分"信息已给但没用"与"没问所以没有"。

• 没有一种模拟能代表所有用户：分层 + 敏感性 + 披露是让结论可解释的最低要求。

验证

同一 Agent 在三种透露策略下运行：报告成功率差异与归因（信息收集 vs 推理）；抽样真实对话校准模拟参数；评估报告注明策略，避免跨策略比较。

架构师要点

模拟环境的"信息提供方式"是评估结论的隐藏变量。架构师要做敏感性分析 + 真实校准 + 报告披露，才能让"在模拟里跑出来的分数"对生产有预测力。

7. 架构师视角：Agent 评估平台

7.1 业务场景与系统边界

以客服 Agent 上线前的版本准入为场景。评估平台负责数据集、环境、轨迹、指标计算、统计置信度、人工校准和发布建议；业务 owner 负责价值指标和风险容忍度，生产监控负责真实流量验证。平台不把单次 Judge 分数当作事实，也不替安全审批和业务上线决策承担责任。

7.2 端到端生产架构

flowchartLRD[数据集注册/版本]-->E[实验编排器]E-->X[隔离评估环境]X-->T[轨迹与证据采集]T-->J[规则Judge/人工校准]J-->S[统计分析/置信区间]S-->G[发布门禁]G-->R[灰度与生产指标]R-->F[反馈集/回归集]E-->A[审计与成本账单]

业务成功率、用户满意度、人工接管率和单位任务成本由任务定义映射到系统指标；安全硬失败、越权和危险操作作为不可被平均值抵消的门禁。

7.3 非功能需求与降级

7.4 数据、权限与运营治理

数据集记录来源、授权、版本、分层、泄露检查、标注者和变更原因；隐藏集和对抗集由独立权限管理。轨迹中敏感字段脱敏，评估结果按项目和租户隔离，发布门禁、人工覆核和 Judge 分歧可审计。监控任务完成率、样本丢失、Judge 与人工一致率、置信区间宽度、成本、长尾失败和指标漂移；评估服务异常时禁止自动发布并通知 owner。

7.5 成本与容量估算

设任务数为 n、重复次数为 m、每次输入输出 Token 为 t、模型单价为 p、Judge 比例为 q，则 Cost_eval = n × m × (t × p + q × cost_judge) + Cost_env + Cost_storage。成功率近似标准误为 SE = sqrt(p_hat × (1-p_hat) / n)，95% 区间可写为 p_hat ± 1.96 × SE；并发容量按 workers = peak_tasks × runtime / window × headroom 估算。

7.6 ADR：多目标发布门禁

• 背景：平均成功率上涨可能掩盖安全退化、长尾失败或成本失控。

• 备选方案：单一总分；人工全量审核；硬安全门禁加统计指标和灰度。

• 决策：采用硬安全门禁、业务指标置信区间、成本预算、隐藏/对抗集和小流量灰度的组合门禁。

• 代价：评估周期和样本成本增加，部分候选会因不确定性延期。

• 回滚条件：安全硬失败、业务指标下界不达标、成本超预算或灰度异常时自动拒绝/回滚，并保留完整轨迹。

— END —基于李博杰《深入理解 AI Agent：设计原理与工程实践》v1.3 章节笔记整理