简介由快手科技快意大模型知识增强研发负责人毛航宇主讲的专题资料系统梳理了强化学习(多)智能体到大语言模型(多)智能体十年的研究脉络。内容覆盖Deep RL、Deep MARL、Transformer-based RL、LLM-based AI Agent等方向从DQN、PPO、MADDPG到GPT系列、AutoGPT等代表工作并通过时间线图表清晰呈现技术演进关系与关键节点。资源包含十年研究脉络梳理、代表工作选讲、企业实践心得体会三个模块既适合AI算法工程师与强化学习研究者纵览领域全貌也适合大模型应用开发者把握智能体技术趋势。压缩包为1个PDF文件大小约9.81MB内容紧凑可直接阅读。目前已有30人学习下载读者可获得从强化学习到大语言模型智能体的路线图、关键模型对比及由演讲者多年经验凝练的业务落地心得是一份浓缩的领域参考。1. 把强化学习多智能体和大语言模型多智能体放在一起比比的是什么当我在做一个仓储调度的多设备演示时团队里同时出现了两条技术路线一边在调奖励函数让设备学避让另一边在给语言模型写角色提示让它负责任务排序。A同学问了一句这两个都叫智能体到底做哪个这个问题在今天做智能体选型时很典型。强化学习多智能体重点在动作策略靠环境和奖励信号不断试错大语言模型多智能体重点在语言理解和工具调用靠预训练知识和上下文推理直接给出下一步。这两条路线不是替代关系而是处理不同层级的问题前者解决这个动作该怎么做后者解决这件事该由谁做、按什么顺序做。这篇笔记会把它们的差异、最小实现和结合方式讲清楚也会给出我在实际项目里踩过的坑适合正在做智能体选型或者准备从零搭一个智能体 demo 的开发者。2. 两种智能体的本质差异一个在学动作一个在学下一步怎么决策2.1 RL智能体的最小闭环状态、动作、奖励以及它的两个致命短板强化学习智能体的基础是马尔可夫决策过程智能体在每个状态选择一个动作环境返回下一个状态和一个奖励目标是把累积折扣奖励最大化。它学的不是怎么说话而是怎么做能在长期获益。只要环境能反复交互、奖励信号足够明确RL 就擅长逼近最优策略。工程上最常见的形态是查表型 Q-learning、值函数近似和策略梯度三类。但 RL 有两个绕不开的短板。第一个是奖励设计决定一切。稀疏奖励下从零探索几乎不收敛奖励给得不小心又会让智能体学到钻空子的行为。我在一个避让演示里遇到过为了让设备快点到目标点我把回合时长写进了惩罚项结果它学会了卡在边界等对方先走因为等待不触发时间惩罚而我的惩罚只按回合结束时的步数计算这个边界条件让惩罚失效了。第二个是环境必须可交互。真实产线不能拿来做几万次试错所以 RL 项目基本都要先搭仿真环境仿真和真实之间的差距又得单独处理。选型判断就变得很具体任务能不能低成本交互状态和动作空间是不是明确可枚举工程上能不能在两周内构建一个闭环环境如果答案都是否直接上手 RL 大概率是给自己挖坑。这里没有玄学环境交互次数、奖励可设计性、状态观测质量这三个问题想不清楚后面训练曲线就会一直震荡。2.2 LLM智能体的最小闭环上下文、工具、反馈循环以及它为什么慢大语言模型智能体没有显式奖励函数。它的闭环是系统提示加历史消息作为上下文模型输出一段推理和一个动作动作通常是文本指令、工具调用或查询结果工具返回结果后又作为新消息放回上下文进入下一轮。它靠每轮把新信息拼进上下文来即时适应而不是靠梯度更新来改变策略。这个结构的优势很明显任务开放、语言理解强、有常识性规划能力而且不需要搭仿真环境。比如让智能体去查文档、写 SQL、总结异常原因这些任务的状态语义很复杂但动作空间是有限可枚举的 API 调用用 LLM 来做效率远高于为每个任务单独训练一个 RL 策略。短板同样明显。单次推理慢且贵做不了百万次试错上下文窗口有限长回合会丢掉早期信息模型幻觉和输出格式错误会造成工具调用死循环最重要的一点是它没有策略优化你给它一个负反馈它不会自动调整参数只能靠下一次推理时看到这个反馈来临时改主意。选择逻辑也因此不同如果你的动作空间没法清晰枚举又不方便搭环境做大规模交互LLM 智能体通常比 RL 更务实。2.3 多智能体放大的难点协作结构还是通信协议把多智能体三个字加进来两类技术的问题完全不同。RL 多智能体的核心难点是三个联合状态空间和联合动作空间随智能体数量指数膨胀环境不再平稳你的策略在变队友和对手的策略也在变对每个智能体来说环境的转移概率一直在漂还有信用分配一个全局奖励下来到底是谁的功劳、谁该背锅。工程上最常用的方案是先做独立学习每个智能体各用自己的策略观察震荡和推锅后再升级到中心化训练、去中心化执行。这个升级思路在机器人集群和调度场景里是标准解法训练时用全局信息执行时只看局部观测。LLM 多智能体的问题不在策略学习而在协作文本协议谁当协调者、谁当执行者消息格式不统一导致的解析失败多个智能体意见冲突时靠什么收敛。我在模拟项目里见过一次典型翻车三个 LLM 智能体在一个群聊式结构里互相追问八轮之后任务还没开始执行因为没有任何一个角色有最终决定权。本质区别一句话就能讲清RL 多智能体是真正的博弈与策略学习LLM 多智能体更接近角色扮演和文本协商模型权重不动动的是谁拿到了什么上下文。维度RL多智能体LLM多智能体学习方式在线策略学习更新参数或查表值上下文中的即时推理不更新权重知识来源环境交互产生的奖励信号预训练知识加工具返回结果训练成本高需要仿真环境大规模试错高主要是 token 成本不需要仿真多体核心难点联合状态维度、信用分配、环境非平稳角色划分、消息协议、冲突裁决适用场景设备集群、调度博弈、需要真实动作决策开放任务、内容生成、多角色协作规划3. 先把 RL 这条线跑通从单智能体到多智能体的最小示例3.1 单智能体热身离散环境优先用 Q-learning连续环境再换策略梯度我判断 RL 项目从哪起步时只问一个问题状态空间能不能用一张表装下。能装下就用 Q-learning查表更新直观调参反馈快状态连续或者动作连续再换策略梯度类方法因为表格会爆炸。下面这个 4x4 网格是最小的 Q-learning 闭环起点在左上角终点在右下角动作是上下左右。import numpy as np n_states 16 n_actions 4 q_table np.zeros((n_states, n_actions)) alpha 0.1 # 学习率每次更新的步长 gamma 0.95 # 折扣因子未来奖励折算到当前的价值 eps 0.9 # 初始探索率随机动作的概率 eps_min 0.02 eps_decay 0.99 def move(s, a): r, c divmod(s, 4) if a 0: # 上 r max(0, r - 1) elif a 1: # 下 r min(3, r 1) elif a 2: # 左 c max(0, c - 1) else: # 右 c min(3, c 1) return r * 4 c def step(s, a): ns move(s, a) reward 1.0 if ns 15 else -0.01 return ns, reward for _ in range(3000): s 0 while s ! 15: a np.random.randint(4) if np.random.rand() eps else int(np.argmax(q_table[s])) ns, r step(s, a) q_table[s, a] alpha * (r gamma * q_table[ns].max() - q_table[s, a]) s ns eps max(eps * eps_decay, eps_min)这段代码的核心更新公式是 Q 学习的 off-policy 更新r gamma * q_table[ns].max()表示下一步的最优估计不管当前策略选什么动作更新目标都指向后续的最大值。alpha 控制更新幅度调大了会震荡调小了收敛慢0.1 是这种小表格的合适起点。gamma 决定了智能体有多近视回合很短0.95 就够如果换成长期任务再调到 0.99。eps 从 0.9 开始衰减保证前期大量探索、后期偏向利用衰减到 0.02 之后停止给策略留一点容错。这个代码跑完可以打印 q_table 看右下角附近的状态值比看曲线更直观。如果 3000 回合后起点位置的值还不够高先把 eps_decay 改小让探索期更长而不是急着调 alpha。3.2 多智能体最小示例两个智能体各学各的 Q 表共享同一个奖励多智能体 RL 的入门写法是独立学习每个智能体维护自己的 Q 表状态表示里加上对方的位置。下面这个例子让两个智能体从同一起点出发抢右下角终点如果撞到同一个格子各扣 0.5谁先到终点得 1.0。import numpy as np q1 np.zeros((16 * 16, 4)) # 状态 自己位置 * 16 对方位置 q2 np.zeros((16 * 16, 4)) alpha, gamma, eps 0.05, 0.95, 0.6 def move(s, a): # 动作定义与单智能体一致 r, c divmod(s, 4) if a 0: r max(0, r - 1) elif a 1: r min(3, r 1) elif a 2: c max(0, c - 1) else: c min(3, c 1) return r * 4 c def joint_step(s1, s2, a1, a2): ns1, ns2 move(s1, a1), move(s2, a2) if ns1 ns2: return ns1, ns2, -0.5 if ns1 15 or ns2 15: return ns1, ns2, 1.0 return ns1, ns2, -0.01 def pick(q, s): return np.random.randint(4) if np.random.rand() eps else int(np.argmax(q[s])) for _ in range(30000): s1, s2 0, 0 while s1 ! 15 and s2 ! 15: sidx s1 * 16 s2 a1, a2 pick(q1, sidx), pick(q2, sidx) ns1, ns2, r joint_step(s1, s2, a1, a2) q1[sidx, a1] alpha * (r gamma * q1[ns1 * 16 ns2].max() - q1[sidx, a1]) q2[sidx, a2] alpha * (r gamma * q2[ns1 * 16 ns2].max() - q2[sidx, a2]) s1, s2 ns1, ns2 eps max(eps * 0.999, 0.02)这个版本刻意做得简单两个关键点要理解。第一状态索引s1 * 16 s2同时包含自己和对方的位置单独看一个智能体的 Q 表没有意义因为它的表格是在对方处于某位置时我该怎么动。第二两个智能体拿到的是同一个r这是最简单的共享奖励结构代码能跑通但训练中会频繁出现一个智能体学会不动、等对方先走的投机行为。实际跑的时候不要只看总奖励。把两个智能体各自的单步平均奖励分别记下来你会发现总奖励在涨但可能只有一方在进步。这就是第 5 章要展开的信用分配问题。alpha 在这里我都给到了 0.05比单智能体低一半因为两个学习器同时更新步长太大会互相干扰。如果震荡到完全发散先不要调参去检查奖励和状态表示。3.3 接入仿真环境后必调的三个参数从网格跳到真实一点的仿真环境我通常只先动三个参数。第一是 gamma回合越长越接近 1回合能在几十步内结束就用 0.95超过几百步的任务直接上 0.99。第二是学习率样本量大的连续控制任务alpha 通常会从 0.1 降到 0.01 这个量级多智能体共享奖励的场景再降一半。第三是奖励尺度如果奖励动不动就是几十的量级更新步长会被放大训练曲线像噪声先把奖励归一化到 [-1, 1] 再跑。另外一个值得养成的习惯是画每个智能体的个体奖励曲线而不是只画总奖励。多智能体场景下总奖励上涨说明不了任何问题个体方差才是策略健康度的信号。某开发者接手我的代码后第一件事就是加了按智能体分组的奖励曲线立刻发现我之前的第二智能体其实一直在拖后腿。多智能体参数调优的玄学大多发生在这里但其实不是超参数的问题是优化目标本身没设计对。4. 再把 LLM 这条线跑通从单智能体到多智能体的提示工程结构4.1 单智能体最小循环让模型只输出 JSON 动作而不是自由文本LLM 智能体的第一个工程决定是输出格式。让模型自由发挥会得到大量不可解析的自然语言后面每个环节都要处理脏数据。我一般会强制模型只输出 JSON结构固定为工具调用或结束两类。import httpx import json API_URL http://localhost:8000/v1/chat/completions # 替换成你的模型服务地址 MODEL your-model-name def chat(messages, temperature0.2, max_tokens256): resp httpx.post(API_URL, json{ model: MODEL, messages: messages, temperature: temperature, max_tokens: max_tokens, }, timeout30) return resp.json()[choices][0][message][content] def run_agent(task, tools, max_iter5): messages [ {role: system, content: 你只输出JSON格式为{\type\:\call_tool\,\tool\:\工具名\,\args\:{}} 或{\type\:\finish\,\answer\:\最终答案\}}, {role: user, content: task}, ] for _ in range(max_iter): out chat(messages) try: act json.loads(out) except json.JSONDecodeError: messages.append({role: user, content: f你刚才没输出合法JSON{out}请重来}) continue if act[type] finish: return act[answer] if act[tool] not in tools: messages.append({role: user, content: f工具 {act[tool]} 不存在请从 {list(tools)} 中选择}) continue result tools[act[tool]](**act[args]) messages.append({role: assistant, content: out}) messages.append({role: user, content: f工具返回{result}}) raise TimeoutError(迭代次数用完仍未完成任务)temperature我固定 0.2太低会变得机械重复太高会让工具名都拼错。max_tokens256 对单次动作足够因为只要求输出 JSON。max_iter设 5 是为了防死循环实际生产我会放到 10 但叠加下面的兜底机制。两个关键设计解析失败时不抛异常而是把原始输出作为错误信息丢回给模型让它自己纠正工具不存在时同样回灌错误下一轮模型大概率会换一个工具名。这套循环跑通之后再加缓存和历史摘要就是一个可上生产的单智能体骨架。4.2 多智能体最小示例一个模型后端多个角色上下文轮流对话LLM 多智能体的常见误入是把多个智能体理解成需要多个模型实例。实际不是多数项目只要一个模型后端每个智能体是独立的消息上下文通过互相传递文本完成协作。下面这个双角色调度器例子A 负责拆任务B 负责执行每轮把对方的输出拼进自己的上下文。def make_agent(role_desc): return [{role: system, content: role_desc}] def multi_agent_round(agent_a, agent_b, task, max_rounds3): agent_a.append({role: user, content: task}) last_out for _ in range(max_rounds): out_a chat(agent_a) agent_a.append({role: assistant, content: out_a}) agent_b.append({role: user, content: f协调者说{out_a}}) out_b chat(agent_b) agent_b.append({role: assistant, content: out_b}) agent_a.append({role: user, content: f执行者说{out_b}}) last_out out_b if type:finish in out_b: break return last_out这个例子最值得注意的地方是两个智能体共享同一个模型服务但因为各自维护独立的消息列表模型的角色行为被 system prompt 隔离开。协调者看到的上下文包含执行者的所有回复执行者也一样但两边的历史不完全一致这是多智能体协作里很关键的一点——不需要上下文全部相同只需要交换必要信息。停止条件我用的是字符串匹配实际项目里更可靠的做法是让每个智能体输出结构化消息比如在最外层 JSON 里加role和phase字段协调者根据phase判断是继续讨论还是给结论。用关键词判断完成很容易误停这是我从一个多轮对话 demo 里踩出来的教训。4.3 把 LLM 接进 RL 奖励函数状态文本化打分两条路线真正的交叉点在这里。常见做法之一是让 LLM 当奖励函数把环境状态翻译成一段自然语言描述让模型打分再把分数喂给 RL 策略。下面这个函数可以直接替换上一章的奖励计算。def llm_reward(state_desc, prev_reward0.0): prompt f请评估以下状态对完成目标有利还是有弊只输出-1到1之间的数字{state_desc} score chat([{role: user, content: prompt}], temperature0.0, max_tokens8) try: reward float(score.strip()) except ValueError: return prev_reward or 0.0 # 解析失败回退不抛异常 return max(-1.0, min(1.0, reward)) # 限制范围防止异常值放大更新步长temperature0.0是为了让打分尽量稳定但即使这样同一个状态分两次也可能差 0.3所以我在实际项目里会同一个状态采样三次取平均。max_tokens8是因为只需要输出一个数字给多了反而容易夹带解释文本。解析失败时返回上一轮奖励或者 0.0这是必须的兜底解析失败返回 NaN 会让整个训练直接崩掉。这类 LLM 奖励适合什么场景低频、状态能用语言描述、不需要实时反馈的场景。举例仓库里判断一个设备摆放是否合理每 5 秒评估一次可以接受但机械臂每个控制周期 10 毫秒让 LLM 打分完全不现实。高频控制必须让 RL 直接吃数值状态LLM 只能做高层指导。这是后面第 6 章组合方案的判断原则。5. 多智能体项目里的常见翻车场景与排查清单5.1 训练不收敛但单智能体测试很正常现象把代码拆成单智能体版本训练曲线正常一旦多个智能体同时开始训练奖励曲线变成一团乱麻调低学习率也只能缓解不能根治。原因多智能体环境下每个智能体的策略都在变对单个智能体来说环境是非平稳的它学到的 Q 值或策略梯度时刻在被队友和对手打乱。这不是超参数问题是独立学习的结构性问题。光调参等于用高倍望远镜看错方向。解决先确认每个智能体各自的奖励是否也在震荡如果是个体奖励平稳而总奖励乱问题在信用分配见下一条。如果个体奖励本身就乱把训练方式升级为中心化训练、去中心化执行训练时让每个智能体额外看到全局状态或对方动作执行时再退化到局部观测。5.2 多智能体互相推锅群体奖励上升个体策略退化现象总奖励在缓慢上涨但把每个智能体单独拎出来看其中一个的动作越来越固化永远在重复同一个动作序列换一个对手后完全失效。原因共享奖励无法区分谁的贡献大。A 智能体学会了好策略B 跟着捡分B 的策略没有被淘汰的压力于是退化成一个偷懒策略。解决第一步把总奖励拆成个人子奖励至少让每个智能体有自己的任务项哪怕只是很小的权重第二步引入边际贡献的概念对比我在场和我不在场的奖励差用差值指导分配。工程上最省事的是前者先拆开再优化。5.3 LLM 智能体在工具调用上死循环现象日志里同一个工具名反复出现模型每次都传接近相同的参数工具每次都返回同一个错误循环直到 max_iter 被截断。原因工具返回的错误信息没有给模型带来新的决策依据。常见的是错误信息太长被截断或者报错内容是参数错误这种没有实际指导意义的文案。解决把错误信息摘要化只保留关键字段比如第 3 个参数应为数字当前为字符串把重试次数从 max_iter 中分离单独设 max_retry超过后强制让模型换工具如果模型始终纠结在同一工具在下一轮消息里直接追加重新检查工具清单不要再次调用 tool_name。5.4 LLM 当奖励函数时打分漂移现象RL 训练曲线看起来像高频噪声明明环境没变化奖励值却上下大幅跳动策略学到的是去讨好打分规律而不是解决任务。原因LLM 打分本身有随机性温度再低也有采样波动状态描述一旦含糊模型会把注意力放到无关细节上。这是奖励信号的信噪比问题。解决降低到 temperature0.0把打分从连续值改成离散档位只允许输出 -1、0、1给 prompt 加参考锚点比如0 表示状态没有变化1 表示明显接近目标同一个状态采样三次取平均方差超过阈值时用上一轮的奖励替代。5.5 把微调的 LLM 直接当 RL 策略用奖励曲线假漂亮现象有人想把 LLM 微调成动作生成器训练阶段用模仿学习验证时单轮成功率很高但放进真实闭环环境里跑长回合累积收益明显低于 RL 训练出来的策略。原因LLM 微调优化的是 token 级别的交叉熵不是决策收益。单轮生成正确不代表多步决策能最大化长期回报而且微调数据的分布和运行时的真实分布不一致一步错后面全错。解决如果动作空间是开放式的又确实需要 LLM 的理解力把它放在规划层而不是控制层。让 LLM 输出方案建议RL 负责执行和评价。如果动作空间是固定有限的枚举类型直接用 RL 训练一个查表或策略网络不要硬套 LLM。6. 验证这套方案值不值得做离线回放、两个在线信号和一个组合习惯投入任何一个方向之前先用离线回放估上限。把一段历史数据录下来包含状态、动作、奖励和 LLM 输出然后用这段数据回放两种方案LLM 方案看在每个历史节点重新推理会得到什么动作、收益和单步延迟RL 方案看用历史数据做批量训练时个体奖励曲线的方差有多大。离线能跑通的效果在线不一定能复现但离线就崩的方案在线几乎一定崩。在线评估阶段除了常规的成功率我会额外盯两个信号单步耗时和恢复成本。一个方案奖励涨了但单步耗时从 0.2 秒涨到 2 秒说明推理成本正在吃掉收益。恢复成本是失败后回到正常状态需要多少额外动作或 token如果一次失败要消耗 20 次重试才恢复这个方案在生产里的可用性要打问号。我现在做智能体项目的默认组合是LLM 负责目标分解、排序和冲突裁决RL 负责高频动作执行最后加一层规则兜底。仓储调度那个项目就是这个结构LLM 接收订单和状态描述输出任务队列RL 控制每台设备是否移动、往哪个方向走设备碰撞风险由独立的安全规则直接覆盖。LLM 只在场景状态变化时被调用不参与每个控制周期RL 在底层持续学习优化规则负责不让任何一行代码出安全事故。这个组合习惯来自一次教训。我最早尝试让 LLM 每分钟给 RL 打一次分奖励信号变来变去训练曲线起伏大得没法看后来把奖励函数固定住LLM 只负责调整任务顺序RL 专心优化设备动作两天内训练就稳定了。给我最大的感受是多智能体项目真正难的不是某个模型有多强而是分清哪些决策应该交给语言模型、哪些动作必须交给强化学习。高频动作放 RL低频语义决策放 LLM规则兜底不可省按这个顺序切入大多数方案都能在两周内给出一个值得继续投入的原型。希望帮到你。本文还有配套的精品资源点击获取