Kimi K2.5：视觉 agentic 智能

本文译自 Kimi Team 的 Kimi K2.5: Visual Agentic Intelligence¹，2026 年 2 月 2 日提交于 arXiv，30 页 12 图 6 表。这里是全文翻译，覆盖摘要、§1 引言、§2 文本与视觉的联合优化、§3 Agent Swarm、§4 方法总览、§5 评测、§6 结论，以及附录 B 预训练、附录 C Infra、附录 D 统一 agentic 强化学习环境、附录 E 评测设置、附录 F 可视化。附录 A 的贡献者名单不在译文范围内。

摘要

我们推出 Kimi K2.5，一个开源的多模态 agentic 模型，目标是推进通用 agentic 智能。K2.5 强调文本与视觉的联合优化，让两个模态互相增强。这包含一系列技术：文本-视觉联合预训练、zero-vision SFT，以及文本-视觉联合强化学习。在这个多模态底座之上，K2.5 引入 Agent Swarm，一个自主的并行 agent 编排框架，它把复杂任务动态分解成异质的子问题并并发执行。大量评测显示 Kimi K2.5 在 coding、视觉、推理、agentic 任务等多个领域达到 state-of-the-art。Agent Swarm 相比单 agent baseline 最多把延迟降低 $4.5\times$。我们发布后训练好的 Kimi K2.5 模型 checkpoint²，以推动 agentic 智能的后续研究和现实应用。

1 引言

大语言模型（LLM）正在快速朝 agentic 智能演进。近期的进展，比如 GPT-5.2³、Claude Opus 4.5⁴、Gemini 3 Pro⁵ 和 Kimi K2-Thinking⁶，在 agentic 能力上——尤其是工具调用和推理上——展示了实质性的进步。这些模型越来越能把复杂问题分解成多步计划，并执行长串交织的推理与动作。

在这份报告里，我们介绍 Kimi K2.5 的训练方法和评测结果。具体来说，我们在以下两个关键方面改进了 K2.5 相比先前模型的训练。

文本与视觉的联合优化。K2.5 实践中的一个关键洞察是，文本与视觉的联合优化能同时增强两个模态、避免冲突。具体而言，我们为此设计了一套技术。预训练阶段，常规做法是在较晚的阶段才往文本 backbone 里加视觉 token⁷⁸，与之相反，我们发现在总的视觉-文本 token 量固定的前提下，early fusion 配上较低的比例倾向于给出更好的结果。因此 K2.5 在整个训练过程中都以一个恒定比例混合文本与视觉 token。

架构上，Kimi K2.5 采用 MoonViT-3D，一个原生分辨率的 vision encoder，纳入了 NaViT 的 packing 策略⁹，从而支持可变分辨率的图像输入。视频理解方面，我们引入一种轻量的 3D ViT 压缩机制：连续帧按四帧一组，过共享的 MoonViT encoder，然后在 patch 层面做时间维度平均。这个设计让 Kimi K2.5 能在同样的上下文窗口内处理长 $4\times$ 的视频，同时图像与视频 encoder 之间完全共享权重。

后训练阶段，我们引入 zero-vision SFT——只用纯文本 SFT 就能激活视觉推理和工具使用。我们发现在这一阶段加入人工设计的视觉轨迹反而损害泛化。相比之下纯文本 SFT 表现更好——很可能是因为联合预训练已经建立了很强的视觉-文本对齐，让能力能自然地跨模态泛化。之后我们在文本和视觉任务上一起做 RL。关键的是，我们发现视觉 RL 会增强文本表现而不是让它退化，在 MMLU-Pro 和 GPQA-Diamond 上都有提升。这种双向增强——文本 bootstrap 视觉，视觉再打磨文本——代表了联合训练下更好的跨模态对齐。

Agent Swarm：并行 agent 编排。现有大多数 agentic 模型依赖工具调用的串行执行。即使是能走几百个推理步的系统，比如 Kimi K2-Thinking⁶，也受制于推理时间的线性增长，导致无法接受的延迟、限制了任务复杂度。当 agentic 工作负载在范围和异质性上继续增长——比如构建一个涉及大规模调研、设计和开发的复杂项目——串行范式就越来越低效。

为了突破串行 agent 执行的延迟和可扩展性上限，Kimi K2.5 引入 Agent Swarm，一个并行 agent 编排的动态框架。我们提出 Parallel-Agent Reinforcement Learning（PARL） 范式，它与传统 agentic RL¹⁰ 分道扬镳。除了用可验证奖励优化工具执行之外，模型还被配上了创建 sub-agent 和委派任务的接口。训练时 sub-agent 是冻结的，它们的执行轨迹被排除在优化目标之外；只有 orchestrator 通过强化学习更新。这个解耦绕开了端到端协同优化的两个难题：credit assignment 的模糊性，以及训练不稳定。Agent Swarm 让复杂任务能被分解成异质子问题、由领域专精的 agent 并发执行，把任务复杂度从线性增长变成并行处理。在 wide-search 场景下，Agent Swarm 相比单 agent baseline 把推理延迟最多降低 $4.5\times$，同时把 item 级 F1 从 72.8% 提到 79.0%。

Kimi K2.5 代表了一个面向通用 agentic 智能的统一架构，把视觉与语言、thinking 与 instant 两种模式、对话与 agent 整合在一起。它在一大批 agentic 和前沿 benchmark 上都表现很强，在我们的内部评测里于视觉转代码生成（图/视频转代码）和真实软件工程上取得 state-of-the-art，同时在专精 agent 的多样性和并行度两个方向上都能 scale。为了加速社区朝通用 agentic 智能推进，我们开源 Kimi K2.5 后训练好的 checkpoint，让研究者和开发者能探索、改进、部署可扩展的 agentic 智能。

2 文本与视觉的联合优化

Kimi K2.5 是在 Kimi K2 之上、通过约 15 万亿混合视觉与文本 token 的大规模联合预训练构建出来的原生多模态模型。与那些要么牺牲语言能力、要么牺牲视觉能力的 vision-adapted 模型不同，我们的联合预训练范式同时增强两个模态。这一节描述把 Kimi K2 扩展成 Kimi K2.5 的多模态联合优化方法。

2.1 原生多模态预训练

Table 1：不同视觉-文本联合训练策略的性能对比。在总的视觉-文本 token 预算固定的前提下，early fusion 配上较低的视觉比例给出更好的结果。

多模态预训练的一个关键设计问题是：给定固定的视觉-文本 token 预算，最优的视觉-文本联合训练策略是什么。常规认知⁷⁸ 认为，应该在 LLM 训练的较晚阶段以高比例（比如 50% 或更高）集中引入视觉 token，这样能加速多模态能力的获得——这实际上把多模态能力当成语言能力之上的事后附加物。

然而我们的实验（如 Table 1 和 Figure 9 所示）揭示了不一样的故事。我们做了消融实验，在保持视觉与文本总 token 预算固定的前提下改变视觉比例和视觉注入时机。为了严格满足不同比例的目标，我们在引入视觉数据之前先用纯文本 token 预训练一个专门算出来的 token 数。出人意料的是，我们发现视觉比例对最终多模态性能的影响很小。事实上，在总的视觉-文本 token 预算固定的前提下，early fusion 配上较低的视觉比例给出更好的结果。这促成了我们的原生多模态预训练策略：不做那种集中在末尾的、视觉占比很重的激进训练，而是采用一个适中的视觉比例、在训练早期就集成进去，让模型自然发展出均衡的多模态表示，同时享受两个模态更长时间的协同优化。

2.2 Zero-Vision SFT

预训练好的 VLM 并不天然会做基于视觉的工具调用，这给多模态 RL 带来一个冷启动问题。常规做法通过人工标注或 prompt 工程得来的 chain-of-thought（CoT）数据解决这个问题⁷，但这类方法多样性受限，往往把视觉推理局限在简单图示和原始的工具操作（裁剪、旋转、翻转）上。

一个观察是，高质量的文本 SFT 数据相对充裕且多样。我们提出一个新方法 zero-vision SFT，只用文本 SFT 数据就在后训练阶段激活视觉的、agentic 的能力。在这个方法里，所有图像操作都通过 IPython 里的程序化操作来代理，实际上是传统视觉工具使用的一种泛化。这种「zero-vision」激活能带出多样的推理行为，包括像素级操作，比如通过二值化和计数来估计物体尺寸，并且能泛化到有视觉依托的任务上，比如物体定位、计数和 OCR。

Figure 2 展示了 RL 训练曲线，其起点来自 zero-vision SFT。结果显示 zero-vision SFT 足以激活视觉能力，同时保证跨模态的泛化。这个现象很可能归因于 §2.1 所述的文本与视觉的联合预训练。相比 zero-vision SFT，我们的初步实验显示文本-视觉 SFT 在视觉的、agentic 的任务上表现差得多，可能是因为缺少高质量的视觉数据。

2.3 文本-视觉联合强化学习（RL）

这一节我们描述 K2.5 中让多模态 RL 有效的方法，从 outcome-based 的视觉 RL 讲到那个涌现出来、能增强文本表现的跨模态迁移。

Outcome-Based Visual RL。在 zero-vision SFT 之后，模型还需要进一步打磨，才能可靠地把视觉输入纳入推理。仅靠文本发起的激活会有明显的失败模式：视觉输入有时被忽略，需要看图的时候图却没被 attend 到。我们在那些必须理解视觉才能做对的任务上做 outcome-based RL。我们把这些任务分成三个领域：

• 视觉 grounding 与计数：准确定位并数出图像中的物体；
• 图表与文档理解：解读结构化的视觉信息并抽取文字；
• 视觉关键的 STEM 题目：经过筛选、必须依赖视觉输入的数学与科学题。

在这些任务上做 outcome-based RL 既提升了基础视觉能力，也提升了更复杂的 agentic 行为。把这些轨迹提取出来做 rejection-sampling fine-tuning（RFT），就得到一条自我改进的数据流水线，让后续的联合 RL 阶段能用上更丰富的多模态推理轨迹。

视觉 RL 提升文本表现。

Table 2：跨模态迁移——视觉 RL 提升文本知识

为了考察视觉与文本表现之间是否存在权衡，我们在视觉 RL 前后都评测了纯文本 benchmark。出人意料的是，outcome-based 的视觉 RL 在文本任务上产生了可测量的提升，包括 MMLU-Pro（84.7% $\rightarrow$ 86.4%）、GPQA-Diamond（84.3% $\rightarrow$ 86.4%）和 LongBench v2（56.7% $\rightarrow$ 58.9%）（Table 2）。分析表明视觉 RL 改善了那些需要结构化信息抽取的领域上的 calibration，降低了在类似「有视觉依托的推理」的查询（比如计数、OCR）上的不确定性。这些发现说明视觉 RL 可以促成跨模态泛化，在提升文本推理的同时看不到语言能力的退化。

联合多模态 RL。既然发现稳健的视觉能力可以从 zero-vision SFT 加视觉 RL 中涌现出来——而且还会进一步增强通用文本能力——我们在 Kimi K2.5 的后训练中采用联合多模态 RL 范式。与常规的按模态划分专家不同，我们组织 RL 领域的依据不是输入模态，而是能力——知识、推理、coding、agentic 等等。这些领域专家从纯文本和多模态查询中一起学习，而 Generative Reward Model（GRM）同样跨异质轨迹优化、不设模态壁垒。这个范式保证了不管能力提升是通过文本输入还是视觉输入获得的，都内在地会泛化过去、增强另一个模态上的相关能力，从而最大化跨模态的能力迁移。

3 Agent Swarm

现有 agent 系统的首要挑战在于它们依赖推理和工具调用步骤的串行执行。这个结构对更简单、短程的任务或许有效，但随着任务复杂度上升、累积上下文变长，它就不够用了。当任务演变到包含广泛的信息收集和错综的多分支推理时，串行系统常常遇到严重瓶颈¹¹⁴¹²。单个 agent 一步一步走完全程的容量是有限的，这会导致实际推理深度和工具调用预算被耗尽，最终妨碍系统处理更复杂场景的能力。

为解决这一点，我们引入 Agent Swarm 和 Parallel Agent Reinforcement Learning（PARL）。K2.5 不是把任务当成一条推理链来执行、也不依赖事先指定的并行化启发式规则，而是通过动态任务分解、subagent 实例化和并行子任务调度来发起一个 Agent Swarm。重要的是，并行本身并不被假定为天然有利；要不要并行、何时并行、怎么并行，这些决策都明确地通过环境反馈和 RL 驱动的探索学出来。如 Figure 4 所示，性能的推进过程展示了这种自适应能力——随着 orchestrator 在训练中优化自己的并行化策略，累计奖励平滑上升。

架构与学习设置。PARL 框架采用一个解耦架构，由一个可训练的 orchestrator 和一批从固定的中间 policy checkpoint 实例化出来的冻结 subagent 组成。这个设计有意避开端到端协同优化，以绕过两个根本难题：credit assignment 的模糊性，以及训练不稳定。在这种多 agent 设定下，outcome-based 奖励本质上是稀疏且带噪的；最终答案正确并不保证 subagent 的执行毫无瑕疵，正如失败也不意味着所有 subagent 都错了。把 subagent 冻结、把它们的输出当成环境观测而不是可微的决策点，我们就把高层的协调逻辑与底层的执行水平解耦了，从而收敛得更稳健。为提高效率，我们先用小尺寸 subagent 训练 orchestrator，再切换到更大的模型。我们的 RL 框架还支持动态调整 subagent 与 orchestrator 之间的推理实例比例，从而最大化整个集群的资源利用率。

PARL 奖励。训练一个可靠的并行 orchestrator 是有挑战的，因为独立 subagent 执行本身带来延迟的、稀疏的、非平稳的反馈。为此，我们把 PARL 奖励定义为：

性能奖励 $r_{\text{perf}}$ 评估给定任务 $x$ 下解 $y$ 的整体成功与质量。在此之上加了两个辅助奖励，各自应对学习并行编排中的一个不同难题。$r_{\text{parallel}}$ 用来缓解 serial collapse——一个 orchestrator 退回到单 agent 执行的局部最优。通过激励 subagent 实例化，这一项鼓励对并发调度空间的探索。$r_{\text{finish}}$ 关注被分派子任务的成功完成，用来防止 spurious parallelism，一种 orchestrator 通过大量生成 subagent 而不做有意义的任务分解、把并行度指标猛拉上去的 reward-hacking 行为。通过奖励已完成的子任务，$r_{\text{finish}}$ 强制了可行性，把 policy 引向有效且高效的分解。

为保证最终 policy 优化的是主目标，超参数 $\lambda_1$ 和 $\lambda_2$ 在训练过程中被退火到零。

Critical Steps 作为资源约束。为了在并行 agent 设定下衡量计算时间开销，我们类比计算图里的 critical path 定义 critical steps。我们把一个 episode 建模成一串执行阶段，索引 $t=1,\dots,T$。每个阶段里，主 agent 执行一个动作，它对应直接的工具调用，或者实例化一组并行运行的 subagent。记 $S_{\mathrm{main}}^{(t)}$ 为主 agent 在阶段 $t$ 走的步数（通常 $S_{\mathrm{main}}^{(t)} = 1$），$S_{\mathrm{sub},i}^{(t)}$ 为该并行组里第 $i$ 个 subagent 走的步数。阶段 $t$ 的时长由这一批里跑得最久的 subagent 决定。于是一个 episode 的总 critical steps 定义为

用 critical steps 而不是总步数来约束训练和评测，框架就明确地激励了有效的并行化。在这个指标下，那些不能缩短并行组最长执行时间的过度子任务创建收益甚微，而能缩短最长并行分支的均衡任务分解则直接降低 critical steps。结果是，orchestrator 被鼓励以最小化端到端延迟的方式在 subagent 之间分配工作，而不只是把并发度或总工作量拉满。

面向并行 agent 能力诱导的 prompt 构造。为了激励 orchestrator 利用并行化的优势，我们构造了一批合成 prompt，专门去逼串行 agentic 执行的极限。这些 prompt 强调两类：wide search，要求同时探索许多独立信息源；或者 deep search，要求多条推理分支加延迟聚合。我们还加入了受真实工作负载启发的任务，比如长上下文文档分析和大规模文件下载。串行执行时，这些任务很难在固定的推理步数和工具调用预算内完成。按构造，它们会鼓励 orchestrator 并行分派子任务，使得任务能在比单个串行 agent 可行范围更少的 critical steps 内完成。重要的是，这些 prompt 并没有明确指示模型去并行。相反，它们塑造了任务分布，使得并行分解和调度策略自然地占优。

4 方法总览

4.1 底座：Kimi K2 base 模型

Kimi K2.5 的底座是 Kimi K2¹³，一个万亿参数的 Mixture-of-Experts（ MoE）transformer¹⁴ 模型，在 15 万亿高质量文本 token 上预训练。Kimi K2 采用 token 高效的 MuonClip 优化器¹⁵¹⁶，配 QK-Clip 保训练稳定。模型总参数 1.04 万亿、激活参数 320 亿，用 384 个 expert、每 token 激活 8 个（稀疏度 48）。MuonClip、架构设计和训练基础设施的详细描述，参见 Kimi K2 技术报告¹³。

4.2 模型架构

Kimi K2.5 的多模态架构由三个组件构成：一个三维原生分辨率 vision encoder（MoonViT-3D）、一个 MLP projector，以及 Kimi K2 的 MoE 语言模型，遵循 Kimi-VL¹⁷ 建立的设计原则。

MoonViT-3D：图像与视频的共享 embedding 空间。在 Kimi-VL 里，我们用 MoonViT 原生地按原始分辨率处理图像，省掉了复杂的子图切分与拼接操作。MoonViT 从 SigLIP-SO-400M¹⁸ 初始化，纳入了 NaViT⁹ 的 patch packing 策略：单张图被切成 patch、压平，再顺序拼接成一维序列，从而能在不同分辨率的图像上高效地同时训练。

为了把图像理解能力最大程度地迁移到视频上，我们引入 MoonViT-3D，它架构统一、参数完全共享、embedding 空间一致。把「patch n’ pack」的思路推广到时间维度：最多四个连续帧被当成一个时空体，这些帧的 2D patch 被联合压平、packed 成单条一维序列，让同一套 attention 机制能在空间和时间上无缝运作。额外的时间维 attention 改善了对高速运动和视觉特效的理解，而共享则最大化了从静态图像到动态视频的知识泛化，在不需要专用视频模块、也不需要架构分叉的情况下取得很强的视频理解表现（见 Table 4）。在 MLP projector 之前，轻量的时间维 pooling 会把每个时间块内的 patch 聚合起来，得到 $4\times$ 的时间压缩，显著延长可行的视频长度。最终得到一条统一的流水线，图像预训练获得的知识和能力通过一个共享的参数空间和特征表示整体地迁移到视频上。

4.3 预训练流水线

如 Table 3 所示，Kimi K2.5 的预训练建立在 Kimi K2 语言模型 checkpoint 之上，跨三个阶段处理约 15T token：第一，独立的 ViT 训练，建立一个稳健的原生分辨率视觉 encoder；第二，联合预训练，同时增强语言与多模态能力；第三，在高质量数据上做 mid-training 并激活长上下文，打磨能力、扩展上下文窗口。

Table 3：训练阶段总览：数据构成、token 量、序列长度和可训练组件。

ViT 训练阶段。MoonViT-3D 从 SigLIP¹⁸ 出发，在图-文对和视频-文对上做 continual pre-training，其中文本部分包含多种目标：图像 alt text、图像与视频的合成 caption、grounding bbox，以及 OCR 文本。与 Kimi-VL¹⁷ 的实现不同，这次 continual pre-training 不包含对比损失，只用条件于输入图像和视频的 caption 生成的交叉熵损失 ${L}_{caption}$。我们采用两级对齐策略。第一级我们更新 MoonViT-3D，通过 caption 损失把它与 Moonlight-16B-A3B¹⁶ 对齐，消耗约 1T token、训练 FLOPs 很少。这一级让 MoonViT-3D 主要学会理解高分辨率图像和视频。紧接着一个很短的第二级，只更新 MLP projector，把 ViT 与 1T 的 LLM 桥接起来，让后面的联合预训练更平滑。

联合训练阶段。联合预训练阶段从一个接近训练末期的 Kimi K2 checkpoint 继续，在 4K 序列长度上再走 15T 视觉-文本 token。数据配方在 Kimi K2 的预训练分布之上做了扩展：引入 unique token、调整数据比例、加重 coding 相关内容的权重、控制每个数据源的最大 epoch 数。第三级做长上下文激活，融入更高质量的 mid-training 数据，通过 YaRN¹⁹ 插值逐步扩展上下文长度。这在长上下文文本理解和长视频理解上带来了显著的泛化提升。

4.4 后训练

4.4.1 监督微调

沿用 Kimi K2¹³ 建立的 SFT 流水线，我们通过从 K2、K2 Thinking 以及一批自有的专家模型合成高质量候选回答来开发 K2.5。我们的数据生成策略用了针对特定领域定制的专门流水线，把人工标注与高级 prompt 工程、多级验证结合起来。这套方法产出了一个大规模指令微调数据集，包含多样的 prompt 和错综的推理轨迹，最终训练模型在复杂的现实应用中优先做交互式推理和精确的工具调用。

4.4.2 强化学习

强化学习是我们后训练的关键一环。为了促成文本与视觉模态的联合优化、以及为 agent swarm 支持 PARL，我们开发了一个统一 agentic 强化学习环境（附录 D）并优化了 RL 算法。文本-视觉联合 RL 和 PARL 都建立在这一节描述的算法之上。

策略优化。对每个从数据集 $\mathcal{D}$ 采出的问题 $x$，用先前的 policy $\pi_{\mathrm{old}}$ 生成 $K$ 个回答 $\{y_1,\dots,y_K\}$。我们按下面这个目标优化模型 $\pi_\theta$：

这里 $\alpha, \beta, \tau >0$ 是超参数，$y^j_{0:i}$ 是第 $j$ 个回答里到第 $i$ 个 token 为止的前缀，$N=\sum_{i=1}^{K} |y_i|$ 是一个 batch 里生成的 token 总数，$\bar{r}(x) = \frac{1}{K}\sum_{j=1}^K r(x, y_j)$ 是所有生成回答的平均奖励。

这个损失函数与 K1.5²⁰ 用的策略优化算法分道扬镳之处，是引入了一个 token 级的 clipping 机制，用来缓解被训练与推理框架之间差异放大的 off-policy 偏离。这个机制的作用相当于一个简单的梯度 masking 方案：log-ratio 落在区间 $[\alpha, \beta]$ 内的 token 正常算 policy gradient，落在区间外的 token 梯度置零。值得注意的是，与标准 PPO clipping²¹ 的一个关键区别是，我们的方法严格依赖 log-ratio 来显式地限住 off-policy drift，与 advantage 的符号无关。这个做法与近期为稳定大规模 RL 训练提出的策略一致²²²³。经验上，我们发现这个机制对于在需要长程、多步工具使用推理的复杂领域里维持训练稳定至关重要。我们用 MuonClip 优化器¹⁵¹⁶ 来最小化这个目标。

奖励函数。对有可验证解的任务，比如推理和 agentic 任务，我们施加基于规则的 outcome 奖励。为了优化资源消耗，我们还纳入一个 budget-control 奖励来提升 token 效率。对通用任务，我们用 Generative Reward Model（GRM）给出与 Kimi 内部价值准则对齐的细粒度评价。此外对视觉任务，我们设计了任务专用的奖励函数来提供细粒度监督。对视觉 grounding 和点定位任务，我们用带软匹配的 F1 奖励：grounding 任务的软匹配从 Intersection over Union（IoU）导出，点任务的软匹配在最优匹配下从高斯加权距离导出。对多边形分割任务，我们把预测的多边形栅格化成二值 mask，与 ground-truth mask 算分割 IoU 来赋奖励。对 OCR 任务，我们采用归一化编辑距离来量化预测与 ground-truth 之间的字符级对齐。对计数任务，奖励按预测与 ground-truth 的绝对差赋值。此外我们合成复杂的视觉谜题问题，用一个 LLM verifier（Kimi K2）来提供反馈。

Generative Reward Models。Kimi K2 对开放式生成使用一个 self-critique rubric 奖励¹³，K2.5 把这条线扩展下去，在广泛的 agentic 行为和多模态轨迹上系统性地部署 Generative Reward Model（GRM）。我们不把奖励建模局限在对话输出上，而是在多种环境里、在已验证的奖励信号之上施加 GRM，包括对话助手、coding agent、搜索 agent 和产物生成 agent。值得注意的是，GRM 不是二元的裁判，而是与 Kimi 价值观对齐的细粒度评价者，这些价值观对用户体验很关键，比如有用性、回答的就绪程度、上下文相关性、恰当的细节水平、生成产物的美观质量，以及严格遵循指令。这个设计让奖励信号能捕捉那些纯规则或任务专用 verifier 难以编码的细微偏好梯度。为了缓解 reward hacking 和对单一偏好信号的过拟合，我们采用多套针对不同任务语境定制的替代 GRM rubric。

Token 高效强化学习。对做 test-time scaling 的 LLM 来说，token 效率是核心。test-time scaling 本质上是用计算换推理质量，但要拿到实际收益，需要能主动在这个权衡里导航的算法创新。我们先前的发现表明，施加一个依题目而定的预算能有效约束推理时算力，激励模型生成更简洁的 chain of thought 推理模式、不做无谓的 token 膨胀²⁰¹³。然而我们也观察到一个 length-overfitting 现象：在刚性预算约束下训出来的模型往往无法泛化到更高的算力尺度。结果它们不能有效利用额外的推理时 token 去解复杂问题，反而退回到被截断的推理模式。

为此我们提出 Toggle，一个在推理时 scaling 与预算约束优化之间交替的训练启发式：对学习迭代 $t$，奖励函数定义为

其中 $\lambda$ 和 $m$ 是算法的超参数，$K$ 是每个问题的 rollout 数。具体来说，算法每 $m$ 次迭代在两个优化阶段之间交替：

• Phase0（预算受限阶段）：模型被训练在一个依任务而定的 token 预算内解题。为了防止过早地为效率牺牲质量，这个约束是有条件施加的：只在模型在给定问题上的平均准确率超过阈值 $\lambda$ 时才强制。
• Phase1（标准 scaling 阶段）：模型生成回答直到最大 token 上限，鼓励模型利用算力换取更好的推理时 scaling。

依题目而定的预算，由正确回答子集中 token 长度的第 $\rho$ 百分位估计得到：

这个预算在训练开始时估一次，之后保持固定。值得注意的是，Toggle 相当于一个双目标问题的随机交替优化。它专门被设计来调和推理能力与计算效率。

我们在 K2 Thinking⁶ 上评估 Toggle 的有效性。如 Figure 5 所示，我们观察到几乎所有 benchmark 上输出长度都一致下降。平均来看，Toggle 把输出 token 减少 25$\sim$30%，而对性能影响可以忽略。我们还观察到 chain-of-thought 里的冗余模式，比如重复验算和机械计算，大幅减少。此外 Toggle 展示出很强的领域泛化。举例来说，只在数学和编程任务上训练时，模型在 GPQA 和 MMLU-Pro 上仍然一致地减少 token，性能只有边际退化（Figure 5）。

4.5 训练基础设施

Kimi K2.5 基本原样继承 Kimi K2¹³ 的训练基础设施，只做很少改动。针对多模态训练，我们提出 Decoupled Encoder Process，把 vision encoder 以几乎可忽略的额外开销纳入现有流水线。

4.5.1 Decoupled Encoder Process（DEP）

在使用 Pipeline Parallelism（PP）的典型多模态训练范式里，vision encoder 和 text embedding 被放在流水线的第一级（Stage-0）。然而由于多模态输入尺寸本身的变化（比如图片数量和分辨率），Stage-0 在计算负载和内存占用两方面都剧烈波动。这迫使现有方案为视觉语言模型采用定制的 PP 配置——比如 Kimi-VL¹⁷ 手工调整 Stage-0 里 text decoder 层的数量来预留内存。这种妥协虽然缓解了内存压力，但没有从根本上解决多模态输入尺寸带来的负载不均衡。更关键的是，它排除了直接复用那些为纯文本训练高度优化过的并行策略的可能。

利用视觉 encoder 在计算图里的独特拓扑位置——具体说，它是 forward 的起点、backward 的终点——我们的训练采用 Decoupled Encoder Process（DEP），每个训练 step 由三个阶段组成：

• 均衡的视觉 forward：先为 global batch 里所有视觉数据执行 forward。因为 vision encoder 很小，我们不管其他并行策略如何，都把它复制到所有 GPU 上。这一阶段里，forward 的计算负载按负载指标（比如图片数或 patch 数）均匀分配到所有 GPU 上。这消除了 PP 和视觉 token 数带来的负载不均衡。为了把峰值内存压到最低，我们丢弃所有中间激活，只保留最终输出激活。结果被 gather 回 PP Stage-0；
• backbone 训练：这一阶段执行主 transformer backbone 的 forward 和 backward。由于前一阶段丢掉了中间激活，我们现在可以完全复用任何在纯文本训练中验证过的高效并行策略。这一阶段之后，梯度累积在视觉 encoder 的输出上；
• 视觉重算与 backward：重新计算 vision encoder 的 forward，接一次 backward 来算 vision encoder 参数的梯度；

DEP 不仅做到了负载均衡，还把 vision encoder 与主 backbone 的优化策略解耦了。K2.5 无缝继承了 K2 的并行策略，多模态训练效率达到纯文本训练的 90%。我们注意到一项同期工作 LongCat-Flash-Omni²⁴ 有相似的设计哲学。

5 评测

5.1 主要结果

5.1.1 评测设置

Benchmarks。我们在一套全面的 benchmark 上评测 Kimi K2.5，覆盖基于文本的推理、竞赛与 agentic coding、多模态理解（图像与视频）、自主 agentic 执行，以及 computer use。我们的 benchmark 分类按以下能力轴组织：

• 推理与通用：Humanity’s Last Exam（HLE）²⁵、AIME 2025²⁶、HMMT 2025（2 月）²⁷、IMO-AnswerBench²⁸、GPQA-Diamond²⁹、MMLU-Pro³⁰、SimpleQA Verified³¹、AdvancedIF³²、LongBench v2³³。
• Coding：SWE-Bench Verified³⁴、SWE-Bench Pro（public）³⁵、SWE-Bench Multilingual³⁴、Terminal Bench 2.0³⁶、PaperBench（CodeDev）³⁷、CyberGym³⁸、SciCode³⁹、OJBench（cpp）⁴⁰、LiveCodeBench（v6）⁴¹。
• Agentic 能力：BrowseComp⁴²、WideSearch⁴³、DeepSearchQA⁴⁴、FinSearchComp（T2&T3）⁴⁵、Seal-0⁴⁶、GDPVal⁴⁷。
• 图像理解：（数学与推理）MMMU-Pro⁴⁸、MMMU（val）⁴⁹、CharXiv（RQ）⁵⁰、MathVision⁵¹ 和 MathVista（mini）⁵²；（视觉知识）SimpleVQA⁵³ 和 WorldVQA⁵⁴；（感知）ZeroBench（带工具与不带工具）⁵⁵、BabyVision⁵⁶、BLINK⁵⁷ 和 MMVP⁵⁸；（OCR 与文档）OCRBench⁵⁹、OmniDocBench 1.5⁶⁰ 和 InfoVQA⁶¹。
• 视频理解：VideoMMMU⁶²、MMVU⁶³、MotionBench⁶⁴、Video-MME⁶⁵（带字幕）、LongVideoBench⁶⁶ 和 LVBench⁶⁷。
• Computer Use：OSWorld-Verified⁶⁸⁶⁹ 和 WebArena⁷⁰。

Table 4：Kimi K2.5 与开源、闭源模型的性能对比。粗体表示全局 SOTA；标 * 的数据点来自我们的内部评测。† 指它们纯文本子集上的分数。

译注：原表里 GPT-5.2 的 BrowseComp 分数 65.8 用 \multirow 跨了「BrowseComp」和「BrowseComp (w/ ctx manage)」两行，markdown 表没有跨行，这里在两行都填了 65.8。

Table 5：部分推理模型的性能与 token 效率。括号里是平均输出 token 数（千为单位）。

Baselines。我们与最先进的闭源和开源模型对比。闭源方面，我们对比 Claude Opus 4.5（开 extended thinking）⁴、GPT-5.2（xhigh reasoning effort）³ 和 Gemini 3 Pro（high reasoning-level）⁵。开源方面，文本 benchmark 我们纳入 DeepSeek-V3.2（开 thinking 模式）⁷¹，而视觉 benchmark 改为汇报 Qwen3-VL-235B-A22B-Thinking⁷。

评测配置。除特别说明外，所有 Kimi K2.5 的评测都用 temperature = 1.0、top-p = 0.95、上下文长度 256k token。没有公开分数的 benchmark 在相同条件下重新评测，并标星号（*）。完整评测设置见附录 E。

5.1.2 评测结果

Kimi K2.5 与闭源、开源 baseline 的全面对比结果见 Table 4。我们把核心能力域上的关键观察列出来：

推理与通用。Kimi K2.5 在严苛的 STEM benchmark 上与顶级闭源模型有竞争力。数学任务上，AIME 2025 K2.5 拿到 96.1%，逼近 GPT-5.2 的满分，同时超过 Claude Opus 4.5（92.8%）和 Gemini 3 Pro（95.0%）。这个高水位延伸到 HMMT 2025（95.4%）和 IMO-AnswerBench（81.8%），显示 K2.5 更好的推理深度。Kimi K2.5 也表现出出色的知识与科学推理能力，SimpleQA Verified 36.9%、MMLU-Pro 87.1%、GPQA 87.6%。值得注意的是，不用工具的 HLE 上 K2.5 的 HLE-Full 分数是 30.1%，分项是文本子集 31.5%、图像子集 21.3%。启用工具后，K2.5 的 HLE-Full 升到 50.2%，分项 51.8%（文本）和 39.8%（图像），显著超过 Gemini 3 Pro（45.8%）和 GPT-5.2（45.5%）。除推理和知识之外，K2.5 展示出很强的 instruction-following 表现（AdvancedIF 75.6%）和有竞争力的长上下文能力，LongBench v2 拿到 61.0%，与闭源、开源模型相比都有竞争力。

复杂 coding 与软件工程。Kimi K2.5 展示出很强的软件工程能力，尤其在真实的编码和维护任务上。它在 SWE-Bench Verified 上拿到 76.8%、SWE-Bench Multilingual 上 73.0%，超过 Gemini 3 Pro，同时与 Claude Opus 4.5 和 GPT-5.2 保持竞争力。LiveCodeBench v6 上 Kimi K2.5 达到 85.0%，超过 DeepSeek-V3.2（83.3%）和 Claude Opus 4.5（82.2%），凸显了它在实时、持续更新的编码挑战上的稳健性。TerminalBench 2.0、PaperBench 和 SciCode 上分别拿到 50.8%、63.5% 和 48.7%，在自动化软件工程和跨领域问题求解上展示出稳定的竞赛级表现。此外 K2.5 在 CyberGym 上取得 41.3 分——这个任务是只给一段高层的弱点描述，就要在真实开源软件项目里找出先前已被发现的漏洞——进一步印证了它在安全导向的软件分析上的有效性。

Agentic 能力。Kimi K2.5 在复杂的 agentic 搜索与浏览任务上确立了新的 state-of-the-art。BrowseComp 上，K2.5 不用上下文管理技术拿到 60.6%，用 Discard-all 上下文管理⁷¹ 拿到 74.9%——大幅超过 GPT-5.2 汇报的 65.8%、Claude Opus 4.5（37.0%）和 Gemini 3 Pro（37.8%）。同样地，WideSearch 的 item-f1 达到 72.7%。DeepSearchQA（77.1%）、FinSearchCompT2&T3（67.8%）和 Seal-0（57.4%）上 K2.5 领先所有被评测的模型，显示出在 agentic 深度调研、信息综合和多步工具编排上更强的能力。

视觉推理、知识与感知。Kimi K2.5 展示出很强的视觉推理与世界知识能力。它在跨多学科多模态任务的 MMMU-Pro 上拿到 78.5%。世界知识问答方面，K2.5 在 SimpleVQA 上 71.2%、WorldVQA 上 46.3%。视觉推理方面，MathVision 84.2%、MathVista（mini）90.1%、BabyVision 36.5%。OCR 与文档理解方面，K2.5 交出出色的结果：CharXiv（RQ）77.5%、OCRBench 92.3%、OmniDocBench 1.5 88.8%、InfoVQA（test）92.6%。在很难的 ZeroBench 上，Kimi K2.5 拿到 9%、带工具增强 11%，明显领先竞品。基础视觉感知 benchmark BLINK（78.9%）和 MMVP（87.0%）上我们也看到 Kimi K2.5 有竞争力的表现，显示了它稳健的真实世界视觉感知。

视频理解。Kimi K2.5 在多样的视频理解任务上达到 state-of-the-art。它在 VideoMMMU 上拿到 86.6%、MMVU 上 80.4%，与前沿水位并驾齐驱。凭 MoonViT-3D 的上下文压缩和密集时间理解能力，Kimi K2.5 在长视频理解上也确立了新的全球 SOTA 记录：喂进两千多帧，LVBench 75.9%、LongVideoBench 79.8%，同时在高维的 MotionBench 上以 70.4% 展示出稳健的密集运动理解。

Computer-Use 能力。Kimi K2.5 在真实任务上展示出 state-of-the-art 的 computer-use 能力。在 computer-use benchmark OSWorld-Verified⁶⁸⁶⁹ 上，它只靠 GUI 动作、不用外部工具就取得 63.3% 的成功率。这大幅超过 Qwen3-VL-235B-A22B（38.1%）这类开源模型，以及 OpenAI 的 computer-use agent 框架 Operator（基于 o3）（42.9%），同时与当前领先的 CUA 模型 Claude Opus 4.5（66.3%）保持竞争力。在基于 GUI 的网页浏览老 benchmark WebArena⁷⁰ 上，Kimi K2.5 取得 58.9% 的成功率，超过 OpenAI 的 Operator（58.1%）、逼近 Claude Opus 4.5（63.4%）的水平。

5.2 Agent Swarm 结果

Benchmarks。为了严格评估 agent swarm 框架的有效性，我们选了三个有代表性的 benchmark，合起来覆盖深度推理、大规模检索和真实世界复杂度：

• BrowseComp：一个很有挑战的深度调研 benchmark，要求多步推理和复杂的信息综合。
• WideSearch：一个用来评估在多样来源上做广泛、多步信息搜寻与推理能力的 benchmark。
• 内部 Swarm Bench：我们内部开发的 Swarm benchmark，用来在真实世界的高复杂度条件下评估 agent swarm 表现。它覆盖四个领域：WildSearch（在开放 web 上做无约束的真实信息检索）、Batch Download（大规模获取多样资源）、WideRead（涉及 100 份以上输入文档的大规模文档理解）和 Long-Form Writing（连贯生成超过 10 万字的长内容）。这个 benchmark 纳入了极端规模的场景，压力测试 agent 系统的编排、可扩展性和协调能力。

Table 6：Kimi K2.5 Agent Swarm 与单 agent、闭源 baseline 在 agentic 搜索 benchmark 上的性能对比。粗体表示每个 benchmark 上的最好结果。

性能。Table 6 给出 Kimi K2.5 Agent Swarm 相对单 agent 配置和闭源 baseline 的表现。结果显示多 agent 编排带来实质性的性能提升。BrowseComp 上 Agent Swarm 拿到 78.4%，相比单 agent 的 K2.5（60.6%）绝对提升 17.8%，甚至超过 GPT-5.2 Pro（77.9%）。同样地，WideSearch 的 Item-F1 提升 6.3%（72.7% $\to$ 79.0%），让 K2.5 Agent Swarm 超过 Claude Opus 4.5（76.2%）、确立新的 state-of-the-art。收益在内部 Swarm bench 上最为显著（16.7%），那里的任务是被明确设计来奖励并行分解的。这些跨 benchmark 的一致提升印证了 Agent Swarm 能把计算并行度有效转化为质的能力提升，对那些需要广泛探索、多源验证或同时处理独立子任务的问题尤其如此。

并行带来的执行时间节省。除了任务表现的提升，Agent Swarm 还通过并行 subagent 执行取得可观的 wall-clock 时间削减。在 WideSearch benchmark 上，它把达到目标性能所需的执行时间相比单 agent baseline 降低 3$\times\sim$4.5$\times$。如 Figure 8 所示，这个效率收益随任务复杂度放大：当目标 Item-F1 从 30% 升到 70%，单 agent 的执行时间从约 $1.8\times$ 涨到 $7.0\times$ 以上 baseline，而 Agent Swarm 维持在 $0.6\times\sim 1.6\times$ 这个近乎恒定的低延迟区间。这些结果表明 Agent Swarm 有效地把串行的工具调用转化成并行操作，避免了任务难度上升时通常会看到的完成时间线性增长。

动态 subagent 创建与调度。在一个 agent swarm 内部，subagent 是动态实例化而非事先定义的。通过 PARL，orchestrator 学出自适应的策略，随任务结构和问题状态的演变来创建和调度自托管的 subagent。与静态分解方法不同，这个学出来的 policy 让 Orchestrator 能根据查询去推断所需 subagent 的数量、时机和专精方向。于是一个异质的 agent 群体从这种自适应分配策略中自然涌现出来（Figure 7）。

Agent Swarm 作为主动上下文管理。除了更好的表现和运行时加速，agent swarm 还是一种由多 agent 架构带来的主动、智能的上下文管理¹¹。这个思路不同于 test-time 的上下文截断策略，比如 Hide-Tool-Result¹⁰、Summary⁷² 或 Discard-all⁷¹——那些策略是在上下文溢出时才通过压缩或丢弃累积历史来反应。它们在减少 token 用量上有效，但本质上是被动的，往往牺牲结构信息或中间推理。

相比之下，Agent Swarm 通过显式编排实现主动的上下文控制。长程任务被分解成并行的、语义上相互隔离的子任务，每个由一个专精 subagent 在有界的局部上下文里执行。关键的是，这些 subagent 维护各自独立的工作记忆、在本地做推理，不会直接改动或污染中央 orchestrator 的全局上下文。只有与任务相关的输出——而不是完整的交互轨迹——才被选择性地路由回 orchestrator。这个设计带来的是上下文分片而非上下文截断，让系统能沿着一个额外的架构维度扩展有效上下文长度，同时保住模块化、信息的局部性和推理的完整性。

如 Figure 7 所示，这个主动策略在 BrowseComp 上于效率和准确率两方面都优于 Discard-all。通过在 orchestrator 层面保住任务级的连贯性、同时把 subagent 的上下文严格框住，Agent Swarm 实现了带选择性上下文留存的并行执行，只保留高层协调信号或必要的中间结果。于是 Agent Swarm 是一个主动的、结构化的上下文管理者，用比统一上下文截断少得多的 critical steps 取得了更高的准确率。

6 结论

Kimi K2.5 表明，可扩展的通用 agentic 智能可以通过文本与视觉的联合优化加上并行 agent 执行来达成。通过在预训练和强化学习中统一语言与视觉，模型取得了很强的跨模态对齐和视觉—文本推理能力。Agent Swarm 让异质子任务能并发执行，在降低推理延迟的同时提升了复杂 agentic 工作负载上的表现。立在视觉—文本智能和 agent swarm 之上，Kimi K2.5 在 benchmark 和真实任务上都表现很强。通过开源后训练好的 checkpoint，我们希望支持开源社区构建可扩展的通用 agentic 系统，加速朝通用 agentic 智能的进展。

附录 B 预训练

B.1 联合训练

我们在 Figure 9 里进一步给出所有配置的完整训练曲线。值得注意的是，我们在 mid-fusion 和 late-fusion 阶段的文本表现上观察到一个「dip-and-recover」模式：视觉数据刚被引入时，文本能力先退化，然后逐渐恢复。我们把这归因于模态的 domain shift——视觉 token 的突然引入打乱了已经建立起来的语言表示空间，迫使模型暂时牺牲文本专项能力去换跨模态对齐。

相比之下，early fusion 在整个训练过程中维持了一条更健康、更稳定的文本表现曲线。从一开始就联合优化视觉与语言，模型自然地演化出统一的多模态表示，不必经历后期 domain 迁移带来的冲击。这说明早期暴露不仅避免了 late fusion 里观察到的表示塌缩，还为两个模态都带来更平滑的梯度地形。合起来看，这些发现强化了我们对原生多模态预训练的主张：在固定 token 预算下，适中的视觉比例配上 early fusion 给出更优的收敛性质和更稳健的双模态能力。

B.2 文本数据

Kimi K2.5 的预训练文本语料由精挑的高质量数据构成，跨四个主要领域：Web Text、Code、Mathematics 和 Knowledge。大多数数据处理流水线沿用 Kimi K2¹³ 里列出的方法。对每个领域，我们都做了严格的正确性与质量校验，并设计了有针对性的数据实验，确保精挑出来的数据集在多样性和有效性两方面都达标。

增强的代码智能。我们加重了以代码为中心的数据的权重，显著扩充了：（1）支持跨文件推理和架构理解的仓库级代码，（2）来自互联网的 issue、code review 和 commit 历史，它们捕捉真实的开发模式，（3）从 PDF 和 webtext 语料中检索出的代码相关文档。这些工作强化了复杂编码任务所需的仓库级理解力，提升了补丁生成、单测编写这类 agentic coding 子任务上的表现，也增强了代码相关的知识能力。

B.3 视觉数据

我们的多模态预训练语料包含七类：caption、interleaving、OCR、knowledge、perception、video 和 agent 数据。caption 数据⁷³⁷⁴ 提供基础的模态对齐，其中对合成 caption 有严格限额以缓解幻觉。来自书籍、网页和教程的图文交错数据⁷⁵⁷⁶ 使多图理解和更长上下文的学习成为可能。OCR 数据跨多语言文本、密集版式和多页文档。knowledge 数据纳入了经版式解析器处理过的学术材料，用来培养视觉推理能力。

此外我们精心构建了一份专门的多模态问题求解语料，以强化 Science、Technology、Engineering、Mathematics 领域内的推理。这份数据通过定向检索和网页爬取汇集而成；对那些缺少显式提问格式的信息型内容，我们用 in-context learning⁷⁷ 自动把原始材料重写成结构化的学术题目，覆盖 K-12 到大学各个层级。为了弥合视觉版式与代码数据之间的模态鸿沟，我们纳入了大量图-代码配对数据。这包括多种代码格式——比如 HTML、React、SVG 等等——与它们对应的渲染截图配成对，让模型能把抽象的结构逻辑与具体的视觉几何对齐。

面向 agentic 与时序理解，我们采集了桌面、移动端和 web 环境下的 GUI 截图与动作轨迹，包括人工标注的演示。来自多样来源的视频数据同时支撑小时级的长视频理解和细粒度的时空感知。此外我们纳入 grounding 数据来增强细粒度视觉定位，包括感知标注（bounding box）和基于点的引用。我们还引入一个新的轮廓级分割任务⁷⁸ 来做像素级感知的学习。所有数据都经过严格的过滤、去重和质量控制，以保证高多样性与有效性。

附录 C Infra

Kimi K2.5 在 NVIDIA H800 GPU 集群上训练，节点间是 8 × 400 Gbps 的 RoCE 互联。我们采用一套灵活的并行策略，把 16 路带 virtual stage 的 Pipeline Parallelism（PP）⁷⁹⁸⁰、16 路 Expert Parallelism（EP）⁸¹ 与 ZeRO-1 Data Parallelism 组合起来，从而能在任意 32 的倍数个节点上训练。EP 的 all-to-all 通信在 interleaved 1F1B 调度下与计算 overlap。为了把激活塞进 GPU 内存限额，我们对 LayerNorm、 SwiGLU 和 MLA up-projection 做选择性重算，把不敏感的激活压到 FP8-E4M3，并把剩余激活以 overlap 的流式方式 offload 到 CPU。

C.1 数据存储与加载

我们用云厂商提供的 S3⁸² 兼容对象存储来存放 VLM 数据集。为了弥合数据准备与模型训练之间的落差，我们把视觉数据保留为原生格式，并搭建了一套高效、适应性强的数据加载基础设施。这套设施提供以下几个关键优势：

• 灵活性：支持训练过程中动态的数据 shuffle、混合、tokenize、loss mask 和 sequence packing，使数据比例能随需求演变而调整；
• 增强：允许对视觉和文本两个模态做随机增强，同时在几何变换过程中保持 2D 空间坐标和朝向元数据的完整性；
• 确定性：通过对随机种子和 worker 状态的细致管理保证完全确定性的训练，使任何训练中断都能无缝恢复——恢复之后的数据序列与未中断的运行完全一致；
• 可扩展性：通过分层缓存机制取得优越的数据加载吞吐，稳健地扩展到大型分布式集群，同时把对对象存储的请求频率控制在可接受范围内。

此外，为了维持统一的数据集质量标准，我们搭建了一个统一平台，统管数据注册、可视化、统计分析、跨云同步和生命周期治理。

附录 D 统一 agentic 强化学习环境

Environment。为支持统一的 Agentic RL，我们的 RL 框架提供一套标准化的、Gym 风格⁸³ 的接口，以简化各类环境的实现。这个设计让用户能以最小的开销实现和定制环境。我们的设计通过集成一组可插拔组件来优先保证组合式的模块化，比如一个支持各种带沙箱工具的 Toolset 模块、一个给出多面奖励信号的 Judge 模块，以及若干做 prompt 多样化和 instruction-following 增强的专门模块。这些组件可以与核心 agent 循环动态组合，提供高度灵活性、增强模型泛化。

在执行层面，我们的 RL 框架把每个 agent 任务当成一个独立的异步协程。每个任务都能递归触发子任务的 rollout，简化了 Parallel-Agent RL 和 Agent-as-Judge 这类复杂多 agent 范式的实现。如 Figure 10 所示，一个专门的 Rollout Manager 在 RL 过程中编排最多 100,000 个并发 agent 任务，提供细粒度控制以支撑 partial rollout²⁰ 这类特性。激活时，每个任务从一个受管池里取一个环境实例，配上沙箱和专门工具。

推理引擎协同设计。我们的框架严格遵循 Token-in-Token-out 范式。我们还记录推理引擎所有输出的 log probability 来做 训练-推理 mismatch 校正，确保 RL 训练稳定。围绕 RL 需求对推理引擎做协同设计，让我们能通过为 RL 定制的推理 API 支持这些特性。

除了一整套内建的白盒环境之外，也存在只能在标准 LLM API 协议下运行的黑盒环境，它们无法用上我们自定义 API 协议提供的高级特性。为了便于在黑盒环境下做模型优化，我们开发了 LLM Gateway，这是一个代理服务，它在我们的自定义协议下详细记录 rollout 的请求与响应。

监控与调试。要在保证正确性的同时优化一个高度并行的异步执行系统的性能，是件有挑战的事。我们开发了一系列做性能监控、profiling、数据可视化和数据校验的工具。我们发现它们对调试、以及对保证 Agentic RL 的效率与正确性都很关键。

附录 E 评测设置

这一节给出 Table 4 中所汇报的所有 benchmark 的完整配置细节与测试协议。

E.1 通用评测协议

除明确说明外，Kimi-K2.5 的所有实验都遵循以下超参数配置：

• Temperature：1.0
• Top-p：0.95
• 上下文长度：256k token

E.2 Baselines

对 baseline 模型，我们汇报它们各自高性能推理配置下的结果：

• Claude Opus 4.5：Extended thinking 模式
• GPT-5.2：最大 reasoning effort（xhigh）
• Gemini 3 Pro：High thinking level
• DeepSeek-V3.2：开启 thinking 模式（仅纯文本 benchmark）
• Qwen3-VL-235B-A22B：Thinking 模式（仅视觉 benchmark）

对视觉与多模态 benchmark，GPT-5.2-xhigh 在视觉评测过程中表现出约 10% 的失败率（即重试三次后仍无输出）。这些失败被当作错误预测处理，也就是说汇报的分数可能是该模型真实能力的保守下界。

此外，由于我们无法稳定访问 GPT-5.2 API，我们跳过了一些评测成本很高的 benchmark，比如 WideSearch。

E.3 文本 Benchmark

推理 benchmark。对高复杂度的推理 benchmark，包括 HLE-Full、AIME 2025、HMMT 2025、GPQA-Diamond 和 IMO-AnswerBench，我们施加 96k token 的最大生成预算以保证足够的推理深度。为降低随机推理路径带来的方差，AIME 2025 和 HMMT 2025（2 月）的结果取 64 次独立运行的平均（Avg@64），GPQA-Diamond 取 8 次运行的平均（Avg@8）。

LongBench v2。为保证比较公平，我们用与 LongBench v2³³ 相同的截断策略把所有输入上下文统一到约 128k token。我们观察到 GPT5.2-xhigh 经常给出自由形式的问答式回答，而不是要求的多选格式。因此我们汇报 GPT5.2-high 的结果，它能稳定遵循预期的输出格式。

E.4 图像与视频 Benchmark

所有图像与视频理解评测采用以下配置：

• 最大 token 数：64k
• 采样：取 3 次独立运行的平均（Avg@3）

ZeroBench（带工具）。多步推理评测使用受约束的逐步生成：

• 每步最大 token 数：24k
• 最大步数：30

MMMU-Pro。我们严格遵循官方评测协议：所有模态保持输入顺序，图像按 benchmark 指南所规定前置于文本序列。

视频 benchmark 的采样策略。对短视频 benchmark（VideoMMMU、MMVU 和 MotionBench），我们均匀采样 128 帧输入、最大空间分辨率 896；长视频 benchmark（Video-MME、LongVideoBench 和 LVBench）均匀采样 2048 帧、空间分辨率 448。

专门指标。

• OmniDocBench 1.5：分数按 $(1-\text{normalized Levenshtein distance})\times 100$ 计算，值越高表示 OCR 与文档理解越准。
• WorldVQA：可从 https://github.com/MoonshotAI/WorldVQA 获取⁵⁴。这个 benchmark 评测原子的、以视觉为中心的世界知识，需要细粒度视觉识别和地理理解。

E.5 Coding 与软件工程

Terminal Bench 2.0。所有分数都用默认的 Terminus-2 agent 框架加它提供的 JSON parser 得到。值得注意的是我们在 non-thinking 模式下评测，因为我们当前为 thinking 模式实现的上下文管理与 Terminus-2 的对话状态处理在技术上不兼容。

SWE-Bench 系列。我们使用一套内部开发的评测框架，工具集很小：bash、create_file、insert、view、str_replace 和 submit。system prompt 是专门为仓库级代码操作定制的。所有 SWE-Bench 变体（Verified、Multilingual 和 Pro）上，峰值表现都是在 non-thinking 模式下取得的。

CyberGym。这个 benchmark 上 Claude Opus 4.5 的结果按其技术文档所指定，在 non-thinking 设置下汇报。我们汇报难度等级 1（主设置）下的分数。

PaperBench。我们汇报 CodeDev 设置下的分数。

采样。所有 coding 任务结果取 5 次独立运行的平均（Avg@5），以保证跨环境初始化和非确定性测试用例顺序的稳定性。

E.6 Agentic 评测

工具设置。所有 agentic 评测中，Kimi-K2.5 都配备 web 搜索工具、code interpreter（Python 执行环境）和 web 浏览工具，包括带工具的 HLE 以及 agentic 搜索 benchmark（BrowseComp、WideSearch、DeepSearchQA、FinSearchComp T2&T3 和 Seal-0）。

上下文管理策略。为应对复杂 agentic 任务固有的超长轨迹，我们实现了领域专用的上下文管理协议。除下面特别说明外，agentic 评测不施加任何上下文管理；超出模型支持上下文窗口的任务直接计为失败，而不做截断。

• Humanity’s Last Exam（HLE）。HLE 带工具设置下我们采用 Hide-Tool-Result 上下文管理策略：当上下文长度超过预定阈值时，只保留最近一轮的工具消息（observation 与返回值），而之前所有步骤的推理链与思考过程都完整保留。
• BrowseComp。BrowseComp 评测里我们同时给出带与不带上下文管理两种设置。带上下文管理的设置下，我们采用 DeepSeek 提出的同一套 discard-all 策略，即一旦超过 token 阈值就把所有历史截掉。

System Prompt。所有 agentic 搜索与 HLE 评测使用下面这个统一的 system prompt，其中 DATE 动态设为当前时间戳：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

You are Kimi, today's date: DATE.
Your task is to help the user with their questions by using various tools,
thinking deeply, and ultimately answering the user's questions.

Please follow the following principles strictly during the deep research:
1. Always focus on the user's original question during the research process,
   avoiding deviating from the topic.
2. When facing uncertain information, use search tools to confirm.
3. When searching, filter high-trust sources (such as authoritative websites,
   academic databases, and professional media) and maintain a critical mindset
   towards low-trust sources.
4. When performing numerical calculations, prioritize using programming tools
   to ensure accuracy.
5. Please use the format [^index^] to cite any information you use.
6. This is a **Very Difficult** problem, do not underestimate it. You must use
   tools to help your reasoning and then solve the problem.
7. Before you finally give your answer, please recall what the question is
   asking for.

采样协议。为计入搜索引擎结果排序的固有随机性和网页内容的动态可得性，Seal-0 和 WideSearch 的结果取 4 次独立运行的平均（Avg@4）。除明确说明外，其他所有 agentic benchmark 都在单次运行协议下评测。

E.7 Computer-Use 评测

超参数设置。所有实验我们设 max_steps_per_episode $=100$，OSWorld-Verified 用 temperature $=0$、WebArena 用 temperature $=0.1$。受资源限制，所有模型都在 one-shot 设置下评测。遵循 OpenCUA 的配置⁸⁴，agent 上下文包含最近 3 张历史图像、完整的思考历史和任务指令。对 WebArena，我们手工修正了评测脚本里的错误，并用 GPT-4o 作为 fuzzy_match 函数的 judge 模型。为保证比较公平，Claude Opus 4.5 只配 computer-use 工具评测（不含浏览器工具），这与其 System Card 的配置⁴ 不同。

System Prompt。所有 computer use 任务我们使用一个统一的 system prompt：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

You are a GUI agent. You are given an instruction, a screenshot of the screen and your
previous interactions with the computer. You need to perform a series of actions to
complete the task. The password of the computer is {password}.

For each step, provide your response in this format:
{thought}
## Action:
{action}
## Code:
{code}

In the code section, the code should be either pyautogui code or one of the following
functions wrapped in the code block:
- {"name": "computer.wait", "description": "Make the computer wait for 20 seconds
for installation, running code, etc.", "parameters": {"type": "object", "properties":
{}, "required": []}}
- {"name": "computer.terminate", "description": "Terminate the current task and report
its completion status", "parameters": {"type": "object", "properties": {"status":
{"type": "string", "enum": ["success", "failure"], "description": "The status of the
task"}, "answer": {"type": "string", "description": "The answer of the task"}},
"required": ["status"]}}

E.8 Agent Swarm 配置

工具设置。除了附录 E.6 描述的核心工具集（web 搜索、code interpreter 和 web 浏览）之外，orchestrator 还配备两个专门用于 sub-agent 创建与调度的工具：

• create_subagent：用自定义的 system prompt 和标识符实例化一个专精 sub-agent，以便跨任务复用。
• assign_task：把任务派发给已创建的 sub-agent。

工具 schema 如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

{
 "name": "create_subagent",
 "description": "Create a custom subagent with specific system prompt
   and name for reuse.",
 "parameters": {
   "type": "object",
   "properties": {
     "name": {
       "type": "string",
       "description": "Unique name for this agent configuration"
     },
     "system_prompt": {
       "type": "string",
       "description": "System prompt defining the agent's role,
         capabilities, and boundaries"
     }
   },
   "required": ["name", "system_prompt"]
 }
}
{
 "name": "assign_task",
 "description": "Launch a new agent.\nUsage notes:\n
   1. You can launch multiple agents concurrently whenever possible,
      to maximize performance;\n
   2. When the agent is done, it will return a single message back to you.",
 "parameters": {
   "type": "object",
   "properties": {
     "agent": {
       "type": "string",
       "description": "Specify which created agent to use."
     },
     "prompt": {
       "type": "string",
       "description": "The task for the agent to perform"
     }
   },
   "required": ["agent", "prompt"]
 }
}

步数上限。在 Agent Swarm 模式下运行时，我们给 orchestrator 和 sub-agent 都设算力预算。步数上限作用于工具调用与环境交互的总次数。

• BrowseComp：orchestrator 最多 15 步。每个派生出来的 sub-agent 在 100 步上限下运行（即每个 sub-agent 最多 100 次工具调用）。
• WideSearch：orchestrator 和每个 sub-agent 各分配最多 100 步的预算。
• 内部 Bench：orchestrator 最多 100 步。每个派生出来的 sub-agent 在 50 步上限下运行。

System Prompt。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

You are Kimi, a professional and meticulous expert in information collection and organization.
You fully understand user needs, skillfully use various tools, and complete tasks with the
highest efficiency.
# Task Description
After receiving users' questions, you need to fully understand their needs and think
about and plan how to complete the tasks efficiently and quickly.
# Available Tools
To help you complete tasks better and faster, I have provided you with the following tools:
1. Search tool: You can use the search engine to retrieve information, supporting multiple
queries in parallel.
2. Browser tools: You can visit web links (web pages, PDFs, etc.), get page content, and
perform interactions such as clicking, inputting, finding, and scrolling.
3. Sub Agent tools:
   - `create_subagent`: Create a new sub-agent with a unique name and clear, specific
   system prompt.
   - `assign_task`: Delegate tasks to created sub-agents. Sub-agents can also use search
   and browser tools.
4. Other tools: Including code execution (IPython, Shell).

E.9 GDPVal

我们引用 Artificial Analysis 的 GDPVal-AA 评测，Table 4 中汇报的分数反映的是截至 2026 年 1 月 28 日的官方榜单指标。

Figure 11 的补充材料：生成的网页 与原始视频（版权归原作者所有）。

附录 F 可视化

Figure 11 展示我们的 Agent Swarm 攻克一个有挑战的长视频理解任务：分析《黑神话：悟空》的完整流程（32 个视频、24 小时连续游玩，总计 40GB）。系统采用一个分层多 agent 架构，其中 Main Agent 编排并行的 Sub Agent 各自独立处理单个视频片段。每个 sub agent 执行抽帧、时序事件分析和关键时刻识别（比如 boss 战、升级）。Main Agent 随后把这些分布式分析汇总起来，合成一份完整的 HTML 展示，含通关时间线、嵌入的视频片段和交互式可视化。这个例子展示了系统通过并行化处理超大规模多模态内容、同时维持连贯长上下文理解的能力。

Figure 12 给出 Kimi K2.5 通过工具增强推理求解多样视觉推理任务的定性示例。模型展示了：（1）迷宫求解——处理二值图像分割并实现寻路算法（BFS）来穿越复杂迷宫；（2）饼图分析——执行像素级颜色分割和几何计算来确定精确的面积占比；（3）找不同——运用计算机视觉技术检测图像对之间的像素级差异。这些例子凸显了模型把复杂视觉问题分解成可执行代码、依据中间结果迭代改进策略、并通过定量视觉分析综合出精确答案的能力。