文章对月之暗面发布的 Kimi K2.5 模型及 Kimi Code 进行了为期 48 小时的深度实测。内容涵盖了从环境配置到多维度实战演练：首先通过视频录制成功复刻了复杂的网页 UI 与交互逻辑，展示了模型极强的多模态理解力；其次在真实开源项目维护中，验证了其在文档整理、增量开发及单元测试生成方面的工程提效能力；最后，文章深入解析了 Kimi 的 Agent 集群（蜂群）运作机制，揭示了其在任务规划、并行执行及异常处理上的工程化设计。作者认为 K2.5 是目前实战能力最强的国产开源原生多模态模型之一。
原创 筱可 2026-01-30 22:02 浙江
Datawhale干货
作者：筱可，Datawhale成员
最近 Claude 凭借 Computer Use 等一系列骚操作确实赚足了眼球，也让大家看到了差距。
这也让人想起 Anthropic CEO Dario 之前那句有点扎心的话——他说中国模型主要是在刷榜，实际推理和应用能力跟顶尖模型还有距离。
但月之暗面创始人杨植麟亲自发布的 Kimi K2.5，或许算是一次脚踏实地的追赶。
为什么关注：开源界的实力派
如果你问我 Kimi K2.5 的实际体验到底在一个什么水平？
在我充分体验了 Kimi Code + K2.5 的组合后，最直观的感觉是：它像是一个开源版的 Gemini 3 Pro 与 Claude Sonnet 4.5 的结合体。
先说差距。从官方放出的 SWE-bench 代码评测来看，Claude Opus 4.5 依然稳坐头把交椅。那种处理复杂架构的细腻度，目前的国产模型确实还有一段路要走。Kimi K2.5 在纯代码生成上虽然挤进了第一梯队，但距离最强仍有肉眼可见的空间。
但在实战层面，它给出了惊喜。虽然代码能力没能登顶，但 Kimi K2.5 在 Agents 调度和视频理解等实战指标上，不仅咬住了比分，甚至在部分项目上实现了反超。
而这些判断，也得到了第三方权威榜单的验证。
先看 OpenRouter 的实际使用数据。OpenRouter 是一个聚合了多家 AI 模型的平台，它的排行榜基于真实用户的调用量，能直观反映模型在实际应用中的受欢迎程度。
从最新的日榜数据来看，Kimi K2.5 以 69.9B tokens 的调用量位居第 3，仅次于 Claude Sonnet 4.5 和 Gemini 3 Flash Preview，而且增长率达到了 13%，是前十名中增速最快的模型之一。
再看大模型竞技场 LMArena 的评测数据。最新放榜显示，Kimi K2.5 代码能力位居全球开源第一，总榜前三，仅次于 Claude 和 Gemini。
Artificial Analysis 的排名更是直接将 K2.5 列为全球开源第一，总排名第 5。
不得不感慨，这可能是我目前测试过最强的国内开源原生多模态大模型。
但真正让我震撼的，不是单纯的代码生成。
而是它带来的一种全新的编程交互方式——直接用视频作为编程指令的输入。这在以前是我从未体验过的。
一、保姆教程：Kimi Code + K2.5
咱们先把环境搭起来。
1. 安装Kimi Code
运行安装脚本即可完成安装。脚本会先安装 uv（Python 包管理工具），再通过 uv 安装 Kimi Code：
# Linux / macOScurl -LsSf https://cdn.kimi.com/binaries/kimi-cli/install.sh | bash
# Windows (PowerShell)Invoke-RestMethod https://cdn.kimi.com/binaries/kimi-cli/install.ps1 | Invoke-Expression
验证安装是否成功：
kimi --version安装成功会显示
2. 配置 Kimi Code
官网地址：前往https://www.kimi.com/code，获取API KEY
截止发稿前，发现 Kimi 官方也非常听劝，包月套餐把用量提升了，能够全速体验 Kimi K2.5 并正式切换为基于 Token 计费。
随后，在命令行输入 kimi 启动，输入 /login 登录即可使用。
二、实测：视频驱动的页面复刻
难度1：复刻 Kimi Chat 页面
第一个测试，我想验证 K2.5 基于视频理解交互样式的能力边界。
操作很简单：录制一段使用 Kimi Chat 的操作视频，直接上传给 Kimi Code，附带一句提示词——“复刻这段视频的页面内容及交互效果”。
原版 Kimi Chat 页面
复刻版Kimi Chat 页面
几分钟后，生成的页面确实让我眼前一亮。
Thinking 模块的展开折叠、对话气泡的生成动画、侧边栏弹出的时机节点，全部还原。除了一些细小的图标，以及颜色存在微小偏差，整体布局结构与原版几乎一致。如果第一眼看到的时候甚至会以为真的是 Kimi 的对话页面。
这种复刻精度，超出了我的预期。只要视频内有提到的交互样式，基本上都能在复刻的版本里面体现出来。这个例子还没有测试到它的上限。
难度2：复刻 Kimi 主页
第二个测试，我选择了 Kimi 的主页。
选择主页的原因很明确：Kimi 产品的 UI 设计和交互逻辑一直保持着较高的审美水准，属于设计师级别的呈现。我想看看 K2.5 能否从视频中捕捉到并复刻出他们团队的设计美学。
原版 Kimi 主页
复刻版 Kimi 主页
从结果上来看，复刻效果基本上达到了像素级的视觉还原，中英文切换的交互逻辑也完整保留。
这说明一个问题：通过融合视觉能力，K2.5 实质性地降低了编程门槛。
你不需要理解 CSS 的布局参数，不需要掌握 flexbox 和 grid 的差异，只需要提供一个参考视频。模型会自动解析视频中的视觉元素、交互逻辑和设计细节，然后生成对应的代码实现。
这种能力的本质，是将“视觉理解”和“代码生成”两个环节打通了。
难度3：复刻 Kimi+ 广场
第三档测试，我选择了 Kimi 的 Kimi+ 广场。
选择它的原因主要是因为它的页面有些特殊——它的 tab 页和滚动是绑定的，和实际的视频呈现效果联系会更多一些。如果仅仅是靠切分图片的方式，是很难洞察到这种交互效果的，对模型视频理解能力的要求会更高。
原版 Kimi+ 广场
复刻版 Kimi+ 广场
从视频里面能看出来，这个例子稍微有点翻车。
因为它的 tab 页没有实现和滚动绑定，直接就是使用 tab 页分割各个块的内容，而且点击进页面的时候居然没有实现那种跳转的效果，而是弹出一个侧边栏进行对话。感觉和视频里面呈现的差距还是有点大的。
总体来说，三个例子里面有两个例子都很亮眼了。只是这个例子稍微有点偏差，并没有达到前面两个例子的复刻水平。不过至少没有 bug，还有一些参考价值，所以也称得上合格吧。
三、实测：实际日常开发能力
测完页面复刻的建站能力，我转向更贴近日常的开发任务——维护一个开源项目的文档和代码。
我选择了自己最近开源的 Python Code Sandbox MCP 项目。这个项目因为是刚刚做的，所以特点是文档繁重、代码需要频繁迭代，正好测试 K2.5 在真实工程场景中的表现。
地址：https://github.com/li-xiu-qi/python-code-sandbox-mcp
由 Docker 驱动的安全、隔离的 Python 执行沙箱 MCP 服务器。特点：临时运行、会话持久性、多架构支持以及超快速的 pip 缓存。
实际使用的时候发现 kimi code 主动调用 sub Agent 的频率很高，所以任务执行的速度会很快。它能灵活使用 sub Agent 是一个亮点，另外一个亮点是能读取图片以及视频，在开始的例子里面复刻 kimi 前端的时候演示过了。
文档整理
第一个任务是让 Kimi 整理项目文档。项目初期文档散落在各处，有中文有英文，版本管理也比较混乱。
Kimi 的处理方式是先梳理现状：它读取了现有的 README、USAGE、ARCHITECTURE 等文档，然后提出一个完整的重构方案——按版本号重新组织 CHANGELOG，统一文档结构，并建立中英文同步机制。
执行过程中有个细节：它主动使用 Task subagent 批量处理所有文档中的表情符号。这种批量并行处理的思路，比逐个文件修改效率高得多。
增量开发
更考验能力的是增量开发。我需要为项目添加文件持久化功能——让沙箱中创建的文件自动保存到宿主机。
第一次描述需求时，我说得过于简单：“帮我创建 examples 文件夹写一些使用示例”。结果 Kimi 创建了一堆纯 Python 代码，完全没有展示如何调用 MCP Server。这是我需求描述的问题，但也反映出 AI 在“理解隐含意图”上的局限。
我明确指出来后，它的修正速度很快：删除全部内容，重新设计符合需求的客户端调用示例。这种快速适应能力在迭代开发中很关键。
功能实现上，Kimi 展现了不错的工程思维。文件持久化功能它实现了三种模式：智能默认（用系统临时目录）、自定义路径、以及禁用持久化。覆盖不同用户场景的同时，保持了向后兼容。
但工程关联性上确实有疏漏。它修改完 docker_utils.py 后，没有主动更新测试文件和文档。是我提醒后，它才补充了 14 个单元测试，并更新了配置说明。
测试覆盖度倒是很完整。三种配置模式、宿主机文件操作、缓存机制都有对应的测试，21 个测试全部通过。对于需要长期维护的开源项目，这种测试意识是必须的。
这次测试给我的体感是：Kimi K2.5 在代码实现的质量上已经达到一线水平，工程完整性比如测试、文档需要人工把关，但它的配合度很高，迭代效率不错。
对于日常开发中的增量需求，它是能实打实提效的工具。
因为 Kimi code 里面它的多个子 Agent 经常能触发被调用，让我对 kimi 家推出的 Agent 集群非常感兴趣。所以我专门去体验了一下 kimi 家的多 Agent 蜂群协作，并尝试逆向解析里面内部的运行机制。
下面我们一起来看。
四、解读：Agent 集群的运作机制
我设计让它写一部小说。
为什么选小说？因为小说创作需要角色设定、情节规划、细节把控、文笔润色等多个环节的协同，正好可以解析Agent 集群的任务分解和协作能力。
它是怎么开始的？
Agent 启动后的第一个动作是读取待办清单。
这个设计逻辑很清晰：如果待办清单为空，进入角色创建流程；如果存在待办事项，优先完成清单任务。
这种“先规划后执行”的模式，避免了盲目执行导致的资源浪费。
它创建了一个“蜂群”
在小说创作任务中，Agent 组建了一个功能完备的蜂群：
-
主蜂后：握有最终解释权，监控情绪的一致性。
-
架构蜂：绘制 70 章的节拍蓝图。
-
商业蜂与细节蜂：负责数据查证，比如 2015 年的技术漏洞和北京中关村的租金细节。
-
文笔蜂：专门负责“通感修辞”，比如用“胃部的延迟响应”来描写饥饿感。
每个角色不是简单的指令集，而是拥有专属卡片、头像和功能说明的实体。甚至点击说明时，卡片会翻转展示详细信息。这种可视化设计，让 Agent 集群的运作过程变得透明可控。
下面的图就是具体的角色说明，可以理解成是它的系统提示词。
主要内容包括核心权利与责任、审查内容、原则纪律，以及输出格式。基本大部分的角色都是按照这个规律创建的。
蜂群是怎么工作的？
从图片中不难看出，蜂群的各个角色是并行执行任务的，不是串行。
就像一个工地上，电工、水工、泥瓦工同时开工，而不是等电工干完了水工才能上。这种并行化设计，显著提升了任务执行效率。
而且任务指令来自一个统一的任务调度 Agent，它负责串行生成一个批次的任务调度指令。因为任务调度是同一个 Agent 做的，所以任务之间的重复性会降低，任务的相关性会提升。
实际上和用户交互的可以叫做主控Agent，不过并不在上面的角色之列，但是是负责统管全局使用的。
从任务分配可以看到，最后会有一个 todo list 的勾选环节。如果遇到任务执行失败的情况，我猜测它会有几种处理方式：要么 Agent 自己尝试重试任务，要么任务调度 Agent 尝试更换模型重试，或者修改指令重试，再不行就分解任务继续细化，最坏的结果就是放弃任务，重新改写任务。
从上面的图可以继续分析。我们看右侧边栏的部分内容，可以发现角色使用了和第一个输入任务相同的方式执行流程：首先思考，接着读取任务待办清单，编写任务清单，最后生成任务需要它输出的蜂后世界观手册。
超长文档的续写机制
蜂群执行任务的时候，还有一个很有意思的细节。
因为大模型输出的长度是有限的，在生成超长文档的时候，K2.5 使用了一个续写机制。我猜测是使用滚动窗口的方式，也有可能是纯追加式的续写。
在每个角色都生成他们的设计内容之后，执行的流程就是创建新的角色负责生成我们的第一章内容了。
在任务完成之后有一个负责检查的Agent会对整个的内容进行检查。而且会提供下一张的接龙标记，方便下一个Agent继续按照这里的指令完成后续的任务。
这种机制避免了每次生成都要重新处理全部上下文，提高了长文档的生成效率。就像你写论文，不是每次都从第一章重新读起，而是接着上次的思路继续往下写。
章节之间的交接
完成第一章后，Agent 会继续执行后续任务。这里它们的任务交接方式很有意思。
在上一章的内容里面 Agent 留下了部分需要接龙的内容，第二章也很明显在任务的规划里面有提到让第一章的重要内容传递给第二章，并创建角色时传递了所需要的遗留信息内容。
这种显式的信息传递机制，保证了章节之间的连贯性。就像接力赛跑，前一棒的选手不只是把棒子递给你，还会告诉你“前面有个弯道，注意减速”。
异常处理
测试中发现了一个有趣的容错设计。
当子 Agent 无法完成任务时，主控 Agent 会直接接管，放弃调用子 Agent。这种设计避免了因单点故障导致整个流程阻塞。
总的来说，基本的流程就是：主控的 Agent 从开始的时候都会读取待办清单，如果没有就会创建新的待办清单。接着会生成指令创建角色去完成任务，被创建的角色本身也会按照主控 Agent 的流程进行，不过他们不具备创建角色的能力。
技术视角的思考
测试完成后，我认为 K2.5 在两个维度上实现了突破。
第一个维度是多模态融合的质量。
Moonshot 创始人杨植麟曾提到：在增加一个模态的同时不损伤模型原有的语言能力，是非常困难的。但在本次测试中，K2.5 显然跨过了这道门槛。视觉理解的敏锐度和语言逻辑的严谨性同时在线，这是它的核心竞争力。
第二个维度是 Agent 集群的工程化实现。
K2.5 的 Agent 集群不是简单的多模型调用，而是一套完整的任务调度、角色管理、信息传递、容错处理体系。它把原本需要大量人工协调的专家团队服务，变成了一套随调随用的“数字员工”体系。
虽然测试中只用了不到十个 Agent 角色，但这远未触及 K2.5 的能力上限。根据官方数据，它可以调度多达 100 个 Agent，并行处理 1500 个步骤。
从小说创作的结果看，大部分内容可以直接使用，只有少部分需要微调。这个质量水平，已经具备实用价值。
结论
回到最初的问题：K2.5 和 Claude、Gemini 的差异在哪里？
我的答案是：K2.5 是第一个真正具备实战能力的国产开源原生多模态模型。
它不只是在跑分上好看，而是在实际应用中展现出了可靠的性能。视频驱动的页面复刻、Agent 集群的协同创作，这些能力的背后，是多模态融合和工程化实现的双重突破。
还有个实际的点：用 Agent 干活，成本比你想的低。
Chatbot 场景下，cache hit 率大概是 1:3，但 Agent 这种高频调用的场景能到 1:10 甚至 1:100。什么概念？就是你让 Agent 写一部小说，实际花的钱可能只是表面价格的十分之一。这对需要大规模部署的团队来说，是个不小的优势。
如果用一句话总结：没有组织的智能是天才，有组织的智能才是生产力。
Kimi K2.5 证明了，国产模型不只是在追赶，而是在某些方向上开始探索自己的路径。
一起“点赞”三连↓