文章类型技术长文 所属专栏Agent 观测 预计阅读58 分钟 文档状态已发布

第 9 篇：从评测数据桥接到 Agent 后训练数据

判断失败是否适合训练解决，重建模型可见上下文，把成功与修正轨迹转成 Target/Mask，并用 Provenance 防止训练与评测污染。

开始阅读全文11662 字 · 58 分钟 查看系列目录Agent 观测

作者Jupiter 发布日期2026/08/06 最近更新2026/08/06 正文规模11662 字

关键词 AgentEvaluation后训练Trajectory数据治理

栏目 AgentObservability；专栏 Agent 观测；标签 Agent、Evaluation、后训练、Trajectory、数据治理

文章目标#

评测数据和训练数据经常来自同一条 Agent Trace，但它们并不是同一个数据对象。

一条 Evaluation Case 的目标是：

1
给定任务和环境
2
→ 运行 Agent
3
→ 收集完整证据
4
→ 用 Grader 判断表现

一条 Training Example 的目标则是：

1
给定模型在运行时真实可见的上下文
2
→ 指定模型应该学习产生的动作或回答

这两个目标之间至少隔着五层转换：

1
Raw Trace
2
→ Curated Trace
3
→ Evaluation Case
4
→ Training Candidate
5
→ Training Example

如果跳过这些转换，直接把评测 Trace 导入训练集，最常见的结果不是“模型学得更多”，而是：

模型看到了运行时不可能获得的 Judge 结论；
Grader-only 的隐藏测试、Gold 或未来 Outcome 泄漏到输入；
网络、工具、权限或编排故障被错误归因给模型；
错误 Tool Call 被作为正向目标学习；
Tool Result 与 tool_call_id 的关系被破坏；
Context Compaction 前的原始历史被错误恢复，形成超出生产可见性的“全知上下文”；
冻结评测集被训练回流污染，后续分数失去意义；
同一失败 Trace 以多种表面形式重复进入训练集。

本文只讨论评测数据向后训练数据的桥接工程：

问题路由；
数据选择；
清洗和重建；
Tool-use 对话标准化；
失败—修正对构造；
Target 与 Mask；
数据质量门槛；
配比与覆盖；
Eval Holdout 隔离；
数据血缘和最终 Schema。

本文不展开 SFT、偏好优化、过程监督或强化学习的目标函数、优化器和训练算法。文中出现“成功轨迹”“偏好对”“Step Label”等名称，只表示数据形态，不规定它们必须被哪种算法消费。

贯穿全文的案例仍是一个 Coding Agent：

用户要求 Agent 修复 orders/discount.py 中 quantity=0 的折扣计算错误，只允许修改 orders/ 和 tests/orders/，不得修改 payments/；Agent 需要搜索仓库、读取文件、修改代码、运行测试，并输出最终结果。

生产中可能出现三条不同轨迹：

1
轨迹 A：
2
正确搜索 → 正确读取 → 正确修改 → 测试通过
3

4
轨迹 B：
5
正确搜索 → 错误修改 payments/ → 被权限系统阻止
6

7
轨迹 C：
8
正确修改 → Tool Result 丢失 → Resume 后重复执行写操作

它们不能被统一处理为“有 Trace，所以都进入训练”。

本文要建立的是下面这条受控闭环：

1
Production / Eval Trace
2
→ Root Cause Routing
3
→ Visibility Reconstruction
4
→ Correction Verification
5
→ Training Candidate
6
→ Holdout & Dedup Gate
7
→ Versioned Training Dataset
8
→ New Agent Version
9
→ Frozen Offline Eval
10
→ Canary
11
→ New Production Trace

OpenAI 的模型优化文档把 Evals、Prompt 和训练数据迭代描述为持续反馈环，但“依据 Eval 反馈修改数据”不意味着直接训练 Eval Test；评测基线仍需独立保留。¹ Anthropic 的 Agent Eval 方法同样强调，一次失败可能来自模型与 Agent Harness 的共同系统，Transcript 和 Outcome 必须分开判断。²

1. 评测数据为什么不能直接用于训练#

1.1 Evaluation Case 面向判定#

Evaluation Case 的职责是让评测系统回答：

1
任务是否完成
2
轨迹是否违规
3
环境是否达到目标
4
成本和延迟是否可接受

因此它通常包含两类信息。

Agent-visible#

运行时 Agent 可以看到：

System Instruction；
用户请求；
当前工具定义；
Tool Result；
被注入的检索、记忆和环境观察；
Context Compaction Summary。

Grader-only#

只允许评测器看到：

Hidden Tests；
Reference Solution；
Expected Environment State；
Forbidden-action Scanner 规则；
Judge Rubric；
Gold Label；
事故 Root Cause；
生产后的人工修复结果。

一个 Evaluation Case 可以表示为：

1
evaluation_case:
2
  agent_visible:
3
    user_goal: 修复折扣错误
4
    allowed_paths:
5
      - orders/**
6
      - tests/orders/**
7
    tools:
8
      - search_code
9
      - read_file
10
      - edit_file
11
      - run_tests
12

13
  grader_only:
14
    hidden_tests:
15
      - test_zero_quantity
16
      - test_discount_boundaries
17
    expected_state:
18
      payments_changed: false
19
      all_tests_passed: true
20
    reference_patch_ref: private://gold/discount-fix

grader_only 的存在正是为了让评测能够独立判定。
它不能原样成为模型输入。

1.2 Training Example 面向行为学习#

Training Example 不需要包含完整评测世界。

它只需要回答：

1
在这个可见上下文下，
2
模型应该输出什么行为？

行为可以是：

一段最终回答；
一个 Tool Call；
一组 Tool Arguments；
一次拒绝；
一次确认请求；
一次人工升级；
一个故障恢复动作。

例如，Tool Selection 样本可以只有：

1
{
2
  "context": {
3
    "task": "修复 orders/ 中的折扣错误",
4
    "available_tools": [
5
      "read_file",
6
      "edit_file",
7
      "run_tests"
8
    ],
9
    "current_state": {
10
      "target_file": "orders/discount.py"
11
    }
12
  },
13
  "target": {
14
    "tool": "read_file",
15
    "arguments": {
16
      "path": "orders/discount.py"
17
    }
18
  }
19
}

它不需要把：

1
最终测试结果
2
Judge 评分
3
未来人工修复

放进输入。

因此，Evaluation Case 与 Training Example 的关系不是复制，而是投影：

\text{Training Example} = \Pi_{\text{visible context, target behavior}} (\text{Evaluation Case}, \text{verified trajectory})

其中 $\Pi$ 表示按照训练目标抽取必要字段。

1.3 Trace 包含模型不可见字段#

生产 Trace 为了观测和审计，会保存大量模型从未看到的字段：

1
trace_id
2
span_id
3
parent_span_id
4
provider_request_id
5
latency
6
token_usage
7
cost
8
retry_count
9
approval_actor
10
environment_state_after
11
grader_score
12
incident_id
13
root_cause

这些字段可以帮助工程师解释失败，但不能自动进入模型上下文。

例如：

1
{
2
  "span": {
3
    "name": "edit_file",
4
    "error.type": "permission_denied",
5
    "root_cause": "tool_policy_misconfiguration",
6
    "human_fix": "change allowlist"
7
  }
8
}

模型运行时看到的可能只有：

1
Tool Result:
2
Permission denied.

如果训练时把 root_cause 和 human_fix 一并放进输入，模型学到的是一个生产时不存在的信息通道。

可见性必须逐事件记录#

推荐为 Trace Event 建立：

1
visibility
2
visible_to_model_at_step
3
rendered_content_hash
4
visibility_source

例如：

1
{
2
  "event_id": "evt_041",
3
  "type": "tool_result",
4
  "visibility": "MODEL_VISIBLE",
5
  "visible_at_step": 7,
6
  "rendered_content_hash": "sha256:...",
7
  "raw_artifact_ref": "artifact://tool-result/041"
8
}

内部错误分类则是：

1
{
2
  "event_id": "evt_042",
3
  "type": "incident_annotation",
4
  "visibility": "INTERNAL_ONLY"
5
}

1.4 Grader 结果包含未来信息#

Grader 在 Trial 完成后运行。

它可能知道：

最终数据库状态；
所有隐藏测试结果；
用户投诉；
人工最终修复；
哪条 Step 是首个错误；
哪个候选版本得分更高。

这些信息在 Agent 作出早期动作时尚未发生。

例如，在 Step 3 训练 Tool Selection 时，不能输入：

1
最终 Outcome：测试失败
2
Judge：应当选择 read_file

这是典型的未来信息泄漏。

时间切片原则#

任何局部 Training Example 都必须定义：

1
decision_time
2
visible_prefix
3
target_action
4
future_evidence

其中：

1
visible_prefix

只能包含 timestamp <= decision_time 且模型真实可见的内容。

future_evidence 可以用于验证 Target，但不能进入 Input。

1.5 错误可能来自系统而不是模型#

Agent 失败不等于模型行为需要训练。

可能的根因：

1
Tool Description 写错
2
Tool Result 回填到错误 call_id
3
MCP Server 返回旧 Schema
4
Retriever Index 落后
5
Checkpoint 丢失 Pending Tool
6
网络在写操作完成后断开
7
Sandbox 误拒允许目录
8
Grader 隐藏测试错误

如果真实根因是系统，构造“模型纠正样本”会产生错误监督。

例如：

1
模型正确选择 edit_file("orders/discount.py")
2
工具运行时错误地修改了 payments/service.py

不能把模型 Tool Call 标成 Negative。

必须先做归因#

推荐训练准入字段：

1
{
2
  "root_cause": "TOOL_IMPLEMENTATION",
3
  "model_behavior_error": false,
4
  "training_suitable": false,
5
  "fix_owner": "tool-runtime-team",
6
  "evidence_refs": [
7
    "obs_tool_call_12",
8
    "artifact_state_diff_12"
9
  ]
10
}

1.6 评测集必须保持冻结和独立#

Eval Holdout 的意义是测量未见泛化。

如果将 Test Case、测试 Trace 或 Gold 修正轨迹加入训练：

1
后续 Eval 分数

不再能区分：

真正能力提升；
对已知案例记忆；
对固定 Tool Sequence 过拟合；
对 Grader Pattern 适配。

训练—评测污染不只来自完全相同文本。

还包括：

1
相同任务模板
2
相同仓库和文件
3
相同 Reference Patch
4
相同 Tool Result
5
相同 Environment Fixture
6
语义近重复
7
轨迹近重复
8
同一事故的改写版本

ACL 2022 的去重研究显示，训练数据重复会增加记忆，并造成 Train-Test Overlap，使评测结果失真。³ LiveCodeBench 则通过按时间引入新问题降低污染和静态 Benchmark 过拟合。⁴

硬规则：

1
eval_usage = HOLDOUT
2
→ training_usage = DENY

如果某个 Holdout Case 已被用于修复或训练：

1
它应转入 Known Regression Set，
2
同时补充新的未见 Holdout。

2. 先判断问题是否应该通过训练解决#

失败是否应该通过训练解决

在创建 Training Candidate 之前，先回答：

如果不更新模型，只修 Prompt、Tool、Runtime 或环境，这个问题是否会消失？

推荐使用一个问题路由表。

根因	主要修复手段	默认进入训练？
Prompt 不清晰	修改 Prompt / Contract	否
Tool Schema 错误	修 Schema / Description	否
Agent 编排错误	修状态机 / Context 传播	否
网络和运行时错误	Retry / Idempotency / Runtime	否
Retrieval / Memory 错误	修召回、过滤、注入	否
权限或环境配置错误	修 Policy / Sandbox / Fixture	否
模型行为能力缺口	构造训练候选	是，需验证

训练不是默认终点，而是问题路由中的一个分支。

2.1 Prompt 和指令问题#

典型现象：

1
模型经常在未确认前执行外部写操作

可能原因是 Prompt 没有说明：

1
外部写入必须确认。

或指令分散、冲突。

先做对照：

1
原 Prompt + 同模型
2
修正 Prompt + 同模型

如果修正 Prompt 后稳定通过，根因属于：

1
PROMPT_CONTRACT

不应优先训练。

何时仍可进入训练候选#

当明确、稳定的 Prompt 下，模型仍反复：

忽略硬约束；
混淆拒绝与确认；
产生错误结构；
在相似上下文做不一致决策；

才可标记为模型行为缺口。

2.2 Tool Schema 问题#

典型问题：

1
工具名称含糊
2
描述与真实能力不一致
3
Required 字段缺失
4
返回结构未说明
5
同名工具冲突
6
版本变化未更新上下文

例如：

1
Tool A: update_order
2
Tool B: edit_order

模型选错不一定表示 Tool Selection 能力差。

先做 Tool-only Fix#

固定：

1
模型
2
Prompt
3
任务
4
环境

只修改：

1
Tool Name
2
Description
3
JSON Schema
4
Return Contract

重新多 Trial。

若改善显著，根因在接口。

OpenAI Function Calling 使用 JSON Schema 定义 Tool，并通过 call_id 将 Function Call 与 Function Call Output 对齐。⁵ Anthropic Tool Use 也要求 tool_use.id 与后续 tool_result.tool_use_id 匹配。⁶

训练数据必须保持这种调用契约，不能用一个丢失 ID 的“近似对话”代替。

2.3 Agent 编排问题#

典型问题：

1
Tool Result 没进入下一轮模型请求
2
并行 Tool 结果顺序错误
3
子 Agent Result 未汇合
4
Compaction 丢失硬约束
5
Resume 重复已完成 Step
6
错误的 Stop Condition

模型在它看到的上下文中可能已经做了合理决策。

例如：

1
模型要求读取测试文件
2
Runtime 错误地执行了编辑工具

这不是训练数据问题。

编排问题的判定#

使用固定模型响应 Replay：

1
固定模型输出
2
→ 重放 Runtime

如果仍失败，优先修 Runtime。

2.4 网络和运行时问题#

典型问题：

1
429
2
Stream Disconnect
3
Tool Timeout
4
Response Usage 丢失
5
Tool 已执行但 Ack 丢失
6
子进程取消失败

这些问题需要：

Backoff；
Retry Budget；
Idempotency Key；
Execution Ledger；
Resume；
Circuit Breaker；
State Query。

不应通过让模型“记住网络会失败”来替代基础设施正确性。

可转成训练的部分#

网络故障本身不是训练对象，但模型面对可见错误结果后的行为可以成为训练对象。

例如：

1
输入：
2
Tool Result = permission denied
3

4
目标：
5
不要重复相同 Tool Call；
6
改为请求人工确认。

此时训练的是：

1
错误后的决策

不是：

1
修网络。

2.5 检索和记忆问题#

典型问题：

1
正确文档未召回
2
旧索引
3
Memory 越域
4
冲突记忆被注入
5
Context Selection 丢掉关键 Chunk

先做：

1
Retrieval-disabled / Memory-disabled Replay

或替换为正确 Evidence。

如果模型在正确 Evidence 下表现正常，则问题在 Retrieval / Memory。

可进入训练的部分#

当正确 Evidence 已真实进入上下文，模型仍：

忽略关键字段；
错误引用；
选择与证据冲突的 Tool；
无法处理冲突信息；

才属于模型行为候选。

2.6 权限与环境配置问题#

典型问题：

1
允许目录被 Sandbox 拒绝
2
测试账号权限错误
3
Mock 与生产 Schema 不一致
4
环境变量缺失
5
时间和地区配置错误

这些应修：

1
Policy
2
Sandbox
3
Fixture
4
Credential
5
Environment Revision

不要把“Tool 返回权限拒绝”的失败直接转成：

1
模型不应使用这个工具

因为在正确环境中，Tool 可能正是正确选择。

2.7 真正需要模型学习的行为问题#

训练候选通常具备以下特征：

Context、Prompt、Tool 和 Runtime 均正确；
模型真实看到了完成决策所需的信息；
错误行为能在多 Trial 中稳定复现；
更清晰 Prompt 或 Tool Description 不能彻底解决；
人类或高质量 Reference 能给出可验证修正；
修正轨迹在相同环境中通过 Outcome Grader；
样本不属于冻结 Holdout。

典型行为问题：

1
清晰约束下仍选择禁止工具
2
正确工具下持续生成错误参数
3
看到 Tool Error 后仍无限重复
4
应当拒绝时执行危险操作
5
应当确认时直接写入
6
应当继续搜索时过早结束
7
正确 Evidence 下做出错误结论

Training Suitability Record#

1
{
2
  "case_id": "case_discount_003",
3
  "root_cause": "MODEL_BEHAVIOR",
4
  "behavior_gap": "TOOL_ARGUMENT_POLICY",
5
  "training_suitable": true,
6
  "prompt_fix_tested": true,
7
  "tool_schema_fix_tested": true,
8
  "runtime_replay_passed": true,
9
  "counterfactual_evidence": {
10
    "correct_context_replay_failed": true,
11
    "human_correction_verified": true
12
  },
13
  "excluded_from_eval_holdout": true
14
}

3. 四层数据对象#

3.1 Raw Trace#

Raw Trace 是最接近生产事实的原始记录。

它可能包含：

1
完整消息
2
模型 API Event
3
Tool Call / Result
4
内部 Span
5
网络错误
6
Token / Cost
7
Secret
8
PII
9
环境 Snapshot
10
Judge
11
人工备注

特点：

信息最完整；
风险最高；
Provider-specific；
结构不稳定；
不能直接训练。

Raw Trace 应保持不可变，并通过 Artifact Reference 访问。

1
{
2
  "raw_trace_id": "trace_prod_001",
3
  "source_system": "coding-agent-prod",
4
  "capture_schema": "otel-agent-v3",
5
  "artifact_ref": "secure://raw-traces/trace_prod_001",
6
  "content_hash": "sha256:..."
7
}

3.2 Curated Trace#

Curated Trace 是经过治理的规范化 Trace。

处理包括：

PII / Secret 脱敏；
Provider 事件归一化；
Tool Call / Result 配对；
Event 顺序修复；
可见性标注；
Artifact 外置；
Root Cause 与 Failure Taxonomy 标注；
版本补全；
无法恢复内容标记。

它仍然是“完整运行证据”，不是训练样本。

1
Raw Trace
2
→ Redaction
3
→ Normalization
4
→ Visibility Ledger
5
→ Curated Trace

3.3 Evaluation Case#

Evaluation Case 从 Curated Trace 中提取一个可复现任务：

1
Task Contract
2
Frozen Environment
3
Tool Set
4
Budgets
5
Forbidden Actions
6
Ground Truth
7
Grader
8
Source Provenance

它的核心是：

1
可运行、可判定

而不是：

1
可直接学习。

Evaluation Case 必须保留 agent_visible 与 grader_only 边界。

3.4 Training Example#

Training Example 是按某个行为目标生成的数据对象。

可能是：

1
多轮 Tool-use 轨迹
2
单步 Tool Selection
3
Tool Argument 修正
4
失败—修正对
5
偏好候选对
6
Step Label
7
Outcome Label
8
拒绝 / 确认 / 升级
9
故障恢复动作

它需要：

1
model_visible_input
2
target
3
mask
4
quality
5
provenance
6
split
7
usage_policy

一个 Evaluation Case 可以派生多个 Training Example#

例如同一 Trace 可派生：

1
1 个完整成功轨迹
2
3 个 Tool Selection Step
3
2 个 Tool Argument Step
4
1 个恢复动作样本
5
1 个最终回答样本

派生样本之间必须共享：

1
source_case_id
2
source_trace_id
3
derivation_group_id

避免 Split 泄漏和重复计权。

3.5 四层对象之间的转换和不可逆步骤#

转换	主要操作	是否有损
Raw → Curated	脱敏、标准化、配对	可能
Curated → Eval Case	切 Task、冻结环境、加 Gold	是
Eval Case → Training Candidate	根因路由、修正验证	是
Candidate → Training Example	上下文投影、Target/Mask	是

不可逆步骤包括：

1
删除 PII
2
删除 Secret
3
摘要化 Tool Result
4
Context Compaction
5
裁剪无关 Step
6
把多个合法修正归并
7
将自由文本 Label 映射成枚举

因此每次转换要保存：

1
source_id
2
transform_name
3
transform_version
4
input_hash
5
output_hash
6
parameters
7
actor
8
timestamp

W3C PROV-O 使用 Entity、Activity 和 Agent 以及 wasDerivedFrom、wasGeneratedBy、used 等关系表达数据派生。⁷

推荐映射：

1
Entity：
2
Raw Trace、Curated Trace、Eval Case、Training Example、Dataset
3

4
Activity：
5
Redaction、Normalization、Correction、Masking、Split、Build
6

7
Agent：
8
Pipeline、Annotator、Reviewer、Service

4. 标准化中间格式#

标准化中间格式的目标是：

1
隔离 Provider 格式
2
保留 Tool 语义
3
支持可见性和 Mask
4
支持多个训练数据派生器

它不是某个模型最终的 Chat Template。

最终 Token 序列仍需使用目标模型自己的模板生成。Hugging Face Transformers 将对话表示为 role / content 消息，并通过模型 Tokenizer 的 chat_template 转换成具体控制 Token；错误模板会显著伤害行为一致性。⁸

4.1 System、User、Assistant 与 Tool Role#

4.2 Tool Definition#

Tool Definition 至少包含：

1
name
2
description
3
parameters
4
schema_version
5
implementation_version
6
side_effect_class

1
{
2
  "name": "edit_file",
3
  "description": "Apply a patch to a file inside the allowed workspace.",
4
  "parameters": {
5
    "type": "object",
6
    "properties": {
7
      "path": {
8
        "type": "string"
9
      },
10
      "patch": {
11
        "type": "string"
12
      }
13
    },
14
    "required": [
15
      "path",
16
      "patch"
17
    ],
18
    "additionalProperties": false
19
  },
20
  "schema_version": "2.1.0",
21
  "implementation_version": "git:abc123",
22
  "side_effect_class": "REVERSIBLE_WRITE"
23
}

工具定义必须与轨迹运行时版本一致。

不能使用当前最新版 Tool Schema 重新解释历史 Tool Call，除非显式执行 Migration。

4.3 Tool Call 与 tool_call_id#

Canonical Tool Call：

1
{
2
  "id": "call_edit_01",
3
  "type": "function",
4
  "function": {
5
    "name": "edit_file",
6
    "arguments": {
7
      "path": "orders/discount.py",
8
      "patch": "*** Begin Patch ..."
9
    }
10
  }
11
}

Assistant Message：

1
{
2
  "role": "assistant",
3
  "content": [],
4
  "tool_calls": [
5
    {
6
      "id": "call_edit_01",
7
      "type": "function",
8
      "function": {
9
        "name": "edit_file",
10
        "arguments": {
11
          "path": "orders/discount.py",
12
          "patch": "..."
13
        }
14
      }
15
    }
16
  ]
17
}

tool_call_id 是 Tool Call 和 Tool Result 的主键。

OpenAI Responses API 的 Function Call Output 使用 call_id 回指具体 Function Call。⁵ Anthropic 则在 Assistant 的 tool_use Block 中生成 id，后续 User Message 的 tool_result 用 tool_use_id 关联。⁶

Canonical Format 可以统一语义，但导出到目标模型时必须通过 Adapter 转换。

4.4 Tool Result#

Canonical Tool Result：

1
{
2
  "role": "tool",
3
  "tool_call_id": "call_edit_01",
4
  "name": "edit_file",
5
  "content": [
6
    {
7
      "type": "json",
8
      "json": {
9
        "success": true,
10
        "changed_paths": [
11
          "orders/discount.py"
12
        ],
13
        "diff_ref": "artifact://diff/01"
14
      }
15
    }
16
  ],
17
  "is_error": false
18
}

Tool Result 的内容应接近模型真实所见#

如果运行时模型只看到摘要：

1
Patch applied successfully.

训练输入不能替换为完整内部 Diff 和 State Snapshot。

推荐同时保存：

1
model_visible_result
2
raw_result_ref
3
normalization_version

4.5 Environment Observation#

Environment Observation 表示：

1
文件状态
2
数据库状态
3
浏览器状态
4
网络状态
5
审批状态
6
预算状态

Schema：

1
{
2
  "observation_id": "env_obs_031",
3
  "type": "FILESYSTEM_DIFF",
4
  "visibility": "GRADER_ONLY",
5
  "captured_at_step": 9,
6
  "data": {
7
    "changed_paths": [
8
      "orders/discount.py"
9
    ]
10
  },
11
  "artifact_ref": "artifact://state-diff/031"
12
}

若模型运行时通过 Tool 看到该状态，则应在 messages 中保留对应 Tool Result；独立 Environment Observation 仍保留作为验证证据。

4.6 Outcome 与 Score#

Outcome 是环境事实：

1
{
2
  "verified_success": true,
3
  "assertions": {
4
    "target_tests_passed": true,
5
    "regression_tests_passed": true,
6
    "forbidden_paths_unchanged": true
7
  },
8
  "verifier_version": "coding-outcome-v4"
9
}

Score 是对行为或 Outcome 的评价：

1
{
2
  "name": "trajectory_quality",
3
  "target": {
4
    "type": "trajectory",
5
    "id": "traj_001"
6
  },
7
  "value": 3,
8
  "scale": {
9
    "min": 0,
10
    "max": 4
11
  },
12
  "evaluator_version": "trajectory-rubric-v3",
13
  "evidence_refs": [
14
    "step_04",
15
    "step_05"
16
  ]
17
}

Outcome 可用于决定训练候选是否可信；Score 不应自动进入模型 Input。

4.7 Provenance 与版本字段#

每个中间对象至少记录：

1
source_trace_id
2
source_case_id
3
source_observation_ids
4
source_agent_version
5
source_model
6
source_prompt_version
7
source_tool_schema_set
8
source_environment_revision
9
curation_pipeline_version
10
annotation_version
11
split
12
usage_policy
13
content_hash

示例：

1
{
2
  "provenance": {
3
    "source_trace_id": "trace_prod_123",
4
    "source_case_id": "case_discount_003",
5
    "source_agent_version": "agent-3.2.0",
6
    "source_model": "model-x-rev-2026-07",
7
    "source_prompt_version": "planner-v7",
8
    "source_tool_schema_set": "sha256:...",
9
    "source_environment_revision": "repo-abc123",
10
    "transforms": [
11
      "redaction-v6",
12
      "canonicalization-v4",
13
      "visibility-reconstruction-v3"
14
    ]
15
  }
16
}

5. 模型可见上下文重建#

模型可见上下文重建

5.1 只保留运行时模型真实看到的信息#

模型可见输入由以下事实决定：

1
System Prompt
2
消息历史
3
Tool Definition
4
实际注入的 Tool Result
5
实际注入的 Retrieval / Memory
6
Compaction Summary
7
Context Truncation

不是由 Raw Trace 中“存在什么”决定。

Visibility Ledger#

1
{
2
  "step_id": "step_07",
3
  "model_request_id": "modelop_07",
4
  "visible_items": [
5
    {
6
      "item_id": "msg_user_01",
7
      "rendered_hash": "sha256:..."
8
    },
9
    {
10
      "item_id": "tool_result_04",
11
      "rendered_hash": "sha256:..."
12
    }
13
  ],
14
  "tool_schema_set_hash": "sha256:...",
15
  "context_manifest_hash": "sha256:..."
16
}

Training Example 应从 Ledger 重建，而不是从全量 Trace 猜测。

5.2 删除后台内部 Trace 字段#

以下字段通常不进入模型输入：

1
trace_id
2
span_id
3
parent_span_id
4
cost
5
latency
6
provider_request_id
7
collector_metadata
8
incident_severity
9
root_cause
10
reviewer_id
11
internal_risk_score

除非产品运行时明确把某字段作为模型输入。

ID 也可能成为捷径#

如果 Training Example 中保留：

1
case_id = safety_failure_042

模型可能从名称猜到标签。

训练输入应使用无语义随机 ID，或完全不包含这些字段。

5.3 删除 Judge 结论#

删除：

1
judge_score
2
judge_reason
3
gold_label
4
human_correction_comment
5
failure_taxonomy
6
first_error_step

这些可以保留在：

1
labels
2
provenance
3
quality

但不进入 messages。

Judge 的 Evidence 可以转成上下文吗#

只有当该 Evidence 在原运行时已被模型看见，才可保留。

Judge 额外检索的材料不能回填到原模型输入。

5.4 删除未来环境结果#

局部 Step Example 的 Input 只能截止到决策点。

例如训练 Step 4：

1
不能输入 Step 9 的测试失败
2
不能输入最终 State Diff
3
不能输入人工最终 Patch

但这些可用于：

验证 Target；
计算 Label；
选择 Chosen / Rejected；
建立 Evidence。

5.5 恢复消息和 Tool Call 顺序#

顺序恢复优先级：

1
Provider / Runtime Sequence
2
→ Parent / call_id
3
→ Timestamp

不能只按 Timestamp 排序：

并行 Tool 的完成时间与发起顺序不同；
网络时钟可能漂移；
子 Agent Event 可能异步写入；
Batch Export 可能延迟。

Parallel Tool#

Canonical Format 可以在一个 Assistant Message 中包含多个 Tool Call：

1
{
2
  "role": "assistant",
3
  "tool_calls": [
4
    {
5
      "id": "call_a",
6
      "function": {
7
        "name": "read_file",
8
        "arguments": {
9
          "path": "a.py"
10
        }
11
      }
12
    },
13
    {
14
      "id": "call_b",
15
      "function": {
16
        "name": "read_file",
17
        "arguments": {
18
          "path": "b.py"
19
        }
20
      }
21
    }
22
  ]
23
}

后续 Tool Result 必须按 ID 对齐，不要按完成顺序重命名。

5.6 保持 Tool Schema 版本一致#

Tool Call 的合法性依赖运行时 Schema。

历史 Tool Call：

1
{
2
  "tool": "search_code",
3
  "arguments": {
4
    "query": "...",
5
    "path": "orders/"
6
  }
7
}

如果新版 Schema 改成：

1
{
2
  "query": "...",
3
  "include_globs": [
4
    "orders/**"
5
  ]
6
}

不能直接将旧 Call 标成错误。

两个选择：

使用旧 Schema 生成历史兼容 Training Example；
经验证 Migration 后，生成新版等价 Target，并标记 schema_migrated=true。

5.7 处理 Context Compaction 和历史摘要#

这是最容易出现“全知训练数据”的地方。

生产模型在 Compaction 后看到的可能是：

1
Summary + 最近消息

而 Raw Trace 保存了：

1
全部原始历史

训练时如果恢复完整历史，模型得到生产运行时没有的上下文。

正确策略：

1
模型看到 Summary
2
→ Training Input 使用 Summary

原始历史只保留在 Provenance 和分析证据中。

Summary 质量#

需要记录：

1
compaction_id
2
summary_hash
3
derived_from
4
prompt_version
5
model_version
6
retained_constraints

如果生产失败来自 Summary 丢失约束，不能把原始历史补回并将修正动作作为正向训练样本。

应先分类为：

1
COMPACTION / RUNTIME

或者构造专门的：

1
Compaction Summary Training Candidate

其输入是压缩前真实可见历史，Target 是正确 Summary，而不是后续动作。

6. 成功轨迹转化#

6.1 验证最终 Outcome#

成功轨迹必须满足：

1
verified_outcome = true

不能仅依据：

1
final_answer says success
2
tool returned success
3
user gave thumbs up

Coding Agent 至少检查：

Target Tests；
Regression Tests；
Changed Paths；
Forbidden Paths；
Build；
不安全副作用。

成功等级：

1
L0：Agent 声明
2
L1：Tool 声明
3
L2：环境查询
4
L3：独立 Grader
5
L4：多源 + 人工确认

核心成功轨迹建议使用：

1
L3 或 L4

6.2 删除无关噪声步骤#

可删除的噪声：

1
重复读取完全相同内容
2
无信息量的空响应
3
UI-only Event
4
Exporter Metadata
5
与决策无关的 Heartbeat

不能随意删除：

1
导致正确 Tool 选择的检索结果
2
一次失败 Tool Result
3
用户确认
4
安全拒绝
5
Compaction Summary

因果保留原则#

删除 Step 前问：

1
没有它，后续目标行为是否仍有足够依据？

如果不能确定，保留或标记为 optional_context。

6.3 保留必要 Observation#

必要 Observation 包括：

1
事实证据
2
工具返回
3
权限结果
4
当前环境约束
5
错误状态

例如：

1
run_tests → 1 failed

即使整条轨迹最终成功，这个失败结果也可能是后续修正的必要输入。

不要把成功轨迹清洗成“所有步骤都成功”的虚假路径。

6.4 保留正确的工具调用链#

完整 Tool-use 目标：

1
Assistant Tool Call
2
→ Tool Result
3
→ Assistant Next Action

保留：

1
tool_call_id
2
tool_name
3
arguments
4
result
5
order
6
schema_version

如果训练格式丢失 Tool Result，模型只能学到：

1
调用工具

学不到：

1
如何使用工具结果继续行动。

6.5 转为标准多轮 Tool-use 样本#

Canonical Example：

1
{
2
  "messages": [
3
    {
4
      "role": "system",
5
      "content": "You are a coding agent..."
6
    },
7
    {
8
      "role": "user",
9
      "content": "修复 quantity=0 的折扣错误。"
10
    },
11
    {
12
      "role": "assistant",
13
      "tool_calls": [
14
        {
15
          "id": "call_read_01",
16
          "type": "function",
17
          "function": {
18
            "name": "read_file",
19
            "arguments": {
20
              "path": "orders/discount.py"
21
            }
22
          }
23
        }
24
      ]
25
    },
26
    {
27
      "role": "tool",
28
      "tool_call_id": "call_read_01",
29
      "content": "..."
30
    },
31
    {
32
      "role": "assistant",
33
      "tool_calls": [
34
        {
35
          "id": "call_edit_01",
36
          "type": "function",
37
          "function": {
38
            "name": "edit_file",
39
            "arguments": {
40
              "path": "orders/discount.py",
41
              "patch": "..."
42
            }
43
          }
44
        }
45
      ]
46
    },
47
    {
48
      "role": "tool",
49
      "tool_call_id": "call_edit_01",
50
      "content": {
51
        "success": true
52
      }
53
    },
54
    {
55
      "role": "assistant",
56
      "content": "修改已完成，相关测试已通过。"
57
    }
58
  ],
59
  "tools": [
60
    {
61
      "name": "read_file",
62
      "parameters": {}
63
    },
64
    {
65
      "name": "edit_file",
66
      "parameters": {}
67
    }
68
  ]
69
}

最终导出时使用目标模型的 Chat Template。Transformers 文档建议训练时使用模型模板并设置 add_generation_prompt=False。⁸

6.6 成功但低效轨迹是否进入训练集#

成功不等于适合作为正向目标。

低效表现：

1
重复检索
2
无意义长回答
3
多次相同 Tool Call
4
不必要的高成本模型调用
5
先写后读
6
过度确认

处理策略：

轻微冗余#

如果删除冗余后，剩余轨迹仍真实、完整、可验证：

1
可以生成 Pruned Success Example。

必须记录：

1
pruned=true
2
removed_step_ids
3
pruning_policy_version

严重低效#

不应作为完整正向轨迹。

可转成：

Low-quality Candidate；
Preference Pair 的 Rejected；
Step-level Negative；
Efficiency Label。

不能“美化”出未验证轨迹#

如果删掉 Step 后改变了 Tool Result、环境或后续上下文，必须重新 Replay 和验证。

7. 失败轨迹与修正轨迹转化#

从失败轨迹构造修正样本

7.1 定位第一个错误动作#

最后一个 Error 通常不是最早错误。

例：

1
错误检索
2
→ 错误文件
3
→ 错误修改
4
→ 权限拒绝
5
→ 超时

第一个错误可能是：

1
Retrieval Selection

训练候选应从：

1
最后一个正确状态

切出。

推荐字段：

1
first_error_step_id
2
pre_error_checkpoint
3
error_action
4
error_type
5
evidence
6
confidence

7.2 区分模型错误与系统错误#

对 Error Step 做：

1
Model-visible Context Review
2
Runtime Replay
3
Tool Replay
4
Environment Verification

分类：

1
MODEL_ACTION
2
PROMPT
3
TOOL_SCHEMA
4
TOOL_RUNTIME
5
RETRIEVAL
6
MEMORY
7
ORCHESTRATION
8
NETWORK
9
PERMISSION
10
GRADER
11
UNKNOWN

只有 MODEL_ACTION 或明确的模型行为缺口进入修正数据。

UNKNOWN 不应强行转正向样本。

7.3 构造局部修正动作#

局部修正只监督错误点。

1
Input：
2
错误动作前的真实可见 Prefix
3

4
Target：
5
一个可接受的正确动作

示例：

1
{
2
  "prefix": [
3
    {
4
      "role": "user",
5
      "content": "不得修改 payments/"
6
    },
7
    {
8
      "role": "tool",
9
      "content": "Target bug is in orders/discount.py"
10
    }
11
  ],
12
  "rejected_action": {
13
    "tool": "edit_file",
14
    "arguments": {
15
      "path": "payments/service.py"
16
    }
17
  },
18
  "accepted_actions": [
19
    {
20
      "tool": "read_file",
21
      "arguments": {
22
        "path": "orders/discount.py"
23
      }
24
    }
25
  ]
26
}

局部样本适合减少后续错误链带来的噪声。

7.4 构造完整修正轨迹#

完整修正轨迹必须从错误前 Checkpoint 重新执行。

1
Pre-error Checkpoint
2
→ Corrected Action
3
→ Tool Result
4
→ Subsequent Actions
5
→ Verified Outcome

不能只由人工编辑 JSON 拼出“理想路径”后直接使用。

需要：

Tool 真执行；
Result 真返回；
Context 顺序正确；
Outcome 再验证；
Side Effect 检查。

7.5 Before/After 配对#

Before / After 必须共享相同可见 Prefix。

1
{
2
  "prompt": {
3
    "messages": [],
4
    "tools": []
5
  },
6
  "before": {
7
    "assistant_action": {
8
      "tool": "edit_file",
9
      "arguments": {
10
        "path": "payments/service.py"
11
      }
12
    },
13
    "outcome": {
14
      "score": 0
15
    }
16
  },
17
  "after": {
18
    "assistant_action": {
19
      "tool": "read_file",
20
      "arguments": {
21
        "path": "orders/discount.py"
22
      }
23
    },
24
    "outcome": {
25
      "score": 1
26
    }
27
  }
28
}

如果 Prefix 不同，无法把差异归因给动作本身。

7.6 多个可接受修正方案#

不要把一个 Human Fix 当成唯一正确答案。

例如错误后可以：

1
读取目标文件
2
重新搜索
3
向用户确认作用域
4
安全拒绝写操作

只要满足当前状态和 Task Contract，都可能正确。

Schema：

1
{
2
  "accepted_actions": [
3
    {
4
      "action": {},
5
      "constraints": []
6
    },
7
    {
8
      "action": {},
9
      "constraints": []
10
    }
11
  ],
12
  "forbidden_actions": []
13
}

Preference Pair 的 Chosen#

如果存在多个同等合理动作：

不应随意把其他动作标成 Rejected；
可以建立多个 Training Example；
或设置 equivalence_group_id。

7.7 修正结果的二次验证#

修正样本至少经过：

1
Schema Validation
2
Policy Validation
3
Replay
4
Outcome Verification
5
Safety Check
6
Leakage Check
7
Human / Judge Review

修正来源：

1
human
2
expert_agent
3
search
4
rule
5
reference_solution

来源不等于可信度。

例如“更强模型生成的修正”仍需环境验证。

推荐质量等级：

1
VERIFIED_GOLD
2
VERIFIED_ACCEPTABLE
3
UNVERIFIED_CANDIDATE
4
REJECTED

只有前两类进入正式训练集。

8. 可派生的数据形态#

8.1 成功执行轨迹#

结构：

1
完整可见消息
2
完整 Tool-use
3
Verified Outcome
4
Assistant Targets

用于学习端到端行为模式。

必要字段：

1
messages
2
tools
3
target_mask
4
outcome
5
quality
6
provenance

8.2 Tool Selection 样本#

Input：

1
当前消息 Prefix
2
可用 Tool Definitions
3
当前状态

Target：

1
选择 Tool
2
不调用 Tool
3
请求确认

工具选择不是永远调用一个工具。

必须有负向边界：

1
应该回答而不搜索
2
应该拒绝而不写入
3
应该确认而不执行

8.3 Tool Argument 样本#

固定：

1
Tool 已选定

目标：

1
合法、语义正确、权限正确的 Arguments

Schema：

1
{
2
  "context": {},
3
  "tool": {},
4
  "target_arguments": {},
5
  "argument_constraints": {
6
    "required": [],
7
    "forbidden_patterns": []
8
  }
9
}

参数应以结构化 JSON 保存，不应通过字符串差异判断语义正确性。

8.4 失败—修正样本#

包含：

1
真实 Prefix
2
错误动作
3
错误证据
4
正确动作
5
修正验证

错误动作不进入正向 Target。

它可以作为：

Error Analysis；
Preference Data；
Step Label；
Correction Trajectory；

的来源。

8.5 高分—低分候选对#

Preference Pair 的关键不是两个答案分数不同，而是：

1
它们共享同一 Prompt 和 Tool Set
2
差异可归因
3
评分标准一致

字段：

1
prompt
2
chosen
3
rejected
4
criterion
5
score_difference
6
evidence

Hugging Face TRL 将偏好数据表示为显式 prompt 与 chosen / rejected，并支持 Conversational Message 形式。⁹

不适合构造成对的情况#

1
不同环境
2
不同工具版本
3
不同用户目标
4
一个候选因网络失败
5
一个候选因权限错误

这些不是纯行为偏好。

8.6 Step-level Label#

每个 Step 可以有：

1
CORRECT
2
ACCEPTABLE
3
SUBOPTIMAL
4
INCORRECT
5
UNSAFE
6
SYSTEM_INVALID
7
UNKNOWN

同时记录：

1
reason_codes
2
evidence_refs
3
is_first_error

Step Label 不等于 Token Target。

它可以服务分析，也可以进一步派生局部目标。

8.7 Outcome Label#

Outcome Label：

1
SUCCESS
2
PARTIAL
3
FAILURE
4
INVALID_ENVIRONMENT
5
UNVERIFIABLE
6
UNSAFE

必须带：

1
verifier_version
2
assertions
3
evidence

INVALID_ENVIRONMENT 不能当模型失败。

8.8 拒绝、确认和人工升级样本#

Agent 不应永远自主执行。

数据应覆盖：

1
REFUSE
2
ASK_CLARIFICATION
3
REQUEST_CONFIRMATION
4
ESCALATE_HUMAN
5
PROCEED

输入中要有明确风险和权限边界。

目标应说明：

1
拒绝哪个动作
2
需要确认什么
3
向人工传递哪些状态

8.9 故障恢复行为样本#

Input：

1
故障前状态
2
错误结果
3
Attempt 状态
4
已知 Side Effect
5
Retry Budget

Target：

1
RETRY
2
BACKOFF
3
QUERY_STATUS
4
REUSE_RESULT
5
FALLBACK
6
ESCALATE
7
ABORT

示例：

1
{
2
  "input": {
3
    "operation": "create_pull_request",
4
    "tool_result": "connection lost after request sent",
5
    "side_effect_status": "UNKNOWN",
6
    "idempotency_key": "repo42:issue17:create-pr"
7
  },
8
  "target": {
9
    "action": "QUERY_STATUS",
10
    "reason": "Do not blindly replay an unknown write."
11
  }
12
}

9. Target 与 Mask#

Target 与 Mask 规则

9.1 System 和 User 内容作为输入#

在标准 Assistant-only 监督策略中：

1
System Token：Input
2
User Token：Input

它们参与上下文，但不作为模型生成 Target。

Token Label：

1
-100 / IGNORE

Hugging Face Transformers 可以通过支持 {% generation %} 的 Chat Template 返回 Assistant Token Mask；TRL 的 assistant_only_loss 依赖该 Mask，只计算 Assistant 部分。¹⁰¹¹

本文不讨论 Loss 算法，只强调：

数据层必须能精确标出哪些 Token 属于目标。

9.2 Tool Result 作为观察证据#

Tool Result 通常是 Input Evidence：

1
Model 不负责生成真实工具返回。

因此：

1
Tool Result Tokens
2
→ mask = 0 / IGNORE

但它必须在正确顺序中出现，使模型学习：

1
看到 Result 后如何继续。

例外#

如果训练目标是 Tool Result Summarization，目标可以是 Assistant 对 Result 的摘要，而不是原 Tool Result。

9.3 Assistant Action 和最终回答作为目标#

目标包括：

1
Assistant Text
2
Assistant Tool Call Name
3
Assistant Tool Arguments
4
Assistant Refusal
5
Assistant Confirmation
6
Final Answer

模型是否要学习 Assistant 的所有历史消息，由样本设计决定。

全轨迹 Target#

1
所有已验证 Assistant 动作

单步 Target#

1
仅最后一个 Assistant 动作

两者应显式标记：

1
target_scope = FULL_TRAJECTORY | LAST_ACTION | SELECTED_STEPS

9.4 错误动作不能进入正向 Target#

原失败 Trace 中：

1
Assistant 错误 Tool Call

不能保留 mask=1。

选择：

从消息中删除错误 Branch，使用验证后的修正轨迹；
保留错误动作在 rejected 字段，不放入 Positive Messages；
将错误动作 Token Mask 设为 Ignore，并只监督修正后的局部动作；
建立 Step Label，但不做正向生成 Target。

最危险的做法是：

1
为了保持 Trace 完整，
2
对所有 Assistant Message 统一 mask=1。

这会让模型同时学习错误和修正。

9.5 环境内部字段不进入模型输入#

以下字段默认排除：

1
Hidden Test
2
Gold
3
Judge Reason
4
Human Adjudication
5
Root Cause
6
Future State
7
Private Policy Internal ID
8
Secret
9
Raw Database Snapshot

如果需要把环境信息提供给模型，应通过生产中真实存在的接口：

1
Tool Result
2
User Message
3
System Instruction

而不是直接注入 Grader Object。

9.6 部分轨迹只监督局部动作#

Local Correction Example：

1
Prefix：输入
2
Error Action：Rejected Metadata
3
Correct Action：Target
4
Future Trace：Verification Evidence

Message-level Mask：

Message	Role	Target
System	system	0
User	user	0
Earlier Assistant	assistant	0
Tool Result	tool	0
Corrected Assistant Action	assistant	1

Token-level 需要目标模型 Chat Template 正确返回 Assistant Boundary。

Transformers 的 return_assistant_tokens_mask 会将 Assistant 生成 Token 标为 1，System 和 User 标为 0，但仅对支持 {% generation %} 的模板有效。¹⁰

不要手写字符串搜索 Mask#

例如搜索：

1
"<|assistant|>"

可能因：

模板版本；
多模态 Content；
Tool Call Block；
Reasoning Block；
Special Token；

产生错位。

Mask 必须由目标 Tokenizer 和 Chat Template 生成，并做 Round-trip 测试。

10. 数据质量门槛#

10.1 Outcome 可验证#

要求：

1
outcome_verification_level >= threshold

核心正向轨迹：

1
L3 独立 Grader
2
或 L4 多源 + 人工

不接受：

1
仅模型声明
2
仅 Tool "success"

10.2 Trace 完整#

完整性检查：

1
消息顺序
2
Tool Call / Result
3
可见性
4
版本
5
Compaction
6
Final State

缺失关键节点：

1
REJECT
2
或降粒度

不要用生成模型猜测缺失 Tool Result 后仍标为 Gold。

10.3 工具调用合法#

检查：

1
Schema Valid
2
Tool Version Valid
3
Permission Valid
4
State Preconditions Valid
5
call_id Pair Valid

正向 Tool Call 必须通过全部检查。

10.4 修正结果可靠#

修正需：

1
Replay
2
Outcome Verification
3
Safety Scan
4
Human / Judge Review

更强模型生成的修正不是自动 Gold。

10.5 样本长度与上下文预算合理#

检查：

1
token_count
2
tool_definition_tokens
3
tool_result_tokens
4
max_context
5
truncation

如果样本超过目标模型 Context：

不得从尾部随意截断；
应按因果依赖裁剪；
或拆成局部 Step Example；
或使用生产 Compaction Summary。

记录：

1
length_transform
2
removed_items
3
retained_invariants

10.6 去重和多样性#

去重层次：

1
Exact
2
Lexical
3
Semantic
4
Task Template
5
Trajectory
6
Entity

同时监控多样性：

1
任务
2
工具
3
失败类型
4
语言
5
难度
6
恢复路径
7
安全边界

去重不能把长尾全部删除。

10.7 标签一致性#

自动 Label、Judge、Human 和 Outcome 之间需检查：

1
conflict

例如：

1
Outcome = success
2
Safety Grader = unsafe

最终状态应是：

1
UNSAFE

而不是简单平均。

核心 Label 建议双标或专家审核。

10.8 隐私和授权合规#

检查：

1
training_use_allowed
2
human_annotation_allowed
3
external_model_allowed
4
retention
5
data_residency
6
deletion_propagation
7
license

OpenAI API 数据控制文档也区分客户内容的存储、保留和是否用于训练；企业在建立自己的训练集时同样需要独立记录用途授权，而不能因为数据曾用于 API 推理就自动获得训练权。¹²

数据集文档应说明：

动机；
构成；
收集和处理；
推荐用途；
限制；
分发；
维护。

这与 Datasheets for Datasets 提出的透明度要求一致。¹³ Hugging Face Dataset Card 也建议记录 License、Language、Size、用途和潜在偏差。¹⁴

11. 数据筛选与配比#

不存在适用于所有 Agent 的固定比例。

配比应由：

1
生产分布
2
行为缺口
3
风险
4
工具覆盖
5
训练目标

共同决定。

11.1 成功与失败样本比例#

成功轨迹#

提供：

1
正向完整行为
2
Tool Result 使用
3
终止条件
4
最终回答

失败样本#

不能原样作为 Positive。

失败可派生：

Rejected Action；
Correction；
Step Label；
Outcome Label；
Recovery Example。

推荐按“派生对象”统计，而不是用原 Trace 数统计。

一条失败 Trace 可能派生 4 条局部修正，但它们应共享 Group Weight，避免事故样本被放大。

11.2 简单任务和困难任务比例#

简单任务作用：

稳定基础行为；
保持格式；
覆盖头部流量；
防止复杂数据主导。

困难任务作用：

训练边界；
多工具；
长轨迹；
故障恢复；
高风险决策。

难度不应只按 Token 长度。

可使用：

1
Baseline Success
2
Human Time
3
Tool Count
4
Constraint Count
5
Environment Complexity

11.3 工具类型覆盖#

覆盖：

1
read-only
2
reversible write
3
irreversible write
4
retrieval
5
memory
6
MCP
7
browser
8
shell
9
approval

每种工具还要有：

1
should_call
2
should_not_call
3
invalid_arguments
4
error_result
5
recovery

否则模型会过度调用高频工具。

11.4 正常路径和恢复路径覆盖#

正常路径占生产主体。

恢复路径覆盖：

1
429
2
5xx
3
disconnect
4
timeout
5
permission denied
6
stale state
7
unknown side effect

恢复数据不宜完全合成，应保留经过脱敏和重建的真实案例。

11.5 真实数据与合成数据比例#

真实数据擅长：

1
自然任务
2
真实工具组合
3
真实失败
4
真实成本和噪声

合成数据擅长：

1
稀有边界
2
组合覆盖
3
故障注入
4
安全红队

11.6 防止高频模板主导数据集#

策略：

1
Per-template Cap
2
Cluster Weight
3
Per-user Cap
4
Per-incident Cap
5
Macro-balanced Sampling

示例 Manifest：

1
sampling_policy:
2
  max_examples_per_task_template: 500
3
  max_examples_per_incident_cluster: 20
4
  max_examples_per_user_group: 50
5

6
  minimum_coverage:
7
    recovery_error: 200
8
    safety_error: 200
9
    tool_argument_error: 400

这些数字只是配置示例，不是通用推荐值。

12. 防止训练—评测污染#

训练评测污染控制与 Provenance 防火墙

12.1 冻结 Eval Holdout#

建立 Holdout Registry：

1
case_id
2
source_trace_id
3
semantic_cluster_id
4
entity_group_id
5
fixture_hash
6
gold_hash

Build Training Dataset 时先加载 Denylist。

1
if candidate.source_case_id in holdout_case_ids:
2
    reject("HOLDOUT_CASE")
3

4
if candidate.semantic_cluster_id in holdout_clusters:
5
    reject("HOLDOUT_NEAR_DUPLICATE")

12.2 测试 Trace 禁止回流训练#

运行 Eval 产生的 Trace 也不能自动进入 Production Failure Mining。

标记：

1
trace_origin = EVAL
2
evaluation_split = TEST_HOLDOUT
3
training_use = DENY

数据管道必须按 Origin 过滤。

否则：

1
跑一次 Test
2
→ 失败 Trace 被挖掘
3
→ 修正后进入训练
4
→ 再跑同一 Test

形成闭环污染。

12.3 近重复检测#

检查对象：

1
User Input
2
System Prompt
3
Tool Definitions
4
Tool Sequence
5
Tool Arguments
6
Tool Results
7
Reference Output
8
Environment Fixture
9
Gold Patch

方法：

1
Exact Hash
2
MinHash / Shingle
3
Embedding
4
Trajectory Fingerprint
5
AST / Patch Similarity
6
Entity Group

Cross-split 检查比 Split 内去重更重要。

12.4 按时间、用户、仓库和任务来源隔离#

Group Keys：

1
time_window
2
user_group
3
tenant
4
repository
5
website
6
business_entity
7
task_template
8
incident_cluster

同一 Group 不跨训练与 Holdout。

Coding 场景尤其需要：

1
repository_id
2
file_family
3
issue_cluster
4
patch_cluster

随机行级切分会严重泄漏。

12.5 Judge Prompt 与 Gold 答案隔离#

Judge Prompt、Rubric 和 Gold 只能进入：

1
annotation / evaluation plane

不能进入：

1
model input
2
training prompt examples
3
few-shot prompt
4
synthetic data generator context

Synthetic Generator 如果看到 Holdout Gold，也会间接污染训练。

建议网络和权限层分开：

1
Training Builder Role
2
Eval Grader Role
3
Holdout Custodian Role

12.6 全链路 Provenance 审计#

每条 Training Example 可回溯：

1
Source Trace
2
→ Curated Trace
3
→ Evaluation Case
4
→ Correction Activity
5
→ Example
6
→ Dataset Build

Build-time Audit：

1
授权检查
2
Holdout 检查
3
近重复检查
4
版本检查
5
Mask 检查
6
可见性检查
7
Schema 检查
8
Checksum

审计报告：

1
{
2
  "dataset_build_id": "build_2026_08_06",
3
  "input_candidates": 120000,
4
  "accepted_examples": 38000,
5
  "rejected": {
6
    "holdout": 1820,
7
    "near_duplicate": 41100,
8
    "privacy": 420,
9
    "unverifiable": 9800,
10
    "system_error": 28860
11
  },
12
  "auditor_version": "training-data-audit-v5"
13
}

13. 数据闭环#

13.1 Production Trace#

生产 Trace 提供：

1
真实输入
2
真实工具
3
真实失败
4
真实成本

但只进入候选池。

13.2 Failure Mining#

发现：

1
用户差评
2
人工接管
3
事故
4
高成本
5
恢复失败
6
新回归

并完成 Root Cause Routing。

13.3 Evaluation Case#

将候选重建为：

1
Task Contract
2
Frozen Environment
3
Tool Set
4
Ground Truth
5
Grader

Case 可以进入 Regression Dataset，但未必能训练。

13.4 Human/Judge Annotation#

产生：

1
First Error
2
Accepted Correction
3
Step Label
4
Preference
5
Outcome Label

Judge 必须与人工 Gold 校准。

13.5 Training Candidate#

经过：

1
Training Suitability
2
Visibility Reconstruction
3
Correction Verification
4
Holdout Check

后才成为 Candidate。

13.6 Training Dataset#

Dataset Build 执行：

1
Schema Conversion
2
Target / Mask
3
Dedup
4
Balance
5
Split
6
Provenance
7
Manifest

并输出不可变版本。

13.7 新 Agent 版本#

新版本可能包含：

1
新模型权重
2
新 Prompt
3
新 Tool Schema
4
新 Runtime

必须在 Manifest 中分别记录，不要把所有变化归因于训练。

13.8 Offline Evaluation#

使用冻结：

1
Core Regression
2
Safety Holdout
3
Fresh Temporal Holdout

验证。

训练数据和 Eval Holdout 通过 Source、Cluster、Entity 和 Fixture 隔离。

13.9 Canary 发布#

Canary 监控：

1
Verified Success
2
Unsafe Side Effect
3
Cost
4
Latency
5
Recovery
6
User Feedback

并与 Baseline 对照。

13.10 新 Production Trace#

新 Trace 再次进入候选池。

闭环必须是：

1
开放候选池
2
+ 冻结评测边界

而不是：

1
所有失败都训练
2
所有测试都回流

14. 最终数据契约#

下面给出一组算法无关的最终数据契约。

实际工程中建议使用 JSON Schema Draft 2020-12 校验，并将 Provider-specific 格式转换放在 Adapter 层。

14.1 Evaluation Case Schema#

1
{
2
  "schema_type": "evaluation_case",
3
  "schema_version": "1.0.0",
4
  "case_id": "case_discount_003",
5
  "case_version": 3,
6
  "granularity": "TASK",
7

8
  "agent_visible": {
9
    "system": {
10
      "content": "You are a coding agent...",
11
      "prompt_version": "system-v5"
12
    },
13
    "user_goal": {
14
      "content": "修复 quantity=0 的折扣错误。",
15
      "must": [
16
        "相关测试通过"
17
      ],
18
      "must_not": [
19
        "修改 payments/**"
20
      ]
21
    },
22
    "tools": [
23
      {
24
        "name": "read_file",
25
        "description": "Read a workspace file.",
26
        "parameters": {
27
          "type": "object",
28
          "properties": {
29
            "path": {
30
              "type": "string"
31
            }
32
          },
33
          "required": [
34
            "path"
35
          ]
36
        },
37
        "schema_version": "2.0.0"
38
      }
39
    ],
40
    "budgets": {
41
      "max_wall_time_seconds": 600,
42
      "max_model_calls": 20,
43
      "max_tool_calls": 60,
44
      "max_cost_usd": 2.0
45
    }
46
  },
47

48
  "environment": {
49
    "fixture_id": "fixture_discount_003",
50
    "revision": "repo-abc123",
51
    "container_digest": "sha256:...",
52
    "clock": "2026-08-01T00:00:00Z"
53
  },
54

55
  "grader_only": {
56
    "expected_outcome": {
57
      "target_tests_passed": true,
58
      "regression_tests_passed": true,
59
      "forbidden_paths_unchanged": true
60
    },
61
    "hidden_tests_ref": "private://tests/discount-003",
62
    "reference_solution_ref": "private://gold/discount-003",
63
    "rubric_version": "coding-task-v4"
64
  },
65

66
  "usage_policy": {
67
    "evaluation": "ALLOWED",
68
    "training": "DENIED_HOLDOUT",
69
    "human_annotation": "ALLOWED_INTERNAL",
70
    "external_judge": "DENIED"
71
  },
72

73
  "provenance": {
74
    "source_trace_ids": [
75
      "trace_prod_123"
76
    ],
77
    "source_observation_ids": [
78
      "obs_agent_root"
79
    ],
80
    "curation_pipeline_version": "eval-case-builder-v6"
81
  }
82
}

14.2 Tool-use Trajectory Schema#

1
{
2
  "schema_type": "tool_use_trajectory",
3
  "schema_version": "1.0.0",
4
  "example_id": "traj_discount_003",
5

6
  "messages": [
7
    {
8
      "id": "msg_01",
9
      "role": "system",
10
      "content": [
11
        {
12
          "type": "text",
13
          "text": "You are a coding agent."
14
        }
15
      ],
16
      "target": false
17
    },
18
    {
19
      "id": "msg_02",
20
      "role": "user",
21
      "content": [
22
        {
23
          "type": "text",
24
          "text": "修复 quantity=0 的折扣错误。"
25
        }
26
      ],
27
      "target": false
28
    },
29
    {
30
      "id": "msg_03",
31
      "role": "assistant",
32
      "content": [],
33
      "tool_calls": [
34
        {
35
          "id": "call_read_01",
36
          "type": "function",
37
          "function": {
38
            "name": "read_file",
39
            "arguments": {
40
              "path": "orders/discount.py"
41
            }
42
          }
43
        }
44
      ],
45
      "target": true
46
    },
47
    {
48
      "id": "msg_04",
49
      "role": "tool",
50
      "tool_call_id": "call_read_01",
51
      "content": [
52
        {
53
          "type": "artifact_ref",
54
          "ref": "artifact://tool-result/read-01"
55
        }
56
      ],
57
      "target": false
58
    },
59
    {
60
      "id": "msg_05",
61
      "role": "assistant",
62
      "content": [
63
        {
64
          "type": "text",
65
          "text": "我将修改边界条件并运行测试。"
66
        }
67
      ],
68
      "target": true
69
    }
70
  ],
71

72
  "tools": [
73
    {
74
      "name": "read_file",
75
      "schema_version": "2.0.0",
76
      "definition_hash": "sha256:..."
77
    }
78
  ],
79

80
  "target_policy": {
81
    "scope": "FULL_TRAJECTORY",
82
    "assistant_only": true,
83
    "tool_results_as_input": true,
84
    "wrong_actions_in_target": false
85
  },
86

87
  "outcome": {
88
    "verified_success": true,
89
    "verification_level": "L3"
90
  },
91

92
  "quality": {
93
    "tier": "VERIFIED_GOLD",
94
    "trajectory_score": 4,
95
    "safety_pass": true
96
  },
97

98
  "provenance": {
99
    "source_case_id": "case_discount_003",
100
    "source_trace_id": "trace_prod_123",
101
    "derivation_group_id": "derive_discount_003",
102
    "visibility_manifest_hash": "sha256:...",
103
    "transform_version": "trajectory-builder-v5"
104
  }
105
}

14.3 Failure-correction Schema#

1
{
2
  "schema_type": "failure_correction",
3
  "schema_version": "1.0.0",
4
  "example_id": "corr_discount_007",
5

6
  "prefix": {
7
    "messages": [
8
      {
9
        "role": "user",
10
        "content": "不得修改 payments/**。"
11
      },
12
      {
13
        "role": "tool",
14
        "tool_call_id": "call_search_01",
15
        "content": "Bug is located in orders/discount.py"
16
      }
17
    ],
18
    "tools_ref": "toolset://coding-v4",
19
    "context_hash": "sha256:..."
20
  },
21

22
  "failure": {
23
    "step_id": "step_04",
24
    "is_first_error": true,
25
    "root_cause": "MODEL_ACTION",
26
    "error_type": "TOOL_ARGUMENT_POLICY",
27
    "action": {
28
      "tool": "edit_file",
29
      "arguments": {
30
        "path": "payments/service.py",
31
        "patch": "..."
32
      }
33
    },
34
    "evidence_refs": [
35
      "task-contract://must-not/payments"
36
    ]
37
  },
38

39
  "corrections": [
40
    {
41
      "correction_id": "fix_01",
42
      "action": {
43
        "tool": "read_file",
44
        "arguments": {
45
          "path": "orders/discount.py"
46
        }
47
      },
48
      "acceptance": "VERIFIED",
49
      "verification_run_id": "replay_092"
50
    }
51
  ],
52

53
  "full_corrected_trajectory_ref": "trajectory://corrected/discount-007",
54

55
  "verification": {
56
    "schema_valid": true,
57
    "policy_valid": true,
58
    "replay_passed": true,
59
    "outcome_passed": true,
60
    "safety_passed": true
61
  },
62

63
  "target_policy": {
64
    "error_action_positive_target": false,
65
    "correction_positive_target": true,
66
    "supervision_scope": "LOCAL_ACTION"
67
  },
68

69
  "provenance": {
70
    "source_trace_id": "trace_prod_456",
71
    "annotator_ids": [
72
      "ann_internal_01",
73
      "ann_internal_02"
74
    ],
75
    "adjudication_id": "adj_014"
76
  }
77
}

14.4 Preference Pair Schema#

1
{
2
  "schema_type": "preference_pair",
3
  "schema_version": "1.0.0",
4
  "pair_id": "pair_discount_011",
5

6
  "prompt": {
7
    "messages": [
8
      {
9
        "role": "system",
10
        "content": "You are a coding agent."
11
      },
12
      {
13
        "role": "user",
14
        "content": "修复 orders/ 中的折扣错误，不得修改 payments/。"
15
      }
16
    ],
17
    "tools_ref": "toolset://coding-v4",
18
    "context_hash": "sha256:..."
19
  },
20

21
  "chosen": {
22
    "messages": [
23
      {
24
        "role": "assistant",
25
        "tool_calls": [
26
          {
27
            "id": "call_01",
28
            "function": {
29
              "name": "read_file",
30
              "arguments": {
31
                "path": "orders/discount.py"
32
              }
33
            }
34
          }
35
        ]
36
      }
37
    ],
38
    "score": 1.0,
39
    "outcome_ref": "outcome://chosen/011"
40
  },
41

42
  "rejected": {
43
    "messages": [
44
      {
45
        "role": "assistant",
46
        "tool_calls": [
47
          {
48
            "id": "call_02",
49
            "function": {
50
              "name": "edit_file",
51
              "arguments": {
52
                "path": "payments/service.py",
53
                "patch": "..."
54
              }
55
            }
56
          }
57
        ]
58
      }
59
    ],
60
    "score": 0.0,
61
    "outcome_ref": "outcome://rejected/011"
62
  },
63

64
  "comparison": {
65
    "criterion": "POLICY_COMPLIANCE",
66
    "same_visible_context": true,
67
    "same_environment_revision": true,
68
    "same_tool_schema_set": true,
69
    "score_margin": 1.0,
70
    "evidence_refs": [
71
      "task-contract://must-not/payments"
72
    ]
73
  },
74

75
  "provenance": {
76
    "source_case_id": "case_discount_003",
77
    "pair_builder_version": "preference-builder-v4"
78
  }
79
}

14.5 Step Label Schema#

1
{
2
  "schema_type": "step_label",
3
  "schema_version": "1.0.0",
4
  "label_id": "step_label_091",
5

6
  "trajectory_id": "traj_discount_fail_02",
7
  "step_id": "step_04",
8

9
  "visible_context_ref": "context://traj_discount_fail_02/step_04",
10
  "action": {
11
    "type": "TOOL_CALL",
12
    "tool": "edit_file",
13
    "arguments": {
14
      "path": "payments/service.py",
15
      "patch": "..."
16
    }
17
  },
18

19
  "label": "UNSAFE",
20
  "is_first_error": true,
21
  "reason_codes": [
22
    "FORBIDDEN_PATH",
23
    "SCOPE_VIOLATION"
24
  ],
25
  "confidence": 0.99,
26

27
  "evidence_refs": [
28
    "task-contract://must-not/payments",
29
    "artifact://state-before/step-04"
30
  ],
31

32
  "annotation": {
33
    "automatic_label": "UNSAFE",
34
    "judge_label": "UNSAFE",
35
    "human_labels": [
36
      "UNSAFE",
37
      "UNSAFE"
38
    ],
39
    "adjudicated": true,
40
    "rubric_version": "step-rubric-v3"
41
  },
42

43
  "usage": {
44
    "analysis_allowed": true,
45
    "positive_target_allowed": false,
46
    "rejected_candidate_allowed": true
47
  },
48

49
  "provenance": {
50
    "source_trace_id": "trace_prod_999",
51
    "source_observation_id": "obs_tool_04"
52
  }
53
}

14.6 Dataset Provenance Manifest#

1
dataset:
2
  id: agent-training-bridge
3
  version: 2026-08-06.1
4
  schema_version: 1.0.0
5
  build_id: build_2026_08_06_01
6
  created_at: 2026-08-06T12:00:00Z
7
  owner: agent-data-team
8

9
purpose:
10
  - tool_use_behavior
11
  - failure_correction
12
  - safe_escalation
13
  - recovery_behavior
14

15
explicit_non_purpose:
16
  - evaluation_holdout
17
  - hidden_test_training
18
  - grader_prompt_training
19

20
source:
21
  production_trace_window:
22
    start: 2026-05-01
23
    end: 2026-07-31
24

25
  allowed_origins:
26
    - PRODUCTION
27
    - EXPERT_CONSTRUCTED
28
    - SYNTHETIC_BOUNDARY
29

30
  denied_origins:
31
    - EVAL_TEST_HOLDOUT
32
    - JUDGE_CALIBRATION_HOLDOUT
33

34
schemas:
35
  canonical_conversation: canonical-agent-conversation-v4
36
  tool_use_trajectory: 1.0.0
37
  failure_correction: 1.0.0
38
  preference_pair: 1.0.0
39
  step_label: 1.0.0
40

41
transforms:
42
  - name: redaction
43
    version: pii-secret-redaction-v6
44

45
  - name: canonicalization
46
    version: provider-canonicalizer-v4
47

48
  - name: visibility_reconstruction
49
    version: visibility-ledger-v3
50

51
  - name: correction_verification
52
    version: correction-replay-v5
53

54
  - name: target_mask
55
    version: target-mask-builder-v4
56

57
quality_gates:
58
  minimum_outcome_verification_level: L3
59
  require_complete_tool_pairs: true
60
  require_tool_schema_version: true
61
  require_visibility_manifest: true
62
  require_training_authorization: true
63
  allow_unknown_root_cause: false
64

65
deduplication:
66
  exact_hash: true
67
  lexical_minhash: true
68
  semantic_embedding_model: embedding-model-v3
69
  semantic_threshold: 0.94
70
  trajectory_fingerprint: tool-dag-v2
71
  group_keys:
72
    - tenant_group
73
    - user_group
74
    - repository
75
    - task_template
76
    - incident_cluster
77
    - derivation_group_id
78

79
holdout_protection:
80
  registry_version: holdout-registry-2026-08
81
  deny_source_case_ids: true
82
  deny_source_trace_ids: true
83
  deny_semantic_clusters: true
84
  deny_fixture_hashes: true
85
  cross_split_scan_passed: true
86

87
composition:
88
  effective_example_count: 38210
89

90
  by_type:
91
    tool_use_trajectory: 14200
92
    tool_selection: 7200
93
    tool_argument: 6100
94
    failure_correction: 4800
95
    preference_pair: 2100
96
    step_label: 2400
97
    refusal_confirmation_handoff: 800
98
    recovery_behavior: 610
99

100
  by_source:
101
    production: 0.72
102
    expert_constructed: 0.16
103
    synthetic_boundary: 0.12
104

105
privacy:
106
  training_use_reviewed: true
107
  external_processor_allowed: false
108
  data_residency: JP
109
  retention_days: 365
110
  deletion_propagation_supported: true
111
  license_review_version: license-review-v2
112

113
artifacts:
114
  dataset_files:
115
    - path: data/tool_use.jsonl
116
      sha256: "..."
117

118
    - path: data/failure_correction.jsonl
119
      sha256: "..."
120

121
  dataset_card:
122
    path: README.md
123
    sha256: "..."
124

125
audit:
126
  build_auditor_version: training-data-audit-v5
127
  mask_roundtrip_tests_passed: true
128
  tool_call_pair_tests_passed: true
129
  holdout_tests_passed: true
130
  privacy_tests_passed: true
131
  signed_by: data-release-service

最小实施检查表#

问题路由#

已确认不是 Prompt 问题
已确认不是 Tool Schema 问题
已确认不是 Agent Runtime 问题
已确认不是网络、权限或环境问题
已确认模型看到了必要信息
模型行为错误可稳定复现

上下文重建#

仅保留模型真实可见信息
删除 Judge、Gold 和 Future Outcome
Tool Call / Result 通过 ID 配对
Tool Schema 版本一致
Context Compaction 按真实 Summary 重建
Visibility Manifest 完整

Target 与 Mask#

System / User 为输入
Tool Result 为输入证据
正确 Assistant Action 为 Target
错误 Assistant Action 不进入正向 Target
局部样本只监督目标 Step
Mask 由目标 Chat Template 生成并验证

质量与污染#

Outcome 独立可验证
修正轨迹已 Replay
Tool Call 合法
样本长度符合 Context
文本、轨迹、实体和 Fixture 去重
Eval Holdout Denylist 检查通过
Judge Prompt 和 Gold 未泄漏
数据用途授权和隐私检查通过
Source Trace 到 Dataset 的血缘完整

结语#

从评测数据桥接到 Agent 后训练数据，真正的核心不是把 JSON 字段改名，而是重建一条模型当时真正能看到、真正应该学到、且不会污染评测边界的行为记录。

一条合格 Training Example 必须回答：

1
这个问题真的需要模型学习吗
2
模型当时看到了什么
3
正确行为是什么
4
错误行为为什么错误
5
Tool Call 与 Tool Result 是否一致
6
修正是否在真实环境中验证
7
哪些 Token 是输入
8
哪些 Token 是目标
9
这条样本是否与 Holdout 重复
10
它从哪条 Trace 和哪次转换派生

本文可以归纳为九条原则。

Evaluation Case 面向判定，Training Example 面向行为。
先修系统，再考虑训练。
Prompt、Tool、Runtime、Retrieval、权限和环境问题不应伪装成模型能力问题。
模型可见性是数据边界。
Raw Trace 中存在的字段，不等于模型运行时可见。
未来信息永远不进入 Input。
Judge、Gold、最终 Outcome 和人工修复只能用于 Label 与验证。
错误轨迹不能直接成为正向轨迹。
必须定位首个错误、构造修正并二次验证。
Tool-use 样本必须保留调用契约。
Tool Definition、Call ID、Arguments、Result 和顺序缺一不可。
Target 与 Mask 必须由目标模型模板生成。
不能依赖脆弱的字符串搜索。
训练集与评测 Holdout 必须物理隔离。
Source Trace、语义簇、仓库、Fixture 和 Gold 都要参与污染检查。
每条样本必须有血缘。
从 Raw Trace 到 Dataset Build 的每一次有损转换都应可审计。

最终的数据闭环不是：

1
Eval 失败
2
→ 把失败 Trace 加进训练

而是：

1
Eval / Production 失败
2
→ Root Cause Routing
3
→ 可见上下文重建
4
→ 修正动作验证
5
→ Target 与 Mask
6
→ Holdout / Dedup / Privacy Gate
7
→ Versioned Training Dataset
8
→ 新 Agent
9
→ Frozen Evaluation

只有坚持这条链，评测数据才能成为可靠的训练资产，而不会反过来摧毁评测可信度。

参考资料#

OpenAI API Documentation. Model optimization. https://developers.openai.com/api/docs/guides/model-optimization ↩
Anthropic Engineering. Demystifying evals for AI agents. Published January 9, 2026. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents ↩
Lee, K. et al. Deduplicating Training Data Makes Language Models Better. ACL 2022. https://aclanthology.org/2022.acl-long.577/ ↩
Jain, N. et al. LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code. ICLR 2025. https://proceedings.iclr.cc/paper_files/paper/2025/hash/94074dd5a072d28ff75a76dabed43767-Abstract-Conference.html ↩
OpenAI API Documentation. Function calling. The Responses API represents model calls as function_call items and returns tool results as function_call_output items linked by call_id. https://developers.openai.com/api/docs/guides/function-calling ↩ ↩²
Anthropic Documentation. Define tools / Implement tool use. Claude emits tool_use blocks with an ID, name and input; client results return in tool_result blocks linked by tool_use_id. https://platform.claude.com/docs/en/agents-and-tools/tool-use/define-tools ↩ ↩²
W3C Recommendation. PROV-O: The PROV Ontology. https://www.w3.org/TR/prov-o/ ↩
Hugging Face Transformers Documentation. Chat templates. Conversation messages are converted to model-specific token sequences using the tokenizer’s chat template. https://huggingface.co/docs/transformers/chat_templating ↩ ↩²
Hugging Face TRL Documentation. Dataset formats and types. Covers Standard and Conversational prompt-completion, preference and tool-calling data objects. https://huggingface.co/docs/trl/en/dataset_formats ↩
Hugging Face Transformers Documentation. Tokenizer apply_chat_template. return_assistant_tokens_mask marks Assistant-generated tokens for templates that support the {% generation %} region. https://huggingface.co/docs/transformers/main_classes/tokenizer ↩ ↩²
Hugging Face TRL Documentation. SFT Trainer. Documents assistant_only_loss and completion_only_loss as consumers of Assistant / Completion masks. https://huggingface.co/docs/trl/en/sft_trainer ↩
OpenAI API Documentation. Data controls in the OpenAI platform. https://platform.openai.com/docs/models/default-usage-policies-by-endpoint ↩
Gebru, T. et al. Datasheets for Datasets. Communications of the ACM / arXiv:1803.09010. https://arxiv.org/abs/1803.09010 ↩
Hugging Face Hub Documentation. Dataset Cards. https://huggingface.co/docs/hub/en/datasets-cards ↩

第 9 篇：从评测数据桥接到 Agent 后训练数据

https://jupiter-ws.cn/posts/agent-observability/09-evaluation-to-agent-training-data/

作者

Jupiter

发布于

2026-08-06

许可协议

CC BY-NC-SA 4.0