[LLM Agents F25] 后训练可验证 Agent：从数据到算法
| 字段 | 内容 |
|---|---|
| 作者/整理 | 基于 Jiantao Jiao 授课内容整理 |
| 来源 | Berkeley RDI |
| 日期 | 2026-08-18 |
![[LLM Agents F25] 后训练可验证 Agent：从数据到算法](cover.jpg)
官方幻灯片证据链：从可验证数据到稳定探索
本节按官方 deck 的顺序重建整套后训练逻辑。课程不是把“Agent”定义为多调用几次工具，而是把训练对象从单轮回答扩展为环境中的行动轨迹：模型读取状态、选择工具、改变环境，再由 verifier 判断是否达到可验证目标。读图时要持续区分人类偏好、程序化正确性、探索多样性和计算成本，因为四者并不会自动同步改善。
Agentic shift：从 human preference 对齐到 environment feedback 对齐
slides 1--6 先比较聊天模型与 Agentic 模型。早期 chat post-training 用 SFT、PPO、GRPO 等方法吸收偏好数据，目标是生成更令人满意的回答；Agent 模型还要与 sandbox、工具和环境状态交互，以 rubric、ground truth、unit test 等信号最大化正确性。讲者随后把课程拆成三步：获得可验证数据、定义“智能”的评估、找到把数据有效喂给模型的 recipe。
\lecturefigure{slides-images/slide-001.png}{官方 slide 1：Post-Training Verifiable Agents} \lecturefigure{slides-images/slide-002.png}{官方 slide 2：human preference aligned 与 environment feedback aligned} \lecturefigure{slides-images/slide-003.png}{官方 slide 3：早期 chat model 的偏好后训练} \lecturefigure{slides-images/slide-004.png}{官方 slide 4：可验证任务、环境交互与聊天任务的差异} \lecturefigure{slides-images/slide-005.png}{官方 slide 5：sandbox、tools 与 verifier 驱动的 Agentic model} \lecturefigure{slides-images/slide-006.png}{官方 slide 6：数据、智能定义与训练 recipe 三步框架}
读图：可验证奖励不是人类偏好的替代品
slide 2 写的是 “in addition to human preference”。代码通过测试不代表修改可维护，数学答案正确不代表解释适合用户，网页任务完成也不代表没有越权。生产模型通常需要联合目标：任务正确、交互可用、行为安全、成本可控。可验证信号的价值在于把某些结果从主观评价转成可重复执行的检查，而不是把所有价值判断压缩成一个测试。
课堂提示：讲者将 environment feedback alignment 作为 Agentic 模型的分界线。环境不是一段背景文字，而是会随动作变化的状态；工具也不是固定格式，而是读写环境的接口。若训练数据只保存最终答案，不保存动作与反馈，模型无法学习哪一步导致成功或失败。
可验证训练数据：Environment、Tools、Verifier 三元组
slides 8--11 定义数据结构。Environment 可以是代码仓库、浏览器、数据库或销售流程；Tools 是查询或修改状态的 API；Verifier 可以是单元测试、数学检查器、DOM 脚本或 ground-truth state。一个好数据集必须覆盖多种环境、工具和 verifier，并控制 verifier 的 false positive/false negative。困难任务尤其容易出现“答案其实正确但未被接受”或“错误轨迹碰巧过测试”的问题。
\lecturefigure{slides-images/slide-008.png}{官方 slide 8：Environment、Tools 与 Verifier 三个训练对象} \lecturefigure{slides-images/slide-009.png}{官方 slide 9：三轴多样性决定训练数据覆盖} \lecturefigure{slides-images/slide-010.png}{官方 slide 10：API、数据库、浏览、代码工具与多类环境/verifier} \lecturefigure{slides-images/slide-011.png}{官方 slide 11：verifier false positive 与 false negative}
术语消化：状态、动作与 verifier
状态 \(s_t\) 表示第 \(t\) 步环境可观测信息，动作 \(a_t\) 是模型生成的工具调用或文本操作，环境返回新状态 \(s_{t+1}\)。轨迹写作 \(\tau=(s_0,a_0,s_1,\ldots,s_T)\)。verifier \(V(\tau)\) 根据终局状态或整个过程返回奖励。若 \(V\) 只检查最终文本，模型可能通过破坏环境、修改测试或走危险捷径得分；因此高风险任务还要验证权限、过程不变量和副作用。
Verifier quality 决定奖励是否可信
同一个数学值可能写成 \(1/2\) 或 \(2/4\)；若题目要求最简形式，二者待遇不同。verifier 必须把题意编码准确。false negative 会惩罚正确的多样解法，压缩探索；false positive 会奖励错误策略，引发 reward hacking。老师强调：规模不能弥补 verifier 定义错误，困难 prompt 上反而更容易放大错误。
Holistic evaluation：benchmark、harness 与智能定义
slides 13--18 把评估从单一 benchmark 扩展为五个维度：工具、use case、模糊指令、软件系统和鲁棒性。off-the-shelf benchmark 测任务，agent harness 决定模型怎样探索 sandbox，focused unit eval 检查结构输出、条件指令和长轨迹。课程进一步提出 benchmark quality 的三个轴：hardness、diversity 和 separability。选择评估套件，就是在操作性地定义“智能”。
\lecturefigure{slides-images/slide-013.png}{官方 slide 13：Agent 评估需要量化追踪的五类期望} \lecturefigure{slides-images/slide-014.png}{官方 slide 14：benchmark、agent harness 与 focused unit evaluation} \lecturefigure{slides-images/slide-015.png}{官方 slide 15：任务与多种 harness 组成 holistic measurement} \lecturefigure{slides-images/slide-016.png}{官方 slide 16：多任务、多 harness、多工具共同定义智能} \lecturefigure{slides-images/slide-017.png}{官方 slide 17：任务集合是否足以成为智能度量} \lecturefigure{slides-images/slide-018.png}{官方 slide 18：hardness、diversity 与 separability}
读图：Harness swap 在测什么
同一模型接 OpenHands、bash-only MiniSWE 或不同搜索 harness，结果会显著变化。差异可能来自模型，也可能来自 scaffold 提供的工具、状态压缩、错误恢复和提示。固定 harness 只能测“模型+系统”的组合；交换 harness 才能估计模型对接口变化的鲁棒性。评估报告应同时记录 model、harness、tool version 和环境镜像，避免把系统升级误当成模型能力提升。
Benchmark quality 的三个轴
Hardness 要让当前模型既非全对也非全错，才能提供学习和比较信号；Diversity 要覆盖不同环境、工具和解法；Separability 要能稳定区分能力不同的模型。难但无稳定 verifier 的题不一定是好 benchmark，题量大但同质也不代表 holistic。Agent 评估还应报告成本、轨迹长度和失败类型。
先模仿再探索：Light SFT 与 RL 的职责边界
slides 20--23 把训练解释为在环境中采样多条 attempt，并强化正确且有价值的轨迹。SFT 先模仿专家示范，目的是降低采到荒谬动作的概率，使后续 rollout 在有限 compute 下可用；RL 再从当前策略探索不同轨迹。示范应多样，SFT 应轻，因为过度拟合单一示范会让采样分布变窄，RL 无法看到足够多的可替代策略。
\lecturefigure{slides-images/slide-020.png}{官方 slide 20：多 attempt、工具、verifier 与采样成本} \lecturefigure{slides-images/slide-021.png}{官方 slide 21：SFT imitate 与 RL explore} \lecturefigure{slides-images/slide-022.png}{官方 slide 22：light/diverse SFT 为 RL 提供有意义的 rollout} \lecturefigure{slides-images/slide-023.png}{官方 slide 23：SFT 排除低质量，RL 强化智能}
读图：SFT 与 RL 不是“基础版/高级版”
SFT 优化示范轨迹的似然，适合注入格式、工具协议和初始策略；RL 需要在线或近在线采样，再根据 reward/advantage 更新。若零样本策略几乎不会成功，RL 预算会浪费在无意义轨迹上；若 SFT 太强且示范单一，策略熵降低，RL 又缺少探索空间。二者的接口是 rollout 分布，而不是固定训练轮数。
老师强调：“SFT is just there”是强调其在本讲 recipe 中的功能边界，不是贬低 SFT。高质量示范仍决定工具语义和安全起点；但真正超越示范、发现新轨迹，需要当前策略在环境中探索并接受 verifier 反馈。
Train longer：稳定性、策略偏差与 entropy balance
slides 24--30 给出 good RL 的第一支柱。训练更久不是增加 step 数，而是控制 reward 上升与 entropy 下降的交换。off-policy 数据会使更新偏离当前策略，产生 biased update；clip 过于对称或过紧，会阻止低概率但有价值 token 增长；显式 entropy loss 可鼓励分布保持多样。课程引用 on-policy baseline、DAPO、Skywork 等结果说明这些干预如何影响 generalization。
\lecturefigure{slides-images/slide-024.png}{官方 slide 24：train longer、train harder、sample better 三支柱} \lecturefigure{slides-images/slide-025.png}{官方 slide 25：entropy-reward tradeoff 与训练时长} \lecturefigure{slides-images/slide-026.png}{官方 slide 26：减少 biased update 与平衡 clipping} \lecturefigure{slides-images/slide-027.png}{官方 slide 27：on-policy 更新、entropy control 与 generalization} \lecturefigure{slides-images/slide-028.png}{官方 slide 28：非对称 clipping 为低概率 token 留出增长空间} \lecturefigure{slides-images/slide-029.png}{官方 slide 29：显式 entropy regularization 路径} \lecturefigure{slides-images/slide-030.png}{官方 slide 30：entropy loss 的训练曲线}
术语消化：on-policy、off-policy、clipping 与 entropy
On-policy 使用当前策略采样的数据更新当前策略；off-policy 使用旧策略或其他策略数据，复用效率更高但 importance ratio 可能带来偏差。Clipping 限制新旧策略概率比，防止单次更新过强；上下界可非对称，让原本低概率的好动作有更大增长空间。Entropy 衡量动作分布不确定性，下降过快意味着策略过早集中，可能丢失可泛化探索。
Entropy 高低都不是独立目标
高 entropy 可能只是随机和冗长，低 entropy 也可能是模型已学会确定策略。课程关注的是与 reward、任务难度和 generalization 联合观察。显式 entropy bonus 若过大，会牺牲正确性；若完全不控制，训练可能快速塌缩。图中曲线支持特定实验干预，不能直接给出所有 Agent 任务的通用系数。
Train harder：任务应处于当前策略的可学习区间
slides 31--34 解释第二支柱。不能把最难题一股脑加入训练；若当前策略几乎从不成功，reward 全为零，梯度没有方向。也不能只训练已饱和的简单题。合适难度要求策略置信与 advantage/reward 之间保留有意义相关。课程用数学 benchmark 曲线展示过易、合适和过难数据，并讨论提高困难 prompt 权重来改善 learning signal。
\lecturefigure{slides-images/slide-031.png}{官方 slide 31：难度、策略概率与 advantage 的相关性} \lecturefigure{slides-images/slide-032.png}{官方 slide 32：简单、适中与超难数学数据的训练差异} \lecturefigure{slides-images/slide-033.png}{官方 slide 33：改善困难任务 learning signal 的干预} \lecturefigure{slides-images/slide-034.png}{官方 slide 34：对更难 prompt 提高奖励权重}
读图：难度课程应随模型移动
同一道题对不同 checkpoint 难度不同。可用 pass@K、成功率或 verifier reward 分布估计当前可学习区间：成功率接近 100% 的题贡献有限，接近 0 的题又缺少正例；中间区域通常最有信息。随着策略提升，curriculum 要动态加入更难题，并保留部分旧题监控遗忘。难度加权也要防止模型只优化高权重窄领域。
课堂提示：讲者把“hard but not impossible”与稳定训练绑定，而不是只追求 benchmark headline。Agent 环境中还要考虑失败成本：某些探索虽有学习价值，却可能产生危险副作用，因此困难任务应在 sandbox 中设计，并由权限和过程 verifier 约束。
Sample better：扩大计算必须配合选择与置信度
slides 35--38 给出第三支柱。增加每题采样数可获得更多推理路径，但只有高质量反馈和选择器才能把 compute 转成训练信号。GenSelect 把多个候选交给选择模型挑最佳；DeepConf 只在置信度高于阈值的候选上做 majority voting；beam-style reasoning 则在中间步骤搜索。最终 recipe 把 expert/synthetic/self-distilled SFT 与 train longer/harder/sample better 的 RL 组合起来。
\lecturefigure{slides-images/slide-035.png}{官方 slide 35：parallel reasoning、beam search 与 sample better} \lecturefigure{slides-images/slide-036.png}{官方 slide 36：GenSelect 从多个采样答案中选择最佳} \lecturefigure{slides-images/slide-037.png}{官方 slide 37：DeepConf 用置信阈值筛选后投票} \lecturefigure{slides-images/slide-038.png}{官方 slide 38：SFT 数据与三类 RL recipe 总结}
读图：Best-of-N 的收益来自覆盖与选择器
若单样本成功率为 \(p\)，独立采样 \(N\) 次至少一次成功的概率为 \(1-(1-p)^N\)；但系统不知道哪条成功，仍需 verifier 或 selector。候选高度相关时，独立假设会高估收益；selector 偏差也会选中更自信、更长却错误的答案。报告 sampling 方法时应同时给准确率、token/latency 成本、候选多样性和选择器错误。
更多样本不等于更多有效探索
重复同一路径只增加账单。temperature、prompt、tool policy、search branching 和模型 ensemble 都会改变多样性。DeepConf 的阈值过滤可能提高投票质量，也可能丢掉罕见正确路径；GenSelect 的 selector 需要独立校准。课程的结论是“sample better”，不是“无限 sample”。
开放式 collection：把环境、评估与算法放进同一公共闭环
slides 40--44 从单个 recipe 转向生态系统。第一步众包高质量环境、verifier 和评估；第二步研究 benchmark 的强弱并形成更 holistic 的智能定义；第三步发布能稳定训练、更难课程和多样响应的算法。最终开放问题借鉴人类学习：跨环境学习、重点课程、自主探索与教师示范如何平衡，以及不同智能定义如何比较。
\lecturefigure{slides-images/slide-040.png}{官方 slide 40：collection、智能定义与训练算法三步议程} \lecturefigure{slides-images/slide-041.png}{官方 slide 41：众包 environments、evals 与 recipes} \lecturefigure{slides-images/slide-042.png}{官方 slide 42：分析 benchmark 并用于 holistic RL scale-up} \lecturefigure{slides-images/slide-043.png}{官方 slide 43：稳定、困难、多样的算法进入共享 collection} \lecturefigure{slides-images/slide-044.png}{官方 slide 44：环境、课程、探索/教师与智能定义开放问题}
共享 collection 的最小治理要求
每个环境需要版本、许可证、工具权限、可复现镜像和 verifier 测试；每个 benchmark 需要污染、难度、分离度和 harness 记录；每个 recipe 需要模型、数据、采样预算、随机种子与失败日志。没有这些元数据，collection 会变成不可比较的任务堆，而不是可累积的科学基础设施。
讲义提醒：用人类学习作类比能提出好问题，却不能直接推出算法。人类环境、记忆、社会反馈和身体约束远比当前 sandbox 复杂。课程将它作为研究议程：建立可实验的环境集合，明确测量，再逐步验证 curriculum、exploration 和 imitation 的组合，而不是凭类比宣布答案。
课程背景与核心问题
本讲主题是 Post-Training Verifiable Agents。Jiantao Jiao 的切入角度非常明确：如果我们希望 Agent 在真实环境里长期稳定执行任务，仅靠 “对话质量好” 不够，必须把训练目标从 “讨好人类偏好” 扩展为 “在环境反馈下可验证地完成任务”。也就是说，模型输出不再只是文本，而是带状态影响的行动轨迹（trajectory）。
本讲主命题
Agentic 模型的后训练目标可以写成一句话：在保持人类可用性的前提下，最大化可验证任务回报（verifiable rewards）。它要求系统同时满足 “会沟通” 与 “会做事” 两类能力，而不是只优化其中一侧。
讲者在开场就强调，很多早期聊天模型主要优化的是人类偏好（preference alignment），例如回答礼貌、语气自然、内容看起来合理。但 Agent 任务往往包含代码修改、工具调用、数据库查询、外部 API 交互等动作，这些动作会改变环境状态，错误也会有累计效应。因此，训练目标需要显式纳入环境反馈。
从 Chatbot 到 Agent 的目标函数变化
- Chatbot：偏向 “回答是否让人满意”，奖励常来自偏好比较。
- Agent：偏向 “任务是否完成且可验证”，奖励更多来自程序化 verifier。
- 两者并非对立：生产系统通常需要 “偏好质量 + 任务正确率” 的联合优化。
课程还反复指出一个实践问题：当模型开始执行复杂任务时，“看起来像对” 与 “真的做对” 差距会迅速扩大。越是多步任务，这个差距越明显。因此，是否有高质量 verifier，以及 verifier 是否覆盖关键失败模式，直接决定后训练上限。
本章小结
本章建立了后续全部讨论的前提：Agent 后训练不是把聊天模型 “再微调一下”，而是把训练目标重构为 “环境中的可验证任务完成”。这会牵引数据、评估和算法三条线同时变化。
Agentic 模型与传统后训练范式的分野
为什么传统 RLHF 不能直接覆盖 Agent 需求
传统 RLHF 的核心是偏好建模：收集人类比较数据，训练 reward model，再用 SFT、PPO/GRPO 等算法提升 “被人偏好” 的概率。这条链路在对话系统上很有效，但在 Agent 场景里会暴露两个缺口：第一，许多任务存在硬约束（例如 JSON 结构、单元测试通过、SQL 正确执行）；第二，任务执行过程会跨越多轮工具调用，最终结果取决于过程正确性而非表面表达。
常见误区：把 Agent 训练当成 “更长的对话 RLHF”
如果只把 Agent 当作更长上下文的聊天任务，会出现三类问题：
- 过程错误被最终话术掩盖，导致 “可读不可用”；
- 奖励信号过度依赖主观偏好，难以覆盖硬性正确性；
- 训练后模型在真实工具链中不稳定，出现格式漂移和动作失配。
双目标训练：Preference + Verifiability
讲者的建议不是抛弃偏好目标，而是建立双目标后训练框架：模型既要保留自然交互能力，又要在环境中完成可验证任务。具体做法通常是让数据集和评估集同时包含 “偏好维度” 与 “任务维度”，并在训练阶段分配不同权重。
| 维度 | 传统对话后训练 | 可验证 Agent 后训练 |
|---|---|---|
| 训练对象 | 单轮或短多轮文本输出 | 长轨迹动作序列（含工具调用） |
| 奖励来源 | 人类偏好模型为主 | verifier + 偏好联合 |
| 失败表现 | 不够礼貌或不够有用 | 任务失败、格式失败、状态污染 |
| 验证成本 | 高度人工主观判断 | 可程序化自动验证比例更高 |
从 “回答” 到 “行动轨迹”
课程中的一个关键表述是：Agent 的核心单位不是 token，而是 trajectory。一次任务里模型需要先理解目标，再决定何时调用工具、如何解释工具反馈、是否需要重试、何时终止并汇报。这个过程本质是序列决策问题。
后训练单位变化
当训练单位从 “response” 变为 “trajectory” 后，数据标注、奖励计算、评估指标、甚至日志系统都要改变。很多工程团队的瓶颈并不在模型本身，而在没有把这套基础设施同步升级。
本章小结
本章结论是：Agent 后训练必须从 “偏好对齐” 升级为 “偏好 + 可验证任务完成” 的联合优化，并把训练单位重定义为可执行轨迹，而非单条文本回复。
可验证 Agent 的任务建模：环境、工具、状态
三元组视角：Environment / Tools / Verifier
在讲座中，讲者将可验证 Agent 数据与训练对象拆成三个核心部分：环境（environment）、工具（tools）、验证器（verifier）。这不是概念分类，而是可执行系统中的三类实际约束。
Environment 的含义
Environment 不只是 “题目文本”，而是包含运行上下文的完整状态：代码仓库文件、依赖版本、测试脚本、系统提示词、可访问接口、历史交互痕迹等。Agent 的每个动作都可能改变该状态。
工具调用不是附属能力，而是主能力
讲者强调，Agentic LLM 的一个核心能力是生成可被工具消费的 token 序列。也就是说，模型不仅要 “会说”，还要 “会调用”：参数正确、调用时机正确、错误恢复路径正确。工具链越复杂，训练数据越需要覆盖动作空间差异。
工具调用的三层正确性
- 语法正确：格式、字段、类型、JSON 结构合法。
- 语义正确：调用意图匹配任务目标，参数有业务意义。
- 时序正确：在正确阶段调用正确工具，避免无效循环。
状态转移与轨迹可验证性
Agent 在环境中执行任务时，关键不只是最终答案，而是状态转移是否可追踪。例如代码修复任务中，“改了什么”、“为何改”、“测试是否覆盖” 都应被记录并可验证。这就要求训练样本包含完整轨迹，而不只是终局结果。
只监督终局答案的风险
如果数据只给 “最终通过” 样本，模型可能学到不可泛化的捷径：
- 对中间步骤缺乏约束，导致不可解释行为；
- 面对分布外任务时，缺乏稳定的中间决策策略；
- 调试困难，错误定位成本飙升。
本章小结
可验证 Agent 的建模核心是把问题写成 “环境状态 + 工具动作 + 验证反馈” 的闭环系统。训练质量取决于这三者是否被同时建模，而非只强化最终文本回答。
训练数据构建：覆盖、组合爆炸与泛化
为什么数据问题在 Agent 里更难
讲者把 “高质量训练数据” 放在第一优先级。原因在于 Agent 任务空间是组合爆炸的：环境类型、工具集合、验证方式、任务目标可自由组合。即便在单一领域（如 coding），也会出现仓库结构、测试风格、错误类型、依赖生态的大幅变化。
Agent 数据难点是组合，而非规模
在 Agent 训练中，单纯增加样本数量并不能保证泛化。真正关键是是否覆盖了 “环境-工具-验证器” 的代表性组合，以及这些组合之间是否有足够多的跨域迁移信号。
数据集构建原则
结合讲座内容，可以将可验证 Agent 的数据构建原则归纳为以下四点：任务类型广度、动作多样性、验证维度完整性、失败模式显式化。尤其是失败样本，往往比成功样本更能提升鲁棒性。
| 原则 | 目标 | 落地做法 |
|---|---|---|
| 环境多样性 | 减少场景过拟合 | 同时引入数学、代码、检索、业务 API 等环境 |
| 动作多样性 | 提升策略广度 | 对同一任务保留多条高质量轨迹而非单解 |
| 验证多样性 | 防止单指标投机 | 单元测试、格式检查、规则引擎、人工抽检联合 |
| 失败样本显式化 | 学习错误边界 | 记录失败原因并在训练中加入负反馈 |
从 “看起来强” 到 “真实泛化”
讲者反复提醒：如果训练集与评估集过于相似，模型会出现 “指标高但真实任务崩”。这在 Agent 场景更严重，因为任务链路更长，任何一步分布偏差都会放大终局误差。
数据-评估同分布幻觉
若训练和评估过于接近，会导致团队误判模型能力：
- 在已见任务上持续提升，但在新任务上性能急剧下降；
- 模型学会针对 benchmark 的策略，而非学到一般能力；
- 部署后出现 “离线好、在线差” 的系统性偏差。
本章小结
Agent 数据工程的重点是 “覆盖正确的组合空间”。与其追求样本总量，不如优先保障环境、工具、验证器和失败模式的结构化多样性。
评估系统设计：从单点评分到 Holistic Evaluation
训练数据只有通过稳定测量才能形成迭代闭环。本节承接官方 slides 13--18，把“评估一个模型”拆成任务、harness、工具空间、指令鲁棒性和 benchmark 质量五个层面，重点说明模型能力与脚手架能力如何分离，以及单一平均分为何不足以定义智能。
Verifier 不是一个分数，而是一组机制
上一节从数据角度定义 verifier，这里转向评估系统：同一轨迹需要结果、结构、过程和安全多层检查。只有把这些检查的触发条件和失败原因分别记录，团队才能知道模型是不会解题、不会用工具，还是利用了测试漏洞。 课程中一个很重要的观点是：verifier 不应被理解为单个布尔规则，而应是多维度验证体系。代码任务可能用单元测试，数学任务可用 proof checker，结构化输出任务要校验 JSON 合法性与字段一致性，业务任务还要检查副作用边界。
Verifier 的分层设计
- L1 结果层：最终答案是否正确。
- L2 结构层：输出是否满足协议与格式要求。
- L3 过程层：关键中间步骤是否符合策略约束。
- L4 安全层：是否触发越权调用、数据泄露或危险动作。
Harness 交换与鲁棒性验证
讲者提到应在评估中引入 harness swapping：同一任务在不同执行框架、不同工具包装、不同系统提示下重复评测。如果性能大幅波动，往往说明模型依赖了偶然实现细节而非稳健策略。
Harness 交换的价值
它不是 “再测一次”，而是检测模型是否具备环境迁移鲁棒性。若模型只在某个固定 harness 上表现优秀，部署风险会很高。
评估污染与难度监控
课程中还强调 benchmark contamination 与 hardness drift。随着社区迭代加速，公开数据可能被训练过程吸收，导致指标失真。评估系统必须持续监控题目难度与分布变化。
高分不等于高能力
当 benchmark 被污染或难度下降时，高分可能只意味着 “见过类似题”。因此评估要包含：
- 新样本引入频率控制；
- 题目泄露风险审计；
- 难度分层报告（easy/medium/hard）；
- 跨 benchmark 交叉验证。
本章小结
可验证 Agent 的评估必须是 Holistic 的：多 verifier、多 harness、多难度分层、持续污染监控。单一分数无法支撑可靠部署。
后训练主流程：Light SFT 与 RL 的分工
两阶段框架
讲者给出的实践框架是两阶段：先做 Light SFT，再做 RL 强化。SFT 的作用是把模型带入 “可用轨道”，减少无意义动作；RL 的作用是让模型在反馈中持续探索并提升真实任务能力。
分工边界
- SFT：建立初始行为先验，压低明显错误率。
- RL：在可验证反馈下优化策略，提升复杂任务成功率。
如果 SFT 过重，模型会过度模仿演示、探索能力下降；如果 SFT 过轻，RL 早期会浪费大量算力在低质量轨迹上。
为什么 SFT 要 “轻且多样”
两阶段框架的关键不在名称，而在 SFT 结束时留下什么 rollout 分布。本小节解释为何示范需要覆盖多种正确策略、训练强度只需排除明显无意义动作，并用 entropy 与 OOD 表现判断模型是否在进入 RL 前已经过度收窄。 讲座明确提出 two requirements：SFT 样本要多样，且训练强度要轻。原因是 Agent 需要在 RL 阶段保持探索空间。过重 SFT 会把分布压得过窄，后续即便加大 RL 计算，也难以跳出早期模式。
轻 SFT 的工程判据
实践中可用如下信号判断 SFT 是否过重：
- 训练后采样熵快速下降；
- 同任务轨迹高度同质化；
- RL 初期奖励提升快但很快停滞；
- OOD 任务表现明显劣化。
RL 阶段的目标不是 “更高分”，而是 “更好学习”
讲者指出，RL 的关键在于让模型从自身错误里学习，而不仅是追求短期 reward 增长。换言之，反馈机制要能区分 “可修复错误” 与 “策略性错误”，并把更新集中在可提升区域。否则会出现训练奖励上涨、测试泛化不升反降。
只看训练 reward 的风险
如果团队只盯训练 reward 曲线，容易忽略：
- 探索空间塌缩（entropy collapse）；
- 对易题过拟合、对难题无增益；
- 在验证器缺陷处投机。
本章小结
本章的核心是两句话：SFT 负责起步，不负责封顶；RL 负责突破，但前提是保持可探索性。Light SFT + 强反馈 RL 是当前可验证 Agent 的主流工程路径。
强化学习关键现象：长训练、熵塌缩与探索维持
Light SFT 为 RL 提供可用起点，但并不保证长期学习。随着策略集中到少数高奖励轨迹，entropy、任务难度和样本多样性会共同决定训练是否继续产生新能力；本节把这三个现象作为动态监控对象，而不是在训练结束后只看最终 reward。
为什么 “训练更久” 不是自动有效
增加 optimizer step 只有在策略仍能探索且 verifier 仍提供区分信号时才有价值。本小节分析 reward 上升与 entropy 下降可能同时发生的情况，并说明平台期可能来自策略变窄，而非任务已经被真正解决。 讲者提出第一个观察：很多系统在 RL 中会很快进入性能平台期。根因之一是输出熵下降过快，模型只会重复高概率轨迹，难以继续发现新解。对长任务 Agent 来说，这意味着 “能做一点，但做不深”。
熵塌缩的实质
熵塌缩不是 “模型变差”，而是 “模型变窄”：它在少数轨迹上越来越确定，但失去探索不同正确路径的能力。对于复杂任务，这会直接限制上限。
第二观察：任务难度需要动态调度
如果训练样本长期停留在简单任务，模型很快 “学完”，后续更新收益极低；但如果一开始就喂过难任务，也会因为正反馈稀疏而学不动。因此，课程隐含了一个 curriculum 观点：难度应随能力上升动态调整。
难度调度的实践框架
- 起步阶段：高可验证、低复杂度任务保证有效学习信号。
- 中期阶段：提高组合复杂度，增加多工具协作场景。
- 后期阶段：引入长轨迹、弱监督、开放式问题，重点保探索。
第三观察：多样高质量响应是核心资源
课程把 “diverse high-quality responses” 作为第三支柱。这里的多样不是随机噪声，而是多条可行策略路径。只有当正负样本都具有结构多样性，RL 才能学到 “什么时候该怎么做”，而不是死记模板。
伪多样性的陷阱
如果多样性只体现在表面措辞，而动作序列和决策逻辑仍然单一，训练效果会被高估。真正有效的多样性应体现在工具选择、步骤顺序、失败恢复策略等决策层。
本章小结
长训练要有效，必须同时处理三件事：防熵塌缩、做难度调度、保证策略级多样性。否则训练越久，收益越小。
算法细节与工程权衡：On-policy、更新强度与熵正则
On-policy 与 Off-policy 的核心差异
讲者用直观方式解释了 on-policy：模型应优先从 “自己当前策略生成的轨迹” 中获得反馈。因为这些错误最贴近当前能力边界，学习效率更高。对 Agent 训练来说，这通常能更好地维持策略一致性和探索质量。
工程上如何理解 on-policy 优势
on-policy 的价值不是理论口号，而是减少 “反馈错位”：你给模型的奖励，最好对应模型当前真实会走的轨迹，而不是别的策略分布。这样更新方向更一致，避免学到不可复现行为。
更新强度控制：clipping 与解耦阈值
课程讨论了 RL 更新中的 clipping 调整：通过上/下界非对称设置，鼓励低概率 token 的合理探索，缓解过早收敛。讲者也坦诚这类技巧在当下更像 “有效工程 hack”，未必是长期最优理论形式。
工程结论
在可验证 Agent 训练里，稳定更新 与 保持探索 同等重要。只追求稳定会导致保守退化，只追求探索会导致训练发散。clipping、熵正则等机制本质上是在做这两个目标的平衡。
熵正则：显式维持可探索空间
当观测到熵持续下降时，常见做法是加入熵相关损失项，将生成熵维持在合理区间。讲座中提到社区已有多种实现方案，效果依赖任务、模型与 verifier 质量，尚不存在一次性通吃的方法。
不要把技巧当定律
当前许多有效技巧是 “经验可行”，并不代表理论已收敛。团队在迁移方法时应保留审计和消融流程，避免把某个数据集上的增益误判为普适规律。
本章小结
算法层面最关键的不是某个单一公式，而是 “反馈一致性 + 更新稳定性 + 探索维持” 三者协同。on-policy、clipping 调整、熵正则都是围绕这三点展开。
研究前沿与开放问题
理论与实践之间仍有明显断层
讲者明确指出，当前主流后训练算法与理想化机器学习理论并未完全对齐。实践中很多成功经验来自规模化试验和工程迭代，而不是闭式推导。因此，未来几年算法空间仍非常开放。
开放研究方向
- 更贴合 Agent 场景的策略优化目标；
- 更稳健的长轨迹 credit assignment；
- 更低成本的高质量 verifier 构建；
- 训练与部署一体化的在线反馈闭环。
从人类学习类比到可实现算法
课程多次使用 “人类学习” 做类比：先看示例，再做题，再拿反馈迭代。类比本身直观，但真正困难在于把它转成可训练、可扩展、可审计的算法与系统。这一点在 Agent 场景尤为突出。
类比可用，直译不可用
把人类学习过程直接翻译成算法通常会失败。可行路径是提取可操作原则，例如：
- 先建立基本可行策略（Light SFT）；
- 再以高质量反馈持续探索（RL）；
- 始终监控泛化与评估污染（Holistic eval）。
部署风险与治理议题
当 Agent 被用于代码、业务流程或关键系统，训练问题会直接转化为治理问题。模型是否会越权调用、是否会在弱验证场景投机、是否能被追责审计，都需要在训练和评估阶段前置设计。
能力提升必须伴随可控性提升
如果只提升任务成功率而不提升可解释性、可回滚性和权限治理，系统风险会随能力线性以上增长。可验证训练的真正价值，正在于把能力增长与治理能力绑定在一起。
本章小结
本章结论是：可验证 Agent 仍处于快速演化期，方法论尚未收敛。最值得投入的方向是把 “高质量反馈学习” 与 “可部署治理机制” 联合起来。
附录：工程落地检查清单
训练前准备清单
为了把课程中的方法真正落地，团队通常需要先完成 “训练前系统准备”。这一环节经常被低估，但它决定了后续 RL 是否能稳定推进。尤其是可验证 Agent 训练，任何日志缺失或工具观测缺失都会直接削弱反馈质量。
优先级排序建议
先把 “可观测” 做完整，再追求 “算法更强”。如果缺少高质量轨迹日志、工具调用回放和 verifier 诊断信息，再复杂的算法也会因为反馈噪声而收益有限。
| 阶段 | 检查项 | 通过标准 |
|---|---|---|
| 阶段 | 检查项 | 通过标准 |
| 任务定义 | 任务目标可程序化表达 | 对每类任务可写出明确 success/failure 条件 |
| 任务定义 | 终止条件明确 | 可判定 “何时应停止继续调用工具” |
| 环境建模 | 环境状态可序列化 | 能回放每一步状态变更并定位差异 |
| 环境建模 | 环境重置机制可靠 | 同一任务可重复运行并得到可比较结果 |
| 工具链路 | 工具 I/O 协议固定 | 字段、类型、错误码、超时策略均有文档 |
| 工具链路 | 工具副作用可审计 | 任意调用可追溯到操作者、参数、时间与结果 |
| Verifier | 结果层 verifier 完整 | 关键任务均有自动通过/失败判断 |
| Verifier | 过程层 verifier 可用 | 对关键中间步骤可检测常见违规模式 |
| 数据管线 | 轨迹采集字段齐全 | Prompt、action、observation、reward 全量记录 |
| 数据管线 | 失败样本可分型 | 至少区分工具失败、策略失败、验证器失败 |
| 训练系统 | 采样吞吐可监控 | 可实时观察样本速率、成功率、拒绝率 |
| 训练系统 | 更新稳定性可监控 | 可追踪梯度异常、loss 爆炸、熵突降等事件 |
| 评估系统 | 难度分层报告可产出 | easy/medium/hard 分层结果可自动生成 |
| 评估系统 | Harness 交换机制可运行 | 同任务可在不同 harness 下重复评测 |
| 治理与安全 | 权限边界已实现 | 高风险工具调用需满足显式授权策略 |
| 治理与安全 | 回滚链路可演练 | 关键失败可在分钟级回滚到安全状态 |
训练中监控面板
结合课程中的观察，团队在训练过程中至少应维护三块看板：能力看板（准确率/成功率）、探索看板（熵/轨迹去重率）、可靠性看板（格式正确率/工具错误率）。三者缺一不可。
推荐日常监控指标
- 任务成功率：按任务类别和难度分层统计，不看单一均值。
- 输出熵与去重率：监控探索是否过早塌缩。
- verifier disagreement：不同 verifier 对同轨迹是否冲突。
- 工具失败率：按工具类型和错误码分布聚类。
- 轨迹长度分布：防止出现无意义超长循环。
训练后验收与发布门槛
课程强调 “高分不等于可部署”。因此，训练后验收不能只看 benchmark 分数，还要看跨环境稳定性、异常场景恢复能力、权限边界遵守率。发布门槛必须写成制度化 checklist，而非临时判断。
发布前必须回答的三个问题
- 这个模型在分布外任务失败时，是否会安全失败（safe fail）？
- 当 verifier 冲突或不可用时，系统是否会降级而非盲目执行？
- 线上事故发生后，是否能在审计日志中还原完整责任链？
本章小结
工程落地的关键不是 “再加一种算法”，而是把任务定义、状态观测、验证体系、监控面板和发布门槛连接成闭环。只有闭环完整，课程中的方法才会在真实系统里持续生效。
附录：讲座时间线精读
关键时间点与技术主线
为了便于复习，本节按照时间线提炼讲座主线，并对应到可执行工程动作。此表既可用于复盘，也可直接转为团队内部的学习任务分配。
| 时间 | 讲座要点 | 工程启示 | |
|---|---|---|---|
| 时间 | 讲座要点 | 工程启示 | |
| 00:00–00:03 | 主题定义：Post-Training Verifiable Agents | 明确目标不是 “更会聊”，而是 “更会完成可验证任务” | |
| 00:03–00:06 | 回顾 RLHF/SFT/PPO/GRPO 基本链路 | 将原有聊天后训练管线扩展到轨迹级学习 | |
| 00:06–00:10 | 可验证任务需要清晰 verifier | 建立自动验证优先的数据与评估标准 | |
| 00:10–00:14 | coding agent 环境与工具状态建模 | 数据采集要记录状态转移，不只记录最终答案 | |
| 00:14–00:18 | verifier 多样性与覆盖挑战 | 使用多维 verifier 组合替代单评分器 | |
| 00:18–00:22 | 训练与评估分布差异风险 | 评估集要做去污染和难度漂移监控 | |
| 00:22–00:26 | 泛化不是由单 benchmark 决定 | 建立跨任务、跨工具、跨 harness 的评估矩阵 | |
| 00:26–00:31 | structured output 与真实可用性问题 | 把格式正确率纳入硬门槛，不靠后处理兜底 | |
| 00:31–00:34 | holistic evaluation 与 benchmark contamination | 引入持续更新评估池与社区协作审计机制 | |
| 00:34–00:40 | 进入训练策略讨论前的前提重申 | 先保证数据与评估质量，再谈算法优劣 | |
| 00:40–00:44 | 两阶段框架：SFT + RL | Light SFT 打底，RL 负责探索与提升 | |
| 00:44–00:49 | 轻 SFT + 多样样本的重要性 | 避免过重 SFT 把策略空间压窄 | |
| 00:49–00:54 | 算法仍在演化，理论未收敛 | 保持消融实验与多路线并行探索 | |
| 00:54–00:58 | train longer / harder tasks / diversity 三观察 | 训练策略需同时考虑步数、难度和多样性 | |
| 00:58–01:00 | entropy collapse 现象分析 | 建立熵监控与探索保持机制，防止早停滞 | |
| 01:00–01:03 | on-policy 与 off-policy 对比 | 优先从当前策略轨迹学习，减少反馈错位 | |
| 01:03–01:05 | clipping 解耦与探索鼓励技巧 | 在稳定与探索之间做可解释的参数平衡 | |
| 01:05–01:08 | 熵正则等方法缓解塌缩 | 可显式加入熵控制损失，结合任务表现调参 | |
| 01:08–01:14 | 难题训练集构造与能力分层观察 | 建立按难度分桶的数据调度机制 | |
| 01:14–01:17 | Q\ | A 与系统化建议收束 | 将课程结论转化为团队流程、面板与发布门槛 |
关键术语对照
| 术语 | 本讲语境 | 建议团队内定义 |
|---|---|---|
| Verifiable reward | 可程序化判定的任务反馈 | 可自动复现、可审计、可分解的奖励信号 |
| Environment state | 任务运行上下文全状态 | 含输入、文件、配置、历史动作与观测 |
| Trajectory | 多步行动与反馈序列 | 训练、评估与回放的统一数据主键 |
| Light SFT | 轻量行为先验注入 | 减错而不压缩探索，保持 RL 可提升空间 |
| Entropy collapse | 采样多样性丢失 | 策略退化为单一路径，导致长期停滞 |
| Harness swapping | 执行框架扰动评测 | 测试模型是否依赖偶然实现细节 |
如何使用本附录
建议将时间线和术语表直接映射到团队周计划：每个时间段对应一个工程行动项，每个术语对应一个内部统一定义，避免跨角色沟通歧义。
本章小结
时间线精读的价值在于把 “听懂” 变成 “可执行”。当每个关键观点都对应到具体工程动作，课程内容才能真正进入团队生产体系。
总结与延伸
全讲框架回顾
| 模块 | 核心结论 | 实践动作 |
|---|---|---|
| 问题定义 | Agent 后训练目标是可验证任务完成 | 建立 preference + verifier 联合目标 |
| 任务建模 | 核心三元组：环境、工具、验证器 | 数据与系统日志按轨迹组织 |
| 数据工程 | 难点在组合覆盖而非样本总量 | 扩展环境/工具/验证组合，显式纳入失败样本 |
| 评估体系 | 必须 Holistic，防止指标幻觉 | 多 verifier + harness swapping + 污染监控 |
| 训练流程 | Light SFT 打底，RL 负责突破 | 控制 SFT 强度，保留探索空间 |
| RL 关键点 | 防熵塌缩、难度调度、多样高质轨迹 | 监控熵与难度分层，优化采样与反馈闭环 |
| 算法实现 | on-policy、更新强度平衡、熵正则有用 | 保留消融与审计，避免技巧神化 |
一句话总结
可验证 Agent 训练的本质，不是 “让模型更会说”，而是 “让模型在可观测、可验证、可治理的环境中持续学会做对事”。
延伸阅读与实践建议
前面的总结表给出机制关系，本小节进一步把它们转成可复现实验。阅读论文时应同时复现环境、verifier、采样预算和基线，实践中则优先做 harness swap、SFT 强度消融、entropy 监控与轨迹级数据治理，避免只复制算法名称。
| 主题 | 建议阅读/实践方向 |
|---|---|
| 主题 | 建议阅读/实践方向 |
| 课程原视频 | Berkeley RDI 发布的本讲完整视频（Jiantao Jiao, Post-Training Verifiable Agents），建议结合本笔记的关键时间戳回看图示部分。 |
| 评估工程 | 重点补齐 verifier 分层设计：结果层、结构层、过程层、安全层；在内部基准上进行 harness swapping 实验。 |
| 训练策略 | 对比 “重 SFT + 轻 RL” 与 “轻 SFT + 强 RL” 两种配置，追踪熵变化、成功率和 OOD 泛化差异。 |
| 熵与探索 | 针对熵塌缩建立日常监控面板：token entropy、轨迹去重率、有效探索比例、失败类型分布。 |
| 数据体系 | 从 “按任务存样本” 升级到 “按轨迹存状态转移”，将工具调用参数与中间反馈纳入训练可回放数据。 |
| 治理闭环 | 引入权限边界、调用审计、异常回滚机制，把部署可控性作为后训练优化目标的一部分。 |
进一步思考
- 当 verifier 无法覆盖复杂开放任务时，如何避免模型在弱约束区域形成投机策略？
- 在成本受限条件下，如何选择最具信息增益的轨迹进行 on-policy 更新？
- 可验证 Agent 的评估是否应从 “单模型分数” 转向 “系统级可靠性曲线”？
- 如果训练目标同时包含能力与治理，损失函数和评估基准应如何共同设计？