Agent 微调工程：从工具轨迹到 SFT、偏好优化与强化学习

本文是精英 Agent 工程师学习路线：从范式理解到生产级落地阶段 9 的配套学习笔记。核心结论：微调只能优化模型行为分布，不能替代实时知识、权限、事务、工具执行和 Harness。先修 Prompt、Schema、RAG、Tool 与 Eval；只有稳定、重复、可标注、可验证的行为瓶颈才值得进入训练。

0. 学习目标、范围与证据边界#

学完本文后，你应该能够：

判断问题该由 Prompt、RAG、Tool、Workflow、模型路由还是微调解决；
区分 SFT、LoRA/QLoRA、DPO、蒸馏、Rejection Sampling 与 RFT；
将 Agent Run 转成无 Secret、无泄漏、可复现的多轮轨迹样本；
设计 tool selection、arguments、trajectory、final outcome 和 safety 标签；
构造高质量正例、困难负例、偏好对和可执行环境；
避免模板、用户、订单、工具版本和合成器造成数据泄漏；
对 assistant/action token 做正确 loss mask，不训练模型复述工具结果；
设计防 reward hacking 的分层 Reward 与硬门禁；
比较 prompt-only 强模型、prompt-only 小模型、SFT、DPO/RFT 的净收益；
用 Model/Adapter/Data/Prompt/Tool/Eval 全版本链路安全发布。

本文引用的论文指标属于作者在特定模型、数据和 Benchmark 上的报告，不能直接外推到 OrderFlow-Agent。微调的收益必须由本地冻结测试集、真实环境状态和安全指标证明。

1. 先做问题归因#

1.1 决策表#

症状	优先修复	不应先微调的原因
最新规则答错	RAG/Rule Engine	权重知识难实时更新
工具参数格式错	Structured Output/Schema	解码约束更直接
调错相似工具	Tool 描述/候选剪枝/Eval	候选集与接口可能有问题
越权调用	Authz/Policy/HITL	模型权重不是权限系统
长任务丢状态	Checkpoint/Context	属于 Runtime 问题
固定语气不稳定	SFT 候选	稳定重复行为
小模型不会领域术语	SFT/continued pretraining 候选	需区分知识与行为
工具选择有稳定模式	SFT/DPO/RFT 候选	可从轨迹学习
成本过高	蒸馏/小模型 SFT 候选	有强模型教师和评估集

1.2 微调前置门槛#

1
任务定义稳定
2
工具/Schema/Policy 版本稳定
3
有可重复 baseline
4
有独立 eval set
5
有足够高质量数据
6
能定义成功和安全失败
7
上线有灰度/回滚

任何一项缺失，训练曲线变好也无法证明业务变好。

1.3 微调不能解决什么#

1
实时事实更新
2
数据库事务
3
资源级授权
4
Prompt Injection 的完整防护
5
工具实际执行
6
业务最终状态验证

2. 方法谱系#

2.1 SFT#

用高质量输入-目标输出做监督学习：

1
query + state + tools
2
-> correct tool call / structured decision / final response

适合学习格式、领域表达、稳定决策模式和工具调用风格。

2.2 LoRA#

LoRA 冻结基础权重，用低秩矩阵学习权重更新，大幅减少可训练参数。[P1]

1
W' = W + ΔW
2
ΔW = B A, rank r << hidden dimension

2.3 QLoRA#

QLoRA 在量化基础模型上训练 LoRA Adapter，以更低显存接近全精度微调能力。[P2] 量化、计算 dtype、量化组与推理部署需要一致验证。

2.4 DPO#

DPO 使用同一输入下的 chosen/rejected 偏好对，直接优化相对偏好而无需显式训练 Reward Model。[P3]

适合：

1
正确工具 > 相似错误工具
2
必要调用 > 过度调用
3
安全拒绝 > 越权执行
4
证据充分回复 > 过度承诺

2.5 Rejection Sampling / Distillation#

强模型为同一任务生成多个候选，经确定性/环境 Verifier 筛选，再训练小模型。OpenAI 等公开文档提供 SFT、DPO、RFT 与 distillation 工作流；Google、Azure、AWS 也提供托管调优能力。[S1] [S2]

2.6 RFT / Agent RL#

在可执行环境中采样完整轨迹，根据环境结果、过程和安全约束给 Reward，再更新 Policy。适合单纯模仿不足、需要探索策略的任务；同时也是最容易 reward hacking、环境过拟合和成本失控的方法。

Agent Lightning、ReTool、RAGEN 等近期工作探索把 Agent 执行、工具交互与多轮强化学习连接起来。[P4] [P5] [P6] 这些 2025 工作代表研究方向，不意味着所有生产 Agent 都应使用 RL。

3. 训练对象：行为、策略还是知识#

3.1 行为层#

1
输出 Schema
2
语气/风格
3
工具选择
4
参数生成
5
何时澄清
6
何时拒绝

SFT/DPO 常适合。

3.2 策略层#

1
多步行动
2
何时搜索/停止
3
失败后修复
4
成本与成功权衡

需要轨迹、环境与 Verifier，可能用 SFT + RFT。

3.3 知识层#

稳定领域语言可通过训练改善；频繁变化事实和政策应留在 RAG/工具/规则层。把规则写进权重会产生版本不可见和撤回困难。

3.4 权限层#

永远留在外部 Policy/Executor。可以训练模型更好地提出安全动作，但仍要假设它会出错。

4. Agent Trajectory 数据模型#

4.1 顶层记录#

1
from typing import Literal
2
from pydantic import BaseModel
3

4

5
class TrajectoryRecord(BaseModel):
6
    trajectory_id: str
7
    task_id: str
8
    scenario_id: str
9
    tenant_class: str
10
    environment_version: str
11
    agent_version: str
12
    base_model: str
13
    prompt_bundle_version: str
14
    tool_registry_version: str
15
    policy_bundle_version: str
16
    events: list[dict]
17
    terminal_status: Literal["success", "failure", "human", "cancelled"]
18
    verified_outcome_ref: str | None
19
    grader_results: list[dict]
20
    safety_labels: list[str]
21
    usage: dict
22
    provenance: dict

4.2 Event#

1
class TrajectoryEvent(BaseModel):
2
    sequence: int
3
    type: Literal[
4
        "user_message",
5
        "assistant_message",
6
        "tool_call",
7
        "tool_result",
8
        "state_transition",
9
        "policy_decision",
10
        "human_decision",
11
    ]
12
    content: dict
13
    source_ref: str
14
    occurred_at: str

4.3 不保存隐藏 CoT#

训练数据需要结构化动作和可验证中间字段，不需要采集/训练隐藏 Chain-of-Thought：

1
task type
2
selected capability
3
arguments
4
evidence refs
5
state transition
6
error/repair code

4.4 Tool Result#

工具结果作为上下文输入，不作为模型目标 token。保留结构化字段、来源与版本；原始 PII/Secret 必须脱敏或替换为一致占位符。

5. 从线上 Trace 到训练样本#

1
Trace/Event Store
2
-> Consent/Purpose Filter
3
-> Secret/PII Redaction
4
-> Normalize Provider Formats
5
-> Reconstruct Trajectory
6
-> Verify Environment Outcome
7
-> Deduplicate
8
-> Failure/Safety Label
9
-> Human/Rule Review
10
-> Split Assignment
11
-> Immutable Dataset Snapshot

5.1 Provenance#

每条样本记录：

1
来源 Run/Case
2
采集时间
3
脱敏器版本
4
归一化器版本
5
标注者/Verifier
6
合成模型与 Prompt（如合成）
7
接受/拒绝理由

5.2 脱敏一致性#

1
真实订单 ORD-X -> <ORDER_1>
2
同一轨迹后续仍为 <ORDER_1>
3
另一个订单 -> <ORDER_2>

随机替换不一致会破坏多轮引用和工具结果关联。

5.3 数据最小化#

1
移除不影响决策的个人信息
2
不记录 API Key/token/cookie
3
敏感文本用受控合成替代
4
限制跨租户汇总
5
保留删除/撤回映射

5.4 Delete Lineage#

训练集需要 source-to-example lineage。源数据被依法删除时，能定位受影响 Dataset Snapshot、Adapter 和是否需要重训/退役；仅删除原始 Trace 不等于删除派生模型影响。

5.5 Dataset Manifest#

1
dataset_id: orderflow-tool-agent@2026-07-15.1
2
schema_version: "3"
3
record_count: 1842
4
token_count: 7350000
5
sources:
6
  production_consented: 620
7
  human_authored: 302
8
  synthetic_verified: 920
9
time_range: [2026-01-01, 2026-06-30]
10
tool_registry_versions: [readonly@7, readonly@8]
11
policy_versions: [support-cn@16, support-cn@17]
12
redaction_version: pii-redactor@5
13
dedup_version: semantic-dedup@3
14
split_version: grouped-time-split@2
15
license_review: approved
16
retention_until: 2027-07-15
17
content_digest: sha256:...

Manifest 与实际 Parquet/JSONL content hash 一起冻结；“同名 dataset 文件夹”不是可复现版本。

5.6 License、Consent 与用途#

1
原始数据许可证是否允许训练/派生模型？
2
用户同意是否覆盖当前用途？
3
第三方文档/工具返回能否进入训练集？
4
合成模型条款是否允许蒸馏？
5
数据是否受地域/行业限制？

技术上可抓取不等于法律和合同上可训练。数据 Owner、隐私、安全与法务审批应成为 Dataset Gate。

5.7 Quarantine#

新采集数据先进入隔离区：

1
raw -> quarantined -> reviewed -> accepted/rejected -> immutable snapshot

隔离区不能被训练 Job 通过通配符直接读取；接受动作记录规则/人工 Reviewer 与理由。

6. 数据质量：正确轨迹比大量轨迹重要#

6.1 接受条件#

1
任务定义完整
2
输入/状态版本可复现
3
工具调用 Schema 合法
4
无越权动作
5
最终环境状态验证
6
无未解决冲突
7
来源和脱敏完整

6.2 成功轨迹也可能有问题#

1
碰巧成功但走错工具
2
重复调用造成高成本
3
使用了越权数据
4
最终答案正确但副作用重复
5
人工偷偷修正而未记录

训练前评估轨迹，不只看终态。

6.3 失败轨迹的用途#

1
SFT：通常不用错误 action 作为目标
2
DPO：构造 rejected
3
RFT：提供负 Reward/安全门禁
4
Error Recovery SFT：只保留“错误 Observation -> 正确 repair”片段

6.4 多样性#

覆盖：

1
意图/场景
2
工具与参数
3
正常/边界/异常
4
不同语言与表达
5
不同环境状态
6
澄清/拒绝/人工
7
成本敏感任务
8
攻击样例

6.5 长尾优先#

随机采样线上流量会被简单成功 Case 淹没。按 Failure Taxonomy、置信度、工具稀有度和业务风险分层采样。

7. 数据切分：防止“记住答案”#

7.1 泄漏来源#

1
同一用户/订单进入 train 和 eval
2
同一模板只替换 ID
3
同一规则 paraphrase
4
同一合成 Prompt 生成两边
5
同一工具轨迹近重复
6
未来数据泄漏到时间回测

7.2 Group Split#

按以下 group key 切分：

1
business entity
2
scenario family
3
source document
4
conversation/thread
5
generation batch/template

7.3 Time Split#

1
train: T0-T1
2
validation: T1-T2
3
test: T2-T3

模拟未来分布与规则变化。

7.4 Frozen Suites#

1
Core Golden
2
Long-tail
3
Adversarial/Safety
4
Regression Failures
5
OOD/Tool-version Shift
6
Cost/Latency

训练过程中不能反复查看并针对最终测试集调参。

7.5 近重复检测#

逐字 hash 只能发现完全重复。还需组合：

1
规范化文本 hash
2
MinHash/LSH n-gram
3
embedding similarity
4
trajectory action signature
5
tool argument pattern
6
source/template/generation batch

轨迹签名示例：

1
refund_request
2
-> query_order
3
-> query_logistics
4
-> search_policy
5
-> clarify

ID 不同但签名和文本高度相近的样本应在同一 split group。

7.6 Contamination Audit#

1
Eval Case 是否出现在教师 Prompt？
2
教师模型是否被显式提供答案？
3
公开 Benchmark 答案是否混入训练？
4
Regression Failure 修复样本是否误入最终 Test？

每次 Dataset 更新生成 contamination report；Eval Set hash 固定并限制访问。

7.7 分布报告#

1
scenario/tool/error/language/risk 分布
2
sequence length 分布
3
source 类型分布
4
accepted/rejected 原因
5
每个 group 的 train/val/test 数量

没有分布报告，无法解释“整体变好但高风险 Case 变差”。

8. SFT 样本设计#

8.1 Tool Selection#

1
{
2
  "messages": [
3
    {"role": "system", "content": "<stable task contract>"},
4
    {"role": "user", "content": "订单三天没发货，我要退款"},
5
    {
6
      "role": "assistant",
7
      "tool_calls": [
8
        {
9
          "name": "query_order",
10
          "arguments": {"order_id": "<ORDER_1>"}
11
        }
12
      ]
13
    },
14
    {
15
      "role": "tool",
16
      "name": "query_order",
17
      "content": {"status": "paid", "version": 8}
18
    },
19
    {
20
      "role": "assistant",
21
      "tool_calls": [
22
        {
23
          "name": "query_logistics",
24
          "arguments": {"order_id": "<ORDER_1>"}
25
        }
26
      ]
27
    }
28
  ]
29
}

实际训练格式服从目标模型 chat template/SDK，不直接把示例 JSON 当通用标准。

8.2 Loss Mask#

通常只对模型应生成的 assistant/action token 计算 loss：

1
system/user/tool result -> context, loss masked
2
assistant tool call/final -> target, loss enabled

如果对工具返回也训练 loss，模型会学习伪造 Observation。

8.3 长轨迹切片#

1
full trajectory：学习全局，但长、稀疏、成本高
2
decision window：当前 state + 相关历史 + 下一正确 action
3
repair window：error observation + correct repair
4
finalization window：verified state + faithful response

保留 trajectory_id/step_range，防止同一轨迹切片跨 train/eval。

8.4 Packing#

Sequence packing 提高吞吐，但必须保证不同样本 attention/loss 边界正确，不能让前一个工具结果污染下一个任务。

8.5 Chat Template 是模型接口#

1
role token
2
turn separator
3
tool call begin/end token
4
tool result token
5
assistant generation prefix
6
EOS/stop token

训练与推理使用不同 Chat Template，会出现：

1
模型不生成工具结束标记
2
把 tool result 当 assistant 文本
3
停止过早/不停止
4
arguments 被额外转义

Dataset Renderer 先用目标 tokenizer/template 渲染，再做 token-level snapshot test。

8.6 Token-level Contract Test#

1
def test_tool_sample_round_trip(renderer, tokenizer):
2
    rendered = renderer.render(sample)
3
    token_ids = tokenizer.encode(rendered)
4
    decoded = tokenizer.decode(token_ids)
5

6
    assert renderer.has_single_assistant_target(token_ids)
7
    assert renderer.tool_result_is_masked(token_ids)
8
    assert renderer.can_parse_tool_call(decoded)
9
    assert token_ids[-1] == tokenizer.eos_token_id

8.7 Truncation Policy#

长样本不能从右侧盲切，可能切掉最终 action/outcome。推荐：

1
保留当前 decision window
2
保留必要 tool observations
3
以 summary/reference 替换早期历史
4
丢弃无法保持因果完整性的样本
5
记录 truncation metadata

9. LoRA/QLoRA 工程#

9.1 选择 Target Modules#

常见候选是 attention/MLP projection；具体名称随模型架构变化。不能照抄另一个模型的 q_proj/v_proj 列表而不检查 module tree。

9.2 关键配置#

1
base_model: model@exact-revision
2
tokenizer: tokenizer@exact-revision
3
chat_template: orderflow-chat@3
4
method: qlora
5
quantization: 4bit-nf4
6
compute_dtype: bfloat16
7
lora_rank: 32
8
lora_alpha: 64
9
lora_dropout: 0.05
10
target_modules: [q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj]
11
learning_rate: 0.0002
12
epochs: 2
13
max_sequence_length: 8192
14
gradient_checkpointing: true
15
dataset_snapshot: tool-agent-sft@2026-07-15.1

这是示意，不是所有模型的最佳参数。

9.3 训练稳定性#

监控：

1
train/validation loss
2
gradient norm
3
learning rate
4
tokens/sec
5
OOM/overflow
6
sequence length distribution
7
tool token accuracy
8
held-out task metrics

Loss 降低不代表工具调用正确。

9.4 Adapter Registry#

1
base model revision
2
adapter weights + digest
3
tokenizer/chat template
4
tool schema bundle
5
dataset snapshot
6
training code/container
7
hyperparameters/seed
8
eval report
9
license/data policy

Hugging Face PEFT/TRL、Meta torchtune、NVIDIA NeMo RL 等提供不同层级的开源训练能力。[S3]

9.5 Effective Batch#

1
effective_batch_tokens =
2
  devices
3
  × per_device_sequences
4
  × gradient_accumulation
5
  × average_unmasked_target_tokens

Agent 样本 target 长度差异很大，只报告 sequence batch size 可能误导。监控每步 unmasked target tokens 与不同 task mix。

9.6 Data Mixture#

1
mixture:
2
  tool_selection: 0.30
3
  argument_generation: 0.20
4
  no_tool_or_clarify: 0.15
5
  error_recovery: 0.15
6
  grounded_response: 0.10
7
  safety_refusal: 0.10

用可配置 sampler 实现，不靠复制文件。过采样高风险/稀有类时，评估报告仍按真实分布与风险加权分别输出。

9.7 Reproducibility#

保存：

1
code commit/container digest
2
CUDA/framework/library versions
3
model/tokenizer revisions
4
dataset shards/order
5
seed
6
distributed topology
7
optimizer/scheduler state
8
checkpoint hash

完全 bitwise reproducibility 未必可得，但至少应能复现指标区间和行为分布。

9.8 Checkpoint 选择#

不要自动选最低 validation loss。按冻结 Agent Eval 的多目标门禁选：

1
Safety hard pass
2
Tool/Argument
3
Task Success
4
Cost/Latency
5
then validation loss as diagnostic

10. DPO：偏好对如何构造#

10.1 Pair Schema#

1
class PreferencePair(BaseModel):
2
    pair_id: str
3
    prompt_context: list[dict]
4
    chosen: dict
5
    rejected: dict
6
    preference_reasons: list[str]
7
    grader_refs: list[str]
8
    policy_version: str
9
    difficulty: str

10.2 有价值的 Pair#

1
正确工具 vs 相似错误工具
2
先澄清 vs 猜测缺失参数
3
只读查询 vs 未确认写操作
4
最小调用 vs 重复调用
5
引用充分 vs 过度承诺
6
安全拒绝 vs 服从注入

10.3 困难负例#

Rejected 应表面合理但违反一个明确约束，而不是随机乱码。否则模型只学会区分明显坏答案。

10.4 Pair 污染#

同一个 chosen 不要与大量轻微改写 rejected 复制，避免模板偏差主导训练。

10.5 DPO 不替代环境#

偏好标签可能错；对于工具动作，优先使用真实 Schema、Policy 与环境状态生成 Pair，而不是只让另一个模型凭文本打分。

10.6 Position/Style Bias#

模型 Judge 可能偏好更长、措辞更强或固定位置。构造 Pair 时：

1
交换 chosen/rejected 展示顺序
2
控制长度差
3
隐藏模型身份
4
用确定性规则先判可判项
5
人工复核分歧样本

10.7 Pair 一致性#

如果 A>B、B>C，却又标 C>A，偏好图存在循环。对同一 prompt family 建 preference graph，扫描冲突并回到来源/Reviewer。

10.8 DPO 回归面#

DPO 可能提升拒绝/风格但损害工具参数或多轮恢复，因此仍跑完整 Rollout，而不只测 pair win rate。

11. Synthetic Data 与 Rejection Sampling#

11.1 生成管线#

1
Scenario Generator
2
-> Environment Fixture
3
-> Strong Teacher produces N trajectories
4
-> Schema/Policy/Environment Verifiers
5
-> Diversity/Dedup Filter
6
-> Human sample review
7
-> Accepted Dataset

11.2 Counterfactual#

从 Gold Case 改一个决定性事实：

1
72h -> 24h
2
normal -> presale
3
owner user -> different user
4
policy current -> expired
5
confirmation valid -> expired

期望动作必须相应改变。

11.3 Teacher Bias#

Teacher 的措辞、工具偏好和错误会被蒸馏。使用多 Teacher/多 Prompt、多样性采样和确定性 Verifier，并保留 teacher_model/version。

11.4 Self-Instruct/LIMA/Orca 启发#

Self-Instruct、LIMA、Orca 分别展示了自生成指令、少量高质量对齐数据和解释型教师信号的不同价值。[P7] [P8] [P9] 对 Agent 数据而言，环境可执行验证比长解释更重要。

12. Agent RFT：环境、Reward 与 Credit Assignment#

12.1 Environment#

1
reset(seed, scenario)
2
observe()
3
step(action) -> observation, done, info
4
snapshot()/restore()
5
final_state()

必须使用沙箱/模拟业务系统，不能让探索策略操作真实退款。

12.2 Reward 分解#

1
Hard gates:
2
  authorization_pass
3
  no_unsafe_action
4
  no_duplicate_side_effect
5
  schema_valid
6

7
Outcome:
8
  verified_task_success
9

10
Process:
11
  required_fact_coverage
12
  correct_tool_sequence
13
  recovery_success
14

15
Efficiency:
16
  step/token/latency budget

先应用 Hard Gate，再计算软 Reward；不要让高任务得分抵消安全违规。

12.3 Reward 示例#

1
def reward(trajectory, outcome) -> float:
2
    if trajectory.has_policy_violation:
3
        return -10.0
4
    if trajectory.has_duplicate_side_effect:
5
        return -10.0
6
    if not outcome.verified_success:
7
        return -1.0
8

9
    score = 5.0
10
    score += 1.0 * trajectory.required_fact_recall
11
    score -= 0.05 * trajectory.unnecessary_tool_calls
12
    score -= 0.001 * trajectory.total_tokens
13
    return score

权重需防止“少调用但漏步骤”等投机。

12.4 Reward Hacking#

1
伪造成功文本
2
跳过困难 Case
3
过早终止降低成本
4
利用模拟器漏洞
5
重复低成本动作刷过程分
6
操纵 LLM Judge

防御：环境状态、隐藏测试、对抗场景、Reward 审计、Holdout Environment 和人工抽检。

12.5 Credit Assignment#

长轨迹最终成功/失败很难归因到具体 action。可结合：

1
step-level deterministic checks
2
process verifier
3
subtask outcome
4
advantage/return estimation
5
trajectory segmentation

Agent Lightning 等工作重点研究把任意 Agent 执行解耦为可训练轨迹并做 credit assignment；RAGEN 讨论多轮 Agent RL 的自演化与训练动态。[P4] [P6]

12.6 Environment Manifest#

1
environment: orderflow-sim@4.2.0
2
database_fixture: refunds-edge-cases@9
3
tool_registry: sandbox@11
4
policy_bundle: support-cn@18
5
clock_mode: deterministic
6
network_mode: disabled
7
seed: 845201
8
grader_bundle: agent-rft-graders@7
9
known_exploits: reward-audit@5

Environment 是训练制品。规则、模拟器或 Grader 变更会改变 Reward 分布，必须新建版本而不是覆盖。

12.7 Reset 与隔离#

每个 Episode：

1
独立数据库 namespace
2
固定初始 snapshot
3
无生产凭据
4
受限 CPU/内存/时间
5
网络 deny-by-default
6
结束后断言无跨 Episode 状态

12.8 Hidden Holdout Environment#

训练策略可能利用已知模拟器漏洞。保留不同实现或隐藏约束的 Holdout Environment，验证策略学到业务能力而非环境特征。

12.9 Reward Versioning#

Reward 函数、权重、Hard Gate 与 Judge 都进入 reward_bundle_version。升级 Reward 后不能直接与旧曲线比较，需要在同一冻结 Policy/数据上重放校准。

13. Tool-use 专项训练#

13.1 能力分解#

1
Need-tool Detection
2
Capability Retrieval
3
Tool Selection
4
Argument Generation
5
Parallel/Sequential Planning
6
Observation Use
7
Error Recovery
8
Stop/Finalize

13.2 工具版本#

训练样本固定 Tool Schema；上线 Tool 变更后必须评估：

1
name/description
2
required/optional fields
3
enum
4
error codes
5
side effect

模型学的是某版本接口分布。

13.3 Toolformer、ToolLLM、AgentTuning、FireAct、ToolACE#

这些工作分别探索自监督工具使用、大规模 API 数据、通用 Agent 指令调优、多任务 Agent 轨迹微调和函数调用数据合成/训练。[P10] [P11] [P12] [P13] [P14]

工程落点：

1
工具树/候选召回
2
多轮 action-observation 数据
3
多任务混合避免单域过拟合
4
格式、选择、参数与环境结果分层评估

14. OrderFlow MiniToolAgent-SFT#

14.1 目标#

训练小模型完成：

1
意图/槽位
2
只读工具选择
3
规则检索 query
4
安全的下一步建议

不让模型直接执行退款。

14.2 数据规模#

路线建议 500-2000 条作为实验：

1
60% normal
2
15% missing slots/clarification
3
10% tool errors/recovery
4
10% boundary/policy refusal
5
5% adversarial

这是教学规模，不保证达到生产效果。

14.3 Tool Set#

1
query_order
2
query_logistics
3
search_policy
4
request_clarification
5
escalate_human

写工具不进入训练候选集，先验证低风险能力。

14.4 Baselines#

1
B0 rules/workflow
2
B1 small model prompt-only
3
B2 strong model prompt-only
4
B3 small model SFT full
5
B4 small model QLoRA
6
B5 B4 + DPO

14.5 成功门槛#

1
Tool Selection Accuracy
2
Argument Accuracy
3
No-tool Accuracy
4
Clarification Accuracy
5
Unsafe Action Rate=0 on frozen safety set
6
Task Success
7
Latency/Cost per Verified Success

SFT 若只接近强模型但成本显著下降，也可能有价值；若安全/长尾退化则不能上线。

15. Eval Harness#

15.1 离线#

1
Schema Validity
2
Intent/Slot
3
Tool Selection/Args
4
Sequence/Trajectory
5
Final Outcome
6
Safety/Policy
7
Calibration
8
Cost/Latency

15.2 Teacher-forced vs Rollout#

1
Teacher-forced：给正确历史，测下一 action
2
Rollout：模型自己的错误会累积，测端到端

两者都要。只测 teacher-forced 会低估 exposure bias。

15.3 Environment Replay#

固定环境 fixture、工具版本、随机 seed 和 Policy。模型输出动作后真实推进模拟状态，最终用数据库断言验收。

15.4 OOD#

1
新工具组合
2
新表达/语言
3
更长对话
4
工具错误分布变化
5
规则版本变化
6
未知 intent

15.5 统计#

报告置信区间与按场景切片，不用单一平均分掩盖高风险长尾。

15.6 Paired Evaluation#

对同一 Case/seed 运行 baseline 与 candidate，记录配对差异，减少场景随机性。报告：

1
win/tie/loss
2
McNemar/paired bootstrap（按指标选）
3
confidence interval
4
high-risk regressions count

统计显著不等于业务显著；预先定义最小可接受收益和零容忍安全门槛。

15.7 Release Gate 示例#

1
hard:
2
  unsafe_action_rate: 0
3
  cross_tenant_leakage: 0
4
  schema_validity_gte: 0.999
5
  regression_critical_pass: 1.0
6
soft:
7
  task_success_delta_gte: 0.03
8
  tool_accuracy_delta_gte: 0.02
9
  cost_per_success_delta_lte: -0.20
10
  p95_latency_delta_lte: 0.10

Soft 指标可多目标评审；Hard 指标任一失败直接拒绝发布。

16. 发布与回滚#

16.1 Release Manifest#

1
model_release: orderflow-mini-agent@1.3.0
2
base_model: base@exact-revision
3
adapter: qlora@sha256:...
4
tokenizer: tokenizer@revision
5
chat_template: orderflow@3
6
prompt_bundle: support@12
7
tool_registry: readonly@8
8
policy_bundle: support-cn@18
9
dataset_snapshot: tool-agent-sft@2026-07-15.1
10
training_code: git:abc123
11
eval_report: eval://orderflow-mini/1.3.0

16.2 Stages#

1
offline gate
2
-> shadow
3
-> internal users
4
-> 1% canary
5
-> 10%
6
-> progressive rollout

16.3 Online Guardrails#

1
只读工具 allowlist
2
强 Policy/Schema
3
step/cost budget
4
fallback strong model/rule/human
5
failure sampling
6
kill switch by model/adapter version

16.4 Rollback#

回滚指针到上一完整 Manifest，不只换 Adapter。Prompt/Tool/Policy 组合可能决定行为。

16.5 Drift#

监控：

1
input/scenario distribution
2
tool selection distribution
3
argument/error distribution
4
unknown/handoff rate
5
policy violation
6
task success
7
cost/latency

16.6 Total Cost of Ownership#

1
数据采集/标注/审核
2
训练 GPU/托管费用
3
实验与评估
4
Adapter/Model 托管
5
监控与事故响应
6
规则/工具变化后的重训
7
安全与合规审查

与 API 强模型比较时使用年度/请求量情景：

1
break_even_requests =
2
  fixed_training_and_ops_cost /
3
  (strong_model_cost_per_success - tuned_model_cost_per_success)

还要把质量退化和人工升级成本计入；便宜的单次推理不等于更低 TCO。

16.7 Champion/Challenger#

线上同时保留：

1
Champion：当前稳定发布
2
Challenger：shadow/canary 候选
3
Fallback：强模型/规则/人工

所有路由记录 reason/version，避免只在故障时才发现 fallback 从未正确配置。

17. 大厂与开源方案对照#

方案	公开能力	可借鉴	需自行补齐
OpenAI SFT/DPO/RFT	托管数据、训练、grader/RFT 工作流	方法选择与评估流程	业务环境/权限
OpenAI Distillation	强模型结果进入小模型优化流程	Teacher + eval	数据与教师偏差
Google Vertex AI	Gemini supervised tuning	托管训练/评估	Agent 轨迹与工具状态
Azure OpenAI	托管 fine-tuning	企业云集成	数据治理/业务门禁
AWS Bedrock	custom model/import/customization	云模型定制	行为归因与环境 Eval
Hugging Face PEFT/TRL	LoRA、SFT/DPO/RL 算法栈	可控实验与开源训练	生产服务/合规
Meta torchtune	PyTorch-native tuning recipes	配置透明	Agent 专项数据
NVIDIA NeMo RL	分布式 RL/后训练系统	大规模训练	Reward/环境正确性

官方入口见 [S1] 到 [S3]。托管服务减少训练基础设施，不替代 Agent 数据和环境设计。

18. Failure Taxonomy#

编号	失败	示例	修复层
FT01	Wrong Problem	用微调修权限漏洞	Architecture
FT02	Bad Provenance	样本来源/同意未知	Data Governance
FT03	PII/Secret	token 进入轨迹	Redaction
FT04	Outcome Error	错误轨迹标成成功	Verifier
FT05	Leakage	同模板跨 train/test	Split
FT06	Teacher Bias	蒸馏教师错误	Synthesis
FT07	Tool Drift	训练 Schema 已过期	Versioning
FT08	Loss Mask Error	学会伪造 tool result	Training Pipeline
FT09	Catastrophic Forgetting	通用能力退化	Data Mix/PEFT
FT10	Reward Hacking	早停刷效率分	Reward/Environment
FT11	Offline/Online Gap	teacher-forced 好、rollout 差	Eval
FT12	Unsafe Generalization	长尾越权	Safety Suite
FT13	No Economic Gain	质量/成本无净收益	Product
FT14	Rollback Mismatch	只回滚 Adapter	Release Manifest

19. 常见反模式#

19.1 没有 Eval 先训练#

无法知道变好、过拟合或只是格式更像。

19.2 把线上成功日志全量做 SFT#

会学习偶然成功、冗余步骤、越权数据和人工修正。

19.3 用微调存规则#

规则难更新、难引用、难撤回；应放 RAG/Policy。

19.4 只看 Training Loss#

Loss 不是工具准确率、任务成功或安全。

19.5 随机行切分#

近重复轨迹导致虚高测试分。

19.6 合成器也是唯一 Judge#

同一模型生成和筛选会保留共享错误。

19.7 Reward 加权抵消安全违规#

Hard Safety Gate 应先于软 Reward。

19.8 Adapter 是独立制品#

没有 base/tokenizer/template/tool schema 无法正确加载与复现。

20. 项目目录与实践任务#

1
fine_tuning/
2
  schemas/
3
    trajectory.py
4
    preference.py
5
    release.py
6
  data/
7
    extract.py
8
    redact.py
9
    normalize.py
10
    deduplicate.py
11
    split.py
12
    synthesize.py
13
    validate.py
14
  train/
15
    sft.py
16
    qlora.py
17
    dpo.py
18
    rft/
19
  eval/
20
    next_action.py
21
    rollout.py
22
    safety.py
23
    ood.py
24
    report.py
25
  registry/
26
    datasets/
27
    adapters/
28
    releases/
29
  configs/
30
  reports/
31
tests/
32
  data_pipeline/
33
  training_contract/
34
  environment/

实践顺序：

1
1. 冻结 baseline 与 eval suite
2
2. 定义 Trajectory/Event/Outcome Schema
3
3. 构建 500-2000 条可验证样本
4
4. 做 group/time split 与泄漏扫描
5
5. 小模型 prompt-only baseline
6
6. SFT/LoRA baseline
7
7. QLoRA 资源实验
8
8. 只在明确偏好瓶颈上做 DPO
9
9. 有沙箱和可靠 Reward 后再试 RFT
10
10. 以 Manifest 做 shadow/canary/rollback

21. 达标检查清单#

Decision/Data#

能证明瓶颈属于可学习行为；
Prompt/RAG/Tool/Harness baseline 已稳定；
每条轨迹有来源、版本、脱敏和 Verified Outcome；
同用户/实体/模板/轨迹不会跨 split；
训练样本不包含 Secret 或隐藏 CoT。

Training#

明确 SFT、DPO、RFT 各自目标；
Loss mask 只覆盖正确目标 token；
固定 base/tokenizer/chat template/tool schema；
LoRA target modules 与模型结构匹配；
训练中跑 held-out Agent 指标，不只看 loss。

Reward/Eval#

Reward 以环境状态为核心；
安全/权限是 Hard Gate；
同时跑 teacher-forced 与 rollout；
有 OOD、adversarial、regression 与成本集；
对比强模型和小模型 prompt-only baseline。

Release#

Release Manifest 关联全部版本；
只读/低风险范围先灰度；
有 fallback、kill switch 和完整回滚；
监控分布、错误、安全、成本和延迟；
无净收益时停止训练路线。

22. 面试与架构评审问题#

哪些 Agent 问题不该靠微调解决？
SFT、DPO 与 RFT 分别学习什么信号？
LoRA 与 QLoRA 的工程权衡是什么？
Agent Trajectory 为什么必须保存环境和工具版本？
为什么 Tool Result token 通常不计算 loss？
如何防止同一模板/轨迹泄漏到测试集？
成功轨迹为什么不一定是好训练样本？
如何构造工具选择的困难负例？
Agent Reward 为什么要先做 Hard Safety Gate？
teacher-forced 与 rollout 指标为何会不同？
Adapter 发布为什么需要完整 Manifest？
何时微调小模型比继续调用强模型更划算？

23. 参考资料与延伸阅读#

以下资料用于核对官方训练能力和论文原始思想。服务支持范围、模型和参数会变化；训练方法必须在实际目标模型与数据许可证下重新核对。

官方训练方案#

[S1] OpenAI Optimization Guides#

[S2] 云厂商调优#

Google Cloud Gemini supervised tuning；
Microsoft Azure OpenAI Fine-tuning；
AWS Bedrock Custom models。

[S3] 开源训练栈#

Hugging Face PEFT；
Hugging Face TRL；
Meta torchtune；
NVIDIA NeMo RL。

基础与 Agent 训练论文#

24. 阶段总结#

Agent 微调的正确顺序是：

1
先定义任务与成功条件；
2
再稳定 Prompt/RAG/Tool/Harness；
3
建立可复现 baseline 与 eval；
4
把 Trace 变成有来源、脱敏、可验证的轨迹；
5
先 SFT/PEFT，再按明确瓶颈选择 DPO/RFT；
6
最后用环境结果、安全和单位成功成本决定是否发布。

微调后的模型仍然只是 Harness 中的概率决策组件。它可以更稳定地选择工具、生成参数和恢复错误，但：

1
权限仍由 Policy 决定；
2
事实仍由工具/RAG 提供；
3
副作用仍由受控 Executor 执行；
4
结果仍由环境 Verifier 确认；
5
失败仍要可追踪、灰度和回滚。

能清楚回答“为什么这个瓶颈必须通过权重更新解决，以及它相对更简单方案带来多少净收益”，才算真正掌握 Agent 微调工程。