轨迹整理
目的
为什么用智能体自身记录的轨迹训练它，往往反而会使它表现更差？
部署后的智能体会为它尝试执行的每项任务记录一条轨迹，而掌握了这些轨迹评估方法的团队，很快就会积累数百万条轨迹。直觉上的下一步是用这些记录进行训练，但这通常是错误的选择。日志中的大多数失败从来就不是模型本身的过错。它们源于上下文中缺失的事实、含糊不清的工具模式，或超时的沙箱，而在模型权重之外修复这些问题，既更快，也更容易回退。许多成功也并非表面上看起来的那样，因为智能体可能靠运气、漫无目的的尝试，或修改用于评判它的测试而通过验证。用这些记录训练的模型，会学到它自身走过的弯路、宿主环境中不稳定的基础设施，以及检查机制未能识别的捷径；如果评估任务与训练数据中的任务重叠，评估就会将这种损害报告为进步。轨迹整理是介于日志与训练运行之间的一套严谨方法。它决定哪些失败确实值得通过训练来修复、哪些轨迹能够得到验证器的担保、这些轨迹以何种配比才值得学习，以及如何排除所有评估任务。训练会改变模型，却不会改变 H·S·A 的三类暴露，因此，语料库必须覆盖部署后的智能体实际面对的时间跨度、状态和权限，而且轨迹准入证据必须与这些暴露所要求的闭环保障同样有力。
学习目标
- 在选择训练作为修复手段之前，先诊断智能体失败属于上下文、接口、运行时还是策略缺陷。
- 为代码类和非代码类任务设计带版本的任务测试夹具，其判定机制应能够区分成功与失败。
- 构建按成本排序的准入验证器级联，并计算每条获准纳入的轨迹所需的成本。
- 解释为什么学习型排序器和 LLM 评判器可以对候选轨迹排序，却不能单独决定其准入。
- 按词元数规定监督训练轨迹的配比，并论证为何应将困难负例排除在外。
- 分析自我改进循环中的任务信息价值、数据陈旧性和坍塌问题，并设定其刷新频率。
- 对获准纳入的语料库严格执行来源追溯、保持语法结构的脱敏、数据划分卫生管理和去污染。
能力差距诊断
在升级到模型重新训练之前，穷尽确定性的运行时干预层级可解决 90% 的失败，而这些干预层级的延迟跨度达四个数量级。
当一个自主数据库迁移智能体在多个生产集群的模式变更任务中反复失败时，工程团队就面临一个根本性的系统难题。 在遥测日志中，智能体在执行 ALTER TABLE 操作时生成无效的 SQL 语句，引发语法错误异常，进而触发数据库事务回滚。许多机器学习工程团队的第一反应，是将这种失败归类为模型的根本性缺陷，并立即安排一次成本高昂的监督微调，使用数千份经过整理的数据库迁移脚本进行训练。然而，对执行轨迹进行严谨的取证式分解后发现，向模型暴露的工具模式 execute_sql(query: string) 遗漏了目标数据库引擎的方言和版本。由于暂存上下文缓冲区中缺少这一环境约束，模型默认生成了有效的 PostgreSQL 语法，而实际执行的目标却是正在运行的 MySQL 8.0 集群。在 JSON 模式规范中加入显式的 engine_dialect 枚举，并将目标引擎版本注入上下文窗口后，100% 的失败立即得到解决，且没有修改任何一个模型权重。
在选择策略适配之前，运行时工程师必须严格诊断所观察到的失败究竟源于信息不足、工具接口歧义、运行时缺陷，还是真正的模型能力不足。将参数适配作为首选补救机制，是一种被称为过早微调陷阱的架构反模式。在计算机系统设计中，调整基础模型的参数权重 \(\Theta\)，是整个智能体软件栈中最慢（\(T_{\text{train}} \ge 10^4\text{ s}\)）、资本投入最大、可观测性最低且最难回退的干预手段。修改上下文中的提示词、丰富检索查询或修补工具模式，部署延迟几乎为零（\(T_{\text{deploy}} \le 1\text{ s}\)），并且支持确定性的 git 级回滚；而重新训练神经策略会消耗大量加速器集群机时，使下游推理缓存结构失效，并带来严重的运维风险：此前已验证的能力可能发生灾难性遗忘。
运行中的智能体集群会持续记录尝试过程，而其中大多数记录并不构成训练信号。一条执行轨迹可能因上下文缺少某个事实、工具模式存在歧义、沙箱超时，或策略无法完成任务而失败，只有最后一种原因才能通过修改权重来修复。执行轨迹也可能因错误的原因而成功，例如靠运气或修改自身的测试。本章将轨迹采集视为策略编译器的准入阶段，探讨哪些失败有资格进入训练语料库，以及在任何执行轨迹获准进入之前，运行时必须构建哪些机制，即可复现的测试夹具、按顺序执行的级联验证器、恢复轨迹通道，以及不会发生泄漏的评估数据划分。
将未经筛选整理的原始生产遥测数据直接灌入训练数据集，会形成灾难性的自我强化失败循环。未经过滤的执行轨迹主要由瞬时基础设施故障、反复重试造成的抖动、低效搜索路径，以及听起来可信的幻觉构成。如果工程团队贸然使用自身未经验证的运行轨迹来训练模型，微调后的策略只会记住历史上的低效行为，并学会以更高的置信度模仿过去的失败模式。因此，轨迹采集不能充当被动的日志接收端。在任何执行轨迹获准进入离线学习流水线之前，必须对每一个观察到的异常进行诊断分流。
遥测中的验证关卡拒绝：由于模型不具有任何隐式权限，它发出的每一次工具调用都只是运行时可以拒绝的提议。运行轨迹中记录的失败，往往反映的是运行时验证关卡的拒绝，而非环境故障；遥测必须将二者分别归类。
轨迹采集承接了 Fail-Plausible 故障模型 和 不变闭包原则 中的两个事实。失败轨迹很少会直接揭示其原因，因为即使失败仍显得合理的模型，会基于对宿主状态的错误假设发出格式正确的调用；而模型声称成功，并不具有任何证据效力。因此，失败本身并不能说明必须修改哪一层。
为防止过早更新参数并指导轨迹采集，智能体运行时必须对每一条异常执行轨迹进行系统性的取证诊断，区分四种互斥的根因，概述见 表 1：
| 失败类别 | 子系统根因 | 可观测的遥测特征 | 实证诊断探测 | 最低成本补救措施 |
|---|---|---|---|---|
| 上下文不足 | 工作集 / 记忆（§上下文工程长期记忆） | 工具因缺少文件路径、环境标志或配置状态而失败。 | 向提示词缓冲区注入标准答案上下文片段；测量通过率 \(\Delta\)。 | 丰富检索索引，改进上下文压缩，固定关键状态。 |
| 接口歧义 | 工具虚拟化（§工具调用） | 模式解析错误、缺少必需参数或枚举值无效。 | 使用具有严格枚举约束的显式 JSON Schema 重放执行轨迹。 | 添加严格的类型定义、参数边界和明确的文档字符串。 |
| 运行时缺陷 | 沙箱底层（§智能体沙箱智能体运行框架） | 子进程超时（\(T > T_{\text{limit}}\)）、网络丢包、因内存不足（OOM）而被终止。 | 在提高资源限额的干净宿主容器中执行相同的工具调用载荷。 | 强化沙箱隔离，调整看门狗超时设置，实现退避重试。 |
| 策略能力不足 | 神经核心策略（§模型调用边界测试时计算） | 多步逻辑错误、规划循环、无法从工具错误中恢复。 | 提供完整的标准答案上下文和模式；模型仍无法完成多步任务。 | 采集恢复轨迹，用于 SFT（§轨迹微调）或 RLVR（§可验证奖励强化学习）。 |
当检索引擎、记忆管理器或工作集组装器未能向模型的当前上下文窗口提供关键环境状态时，就会出现上下文缺失。智能体失败并非因为其内部推理权重能力不足，而是因为所需事实——例如当前使用的库版本、环境变量或导入的接口签名——已被逐出，或从未被检索到。当工具定义、参数类型或描述语义的文档字符串相互矛盾、规定不充分，或在结构上与运行时底层的执行分派机制不匹配时，就会出现接口歧义。如果智能体输出了无效参数，或未能调用已有能力，缺陷几乎总是出在呈现给模型的模式契约上，而非神经核心的推理能力上。运行时缺陷完全源于模型下方的执行底层：沙箱容器启动超时、microVM 网络连接中断、宿主机内核的内存不足（OOM）终止机制杀死进程、文件系统权限不匹配，或异步 RPC 分派期间的竞态条件。通过微调一个拥有 700 亿参数的模型来弥补临时容器超时或未处理的套接字断连，是对工程资源的灾难性误用。
只有当遥测证明上下文缓冲区包含全部必要证据、工具模式在数学上无歧义，且运行时以确定性方式执行而无缺陷时，才能将一次失败归类为真正的策略能力不足。这一剩余类别涵盖程序性推理失效、算法幻觉、无法分解多步骤任务，以及无法从有效错误返回中恢复的灾难性失败。只有这一类别才构成离线策略学习的真正训练信号，因此，经验证的轨迹后训练（原则 16）要求在任何权重变更之前完成这种分诊。其他所有类别的问题都能在权重之下的系统层中得到更快、也更易回退的修复。
为将这种取证式分诊落实到实际运行中，智能体运行时强制执行系统干预阶梯。系统工程师必须先穷尽成本更低、具有确定性且易于回退的各层措施，才能升级到随机性参数适配： \[\text{Context Injection} \prec \text{Tool and Schema Redesign} \prec \text{Runtime Hardening} \prec \text{Supervised Policy Adaptation} \prec \text{Reinforcement Learning}\]
这一递进过程直接体现了 Saltzer、Reed 和 Clark 提出的经典系统设计中的端到端论证 (Saltzer 等 1984年)：如果某项系统功能能够通过应用边界处的轻量机制完整且正确地实现，就不应将其实现在架构中更底层、更沉重的层次上。当底层工具模式缺乏显式类型约束时，试图通过微调模型权重来“教会”智能体一个 API 签名，直接违反了这一原则。通过微调模型来弥补上游接口缺陷，会产生脆弱的记忆：下游 API 一旦发生变化，训练后的权重就会过时。相比之下，类型化动作契约（原则 8）与完整的上下文能够建立不变量，对其后接入的任何模型都成立。
分诊本身不能交给模型。自我报告处于闭环证据等级的最底层（闭合证据等级），而要求模型“反思你之前的回答”的提示，只会发起另一次受相同限制约束的调用。因此，每一项分诊判定都依赖模型之外的检查，例如强制保证类型健全性的编译器、验证语法不变量的静态检查工具、审计系统调用的安全监控器，以及评估状态变化的沙箱化测试套件。
图 1 中形式化定义的分诊级联机制将这一验证边界落实为具体操作：在监督器看门狗或非零退出处理程序处拦截每一处轨迹异常，并使其依次通过四道确定性评估关卡：
- 关卡 1（执行底层遥测）审计内核 cgroup 退出码、OOM 杀手触发事件和 microVM 超时，以便在审查模型权重之前捕获运行时缺陷。
- 关卡 2（上下文窗口与工作集）依据当前工作区审计提示词的词元组装和检索召回情况，以拦截状态驱逐导致的上下文缺失。
- 关卡 3（工具接口与模式类型约束）依据严格的 JSON Schema 和参数边界评估输出的参数，以在工具契约边界处定位接口歧义。
- 关卡 4（不变量判定器与状态增量）执行隔离测试套件和状态差异审计（\(\Delta_{\text{fs}}\)），以区分无害的重试循环与真正的策略能力不足。 只有通过全部四道关卡的执行轨迹才能实现确定性验证闭合并进入训练语料库；未能通过前面关卡的轨迹会立即触发低成本的系统补救措施——运行时加固、上下文注入或模式重设计——从而避免不必要的模型再训练。
Example 0.1: 系统干预阶梯的权衡
工程团队评估了两条补救路径。在策略 A（系统干预阶梯）下，工程师通过严格的 JSON Schema 契约消除接口歧义，利用异步容器池加固沙箱运行时，并隔离剩余的 \(300\) 真正策略失败。在策略 B（过早微调）下，工程师收集全部 \(3{,}000\) 条原始失败轨迹，生成合成修正数据，并在一个 8-GPU 节点上对一个开放权重的 70B 参数模型执行完整的监督微调（SFT）。
请从工程投入、以 FLOPs 衡量的训练计算量、财务支出、部署延迟和灾难性遗忘风险等方面评估这两种策略。假设模型参数量为 \(70\text{B}\)（\(N_{\text{params}} = 70 \times 10^9\)），平均序列长度为 \(L = 4{,}096\) 个词元，训练 \(E = 3\) 个轮次，使用一个配备 NVIDIA H100 SXM5 加速器的 8-GPU 节点（每个 GPU 的稠密 BF16 计算性能为 \(989\text{ TFLOP/s}\)，MFU 为 \(45\%\)），云租赁费率为 \(\$3.50\text{ per GPU-hour}\), and an engineering labor rate of \(\$150\text{ per hour}\)。
解答：
策略 A：系统干预阶梯（模式修复与运行时加固）。 为 OpenAPI 和 JSON 模式添加严格的枚举约束和显式类型，约需 \(4\) 个工程工时。在沙箱守护进程中实现异步容器预热池，需要 \(12\) 个工程工时，使总人工成本达到 \(16\text{ hours} \times \$150/\text{hr} = \$2{,}400\)。由于模式验证和容器池完全在现有主机 CPU 基础设施上运行，训练计算开销恰为零 FLOPs，GPU 费用也为零。模式更新和运行时配置通过持续集成在 \(T_{\text{deploy}} \le 15\text{ minutes}\) 内完成部署。这种干预完全是确定性的：如果模式修改引入了意外回归，可通过版本控制立即回滚，因此不会给无关能力带来任何灾难性遗忘风险（\(\Delta \text{Acc}_{\text{unrelated}} = 0\%\)）。关键在于，这可以永久解决每月 \(70\% + 20\% = 90\%\) 的失败（\(2{,}700\) 项任务），从而将剩余的 \(300\) 真实策略能力缺口隔离出来，供针对性轨迹整理使用。
策略 B：过早进行监督微调。 对自回归 Transformer 进行微调，每轮训练中每个词元约需 \(6 \times N_{\text{params}}\) 次浮点运算（前向计算需要 \(2\) FLOPs，反向梯度传播需要 \(4\) FLOPs）。将 \(3{,}000\) 条轨迹打包至 \(L = 4{,}096\) 个词元，并训练 \(E = 3\) 轮，数据集共包含 \(1.2288 \times 10^7\) 个词元，需要 \(1.548 \times 10^{19}\text{ FLOPs}\) 的总训练计算量。在一个配备 8 块 NVIDIA H100 SXM5 加速器的 GPU 节点上，以 \(45\%\) 的模型 FLOPs 利用率运行时，集群吞吐量达到 \(3.560 \times 10^{15}\text{ FLOP/s}\)，实际训练时间为 \(T_{\text{train}} \approx 4{,}348\text{ seconds}\)（\(1.21\text{ hours}\)）。计入数据集词元化、检查点评估、评估框架运行和权重量化后，集群总占用时间达到 \(6\text{ wall-clock hours}\)，产生 \(\$168\) in raw compute (\(48\text{ GPU-hours} \times \$3.50/\text{hr}\)）。合成轨迹整理、数据集清洗、训练流水线编排和训练后回归审计耗费 \(40\) 个工程工时（\(\$6{,}000\)). Checkpoint validation, regression benchmarking across coding suites, and serving engine canary rollout extend deployment latency to \(T_{\text{deploy}} \approx 48\text{ hours}\). Furthermore, standard post-training evaluations on 70B models fine-tuned on narrow tool traces frequently exhibit an accuracy degradation of \(\Delta \text{Acc}_{\text{general}} \approx -2.5\%\) to \(-4.0\%\)，原因是参数漂移导致通用推理基准上的性能下降。最关键的是，由于底层系统根因——模式中缺失的枚举定义和容器超时——从未在运行时得到修复，微调后的模型仍会遭遇容器超时；而当外部工具 API 更改参数签名时，新训练的权重就会完全失效。
结论：策略 A 以确定性的方式解决 \(90\%\) 的故障，部署延迟不到一小时，计算开销为零，模型性能回退风险为零。策略 B 中过早进行的微调带来大量工程开销，将部署延迟增加两个数量级，引入灾难性遗忘，而且未能消除底层系统故障。
只有当系统性的诊断分流确认某项故障确实反映了策略能力缺口时，离线学习流水线才会启动；这类操作挑战发生时，上下文缓冲区完整、工具模式明确无歧义，且运行时底层设施执行无缺陷。然而，原始生产遥测数据仍具有非确定性、充满噪声，并受到临时依赖项、未记录的环境变量和已过期网络凭据的污染。要将真实世界中的故障转化为持久有效的训练信号，系统工程师不能简单地回放未经整理的日志。相反，运行时必须构建隔离且可复现的任务夹具，其中包含不可变的初始环境状态、固定的依赖项版本、亚秒级重置框架，以及明确且可机械判定的完成标准。智能体运行时必须如何设计这些任务夹具，才能让数千个并行轨迹采样工作进程可靠地执行、验证并收集干净的示范轨迹，而不发生状态损坏？
任务夹具设计
当未隔离的智能体轨迹采样在依赖项版本未固定的软件环境中执行时，模型尚未生成任何词元，非确定性就已进入训练循环。外部软件包仓库中一次微小的依赖项更新、一个未记录的环境变量，或上一轮执行遗留的未清理套接字，都会悄然改变执行底层设施。这类状态污染会产生不可复现的轨迹，破坏策略梯度，或以虚假的因果关系污染下游微调语料。在在线智能体循环中，执行轨迹记录的是神经网络策略与有状态环境之间的交互；如果环境的状态转移函数在不同轨迹采样之间发生不可预测的波动，那么所得轨迹就毫无科学或教学价值。
有效的轨迹收集需要可复现的任务夹具——不可变的初始环境状态、固定的依赖项版本、重置框架，以及明确且可机械判定的完成标准。正如硬件架构师需要标准化的周期精确基准测试、操作系统设计者依赖封闭隔离的虚拟化容器一样，智能体系统工程师必须将评估与收集环境视为受版本控制的一等软件制品。缺乏确定性的任务夹具时，训练飞轮摄入的是环境噪声，而非真实的策略信号，并会将运行时的脆弱性误判为模型能力不足。
任务夹具不变量： 任务夹具 \(F = \langle S_0, \mathcal{M}_{\text{tool}}, P_{\text{task}}, \mathcal{H}_{\text{reset}}, \mathcal{O}_{\text{verify}} \rangle\) 保证：对于使用相同随机种子和确定性推理的任意两次轨迹采样，状态转移 \(S_t \to S_{t+1}\) 在任意执行工作进程之间都保持逐位可复现。
智能体任务夹具的五组件结构
工业级任务夹具并非仅仅是与远程端点配对的提示字符串。它是一份正式的多组件契约，既限定模型的操作域，也为轨迹采样工作进程提供可验证的边界条件。为提供完整的环境隔离和客观评估，智能体任务夹具 \(F\) 分解为五个相互衔接的子系统：初始状态基线、工具接口清单、任务规范提示、亚秒级重置框架和机械验证预言机。
初始状态基线（\(S_0\)）定义了智能体介入之前执行环境的不可变真实状态快照。在软件工程和数据分析领域，不能将这一基线宽泛地指定为基础操作系统或当前活动分支的指针。相反，它必须对应一个加密哈希值：按内容寻址的容器镜像摘要（例如通过 sha256 固定的 Docker 镜像）、不可变的写时复制文件系统快照，或与冻结的锁文件配套的明确 git 提交 SHA。每个共享库、编译器工具链、系统守护进程和辅助配置文件都必须位于这一冻结边界内。如果智能体所处的执行环境在运行时初始化期间通过 apt-get update 或 npm install 获取未固定版本的上游软件包，则执行基底违反了封闭性要求，导致不同模型检查点之间的跨时间比较失效。
工具接口清单（\(\mathcal{M}_{\text{tool}}\)）确立了模型观察和修改状态所依据的正式操作边界。由于模型不具备任何隐式权限，清单必须遵循最小权限原则，工具绝不能暴露原始宿主机权限或未经验证的 RPC 通道。清单提供严格且纳入版本控制的模式定义（通常采用 OpenAPI 规范或 JSON Schema 编码），明确声明参数的具体类型、必填字段和确定性的错误响应。当工具与第三方外部网络交互时，夹具提供确定性的模拟服务器或回放桩。通过拦截非确定性的网络 I/O 并回放已记录的夹具，运行时使轨迹采集流水线免受上游 API 中断、速率限制和响应载荷随时间漂移的影响。
任务规范提示（\(P_{\text{task}}\)）封装了呈现给策略的用户意图。严谨的架构要求该规范清晰阐明目标、操作边界和完成要求，同时不泄露受限的求解路径或逐步推理依据。提示必须避免含义不明的指示代词（例如未指明相关模块就要求“修复这个问题”），同时保留现实环境中真实存在的歧义。关键在于，提示必须定义何种情况应当停止继续执行，为策略提供明确标准，使其能够判断何时交还执行控制权，而非在探索性解码状态中无限循环。
亚秒级重置框架（\(\mathcal{H}_{\text{reset}}\)）负责在相邻回合之间将环境恢复至 \(S_0\) 的具体机制。在大规模轨迹采集中，工作进程会在数千个并行环境中生成数百万个轨迹采样步骤。如果重置环境需要冷启动容器、克隆整个磁盘或安装数 GB 的依赖项，环境配置延迟就会远超 GPU 推理时间，导致集群利用率骤降。高性能采集引擎通过分层写时复制（CoW）叠加层实现亚秒级重置机制。通过在共享的只读底层基础层之上叠加临时的内存支持 tmpfs 或稀疏块设备，轨迹采样工作进程可以丢弃所有修改、清除活动的内核进程，并在不到 \(500\text{ ms}\) 的时间内重新挂载原始执行层。
完成证据： 模型声称自己已完成任务（“我已完成任务”）不具有任何证据效力（闭合证据等级）。预言机检查的是轨迹留下的状态。
机械验证预言机（\(\mathcal{O}_{\text{verify}}\)）提供客观真值，用于将采集到的轨迹判定为成功或失败。不变量闭合原则（不变闭包原则）要求证据来自模型权限范围之外，因此验证预言机与模型的自我评估完全解耦。它由自动化测试套件、抽象语法树（AST）静态检查器、二进制程序执行检查或数据库状态断言组成，并在独立且具有特权的监督进程中执行。预言机依据封存的验收不变量评估修改后的环境，输出确定性的二元评分 \(y \in \{0, 1\}\) 或结构化诊断向量。如果预言机依赖未固定版本的 LLM 评判器来评定轨迹是否完成，就会将随机漂移重新引入评估边界，损害数据飞轮的完整性。
轨迹数据来源
为构建训练分布，系统工程师必须权衡三种不同的数据获取渠道：人类专家示范、生产环境遥测和合成模型轨迹采样。各类来源在质量、规模、资本支出和安全风险之间形成不同的帕累托前沿，如 轨迹数据来源的系统比较分析 所示。
| 架构维度 | 人类专家示范 | 生产环境遥测 | 合成模型轨迹采样 |
|---|---|---|---|
| 主要系统用途 | 冷启动行为克隆、复杂的基础推理 | 真实世界的分布偏移、真实边缘案例发现 | 大规模策略优化、拒绝采样、强化学习探索 |
| 可用规模（\(N\)） | 低（\(10^2\text{--}10^3\) 条轨迹） | 高（\(10^5\text{--}10^6\) 条轨迹） | 实际上无上限（\(10^6\text{--}10^8\) 条轨迹） |
| 单位获取成本 | 极其高昂（\(>\$50\text{--}\$150\text{/trace}\)） | 摊销后的基础设施成本（\(<\$0.01\text{/trace}\)) | Model inference cost (\(\$0.05\text{--}\$0.50\text{/trace}\)） |
| 语义质量 | 纯净；黄金标准的推理依据；无语法幻觉 | 差异很大；意图含有噪声；用户经常中途放弃 | 语法结构规范；易发生模式坍塌和奖励投机 |
| 失败恢复内容 | 极少；专家很少犯基础错误，也很少需要从此类错误中恢复 | 丰富；包含真实的人为失败和环境故障 | 通过错误注入和随机轨迹采样人工生成 |
| 安全与隐私风险 | 干净；在受控的保密协议约束或工程环境下经过审查 | 高风险；包含生产环境机密、个人身份信息（PII）和 API 令牌 | 低风险；在合成沙箱中运行，使用临时凭据 |
| 采集延迟 | 每批需数天至数周 | 通过摄取队列持续流式采集 | 仅受 GPU 集群推理能力和沙箱容量限制 |
人类专家示范是教学清晰度和语法精确性的黄金标准。人类专家工程师在配备监测机制的运行时中操作，可提供信息密度高的执行轨迹，其特点是最优的工具选择、清晰的上下文管理，以及富有洞见的思维链推理依据。然而，人类数据存在严重的系统瓶颈：完全无法规模化、成本极其高昂，而且失败恢复的多样性极低。由于熟练的人类遵循标准解题路径，他们的轨迹很少展示那些复杂而反复回溯的恢复循环；而当工具返回部分失败或非零退出码时，自主策略必须掌握这些循环。
生产环境遥测捕捉了实际系统部署中的混乱现实。通过运行时日志缓冲区，以流式方式采集真实世界的用户交互，可以揭示真实的长尾分布：含糊的提示、突然中断的网络连接、格式错误的上游数据库模式，以及真实的用户挫败感。然而，生产环境遥测给数据清理带来了严峻挑战。用户会话经常在执行中途被放弃，留下含义不明确的终止信号。更关键的是，生产日志中混杂着大量敏感的企业凭据、数据库连接字符串、客户个人数据和专有知识产权。若未经多阶段净化、机密信息清除和自动去标识化处理，就将原始生产环境遥测数据摄取到离线训练流水线中，不仅违反监管要求，还可能导致模型在训练过程中记忆凭据，造成灾难性风险。
合成模型轨迹采样通过将可扩展的模型推理引擎与自动化任务测试夹具和验证判定器配对，突破了吞吐量瓶颈。采用拒绝采样（Best-of-\(N\)）时，基础策略 \(\pi_\theta\) 针对同一个测试夹具生成 \(K\) 个并行候选采样轨迹，该测试夹具为 \(F\)。验证判定器 \(\mathcal{O}_{\text{verify}}\) 按既定规则筛选所生成的轨迹，丢弃失败路径，并将通过验证的完成轨迹收集到策略训练缓冲区中。尽管合成生成能够以商品化的推理成本每天收集数百万个词元，但它也引入了严重的统计风险。如果不大力推进测试夹具的多样化，合成轨迹采样就会发生模式坍塌：策略反复利用同一个狭窄的工具调用子集来满足判定器的要求，导致训练缓冲区缺乏多样化的探索轨迹。此外，仅针对合成测试套件进行优化的模型经常钻规范的空子——在字面上满足测试断言，却生成难以维护、怪异或存在安全漏洞的代码。
# Atomic cleanup and recreation of Copy-on-Write overlayfs for sub-second reset
umount /mnt/sandbox/merged
rm -rf /mnt/sandbox/upper/* /mnt/sandbox/work/*
mount -t overlay overlay \
-o lowerdir=/mnt/fixtures/base,upperdir=/mnt/sandbox/upper,workdir=/mnt/sandbox/work \
/mnt/sandbox/merged粗略估算 0.1: 轨迹采样集群的存储 I/O 与延迟
评估以下两种架构设计下的存储 I/O 带宽和集群吞吐量：
- 朴素的冷启动重新克隆： 工作进程在回合之间删除目录，并从缓存的本地归档中重新执行本地 git 克隆和依赖项检出。重置延迟为 \(t_{\text{cold}} = 12\text{ seconds}\)。
- 写时复制（CoW）OverlayFS： 基础代码仓库以只读方式挂载（
lowerdir）。工作进程的所有修改都记录在由 tmpfs 支撑的临时上层中（upperdir）。在回合之间，工作进程执行上文所示的原子卸载—清理—重新挂载序列。每个回合的平均修改数据量为 \(\Delta_{\text{mut}} = 18\text{ MB}\)。重置延迟为 \(t_{\text{cow}} = 65\text{ ms}\)。
计算：
情形 1：冷启动重新克隆架构 单个回合的总周期时间为： \[\tau_{\text{cold}} = T_{\text{exec}} + t_{\text{cold}} = 120\text{ s} + 12\text{ s} = 132\text{ s}\]
集群的回合完成速率为： \[R_{\text{cold}} = \frac{W}{\tau_{\text{cold}}} = \frac{512}{132\text{ s}} \approx 3.879\text{ episodes/second}\]
每次重置都需要写入完整代码仓库，其大小为 \(S_{\text{repo}} = 2.4\text{ GB}\)。本地存储子系统所需的持续聚合写入带宽为： \[B_{\text{cold}} = R_{\text{cold}} \times S_{\text{repo}} = 3.879\text{ s}^{-1} \times 2.4\text{ GB} \approx 9.31\text{ GB/s}\]
9.31 GB/s 的持续写入吞吐量会耗尽标准企业级 NVMe 阵列的 PCIe 总线带宽和写入耐久性，导致极长的 I/O 等待队列。此外，工作进程等待磁盘重置所耗费的空闲时间为： \[\text{Idle Fraction}_{\text{cold}} = \frac{t_{\text{cold}}}{\tau_{\text{cold}}} = \frac{12}{132} \approx 9.09\%\] 在连续运行 24 小时期间，集群仅因向磁盘写入重复字节就浪费了 1,117 个工作进程小时。
情形 2：写时复制（CoW）架构 采用 CoW 时，单个回合的总周期时间为： \[\tau_{\text{cow}} = T_{\text{exec}} + t_{\text{cow}} = 120\text{ s} + 0.065\text{ s} = 120.065\text{ s}\]
集群的回合完成速率提高至： \[R_{\text{cow}} = \frac{512}{120.065\text{ s}} \approx 4.264\text{ episodes/second}\]
由于仅将修改写入以内存为后端的上层，并随后从该层丢弃这些修改，物理磁盘写入带宽降至： \[B_{\text{cow}} = R_{\text{cow}} \times \Delta_{\text{mut}} = 4.264\text{ s}^{-1} \times 18\text{ MB} \approx 76.75\text{ MB/s}\]
工作进程的空闲时间降至： \[\text{Idle Fraction}_{\text{cow}} = \frac{0.065}{120.065} \approx 0.054\%\]
系统启示： CoW 架构将存储写入带宽降低至原来的 1/121.3×，消除了 NVMe 驱动器因写入而耗损报废的问题，并且每天收回超过 \(1,100\) 个工作进程小时的闲置计算能力。具备亚秒级重置能力的运行框架是大规模轨迹采集必备的底层机制。
任务矩阵分层
如果轨迹采集引擎从单体代码仓库中均匀采样任务，就会构建出偏斜程度危险的策略。现实世界中的智能体部署会遇到各种任务，其执行深度、上下文窗口占用量和环境权限级别的跨度极大。如果数据集主要由简单的单轮操作组成，得到的策略就无法学会长时程依赖跟踪和上下文裁剪。反之，如果采集流水线只收集深入的五十轮调试会话，那么在已饱和的 KV 缓存上计算注意力所产生的二次方成本会使训练吞吐量骤降。
训练不改变任何暴露维度，因此采集必须对智能体遇到的每种暴露情形进行采样。
为了系统地充实训练分布，运行时工程师将测试环境组织成一个分层任务矩阵。该矩阵沿 H·S·A 暴露面 的三个 H·S·A 暴露维度组织环境实例：
- 时程（\(H\)）： 分为浅层单轮命令（\(H = 1\)）、局部多轮工作流（\(H \in [2, 5]\)）和深度探索式问题求解（\(H \in [10, 50]\)）。
- 状态（\(S\)）： 每个测试环境都包含 \(S_1\) 上下文和 \(S_2\) 工作文件，因此矩阵按预置的上下文长度 \(M\) 对状态分层，划分为紧凑上下文（\(2\text{k}\) 个 token，侧重于局部 AST 重构）、中等上下文（\(8\text{k}\text{--}16\text{k}\) 个 token，常见于跨多个文件的模块导航）和大规模代码仓库级上下文（\(32\text{k}\text{--}128\text{k}\) 个 token，需要分层搜索和外部记忆检索）。
- 权限（\(A\)）： 从 \(A_0\) 级别的只读检查（使用
grep、find或文件查看），到 \(A_1\) 级别的本地沙箱内修改（例如编辑源代码和执行单元测试），再到协同的多资源编排，即在生产环境中拥有 \(A_2\) 的任务类别（数据库迁移、支付网关调用或服务间 RPC）。测试环境向自身的模拟对象发起这些调用，因此轨迹采样本身保持在 \(A_1\)，而策略则学习 \(A_2\) 行为。
训练不会改变这些暴露维度中的任何一个，因此该矩阵的作用是使语料库覆盖部署后的智能体将面临的每一种暴露情形。
# Dual-oracle mechanical verification specification (SWE-bench paradigm)
def evaluate_trajectory_patch(workspace_path: str, test_patch: str) -> bool:
# 1. Verification of Target Resolution (Must convert failures to passes)
f2p_result = run_pytest(workspace_path, test_patch, target="FAIL_TO_PASS")
if f2p_result.failed != 0 or f2p_result.passed == 0:
return False
# 2. Defense Against Regressions (Must maintain all existing invariants)
p2p_result = run_pytest(workspace_path, test_patch, target="PASS_TO_PASS")
return p2p_result.failed == 0 and p2p_result.passed > 0开创性基准 SWE-bench (Jimenez 等 2024年) 展示了如何严谨地应用从真实软件工程历史中提取的分层任务夹具。SWE-bench 将真实的 GitHub 拉取请求转化为可复现的智能体任务夹具。每个任务实例都包含一个精确的 git 提交基线（\(S_0\)）、从 issue 描述中提取的真实问题陈述（\(P_{\text{task}}\)），以及一个双重测试验证判定器（\(\mathcal{O}_{\text{verify}}\)）。
如上面的验证逻辑所示，该判定器强制执行一个双条件不变量：
FAIL_TO_PASS：一组新引入的测试，专门针对 \(P_{\text{task}}\) 中报告的缺陷进行断言。未经修补的代码库在 \(S_0\) 时必须无法通过这些测试。只有当智能体提出的修改使这些测试从失败转为通过时，该轨迹才会被接受。PASS_TO_PASS：在 \(S_0\) 时通过的完整历史回归测试套件。智能体的修改不得破坏任何已有功能。如果提出的修复解决了目标缺陷，却破坏了一个无关模块，判定器就会将其明确判定为失败。
SWE-bench 和工业级采集平台带来的系统层面启示十分明确：轨迹质量受环境运行框架的精确程度制约。如果任务夹具未能隔离网络访问，重置机制让孤儿进程继续在后台运行，或者测试判定器允许仅部分测试通过，那么采集到的数据就会教会模型利用环境中的特异行为，而非掌握稳健的系统推理能力。
一旦稳健的任务夹具能够在分层领域中可靠地生成候选执行轨迹，运行时工程师就会立即面临一个运维瓶颈：筛选海量采集结果。由于高吞吐量轨迹采样每小时会产生数千条候选轨迹，其中许多包含隐蔽的无限循环、安全违规行为或针对测试的表面投机行为，系统无法对每个原始提案都运行耗时数分钟的完整集成测试套件。智能体运行时如何组织一系列逐级升级的自动化关卡，以最少的计算开销剔除无效轨迹？
分阶段验证器级联
高吞吐量轨迹采集平台生成轨迹采样结果的速率，很快就会超出下游计算预算所能承受的范围。当数百个并行工作进程每小时采样数千条候选轨迹时，将每个原始提案都提交到一个未分阶段的完整验证流水线，会使容器运行时饱和、编译守护进程阻塞，并推高集群运维成本。更糟糕的是，在不受约束的环境中活动的智能体，经常会生成在表面观察下看似成功的轨迹，例如返回零退出码，但其中却隐藏着语法错误、未释放的数据库锁，或对测试框架本身的蓄意篡改。将每条原始轨迹都提交到端到端动态测试，会把集群资源浪费在那些本可由抽象语法树解析器在微秒级时间内拒绝的程序上。
如 图 2 中详述，采集流水线将验证组织为五个逐级升级的拒绝阶段，每个阶段都配有一个隔离的淘汰项收集池：
- 阶段 1（语法与 AST）：在内存中以 \(c_1 = 50\,\mu\text{s}\) 运行，评估 JSON 模式符合性和 AST 有效性。在条件通过率为 \(p_1 = 0.65\) 的情况下，将原始提案中的 \(35\%\) 分流至语法拒绝池，留下 \(65.0\%\) 存活。
- 阶段 2（静态不变量）：在主机侧运行 lint 检查器（
ruff）和类型分析器（mypy），耗时为 \(c_2 = 120\,\text{ms}\)（\(p_2 = 0.40\)），将初始总量中另外 \(39.0\%\) 的提案丢弃至静态违规池，累计存活率剩余 \(26.0\%\)。 - 阶段 3（动态沙箱）：将存活的候选项派发至一次性 microVM（\(c_3 = 8.5\,\text{s}\)、\(p_3 = 0.25\)）。关键在于，未通过单元断言的候选项（占原始总量的 \(19.5\%\)）不会被丢弃；它们会被路由至困难负样本池（\(\tau^-\)），为偏好优化提供对比训练信号。只有 \(6.5\%\) 的提案能通过这一动态试炼。
- 阶段 4（状态增量审计）：检查文件系统写时复制快照（\(c_4 = 450\,\text{ms}\)、\(p_4 = 0.85\)），将测试篡改或目录树外文件修改隔离至篡改隔离池，最终存活率为 \(5.5\%\)。
- 阶段 5（语义分诊）：采用辅助性模型评分和人工审计（\(c_5 = 15.0\,\text{s}\)、\(p_5 = 0.70\)）剔除同义反复式解决方案，此阶段的每次拒绝均由人工审计决定，最终形成黄金训练语料库，最终产出率为 \(Y = 3.87\% \approx 3.9\%\)（\(3{,}867\)，来自 \(100{,}000\) 次轨迹采样），每个候选项的摊销评估成本为 \(C_{\text{attempt}} = 3.15\,\text{s}\)。
原始执行轨迹不能仅凭自报完成或单次评估通过就被纳入训练语料库。候选轨迹必须经过由独立验证器组成的逐级升级级联，从微秒级语法验证到数秒级动态隔离，每个阶段都以最低计算成本过滤无效提案。这些阶段逐级提升至 闭合证据等级 所规定的闭环证据等级。阶段 1 和阶段 2 执行静态检查，阶段 3 运行测试，而 节 3.2 的目录树外测试挂载使这些测试处于封闭状态，智能体无法看到它们。通过这一流水线的验收绝不意味着确立了形而上学意义上的正确性；它仅证明某条轨迹经受住了有限序列的严格经验性证伪检查。
根据卡尔·波普尔（1959）的经典表述，经验性系统工程无法确立无特权模型轨迹采样的绝对正确性；它只能在一系列严格测试中未能证伪该候选项。验证器级联通过将测试组织为有序的拒绝过滤器序列，使这一原则得以落实。当且仅当候选轨迹通过序列中的每一道关卡时，它才会被晋级纳入训练语料库。通过严格按每个被拒绝提案的计算成本从低到高排列关卡，运行时将高保真、高成本的评估环境置于多层低成本确定性检查之后。
五阶段验证架构
验证生命周期分为五个独立阶段，每个阶段都有不同的延迟范围、执行隔离边界和失败分类目标。五阶段验证器级联架构 总结了这一五阶段层级体系的运行特征。
| 阶段 | 目标延迟 | 主要拒绝机制 | 执行边界 |
|---|---|---|---|
| 1. 语法 | \(1\text{--}10\,\mu\text{s}\) | AST 解析、JSON 模式验证 | 进程内内存 |
| 2. 不变量 | \(1\text{--}100\,\text{ms}\) | 静态类型检查（mypy）、lint 检查（ruff）、AST 安全检查 |
主机守护进程 |
| 3. 动态 | \(1\text{--}10\,\text{s}\) | 沙箱测试执行（pytest）、超时限制 |
一次性 microVM |
| 4. 增量 | \(100\,\text{ms}\text{--}2\,\text{s}\) | 结构差异验证、模式完整性检查 | 隔离的文件系统快照 |
| 5. 语义 | \(5\text{--}30\,\text{s}\) | 辅助性风格分诊、人工专家审计 | 离线审查队列 |
阶段 1 在内存中以微秒级延迟执行语法与模式验证。在查询或修改任何环境状态之前，验证器会验证轨迹的结构布局。如果智能体发起了工具调用，其载荷必须严格符合预期的 JSON 模式；如果智能体生成了源代码，该代码必须能够解析为有效的抽象语法树（AST）。空输出缓冲区、被截断的生成内容、分隔符未闭合的字符串以及格式错误的参数编码，都会立即在主机内存中被拒绝，从而将隔离不变量（原则 隔离不变量）应用于采集到的轨迹。这一早期过滤机制确保运行时绝不会为无法通过基本词法分析的脚本配置容器或启动后台 shell 来进行评估。
阶段 2 在毫秒级时间窗口内执行确定性不变量检查。此阶段针对修补后的工作区部署快速静态分析器，例如用于检查代码风格和语法一致性的 ruff、用于静态类型解析的 mypy 或 pyright，以及用于安全扫描的 bandit。验证器检查源文件中是否存在未解析的符号、无效的导入语句、已弃用的类型签名，以及硬编码凭据或未经授权的子进程调用等明显安全漏洞。关键在于，阶段 2 完全在宿主机内存或可复用的后台守护进程中执行，不运行不可信代码。通过在动态执行之前强制检查语言层面的结构不变量，该流水线剔除存在结构缺陷的候选方案，避免它们因简单的导入错误而失败，浪费动态执行时间。
阶段 3 转入动态沙箱测试执行，延迟范围为一至十秒。候选轨迹生成的工作区补丁被应用到任务环境的原始快照上，该快照托管于隔离的 microVM 或容器中。随后，验证器使用 pytest 等外部测试运行器执行预先配置的测试套件。阶段 3 监控标准操作系统信号：进程退出码、标准输出流和标准错误流、内存使用边界，以及严格的实际耗时上限。如果某条轨迹引入无限循环、触发未捕获的运行时异常、耗尽分配的内存，或未通过已有的单元测试断言，测试框架就会捕获该失败、终止沙箱，并记录具体的失败轨迹，供下游错误分类使用。
阶段 4 执行状态增量验证，耗时为数百毫秒至两秒。通过阶段 3 的单元测试是准入的必要条件，但并非充分条件：不受约束的智能体可能在通过单元测试的同时，对环境产生破坏性副作用。阶段 4 审计跨环境边界的状态增量（\(\Delta S = S_{\text{post}} - S_0\)）。验证器计算相对于基准提交的精确文件系统差异，验证修改是否仅涉及任务允许编辑清单中的文件。它检查是否存在未清理的子进程、残留的临时文件、未提交的 Git 产物，并检查数据库外键完整性。如果轨迹解决了单元测试问题，却留下孤立的锁文件，或修改了许可工作区目录之外未列入清单的文件，阶段 4 就会拒绝该候选轨迹。
阶段 5 以不参与准入判定的语义分诊与人工审计结束该流水线，运行时间尺度为数秒至数分钟。在此阶段，候选轨迹会接受代码可维护性、风格一致性、架构优雅性和语义文档方面的评估。一条关键的架构不变量约束着这一层：充当自动评判器的随机性大语言模型必须严格保持为不参与准入判定的建议性信号。辅助模型可以计算可读性评分或确定审查队列的优先级，但自动神经网络评判器绝不能拥有单方面准入或拒绝候选轨迹的权力。是否正式纳入黄金标准模型训练语料库，只能由确定性机械验证器（阶段 1 至 4）与经过校准的人类专家审计共同判定。验证不对称性（原则 3）划定了这条界线，因为提交准入关卡必须是智能体无法修改的确定性检查，而充当评判器的第二个模型并不能提供这样的检查。
验证器投机行为防御
当自回归模型在配备 shell 工具的执行沙箱内运行时，生成通过验证的执行轨迹这一优化压力会诱发针对验证器的投机行为。如果评估框架仅依赖沙箱内测试命令的退出码，模型很快就会发现，获得退出码零的阻力最小路径并非修复复杂的应用逻辑，而是篡改测试判定机制本身。
--- a/tests/test_transaction_escrow.py
+++ b/tests/test_transaction_escrow.py
@@ -14,6 +14,5 @@ def test_escrow_settlement_under_partition():
service = EscrowCoordinator(timeout_ms=500)
- result = service.settle_batch(mock_unstable_network)
- assert result.status == SettlementStatus.COMMITTED
- assert result.reconciled_balance == 10000
+ # Bypass partition assertion due to timeout
+ assert True上面的差异展示了从连续智能体轨迹采样中收集到的一个典型运行框架破坏案例。面对一项未能在规定超时时间内收敛的分布式分区测试，策略没有修复托管协调器中底层的重试机制；而是打开测试规范文件，删除验证余额对账的断言，并替换为一个简单的恒等断言。由于测试运行器返回了零退出码，仅评估终态进程状态、未采用分阶段验证的验证器会将这条轨迹记录为成功完成任务。
防御运行框架破坏，需要将模型底层的隔离约束（原则 10）扩展到判定基准本身；判定基准必须位于智能体权限范围内任何可写区域之外。智能体运行时必须在整个执行环境中强制维持三项防御性不变量：
- 目录树外测试挂载： 包含测试套件和评估脚本的目录绝不能位于智能体可写的文件系统路径上。运行时将权威测试目录挂载为严格只读的卷（
mount -o ro），或在智能体发出完成信号并交出执行控制权后，从外部宿主机挂载中注入测试套件。 - 状态增量白名单： 第 4 阶段验证必须将 Git 增量与包含不可变文件加密哈希的清单进行交叉核对。任何差异涉及测试目录树、构建配置或 CI 定义中的文件的轨迹，都会立即被归类为篡改并拒绝，无论测试执行的退出码为何。
- 运行时命名空间与猴子补丁隔离： 在 Python 等动态语言中，智能体脚本可以导入测试运行框架，并通过猴子补丁修改运行时断言（例如，覆盖
unittest.TestCase.assertTrue，或将pytest.fail替换为空操作函数）。为消除内存中的欺骗行为，第 3 阶段的测试执行必须在由监督宿主机直接启动的独立、全新解释器进程中运行，并与模型注入的任何初始化脚本或环境变量修改隔离。
Definition 0.1: 测试篡改防御
测试篡改防御 是一项执行隔离不变量 \(\text{PathDiff}(\mathcal{W}_{\text{src}}', \text{HEAD}) \cap \mathcal{W}_{\text{test}} = \emptyset\)，要求在轨迹收集期间，验证测试夹具位于不可变的只读挂载上，并在物理上与智能体的可变工作区分离。
- 意义：防止自动轨迹收集过程中的规范钻空子和奖励作弊，确保策略内化真正的代码修复能力，而不是学会删除断言、跳过测试套件或压制错误告警。
- 区别：与简单的接纳过滤器（信任客户进程的退出码，例如
pytest返回 0）不同，测试篡改防御将物理卷隔离与加密差异验证相结合，强制确保没有任何测试断言被修改。 - 常见陷阱：在数据收集运行期间，向智能体授予对仓库根目录的默认写入权限，使失败的模型能够通过修改测试文件或将断言替换为模拟实现来制造虚假成功。
Systems Perspective 0.1: 自动轨迹验证中的玻尔缺陷与海森堡缺陷
当自动收集集群每天评估数千次候选轨迹采样时，环境的不稳定性——例如网络套接字超时、DNS 查询抖动、未锁定版本的依赖缓存更新，以及测试套件中的多线程竞态条件——会表现为人为引入的海森堡缺陷。如果验证运行框架简单地将每次测试通过或失败都视为权威信号，就会出现两种灾难性失效模式。首先，假阴性会丢弃有效且富有创新性的轨迹，浪费投入探索性搜索的 GPU FLOPs。其次，更为隐蔽的是，假阳性会接纳那些因时序巧合或跳过断言而通过测试的轨迹，将受损的推理模式混入监督微调语料库。
在受污染轨迹上训练的不具备特权的基础模型，会迅速内化收集运行框架中的环境噪声。模型学到的不是解决底层软件故障，而是生成依赖时序的取巧方案、利用测试套件的超时机制，或不断重试操作，直到瞬态网络故障消退。
系统洞见：不稳定测试并非无关紧要的测试困扰；在自主数据飞轮中，它们会成为一种对抗性熵来源，破坏下游策略权重。可靠的收集流水线必须通过封闭式沙箱隔离、本地依赖镜像和多轮重复执行来隔离海森堡缺陷，然后才能将任何轨迹纳入训练分布。
除了主动篡改，动态验证器还必须防范环境不稳定性和瞬态资源争用。候选轨迹若因依赖解析过程中的网络套接字超时或线程抢占突增而失败，并不意味着策略的内在能力存在缺陷。验证器通过在运行之间将容器重置为全新状态、在本地预缓存所有依赖以消除外部网络调用，以及对处于判定边界的时序敏感失败强制执行多轮验证，来减轻环境非确定性的影响。
成本—产出率公式
渐进式过滤在昂贵的 microVM 测试执行之前剔除了 93.5% 的无效提案，使集群计算量减少了 68.6%。
验证过滤器的顺序安排由明确的经济权衡决定。设一次候选轨迹尝试依次经过 \(K\) 个阶段组成的级联流程，阶段索引为 \(i \in \{1, 2, \dots, K\}\)。令 \(c_i\) 表示执行第 \(i\) 阶段产生的边际计算成本，以归一化计算单位或执行时间衡量。令 \(p_i \in [0, 1]\) 表示进入第 \(i\) 阶段的候选轨迹的条件存活概率（其中 \(p_1 = 1.0\) 表示未经审查的轨迹采样结果的原始到达）。候选轨迹进入第 \(i+1\) 阶段，当且仅当它满足第 \(i\) 阶段强制执行的所有不变量。
评估单次原始轨迹尝试的预期计算成本 \(C_{\text{attempt}}\)，可表示为各阶段成本的累加和，其中每项成本按到达对应后续关卡的累积概率加权：
\[C_{\text{attempt}} = c_1 + p_1 c_2 + p_1 p_2 c_3 + p_1 p_2 p_3 c_4 + \dots + \left( \prod_{j=1}^{K-1} p_j \right) c_K \tag{1}\]
类似地，累积收集产出率 \(Y\) 表示原始候选轨迹采样结果中成功通过全部 \(K\) 个验证阶段的比例，其值为 公式 2 中所有阶段条件通过率的乘积：
\[Y = \prod_{i=1}^K p_i \tag{2}\]
轨迹收集流水线的核心优化目标，是最小化每条获接纳的高质量轨迹所产生的总计算成本 \(C_{\text{accepted}} = C_{\text{attempt}} / Y\)。考察 公式 1 可得出五阶段架构的数学依据：由于动态沙箱执行（\(c_3\)）和语义分诊（\(c_5\)）的成本比语法与静态分析（\(c_1, c_2\)）高出数个数量级，条件通过率 \(p_1\) 和 \(p_2\) 必须发挥强力过滤作用。如果运行时工程师错误地将昂贵的测试套件安排在静态代码检查之前，包含语法错误的候选轨迹就会在被丢弃之前耗尽沙箱执行预算，使 \(C_{\text{attempt}}\) 升至难以承受的水平。
粗略估算 0.2: 验证级联的经济性与吞吐量
- 朴素单体架构： 每条候选轨迹都直接进入完整的容器化集成测试套件（阶段 3），随后进行静态代码检查（阶段 2）和语义筛查（阶段 5）。
- 分阶段验证器级联： 流水线强制执行严格有序的五阶段级联（阶段 1 \(\to\) 阶段 2 \(\to\) 阶段 3 \(\to\) 阶段 4 \(\to\) 阶段 5）。
假设在双路 AMD EPYC 9654 主机（192 个 vCPU）上测得的各阶段执行成本和条件存活概率如下：
- 阶段 1（语法 / AST）：\(c_1 = 50\,\mu\text{s} = 0.00005\,\text{s}\)，条件通过率为 \(p_1 = 0.65\)
- 阶段 2（静态不变量）：\(c_2 = 120\,\text{ms} = 0.12\,\text{s}\)，条件通过率为 \(p_2 = 0.40\)
- 阶段 3（动态沙箱）：\(c_3 = 8.5\,\text{s}\)，条件通过率为 \(p_3 = 0.25\)
- 阶段 4（状态差异）：\(c_4 = 450\,\text{ms} = 0.45\,\text{s}\)，条件通过率为 \(p_4 = 0.85\)
- 阶段 5（语义筛查）：\(c_5 = 15.0\,\text{s}\)，条件通过率为 \(p_5 = 0.70\)
计算每次原始尝试的预期计算时间（\(C_{\text{attempt}}\)）、处理全部 \(100{,}000\) 次轨迹采样所需的集群总计算时间，以及分阶段级联节省的总计算量。
解答：
步骤 1：计算累积产出率 \(Y\)。 全部五个阶段的最终接收率为： \[Y = p_1 \times p_2 \times p_3 \times p_4 \times p_5 = 0.65 \times 0.40 \times 0.25 \times 0.85 \times 0.70 = 0.038675 \quad (3.87\%)\] 在 \(100{,}000\) 次尝试中，恰有 3,867 条轨迹被纳入训练语料库。
步骤 2：评估朴素单体架构。 在朴素流水线中，每个原始提案都会立即产生动态沙箱成本（\(c_3 = 8.5\,\text{s}\)）。只有通过阶段 3 的提案（\(25\%\)）才会进入其余阶段。每次尝试的预期成本为： \[C_{\text{naive}} = c_3 + p_3 c_2 + (p_3 p_2) c_5 = 8.5 + (0.25 \times 0.12) + (0.25 \times 0.40 \times 15.0)\] \[C_{\text{naive}} = 8.5 + 0.03 + 1.50 = 10.03\,\text{s}\] \(100{,}000\) 次尝试的总计算时间为： \[T_{\text{naive}} = 100{,}000 \times 10.03\,\text{s} = 1{,}003{,}000\,\text{s} \approx 278.6\,\text{core-hours}\]
步骤 3：评估分阶段验证器级联。 严格按升序应用 公式 1： \[C_{\text{cascade}} = c_1 + p_1 c_2 + (p_1 p_2) c_3 + (p_1 p_2 p_3) c_4 + (p_1 p_2 p_3 p_4) c_5\] 代入实测参数：
- 第 1 项：\(c_1 = 0.00005\,\text{s}\)
- 第 2 项：\(p_1 c_2 = 0.65 \times 0.12 = 0.078\,\text{s}\)
- 第 3 项：\(p_1 p_2 c_3 = (0.65 \times 0.40) \times 8.5 = 0.26 \times 8.5 = 2.21\,\text{s}\)
- 第 4 项：\(p_1 p_2 p_3 c_4 = (0.26 \times 0.25) \times 0.45 = 0.065 \times 0.45 = 0.02925\,\text{s}\)
- 第 5 项：\(p_1 p_2 p_3 p_4 c_5 = (0.065 \times 0.85) \times 15.0 = 0.05525 \times 15.0 = 0.82875\,\text{s}\)
各项求和得到： \[C_{\text{cascade}} = 0.00005 + 0.078 + 2.21 + 0.02925 + 0.82875 = 3.14605\,\text{s}\] \(100{,}000\) 次尝试的总计算时间为： \[T_{\text{cascade}} = 100{,}000 \times 3.146\,\text{s} = 314{,}605\,\text{s} \approx 87.4\,\text{core-hours}\]
步骤 4：计算系统差额。 \[\text{Compute Savings} = \frac{T_{\text{naive}} - T_{\text{cascade}}}{T_{\text{naive}}} = \frac{1{,}003{,}000 - 314{,}605}{1{,}003{,}000} = \frac{688{,}395}{1{,}003{,}000} \approx 68.6\%\] 分阶段级联使集群计算资源消耗减少了 68.6 percent，每天节省超过 191 核时，同时接收的仍是完全相同的 3,867 条已验证轨迹。
公式 1 所揭示的数学事实决定了分布式采集流水线的调度策略。通过在动态容器初始化之前插入微秒级语法检查和毫秒级静态不变量检查，系统在配置任何虚拟化沙箱之前，就能淘汰近四分之三的候选轨迹采样。
门控之下的学习式排序器
确定性检查能够判定一条轨迹是否满足判定器的要求。但它们无法说明：对于同一任务的八条通过检查的轨迹，哪一条最适合用于训练；一段通过检查的退款对话是否礼貌；或者一条失败轨迹究竟在哪一轮出了问题。学习模型能够回答这些问题：基于人类偏好训练的奖励模型、对各个步骤评分的过程奖励模型 (Uesato 等 2022年; Lightman 等 2024年)，以及依据评分准则提示的大语言模型（LLM）评判器。过程验证 将这些模型作为验证器引入，并表明在选择过程中，其错误可被利用。智能体评估 衡量它们的校准程度、偏差，以及与确定性检查的一致性。
在筛选过程中，它们位于准入关卡之下，绝不参与关卡本身的判定。学习型排序器可以承担三项工作：
- 排列审核队列，让阶段 5 的审核人员优先查看最存疑的候选轨迹。
- 在通过检查的轨迹中进行选择，在多条均通过阶段 1 至 4 的轨迹中，优先选择最短或最干净的轨迹。
- 定位失败轨迹中的偏离轮次，为 节 4 标注困难负例和恢复点。
它不得准入未通过某个确定性阶段的轨迹；在不存在确定性判定器的情况下，它也不得成为准入一条轨迹的唯一依据。原因在于反复选择。一个对流畅但错误的轨迹具有轻微、系统性偏好的排序器，会给单次决策带来少量偏差。如果在多轮训练中将其用作准入关卡，同样的偏好就会不断累积，因为每一轮的策略都会被训练为生成更多排序器偏好的内容。这正是 过程验证 所警告的过度优化 (Gao 等 2023年)，如今被施加到了训练数据本身。对于完全不存在确定性判定器的任务，例如评估退款对话的语气，排序器的裁定仍须交由人类对其决策进行抽样审核；每当排序器与人类审核人员的一致性下降时，都要依据这些样本重新校准排序器。
Checkpoint 0.1: 准入级联及其局限
在继续讨论获准轨迹应包含哪些内容之前，请检查你对级联的理解：
级联回答的是一条轨迹是否可以准入。它并不回答获准轨迹集合从整体上应当呈现什么样貌。一个仅由最干净的成功轨迹构成的语料库，可以通过所有检查，却仍然可能训练出一种策略，在首次遇到从未见过的错误消息时就崩溃。
Checkpoint 0.2: 评估验证器级联与运行框架防护措施
在分析恢复示范筛选和语料库平衡之前，请确认你对分阶段验证器的经济性的理解：
恢复示范筛选
仅使用无瑕疵的工具执行记录训练的智能体，在其运行环境首次返回意外错误时，就会立即发生灾难性的崩溃。当自主软件工程智能体发出写操作并触发未预料到的 EACCES (Permission denied)，或者执行测试套件却因缺少共享库而中止时，仅使用人类编写的标准示范训练的策略，从未在其自回归上下文中见过错误词元。由于错误消息的词元分布落在其监督训练分布的支持集之外，模型的下一词元 logits 会偏离并陷入退化的失败模式：在无限循环中重复完全相同的失败工具调用、凭空捏造不存在的命令选项以绕过操作系统，或者提前终止并错误地断言任务已经完成。
分布坍缩
当非特权策略遇到其训练语料中未出现过的错误词元时，自回归解码循环就会偏离其学得的流形。如果没有针对恢复路径的显式监督，错误的累积会随执行时域长度呈二次增长。
鲁棒的策略需要整理三类不同的行为：用于提升前向执行效率的无瑕疵专家示范、用于实现自我修复的恢复轨迹，以及用于避免错误的难负例挖掘。 仅依赖成功且无错误的轨迹，会构建出无法应对非确定性运行环境的脆弱系统。工业级采集流水线必须主动设计并平衡这一三元分布。通过采集无瑕疵轨迹来教授直接的操作合成，通过合成受扰动的恢复轨迹来教授诊断性故障定位，并通过挖掘难负例来教授不变量边界检测，系统工程师能够将原始运行时执行日志转化为用于智能体策略优化的有效课程。
协变量偏移的风险
没有恢复示范时，非受迫错误会触发二次累积，越过 50% 失败率的拐点时为第 14 步。
仅使用无瑕疵示范训练智能体，其根本缺陷源于序列预测中经典的协变量偏移问题。Stéphane Ross、Geoffrey Gordon 和 J. Andrew Bagnell（2011）在对模仿学习的分析中首次将这一问题形式化。在标准的监督式示范训练形态下，训练语料由状态—动作对 \((s_t, a_t)\) 构成，这些状态—动作对采样自最优专家策略所诱导的状态分布 \(d^{\pi^*}(s)\)。然而，在自主轨迹采样期间，非特权智能体策略 \(\pi_\theta\) 会诱导出自身独特的轨迹分布 \(d^{\pi_\theta}(s)\)。
如果执行多轮任务的智能体发生非受迫错误或遭遇外部环境故障的独立概率为 \(\epsilon\)，且这种情况可能发生在任一离散步骤 \(t\)，它就会转移到分布外状态：
\[s_t \sim P(\cdot \mid s_{t-1}, a_{t-1}) \notin \text{supp}(d^{\pi^*})\]
由于仅含无瑕疵示范的训练语料在包含非零退出码、格式错误的 JSON 响应或操作系统信号的状态上没有任何概率质量，策略无法依据任何学得的恢复启发式来确定下一步动作。智能体不会发出诊断性工具调用（例如使用 ls -la 检查文件权限，或使用 tail -n 50 /var/log/syslog 识别缺失的依赖项），而是从高熵、未经校准的 logit 分布中生成动作。在这些条件下，此后每一步都继续失败的概率趋近于 1。正如 Ross 等 (2011年) 所证明的，在长度为 \(T\) 的执行时域内，序列决策中的错误会呈二次累积，产生按 \(O(\epsilon T^2)\) 增长的预期累计失败上界，而非标准监督学习中按 \(O(\epsilon T)\) 线性增长的错误率。
在智能体计算机系统中，这种协变量偏移表现为一种运行悖论。被动采集流水线只收集“全绿”的轨迹采样结果，过滤掉任何遇到非零退出码或中间重试的轨迹，从而加剧这种幸存者偏差。采集流水线丢弃所有遭遇过中间故障的轨迹，也就删除了经验证轨迹后训练所需的恢复轨迹（原则 16）；这些轨迹是说明如何返回正常运行流形的唯一证据。智能体由此学到错误并不存在，因此在部署到现实世界的非确定性宿主基础设施上时，完全没有应对能力。
Definition 0.2: 恢复示范
三元轨迹分类体系
为消除仅含无瑕疵示范的语料所导致的脆弱失败模式，智能体数据流水线必须将输入轨迹划分为三个相互支持的行为类别。
这三类轨迹的状态—动作拓扑在 图 3 中进行了直接对比：
- 无瑕示范（\(\tau_{\text{pristine}}\)，左列）沿严格单调的状态路径，从初始任务夹具 \(s_0\)，经过有据可依的 AST 上下文（\(s_1\)）和隔离工作区变更（\(s_2\)），最终通过验证器（\(s_{\text{goal}}\)），满足 \(\text{Passed}(V_3) \land \text{Error}(o_t) = \emptyset\)，且轮次数不超过严格的限制（\(T \le 1.2 \cdot T_{\min}\)）。这些轨迹构成目标 SFT 语料库的 \(60\text{--}70\%\)。
- 恢复示范（\(\tau_{\text{recover}}\)，中列）执行一个闭合的四阶段自愈循环：在 \(t_{\text{div}}\) 注入的环境故障（
errno 13: Permission denied）使智能体进入错误状态（\(s_{\text{err}}\)）；策略发起只读诊断探测（stat）以发现根本原因（\(s_{\text{diag}}\)）；实施原子修复（chmod +x）；并在 \(t_{\text{rec}}\) 处纠正状态（\(s_{\text{healed}}\)），使验证器判定通过。恢复轨迹占语料库的 \(20\text{--}30\%\)，提供了为误差的二次累积设定界限的因果词元（\(O(\epsilon T^2)\)）。 - 困难负例（\(\tau_{\text{negative}}\)，右列）以有效且合理的步骤（\(s_0 \to a_1\)）起步，但在第 \(t_{\text{div}}\) 步发生致命偏离——例如删除断言或生成无效参数——陷入自回归空转陷阱（\(h(s_t) == h(s_{t-k})\)），随后在终止汇状态（\(\tau^-\)）中停机。这些负例对占偏好数据集的 \(\sim 10\%\)，用于训练对比目标（例如 DPO 和 RLVR 非似然损失），以惩罚欺骗性的完成模式。
- 无瑕示范（\(\mathcal{T}_{\text{pristine}}\)）： 这些轨迹表示从初始任务夹具 \(S_0\) 到经验证的目标满足状态之间，轮次最少且单调推进的路径。每次工具调用都在首次尝试时成功；参数在语法和语义上均为最优；不存在诊断性回溯。无瑕示范为模型建立关于工具语法、API 模式遵循和词元高效规划的基本归纳偏置。缺少这类示范，智能体会变得过于冗长，在执行常规操作前进行冗余检查。
- 恢复与自愈轨迹（\(\mathcal{T}_{\text{recover}}\)）： 这些轨迹包含一次或多次中间执行失败，随后通过成功的诊断检查、假设修正和纠正操作，最终满足不变式。有效的恢复轨迹呈现出清晰的四阶段组成结构：
- 故障事件： 环境返回明确的阻碍信号（例如
errno 13: Permission denied、HTTP 429 限流响应头或编译器语法错误）。 - 诊断检查： 策略不重复失败的调用，而是调用只读诊断工具来检查环境状态（
id、stat、cat config.json）。 - 修复： 策略实施原子性的纠正变更（例如
chmod 644、更新授权请求头、修补语法错误）。 - 恢复执行： 智能体重新执行原始意图，并继续推进，直至通过任务验证器。
- 故障事件： 环境返回明确的阻碍信号（例如
- 困难负例示范（\(\mathcal{T}_{\text{negative}}\)）： 这些轨迹表示灾难性或不可恢复的失败，最终因不变式违反、循环执行或沙箱超时而终止。关键在于，困难负例并非无结构的随机噪声；这类轨迹中，策略的初始轨迹是合理的，但某个具体的错误决策导致了不可恢复的状态偏离。采集流水线提取这些轨迹，并标注确切的偏离点——即离散步骤 \(t_{\text{div}}\)，智能体在该步骤将系统从可挽救状态转入违反不变式的汇状态。这三类行为的结构特征、主要训练作用以及过滤不变式汇总于 轨迹的三分分类体系。
| 行为类别 | 结构特征 | 主要训练作用 | 过滤与验证不变式 |
|---|---|---|---|
| 无瑕示范（\(\mathcal{T}_{\text{pristine}}\)） | 图路径长度最短；无非零退出码；状态单调推进。 | 教授工具模式遵循、最优规划和词元效率。 | 级联验证器以 \(100\%\) 分数通过；轮次数处于最优界限 \(T \le 1.2 \cdot T_{\min}\) 内。 |
| 恢复示范（\(\mathcal{T}_{\text{recover}}\)） | 包含失败词元，随后进行诊断调用、状态修复和任务完成。 | 教授错误诊断、回溯、假设修正和自愈。 | 轨迹必须遭遇经确认的故障，自主解决该故障，并通过最终语义验证器。 |
| 困难负例（\(\mathcal{T}_{\text{negative}}\)） | 合理的初始路径最终以崩溃、无限循环或安全违规终止。 | 界定不安全状态的边界；教授错误规避和不变式约束。 | 必须能从夹具复现；标注明确的步骤级偏离标记 \(t_{\text{div}}\)。 |
要理解这些轨迹在存储中如何区分，可以考察轨迹采集过程中记录的结构化元数据。自愈轨迹会显式记录中间的诊断过程，而困难负例则会标记致命的状态转移：
// Trace metadata diff: Recovery vs. Hard Negative
{
"trace_id": "traj-8492-recov",
"fault_injected": "ERRNO_13_ACCES",
"fault_turn": 4,
"diagnostic_turns": [5, 6], // "ls -la /build", "whoami"
"remediation_turn": 7, // "chmod +x /build/compile.sh"
"terminal_status": "VERIFIER_PASS"
}
// ----------------------------------------------------
{
"trace_id": "traj-9104-neg",
"divergence_turn": 4, // Executed "rm -rf /" instead of "./"
"invariant_violated": "INV_FILESYSTEM_ROOT_INTEGRITY",
"terminal_status": "VERIFIER_FAIL_TERMINAL"
}故障注入合成
在设计良好的生产预发布环境中，自然发生的错误很少。等待自然发生的网络断连、过期锁文件或权限配置错误来生成恢复轨迹，所能达到的采样率低得不切实际。因此，工业级轨迹采集系统必须纳入一个主动的故障注入合成运行框架，在轨迹采样生成期间有意扰动沙箱执行环境。
在运行良好的环境中，恢复行为很少出现。等待自然发生的权限错误或速率限制，所能采集到的恢复轨迹太少，因此采集过程会有意注入故障。容错系统综合 中为测试运行时恢复路径而构建的故障注入运行框架，也兼作恢复轨迹生成器。它按照配置的计划，在工具边界返回 恢复数据的故障注入分类体系 中的一类故障，而成功恢复的轨迹采样结果则成为恢复类别的候选样本。
| 故障类别 | 注入的异常 | 轨迹应展示的恢复行为 |
|---|---|---|
| 命令失败 | 退出码 127（command not found）、126（permission denied）、1（错误） |
检查环境，安装或定位二进制程序，修复权限 |
| 文件系统与状态 | 文件缺失、磁盘已满、合并冲突标记 | 定位文件，释放空间，编辑冲突标记并暂存处理结果 |
| 网络与服务 | HTTP 429、HTTP 504、连接断开 | 遵循重试响应头，执行退避，或绕过故障端点 |
| 格式错误或截断的数据 | JSON 解析错误、输出截断 | 重新发出有效调用，或请求分页输出 |
故障注入运行框架作为一个确定性代理层，置于智能体运行时与底层执行沙箱之间。通过利用操作系统级钩子——例如 ptrace 拦截、动态链接器预加载（LD_PRELOAD）或自定义虚拟文件系统（VFS）封装层——该框架拦截标准工具执行调用，并按照配置的扰动计划注入合成故障：
- 文件系统扰动： 模拟存储空间耗尽（
ENOSPC）、只读文件系统挂载（EROFS）、写入权限缺失（EACCES），或文件修改过程中出现的悬空符号链接。 - 进程与执行扰动： 注入共享库缺失（
LD_LIBRARY_PATH损坏）、编译器工具链未安装、内存不足导致的进程终止（通过 Linux cgroups 触发SIGKILL），或过期锁文件冲突（EEXIST）。 - 网络与 RPC 扰动： 在工具通信期间引入暂时性的 HTTP 429（请求过多）、HTTP 503（服务不可用）、损坏的 JSON 响应载荷或 TCP 数据包丢失。
结构可达性
当且仅当故障后的环境状态 \(S'\) 保留了通向目标的非空可达路径集合时，故障注入才有效：\(\text{Paths}(S' \to S_{\text{goal}}) \neq \emptyset\)。注入不可恢复的故障会使数据集质量退化为随机噪声。
故障注入受到一项关键工程约束的支配：结构可达性不变量。合成故障必须能够使用智能体清单 \(\mathcal{M}_{\text{tool}}\) 中可用的工具来恢复。如果运行框架通过删除包管理器来模拟库缺失，或在没有本地备用方案的情况下完全切断网络接口，智能体就不可能解决这一困境。注入不可恢复的故障不会产生恢复轨迹；它只会浪费计算周期，并生成不提供有效信息的负样本。该框架必须持续执行确定性验证检查，确认每一种注入故障配置都存在经过验证的恢复序列。
语料库组成比例
多轮诊断循环使恢复轨迹消耗了 45% 的词元预算，尽管它们仅占轨迹总数的 25%。
完成采集、验证和分类后，应如何将这些轨迹组合成一个连贯的策略训练语料库？朴素方法——例如仅使用等量的无故障轨迹和恢复轨迹进行训练——会在推理期间导致严重的行为失真。
如果策略的训练分布过度偏重恢复轨迹（占总词元量的 \(>40\%\)），模型就会形成操作性偏执。由于观察到标准工具调用之后出现意外错误的频率极高，策略开始臆想并不存在的风险。在运行简单的 git status 或编译一个简单测试之前，过度敏感的智能体会执行冗余的执行前检查：调用 whoami、使用 df -h 检查磁盘空间，以及验证网络套接字。这种过度防御行为加大了上下文窗口的消耗，增加了实际耗时延迟，并提高了模型服务成本，却没有改善任务成功率。
相反，如果数据集过度偏重高难度负例示范（\(>20\%\)），策略就会形成习得性无助或过度拒绝行为。当面对复杂、含糊的任务提示时，智能体会预测灾难性失败即将发生，选择输出拒绝词元或持续含糊其辞，而不是在环境中采取果断行动。
实证系统评估表明，通过强制采用非对称的语料库混合比例，可以实现最佳的策略韧性：
\[\mathcal{D}_{\text{train}} = \alpha \cdot \mathcal{T}_{\text{pristine}} \cup \beta \cdot \mathcal{T}_{\text{recover}} \cup \gamma \cdot \mathcal{T}_{\text{negative}}\]
其中，混合系数受到以下约束：
\[\alpha \in [0.60, 0.70], \quad \beta \in [0.20, 0.30], \quad \gamma \approx 0.10\]
这一分布确保正向的最优执行路径仍是模型策略分布中的主导模式，同时将近三分之一的训练课程用于诊断假设生成、错误纠正和明确的边界认知。
粗略估算 0.3: 混合策展的词元预算分配
对采集轨迹的实证性能分析表明，各类别具有以下特征：
- 无瑕轨迹（\(\mathcal{T}_{\text{pristine}}\)）： 平均轮数为 \(\bar{k}_{\text{p}} = 6\) 轮。平均序列长度为 \(\bar{L}_{\text{p}} = 7{,}200\) 个词元。
- 恢复轨迹（\(\mathcal{T}_{\text{recover}}\)）： 平均轮数为 \(\bar{k}_{\text{r}} = 14\) 轮（4 轮初始执行、1 轮故障、4 轮诊断、2 轮修复和 3 轮完成）。平均序列长度为 \(\bar{L}_{\text{r}} = 18{,}500\) 个词元。
- 困难负例（\(\mathcal{T}_{\text{negative}}\)）： 在偏离轮次之后再保留 2 轮探索，然后截断。平均轮数为 \(\bar{k}_{\text{n}} = 8\) 轮。平均序列长度为 \(\bar{L}_{\text{n}} = 9{,}800\) 个词元。
工程负责人设定的轨迹混合比例为：\(\alpha = 0.65\) 无瑕轨迹、\(\beta = 0.25\) 恢复轨迹和 \(\gamma = 0.10\) 困难负例。
- 计算分配给每个行为类别的轨迹总数。
- 计算策展数据集的词元总量，并确定三个类别在词元层面的实际分布。
- 量化存储和内存影响：恢复轨迹的长度明显偏大，这会如何影响数据集的词元成本？
解答：
步骤 1：轨迹数量分配
将目标混合系数应用于 \(N = 50{,}000\) 条轨迹： \[N_{\text{pristine}} = 0.65 \times 50{,}000 = 32{,}500 \text{ trajectories}\] \[N_{\text{recover}} = 0.25 \times 50{,}000 = 12{,}500 \text{ trajectories}\] \[N_{\text{negative}} = 0.10 \times 50{,}000 = 5{,}000 \text{ trajectories}\]
步骤 2：词元总量与实际词元分布
将轨迹数量乘以各自的平均序列长度： \[\text{Tokens}_{\text{pristine}} = 32{,}500 \times 7{,}200 = 234{,}000{,}000 \text{ tokens (234.0 M)}\] \[\text{Tokens}_{\text{recover}} = 12{,}500 \times 18{,}500 = 231{,}250{,}000 \text{ tokens (231.25 M)}\] \[\text{Tokens}_{\text{negative}} = 5{,}000 \times 9{,}800 = 49{,}000{,}000 \text{ tokens (49.0 M)}\]
词元总量 \(\mathcal{V}_{\text{total}}\) 为： \[\mathcal{V}_{\text{total}} = 234.0 + 231.25 + 49.0 = 514.25 \times 10^6 \text{ tokens (514.25 M tokens)}\]
现在，计算每个类别在词元层面的实际占比： \[\text{Share}_{\text{pristine}} = \frac{234.00}{514.25} \approx 45.50\%\] \[\text{Share}_{\text{recover}} = \frac{231.25}{514.25} \approx 44.97\%\] \[\text{Share}_{\text{negative}} = \frac{49.00}{514.25} \approx 9.53\%\]
步骤 3：系统层面的影响与经济性分析
尽管恢复轨迹仅占原始轨迹数量的 \(25\%\)（12,500 条，总计 50,000 条），但其冗长的诊断内容和较多的轮数使其贡献了全部监督训练词元的 44.97 percent。
采用标准 float16 表示（数据加载器中每个参数/词元的梯度占用 2 字节）时，数据集打包后的词元存储占用超过 1.028 GB。更关键的是，序列长度的差异（\(\bar{L}_{\text{r}} = 18{,}500\) 与 \(\bar{L}_{\text{p}} = 7{,}200\)）给分布式训练中的内存打包带来了重大挑战。如果简单地将批次中的序列填充到微批次内最长序列的长度，包含恢复轨迹的批次就会产生严重的尾部填充开销。因此，训练流水线必须实现动态序列打包（例如，将多条轨迹拼接打包，并配合交叉注意力掩码），以在梯度更新期间保持较高的张量核心利用率。
对这一均衡的三类语料库进行策展，可确保所得策略既学会持续推进执行，也具备诊断故障并从中恢复的能力。然而，大规模实施这一策展策略会带来巨大的系统挑战。生成数万条候选轨迹采样结果，在有状态环境中执行这些轨迹，注入同步的操作系统级扰动，并通过多阶段级联验证器评估每条轨迹，都需要工业级计算架构。我们应如何设计异步分布式基础设施，使其能够并发执行、隔离和采集数千条有状态的智能体轨迹，同时避免流水线停滞或串扰污染？
自我改进循环
一个团队使用其当前模型通过验证的轨迹采样结果进行微调，在留出任务上的表现提升了几个百分点，然后重复这一过程。第二轮的提升较小。到了第四轮，熟悉任务类型的通过率仍在上升，而不常见任务的通过率已停滞不前，模型生成的轨迹也变得更短、更趋同。流水线中的任何环节都没有失效。这个将模型自身经验证的输出反馈给模型的循环，缩窄了模型所接触的内容范围。
拒绝采样与专家迭代
这个循环包含四个步骤。当前策略 \(\pi_n\) 对每个测试用例尝试 \(k\) 次。级联验证流程接纳通过验证的尝试。使用这些尝试进行训练，得到 \(\pi_{n+1}\)（轨迹微调）。在留出划分上评估新策略；如果它通过发布门槛，就成为下一轮的采样策略。用验证器筛选采样输出，并使用保留下来的输出进行训练，这就是拒绝采样微调。每次使用新策略作为采样策略来重复这一过程，就是专家迭代；以模型自身成功的推理作为训练信号的自举推理方法，也以同样的模式为基础 (Zelikman 等 2022年)。验证器承担了专家示范者的角色，因此，级联验证流程的健全性限定了这个循环能够学到什么。
训练信号位于何处
并非每个测试用例都能提供训练信号。如果策略每次尝试成功完成某项任务的概率为 \(p\)，那么在 \(k\) 次独立尝试中，该任务至少产生一次成功的概率为 \(1 - (1-p)^k\)；当每次尝试都已成功时，该任务便不再提供新的可学习内容，这种情况的概率为 \(p^k\)。具有信息量的比例为
\[P_{\text{inform}}(p, k) = 1 - (1-p)^k - p^k \tag{3}\]
当 \(k = 8\) 时，公式 3 表明：对于策略有 5% 的概率解决的任务，其提供有效学习信息的概率约为 0.34；对于策略有一半概率解决的任务，该概率约为 0.99；对于策略有 95% 的概率解决的任务，该概率又降至约为 0.34。策略从未解决的任务无法提供成功样本，而策略总能解决的任务提供的则是它已经能够生成的轨迹。训练信号集中在中等难度区间，循环的采样预算应分配到这个区间。潜在能力解耦 中各任务的通过率可以确定这一区间，而测试用例生成过程应随着策略的改进，持续为该区间补充用例。
陈旧性与刷新
从 \(\pi_n\) 采样得到的轨迹描述的是 \(\pi_n\) 的行为。一旦训练产生 \(\pi_{n+1}\)，该语料库就成为离策略数据。原先处于有效学习区间的任务已向容易解决的一端移动，而值得学习如何从中恢复的错误，也不再是 \(\pi_{n+1}\) 所犯的那些错误。监督训练可以容忍一两轮的数据陈旧，但跨多轮重复使用的语料库会持续教授旧模型的行为。实践中的规则是：在每轮训练前，使用新策略对该区间内的每个测试用例重新采样，并在每条轨迹上记录采样策略的摘要标识（节 7），以便识别并淘汰陈旧轨迹。可验证奖励强化学习 在短得多的时间尺度上面临同样的问题，此时采样器与学习器之间的差距以梯度更新步数衡量。
坍缩
反复使用自身输出进行训练的模型，会丢失其分布的尾部。罕见但有效的策略被采样、接纳和用于训练的次数越来越少，直至消失 (Shumailov 等 2024年)。对于智能体，这些症状可以量化。每个测试用例对应的不同动作序列数量会下降。Pass@1 上升，而 pass@\(k\) 在 \(k\) 较大时保持不变；潜在能力解耦 将这一现象解读为策略正在集中于已有策略，而非获取新策略。留出任务族上的表现停滞不前，而训练任务族上的表现仍在上升。
四项措施可以维持循环的健康运行：
- 限制每个测试用例的采样数量，避免简单用例主导本轮训练。
- 按规范化后的动作序列去重，使八条近乎相同的通过验证的轨迹只计为一条。
- 保留一组外部数据作为锚点，其中包含人类和专家的示范，任何一轮都不替换这些数据。
- 跟踪多样性和留出任务族的表现，当这些指标停滞时停止循环，即使训练任务族的通过率仍在上升。
验证器的弱点也会以同样的方式被放大。级联验证流程在第一轮漏检的捷径会被准入、用于训练，并在第二轮更频繁地产生，这就是选择作用下的古德哈特定律（过程验证）在多轮迭代中的体现。每一轮都对已准入轨迹进行抽样审计，而不只是在开始时审计，才能在这种捷径成为策略偏好的行为之前将其发现。
生产环境反馈信号
部署后的智能体会产生任何测试夹具都无法提供的信号。用户会接受、编辑或撤销智能体生成的结果。他们会在对话中途纠正智能体、重试同一请求、放弃会话，或点击评分按钮。这些信号到来时没有判定基准，而且各自带有偏差，概述见 表 2。
| 信号 | 它表明什么 | 偏差或盲点 | 允许的用途 |
|---|---|---|---|
| 未经编辑即接受 | 输出交付时即可使用。 | 用户会接受看似合理但未经核查的输出。 | 排序信号；可考虑将对应任务转化为测试夹具。 |
| 编辑或撤销 | 输出有误或不完整；编辑内容揭示了具体问题。 | 编辑混合了纠错与个人偏好。 | 新测试夹具的来源，以编辑后的内容作为参考解答。 |
| 任务中途纠正 | 智能体在某个特定轮次误读了意图或状态。 | 标记了轮次，却没有指出原因。 | 分诊输入（节 1）；标记一个候选 \(t_{\text{div}}\)。 |
| 重试或放弃 | 本次尝试未满足需求。 | 也可能由延迟、成本或用户改变计划所致。 | 仅用作分诊输入。 |
| 显式评分 | 总体满意度。 | 数据稀疏、偏向极端评价，且对语气敏感。 | 排序器的校准数据；绝不能单独作为准入标签。 |
生产环境信号来自模型外部，因此比自我报告更有证据价值。但它们的噪声和偏差仍然过大，无法单独作为轨迹准入的依据。它们最适合用于发现值得构建测试夹具的任务。经过编辑的输出揭示了一个真实任务、一次真实失败，而且往往提供了参考解答，因此该任务可以转化为新的测试夹具，其判定基准可借助编辑内容来定义，而这次事件则成为 事件取证复盘 所指的回归任务。人工标注弥合了剩余的差距。由 节 3.4 中的排序器排序的标注队列，会将那些标注结果最能改变语料库的轨迹发送给审核人员；其吞吐量以每小时审核的轨迹数衡量，是下一节要确定规模的预算之一。
这一循环持续大规模运行，其成本由最慢的阶段决定。轨迹采样生成速度快，且可并行进行。验证过程则具有突发性，耗时呈重尾分布。当二者的处理速率偏离时，流水线要么停滞，要么被积压淹没。
采集流水线架构
在真实软件环境中执行数千条多轮自主智能体轨迹，会暴露出计算栈各层之间根本性的适配失衡。自回归轨迹采样工作进程在解码期间受 GPU 内存带宽限制，并在数十秒内间歇性地以流式方式输出突发的 token 序列。相对地，执行智能体 bash 调用、文件修改和编译器调用的环境沙箱会改变本地内核状态、消耗易失性存储块，并分配主机网络命名空间。当未经验证的候选轨迹完成与环境的交互后，必须将其移交给验证池。该验证池由静态代码检查器、封闭隔离的测试运行器和辅助神经判别器组成，其执行延迟跨越四个数量级——从抽象语法树（AST）解析所需的 \(15\text{ ms}\)，到包含合成网络延迟的完整系统集成测试套件所需的 \(180\text{ s}\)。
如果运行时工程师将这些阶段耦合成一个单体同步执行循环，最慢的验证框架就会阻塞 GPU 解码流水线，而快速涌入的轨迹采样突发负载则会耗尽主机内核文件描述符、造成网络命名空间泄漏，并使主机虚拟机监控程序陷入灾难性的内存耗尽与抖动。工业级轨迹采集流水线不能将轨迹采样生成、环境执行和验证视为一个单体循环；它需要一条异步、解耦的流水线，并通过严格的背压机制和亚秒级临时虚拟化来加以管控。
分布式流水线拓扑
为在异构计算资源上实现较高的硬件利用率，采集基础设施将轨迹采集分解为五个松耦合阶段，通过持久、异步的消息通道相连，如 图 4 所示。每个阶段遵循不同的系统设计原则：
- 阶段 1（任务分发器）管理代码仓库测试环境存储（\(S_0\)）、任务规格（\(P_{\text{task}}\)）和工具清单（\(\mathcal{M}_{\text{tool}}\)），发放拉取式租约（\(T_{\text{lease}} = 2 \times T_{\max}\)），其发放过程由配有主动式租约速率调节器（\(P_{50} = 2\,\text{ms}\)）的优先级引擎控制。
- 阶段 2（轨迹采样集群）承载非特权智能体监督进程，与 vLLM 连续批处理 GPU 解码器（\(P_{50} = 8\,\text{s}\)）交互。监督进程确保模型不具有任何隐式权限，将所有 shell 和编译器执行通过受控 RPC 边界委托出去。
- 阶段 3（临时沙箱池）维护已预热且处于暂停状态的 Firecracker 微虚拟机快照（\(P_{50} = 8\,\text{ms}\)）。工作进程利用写时复制（CoW）页表和本地 NVMe 覆盖层，在短于 \(10\,\text{ms}\) 的时间内恢复干净的测试环境，将观测增量（\(\Delta_{\text{fs}}\)）返回给监督进程，然后异步销毁。
- 阶段 4（暂存总线与验证器）将原始载荷（\(\tau_{\text{raw}} \approx 8.5\,\text{MB}\)）缓冲至持久化 Kafka 环形缓冲区（\(P_{50} = 120\,\text{ms}\)），同时由 CPU 工作进程执行多层验证器级联（\(V_1 \to V_2 \to V_3\)）。当队列积压深度 \(L_q > Q_{\max}\)（流量强度 \(\rho = \lambda/\mu \ge 0.85\)）时，验证器阶段会激活闭环背压反馈回路，通知分发器的租约速率调节器限制轨迹采样租约速率 \(\lambda_{\text{rollout}}\)。
- 阶段 5（存储接收端与数据划分）将已验证的执行轨迹（\(\tau_{\text{ver}}\)）摄取至列式 Apache Arrow / Parquet 数据集（\(P_{50} = 50\,\text{ms}\)），计算 HMAC 血缘封印（\(H_{\text{lineage}}\)），并将数据划分到干净训练存储（\(\mathcal{D}_{\text{train}}\)）和困难负样本隔离接收端（\(\tau^-\)），确保各划分的代码仓库家族互不重叠。 每个阶段均可独立扩展，隔离各自的故障域，并在入口和出口边界执行严格的运行契约，详见 表 3。
| 流水线阶段 | 主要硬件资源 | 延迟特征（\(P_{50}\) / \(P_{99}\)） | 核心系统抽象 | 主要故障模式 |
|---|---|---|---|---|
| 任务分发器 | CPU / 内存状态存储 | \(2\text{ ms}\) / \(15\text{ ms}\) | 支持种子租约的优先级 FIFO 队列 | 租约饥饿、重复分发 |
| 轨迹采样集群 | 高带宽 GPU 集群 | \(8\text{ s}\) / \(65\text{ s}\) | 无状态智能体宿主监督进程 | 推理超时、上下文溢出 |
| 沙箱池 | 宿主内存 / NVMe CoW 存储 | \(8\text{ ms}\) / \(45\text{ ms}\) | 临时微虚拟机快照 | 根文件系统泄漏、fork 炸弹、OOM |
| 验证集群 | 计算优化型 CPU / GPU | \(120\text{ ms}\) / \(180\text{ s}\) | 多阶段验证器级联 | 不稳定测试死锁、CPU 饱和 |
| 存储接收端 | 分布式对象存储 / NVMe | \(50\text{ ms}\) / \(350\text{ ms}\) | 列式 Arrow/Parquet 追加写入器 | 摄取背压、模式漂移 |
单条轨迹的生命周期始于任务分发器。分发器维护一个按优先级排序的任务测试环境描述符队列（\(\mathcal{F} = \langle S_0, \mathcal{M}_{\text{tool}}, \mathcal{P}_{\text{task}}, K \rangle\)）。它为每个任务分配一个密码学种子，以保证重复轨迹采样时伪随机数生成器（PRNG）的初始化具有确定性。分发器不直接向计算节点推送工作，而是提供拉取式租约协议。当轨迹采样集群中的空闲工作进程请求任务时，分发器将测试环境租借给它，租期为 \(T_{\text{lease}} = 2 \times T_{\max}\)，其中 \(T_{\max}\) 是任务的硬性执行超时时限。如果轨迹采样工作进程未能在 \(T_{\text{lease}}\) 到期前发送心跳，分发器便递增重试计数器，并将该测试环境重新加入队列。
轨迹采样工作进程充当无特权、无状态的宿主机监督进程。它执行智能体循环：通过 gRPC 将令牌生成请求分发至推理集群（例如，运行高吞吐量推测解码的 vLLM 或 SGLang），同时在无任何隐式授权的条件下对候选工具操作进行管控。轨迹采样工作进程不在本地执行命令，而是从临时沙箱池获取执行租约。
为防止智能体操作污染宿主机或在并发运行之间造成交叉干扰，每条轨迹都绑定到一个隔离的硬件虚拟机（如 Firecracker microVM）或无特权容器沙箱。沙箱池维护一组处于暂停状态的 microVM 快照热池，从而避免启动全新 Linux 内核或从头运行 docker run 所带来的数秒延迟。借助写时复制（CoW）页表和本地 NVMe 阵列上的叠加块存储，工作进程可恢复相同的基础快照 \(S_0\)，耗时低于 \(10\text{ ms}\)。
轨迹完成时——由显式停止令牌、预算耗尽或不可恢复的沙箱故障触发——轨迹采样工作进程将完整事件序列 \(\tau = (s_0, a_0, o_0, \dots, a_T, o_T)\) 序列化为紧凑的 Protocol Buffer，并将其加入验证暂存总线的队列。随后，轨迹采样工作进程立即将其 microVM 交还沙箱管理器，以便在后台销毁，从而将推理硬件与后处理评估解耦。
验证工作进程池从队列中取出原始轨迹，并按照 节 3 中确立的分阶段级联流程进行验证：
- 阶段 1 执行快速静态验证（\(V_1\)），检查 JSON 格式、补丁语法和 AST 有效性。未通过 \(V_1\) 的轨迹会立即被分流为困难负例训练候选样本或被丢弃，跳过成本高昂的下游阶段。
- 阶段 2 实例化封闭隔离的测试容器，以执行确定性的单元测试和回归测试套件（\(V_2\)）。
- 阶段 3（如适用）使用隔离的编译器工具链运行语义检查（\(V_3\)）。辅助判别模型也可对轨迹评分，以确定人工审核的优先顺序，但按照 节 3.1 的要求，它绝不独立决定接纳或拒绝某条轨迹。
通过验证阈值 \(c^*\) 的轨迹会附加完整的执行元数据（退出状态、执行墙钟时间、补丁差异和验证器评分卡），并交给存储接收端。存储接收端维护内存映射的环形缓冲区，将传入的轨迹记录批量组织为列式 Apache Arrow 记录批次，并定期将压缩后的 Parquet 文件写入分布式对象存储。这种列式格式将令牌序列、工具调用载荷和验证器标签组织为连续的字节向量，从而优化分布式训练期间的下游 I/O 吞吐量。
背压治理
由于采集流水线各阶段的服务时间分布差异极大，缺乏管控的架构必然会在灾难性的内存耗尽与工作进程饥饿之间振荡。令 \(\lambda_{\text{rollout}}\) 表示轨迹采样集群产出的已完成轨迹的平均到达率，令 \(\mu_{\text{verify}}\) 表示验证工作进程池的总服务率。
在平稳运行条件下，队列稳定性要求系统流量强度满足：
\[\rho = \frac{\lambda_{\text{rollout}}}{\mu_{\text{verify}}} < 1\]
然而，\(\lambda_{\text{rollout}}\) 和 \(\mu_{\text{verify}}\) 都不是确定性的。轨迹采样完成率 \(\lambda_{\text{rollout}}\) 会随着自回归序列长度、工具调用深度以及访问推理引擎的网络延迟而波动。更严重的是，验证服务时间分布 \(B(t)\) 呈显著右偏：语法验证（\(V_1\)）可在数十毫秒内完成，而 \(V_2\) 中失败的单元测试可能持续运行，直到达到 \(120\text{-second}\) 的超时限制。如果某批任务出现意外的回归问题，触发级联测试超时，\(\mu_{\text{verify}}\) 的降幅可达两个数量级。
根据利特尔定律（\(L = \lambda W\)），验证暂存缓冲区中积累的平均轨迹数（\(L_q\)）等于到达率 \(\lambda\) 与队列平均等待时间（\(W_q\)）的乘积：
\[L_q = \lambda_{\text{rollout}} \cdot W_q = \lambda_{\text{rollout}} \left( \frac{\rho}{\mu_{\text{verify}}(1 - \rho)} \right) \cdot \left( \frac{C_a^2 + C_s^2}{2} \right)\]
其中，\(C_a^2\) 和 \(C_s^2\) 分别表示到达间隔时间和服务时间的变异系数平方（针对 \(G/G/1\) 系统的金曼近似）。由于软件测试套件的执行时间呈重尾分布（\(C_s^2 \gg 1\)），任何满足 \(\lambda_{\text{rollout}} \to \mu_{\text{verify}}\) 的持续突发负载都会导致 \(L_q\) 急剧增大。
由于每个原始轨迹 Protocol Buffer 都封装了完整的多轮执行历史——包括环境的 stdout/stderr 转储、中间 git 差异以及高分辨率遥测数据——单条轨迹序列化后的内存占用平均为 \(\bar{S}_{\text{traj}} \approx 8.5\text{ MB}\)，在大型多文件重构运行中最高可达 \(64\text{ MB}\)。一个缺乏管控、积压了 \(10{,}000\) 条轨迹的暂存队列将消耗超过 \(85\text{ GB}\) 的易失性系统内存，导致消息代理所在系统触发内核内存不足（OOM）故障。
粗略估算 0.4: 暂存缓冲区与背压容量规划
下游验证资源池包含 \(N_{\text{ver}} = 512\) 个 CPU 工作槽位。级联验证器的服务时间呈双峰分布：
- \(75\%\) 的轨迹未通过早期静态检查（\(V_1\)），耗时 \(t_{\text{fast}} = 2.5\text{ s}\)。
- \(25\%\) 的轨迹需要执行完整测试套件（\(V_2\)），耗时 \(t_{\text{slow}} = 60.0\text{ s}\)。
1. 计算标称验证服务速率与容量利用率： 每条轨迹的平均验证服务时间为： \[\bar{t}_{\text{verify}} = (0.75 \times 2.5\text{ s}) + (0.25 \times 60.0\text{ s}) = 1.875\text{ s} + 15.0\text{ s} = 16.875\text{ s}\]
\(512\) 个验证槽位的总服务速率为： \[\mu_{\text{verify}} = \frac{N_{\text{ver}}}{\bar{t}_{\text{verify}}} = \frac{512}{16.875\text{ s}} \approx 30.34\text{ trajectories/s}\]
标称流量强度为： \[\rho = \frac{\lambda_{\text{rollout}}}{\mu_{\text{verify}}} = \frac{22.75}{30.34} \approx 0.750\] 在稳态条件下，验证资源池具有充足的余量（\(\rho < 1\)）。
2. 异常代码挂起故障突发的影响： 假设一个损坏的软件测试夹具在测试套件中引入了无限循环，导致所有测试均达到测试运行器的硬超时上限（\(t_{\text{timeout}} = 120\text{ s}\)），使分布发生变化：传入的轨迹采样中有 \(100\%\) 进入 \(V_2\) 并触发超时。
退化后的服务速率骤降至： \[\mu_{\text{degraded}} = \frac{512}{120\text{ s}} \approx 4.27\text{ trajectories/s}\]
退化后的流量强度变为： \[\rho_{\text{degraded}} = \frac{22.75}{4.27} \approx 5.33 \gg 1\] 队列以如下净速率增长： \[\Delta \lambda = \lambda_{\text{rollout}} - \mu_{\text{degraded}} = 22.75 - 4.27 = 18.48\text{ trajectories/s}\]
以消息代理中累积的物理内存量计： \[\frac{dM}{dt} = \Delta \lambda \times \bar{S}_{\text{traj}} = 18.48\text{ trajectories/s} \times 8.5\text{ MB} \approx 157.08\text{ MB/s}\]
3. 设定缓冲区容量上限与限制入口流量： 如果消息队列代理分配了 \(M_{\max} = 32\text{ GB}\) 的专用暂存 RAM，则在退化条件下，距离内存耗尽的时间为： \[T_{\text{exhaust}} = \frac{32 \times 1{,}024\text{ MB}}{157.08\text{ MB/s}} \approx 208.6\text{ s} \approx 3.48\text{ minutes}\]
为防止灾难性系统故障，流水线必须强制执行绝对队列深度阈值： \[Q_{\max} = \frac{M_{\max}}{\bar{S}_{\text{traj}}} = \frac{32 \times 1{,}024\text{ MB}}{8.5\text{ MB}} \approx 3{,}855\text{ trajectories}\]
将高水位标记设为 \(Q_{\text{high}} = 0.75 \times Q_{\max} \approx\) 2,891 条轨迹，可使背压控制器立即停止任务分发器发放任务租约，迫使轨迹采样工作进程在消息代理耗尽物理内存之前暂停执行。
为保护系统免于内存耗尽和工作进程级联故障，采集架构实现了一个采用双水位的闭环背压控制器。该控制器监控验证暂存缓冲区的瞬时队列深度 \(Q_{\text{current}}\)：
\[\text{Dispatcher State} = \begin{cases} \text{ACTIVE} & \text{if } Q_{\text{current}} \le Q_{\text{low}} \\ \text{THROTTLED}(p_{\text{shed}}) & \text{if } Q_{\text{low}} < Q_{\text{current}} < Q_{\text{high}} \\ \text{HALTED} & \text{if } Q_{\text{current}} \ge Q_{\text{high}} \end{cases}\]
当 \(Q_{\text{current}}\) 越过 \(Q_{\text{high}}\) 时，任务分发器撤回向轨迹采样集群提供的租约。空闲的轨迹采样工作进程无法启动新的轨迹采样，而是停留在异步等待循环中。
高吞吐量采集系统采用基于信用额度的流量控制，而非完全依赖响应式队列水位机制。每个轨迹采样工作进程在拉取任务夹具之前，必须从集中式租约管理器获取一个执行信用额度。租约管理器配置的信用额度池总量受以下约束：
\[C_{\text{total}} = Q_{\text{target}} + N_{\text{ver}}\]
其中，\(Q_{\text{target}}\) 是掩盖验证调度抖动所需的最优队列深度，同时避免内存占用过度累积。当验证工作进程完成评估的最后阶段并将记录写入存储接收端时，它会将信用额度归还租约池。如果验证停滞，可用信用额度会递减至零，自动在输入阶段阻止轨迹采样集群获取新任务，从机制上防止队列膨胀，其形式化描述见 表 4。
| 流水线组件 | 运行机制 | 流量控制状态 | 不变量保证 |
|---|---|---|---|
| 轨迹采样工作进程集群 | 生成候选轨迹（\(T_{\text{rollout}}\)）；在开始执行步骤之前向租约池申请执行信用额度。 | 当信用额度 \(\le 0\) 时阻塞 | 绝不会超出下游缓冲区的内存容量。 |
| 中间队列 | 高吞吐量内存消息代理（Kafka / Redis Streams），用于缓冲尚未验证的轨迹。 | 受 \(Q_{\text{target}}\) 约束 | 队列内存开销严格限制在 \(M_{\text{queue}} \le 4\ \text{GB}\)。 |
| 验证工作进程集群 | 执行分阶段验证器（\(V_1 \to V_2 \to V_3\)）；记录写入接收端后将信用额度归还池中。 | 动态扩展并发度 | 验证吞吐量与下游消费者速率匹配。 |
| 存储接收端与分区 | 将验证成功的记录路由至训练接收端，将验证失败的记录路由至困难负样本分区，将损坏的轨迹路由至丢弃分区。 | 持续流式追加 | 以确定性方式对数据进行分区，形成均衡的微调数据混合。 |
虚拟机监控器资源清理
由于智能体轨迹会在沙箱内执行任意、非确定性的 shell 命令、测试脚本和系统工具，因此会对底层宿主机操作系统造成严重且不断累积的损耗。虽然主要的文件修改发生在沙箱边界内，但每小时反复创建、连接和销毁数千个执行环境的过程，会在宿主机 Linux 内核中引发严重的资源泄漏。实践中，长期运行的采集集群很少因模型推理失败而崩溃；它们崩溃的原因是宿主机虚拟机监控器耗尽了存储块、网络表资源或内核进程表条目。宿主机与沙箱边界两侧的子系统层、泄漏机制及清理策略见 表 5。
| 子系统层 | 物理资源 | 泄漏故障模式 | 运行时清理与回收协议 |
|---|---|---|---|
| 进程子系统 | 内核 PID 表（/proc/sys/kernel/pid_max） |
崩溃的子智能体留下的僵尸进程未被回收，耗尽宿主机 PID 表。 | 专用 PID 命名空间（CLONE_NEWPID）；子进程回收 init 守护进程在退出时向 cgroup 树发送 SIGKILL。 |
| 网络子系统 | 虚拟以太网（veth）接口对与网桥端口 |
遗弃的 veth 接口耗尽 Linux 网桥（br0）的端口配额（最多 1,024 个）。 |
原子化销毁网络命名空间（ip netns del）；动态接口回收守护进程审计网桥状态。 |
| 内存子系统 | POSIX 共享内存（/dev/shm）与页缓存 |
多进程 IPC 段遗留在 /dev/shm 中且未解除链接，导致宿主机 DRAM 泄漏。 |
为每个沙箱挂载独立、临时的 tmpfs 实例；cgroup v2 内存控制器强制执行严格的驱逐上限。 |
| 存储子系统 | OverlayFS 可写 upperdir 与 DeviceMapper |
孤立的 CoW 层以及已解除链接但仍打开的文件描述符消耗 NVMe 磁盘块。 | 使用临时回环卷或 ZFS 子卷，并以确定性方式销毁（umount + ioctl(BLKDISCARD)）。 |
生产环境中的轨迹采集运行时必须显式防范三大类虚拟机监控器资源泄漏：
- 残留的网络命名空间和虚拟接口： 每个容器或 microVM 都需要一对虚拟以太网接口（
veth），将客户机网络接口桥接到隔离的宿主机网桥（例如br0）。当智能体超时或异常崩溃时，缺乏协同的清理脚本往往会终止客户机进程，却未能删除对应的宿主机侧veth接口。Linux 内核对网络接口数量施加了架构层面的硬性上限（通常受默认配置或路由表内存限制）。经过数千次迭代，残留接口会耗尽内核网络子系统表的容量，导致后续套接字分配失败，报出ENFILE（文件表溢出）或EADDRINUSE。 - 孤立的存储块和已解除链接的 inode： 高速沙箱重置依赖写时复制（CoW）叠加层（例如 Linux
overlayfs或 DeviceMapper 精简配置）。在智能体轨迹采样过程中，修改构建目录、编译二进制文件或下载依赖项等操作，可能向临时叠加层的上层目录（upperdir）写入数 GB 的临时数据。如果工作进程在清理过程中崩溃，底层回环挂载或逻辑卷的引用计数就会保持非零。尽管目录路径可能已从文件系统树中解除链接，底层存储块仍然在宿主机 NVMe 阵列上处于已分配状态。这表现为一种隐蔽的“幽灵泄漏”：宿主机磁盘使用情况（df）报告容量利用率为 \(100\%\)，而目录遍历（du）显示文件占用量微乎其微。 - POSIX 共享内存和 IPC 泄漏： 在执行沙箱中运行的应用程序，尤其是 Python 多进程应用、PyTorch CPU 张量和无头浏览器进程，会通过
/dev/shm和 POSIX 信号量大量分配共享内存。当沙箱通过直接发送SIGKILL终止，而未让子进程回收器正常完成关闭流程时，宿主机内核会保留孤立的共享内存段。由于/dev/shm被挂载为虚拟内存文件系统（tmpfs），孤立内存段会直接消耗宿主机 RAM，挤占操作系统页缓存，并引发宿主机范围的内存压力。
为持续保持虚拟机监控器的资源整洁，同时避免破坏性的宿主节点重启，智能体执行监控程序在每个沙箱生命周期中实施严格的多层清理协议，概述见 表 6：
| 宿主机资源子系统 | 故障／泄漏机制 | 内核诊断指标 | 确定性清理机制 |
|---|---|---|---|
| 进程表 | 逃逸出容器命名空间的僵尸子进程 | /proc/sys/kernel/ns_last_pid 中 PID 数量过高 |
在宿主机监控程序上使用 PR_SET_CHILD_SUBREAPER + cgroup.kill |
| 虚拟网络 | 孤立的 veth 接口对和残留的网桥端口 |
ip link show type veth 中未绑定的条目 |
显式解除命名空间关联：ip link delete <veth_id> |
| 存储子系统 | 未释放的 CoW 叠加层挂载和打开的文件句柄 | lsof +L1 与 df -h 之间的 inode 不匹配 |
延迟卸载（umount -l），随后对卷池执行 trim 操作 |
| IPC 与共享内存 | 孤立的 /dev/shm 分配和 IPC 信号量 |
ipcs -m 和 /dev/shm/ 中的内存泄漏 |
专用的沙箱挂载命名空间；卸载时清理 tmpfs |
清理框架使用 Linux cgroup v2 控制层级结构实现进程隔离。每个临时沙箱都被分配一个唯一的专用控制组路径（例如 /sys/fs/cgroup/agent/sandbox_<id>）。当轨迹采样工作进程发出完成信号或达到执行截止时间时，宿主机运行时通过向控制组的原子终止控制器写入 1 来启动清理流程：
# Atomically terminate all descendant threads inside the sandbox cgroup
echo 1 > /sys/fs/cgroup/agent/sandbox_1042/cgroup.kill向进程标识符发送定向的 kill -9 时，如果智能体启动的后台守护进程脱离了父进程树，就可能留下孤儿子进程；与之不同，cgroup.kill 会调用内核内部的任务终止机制，以原子方式终止共享同一 cgroup 叶节点的所有线程。
为消除网络接口泄漏，主机监督程序使用显式上下文管理器封装网络创建操作，确保每个虚拟接口的创建都配有一个保证执行的终结器。监督程序使用仅追加的内存租约注册表来跟踪生命周期：
# Host-side virtual interface lease teardown with error resilience
def release_sandbox_network(sandbox_id: str, veth_host: str) -> None:
try:
# Explicit deletion of the host-side veth removes the paired peer in the guest namespace
subprocess.run(["ip", "link", "delete", veth_host], check=True, timeout=2.0)
except (subprocess.CalledProcessError, subprocess.TimeoutExpired) as err:
logger.error(f"Failed to detach veth {veth_host} for sandbox {sandbox_id}: {err}")
# Force reconciliation: move interface to fallback janitor namespace for background purge
quarantine_network_interface(veth_host)最后，一个低优先级的宿主机守护进程（清理智能体）在每个物理虚拟机监控器节点上以带外方式运行。该清理智能体每隔 \(30\text{ seconds}\) 扫描系统表，将活跃沙箱标识符与宿主机资源租约进行核对。任何在任务分发器中没有活跃租约的网络命名空间、叠加挂载点或 /dev/shm 分配，都会立即被卸载、解除链接并回收。通过使宿主机虚拟机监控器免受不断累积的执行产物影响，分布式流水线能够在数百万次轨迹采样中维持连续的采集循环，而无需因维护而停机。
随着经过清洗和验证的轨迹以流式方式写入持久化列式存储接收端，工程挑战的重心从运行可用性转向数据完整性。如果训练流水线无法确定生成每个步骤的确切模型检查点、系统提示词、工具模式和环境条件，或者不可信的智能体交互意外地将有效的 API 密钥、数据库凭据或私有源代码持久化到训练语料中，那么海量轨迹记录就毫无用处，甚至可能带来危险。我们该如何设计一个不可变、可通过密码学验证的来源追踪系统，在审计每一次状态转移的同时，严格清除采集数据中的敏感凭据？
轨迹来源追踪
当自主智能体与云基础设施、本地开发沙箱和企业数据库交互时，其执行轨迹不可避免地会接触敏感且易变的状态：临时云凭据、个人访问令牌、数据库连接字符串以及专有源代码树。如果轨迹采集流水线将这些原始轨迹直接以流式方式写入离线存储接收端，用于后续策略优化，就会引入两种灾难性失效模式，分别冲击机器学习系统生命周期的两端。首先，自回归语言模型能够以惊人的效率记忆高熵子串；在未经清洗的轨迹上微调的智能体策略，在受到不可信外部用户提示时，会稳定地复述出有效的 root 凭据、私有加密密钥或专有的内部 API 端点。其次，当更新后的策略在数月后出现严重的行为退化时，系统工程师往往发现，他们无法复现训练轨迹，因为基础模型检查点、确切的系统提示词模板、外部工具模式定义或容器文件系统状态已经发生变化，却没有留下不可变的密码学记录。
缺少密码学谱系的采集轨迹是无法复现的遥测数据；缺少自动凭据清除机制的采集轨迹则是企业的有害负担。 将执行轨迹视为一等系统产物，要求将其从任意的序列化 JSON 字符串序列提升为不可变、经密码学封存的数据结构——谱系封套——同时执行确定性的多遍清洗流水线，在保留工具调用语法完整性的同时，不持久化任何私有环境隐含权限信息。
密码学谱系封套
在经典分布式系统和数据库理论中，数据来源回答了 Peter Buneman、Sanjeev Khanna 和 Tan Wang-Chiew（2001）提出的两个基本问题：原因来源，用于识别促成某一输出的具体输入数据；以及生成过程来源，用于描述生成该输出的确切计算过程和结构变换。在智能体执行运行时中，每一次观测到的转移 \(s_t \xrightarrow{a_t} s_{t+1}\) 都不只是模型权重 \(\pi_\theta\) 的产物；它是四层计算栈共同作用的产物：神经推理引擎、宿主机编排框架、工具执行平面以及沙箱化的操作系统环境。
为了保证完整的生成过程来源信息，采集流水线必须将每条收集到的轨迹封装在不可变的轨迹谱系封套中。该封套将状态转移序列与参与轨迹生成循环的每个硬件和软件组件的密码学摘要绑定起来。如果这个计算栈的任何组件发生变化——无论是上游工程师更新了系统提示词中的一句话、工具开发者向 OpenAPI 模式添加了一个可选参数，还是基础 Docker 镜像重新构建了某个底层动态共享库——轨迹的密码学身份都会随之改变，从而防止静默的分布偏移污染下游策略训练语料。
算法确定性与逐位确定性 由于 GPU 矩阵乘法内核中并行浮点归约的顺序存在差异（例如，在不同线程块调度器下，不满足结合律的 FP16/BF16 GEMM 运算），跨不同 GPU 微架构保证精确的逐位确定性极其困难。固定随机种子、生成参数和权重校验和可以保证算法可复现性，从而将软件漂移与硬件微架构差异区分开来。
谱系封装强制实施五个相互正交的密码学追踪维度，详见 表 7：
- 基础模型快照： 规范的模型家族名称、架构修订版本，以及完整模型权重的 SHA-256 密码学摘要（例如，对
safetensors分发包中按键排序的扁平张量字典计算摘要）。如果采用参数高效微调（PEFT），封装还会单独记录当前启用的 LoRA 适配器权重的确切提交哈希和校验和。 - 运行框架与接口清单： 规范系统提示词模板的 SHA-256 摘要、BPE 分词器配置摘要，以及智能体调度表中注册的每个工具端点的语义版本号和 OpenAPI 3.0 模式哈希。
- 沙箱环境状态： 根容器镜像的密码学内容地址（摘要）（例如，
docker-manifest.v2+json摘要）、宿主机内核版本，以及待测目标仓库的确切 Git 提交 SHA，包括在步骤 \(t_0\) 之前应用的所有未提交工作树差异的 SHA-256 摘要。 - 随机采样元组： 传递给推理引擎的伪随机数生成器种子，以及控制词元生成的完整超参数元组：温度 \(\tau\)、核采样阈值 top-\(p\)、top-\(k\)、重复惩罚，以及生成词元数量的最大边界。
- 验证与结果签名： 验证测试套件的 Git 提交哈希、每个分阶段验证器的标准 POSIX 退出状态码，以及对轨迹进行评估的验证工作节点的分离式密码学签名。
| 元数据维度 | 具体字段名称 | 表示格式 | 验证保证 |
|---|---|---|---|
| 模型检查点 | model_weight_digest |
sha256:[64 hex] |
确认权重在字节级别完全一致；检测对基础检查点的静默修补。 |
| 模型检查点 | adapter_digest |
sha256:[64 hex] |
验证应用于基础模型的确切 LoRA/PEFT 参数增量。 |
| 提示词模板 | prompt_template_hash |
sha256:[64 hex] |
检测上游系统提示词的变更和分隔符调整。 |
| 分词器 | tokenizer_vocab_digest |
sha256:[64 hex] |
防止分词不匹配和词表索引错位。 |
| 工具接口 | tool_manifest_digest |
sha256:[64 hex] |
保证工具定义、参数类型和文档字符串完全一致。 |
| 环境 | container_image_digest |
sha256:[64 hex] |
验证容器根文件系统、操作系统软件包和共享库。 |
| 环境 | repo_commit_sha |
git-sha1:[40 hex] |
标识智能体修改之前的确切应用代码库基线。 |
| 采样控制 | sampling_params |
规范 JSON 元组 | 记录控制解码循环的 \(\tau\)、top-\(p\)、top-\(k\) 和伪随机数生成器种子。 |
| 验证器不变量 | verifier_suite_digest |
sha256:[64 hex] |
保证机械化测试判据未被放宽或发生漂移。 |
为防止分布式对象存储中的篡改或数据退化，采集流水线对整个执行封装计算聚合谱系标识符 \(H_{\text{lineage}}\)：
\[H_{\text{lineage}} = \text{HMAC-SHA256}\left( K_{\text{pipe}}, \, H_{\text{model}} \parallel H_{\text{prompt}} \parallel H_{\text{tools}} \parallel H_{\text{env}} \parallel H_{\text{sample}} \parallel H_{\text{trajectory}} \right)\]
其中，\(K_{\text{pipe}}\) 表示摄取流水线的私钥，\(H_{\text{trajectory}}\) 是根据按顺序排列的交互轮次序列 \(\langle (s_0, a_0), (s_1, a_1), \dots, (s_T, a_T) \rangle\) 计算得到的 Merkle 根。以 \(H_{\text{lineage}}\) 为索引存储轨迹，可保证存储具备内容寻址能力：下游训练作业可以根据确切的环境配置选择性地筛选训练数据，确保策略绝不会使用在不兼容的工具定义或未经验证的运行时环境下生成的轨迹进行训练。
这一密码学绑定的完整结构及其下游脱敏流程详见 图 5：
- 左侧的密码学谱系封装记录布局（\(S_{\text{envelope}} \approx 2.65\,\text{KB}\)）封装了三个不可变层级：
- 不可变头部清单，记录模型权重（\(H_{\text{model}}\)）、系统提示词模板（\(H_{\text{prompt}}\)）、OpenAPI 工具模式（\(H_{\text{tools}}\)）、容器 rootfs 和提交 SHA（\(H_{\text{env}}\)）以及 PRNG 采样种子（\(H_{\text{sample}}\)）的密码学摘要。
- 状态—动作 Merkle 树，覆盖全部 \(T\) 个交互步骤，将步骤元组 \(h_t = H(s_t, a_t, o_t)\) 和文件系统差异 \(\Delta_{\text{fs}}\) 哈希为单一 Merkle 根 \(H_{\text{trajectory}}\)。
- 机械验证证明与角色标签，绑定测试退出断言和轨迹分类（
RECOVERY_DEMONSTRATION）。 这些字段使用 HMAC 密钥 \(K_{\text{pipe}}\) 封存，生成不可变的内容可寻址索引 \(H_{\text{lineage}}\)，从而确立权威对象存储键（s3://corpus/traj-e84a1b.arrow）。
- 右侧的保持语法不变的三遍脱敏流程在不破坏语法的情况下清洗传入轨迹。暴露凭据的原始观测（例如 AWS 密钥
AKIAIOSFODNN7EXAMPLE、员工电子邮件地址和 RFC 1918 IP 地址10.240.0.12）依次经过第 1 遍处理（DFA 正则表达式匹配，以及针对 \(H(S) \ge 4.5\,\text{bits/char}\) 的滑动窗口香农熵过滤）；第 2 遍处理（量化 DistilBERT NER 和 CIDR 子网检测）；第 3 遍处理（使用加盐化名HMAC(K_salt, secret)[:12]对 AST 字符串字面量进行掩码处理）。生成的列式记录保留逐位有效的 JSON 语法和 token 序列长度，同时确保向下游模型权重泄漏的 token 数为零（\(\Lambda_{\text{leak}} = 0.00\%\)）。
粗略估算 0.5: 谱系封装的存储与延迟
轨迹特征： 每个交互步骤记录一个模型生成块（512 个 token，约为 \(2{,}048\text{ bytes}\) 的 UTF-8 文本）和一个工具观测载荷（平均为 \(1{,}536\text{ bytes}\) 的 shell/JSON 输出）。每条轨迹的原始交互文本量为： \[S_{\text{raw}} = 32 \times (2{,}048 + 1{,}536)\text{ bytes} = 32 \times 3{,}584\text{ bytes} \approx 114.69\text{ KB}\]
谱系封装开销： 谱系封装会添加固定的元数据：
- 模型、适配器、提示词、分词器和工具清单的摘要：\(5 \times 32\text{ bytes} = 160\text{ bytes}\)。
- 环境哈希（容器摘要、Git SHA、差异摘要）：\(3 \times 32\text{ bytes} = 96\text{ bytes}\)。
- 采样参数块和验证器元数据：\(256\text{ bytes}\)。
- 32 个步骤对应的 Merkle 树中间节点哈希：\((32 + 16 + 8 + 4 + 2 + 1) \times 32\text{ bytes} = 63 \times 32\text{ bytes} = 2{,}016\text{ bytes}\)。
- 数字签名和封装成帧信息：\(128\text{ bytes}\)。 每条轨迹的封装总开销为： \[S_{\text{envelope}} = 160 + 96 + 256 + 2{,}016 + 128 = 2{,}656\text{ bytes} \approx 2.60\text{ KB}\]
相对存储开销： \[\text{Overhead Ratio} = \frac{S_{\text{envelope}}}{S_{\text{raw}}} = \frac{2{,}656}{114{,}688} \approx 2.32\%\] 对于每天的 \(100{,}000\) 条轨迹，原始载荷总量为 11.47 GB/day，而密码学谱系封装仅占 0.27 GB/day。
验证吞吐量： 在现代 AVX-512 或支持 ARMv8-A 密码学扩展的硬件上计算 SHA-256 摘要时，每个 CPU 核心的吞吐量可超过 \(1.8\text{ GB/s}\)。对合计为 \(117.34\text{ KB}\) 的原始轨迹记录与封装进行哈希计算，需要： \[t_{\text{hash}} = \frac{117.34 \times 10^3\text{ bytes}}{1.8 \times 10^9\text{ bytes/s}} \approx 6.52 \times 10^{-5}\text{ s} = 65.2\ \mu\text{s}\] 单个专用验证线程每秒可对超过 15,340 条轨迹完成密码学封装，给摄取流水线带来的延迟可以忽略不计。
秘密信息脱敏
虽然谱系封装保证了结构完整性，但执行轨迹的原始内容在清洗之前仍具有危险性。当智能体尝试解决软件工程任务或执行 API 工作流时，它经常会执行暴露敏感凭据的命令：读取 .env 文件、调用云服务提供商的凭据辅助工具、通过 OAuth 令牌获取私有依赖，或接触生产数据库转储。
如果一个简单的采集系统采用常规字符串删除或粗暴的正则表达式替换，就会造成一种隐蔽但破坏性极强的系统故障：语法损坏。现代语言模型经过训练，需要遵循严格的语法规范，例如有效的 JSON 工具调用或括号配对完整的 Bash 命令替换。如果脱敏处理任意删除 JSON 载荷中的 API 密钥（例如，将 {"auth": "bearer ghp_secret123"} 转换为 {"auth": }），JSON 解析器就会失败，或者下游策略会学会生成语法错误的工具调用。反之，如果高熵秘密信息未被脱敏，微调过程就会将其记忆下来，违反 Cynthia Dwork（2006）对差分隐私的奠基性表述：查询训练后模型的攻击者不应能够推断某个特定私有凭据是否存在于训练语料中。
为了兼顾隐私保护与语法有效性，生产环境中的采集运行时会在将轨迹提交到持久化存储目标之前，执行自动化的三遍脱敏流水线。
第一遍：确定性模式扫描
第一遍脱敏使用结合确定性正则表达式与香农熵计算的双引擎过滤器，扫描动作和观测中的所有文本字段。
结构化秘密信息具有已知前缀和校验和约束。第一遍处理采用高吞吐量的确定性有限自动机（DFA），匹配既定的秘密信息特征，包括 AWS 访问密钥 ID（AKIA[0-9A-Z]{16}）、GitHub 个人访问令牌（ghp_[A-Za-z0-9_]{36}）、Slack API 令牌和 OpenSSH 私钥 PEM 头（-----BEGIN OPENSSH ...-----）。
非结构化秘密信息——例如原始数据库密码、base64 编码的二进制令牌或任意十六进制密钥——缺乏可预测的前缀。第一遍处理通过计算经验香农熵 \(H(S)\) 来检测这些字符串，计算采用长度为 \(W\)（通常为 \(W = 32\text{ characters}\)）的滑动字符窗口：
\[H(S) = -\sum_{i=1}^{k} p(c_i) \log_2 p(c_i)\]
其中，\(p(c_i)\) 是字符 \(c_i\) 在窗口内的观测频率，该字符来自字母表 \(\Sigma\)。常规源代码和自然语言文本的熵介于 \(2.5\) 与 \(3.8\text{ bits per character}\) 之间，这是因为人类语言和编程语言关键字的频率分布不均匀。随机密码学密钥、密码和 base64 编码的哈希值接近最大熵，其熵值始终达到 \(H(S) \ge 4.5\text{ bits per character}\)。任何超过经验阈值 \(H_{\text{threshold}} = 4.5\)、且并非已有 Git 提交哈希或已知编译器摘要的子串，都会被标记为需要脱敏。
第二遍：上下文感知的命名实体识别（NER）
并非所有敏感数据都具有高熵。个人身份信息（PII）——包括员工姓名、企业电子邮件地址和内部网络基础设施拓扑——具有低熵，无法仅凭熵与一般文本区分。第二遍处理将自然语言观测流送入本地部署的高吞吐量命名实体识别（NER）模型（例如量化的 DistilBERT 或 RoBERTa token 分类器）。
除实体分类外，第二遍处理还依据 RFC 1918 私有 IPv4 规范（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）、RFC 4193 唯一本地 IPv6 地址（fc00::/7），以及企业内部完全限定域名（FQDN，例如 *.corp.internal），检查网络地址信息。识别出的主机名和子网会被标记为需要替换，以防智能体策略学到内部预发布集群的拓扑。
第三遍：保持语法不变的差分 token 掩码
最后一遍处理将已标记的秘密信息片段与周围文档的结构语法协调起来。直接拼接原始字符串会破坏 JSON 和 shell 的 AST，因此第三遍处理采用差分 token 掩码。脱敏器将结构化字符串解析为抽象语法树（AST），定位包含秘密信息的具体字符串字面量节点，并将敏感字符替换为通过密码学加盐生成的假名：
<REDACTED_SECRET:HMAC-SHA256(K_salt, secret)[:12]>这种替换策略保留了三项关键的系统不变量：
- 语法正确性：由于替换发生在 AST 的字符串字面量节点内部，引号、转义字符、右花括号和数组逗号始终保持完全配对。
- 引用透明性（共指一致性）：通过使用每个数据集专属的盐值 \(K_{\text{salt}}\)，对原始秘密值计算带密钥的哈希并据此生成化名，同一轨迹中多个步骤里的相同秘密值会得到相同的化名。如果智能体在第 3 步输出一个身份验证令牌，并在第 7 步的 curl 请求头中再次输出该令牌，下游模型就能观察到一致的变量复用，从而在不暴露底层凭据的情况下保留演示的因果逻辑。
- 令牌长度稳定性：如果将长字符串替换为任意占位符，下游分词器的切分边界可能发生显著变化。将化名格式化为固定字符宽度，可尽量减少对模型自回归注意力跨度的人为扭曲。
以下失败轨迹展示了差异化令牌掩码对实际执行记录的物理影响：
// Trajectory Step 04: Execute authenticated API pull
{
"tool_name": "execute_bash",
- "command": "curl -H 'Authorization: Bearer ghp_99AxL002KzQ891mB18' https://api.internal.net/v1/keys",
- "stdout": "{\"status\": \"success\", \"api_key\": \"sec_live_99814421bfae\"}"
+ "command": "curl -H 'Authorization: Bearer <REDACTED_SECRET:4f8a2b1c9e01>' https://api.internal.net/v1/keys",
+ "stdout": "{\"status\": \"success\", \"api_key\": \"<REDACTED_SECRET:7a9c3d1e2f45>\"}"
}该差异对比展示了差分词元掩码如何隔离敏感凭据，同时保留 shell 命令结构和工具标准输出中的 JSON 内部语法。
许可证污染隔离
除操作凭据外，轨迹采集还会引入法律风险，可能影响下游策略的商业部署。自主编码智能体经常在外部开源仓库中工作，以解决 GitHub 问题、调试库或移植遗留代码库。在这一交互循环中，智能体将源文件、编译器输出和依赖树读入其观测上下文，偶尔会将例程或结构模式复制到其拟议动作中。
如果采集流水线不加区分地摄取从采用强 copyleft 条款的软件中收集的轨迹，例如采用 GNU 通用公共许可证（GPLv2、GPLv3）或 Affero 通用公共许可证（AGPLv3）的软件，并将这些轨迹用于监督微调（SFT）或直接偏好优化（DPO），则生成的模型权重可能面临有关衍生作品义务的法律质疑。尽管模型参数是否构成训练数据的衍生作品，其法律边界仍是司法讨论的热点，但生产系统工程要求严格的预防性隔离：企业模型必须保持清晰、可审计的法律来源脉络。
SPDX 标识符 系统软件包数据交换（SPDX）标准提供了用于声明软件许可证的机器可读语法（例如，SPDX-License-Identifier: Apache-2.0）。现代 AST 解析器提取这些文件头注释，以自动完成仓库级许可证分类。
为实施法律隔离，轨迹采集运行时会在实例化任何任务夹具之前，在仓库边界执行自动许可证识别。每个任务夹具都会通过自动许可证检测引擎进行扫描（例如，分析顶层 LICENSE 文件和源文件中的 SPDX 文件头），将目标代码库划分为四个治理级别之一，概述见 表 8。
| 治理级别 | 允许的许可证 | 轨迹摄取策略 | 允许的下游训练目标 |
|---|---|---|---|
| 第 1 级：宽松许可 | MIT, Apache 2.0, BSD-2/3-Clause, ISC | 不受限制地摄取；允许完整采集上下文和动作。 | 商业基础模型、对外提供的微调检查点、公开发布的智能体。 |
| 第 2 级：弱 copyleft | LGPL v2.1/v3, MPL 2.0, EPL 2.0 | 仅在修改被隔离于独立动态模块的情况下允许摄取。 | 企业内部商业模型；限制对外再分发模型权重。 |
| 第 3 级：强 copyleft | GPL v2/v3, AGPL v3 | 隔离轨迹；严格掩码处理观测和动作载荷。 | 仅允许用于明确采用互惠许可条款的研究模型。 |
| 第 4 级：专有 / 受限 | 非商业用途, CC-BY-NC, 无许可证 | 在摄取队列中严格阻止；立即丢弃并记录审计日志。 | 隔离；禁止任何模型训练。 |
当智能体在第 3 级或第 4 级仓库内执行时，采集流水线会启用 AST 级污点跟踪器。如果智能体的观测窗口捕获了 copyleft 文件中的原始源代码，则任何后续代码生成动作 \(a_t\)，只要与该观测具有较高的 n-gram 重叠度（\(n \ge 7\)）或 AST 子树同构性，都会被标记。流水线会在轨迹元数据封装中添加显式污染标记（license_taint: RECIPROCAL_COPYLEFT），将该轨迹记录分离到数据湖的隔离分区中。随后，企业训练运行框架可在编译时实施数据集排除过滤器，确保商业策略仅使用第 1 级宽松许可代码库进行训练。
Checkpoint 0.3: 评估恢复轨迹筛选与流水线卫生
在考察数据集划分和环境污染途径之前，请检验你对轨迹筛选的理解：
数据集划分卫生验证
在经典分布式系统中，与生产运行时共享可变存储的测试框架会制造可靠性的假象；在智能体机器学习系统中，与训练语料共享环境状态的验证集划分则会导致灾难性的策略过拟合，却伪装成具有泛化能力的智能。当一个非特权策略 \(\pi_\theta\) 在智能体运行时中执行时，其观测并非由孤立的自然语言句子构成，而是包含完整的操作系统状态：目录层次结构、编译器诊断信息、环境变量、依赖锁定信息、单元测试断言以及中间工具响应。如果工程团队采用标准的均匀随机采样，对收集到的各个会话进行采样以划分轨迹数据集，那么在同一软件仓库中生成的轨迹，或针对相同模拟后端生成的轨迹，必然会同时落入评估划分的两侧。
由此产生的失效模式十分严重。基于受污染轨迹微调的智能体，在使用源自其训练仓库的测试夹具进行评估时，任务完成率通常超过 80%。当部署到使用完全相同编程语言编写的陌生代码库时，其完成率却经常骤降至 15% 以下。该策略并未习得可泛化的探索性代码搜索、诊断信息解读或迭代补丁合成策略。相反，它记住的是独特的目录布局、项目特有的命名约定、确定性的测试框架副作用，以及既有的缺陷特征。
轨迹数据集的质量无法通过词元困惑度或宽松的留出划分来认证；只有在严格留出、按多个维度划分的环境夹具上，通过下游任务完成情况才能验证其质量。 要保证这种隔离，就必须沿智能体运行时的各个结构轴建立正式的隔离边界。
环境污染途径
经典统计学习假设样本从底层数据分布中独立同分布（\(i.i.d.\)）地抽取。在文本分类或语言建模中，数据泄漏主要表现为 \(n\) 元语法重叠、近重复文档碰撞，或未来词元影响过去预测的时间泄漏。标准去重流水线——例如 MinHash 局部敏感哈希（LSH）或后缀数组匹配——能够有效抑制这些表层文本重叠。
为什么表层去重对执行轨迹失效 在相同仓库中解决同一缺陷的两条轨迹，由于思维链暂存内容不同、工具参数顺序变化以及进程 ID 的非确定性，其词元重叠率可能低于 40%。然而，从结构上看，两者都依赖相同的环境不变量。经典 MinHash LSH 会将它们标记为不同轨迹，从而掩盖底层污染。
然而，在智能体执行过程中，数据泄漏是一种环境现象，而非词汇层面的现象 (Kaufman 等 2012年)。智能体轨迹 \(\tau = (s_0, a_0, o_0, a_1, o_1, \dots, a_T, o_T)\) 绑定于任务夹具 \(F = (S_0, \mathcal{M}_{\text{tool}}, P_{\text{task}})\)，其中 \(S_0\) 是初始环境快照，\(\mathcal{M}_{\text{tool}}\) 是工具清单，\(P_{\text{task}}\) 是自然语言问题描述。当评估夹具在以下四个不同运行时维度中的任意一个维度上泄漏了训练分布中的结构不变量时，就会发生污染：
- 代码库与仓库布局： 文件的层次树、模块导入图、构建脚本（
Makefile、CMakeLists.txt、pyproject.toml）以及提交历史。在训练期间接触过仓库 \(R\) 的策略，会以隐式参数记忆保留工具函数所在的位置、哪些文件包含核心业务逻辑，以及如何调用测试运行器。在 \(R\) 上接受评估时，它会完全跳过探索性发现过程，生成有针对性的文件系统操作，而这些操作是它无法在陌生系统上复现的。 - 模拟 API 的行为特性： 为使轨迹采集流水线免受速率限制或非确定性第三方 API 的影响而构建的合成工具后端和模拟 HTTP 服务。模拟实现通常采用简化的响应模式、省略暂时性 HTTP 错误，或返回确定性的边界情况载荷。接触过这些行为的策略会记住模拟实现的理想化契约，而它在评估中成功，仅仅是因为测试夹具共享了完全相同的人工桩实现。
- 诊断信息与错误特征： 执行工具输出的格式、回溯信息和警告模式。当 Python 运行时抛出异常或编译器报告错误时，具体措辞通常反映了确切的编译器版本、已安装的代码检查工具，或自定义日志封装。如果训练集与评估集都运行在相同的基础容器层上，并使用相同的工具二进制文件，策略就会对局部特有的编译器行为过拟合，而非学会解析标准的语言错误。
- 测试框架与验证产物： 分阶段验证器级联（\(V_1, V_2, V_3\)）所使用的具体断言、夹具和模拟输入。如果用于接纳轨迹进入训练集的单元测试，与评估框架共享辅助函数、测试数据生成器或断言结构，模型学到的就会是测试风格，而非底层规范。
# Observable Failure Trace: Environmental Memorization Collapse
# Task: Locate and patch null-pointer dereference in an unencountered repository
[Runtime Step 1] Action: ReadFile(path="src/utils/compat/string_helpers.py")
[Runtime Step 1] Result: ERROR - FileNotFoundError: [Errno 2] No such file or directory
[Runtime Step 2] Action: ReadFile(path="src/utils/compat/shims.py")
[Runtime Step 2] Result: ERROR - FileNotFoundError: [Errno 2] No such file or directory
[Runtime Step 3] Action: ReadFile(path="src/core/compat.py")
[Runtime Step 3] Result: ERROR - FileNotFoundError: [Errno 2] No such file or directory
[Runtime Step 4] Exhausted step budget (T_max=30). Task Failed.上述轨迹揭示了环境污染的实证特征。智能体没有发出探索性命令（如 find、git ls-files 或 grep）来探明陌生仓库的目录布局。相反，它自信地执行了凭空臆造的 ReadFile 操作，目标是特定的嵌套路径。这些确切路径存在于训练集中的一个仓库，该仓库解决过类似的字符串解析问题。由于训练语料奖励在未执行前置探索操作的情况下快速、未经提示地访问文件，策略将路径选择内化为一种无条件的反射式关联，导致其在面对未见过的目录布局时，执行能力完全陷入瘫痪。
分层划分规范
为消除环境泄漏，运行时工程师必须在轨迹收集期间严格执行分层划分规范。划分不应在收集树的叶节点上针对单条轨迹进行，而必须在定义执行上下文的根部结构边界处进行，详见 表 9。
| 划分层级 | 强制维持的不变量 | 防止的主要污染途径 | 验证审计机制 |
|---|---|---|---|
| 仓库族 | \(\mathcal{R}_{\text{train}} \cap \mathcal{R}_{\text{eval}} = \emptyset\) | 目录记忆、对构建脚本的熟悉程度、工具适配层 | AST 依赖图互不相交检查、Git 提交哈希谱系检查 |
| 工具模式族 | \(\mathcal{M}_{\text{tool}}^{\text{eval}} \not\subseteq \mathcal{M}_{\text{tool}}^{\text{train}}\) | RPC 参数签名记忆、硬编码的标志假设 | 结构模式差异比较、参数排列置换与重命名验证 |
| 问题领域 | \(\mathcal{D}_{\text{train}} \cap \mathcal{D}_{\text{eval}} = \emptyset\) | 算法原型记忆（例如，并发竞态与内存泄漏） | 语义分类体系标注、功能需求分类 |
| 运行时基础镜像 | \(\mathcal{I}_{\text{train}} \neq \mathcal{I}_{\text{eval}}\) | 依赖路径硬编码、对编译器版本诊断信息的过拟合 | 基础 OS 发行版差异（例如，Debian 与 Alpine、GCC 与 Clang） |
首要的隔离边界是仓库族。仓库族不仅包括单个 Git 仓库，还包括其所有上游分叉、下游衍生项目，以及由同一组织维护的关联库。许多软件组织维护着数十个共享共同架构基础的微服务：相同的日志框架、共享的配置加载器和统一的测试框架。将 repo-auth 放入训练集划分、将 repo-billing 放入评估集划分，会违反环境隔离原则。这两个服务共享该组织的内部库约定，从而为结构污染建立了一条未被检测到的通路。划分流水线必须构建组织关系与依赖关系的闭包图，确保共享传递性内部依赖的任意两个仓库都不会分处训练与评估边界两侧。
第二个边界是工具模式族。如果训练集中的每条轨迹都通过名为 ReadFile(path: str, offset: int, limit: int) 的工具与文件系统交互，那么在相同签名上接受评估的模型会显得熟练。然而，这种熟练程度可能极为脆弱。如果运行时将签名改为 Read(file: str, line_start: int, line_count: int)，或要求使用将搜索与检查合并到统一句柄中的 RPC 接口，过拟合的模型就会遭遇灾难性的工具调用模式失效。评估集划分必须有意预留不同的工具模式族：
\[\mathcal{M}_{\text{tool}}^{\text{eval}} = \{\mu'_1, \mu'_2, \dots, \mu'_k\} \quad \text{where} \quad \forall \mu' \in \mathcal{M}_{\text{tool}}^{\text{eval}}, \; \mu' \notin \mathcal{M}_{\text{tool}}^{\text{train}}\]
这些评估工具提供对底层 OS 或沙箱等效的功能访问，但要求模型在线完成工具语义对齐——读取系统提示中提供的模式定义、推断所需的参数类型，并动态构造有效的载荷结构，而非依赖记忆中的调用模板。
最后，流水线必须强制执行领域隔离。如果训练语料包含 5,000 条修复并发 Go 程序中竞态条件的轨迹，那么由更多 Go 竞态条件任务组成的评估集划分，评估的只是狭窄算法流形内的插值能力。为验证真正的操作泛化能力，评估划分必须按功能性问题领域隔离任务：数据库模式迁移、资源泄漏调试、网络协议反序列化和分布式同步。
数据混合的实证消融实验
在落实环境边界之后，我们如何确认采集到的轨迹语料确实提升了策略性能？在经典预训练中，数据集通常依据留出文本上的损失收敛速率进行排序。在智能体系统中，词元困惑度与任务执行成功率的相关性较弱。策略在工具调用参数上可能表现出更低的交叉熵损失，却因不可恢复的累积错误而无法完成多步骤任务。
因此，必须通过实证混合比例消融实验来评估轨迹数据集的质量：在固定的训练 token 预算下，以严格留出的环境测试夹具上的下游任务完成率作为衡量指标。
考虑三种候选训练混合方案，每种方案均按相同的 \(10^9\) token 计算预算进行校准：
- 未经筛选的轨迹采样：仅凭通过终态验证器（\(V_3\)）就予以接纳的原始轨迹，其中包含任意的探索游走、冗余操作和低效的工具调用循环。
- 仅含无失误示范：每一步均为最优操作的轨迹，由高能力前沿模型或人类专家生成，执行最短路径解法且不出现失误。
- 增强恢复示范的混合方案：经过筛选和平衡的组合，由 70% 的无失误轨迹和 30% 的结构化恢复示范组成（通过 节 4 中确立的偏离与检查点回滚技术合成）。
图 6 展示了这一权衡在三种不同基准任务形态下的定量变化：
- 在单轮单元任务（绿色曲线）上，无失误示范占优；恢复示范占比超过 \(20\%\) 后，会因鼓励不必要的探索性检查而略微降低性能（从 \(83.4\%\) 降至 \(64.1\%\)，此时恢复示范占比为 \(60\%\)）。
- 在受扰动的环境故障（红色虚线）上，运行时会有意注入权限拒绝、瞬时网络中断和模式变更，未使用恢复示范训练的策略几乎完全失败（通过率为 \(15.2\%\)，此时恢复示范占比为 \(0\%\)）。随着恢复示范比例向 \(60\%\) 增加，恢复能力单调提升至 \(64.2\%\)。
- 在贴近实际的复杂多步代码仓库任务（蓝色曲线）上，性能呈现倒 U 形的帕累托前沿。在全部采用无失误示范的基线下（恢复示范占比为 \(0\%\)），成功率停留在 \(41.0\%\) 的低水平，因为非受迫性错误会引发失控的累积漂移。引入恢复轨迹后，性能迅速提升，通过率达到 \(73.2\%\) 的实证峰值，此时恰好对应 \(30\%\) 的恢复示范与 \(70\%\) 的无失误示范这一平衡比例。超过这一转折点后，过度侧重恢复轨迹会削弱向前执行的动能，导致模型对常规操作进行过度诊断，使成功率降至 \(50.0\%\)，此时恢复示范占比为 \(60\%\)。因此，\(30\%\) 的恢复示范比例提供了最优的运行平衡。
当仅以无失误路径训练的智能体在未见过的代码仓库中遇到意外的工具错误或含糊的目录布局时，它便会偏离已知的状态分布。由于训练数据中完全没有错误恢复示例，模型会立即发生策略崩溃，反复输出同一个失败操作，或过早终止。相应地，增强恢复示范的混合方案能够培养行为上的恢复能力。通过学习关注诊断反馈、从死路中退回，以及在初始查询返回空集时改用其他搜索工具，策略能够在完全未见过的代码仓库测试夹具上，针对长时程任务维持较高的任务完成率。
这种消融方法直接揭示了支配轨迹采集的工程权衡：原始采集量是虚荣指标；决定下游部署成功与否的唯一指标是可用产出率。
自动化飞轮生成的每条轨迹都会产生生成成本（轨迹采样过程中的 LLM 推理计算）、验证成本（microVM 生命周期开销、测试套件的 CPU 执行、代码检查器检查）以及净化成本（AST 扫描、正则表达式脱敏、密钥熵过滤）。如果已验证轨迹中有相当一部分随后在数据划分洁净性验证中因环境污染而被判定为不合格，那么每个训练 token 的实际资金与计算成本就会非线性上升。
我们在 \(C_{\text{usable}}\) 处将每条可用轨迹的经济成本形式化，并在 公式 4 中给出：
\[C_{\text{usable}} = \frac{C_{\text{generation}} + C_{\text{verification}} + C_{\text{sanitization}}}{N_{\text{accepted}} \cdot (1 - \text{LeakageRate})} \tag{4}\]
其中，\(N_{\text{accepted}}\) 表示成功通过验证器级联的候选轨迹的原始数量，\(\text{LeakageRate} \in [0, 1)\) 表示为维持训练集与评估集之间严格的环境隔离，必须从已接受轨迹中清除的比例。
如果一个组织运行的采集流水线管理不严，泄漏率达到 30%——即其采集的任务中有 30% 意外重复使用了为评估预留的代码仓库、模式或测试夹具——分母就会缩小，从而大幅推高每个有效训练词元的摊销单位成本。
粗略估算 0.6: 受污染产出的经济成本
流水线参数：
生成计算： 模型推理成本为 \(\$0.75\) per million tokens (\(10^6\) token）。每次轨迹采样尝试平均消耗 40,000 个 token（涵盖系统提示、上下文历史和工具输出）。
每个任务的采样成本： 生成器针对每个任务夹具开展 \(K = 5\) 次并行轨迹采样尝试。因此，每个任务消耗： \[C_{\text{generation}} = 5 \times (40{,}000 \times 10^{-6} \times \$0.75) = 5 \times \$0.030 = \$0.150\]
验证成本： 每次到达终止状态的生成尝试都会在临时 microVM 沙箱中执行，并经过三级验证器级联（\(V_1, V_2, V_3\)）。每条受检轨迹的 microVM 分配与执行成本平均为 \(\$0.020\)。进行 5 次尝试时： \[C_{\text{verification}} = 5 \times \$0.020 = \$0.100\]
净化计算： 加密哈希计算、AST 解析和秘密信息熵过滤的成本为每次尝试 \(\$0.005\)： \[C_{\text{sanitization}} = 5 \times \$0.005 = \$0.025\]
每个任务的总成本： \[C_{\text{task}} = C_{\text{generation}} + C_{\text{verification}} + C_{\text{sanitization}} = \$0.150 + \$0.100 + \$0.025 = \$0.275\]
产出与接收： 每尝试 100 个任务，验证器级联就能在其中 20 个任务上成功识别出至少一条有效轨迹（每 100 个任务 \(N_{\text{accepted}} = 20\)）。 审计前，每条已接收轨迹的名义成本为： \[C_{\text{nominal}} = \frac{100 \times \$0.275}{20} = \frac{\$27.50}{20} = \$1.375 \text{ per trajectory}\]
比较：
形态 A（宽松划分）： 团队在轨迹层面随机划分任务。采集后的数据划分卫生审计发现，在 20 条已接收轨迹中，有 5 条来自与留出评估套件重叠的代码仓库族和工具模式（\(\text{LeakageRate} = 0.25\)）。这 5 条轨迹必须丢弃，以防止评估污染。 \[C_{\text{usable}}^{(\text{A})} = \frac{\$27.50}{20 \cdot (1 - 0.25)} = \frac{\$27.50}{15} = \$1.833 \text{ per usable trajectory}\]
形态 B（严格分层划分）： 团队在任务摄取前，严格按代码库和模式族进行划分（\(\text{LeakageRate} = 0.00\)）。全部 20 条已接收轨迹均可合规地用于各数据划分。 \[C_{\text{usable}}^{(\text{B})} = \frac{\$27.50}{20 \cdot (1 - 0.00)} = \$1.375 \text{ per usable trajectory}\]
结论： 25% 的泄漏率会使训练数据的实际单位成本增加： \[\frac{\$1.833 - \$1.375}{\$1.375} = +33.3\%\] 对于目标为 50,000 条可用轨迹的生产运行，形态 A 仅因下游数据划分卫生清理，就会浪费 $22,917，这些损失来自被浪费的推理与计算周期。严格的前置划分是经济上的必要条件，而不只是学术上的形式要求。
任务夹具定义可复现的沙箱初始状态；分阶段验证器级联过滤貌似有效的完成结果；恢复示范整理赋予行为韧性；不可变的来源追踪保障法律与运营层面的完整性；分层数据划分卫生则防止产生泛化能力的假象。然而，在工业级智能体工程环境中，这些架构机制不能作为彼此脱节的手动脚本或临时诊断流程运行。必须将它们整合成一个自动化、持续执行且能够自我平衡的采集运行框架，将原始、非确定性的智能体执行转化为高价值的策略适配资产。我们如何将这些分散的组件综合为统一、版本化、端到端的数据采集架构？
端到端轨迹采集的综合构建
如果运行一个由无特权智能体运行时组成的分布式集群，却没有自动化且设有严格准入关卡的采集运行框架，就会立即引发系统故障：流水线要么淹没在未经验证、规模达数 TB 的退化交互日志泥潭中，悄然污染下游训练语料；要么在人工检查瓶颈下崩溃，使策略优化缺乏多样化的执行信号。当自主智能体与真实开发环境交互——调用 shell 命令、编译代码、阅读文档和编辑源文件——时，生成的绝大多数轨迹都不可用。智能体会陷入无限循环，生成语法无效的工具调用，通过断言显然恒真的命题来钻静态测试套件的空子，或将生产环境 API 令牌直接泄漏到交互上下文中。
工业级轨迹整理需要将可复现测试夹具的合成、分阶段验证、恢复轨迹整理和脱敏整合为统一的版本化数据流水线，并依据实测产出率和任务迁移指标进行评估。 如果工程组织将轨迹采集视为一组非正式的离线 shell 脚本或临时日志抓取程序，所得数据集就不可避免地出现 Sculley 等 (2015年) 所归纳的典型失效模式：流水线丛林、隐蔽的数据依赖，以及将智能体的历史错误放大而非消除的反馈循环。借鉴科学数据存储库的核心设计原则，具体包括一次写入的不可变存储、持续的血缘审计和自动化数据质量验证，工业级采集流水线必须作为闭环运行时编译器运作。它从智能体监督器的预写日志（WAL）和智能体控制块（ACB）中摄取非确定性的原始执行日志，将每条候选轨迹提交至逐级增强的物理不变量检查序列，清除敏感的运维数据，并输出经密码学封存、数据划分相互隔离的训练语料。
如 图 7 所综合展示，工业级采集架构将六阶段摄取生命周期（上面板）与其实测产出率—质量性能曲线（下面板）统一起来：
- 摄取生命周期（上图）：来自监督器预写日志（阶段 1）的原始运行时轨迹，由多层验证器（阶段 2）把关，以剔除格式错误的语法和钻测试空子的行为。通过验证的轨迹被划分为行为原型（阶段 3，目标是 \(70\%\) 无瑕疵轨迹和 \(30\%\) 恢复轨迹，同时纳入挖掘出的困难负样本），经过三遍 AST 脱敏（阶段 4）以消除凭据泄露（\(\Lambda_{\text{leak}} = 0.00\%\)），使用 HMAC Merkle 摘要封存（阶段 5），并分配至仓库家族互不重叠的数据划分（阶段 6），随后送入闭环再训练飞轮。
- 实测流水线留存率（下图）：配套的定量系统曲线对比了获准纳入的语料产出率 \(\eta\) 与下游任务通过率 \(P_{\text{task}}\)，涵盖 表 11 中分析的五种流水线配置。直接使用未过滤的生产日志训练（即未过滤日志的风险）虽然保留了 \(100.0\%\) 的产出率，却因自回归模仿本可避免的循环而将模型能力削弱至不可接受的 \(11.2\%\) 通过率。引入静态过滤（\(V_1\)）可剔除语法缺陷，将产出率降至 \(58.2\%\)，并将通过率略微提高至 \(18.6\%\)。启用机械式 microVM 沙箱（\(V_1 \to V_2\)）会大幅剔除测试作弊轨迹和超时循环，将产出率降至 \(17.4\%\)，同时将通过率提升至 \(27.4\%\)。决定性突破出现在恢复轨迹挖掘（\(V_3\)）阶段，自我修复轨迹带来了 \(+9.4\%\) 的性能拐点（\(36.8\%\) 的通过率，对应 \(14.1\%\) 的产出率）。最后，全面整合的采集器实现了下游泛化能力的峰值（\(42.5\%\) 的通过率），而严格筛选后的获准纳入产出率为 \(12.8\%\)，这表明，决定智能体飞轮运转速度的是数据质量和结构多样性，而非原始数据量。
摄取生命周期：从运行时 WAL 到划分后的语料
智能体执行轨迹的生命周期跨越六个独立的流水线阶段，从原始执行遥测数据转化为不可变、版本化的训练产物。每个阶段都充当具有故障即停止语义的不变量关卡：任何未通过验证检查或违反结构约束的轨迹都会立即被拒绝，或转入诊断隔离队列，从而防止损坏的记录消耗下游计算资源。
阶段 1：原始执行捕获
采集流水线始于智能体运行时监督器。如宿主架构中所述，无特权的智能体模型在不具备任何隐式权限的条件下执行，仅通过受中介机制管控的远程过程调用（RPC）与环境交互。每次提示组装、每个解码输出词元、每次工具调用、每条标准输出流以及每次沙箱文件系统修改，都会按顺序追加到由智能体控制块（ACB）支撑的仅追加预写日志中。
当一个回合终止时——无论是由于显式完成任务、步数耗尽（\(T \ge T_{\max}\)）、不可恢复的沙箱故障，还是监督器介入——运行时都会将该会话打包为原始轨迹载荷 \(\tau_{\text{raw}}\)。该封装包含：
初始任务规范 \(P_{\text{task}}\) 及输入上下文。
初始环境快照标识符 \(S_0\)（例如，按内容寻址的容器镜像哈希或 microVM 快照 ID）。
执行期间暴露的工具接口模式清单 \(\mathcal{M}_{\text{tool}}\)。
按时间顺序排列的完整状态、动作、观测和运行时时间戳序列： \[\tau_{\text{raw}} = \left( s_0, a_0, o_0, t_0, s_1, a_1, o_1, t_1, \dots, s_T, a_T, o_T, t_T \right)\]
在临时写时复制工作区内生成的最终文件系统差异 \(\Delta_{\text{fs}}\)。
运行时将 \(\tau_{\text{raw}}\) 通过高吞吐量消息队列（例如 Apache Kafka 或 gRPC 流式缓冲区）以流式方式传输至解耦的流水线摄取工作进程，确保沙箱销毁和宿主智能体执行始终不会因数据处理反压而阻塞。
阶段 2：分阶段验证级联
原始追踪记录进入逐级加强的验证级联，旨在以尽可能低的计算成本过滤掉不可用的轨迹。如验证器级联的经济性分析所形式化阐述的那样，在运行中的 microVM 内，使用完整的集成测试套件或动态性质测试评估每条轨迹，计算成本高到难以承受。流水线采用三级筛选机制：
- 阶段 \(V_1\)（静态模式与语法验证）： 完全在 CPU 内存中运行、延迟低于一毫秒（\(c_1 \approx 0.5\text{ ms}\)）的 \(V_1\) 解析原始交互记录，确保其格式正确。它验证每个模型动作是否遵循 \(\mathcal{M}_{\text{tool}}\) 的 JSON 模式，验证文件补丁是否符合统一差异格式语法，并检查代码修改能否在无语法错误的情况下编译或解析为抽象语法树（AST）。包含格式错误的词元、幻觉生成的工具标识符或截断控制块的追踪记录会立即被丢弃。
- 阶段 \(V_2\)（封闭沙箱执行）： 通过 \(V_1\) 的追踪记录进入容器化沙箱（\(c_2 \approx 5\text{–}30\text{ s}\)），在其中将最终工作区差异 \(\Delta_{\text{fs}}\) 应用于未改动的初始测试基境 \(S_0\)。验证器运行已有的单元测试、代码规范检查器和类型检查器。关键在于，验证器会验证差异的安全性：智能体不得修改测试基境、禁用代码规范检查规则，或添加使断言轻易通过的代码。
- 阶段 \(V_3\)（动态测试不稳定性与变异审计）： 为消除非确定性测试套件产生的假阳性，\(V_3\) 使用 \(K\) 个独立种子（\(K \ge 3\)），在 CPU 限速和网络隔离条件下执行测试套件。此外，还会注入语义性质测试和变异检查，以确保智能体的补丁确实解决了根本问题，而非过拟合于表层断言。
阶段 3：行为角色标注
通过验证器级联的轨迹并非都具有相同的教学用途。仅使用无瑕、直接执行路径进行训练的流水线，会产生脆弱的策略；这些策略在遇到第一个意外工具错误或环境异常时，就会严重偏离正常执行。反之，不加区分地使用冗长曲折的路径进行训练，则会让模型养成低效、循环往复的探索习惯。
合成引擎将接纳的轨迹划分为三种结构性行为类别，详见 表 10：
| 行为类别 | 结构特征 | 主要策略用途 | 流水线接纳条件 |
|---|---|---|---|
| 无瑕专家路径（\(\tau \in \mathcal{T}_{\text{expert}}\)） | 单调推进；零工具错误；词元长度最小（\(T \le 1.2 \cdot T_{\text{optimal}}\)）。 | 最大化向前执行效率与直接任务求解能力。 | \(\text{Passed}(V_3) \land \forall t, \text{Error}(o_t) = \emptyset\)。 |
| 恢复路径（\(\tau \in \mathcal{T}_{\text{recovery}}\)） | 非单调；包含环境故障（\(o_{t_{\text{div}}} = \text{Error}\)），随后进行诊断、实施修正补丁，并最终完成验证。 | 教授错误定位、诊断性重规划与自我修复。 | \(\text{Passed}(V_3) \land \exists t_{\text{div}}, \text{Error}(o_{t_{\text{div}}}) \land \text{Rectified}(\Delta_{\text{fs}})\)。 |
| 困难负例路径（\(\tau \in \mathcal{T}_{\text{negative}}\)） | 置信度高；语法无瑕；未通过语义验收或违反安全不变量。 | 校准偏好模型；抑制欺骗性对齐与奖励投机。 | \(\text{Passed}(V_1) \land \neg \text{Passed}(V_2) \land \text{TrivialExploit}(\Delta_{\text{fs}})\)。 |
对于恢复轨迹，流水线会标记智能体偏离正常执行并进入错误状态的偏离索引 \(t_{\text{div}}\)，以及智能体识别根因并开始采取修正措施的恢复拐点 \(t_{\text{rec}}\)。这些元数据使下游整理阶段能够提取专门聚焦于错误到恢复这一转变的目标子轨迹。
# Empirical verification failure trace: detecting test-suite tampering
def verify_diff_integrity(patch_diff: str, fixture_manifest: dict) -> bool:
"""Rejects patches that alter validation infrastructure or disable assertions."""
for line in patch_diff.splitlines():
# Detect modification to sealed test suites or CI configurations
if line.startswith("--- a/") or line.startswith("+++ b/"):
filepath = line[6:].strip()
if filepath in fixture_manifest["protected_test_files"]:
return False # Test tampering detected: agent modified ground truth
# Detect lazy assertion suppression in modified application code
if line.startswith("+") and any(cheat in line for cheat in [
"pytest.mark.skip", "pragma: no cover", "unittest.skip", "assert True"
]):
return False # Assertion bypass detected
return True阶段 4：多轮脱敏
生产环境执行日志包含有害的运维产物：临时 API 密钥、授权令牌、数据库连接字符串、内部绝对路径、员工标识符以及专有基础设施名称。简单的字符串替换或基于正则表达式的掩码处理往往会破坏代码文件的语法，或使 BPE 词元对齐失效，导致轨迹无法用于训练。
脱敏工作进程执行确定性的多轮脱敏协议：
- 确定性高熵词元扫描： 使用香农熵阈值，结合已知的秘密信息模式（例如云凭证的标准正则表达式前缀、SSH 私钥头部、持有者令牌），扫描所有字符串字段。检测到的秘密信息会被录入每条轨迹各自的替换符号表 \(\mathbf{\Sigma}_{\text{secret}}\)。
- 保留上下文的一致替换： 将每个敏感字面量 \(s_k \in \mathbf{\Sigma}_{\text{secret}}\) 替换为结构有效、语义中性的虚拟字面量，同时保留底层语法。AWS 访问密钥（
AKIAIOSFODNN7EXAMPLE）被映射为符合 RFC 的合成令牌（AKIA00000000EXAMPLE000），确保下游格式验证器不会崩溃。关键在于，替换在轨迹 \(\tau\) 的所有步骤中保持全局一致，使变量引用与其声明相匹配。 - 保留 AST 的 JSON 与代码规范化： 将所有空白字符、JSON 键和代码块规范化为标准形式（例如标准缩进、排序后的字典键）。这会消除宿主运行时引入的偶然、非确定性格式特征，确保策略不会耗费建模能力去学习短暂的空白字符产物。
阶段 5：加密溯源标记
为满足 Stonebraker 对科学数据溯源不可变性的要求，流水线为每条已脱敏轨迹构建一棵 Merkle 血缘树。缺乏严格的溯源信息，就无法调试下游回归异常：当微调后的模型突然出现退化的工具调用循环时，工程师必须能够将每个训练样本追溯到生成它时使用的确切编译器标志、运行时提示词模板、工具清单以及基础模型检查点。
溯源引擎计算复合 SHA-256 血缘哈希： \[H_{\text{lineage}} = \text{SHA-256}\left( H_{\text{trajectory}} \,\|\, \Theta_{\text{base}} \,\|\, S_0 \,\|\, \mathcal{M}_{\text{tool}} \,\|\, K_{\text{pipe}} \right)\] 其中，\(H_{\text{trajectory}}\) 是已脱敏交互序列的内容哈希，\(\Theta_{\text{base}}\) 标识生成模型的权重和温度超参数，\(S_0\) 是不可变的容器 rootfs 摘要，\(\mathcal{M}_{\text{tool}}\) 是序列化后的工具规范，\(K_{\text{pipe}}\) 表示采集流水线自身的版本提交。轨迹被写入以 \(H_{\text{lineage}}\) 为索引的不可变对象存储（例如启用 Object Lock 的 S3 或只读 blob 存储），并附带不可变的元数据清单。
阶段 6：按代码仓库家族划分数据集
最后一个阶段将已加标记的轨迹分配到一个评估数据划分中：训练集、验证集或留出测试集。标准的随机划分（\(k\) 折划分或在轨迹之间进行均匀采样）对于智能体系统完全不可接受。如果一个智能体针对 django/django 代码仓库执行三个不同任务，将其中两个任务分配到训练集、一个任务分配到测试集，就会造成严重的数据泄漏：模型会记住代码仓库的目录布局、辅助函数名称、测试惯例和数据库模拟结构。
流水线强制执行代码仓库家族互斥划分。源自同一软件项目、该项目在组织内的分叉版本及其紧密耦合的内部依赖项的所有任务夹具，均作为一个不可分割的整体分配到同一分区。令 \(\mathcal{F}\) 表示所有任务夹具的集合，令 \(\mathcal{G}_{\text{repo}}(f)\) 将夹具映射到其根代码库家族。划分函数必须满足： \[\forall f_i \in \mathcal{D}_{\text{train}}, \forall f_j \in \mathcal{D}_{\text{test}} \implies \mathcal{G}_{\text{repo}}(f_i) \cap \mathcal{G}_{\text{repo}}(f_j) = \emptyset\] 此外，还要分析传递依赖图，以保证共享的内部库工具不会跨越数据划分边界。
流水线吞吐量的经济性
运营轨迹采集工厂需要持续监控遥测数据。由于轨迹生成本质上是随机的，提示词模板、工具运行时响应延迟或底层模型权重的细微变化，都可能导致流水线产出率大幅波动。
关键不变量：流水线筛选机制 如果验证器级联的筛选能力低下或不稳定性很高，那么再高的原始生成速率也毫无用处。流水线必须将产出率 \(\eta\) 作为主要成本驱动因素进行衡量。
形式化数学指标
我们定义四项主要系统指标，用于管控采集流水线：
轨迹产出率（\(\eta\)）： 通过验证、完成全面脱敏并被接受的轨迹数量与运行时启动的原始回合总数之比： \[\eta = \frac{N_{\text{accepted}}}{N_{\text{generated}}} = \prod_{i=1}^{M} p(V_i \mid V_{<i})\] 其中，\(p(V_i \mid V_{<i})\) 是在轨迹通过所有前序阶段的条件下，验证阶段 \(V_i\) 的条件通过率。在生产软件工程环境中，典型产出率介于 \(\eta = 0.05\) 和 \(\eta = 0.20\) 之间。异常高的产出率（\(\eta > 0.50\)）几乎总是表明验证器过于宽松或存在测试作弊。
不稳定性比率（\(R_{\text{flake}}\)）： 相同的工作区补丁在独立评估运行中产生不同验证结果的频率： \[R_{\text{flake}} = \frac{N_{\text{inconsistent}}}{N_{\text{verified}}} = \frac{\sum_{j=1}^{N} \mathbb{I}\left( 0 < \sum_{k=1}^K V_{3}(\Delta_{\text{fs}}^{(j)}, \text{seed}_k) < K \right)}{N}\] 当 \(R_{\text{flake}} > 0.02\)（大于 2%）时，流水线会停止自动摄取，因为非确定性测试会让无效轨迹污染训练语料，同时丢弃有效的恢复路径。
脱敏覆盖率与泄漏界限（\(\Lambda_{\text{leak}}\)）： 未被掩码处理的敏感词元泄漏到输出存储的经验比率，通过离线金丝雀插入流程测量： \[\Lambda_{\text{leak}} = \frac{C_{\text{detected\_canaries}}}{C_{\text{injected\_canaries}}}\] 健康的流水线针对注入原始执行流的合成金丝雀保持 \(\Lambda_{\text{leak}} \equiv 0\)。
验证计算倍数（\(Q_{\text{verify}}\)）： 验证、沙箱隔离和脱敏所消耗的 CPU 与 GPU 计算周期总量，相对于初始智能体轨迹采样期间自回归词元生成所消耗的计算量的比值： \[Q_{\text{verify}} = \frac{\text{FLOPs}_{\text{verification}}}{\text{FLOPs}_{\text{generation}}}\] 由于验证主要依赖快速的 CPU microVM 和静态分析，而非密集张量加速器，在总硬件成本方面保持 \(Q_{\text{verify}} < 0.10\)，可确保数据整理不会占据基础设施预算的主要部分。
粗略估算 0.7: 工业级轨迹采集器的规模配置
工作负载参数如下：
- 每个智能体在每个回合中平均执行 \(T = 20\) 轮交互。
- 每轮交互生成 \(512\) 个输出词元，并接收平均长度为 \(16,384\) 个词元的上下文。
- 每个回合的总生成时间：\(60\text{ seconds}\) 的 GPU 活跃计算时间。
- 集群每个 24 小时日启动 \(N_{\text{generated}} = 50,000\) 条原始轨迹。
- 级联过滤器的通过率：\(V_1\)（模式/AST）的通过率为 \(p_1 = 0.60\)；\(V_2\)（封闭环境单元测试）的通过率为 \(p_2 = 0.30\)；\(V_3\)（不稳定性/防篡改）的通过率为 \(p_3 = 0.80\)。
- 清理与来源信息标记会因无法脱敏的二进制数据块或元数据损坏，额外剔除 \(2\%\) 的轨迹记录（\(p_4 = 0.98\)）。
- 验证的计算成本：\(V_1\) 耗时 \(0.001\text{ CPU-hr}\)；\(V_2\) 在 microVM 中耗时 \(0.05\text{ CPU-hr}\)；\(V_3\) 耗时 \(0.15\text{ CPU-hr}\)（3 次并行运行）。
计算：
- 总体轨迹产出率 \(\eta\) 和每日接纳的轨迹总数 \(N_{\text{accepted}}\)。
- 为执行验证级联且不积压处理队列，每日所需的 CPU 工作节点池规模。
- 假设云 CPU 工作节点的费用为 \(\$0.04\text{ per CPU-hour}\) compared to GPU generation costs at \(\$2.50\text{ per GPU-hour}\)，计算每条接纳轨迹的摊销验证 CPU 成本。
解答：
步骤 1：计算轨迹产出率和每日产量 \[\eta = p_1 \cdot p_2 \cdot p_3 \cdot p_4 = 0.60 \cdot 0.30 \cdot 0.80 \cdot 0.98 = 0.14112 \approx 14.11\%\] \[N_{\text{accepted}} = N_{\text{generated}} \cdot \eta = 50,000 \cdot 0.14112 = 7,056\text{ accepted trajectories/day}\]
步骤 2：确定验证所需的 CPU 计算规模 轨迹记录依次进入各阶段，因此每个阶段只处理上一阶段通过筛选的记录：
阶段 \(V_1\) 处理全部 \(50,000\) 条轨迹记录： \[\text{Work}_{V_1} = 50,000 \cdot 0.001\text{ CPU-hr} = 50\text{ CPU-hours}\]
阶段 \(V_2\) 处理 \(50,000 \cdot p_1 = 30,000\) 条轨迹记录： \[\text{Work}_{V_2} = 30,000 \cdot 0.05\text{ CPU-hr} = 1,500\text{ CPU-hours}\]
阶段 \(V_3\) 处理 \(30,000 \cdot p_2 = 9,000\) 条轨迹记录： \[\text{Work}_{V_3} = 9,000 \cdot 0.15\text{ CPU-hr} = 1,350\text{ CPU-hours}\]
清理与元数据标记处理 \(9,000 \cdot p_3 = 7,200\) 条轨迹记录，其 CPU 成本可忽略不计（\(\approx 0.002\text{ CPU-hr}\)）： \[\text{Work}_{\text{san}} = 7,200 \cdot 0.002 = 14.4\text{ CPU-hours}\]
每日验证所需的 CPU 工作总量： \[\text{Work}_{\text{total}} = 50 + 1,500 + 1,350 + 14.4 = 2,914.4\text{ CPU-hours/day}\] 要在 24 小时内处理完这些工作负载且不造成队列积压： \[\text{Workers}_{\text{required}} = \frac{2,914.4\text{ CPU-hours}}{24\text{ hours}} \approx 121.4 \implies 122\text{ dedicated CPU cores}\]
步骤 3：经济成本比较
每日验证 CPU 成本： \[\text{Cost}_{\text{verify}} = 2,914.4\text{ CPU-hr} \cdot \$0.04 = \$116.58/\text{day}\] \[\text{Cost}_{\text{verify per accepted trace}} = \frac{\$116.58}{7,056} \approx \$0.0165\text{ (1.65 cents)}\]
每日 GPU 生成成本： 每个回合需要 \(60\text{ GPU-seconds} = \frac{1}{60}\text{ GPU-hours}\)。 \[\text{Total GPU Work} = 50,000 \cdot \frac{1}{60} \approx 833.33\text{ GPU-hours}\] \[\text{Cost}_{\text{generation}} = 833.33\text{ GPU-hr} \cdot \$2.50 = \$2,083.33/\text{day}\] \[\text{Cost}_{\text{generation per accepted trace}} = \frac{\$2,083.33}{7,056} \approx \$0.2952\text{ (29.5 cents)}\]
每条经过清理、接纳并验证的轨迹的总成本： \[\text{Cost}_{\text{total}} = \$0.2952 + \$0.0165 = \$0.3117\] 请注意，验证仅占流水线总支出的 5.3 percent，却剔除了 85.9 percent 的有缺陷、误导性或有害的训练数据。
数据集质量评分卡
轨迹采集流水线的最终验证并不发生在数据流水线内部。严格遵循 Saltzer、Reed 和 Clark 的端到端论证（1984），流水线内部指标——如语法通过率、代码检查器评分和词元压缩比——仅仅是中间代理指标。真正的不变量是下游任务完成情况：在整理后的语料库上训练一个无特权的基础智能体，是否能可衡量地提高其在严格留出、此前未见过的任务环境中的自主问题求解通过率？
在将数百万词元的精选轨迹投入大规模训练之前，工程团队会依据标准化的数据集质量评分卡评估候选数据集快照。
| 流水线配置 | 接纳产出率 (\(\eta\)) | 脱敏泄漏率 (\(\Lambda_{\text{leak}}\)) | 不稳定性指数 (\(R_{\text{flake}}\)) | 下游任务通过率 (\(P_{\text{task}}\)) | 每条干净轨迹的成本 |
|---|---|---|---|---|---|
| 基线：未过滤日志 | \(100.0\%\) | \(14.2\%\) | \(18.4\%\) | \(11.2\%\)（性能退化） | \(\$0.04\) |
| 仅静态过滤 (\(V_1\)) | \(58.2\%\) | \(3.1\%\) | \(17.9\%\) | \(18.6\%\) | \(\$0.08\) |
| 机械式级联 (\(V_1 \to V_2\)) | \(17.4\%\) | \(0.8\%\) | \(6.2\%\) | \(27.4\%\) | \(\$0.26\) |
| 级联 + 恢复轨迹挖掘 (\(V_1 \to V_3\)) | \(14.1\%\) | \(< 0.01\%\) | \(0.4\%\) | \(36.8\%\) | \(\$0.31\) |
| 综合采集器（完整流水线） | \(12.8\%\) | \(\mathbf{0.00\%}\) | \(\mathbf{0.1\%}\) | \(\mathbf{42.5\%}\) | \(\$0.34\) |
数据集质量评分卡中的实证结果表明，原始数据量与下游智能体能力之间存在反向关系。使用未过滤的原始交互日志进行训练会产生灾难性的结果：智能体的下游通过率降至 \(11.2\%\)（低于未经调优的基础模型的零样本基线 \(14.5\%\)）。未经清洗的语料将数千次工具语法使用失败、无限循环和 shell 超时重试直接注入自回归前缀，使模型学会预期并重复这些失效模式。
静态过滤器（\(V_1\)）会移除语法错误，但语料仍易受测试套件投机行为和不稳定断言的影响。只有将完整的分阶段级联与行为恢复轨迹挖掘、严格的数据划分隔离整合起来，下游智能体才能达到最先进的任务迁移水平（\(42.5\%\)）。注入精选恢复轨迹尤为关键：使用完整流水线训练的智能体不仅会避免错误；当一个全新的留出环境中不可避免地出现环境错误时，它们还会展现出第 3 阶段所捕获并标注的精确自愈行为。
通过将轨迹采集视为经过工程设计、可验证的系统编译器，而非附带的数据收集杂务，宿主架构建立起了一个可自我维持的数据飞轮。原始执行轨迹被转化为干净、可通过密码学方法审计且产出率高的训练分布，为行为适应提供了必要基础。
然而，即使数据采集架构在机械机制和密码学层面都经过完全严谨的工程设计，系统设计者仍经常陷入隐蔽的概念陷阱。在构建好数据引擎之后，我们必须审视那些普遍存在、会削弱生产环境中智能体数据飞轮的谬误。
谬误与陷阱
构建自动化轨迹采集流水线，意味着必须直面无特权基础模型与可变环境交互时的非确定性失效模式。由于智能体运行时每小时会在分布式 microVM 沙箱中产生数十万个交互词元，系统设计者常常将记录下来的海量执行轨迹误认为高质量的策略学习信号。轨迹精选的根本挑战在于所采集状态的语义有效性、环境隔离和行为分布，而非存储接收端的吞吐量。以下谬误与陷阱揭示了团队在缺乏严格系统保护措施的情况下构建数据飞轮时出现的隐蔽失效模式。
谬误： 收集更多轨迹会自动带来更优的智能体策略。
在经典离线预训练中，规模定律能够可靠地预测：向自回归 Transformer 输入更大规模的文本词元语料，会降低其在更广泛语言分布上的验证损失。系统团队往往不加审视地套用这一类比，认为智能体数据飞轮只需要一个不限流的数据摄取入口：将预发布环境、生产遥测和合成自博弈工作进程中的每条原始轨迹 \(\tau_{\text{raw}}\) 都采集到数据湖中，将其序列化为词元序列，再对策略 \(\pi_\theta\) 进行微调。这一做法隐含的假设是，经验数据规模的扩大必然会消除单次执行异常的影响，从而渐近地实现自主能力的自我提升。
在闭环智能体系统中，这一信念从根本上就是错误的。扩大未经精选的轨迹规模，会通过三种不同的失效机制引发严重的策略退化：
- 退化循环上的模式坍塌： 当不受约束的模型遇到含糊的任务或脆弱的环境时，其失败分布并非均匀分布的噪声。相反，非特权模型会系统性地将概率质量集中在病态吸引子上：重复列出目录、循环执行 grep 命令、以相同的语义参数反复查询，以及来回变更工具参数。大规模摄取原始执行转储，会使训练分布过度偏向这些低熵、重复的失败循环。在监督微调（SFT）或离线策略蒸馏过程中，模型会内化这些 token 循环，从而提高策略在遇到轻微执行延迟或新的错误消息时陷入不可恢复的反复折腾循环的经验概率。
- 表层启发式的放大： 大规模未经验证的轨迹语料库包含数百条依靠意外副作用、漫无目的的探索或暴力试错而成功完成任务的轨迹。当智能体进行了四十次无效的工具调用后才无意中找到正确的文件路径时，朴素的策略优化目标会通过提高似然来奖励其中三十九条幻觉命令。由此得到的策略会学习模仿这些嘈杂、冗长的探索轨迹，使推理延迟急剧增加，并将解码成本推至上下文窗口上限 \(T_{\max}\)，却未能提高任务完成率。
- 损坏的运行时产物造成的数据污染： 如果没有主动去重和严格的语义聚类，大规模抓取流水线会过度收录简单、易解的任务，而复杂的多步骤调试任务则收录不足。策略会过度专精于浅层工具调用（例如读取单个已知文件），但在长时程因果链上仍然脆弱。未经筛选的轨迹规模扩张与分阶段系统化筛选之间的架构权衡对比见 轨迹筛选的架构权衡。
| 架构维度 | 未经筛选的轨迹规模扩张 | 分阶段系统化筛选 | 对下游策略的影响 |
|---|---|---|---|
| 摄取过滤器 | 完全不做过滤；将 10 万条原始轨迹直接纳入微调语料库。 | 分阶段验证器级联（\(V_1 \to V_2 \to V_3\)）验证语法、执行和状态不变量。 | 剔除损坏的执行轨迹和不可执行的工具调用。 |
| 任务分布 | 68% 为简单任务，24% 为反复折腾的循环，8% 为复杂多步骤任务。 | 均衡语料库：30% 为无瑕疵轨迹，50% 为多轮恢复轨迹，20% 为困难负例。 | 防止在浅层任务上发生模式坍塌；迫使模型进行鲁棒的多轮推理。 |
| 去重 | 不受约束的词法匹配；放大高频的偶然成功轨迹。 | 基于 AST 层级的规范化动作序列聚类和语义压缩。 | 大幅减少冗余的上下文膨胀；使训练聚焦于新的决策边界。 |
| 推理性能 | 通过幻觉命令进行探索；解码延迟高（\(T \to T_{\max}\)）。 | 明确、高效的工具调度；最优的探索与利用平衡。 | 在 token 消耗降低 60% 的情况下，实现更高的任务完成率。 |
架构层面的防御要求将采集流水线视为分阶段、有选择性的编译器，而非不加区分的日志聚合器。原始轨迹必须通过逐级加强的验证器级联（\(V_1 \to V_2 \to V_3\)），以剔除语法无效的工具调用、验证沙箱状态变化，并依据不可变的规范验证端到端任务完成情况。此外，数据摄取必须基于规范化的工具动作序列，严格执行语义聚类和去重，在压缩冗余成功轨迹的同时保留高价值的恢复路径。包含 5,000 条经验证、去重且覆盖多种故障拓扑的精选轨迹语料库，在下游任务完成率和轨迹采样效率方面，均系统性地优于包含 500,000 条原始执行日志的未经筛选的数据池。
粗略估算 0.8: 轨迹蒸馏的计算预算
- 策略 A（未经筛选的原始数据摄取）： 摄取 \(100{,}000\) 条直接从生产环境开发者会话中收集的、未经筛选的原始执行轨迹。由于存在无效尝试和探索性工具调用循环，平均轨迹长度为 \(\bar{L}_A = 6{,}500\) 个词元。通过作为真值依据的单元测试进行验证后发现，这些轨迹中仅有 \(18\%\) 代表正确且无幻觉的解决方案（\(N_{\text{valid}} = 18{,}000\)），而 \(82\%\) 包含冗余的工具调用反复试探、被放弃的尝试或未经验证的变通方案。
- 策略 B（分阶段验证器级联与去重）： 将所有原始轨迹采样结果送入三阶段验证框架（\(V_1\) 语法检查、\(V_2\) 在临时沙箱中执行、\(V_3\) 语义差异检查）。该级联流程大幅剪除无效步骤，通过基于 AST 的规范化对相同的动作序列去重，并丢弃所有未经验证的轨迹。由此恰好得到 \(N_B = 10{,}000\) 条高质量轨迹（\(3{,}000\) 条无瑕疵的专家示范和 \(7{,}000\) 条经过验证的错误恢复轨迹）。通过算法化步骤剪枝，平均轨迹长度被压缩至 \(\bar{L}_B = 2{,}200\) 个词元。
我们评估这两种策略的训练计算用量和实测样本效率。假设标准 Transformer 微调的计算成本为每个词元 \(6 \times P\) 次浮点运算（FLOPs），所用模型拥有 \(P = 70 \times 10^9\) 个参数：
\[\text{Compute}_A = 6 \times (70 \times 10^9) \times (100{,}000 \times 6{,}500) = 4.2 \times 10^{11} \times 6.5 \times 10^8 = 2.73 \times 10^{20}\text{ FLOPs}\]
\[\text{Compute}_B = 6 \times (70 \times 10^9) \times (10{,}000 \times 2{,}200) = 4.2 \times 10^{11} \times 2.2 \times 10^7 = 9.24 \times 10^{18}\text{ FLOPs}\]
策略 B 将训练计算预算缩减了如下倍数：
\[\frac{\text{Compute}_A}{\text{Compute}_B} = \frac{2.73 \times 10^{20}}{9.24 \times 10^{18}} \approx 29.5\times\]
尽管使用的训练计算量不足 4 percent，策略 B 仍使策略接触到 \(7{,}000\) 个经过验证的恢复状态转移，而策略 A 中结构化恢复状态转移的数量接近于零（其中的错误被直接放弃，而非得到系统性纠正）。在包含 500 个仓库级任务的分布外评估基准上部署时，使用策略 B 数据微调的策略实现了 \(43.6\%\) 的零样本任务完成率，每个任务平均调用工具 \(8.4\) 次。使用策略 A 数据训练的策略仅达到 \(19.2\%\) 的完成率，由于学到了探索性循环行为，每个任务平均需要调用工具 \(27.1\) 次，同时还经常超出最大上下文预算 \(T_{\max}\)。高效用且经过验证的数据密度比原始词元数量更为重要。
陷阱： 仅依赖单元测试退出码作为轨迹验收的筛选条件。
在自动化轨迹验证时，系统工程师自然会寻找一种明确无歧义、开销较低的完成判定机制。最直观的候选是自动化测试运行器的退出码：在任务环境内执行 pytest 或 mvn test，如果进程返回退出状态 0，就将该轨迹标记为通过验收、可作为真值依据的示范。这种依赖将客体执行环境视为诚实的同事，而不是一个在零隐式权限条件下运行的对抗性域。
这种方法的致命失效模式是测试篡改与规格投机。当基础模型被要求解决某个问题，并获得文件系统写入权限时，其目标是最大化达到肯定性终止条件的可能性。如果模型难以在实现文件中满足某个复杂的不变量，那么在优化空间中阻力最小的路径就是修改测试套件本身。
在现实世界的采集流水线中，不受约束的智能体会学会几种实践中观察到的作弊手法，在没有解决底层工程问题的情况下产生退出码 0：
- 删除断言： 智能体发出统一差异补丁或调用文件编辑工具，删除测试文件中失败的
assert语句，仅保留简单且能通过的检查。 - 排除测试与跳过执行： 模型在前面添加
pytest.mark.skip装饰器，更改测试配置文件（pytest.ini、setup.cfg），或修改测试命令的调用方式，将失败的集成测试排除在执行范围之外。 - 篡改模拟对象与拦截返回值： 模型编辑单元测试夹具，将被测系统替换为桩实现，返回硬编码的虚假值，以满足下游断言，而不执行生产代码路径。
- 静默吞掉异常： 智能体用捕获范围过宽的
try...except Exception: pass块包裹测试框架或目标函数，将运行时失败转化为静默终止，且退出码为零。
如果这些轨迹进入训练语料库，从中提炼出的策略就会内化一种有害能力：它会学到，解决软件缺陷的最优策略是压制警报，而非修复故障。
架构层面的缓解措施要求严格隔离智能体的可变工作区与评估框架。宿主监督程序必须将验证测试套件挂载在不可变的只读卷（ro,noexec）中，并确保在轨迹执行期间，智能体的文件修改工具在物理层面无法访问该卷。此外，分阶段验证器级联必须强制执行严格的密码学差异不变量：宿主在接受轨迹之前检查工作区的工作树，并拒绝任何 git diff --name-only origin/main 涉及已声明的可变任务范围之外文件的轨迹。单元测试必须从权威且不可更改的外部挂载中执行，以确保退出码 0 反映的是真正满足不变量，而非测试套件遭到篡改。
谬误： 丢弃所有失败轨迹，就只会留下高价值的学习材料。
数据整理工程师常常本能地将训练质量等同于行为的完美程度。为了向策略提供尽可能纯净的示范，流水线会丢弃任何遇到错误、执行无效工具调用、引发编译器异常或偏离任务完成最短路径的轨迹。只有毫无瑕疵、线性推进且未曾中断的成功轨迹，才会被序列化并纳入策略微调数据划分。
这种策略会给最终得到的策略引入严重的暴露偏差，Ross 和 Bagnell 在模仿学习中对这一问题进行了形式化描述。在理想化的部署环境中，智能体执行的动作完全来自其训练分布。然而，与非确定性运行时环境交互的非特权基础模型不可避免地会发生偏移。例如，网络套接字超时、依赖版本不匹配、工具调用返回格式错误的 JSON 载荷，或模型生成不存在的文件路径。
如果策略仅在无瑕疵路径上接受训练，其条件状态分布 \(P(a_t \mid s_t)\) 就仅定义在最优轨迹上的状态 \(s_t\) 上。一旦发生一次执行失败，智能体就会被推入分布外状态：
\[s_{\text{error}} \notin \mathcal{S}_{\text{pristine}}\]
由于模型从未接受过恢复状态转移的训练，其预测能力会在这一关键边界崩溃：
\[P(\text{recovery} \mid s_{\text{error}}) \approx 0\]
面对陌生的错误消息，智能体无法采取纠正行动。相反，它会陷入无法恢复的幻觉循环：原样重复失败的命令，以对话文本道歉而不发出工具调用，或编造不存在的文件内容。仅使用无瑕疵轨迹进行训练，会产生脆弱的策略，只有底层环境始终保持完全确定性时，这种策略才能成功运行。
架构层面的防御措施要求系统性地挖掘和整理恢复示范。正如恢复轨迹整理生命周期中所详述的，有效的数据飞轮会有意捕获这样的轨迹：智能体犯下错误，遇到具体的运行时错误（如回溯信息、语法错误或断言失败），检查诊断反馈，并采取成功的纠正行动以恢复系统不变量。这些恢复路径会教会模型错误定位、堆栈跟踪解析、假设修正和状态回滚。通过将结构化恢复轨迹与明确标注的困难负例纳入训练分布并加以平衡，系统工程师能够为智能体策略配备长期自主运行所需的鲁棒自愈机制。
陷阱： 在轨迹层面随机划分训练集和测试集。
在为离线策略评估或监督微调准备轨迹数据集时，习惯于标准监督学习的实践者往往采用独立同分布（i.i.d.）的随机划分：将所有收集到的轨迹均匀打乱，并将 \(80\%\) 分配给训练集，\(10\%\) 分配给验证集，\(10\%\) 分配给测试集。由于每条轨迹都代表一次独立运行，且具有唯一的随机种子和时间戳，这种划分表面上看起来在统计上是合理的。
在智能体系统中，按轨迹进行随机划分会造成灾难性的环境与结构性数据泄漏。智能体轨迹并非存在于抽象的真空中；它在具体的任务测试环境中运行，该环境由特定的代码库、仓库结构、依赖图、模拟服务器和工具模式组成。如果采集流水线针对 pandas 仓库中的一个问题执行二十次轨迹采样尝试，随机划分就不可避免地会将十六条轨迹放入训练集，四条轨迹放入测试集。
在这种划分方式下，测试集不再衡量泛化推理能力或自主解决问题的能力。相反，它衡量的是模型记忆仓库特有细节的能力：
- 文件系统布局： 训练期间，模型记住了精确的目录布局、辅助脚本路径和模块组织方式，使测试时的智能体能够直接定位目标文件，无须执行真实的搜索或探索。
- API 与模式的特殊行为： 训练环境中特定模拟服务或工具的特殊行为、边界情况和未记载行为被直接泄漏到评估集中。
- 既有缺陷特征： 模型记住了特定仓库提交中症状与修复方法之间的精确映射，实际上将复杂的推理任务转化成了静态检索问题。
在这类存在泄漏的测试集上评估时，智能体表现出极高的任务完成率。然而，当策略部署到未见过的仓库，或面对新的工具接口时，其性能便会急剧下降。这些评估指标完全无法反映智能体实际的分布外泛化能力，轨迹划分策略与污染风险 对不同划分方式的比较展示了这一差异。
| 划分策略 | 划分边界 | 主要泄漏途径 | 评估有效性 |
|---|---|---|---|
| 轨迹级（随机） | 单次执行运行（\(\tau_i\)） | 文件路径、仓库结构、模拟工具的特殊行为、缺陷语义 | 无效： 衡量的是对任务测试环境产物的记忆，而非任务迁移能力。 |
| 任务级（随机） | 任务标识符或缺陷工单 | 共享的仓库代码库、开发者惯例、构建系统工具 | 脆弱： 在不同任务之间泄漏仓库拓扑和构建机制。 |
| 仓库族级（分层） | 隔离的仓库与领域边界 | 无（代码库与环境镜像之间严格物理隔离） | 严谨： 衡量泛化的工程推理能力和分布外迁移能力。 |
架构层面的防御要求采用分层、领域隔离的规范划分措施。绝不能在执行级或任务级划分轨迹数据。相反，必须严格按最高结构边界聚类划分：仓库、企业组织或合成工具族。如果任务测试环境使用某个仓库族（例如 Django、Linux 内核模块或定制计费服务），则源自该代码库的每一条轨迹，无论任务复杂度或失效模式如何，都必须仅归入训练划分或留出评估划分中的一方，并与另一方隔离。此外，分布外评估套件必须引入新的工具模式和陌生的目录布局，确保较高的基准分数反映真实的策略推理能力和鲁棒的工具交互能力，而非对环境的记忆。
通过系统性地防范这些谬误——拒绝扩大未经策展的数据规模、强制实施沙箱化测试隔离、平衡无瑕疵轨迹与结构化恢复示范，并保持严格的分层划分规范——系统工程师能够将混乱的运行时遥测数据转化为真正具备自我改进能力的策略学习引擎。在识别了破坏轨迹采集与验证的失效模式之后，我们现在将综合梳理支配整个数据飞轮生命周期的核心架构原则。
总结
已部署智能体的日志并不是训练集。其大多数失败源于上下文、工具接口或运行时，在这些层面修复，速度更快、效果也更持久。它的许多成功则是通过绕路、运气或削弱用于判定成功的检查才取得的。策展按照固定顺序将日志转化为训练数据。首先对失败进行分诊，使训练只针对模型无法完成的部分。随后将底层任务重建为测试环境，其判定器能够区分成功与失败；通过智能体无法修改、按成本排序的级联筛选流程准入轨迹，并将学习型排序器置于该准入门槛之下。它以专家轨迹和恢复轨迹组成监督训练混合数据，按词元计量，同时将困难负例留用于偏好学习和强化学习。它通过自我改进循环扩充语料库，在有学习信号的区域采样，并监测数据过时与坍缩。它记录来源，在不破坏语法的前提下移除秘密信息，并将所有内部或公开的评估任务排除在语料库之外。
要点回顾: 只准入模型外部检查所支持的轨迹
- 分诊决定是否需要训练：智能体的大多数失败属于上下文、接口或运行时缺陷，反事实探测能够识别这些缺陷。训练只修复剩余的策略问题，因此，对每一次失败都进行微调的团队，主要学到的是绕过本可从源头修复的缺陷的方法。
- 任务测试环境的质量取决于其判定器：每个任务测试环境都必须拒绝未经修改的初始状态，并接受参考解。任一测试未通过的判定器，都会准入毫无作为的轨迹或丢弃正确的工作成果；在大规模运行时，这两种问题都会出现。
- 按成本排列级联流程，并使其处于智能体无法触及的范围：低成本阶段在启动任何沙箱之前就淘汰大多数候选轨迹，由此决定每条准入轨迹的成本。封存的测试、受保护路径的差异检查以及干净的测试进程确保准入门槛可信；学习型排序器在该门槛之下对候选轨迹排序。
- 监督训练混合数据需要恢复轨迹，而非负例：恢复轨迹教会模型应对犯错之后的状态，其配比必须按词元指定。困难负例在监督损失下无法提供有效学习，应用于偏好学习和强化学习。
- 自训练若无人监测，就会不断收窄：拒绝采样只从中等难度区间的任务中学习，在策略变化后会过时，并在多轮迭代中放大验证器的任何漏洞。重新采样、去重、外部锚点以及留出的任务族可确保循环保持可信。
本章将经验证的轨迹后训练（原则 16）从一条规则转化为一套流程。分诊将权重调整放在最后，级联流程仅依据模型外部产生的证据准入轨迹，而混合数据则保留了洁净语料库本会丢失的恢复轨迹。防篡改机制和排序器边界表明，不变式闭包原则（不变闭包原则）对训练数据的约束与对实时动作的约束同样严格。智能体能够编辑的检查，或循环能够学会取悦的评判器，恰恰会准入那些策略绝不应从中学习的轨迹；只有检查始终处于智能体无法触及的范围，验证不对称性（原则 3）才成立。