第 17 章　模型调优¶

模型是 Agent 理解任务、选择工具、组织多步行动并根据环境反馈调整策略的决策核心。在 Harness 与执行环境满足运行要求的前提下，模型能力主要决定 Agent 的决策上限，并显著影响任务效果与单位成功任务成本。因此，在 Agent 的各类调优手段中，模型优化是提升能力上限和规模化运行效率的核心环节。

通用模型具备广泛的语言与推理能力，却未必天然适合特定 Agent 的任务分布、工具体系和业务约束。面向目标场景进行模型优化，可以让模型更稳定地识别任务目标、生成合法动作、利用执行反馈并完成长链路决策；也可以通过减少冗长提示、无效调用、失败重试和强模型依赖，改善端到端时延与单位成功任务成本。其价值不只是让模型“更强”，而是训练出在目标任务上效果更好、成本更可控、部署条件更匹配的模型。

模型优化也不是所有 Agent 问题的统一答案。工具协议含混、上下文缺失、权限控制失效或外部服务异常，分别属于 Harness 或执行环境问题，不能依靠训练模型来补偿。只有先明确 Agent 场景及其能力要求，并确认问题确实来自模型的理解、推理或决策能力，模型训练才能形成可验证、可复用的收益。

17.1 Agent优化方法总述¶

Agent模型优化始于目标场景：Agent 要完成什么任务，需要模型作出哪些关键决策，当前能力缺口在哪里，对效果、时延、资源和安全又有哪些要求。基于这些条件，团队才能判断是否需要优化模型，选择合适的训练信号与方法，并在完整 Agent 系统中验证收益。

本节围绕四个问题展开：

Agent 对模型提出了哪些能力要求；
什么时候优化模型、什么时候优化 harness 或执行环境；
如何定义优化目标，设定质量、可靠性、成本指标与安全护栏；
如何选择 SFT、Agentic RL 与模型蒸馏。

图 17.1-1 Agent 优化闭环总览

17.1.1 判断优化对象：模型、Harnesss 与执行环境¶

Agent 的端到端能力由模型、Harness 和执行环境共同形成：

模型负责在给定信息和动作空间内理解任务、作出决策、生成动作并解释反馈；
Harness 负责上下文组织、工具协议、任务状态、调用路由、反馈传递，以及重试和停止等运行支撑；
执行环境包括业务系统、数据服务、计算资源和外部服务，负责实际承载动作并返回结果。

图 17.1-2 模型—Harness—执行环境职责边界

因此，Agent 优化应先判断问题发生在哪一层。以失败恢复为例，模型判断当前错误是否可恢复、下一步应采取什么动作，属于决策能力；Harness 根据模型建议和预设策略决定是否重试、停止或请求授权，属于运行控制；执行环境因服务不可用或资源不足而无法完成动作，则属于环境故障。三者可能表现为相似的失败现象，但对应的优化手段不同。

失败归因的基本原则是：先判断模型在作出错误决策时是否已经获得准确、充分的信息，是否具备清晰可用的动作接口，以及执行环境是否正常。若必要信息缺失、工具协议含混、状态不可见或反馈被截断，应优先修复 Harness；若工具不可用、资源不足或外部服务异常，应修复执行环境；只有在信息、动作空间和反馈条件均明确且稳定时，同类决策错误仍跨任务变体反复出现，才有充分理由将其列为模型能力优化目标。

数据分析 Agent 反复生成错误 SQL 可以说明这一原则：若模型没有获得字段含义，应改善数据字典检索和上下文供给；若工具对时间范围的描述存在歧义，应修正工具协议；若查询服务本身不可用，应处理执行环境；若字段、统计口径和执行反馈均已清楚提供，模型仍在不同任务中混淆去重或关联逻辑，才应进一步评估模型优化。

失败现象本身不能直接决定归因。例如，工具选错既可能源于模型能力不足，也可能源于工具描述含混。表 17.1-1 因此将现象与判定条件结合，并直接给出优先优化对象。

表 17.1-1 Agent 失败归因

归因对象	常见失败情况	如何验证
执行环境	模型已经给出可执行动作，但业务系统、数据服务、Sandbox、计算资源或外部服务无法正常执行并返回结果	绕过模型直接调用相应工具或服务；若故障仍能复现，则归因于执行环境
Harness	模型没有获得必要信息、清晰的工具接口或完整反馈，或者任务状态、重试、停止和权限控制没有被可靠管理	固定模型和执行环境，修正上下文、工具协议或运行控制；若问题明显减少，则归因于 Harness
模型	信息、动作接口和反馈均充分，执行环境也正常，但模型仍持续作出错误的理解、推理、工具选择、失败恢复或终止决策	固定 Harness 和执行环境进行重复测试或替换模型；若错误跨任务变体稳定出现，或随模型变化显著改善，则归因于模型

实际排查时，应先排除能够独立复现的执行环境故障，再检查 Harness 是否提供了充分的信息和可靠的运行控制，最后判断是否属于模型能力缺口。这个顺序并不意味着工具选择、重复执行等现象只能由某一层引起，而是为了避免用模型训练弥补本应由系统工程解决的问题。

对于模型与 Harness 边界不清的问题，可以在执行环境稳定的前提下组织四组对照：原模型与原 Harness、原模型与候选 Harness、候选模型与原 Harness、候选模型与候选 Harness。在一致的任务集和预算下，比较模型改动、Harness 改动及二者交互带来的收益。若候选模型需要专门的提示或协议适配，应将适配纳入对应配置记录，避免将组合变化全部归因于模型。

此外，模型优化也可以由成本目标驱动。某些高频任务已经能够依靠长提示、反复纠错或多个模型复核完成，但执行开销超过预算。如果任务分布相对稳定、有效行为可以学习，就可以评估通过 SFT 或蒸馏减少这些开销。此时需要同时调整模型和 harness，并继续保留必要的权限控制、执行约束和独立验证。

17.1.2 Agent 模型能力的要求¶

当问题被归因于模型后，需要进一步判断模型的哪类决策能力不足。在“接收观察—作出决策—获得反馈—调整决策”的循环中，可将模型问题归纳为四类：

任务理解与约束识别。模型需要把自然语言要求转化为可执行目标，识别完成标准、前置条件和允许的操作范围。例如，数据分析 Agent 接到“比较两个季度的客户增长”时，需要明确客户口径、时间范围和去重规则，并判断现有信息是否足够；必要条件不明确时，提出澄清也是有效的任务推进方式。
工具使用与反馈理解。模型需要选择合适的工具，生成符合接口要求的动作，并判断返回结果能否支持下一步决策。调用成功仅说明接口完成了请求，模型还需要识别结果是否完整、数据口径是否一致，以及是否需要进一步核验。
多步决策与状态利用。模型需要理解已经完成的工作、尚未解决的问题和当前可用的信息，并根据反馈调整行动顺序。在涉及用户协作的任务中，还要确认用户是否完成了必要操作。τ²-Bench 将用户和 Agent 都能操作共享环境的情形纳入评估，并通过消融实验区分推理错误与沟通、协调错误，说明任务完成能力需要同时覆盖决策和交互。
失败恢复与合理终止。工具报错后，模型需要判断应修正参数、补充信息、切换路径还是请求帮助；结果满足完成条件后，则需要判断任务是否可以终止。

这些能力描述的是模型的决策表现，而不是 Agent 的完整运行能力。模型可以提出调用、重试或停止建议，但工具实际执行、状态持久化、权限校验和动作放行仍由 Harness 与执行环境承担。完成这一步，才能把笼统的“Agent 效果不好”转化为可构造训练数据、可选择学习信号、可独立验收的模型优化目标。

17.1.3 设定优化目标：质量、可靠性、成本与安全护栏¶

确定优化对象后，需要把“更强”或“更省”转化为可验证的目标。优化动因可以分为两类：效果驱动关注任务质量和稳定性不足，效率驱动关注任务已经能够完成，但依赖过长提示、反复重试、多模型复核或较高推理成本。两类目标都应从质量、可靠性和成本三个维度共同评估。

质量。衡量任务是否按要求完成。除最终答案外，还应检查关键动作是否正确、结果是否满足业务口径、约束是否得到遵守。对数据分析 Agent，可以检查数据源和时间范围是否正确、查询结果能否复现、结论是否得到数据支持。工具调用格式正确率等局部指标可以辅助定位问题，最终验收仍应回到完整任务。
可靠性。衡量 Agent 在不同条件下能否持续完成任务。同一任务应进行多次运行，并覆盖输入变化、长交互、工具异常和用户补充条件等情形。平均成功率提高时，仍需确认关键业务场景没有回退；权限或执行边界被违反的情况应单独报告。
成本。衡量获得有效结果的总体投入，包括模型调用、工具执行、失败重试和人工介入，同时观察端到端时延及其高分位表现。可采用“单位成功任务成本”，即统计期内全部任务的执行成本除以成功完成的任务数量，失败任务消耗的资源也计入分子。比较时应固定任务构成并同时报告成功率，避免因放弃困难任务而形成表面上的成本下降。

效率驱动并不意味着模型训练必然降低成本。SFT 只有在减少提示长度、降低重试与复核次数，或使更小模型能够胜任目标任务时，才可能降低端到端成本；否则，数据准备、训练、评测、发布和维护的一次性投入可能抵消运行节省。对于低频或变化较快的任务，轻量的 Harness 调整可能更经济；对于高频且相对稳定的任务，模型训练或蒸馏带来的单次执行节省才更可能形成累计收益。具体结论需要结合实际业务规模核算。

指标之外还需设置安全护栏。模型负责识别约束并提出动作，但不能仅依赖模型自行遵守：Harness 负责调用侧的权限校验、动作放行、重试上限、停止条件和独立验证，执行环境则负责资源与服务侧的强制校验和动作执行。训练前应明确目标任务、对照基线、质量门槛、可靠性要求、成本预算、安全约束和回归范围；训练后采用同一口径复测，才能判断收益是否来自预期能力提升，并确认没有以可靠性或安全性换取局部指标改善。

17.1.4 选择合适的模型优化方法¶

确认模型能力缺口后，应根据学习信号和优化目的选择方法：

有明确示范时选择 SFT。当工具使用、任务推进或失败恢复已有较明确的有效示范，而模型执行不够稳定时，可以通过监督微调提高这些行为在相应条件下出现的概率。训练样本应包含产生目标动作所需的上下文、工具反馈和任务变化，使模型能够在新的输入与交互状态下运用所学行为。
需要交互探索且环境能够提供可靠反馈时选择 Agentic RL。当任务存在多种执行路径，路径优劣需要通过实际执行才能判断，并且环境能够提供可验证反馈时，可以通过 Agentic RL 优化行动策略。采用该方法的前提是交互环境可运行、反馈与真实任务目标一致，并且探索和训练成本可承担。
教师模型已具备能力，且目标是迁移、压缩或部署时选择模型蒸馏。当教师模型能够完成目标任务，而生产环境希望使用满足特定规模、时延或部署条件的学生模型时，可以利用教师在目标任务分布上生成的输出或行动轨迹训练学生模型。学生模型在实际执行中可能进入教师示范未覆盖的状态，因此仍需检验偏差累积和失败恢复能力。

三类方法并不互斥。就本章讨论的输出或轨迹蒸馏而言，蒸馏通常通过教师生成数据上的 SFT 实现；SFT 后的模型也可以继续开展 Agentic RL。是否组合以及如何排序，应由基础模型能力、训练信号质量、目标 Harness 和成本预算共同决定。训练阶段应尽可能覆盖生产中的主要上下文组织、工具协议和反馈方式，或验证训练条件与生产条件之间的差异可以被可靠适配。

图 17.1-3 模型优化方法选择路径

进入后续训练环节前，应形成明确的优化任务定义：目标任务及分布是什么，待改善的能力缺口是什么，归因证据如何，现有 Harness 和执行环境已经提供哪些条件，采用何种学习信号和优化方法，质量、可靠性、成本与安全门槛分别是什么，以及将使用哪些独立任务和回归范围进行验收。后续各节将据此展开 SFT、Agentic RL、模型蒸馏及上线验证的方法。

17.2 SFT：建立面向 Agent 的任务执行能力¶

当问题已被归因于模型，并且正确行为能够被明确示范时，可以使用监督微调（Supervised Fine-Tuning，SFT）提高模型复现这些行为的稳定性。SFT 的作用不是替代 Harness 或执行环境，也不是自动发现未知的最优策略，而是让经过验证的理解、决策和响应方式更容易在相似任务中被模型采用。

面向 Agent 的 SFT，监督对象不只是最终答案，还包括任务执行过程中的关键决策，例如是否需要调用工具、选择哪个工具、如何生成参数、如何解释反馈，以及何时继续、澄清、求助或终止。其基本学习单位可以概括为：在当前可见的信息和动作空间下，模型应当生成什么响应或行动。

延续前文的数据分析示例：用户要求比较两个季度的新增付费企业客户，并提供核验依据。即使“按企业去重、以历史首次有效付费时间确定新增、排除测试账号”等口径已经明确，模型仍可能先筛选季度内订单，再计算首次付费时间，导致老客户被计入新增。此时，SFT 的目标不是让模型记住某一条查询语句，而是通过多样化示范，使其稳定学会“先在全量有效付费记录上确定企业首次付费时间，再按目标季度统计”的执行方法。

图 17.2-1 Agent SFT 对模型行为的作用机制

如图 17.2-1 所示，在任务目标、可见信息和动作空间保持一致的情况下，SFT 使用“当前决策条件—经验证目标行为”作为监督信号，调整模型参数，使目标行为在相似上下文中的生成倾向提高。它改变的是模型的条件行为分布，而不是 Harness 的状态维护、工具执行与权限控制，也不依靠环境交互探索未知的最优策略。

前文已经讨论了轨迹处理和质量资产建设。本节承接这些成果，重点说明如何从轨迹中确定监督目标、组织训练样本，并通过执行评测判断模型是否真正获得了可迁移的任务执行能力。

17.2.1 明确 SFT 的适用边界¶

进入 SFT 前，除确认问题属于模型外，还需要判断目标行为是否能够被可靠示范。如果专家、规则系统或更强模型可以给出稳定、可核验的正确行为，SFT 可以将这些行为迁移给目标模型；如果路径优劣只能通过环境交互才能判断，或者同一状态下缺少可信的目标动作，就不应直接将不确定结果作为监督标签，而应先完善验证条件，或考虑 Agentic RL 等依赖环境反馈的方法。

监督目标应从已经识别的能力缺口出发，而不是笼统地定义为“提升 Agent 能力”。例如，工具调用失败可以进一步拆分为调用时机错误、工具选择错误、参数语义错误或反馈理解错误；多轮任务失败可以定位为约束遗失、状态利用不足或终止判断错误。只有将问题落到具体决策点，才能确定需要补充什么样本、监督哪些输出，以及用什么测试验证改进。

面向 Agent 的 SFT 通常覆盖以下几类目标行为：在信息充分时直接回答，在需要外部信息时选择工具，在关键条件缺失时提出澄清；依据用户要求和当前接口生成参数；结合工具结果更新计划；在错误、权限不足或结果不完整时选择修正、求助或停止。模型负责学习这些决策，任务状态维护、工具实际调用、权限校验、重试上限和动作放行仍由 Harness 与执行环境负责。

17.2.2 从轨迹中构造可监督样本¶

轨迹记录了任务执行过程，但轨迹本身不等于监督目标。一条轨迹可能同时包含系统指令、用户请求、工具定义、模型动作、环境反馈和后续修正；其中只有经过验证、值得复用的模型行为才应参与监督。面向 Agent 的样本构造，本质上是在保持决策因果关系的前提下，将完整轨迹转化为若干“可见上下文—目标行为”样本。

每个目标行为只能依赖该决策时刻已经可见的信息。某次工具调用尚未返回时，目标动作不能使用其结果；用户在后续轮次补充的条件，也不能提前进入早期决策的输入。否则，离线训练中的信息条件优于真实运行条件，模型即使拟合了监督数据，上线后也难以复现相同表现。

完整交互可以作为连续上下文输入，也可以按决策点拆分为多个历史前缀样本。两种方式都需要保留目标动作所依赖的任务约束、工具说明、历史动作和环境反馈。模型需要学习的是如何利用这些信息作出当前决策，而不是承担运行时的状态存储；如果必要状态在进入模型前已经被截断、遗漏或错误组织，应先修复 Harness，而不是依靠 SFT 补偿。

样本覆盖应同时包含正常执行、多轮推进和异常恢复，但不必将三者割裂为独立能力。对于工具使用，需要覆盖直接回答、发起调用和请求澄清等不同选择，避免模型形成“遇到任务就调用工具”的单一习惯；对于多轮任务，需要保留约束变化、已有结果和待完成步骤之间的关系；对于异常场景，则需要呈现错误发生后的可见状态，以及经过验证的修正、求助或终止行为。

在新增客户分析任务中，样本应保留客户口径、字段说明和当前可用工具，并将正确的查询动作及其依据作为目标。工具返回后，后续目标可以是核验统计口径、补充查询或形成有证据支持的答复。通过改变季度范围、字段表达、表结构和数据分布，可以使模型学习可迁移的处理原则，而不是记忆固定模板。

17.2.3 筛选监督内容并控制样本质量¶

任务最终成功，并不意味着轨迹中的每一步都值得模仿。成功轨迹可能包含多余查询、无依据的判断，或错误后偶然得到正确结果的步骤；失败轨迹中也可能包含有价值的错误反馈和恢复过程。因此，样本质量不能只由最终结果决定，还需要对关键行为逐步审查。

对于纠错场景，可以将错误动作保留在历史上下文中，使模型理解当前为何需要修正，但屏蔽该错误动作对应的训练损失，只监督经过验证的后续行为。例如，模型提交查询后收到“字段不存在”的反馈，样本可以保留原调用和错误信息，并将检查可用字段、修改查询及重新核验作为目标。这样训练的是错误后的恢复决策，而不是错误动作本身。

不同交互内容在训练中的作用可以按表 17.2-1 处理。

表 17.2-1 Agent SFT 中不同交互内容的监督处理

交互内容	在样本中的作用	常见监督处理
系统指令、用户请求与工具定义	提供任务目标、约束和动作空间	作为输入上下文，通常不作为本任务的生成目标
工具结果、环境观察与错误反馈	提供决策时可见的执行状态	保留在输入中，通常不计算生成损失
经验证的工具调用、澄清、修正和最终答复	表示模型应当学习的目标行为	对选定内容计算监督损失
用于解释恢复场景的错误模型步骤	说明失败状态及后续修正的起点	可保留为上下文，但屏蔽相应损失
尚未核验或质量存疑的步骤	无法确认是否值得模型复用	补充核验；无法确认时移出训练集

角色级掩码和质量级掩码解决不同问题。仅对模型生成内容计算损失，可以排除用户消息和工具返回；但错误调用本身也可能由模型生成，因此仍需更细粒度的行为标记。实施时应抽查实际参与损失计算的内容，确认工具调用结构、响应边界和错误步骤处理符合设计。

17.2.4 组织训练并保持能力边界¶

样本配比应同时反映生产任务分布和已经确认的能力缺口。高频任务用于建立稳定的基本行为，长链路任务用于训练跨步骤的信息利用，低频但影响较大的异常用于补足恢复能力。对于原本可以直接完成的简单任务，也应保留相应样本，防止训练后普遍增加工具调用或交互轮次。

样本不需要机械地等量混合。更合适的做法是根据开发集中的失败类型调整覆盖范围，同时保留必要的通用指令遵循和问答样本，检查专业任务改善是否伴随其他能力回退。重复复制少量同质示范只能提高这些示范的权重，不能替代对任务变化、状态分支和异常条件的真实覆盖。

训练和推理应使用相互兼容的对话模板、工具调用格式与结束标记。较长样本还需要检查截断位置，避免保留目标动作却丢失其依赖的约束或工具结果。否则，训练损失可能正常下降，但模型生成的动作无法被运行时解析，或缺少作出正确决策所需的信息。

参数更新可以采用全量微调，也可以使用 LoRA 等参数高效微调方法。LoRA 能够减少可训练参数和相关资源开销，适合在预算受限时快速迭代；全量微调提供更大的参数调整空间，但通常需要更高的训练和版本维护成本。二者都不能替代数据质量控制，也不能天然避免能力回退，最终选择应根据基座模型、任务复杂度、资源预算和独立评测结果确定。

17.2.5 通过执行评测验证行为泛化¶

训练损失下降只说明模型更容易生成监督样本中的目标内容，不能证明它能够在真实交互中完成任务。SFT 的验收应让候选模型在固定的 Harness、工具接口和执行预算下自主运行，由环境返回实际反馈，再观察早期决策如何影响后续执行。若每一步都提供标准历史，只检查模型能否续写下一条标准响应，就无法暴露错误累积和恢复失败。

质量关注任务是否完成、关键约束是否满足，以及答复是否有执行结果支持；可靠性关注不同输入、长交互和异常条件下的重复表现；成本关注工具调用次数、token、端到端时延和单位成功任务成本；安全则检查权限边界、危险动作和停止条件是否得到遵守。工具调用格式正确率等局部指标可用于定位问题，但不能替代完整任务的验收。

测试集应尽量按任务族、模板或数据来源进行分组，避免同一任务的近似改写同时进入训练集和测试集。对于新增客户分析任务，可以改变季度范围、字段表达和数据分布，并加入历史客户再次付费、同一企业存在多笔订单等条件，检查模型能否继续正确应用新增口径。还应覆盖工具描述变化、用户中途修改要求和可恢复的执行错误，验证模型学习的是执行方法而不是固定表达。

比较不同模型版本时，应保持 Harness、任务条件和执行预算一致；如果同时修改提示词、工具协议或上下文策略，应将其作为组合变更单独记录。对存在采样随机性的任务，需要进行重复运行并报告波动范围。最终交付物应包括候选模型或适配器、训练与推理配置、数据版本，以及按能力缺口和统一准入指标组织的评测报告。

17.2.6 与 Agentic RL 和模型蒸馏衔接¶

SFT 适合将已经明确的正确行为转化为稳定的初始策略，但其效果受示范质量、任务覆盖和基座模型能力约束。当模型已经能够执行任务，却需要通过环境交互寻找示范之外的更优路径，或者需要处理长程信用分配问题时，可以进一步进入 Agentic RL；当成熟能力需要迁移到更小、更低成本或更易部署的模型时，可以使用教师输出或轨迹构造蒸馏数据，并主要通过 SFT 训练学生模型。

三种方法由不同问题驱动，而不是固定的流水线。SFT 可以作为 Agentic RL 的稳定起点，也可以直接承载输出或轨迹蒸馏；是否继续采用其他方法，应由执行评测暴露的剩余能力缺口和部署目标决定。

17.3 Agentic RL：以环境反馈优化决策策略¶

Agentic RL 使用模型在环境中执行任务产生的轨迹作为学习样本，并依据任务结果、过程状态或验证器反馈更新模型策略。它优化的不是某一条固定回答，而是模型在连续决策中选择动作的倾向：何时调用工具、选择哪个工具、如何生成参数、如何解释返回结果，以及何时修正、求助或终止任务。

SFT 与 Agentic RL 都可以优化工具调用和多步决策，二者的区别在于监督信号的来源。SFT 从固定示范中学习目标行为，提高示范动作在相似上下文中的生成概率；Agentic RL 则让策略在环境中产生一条或多条执行轨迹，再利用结果或过程反馈优化期望任务收益。前者要求目标行为能够被可靠示范，后者允许存在多种可行路径，但要求路径优劣能够被稳定评价。

延续前文的数据分析思路，假设任务变为“核验订单是否满足规则并发起退款”。模型可能正确查询订单，却跳过退款政策核验；也可能完成退款，但使用了不必要的工具调用。单独标注每一步的唯一正确动作并不容易，但任务是否完成、退款金额是否正确、政策是否满足、是否发生越权操作通常可以验证。此类任务具备进入 Agentic RL 的基本条件。

Agentic RL 不是对 Harness 或执行环境缺陷的补偿。如果必要上下文没有进入模型、工具定义存在歧义、权限控制可以被绕过，或环境无法稳定复现，训练只会把错误的观察和反馈固化进策略。本节因此按照“准入判断—环境与任务—奖励与验证器—Rollout 与策略更新—长程优化—独立验证”的顺序展开。

17.3.1 判断任务是否适合 Agentic RL¶

进入 Agentic RL 前，需要分别回答两个问题：这个任务是否值得使用强化学习，以及当前系统是否具备训练条件。前者由模型能力缺口和任务反馈结构决定，后者由环境、验证器、安全边界和训练成本决定。只有两类条件同时满足，Agentic RL 才是合理选择。

表 17.3-1 Agentic RL 准入判断

判断维度	适合进入 Agentic RL 的条件	条件不满足时的优先处理
问题归因	失败来自模型的动作选择、反馈利用或恢复策略	先修复上下文、工具协议、权限或执行环境
示范可得性	有效路径不唯一，难以为每个决策点提供稳定标签	若正确行为可稳定示范，优先使用 SFT
结果可验证性	任务结果或关键中间状态可由规则、测试或可靠评审稳定判断	先建设验证器或高质量标尺集
环境能力	任务可重复执行，状态可重置，探索可隔离，过程可追踪	先建设 Sandbox、模拟器或可回放环境
基础策略	模型已具备基本指令遵循和工具调用能力，能够产生一定比例的有效轨迹	先通过提示、SFT 或能力更强的基座建立可学习起点
投入产出	预期成功率、可靠性或单位成功任务成本的改善能够覆盖 Rollout 与环境维护成本	使用更低成本的模型、数据或 Harness 优化方案

其中，“结果可验证”比“过程能够被完整标注”更重要。Agentic RL 可以在多条路径之间寻找更优策略，但无法从不可靠的反馈中自动推断真实目标。如果退款验证器只检查“是否生成退款记录”，却不检查政策、金额和权限，模型就可能学会更快地创建不合规退款。

对退款任务而言，Agentic RL 的准入条件可以具体化为：订单、政策和退款状态能够在隔离环境中执行和重置；任务成功可由数据库状态与业务规则联合判断；模型已经能够调用基础工具，但仍存在漏检政策、错误恢复不足或调用成本过高等策略问题。若模型连工具参数格式都无法稳定生成，应先完成 SFT，而不是直接扩大 Rollout。

17.3.2 构建可交互、可验证的训练环境¶

Agentic RL 首先需要把业务任务转化为可重复的交互过程。外部系统存在模型无法直接观察的真实状态sₜ，模型通常只能看到用户请求、历史消息、工具定义和工具返回等局部信息oₜ。因此，更合适的描述是：模型依据截至当前时刻的交互历史hₜ=(o₀,a₀,…,oₜ)选择动作，而不是把单次观察当作完整状态。

对多数 Agent 而言，外部系统存在模型无法直接观察的真实状态；模型只能看到用户请求、历史消息、工具返回等局部观察。因此，更适合将任务描述为部分可观测序列决策过程。模型依据交互历史选择动作，而不是把单步观察直接视为完整状态。

令第 t 步可见信息为oₜ，动作记为aₜ，环境或验证器返回的反馈为rₜ ，一条执行轨迹可表示为：

τ = (o₀, a₀, r₀, o₁, a₁, r₁, …, oₜ, aₜ, rₜ)

模型历史记为 hₜ=(o₀,a₀,…,oₜ)，策略写作 πθ(aₜ|hₜ)，训练目标是在任务分布和环境转移下最大化期望累计回报：

J(θ) = E[ Σₜ γᵗ rₜ ],  aₜ ~ πθ(·|hₜ)

任务建模需要明确四个要素：

观察：模型在每一步能够看到什么，包括用户目标、上下文、工具描述、历史动作、工具结果和剩余预算。观察必须与生产环境保持一致，避免训练时获得线上不可用的信息。
动作：模型能够做什么，包括输出回复、调用工具、写入记忆、请求澄清、等待外部事件或结束任务。动作粒度可按完整回复、工具调用或更细的 token 级别定义。
转移：动作如何改变环境。工具调用可能成功、失败、超时或返回不完整结果；用户和外部系统也可能改变后续状态。
任务结束：任务结束还需要区分终止（termination）和截断（truncation）。任务成功、业务失败或预算耗尽被明确建模为失败状态时，应记录为终止；仅因外部采样时限、基础设施中断等与任务目标无关的原因停止时，才属于截断。只有截断后仍能获得有效的后继观察，并且价值函数能够基于后继历史 hₜ₊₁ 或其充分状态表示估计后续回报时，才适合进行价值 bootstrap；不能把所有未完成轨迹一律当作失败，也不能在缺少后继状态时强行续估。

训练环境应满足以下要求：

可执行：工具、数据库、沙箱或模拟器能够真实响应模型动作；
可重置：每次 rollout 可以恢复到明确的初始状态，避免样本相互污染；
可复现：记录任务、随机种子、工具版本、Prompt 和环境快照；
可审计：完整保存观察、动作、返回、时延、成本和终止原因；
可隔离：训练探索不得直接作用于真实生产数据或高风险系统。

退款任务可以压缩为如下环境规格：

{
  "task_id": "refund_017",
  "environment_version": "refund-sandbox-v4",
  "initial_observation": {
    "user_goal": "核验订单并发起退款",
    "available_tools": [
      "query_order",
      "check_policy",
      "create_refund"
    ]
  },
  "limits": {
    "max_steps": 12,
    "max_tool_calls": 8,
    "timeout_seconds": 90
  },
  "terminal_checks": [
    "refund_created",
    "policy_satisfied",
    "amount_verified"
  ]
}

这份规格不仅定义了模型可以做什么，也定义了系统如何判断任务完成。环境版本、工具协议或停止规则发生变化，模型面对的决策问题也随之变化，因此必须作为训练版本的一部分记录。

17.3.3 设计奖励与验证器¶

奖励定义了策略更新的方向。设计原则不是“让奖励更丰富”，而是让奖励尽可能贴近真实任务目标，并减少模型利用评价漏洞获得高分的空间。

奖励通常由四类信号组成：

结果奖励：任务是否完成，最终结果是否正确、完整、可验证。它与业务目标最接近，应作为核心信号。
过程奖励：关键中间状态是否满足要求，例如工具选择是否合理、参数是否合法、必要证据是否完成核验。它可以缓解终局奖励稀疏，但不应强制模型复制唯一流程。
成本信号：工具调用次数、token 消耗、执行时延、失败重试和人工介入。成本应在任务成功的前提下优化，不能诱导模型通过提前终止规避困难任务。
约束信号：权限、隐私、格式和操作边界。高风险约束不能只依赖负奖励，还必须由 harness 设置不可绕过的系统控制。

一个可操作的组合形式是：

R(τ) = w₁R_task + w₂R_process - λC_execution - μP_violation

其中，R_task 衡量任务结果，R_process 衡量关键过程，C_execution 表示执行成本，P_violation 表示约束违反。权重不应仅凭经验设定，而应通过离线回放、人工抽检和消融实验校准。

表 17.3-2 退款任务中的反馈层级

反馈层级	退款任务示例	设计边界
系统硬约束	禁止越权退款、限制金额、隔离真实账户	由 Harness 与执行环境强制实施，不能只依赖负奖励
结果奖励	退款已创建，政策满足，金额与订单一致	直接对应任务成功，应作为核心信号
过程奖励	已核验订单状态、退款政策和金额依据	只奖励可客观判断的关键状态，不规定唯一行动序列
成本信号	无效查询、重复调用、时延和人工介入	优先比较成功策略，避免诱导提前终止

反馈由验证器（Verifier）产生，通常包括三类：

规则验证器：基于结构校验、数据库状态、单元测试或业务规则评分。结果稳定、成本较低，适合可形式化任务。
模型验证器：评价开放式结果的正确性、完整性和一致性。覆盖面更广，但需要检查偏见、长度偏好和自洽性偏差。
人工反馈：用于校准复杂偏好、审查边界案例和验证自动评分。成本较高，适合构建高质量标尺集，而非覆盖全部 rollout。

奖励设计的主要风险如下：

奖励投机：模型找到评分规则的漏洞，而非完成真实任务；
代理目标偏移：局部指标上升，但端到端成功率、可靠性或用户价值下降；
评审器漂移：验证模型或业务规则变化后，历史奖励与当前标准不再一致。

对应的控制原则是把训练奖励、独立评测指标和系统约束分开：奖励负责提供学习信号，独立评测判断能力是否真实提升，系统控制保证任何模型版本都不能越过操作边界。这三套机制作用于不同对象、在不同时刻反馈，其边界关系如图 17.3-1 所示。

图 17.3-1 Agentic RL的三重控制边界

17.3.4 组织 Rollout 与策略更新¶

Agentic RL 的基本循环是：模型在环境中执行任务，系统记录交互轨迹，验证器（Verifier）计算反馈，训练器据此更新策略，再由新策略重新执行任务。

flowchart LR
    A[训练任务采样] --> B[策略 Rollout]
    E[版本化环境与工具] --> B
    B --> C[轨迹存储]
    C --> D[Verifier 评分]
    D --> F[回报与 Advantage]
    F --> G[策略更新]
    G --> H[新策略版本]
    H --> B
    C --> I[开发集失败分析]
    I --> A
    H --> V[开发与验证集评测]
    V --> A
    H -.冻结候选版本.-> J[发布候选]
    J --> K[固定留出集一次性评测]
    K --> L[准入判定]

图 17.3-2 Agentic RL的训练闭环

一轮训练通常包含以下步骤：

任务采样：从训练任务分布中按场景、难度和决策跨度采样，避免简单任务占据主要训练预算；
交互采样：使用行为策略进行 rollout，对同一任务生成一条或多条轨迹，保留成功、失败和恢复路径；
反馈计算：由环境状态、规则验证器和模型验证器生成结果奖励及必要的过程信号；
信用分配：估计不同动作对最终回报的贡献，将轨迹级反馈转化为可学习的优势（Advantage）信号；
策略更新：使用 PPO、组相对策略优化或其他策略梯度方法更新模型，并通过裁剪目标与 KL 正则抑制过大的策略漂移；
版本注册：绑定模型、环境、工具、Prompt、验证器和训练配置，保证收益可追踪、问题可回放。

一个不依赖具体算法的训练骨架可以压缩为：

policy = initialize_from_base_or_sft_model()

for iteration in range(num_iterations):
    rollout_policy = freeze(snapshot(policy))
    tasks = sample_tasks_by_scenario_and_difficulty()
    trajectories = rollout(tasks, rollout_policy, pinned_environment)
    rewards = verifier.score(trajectories, pinned_verifier)
    update_batch = assign_credit(trajectories, rewards)
    policy = update_policy(policy, rollout_policy, update_batch)
    evaluate_on_development_suite(policy)

candidate = freeze(select_by_validation_results())
evaluate_on_locked_holdout(candidate)
register_if_pass(candidate)

使用基于价值估计的 PPO 训练时，Rollout 通常由更新前的行为策略生成，再利用概率比率裁剪限制策略变化，并通过价值函数估计优势；参考策略 KL 可以进一步抑制偏移，但不是 PPO 的必备定义。PPO 属于近似 on-policy 方法，轨迹跨多个策略版本反复复用会增加离策略偏差，需要限制复用范围或进行相应校正。

组相对方法改变的主要是优势基线：它对同一任务生成多条轨迹，用组内相对回报替代单独训练的价值模型；策略更新仍可采用 PPO 式裁剪，同样需要关注采样策略与当前策略的偏差。它适合能够并行采样且同一任务存在明显回报差异的场景；如果组内结果几乎相同，优势信号会趋近于零，而多轨迹 Rollout 也会增加执行成本。

表 17.3-3 优势估计方式的选择条件

方式	主要优势	主要代价	适用条件
价值模型基线	可结合状态价值估计，对不同轨迹位置构造较细粒度优势	需要训练和维护价值模型，系统复杂度较高	能够获得稳定价值估计，任务需要细粒度信用分配
组相对基线	利用同任务多轨迹比较，无需单独训练价值模型	Rollout 成本较高，依赖组内回报差异	任务可重复采样，验证器能够稳定排序

算法不能弥补任务和奖励设计缺陷。无论选择何种优势估计和策略更新方式，都应先确认奖励具有区分度、Rollout 覆盖有效路径、环境状态可重置，并且策略更新后的收益能够在独立任务集上复现。

工程上，Agent 执行系统与模型训练系统通常需要解耦。执行侧负责维护上下文和状态、调用工具、实施权限、采集轨迹与反馈；训练侧负责任务采样、奖励计算、优势构造、参数更新和模型注册。两侧通过标准化模型调用接口和轨迹协议连接，但工具版本、Prompt、环境、验证器和策略版本必须共同登记，才能回放收益与定位退化。

在平台实现中，PAI 强化学习服务可用于组织任务与并行 Rollout、接入规则或模型验证器并执行策略训练；工具调用和状态变更则可在隔离的 Sandbox 环境中运行。平台的价值不是替业务定义奖励，而是以标准化接口连接环境、轨迹、训练与评测，使整个过程具备可复现、可扩展和可审计的工程基础。

17.3.5 优化长程决策与失败恢复¶

长程任务的困难不只是步骤更多，而是反馈更晚、有效路径更少，且早期错误会改变后续状态。终局失败通常由多个决策共同造成，把相同回报平均分配给所有动作，难以识别真正需要调整的位置。

flowchart TD
    G[任务目标] --> P[规划]
    P --> T[工具选择]
    T --> X[执行与观察]
    X --> R[修正或继续]
    R -->|继续执行| P
    R -->|满足终止条件| O[最终结果]

    O --> RT[终局奖励]
    P --> RP[规划检查]
    T --> RV[动作合法性]
    X --> RC[成本信号]
    R --> RR[恢复质量]

    RT --> C[信用分配]
    RP --> C
    RV --> C
    RC --> C
    RR --> C
    C --> A[各决策步 Advantage]

图 17.3-3 Agentic RL 的信用分配机制

提高长程学习效率可以从四个方面入手。首先，采用课程式任务采样，从短轨迹和强反馈任务开始，再逐步增加工具数量、状态变化和决策跨度。其次，只在能够客观验证的阶段性状态提供过程反馈，例如“订单已核验”“政策已满足”，而不是为每一步自然语言推理打分。再次，对同一任务采样多条轨迹，用相对结果识别更优路径。最后，显式覆盖参数修正、工具切换、状态回滚、请求澄清和合理终止，使恢复行为进入可探索的任务分布。

轨迹分段本身不会自动改善信用分配。只有当分段同时对应可验证的子目标、阶段奖励、价值估计或层级策略时，才可能缩短信号传播距离；如果只是把长轨迹切成若干文本片段，却没有可靠反馈，模型仍然无法判断哪个早期动作导致了最终结果。

退款任务中的两条轨迹可以形成直观对照：

轨迹 A：查询订单 → 直接创建退款 → 政策校验失败 → 任务失败
轨迹 B：查询订单 → 核验退款政策 → 校验金额 → 创建退款 → 任务成功

Agentic RL 不要求把轨迹 B 的每一步定义为唯一标准答案，而是利用“退款成功、政策满足、金额正确、无越权操作”等反馈，提高产生合规成功路径的概率。如果另一条路径同样满足结果、约束和成本目标，也应被视为有效策略。图 17.3-4 把这一思路展开为多条候选轨迹：既包含结果失败与违反硬约束被拦截的路径，也包含成本不同的两条合规成功路径，训练目标是提高落入有效策略集合的概率，并在集合内偏好更低成本的策略。

图 17.3-4 多路径探索与有效策略集合

失败轨迹需要区分使用方式。它们可以直接用于错误分析、任务重采样、奖励设计，也可以经过验证后转化为 SFT 的恢复样本；但若用于 PPO 等近似 on-policy 的策略梯度更新，应保持与当前策略足够接近，或采用适当的离策略校正。将历史失败轨迹无限回放并不会自然产生有效的策略梯度。

探索也必须服从系统边界。最大步数、工具权限、资源预算和可写数据范围应由 Harness 与 Sandbox 控制。奖励可以鼓励模型减少无效行动，却不能代替权限系统阻止高风险调用。

17.3.6 通过独立评测确认真实收益¶

训练奖励上升只能说明策略更擅长获得当前奖励，不能证明真实任务能力已经提升。独立评测的作用，是在训练回路之外回答一个更严格的问题：冻结后的 RL 模型，在相同系统条件下，是否比基线模型更稳定、更安全且更经济地完成真实任务。因此，验收应按以下四步展开。

第一步，冻结候选版本并建立可比基线。对基础模型、SFT 模型与 RL 模型进行对照时，应保持 Prompt、Harness、工具协议、执行预算和环境版本一致。模型版本及其训练配置需要单独登记，避免把 Prompt 调整、权限放宽或环境简化带来的收益误判为策略能力提升。

第二步，隔离评测数据与评测机制。训练阶段使用的反馈不应直接充当发布结论，具体包括：

开发集用于设计任务、奖励和验证器，允许反复迭代；
验证集用于选择模型版本与推理配置；
锁定留出集仅用于候选版本冻结后的发布验收，并按任务模板、业务实体、环境种子和工具版本与训练数据隔离；
训练验证器与独立评测器应尽量分离。采用模型评审时，需要通过人工标尺集验证一致性，并检查其对长度、措辞和模型身份的偏好；对高分轨迹还应进行人工抽检，以排除评分漏洞、隐藏状态和环境实现细节的利用。

即使没有直接使用留出集调参，长期依据同一留出集的通过结果选择版本，也会产生间接过拟合。因此，需要定期更新私有任务、轮换环境种子，或保留新的影子评测集。

第三步，从四个维度报告端到端结果。独立评测仍应遵循 17.1 的质量、可靠性、成本和安全准入框架，但指标必须覆盖完整 Agent 运行结果，而不是只观察模型输出：

质量：报告端到端任务成功率，并确认高分不是来自环境捷径或验证器漏洞；
可靠性：对同一任务执行多次 Rollout，报告成功率波动、失败类型和必要的置信区间；
成本：统计单位成功任务的平均 token、工具调用次数、时延和资源消耗，而不是只比较单次模型调用成本；
安全：统计越权尝试、约束拦截、错误状态变更和异常终止。这里既要评价模型产生违规动作的频率，也要单独验证 Harness 与执行环境是否能够可靠拦截。

落实到退款任务，可以重点报告合规退款成功率、工具失败后的恢复率、越权或金额错误率，以及每个成功退款的平均 token、工具调用次数和端到端时延。

第四步，解释收益来源并形成发布判断。当 RL 模型优于基线时，仍需通过消融实验判断收益来自何处，例如分别移除过程奖励、成本信号、课程采样、恢复任务或特定验证器，再观察端到端成功率、异常恢复率和单位成功任务成本的变化。如果训练回报提高而独立成功率没有同步改善，应优先检查以下问题：

奖励定义是否鼓励了代理目标或捷径；
训练验证器是否存在系统性偏差；
训练环境是否向模型泄漏了答案或隐藏状态；
训练环境与生产环境是否存在任务、工具或状态分布差异。

上线应采用分任务、分流量灰度，并预先设置扩大、暂停和回滚条件。只有当独立评测与真实流量均显示稳定收益，且质量、安全和成本护栏持续满足准入要求时，才能认为 Agentic RL 的改进完成了从“训练奖励上升”到“真实系统收益”的验证。

这一判断也构成 Agentic RL 落地的最终边界：问题应确实来自模型策略，环境应能够重复执行并提供可信反馈，训练收益还应能够在独立任务和完整 Agent 系统中复现。若任务不可验证、环境不可复现或系统控制存在缺陷，强化学习可能把偏差固化进模型。因此，Agentic RL 既是模型优化问题，也是环境工程、反馈工程和评测工程的联合问题。

17.4 模型蒸馏：迁移任务能力，降低执行成本¶

大模型为 Agent 提供了更强的规划、工具使用与错误恢复能力，但如果每一步决策都依赖高成本模型，调用费用、端到端时延和服务容量会很快成为规模化瓶颈。模型蒸馏的目标并不是简单地让小模型“说得像”强模型，而是把强模型在任务执行中表现出的有效决策迁移给目标模型，使其能够以更低成本独立承担可界定、可评测的工作，并在超出能力边界时主动交还给教师模型。

因此，Agent 蒸馏应回答两个相互约束的问题：哪些能力可以稳定迁移，以及迁移后是否真正降低了每个成功任务的总成本。前者要求训练数据覆盖 Agent 的交互决策，而不只是最终答案；后者要求把失败、重试、工具调用和教师兜底一并纳入核算，而不只比较单次模型调用价格。

17.4.1 确定蒸馏目标：确定能力范围与教师、学生模型¶

蒸馏设计应从线上职责出发，而不是从模型尺寸出发。教师模型需要在目标任务上具备足够高且稳定的成功率，并能产生可验证的示范；学生模型则要在质量底线、推理时延、显存占用、吞吐与单位调用成本之间达到可部署的平衡。若教师在某类任务上本身不稳定，蒸馏只会更高效地复制其错误。若学生容量过小，增加示范数量也未必能弥补表示能力与长程规划能力的不足。

可先建立一张“任务—职责—风险”矩阵，将任务划分为学生独立执行、学生执行且教师校验、教师直接执行三类。任务边界至少应包含输入分布、允许调用的工具、最大行动步数、成功判定方式和不可接受的失败类型。对于高风险或不可逆操作，即使学生在离线评测中达到较高成功率，也不宜仅凭平均分取消教师校验。

Agent 能力迁移通常有两种范围。完整 Agent 行为迁移要求学生学习从理解目标、制定计划、选择工具、生成参数、解释观察到最终作答的连续过程；技能级迁移则只让学生承担其中一个稳定环节，例如工具路由、查询生成、参数抽取、结果核验或格式转换。后者更容易定义成功标准和故障边界，也更适合作为首次落地的切入点。

AgentDistill 的实验表明，蒸馏 Thought—Action—Observation 轨迹可以让较小模型学习检索和代码工具的组合使用，而不只是复现最终答案；其训练损失覆盖教师的思考与动作 token，不把环境返回的 observation 作为预测目标。这一结果说明，工具名称、查询内容和调用参数只要被序列化为动作，就可以纳入统一的语言建模目标。但该工作仅在固定工具协议、有限步数和特定任务集上验证，不能据此推断任意复杂 Agent 能力都能完整迁移。

教师与学生的选择可用以下四项约束共同决定：

任务覆盖决定教师是否“会做”；
示范可验证性决定错误数据能否被过滤；
学生容量决定其能否承载所需技能；
线上预算决定蒸馏后是否具有经济意义。

实践中，应先用候选学生完成小规模可教性测试，再决定数据规模和训练投入，避免在能力上限尚未明确时盲目扩大蒸馏集。

17.4.2 构造教师信号：从任务输出到交互决策¶

教师信号的价值取决于其是否覆盖了学生上线后必须作出的决策。仅用最终答案训练，学生可能学会结果形式，却没有学会何时调用工具、如何构造参数以及观察异常后如何调整。对 Agent 而言，更有用的监督通常沿着四个层次逐步增加：

最终输出提供结果级模仿；
推理说明提供中间依据；
结构化动作提供工具与参数决策；
多轮轨迹则进一步覆盖行动后的状态变化和恢复行为。

教师信号	主要学习对象	优点	主要局限
最终输出	答案、格式、风格	生成成本低，适合黑盒教师	难以学习工具时机和失败恢复
标签与理由	结果及任务相关依据	比纯标签提供更密集监督	理由可能事后合理化，也可能复制教师偏差
结构化动作	工具选择、参数、约束	可直接评测动作是否合法	需要稳定的工具协议和参数校验器
多轮轨迹	计划、行动、观察、修正	最接近真实 Agent 执行分布	轨迹昂贵，错误会沿多轮累积
概率信号	每个决策位置的相对偏好	保留教师不确定性，监督更细	依赖教师概率接口、词表与 tokenizer 对齐

按教师可见信息，蒸馏又可分为硬目标和软目标。硬目标只需要教师生成文本或动作序列，适用于闭源 API、跨模型架构和不同词表的场景，但会丢失教师在候选 token 之间的相对偏好。软目标使用教师的概率分布或 log-prob，能够告诉学生“哪些替代行为也合理、哪些行为几乎不应选择”，但通常要求访问教师的概率接口。在具体系统中，软目标训练还可能增加概率数据的传输与存储开销；教师和学生 tokenizer 不一致时，也需要额外设计对齐方案。因此，是否使用概率蒸馏不是单纯的算法偏好，而是由教师访问方式和训练基础设施共同决定的工程约束。

教师示范进入训练集之前还必须经过验证。最终答案可用标准答案或裁判器检查，工具动作可用 schema、权限和执行结果检查，多轮轨迹则应同时检查任务成功、步骤合法、调用效率和安全约束。过滤错误轨迹并保留失败原因，比单纯扩大未经验证的教师样本更重要。

17.4.3 选择蒸馏路线：教师示范与学生自主交互¶

离线教师示范是最直接的起点。首先从真实业务分布中抽取任务，要求教师生成包含思考、动作、观察与最终结果的完整轨迹；随后用环境执行器、规则校验器或人工抽检验证轨迹，只保留成功且合规的示范；最后以监督微调学习教师的输出和动作。该路线实现简单、训练稳定，适合冷启动，但训练状态主要来自教师策略。学生一旦在部署时作出不同动作，就可能进入教师示范中从未出现的状态，后续误差因此持续累积。

在线策略蒸馏（On-policy Distillation，OPD）针对这一分布偏移，让当前学生先在环境中生成行为，再由教师对学生实际到达的状态提供监督。与离线 SFT 相比，OPD 的状态来自学生；与在线强化学习相比，OPD 不只依赖任务结束后的稀疏奖励，而是在每个 token 或动作位置获得教师的稠密评价。这使训练能够集中处理学生“真正会犯的错”，而不是重复学习教师已经熟练覆盖的状态。

设学生策略为$\pi_\theta$，教师策略为$\pi_T$，学生在前缀$s_t=x_{<t}$上采样动作或 token$a_t$。OPD 可最小化学生到教师的反向 KL：

$\mathcal{L}_{\mathrm{OPD}} = \mathbb{E}_{\tau\sim\pi_\theta} \left[ \sum_t D_{\mathrm{KL}} \left( \pi_\theta(\cdot\mid s_t) \,|\, \pi_T(\cdot\mid s_t) \right) \right].$

对学生已采样的 token，可用下面的单样本量估计给定状态下的局部 KL 差异：

$\hat d_t = \log \pi_\theta(a_t\mid s_t) - \log \pi_T(a_t\mid s_t).$

该量是目标函数的蒙特卡洛估计项，并不等同于完整训练梯度；实际优化仍需结合策略梯度或等价的梯度估计方法。这意味着训练系统不一定需要保存教师的完整 logits。教师可以在 teacher forcing 下对学生已生成的序列打分，只返回每个已采样 token 的归一化 log-prob；但教师服务仍需支持对给定序列计算概率，只有文本生成接口而没有 log-prob 能力时无法直接采用该方案。不同 tokenizer 之间如何稳定对齐，也需要单独验证。

在学生容量或可表达策略族受限时，反向 KL 常表现出“模式寻求”（mode-seeking）特性：当教师对某个行为赋予很低概率时，学生把概率放在该行为上会受到显著惩罚；而学生不必覆盖教师所有可能模式。对于 Agent，这有助于学生收敛到一条连贯的高概率决策路径，减少在互斥工具或参数方案之间平均化的倾向。但“教师高概率”不等同于“任务正确”。反向 KL 仍可能复制教师偏差、压低必要探索，甚至让学生固守一种局部最优策略，因此必须与任务成功验证和异常覆盖联合使用。

模型蒸馏训练路线对比.svg

图为机制示意，不是跨模型、跨任务可复用的实测曲线。Thinking Machines Lab 在特定数学推理设置中报告了 OPD 的样本和计算效率优势，但其中部分 SFT 成本来自趋势外推，实验任务也不是通用 Agent 环境。因此，正式项目应使用自身任务的实测点重新拟合曲线，而不应直接引用图中的相对斜率作为收益承诺。

路线	训练状态来源	主要监督	典型优势	典型风险
Off-policy SFT	教师或历史轨迹	教师文本、动作或理由	稳定、易实现、适合冷启动	学生状态分布偏移，容易较早进入平台期
On-policy RL	当前学生轨迹	环境或验证器的结果奖励	可直接优化任务成功	奖励稀疏、信用分配困难、训练方差较大
On-policy Distillation	当前学生轨迹	教师逐 token 或逐动作评价	学生状态与稠密教师信号结合	依赖教师打分接口，可能压低探索并继承教师偏差

17.4.4 能力差距补强：困难任务、执行偏差与失败恢复¶

多轮 Agent 的失败通常不是在最后一步突然发生，而是由早期偏差逐步放大。一次错误的工具选择会带来无关观察，错误参数会污染后续上下文，未经核验的中间结论会使计划建立在错误前提上。因此，能力补强的重点不应只看最终失败标签，而应定位学生相对于有效路径的首个关键偏离。

可将失败轨迹拆解为四类缺口：

知识缺口表现为目标或约束理解错误；
决策缺口表现为工具选择或步骤顺序错误；
执行缺口表现为参数、格式、权限或调用协议不合法；
恢复缺口表现为面对空结果、超时、冲突证据或工具报错时继续重复原动作。

每一类缺口需要不同的数据补强。知识缺口适合增加解释与对照样本，决策缺口适合增加相邻候选动作及选择依据，执行缺口适合加入结构化校验，恢复缺口则需要显式提供“发现异常—诊断原因—更换路径—重新验证”的纠错轨迹。

一套可执行的补强闭环是：先按首错位置、工具类型和失败原因聚类；再为高频或高损失缺口补充困难任务、反例和局部纠错示范；随后让新学生在同类任务上自主执行；最后同时检查成功率、恢复率、调用步数和新引入的失败模式。只有当学生在独立保留集和分布外压力集上都改善，才应把专项补强视为有效，而不是对训练集的记忆。

17.4.5 验证蒸馏收益：质量保留与单位成功任务成本¶

蒸馏收益必须在同一任务集、同一工具环境、同一成功判定和同一流量条件下比较三类系统：教师模型、学生模型和原有线上模型。至少应记录任务成功率、一次通过率、平均与高分位行动步数、模型调用次数、工具调用次数、重试次数、教师兜底率、端到端 P50/P95/P99 时延以及全链路成本。只比较 token 单价，会忽略学生因规划能力下降而产生的额外步骤和失败重试。

“单位成功任务成本”应按所有任务的实际总成本除以成功任务数定义：

$C_{\mathrm{success}} = \frac{ \sum_{i=1}^{N} \sum_{a=1}^{A_i} \left( C_{\mathrm{student}} +C_{\mathrm{teacher}} +C_{\mathrm{verifier}} +C_{\mathrm{tool}} +C_{\mathrm{runtime}} \right)_{i,a} }{ \sum_{i=1}^{N}\mathbf{1}(\mathrm{task}_i\;\mathrm{success}) }.$

其中，$A_i$表示任务$i$实际发生的全部尝试，因而重试成本已经通过对各次尝试求和计入，无需另设一个可能重复计费的$C{\mathrm{retry}}$。教师兜底、验证器、工具服务和编排运行时都应按真实调用路径计入。只有当$\mathbb{E}[C{\mathrm{task}}]$已经完整包含这些条件成本时，才能简写为：

$C_{\mathrm{success}} = \frac{\mathbb{E}[C_{\mathrm{task}}]}{P(\mathrm{success})}.$

因此，“单次推理成本 × 平均重试次数 ÷ 成功率”只能作为极简近似。它默认每次尝试成本相同、失败与成功路径长度相同，并忽略工具调用与教师兜底；在多模型、多工具 Agent 中通常不成立。

质量保留可以用学生相对教师的成功率表示：

$R_Q=\frac{P_{\mathrm{success,student}}}{P_{\mathrm{success,teacher}}}.$

但部署决策不应只设一个平均$R_Q$阈值。对于高风险任务，应分别设置安全违规率、不可逆错误率和教师兜底召回率等门槛。若学生在低风险高频任务上达到质量要求，而在长程、开放域或高风险任务上不稳定，可以采用路由或级联：学生先执行，置信度、规则校验或多样本一致性不足时调用教师。

推理期蒸馏研究展示了这种级联思路：学生多次采样结果一致时直接执行，否则调用教师。收益可以来自“减少教师调用”，而不一定要求一次训练后完全替代教师。

Prodinit 的语音 AI 案例称，通过将大部分流量从 GPT-4.1 迁移到微调后的 GPT-4o-mini，并保留约 10% 教师流量，推理成本估算下降约 70%。该案例提供了灰度发布和持续监控的实践参考，但质量、时延、重试和运维成本缺少可审计的完整数据，应视为厂商案例，而不是普适收益基准。

最终 ROI 还要加入一次性投入。设数据构建、训练、评测、部署与迁移的固定投入为$F$，新旧方案每个原始任务的全路径期望成本分别为$\bar C{\mathrm{new}}$和 $\bar C{\mathrm{old}}$，若质量与业务价值近似不变，则盈亏平衡任务量为：

$N^* = \frac{F}{\bar C_{\mathrm{old}}-\bar C_{\mathrm{new}}}.$

若两种方案成功率不同，则应先把成功任务带来的价值和失败损失纳入单任务净收益。设成功价值为$V$、失败损失为$L$、成功率为$p$，单任务净收益为：

$g=pV-(1-p)L-\bar C.$

此时盈亏平衡任务量应写为：

$N^*=\frac{F}{g_{\mathrm{new}}-g_{\mathrm{old}}}.$

上述计算要求$F$、$V$、$L$与各类成本使用同一价值单位，且$g{\mathrm{new}}-g{\mathrm{old}}>0$；若新方案的单任务净收益不高于旧方案，就不存在有限的正向盈亏平衡点。这一表达能够避免“成本下降但失败损失上升”的伪收益。对仍需教师兜底的系统，应把兜底看作目标架构的一部分，而不是蒸馏失败的例外。只要路由准确、兜底比例可控，并且单位成功任务成本与端到端时延优于原方案，部分替代同样可以形成可验证的商业价值。

17.4.6 工程实现：从数据管线到线上灰度¶

前五节回答的是“迁移什么、怎么训练、如何补强与核算”。但对工程团队而言，蒸馏能否落地往往取决于另一组问题：教师轨迹如何被批量生产并自动验证，训练与采样如何在有限 GPU 上高效解耦，教师概率如何作为在线服务稳定提供，学生模型又如何安全放量并持续监控。本节按数据、训练、推理、部署四个环节，梳理业界较成熟、可直接复用的工程做法。

模型蒸馏工程实现闭环.svg

模型蒸馏端到端闭环：数据管线产出经验证的示范，训练环节完成能力迁移，采样与教师打分服务支撑 on-policy 迭代，部署环节以级联路由和灰度放量控制风险，线上监控与失败轨迹再回流到数据管线，形成持续迭代。

先定工程路线：黑盒序列级还是白盒分布级

工程实现的第一步不是选框架，而是确认教师能提供的信号形态，它决定了后续整条链路的复杂度。

黑盒（序列级）路线只依赖教师生成的文本或动作，流程是“生成轨迹 → 验证 → SFT”。它对教师没有权重或概率接口要求，跨厂商、跨 tokenizer 都能用，是企业落地的主流选择。DeepSeek-R1 的蒸馏阶段就明确“只做 SFT、不包含 RL 阶段”，属于典型的序列级硬目标训练（参考：DeepSeek-AI, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, 2025）；Qwen3 的长思维链冷启动同样是“教师对每题生成多个候选、仅保留通过验证的样本再做 SFT”（参考：Yang et al., Qwen3 Technical Report, 2025）。这说明头部推理模型的能力迁移并不必然依赖 logits 级对齐，黑盒路线已被大规模验证可行。

白盒（分布级）路线能拿到教师的 logits 或 log-prob，用 KL/JSD 做逐 token 对齐。监督更稠密、样本效率更高，但通常要求师生共享 tokenizer，并需要额外的概率缓存与对齐工程。

维度	黑盒序列级	白盒分布级
教师信号	生成文本 / 动作轨迹	logits 或 log-prob
教师访问	仅需推理 API	需权重或概率打分接口
tokenizer	可跨词表	通常需同词表（跨词表方案见下方 5 小节）
代表方法	轨迹 SFT、序列级 KD	GKD、MiniLLM、top-K logits 蒸馏
典型场景	闭源教师模型、跨厂商迁移	自研同族模型、追求样本效率

实践中可用下面这棵决策树快速选型：先看能否拿到教师的 logits/log-prob，再看师生是否共享词表，随后判断是否需要 on-policy 覆盖学生真实状态、以及显存能否承载 logits 缓存，最终落到黑盒序列级、白盒跨词表、白盒 on-policy 或白盒离线 logits-KD 四类可落地路线。

黑盒vs白盒蒸馏路线决策树.svg

黑盒/白盒蒸馏路线决策树：四个判断节点自上而下逐步收窄选择：教师只给文本时走黑盒序列级；能给概率但词表不同，则视是否愿意引入跨词表对齐，在“白盒跨词表”与“回退黑盒”之间取舍；词表相同且需要覆盖学生状态时走 on-policy 蒸馏，否则按显存条件选择离线 logits 缓存或分块 JSD。

数据管线：生产、验证、去污染与配比

对黑盒路线，数据管线既是成本中心，也是质量上限所在。生成阶段通常对每个任务采样多个候选：DeepSeek-R1 对强化学习 checkpoint 做拒绝采样来构造推理数据，Qwen3 用 Pass@N 保留可解样本。

验证应分层设计，优先用可自动化的规则校验：数学要求答案写成可解析的 box 格式、代码用编译器跑测试用例；无法规则化的部分再交给生成式裁判或 LLM-as-judge。DeepSeek-R1 明确不使用神经奖励模型，理由是其易被 reward hacking，这一架构决策对企业自建验证器有直接参考价值。

去污染与去重是防止评测虚高的关键动作。Tulu 3 用 8-gram 匹配做去污染，单条样本与测试集的重叠超过 50% 即判定为污染样本予以剔除、整个数据集重叠超过 2% 则直接弃用；规模化场景可借助 NVIDIA NeMo Curator 的 GPU 加速精确 / 模糊（MinHash+LSH）/ 语义去重。配比则应尽量参数化而非拍脑袋：阿里云 PAI EasyDistill 的 CoT 蒸馏按认知难度分箱，再为不同难度设定推理冗长度目标与每箱样本上限，把“数据配比”变成可配置项。
训练框架与参数高效蒸馏

主流开源框架已把上述路线沉淀为可配置组件。HuggingFace TRL 提供 GKDTrainer（用 lmbda 控制学生自生成数据占比、beta 在前向 KL 与反向 KL 之间插值）、DistillationTrainer（用分块 JSD 避免物化 vocab×seq 的 logits 张量以省显存）、MiniLLMTrainer（反向 KL，官方称是 Thinking Machines on-policy 蒸馏的泛化实现），以及 AsyncDistillationTrainer（教师以独立 vLLM server URL 提供、可部署在单独硬件上，但硬性要求师生共享 tokenizer）。NVIDIA NeMo/ModelOpt 通过把 loss 替换为输出 logits 间的 KL 实现蒸馏；NeMo-Aligner 让学生匹配教师 top-K logits，并建议离线缓存教师 logits——一个易踩的坑是缓存必须按降序保存，否则影响收敛，实践中 top_k 常取约 100 而非示例里的小值。国内团队可直接用 PAI EasyDistill 的统一 CLI 串起指令扩展、生成、评测、质量过滤到构建 SFT 数据的完整阶段，其后端兼容任意 OpenAI 兼容端点，输出可直接喂给 LLaMA-Factory 或 ms-swift 训练框架。

参数高效蒸馏已是优选项。TRL 官方说明所有 trainer 均支持通过 peft_config 启用 LoRA/QLoRA，LoRA 学习率通常取全参微调的约 10 倍，QLoRA 另需 bitsandbytes。对显存受限的团队，用 LoRA 做蒸馏能在单卡或少卡上完成能力迁移，再决定是否合并权重做全参精调。
采样与训练解耦

on-policy 路线的真正瓶颈是学生 rollout 采样，而非梯度计算。工程上应把“生成”交给高吞吐推理引擎、“训练”交给训练后端，两者解耦并行。TRL 支持与 vLLM server 协同：trainer 向 OpenAI 兼容端点发送 prompt token IDs 采样，每个优化步后经 NCCL 三段式把最新权重推回推理引擎，且 server 与 trainer 必须位于不同 CUDA 设备15。verl 采用 3D-HybridEngine 解耦计算与数据依赖，生成后端支持 vLLM 与 SGLang、训练后端支持 FSDP 与 Megatron-LM，并提供 Rollout Correction，用重要性采样与拒绝采样修正“推理引擎策略”与“训练策略”之间的分布漂移。OpenRLHF 则以 Ray+vLLM 把 Actor/Reward/Reference/Critic 分布到不同 GPU。

两个务实提醒：其一，框架与推理引擎的版本矩阵往往很严格（例如异步蒸馏对 vLLM、transformers 版本和 FSDP2 有硬约束），生产环境应锁定并记录版本组合；其二，异步与解耦必然引入一定 off-policy 偏差，需要配套的重要性采样或拒绝采样修正，否则训练容易不稳定。
教师打分服务与跨 tokenizer 对齐

白盒与 on-policy 路线都要求教师能对学生已生成的序列逐 token 打分。工程上把教师部署为一个无状态“打分服务”——只做前向、不做采样，与学生生成解耦，并按序列长度分桶以提高 GPU 利用率。vLLM 的 prompt_logprobs 参数天然适配这种 teacher-forcing 打分：它返回输入序列中每个 token 在其前缀下的 log-prob，正是计算“学生 log-prob 减教师 log-prob”这一逐 token 惩罚所需的量。需要提醒的是，推理引擎并不总是保证 log-prob 在版本间完全稳定，用于训练监督前应先做一致性校验并锁定引擎版本。Thinking Machines 的做法即让学生生成轨迹、送教师单次前向得到 log-prob、取负作为 advantage 并用重要性采样策略梯度更新学生，且采用零折扣只优化紧邻 token。
```
from vllm import LLM, SamplingParams

# 教师常驻为“打分服务”：只前向、不采样
teacher = LLM(model="teacher-checkpoint", tensor_parallel_size=4)

# prompt_logprobs 返回序列中每个 token 在其前缀下的 log-prob，
# 即教师对学生已生成轨迹做 teacher-forcing 打分所需的量
params = SamplingParams(temperature=0, max_tokens=1, prompt_logprobs=1)
outputs = teacher.generate(student_trajectories, params)

for out in outputs:
    teacher_logprobs = out.prompt_logprobs  # 逐 token 教师 log-prob
    # 训练侧用 (student_logprob - teacher_logprob) 作为 per-token 惩罚
```
当师生词表不一致、无法直接对齐 logits 时，可借助跨 tokenizer 蒸馏方法：ULD 用最优传输在分布层面对齐、不要求共享词表；DSKD 用双空间投影加 cross-model attention 统一师生输出空间；MultiLevelOT 在 token 级与序列级用 Sinkhorn 距离对齐，报告优于 SFT、SeqKD、MinED 与 ULD。这些方法让“用不同家族的强模型当教师”成为可能，但计算与实现复杂度更高，应在确有跨词表需求时再引入。
部署：级联路由、投机解码与灰度监控

蒸馏产物上线不必是“一次性全量替换”。FrugalGPT 提出的 LLM 级联通过学习“不同请求走哪些模型组合”，报告在保持精度的同时最高降低约 98% 成本，或在同等成本下精度提升约 4%。落到 Agent，就是路由 / 级联：学生先执行，当置信度、规则校验或多样本一致性不足时升级到教师兜底，兜底路径始终指向强模型。

蒸馏出的小模型还有第二个高价值用途——作为投机解码的 draft model（草稿模型）。draft model 的核心要求是“与目标模型分布高度一致且足够快”，而 KL 对齐的蒸馏正是训练这种高接受率小模型的主流手段，接受率越高、加速比越大；vLLM 支持 draft-model、EAGLE、n-gram 等模式，用拒绝采样保证输出分布无损，其跨词表 draft 模式目前仅适配 draft-model 方式且只支持贪婪草稿采样，选用前应核对版本能力。

上线放量应遵循灰度纪律：先用影子流量（不接真实请求）验证，再按比如1%→10%→25%→50%→90%→100% 逐档放量，每档设最短观察窗与自动回滚阈值（此为工程实践建议，具体档位按业务风险调整）。线上需持续监控 P50/P95/P99 时延、首 token 时延（TTFT）、任务成功率、教师兜底 / 升级率、投机解码接受率、师生一致性或 KL，以及业务侧质量抽检。同时维护一个固定的黄金数据集（golden set）加线上采样回流的回归评测集，在每个灰度档位跑离线回归并与线上指标交叉验证，防止学生模型在长尾场景悄悄退化——这也正是把监控数据回流到数据管线、驱动下一轮蒸馏的闭环起点。

17.5 模型验收与上线：在完整 Agent 中验证优化收益¶

训练完成并不等于模型已经具备上线条件。SFT、Agentic RL 或模型蒸馏改变的是模型参数，但真实应用效果由模型、Harness 与执行环境共同决定：模型负责理解状态并提出动作；Harness 负责组织上下文、暴露和校验工具协议、管理任务状态与权限，将放行后的请求路由至执行环境并回传观察；执行环境负责实际执行动作、维护业务状态并返回结果。候选模型只有进入完整 Agent，在可比较的系统条件下证明收益，并通过灰度替换验证真实流量中的稳定性，才算完成一次模型优化。

本节回答两个问题：训练后的模型能否改善真实应用，以及如何在不破坏既有能力和系统边界的前提下完成替换、回滚与下一轮迭代。整个过程由五个环节组成：建立可比较版本、完成系统适配、设置准入门禁、实施灰度替换，以及根据上线结果选择下一轮优化路径。

17.5.1 建立可比较的版本：模型、应用与环境配置¶

模型上线首先需要定义“比较的对象”。如果候选模型同时使用了新的 Prompt、更宽松的工具权限或更简单的任务环境，即使端到端成功率提高，也无法判断收益来自模型训练还是系统条件变化。因此，发布前应冻结并关联配置，但不能把不同层职责混为一谈：

模型配置：基础模型、候选检查点或适配器、训练方法、训练数据版本、训练超参数、对话模板、Tokenizer 版本和推理参数；
Harness 配置： System Prompt、Skill、上下文裁剪与记忆策略、工具 Schema、调用路由、并行策略、重试上限、停止条件、权限校验和人工介入规则；
执行环境配置：工具与业务服务版本、Sandbox 镜像、测试数据快照、外部依赖、资源规格以及可读写范围；
评测配置：任务集版本、环境种子、执行预算、验证器版本、重复运行次数、指标口径和准入阈值。

这些信息共同构成一个可追溯的候选发布单元。发布单元并不意味着将模型、Harness 与执行环境合并为同一对象，而是用显式依赖关系记录“哪个模型在什么应用和环境条件下通过了验收”。当 Prompt、工具协议或环境版本发生变化时，原有结论不能自动沿用。

为了区分模型训练与应用适配的收益，至少应保留两组对照：

纯模型对照：基线模型与候选模型使用相同的 Harness、执行环境和预算，用于判断参数更新本身带来的变化；
部署组合对照：候选模型使用上线所需的适配后 Harness，与当前生产版本进行比较，用于判断最终发布组合是否真正改善业务结果。

如果候选模型只有经过大幅 Prompt 扩写、额外重试或放宽工具权限后才能取得更高分，应把这些变化作为应用成本和风险单独报告，不能全部归因于模型能力提升。

17.5.2 完成系统适配：工具协议、上下文管理与执行预算¶

不同模型对消息模板、结构化输出、工具描述和停止信号的敏感性不同。直接替换模型端点，可能出现离线能力分数提高但 Agent 无法解析工具调用、重复执行动作或不能正确终止的问题。因此，系统适配的目标不是继续“调分”，而是确认候选模型能够在既有运行边界内稳定工作。

适配检查应覆盖以下内容：

工具协议兼容性：检查工具选择、函数名、参数类型、必填字段、枚举值和结构化输出能否被 Harness 稳定解析；模型负责产生候选动作，Harness 仍负责协议校验和动作放行；
上下文兼容性：检查对话模板、System Prompt、工具返回、历史轨迹、长上下文裁剪和记忆注入是否保留了模型决策所需的信息；
执行行为兼容性：检查模型在成功、失败、权限不足和信息缺失时，能否正确选择继续、修正、求助或终止，避免无限规划、重复调用和过早结束；
预算兼容性：比较替换前后的 token、工具调用次数、并行度、超时、重试和端到端时延，确认候选模型能够在现有资源上限内完成目标任务；
安全边界兼容性：验证模型产生越权或高风险动作时，Harness 与执行环境仍能执行独立校验和强制拦截，不能因模型表现改善而取消系统护栏。

适配过程宜采用由局部到闭环的测试顺序。先通过固定输入检查消息和工具 Schema，再用标准历史前缀验证单步动作，随后在 Sandbox 中自主运行完整任务，并通过工具超时、无效返回、资源不足和权限拒绝等故障注入验证恢复行为。只有闭环执行稳定，局部格式正确率才具有上线意义。

应用适配应形成独立变更记录。若调整了 Prompt、上下文策略、工具描述或重试规则，需要重新运行对应回归集；若适配改变了任务难度、可见信息或动作权限，则应建立新的评测基线，而不是继续沿用原分数。

17.5.3 设置准入门禁：任务收益、行为约束与能力回归¶

17.1 已给出质量、可靠性、成本和安全的统一指标，17.2—17.4 分别说明了不同训练方法的独立评测重点。本节不再重复设计评测体系，而是把已有评测结果转化为发布判断。准入不能依赖一个加权总分，而应采用“硬门槛 + 目标收益”：任何关键兼容性、安全或能力回归不合格都应阻断发布；通过硬门槛后，再判断目标任务收益是否足以覆盖适配、部署和维护成本。

候选发布单元至少需要通过以下门禁：

接口兼容门禁：工具调用格式、参数合法性、消息边界和终止信号达到运行要求，不依赖大量解析修复才能完成任务；
目标收益门禁：在锁定测试集和一致执行预算下，目标任务指标达到预先设定的最小改善幅度，并报告重复运行结果及置信区间；
能力回归门禁：核心通用能力、既有高价值任务和关键长尾场景满足预先设定的非劣效界值，不能用局部任务提升掩盖其他能力退化；
运行预算门禁：单位成功任务成本、超时率、重试率和端到端高分位时延满足上线预算，避免单次推理成本下降却导致完整任务成本上升；
安全硬门禁：危险动作、越权尝试、错误状态变更和有害输出满足风险阈值，关键约束穿透不得由其他指标抵消。

门槛、非劣效界值、最低样本量、置信区间口径和观察窗口应在查看候选结果前确定。安全门禁还要区分两个对象：模型产生违规动作的频率衡量策略风险，违规动作穿透系统边界并被实际执行的频率衡量 Harness 与执行环境的防护有效性。模型更少提出违规动作值得肯定，但系统仍必须独立拦截不可接受的操作。

发布判断可以归纳为三种结果：全部硬门禁通过且目标收益达标，进入灰度；硬门禁通过但样本量、收益稳定性或长尾覆盖不足，只能在限定范围继续验证；任一硬门禁失败，则退回对应责任层修复。若模型在信息充分时仍选错工具，应修复模型；若工具描述遗漏约束，应修复 Harness；若正确动作因服务异常未执行，应修复执行环境。

17.5.4 灰度替换与回滚：验证真实流量中的效果¶

离线评测只能覆盖已构造的任务分布。进入灰度前，应先建立离线指标与线上结果的映射，例如将离线任务成功率映射到真实业务完成率，将失败恢复映射到人工接管率，将工具与 token 消耗映射到单位成功任务成本。线上 A/B 对照还应固定分流单元，通常按用户、会话或任务分桶，避免同一长程任务在新旧模型间切换；最小样本量、观察窗口和区间估计口径同样需要预先确定。

模型替换宜按照以下顺序逐步扩大影响范围：

影子验证。对无副作用的问答或只读任务，可以将脱敏真实请求复制给候选版本并与旧版本双跑。对于依赖状态变更的多步任务，应在隔离 Sandbox 或状态副本中重放，或者只比较候选动作而不执行，不能把“未产生副作用”误认为完成了端到端验证。
低风险灰度。先选择只读工具、低风险任务、内部用户或明确业务范围承接少量真实流量，验证完整调用链、指标采集和告警链路。
分阶段扩量。在满足最低样本量和观察窗口后，按任务类型、用户范围或流量比例逐级扩大；高风险写操作应晚于一般问答和只读任务开放。
稳定替换。全量切换后继续保留旧版本和配置快照，在一个完整业务周期内观察任务质量、异常恢复、成本、时延和安全事件。

每个阶段都应预先定义三类判断条件：

扩大条件：目标任务收益达到门槛，核心回归满足非劣效要求，成本和时延在预算内，且未出现关键安全事件；
暂停条件：样本量不足、指标波动过大、数据延迟或归因不清，保持当前流量比例并补充观察；
回滚条件：出现关键约束穿透、持续性任务退化、异常成本增长、服务稳定性下降，或核心业务指标超过预设劣化阈值。

回滚对象应是完整的候选发布单元，而不只是模型权重。如果新模型依赖新的 Prompt、工具 Schema 或上下文策略，仅回退模型可能形成不兼容组合。生产侧需要保留可快速恢复的模型服务、Harness 配置和依赖版本，并定期验证回滚路径。回滚只能阻止后续请求继续使用故障版本，不能撤销已经在外部系统中完成的写操作；涉及资金、账户或业务状态的任务还需要独立的幂等、审计和补偿机制。

在平台实现中，可以利用 PAI-EAS 服务组和流量权重组织新旧模型共存，并通过滚动更新逐步替换实例；需要分批、暂停或回退服务更新时，应结合相应的更新计划与版本配置。模型服务之外的 Prompt、Skill、Harness 和工具协议仍应由应用侧独立版本化，并与对应的 EAS 服务版本共同登记，避免只有模型端可回退、应用端无法恢复。

17.5.5 持续迭代：识别能力变化并选择下一轮优化路径¶

模型上线不是本轮训练的终点，而是下一轮证据收集的起点。新版本产生的轨迹、Badcase、用户反馈、成本变化和回滚事件，应与候选发布单元绑定，并重新按照模型、Harness 和执行环境三层归因。只有被持续观察到、影响明确且可验证的问题，才应进入下一轮优化；单个偶发失败不应自动触发训练。

下一轮路径应由剩余问题的性质决定：

选择 SFT：已知正确行为可以被明确示范，主要问题是工具格式、固定流程、约束遵循或常见恢复动作不稳定；
选择 Agentic RL：模型已经能够进入任务，但需要通过可重复环境探索多步策略，且结果或关键过程能够被可靠验证；
选择模型蒸馏：现有教师在目标任务上稳定领先，下一阶段重点是降低模型规模、推理成本或时延，并可接受一定能力保真约束；
修改 Harness：问题来自信息供给、上下文组织、工具描述、状态管理、重试、停止或权限控制，而非模型在充分条件下的决策能力；
修复执行环境：正确动作因服务可用性、数据状态、资源限制或外部依赖而失败，此时继续训练模型不会消除根因。

在具备轨迹连接器、版本元数据映射和优化工作流配置的前提下，可以将版本化轨迹、失败归因、评测报告、灰度指标和发布事件接入 Trace2Optimizers，使优化提案能够追溯到具体任务、模型版本和系统条件。这里的目标不是把所有线上数据自动回灌训练，而是建立明确的触发机制：当某类问题在独立样本中稳定复现、业务影响超过阈值、责任层已经确认且存在可验证的修复路径时，再创建下一轮 SFT、Agentic RL、蒸馏或应用优化任务。

由此形成的持续优化链路是“运行—观测—归因—训练或系统修复—独立验收—灰度发布—再运行”。这条链路既允许模型能力持续变化，也要求每次变化都经过相同的版本记录、准入门禁和回滚控制，从而避免将持续迭代演变为不可解释、不可复现的线上试错。

第 17 章 模型调优¶