开放权重之后，为什么 Agent 仍然无法复现：真正缺的是可重放行为证据
一、同样的开放权重，为什么两个 Agent 不像同一个系统
同一个开放模型、同一条用户指令，两支团队做出的 Agent 可能完全不像同一个系统。一支能在工具超时后换路重试、验证外部状态再结束；另一支遇到 403 仍继续编造"操作已完成"。差别未必来自权重。系统 Prompt、工具 Schema、权限、失败样本、数据混合方式与评测器，都可能改变最后的行为。
这正是 2026 年 7 月 8 日 Hugging Face 与 NVIDIA 发布《Data for Agents》时提出的问题：开放权重只是开放 Agent 生态的一部分。真正决定一个 Agent 能否被理解、比较和复现的，还包括数据、策展方式、训练配方与评测资产。
二、Prompt Atlas 暴露了一个常被忽略的问题：数据配比也是产品决策
Prompt Atlas 把数据集、流水线、领域、工具使用等维度放进一张按体量采样的可视化地图，让人能看到训练材料由什么构成，而不只是看到一个总规模。两个团队拿到相同原始数据，只要成功与失败比例、难度课程、去重阈值、合成方法、领域采样不同，训练出的 Agent 行为就会不同。
↑ 02 · Prompt Atlas 解释图：把数据配比 / 流水线 / 领域 / 工具使用这四个维度，叠到同一张地图上，颜色覆盖可按维度切换。
↑ 03 · Hugging Face / NVIDIA 官方原文证据（2026-07-08）：Prompt Atlas "interactive visual map where each point is a prompt sample, drawn from the Nemotron v3 post-training collection and volume-sampled to reflect the honest proportions of the data mixture"，覆盖 8 类 Agent 数据面（软件工程轨迹、工具使用失败、多步推理、检索、安全、用户模拟、工作流、物理世界交互）。
普通问答数据常被压成两列：用户问题和助手回答。Agent 执行却是一条有状态的行为链：
text
目标 → 计划 → 工具选择 → 参数 → 工具结果
→ 状态变化 → 重试或升级 → 最终验证如果只保存最终答案，最关键的信息会消失：模型为什么选这个工具，参数是否符合当时的 Schema，第一次调用为何失败，重试是否产生了副作用，最终状态又由谁验证。
《Data for Agents》把软件工程轨迹、工具使用失败、多步推理、检索、安全、用户模拟、工作流执行和物理交互都列为 Agent 数据面。这个分类最值得注意的地方，不是类别多，而是它把失败与恢复放回了训练和评测视野。
生产系统里，真正棘手的往往不是"正常调用一次 API"，而是这些情况：权限在执行中途过期；工具返回部分成功，外部状态已经改变；API 字段升级，旧参数仍然语法合法但语义改变；重试不是幂等操作，第二次调用会重复扣款或重复建单；Agent 给出语言上合理的总结，但实际任务没有完成。
只用漂亮的成功轨迹训练，模型容易学会"成功的叙述"；只有把失败、恢复、人工修正和外部状态验证一起留下，系统才有机会学会"成功的行为"。
三、规模不能替代配比、版本与谱系
↑ 04 · NVIDIA Technical Blog 官方原文证据（2025-12-15，《Inside NVIDIA Nemotron 3》）："NVIDIA's synthetic pretraining corpus --- nearly 10 trillion tokens --- can be inspected or repurposed"；"Nemotron post-training 3.0: a 13-million-sample corpus for supervised fine-tuning and reinforcement learning that powers Nemotron 3 Nano's alignment and reasoning"。这是组织级汇总口径，跨预训练、后训练、persona、安全、RL、RAG 等集合，不是单一数据集。NVIDIA Developer Topics 页面（2026-08-26 核验）只列模型清单，不显示汇总数字，因此本任务的 S2 来源采用 NVIDIA Blog 而非 Topics 页。
因此，规模只能回答"有多少"，不能回答：
- 这些样本来自哪里，经过什么筛选；
- 哪些是合成数据，教师模型和生成方法是什么；
- 哪些任务包含真实失败与恢复路径；
- 各子数据集允许怎样的训练、商用和再分发；
- 训练集是否与回归评测或公开 Benchmark 重叠。
开放数据让这些问题变得可检查，却不会自动替你完成检查。
四、5 层 Behavior Reproducibility Bundle：Agent 真正可复现的单位
↑ 05 · 5 层 Bundle 解释图：每一层 1 句"缺失后的后果"，突出运行身份 / 行为轨迹 / 执行环境 / 结果判定 / 数据治理都是必要条件。
对语言模型，下载权重至少可以重建一次近似推理。对 Agent，模型只是执行链中的一个组件。一次行为能否被重放，至少取决于五类信息。
| 证据层 | 必须绑定的内容 | 缺失后的后果 |
|---|---|---|
| 运行身份 | 模型、Prompt、Skill、Router、策略版本 | 无法定位行为变化来自哪个组件 |
| 行为轨迹 | 工具选择、参数 digest、结果、重试、状态迁移 | 只看见答案，看不见失败机制 |
| 执行环境 | 工具 Schema、沙箱、数据夹具、权限范围、依赖 | 旧轨迹无法在同一语义下重放 |
| 结果判定 | expected/observed 外部状态、evaluator、人工修正 | "完成"被误当成真实完成 |
| 数据治理 | 来源、版本、许可证、合成方法、脱敏、训练/评测隔离 | 无法安全复用，无法解释指标污染 |
这五层合起来，才是一份 Agent Behavior Reproducibility Bundle------Agent 行为可重放包。它不承诺逐 token 一致。供应商 API、硬件、并发、搜索结果和外部数据库都可能变化。更现实的目标是：同一类失败可以再次触发，修复前后的指标可以比较，副作用可以检查，结论可以追溯。这也是为什么"导出聊天 JSON"远远不够。聊天记录保存的是叙述；可复现包保存的是一次执行的合同、过程和判决。
重要边界：
Agent Behavior Reproducibility Bundle是作者工程抽象，不是 NVIDIA / Hugging Face / OpenTelemetry / OpenAI 的官方术语。
五、先建立最小事件合同，再接入各家 Trace
产品团队很容易把某个 SDK 的 tracing 格式直接当成自己的数据模型。短期快，长期会被供应商字段和版本牵着走。
↑ 06 · 最小事件合同解释图：run / event / verdict / governance 四段 YAML 字段含义与"先合同后 Trace"的工程原则。
↑ 07 · OpenTelemetry GenAI 官方原文证据(2026-08-26 检查):当前可访问的 GenAI semconv 1.44.0 中,gen_ai.tool.call.arguments / gen_ai.tool.call.result / input.messages / output.messages / system_instructions 字段定义上均明确标注 "This attribute may contain sensitive information" 警告文字(警告出现在新仓库 footnote 12/13 等位置,需跟随链接到新仓库 footnote 查看)。
本截图聚焦表行:1.44.0 标注 deprecated + Moved to the OpenTelemetry GenAI semantic conventions repository 链接,新仓库对上述字段统一标 sensitive。OpenTelemetry GenAI 语义约定独立演化,但官方已经明确:
也就是说，工具调用参数和结果属性本身在 OpenTelemetry 公共规范里就被识别为敏感。
↑ 08 · OpenAI API Data Controls 官方原文证据："OpenAI does not use your data to improve our models, unless you have explicitly opted in to share your data for this purpose" 紧邻 "Abuse monitoring log data may be retained for up to 30 days, regardless of whether you have opted in to share your data for model improvement"。
OpenAI API 数据控制同样说明"不训练"和"保留"是两件事：默认情况下，API 数据不用于训练；但 abuse monitoring log 可能保留至 30 天，application state 按 endpoint / feature 独立保留。
由此更稳妥的做法不是"把所有 trace 全量留存"，而是先定义自己的最小事件合同，再通过适配器连接 SDK 或可观测平台。一条可用于诊断和回归的最小记录，至少应包含：
yaml
run:
model_version: ...
prompt_version: ...
policy_version: ...
tool_schema_version: ...
event:
intent: ...
tool_name: ...
arguments_digest: ... # 替代原始参数 --- 见 S3 OTel 敏感警告
result_class: success | partial | timeout | denied | invalid
state_before: ...
state_after: ...
retry_of: ...
verdict:
expected_external_state: ...
observed_external_state: ...
evaluator_version: ...
human_correction: ...
governance:
source: ...
consent_and_license: ...
sanitization: ...
split: train | validation | sealed_eval这里有意使用 arguments_digest，而不是默认保存原始参数。真实参数可能包含个人信息、令牌、客户内容或商业数据。只有当诊断确实需要、授权和保留策略明确时，才保存经过裁剪与脱敏的原值。verdict.expected_external_state 与 observed_external_state 显式记录，可以让"模型的完成"与"任务的完成"分开。
六、先回归后训练：生产 Trace 的第一用途通常不是训练
↑ 09 · 5 步训练顺序解释图：失败分类 → 隔离回归 → 系统修复 → 稳定指向模型缺口再训练 → sealed eval 隔离。
看到大量失败日志后，团队很容易直接走向微调。但很多问题并不该交给模型学习：工具描述含糊、权限配置错误、后端接口不幂等、产品状态机缺少保护，都应该先由系统修复。
一条更稳的路径是：
- 用 trace 建立失败分类，先知道失败集中在哪一层；
- 把已确认的生产失败改造成隔离回归用例；
- 修复 Prompt、工具合同、Router、权限或产品逻辑；
- 只有当错误稳定指向模型能力缺口时，再选择后训练数据；
- 训练集与 sealed eval 分开，评测集一旦揭盲就不能继续拿来调参。
这条顺序有一个直接好处：每次改动都有可观察对象。如果只看总体成功率，模型升级、工具升级和数据变化会混在一起；如果按失败类别比较，就能知道提升来自哪里，又牺牲了什么。
合成数据也应放在这条链的后半段。它适合扩展已知模式、覆盖稀有组合和降低直接使用敏感生产数据的风险，但它不能自动证明任务真实、失败分布真实或标签正确。没有真实场景锚点、谱系记录和人工抽检，合成数据只是把教师模型的偏差规模化。
七、"开放"降低了审计门槛，但没有取消工程责任
开放权重让人能够运行模型；开放数据让人能够追问能力从哪里来；开放配方和评测则让不同团队有机会比较过程与结果。这些资产越完整，Agent 生态越接近可研究、可修改的工程系统。
但"开放"不等于：所有子集许可证相同、数据无污染、工具可重放、合成样本无偏差，或者拿到资源就能复现官方指标。具体使用时仍需逐个检查 dataset card、来源、版本、许可、生成方法和评测隔离。
《Data for Agents》真正有价值的地方，不是又公布了一个庞大的数字，而是把 Agent 的开放问题从"能否下载模型"推进到"能否检查它如何行动"。
对产品团队，最先该建设的也不是更大的聊天仓库，而是一条可以把真实执行转换为失败证据、人工修正、隔离回归和版本化判决的数据链。只有当一次成功和一次失败都能被重放，开放权重才开始变成可复现的 Agent 能力。
参考资料
- Data for Agents，Hugging Face / NVIDIA，2026-07-08，访问于 2026-08-26。
- Inside NVIDIA Nemotron 3: Techniques, Tools, and Data，NVIDIA Technical Blog，2025-12-15，访问于 2026-08-26。
- Semantic conventions for generative AI systems，OpenTelemetry，访问于 2026-08-26。
- Data controls in the OpenAI platform，OpenAI Developers，访问于 2026-08-26。