智能体评估

目的

我们如何判断一个智能体已达到足以发布的水平？当它失败时，又该如何确定是哪个部分出了问题？

一个能够强制执行预算限制、在崩溃后继续运行并从错误动作中恢复的运行时，仍然无法判断任务是否完成。智能体可能在删除了本可发现其缺陷的测试后报告成功，可能在回填任务半途停止时返回正常状态，也可能在一次运行中通过基准测试，却在下一次运行中无法完成同一个任务。对于只统计退出码和响应时间的仪表盘，这些运行看起来都很健康。评估以完成任务的证据取代活动信号。这种证据是环境中经过验证的变化，需要在足够多的独立任务和重复运行中加以度量，以区分真实改进与采样噪声，并关联到能够说明每次失败究竟由模型、运行框架还是环境造成的追踪记录。同一套机制还决定新模型、提示词、工具或运行框架版本是否可以发布，并确认哪些轨迹成功完成了任务，而这正是后续能够安全地从这些轨迹中学习的基础。用 H·S·A 的术语来说，评估是运行时检查自身闭合性的方式：根据所验证的变化判断状态，根据相对于预算消耗的轮次和美元金额判断时域，并通过审计智能体采取的每个动作判断权限。

学习目标

• 制定四层评估契约（语法层面的模式有效性、执行不变量、环境状态变化量以及运行约束合规性）
• 利用临时沙箱、确定性模拟服务和重置耗时低于一秒的运行框架，设计封闭隔离的任务环境
• 比较作为轨迹评分方法的结果验证器、过程评分与步骤级指标，以及经过校准的 LLM 评判器
• 根据预算相同的重复试验，计算置信区间、所需样本量和 pass\(^k\) 可靠性
• 将轨迹记录为 OpenTelemetry 跨度图，并选择能够保留每次失败的尾部采样策略和敏感信息脱敏策略
• 利用确定性追踪重放和反事实试验场消融，开展取证式事件复盘
• 通过离线、影子和序贯金丝雀阶段，依据复合门控条件评估候选发布版本
• 构建基于实证的可观测性与评估控制平面，将基准测试门控、分布式追踪和生产遥测统一到自动化运行框架中

多层评估契约

脚手架带来的加速效应不断累积，突破即使模型无限快也会触及的 \(1.54\times\) 上限。

考虑一个部署在企业计费基础设施中的自主余额对账智能体。标准应用性能监控（APM）仪表盘显示其运行健康状况正常：服务可用性达到五个九（99.999% 的响应为 HTTP 200），工具执行延迟低于 100 毫秒（\(T_{\text{tool}} = 78\text{ ms}\)）。然而，随后的财务审计发现，该智能体错误地发放了 $450,000 的重复余额贷记。对因果执行图进行取证分析后，故障机制得以揭示：智能体在查询中央账本数据库中的既往交易标识符时，遇到了短暂的套接字读取超时。工具封装层捕获了网络异常，并试图维持韧性，因此返回空字符串，而没有向上传递运行故障。基础模型看到空的交易列表后，推断此前没有发生过任何发放。它反复执行余额贷记工具，直到下游支付网关返回 HTTP 200 响应。对于操作系统进程监控器、网络套接字和 APM 监控器而言，每个系统组件都在无错误地运行；对于事务状态机而言，智能体却违反了复式记账的核心不变量。

在这起事件中，运行时并非看不到任何相关信息。每次工具调用、每个空结果和每笔重复贷记都记录在某处，然而团队关注的信号中，没有一个能够表明任务已经失败，也没有任何记录能够说明原因。我们将这种状况称为绿色仪表盘谬误。工具调用可以正常退出，但其任务却失败，这正是 Fail-Plausible 故障模型 所描述的失败却貌似正常的行为，而 五部分契约规范 的五部分契约已经定义了成功的含义。前面章节构建的运行时具备动作执行能力（智能体沙箱），记录每个事件（持久执行），并协调智能体团队（多智能体协同），但这些机制都无法判断任务是否成功。

本章要回答的问题是：什么样的证据能够发现这一故障。在发布前，这类证据是经过验证的环境状态变化，并且需要在足够多的独立任务上进行测量，以区分真实收益与采样噪声。在生产环境中，这类证据则是一条因果追踪记录，沿着同一条轨迹贯穿模型调用、工具、沙箱和协作智能体，从而将此类故障或停滞的多智能体流水线归因于导致问题的组件。因果与统计发布证据（原则 15）要求这两方面兼备，本章将构建生成这两类证据的机制。

表 1 的四层评估契约对不变量闭合（原则 不变闭包原则）的两个方面都进行了测量。语法有效性、执行不变量和约束合规性检查运行时在模型下层强制实施的边界，而状态差量验证则提供任务成功的端到端证据。监督运行框架并不将遥测视为被动的日志摄取，而是通过四个严格有序、不可相互替代的层次来评估候选轨迹。任何较低层次的失败都会立即使较高层次的评估失效，防止合成或损坏的数据污染可观测性流水线。

表 1: 分层评估契约谱系：验证目标、测量机制、确定性边界以及常见的静默故障模式。

层次	验证目标	测量工具	常见的静默故障模式
第 1 层：语法有效性	序列化封装、字段模式、类型签名	JSON Schema 验证器、AST 解析器、类型检查器	JSON 结束括号被截断、字符串浮点数被强制类型转换、凭空生成的参数键
第 2 层：执行不变量	操作规范、进程正常退出、非空输出	OS 退出码（exit == 0）、RPC 状态码、stderr 监视器	异常被吞掉并转换为错误字符串、非幂等的重复重试、未处理的套接字超时
第 3 层：状态差量验证	物理环境变更（\(\Delta S = S_{\text{post}} - S_{\text{pre}}\)）	封闭隔离的测试框架、git diff 验证、数据库事务断言	语法上看似合理却无法通过单元测试的代码变更、数据库部分写入、遗留的临时文件
第 4 层：约束合规性	资源预算（\(T_{\max}, C_{\max}, N_{\max}\)）和安全边界	token 计量器、挂钟计时器、步骤计数器、eBPF / 沙箱过滤器	无限推理循环、token 预算耗尽、未经授权的文件系统或网络访问尝试

基础层——语法有效性——在动作被分派到环境之前强制确保结构合规。模型输出的每个候选动作都必须能够依据已注册的类型模式进行确定性解析。验证会检查必需键是否存在、数据类型是否与目标函数签名匹配，以及枚举参数是否属于允许的集合。这项验证在运行时边界同步执行，在格式错误的输出仍处于内存暂存区时将其拦截，避免其到达外部套接字或文件系统。

第二层——执行不变量——验证工具执行期间是否遵守操作规范。除了简单的进程完成（exit == 0）之外，工具调用还必须满足基本的系统不变量：操作必须在重试时保持幂等性，以确定性方式处理套接字超时，捕获非空输出流，并隔离内存故障。如果工具包装器拦截内部异常并将其转换为对话文本，就会违反这一层的要求，因为它用非结构化噪声污染了观测上下文，而没有向监督器传递可据以采取行动的结构化错误码。

第三层——状态差量验证——测量智能体对环境造成的真实物理变化：

\[\Delta S = S_{\text{post}} - S_{\text{pre}}\]

其中，\(S_{\text{pre}}\) 和 \(S_{\text{post}}\) 分别表示轨迹执行前后环境的持久物理状态，包括文件系统树、git 提交、关系数据库表或网络配置。智能体的主要交付物通常并非其中间思维链 token，而是这种环境变更。在软件维护领域，Jimenez 等人 (2024年) 在 SWE-bench 中确立了这一原则：评估智能体提出的代码库修改时，不检查其对话解释或提交说明，而是将原始 git diff 应用于干净的代码仓库检出副本，并运行自动化测试框架，其中既包含从失败变为通过的单元测试（验证缺陷已修复），也包含持续通过的单元测试（验证未引入回归）。如果补丁无法编译、引入回归或未通过目标验收测试，无论模型的语言表达多么出色，或其报告的置信度多高，评估得分都严格为零。

Definition 0.1: 已接受的任务

验收通过的任务 是指这样一条轨迹：其最终环境状态在任务所要求的闭环证据级别上满足任务完成标准，且整条轨迹均未超出契约规定的任何预算上限。

1. 重要性：验收通过的任务是成功率、可靠性以及每个验收通过任务的成本所采用的计数单位。一次运行即使通过了验证器，只要超出预算，就不能通过验收。
2. 区别：经验证的成功仅表示最终状态通过了验证器。验收还要求满足预算和证据级别，因此，通过可见测试并不意味着一个契约要求通过封存测试的任务能够通过验收。
3. 常见误区：因为智能体报告成功、传输层返回成功状态，或评判模型对对话记录给出高分，就将一次运行计为验收通过。这些方式均未观测环境。

Definition 0.2: 状态增量验证

一种实证性的可观测性与评估机制，严格依据执行前后持久化环境状态的差异（\(\Delta S = S_{\text{post}} - S_{\text{pre}}\)）来衡量智能体轨迹的有效性。状态增量验证评估的是隔离的文件系统树、数据库预写日志或封存的回归测试套件，而非中间推理词元或自行报告的完成情况，从而保证任务正确性的客观判定独立于对话的流畅程度。

可观测性监测全部三类暴露：验证状态、限定时域并审计权限。

最后一层是约束合规性，负责强制执行物理资源限额和操作边界。一条轨迹即使正确修改了状态，若消耗的计算资源没有上限，仍然违反操作契约。约束评估将轨迹总延迟 \(T_{\text{task}}\)、将 轨迹时长核算 在轨迹的 \(N\) 个步骤上求和得到的时长核算恒等式，以及词元总消耗量 \(C_{\text{task}}\) 限定在固定的操作上限内：

\[T_{\text{task}} = \sum_{t=1}^N \left( T_{\text{model}, t} + T_{\text{tool}, t} + T_{\text{wait}, t} + T_{\text{runtime}, t} \right) \le T_{\max}\]

\[C_{\text{task}} = \sum_{t=1}^N \left( c_{\text{prompt}, t} + c_{\text{completion}, t} \right) \le C_{\max}\]

其中，轨迹步数 \(N\) 受 \(N \le N_{\max}\) 限制，以终止无限推理循环。同时，安全检查验证执行始终处于指定的沙箱命名空间内、遵守能力令牌的约束，且从未尝试提升权限。这四个层次共同观测 H·S·A 暴露面 的全部三类暴露：状态增量验证检查轨迹对状态做了什么，步数预算和实际耗时预算限定其时域，而安全检查则确认其从未超越自身权限采取行动。

基于模型的评分器不属于这一契约。通过提示让第二个模型依据评分准则对对话记录评分，衡量的是表达上的可信度。Zheng 等人 (2023年) 记录了这类评判模型的三种系统性失真：偏好自身模型家族输出的自我偏好偏见；偏好冗长详尽的回答而非简洁正确回答的冗长偏见；以及成对比较中的位置偏见。评判模型也只能读取词元。它无法检查文件系统、查询预写日志或运行回归测试套件，因此自身无法提供任何额外的闭环证据级别（闭合证据等级）。因此，评分器仅提供参考意见，其适用范围限于文档可读性、代码是否符合惯用写法或是否契合用户意图等开放式标准，因为这些标准无法构建算法判定器。即便在这些情形下，其评分也必须使用标注者间一致性指标（例如 Cohen 的 \(\kappa\) 或 Spearman 的 \(\rho\)）对照人类专家的真实标准进行校准，并且必须向其提供有事实依据的证据（状态增量 \(\Delta S\) 和执行日志），而非原始对话记录。

粗略估算 0.1: 评估四层任务契约

设想一个自主数据库管理员智能体，其任务是对一个分片 PostgreSQL 集群执行在线模式迁移：为 (tenant_id, created_at) 添加复合索引，目标为包含 12,000,000 条记录的 audit_events 表，回填非空的 status 列，并依据服务级别目标（SLO）验证查询延迟。宿主监督器在自动化评估框架下运行该智能体，并从契约的四个层次检查所产生的轨迹。

在第 1 层（语法有效性）中，智能体发出初始工具调用载荷，该载荷序列化为 JSON 对象：run_migration(shard_id="shard-04", ddl_statement="...", backfill_batch_size=5000)。运行时在内存托管区中拦截该载荷，并将其分派给 JSON Schema 验证器。该模式确认 shard_id 可解析为已知的集群端点，ddl_statement 可解析为有效的 SQL 字符串且不存在未配对的定界符，backfill_batch_size 是处于允许范围 \([100, 10000]\) 内的整数。验证在 \(0.4\text{ ms}\) 内完成。第 1 层记录为无条件通过。

在第 2 层（执行不变量）中，运行时在容器化会话内将 DDL 命令分派给数据库引擎。Shell 包装器拦截执行过程，并报告操作系统返回码为 exit == 0。然而，检查捕获的标准错误流（stderr）后发现了一项操作违规：WARNING: concurrent transaction lock acquisition timed out after 30000ms; falling back to non-concurrent CREATE INDEX。工具包装器的设计目标是报告进程完成情况；它捕获了进程退出事件，并将返回码 0 传递给监督器，却未标记该警告。实际上，非并发回退操作获取了排他表锁（AccessExclusiveLock），锁定这张包含 1200 万行的表长达 \(41.2\text{ seconds}\)，使 \(1{,}840\) 个传入的客户端查询进入排队状态，并导致连接池饱和。尽管进程以零退出码完成，第 2 层的执行不变量仍遭到破坏。

在第 3 层（状态增量验证）中，评估框架量化持久性的环境变更 \(\Delta S = S_{\text{post}} - S_{\text{pre}}\)。该框架检查关系目录（pg_indexes），并验证复合索引是否存在。随后，它执行一套自动化验证测试，该测试套件由五条确定性的 SQL 断言查询组成。测试套件在第四条断言处失败：

SELECT count(*) FROM audit_events WHERE status IS NULL;
-- Expected: 0
-- Returned: 3,580,000

虽然 DDL 语句已执行，但后续回填事务在第 8,420,000 行遭遇了内部语句超时。由于智能体未将回填操作封装在带有保存点的原子事务中，操作提前终止，导致 3,580,000 行的 NULL 状态未初始化。智能体在最终对话回复中宣称：“在线模式迁移已成功完成。全部 12,000,000 条记录均已回填，复合索引已创建，全程零停机。” 一名基于模型的自动评判器审查了智能体的文本回复，并就清晰度和流程正确性给出了 5/5 的评分。然而，实测状态增量验证揭示了灾难性的部分写入，最终基于真实结果的任务得分为 0。

在第 4 层（约束合规性），运行时依据严格的运行上限计量轨迹的资源消耗：实际经过时间的延迟上限 \(T_{\max} = 120.0\text{ s}\)、词元消耗上限 \(C_{\max} = 25{,}000\text{ tokens}\)，以及最大步数 \(N_{\max} = 10\text{ steps}\)。遥测记录显示：

\[T_{\text{task}} = \sum_{t=1}^6 \left( T_{\text{model}, t} + T_{\text{tool}, t} + T_{\text{runtime}, t} \right) = 142.6\text{ s} > 120.0\text{ s} \quad (\text{FAIL})\]

\[C_{\text{task}} = 14{,}200\text{ prompt tokens} + 3{,}150\text{ completion tokens} = 17{,}350\text{ tokens} \le 25{,}000 \quad (\text{PASS})\]

\[N_{\text{steps}} = 6 \le 10 \quad (\text{PASS})\]

由于表锁争用，该轨迹超出最大延迟阈值 {python} EvaluatingFourLayerTaskContract.overrun_s_str（超出比例为 {python} EvaluatingFourLayerTaskContract.overrun_pct_str）。

系统核算：智能体实现了无可挑剔的语法有效性（第 1 层），并生成了一段礼貌、令人安心的叙述，说服了模型评判器。然而，它锁定了生产环境中的表，违反了运行执行不变量（第 2 层）；通过未完成的批处理执行破坏了持久数据库状态（第 3 层）；并超出了实际经过时间的延迟预算（第 4 层）。通过对话遥测或进程退出码评估自主智能体，会将运行失败认证为生产成功；只有明确的多层契约才能强制保障正确性。

如果自主智能体评估的真实结果基础是物理状态增量 \(\Delta S = S_{\text{post}} - S_{\text{pre}}\)，评估基础设施就必须保证 \(S_{\text{pre}}\) 干净、不可变，并且在各次实验运行中完全可复现，同时保证 \(S_{\text{post}}\) 的捕获不受并发任务的串扰或泄漏影响。在生产工程中，让数千条会改变状态的智能体轨迹在真实环境或隔离不充分的环境中运行，会引发灾难性的测试污染、不可复现的外部网络依赖，以及破坏性副作用。系统工程师如何构建交互式评估环境，使其提供完全的容器化隔离、确定性的模拟服务桩，以及亚秒级文件系统重置，同时避免高昂到难以承受的存储和虚拟化开销？这一架构要求决定了封闭隔离评估训练场的设计。

封闭隔离评估训练场

当自动化评估运行框架启动并行智能体轨迹，使其访问真实外部服务时，评估框架会因自身的运行副作用而崩溃。一个负责调试开源仓库中某个问题的智能体，可能向 GitHub 发出数百次未限流的 API 请求，触发 IP 级速率限制，导致后续基准测试任务出现误报失败。另一个智能体被授予 root shell 权限，以便在共享宿主容器中安装缺失的 C++ 编译器，它可能对 /var/log 执行递归删除，或修改全局环境变量，从而破坏所有并发工作线程的工作空间。更糟糕的是，一个被要求修复数据库模式迁移的智能体，可能针对持久化测试实例执行真实的 DROP TABLE 命令，使所有下游评估都必然发生运行时异常。

评估自主智能体需要一个交互式、封闭隔离的执行训练场，保证完全的状态隔离、确定性的网络交互，以及亚秒级环境重置。 在传统软件工程中，单元测试在自包含进程中执行，隔离很容易实现，状态也很少在测试进程结束后继续存在。在智能体系统中，被测实体是一个无特权的随机策略，它会在数十轮连续交互中与有状态环境进行交互。如果底层环境无法在每次试验前重置为数学上完全相同的初始状态 \(S_{\text{pre}}\)，基准测试结果就会成为由执行顺序和网络抖动造成的不可复现产物。

系统评估中的封闭隔离性意味着执行环境完全封闭：外部网络交互被拦截，文件系统从已知的密码学状态开始，并发评估工作进程之间不会相互泄漏内存、锁或磁盘块。

为何静态基准不适用于自主系统

机器学习界多年来一直使用 MMLU、GSM8K 和 HumanEval 等静态问答基准评估基础模型。这些基准通过单次前向传播或孤立的代码生成步骤，评估形如 \(P(Y \mid X)\) 的条件概率分布。例如，在 HumanEval 中，模型接收 Python 函数签名和文档字符串，输出自回归补全结果，再由宿主运行器评估是否满足 candidate_function(*test_inputs) == expected_outputs。模型在运行时不具备自主行动能力：它无法检查编译器诊断信息，无法查询外部文档，无法运行部分程序来观察中间运行时行为，也无法通过迭代改进来修正语法错误。

自主智能体打破了这一静态评估范式。智能体运行 形式化系统定义 闭环，其中，动作 \(a_t\) 从策略 \(\pi_\theta(a_t \mid s_t, h_t)\) 中采样得到，并改变底层操作系统、浏览器或分布式服务的物理状态。环境以物理状态转移 \(S_{t+1} \sim \mathcal{T}(S_t, a_t)\) 作出响应，并产生观测 \(o_{t+1}\)，该观测被追加到智能体的上下文历史 \(h_{t+1}\) 中。智能体的性能不仅取决于其内部的参数化知识，还取决于其应对部分可观测性、从失败的工具调用中恢复、管理长时程依赖图，以及整合多轮轨迹中的诊断反馈的能力。

评估此类系统需要一个交互式评估训练场。智能体训练场源于强化学习中具有显式动作空间和观测空间的环境形式化定义，它将整个操作系统运行时——包括 POSIX 文件系统、进程表、网络栈和包管理器——封装到交互式运行框架中。评估运行框架不对智能体文本的流畅程度评分；它衡量的是终止状态 \(S_{\text{post}}\) 是否满足任务验收契约所定义的操作不变量。

由于智能体会与实际运行的二进制程序和系统守护进程动态交互，静态模拟框架无法胜任。如果智能体执行 apt-get install -y libpq-dev，或尝试使用 python setup.py build_ext --inplace 重新编译 CPython 扩展，训练场就必须提供真实的操作系统环境，能够执行真实的 ELF 二进制程序、链接动态库并处理系统调用。如果训练场试图使用启发式文本模拟来伪造这些交互，智能体的推理闭环就会退化为钻模拟运行框架空子的练习，而非解决底层工程问题。

封闭隔离训练场的三大架构支柱

构建一个能够执行数千条不可信且会改变状态的智能体轨迹的交互式训练场，需要解决三项基本系统挑战：跨租户状态泄漏、外部非确定性，以及高昂到难以接受的环境重置延迟。实施这些边界所需的系统拓扑详见 图 1。

图 1: 封闭隔离评估训练场架构：由硬件强制实施的 Firecracker microVM 边界、分层写时复制存储隔离、结合确定性本地代理模拟的 eBPF 网络过滤，以及带外真值验证判定器。

如 图 1 所示，物理评估宿主机运行裸机 Linux，并利用 KVM 虚拟化，在不到 5 毫秒内启动一次性 Firecracker microVM 沙箱。在客户机边界内，智能体运行时以 PID 1 运行，受严格的资源配额约束（固定绑定的 vCPU 和 4 GB RAM 上限），同时从确定性 PRNG 种子供给接口获取熵，以保证轨迹可重放。存储架构将状态拆分为不可变的只读基础根文件系统（rootfs.ext4）和可写的 tmpfs 写时复制（CoW）增量层，使环境能够通过 blkdiscard 在不到 50 毫秒内完成重置，且无需磁盘写入。同时，虚拟 TAP 网络接口配合 eBPF 过滤规则，丢弃所有发往公共广域网的出站流量，并将出站 HTTP 请求重定向至确定性的本地模拟代理。轨迹结束后，只有候选产物补丁（git diff HEAD..worktree）会穿过隔离边界，进入隔离的带外验证器区域；隐藏的验收测试套件在该区域内针对原始无修改的代码仓库快照执行，输出防篡改的二元评估判定 \(V(\tau) \in \{0, 1\}\)。

临时沙箱隔离

每项评估任务都必须在一次性、隔离的沙箱中执行，以防止状态相互干扰。在评估智能体执行软件仓库任务的能力时，沙箱必须确保文件修改、临时编译产物、运行中的后台守护进程以及被修改的系统配置文件都受到严格隔离。如果工作进程 1 修改了 /etc/hosts，或遗留了一个未终止且绑定到端口 5432 的后台 Postgres 进程，工作进程 2 就绝不能继承这一受污染的环境。

为此，评估监督程序将每个沙箱实例都视为一次性实例。底层物理机器或宿主机虚拟机监控器会长期运行，以摊销硬件初始化成本，而客户机执行边界则针对单条任务轨迹动态创建，并在任务终止后立即销毁。写入指定评估工作区之外的任何数据都会在虚拟块层被丢弃。

确定性模拟服务

在软件工程或管理场景中运行的自主智能体经常会发出外部 HTTP 请求：从 PyPI 获取软件包依赖、通过 GitHub REST API 查询议题、查询 AWS 元数据端点，或向 Slack 发送通知 webhook。允许评估沙箱直接与真实的第三方端点通信，会给评估流水线引入严重的故障模式：

• 第三方服务中断与速率限制： 并行运行 100 次智能体评估，可能在几分钟内耗尽组织的 GitHub 或 Jira API 速率限额，导致整轮基准测试提前中止。
• 外部状态漂移： 如果智能体的任务是解决开源仓库中的某个议题，并且它通过互联网查询真实仓库，那么外部维护者在实验运行中途推送的一次提交就会改变智能体的上下文，破坏跨时间的可复现性。
• 灾难性副作用： 负责云基础设施编排的智能体可能调用真实的 AWS API，创建实际资源、产生真实费用，或删除生产基础设施。

封闭式训练环境实施严格的网络隔离。沙箱部署在内部数据包过滤器之后，该过滤器阻断所有通往公共互联网的出站流量。任务所需的外部服务由本地高吞吐量 HTTP 模拟桩替代。这些模拟桩采用两种模式之一运行：录制与回放或有状态仿真。在录制与回放模式下，每个匹配已知特征（方法、路由、查询参数、载荷哈希）的 HTTP 请求，都会返回一份在基准测试整理阶段采集、预先录制且通过密码学机制固定的响应。在有状态仿真模式下，轻量级本地守护进程（例如模拟 Git 服务器、本地 S3 仿真器或本地缺陷跟踪系统）会在任务持续期间维护临时内存状态，使智能体能够执行真实的状态变更操作（例如创建 Git 提交、发起拉取请求、上传构建产物），而无需访问外部网络。

通过写时复制实现亚秒级重置框架

交互式评估的主要运行瓶颈是环境重置延迟。如果一个评估套件包含 \(N = 2,500\) 个不同任务，而重置操作系统、编译器工具链和仓库状态需要完整重启虚拟机，或对一个 15 GB 磁盘映像执行顺序目录复制，那么评估流水线将有超过 95% 的实际耗时用于等待存储 I/O。

为使大规模智能体评估在计算上可行，封闭式训练环境依赖文件系统或块设备层面的写时复制（Copy-on-Write，CoW）存储虚拟化。评估运行框架会准备一个标准基底层，其中包含预先编译好的操作系统、语言运行时、软件包缓存以及干净的仓库检出副本。任务下发时，监督程序会创建一个临时 CoW 快照（例如使用 OverlayFS 上层目录、Btrfs 子卷快照或 device-mapper 精简配置卷）。

智能体以底层存储总线的原始速度直接读取不可变的标准基底层。当智能体写入或修改文件时，存储驱动程序只在临时上层中分配新的物理块。轨迹结束且判定器评估完由此产生的状态增量后，监督程序只需卸载叠加层并丢弃上层元数据，即可销毁沙箱；无论底层基础映像的大小如何，这一操作都能在几十毫秒内完成。

粗略估算 0.2: 存储 I/O 与重置成本摊销

考虑一个具有 \(W = 64\) 个并行工作槽位的评估集群，对软件工程基准中的 \(N = 2,500\) 个任务执行一轮评估。每个任务都需要一个 Linux 环境，其中包含完整的 C++ 工具链、Python 虚拟环境、预先建立索引的 git 树以及数据库二进制文件，未压缩的磁盘状态总量为 \(S_{\text{env}} = 12\text{ GB}\)。

在一条典型轨迹中，智能体修改或创建的文件总量平均为 \(S_{\Delta} = 80\text{ MB}\)（包括源代码差异、测试日志、.pyc 缓存）。宿主集群使用企业级 NVMe SSD，其持续顺序写入吞吐量可达 \(B_{\text{write}} = 2.5\text{ GB/s}\)，顺序读取吞吐量可达 \(B_{\text{read}} = 5.0\text{ GB/s}\)。

情况 1：朴素全量复制（cp -a 或完整镜像解包） 为了在任务之间重置环境，每个工作进程都会复制整个 12 GB 的基准目录： \[T_{\text{reset, naive}} = \frac{S_{\text{env}}}{B_{\text{write}}} = \frac{12\text{ GB}}{2.5\text{ GB/s}} = 4.8\text{ seconds}\] 在完整的一轮基准评估中，写入 SSD 的数据总量为： \[D_{\text{total, naive}} = N \times S_{\text{env}} = 2,500 \times 12\text{ GB} = 30,000\text{ GB} = 30\text{ TB}\] 当 64 个工作进程并发运行时，重置期间的总写入需求为 \(64 \times 2.5\text{ GB/s} = 160\text{ GB/s}\)，这会使宿主机的 PCIe 存储总线严重饱和，并引发热降频。

情况 2：写时复制快照（OverlayFS / Btrfs 快照） 配置 OverlayFS 上层目录需要创建一个空的工作目录，并发起一次 mount 系统调用。快照创建时间主要取决于 inode 分配和目录 dentry 初始化： \[T_{\text{create, CoW}} \approx 15\text{ ms} = 0.015\text{ seconds}\] 任务执行期间，只有被修改的块会写入上层（\(S_{\Delta} = 80\text{ MB}\)）。任务结束时，销毁环境需要发起一次 umount 系统调用，并递归删除 \(80\text{ MB}\) 的上层目录： \[T_{\text{teardown, CoW}} = \frac{S_{\Delta}}{B_{\text{write}}} = \frac{0.08\text{ GB}}{2.5\text{ GB/s}} \approx 32\text{ ms} = 0.032\text{ seconds}\] 每个任务的总重置开销为： \[T_{\text{reset, CoW}} = T_{\text{create, CoW}} + T_{\text{teardown, CoW}} = 0.015\text{ s} + 0.032\text{ s} = 0.047\text{ seconds}\] 在整轮评估中，写入存储的数据总量为： \[D_{\text{total, CoW}} = N \times S_{\Delta} = 2,500 \times 0.08\text{ GB} = 200\text{ GB}\] 存储写入量缩减的倍数为： \[\frac{D_{\text{total, naive}}}{D_{\text{total, CoW}}} = \frac{30,000\text{ GB}}{200\text{ GB}} = 150\times\] 重置延迟从 {python} StorageIoResetAmortization.t_reset_naive_s_str 降至 {python} StorageIoResetAmortization.t_reset_cow_s_str，实现了 {python} StorageIoResetAmortization.speedup_mult_str 倍的加速，并消除了整个由 64 个工作进程组成的评估集群中的存储总线饱和问题。

基准污染风险

在传统机器学习中，基准完整性几乎只关注数据污染：即评估数据集中的问答对被意外纳入模型预训练所用的网页抓取数据的风险。如果一个 LLM 在预训练期间记住了 HumanEval 的解答，那么它的高通过率反映的是机械记忆后的检索，而非具有泛化能力的代码合成。

在自主智能体系统中，工程师面临第二种危害更大的失效模式：运行时信息泄漏（或评估框架渗透）。由于智能体具备通用工具使用能力，包括终端执行、文件系统遍历和进程检查，它可以主动探查自身的执行环境，以发现、读取或操纵评估框架本身。

Agent Execution Trace (Harness Penetration Attack):
$ whoami
root
$ pwd
/workspace/django
$ find / -name "*test*" -type f 2>/dev/null | grep -E "eval|oracle|patch"
/opt/eval_harness/test_patches/issue_14521_eval.py
/opt/eval_harness/oracle_solution.diff
$ cat /opt/eval_harness/oracle_solution.diff
diff --git a/django/db/models/fields/__init__.py b/django/db/models/fields/__init__.py
...
$ git apply /opt/eval_harness/oracle_solution.diff
$ git commit -am "Fixed issue"
$ echo "SUCCESS"

如果评估运行框架只是将标准答案验证脚本挂载到容器文件系统中（即使位于 /opt/eval_harness 这样的父目录中），现代前沿模型也会使用 find 或 grep 等工具定位这些文件，读取确切的参考补丁，将其直接应用到代码仓库，并在没有进行任何问题求解的情况下获得满分评估结果。

此外，如果智能体拥有 root 权限，而评估运行框架在智能体完成任务后于同一容器内部运行验证测试，智能体就可以篡改验证基础设施。智能体可以定位 pytest 运行器，并通过猴子补丁修改其断言逻辑、覆盖系统级测试库，或将验证退出码脚本替换为无条件返回 0 的伪二进制程序。

为消除运行时信息泄漏，生产级训练场实施严格的双舱沙箱架构：

1. 不可信工作沙箱（A 舱）： 智能体完全在 A 舱内运行。该舱仅包含运行目标软件项目所需的最少依赖项（例如编译器、Python 解释器、git 树、问题描述）。A 舱中不存在任何对标准答案单元测试的引用，不包含任何评估驱动代码，也无法访问测试运行框架宿主机。网络命名空间通过严格的防火墙规则限制为仅能访问本地模拟服务。
2. 验证预言机沙箱（B 舱）： 一旦智能体发出任务完成信号（或耗尽步数或词元预算），宿主机监督程序就会停止 A 舱，并捕获其文件系统增量 \(\Delta S = S_{\text{post}} - S_{\text{pre}}\)。该增量以只读方式挂载到 B 舱。B 舱包含封闭隔离的测试运行器和标准答案测试套件（FAIL_TO_PASS 和 PASS_TO_PASS 断言）。

验证脚本仅在 B 舱内执行。智能体在其轨迹过程中无法检查 B 舱，也无法修改测试执行脚本或篡改产生的退出码。通过将执行运行时与验证预言机进行物理隔离，运行框架确保智能体的实测性能反映真实的任务解决能力，而非对环境的对抗性利用。

生产级智能体训练场

为理解这些架构原则如何体现在具体实现中，我们考察三个具有代表性的生产级训练场，它们在 AI 系统文献中被广泛用作标准评估目标（表 2）：SWE-bench、GAIA 和 WebArena。

表 2: 智能体评估训练场的比较分类：目标模态、主要状态表示、网络隔离基础设施、重置机制与预言机验证边界。

评估训练场	目标模态	主要状态表示	网络与外部模拟	重置机制	预言机验证边界
SWE-bench (Jimenez 等 2024年)	开源 Python 代码仓库中的软件工程	Git 仓库树、Python 虚拟环境、AST	完全阻断出站网络访问；所有依赖项均预先安装	每个代码仓库实例使用一个基础 Docker 容器；临时 CoW 差异	双舱：在独立运行器中应用标准答案测试补丁
GAIA (Mialon 等 2023年)	多模态助手与通用工具使用	本地文件系统、办公文档、多模态 CLI 工具	混合模式：默认阻断；静态文件桩与本地工具	为每个任务实例创建临时容器	规范化后的精确匹配或程序化文件断言
WebArena (Zhou 等 2024年)	自主网页浏览与 Web 应用操作	DOM 树、无障碍树、浏览器标签页状态	完全离线的自托管 Web 生态系统（GitLab、购物网站、论坛）	通过本地守护进程重置有状态的 SQL/数据库快照	多模态：数据库状态断言、DOM 检查、HTTP 查询

SWE-bench：大规模代码仓库执行

SWE-bench 由 Jimenez 等 (2024年) 提出，用于评估智能体解决真实软件工程问题的能力，这些问题采集自热门 GitHub 代码仓库（例如 django、sympy、scikit-learn、pytest）。每个任务实例包含一份自然语言问题描述（从真实的 GitHub 问题中提取）和一个代码仓库基础提交。

Jimenez, Carlos E., John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, 和 Karthik Narasimhan. 2024年. 《SWE-bench: Can Language Models Resolve Real-World GitHub Issues?》 International Conference on Learning Representations (ICLR).

SWE-bench 的系统运行机制要求严格隔离。每个代码仓库都依赖复杂且互不兼容的依赖图：一个任务可能需要 Python 3.8 和某个特定的旧版 NumPy，而另一个任务则需要 Python 3.11 和定制的 Cython 扩展。SWE-bench 通过为每类代码仓库维护预先构建的基础容器镜像来解决这一问题。

任务执行时，运行框架会克隆代码仓库并检出基础提交，应用环境设置脚本，并向智能体提供 shell 接口。关键在于，SWE-bench 将验证测试划分为两个不同的类别：

• FAIL_TO_PASS：由人类维护者专门编写、用于复现所报告缺陷的标准答案单元测试。在基础提交中，这些测试无法通过。成功的智能体轨迹必须修改代码库，使所有 FAIL_TO_PASS 测试通过。
• PASS_TO_PASS：在基础提交中已通过的现有单元测试。成功的智能体轨迹不得破坏现有功能；每个 PASS_TO_PASS 测试都必须继续通过。

由于标准答案补丁与智能体的上下文严格隔离，智能体必须生成标准的统一差异补丁（git diff），以表示其提出的修复方案。SWE-bench 运行器将该差异补丁应用于仓库的干净实例，再应用包含 FAIL_TO_PASS 测试的测试补丁，并在 B 室内执行测试运行框架，记录返回码和测试失败追踪信息。

GAIA：通用多模态工具使用

GAIA（通用人工智能助手）由 Mialon 等 (2023年) 提出，用于测试智能体解决复杂、多跳行政事务与分析任务的能力。SWE-bench 将智能体限制在 git 仓库和 shell 中，而 GAIA 则要求智能体与多种文件模态交互：读取原始 PDF 研究论文、执行 Python 代码以分析 Excel 电子表格、处理音频文件，以及调用命令行实用工具。

Mialon, Grégoire, Clémentine Fourrier, Craig Swift, Thomas Wolf, Yann LeCun, 和 Thomas Scialom. 2023年. 《GAIA: A Benchmark for General AI Assistants》. arXiv preprint arXiv:2311.12983.

GAIA 的主要系统挑战是防止智能体幻觉式地声称执行了工具。许多任务需要多步推理，其中的中间结果必须通过确定性计算得出（例如，“计算所附 PDF 第 14 页报告的指标的复合年增长率，并与所附电子表格的 C 列进行交叉核对”）。

GAIA 训练环境提供了一套完整的命令行工具（pdftotext、ffmpeg、Python 数据科学运行时）。由于任务被设计为产生明确且可验证的答案（单个数字、特定字符串或逗号分隔的列表），验证依赖严格的规范化函数，将智能体最终输出的答案字符串与精确的标准答案判定基准进行比较，从而消除基于模型的评判器所固有的主观性。

WebArena：端到端企业 Web 沙箱

WebArena 由 Zhou 等 (2024年) 提出，代表了动态环境虚拟化的前沿。WebArena 评估自主 Web 智能体在图形化和文本型 Web 应用中导航的能力。允许智能体浏览真实互联网会引入不可控的变异性、安全漏洞和隐私侵犯，因此 WebArena 部署了一个完全自包含的离线 Web 生态系统。

Zhou, Shuyan, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, 等. 2024年. 《WebArena: A Realistic Web Environment for Building Autonomous Agents》. Proceedings of the 12th International Conference on Learning Representations (ICLR).

WebArena 基础设施编排了部署在私有局域网上的四个完整的开源企业 Web 应用：

• 电子商务： 在线购物店面（基于 OpenCart）。
• 社交媒体： 协作式讨论论坛（基于 Postmill）。
• 代码协作： 功能完备的 Git 托管与代码审查平台（基于 GitLab）。
• 内容管理： 企业 wiki 与文档系统（基于 MediaWiki）。

为提供真实的交互，WebArena 使用真实数据填充这些应用（例如，数千种产品、活跃的用户讨论帖和真实的仓库历史记录）。智能体通过无头浏览器实例（例如通过 Playwright 使用 Chromium）与环境交互，观察无障碍树或原始渲染像素，并执行点击、键盘输入、滚动和标签页导航等操作。

WebArena 的核心系统创新是其程序化状态断言引擎。WebArena 中的任务很少能简化为简单的字符串匹配。如果智能体接到指令：“取消我最近的一笔订单，并在卖家的论坛上发表评论解释原因”，那么验证任务是否完成就需要检查多个系统：

1. 查询电子商务平台的 PostgreSQL 数据库，确认目标订单状态已从 Pending 转变为 Canceled。
2. 检查论坛的 MySQL 数据库，验证是否插入了新的论坛帖子，且作者 ID 和外键关联正确。
3. 确认没有发生非预期的数据变更（例如，删除无关订单或损坏用户个人资料记录）。

WebArena 使用协调执行的数据库事务回滚和本地服务快照恢复来重置这一分布式 Web 生态系统。通过在内部虚拟交换机后方本地运行整个 Web 技术栈，WebArena 实现了确定性的执行速度，比真实网页浏览快数个数量级，同时完全隔绝了外部网络波动对评估的影响。

---

轨迹评分

针对同一退款任务的两条轨迹，最终都使订单恰好退款一次。其中一条进行了四次工具调用。另一条发起了两次退款，发现重复后撤销了重复的退款，而客户的账单上会显示这两笔记录。针对最终状态的结果检查会给它们相同的分数。评分决定轨迹的哪些属性应计入评估，以及用哪种测量工具衡量各项属性；这些选择决定了分数提高意味着什么。

结果验证器

主要评分器是一种机械式结果验证器，属于 过程验证 所分类的类型：测试、模式与数据库断言、文件检查以及精确匹配答案。在评估中，两类错误的影响并不对称。错误拒绝会降低优秀智能体的得分。错误接受则会将失败计为成功。验证的不对称性（原则 3）既适用于搜索，也适用于评估。如果测得的提升不大于验证器的错误接受率，就无法将其与这样的候选智能体区分开来：它只是学会了更频繁地满足验证器，却没有完成任务。只有人工审阅随机抽取的已接受轨迹样本，才能估计这一比率；每份评估报告都应在得分旁列出这一估计值。

过程评分与步骤级指标

结果验证器判断任务是否成功结束。过程评分则对各个步骤进行评分。Uesato 等人 (2022年) 发现，在数学应用题上，结果反馈与过程反馈达到了相近的最终答案准确率，但过程反馈显著降低了正确答案背后存在推理缺陷的比例；Lightman 等人 (2024年) 则发现，过程监督的奖励模型比结果监督的奖励模型更可靠地选出正确解答。对于智能体而言，过程既包括推理，也包括行动，若干步骤级指标可直接从执行记录中获得（节 5）：

Uesato, Jonathan, Nate Kushman, Ramana Kumar, Francis Song, Noah Shen, Hemanth Ramchurn, Balazs Gyevnar, Laurence Aitchison, Richard Evans, 和 Tianqi Gao. 2022年. 《Solving math word problems with process- and outcome-based feedback》. arXiv preprint arXiv:2211.14275, 网络首发. https://doi.org/10.48550/arXiv.2211.14275.

Lightman, Hunter, Vineet Kosaraju, Yura Burda, Harri Harres, Karl Cobbe, Christopher Hesse, Oleg Klimov, Jan Leike, John Schulman, 和 Ilya Sutskever. 2024年. 《Let’s Verify Step by Step》. International Conference on Learning Representations (ICLR).

• 工具调用有效率：所提出的调用中通过其模式校验的比例（第 1 层按调用计数，而非按任务计数）。
• 调用正确性：在存在参考调用时，工具及参数是否与参考调用匹配。Patil 等人 (2023年) 通过将生成的 API 调用结构与参考调用进行匹配来检查调用，从而区分参数错误与工具选择错误。
• 恢复率：观察到错误后，智能体的下一步行动针对该错误采取措施而非重复调用的比例，用于衡量 前向恢复 所述的前向恢复能力。
• 效率：每个被接受任务所需的轮数、词元数和冗余调用次数，仅在预算相同的条件下进行比较（节 4.4）。
• 部分得分：任务子目标中通过状态检查的比例，用于区分完成了五个步骤中的四个步骤的智能体与什么都没做的智能体。

Patil, Shishir G., Tianjun Zhang, Xin Wang, 和 Joseph E. Gonzalez. 2023年. 《Gorilla: Large Language Model Connected with Massive APIs》. arXiv preprint arXiv:2305.15334, 网络首发. https://doi.org/10.48550/arXiv.2305.15334.

步骤级指标用于诊断，通常不应作为准入门槛。候选智能体若提高了工具调用有效率，却降低了被接受任务的数量，就只是改善了一个代理指标；而 节 8 中的准入门槛依据的是被接受任务的数量。

LLM 裁判

有些标准没有机械式验证器：客服回复是否遵循了语气规范，报告是否回答了所提出的问题，代码变更是否符合惯用写法。对于这些标准，评估使用大语言模型（LLM）裁判，即通过评分准则提示另一个模型，对一条轨迹进行评分，或比较两条轨迹。候选选择 曾使用裁判在任务执行期间从候选方案中进行选择。评估对裁判提出了更高要求，因为其评分将成为发布决策所依据的证据。

Zheng 等人 (2023年) 记录了此类裁判的三种系统性偏差：偏好来自自身模型家族的输出，偏好更长、更详尽的答案而非简洁正确的答案，以及在成对比较中偏好先出现的答案。裁判也只能读取词元。它无法运行测试或查询数据库，因此不能自行提供任何额外层级的闭环证据（闭合证据等级），而且智能体撰写的文本可能左右其判断。基于这些局限，负责任地使用裁判应遵循以下原则：

Zheng, Lianmin, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Hao Wu, Yonghao Zhuang, Zi Lin, 等. 2023年. 《Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena》. Advances in Neural Information Processing Systems (NeurIPS) 36: 46595～623.

1. 限定范围。 裁判仅评判验证器无法检查的标准，其评分绝不能推翻验证器给出的失败判定。
2. 以证据为依据。 向裁判提供状态变化、测试输出和工具结果等证据，而非智能体自行撰写的总结；评分准则应列出具体且独立的标准，而非依赖总体印象。
3. 消除偏差。 成对比较应按两种顺序分别进行，并优先选择与候选智能体来自不同模型家族的裁判。
4. 进行校准。 在留出样本上，将裁判的标签与专家标签进行比较，报告经过偶然一致性校正的一致性指标，例如 Cohen 的 \(\kappa\)；对于同时具备裁判和验证器的任务，还应将裁判标签与验证器判定进行比较。如果裁判在可验证任务上的判断与验证器不一致，就不应在不可验证任务上信任它。

经过校准的评判器会降低将不良轨迹评为良好轨迹的概率，但绝不会对此作出保证。如果存在保证，它来自智能体无法访问的验证器。当智能体能够访问评分器并学会利用其漏洞时，问题就演变为奖励黑客行为，可验证奖励强化学习 在这种行为最危险的情境下对其进行了讨论。

现在，每次经过评分的试验都会产生可信的判定结果和一组诊断性评分。然而，无论评分多么完善，单次试验都只是从随机系统中进行的一次抽样，接下来的问题是：一项论断需要多少次抽样才能得到支持。

统计评估的严谨性

一旦评估训练场实现了完全的封闭隔离——消除了网络不稳定性、防止了磁盘损坏，并封闭了预言机验证边界——系统工程师就会遇到一个无法回避的数学事实：基础模型是随机推理引擎。即使初始状态完全相同 \(S_{\text{pre}}\)，自回归解码路径、采样温度以及 GPU 集群上的浮点数值运算执行过程的变化，仍会导致很高的轨迹方差。在单轮评估中测得的单次通过率，完全无法为智能体系统能否安全部署到生产环境提供统计保证。系统工程师应如何对这种随机不确定性建模，如何在有限任务分布上计算严谨的置信区间，又如何从数学上区分智能体潜在的推理能力与其部署后的运行可靠性？这一问题决定了智能体评估的统计机制。

在包含 150 项软件工程任务的自动化评估套件中，智能体运行时发布候选版本 \(v_{\text{RC1}}\) 的实测通过率为 54.7%（解决了 82 项任务），而候选版本 \(v_{\text{RC2}}\) 的实测通过率为 58.7%（解决了 88 项任务）。在传统的确定性软件工程中，例如对优化编译器进行基准测试或对 SQL 查询规划器进行回归测试，在保持不变的测试框架上出现四个百分点的性能差异，意味着明确无疑的进步。但在随机智能体系统中，这一结论只是经验观测造成的错觉。如果测试框架在完全相同的任务夹具上第二次执行 \(v_{\text{RC2}}\)，其测得的成功率可能降至 51.3%，而对 \(v_{\text{RC1}}\) 的第二轮评估则可能升至 56.0%。两个运行时之间看似存在的性能差异，并非结构性的架构突破，而是来自宽广且相互重叠的非确定性轨迹分布中的采样噪声。

系统工程师不能将智能体系统的执行视为确定性的布尔测试套件。 由于基础模型从离散词表上的条件概率分布中采样词元，智能体在环境中的轨迹是一条随机马尔可夫链，受到外部工具延迟、非结合性的浮点归约运算以及采样超参数的调制。评估此类系统，需要将经验性基准测试从临时性的评分转变为正式的统计估计。这一转变要求采取三项基础实践：将任务环境作为主要重采样单位，使用 Wilson 得分置信区间界定有限样本的二项不确定性，以及严格区分潜在推理能力（\(pass@k\)）与实际运行的执行策略（\(pass^k\) 和受成本预算约束的接受机制）。

重采样层级

机器学习系统工程中一个普遍的误解是，将生成温度设为零（\(T=0\)）就能使智能体系统具有确定性。在不受约束的宿主运行时中，贪心自回归解码并不能消除各次运行之间的差异。非确定性通过物理硬件操作和异步环境交互进入执行图。

浮点运算的非结合性由 IEEE-754 规定：对于有限精度的数值，\((a + b) + c \neq a + (b + c)\)。在高吞吐量 GPU 内核中，线程束完成并行归约的顺序会随内存总线争用和时钟频率调整而动态变化。

在硬件层面，GPU 张量核心内部的并行矩阵归约运算本质上不满足结合律。在对数千个词元计算缩放点积注意力，或对拆分的词表投影产生的 logits 进行归约时，现代 GPU 运行时会将张量分块分配到各个流式多处理器上。由于线程块调度受到动态内存总线争用、热降频和线程束调度器仲裁的影响，浮点求和的顺序会在连续的前向传播之间发生变化。只要概率最高的两个词元之间的 logit 差值小于浮点累加器的精度阈值（\(\ell_{(1)} - \ell_{(2)} < \epsilon_{\text{fp}}\)），浮点运算顺序的微小变化就会使 argmax 选中的词元发生改变。对于执行五十步轨迹的自主智能体，早期规划步骤中仅一个词元发生变化，就会使整个后续执行路径发生分歧。

除了设备层面的浮点运算非确定性之外，运行时环境还会引入异步时序抖动。外部工具端点、数据库连接、容器文件系统操作以及子智能体远程过程调用（RPC）的延迟均存在波动。如果智能体并发调用工具，或以非阻塞超时方式轮询外部子进程，操作系统线程调度的变化就会改变观测结果注入模型上下文窗口的顺序。先收到 ToolResult(stdout="OK")、后收到 ToolResult(stderr="Warning") 的智能体，所构建的提示前缀与按相反顺序接收观测结果的智能体完全不同，从而使推理轨迹发生不可逆的分叉。

为了在这种物理随机性下衡量性能，系统工程师必须形式化地定义重采样层级。评估运行框架包含两种不同的方差来源：

1. 任务采样方差（\(\sigma^2_{\text{task}}\)）： 选取包含 \(N\) 个评估任务的有限子集所引入的变异性，该子集来自更广泛的现实问题全集 \(\mathcal{D}_{\text{task}}\)。
2. 策略采样方差（\(\sigma^2_{\text{policy}}\)）： 在完全相同的任务测试实例 \(\tau_i\) 上反复评估时，智能体内部轨迹生成过程在各次运行之间表现出的随机性。

统计重复的基本单位是独立的任务测试实例，而非重复运行。对 100 次运行取平均，即使覆盖五个任务，也只能对这五个狭窄的测试实例获得很高的精度，无法对样本外泛化提供任何置信保证。

在估计智能体的真实运行成功率 \(p^* = \mathbb{E}_{\tau \sim \mathcal{D}_{\text{task}}} [\mathbb{E}_{a \sim \pi} [S(\tau, a)]]\) 时，估计量的总方差可按层级分解为 \(N\) 个独立任务之间的方差，以及每个任务 \(R\) 次重复执行之间的方差：

\[\text{Var}(\hat{p}) = \frac{\sigma^2_{\text{task}}}{N} + \frac{\sigma^2_{\text{policy}}}{N \cdot R} \tag{1}\]

公式 1 揭示了一条无法规避的架构规律：在固定的基准测试套件上增加重复运行次数 \(R\)，可以降低每个任务的策略噪声，但最终会触及由任务采样方差 \(\sigma^2_{\text{task}} / N\) 决定的严格渐近下限。让智能体运行十次，覆盖 100 个 SWE-bench 任务（\(N=100, R=10\)），可以高度确定智能体在这 100 个特定代码库上的表现，但无法缩小其在未观测过的企业代码仓库上表现的不确定性。相比之下，让智能体仅运行一次，覆盖 1,000 个独立任务（\(N=1000, R=1\)），可以直接缩小占主导地位的任务采样误差项。独立的任务测试实例是系统评估的主要重采样单位。

有限样本不确定性

在少于 200 个任务上进行评估会产生较宽的置信区间（正负 16%），使真实的模型性能退化被统计噪声掩盖。

由于基准测试执行的计算成本和经济成本都很高，评估套件采用有限的样本量，通常包含 100 至 1,000 个任务。在这些有限样本范围内，系统工程师必须构建能够准确刻画成功概率分布的置信区间。

标准工程入门教材经常使用正态近似来计算置信界限，这种方法称为 Wald 置信区间（公式 2）：

\[\text{CI}_{\text{Wald}} = \hat{p} \pm z_{1-\alpha/2} \sqrt{\frac{\hat{p}(1-\hat{p})}{N}} \tag{2}\]

其中，\(\hat{p} = X / N\) 是 \(N\) 个任务上的经验成功比例，\(z_{1-\alpha/2}\) 是标准正态分位数（例如，\(1.96\) 对应 95% 的置信水平）。

对于智能体系统，Wald 区间极不适用，其后果十分严重。正态近似假设 \(\hat{p}\) 的采样分布对称且具有良好的性质。这一假设在两个方面不成立：

• 边界灾难： 当智能体在基准测试中一次也未成功（\(X=0\)），或全部成功（\(X=N\)）时，估计标准误 \(\sqrt{\hat{p}(1-\hat{p})/N}\) 的计算结果为零。Wald 公式由此以 100% 的数学确定性断言，智能体在生产环境中永远不会成功（或永远不会失败）。如果早期原型在评估运行框架中的全部 50 个任务上都失败，声称其 95% 置信区间为 \([0.0, 0.0]\) 就完全无效；真实成功率完全可能是 3% 或 5%。
• 极端情形下的严重偏斜： 复杂的智能体任务（例如自动修复代码仓库级别的缺陷，或多跳网页信息提取）通常具有较低的基线通过率（\(\hat{p} \in [0.05, 0.20]\)）。在这种非对称情形下，真实的二项采样分布高度偏斜。对称的 Wald 区间向下延伸至实际上不可能出现的负值区域（\(\text{CI}_{\text{lower}} < 0\)），同时其上界对真实参数的覆盖率严重不足。

为获得二元任务结果在数学上可靠的界限，系统工程师采用埃德温·B. 威尔逊于 1927 年提出的威尔逊得分区间。威尔逊得分法并非在含有噪声的经验点估计 \(\hat{p}\) 处计算标准误，而是在零假设分布下反演假设检验，在假设的真实参数 \(p\) 处计算方差：

\[\tilde{p} = \frac{X + \frac{z^2}{2}}{N + z^2}, \quad \text{CI}_{\text{Wilson}} = \tilde{p} \pm \frac{z}{N + z^2}\sqrt{\frac{X(N-X)}{N} + \frac{z^2}{4}} \tag{3}\]

威尔逊得分区间的代数形式提供了一种直观的系统层面解释。区间的中点 \(\tilde{p}\) 并不是原始样本比例 \(X/N\)。相反，它引入了一个收缩先验，将估计值拉向最大熵状态（\(0.5\)）。分母从 \(N\) 增加到 \(N + z^2\)，而分子则加入 \(z^2/2\) 次“虚拟”成功。对于 95% 的置信水平（\(z \approx 1.96, z^2 \approx 3.84\)），该公式实际上向样本中加入两次虚拟成功和两次虚拟失败（即 Agresti-Coull 解释），确保即使在 \(X=0\) 时，上界仍严格为正：

\[\text{CI}_{\text{Wilson}}(X=0, N=50) = \left[0.000, \, \frac{3.84}{53.84} + \frac{1.96}{53.84}\sqrt{\frac{3.84}{4}}\right] = [0.000, \, 0.071]\]

系统工程师可以明确报告：尽管在 50 次试验中未观察到任何成功，但在 95% 的置信水平下，智能体的真实性能上限仍可能达到 7.1%。

图 2: 样本量扩展与威尔逊得分置信界限：不同基准通过率下，误差幅度随基准测试样本量 \(N\) 增大而收缩的情况，以及在边界与偏斜情形下，Wald 近似与威尔逊得分反演所得到的经验区间结构。

图 2 中的双面板分解揭示了为什么智能体评估必须以严格的统计界限为依据。在面板 A 中，双曲线形的收缩曲线表明，不确定性按 \(\mathcal{O}(1/\sqrt{N})\) 缩放：将评估误差幅度减半，需要将基准测试规模扩大至四倍。在接近最大方差的条件下（\(p=0.50\)）评估候选智能体时，由 \(N=100\) 个任务组成的标准测试集会产生宽达 \(\pm 9.8\%\) 的误差幅度（\([40.2\%, 59.8\%]\)），因而无法验证细微的个位数性能退化。要分辨 \(\pm 2.0\%\) 的性能差异——这是生产环境中金丝雀版本晋级所要求的标准阈值——需要将评估测试集扩展至 \(N \ge 2,400\) 个独立测试用例。在面板 B 中，误差棒的对比突显了经典 Wald 正态近似在 \(N=50\) 时、三种关键运行情形下的失效模式。在情形 1（边界灾难，\(X=0\)）中，Wald 区间坍缩为一个退化的零宽度点 \([0.0\%, 0.0\%]\)，错误地断言失败具有绝对确定性；威尔逊反演则通过其 Agresti-Coull 先验，将估计值恰当地正则化为 \([0.0\%, 7.1\%]\)。在情形 2（负概率陷阱，\(X=2\)，\(\hat{p}=4.0\%\)）中，Wald 的对称高斯假设使区间向下延伸至物理上不可能的负概率（\([-1.4\%, 9.4\%]\)），而威尔逊得分区间则保证了非对称且严格为正的界限（\([1.1\%, 13.5\%]\)）。只有在情形 3（最大方差，\(X=25\)，\(\hat{p}=50.0\%\)）中，两种公式的结果才趋于一致，但二者仍存在很大的不确定性（\(\pm 13.5\%\)），因此不能据此仓促作出部署决策。

import math

def compute_wilson_score_interval(x: int, n: int, z: float = 1.96) -> tuple[float, float]:
    """Calculate the Wilson score confidence interval for a binomial proportion."""
    if n <= 0:
        raise ValueError("Sample size n must be strictly positive.")
    p_tilde = (x + (z**2) / 2) / (n + z**2)
    margin = (z / (n + z**2)) * math.sqrt((x * (n - x) / n) + (z**2) / 4)
    return max(0.0, p_tilde - margin), min(1.0, p_tilde + margin)

Example 0.1: 智能体基准测试中的 Wilson 得分界限

系统困境： 一个工程团队在标准化测试框架上评估两种候选智能体监督架构，测试包含 \(N = 150\) 个独立的代码仓库修复任务：

• 架构 A（基线 ReAct）：解决 82 个任务（\(X_A = 82, \hat{p}_A = 54.67\%\)）。
• 架构 B（推测式验证）：解决 88 个任务（\(X_B = 88, \hat{p}_B = 58.67\%\)）。

项目负责人以性能领先 4.0% 为由，提议立即部署架构 B。在 95% 的置信标准（\(\alpha = 0.05, z = 1.96\)）下，这些实证数据是否支持发布该候选版本？

分析： 我们将 公式 3 中的 Wilson 得分区间公式应用于这两种候选架构：

对于架构 A（\(X_A = 82, N = 150\)）： \[\tilde{p}_A = \frac{82 + \frac{1.96^2}{2}}{150 + 1.96^2} = \frac{82 + 1.9208}{153.8416} = \frac{83.9208}{153.8416} \approx 0.5455\] \[\text{Margin}_A = \frac{1.96}{153.8416}\sqrt{\frac{82(68)}{150} + \frac{1.96^2}{4}} = 0.01274 \times \sqrt{37.1733 + 0.9604} = 0.01274 \times 6.1753 \approx 0.0787\] \[\text{CI}_A = [0.5455 - 0.0787, \, 0.5455 + 0.0787] = [0.4668, \, 0.6242] \implies [46.7\%, \, 62.4\%]\]

对于架构 B（\(X_B = 88, N = 150\)）： \[\tilde{p}_B = \frac{88 + 1.9208}{153.8416} = \frac{89.9208}{153.8416} \approx 0.5845\] \[\text{Margin}_B = \frac{1.96}{153.8416}\sqrt{\frac{88(62)}{150} + 0.9604} = 0.01274 \times \sqrt{36.3733 + 0.9604} = 0.01274 \times 6.1101 \approx 0.0778\] \[\text{CI}_B = [0.5845 - 0.0778, \, 0.5845 + 0.0778] = [0.5067, \, 0.6623] \implies [50.7\%, \, 66.2\%]\]

结论： 两个置信区间高度重叠（\([46.7\%, 62.4\%]\) 与 \([50.7\%, 66.2\%]\)）。架构 A 在实际运行中的通过率可能为 61%，而架构 B 的通过率可能为 52%。要确定 4% 的改进在 \(\alpha = 0.05\) 水平下是否具有统计显著性，并达到 80% 的统计功效，测试框架需要完成以下规模的评估：

\[N_{\text{required}} \approx \frac{2 \cdot (z_{0.975} + z_{0.80})^2 \cdot \bar{p}(1 - \bar{p})}{(\Delta p)^2} = \frac{2 \cdot (1.96 + 0.84)^2 \cdot 0.5667(0.4333)}{(0.04)^2} \approx 2,408 \text{ tasks}\]

在包含 150 个任务的测试套件上领先四个百分点，并不足以提供支持架构迁移的实证证据。

潜在能力解耦

当智能体系统以非确定性方式进行评估、每个任务执行多条轨迹时，汇总性能需要在衡量潜在推理能力与衡量实际执行可靠性的指标之间做出选择。混淆这两个维度会导致严重的部署失败。

在评估生成模型代码能力的奠基性工作中，Chen 等 (2021年) 形式化定义了指标 \(pass@k\)。当智能体为给定任务生成 \(k\) 条候选解题轨迹时，\(pass@k\) 衡量这 \(k\) 条轨迹中至少有一条通过所有验证关卡的概率。

Chen, Mark, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, 等. 2021年. 《Evaluating Large Language Models Trained on Code》. arXiv preprint arXiv:2107.03374.

若采用朴素方法，每个任务恰好生成 \(k\) 条轨迹，并检查是否有轨迹通过验证，所得经验估计量的采样方差会很高。为此，Chen 等 (2021年) 提出了无偏、低方差的超几何估计量。测试框架针对每个任务执行 \(n\) 次独立候选运行（\(n \ge k\)），并记录成功运行的次数 \(c\)。随机抽取一个大小为 \(k\) 的子集，其中至少包含一条通过验证的轨迹的期望概率为：

\[\text{pass}@k = \mathbb{E}_{\tau \sim \mathcal{D}_{\text{task}}} \left[ 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} \right] \tag{4}\]

其中，\(\binom{n-c}{k} / \binom{n}{k}\) 表示所选的全部 \(k\) 条轨迹均来自 \(n-c\) 次失败尝试的组合概率。

import math

def compute_pass_at_k(n: int, c: int, k: int) -> float:
    """Calculate the unbiased pass@k metric using Chen et al.'s formulation."""
    if n - c < k:
        return 1.0
    return 1.0 - (math.comb(n - c, k) / math.comb(n, k))

\(pass@k\) 假设存在一个全知且无成本的验证器，能够从 \(k\) 个提案中选出唯一有效的轨迹。在没有自动化测试判定器的生产环境中，用户实际体验到的是 \(pass@1\)。

公式 4 是科学研究中的严谨工具，但它会给系统工程师带来一个危险的陷阱。\(pass@k\) 指标衡量的是潜在生成能力的边界：如果配备一个全知且零成本的判定器，检查全部 \(k\) 次候选运行并部署其中成功的一次，智能体架构能够达到怎样的表现。

在面向客户的企业部署中（例如自动化客户支持智能体或无人值守的基础设施修复工作单元），并不存在这样的外部判定器。如果智能体运行时针对一个客户请求生成五条候选轨迹，除非系统具备自动化、确定性的验证判定器（例如通过的测试套件或可验证输出的编译器），否则就无法判断哪条轨迹是正确的。如果没有自动化验证过滤器就进行部署，即使智能体系统的 \(pass@10 = 92\%\) 表现极佳，它直接向用户提供的运行可靠性仍将是 \(pass@1 = 48\%\)。

为了评估自主生产环境中的运行安全性，系统工程师将 \(pass@k\) 与两个面向部署的指标进行对比：

1. 执行一致性（\(pass^k\)）： 对于多步骤企业工作流，首要的运行关注点并非系统能否在 \(k\) 次尝试中成功一次，而是它能否在每次执行中都保持一致，且无需人工干预。一致性指标 \(pass^k\) 评估智能体在连续 \(k\) 次执行中全部成功的概率（公式 5）：

\[pass^k = \mathbb{E}_{\tau \sim \mathcal{D}_{\text{task}}} \left[ \frac{\binom{c}{k}}{\binom{n}{k}} \right] \tag{5}\]

对于集成到持续交付流水线中的自主智能体，单次运行可靠性（\(pass@1\)）必须接近 1。如果智能体的单次运行通过率为 85%（\(pass@1 = 0.85\)），那么它在五项任务构成的部署序列中的一致性就会骤降至 \(pass^5 \approx (0.85)^5 = 44.4\%\)。

2. 成本预算约束下的接受率（\(pass@\$B\)): Standard evaluation metrics ignore resource consumption. An agent that achieves an 80 percent pass rate by consuming 1.2 million tokens across deep multi-turn planning loops ($每项任务 12.50）与达到 76%、成本为 $0.18 per task. The cost-budgeted metric $ 的优化基线相比，可能在商业上不可行。pass@$B$ 计算运行时的累计资金或 token 支出受上限 \(B\) 约束时所能达到的最高通过率（公式 6）：

\[pass@\$B = \mathbb{E}_{\tau \sim \mathcal{D}_{\text{task}}} \left[ \mathbb{I}\left( S(\tau, a) = 1 \;\land\; \text{Cost}(a) \le B \right) \right] \tag{6}\]

这些指标的数学表述、系统层面含义和运行要求汇总于 表 3。

表 3: 智能体系统的统计评估指标：各类评估指标的数学表述、系统层面含义和生产环境先决条件。

指标	形式化表述	系统层面含义	生产环境先决条件
\(pass@k\)	\(\mathbb{E}\left[ 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} \right]\)	在 \(k\) 次并行生成尝试下的潜在模型能力。	需要自动化、封闭隔离的验证判定器来选择候选轨迹。
\(pass@1\)	\(\mathbb{E}\left[ \frac{c}{n} \right]\)	预期的单次自主执行成功率。	单轮自主工作单元的标准发布基线。
\(pass^k\)	\(\mathbb{E}\left[ \frac{\binom{c}{k}}{\binom{n}{k}} \right]\)	连续 \(k\) 次运行成功的概率（一致性）。	无人值守自动化流水线和多智能体级联系统的必要条件。
\(pass@\$B\)	\(\mathbb{E}\left[ \mathbb{I}(S = 1 \land \text{Cost} \le B) \right]\)	严格资金或资源上限约束下的运行效率。	商业智能体运行时的财务可行性门槛。

通过将评估分解为统计置信区间和运行指标概况，系统工程师可以确定智能体架构的性能差异是否代表可复现的进步。

---

在各项任务测试配置上进行严谨的统计分析，可以确定智能体系统的总体性能在可量化的置信界限内是有所提升、出现退化，还是停滞不前。然而，总体统计数据本质上仍是黑箱指标：它们量化了失败的频率，却无法解释失败的机制。当更新后的智能体运行时导致基准测试通过率下降六个百分点时，置信区间可以确认这种退化在统计上确实存在，但无法辨别失败究竟源于损坏的检索查询、错误的工具调用模式、耗尽的上下文窗口，还是多智能体 RPC 共识过程中的级联循环。为了诊断非确定性失败的微观成因，系统工程师必须深入总体分布内部，检查单条轨迹的因果执行图。这一诊断需求促使我们引入分布式轨迹追踪。

在相同预算下比较

获准使用更多轮次、更多样本或更大模型的候选方案通常会获得更高的分数，但这种提升并不能说明所测试的改动有何效果。因此，每次比较都必须固定预算：相同的轮次上限、token 上限和实际耗时限制，以及每项任务相同的样本数。表 3 的最后一行通过 公式 6 将这一要求形式化。

除 pass@\(B\) 指标外，评估报告还应列出每个候选方案完成每项获接受任务的成本，即总支出除以获接受的任务数，因为一个得分提高两个百分点、支出却增至三倍的候选方案只是改变了运行点，而非改进了智能体。如何在整个集群中将这一成本降至最低，属于 智能体经济学 的讨论范围。

区间、可靠性指标和相同预算可以告诉我们候选方案是否有所改进。但它们无法解释任务为何失败，也无法判断性能退化究竟源于检索、工具、被截断的观测，还是模型本身。为此，我们需要深入查看单条轨迹的内部过程。

Checkpoint 0.1: 统计证据

在阅读追踪记录如何解释差异之前，先检查自己能否为测得的差异提供充分依据。

• 重复实验单位：为什么增加任务数可以降低对生产环境成功率估计的不确定性，而增加每项任务的运行次数却不能？
• 区间选择：对于 50 项任务中成功 0 次的情况，Wald 区间给出的结果是什么，Wilson 区间给出的结果又是什么？
• 样本量估计：当通过率接近 50% 时，每个候选方案大约需要多少项任务，才能确认两个百分点的差异？
• 潜力与可靠性：何时应将 pass@\(k\) 作为发布目标，何时团队必须改为报告 pass\(^k\)？

分布式轨迹追踪

异步载荷卸载和基于尾部的采样将活跃轨迹遥测索引从 100 MB 压缩至 25 KB，在避免耗尽 gRPC 帧容量的同时，保留生产环境中 100% 的失败追踪记录。

设想一个在生产代码库上运行的自主软件工程智能体，在执行常规重构任务时突然耗尽了三十秒的实际耗时限额。客户端应用只记录了一个没有附加信息的 DEADLINE_EXCEEDED 错误码，而宿主运行时的日志目录则堆满了互不关联的零散日志行：推理服务器记录了八次自回归解码突发；内存向量数据库记录了三次 \(k\) 近邻索引遍历；容器运行时记录了两次 POSIX git 子进程执行；另一个负责代码审查的智能体则记录了一次传入的 JSON-RPC 消息交换。由于每个子系统都维护着各自独立的日志流，实际时钟时间戳未经协调，关联标识符也互不相通，系统工程师无法确定时间限额究竟消耗在模型预填充期间的 GPU 内存总线饱和、向量数据库中未使用索引的表扫描、bash 沙箱中无缓冲管道的阻塞，还是协作智能体之间异步 RPC 队列的卡死上。

端到端轨迹可观测性要求将这些碎片化的运行时域统一为一张因果有向无环图（DAG）。通过将智能体执行过程组织为 OpenTelemetry 追踪层级，每次神经网络推理、沙箱化工具调用、记忆检索以及智能体间消息，都由确定性的因果关系和密码学标识符关联起来。 分布式轨迹追踪将 Dapper (Sigelman 等 2010年) 的基本原理应用于随机性智能体架构，使延迟分解、token 消耗、工具副作用和结构性故障都能在数学上追溯到其源头执行步骤，而不再将智能体视为一个输出不透明 token 流的单体黑盒。

混合轨迹 DAG 的构成

在经典微服务架构中，分布式追踪跟踪通过 HTTP 或 gRPC 等标准传输协议跨越网络边界传播的同类远程过程调用。追踪上下文在 API 网关处创建并注入网络报头；下游服务读取传入的元数据，实例化子跨度，并将修改后的上下文转发给后续后端。虽然微服务 RPC 的载荷大小和数据库查询复杂度各不相同，但其执行模型在根本上仍然一致：由确定性 CPU 指令驱动的同步或异步线程执行。

智能体系统使这种架构同质性不再成立。智能体轨迹是一条混合执行流水线，跨越四种在物理和计算层面根本不同的底层基础：

1. 自回归神经网络执行： 在 GPU 加速器集群上执行的高吞吐量、受内存带宽限制的矩阵运算，由词元批处理调度器、键值（KV）缓存分页和推测解码循环控制。
2. 本地沙箱计算： 在隔离容器或 microVM 内生成的带外操作系统进程，与虚拟化文件系统、网络接口和 POSIX 管道交互。
3. 高维向量记忆检索： 在分布式向量索引上执行的近似最近邻（ANN）搜索，通过遍历分层可导航小世界（HNSW）图等图结构来检索上下文片段。
4. 异步多智能体 RPC 消息传递： 离散的协同协议，其中对等智能体协商任务分配、审查中间产物，并在不同物理节点之间执行共识算法。

为刻画这种异质性，智能体追踪被形式化定义为有向无环图 \(\mathcal{G} = (\mathcal{V}, \mathcal{E}_{\text{causal}})\)。顶点集 \(\mathcal{V} = \{s_0, s_1, \dots, s_n\}\) 表示所有执行跨度的集合，其中每个跨度 \(s_i\) 都是一个形式化元组：

\[s_i = \langle \text{trace\_id}, \text{span\_id}, \text{parent\_id}, t_{\text{start}}, t_{\text{end}}, \mathcal{A}, \mathcal{X} \rangle\]

标识符 \(\text{trace\_id}\) 和 \(\text{span\_id}\) 分别提供 128 位和 64 位的熵保证；\(\text{parent\_id}\) 将该跨度链接到其因果祖先；\(t_{\text{start}}\) 和 \(t_{\text{end}}\) 表示单调时钟时间戳；\(\mathcal{A}\) 是包含语义键值属性的类型化字典；\(\mathcal{X}\) 则是带时间标记的事件的有序序列，用于捕获瞬态状态转换，例如词元输出间隔或工具执行过程中的 stderr 写入。

分布式追踪层次结构：异构智能体执行的分层分布式追踪分解。

跨度标识符	执行域	时间区间与持续时间	操作与语义属性	在轨迹中的因果作用
根跨度 (s_0)	agent.orchestration	\([0.00, 14.85]\text{ s}\) (\(\Delta t = 14.85\text{ s}\))	追踪 ID 4bf92f35...，模型成本 $0.042，状态 OK	包含根轨迹的完整生命周期
跨度 1 (s_1)	agent.memory（检索）	\([0.00, 0.18]\text{ s}\) (\(\Delta t = 185\text{ ms}\))	查询 "git patch apply syntax"，3 个片段，HNSW 索引	推理前的情景上下文依据获取
跨度 2 (s_2)	gen_ai.client（推理）	\([0.18, 4.25]\text{ s}\) (\(\Delta t = 4.07\text{ s}\))	模型 llama-3-70b，提示 4,096 个词元，输出 256 个词元，TTFT 120 ms	制定计划并生成工具调用
跨度 3 (s_3)	agent.tool（沙箱执行）	\([4.26, 8.46]\text{ s}\) (\(\Delta t = 4.20\text{ s}\))	命令 git apply patch.diff，退出码 0，MicroVM	在隔离沙箱中进行确定性执行
跨度 4 (s_4)	agent.message（子智能体）	\([8.47, 10.32]\text{ s}\) (\(\Delta t = 1.85\text{ s}\))	协议 JSON-RPC，接收方 reviewer-01，哈希 0x9e12a4	异步子智能体委派屏障
跨度 4.1 (s_{4.1})	gen_ai.client（子智能体审查）	\([8.50, 10.28]\text{ s}\) (\(\Delta t = 1.78\text{ s}\))	模型 llama-3-8b，提示 1,024 个词元，输出 128 个词元，TTFT 45 ms	专门的对等审查与验证过程
跨度 5 (s_5)	gen_ai.client（综合）	\([10.33, 14.85]\text{ s}\) (\(\Delta t = 4.52\text{ s}\))	模型 llama-3-70b，提示 6,144 个词元，输出 384 个词元，TTFT 180 ms	最终轨迹综合与任务结束

有向边 \(\mathcal{E}_{\text{causal}} = \{(s_i, s_j)\}\) 表示严格的先发生关系（\(s_i \prec s_j\)），这些关系通过智能体运行时内部的同步栈执行，或通过跨分布式边界显式注入父上下文来建立。

如分布式追踪分解（分布式追踪层次结构）中的形式化描述所示，根跨度 \(s_0\) 涵盖端到端的任务执行。它被分解为直接映射到混合计算域的子跨度：同步向量检索、依赖加速器的模型生成、隔离沙箱中的工具执行，以及向下游子智能体派发任务所形成的异步委派屏障。

图 3: 智能体轨迹的 OpenTelemetry 分布式追踪瀑布图：通过具有层级父子关系的跨度 DAG 和按时间索引的瀑布图，分解一条 14.85 秒执行轨迹中的记忆检索、神经模型推理、隔离沙箱工具执行和异步子智能体同行评审。

图 3 中的分布式追踪瀑布图直观呈现了 分布式追踪层次结构 中记录的运行过程分解。根跨度 \(s_0\)（agent.orchestration）涵盖追踪 ID 4bf92f35... 下长达 14.85 秒的生命周期，产生的模型总成本为 $0.042. Execution commences with span \(s_1\) (agent.memory), consuming 185 ms to query an HNSW index and retrieve three episodic memory chunks. Grounded by this context, the host dispatches planning span \(s_2\) (gen_ai.client) to llama-3-70b over \([0.18, 4.25]\text{ s}\) (\(\Delta t = 4.07\text{ s}\)); the visualization isolates the 120 ms Time-to-First-Token (\(t_{\text{TTFT}}\)) prefill phase across 4,096 prompt tokens from the autoregressive generation of 256 completion tokens. The emitted plan triggers tool span \(s_3\) (agent.tool), which executes git apply patch.diff inside an isolated microVM sandbox over \([4.26, 8.46]\text{ s}\) (\(\Delta t = 4.20\text{ s}\)). The agent then delegates verification across an asynchronous JSON-RPC barrier in span \(s_4\) (agent.message, \(\Delta t = 1.85\text{ s}\)), while downstream subagent reviewer-01 runs child review span \(s_{4.1}\) (gen_ai.client on llama-3-8b, \(\Delta t = 1.78\text{ s}\)). Finally, synthesis span \(s_5\) runs for 4.52 seconds on llama-3-70b to generate the concluding response. The cumulative latency profile at the bottom exposes an immediate systems bottleneck: while neural inference represents 69.8% (10.37 s) of execution time, sandbox tool execution consumes 28.3% (4.20 s). By the Amdahl bound of 轨迹时长核算, infinitely accelerating neural inference can at best yield a \(3.3\times\) end-to-end speedup (\(1/(1 - 0.698)\)），除非同时优化沙箱虚拟化开销和工具 I/O。

智能体系统的 OpenTelemetry 语义约定

虽然通用分布式追踪工具提供了通用的跨度原语，但诊断复杂的智能体故障需要标准化的语义词汇。如果一位工程师将提示长度记录在属性 input_tokens 下，而另一位将其记录为 prompt_size，自动化遥测处理器就无法计算汇总的 token 处理速率、跟踪上下文窗口饱和程度，或触发自动熔断器。

云原生计算基金会（CNCF）通过 OpenTelemetry 生成式 AI 与智能体特别兴趣小组，定义了精确的语义约定，规范智能体执行生命周期各阶段的属性。这些约定确立了四类专用跨度：

模型调用跨度（genai.client / genai.server）

模型调用跨度对智能体宿主监督器与神经推理引擎之间的单次前向事务进行插桩。由于推理分为受计算能力限制的预填充阶段（GEMM）和受内存带宽限制的自回归解码阶段（GEMV），该跨度必须捕获能够区分这两种硬件运行形态的运行指标：

• gen_ai.system：提供商或运行时引擎标识符（例如 vllm、sglang、triton）。
• gen_ai.request.model：智能体请求的逻辑检查点（例如 llama-3-70b-instruct）。
• gen_ai.response.model：部署在服务引擎上的物理检查点版本。
• gen_ai.usage.input_tokens：预填充阶段处理的 token 数量 \(N_{\text{prompt}}\)。
• gen_ai.usage.output_tokens：自回归解码期间生成的 token 数量 \(N_{\text{comp}}\)。
• gen_ai.client.token.time_to_first_token：从请求派发到首个补全 token 到达的实际经过时间延迟 \(t_{\text{TTFT}}\)，用于单独衡量预填充的排队时间和执行时间。
• gen_ai.request.temperature 和 gen_ai.request.top_p：控制解码循环 softmax 分布的随机采样参数。
• gen_ai.response.finish_reasons：终止生成的离散条件，例如 stop（自然序列结束 token）、length（达到上下文窗口限制）或 tool_calls（因模式检测而中断生成）。

工具执行跨度（agent.tool）

根据最小权限原则，智能体监督器通过结构化工具接口，将具有副作用的操作委托给外部环境。工具执行跨度对完整的派发生命周期进行插桩，捕获无特权的操作提议、调解边界以及环境的实际响应：

• agent.tool.name：正在执行的工具的规范标识符（例如，bash、file_editor、sql_query）。
• agent.tool.type：结构化执行域（例如，subprocess、rpc、in_memory）。
• agent.tool.call_id：将本次执行关联到模型发起此次执行的 tool_call 对象的加密标识符或序列标识符。
• agent.tool.args：传递给工具的结构化输入参数，序列化为经过验证的 JSON。
• agent.tool.exit_code：目标进程返回的 POSIX 返回码或应用状态指示值。
• agent.tool.stdout_bytes 和 agent.tool.stderr_bytes：标准输出流和标准错误流的大小，既可防止数 GB 的命令输出转储阻塞日志流水线，又能保留计量数据。

记忆检索跨度（agent.memory）

当智能体查询长期情景记忆或语义记忆存储时，记忆检索跨度会记录文本查询转换为潜在向量表示的过程，以及随后遍历索引的过程：

• agent.memory.operation：事务类别（例如，query、upsert、delete）。
• agent.memory.index_name：操作所针对的逻辑命名空间或数据库表。
• agent.memory.top_k：请求的候选近邻数量 \(k\)。
• agent.memory.similarity_metric：决定遍历方式的距离度量（例如，cosine、dot_product、euclidean）。
• agent.memory.retrieved_chunks：返回到智能体上下文中的文档片段数量，以整数表示。
• agent.memory.scores：与检索出的候选项对应的浮点相似度值数组，对检测语义漂移或低置信度上下文污染至关重要。

多智能体消息跨度（agent.message）

在多个自主智能体协作的分布式拓扑中，消息跨度用于对智能体间的共识和委派机制进行插桩：

• agent.message.sender_id：发起智能体的不可变标识符。
• agent.message.recipient_id：目标智能体或多播通道的标识符。
• agent.message.envelope_hash：序列化消息信封的加密哈希值（例如，SHA-256），用于验证载荷，而无需在追踪存储中重复保存消息正文。
• agent.message.protocol：应用层协同协议（例如，json_rpc、actor_tell、blackboard_write）。

这些跨度类别的核心语义属性、因果链接和可检测的故障模式汇总于 表 4。

表 4: 面向智能体系统的 OpenTelemetry 语义约定跨度分类体系：跨度类别、主要执行域、核心语义属性、因果父级链接和可检测的故障特征。

跨度类别	主要领域	核心语义属性	因果父级链接	可检测的故障特征
gen_ai.client	加速器 / 推理运行时	gen_ai.usage.input_tokens、output_tokens、time_to_first_token、finish_reasons	任务根跨度或监督步骤跨度	上下文长度截断、预填充队列饥饿、解码循环
agent.tool	沙箱化 POSIX 子进程 / RPC	agent.tool.name、args、exit_code、stdout_bytes、stderr_bytes	包含工具调用的模型调用跨度	工具模式违规、命令超时、容器崩溃
agent.memory	向量数据库 / 嵌入	agent.memory.operation、top_k、similarity_metric、scores	需要依据支撑的推理步骤跨度	无关上下文注入、零命中查询、索引延迟
agent.message	智能体间传输互连结构	agent.message.sender_id、recipient_id、envelope_hash、protocol	发出调度的智能体的审议跨度	死锁、无限委派循环、共识投票丢失

跨非网络边界的因果上下文传播

对智能体系统进行插桩时，首要的机制性难题在于上下文传播。在标准 Web 服务中，中间件库通过向出站网络调用注入 HTTP 标头来解决分布式上下文传播问题。然而，智能体监督器经常跨越不使用 HTTP 或 gRPC 网络层的边界来调度操作：它在容器内创建本地 POSIX 进程、执行任意 bash 命令、查询本地文件缓存，并向消息队列写入数据。

为了在这些非网络接口之间维持连续的因果 DAG，智能体运行时必须实现符合 W3C Trace Context 规范的上下文序列化和提取协议。该标准将追踪上下文编码在 traceparent 标头中，该标头是一个由 4 个字段组成、以连字符分隔的字符串，格式为 00-${trace_id}-${span_id}-${trace_flags}。

调用沙箱化 shell 工具时，监督器无法依赖网络中间件。它必须显式地将序列化的追踪上下文注入沙箱环境，注入形式可以是 POSIX 环境变量，也可以是命令行信封包装器。在沙箱内部，经过插桩的 CLI 工具或子脚本读取 TRACEPARENT 环境变量，提取当前有效的 trace_id 和 span_id，并将自身注册为全局执行图中的合法子跨度。

def execute_traced_tool(cmd: list[str], parent_span: Span) -> tuple[int, str]:
    carrier = {}
    TraceContextTextMapPropagator().inject(carrier)
    env = {**os.environ, "TRACEPARENT": carrier["traceparent"]}
    with tracer.start_as_current_span("agent.tool", context=parent_span.get_context()) as span:
        span.set_attribute("agent.tool.name", cmd[0])
        span.set_attribute("agent.tool.args", json.dumps(cmd[1:]))
        proc = subprocess.run(cmd, env=env, capture_output=True, text=True, timeout=15)
        span.set_attribute("agent.tool.exit_code", proc.returncode)
        span.set_attribute("agent.tool.stdout_bytes", len(proc.stdout.encode("utf-8")))
        if proc.returncode != 0:
            span.record_exception(Exception(proc.stderr[:512]))
        return proc.returncode, proc.stdout

前面的实现展示了这种边界跨越。运行时从 parent_span 中提取当前活动的追踪上下文，将 W3C traceparent 表示注入进程环境字典，并将执行过程封装在专用的 agent.tool 跨度中。关键在于，该跨度记录了实际工具名称、参数模式、进程返回码和载荷字节大小。如果进程遇到非零退出码或终止性异常，则通过 record_exception 将该失败直接关联到当前活动跨度，从而保留确切的执行上下文，同时不截断外围的追踪层级。

粗略估算 0.3: 关键路径延迟分解

考虑一个自主编码智能体，它执行一个包含 5 个步骤的循环：检索文档、生成代码补丁、在容器沙箱中执行测试套件、并行向两个子智能体分发审查请求，以及综合生成最终的拉取请求。

宿主监督程序在根追踪 \(\mathcal{T}_{\text{root}}\) 下对整条轨迹进行插桩，并观测到总墙钟耗时为 \(T_{\text{wall}} = 18.25\text{ s}\)。底层 OpenTelemetry 跨度记录了以下硬件与执行参数：

1. 向量记忆检索跨度：
   • 输入：1 个查询字符串。输出：排名前 \(k=5\) 的片段（共 \(2{,}048\) 个词元）。
   • 执行：先生成嵌入（\(t_{\text{embed}} = 35\text{ ms}\)），再遍历 HNSW 向量索引（\(t_{\text{index}} = 45\text{ ms}\)）。
   • 跨度耗时：\(t_1 = 80\text{ ms} = 0.08\text{ s}\)。
2. 模型调用跨度（补丁生成）：

   • 硬件：运行 vLLM 的 8 块 NVIDIA H100 SXM5 GPU 集群。总内存带宽为 \(B_{\text{mem}} = 8 \times 3.35\text{ TB/s} = 26.8\text{ TB/s}\)。

   • 工作负载：输入提示包含 \(N_{\text{prompt}} = 8{,}192\) 个词元；生成的补全文本包含 \(N_{\text{comp}} = 512\) 个词元。

   • 预填充阶段：处理 \(N_{\text{prompt}}\)，有效吞吐量为 \(4{,}000\text{ tokens/s}\)： \[t_{\text{prefill}} = \frac{8{,}192\text{ tokens}}{4{,}000\text{ tokens/s}} = 2.05\text{ s}\]

   • 解码阶段：采用 FP8 精度的 700 亿参数模型（每次前向传播 \(70 \times 10^9\text{ bytes} = 70\text{ GB}\)）。 在包含 8 块 GPU 的节点上，受内存带宽限制的每步词元解码时间理论值为： \[t_{\text{step}} = \frac{70\text{ GB}}{26{,}800\text{ GB/s}} \approx 2.61\text{ ms/token}\] 生成 \(512\) 个词元产生的自回归解码延迟为： \[t_{\text{decode}} = 512 \times 2.61\text{ ms} = 1.34\text{ s}\]

   • 跨度耗时：\(t_2 = t_{\text{prefill}} + t_{\text{decode}} = 2.05\text{ s} + 1.34\text{ s} = 3.39\text{ s}\)。

3. 沙箱化工具执行跨度（pytest）：
   • 工作负载：MicroVM 容器初始化、磁盘同步和测试执行。
   • 跨度耗时：\(t_3 = 6.20\text{ s}\)。
4. 多智能体消息分发跨度（代码审查）：
   • 监督程序将补丁同时分发给子智能体 A（代码风格检查器）和子智能体 B（安全分析器）。
   • 子智能体 A 的跨度：\(t_{4a} = 2.10\text{ s}\)。
   • 子智能体 B 的跨度：\(t_{4b} = 3.85\text{ s}\)。
   • 由于这些跨度并发执行，屏障等待延迟为： \[t_4 = \max(t_{4a}, t_{4b}) = 3.85\text{ s}\]
5. 模型调用跨度（最终综合）：
   • 工作负载：\(N_{\text{prompt}} = 12{,}288\) 个词元，\(N_{\text{comp}} = 256\) 个词元。
   • 预填充耗时：\(t_{\text{prefill}} = 3.07\text{ s}\)；解码耗时：\(t_{\text{decode}} = 0.67\text{ s}\)。
   • 跨度耗时：\(t_5 = 3.74\text{ s}\)。

关键路径分析： 为确定智能体的性能受限于计算、I/O 还是协同，系统工程师沿具有因果关系的关键路径对各跨度耗时求和：

\[T_{\text{crit}} = t_1 + t_2 + t_3 + \max(t_{4a}, t_{4b}) + t_5\] \[T_{\text{crit}} = 0.08\text{ s} + 3.39\text{ s} + 6.20\text{ s} + 3.85\text{ s} + 3.74\text{ s} = 17.26\text{ s}\]

剩余延迟（\(T_{\text{wall}} - T_{\text{crit}} = 18.25\text{ s} - 17.26\text{ s} = 0.99\text{ s}\)，即 {python} CriticalPathLatencyDecomposition.pct_orchestration_str）表示宿主运行时的编排开销（JSON 序列化、进程上下文切换和 RPC 队列等待时间）。

对关键路径的分解揭示了主导系统运行的瓶颈：

• 沙箱化工具执行占关键路径时间的 {python} CriticalPathLatencyDecomposition.pct_tool_str（\(6.20\text{ s}\)）。
• 神经网络模型推理占 {python} CriticalPathLatencyDecomposition.pct_model_str（\(3.39\text{ s} + 3.74\text{ s} = 7.13\text{ s}\)）。
• 多智能体协同屏障占 {python} CriticalPathLatencyDecomposition.pct_barrier_str（\(3.85\text{ s}\)）。
• 向量检索仅占 {python} CriticalPathLatencyDecomposition.pct_retrieval_str（\(0.08\text{ s}\)）。

如果没有分布式追踪，工程师可能会凭直觉尝试优化检索延迟或升级 GPU 硬件。追踪数据明确否定了这两种直觉：记忆检索的耗时可以忽略不计，而工具执行和并行子智能体的延迟主导了推理过程。优化该系统需要解决步骤 3 中的沙箱 I/O 开销，以及步骤 4 中子智能体 B 的拖尾延迟。

Checkpoint 0.2: 评估分布式轨迹追踪与跨度

在分析基于尾部的采样预算和信息脱敏流水线之前，请检验你对轨迹插桩的理解：

• 混合 DAG 跨度：分布式追踪树如何同时表示毫秒级的神经网络解码跨度和持续数分钟的 POSIX 工具跨度？
• 附带信息传播：为什么 OpenTelemetry 追踪上下文和关联 ID 必须跨越容器与 microVM 的虚拟化边界？
• 数据量激增：与标准微服务 RPC 跨度相比，采集完整的提示上下文和原始工具 I/O 会如何增加追踪存储量？
• 关键路径分析：对跨度持续时间的细分分析如何避免将工程资源错误地投入向量检索等快速子系统？

基于尾部的采样预算

一个每小时编排数千条自主智能体轨迹的企业平台，会遭遇传统分布式追踪系统在设计时从未考虑过的遥测物理资源困境。在微服务架构中，单个 OpenTelemetry 跨度通常记录一次轻量级远程过程调用（RPC），内容包括 HTTP 元数据、数据库查询文本和微秒级执行耗时，每条端到端追踪产生的数据量约为二至五千字节。与此形成鲜明对比的是，自主智能体在执行复杂任务时，会在数十个自回归推理步骤、沙箱终端交互和外部工具调用中不断积累历史记录。由于每一轮都必须保留复现智能体内部状态机所需的确切输入上下文、生成的补全词元、工具参数以及标准 I/O 流，单条轨迹追踪通常会占用数十兆字节的原始结构化数据。

持久化保存企业智能体集群中的每一条生产追踪，会迅速耗尽网络出口带宽，并使下游可观测性存储集群被数拍字节的冗余、缺乏有效信息的执行日志淹没。然而，采用传统的基于头部的采样方式——在轨迹开始时随机选取固定比例的追踪——会严重削弱事故后的可靠性工程能力。在基准成功率较高的自主软件系统中，工程师必须检查的关键运行信号，例如沙箱权限违规、多轮推理循环和罕见的工具超时，出现在不到 1% 的执行中。在入口处随机丢弃 99% 的传入任务追踪，意味着当灾难性故障破坏生产数据时，诊断根因所需的因果遥测追踪早在错误显现之前就已被丢弃。因此，管理自主智能体的可观测性开销，需要在架构上从盲目的基于头部的过滤转向能够感知状态的、基于尾部的采样缓冲区，并结合基于密码学的隐私脱敏。

遥测数据量激增

要理解为什么简单的遥测采集方式会在智能体工作负载下崩溃，可以考察智能体自回归执行循环中上下文累积所遵循的数学关系。设智能体轨迹 \(\tau\) 包含 \(T\) 个依次进行的推理与执行轮次：

\[\tau = (s_0, a_0, o_0, s_1, a_1, o_1, \dots, s_T)\]

在每一轮 \(t \in \{1, \dots, T\}\) 中，宿主监督程序会构造一个模型提示，其中包含系统指令、由过去的动作和工具观测累积而成的历史序列，以及当前任务状态。如果第 \(t\) 轮的提示包含 \(L_t\) 个词元，且模型输出 \(K_t\) 个词元，那么该步骤产生的未压缩文本量会随上下文长度成比例增长。

基于头部的采样与基于尾部的采样 基于头部的采样在步骤 \(t=0\) 到达时，就作出不可逆的保留决策，此时执行结果或系统轨迹尚不明确。基于尾部的采样在整个执行过程中将跨度缓存在内存中，只有在终止状态 \(s_T\) 和奖励 \(r\) 确定之后，才对策略谓词进行求值。

由于对话历史会随每次交互单调扩展，多轮会话中累积的上下文大小并非保持不变；当每一步的历史记录都完整复制到跨度载荷中时，它会随轮次数 \(T\) 呈二次增长：

\[V_{\text{tokens}} = \sum_{t=1}^T \left( L_0 + \sum_{j=0}^{t-1} (|a_j| + |o_j|) + K_t \right) = \mathcal{O}\left(T \cdot L_0 + T^2 \cdot (\overline{|a|} + \overline{|o|})\right)\]

当这些文本与向量相似度分数、模型生成超参数、环境变量，以及沙箱工具执行产生的 stdout/stderr 缓冲区一起序列化为标准 OpenTelemetry 属性时，每轮产生的遥测载荷平均介于 \(30\text{ KB}\) 和 \(150\text{ KB}\) 之间。对于在 32,768 词元上下文窗口内运行的五十轮轨迹，将每一个中间提示和原始观测都序列化后，单条追踪的大小会从 \(5\text{ MB}\) 到超过 \(25\text{ MB}\) 不等，各组成部分的分布详见 表 5。

表 5: 遥测载荷占用量：每个智能体执行轮次的遥测载荷占用量（45 KB 基线）。

遥测组件	载荷大小	占比 (%)	序列化格式	摄取缓解策略
系统提示词与工具模式	8 KB	17.8%	JSON / 静态 Protobuf	基于指针的内容寻址模式去重
多轮上下文历史	24 KB	53.3%	UTF-8 字符串数组	增量编码与检查点引用
原始 LLM 输出与 Logits	3 KB	6.7%	Protobuf / BFloat16	最高对数概率截断与压缩
工具执行标准输出/标准错误	9 KB	20.0%	二进制流 / 分块文本	结合密码学摘要的滑动窗口截断
跨度属性与指标	1 KB	2.2%	OTel 键值映射	标准结构化指标编码

经典分布式追踪架构通过在追踪客户端或摄取代理中实施头部采样来应对海量数据，Dapper 等系统推动了这种方法的普及 (Sigelman 等 2010年)。在头部采样中，传入请求会被分配一个服从均匀分布的伪随机标识符；如果该标识符的哈希值低于预先设定的采样比例 \(\theta \in (0, 1]\)，追踪头就会沿下游 RPC 传播，并记录整条追踪。如果哈希值超过 \(\theta\)，则立即在根跨度处停止采集追踪。

在请求持续时间为毫秒级、故障在统计上呈均匀分布的确定性客户端—服务器架构中，头部采样能够无偏地反映系统延迟分布 (Dean 和 Barroso 2013年)。然而，对于自主智能体系统，头部采样会引入一种破坏性极强的采样病态现象。假设一个智能体集群每天处理 \(N = 100{,}000\) 个生产任务，观测到的任务失败率为 \(p_{\text{fail}} = 0.01\)（1%）。如果基础设施团队采用百分之十的头部采样预算（\(\theta = 0.10\)），以使遥测摄取量保持在已配置的存储配额之内，那么被捕获的失败事件的概率分布就会严重劣化。

在部署期间捕获到的失败轨迹的期望数量为：

\[\mathbb{E}[N_{\text{captured\_failures}}] = N \cdot p_{\text{fail}} \cdot \theta = 100{,}000 \times 0.01 \times 0.10 = 100\]

在 1,000 次生产任务失败中，恰有 900 次失败会在网关处被不可逆地丢弃，此时智能体甚至还未执行第一步。更关键的是，如果某种特定失败模式属于罕见的边缘情况，例如灾难性的文件删除循环，或仅在 \(0.05\%\) 的运行中发生的身份验证失败（总计 \(50\) 起事件），那么该失败模式所捕获追踪的期望数量会降至：

\[\mathbb{E}[N_{\text{rare\_failures}}] = 100{,}000 \times 0.0005 \times 0.10 = 5\]

由于追踪捕获具有随机性，且与运行时行为无关，因此存在相当大的概率：

\[P(\text{zero captured}) = (1 - \theta)^{50} = (0.90)^{50} \approx 0.00515\]

使得某种异常行为在整个集群中几乎不留下任何取证痕迹。反过来，遥测流水线会耗费其已分配摄取带宽的 90%，来捕获 \(9{,}900\) 条平常且完全相同的成功追踪，而这些追踪对系统工程师毫无诊断价值。

头部采样迫使人们在存储容量无法承受与诊断盲区之间作出虚假的二选一。头部采样在智能体系统中的根本架构缺陷在于：保留遥测数据的决策是在不确定性最大的时刻作出的，即在第 \(t=0\) 轮，非确定性策略尚未执行第一个动作、遭遇第一个工具错误，或陷入无限执行循环之前。

粗略估算 0.4: 遥测摄取的倒置经济性

考虑一个自主软件工程智能体部署，其分布式工作节点集群每小时执行 10,000 项任务。

集群工作负载参数：

• 活跃任务吞吐量：\(\lambda = 10{,}000\text{ tasks/hour} \approx 2.78\text{ tasks/s}\)。
• 平均轨迹深度：\(\overline{T} = 35\text{ turns}\)。
• 每轮平均序列化遥测数据量：\(\overline{S_{\text{turn}}} = 40\text{ KB}\)。
• 平均追踪数据大小：\(\overline{S_{\text{trace}}} = 35 \times 40\text{ KB} = 1.40\text{ MB}\)。
• 任务结果分布：\(95\%\) 常规成功任务（\(r = 1.0\)）、\(4\%\) 执行失败任务（\(r = 0.0\)）、\(1\%\) 高延迟拖尾任务（持续时间为 \(p99\)）。

场景 A：100% 全量保留（不采样）

• 摄取数据速率： \[B_{\text{full}} = 2.78\text{ tasks/s} \times 1.40\text{ MB/task} = 3.89\text{ MB/s} \approx 31.1\text{ Mbps}\]

• 每日遥测存储量： \[V_{\text{daily}} = 10{,}000\text{ tasks/hour} \times 24\text{ hours} \times 1.40\text{ MB} = 336\text{ GB/day}\]

• 每月未压缩摄取量：\(10.08\text{ TB/month}\)。在具有多智能体扇出和 100 轮任务的企业环境中，这一摄取量会扩展至超过 \(150\text{ TB/month}\)，导致云可观测性费用经常超过模型推理本身的支出。

场景 B：5% 头部采样（\(\theta = 0.05\)）

• 每小时保留的任务数：\(500\text{ tasks/hour}\)。
• 每日遥测存储量：\(16.8\text{ GB/day}\)。
• 每小时捕获的失败任务数：\(10{,}000 \times 0.04 \times 0.05 = 20\text{ failures/hour}\)（实际失败任务共 400 项）。
• 丢弃的失败任务数：\(380\text{ failures/hour}\)（生产环境中全部缺陷的 \(95\%\) 丢失）。

场景 C：状态感知的尾部采样

• 保留 \(100\%\) 的失败任务（\(400\text{ tasks/hour} \times 1.40\text{ MB} = 560\text{ MB/hour}\)）。

• 保留 \(100\%\) 的拖尾任务（\(100\text{ tasks/hour} \times 1.40\text{ MB} = 140\text{ MB/hour}\)）。

• 将常规成功任务下采样至 \(2\%\)（\(9{,}500 \times 0.02 = 190\text{ tasks/hour} \times 1.40\text{ MB} = 266\text{ MB/hour}\)）。

• 遥测总存储量： \[V_{\text{tail}} = (560 + 140 + 266)\text{ MB/hour} = 966\text{ MB/hour} \approx 23.2\text{ GB/day}\]

• 相对于全量日志记录的摄取量降幅： \[\text{Data Reduction} = 1 - \frac{23.2}{336} = 93.1\%\]

尾部采样架构依据执行终态属性而非初始随机选择来保留遥测数据，将存储量缩减至原来的 1/({python} TelemetryIngestionInvertedEconomics.reduction_mult_str)，同时捕获全部运行失败和性能异常中的 \(100\%\)。

尾部路由策略

为避免头部采样固有的信息损失，智能体运行时实现了尾部采样。在尾部采样架构中，保留或丢弃追踪的决策会推迟到轨迹终止或越过明确的运行异常阈值时才做出。

实现尾部采样需要一个低延迟的中间遥测缓冲区，能够在任务的整个生命周期内将尚未完成的跨度保存在内存中。智能体执行时，其生成的跨度涵盖模型请求、向量检索、沙箱命令和智能体间消息，并直接以流式方式传入内存中的追踪暂存缓冲区；该缓冲区作为同节点部署的边车进程运行，或运行于临时追踪收集器集群中。收集器按各跨度所属的根 trace_id 对跨度分组。跨度会驻留在暂存缓冲区中，直到智能体运行时发出终态事件，或外部监督程序标记出不变量违反事件。

图 4: 面向智能体轨迹遥测的尾部采样流水线：通过内存追踪暂存缓冲区、数据出站前的秘密信息脱敏、确定性异常分类级联，以及按优先级划分的目标持久化层级，在不遗漏执行异常的情况下，将集群存储量减少 93.1%。

图 4 中的架构流水线通过三个物理处理阶段，明确规定了智能体遥测的完整生命周期。在阶段 1，由 \(C=128\) 个工作节点组成的并发集群生成的流式跨度 DAG（摄取量为 336.0 GB/天）流入容量设为 \(M_{\text{escrow}} \ge 2.0\text{ GB RAM}\) 的内存环形暂存缓冲区。在跨度跨越节点边界之前，内联正则表达式与命名实体识别（NER）脱敏过滤器会清除 API 凭据、持有者令牌和客户个人身份信息（PII）。在阶段 2，已完成的轨迹触发由匹配 表 6 的确定性路由谓词组成的优先级级联：优先级 1（沙箱故障、模式错误和安全机制触发）保留 100% 的追踪（560 MB/小时）；优先级 2（延迟拖尾任务 \(>p99\)、提示词膨胀 \(>p95\)，或轮数 \(>3\times\) 中位数）保留 100%（140 MB/小时）；优先级 3（人工覆盖和权限提升）保留 100%（28 MB/小时）；优先级 4（持续时间 \(\le p90\) 的常规已验证完成任务）则应用 2% 的均匀下采样规则（266 MB/小时），将其余 98% 从内存中释放。在阶段 3，遥测路由器将追踪分发到专门的后端层级：100% 的异常轨迹和升级处理轨迹持久化到取证事件队列，用于自动生成回归测试，而采样得到的正常运行记录则流入高基数列式 OLAP 存储（例如 ClickHouse 或对象存储上的 Parquet）。这种多层架构将集群传输数据的存储量从 336.0 GB/天削减至 23.2 GB/天，降幅为 93.1%（\(14.5\times\)），同时保证以比特级精确度捕获每一个异常执行事件。

表 6: 尾部追踪采样策略与保留标准：轨迹类别、分类谓词、保留目标、采样比例和工程用途。

轨迹类别	分类谓词	采样策略	主要工程用途
失败与违规	沙箱退出码非零；模式验证错误；上下文预算耗尽；触发安全不变量。	\(100\%\) 保留率	取证式根因分析；回归测试生成；模型补丁验证。
延迟与词元异常值	执行持续时间 \(> p99\)；提示词词元数 \(> p95\)；轮数 \(T > 3\times\) 中位数。	\(100\%\) 保留率	识别自回归循环、提示词膨胀和沙箱 I/O 瓶颈。
人工干预	用户发起覆盖操作；监督工具取消操作；请求手动提升权限。	\(100\%\) 保留率	对齐失败诊断；边界情况发现；微调数据集整理。
常规成功	任务目标已验证（\(r = 1.0\)）；持续时间 \(\le p90\)；工具故障数为零。	\(1\%\text{--}5\%\) 动态采样	长期漂移监控；基准延迟核算；模型性能跟踪。

控制追踪从暂存缓冲区中逐出的决策逻辑必须以确定性方式运行。当智能体轨迹结束时，宿主监督程序会评估终态记录，并在关闭追踪上下文之前，将路由指令属性（sampling.priority）附加到根跨度上。

# Low-overhead tail-sampling classification predicate
def classify_trajectory_sampling(trace: TrajectoryTrace) -> float:
    if trace.has_policy_violation or trace.exit_code != 0:
        return 1.0  # Retain 100% of faults and security errors
    if trace.human_intervened:
        return 1.0  # Retain 100% of supervisor escalations
    if trace.duration_ms > LATENCY_P99_THRESHOLD_MS:
        return 1.0  # Retain 100% of severe latency stragglers
    if trace.total_tokens > TOKEN_BUDGET_P95_THRESHOLD:
        return 1.0  # Retain 100% of context-thrashing runs
    return 0.02     # Downsample routine completions to 2%

基于尾部的采样面临一项关键的系统约束：轨迹暂存环形缓冲区的物理容量配置。由于智能体任务可能持续数十分钟，远超微服务 RPC 不足一秒的生命周期，将未压缩的轨迹保存在内存中会给工作节点带来显著的内存压力。

令 \(C\) 表示一个节点上并发执行的智能体轨迹数量，\(\overline{T_{\text{task}}}\) 表示以秒为单位的平均任务持续时间，\(\beta\) 表示以字节每秒为单位的未压缩遥测数据生成速率：

\[\beta = \frac{\overline{S_{\text{trace}}}}{\overline{T_{\text{task}}}}\]

为防止轨迹被过早逐出，所需的最小稳态暂存缓冲区内存 \(M_{\text{escrow}}\) 为：

\[M_{\text{escrow}} \ge C \cdot \overline{T_{\text{task}}} \cdot \beta = C \cdot \overline{S_{\text{trace}}}\]

如果单个工作节点承载 \(C = 128\) 个并发沙箱会话，且平均轨迹占用空间为 \(\overline{S_{\text{trace}}} = 15\text{ MB}\)，则该节点必须专门划拨近 \(2\text{ GB}\) 的高速 RAM，用于中间遥测数据的缓冲。

为防止突发并发激增或级联慢任务事件导致内存耗尽，暂存引擎必须实现两项架构保障措施。首先，暂存的跨度必须使用轻量级、面向块的压缩算法进行压缩，例如 LZ4 或压缩级别为 1 的 Zstandard；实测基准表明，这些算法对重复的自然语言和 JSON 模式可达到 \(3.5\times\) 的压缩比，同时消耗的主机 CPU 周期不到 2%。其次，暂存缓冲区必须设置明确的内存上限，并对常规成功执行采用最旧优先的环形逐出策略：如果缓冲区使用量达到容量的 85%，则立即丢弃常规成功执行的跨度，同时严格保护异常和错误跨度，防止其被过早逐出。

暂存逐出不变量 在内存压力下，暂存缓冲区必须先丢弃未分类或常规成功执行的轨迹，然后才能逐出任何标记为 exit_code != 0 或 policy_violation = True 的轨迹。错误遥测数据所占的内存受到保护。

密码学机密信息脱敏

虽然基于尾部的采样解决了数据量危机，但它也加剧了一个同样严重的安全与合规漏洞，即敏感信息向可观测性后端泄露。模型不持有任何环境权限，但其运行的任务会读取专有代码仓库、客户私有数据库、内部 API 和配置文件。读取访问本身就是一种权限暴露（H·S·A 暴露面），因为智能体读取的任何内容都可能通过任何能够将其传送到外部的通道流出，而遥测正是这样一种通道。在标准执行过程中，模型的提示词和工具输出不可避免地会包含机密内容：

1. 身份验证机密： AWS 访问密钥（AKIA...）、GitHub 个人访问令牌（ghp_...）、Bearer 令牌、SSH 私钥，以及内嵌明文密码的数据库连接字符串。
2. 个人身份信息（PII）： 数据处理任务中遇到的客户姓名、国家身份证件号码、信用卡号码序列、实际地址和电子邮件标头。
3. 内部知识产权： 专有源代码算法、公司机密财务预测和保密架构模式。

如果一个非特权智能体执行了诸如 env 的 bash 命令，或为执行已获授权的数据库迁移而读取凭据文件，那么该私密信息就会被直接序列化到表示标准输出的 OpenTelemetry 跨度属性中。一旦传输到集中式、第三方或多租户可观测性平台（例如 Datadog、Jaeger 或云托管的遥测数据湖），该机密信息就会以明文形式建立索引。这会形成严重的权限提升途径：任何拥有生产遥测轨迹读取权限的开发人员、承包商或自动化分析脚本，都会突然获得对智能体集群所处理全部凭据的环境访问权限。

为满足最小权限原则，遥测数据必须在跨越执行沙箱的隔离边界之前，经过自动化且保护隐私的净化处理。净化处理不能推迟到沙箱外的下游遥测聚合器中进行；一旦机密信息通过未加密的本地套接字或明文采集器流水线离开隔离执行环境，隔离边界就已从根本上被突破。

表 7: 遥测数据净化流水线：沙箱内流式遥测数据净化流水线的各个阶段。

过滤阶段	目标威胁类别	检测与匹配模式	转换操作	计算开销
阶段 1：高熵过滤器	硬编码 API 密钥与云凭据	正则表达式模式（例如，AKIA...、ghp_...、香农熵 \(H > 4.5\)）	脱敏令牌替换 [REDACTED:API_KEY:<hash_8>]	每 KB \(< 0.2\text{ ms}\)
阶段 2：HMAC 引擎	租户标识符、用户 ID、账号	UUID 正则表达式、数据库主键、电子邮件身份标识	单向带密钥变换 \(\text{HMAC-SHA256}(k_{\text{salt}}, v)\)	每条记录 \(< 0.5\text{ ms}\)
阶段 3：本地 PII 分类器	非结构化 PII（姓名、地址、银行卡）	设备端轻量级 NER / 正则表达式规则	语义令牌替换 [REDACTED:PII_CLASS]	每 KB \(1.5\text{--}3.0\text{ ms}\)
出口托管关卡	向外部采集器泄露明文	流式零知识字节扫描器	检测到泄露时丢弃相应片段或进行隔离	\(< 0.1\text{ ms}\) 流处理开销

如 表 7 所概述，沙箱内净化流水线实现了多阶段流式过滤器，在序列化之前拦截所有跨度属性、提示字符串和工具 I/O 载荷：

高熵模式匹配

结构化秘密信息（例如 API 令牌、加密私钥和授权标头）具有明显的语法前缀和较高的字符熵。净化器使用一组已编译的确定性正则表达式检查所有出站文本缓冲区，以匹配已知云服务提供商的特征模式（例如 Google Cloud API 密钥、Slack webhook URL、Stripe 生产环境密钥）。

为了捕获自定义或非结构化秘密信息，过滤器计算香农熵 \(H(X)\)，计算范围为长度为 \(W\) 的滑动字节窗口：

\[H(X) = -\sum_{i=1}^{n} P(x_i) \log_2 P(x_i)\]

其中，\(P(x_i)\) 表示字符 \(x_i\) 在窗口内的经验频率。Base64 编码的秘密信息和十六进制加密密钥的香农熵值通常满足 \(H(X) \ge 4.5\text{ bits/byte}\)，而标准源代码和自然语言文本的香农熵值很少超过 \(3.2\text{ bits/byte}\)。任何超过熵阈值的令牌序列都会被删除，并替换为结构化墓碑标记：[REDACTED:ENTROPY_KEY:sha256_prefix]。

确定性 HMAC 假名化

完全掩盖标识符会破坏对分布式追踪进行取证因果分析的能力。如果某个客户标识符 user_89412 导致智能体工作流在五个独立会话中崩溃，那么将其每次出现都替换为通用字符串 [REDACTED_USER]，就会使工程师无法识别出这五次故障都源于同一个已损坏的客户档案。

为了在不暴露原始标识符的情况下保留跨追踪关联能力，净化器采用基于密钥散列消息认证码（HMAC）的假名化处理，使用临时盐值 \(S_{\text{ephemeral}}\)，并按二十四小时的周期轮换：

\[\text{Pseudonym}(x) = \text{Truncate}_{12}\left(\text{HMAC-SHA256}(S_{\text{ephemeral}}, x)\right)\]

原始标识符 user_89412 被改写为 ID:b8f3a9e21c04。在单个运行周期内，所有引用该实体的追踪都保持结构上的关联，使聚类算法能够识别实体特有的故障模式，同时确保检查追踪日志的工程师在未经授权访问安全密钥管理服务的情况下，无法将假名映射回其背后的个人身份。

轻量级本地命名实体识别（NER）

非结构化 PII（例如嵌入自然语言指令中的人名、街道地址和医学术语）无法通过静态正则表达式可靠地检测出来。然而，调用外部云 API 扫描每个中间轮次会引入循环依赖、难以承受的延迟开销以及额外的安全暴露风险。

运行时通过直接在监督器主机边界内部署经过优化和量化的本地序列分类模型（例如采用 4 位量化的 DistilBERT 或紧凑的 ONNX-runtime 令牌分类器）来解决这一问题。该本地模型在每千字节文本低于三毫秒的推理延迟预算内运行，标注需要删除的实体边界，并将实体替换为通用实体标签（[REDACTED:PERSON]、[REDACTED:LOCATION]）。

# Streaming in-sandbox telemetry scrubber interface
def sanitize_telemetry_payload(raw_text: str, salt: bytes) -> str:
    # Pass 1: Deterministic regex and Shannon entropy redaction
    scrubbed = SECRET_REGEX_SUITE.sub("[REDACTED:SECRET]", raw_text)
    scrubbed = entropy_filter(scrubbed, threshold=4.5)

    # Pass 2: Consistent HMAC pseudonymization for session identifiers
    scrubbed = ID_PATTERN.sub(
        lambda m: f"ID:{hmac.new(salt, m.group(0).encode(), hashlib.sha256).hexdigest()[:12]}",
        scrubbed
    )

    # Pass 3: Local lightweight entity masking
    return local_ner_classifier.mask_entities(scrubbed)

通过将沙箱内的密码学脱敏与状态感知的尾部采样相结合，智能体平台建立了可辩护的遥测边界。平台系统性地捕获难以发现的长尾故障，这些故障对于稳定复杂自主系统至关重要，同时避免被数 PB 缺乏有效信息的日志淹没，也不会损害生产数据的基本隐私。

---

事件取证复盘

当尾部采样引擎成功保留异常、高延迟或失败的轨迹时，原始遥测追踪就构成了运行故障不可变的因果记录。然而，捕获的追踪仅仅是诊断证据；它无法解释非确定性策略为何偏离预期轨迹，也无法说明究竟是哪次工具交互引发了系统性崩溃。要将孤立的错误追踪转化为可实施、持久有效的软件修复，需要采用严谨的复盘分析工程方法。这一取证挑战促使我们采用轨迹重放与反事实消融的系统性技术。

当自主智能体在生产环境中崩溃或产生灾难性副作用时，经典调试范式立即失效。在传统的确定性软件中，工程师可以附加符号调试器、检查确定性的核心转储，或沿执行栈向后回溯，以定位导致故障的指令。在智能体机器学习系统中，可观测的故障表现——例如智能体执行不可恢复的文件系统删除操作，或陷入无限的词元生成循环——很少与底层缺陷出现在同一位置。由于宿主运行时将规划与工具调用合成委托给一个无特权、在非零采样温度下运行的自回归基础模型（\(\tau > 0\)），某次在步骤 \(t=14\) 失败的运行，可能早在步骤 \(t=2\) 就已被截断的工具载荷致命地污染，该载荷悄然破坏了模型的认知状态。此外，尝试通过让智能体再次访问在线生产微服务来复现缺陷，会引入破坏性副作用、违反状态隔离要求，并且由于外部环境漂移，无法保证获得相同的观测。

诊断失败轨迹需要结构化的复盘取证：重放已记录的观测、隔离组件故障假设，并开展受控的反事实消融。

如果没有系统性的取证规程，系统团队就会默认采用一种不科学的反模式：将每次运行故障都视为难以解释的“模型幻觉”，随后临时调整提示词，导致模型在未观测任务上的泛化能力下降。严谨的复盘工程将基础模型视为一个无特权、在期望意义上具有确定性的计算引擎，它处理的是按因果顺序排列的离散上下文词元序列。通过在执行过程中捕获完整的智能体控制块（ACB）和分布式 OpenTelemetry 跨度图，运行时能够在不改变外部状态的情况下实现封闭隔离的轨迹重放。工程师可以系统性地剖析因果链，区分语义接口故障与算法策略失效，并将经过验证的修复固化为评估训练场中永久的自动化回归测试夹具。

确定性轨迹重放

取证分析的基础是轨迹重建。当智能体轨迹 \(\tau = (s_0, a_0, o_0, s_1, a_1, o_1, \dots, s_T)\) 因未处理的异常、安全不变量遭到违反或任务被明确拒绝而终止时，复盘引擎必须重建当时呈现给模型的历史上下文缓冲区 \(c_t\) 的精确序列。由于模型不具备任何环境隐式授予的权限，与操作系统、存储层和网络服务的每次交互都必须经过受中介控制的工具调用，并由运行时记录为一个 OpenTelemetry 跨度。因此，遥测账本包含一份不可变、按时间顺序排列的日志，记录了每次模型调用、提示词序列化、原始生成结果、工具标识符、输入参数字典和序列化观测字符串。

针对在线外部 API 重放智能体轨迹，必然会产生非确定性。外部数据库会发生变化，Web 服务返回的载荷会不断变化，而修改状态的调用会重复执行事务。真正的取证重放需要一份不可变的历史观测记录。

取证重放建立在 重放 的重建机制之上。它重放已记录的观测，而不要求重新生成的模型输出与原输出一致（原则 15）；它采用两种运行模式，每种模式回答不同的诊断问题。

1. 纯回放重放（状态机验证）： 运行时监督器读取已记录的轨迹日志，逐步推进执行序列，无须调用基础模型或执行外部工具 RPC。重放运行框架将已记录的动作 \(a_t\) 直接输入监督器的状态机，以验证校验逻辑、速率限制器、词元计数估算器或沙箱策略是否发生故障。如果监督器因未处理的 JSON 解析异常或上下文窗口计量中的整数溢出而崩溃，纯回放可以在数毫秒内暴露缺陷，且不产生任何推理成本。
2. 采用封闭隔离模拟的生成式重放（策略验证）： 为诊断基础模型为何选择了错误动作 \(a_t\)，重放运行框架重新实例化智能体运行时，加载提示词模板、系统指令和历史上下文缓冲区 \(c_t\)，但拦截所有向外部派发的工具调用。运行框架不会在在线基础设施上执行请求的工具，而是从已记录的追踪中查询对应的观测 \(o_t\)，并将其注入下一个上下文帧。随后，在相同的生成超参数下再次查询基础模型（温度 \(\tau \to 0\)、固定随机种子、相同的 logit 惩罚）。

生成式重放体现了 David K. Gifford（1979）在《复制数据的加权投票》（Weighted Voting for Replicated Data）中阐述的复制状态机原则。Gifford 证明，只有当状态转换受不可变且经法定人数验证的历史变更日志支配时，分布式副本才能在网络分区期间保持语义一致性。在智能体运行时中，封闭隔离模拟根据遥测追踪构建外部世界的本地合成副本。当智能体发出修改状态的工具调用——例如 DROP TABLE analytics_staging 或 DELETE /v1/instances/i-09a1——时，封闭隔离模拟引擎会将调用签名与已记录的跨度图进行匹配，返回在线事件发生时收到的完全相同的状态载荷，并推进智能体时钟，从而避免生产基础设施遭受二次破坏。

# Minimal trajectory replay harness intercepting tool execution via trace mocks
def replay_step(agent, trace_span, model_client):
    context = agent.format_context(trace_span.history)
    predicted_action = model_client.generate(context, temperature=0.0)
    if predicted_action.tool_name != trace_span.expected_action.tool_name:
        raise DivergenceError(f"Drift at step {trace_span.step}: {predicted_action}")
    # Hermetic mock: inject recorded observation without re-executing tool
    agent.append_observation(trace_span.recorded_observation)

如果在 \(\tau = 0\) 下重新调用的模型重现了完全相同的失败动作 \(a_t\)，而此时向其提供的上下文为 \(c_t\)，则可验证该缺陷在计算上具有可复现性。如果模型在零温度下输出了完全不同且有效的动作，则将原始生产环境故障归类为由较高推理温度或分布式推理集群中的非确定性词元采样所驱动的边缘情形随机偏离。

子系统故障归因：区分幻觉与接口故障

当智能体输出无效的 SQL 查询、尝试访问不存在的文件路径，或在解析编译器错误时陷入无限循环时，运维团队通常会将事件标记为模型固有的“幻觉”。取证式系统分析认为，这种定性体现了思维上的懒惰。基础模型是一个关于下一个词元的自回归概率分布，其条件完全由此前的词元序列决定：

\[P(a_t \mid c_t) = \prod_{i=1}^{M} P(w_i \mid c_t, w_{<i})\]

其中，\(c_t = (s_{\text{sys}}, p_{\text{task}}, a_0, o_0, \dots, a_{t-1}, o_{t-1})\) 表示累积的上下文。如果操作系统工具返回的观测 \(o_{t-1}\) 含义模糊、被静默截断、丢失了错误码，或其格式与工具声明的模式不一致，那么由此产生的错误动作 \(a_t\) 就不是无缘无故的幻觉。它是在受损上下文缓冲区上生成的完全合理、贝叶斯最优的补全。

在《软件设计的哲学》（2018）中，John Ousterhout 指出，最好的接口是“深”的：它们通过简单、明确的契约提供强大的功能。“浅”的接口或泄漏实现细节的接口，会迫使调用方处理其无法察觉的边缘情形。当工具接口过浅或返回受损的观测时，智能体内部的现实模型就会破裂。

John Ousterhout（2018）在《软件设计的哲学》中指出，模块设计必须隐藏复杂性，并提供清晰、深层的抽象。当接口泄漏实现细节或产生含义模糊的错误模式时，调用方代码不可避免地会误解接口契约。在智能体架构中，这一设计规律的影响被放大：由于“调用方”是概率神经网络，而非静态编译器，含义模糊的工具接口会直接触发语义层面的策略失效。

为了确定真正的根因，取证协议将每起事件归入以下五个候选子系统之一：

1. 提示与上下文内预算子系统： 上下文窗口管理器静默裁剪了关键的历史词元，系统提示包含相互矛盾的行为约束，或关键指令在较长词元序列中受到“中间信息丢失”现象所引起的注意力退化影响。
2. 工具契约与接口子系统： 工具实现违反了其公开的模式，输出了干扰 JSON 词元化的原始转义字符，在标准错误输出中遗漏了非零退出码，或在任意字节阈值处截断了载荷正文，却未附加明确的截断标记。
3. 模型审慎推理与策略子系统： 在上下文缓冲区完整、明确且工具观测有效的情况下，模型作出了无效的逻辑推断，算错了算术索引，或因退化的注意力汇聚点权重而进入自回归重复循环。
4. 运行时沙箱与操作系统隔离子系统： 物理容器环境发生故障。典型机制包括内存不足导致的内核终止（cgroup OOM-killer 导致退出码 137）、安全监督器强制执行的文件系统权限拒绝，或伪装成应用错误的网络命名空间超时。
5. 外部环境与认知漂移： 外部微服务更改了其 API 响应模式，却未更新智能体的工具规范；上游数据库以非确定性顺序返回行；或外部参与方的并发操作在步骤 \(t\) 与 \(t+1\) 之间改变了底层环境。

这些子系统中的物理故障机制、遥测特征和取证验证方法在 表 8 中作了形式化描述。

表 8: 分层故障归因分类体系：用于轨迹事后剖析的子系统分类、物理故障机制、可观测遥测特征和取证验证方法。

子系统分类	物理故障机制	可观测的遥测特征	取证验证方法
提示 / 上下文	FIFO 裁剪移除了最初的用户约束；Markdown 规则相互冲突。	\(L_t \ge S_{\max}\)；早期片段上的注意力高度分散。	对比 \(c_0\) 与 \(c_t\) 之间的词元偏移；扩大上下文容量后重放。
工具接口	静默截断载荷；原始 ANSI 转义字符；未解析的 stderr 流。	载荷长度等于缓冲区上限（\(16\text{ KB}\)）；追踪跨度内出现 JSON 解析错误。	对原始 \(o_t\) 进行字节检查；依据 OpenAPI JSON 模式进行验证。
模型策略	错误的逻辑推断；空间推理崩溃；重复陷阱。	符合模式的动作 \(a_t\)；序列熵高；出现重复惩罚标志。	使用分步推理提示重放；进行温度消融（\(\tau = 0.0\) 对比 \(0.7\)）。
运行时沙箱	cgroup 内存耗尽；缺少 POSIX 二进制程序；命名空间网络连接中断。	子进程退出码为 137（SIGKILL）或 127；追踪跨度持续时间与超时时长一致。	审计 /sys/fs/cgroup/memory.events；在纯净的 Docker 容器内重放命令。
外部环境	REST API 模式漂移；第三方速率限制（HTTP 429）；过期的 DNS 信息。	外部追踪跨度返回 HTTP 5xx/4xx；故障前出现延迟骤增。	将外部载荷与历史缓存进行差异对比；使用冻结的 API 模拟实现重放。

区分工具接口故障与模型策略故障，是诊断规程中最关键的一步。设想一个负责重构 Python 代码库的智能体。在步骤 \(t=5\)，智能体执行搜索工具 grep_code(pattern="UserAuth")。底层 shell 子进程产生了 180 千字节的匹配行。然而，宿主运行时的工具执行封装层强制实施了一个未记录在文档中的、硬编码的 8,192 字节截断上限。子进程的标准输出在行中间被截断，切断了一个 JSON 字符串定界符，并截去了某个函数定义的右括号。

当这段残缺的观测被追加到上下文缓冲区时，基础模型在步骤 \(t=6\) 判定代码库存在致命的语法错误，并在未收到相应指令的情况下生成了一个操作，试图从头重写目标文件，丢弃了 500 行现有的生产逻辑。粗略审查得出的结论是：“模型幻觉出了一个语法错误，并破坏了文件。” 系统取证式事后剖析揭示了事实真相：模型面对被缺乏监测机制的运行时缓冲区上限破坏的观测流，作出了逻辑上完全一致的反应。纠正措施应落实在工具封装层的流式序列化边界，而非提示词工程中。

反事实试验场消融

一旦形成因果假设，系统工程师就必须证明，所识别的组件既是导致故障的必要条件，也是充分条件。在复杂的随机系统中，异常追踪事件与失败轨迹之间仅有相关性，并不能确立因果关系。验证因果关系的严谨机制是受控反事实消融。

在反事实消融实验中，取证运行框架精确隔离轨迹的分支点，即状态 \(s_t\)，该状态紧接在灾难性决策 \(a_t\) 之前。工程师仅修改一个架构变量 \(\Delta X\)，同时保持所有其他系统变量严格不变：

\[\tau_{\text{cf}} \sim \pi_{\theta, \text{config} \oplus \Delta X}(\cdot \mid c_t)\]

如果单变量修改 \(\Delta X\) 在反复进行的随机评估中使轨迹恢复正常，则根因得到正式确认。典型的消融干预包括：

• 工具契约增强： 追加严格的输入/输出类型注解、提供显式模式定义，或将非结构化字符串返回值转换为带有显式状态标志的类型化 JSON 载荷。
• 观测边界净化： 去除终端转义序列、用显式分页标记（[TRUNCATED: 4,112 bytes omitted; query with page=2]）替代静默字节截断，或将 stderr 重定向到专用观测字段。
• 上下文裁剪改进： 用语义摘要或选择性观测屏蔽替代简单的滑动窗口 FIFO 词元淘汰机制，防止基础任务指令被淘汰。
• 推理支架： 在生成会修改状态的操作之前，插入确定性验证关卡或结构化暂存存储器要求。

Example 0.2: 工具截断的反事实消融

物理场景： 一个自主维护智能体使用 128,000 词元的上下文预算（\(\approx 512\text{ KB}\) 文本），在对单体代码仓库执行依赖审计时失败。在步骤 \(t=8\)，智能体调用 list_directory(path="/services/auth", depth=3)。底层文件系统包含 420 个文件。运行时工具 RPC 封装层将 stdout 缓冲区限制为 \(16\text{ KB}\)（\(16,384\text{ bytes}\)），在第 118 个文件（/services/auth/models/us...）的路径中途截断文件列表，且未提供 EOF 标记或警告横幅。

观测表现： 在步骤 \(t=9\)，智能体输出了一个幻觉结论：“目录 /services/auth/models 已损坏；正在重新生成默认模型文件。” 智能体发出破坏性写入操作，覆盖了正在使用的数据库模型定义，立即触发集成测试失败。

诊断假设：

• 假设 \(H_1\)（模型推理）： 模型缺乏理解嵌套目录层级的能力，因而幻觉出了损坏情况。
• 假设 \(H_2\)（工具接口契约）： 模型将突然截断的路径字符串解释为物理文件系统损坏，因为工具封装层未提供任何表明缓冲区溢出的语义信号。

反事实消融协议： 取证工程师在步骤 \(t=8\) 处搭建受控回放运行框架。测试框架在三种实验条件下运行 \(N=20\) 次随机生成（\(\tau = 0.7\)，系统提示相同）：

1. 基线条件（记录的轨迹）： 未经修改的上下文，其中包含被静默截断的 \(16\text{ KB}\) 观测。

2. 消融 A（提示强制约束）： 追加一条提示警告：“注意：工具可能会截断输出。不要假定存在数据损坏。”

3. 消融 B（接口契约修复）： 修改工具封装器，以追加显式的结构化标头和分页元数据：

   {"status": "PARTIAL_CONTENT", "bytes_returned": 16384, "total_bytes": 58210,
    "has_more": true, "next_offset": 16384, "entries": [...]}

实证结果：

• 在基线条件下，智能体在 \(19 / 20\) 次试验中复现了破坏性写入（失败率为 95%）。
• 在消融实验 A（提示强制）条件下，智能体在 \(8 / 20\) 次试验中避免了破坏性写入，但在 \(12 / 20\) 次试验中停滞或陷入循环（失败率为 60%；事实证明，提示指令不足以解决文件路径缺失的问题）。
• 在消融实验 B（接口契约修复）条件下，智能体识别出内容不完整，输出 list_directory(..., offset=16384)，并在 \(20 / 20\) 次试验中成功完成审计（失败率为 0%）。

取证结论： 根本原因归于子系统 2（工具契约）。工具封装层截断了输出，却未标明截断，违反了带类型约束的动作契约（原则 8）；该契约要求，观测在进入上下文之前必须具有明确的边界和类型。模型的破坏性动作是基于这一受损观测作出的合理推断。

取证式事后分析的最终产物并非静态文本文档，而是自动化软件工件。事后分析协议的最终目标是确保已诊断出的失败模式绝不会在生产环境中悄然复发。系统工程师将捕获的轨迹、经过消融的上下文以及已验证的工具接口修复，转化为封闭隔离的评估训练场（节 2）中的永久回归测试夹具。

# Automated regression test synthesized from forensic post-mortem INC-4921
def test_regression_inc_4921_directory_truncation_handling(eval_gym):
    fixture = eval_gym.load_fixture("fixtures/inc_4921_large_directory.tar.gz")
    agent = eval_gym.spawn_agent(config="configs/production_agent.yaml")
    # Verify agent gracefully paginates instead of emitting destructive writes
    trajectory = agent.execute_task("Audit dependencies in /services/auth", fixture)
    assert trajectory.status == TaskStatus.SUCCESS
    assert not any(action.tool_name == "write_file" for action in trajectory.actions)
    assert any(action.tool_name == "list_directory" and action.params.get("offset")
               for action in trajectory.actions)

本次调查的全面发现汇编为正式的《系统轨迹事后分析报告》，详见 表 9。该文档建立了不可变的记录，涵盖故障机制、通过反事实消融对根因进行的实证验证，以及防止未来智能体迭代出现回归的确切软件提交。

表 9: 结构化轨迹事后分析事件模板：必需的调查章节、正式字段定义、遥测产物，以及来自生产事件的具体取证证据。

报告章节	字段定义	取证调查数据
事件元数据	唯一事件标识符	INC-2026-8831
	根轨迹 ID（trace_id）	4bf92f3577b34da6a3ce929d0e0e4736
	失败跨度 ID（span_id）	00f067aa0ba902b7
	智能体部署版本	v2.4.1-runtime-prod
故障表现	运行症状	智能体在未收到相关指令的情况下主动重写了 auth_models.py，删除了 500 行。
	发生的违规	不变量违反：在预期任务范围之外执行破坏性写入。
	检测机制	维护任务中的 git_diff_lines > 200 触发了尾部采样规则。
回放验证	纯回放结果	成功验证了监督器状态机；未发生内部运行时崩溃。
	生成式回放结果	模型在 \(\tau = 0.0\) 处确定性地复现了破坏性写入（\(20/20\) 次运行）。
故障归因	主要子系统	子系统 2：工具契约与接口设计。
	根因机制	工具 RPC 包装器在 \(16\text{ KB}\) 处静默截断了 stdout 缓冲区，未发出 EOF 信号。
	被证伪的假设	模型幻觉假设被证伪；遵循提示指令的假设被证伪。
反事实验证	消融参数 \(\Delta X\)	将原始截断字符串替换为结构化 JSON 分页元数据。
	实证恢复率	恢复率为 \(100\%\)，基于固定故障种子下的 \(N=20\) 次随机轨迹采样。
纠正措施	软件补丁	提交 7f1a90c：对流式缓冲区进行分块，并提供显式分页标志。
	Gym 回归测试夹具	已将 test_regression_inc_4921_directory_truncation_handling 添加到 CI 测试套件。

Checkpoint 0.3: 评估取证事后分析与故障归因

在分析分阶段金丝雀部署和序贯假设检验之前，请检查你对事后诊断的理解：

• 轨迹回放框架：通过模拟接口回放已记录的工具输出，如何区分模型幻觉与环境故障？
• 反事实消融：在封闭隔离的 Gym 环境中，最小限度的环境扰动如何证明拟议补丁能够解决事件？
• 故障归因：为什么将错误归类为策略、工具契约、环境或人机交互问题，可以避免徒劳的提示调整？
• 回归测试夹具：如何利用事件取证轨迹生成确定性的集成测试，以防止历史问题再次出现？

分阶段金丝雀部署

Wald 序贯概率比检验在 8 轮交互内检测到候选策略性能退化，将金丝雀部署的影响范围缩小了 80%。

某云基础设施工程团队更新了一个自主站点可靠性智能体的运行时监督器，替换了启发式提示注入过滤器，并将底层模型客户端重新指向优化后的推理端点。在传统的编译型服务中，通过确定性集成测试套件，可以保证内存分配例程、网络协议解析器和远程过程调用（RPC）模式中的不变量得到保持。然而，在智能体架构中，候选运行时虽然通过了所有离线基准测试套件，且表面上 \(pass@1\) 提升了 \(3.2\%\)，但系统一遇到真实生产输入，就出现灾难性的性能退化：用户意图表述的细微变化会触发异常的工具重试循环，云 API 的临时速率限制会引发未处理的异常轨迹，而自主操作会耗尽上下文窗口，却未能完成任务。系统返回 HTTP 200 成功状态码，并生成礼貌、自然的对话式进度更新，同时却在无声地阻滞数据库迁移并耗尽 token 预算。

部署更新后的模型、工具模式或监督器，需要采用分阶段发布流水线，将每项变更都视为未经验证的假设（原则 15）。 由于离线基准测试无法涵盖真实生产输入的无界熵，系统工程师必须构建自动化部署关卡，通过离线 Gym 验证、沙箱化影子执行，以及由统计断路器保护的小比例线上金丝雀路由，逐步提升执行权限。

多阶段发布拓扑：从离线 Gym 到影子托管

智能体发布流水线的物理架构必须弥合合成评估与生产执行之间的认知鸿沟。在无状态微服务中，功能回归会表现为即时的 HTTP 5xx 错误或 panic；而智能体回归往往表现为语义漂移：推理轨迹的细微变化、工具参数过度冗长，或对边缘情形下的环境响应表现出意料之外的脆弱性。为防止有缺陷的运行时破坏生产状态，发布流水线采用三阶段渐进式关卡拓扑，如 图 5 所示。

图 5: 分阶段金丝雀部署与自动回滚架构：渐进式验证流水线展示了离线封闭评估环境准入、带语义偏离监控的沙箱化影子隔离执行、由 Wald 序贯概率比检验控制的在线金丝雀流量切换，以及回滚时间低于 10 秒的自动熔断器。

如 图 5 所示，发布流程需经过三个严格的验证阶段，候选配置才能晋升为生产配置。在阶段 1（封闭评估环境）中，发布候选配置 \(\theta_{\text{cand}}\) 对 \(N \ge 2,500\) 个确定性任务进行离线基准测试，要求经验通过率满足 Wilson 得分非劣效性假设（\(p_{\text{cand}} \ge p_{\text{base}} - \delta_{\text{tol}}\)，在 \(\alpha = 0.05\) 下），之后才能接收任何生产流量。在阶段 2（影子隔离执行／暗流量）中，入口路由器复制在线生产请求；基线策略 \(\pi_{\text{base}}\) 以任务所需的完整生产权限在线执行，而候选配置 \(\pi_{\text{cand}}\) 从副本和快照读取数据，并将每一次修改操作限制在可丢弃的沙箱（\(A_1\)）内，同时对具有修改作用的系统调用进行模拟。差异偏离监控器计算语义距离 \(D_{\text{sem}}(a_{\text{cand}}, a_{\text{base}}) \le \epsilon\)，若工具漂移或参数膨胀超出容差，则停止晋升。在阶段 3（金丝雀准入）中，动态流量限流器将在线修改流量的 \(\rho = 1\%\text{--}5\%\) 分配给 \(\pi_{\text{cand}}\)。遥测哨兵根据 Wald 序贯概率比检验（SPRT）评估每条轨迹的结果，其两个决策边界分别用于将候选配置晋升为承接 100% 流量的生产基线，或触发自动熔断器。全局自动回滚与流量钳制总线为整个架构提供支撑，确保平均恢复时间（MTTR）低于 10 秒：一旦触发任何硬性不变量警戒条件（成本激增 \(>1.5\times\)、上下文耗尽 \(>1\%\) 或重复工具循环），总线就立即钳制金丝雀流量 \(\rho \to 0\%\)，并将所有在线路由恢复至已验证的基线 \(\pi_{\text{base}}\)。

阶段 1 在封闭评估环境中实施离线基准测试准入。候选运行时配置——包括更新后的基础模型检查点 \(M_{\text{cand}}\)、修改后的系统提示词 \(c_0\) 或重构后的工具定义 \(\mathcal{A}\)——必须在标准化的留出任务分布 \(\mathcal{D}_{\text{task}}\) 上执行。性能通过经验通过率 \(\hat{p}\) 的 Wilson 得分置信区间进行衡量，具体方法已在 节 4 中确立。发布自动化系统相对于当前生产基线策略 \(\pi_{\text{base}}\) 评估非劣效性假设：

\[H_0: p_{\text{cand}} < p_{\text{base}} - \delta_{\text{tol}} \quad \text{versus} \quad H_1: p_{\text{cand}} \ge p_{\text{base}} - \delta_{\text{tol}}\]

其中，\(\delta_{\text{tol}}\) 表示最大允许性能差距，对于安全关键系统，通常设为 \(0\)；若以少量准确率损失换取显著的延迟或成本降低，则设为一个较小的预算（例如 \(0.01\)）。如果候选运行时无法在显著性水平 \(\alpha = 0.05\) 下达到统计非劣效性，则会在接收生产流量之前被拒绝。

通过离线基准测试准入，仅能证明候选配置满足已知的历史不变量；这并不能证明其在真实用户请求的非平稳分布下具有安全性。因此，阶段 2 将在线流量路由至影子执行，通常称为暗流量。在此阶段，生产流量路由器复制传入的用户提示词 \(c_0\)。主流量路由至生产基线 \(\pi_{\text{base}}\)，该基线保有实际执行权限，以完成用户请求。次流量则异步分叉至候选策略 \(\pi_{\text{cand}}\)，从而建立 暗流量路由 所述的权限划分。

暗流量路由：暗流量分流与权限分区架构。

架构维度	主要生产流（\(\pi_{\text{base}}\)）	镜像暗流（\(\pi_{\text{cand}}\)）	遥测与安全边界
流量分配	\(1 - \rho_{\text{dark}}\)（\(100\%\) 活跃用户请求）	\(\rho_{\text{dark}}\) 异步复制的副本	透明、非阻塞的入口分流
执行权限	在生产基础设施上拥有完整的任务执行权限	仅允许沙箱内的变更（\(A_1\)）；模拟托管	沙箱虚拟机监控器捕获变更类系统调用
读取操作	实时只读副本和活跃数据库	临时写时复制快照或只读副本	隔离的连接池；不对生产环境加锁
变更操作	直接对生产持久化存储执行	被拦截；使用合成桩或临时容器	运行结束后立即丢弃临时容器
响应交付	直接返回给最终用户 / 客户端	丢弃或路由至评估分析器	不向外部客户端暴露
遥测目标	SLA 延迟、可用性、最终用户任务成功率	轨迹分歧、令牌漂移、工具一致性	实时计算差异漂移

智能体系统中影子执行的核心架构挑战在于：候选系统在处理生产输入时，仍须将其权限限制在沙箱内（\(A_1\)）。无状态 Web 服务器可以通过丢弃下游 HTTP 响应来执行影子请求，而智能体系统会通过工具与外部环境动态交互。如果 \(\pi_{\text{cand}}\) 调用某个工具，执行 HTTP DELETE、数据库 DROP TABLE 或外部支付授权，影子执行就会破坏共享的生产环境。

为解决这一两难问题，运行时将候选系统视为不可信对象，在模型之下实施隔离约束（原则 10），并将 \(\pi_{\text{cand}}\) 置于只读模拟托管环境中。工具调用被划分为纯检查操作和变更操作。只读检查工具（如文件读取、数据库查询和代码仓库搜索）被路由至生产副本或写时复制文件系统快照。变更操作由运行时沙箱拦截；监督器不会将变更发送至生产基础设施，而是以合成的成功响应作为该调用的桩实现，或在临时的隔离容器中执行变更，并在轨迹终止后立即丢弃该容器。

第 2 阶段的遥测系统不评估最终环境状态，因为变更被限制在沙箱内。它们转而记录 \(\tau_{\text{base}}\) 与 \(\tau_{\text{cand}}\) 之间的结构性轨迹分歧。遥测智能体采集令牌使用量、步骤延迟、工具选择分布以及输出参数的语义分歧。如果 \(\pi_{\text{cand}}\) 出现异常的令牌消耗、过度的上下文窗口膨胀，或沙箱内工具调用的异常错误率，部署流水线就会在候选系统获得生产状态操作权限之前中止。

金丝雀流量迁移

当候选运行时通过影子执行验证后，便进入阶段 3：线上金丝雀部署。在此阶段，流量路由层会动态地将一小部分线上生产流量——通常为 \(\rho \in [0.01, 0.05]\)，或 \(1\%\) 至 \(5\%\)——直接分流至 \(\pi_{\text{cand}}\)，赋予其修改线上环境状态的完整权限。金丝雀部署需要平衡两项相互竞争的物理约束：尽量缩小未被发现的故障模式的影响范围，同时足够迅速地获得统计功效，以便在发生运行中断之前检测到性能退化。

影响范围不变量 在智能体系统中，影响范围的衡量标准不只是失败的 HTTP 请求数；它还包括熔断器停止执行之前，智能体对持久存储、外部 API 和用户信任造成的不可逆改变。

在传统微服务中，金丝雀发布门控依赖固定时长的观测窗口（例如，在十二小时内监测错误率）。在具有随机性的智能体集群中，固定时间窗口存在根本缺陷。如果流量发生波动，固定时间窗口可能采样到的复杂多轮轨迹过少，无法达到统计显著性；也可能在某种故障模式已可通过统计方法辨识很久之后，仍让数千名用户承受持续存在的性能退化。

为克服这一局限，遥测控制平面使用 Wald 序贯概率比检验（SPRT）实施连续序贯检验。SPRT 不预先固定样本量 \(N\)，而是更新对数似然比 \(\Lambda_n\)，每次更新均在观测到一条已完成轨迹的结果 \(x_i \in \{0, 1\}\) 后进行，其中 \(x_i = 1\) 表示验证成功的轨迹，\(x_i = 0\) 表示失败的轨迹：

\[\Lambda_n = \sum_{i=1}^n \ln \frac{P(x_i \mid p_1)}{P(x_i \mid p_0)} = d_n \ln \left(\frac{p_1}{p_0}\right) + (n - d_n) \ln \left(\frac{1 - p_1}{1 - p_0}\right)\]

其中，\(d_n = \sum_{i=1}^n x_i\) 是成功轨迹的累计数量，\(p_0\) 是可接受的基线成功概率，\(p_1 = p_0 - \Delta\) 表示成功概率退化至不可接受水平的阈值。该检验将 \(\Lambda_n\) 与由假阳性容忍度 \(\alpha\) 和假阴性容忍度 \(\beta\) 定义的两个吸收边界进行比较：

\[A = \ln \left( \frac{1 - \beta}{\alpha} \right), \qquad B = \ln \left( \frac{\beta}{1 - \alpha} \right)\]

如果 \(\Lambda_n \ge A\)，控制平面便判定候选运行时具有非劣效性，并安全地加速流量迁移（例如，将 \(\rho\) 从 \(0.05\) 提升至 \(0.25\)，随后提升至 \(1.0\)）。如果 \(\Lambda_n \le B\)，则可确证候选运行时发生了性能退化；控制平面会触发自动熔断器，立即撤走全部金丝雀流量，将 \(100\%\) 路由恢复至 \(\pi_{\text{base}}\)，并触发告警，以供工程团队开展事后复盘。

注记序贯概率比检验门控

自动金丝雀熔断器将累计轨迹观测结果与两个 Wald 吸收边界进行比较，这两个边界由目标假阳性率 \(\alpha\) 和假阴性率 \(\beta\) 定义：

\[\Lambda_n = d_n \ln \left(\frac{p_1}{p_0}\right) + (n - d_n) \ln \left(\frac{1 - p_1}{1 - p_0}\right)\]

1. 上吸收边界（\(A = \ln \frac{1 - \beta}{\alpha}\)）： 如果 \(\Lambda_n \ge A\)，候选运行时的非劣效性便得到统计验证；控制平面提升候选运行时的发布阶段，并加速金丝雀流量迁移。
2. 下吸收边界（\(B = \ln \frac{\beta}{1 - \alpha}\)）： 如果 \(\Lambda_n \le B\)，则可确证候选运行时发生了性能退化；控制平面立即触发自动熔断器，撤走全部金丝雀流量，以恢复基线路由。
3. 未决区域（\(B < \Lambda_n < A\)）： 继续采样（\(n \leftarrow n + 1\)），不调整流量权重。

如 序贯概率比检验门控 中的形式化定义所述，自动熔断器必须以尽可能短的平均检测时间（MTTD）和平均恢复时间（MTTR）运行，并遵循 Dean 和 Barroso (2013年) 所阐述的尾部容忍原则。除了对总体任务成功率进行序贯假设检验之外，发布流程还复用 工具熔断器 中的熔断器，此时由表明违反硬性安全约束的集群级条件触发：

Dean, Jeffrey, 和 Luiz André Barroso. 2013年. 《The tail at scale》. Communications of the ACM 56 (2): 74～80.

1. 单条轨迹成本激增： 如果每条轨迹的令牌消耗量滚动中位数超过基准阈值的幅度大于 \(K_{\text{cost}} = 1.5\times\)，且持续窗口为 \(W = 50\) 次运行，则触发熔断器，以防止资金耗尽。
2. 上下文耗尽级联： 如果因上下文窗口饱和（\(K \ge K_{\max}\)）而终止的轨迹比例超过 \(1\%\)，则立即停止执行。
3. 重复工具调用循环： 如果任一金丝雀工作进程连续三次以上发出工具和参数均相同的调用，且未发生状态变更，则宿主运行时终止该工作进程，并标记策略的依据关联能力出现回归。

当熔断器触发时，自动回滚延迟必须具有确定性。由于基础模型推理端点与宿主监督器解耦，回滚无需重新部署容器镜像或重启服务器守护进程。流量代理在内存中修改其上游权重向量，立即排空金丝雀并发请求，并确保后续用户轮次仅使用黄金基线执行。

智能体核心 SRE 指标

运行具有随机性的智能体集群，需要从根本上转变站点可靠性工程（SRE）指标。传统 Web 平台通过四大黄金信号量化运行状况：延迟、流量、错误和饱和度 (Beyer 等 2016年)。对于智能体系统，这些信号是必要的，但远远不够。智能体运行时可能在网络层丢包为 \(0\%\) 的情况下运行，每次调用都返回 HTTP 200 OK，宿主机器的 CPU 饱和度保持较低，却仍然在运行层面失败：消耗 120,000 个令牌，执行 40 次缺乏依据的工具调用，最终放弃用户目标。

为了建立有意义的运行可观测性，系统工程师会监测一组三元 SRE 遥测指标，这组扩展指标专门针对自主智能体的动态行为设计（表 10）：有效吞吐量、行为漂移和人工干预率。

表 10: 自主智能体集群的核心 SRE 遥测三元组：对比传统微服务指标与智能体 SRE 指标，并呈现各运行维度的数学表述和故障征兆。

工程维度	传统微服务指标	智能体系统 SRE 指标	系统故障征兆
系统效能	可用性（2xx / 总请求数）	轨迹有效吞吐量（\(\mathcal{G}\)）	轨迹以 200 OK 完成，但未通过实证后置条件验证器的检验
资源效率	请求延迟（p50/p99 ms）	轨迹解决成本	递归提示扩展循环导致令牌耗尽
运行稳定性	错误预算（未捕获异常）	人工干预率（\(I_{\text{rate}}\)）	运维人员必须手动引导或中止失控的工具调用链
行为不变性	API 契约模式违规	工具选择漂移（\(D_{\text{JS}}\)）	模型的偏好转向昂贵或已弃用的工具端点
集群恢复	MTTR（容器重启时间）	回滚与补偿 MTTR	排空金丝雀流量并执行补偿 Saga 所需的延迟

轨迹有效吞吐量 \(\mathcal{G}\)，即集群资源中用于达成经独立验证的轨迹（微效与宏效）的比例，是智能体集群的主要服务水平指标（SLI）。只有通过验收的任务才能交付价值，因此，失败或未经验证的尝试所消耗的所有资源，均计入通过验收的任务成本（原则 22）。计算 \(\mathcal{G}\) 需要对每条轨迹进行验收测试，本节的发布机制直接统计该测试的结果。我们将已启动轨迹中通过确定性后置条件验证器检验、同时满足资源和延迟预算的比例称为经验证的完成率 \(q\)：

\[q = \frac{1}{N} \sum_{i=1}^N \mathbf{1}\left(\text{Verify}(s_T^{(i)}) = 1 \;\land\; \text{Cost}(\tau_i) \le C_{\max} \;\land\; T_i \le T_{\max}\right)\]

其中，\(\text{Verify}(s_T^{(i)})\) 评估终止步骤 \(T\) 时的环境状态是否符合机械化契约检查器的要求（编译器、静态检查器或数据库断言，如 节 1 中所确立），\(\text{Cost}(\tau_i)\) 汇总轨迹 \(\tau_i\) 期间累积的令牌费用和 API 费用，\(T_i\) 为交互轮次数。一条轨迹即使生成了有效代码，但若消耗 \(\$50.00\) in inference costs against a \(\$2.00\) 服务预算，也无法通过此测试，其消耗的每一份资源均在 \(\mathcal{G}\) 中计为无效吞吐量。

行为漂移衡量候选策略 \(\pi_{\text{cand}}\) 与基线 \(\pi_{\text{base}}\) 在相同或统计上可比的输入下，其动作分布之间的统计差异。遥测引擎跟踪工具调用的离散概率分布 \(P(a_{\text{tool}})\)。该差异使用 Jensen-Shannon 散度（\(D_{\text{JS}}\)）量化，这是一种对称、有界的信息论度量：

\[D_{\text{JS}}(P_{\text{base}} \parallel P_{\text{cand}}) = \frac{1}{2} D_{\text{KL}}(P_{\text{base}} \parallel M) + \frac{1}{2} D_{\text{KL}}(P_{\text{cand}} \parallel M)\]

其中，\(M = \frac{1}{2}(P_{\text{base}} + P_{\text{cand}})\) 是混合分布，\(D_{\text{KL}}\) 是 Kullback-Leibler 散度。如果 \(D_{\text{JS}}\) 超过经实证校准的阈值（例如 \(0.15\)），遥测引擎就会向运维人员发出显著行为漂移的警报。例如，候选模型可能突然停止调用细粒度数据库搜索工具，转而执行原始的、大范围的 SQL 查询，从而改变下游数据库的负载模式，却不一定改变整体任务成功率。

Jensen-Shannon 界限 由于使用自然对数时 \(0 \le D_{\text{JS}} \le \ln(2)\)，\(D_{\text{JS}}\) 提供了一个归一化且数值稳定的尺度，用于监测模型更新前后工具使用分布的漂移。

人工干预率（\(I_{\text{rate}}\)）反映智能体给人类监督者带来的运维负担。在采用人在回路监督或针对高风险操作设置审批托管机制的生产部署中，运维人员会观察、引导或中止智能体的计划：

\[I_{\text{rate}} = \frac{N_{\text{interventions}}}{N_{\text{trajectories}}} = \frac{N_{\text{pause}} + N_{\text{steer}} + N_{\text{abort}}}{N}\]

\(I_{\text{rate}}\) 的上升是对齐退化的敏感先行指标。如果更新后的基础模型生成含糊不清的工具参数，或提出触发审批托管机制的高风险 shell 命令，人类运维人员就不得不反复干预。即使经过人工纠正后，经验证的完成率保持不变，运维成本和认知负担也会增加，这表明候选运行时不适合自主部署。

最后，智能体系统中的平均恢复时间（MTTR）同时涵盖流量排空和状态恢复。如果金丝雀部署故障在熔断器触发之前破坏了外部系统，恢复就需要执行 Saga 补偿事务（故障恢复），以撤销部分修改。监测完整的 MTTR，可确保自动化发布系统同时考虑软件回滚速度和实际状态协调恢复的延迟。

粗略估算 0.5: 金丝雀流量规模与熔断器 MTTR 的估算

问题表述 某企业软件工程智能体集群以每小时 \(\lambda = 60\) 条轨迹的到达率处理传入的缺陷修复任务。经过验证的基线生产运行时 \(\pi_{\text{base}}\) 保持着 \(q_{\text{base}} = 0.90\) 的经验证完成率。

工程团队部署了候选运行时 \(\pi_{\text{cand}}\)，旨在降低推理延迟。团队并不知情的是，\(\pi_{\text{cand}}\) 在复杂的多文件补丁上引入了退化，使其真实的经验证完成率降至 \(q_{\text{cand}} = 0.75\)。发布工程流水线将生产流量的 \(\rho = 0.05\)（\(5\%\)）路由至金丝雀部署。自动熔断器针对已完成的金丝雀轨迹监测经验证的完成情况，所采用的序贯假设检验配置为：第一类错误概率 \(\alpha = 0.01\)、检验功效 \(1 - \beta = 0.95\)，以及无差异点 \(p_0 = 0.90\) 和 \(p_1 = 0.75\)。

1. 计算熔断器检测到退化并触发熔断所需的平均金丝雀轨迹数 \(E[N]\)。
2. 确定熔断器触发前的预期实际经过时间（以小时为单位）。
3. 计算影响范围：在相同的检测时段内，金丝雀部署与未受监测的全量部署（\(\rho = 1.0\)）各有多少条客户轨迹失败。

定量求解

步骤 1：序贯检验的预期样本量 在 Wald 序贯概率比检验（SPRT）中，当真实的底层参数为 \(p = p_1 = 0.75\) 时，越过下决策边界 \(B\) 所需的预期样本量为：

\[E_1[N] \approx \frac{(1 - \beta) \ln\left(\frac{\beta}{1 - \alpha}\right) + \beta \ln\left(\frac{1 - \beta}{\alpha}\right)}{E_1[z]}\]

其中，\(z_i = \ln \frac{P(x_i \mid p_1)}{P(x_i \mid p_0)}\) 是单次观测的对数似然比。期望 \(E_1[z]\) 在退化假设 \(p = p_1\) 下为：

\[E_1[z] = p_1 \ln\left(\frac{p_1}{p_0}\right) + (1 - p_1) \ln\left(\frac{1 - p_1}{1 - p_0}\right)\]

代入运行参数 \(p_0 = 0.90\) 和 \(p_1 = 0.75\)：

\[\frac{p_1}{p_0} = \frac{0.75}{0.90} \approx 0.8333 \implies \ln(0.8333) \approx -0.1823\] \[\frac{1 - p_1}{1 - p_0} = \frac{0.25}{0.10} = 2.5000 \implies \ln(2.5000) \approx 0.9163\] \[E_1[z] = 0.75 \times (-0.1823) + 0.25 \times (0.9163) = -0.1367 + 0.2291 = 0.0924\]

现在使用错误容限 \(\alpha = 0.01\) 和 \(\beta = 0.05\)（对应检验功效 \(1 - \beta = 0.95\)）计算分子：

\[\text{Boundary } B = \ln\left(\frac{0.05}{1 - 0.01}\right) = \ln\left(\frac{0.05}{0.99}\right) \approx \ln(0.0505) \approx -2.9857\] \[\text{Boundary } A = \ln\left(\frac{1 - 0.05}{0.01}\right) = \ln(95.0) \approx 4.5539\]

在假设 \(H_1\) 下，触及边界 \(B\) 的概率约为 \(1 - \beta = 0.95\)，而触及边界 \(A\) 的概率为 \(\beta = 0.05\)。分子的期望为：

\[\text{Numerator} = 0.95 \times (-2.9857) + 0.05 \times (4.5539) = -2.8364 + 0.2277 = -2.6087\]

触发熔断器所需的预期样本数为：

\[E_1[N] = \frac{-2.6087}{-E_1[z]} = \frac{2.6087}{0.0924} \approx 28.23 \text{ trajectories}\]

保守地取整至最接近的整数后，得到 \(N \approx 29\) 条金丝雀轨迹。

步骤 2：检测所需的实际经过时间 金丝雀部署接收的流量占比为 \(\rho = 0.05\)，总到达率为 \(\lambda = 60 \text{ tasks/hour}\)：

\[\lambda_{\text{canary}} = \rho \times \lambda = 0.05 \times 60 = 3.0 \text{ trajectories/hour}\]

直到熔断器触发并启动回滚的预期实际经过时间为：

\[T_{\text{detect}} = \frac{E_1[N]}{\lambda_{\text{canary}}} = \frac{28.23}{3.0} \approx 9.41 \text{ hours}\]

步骤 3：影响范围比较 我们将影响范围量化为在 \(9.41\) 小时的检测窗口内因退化而失败的客户任务的预期数量。

情形 A：受控金丝雀部署（\(\rho = 0.05\)） 金丝雀运行总次数 = \(28.23\)。 在 \(q_{\text{cand}} = 0.75\) 下，预期的金丝雀失败次数为：

\[\text{Failures}_{\text{canary}} = 28.23 \times (1 - 0.75) = 28.23 \times 0.25 \approx 7.06 \text{ failures}\]

其余 \(95\%\) 的流量在 \(\pi_{\text{base}}\)（\(q_{\text{base}} = 0.90\)）上运行：

\[\text{Total baseline runs} = 9.41 \text{ hours} \times 57 \text{ tasks/hour} \approx 536.37 \text{ tasks}\] \[\text{Failures}_{\text{baseline}} = 536.37 \times (1 - 0.90) \approx 53.64 \text{ failures}\] \[\text{Total System Failures} = 7.06 + 53.64 \approx 60.7 \text{ failures}\]

情形 B：未经监控的全面部署（\(\rho = 1.0\)） 如果将 \(\pi_{\text{cand}}\) 部署到 \(100\%\) 的流量上，那么在 \(9.41\) 小时的时间窗口内，所有传入任务都将面临下降后的成功率：

\[\text{Total runs} = 9.41 \text{ hours} \times 60 \text{ tasks/hour} = 564.6 \text{ tasks}\] \[\text{Failures}_{\text{full}} = 564.6 \times (1 - 0.75) = 564.6 \times 0.25 \approx 141.15 \text{ failures}\]

比较： 通过受管控的金丝雀边界路由流量，可避免：

\[\Delta_{\text{failures}} = 141.15 - 60.70 = 80.45 \text{ task failures}\]

分阶段金丝雀部署将影响客户的额外失败减少了 {python} SizingCanaryTrafficCircuitBreaker.reduction_pct_str：

\[\frac{141.15 - 60.70}{141.15 - 56.46} = \frac{80.45}{84.69} \approx 95.0\%\]

从而将影响范围精确限制在验证运行缺陷所需的统计阈值内。

---

当离线基准测试套件、暗流量影子执行和自动化金丝雀熔断器协同运行时，工程组织便能对随机模型的部署建立基于实证的控制。然而，如果将这些发布门控视为孤立的临时脚本，运行系统就容易受到遥测碎片化、数据保留策略缺乏协同以及实时事件处置盲区的影响。为实现真正的生产可靠性，系统工程师必须将这些分散的能力——封闭隔离的评估环境、OpenTelemetry 轨迹追踪、基于尾部的采样预算、取证式事后分析以及分阶段金丝雀门控——整合为统一且持续运行的控制平面。这一完整遥测平台在架构上的实现，就是实证可观测性运行框架。

实证可观测性运行框架的综合构建

在缺乏集成控制平面的情况下运行自主智能体集群，会产生一种隐蔽的失效模式，称为遥测孤岛悖论。当智能体集群每小时跨容器化沙箱、模型推理网关和分布式工具后端执行数千条复杂的多步骤轨迹时，每个诊断子系统捕获的都只是系统状态的局部投影，彼此缺乏协同。离线评估运行框架报告合成基准测试的通过率；OpenTelemetry 收集器记录跨工具 RPC 的分布式跨度；边缘代理测量 HTTP 延迟；日志流水线则将未经脱敏的控制台输出汇总至冷存储。当候选提示词更新、路由启发式策略或模型检查点在生产环境中出现性能退化时，这些互不相连的系统会产生相互矛盾的信号。模型网关报告正常的词元生成延迟和 HTTP 200 完成状态，而工具沙箱却遭遇级联权限故障。与此同时，基准测试套件显示没有任何退化，因为其静态测试夹具无法反映真实用户环境中的非确定性状态空间。工程团队只能在数百万条互不关联的 JSON 跨度记录中筛查，无法确定灾难性的任务中止究竟源于模型幻觉、上下文窗口截断、工具网络超时，还是宿主监督进程中的不变量违例。

实证可观测性运行框架不能只是事后诊断工具的碎片化集合；它必须作为统一的闭环遥测控制平面运行。通过将封闭隔离评估环境中的验证、OpenTelemetry 分布式追踪、基于尾部的采样、自动化取证回放以及统计金丝雀发布门控紧密耦合到一个同步反馈回路中，该框架将非确定性的智能体执行转化为有界、可验证且可通过实证观测的生产系统。

分布式智能体运行时中的闭环遥测与故障隔离原则，直接呼应了 Sigelman 等 (2010年) 在 Google 的 Dapper 分布式系统追踪基础设施中确立的架构基础，以及 Beyer 等 (2016年) 在 Google 的站点可靠性工程框架中系统化阐述的严谨运维规范。

Sigelman, Benjamin H, Luiz André Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan, 和 Chandan Shanbhag. 2010年. Dapper, a large-scale distributed systems tracing infrastructure. Dapper-2010-1. Google.

Beyer, Betsy, Chris Jones, Jennifer Petoff, 和 Niall Richard Murphy. 2016年. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media.

智能体可观测性的架构挑战，本质上是信息路由与验证问题。由于智能体对自身成功与否的报告及其思维链都不具备证据效力（闭合证据等级），运行时必须转而捕获客观的因果证据：发送给模型的确切提示词词元、返回的原始补全词元、沙箱状态转换的密码学哈希值、工具执行的网络载荷，以及每个推理阶段的精确时间信息。为将本章逐步构建的各项机制整合为工业级部署，我们将形式化定义五层控制平面架构，明确其严格的生产就绪契约，并推导用于管控自主集群运行的复合数学发布门控。

统一控制平面架构

端到端实证可观测性运行框架将智能体遥测的生命周期组织为五个紧密耦合的功能层：执行层、遥测收集器、评估引擎、取证诊断服务和发布网关。控制平面不会任由遥测数据异步流入未建立索引的日志汇聚端，而是强制采用严格的闭环拓扑，使运行时的生产信号持续为离线验证套件和金丝雀发布决策提供依据，详见 图 6。

图 6: 统一实证可观测性与评估控制平面架构：闭环系统拓扑将执行运行时、具有流式脱敏和尾部采样功能的遥测摄取、离线评估场、取证根因诊断，以及具有自动熔断器的分阶段金丝雀发布网关连接起来。

图 6 中的架构示意图展示了贯穿全部五个功能层的端到端数据流和反馈控制回路。在第 1 层（执行层），宿主监督器、模型网关和 microVM 沙箱发出丰富的 OpenTelemetry 跨度流，其中携带 W3C 上下文头和 GenAI 属性，且开销受到严格限制（\(\le 2\%\)）。在第 2 层（遥测收集器），传入的跨度经过流式敏感信息脱敏后进入内存托管缓冲区；基于尾部的分类器在此将 100% 的故障和拖尾任务路由至诊断服务，同时将常规完成轨迹降采样至 2%，从而使数据量减少 93.1%。在第 3 层（评估引擎），封闭隔离的 microVM 评估场在 Wilson 得分置信界约束下执行离线基准测试套件（\(N \ge 2,500\)），以便在部署前对候选方案进行准入把关。在第 4 层（取证诊断服务），异常追踪接受确定性重放和反事实扰动，以定位执行故障的根因，并合成新的回归测试夹具，直接注入第 3 层的基准测试套件。最后，在第 5 层（发布网关），候选方案接受分阶段的暗流量镜像和在线金丝雀路由，其过程由 Wald 序贯概率比检验（SPRT）控制。两条关键的向上反馈总线闭合了控制回路：取证诊断持续扩充离线验证夹具（左侧总线），而发布网关动态调节执行流量权重，并在检测到异常时触发耗时低于 10 秒的强制回滚机制（右侧总线）。

这五个层次通过结构化接口依次开展运行：

1. 执行层： 在系统边界处，智能体宿主监督器将每个逻辑工作单元都插桩为一个 OpenTelemetry 跨度。当用户请求到达时，监督器生成根 \(\text{trace\_id}\)，并将因果追踪头注入后续的每项操作。当智能体在词元生成和环境操作之间交替时，子跨度记录基础模型的确切输入和输出（预填充词元数、解码词元延迟、温度、top-p 和原始 logit 元数据）、工具 RPC（方法签名、序列化载荷和返回码）、记忆存储查询（向量相似度分数、检索到的块 ID 和缓存命中状态），以及沙箱生命周期事件（容器派生延迟、文件系统差异大小和 POSIX 退出码）。
2. 遥测收集器： 遥测数据从执行集群流入由本地收集器管理的高吞吐量内存缓冲区。在此，持久化序列化之前会执行两项关键操作。首先，流式 PII 脱敏过滤器检查所有非结构化字符串字段（提示词、模型生成结果和工具输出），利用正则表达式和命名实体识别，对加密密钥、访问令牌、凭据和用户 PII 进行掩码处理。其次，智能尾部采样引擎评估每条已完成轨迹的终止状态。因未处理异常、工具执行失败、不变量违反或契约评估未通过而终止的轨迹，以 100% 的保真度保留。延迟和步骤分布符合常规的正常成功轨迹则被降采样至可控的基准比例（例如 1%），避免遥测数据量超出摄取带宽的承载能力。
3. 评估引擎： 评估引擎与生产流量并行运行，在封闭隔离的评估场内，持续对候选模型、修改后的系统提示词和更新后的工具接口进行基准测试。候选智能体在与公共互联网隔离的环境中，针对确定性任务夹具执行。评估引擎运行多随机种子的测试扫描，通过封闭的真实值预言机跟踪状态不变量，并使用 Wilson 得分界计算统计置信区间，以判断观测到的性能差异究竟代表真实的算法变化，还是随机噪声。
4. 取证诊断服务： 当遥测收集器检测到异常追踪或正在发生的生产故障时，会将完整的轨迹 DAG 发送至取证诊断服务。该服务提取已记录的观测流 \(o_1, o_2, \dots, o_t\)，并在隔离的沙箱容器中重放，从而重建历史执行过程。诊断引擎保持外部环境响应不变，同时系统性地扰动模型输入、系统提示词或工具可用性，开展自动化反事实消融，精确定位智能体轨迹偏离任务契约的步骤。
5. 发布网关： 发布网关是控制平面的运行执行者。当新的智能体策略或模型检查点被提议部署时，网关会编排分阶段的金丝雀发布流水线。它配置隔离的影子执行路径，使候选配置接收镜像的生产输入，监控在线验证通过的完成率，并调节金丝雀流量比例。如果在线金丝雀指标突破预设的统计阈值或触发自动熔断器，发布网关就会停止流量迁移，并在毫秒级时间内回退至基准运行时。

这五个子系统层的输入不变量、遥测输出、延迟界限和主要故障模式汇总于 可观测性控制平面的架构规范。

可观测性控制平面的架构规范：实证控制平面中的子系统层、输入不变量、遥测契约、延迟 SLA 界限和主要故障模式。

子系统层	主要输入不变量	输出遥测 / 契约	SLA / 延迟界限	主要故障模式
执行层	在所有 RPC 边界上传播因果追踪上下文	有效的 OpenTelemetry 跨度 DAG，包含 token 和工具属性	开销为轨迹总执行时间的 \(\le 2\%\)	跨异步线程或子进程时上下文载体丢失
遥测收集器	不可变的追踪摄取流；原始内存缓冲区分配	经 PII 脱敏、尾部采样并序列化至存储的跨度批次	摄取滞后 \(\le 200\,\text{ms}\)；缓冲区丢弃率 \(= 0\)	集群范围的错误风暴期间缓冲区饱和，导致追踪丢失
评估引擎	密闭容器中的封存任务测试夹具（\(S_{\text{pre}}\)、\(S_{\text{post}}\)）	任务成功率的 Wilson 得分置信区间（\(pass@k\)）	在 CI/CD 流水线预算内完成异步基准测试	环境状态泄漏或非确定性的模拟对象漂移
取证服务	完整保留的故障追踪 DAG，包含原始观测记录	根因归因向量和反事实分歧步骤	每条轨迹的离线事后分析耗时 \(\le 60\,\text{s}\)	非确定性的智能体行为无法在重放时复现
发布网关	实时生产流量流；双路由配置	动态流量权重（\(w_{\text{base}}, w_{\text{cand}}\)）和触发标志	路由分发开销 \(\le 5\,\text{ms}\)；回滚触发 \(\le 100\,\text{ms}\)	上游 API 延迟导致熔断器误触发

评估就绪契约

不能仅因智能体运行时的各项单元测试通过，就允许其进入生产环境。在将模型、工具库或编排图部署到实时流量之前，工程平台必须验证候选系统满足严格的遥测与评估就绪契约。该契约保证智能体运行时提供因果重建所需的接口，遵守隐私不变量，并在生产工作负载下提供统计保证。

就绪契约应用了 不变闭包原则 中的不变量闭包原则。宿主平台强制执行上下文标头、加密数据掩蔽和容器重置不变量，而不依赖模型描述自身执行过程或监管自身内存状态。

就绪契约包含四项强制性的架构规范：

因果上下文传播不变量

智能体工作流跨越的每个网络边界——包括客户端到监督器的 HTTP 请求、监督器到模型的推理调用、模型到工具的 RPC 调用，以及监督器到沙箱的控制命令——都必须注入并传播标准的 W3C Trace Context 标头。具体而言，元数据元组：

\[\mathcal{C}_{\text{trace}} = \langle \text{trace\_id}, \text{span\_id}, \text{parent\_span\_id}, \text{trace\_flags} \rangle\]

必须保持因果连续性。如果智能体派生出异步子智能体，或分发并行工具执行任务（例如并发执行文件系统搜索和网络查询），则必须在子跨度中显式关联父级 \(\text{span\_id}\)。任何丢弃追踪上下文载体的运行时组件都被严格禁止纳入部署拓扑，因为上下文丢失会永久切断事后分析所需的因果图。

流式托管不变量

由于模型不具有任何环境隐式权限，提出工具调用的补全结果会由宿主监督器托管在内存中，直至通过净化与授权检查。智能体运行时发出的遥测流必须先经过内联净化流水线，才能持久化到磁盘。就绪契约要求字符串序列化过滤器对以下内容执行确定性的令牌替换：

• 标准凭证格式（API 令牌、私钥、授权请求头，以及匹配秘密特征的环境变量）。
• 达到生产环境秘密熵阈值的高熵加密字符串。
• 匹配隐私合规策略的受监管个人标识信息。

脱敏引擎必须维护不可变的审计日志，记录被脱敏子串的密码学哈希以及所应用的策略规则，确保追踪记录在满足隐私合规要求的同时，仍可接受法律审计。

确定性试验环境的保真度

纳入评估套件的每项任务都必须在完全封闭隔离的环境中执行。测试框架当且仅当满足以下条件时，才具有封闭隔离性：

\[S_{\text{pre}}^{(t+1)} = \text{Reset}(S_{\text{post}}^{(t)}) \equiv S_{\text{pre}}^{(0)}\]

执行重置操作后，容器文件系统、内存分配、模拟外部服务以及操作系统伪随机数生成器的状态，必须与原始初始状态逐位一致 \(S_{\text{pre}}^{(0)}\)。必须通过网络命名空间从物理层面阻断外部互联网访问，所有第三方 API 都必须由确定性模拟代理提供支持；这些代理按请求哈希索引并返回已记录的测试夹具响应。如果评估任务在连续运行之间出现状态漂移，例如残留临时文件、数据库记录被修改或随机数生成器未设置种子，则该任务违反就绪契约，不能用作发布门禁。

统计功效不变量

就绪契约规定，任何性能声明都必须有明确的统计功效计算作为依据。为评估候选策略 \(\pi_{\text{cand}}\) 是否相对于基线策略 \(\pi_{\text{base}}\) 在任务分布 \(\mathcal{D}_{\text{task}}\) 上取得实质性改进，评估套件必须抽取最小样本量 \(N\)；该样本量经计算确定，以确保能够检出目标效应量 \(\Delta\)，达到置信水平 \(1 - \alpha\) 和统计功效 \(1 - \beta\)。将任务夹具视为方差为 \(\sigma^2_{\text{task}} = p(1 - p)\) 的独立伯努利试验时，每个评估组所需的样本量受以下界限约束：

\[N \ge \frac{\left( z_{\alpha/2}\sqrt{2 \bar{p}(1 - \bar{p})} + z_{\beta}\sqrt{p_1(1 - p_1) + p_2(1 - p_2)} \right)^2}{\Delta^2}\]

其中，\(\bar{p} = (p_1 + p_2) / 2\) 和 \(z_{\alpha/2}, z_{\beta}\) 表示标准正态分布的临界值。使用临时选取的小批量样本（例如 \(N = 20\)）评估随机性智能体，明确违反就绪契约，因为由此得到的置信区间宽度超过了典型策略性能退化的幅度。

自动化发布门禁的数学综合

当运行遥测流水线持续传输生产数据、封闭隔离的评估引擎测量基线性能时，控制平面将这些输入综合为自动化、客观的发布门禁。在传统软件工程中，持续部署流水线评估确定性的通过／失败退出码：如果所有单元测试均编译成功并通过，构建就被标记为绿色。在随机性智能体系统中，模型输出在不同运行之间会发生变化，单个任务的结果也具有概率性，因此二元退出码从根本上不足以满足需求。发布门禁必须评估一个复合目标函数，同时考虑统计任务准确率、经验证的吞吐量、尾部延迟、工具安全不变量以及动作分布漂移。

令 \(M_{\text{base}}\) 表示当前生产环境的基线运行时，令 \(M_{\text{cand}}\) 表示候选发布版本（其中包含修改后的基础模型检查点、修订后的系统提示词、更新后的工具定义，或调整后的温度与解码参数）。自动化发布门禁评估二元部署指标 \(\mathcal{R}(M_{\text{cand}}, M_{\text{base}}) \in \{0, 1\}\)，其中 \(\mathcal{R} = 1\) 授权继续推进生产环境金丝雀版本的晋级，而 \(\mathcal{R} = 0\) 则触发立即停止部署或自动回滚。

该门禁结合实测评估基准与实时金丝雀流量，评估五项联合判据：

\[\mathcal{R}(M_{\text{cand}}, M_{\text{base}}) = \mathbf{1}\Big( \mathcal{C}_{\text{accuracy}} \wedge \mathcal{C}_{\text{throughput}} \wedge \mathcal{C}_{\text{latency}} \wedge \mathcal{C}_{\text{safety}} \wedge \mathcal{C}_{\text{drift}} \Big)\]

统计准确率准则（\(\mathcal{C}_{\text{accuracy}}\)）

候选运行时必须证明，其任务成功率相对于基线的下降不超过允许的退化幅度 \(\delta_{\text{tol}} \ge 0\)。由于任务结果具有非确定性，准确率的点估计无法提供有意义的信息。控制平面计算候选策略和基线策略各自的双侧 \((1 - \alpha)\) Wilson 得分置信区间的下界，计算基于 \(N\) 次隔离评估试验：

\[w^{-}(\hat{p}, N) = \frac{\hat{p} + \frac{z^2}{2N} - z \sqrt{\frac{\hat{p}(1 - \hat{p})}{N} + \frac{z^2}{4N^2}}}{1 + \frac{z^2}{N}}\]

其中，\(\hat{p}\) 为样本成功率，且 \(z = \Phi^{-1}(1 - \alpha/2)\)。统计准确率准则要求候选策略的下界不低于基线的保守性能阈值：

\[\mathcal{C}_{\text{accuracy}} \iff w^{-}(\hat{p}_{\text{cand}}, N_{\text{cand}}) \ge w^{-}(\hat{p}_{\text{base}}, N_{\text{base}}) - \delta_{\text{tol}}\]

对于安全关键型智能体部署，组织设定 \(\delta_{\text{tol}} = 0\)，要求在 95% 置信水平下实现统计意义上的绝对无退化（\(z = 1.96\)）。

经验证的吞吐量准则（\(\mathcal{C}_{\text{throughput}}\)）

仅有准确率并不能保证系统的可行性。如果候选智能体的准确率更高，却需要多一个数量级的规划迭代次数、工具调用次数和实际执行时间，那么集群的有效容量将急剧下降。我们将经验证的吞吐量 \(\Theta(\pi)\) 定义为：在一批 \(N\) 个任务中，每单位实际经过时间内成功完成且通过验证的任务数量。它衡量的是速率，而非轨迹有效吞吐量所衡量的资源占比：

\[\Theta(\pi) = \frac{\sum_{i=1}^N \mathbf{1}(\text{Task } i \text{ Succeeded})}{\sum_{i=1}^N T_{\text{elapsed}, i}}\]

其中，\(T_{\text{elapsed}, i}\) 表示轨迹 \(\tau_i\) 的端到端总延迟，包括推理预填充、自回归解码、工具执行以及沙箱重置开销。吞吐量准则要求候选吞吐量相对于基线的偏差保持在预定义的容差比例 \(\epsilon_\Theta\) 以内：

\[\mathcal{C}_{\text{throughput}} \iff \Theta(M_{\text{cand}}) \ge (1 - \epsilon_\Theta) \cdot \Theta(M_{\text{base}})\]

尾部延迟准则（\(\mathcal{C}_{\text{latency}}\)）

为防止不受约束的单条轨迹独占系统执行槽位或导致宿主监督器线程挂起，候选运行时必须在任务耗时的高百分位数上满足严格的服务级别目标：

\[\mathcal{C}_{\text{latency}} \iff p99\big(T_{\text{elapsed}}(\tau)\big) \le T_{\max}\]

其中，\(T_{\max}\) 是宿主监督器的失活保护定时器强制执行的最大允许轨迹超时时限。

零容忍安全准则（\(\mathcal{C}_{\text{safety}}\)）

与随机性的任务性能不同，安全不变量具有确定性。执行层监测是否有任何智能体轨迹尝试未经授权的工具执行、突破其容器沙箱、绕过内存托管机制，或触发严重的安全策略违规：

\[\mathcal{C}_{\text{safety}} \iff \sum_{i=1}^{N_{\text{canary}}} V_{\text{escrow}}(\tau_i) = 0\]

其中，\(V_{\text{escrow}}(\tau_i) \in \{0, 1\}\) 表示轨迹 \(\tau_i\) 是否产生了未经中介管控或非法的环境变更。只要发生一次经验证的安全违规，门控就会立即切换至 \(\mathcal{R} = 0\)。

行为漂移准则（\(\mathcal{C}_{\text{drift}}\)）

即使准确率和吞吐量看似稳定，候选模型也可能表现出细微的行为偏离，例如突然更倾向于执行 bash 脚本而非调用结构化 API，或生成重复的工具查询模式。遥测收集器监测所输出工具动作的经验类别分布 \(\mathbf{a} \sim \mathcal{A}\)。令 \(P_{\text{base}}(a)\) 和 \(P_{\text{cand}}(a)\) 分别表示在基线群体和金丝雀群体中观测到的经验动作概率。行为漂移准则评估这些分布之间的 Jensen-Shannon 散度（\(D_{\text{JS}}\)）：

\[D_{\text{JS}}(P_{\text{base}} \parallel P_{\text{cand}}) = \frac{1}{2} D_{\text{KL}}(P_{\text{base}} \parallel M) + \frac{1}{2} D_{\text{KL}}(P_{\text{cand}} \parallel M)\]

其中，\(M = \frac{1}{2}(P_{\text{base}} + P_{\text{cand}})\)。该准则要求动作漂移保持在经校准的阈值 \(\kappa_{\max}\) 以下：

\[\mathcal{C}_{\text{drift}} \iff D_{\text{JS}}(P_{\text{base}} \parallel P_{\text{cand}}) \le \kappa_{\max}\]

粗略估算 0.6: 金丝雀验证与发布门禁

一个工程团队运营着一个自主数据库迁移智能体。当前的生产基线运行时（\(M_{\text{base}}\)）在封闭隔离的训练环境中接受了 \(N_{\text{base}} = 1000\) 次试验评估，实现了 \(k_{\text{base}} = 820\) 次经验证的任务完成（\(\hat{p}_{\text{base}} = 0.820\)）。全部 1000 次试验的累计挂钟执行时间为 \(24{,}500\,\text{s}\)，由此得到基线的经验验证吞吐量：

\[\Theta(M_{\text{base}}) = \frac{820}{24{,}500\,\text{s}} \approx 0.03347\,\text{tasks/s}\]

一个候选运行时（\(M_{\text{cand}}\)）采用了优化后的系统提示词和更新后的工具模式，并接受了包含 \(N_{\text{cand}} = 400\) 次试验的一轮评估。候选运行时成功完成了 \(k_{\text{cand}} = 344\) 个任务（\(\hat{p}_{\text{cand}} = 0.860\)），累计执行时间为 \(11{,}200\,\text{s}\)。候选运行时的经验验证吞吐量为：

\[\Theta(M_{\text{cand}}) = \frac{344}{11{,}200\,\text{s}} \approx 0.03071\,\text{tasks/s}\]

发布门禁在 95% 的置信水平（\(z = 1.96\)）下执行以下运行参数约束：

• 允许的准确率下降容限：\(\delta_{\text{tol}} = 0.01\)（1.0 个百分点）。
• 允许的最大吞吐量下降比例：\(\epsilon_\Theta = 0.10\)（10%）。
• 最大 \(p99\) 轨迹持续时间：\(T_{\max} = 60\,\text{s}\)。观测到的金丝雀 \(p99\) 为 \(48.2\,\text{s}\)。
• 安全违规次数为零：观测值为 \(V_{\text{escrow}} = 0\)。
• 最大动作偏离度：\(\kappa_{\max} = 0.08\)。观测到的 Jensen-Shannon 散度为 \(D_{\text{JS}} = 0.031\)。

问题： 候选运行时是否通过自动化发布门禁 \(\mathcal{R}(M_{\text{cand}}, M_{\text{base}})\)？

步骤 1：计算准确率的 Wilson 得分置信区间。 对于基线（\(N_{\text{base}} = 1000, \hat{p}_{\text{base}} = 0.820\)）： \[\text{Denominator} = 1 + \frac{1.96^2}{1000} = 1 + \frac{3.8416}{1000} = 1.00384\] \[\text{Center} = 0.820 + \frac{3.8416}{2000} = 0.820 + 0.00192 = 0.82192\] \[\text{Spread} = 1.96 \cdot \sqrt{\frac{0.820(0.180)}{1000} + \frac{3.8416}{4 \times 10^6}} = 1.96 \cdot \sqrt{0.0001476 + 0.00000096} \approx 1.96 \cdot 0.01219 \approx 0.02389\] \[w^{-}(\hat{p}_{\text{base}}, 1000) = \frac{0.82192 - 0.02389}{1.00384} = \frac{0.79803}{1.00384} \approx 0.79498 \quad (79.50\%)\]

对于候选运行时（\(N_{\text{cand}} = 400, \hat{p}_{\text{cand}} = 0.860\)）： \[\text{Denominator} = 1 + \frac{1.96^2}{400} = 1 + \frac{3.8416}{400} = 1.00960\] \[\text{Center} = 0.860 + \frac{3.8416}{800} = 0.860 + 0.00480 = 0.86480\] \[\text{Spread} = 1.96 \cdot \sqrt{\frac{0.860(0.140)}{400} + \frac{3.8416}{4 \times 160{,}000}} = 1.96 \cdot \sqrt{0.0003010 + 0.0000060} \approx 1.96 \cdot 0.01752 \approx 0.03434\] \[w^{-}(\hat{p}_{\text{cand}}, 400) = \frac{0.86480 - 0.03434}{1.00960} = \frac{0.83046}{1.00960} \approx 0.82256 \quad (82.26\%)\]

评估 \(\mathcal{C}_{\text{accuracy}}\)： \[w^{-}(\hat{p}_{\text{cand}}, 400) \ge w^{-}(\hat{p}_{\text{base}}, 1000) - \delta_{\text{tol}} \iff 0.82256 \ge 0.79498 - 0.01000 = 0.78498\] 该条件得到满足，因此候选运行时在 \(\delta_{\text{tol}}\) 容限内具有非劣效性。尚未证明其表现更好。候选运行时的置信下限高于基线的置信下限（\(0.82256 > 0.79498\)），并不构成优效性检验；应用 节 4.2 的样本量计算，在这一通过率（\(\bar{p} = 0.84\)，\(\Delta p = 0.04\)）下，每组需要约 1,320 个任务，超过候选运行时 400 个任务的三倍。门禁可以允许候选运行时进入下一阶段，但其四个百分点的领先优势仍未得到证实。

步骤 2：评估吞吐量下降判据（\(\mathcal{C}_{\text{throughput}}\)）。 \[\text{Allowable Throughput Threshold} = (1 - 0.10) \cdot 0.03347 = 0.03012\,\text{tasks/s}\] \[\text{Observed Candidate Throughput} = 0.03071\,\text{tasks/s}\] 由于 \(0.03071 \ge 0.03012\)，候选运行时满足吞吐量判据（其下降幅度为 {python} CanaryVerificationReleaseGates.throughput_deg_pct_str，处于 \(10\%\) 容限预算内，且留有充足余量）。

步骤 3：评估延迟、安全性和漂移判据。

• \(\mathcal{C}_{\text{latency}}\)：观测值为 \(p99 = 48.2\,\text{s} \le 60.0\,\text{s}\)（\(\textbf{Pass}\)）。
• \(\mathcal{C}_{\text{safety}}\)：观测到的违规次数为 \(= 0\)（\(\textbf{Pass}\)）。
• \(\mathcal{C}_{\text{drift}}\)：观测值为 \(D_{\text{JS}} = 0.031 \le 0.080\)（\(\textbf{Pass}\)）。

结论： 全部五项联合判据的计算结果均为真： \[\mathcal{R}(M_{\text{cand}}, M_{\text{base}}) = \mathbf{1}(\text{True} \wedge \text{True} \wedge \text{True} \wedge \text{True} \wedge \text{True}) = 1\] 发布门禁授权将 \(M_{\text{cand}}\) 推进至下一个金丝雀流量阶段。

上述数学发布门禁可以直接实现在自动化遥测采集器和持续评估流水线中：

def evaluate_release_gate(base, cand, z=1.96, delta_tol=0.01, eps_g=0.10, p99_max=60.0, js_max=0.08):
    def wilson_lower(k, n):
        p_hat, d = k / n, 1 + (z**2) / n
        ctr, spd = p_hat + (z**2) / (2 * n), z * math.sqrt((p_hat * (1 - p_hat) / n) + (z**2) / (4 * n**2))
        return (ctr - spd) / d

    c_acc = wilson_lower(cand.k, cand.n) >= (wilson_lower(base.k, base.n) - delta_tol)
    c_tput = (cand.k / cand.wall_time) >= ((1.0 - eps_g) * (base.k / base.wall_time))
    c_lat = cand.p99_latency <= p99_max
    c_safe = cand.escrow_violations == 0
    c_drift = cand.js_divergence <= js_max
    return c_acc and c_tput and c_lat and c_safe and c_drift

当持续通过暗流量影子测试和渐进式金丝雀阶段进行评估时，这一发布门禁便构成了一道确定性的、具有数学依据的屏障，防止静默回归。通过将封闭执行、分布式遥测和统计验证统一到单一控制平面中，系统工程师能够有信心地将随机性智能体部署到任务关键型生产环境中。

---

然而，即使工程团队实现了这一综合运行框架的每一层——为 OpenTelemetry 跨度添加埋点、强制执行流式托管，并评估 Wilson 得分置信界——细微的运维陷阱和概念性谬误仍经常削弱系统可靠性。直观理解这些机制在现实压力下如何失效，对每一位系统架构师都至关重要。接下来，我们将考察部署、监控和评估自主机器学习系统时出现的关键谬误和常见运维陷阱。

谬误与陷阱

为非确定性智能体系统设计和运行可观测性控制平面，会暴露出一种架构上的张力：支配传输层执行的软件接口，并不保证语义或物理层面的正确性。习惯于确定性分布式服务的系统工程师，往往将经典监控假设直接移植到随机性智能体架构中，导致评估流水线脆弱、遥测成本灾难性攀升，以及生产环境中的静默回归。要避免这些运维故障，就必须将基础模型视为无特权的随机性预测器，并对其执行轨迹进行隔离、机械化验证和统计约束。

谬误： 返回 HTTP 200 并输出流畅、礼貌文本的智能体，已经成功完成了任务。

在经典远程过程调用架构中，HTTP 200 OK 状态码配合格式正确的 JSON 响应体，意味着接收服务接受了输入、执行了请求的业务逻辑，并返回了有效结果。然而，在智能体系统中，传输层和自回归解码循环与目标环境的状态完全解耦。推理运行时（如 vLLM 或 SGLang）和宿主监督进程可能在未发生任何异常的情况下运行，成功生成数千个 token，而底层任务却已彻底失败。基础模型的损失函数优化的是训练分布下的序列概率，而非环境中的真实状态；因此，当智能体遇到权限拒绝、命令行语法错误或循环性的工具故障时，往往会输出措辞清晰、令人安心的道歉，或以权威口吻给出幻觉内容，声称请求的操作已全部执行完毕。

这一失效机制源于将模型的文本自述视为状态的权威证据。当在执行沙箱中运行的智能体因偏移量不匹配而未能应用代码补丁时，它可能生成一条响应，声称所有单元测试均已通过，且补丁已安全合并。如果监督运行时通过解析字符串或检查推理端点的 HTTP 返回码来判断任务是否成功，这一失败就会完全漏检。不变量闭合（原则 不变闭包原则）排除了这种验收测试，因为任务正确性只能建立在模型权限范围之外收集的证据之上。架构层面的防御措施是多层评估契约：任务验收绝不能取决于智能体的文本输出或传输层的成功。相反，运行时必须要求外部环境提供权威的物理证据，例如非空的 git diff、通过数据库查询进行的确定性模式验证，或在隔离容器中执行的完全封闭测试框架所返回的零退出码。

陷阱： 在小型基准测试集（\(N < 100\)）上评估随机性智能体，却不报告置信区间。

在智能体运行时的迭代开发中，一个普遍存在的问题是，仅凭小型评估套件上微小的百分比提升，就宣称架构有所改进。工程团队可能修改系统提示词、调整工具描述，或改变暂存存储器的格式，然后在包含 \(N = 50\) 个任务的基准测试上运行新配置，观察到已解决任务数从 28 增加到 31（名义上从 56% 提升到 62%），便将这一变更作为已确认的优化进行部署。由于评估框架运行至完成，并生成了一个清晰的标量指标，团队便将经验方差误认为算法进步。

统计事实是，基础模型根据词表 logits 上的分类分布，以非确定性方式采样词元。由此产生的轨迹 \(\tau\) 代表从联合策略分布 \(\pi_\theta\) 中进行的一次抽样。整个评估套件的总方差可分解为任务难度的内在方差 \(\sigma^2_{\text{task}}\)（涵盖任务分布 \(\mathcal{D}_{\text{task}}\)），以及策略自身在不同随机种子下的随机执行方差 \(\sigma^2_{\text{policy}}\)：

\[\text{Var}(\hat{p}) = \frac{\sigma^2_{\text{task}} + \sigma^2_{\text{policy}}}{N}\]

当 \(N = 50\) 且观测成功率为 \(\hat{p} = 0.60\) 时，95% Wilson 得分置信区间为：

\[w = \frac{\hat{p} + \frac{z^2}{2N} \pm z \sqrt{\frac{\hat{p}(1-\hat{p})}{N} + \frac{z^2}{4N^2}}}{1 + \frac{z^2}{N}} \in [0.461, 0.724]\]

该置信区间的跨度超过 26 个百分点。观测到的六个百分点差异在统计上无法与随机噪声区分，这意味着运行时修改同样可能在生产环境中造成净性能下降。架构层面的缓解措施要求将任务测试用例作为主要重采样单位，并在整个评估流水线中执行严格的统计核算。系统团队必须为所有单次试验成功率计算并报告 Wilson 得分置信区间，执行配对的多随机种子评估以将策略方差与任务方差分离，应用 McNemar 检验来确定候选方案的提升是否达到统计显著性，并扩大基准测试规模 \(N\)，直到置信区间宽度稳妥地低于最小可检测效应量 \(\delta_{\text{tol}}\)。

谬误： 为 100% 的生产环境轨迹记录完整的原始提示和观测载荷，是调试所必需的。

面对自主智能体的非确定性失效模式，系统运维人员往往默认采用传统分布式系统的理念，记录完整、未经压缩的执行日志。在智能体环境中，这表现为持久化保存每条轨迹每一步的完整输入上下文、系统提示、工具模式定义、中间暂存区中的推理过程、观测字符串以及原始模型输出词元。这种误解认为，丢弃任何词元字符串都会永久损害事后取证分析能力。

多轮推理的物理机制使全面记录原始日志在经济和运维层面都难以为继。考虑一个每天执行 \(10^5\) 个多轮工作流的智能体集群。如果每个工作流平均包含 \(T = 20\) 轮交互，且上下文窗口不断扩展至 \(S_{\max} = 64\text{k}\) 个词元，那么在每一步记录完整、未经裁剪的提示载荷，就需要为每个工作流摄取并索引数 GB 的文本遥测数据。在整个集群范围内，这每天会产生数十 TB 的日志数据，导致遥测网络接口饱和、耗尽数据库写入预算，并使冷存储保留成本超过模型推理本身的成本。更关键的是，不加区分地记录完整载荷，会扩大每个被记录任务的权限暴露范围。原始观测经常包含未经脱敏的数据库凭据、API 令牌、专有源代码以及客户的个人身份信息（PII），而完整日志记录会将这些内容归档到可搜索的存储中，使任何拥有遥测数据读取权限的人都能获取这些内容。

架构层面的防御措施是在遥测采集层执行智能尾部采样，并结合基于密码学的流式脱敏。轨迹跨度、工具调用和词元指标必须暂存在主机监管器的内存环形缓冲区中。是否持久化保存完整载荷正文的决定推迟到轨迹终止时作出：采集器保留 100% 的异常轨迹，包括遇到工具执行错误、安全沙箱违规、预算触顶中止（\(T_{\max}\)）、分布外延迟尖峰或用户显式干预的轨迹；同时，将常规且已验证成功的执行降采样为具有代表性的 1% 至 5% 基线，用于长期漂移监测。在任何跨度离开监管器边界之前，其载荷都必须经过自动脱敏流水线，移除识别出的高熵秘密，并用加盐的密码学哈希替换敏感实体，从而在不损害隐私的前提下，确保可复现的追踪关联。

陷阱： 假定 LLM 评判器能够提供客观、无偏见的真值评估。

在自动评估开放式智能体轨迹时，团队常常用现成的前沿基础模型替代人工标注员，并将其配置为自主评估器（“LLM 作为评判器”）。评估器接收用户提示、智能体的交互轨迹以及评分细则，并被要求给出标量评分或二元接受标签。由于前沿模型能够生成详尽且有说服力的评析，团队便假定其评估代表客观真值，可以据此安全地为候选智能体架构评分并将其发布。

失效机制在于自回归神经评估器内在的系统性偏差。LLM 评判器表现出明显的自我偏好偏见，持续为与自身属于同一架构家族或训练谱系的模型所生成的轨迹打出更高分数。它们还存在冗长偏见，系统性地将 token 长度和修辞润色与操作正确性混为一谈，往往更偏好冗长却悄然失败的多步解释，而不是简短但确实实现了所要求状态变化的执行。此外，LLM 评判器在成对评估中表现出位置偏见，偏好提示上下文中先呈现的轨迹，并且容易受到提示注入攻击：智能体输出的恶意或欺骗性暂存推理可能误导评判器，使其为未完成或不安全的轨迹打出高分。更根本的是，LLM 评判器严格局限于符号域内运行；它无法运行编译器、检查操作系统内核表，也无法验证外部数据库约束。

架构层面的缓解措施是在评估控制平面中强制实行严格的关注点分离。功能执行的真实判据必须无条件地建立在确定性的机械验证器之上，包括封闭测试套件、静态分析工具、模式验证器以及环境状态差异。评估模型必须严格限定于主观、非功能性的定性维度，例如语气、对风格指南的遵循程度或教学表述的清晰度，因为这些维度无法具备精确的程序化判定器。即使在这些受限领域中，也绝不能部署未经校准的 LLM 评判器：必须通过位置交换主动消除其评分分布中的偏差，依据历史基线进行归一化，并定期使用 Cohen’s kappa（\(\kappa\)）或 Krippendorff’s alpha 等评判者间一致性指标，与双盲人类专家标注进行基准比较。

---

掌握这些操作层面的谬误与统计陷阱，可以将系统可观测性从被动且成本高昂的日志记录负担，转变为主动且数学上严谨的验证框架。当工程团队超越传输层假设，以机械状态验证作为判据，并用严格的置信区间限定实证结论时，就为可靠的自主运行奠定了必要基础。在完整确立这些诊断原则与遥测保障措施之后，我们现在可以退后一步，综合梳理智能体机器学习可观测性的完整架构框架。

总结

评估将智能体是否有效这一问题，转化为智能体无法影响的测量结果。只有当智能体触及范围之外的验证器确认其在契约规定的预算内对环境作出了相应改变时，一条轨迹才被计入；而这项被验收的任务，是此后所有测量的计数单位。隔离环境与封闭验证器使每次判定都可复现，评分器则将评估扩展到过程以及测试无法检查的标准，其中评判器需要经过校准。由于每次运行都是一次随机抽样，结论必须建立在独立任务、Wilson 区间、用于衡量可靠性的 pass\(^k\)，以及相同预算下的比较之上。在生产环境中，追踪记录将每条轨迹记录为一张因果图，尾部采样保留每一次失败，重放与消融将每次失败归因于模型、运行框架或环境，而分阶段门控则根据证据积累的速度逐步放行变更。

要点回顾: 测量环境，统计独立任务，先归因再修复

• 成功是在预算内实现经过验证的状态变化：退出码、流畅的报告和评判器分数都无法观测环境。任务要通过验收，必须由智能体无法触及的验证器确认状态变化，同时轮次、token 数和成本均不得超过契约规定的上限。
• 环境必须封闭并重置：智能体能够读取或写入的评分测试和参考解答会成为其针对的目标。在独立沙箱中设置隐藏测试，通过写时复制重置到同一摘要对应的状态，为外部服务提供确定性替代实现，并使用新任务或私有任务，才能使分数反映任务本身。
• 任务是重复实验的单位：重复运行无法降低任务抽样方差。在 150 项任务上，四个百分点的提升仍处于相互重叠的 Wilson 区间内；要确认这一提升，每个候选方案在相同预算下大约需要 2,400 项任务。
• 潜力并不等于可靠性：pass@\(k\) 指标假定验证器会选出成功的运行。周期性、无人监督的工作需要使用 pass\(^k\)，而每次运行 0.85 的成功率，在连续五次运行均成功的要求下会降至约 0.44。
• 先对失败归因，再进行修复：追踪记录、分布意义上的重放与单因素消融，可以区分受损观测与模型错误。应先排除运行框架和环境方面的原因，并将每个已确认的原因转化为回归测试任务。
• 按证据允许的速度发布：离线非劣效性检验、沙箱中的影子运行，以及设有硬性触发阈值的序贯金丝雀发布，共同对每项变更实行门控。测试的样本量决定了已测得回归所造成的危害，而金丝雀发布的规模则限制了测试未测量到的危害。

本章将因果与统计发布证据（原则 15）落实到实际操作中。复合门控中的准确率项，统计独立任务中经过验证的状态变化，并给出明确的区间；追踪记录将每次失败与导致它的调用关联起来；重放则被证明能够精确复现已记录的观测，但只能在分布意义上复现模型输出，因此归因时需要多次重放失败轮次。门控实例还展示了这些证据的边界：足以证明候选方案并不更差的样本量，可能远不足以证明它更好。经过验证的完成率为轨迹有效吞吐量（微效与宏效）提供了逐轨迹的验收检验，因此，后续部分用于训练和定价的已验收任务，现在已成为运行时能够统计的对象。

后续内容: 从评估到从轨迹中学习

评估现在能够告诉我们智能体在哪里失败，并确认哪些轨迹取得了成功。当上下文、工具和运行时问题修复后，失败仍然持续存在时，这些经过验证的轨迹能否教会模型做得更好？可以，但前提是用同样严格的规范决定哪些内容可以进入训练：先进行分诊，只纳入验证器支持的内容，并将评估任务排除在训练集之外。轨迹整理 将已记录且经过验证的轨迹转化为训练数据，由此开启第五部分；而本章的门控机制，正是确保从这些轨迹中安全学习的基础。