外观
智能体与对话系统
一句话定位：这一页讲清楚"把 LLM 当策略"的智能体 RL——从早期对话系统的策略学习，到 ReAct 范式的工具调用、Web 导航与具身智能体，核心问题是：环境的接口长什么样、奖励从哪来、以及"任务成功率"这个目标为什么改变了 RLHF 的形状。
一、智能体范式的 MDP 化：环境=API/浏览器/世界
1. 智能体的定义
2022 年后，"Agent"成为 LLM 应用的核心概念：一个 LLM 被封装成循环决策单元，反复执行"读状态 → 决定动作 → 执行动作 → 观察结果"：
text
┌─────────────┐ 动作（调 API / 点网页 / 发工具调用） ┌──────────────┐
│ LLM 智能体 │ ─────────────────────────────────────► │ 环境 │
│ (策略 π_θ) │ ◄───────────────────────────────────── │ API/浏览器/ │
└─────────────┘ 观察（工具返回 / 页面状态 / 报错） │ 真实世界 │
└──────────────┘用 MDP 的语言（见马尔可夫决策过程页）：
text
状态 s_t ：对话历史 + 工具返回结果 + 环境观察（页面 DOM、文件系统、机器人传感器）
动作 a_t ：生成一段文本，其中可能包含工具调用指令（如 JSON 格式的 function call）
奖励 r_t ：任务是否成功、工具调用是否有效、用户反馈（稀疏！）
终止 ：任务完成、达到步数上限、或智能体放弃2. 三个关键差异（相对传统 RLHF）
| 维度 | RLHF（对齐对话） | Agent RL |
|---|---|---|
| 奖励 | 人类偏好（RM 打分） | 任务是否完成（规则/执行器判断） |
| 环境 | 模型自身 | 外部 API/浏览器/物理世界 |
| 稀疏性 | 终局一个打分 | 同样稀疏，但"成功"可自动判定 |
| 状态 | 自回归文本 | 多模态、长上下文、部分可观测 |
这个"奖励=任务成功"的转变是理解智能体 RL 的钥匙：当奖励可以被程序化验证，就不需要训练奖励模型了——这直接通向 RLVR（见前沿进展页）。
二、对话策略学习：RL 在对话系统的老历史
1. 任务型对话系统的"政策"
在 LLM 之前，任务型对话系统（订机票、查天气）采用流水线架构：NLU → 对话政策（Dialog Policy） → NLG。对话政策决定"下一步系统该说什么/做什么"，天然是 RL 问题：
text
状态 ：对话状态（用户意图、槽位填充情况）
动作 ：系统行为（问槽位、确认、数据库查询、最终回复）
奖励 ：任务完成 +1，每轮对话扣一点成本，错误确认重罚Zhao & Eskenazi (2016) 用 DQN 学对话政策，证明深度 RL 能学到比规则更好的"问-答-确认"策略。早期研究（如 2010 年代的 statistical dialogue systems）也用 POMDP 形式化过这个问题。
2. 历史教训：为什么对话政策 RL 没火起来
- 模拟器难建：用户模拟器（user simulator）是虚构的，学出的策略在真人对语上退化；
- 奖励稀疏且噪声大：任务成功与否很难自动判定；
- 数据量：真实对话数据少。
这条历史告诉我们一个通用规律：RL 的效果上限 = 环境保真度 × 奖励质量。LLM Agent 之所以让对话 RL 复兴，正是因为它把"环境"从"用户模拟器"换成了"可执行的 API/浏览器"——奖励终于可以自动验证了。
三、ReAct 范式与 LLM Agent 的 RL 微调
1. ReAct：让 LLM 显式"想→做→看"
Yao et al. (2022) 提出的 ReAct（Reasoning + Acting）是目前 Agent 的标准骨架：让 LLM 交替输出"思考（Thought）→ 动作（Action）→ 观察（Observation）"。这个格式把"推理"和"行动"显式分离，极大改善了可调试性与成功率。
text
Thought: 我需要查询北京的天气
Action: weather_api(city="北京")
Observation: {"temp": 28, "condition": "晴"}
Thought: 天气晴朗，可以建议出行
Final: 北京今天晴，28°C，适合外出。ReAct 本身是提示（prompting）技术，不训练模型。它真正革命性的是给出了统一的动作格式——这为"用 RL 训练 agent"铺平了路。
2. 用 RL 微调 Agent：AgentLM 等
当 ReAct 提示不够用时（长任务、复杂工具、频繁出错），研究转向用 RL 微调 LLM 使它的工具调用更可靠。代表性工作：
- AgentLM（Zeng et al., 2023）：构造大规模工具调用数据集，先做 SFT，再进一步对齐，提升多步工具调用的成功率；
- RFT（Rejection Sampling Finetuning）：先让模型采样大量回答，用奖励/规则筛选"成功"的子集，再对这些子集做 SFT——本质是"离线版的奖励最大化"，比 PPO 简单且稳定；
- ToolLLM（Qin et al., 2023）：用深度优先搜索扩展工具调用树，再用 RFT 训练工具使用能力。
3. 奖励来源：可执行性
工具调用 RL 的奖励设计有一条清晰的阶梯：
| 奖励层级 | 内容 | 特点 |
|---|---|---|
| 过程奖励 | 工具调用语法是否正确、是否调用了合理工具 | 密、可自动计算 |
| 结果奖励 | 工具返回是否被正确使用、最终答案对不对 | 中密度 |
| 任务奖励 | 整个多步任务是否成功完成 | 稀疏、最真实 |
关键工程判断：过程奖励（如"这次 API 调用格式正确"）能让 RL 快速学会"会调用"，但可能学出"调对 API 但没用"的空转行为；任务奖励最真实但最稀疏。业界倾向混合：过程奖励引导、任务奖励把关。
4. ReAct 家族：从反思到多轮改进
ReAct 打开了一族"让 LLM 自己当评委"的免训练方法，它们与 RL 形成互补：
| 方法 | 机制 | 与 RL 的关系 |
|---|---|---|
| Reflexion（2023） | agent 失败后把"为什么失败"写回语言记忆，下一轮避免 | "口头 RL"：用语言替代梯度做改进 |
| Self-Refine（2023） | 生成→自我批评→修正，迭代到满意 | 免训练的"奖励信号内部化" |
| 树搜索（ToT/DFS） | 在推理树上搜索多条路径 | 与 AlphaGo 的搜索×学习同构 |
| 带 RL 的 Agent 微调 | 用可验证奖励真正更新模型权重 | 前两者的"梯度版" |
实践判断：小任务用 Reflexion/Self-Refine 就够了（零成本）；当"反思提示不管用、必须改权重"时再上 RL。这符合RL 设计原则页"从简单开始"的原则。
5. 一个完整的 Agent MDP 例子：工具调用
把"LLM 调工具完成任务"写成可训练的 MDP，看清每个组件的角色：
text
任务：给用户查股票价格并生成涨跌分析
状态 s_t ：对话历史（用户指令 + 已生成的思考/动作/观察）+ 工具目录
动作 a_t ：生成一段文本（含函数调用：stock_price(symbol="AAPL")）
转移 ：工具返回 JSON → 追加进观察
奖励 r_t ：（终局）最终答案是否含正确价格 ± 分析质量评分
终止 ：给出 Final 答案 / 超过步数上限
训练数据：真实用户指令 × 工具调用轨迹 × 终局成败这个例子暴露的三个 Agent 特有难点：
- 状态是"半结构化"的：对话历史是自然语言 + JSON 混合，超出普通 RL 的定长状态假设；
- 动作是"生成式"的：动作空间是文本空间，不是枚举动作——RL 的"动作概率"必须落在 token 分布上；
- 奖励极稀疏：只有终局成败，中间步骤没有任何打分——需要过程奖励或课程分解。
这三个难点合起来，正是 Agent RL 比 RLHF 和经典 RL 都更难的原因，也是为什么"先跑通提示工程 → 再 RFT → 最后 PPO/GRPO"是业界公认的递进路线。
四、Web 导航与代码生成任务的 RL
1. Web 导航（Web Navigation）
任务：给一个指令（"帮我预订从北京到上海的机票"），agent 要在真实/模拟的网页上完成操作（点击、输入、跳转）。
- WebArena / WebArena-Lite（Zhou et al., 2023）：自托管的真实 Web 应用环境，评估 agent 的多步网页操作能力，已成为该方向事实标准；
- 训练方式：先离线收集专家轨迹做 SFT，再用"最终任务是否成功"做 RL 微调；
- 难点：网页状态是部分可观测的（页面内容超长、需要滚动/点击展开），agent 必须学会"用什么操作看什么信息"。
2. 代码生成（Code Generation）
把"写代码"当任务时，奖励可以直接用执行器验证：
text
状态 ：问题描述 + 已生成的代码 + 编译/测试结果
动作 ：下一段代码（token 序列）
奖励 ：单元测试通过率 / 是否通过隐藏测试 / 代码执行结果这类"可验证奖励"的任务让 RL 变得特别干净——不需要训练 RM，用测试用例当裁判即可。这也是 2024–2025 年"RL for Reasoning"（数学、代码）爆炸式发展的同一条主线，详见前沿进展页的 RLVR 小节。
3. 代码生成 RL 的训练细节
代码任务的 RL 微调有四个工程要点：
| 要点 | 做法 | 坑 |
|---|---|---|
| 测试集划分 | 训练/验证/测试用例严格分离 | 测试用例泄露 = 刷分 |
| 奖励粒度 | 单元测试通过率 vs 全过才 +1 | 部分通过要分级，但别让 RL 学会"挑软柿子" |
| 采样数量 | 每个问题采样 8–64 个回答 | 采样太少学不到、太多成本高 |
| 编译环境 | 沙箱执行代码，防恶意输入 | 不沙箱 = 灾难（见下节安全） |
WARNING
代码执行的安全是硬边界：RL 训练的 agent 会在环境里执行自己生成的代码，一旦代码能访问文件系统/网络，训练数据里混入恶意提示就可能让 agent 学会破坏性行为。工业上必须用 Docker 沙箱+超时+资源限制隔离执行环境。这与机器人控制与 Sim2Real页"安全护栏不可省"的原则同源。
TIP
代码与数学是 Agent RL 的"理想实验室"：奖励可自动验证、环境可无限重复、失败可精确归因。如果你刚开始做 Agent RL，从"代码补全/单元测试"或"数学解题"切入，比做开放式网页导航容易得多。有关"可验证奖励"如何改变 RLHF，回看LLM 对齐：RLHF 实战的 RLVR 一节。
五、具身智能体与 VLA：Agent 与机器人合流
1. VLA：视觉-语言-动作模型
2023 年以来的具身智能体方向把 LLM 的"通用语言理解"和机器人的"动作输出"合到一个模型（VLA, Vision-Language-Action）：
text
输入：相机图像 + 语言指令
输出：机器人动作（关节位置增量 / 末端位姿）
训练：海量机器人遥操作数据 + 互联网数据 → SFT，再 RL 微调- RT-2 / RT-2-X（Google DeepMind, 2023）：用网络规模的图文数据提升 VLA 的泛化；
- OpenVLA（2024）：开源 VLA，社区可微调；
- RL 微调让 VLA 在"从失败中学习"上更有效——但受限于真实机器人数据稀缺，仍以仿真为主。
2. 与 Sim2Real 的衔接
具身 Agent 的 RL 与机器人控制与 Sim2Real是同一件事的两端：
- 机器人侧：底层连续控制（关节力矩）用 PPO/SAC 在仿真学；
- Agent 侧：高层任务规划（"先拿杯子再倒水"）用 LLM + RL 学；
- 共同挑战：环境保真度与奖励质量。仿真里学出的"会倒水"能不能在真实厨房成立，取决于仿真器的物理与场景覆盖。
六、环境工程：API 封装与奖励来源
1. "环境即 API"
Agent RL 的工程重心几乎全部在环境侧：
| 环节 | 工程任务 | 常见坑 |
|---|---|---|
| 动作空间 | 把环境操作封装成统一 tool schema（名称/参数/返回） | schema 不一致导致幻觉调用 |
| 观察返回 | 工具结果结构化（JSON/表格），控制长度 | 返回过长超出上下文 |
| 奖励判定 | 任务成功判定器（规则/执行器/LLM 裁判） | 判定器本身不可靠 |
| 重置与采样 | 环境可重置、可并行采样 | 无状态环境、需要 Docker 隔离 |
| 错误处理 | 超时、重试、工具失败降级 | 训练中频繁超时拖垮效率 |
DANGER
环境 bug 是 Agent RL 的头号隐形杀手：某个工具偶尔返回损坏的 JSON、某个网页元素偶尔点击失败，会让智能体学到"反复重试"或"放弃"的怪癖——而训练曲线看起来一切正常。这与常见陷阱与反模式页"环境 bug 静默影响学习"完全一致，但 Agent 环境的 bug 更难排查（涉及多服务、网络、权限）。上线前必须做环境健康监控与失败注入测试。
2. 奖励来源的三条路
- 规则/执行器（测试用例、API 返回校验）——最可靠，能自动验证就用它；
- LLM 裁判（让强 LLM 判"这个回答完成了任务吗"）——灵活但可能被刷分，需校准；
- 人类反馈（RLHF 传统路线）——最真实但最贵，通常只在最后阶段用。
3. 动作空间设计的工程细节
Agent RL 的"动作空间"是一堆工具调用的集合，设计质量决定训练成败：
| 设计点 | 好做法 | 坏做法 |
|---|---|---|
| 工具粒度 | 一个 API 一个工具，参数 JSON Schema 明确 | 把所有能力塞进一个巨型工具 |
| 工具数量 | 一次暴露 10–50 个，按任务动态装载 | 一次给几百个，agent 陷入选择困难 |
| 返回格式 | 结构化（JSON/表格）+ 截断 + 错误码 | 大段自然语言返回 |
| 失败语义 | 工具失败返回可读错误而非抛异常 | 静默失败（agent 以为成功） |
| 上下文管理 | 历史观察摘要化，保留关键状态 | 上下文无限膨胀，模型失去焦点 |
最容易踩的坑是"工具返回里的成功/失败信号不干净"——agent 会学到"调用工具但不看结果"的坏习惯。想要可训练的环境，先让工具返回稳定、结构化、可区分成败。这与RL 系统解剖页"环境即产品"的论断一致。
七、评估难题：成功率之外的事
1. 为什么要"任务成功率"不够
Agent 评估若只看"最终成功与否"，会掩盖大量问题：
| 维度 | 为什么重要 | 常见失真 |
|---|---|---|
| 步数效率 | 成功 20 步 vs 成功 5 步质量不同 | 长链路"绕路成功"也算成功 |
| 失败模式 | 是"不会调工具"还是"理解错任务" | 只看成功率无法归因 |
| 泛化 | 换个任务分布/网站布局还灵不灵 | 训练分布内刷分 |
| 安全 | 是否做出危险操作（删文件、下单） | 成功率高的 agent 可能最危险 |
| 鲁棒性 | 重试几次才能成功 | 一次成功可能是运气 |
报告协议：任务成功率 + 平均步数 + 失败模式分布 + 多 seed 方差，缺一不可——这是评估与基准页协议在 Agent 场景的落地。
2. 泛化的两难
Agent RL 目前最痛的瓶颈是泛化：在 WebArena 训练的 agent 换个网站就崩。原因是网页/API 的分布极广，训练分布覆盖不了。业界路线：
- 更大规模的多样化环境采样；
- 少样本适配（给 agent 看几个新 API 的例子再让它干）；
- 把"泛化"本身写进训练目标（领域随机化思想，见机器人控制与 Sim2Real）。
3. Agent 评估基准图谱
评估 Agent 不能只看自家环境，主流公开基准要熟悉：
| 基准 | 测什么 | 特点 |
|---|---|---|
| WebArena（2023） | 多步 Web 任务（预订、购物、管理） | 自托管真实应用，任务可复现 |
| SWE-bench（2023） | 用真实 GitHub issue 修代码 | 直接测"工程能力"，难且真实 |
| GAIA（2023） | 通用助手多步任务 | 考察推理+工具+多模态的综合 |
| ToolBench / API-Bank | 工具调用能力 | 测 API 选择与调用正确性 |
用法：论文里 Agent 的"成功率"必须说明是在哪个基准、什么协议下测的；跨基准比较时先看任务难度是否可比。这也呼应评估与基准页"基准图谱 + 报告规范"的方法论。
八、前沿与批评
1. 前沿方向
- RLVR 规模化：DeepSeek-R1 证明纯 RL（无 SFT 冷启动）能激发推理能力，Agent 版本正在跟进；
- 自我改进循环：agent 用反馈改进自身 prompt/策略（Reflexion 等），与 RL 的"在线采样"天然互补；
- 多智能体 Agent：多个 LLM agent 协作完成复杂任务，回到多智能体强化学习的非平稳问题。
2. 批评与冷静
- 评估不透明：很多 Agent 论文的成功率来自自建环境，横向可比性差；
- "RL 训练" vs "提示工程"：有些论文的"RL 微调"实际只是 RFT（拒绝采样 SFT），不是真正的策略梯度；
- 成本：Agent RL 每个样本都要跑多步环境交互，token 成本与失败率成正比——RL 训练 Agent 的开销比对齐高一个量级。
3. 成本核算：Agent RL 到底要花多少钱
先算一笔账，再决定要不要上 Agent RL：
text
一个训练样本的成本 = 单次任务交互的 token 数 × 尝试次数 × 单价
例子（Web 导航任务，7B 模型，内部定价 $0.3/百万 token）：
单任务平均 5000 token（输入输出） × 采样 32 次 = 160k token/任务
训练集 10k 个任务 → 1.6B token ≈ $480（仅采样）
加上训练本身（SFT/PPO 各若干 epoch）与失败重试 → 再翻 2–4 倍| 环节 | 成本来源 | 控制手段 |
|---|---|---|
| 数据采样 | 每个任务多次 rollout | 限制采样数、先小任务集验证 |
| 环境交互 | 网页/API 调用、模拟器 | 缓存可复用的轨迹、并行化 |
| 训练 | PPO/GRPO 多模型前向 | 用较小模型跑通再放大 |
| 失败重试 | 环境不稳定导致返工 | 环境健康监控、故障注入 |
工程建议：Agent RL 项目的第一个里程碑不是"刷高成功率"，而是"把单个训练样本的成本降到可接受"——成本不达标，任何算法改进都无法规模化。这与RL 系统解剖页"样本效率意识"原则直接对应。
INFO
读 Agent RL 论文时建议先查三个问题：①环境是公开的还是有门槛的？②"RL"是真的 PPO/GRPO 还是 RFT？③成功率的测量协议是什么（同任务采样几次、种子几个）？ 这三个问题的答案决定了论文结论能相信几分。
延伸阅读
- RLHF 与人类反馈对齐 —— Agent RL 的底层引擎：偏好、RM、KL 约束。
- LLM 对齐：RLHF 实战 —— 从对齐对话到 RLVR/推理 RL 的完整谱系。
- 策略梯度方法 —— PPO/GRPO 在 agent 微调中的实现细节。
- 奖励工程 —— 过程奖励 vs 结果奖励、任务成功率的奖励设计。
- 前沿进展 —— ReAct、AgentLM、RFT、WebArena、DeepSeek-R1 的定位。
- 机器人控制与 Sim2Real —— 具身智能体 VLA 的底层控制与仿真迁移。
参考资料
- Yao, S., et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629.（ICLR 2023）
- Zhao, T., & Eskenazi, M. (2016). Towards End-to-End Learning for Dialog State Tracking and Management using Deep Reinforcement Learning. SIGDIAL 2016.（对话政策 DQN）
- Zeng, A., et al. (2023). AgentTuning: Enabling Generalized Agent Abilities for LLMs. arXiv:2310.12823.（AgentLM）
- Qin, Y., et al. (2023). ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs. arXiv:2307.16789.
- Zhou, S., et al. (2023). WebArena: A Realistic Web Environment for Building Autonomous Agents. arXiv:2307.13854.（ICLR 2024）
- Shinn, N., et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366.（NeurIPS 2023）
- Lightman, H., et al. (2023). Let's Verify Step by Step. arXiv:2305.20050.（过程奖励模型）
- DeepSeek-AI (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948.（RLVR 大规模推理）
- Brohan, A., et al. (2023). RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control. arXiv:2307.15818.