Kimi K2.5 PARL：并行代理强化学习技术深度解析

Agent Swarm 架构概览

从串行到并行：Agentic 系统的范式转变

传统的 agentic 系统采用串行执行模式：

sequenceDiagram
    participant User
    participant Agent
    participant Tools
    
    User->>Agent: 提交任务
    loop 串行执行
        Agent->>Agent: 思考
        Agent->>Tools: 工具调用
        Tools-->>Agent: 观察结果
    end
    Agent-->>User: 最终答案

这种模式的瓶颈显而易见：每个工具调用都必须等待前一个完成，导致 latency 随步骤数线性增长。对于一个需要 10 次搜索和 5 次代码执行的任务，如果每次调用平均耗时 2 秒，总时间将超过 30 秒。

Kimi K2.5 提出的 Agent Swarm 框架彻底改变了这一模式：

sequenceDiagram
    participant User
    participant Orchestrator as Orchestrator<br/>(可训练)
    participant SA1 as Sub-agent 1<br/>(冻结)
    participant SA2 as Sub-agent 2<br/>(冻结)
    participant SA3 as Sub-agent 3<br/>(冻结)
    
    User->>Orchestrator: 复杂任务
    Orchestrator->>Orchestrator: 分析任务结构
    
    par 并行执行
        Orchestrator->>SA1: 子任务 A
        Orchestrator->>SA2: 子任务 B
        Orchestrator->>SA3: 子任务 C
    end
    
    SA1-->>Orchestrator: 结果 A
    SA2-->>Orchestrator: 结果 B
    SA3-->>Orchestrator: 结果 C
    
    Orchestrator->>Orchestrator: 聚合结果
    Orchestrator-->>User: 最终答案

双层架构设计

Agent Swarm 的核心是双层架构：

这种设计的精妙之处在于解耦了信用分配问题（Credit Assignment Problem）。在传统的端到端训练中，如果最终答案正确，可能是 orchestrator 分解得好，也可能是某个 sub-agent “运气好”。通过冻结 sub-agents，它们的输出被视为环境观察，只有 orchestrator 的协调逻辑被优化。

关键工具

Orchestrator 配备了两个核心工具：

1. create_subagent：创建新的子代理实例
2. assign_task：将任务分配给指定子代理

这些工具的调用不是硬编码的，而是通过 RL 学习得到的。模型会根据任务复杂度自主决定：

• 是否需要并行化？
• 应该创建多少个子代理？
• 每个子代理应该处理什么子任务？

PARL：并行代理强化学习

核心思想

PARL（Parallel-Agent Reinforcement Learning） 是 Kimi K2.5 训练 Agent Swarm 的核心算法。与传统的单代理 RL 不同，PARL 需要解决以下独特挑战：

1. 并行度决策：模型需要学习何时并行、何时串行
2. 任务分解质量：如何将复杂任务分解为可并行执行的子任务
3. 负载均衡：避免某些子代理过载而其他闲置

Critical Steps：衡量并行效率的新指标

在传统 RL 中，我们通常用总步数来衡量 episode 长度。但在并行场景中，总步数会误导优化方向。

Kimi 提出了 Critical Steps（关键步数） 的概念，类比计算图中的关键路径：

flowchart TD
    subgraph "传统度量：总步数 = 15"
        A1[Agent 1: 5 steps] 
        A2[Agent 2: 5 steps]
        A3[Agent 3: 5 steps]
    end
    
    subgraph "Critical Steps：max = 5"
        B1[Agent 1: 5 steps]
        B2[Agent 2: 3 steps]
        B3[Agent 3: 4 steps]
        B4[并行屏障]
    end

对于每个并行阶段，critical steps 定义为该阶段所有并行子代理中的最大步数。总 critical steps 是所有阶段的这些最大值之和。

为什么这很重要？

• 总步数优化会导致”虚假并行”：创建大量子代理，每个只做一点点工作
• Critical steps 优化真正关注 latency：鼓励 orchestrator 平衡各子代理的工作负载
• 这与编译器优化中的关键路径分析（Critical Path Analysis）异曲同工

PARL 奖励函数设计

训练可靠的并行协调器需要精心设计的奖励函数。PARL 的奖励由三个组件构成：

1. 性能奖励（Performance Reward, r_perf）

r_perf = 1  if 任务成功
       = 0  if 任务失败

这是最主要的信号，直接反映任务完成质量。

2. 并行度奖励（Parallelism Reward, r_parallel）

这个奖励是为了防止 “串行崩溃”（Serial Collapse） —— 一种常见的局部最优，orchestrator 总是默认使用单代理执行，从不探索并行策略。

r_parallel = α * min(num_subagents, target_parallelism) / target_parallelism

其中 α 是随训练退火到 0 的系数。早期训练鼓励探索并行策略，后期完全依赖性能奖励。

3. 完成奖励（Finish Reward, r_finish）

这个奖励是为了防止 “虚假并行”（Spurious Parallelism） —— orchestrator 创建大量子代理但不进行有意义的任务分解，只是为了收集 r_parallel。

r_finish = β * (completed_subtasks / total_subtasks)

同样，β 会退火到 0。

总奖励公式

R_total = r_perf + λ_parallel(t) * r_parallel + λ_finish(t) * r_finish

其中 λ(t) 表示随时间退火的权重系数。最终的策略只优化纯粹的性能。

推理时的并行决策

动态并行化流程

在推理阶段，模型根据任务特征动态决定并行策略：

flowchart TD
    A[接收任务] --> B{任务分析}
    B -->|简单任务| C[串行执行]
    B -->|复杂多源任务| D[识别子任务结构]
    D --> E[创建子代理]
    E --> F[并行分配任务]
    F --> G[聚合结果]
    G --> H{需要进一步分解？}
    H -->|是| D
    H -->|否| I[生成最终答案]
    C --> I

训练分布设计

Kimi 使用合成提示来塑造模型的并行化行为。这些提示强调两种模式：

1. Wide Search（广搜索）：需要查询多个独立信息源

   • 示例：“比较 Python、Go、Rust 三种语言在并发编程方面的异同”
   • 模型应该并行查询每种语言的文档

2. Deep Search（深搜索）：需要多条推理路径，后期聚合

   • 示例：“分析某公司股价下跌的潜在原因”
   • 模型应该并行探索财务、行业、宏观经济等不同角度

关键设计：提示中不直接指示模型并行化，而是创建那些并行化有帮助的任务。这让模型自己学会何时并行是有效的。

性能表现

BrowseComp 基准测试

Agent Swarm 不仅超越了单代理基线，还略微超过了 GPT-5.2 Pro。

WideSearch 基准测试

Latency 优化

在复杂多源研究任务中，Agent Swarm 将推理延迟降低了 4.5 倍，同时提高了准确率。这是因为：

1. 并行搜索减少了等待时间
2. 子代理的独立上下文避免了长序列的注意力稀释
3. 任务分解让每个子代理专注于更简单的子问题

隐性的上下文管理

Agent Swarm 还起到了主动上下文管理的作用：

flowchart LR
    subgraph "串行执行的问题"
        A1[步骤1] --> A2[步骤2] --> A3[步骤3] --> A4[上下文溢出]
    end
    
    subgraph "Agent Swarm 的解决方案"
        B1[子代理1<br/>独立上下文] 
        B2[子代理2<br/>独立上下文]
        B3[子代理3<br/>独立上下文]
        B1 --> C[Orchestrator 聚合]
        B2 --> C
        B3 --> C
    end

通过将任务分解到隔离的子代理上下文中，避免了长串行运行中的上下文溢出问题。

Kimi K2.5 的完整 RL 训练管线

除了 PARL，Kimi K2.5 的训练还包含以下组件：

1. 基于规则的结果奖励

对于可验证的任务（数学推理、代码执行、agentic 任务），使用确定性规则计算奖励：

• 代码是否通过测试？
• 数学答案是否正确？
• 工具调用是否符合语法？

2. Generative Reward Models (GRMs)

对于开放式任务，Kimi 使用 GRM 进行细粒度评估。GRM 不是简单的 pass/fail 判断，而是根据多个维度打分：

• Helpfulness（帮助性）
• Aesthetic quality（美学质量）
• Instruction following（指令遵循度）

3. Rejection Sampling Fine-Tuning (RFT)

这是一个自我改进的数据 pipeline：

flowchart LR
    A[RL 训练] --> B[提取成功 Trajectory]
    B --> C[作为 SFT 数据]
    C --> D[下一训练阶段]
    D --> A

成功的 RL 轨迹被提取出来，作为下一轮的监督学习数据，形成迭代优化。

4. Token 效率 Toggle

训练过程中交替使用：

• 预算约束阶段：强制模型在有限 token 内完成任务
• 标准扩展阶段：允许正常长度输出

这使模型学会在保持性能的同时，将输出长度减少 25-30%。

优势与局限

优势

局限与挑战

参考资料

1. Kimi K2.5 Technical Report - Moonshot AI 官方技术报告
2. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning - 相关 RL 训练方法
3. AlphaStar: Mastering the Real-Time Strategy Game StarCraft II - 多代理 RL 的经典案例
4. Multi-Agent Reinforcement Learning: A Selective Overview - 多代理 RL 综述