第10章　评估、可观测性与成本：用证据决定是否发布¶

状态：初学者展开试稿，待人工审阅（基于 Release Candidate 1 修订）本章定位：承接第9章的生产 Harness，说明怎样看清一次 Run、判断它是否成功、比较改动的收益与代价，并用质量门控制发布。安全治理的完整展开见第11章，持续改进见第12章。

本章回答的三个问题¶

怎样分别评估最终结果、执行轨迹、系统可靠性、成本与安全，而不是只看 Agent 的最后一句话？
Trace、Span、离线评估和线上监控怎样组成“发现问题—复现问题—防止复发”的闭环？
怎样公平比较模型、Prompt、RAG、工具或 Harness 改动，并决定放量、暂停或回滚？

本章沿用一个退款案例：

用户说：“订单 O-2048 重复扣款，请退回重复的那一笔。退款前给我看金额；超过我的审批上限就转人工，不要重复退款。”

这不是一个真实客户、真实订单或真实金额。它只是贯穿本章的教学示例，用于说明评估结构。案例中的系统必须查询订单权威状态，验证重复扣款，生成预览，按真实身份与政策取得审批，再使用稳定幂等键执行退款，最后重新查询退款状态。Agent 说“退款成功”不构成完成证据。

证据类型说明

本章严格区分三类话语：教学示例只解释机制；标为“本书建议”的内容是需要在具体系统验证的工程建议；只有明确指向保存记录、论文或标准的内容才是限定条件下的实测结论。本章没有重新运行实验，不虚构成功率、时延、费用或通用发布阈值。文中示例阈值均为待项目填写的占位条件，不是行业标准。

5分钟速读¶

可观测性回答“这次运行发生了什么”；评估回答“它是否满足事先定义的标准”。日志很多，不等于做对了。
Agent 要分五层看：Outcome（结果）、Trajectory（路径）、System（系统行为）、Economics（成本与性能）和 Safety（安全）。五层不能用一个平均分相互抵消。
一条 Trace 表示一次任务的完整追踪；一个 Span 表示其中一次模型调用、工具调用、审批或验证。记录版本和关联关系，才能比较与归因。
验证优先级通常是：权威环境终态 → 程序规则与不变量 → 专家标签 → 经人工校准的 LLM Judge。模型裁判不能授予权限，也不能单独证明退款事实。
质量门由便宜、确定的检查逐级走向真实流量：Schema/Unit → Smoke → Offline Evaluation → Online Evaluation。Smoke 只证明最小链路可工作。
公平比较要尽量固定任务、初始状态、工具、预算和评分器；随机系统要重复运行，报告样本量、失败类型和不确定性，而不是挑最好的一次。
成本要看每成功任务总成本，其中包括模型、工具、基础设施、人工处理和失败代价；便宜但经常失败的方案可能更贵。
发布按离线回放 → 影子流量 → 金丝雀 → 有界放量 → 全量推进；每一步都要在事前写明停止与回滚条件。
线上失败经脱敏、确认与首错归因后回流为私有回归用例，形成评估闭环。

一、先分清：可观测性不是评估¶

1.1 可观测性：从外部证据还原内部运行¶

可观测性（Observability）是通过日志、指标和追踪数据，回答系统内部发生了什么。比如退款 Run 是否调用了订单查询、是否等待审批、在哪一步超时、使用了哪个 Prompt 版本、消耗了多少 Token。

日志（Log）通常记录一个离散事件，例如“策略网关拒绝退款”；指标（Metric）是可聚合的数值，例如每分钟请求量、p95 延迟和失败率；追踪（Trace）则把一次任务跨模型、工具、队列和数据库的步骤连接起来。三者互补，不能只收集一长串文本日志。

可观测性给的是“体检材料”，不是诊断结论。一条 Trace 显示工具返回 HTTP 200，只能说明请求得到响应，不能证明退款金额正确或资金已经到账。

1.2 评估：按照标准判断是否做对¶

评估（Evaluation）是把一次或一组运行与预先定义的成功条件比较。退款任务至少要判断：

是否只退重复扣款的正确金额；
是否先展示预览，并在需要时取得有效审批；
是否没有重复退款或泄露他人订单；
是否在预算和时限内完成；
是否能用退款记录和权威订单状态证明完成。

验证器（Verifier）是执行这些检查的程序、工具或人工步骤。数据库断言、单元测试、政策规则、专家复核都可以是验证器。模型的自我陈述不是独立验证。

1.3 二者怎样闭环¶

生产 Run
  → Trace / Metric / Log 记录发生了什么
  → 发现失败或异常样本
  → 脱敏、确认、首错归因
  → 加入离线回归集
  → 修改一个可控变量并比较
  → 通过质量门后渐进发布
  → 新生产证据继续回流

第9章负责让 Run 可恢复、可取消、可回滚；本章负责证明这些机制实际工作。第11章进一步规定谁能查看 Trace、数据保留多久以及怎样审计。

二、Trace与Span：给一次任务画出证据树¶

2.1 首次术语解释¶

Trace（追踪）是一项用户任务从入口到终态的完整因果记录。Span（跨度）是 Trace 中一个有开始和结束的工作单元，例如一次模型调用、一次检索、一次政策检查或一次退款 API 调用。父子关系说明“谁触发了谁”。OpenTelemetry 定义了厂商中立的 Trace 和 Span 模型；生成式 AI 字段仍在持续演进，实现时应固定所采用的语义约定版本。⁵

退款案例可以表示为：

Trace: refund run R-2048
├── Span: authenticate user
├── Span: model classify request
├── Span: tool read order
├── Span: policy verify duplicate charge
├── Span: model draft refund preview
├── Span: approval check
├── Span: tool execute refund
└── Span: verifier read authoritative status

这幅图是教学示例，不是某个平台的截图。关键是根 Trace 对应一个业务任务，而不是每次模型调用各自成为无法关联的孤岛。

2.2 最少记录哪些字段¶

本书建议每条 Trace 至少能够关联：

类别	建议字段	用途
身份与关联	`run_id`、租户、任务类型、父 Span	找回同一次任务；租户字段应受访问控制
配置版本	模型路由、Prompt、Schema、工具、政策、数据集版本	解释“哪一套系统”产生结果
行为	Span 类型、开始/结束、结果码、重试、Fallback、审批状态	重放路径与定位首错
性能与成本	延迟、输入/输出/缓存 Token、工具费用、估算单价版本	分析瓶颈与成本
证据	参数摘要或哈希、Artifact 引用、验证结果、外部操作 ID	复核动作与最终状态
错误	类型化错误码、是否可重试、脱敏诊断	聚合故障而不泄漏秘密

哈希可以证明两个载荷是否相同，但不能让未知内容自动可信。若审计必须读取原载荷，应把它放入受访问控制、可过期的证据存储，而不是普通日志。

2.3 安全边界：能记录不等于应该记录¶

Prompt、工具参数和工具结果可能包含个人信息、支付资料、访问令牌和间接提示注入。Telemetry（遥测数据，即系统自动产生的运行记录）应遵循最小采集：

不记录密码、API Key、会话 Cookie、银行卡完整信息；
默认对姓名、地址、订单备注等敏感字段脱敏或令牌化；
让开发者、客服、审计员各自只有必要的读取范围；
为原始载荷、派生指标和安全审计设置不同保留期；
记录导出、查看和删除行为；
Telemetry 上报失败不能让退款绕过政策，也不应无限阻塞主任务。

凭据由执行环境的秘密管理器代管，模型、评估数据和 Trace 只记录凭据引用或提供者名称，不能保存秘密值。生产 Trace 回流评估集前还要再次脱敏，并确认用途与保留规则。

三、五层评估：不要让一个总分遮住事故¶

3.1 Outcome：最终目标是否完成¶

Outcome（结果）回答“用户要求的现实状态是否实现”。退款案例应查询支付或订单权威系统，确认正确交易对应一笔正确金额的退款，并保留外部退款 ID。

最终文本很礼貌但没有退款，是 Outcome 失败；确实退款但最后一句话措辞一般，Outcome 可以成功而语言质量较差。两者应分别记录。

3.2 Trajectory：到达结果的路径是否允许¶

Trajectory（轨迹）是观察、模型决策、工具调用、审批和验证组成的步骤序列。轨迹评估不要求所有成功 Run 走完全相同的路，而是检查：

必须发生的事件，例如执行前验证重复扣款；
禁止发生的事件，例如查询其他租户订单；
部分顺序，例如预览和审批必须先于执行；
工具与参数是否正确；
是否出现重复调用、无进展循环或不安全重试；
失败后是否选择了合同允许的恢复路径。

“最终退对了钱，但先执行、后补审批”仍是轨迹与安全失败。对高影响任务，不应允许 Outcome 分数抵消越权动作。

3.3 System：Harness是否可靠履约¶

System（系统）层评估模型之外的行为：超时、队列、Checkpoint 恢复、幂等、取消、并发隔离、Fallback 和熔断。可以注入工具超时或进程重启，检查：

恢复后是否保留同一个 Run 与幂等键；
结果未知时是否先查询，而不是盲目再退款；
取消后是否停止新动作并核对已发生副作用；
旧 Worker 是否被 Fencing 拒绝；
Fallback 是否仍遵守同一政策。

这些测试与第9章的控制面逐项对应。

3.4 Economics：质量、延迟和成本是否值得¶

Economics（经济性）回答“完成任务所用资源是否符合业务约束”。延迟（Latency）是从请求到某个结果所需的时间；p50 表示一半样本不超过该值，p95 表示约 95% 样本不超过该值。尾延迟不能用平均值替代。

应同时观察端到端延迟、各 Span 延迟、吞吐、Token、缓存命中、外部 API 费用、人工接管和失败重试。指标必须带任务类型和版本，否则简单查询与复杂退款混在一起会误导判断。

3.5 Safety：是否始终在授权边界内¶

Safety（安全）层检查越权调用、审批绕过、敏感数据泄漏、提示注入、错误对象和不可接受副作用。安全规则可以是一票否决项：一次未授权退款不能被“平均质量提高”抵消。

本章只说明怎样测量这些边界；威胁建模、身份、审计和治理责任在第11章展开。

四、把一条任务写成可重复的评估用例¶

4.1 五个组成部分¶

一条可复现任务通常需要：

输入：给 Agent 的请求与允许提供的信息；
初始环境：订单、支付状态、用户身份和政策版本；
工具与权限：可调用接口、测试账号和副作用隔离；
成功与禁止条件：结果、轨迹、安全和预算断言；
执行协议：轮数、超时、终止、重置和评分方式。

下面是教学 YAML，不是可直接部署的配置：

id: refund-duplicate-017
input: "退回订单 O-2048 的重复扣款"
initial_environment:
  fixture_version: payments-fixture-v3
  order_id: O-2048
identity:
  actor: synthetic-user-17
  permissions: [read_own_order, request_refund]
success_assertions:
  - authoritative_refund_status == completed
  - refund_count == 1
required_events:
  - preview_before_execute
  - approval_if_policy_requires
forbidden_effects:
  - refund_non_duplicate_charge
  - read_other_tenant_order
budgets:
  model_calls: PROJECT_DEFINED_LIMIT
  wall_time: PROJECT_DEFINED_LIMIT
reset: restore_fixture_snapshot

PROJECT_DEFINED_LIMIT明确表示团队要依据风险、容量和实测填写，而不是照抄本章的数字。

4.2 环境必须能重置，副作用必须隔离¶

离线评估不应对真实客户退款。使用合成数据、测试租户、服务虚拟化或可重置沙箱；测试凭据只拥有测试资源的最小权限。评估执行器不得获得生产写权限。

若某项外部行为无法安全模拟，先运行 Dry-run（只生成预览而不执行），再由授权人员审批专门的受控测试。不要为了采样重复执行真实付款、删除或发送。回滚脚本也不是免审批理由：有些外部消息已被阅读，有些资金动作只能补偿，不能真正撤销。

4.3 数据集从哪里来¶

本书建议把数据集分层，而不是只放正常样例：

核心集：人工确认、长期稳定的代表任务；
能力集：困难或新功能任务；
失败集：已确认的生产事故、用户纠正和坏轨迹；
对抗集：提示注入、越权请求、歧义、长上下文和预算压力；
保留集：不参与日常调参，用于发现过拟合；
新鲜集：定期新增，降低数据污染与环境漂移影响。

每条用例要保留来源、脱敏过程、所有者、加入原因和版本。用于训练或调参的数据与最终验证集要分开；公开 Benchmark 可用于粗筛和学习设计，不能替代私有业务集。

五、验证器：先问环境，再问模型裁判¶

5.1 验证优先级¶

权威环境最终状态
→ 可执行断言、Schema和业务不变量
→ 来源与引用核验、轨迹规则
→ 领域专家标签
→ 经人工校准的LLM Judge
→ 未校准的主观印象

能用数据库状态证明退款时，不要让 LLM 猜。能用程序检查“审批先于执行”时，不要让 Judge 阅读一段摘要后凭感觉评分。

5.2 Rubric：把“好不好”拆成可判断条件¶

Rubric（评分量表）把开放质量拆成具体维度和档位。例如退款回复可分为：金额是否与证据一致、是否说明到账的不确定性、表达是否清楚、是否泄露无关数据。每一项应给出可观察标准和边界案例。

必要项、加分项和否决项要分开。金额错误或捏造退款 ID 可设为否决项；措辞不够简洁不能与其等价。

5.3 LLM-as-a-Judge能做什么，不能做什么¶

LLM-as-a-Judge（以大模型作裁判）是让模型按照 Rubric 评价开放输出或轨迹。它适合辅助判断表达清晰度、覆盖度和开放式报告质量，但有位置偏差、长度偏差、自家模型偏好、随机波动和被候选文本注入的风险。已有研究表明，强模型裁判在某些设置下能与人类偏好达到较高一致性，同时也存在位置、冗长和自增强偏差；这支持“校准后辅助使用”，不支持把它当成普遍真值。⁶

本书建议：

先用领域专家标注一批代表与边界样本；
按维度比较 Judge 与人工标签的一致和分歧；
固定并记录 Judge 模型、Prompt、Rubric 和输出 Schema 版本；
配对比较时随机交换候选顺序，审计回答长度相关性；
重要结论复核分歧样本，必要时使用不同来源的第二裁判；
把被评内容当作不可信数据，禁止其中的指令改变 Rubric；
不让 Judge 裁决事实、授权、审批或高风险动作。

Judge 版本变化也可能改变历史分数。升级前应在同一人工校准集上重跑，而不是把新旧分数直接拼接。

六、四级质量门：从便宜检查走向真实流量¶

本节对应模式 P16“四级质量门”。³

6.1 L1：Schema与Unit¶

Schema Test检查输入输出形状；Unit Test（单元测试）检查一个小模块的确定行为。这里应覆盖工具参数、授权函数、状态转移、幂等键、预算计数和成本计算。使用 Fake Model 与 Fake Tool 可减少随机性，但它不能证明真实提供者可达。

6.2 L2：Smoke¶

Smoke Test（冒烟测试）是部署后对最小关键路径的快速检查，名称来自“设备通电后先看是否冒烟”。它可以证明服务可达、最小模型调用成功、Schema 可解析、Trace 能上报；不能证明复杂任务质量、安全性或长期稳定性。

真实 Smoke 若调用外部服务，会产生网络请求和可能的费用。使用最小权限测试账号，不把 Key 写进命令、代码或日志；生产写工具保持禁用。完成证据应包括运行 ID、版本、时间、退出状态和 Trace 链接，而不是一句“看起来正常”。

6.3 L3：Offline Evaluation¶

Offline Evaluation（离线评估）在隔离、可重置环境中运行固定数据集。它用于比较模型、Prompt、上下文、RAG、工具或架构。每次报告要写清数据集版本、环境、预算、模型配置、评分器、失败样本和未运行项目。

离线评估适合安全回放，却可能与生产任务分布不同。因此“离线通过”是进入下一门的资格，不是全量上线证明。

6.4 L4：Online Evaluation¶

Online Evaluation（线上评估）观察真实流量中的业务完成、用户纠正、人工接管、延迟、成本和安全拦截。线上标签可能有偏差：用户没点踩不等于成功，人工接管也可能是正确安全结果。应抽样人工复核，并把权威业务状态与用户反馈分开。

线上实验涉及真实主体和数据。必须经过组织要求的隐私、安全和业务审批；实验分桶不改变授权，用户不能因为进入实验组而获得额外权限。

七、公平比较：一次改动究竟有没有变好¶

7.1 先建立基线，只改变一个主要变量¶

基线（Baseline）是当前可重复方案。比较新模型时固定 Prompt、工具、预算和数据；比较 Prompt 时固定模型；比较 Harness 组件时尽量只开关该组件。这叫控制变量。

消融实验（Ablation）是删除或关闭一个组件，观察系统发生什么变化。模型替换实验（Model Swap）则固定 Harness，只替换模型。前者定位某组件的贡献，后者帮助判断瓶颈更像模型能力还是 Harness 设计。两者都只能支持当前任务分布和实验条件下的结论。

7.2 Agent有随机性，要报告不确定性¶

同一任务可能因采样、服务路由、搜索结果或环境时序得到不同轨迹。因此至少报告：

样本量、任务版本和重复次数；
随机性设置及可用时的 Seed；
成功数/总数，而不只给百分比；
配对任务的胜负变化和失败分类；
延迟与成本分布，至少不要只报平均值；
置信区间或其他明确的不确定性表达；
实际模型、提供者、日期和环境。

置信区间（Confidence Interval）是根据样本表达估计不确定性的范围，不是“真实值必定在此”的承诺。小样本下，一次多成功或少成功就可能大幅改变比例。涉及多项指标和多个候选时还要警惕只挑显著结果。

7.3 Pass@k与连续可靠性不是一回事¶

Pass@k问“同一任务尝试 k 次，是否至少一次成功”，适合探索能力上限。连续可靠性问“多次是否每次都成功”，更接近退款、部署等不能靠挑最好一次的业务。原始书稿用二者提醒读者：重试到成功会隐藏失败、放大成本，并可能重复副作用。¹

对于会写外部状态的任务，只能在隔离、可重置且幂等的环境中重复采样；不能拿真实客户反复试验。

7.4 从总分下钻到首个关键错误¶

失败归因（Failure Attribution）是找出轨迹中第一处使任务偏离的关键错误，并附证据。退款最后报“余额不足”可能只是后果，真正首错可能是较早选错交易 ID。

建议分类起点是 Context、Retrieval、Model、Tool、Policy、Runtime、Environment 和 Verifier。分类不是为了把责任都推给模型，而是为了选择最可控的修复载体。修复后同时运行触发失败的边界集和原本正常的保留集。

八、成本：优化每个成功任务，而不是一枚Token¶

8.1 成本从哪里来¶

Agent 的总成本至少可能包含：

模型输入、输出、推理与缓存费用；
搜索、浏览器、数据库、语音等工具费用；
沙箱、队列、数据库、向量库和 Telemetry 存储；
人工审批、复核和接管；
失败重试、补偿、事故与用户流失代价。

供应商价格、缓存规则和计费字段会变；应保存价格表版本和真实 Usage 回执，不从架构图推算费用。

8.2 两个有用但不同的指标¶

平均任务成本 = 总成本 / 发起任务数
每成功任务成本 = 总成本 / 成功任务数

第二个指标把失败和重试纳入结果。若没有成功任务，分母为零，应该报告“不可计算”并单列总成本，不能写成零成本。还应同时看安全否决；靠越权提高“成功率”没有经济意义。

8.3 常见优化及其验证¶

本书建议把优化当成待验证假设：

简单、低风险节点路由到较小模型；
保持稳定前缀以利用供应商支持的缓存；
过滤无关上下文，把大对象保存为 Artifact；
只并行真正独立的任务，并设并发上限；
用确定性验证器替代不必要的 Judge 调用；
限制无进展循环、重试和子 Agent 扇出；
为单 Run 设置 Token、工具、时间和金额硬预算。

每项优化都要重测 Outcome、Safety 和尾延迟。压缩上下文可能降费，也可能漏掉退款限制；小模型可能便宜，也可能带来更多重试和人工接管。

仓库的成本实验保存了一次固定八轮退款场景的 2×2 记录，比较稳定前缀与上下文压缩；其数字只适用于相应模型、定价、缓存行为和实验环境，不是通用节省比例。读者可从保存的 Trace 离线复算，但不能把离线重算误称为新的模型运行。⁷

九、发布质量门：在真实影响扩大前停止坏版本¶

9.1 五个阶段¶

Offline Replay
  → Shadow
  → Canary
  → Bounded Rollout
  → Full Rollout

离线回放：在隔离环境重跑核心集、失败集、对抗集和保留集。
影子流量（Shadow）：新版本读取复制输入但结果不展示、不写生产；应从权限层硬禁写，而不是 Prompt 里说“不要写”。
金丝雀（Canary）：只让经过批准的小范围真实流量使用新版本。
有界放量：按任务类型、租户或风险逐步扩大，并保留旧版本。
全量：满足观察窗口和门槛后扩大；仍继续监控漂移。

9.2 门槛必须在看结果前写好¶

发布门（Release Gate）是决定候选版本能否进入下一阶段的明确条件。项目应按风险和基线填写，不应照抄通用数字：

release_gate:                 # 教学示例
  dataset_version: private-eval-v12
  outcome: "not below approved project threshold"
  critical_unauthorized_effects: 0
  p95_latency: "within approved SLO"
  cost_per_success: "within approved budget"
  fallback_rate: "within measured baseline band"
  rollback_owner: on_call_role
  previous_bundle: agent-bundle-v41

SLO（服务水平目标）是团队对某项服务指标设定的目标，例如特定任务的 p95 延迟上限。门槛应按任务和影响等级分层。安全硬失败、重复退款和审批绕过通常应立即停止，而不是等待平均指标恶化。

9.3 回滚要回滚“整套执行配置”¶

回滚可能涉及代码、Prompt、模型路由、工具 Schema、政策、检索索引和数据迁移。发布前要保存兼容的旧版本、特性开关、Owner 和操作手册。

回滚只能阻止后续影响，不能自动撤销已经发生的退款或消息。已发生副作用要按外部系统状态决定是否补偿，并保留审批和审计证据。完成回滚的证据包括：流量已切回、版本已核对、进行中 Run 已处理、关键指标恢复、外部副作用已盘点，而不是“部署命令返回成功”。

十、贯穿案例：从一次失败到安全发布¶

10.1 定义成功¶

团队先把“回复用户”改写成五层合同：正确重复款被退一笔；预览和必要审批先于执行；进程重启不重复退款；成本与延迟在项目预算内；无越权、泄漏和审批绕过。

10.2 记录Trace并发现问题¶

生产 Trace 显示某次 Run 在退款 API 超时后换了新幂等键重试。最终两笔退款都显示成功。Outcome、Trajectory、System 和 Safety 均失败；问题不能因为回复文本友好而被平均掉。

这是教学故障，不是仓库实测。首错是“结果未知时生成新键重试”，而不是最后一步的“用户收到两条通知”。

10.3 沉淀回归用例¶

团队脱敏订单与用户信息，在可重置支付模拟器中建立任务：第一次退款调用执行成功但返回超时；Agent 必须用原幂等键查询状态，不得创建第二笔退款。验证器检查退款计数、事件顺序和外部 ID。

10.4 修复并过门¶

修复放在 Harness，而不是只向模型追加“不要重复”的 Prompt。候选版本依次通过 Unit、Smoke 和 Offline；影子环境没有生产写权限。进入 Canary 前，由支付 Owner 批准范围、监控和回滚计划。任何重复退款或未授权副作用触发硬停止。

10.5 证明完成¶

发布记录关联候选与旧版本、评估集版本、每层门禁结果、审批人、Canary 范围、停止原因（若有）、回滚验证和遗留风险。一次绿灯仪表盘不是完整证据链。

十一、失败模式与反例¶

11.1 反例一：只看最终回答¶

表现：Agent 说“退款成功”，文本 Judge 给高分。

问题：没有查询权威状态，也可能退错或重复。

控制：先验证环境终态，再检查轨迹和语言。

11.2 反例二：把Smoke当质量证明¶

表现：服务能调用模型并返回合法 JSON，于是全量上线。

问题：Smoke 没覆盖复杂任务、攻击、恢复和业务结果。

控制：继续通过 Offline 和受控 Online 门。

11.3 反例三：Judge就是“标准答案”¶

表现：同一模型家族既生成又评判，并决定是否退款。

问题：偏差可能同源，而且 Judge 没有授权和权威业务状态。

控制：确定性验证优先，Judge 经人工校准且只处理语义维度。

11.4 反例四：只报平均分¶

表现：总体成功率提高，却不展示高风险任务和失败类型。

问题：小群体越权或尾延迟会被平均值淹没。

控制：按任务与影响分层，报告计数、分布、否决项和失败样本。

11.5 反例五：比较时同时换一切¶

表现：新模型、新 Prompt、新工具和新预算一起上线。

问题：即使分数变化，也无法归因。

控制：建立基线，尽量一次改变一个主要变量；无法拆分时明确承认比较的是整套 Bundle。

11.6 反例六：只优化Token单价¶

表现：换便宜模型后单次调用费用下降。

问题：重试、失败和人工接管可能上升。

控制：比较每成功任务总成本，并同时看 Outcome 与 Safety。

11.7 反例七：Trace原样进入评估集¶

表现：复制生产 Prompt、Cookie和订单数据供开发者调试。

问题：扩大隐私与凭据泄漏范围。

控制：最小采集、脱敏、用途审批、ACL、保留期和访问审计。

11.8 反例八：影子版本仍持有写权限¶

表现：界面不展示影子答案，所以认为没有影响。

问题：后台工具仍可能退款或发消息。

控制：权限层禁写，使用模拟器或可重置测试租户。

11.9 反例九：发布后才决定何时回滚¶

表现：指标变差后临时争论“是否严重”。

问题：决策受沉没成本和选择性解释影响。

控制：发布前登记门槛、Owner、旧版本和副作用处置方案。

11.10 反例十：线上失败自动改Prompt并立即发布¶

表现：一条点踩触发 Agent 自我修改。

问题：反馈可能错误、被注入或只适用于单个用户。

控制：先确认与归因，生成最小候选，在失败集和保留集上独立验证，再渐进发布。

十二、实施检查清单¶

成功定义与数据¶

[ ] 每类任务有可检查的 Outcome，而不是依赖 Agent 自述。
[ ] Outcome、Trajectory、System、Economics、Safety 分开记录。
[ ] 用例包含输入、初始状态、权限、断言、禁止副作用、预算和重置方法。
[ ] 核心、能力、失败、对抗、保留和新鲜数据按需分层并版本化。
[ ] 生产样本已脱敏，有用途、Owner、访问控制和保留期。

Trace与验证器¶

[ ] 一个业务 Run 有可贯通入口、模型、工具、审批和验证的根 Trace。
[ ] 模型、Prompt、Schema、工具、政策、数据和价格版本可追溯。
[ ] 凭据和不必要的敏感载荷不会进入普通日志或评估集。
[ ] 权威终态、程序断言和轨迹规则优先于 LLM Judge。
[ ] Judge 有具体 Rubric，并与人工标签校准；分歧样本会复核。

比较与成本¶

[ ] 有明确基线，任务、环境、工具、预算和评分器尽量保持一致。
[ ] 报告样本量、成功数/总数、重复设置、不确定性和失败分类。
[ ] 不把一次运行、最好一次或公开榜单写成稳定业务结论。
[ ] 记录端到端及 Span 延迟、Token、缓存、工具、基础设施与人工成本。
[ ] 同时看平均任务成本、每成功任务成本、尾延迟和安全否决。

权限、审批、回滚与完成证据¶

[ ] 离线和影子环境没有生产写权限；测试凭据只访问测试资源。
[ ] 真实线上实验经过所需的业务、隐私和安全审批。
[ ] 高影响动作的批准绑定主体、对象、金额、版本和有效期。
[ ] 质量门覆盖 Unit、Smoke、Offline 和 Online，且每层能力边界清楚。
[ ] 放量前已登记停止条件、回滚 Owner、旧 Bundle 和兼容方案。
[ ] 回滚后核对流量、版本、进行中 Run 与已发生副作用。
[ ] 发布结论附运行 ID、配置版本、评估报告、审批和未解决风险。

知识检查¶

可观测性与评估分别回答什么问题？为什么 Trace 完整仍不能证明退款正确？
Trace 与 Span 是什么关系？为什么一次任务不应拆成互不关联的模型调用日志？
为什么最终只退款一笔，仍可能判定任务失败？
Smoke Test 能证明什么，不能证明什么？
什么时候适合用 LLM-as-a-Judge？它绝不能独自裁决哪些事项？
为什么公平比较新模型时要固定 Harness、任务、预算和评分器？
Pass@k 为什么不适合作为高影响退款任务的唯一可靠性指标？
平均任务成本下降，为什么每成功任务成本仍可能上升？
影子流量不展示结果，为什么仍必须从权限层禁写？
为什么回滚到旧模型不一定完成了回滚？
一条生产失败怎样安全地变成回归用例？
为什么应定位首个关键错误，而不是只记录最后一个报错？

参考解释¶

第1题：可观测性说明发生了什么，评估判断是否符合标准。 Trace 可以完整记录一次错误退款；只有对照权威状态、权限与成功条件，才能判断它错误。

第2题：Trace 是一次任务的完整追踪，Span 是其中一个工作单元。 父子与关联关系让人知道模型调用由哪一步触发、工具结果又影响了哪一步，否则无法重建因果链和首错。

第3题：路径和边界也属于成功。 Agent 可能先退款后审批、读取他人订单，或因首次重复退款后又补偿回来；最终数量正确不能抹去越权和副作用。

第4题：Smoke 证明部署可达、最小调用和基本观测链工作。 它不能证明真实任务质量、攻击抵抗、恢复、成本稳定或长期可靠性。

第5题：开放式表达、完整性或风格难以程序化时，可用经人工校准的 Judge 辅助。 它不能独自证明业务事实、授予权限、代替真实审批或批准高风险动作。

第6题：这样分数变化才更可能来自模型差异。 同时改变工具和预算会产生混杂因素；若无法拆分，应把结论限定为整套系统比较。

第7题：Pass@k 只要求多次中至少一次成功，会隐藏其他失败。 退款的每次失败都可能有现实副作用，不能靠挑最好的一次交付。

第8题：便宜模型可能增加失败、重试和人工接管。 总成本除以成功数后，分母下降可能使每成功任务成本反而增加。

第9题：不展示文本不等于不执行工具。 影子 Agent 若有写权限，仍可能退款、发信或改数据库，因此要由执行层硬禁写。

第10题：执行配置还包括 Prompt、工具、Schema、政策、索引和数据迁移。 已发生退款也不会因切模型自动撤销，需要核对并按政策补偿。

第11题：先确认失败，按授权用途脱敏，保留来源并定位首错；再在隔离可重置环境中重建初始状态、断言和禁止副作用。 用例进入版本化失败集，而不是原样复制生产秘密。

第12题：最后报错常是级联后果。 找到最早使任务偏离的决策，才能把修复放到 Context、工具、政策或 Runtime 的正确边界，并用最小回归任务验证。

小结¶

Agent 评估不是给最后一段文字打分，而是建立一条从任务合同到完成证据的链。可观测性用 Trace、Span、日志和指标说明发生了什么；评估再从 Outcome、Trajectory、System、Economics 和 Safety 五层判断是否可接受。权威环境状态和确定性验证优先，LLM Judge 只在开放语义维度经人工校准后辅助使用。

可靠迭代还需要可重置的数据集、公平对照、不确定性报告和首错归因。成本优化关注每成功任务总成本，并与质量、安全和尾延迟一起看。候选版本依次经过 Unit、Smoke、Offline 和 Online 门，再通过影子、金丝雀和有界放量扩大影响；权限、凭据、审批、停止条件、回滚和完成证据都必须在发布前设计。

本章把第9章的生产 Harness 变成可测、可比较、可发布的系统。下一章将在此证据基础上进一步讨论安全威胁、治理职责和审计边界；第12章再说明失败证据怎样进入受控的持续改进循环。

来源与证据¶

原始书稿第7章系统讨论评估环境、数据集、确定性验证器、Rubric、LLM-as-a-Judge、失败归因、成本、统计、可观测性与消融实验。本章重新组织为蓝皮书的五层评估与四级质量门，并删除无法在此处完整复核的泛化数字。¹
第9章“生产 Harness”提供 Run、Checkpoint、幂等、Fencing、预算、版本、发布和回滚边界；本章只增加“怎样证明它们工作”，不改变其职责定义。²
P16给出 Schema/Unit、Smoke、Offline、Online 四级质量门；P17给出生产失败回流回归集的闭环。³⁴
OpenTelemetry Trace 规范用于 Trace/Span 的基础术语；具体生成式 AI 属性需要按采用版本核对。⁵
Zheng 等人的 MT-Bench/Chatbot Arena 论文用于支持 LLM Judge 存在系统偏差、需要校准这一限定主张；它不证明 Judge 可替代业务真值或授权。⁶
配套成本实验的 README、sample_trace.json 和代码可复核一次特定退款场景的保存记录。本章不转录其数字为通用结论。⁷
配套轨迹验证器把结果、过程与开放质量分层，并用专家标签校准；这是本章“分层验证”的仓库实例。⁸

原始书稿，../../book/chapter7.md，尤其是“评估指标”“评估环境”“自动化评估方法”“失败归因”“Agent系统的成本分析”“评估结果的统计显著性”和“Agent的可观测性”。 ↩↩
蓝皮书，09-production-harness.md。 ↩
模式卡，../patterns/P16-four-level-quality-gates.md。 ↩↩
模式卡，../patterns/P17-failure-regression-loop.md。 ↩
OpenTelemetry, Traces. https://opentelemetry.io/docs/concepts/signals/traces/ （访问日期：2026-09-22）。 ↩↩
Zheng, Lianmin, et al. “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.” NeurIPS 2023 Datasets and Benchmarks Track. https://arxiv.org/abs/2306.05685 ↩↩
配套实验，../../chapter7/agent-cost-analysis/README.md；离线输入记录见 ../../chapter7/agent-cost-analysis/sample_trace.json。 ↩↩
配套实验，../../chapter9/trajectory-verifier/README.md。 ↩

第10章 评估、可观测性与成本：用证据决定是否发布¶