作者简介
Philipp Schmid 是德国 AI 工程师与开发者关系专家，目前在 Google DeepMind 负责组建公司首个 AI DevRel 团队。此前他在 Hugging Face 担任技术负责人，深度参与开源大模型生态建设，是该社区的核心贡献者之一，曾获 AWS ML Hero 称号。他长期分享 LLM 微调、Agentic AI、开源工具等工程实战内容，个人博客 philschmid.de 是开发者圈内颇具影响力的技术资源。
综述
Philipp Schmid 近日对三份重量级 Agentic AI 训练技术报告进行了综合分析：
| | |
|---|
| | Agent Swarm：通过 RL 学习动态任务拆解与并行子智能体编排 |
| | 生产环境 RL + 实时学习闭环：5 小时内完成"采集→训练→部署"全流程 |
| | 自编辑上下文：20B 参数模型学会主动修剪检索文档，检索性能匹敌前沿大模型 |
文章提炼了三个团队的共同方法论，并深入分析了三个关键趋势：上下文管理的路径分化、奖励设计的迭代本质，以及垂直模型与通用大模型之间正在缩小的性能差距。
以下为原文翻译
我阅读了三份技术报告：月之暗面的 Kimi K2.5 论文、Cursor 的 Composer 2 报告与博客文章，以及 Chroma 的 Context-1 技术文档。以下是我的学习总结。
每份报告各有侧重。Kimi K2.5 训练了一个 Agent Swarm（智能体群），模型通过强化学习学会将任务拆解为并行的子智能体。Cursor 的 Composer 2 使用自摘要（self-summarization）来处理长编码会话，并从生产流量中进行实时强化学习。Chroma 的 Context-1 则教会模型"自编辑上下文"——主动修剪检索到的文档，为后续搜索腾出空间。
三者都采用强化学习，且方法论高度相似：
从强大的基座模型出发——都不是从零训练。月之暗面为 Kimi K2 增加了多模态预训练；Cursor 在 Kimi K2.5（1T 参数 / 32B 激活 MoE）基础上做继续预训练；Chroma 从 gpt-oss-20B 出发。
在生产环境中训练——每个团队都在与生产相同的工具、提示词和执行环境中运行 RL rollout。
结果导向的奖励——都使用可验证的结果信号，并辅以生成式奖励模型（Generative Reward Model, GRM）处理开放式任务。
异步大规模 rollout——每个训练步骤生成多条并行轨迹。智能体 rollout 成本高昂，三家都在基础设施上投入巨大以支撑规模化运行。
Kimi K2.5：通过强化学习实现 Agent Swarm 与并行智能体编排
Kimi K2.5 是月之暗面的多模态模型，采用 1T 参数 / 32B 激活 MoE 架构。其最核心的特性是 Agent Swarm——一个让模型学会动态地将任务拆解为并行子任务、并分发给子智能体的框架。并行化策略是通过强化学习习得的，而非手工编码。
PARL：并行智能体强化学习
大多数智能体系统是顺序执行的：思考 → 工具调用 → 观察 → 思考 → 工具调用。Agent Swarm 打破了这一模式——通过训练让模型生成多个并行的子智能体。
架构包含两个角色：
- 编排器（可训练）：决定何时创建子智能体、分配什么任务、如何聚合结果。拥有 create_subagent 和 assign_task 两个工具。
- 子智能体（冻结）：独立执行分配的任务。它们的轨迹不参与优化目标。
这种解耦解决了信用分配问题（credit assignment）。在端到端联合优化中，最终答案正确，可能是因为编排器拆解得好，也可能只是子智能体碰巧做对了。冻结子智能体、将其输出视为环境观察，意味着只有编排器的协调逻辑会被优化。
Kimi 还引入了"关键步骤"（critical steps）来衡量并行场景下的计算成本，类似于计算图中的关键路径。不是统计所有智能体的总步数，而是测量最长执行链——每个阶段的成本取所有并行子智能体中步数的最大值，总关键步数是这些最大值的累加。这激励编排器在各分支间均衡负载（缩短最长分支），而不仅仅是盲目追求并发数。
PARL 奖励设计
训练可靠的并行编排器需要精心设计的奖励。PARL 奖励包含三个部分：
- 性能奖励（r_perf）：任务是否成功？这是主要信号。
- 并行奖励（r_parallel）：激励子智能体实例化，防止"串行坍缩"（serial collapse）——一种局部最优，编排器默认使用单智能体执行，永远不去探索并行策略。
- 完成奖励（r_finish）：奖励已完成的子任务，防止"伪并行"（sham parallelism）——一种奖励黑客行为，编排器大量生成子智能体但不做有意义的任务拆解，只为领取 r_parallel。
辅助奖励的系数在训练过程中逐渐衰减为零，因此最终策略只优化性能本身。
推理阶段的工作方式
推理时，模型收到任务后自行决定是否以及如何并行化：
- 通过 create_subagent 创建带有具体指令的子智能体。
- 通过 assign_task 并行分配任务。子智能体使用独立的上下文窗口并发执行。
并行化决策不是硬编码的。简单任务上模型会顺序执行；复杂的多源研究任务上，它则启动大量并行智能体。训练分布鼓励这种行为——合成提示强调"宽搜索"（多独立信息源）或"深搜索"（多推理分支、延迟聚合）。提示本身并不指令模型并行化，而是创造出"并行有帮助"的任务场景。
Agent Swarm 将推理延迟降低高达 4.5 倍，同时提升准确率。在 BrowseComp 上达到 78.4%（单智能体 60.6%），超过 GPT-5.2 Pro（77.9%）。在 WideSearch 上，项目级 F1 从 72.8% 提升到 79.0%。Agent Swarm 还充当了主动上下文管理机制——将任务拆解到隔离的子智能体上下文中，规避了长序列运行中的上下文溢出问题。
更广泛的训练流水线
Kimi K2.5 的 RL 配方还包含以下组件：
- 规则化结果奖励：用于有可验证解的任务（推理、智能体任务）。
- 生成式奖励模型（GRM）：用于开放式任务。不是简单的通过/失败裁判，而是细粒度评估器，与内部质量标准对齐（有用性、美学质量、指令遵循）。引入多组替代 GRM 评判标准，以减轻奖励黑客行为。
- 拒绝采样微调（RFT）：构建自我改进的数据流水线——将成功的 RL 轨迹提取为 SFT 数据，用于后续训练阶段，每轮在前一轮基础上叠加。
- Token 效率交替策略（Token-efficiency toggles）：在预算约束阶段与标准扩展阶段之间交替训练，将输出长度缩减 25–30%，性能损失可忽略不计。
Cursor Composer 2：编程智能体的强化学习
Composer 2 是 Cursor 自研的智能体软件工程模型。它能读写文件、运行 Shell 命令、搜索代码库和浏览网页，目标是自主完成真实的编码任务。
固定且贴近生产的训练环境
Composer 2 在与用户交互完全相同的 Cursor 环境中训练：相同的工具、相同的提示词格式、相同的系统消息、相同的文件上下文。他们在训练期间维护了 Cursor 后端的影子部署（shadow deployment），确保工具行为（如语义搜索）与生产环境完全一致。
SWE-bench 等公开基准使用的是简化环境和过度指定的提示词，而真实的开发者请求是模糊的、混乱的、且允许多种正确解法。在生产环境中训练、从实际 Cursor 使用中抽取问题，意味着 Composer 2 学会的是真实分布上的表现。
他们还构建了 CursorBench——一个内部评估套件，任务来自其工程团队的真实编码会话。CursorBench 任务的中位改动量是 181 行（SWE-bench 为 7–10 行），提示词更短、更模糊。这个基准与产品共同进化：用户对智能体施加的压力越大，基准就变得越复杂。
RL 配方：四个组件
Composer 2 的 RL 基础设施由四个解耦的服务组成：
- 训练：基于 Ray 和 PyTorch 的全异步栈。
- 环境：每个 rollout 运行在内部平台 Anyrun 上的专用 Firecracker 微虚拟机中，支持带浏览器和 GUI 的完整开发环境。Anyrun 每秒可调度 500+ 个 pod，支持文件系统级快照和环境 fork，用于轨迹中途的检查点。
- 推理：与 Fireworks AI 合作进行 RL 推理。权重同步通过增量压缩上传到 S3 并跨训练 rank 分片，实现全球规模的分布式推理。推理 worker 可在 rollout 进行中更新权重，使后续 token 更贴近当前策略。
- 评估：运行固定的生产后端和 Cursor 客户端副本，高置信度保证评估行为与用户体验一致。
策略梯度算法是 GRPO 的近似变体，单轮次应用（每个提示只训练一次），全参数更新。他们移除了标准 GRPO 的长度归一化项（会引入长度偏差），并跳过了标准差优势归一化（当组内所有 rollout 正确性相同时会过度放大噪声）。
Cursor 还训练了额外的 Multi-Token Prediction（MTP）层用于投机解码。这些层是自蒸馏的——学习预测主 LM head 在每个 token 位置的精确 logits 分布。MTP 层从零初始化，在长上下文和 SFT 阶段联合微调后再进入 RL 训练，带来 2–3 倍推理加速，质量退化极小。
长会话的自摘要
真实的编码任务可能很长。智能体可能进行数十次工具调用、读取大量文件、迭代数百轮。为了在有限上下文窗口内保持效果，Composer 2 使用自摘要：每次 rollout 可以包含多次生成，通过摘要链接在一起。最终的结果奖励应用于链中所有 token，因此保留关键信息的好摘要会被强化，丢失关键上下文的差摘要会被削弱。
模型在 RL 训练中自行学会了何时以及如何做摘要。对于困难任务，它往往会进行多次摘要。
实时 RL：从生产流量中学习
除了模拟 RL，Cursor 还运行实时 RL——从真实的生产推理 token 中提取训练信号。流程如下：
- 从用户与当前 checkpoint 的交互中收集数十亿 token。
- 将用户行为提炼为奖励信号（例如：用户是否继续修改、是否表现出满意……）。
- 基于这些信号进行训练，生成更新的 checkpoint。
整个循环约 5 小时，因此他们每天可部署多次改进后的 checkpoint。保持循环快速意味着数据几乎处于在线策略（on-policy）状态：生成数据的模型（几乎）就是正在训练的模型。
Chroma Context-1：自编辑的搜索智能体
Context-1 是一个 20B 参数的智能体搜索模型，只做一件事并做到极致：查找文档。它不回答问题，而是返回一组排序后的支持文档给下游推理模型。核心创新是自编辑上下文——模型学会主动淘汰不再相关的检索文档，释放上下文空间以供进一步探索。
合成数据流水线
真实的智能体搜索任务难以大规模获取——你需要多跳查询，且有已知的真实文档集。Chroma 构建了覆盖四个领域的合成生成流水线：Web、金融（SEC 文件）、法律（USPTO 专利）和邮件（Epstein 档案 + Enron 语料作为干扰项）。
每个任务遵循相同的结构：
- 验证：从文档中提取原文引用，检查它们确实出现在源文本中。
验证步骤至关重要，因为让 LLM 直接判断"这个文档是否相关"是不可靠的。他们使用基于引用提取的流水线：LLM 从文档和线索中提取匹配的引用，然后用确定性检查验证引用确实出现在源文本中。这一方法在所有领域实现了与人类标签 >80% 的一致性。
智能体环境
Context-1 使用四个工具：
- search_corpus(query)：混合 BM25 + 稠密检索，RRF 融合加重排序。
- grep_corpus(pattern)：正则搜索。
- read_document(doc_id)：读取特定块。
- prune_chunks(chunk_ids)：从上下文中删除不相关的块。
环境强制执行固定的 token 预算（如 32K token）。每回合后显示当前用量：[Token usage: 14,203/32,768]。超过软阈值时，提示建议修剪。超过硬截止线时，除 prune_chunks 外所有工具被封锁——模型必须修剪或结束。
去重在环境层面处理：之前所有搜索中见过的每个 chunk ID 都会被追踪，并作为排除过滤器传递给后续搜索，因此每次搜索总是呈现新信息。
当模型执行修剪时，环境从其视图中移除对应块，但保留完整的未修剪轨迹用于奖励计算。这使得智能体在搜索过程中遇到的相关文档即使后来被修剪，也能获得奖励。
一个具体的搜索轨迹示例：
训练：SFT 预热 + RL
SFT 预热：使用 Kimi K2.5 作为推理后端生成轨迹，然后根据召回质量过滤。高召回轨迹完整保留；低召回轨迹按递减比例纳入；极小部分（最多 5%）零召回轨迹作为负例。
RL 使用 CISPO（Clipped Importance-Sampled Policy Optimization），这是 GRPO 的变体，采用完全在线策略训练。每步 128 个查询，每个查询 8 次 rollout，每步产生 1,024 条轨迹。组内 8 次 rollout 获得相同奖励的组被丢弃（在组内归一化下无梯度信号）。
奖励经过精心设计：
- 结果奖励：F-beta 分数，beta 设得很高（召回的权重是精度的 16 倍）。这反映了 Context-1 的角色定位——遗漏文档比包含无关文档更糟，因为下游模型能过滤噪声但无法恢复从未被检索到的内容。
- 过程奖励：轨迹召回。奖励智能体在搜索中遇到相关文档，即使后来被修剪。没有这个奖励，智能体会收敛到"一次宽泛搜索然后退出"的最短路径策略。
- 最终答案奖励：+1.0，奖励检索到包含实际答案的块。
- 惩罚：重复修剪惩罚（阻止逐个修剪的低效串行行为）；回合数惩罚（阻止回报递减的搜索循环）。
共同主题
在部署的地方训练
三个团队都大量投入于让训练环境匹配生产环境。Cursor 使用影子生产后端；Kimi 在相同的 harness 中运行子智能体；Chroma 用真实数据库运行搜索。目标一致：最小化训练表现与真实世界效果之间的差距。
上下文管理是一等公民问题
智能体的上下文随时间不断增长。三家给出了三种不同方案：Cursor 用自摘要压缩历史；Kimi 将上下文分片到并行子智能体中实现隔离；Chroma 教会模型主动丢弃无关块。方案不同，但解决的是同一个底层约束。
奖励设计是迭代过程
每个团队都描述了发现并修复奖励黑客行为的过程。Cursor 的模型学会了发出损坏的工具调用来规避惩罚；Kimi 的编排器陷入"串行坍缩"或"伪并行"；Chroma 的智能体收敛到"一次搜索就退出"。每次的路径都是相同的：观察退化行为 → 理解激励机制 → 添加针对性的奖励或惩罚。
公开基准远远不够
Cursor 明确指出 SWE-bench 分数与现实世界效用不相关——他们从真实用户会话中构建了 CursorBench。Chroma 构建了覆盖四个领域的合成基准。Kimi 同时使用公开和内部评估。结论很清楚：构建垂直模型，就需要垂直评估。
小规模专用模型可以与前沿模型竞争
Chroma 的 20B 模型在检索任务上匹配前沿规模 LLM，但成本只有几分之一，速度快 10 倍。Composer 2 实现了帕累托最优的成本-精度权衡，优于更大的 API 模型。领域特定的强化学习训练正在缩小纯参数规模带来的性能差距。
资源
AI 速览
