支付宝 Copilot 3.0 — Multi-Agent Planning 的 GRPO 训练实战

January 1, 2020

原文：Multi-Agent 的灵活编排之路 | 作者：穆辰、锡亮、初影（阿里云开发者公众号）

这篇文章基于阿里云开发者社区原文深度扩写。我以第一视角重新梳理了支付宝商家经营助手 Copilot 3.0 中 Planning 模块从 CoT 到 GRPO 的完整迭代过程——三个核心难点、7 维复合奖励函数、SFT+GRPO 两阶段训练、以及那个让推理长度降 61%、准确率升 7.4 个百分点的实战结果。

这篇文章说了什么

支付宝商家经营助手 Copilot 从 2.0 升级到 3.0，核心变化是从单一 LLM 架构升级为 Multi-Agent 架构。其中最关键的模块是 Planning——一个负责理解用户问题、把问题拆解并分配合适 Agent 来处理的大脑。

Planning 不是一个简单的分类器。它要同时做改写、拆解、分配、排序——本质上是一道复杂的排列组合题。之前用短 CoT 效果不错，但有两个尖锐问题：

复杂问题思考太长：一思考就刹不住车，输出卡住、成本飙升
简单问题也反复验证：模型养成了"过度思考"的习惯，简单问题也说车轱辘话

解决方案：SFT + GRPO 两阶段训练。SFT 教模型"格式"，GRPO 教模型"该快就快、该慢就慢"。

结果：

推理长度均值从 240 降到 93 token（降幅 61.2%）
准确率从 78.7% 提升到 86.1%（+7.4 个百分点）
推理长度标准差从 77 降到 26（波动性大幅改善）

核心结论：GRPO 不一定让模型"思考更多"，也可以让模型"思考更精准"。关键是奖励函数里要有思考长度约束。

有效的实验就这几招

方法	做了什么	效果
先 SFT 再 GRPO	SFT 阶段用 DeepSeek R1 生成的合成数据学格式，GRPO 阶段用人工标注数据优化策略	直接 GRPO 收敛到 0.5-0.6，SFT+GRPO 收敛到 0.9
7 维复合奖励函数	格式完整性(0.1) + JSON 有效性(0.1) + 思考长度(0.1) + 思考质量(0.1) + 改写准确率(0.2) + 专家分配准确率(0.3) + 规划准确率(0.1)	多目标约束，防止模型走捷径
思考长度 S 形曲线惩罚	不是一刀切截断，而是用 S 形平滑过渡	太短或太长的思考都有惩罚，但允许自然波动
混合历史数据训练	业务迭代加新 Agent 时，新老数据混合训练，不改历史数据	GRPO 泛化能力够强，老 Prompt 没新 Agent 就没必要改
有思考过程 vs 无思考过程对比	两组完全相同的实验条件，只差有没有 `<think>` 标签	有思考过程的模型在改写和规划上表现显著更优

一、业务背景：支付宝商家经营助手

1.1 什么是 Copilot

支付宝商家经营助手是一个面向商家的 AI 助手，主要功能：

基础业务：商家入驻、产品签约、运营工具使用
运营服务：对账结算、数据分析、策略推荐
智能优化：关键词配置、banner 生成、商品图片优化

用户可以在支付宝 APP 搜索"支付宝商家助手"小程序直接体验。

1.2 从 2.0 到 3.0 的架构变化

Copilot 2.0 是一个单一 LLM 架构——所有问题都丢给一个大模型，让它自己判断是回答、是调工具、还是做分析。

问题：

单一 LLM 很难同时平衡"闲聊能力"和"专业分析能力"
意图识别、query 改写、任务规划三个子模块能力受限
面对复杂 query 时处理效能不足

Copilot 3.0 改成了 Multi-Agent 架构：

一个 Planning 模型 负责调度
多个 专家 Agent（全网搜索、数据分析、策略推荐、图片生成、人群运营等）负责执行

1.3 Planning 的角色

Planning 要做的事本质上是一道复杂的排列组合题：

在充分理解用户问题后，把问题分配给合适的一个或多个专家，同时包括改写、拆解、分配、生成执行顺序等多个环节。

举个例子——假设有 3 个 Agent（a、b、c），理论上分配方案至少有 15 种。再加上每个 Agent 要处理的具体子问题不同，方案空间非常大。

这跟之前用 Intention Classification 做路由有本质不同：

意图分类：只判断"这是什么问题"→ 映射到 1 个 Agent
Planning：判断"这个问题需要谁来解决、按什么顺序、子问题是什么"

二、三个核心难点

2.1 鱼和熊掌：复杂问题 vs 简单问题

DeepSeek R1 的用户都懂：模型一思考就刹不住车。简单问题也翻来覆去验证，翻来覆去说车轱辘话。

这是 CoT（Chain of Thought）训练天生的副作用——模型学会了"多想几步"，但不知道什么时候该停下来。

Planning 场景里这个问题更尖锐：

复杂问题（比如"帮我分析一下上个月的营收，并推荐 3 个优化策略"）：需要拆成数据分析 + 策略推荐，两步走，思考过程要完整
简单问题（比如"今日资讯"）：直接交给全网搜索 Agent 就行，不需要深思考

GRPO 的训练必须同时优化这两个目标：复杂问题准确率高 + 简单问题思考短。

2.2 思考过程怎么标注

让运营写带思考过程的标准答案，几乎是不可行的——写一段有逻辑的思考过程耗时长、验收成本高、而且质量参差不齐。

他们的解法：先用大模型生成合成数据，再人工校验。SFT 阶段用的数据是 DeepSeek R1 生成的思考过程 + 规划结果，筛选长度较短的样本；GRPO 阶段数据是人工标注合成的（只标注规划结果，思考过程不要求人工写）。

2.3 业务迭代时历史数据怎么办

今天 5 个 Agent，下个月变成 8 个，之前标注的数据怎么处理？

答案是：不改历史数据，直接混合训练。

因为 GRPO 学到了"在给定的 Agent 列表里做最优选择"的能力。历史的 Prompt 里没有新 Agent（比如《人群运营 Agent》），那在历史数据里《策略 Agent》就是当时的最优选择——没必要改。

推理时，只要用最新的 Prompt（包含新 Agent 列表），模型就能自动处理新场景。

三、解决方案：SFT + GRPO 两阶段训练

3.1 数据构造

输入维度：

历史上下文窗口（动态滑动窗口，N 轮对话）
当前可用的专家列表
数据分析工具列表
产品服务列表

输出格式：

<think>
好的，我现在需要处理用户的问题："查看经营周报"。
首先，根据提供的工具列表，用户问题属于其中的一项。因此，这个问题应该由数据分析专家来处理。
接下来，检查是否有其他相关的子问题需要拆解，但用户的问题很明确，所以不需要进一步拆解。
最后，确认是否需要其他专家介入，但这里只需数据分析专家即可。
</think>

<answer>
{
  "补全后的问题": "查看经营周报",
  "plan": [{
    "专家": "数据分析专家",
    "处理问题": ["查看经营周报"]
  }]
}
</answer>

冷启动数据：用 DeepSeek R1 生成合成数据（思考过程 + 规划结果），筛选出长度较短的样本，用于 SFT 训练。

人工标注数据：人工标注合成数据（只标注规划结果），用于 GRPO 训练。

3.2 SFT：教模型"格式"

SFT 阶段的目标很明确——让模型学会按照特定格式输出：

<think>...</think> 包裹思考过程
<answer>...</answer> 包裹规划结果（JSON）

SFT 只是应试教育：教会模型"格式"，但没教"什么样的思考是好的"。

3.3 GRPO：教模型"策略"

GRPO 是素质教育：不给定标准答案，而是给一个范围让模型探索，然后从更优的回答中找准迭代方向。

训练配置：

参数	值
基座模型	QwQ-32B
GPU	3 机 24 卡 A100
训练框架	ModelScope ms-swift
关键超参	`lr` 和 `beta`（KL 散度权重）

lr 和 beta 设得越大，收敛原则上越快，但训练也越不稳定。实际训练中需要根据是否出现震荡来调整。

四、7 维复合奖励函数

这是这篇文章最有价值的部分。奖励函数从三个方向展开，共 7 个维度：

Reward = 0.1 * StrictFormatReward
       + 0.1 * JSONValidReward
       + 0.1 * ThinkLengthReward
       + 0.1 * ThinkQualityReward
       + 0.2 * CorrectnessReward
       + 0.3 * ExpertValidationReward
       + 0.1 * ProcessingQualityReward

4.1 格式完整性评估（StrictFormatReward + JSONValidReward）

class StrictFormatReward:
    _pattern = re.compile(
        r"^<think>\n.*?\n</think>\n\n<answer>\n.*?\n</answer>$", 
        re.DOTALL
    )
    
    def __call__(self, completions, **kwargs):
        return [1.0 if self._pattern.match(c) else 0.0 for c in completions]

为什么格式奖励放在 GRPO 阶段：因为纯 GRPO（不带 SFT）的格式 reward 是从很低的值开始震荡的（0-0.3），模型需要花大量步数学格式。而先 SFT 再 GRPO，格式奖励一开始就接近 1.0，模型可以把所有步数花在优化内容上。

4.2 思考过程评估（ThinkLengthReward + ThinkQualityReward）

ThinkLengthReward 是整个奖励函数里最精妙的设计：

class ThinkLengthReward:
    def __call__(self, completions, **kwargs):
        rewards = []
        for c in completions:
            length = len(c.think)
            if min_length <= length <= max_length:
                rewards.append(1.0)
            else:
                # S形曲线计算惩罚
                deviation = abs(length - mid) / eps
                reward = 1.0 / (1.0 + np.exp(5 * (deviation - 0.5)))
                rewards.append(float(reward))
        return rewards

不是一刀切截断，而是 S 形平滑过渡：

长度在理想范围内 → 满分
稍微超出 → 少量扣分
严重超出 → 接近 0 分
太短（没思考）→ 同样扣分

这个设计的精妙之处：它不要求"所有问题都用同样的思考长度"，只是惩罚极端情况。复杂问题的思考自然长一些、简单问题的思考自然短一些——只要都在合理范围内，都能拿满分。

ThinkQualityReward：关键词过滤，检查思考过程中是否出现了不应该有的内容（如敏感词等）。

4.3 答案准确性评估（CorrectnessReward + ExpertValidationReward + ProcessingQualityReward）

三个维度覆盖 Planning 输出的所有方面：

奖励	权重	评估什么	怎么算
CorrectnessReward	0.2	query 改写对不对	语义相似度 + 覆盖度
ExpertValidationReward	0.3	Agent 分配对不对	跟标准答案的专家列表比对
ProcessingQualityReward	0.1	规划对不对	语义相似度 + 覆盖度 + 多样性

权重最高的维度是 ExpertValidationReward（0.3）——因为对 Planning 来说，Agent 选错了意味着整个问题解决流程走错路，这是最致命的错误。

五、训练结果

5.1 先 SFT 再 GRPO 的收敛曲线

四条关键 curve：

格式遵循 + 答案质量：一开始就很高（SFT 的功劳），随着训练继续提升
改写、专家选择、规划 reward：都持续提高
思考长度：显著下降！从 ~240 token 降到 ~150 token 并收敛
总 reward：最终收敛在 0.9 左右

对比：直接 GRPO（不先 SFT）

所有 reward function 都从很低开始震荡
最终收敛在 0.5-0.6 之间
差距显著——SFT 是 GRPO 的必要前置

5.2 无思考过程 vs 有思考过程

同样先 SFT 再 GRPO，对比有 <think> 标签和无 <think> 标签的版本：

维度	有思考过程	无思考过程
GRPO 后 reward	0.9	0.6-0.7
平均输出长度	93 token	100 token
改写能力	强	一直很弱
专家选择	强	尚可

结论：思考过程不是锦上添花，是 Planning 能力的基石。没有思考过程的模型，改写（把用户模糊的话翻译成标准表述）能力一直上不去。

5.3 实测效果

指标	GRPO 前	GRPO 后	变化
推理长度均值	240.29	93.28	-61.2%
推理长度标准差	77.30	26.11	波动大幅改善
准确率	78.7%	86.1%	+7.4pp (相对 +9.4%)

在保证模型准确率提升的同时，把推理长度砍掉 60%——这是 GRPO 在 Planning 场景最亮眼的结果。

六、工程启示

6.1 SFT 是 GRPO 的必要前置

直接 GRPO 训练 Planning 模型 = 花大量步数学格式、收敛慢、最终效果差。先 SFT 教会格式，再 GRPO 优化内容——各司其职，效果翻倍。

6.2 思考长度奖励是双刃剑

用 S 形平滑函数而不是 hard cutoff，给了模型足够的灵活性。如果一刀切——"超过 200 token 就是 0 分"——模型可能会为了压缩长度而牺牲推理质量。

6.3 多任务混合训练是 GRPO 的天然优势

业务迭代加新 Agent 时，不需要改历史数据。GRPO 学到的是"在给定列表里选最优"的能力，而不是"记住正确答案"的能力。这是 RL 相比 SFT 最大的优势之一——泛化到新组合。

6.4 复合奖励函数 ≠ 堆奖励

7 个维度不是随便堆的。权重的分配反映了业务优先级：

专家选择（0.3）最重要——选错 Agent 整个流程崩盘
改写准确率（0.2）次重要——query 理解偏差导致后续全错
格式 + 思考 + 规划（各 0.1）——锦上添花，但不能为零

七、跟其他 GRPO Agent 项目的对比

维度	本文 (Copilot Planning)	基金助手	投标 Agent	SageMaker RLVR
Agent 类型	Multi-Agent 调度	SubAgent 工具选择	8 Agent 协作	单 Agent 多工具
输出格式	think + JSON plan	thought + action + plan	trajectory	TOOLCALL tags
奖励维度	7 维复合	6 维规则	多阶段规则	三层分级
思考控制	S 形长度惩罚（最核心创新）	逻辑关键词奖励	-	-
训练阶段	SFT → GRPO	纯 GRPO	SFT → DPO → RL	纯 RLVR

最独特的贡献：用 GRPO 让模型学会"该快就快、该慢就慢"——这在所有 GRPO Agent 笔记里可能是唯一一个有系统化思考长度控制的案例。

这篇文章说了什么​

有效的实验就这几招​

一、业务背景：支付宝商家经营助手​

1.1 什么是 Copilot​

1.2 从 2.0 到 3.0 的架构变化​

1.3 Planning 的角色​

二、三个核心难点​

2.1 鱼和熊掌：复杂问题 vs 简单问题​

2.2 思考过程怎么标注​

2.3 业务迭代时历史数据怎么办​

三、解决方案：SFT + GRPO 两阶段训练​

3.1 数据构造​

3.2 SFT：教模型"格式"​

3.3 GRPO：教模型"策略"​

四、7 维复合奖励函数​

4.1 格式完整性评估（StrictFormatReward + JSONValidReward）​

4.2 思考过程评估（ThinkLengthReward + ThinkQualityReward）​

4.3 答案准确性评估（CorrectnessReward + ExpertValidationReward + ProcessingQualityReward）​

五、训练结果​

5.1 先 SFT 再 GRPO 的收敛曲线​

5.2 无思考过程 vs 有思考过程​

5.3 实测效果​

六、工程启示​

6.1 SFT 是 GRPO 的必要前置​

6.2 思考长度奖励是双刃剑​

6.3 多任务混合训练是 GRPO 的天然优势​

6.4 复合奖励函数 ≠ 堆奖励​

七、跟其他 GRPO Agent 项目的对比​