Multi-Agent 实测：不会带团队，模型干到死

雷峰网讯 Multi-Agent，就是来让用户当皇上的。

想必很多人早已习惯睡前把成堆的事情丢给 Agent，让它跑上一整夜，直到早上自己醒来，看到一份漂亮的交付结果。当然也有很多时候，我们得到的只是一个卡死在凌晨三点的进程，或者不知道从哪步开始，就被幻觉污染得胡言乱语的上下文。

这一点对于复杂任务尤其明显。而在此类场景中，Multi-Agent 系统因其任务拆解能力和对上下文窗口压力的缓解，拥有了超越单独 Agent 的落地能力。

话虽如此，一个任务具体如何拆分、各 Agent 的角色如何分配、谁来纠正幻觉以及长流程管理仍然是横亘在 Multi-Agent 系统面前的考验。从 CrewAI、AutoGen 到打出三省六部制旗号的 Edict，都在试图解决这些问题。

而我们好奇的是，Multi-Agent 生态经历了从 2025 年末至今的飞速成长，今天已经发展到了何种程度？在真实的复杂任务场景中，它会作何表现？

01

Agent Swarm “独苗”，Kimi K2.6

我们选择了 Kimi K2.6 作为此次的测试模型。即使今天距离这款模型的初次问世已经有了一段时间，它却仍然有着一众模型中极为少见的定位，一款针对 Multi-Agent 场景做了针对性优化的模型。

官方将其描述为具备 SOTA Coding、Long-Horizon Execution 和 Agent Swarm capabilities 的开源模型。值得注意的是最后一点，300 sub-agents、4000-step coordination 以及 multi-agent swarm orchestration 直接被 Kimi 写进了官方论文，至今还是止此一份。

更能说明问题的是此前 Kimi 官方披露的两个长程工程案例。K2.6 曾连续运行十几个小时，通过数千次工具调用优化本地模型推理和金融撮合引擎性能。这些案例共同指向一个判断，那就是模型不再仅仅负责生成答案，而是开始承担规划、执行、调用工具、接受反馈、修正路线并最终交付结果的完整链路，这正是 Multi-Agent 系统见长之处。

从结构上看，K2.6 采用 1T 级 MoE 架构，每次推理激活约 32B 参数，并支持 256K 上下文窗口。MoE 架构为模型提供了内部“专业化分工”的基础：面对代码、推理、工具调用、视觉理解和复杂任务拆解等不同场景时，模型可以通过专家路由机制调动不同能力。而 256K 长上下文，则为长程 Agent 任务提供了关键的“工作记忆”，使模型能够在长链路执行中保留任务目标、代码上下文、工具输出和多轮迭代历史。

相比单独 Agent 循环式执行任务，上述底层模型能力外化出的 Agent Swarm 必然会在任务拆解、并行处理和结果合成上有更突出的表现。这种组织能力很难被 Benchmark 体现，但它切实存在。K2.6 讨论的不仅是如何让一款模型更聪明，还在于让多个子 Agent 围绕同一个复杂目标协作。

事实上，在我们的实测中 K2.6 也确实展现出了类似团队协作的工作方式。它没有直接写代码，而是先拆解任务、设计 Agent 角色、进行开发，再通过审查、反思和二次迭代，最终在 53 分钟内生成了一个可运行的浏览器版 macOS 原型。

这正是我们最关注的问题，即组织能力与智能水平的叠加，如何在复杂任务中为模型性能带来更大的增益。

02

Multi-Agent 实战测试，把 MacOS 装进浏览器

我们为 K2.6 准备了一项非常典型的 Agent Swarm 任务。

代码块

请创建一个精美的、浏览器版MacOS系统。

请使用多个agent一起完成这项任务，整体遵循“计划-开发-反思反驳-意见汇-开发”的流程。

这项任务的复杂度极高，原因在于 MacOS 的视觉、交互、状态管理、动效、应用生态、Windows Manager、Menu Bar、Dock 等子系统全部要在浏览器中实现，仅靠单 Agent 顺序写代码，几乎注定会在半途上下文爆炸。

这决定了它天然需要多 Agent 并行协作。一个 Agent 写基础架构，另一个 Agent 写内核，第三个 Agent 写基础应用，它们之间必须有清晰的接口契约和风格约定，否则最后拼出来的产物会四分五裂。

此外，能否遵循“反思-反驳-汇总-再开发”的循环，也是这项任务隐含的一项考验。这几乎等同于 K2.6 所强调的 Multi-Agent Orchestration，即避免多个 Agent 自说自话，而是让它们彼此质询、综合意见、再迭代交付。

下面来看看 K2.6 的真实表现。

▪先搭组织，再写代码

K2.6 没有直接进入代码生成，而是先进入计划模式，对任务进行了结构化拆解。它首先给出了一份完整的开发计划，将浏览器版 macOS 拆成几个核心模块：Desktop 环境、Dock 栏、Menu Bar、Window Manager、内置应用、视觉效果。

对于多 Agent 任务而言，最怕的是各个 Agent 各写各的，最后接口、风格、状态管理全部错位。K2.6 在正式开发前，先定义了技术栈、组件目录、状态结构和验证标准，就相当于先搭了一个组织架构。不要说多 Agent 实践了，有过团队协作经验的都知道这一步有多重要。

▪多 Agent 分工：从开发到审查形成闭环

随后 K2.6 将任务交给六个 Agent 执行，并模拟出清晰的多 Agent 协作流程：

1）基础架构搭建：由 Agent A 负责初始化 Vite、React、TypeScript 项目，配置 Tailwind CSS，并搭建核心状态管理。

2）核心 UI 开发：由 Agent B 负责 Desktop、MenuBar、Dock 和 Window 系统。

3）应用开发：由 Agent C 负责 Finder、Safari、Terminal、Settings 等内置应用。

4）反思与反驳：由多个 Review Agents 分别从代码架构、UI/UX、性能优化角度进行审查。

5）意见汇聚与改进：将审查意见统一排序，确定修复优先级。

6）最终开发迭代：根据审查意见继续修改代码，完成测试和优化。

这套流程基本覆盖了真实软件工程中的几个关键环节，即从设计、开发、审查到修复、验证的全流程。相比单独 Agent 一路写到底，这种更接近团队协作的流程也更能体现 K2.6 所谓 Agent Swarm 的价值。任务拆解不是简单地把负责需求拆碎就完事，衡量拆解质量的标准，是模型能否交付一套可协作、可审查、可合并的工作单元拆解方案。

▪开发阶段：遇到失败后继续推进

在实际开发过程中，K2.6 并非一路顺利，但其总能在遇到失败后找到解决问题的办法，并继续推进任务直到完成项目。一个比较典型的例子是，项目初期曾多次出现依赖安装失败，报错包括 npm 网络连接中断、安装命令失败等。但 K2.6 没有停在错误处，而是调整策略，主动改用新的缓存目录重新安装依赖，最终不仅完成了安装，而且还加装了各种功能额外依赖。

这种报错和失败也是真实工程任务的一个环节，甚至可以说是常态，依赖安装失败、配置不兼容、文件写入错误、类型报错、构建失败都会发生。而 K2.6 的表现显示，它能在失败后继续读取反馈、调整路径，并推动任务继续走下去。

▪反思与审查：三个 Review Agent 并行指出问题

完成首轮开发后，K2.6 进入了“反思与反驳”阶段。系统启动了三个审查 Agent，分别给出了三方面的报告概述。

1）代码架构审查：7 次工具调用，约 30.0k tokens

2）UI/UX 体验审查：32 次工具调用，约 31.2k tokens

3）性能优化审查：23 次工具调用，约 30.3k tokens

此外令人惊喜的是，三个审查 Agent 对识别出的多类问题，自主划分出了高优先级和中优先级。这是一种很清醒的工程视角，或者说 K2.6 没有把审查当成某种形式化的环节，而是意识到它上承开发，下接迭代。将不同审查 Agent 的反馈汇总成优先级列表，意味着二次开发在任务之初就被考虑进了开发进度。

▪53 分钟自主完成一个浏览器版 macOS 原型

在意见汇总后，K2.6 开始执行二次开发。在此次测试任务中，具体内容包括修复了 Tailwind CSS v4 配置问题、修改了 Window 组件、引入 Framer Motion、为窗口添加动画、修复拖拽事件相关逻辑，以及将部分 emoji 图标替换为 Lucide React 的 SVG 图标，使整体视觉风格更加统一。

最终 K2.6 完成了项目构建，并生成了一个可运行的浏览器版 macOS 原型。

打开 http://localhost:5175 ，页面中已经出现了 macOS 风格的桌面、顶部菜单栏、左侧桌面图标和底部 Dock。这并不是一个静态 Demo，而是一个具备完整桌面交互结构的浏览器版 macOS 原型。

分别像使用 MacBook 一样打开 Finder、Terminal、Safari、VS Code、Settings、Calculator、Notes 等应用，并以不同窗口层级叠放在桌面上。每个窗口都有独立标题栏和控制按钮，整体排列符合桌面操作系统的基本逻辑。窗口左上角的红黄绿控制按钮、顶部菜单栏和底部 Dock，整体操作方式已经高度接近 macOS 的桌面体验。

到此，可以看出需求中的几个关键工程目标均已得到实现，例如窗口管理系统可用、应用状态能够区分、Dock 与应用入口联动、系统级布局完整、视觉风格统一。对于一个由 Agent 在不到一小时内完成的前端工程来说，这已经超出了普通代码补全任务的范畴，更接近一个完整小型应用系统的生成。

当然，更关键之处在于 K2.6 在这一过程中展现出的 Agent Swarm 能力，并非停留在多个角色分别发言的角色扮演上，相反所有反馈都被落实到了代码修改中。这既是 Multi-Agent 系统胜任复杂工程任务的原因，也是对于底层模型的考验。

03

组织者，模型的新角色

Agent 概念兴起之初，一种非常简单的期待是，给大模型加上记忆、工具调用和自主规划能力，它就能自动完成任何任务。

但实践很快暴露出这一路径的天花板。对于查询资料、智能客服、代码补全等简单任务，一个 Agent 确实已经足够。可一旦任务复杂度上升，单独 Agent 方案对于一次性完成全部流程的倾向，往往注定导致遗漏步骤、逻辑跳跃以及最终的结果质量波动。

由此，如何让多个 Agent 像一个组织一样协同工作，从而完成单个模型难以稳定完成的复杂任务，成为了催生 Multi-Agent 框架的首要问题。这也是模型层的一块风向标，底层模型在复杂任务中的组织能力，重要性或许不亚于所谓的智能上限。

K2.6 在实测中的表现正体现了这一点，创建浏览器版 macOS，并不是让模型生成一段前端代码，而是要求它设计一个小型桌面系统：窗口管理、应用状态、Dock、Menu Bar、Finder、Safari、Terminal、VS Code、设置、计算器和备忘录都要同时成立。先搭架构，再分工开发，通过审查 Agent 发现问题，最后把反馈回流到二次开发中，这些环节也都要齐备。

有了这些，创建浏览器版 macOS 的任务就不能简单地和代码补全相提并论，而更像是一次压缩版的软件团队协作。

Kimi 官方博客给出的两个长程工程案例，更能说明这种变化。第一个案例中，K2.6 在本地 Mac 上自主下载并部署 Qwen3.5-0.8B 模型，并用 Zig 语言实现和优化推理。整个过程持续 12 小时以上，累计 4000 多次工具调用，经历 14 轮迭代，最终将吞吐从约 15 tokens/s 提升至约 193 tokens/s，并比 LM Studio 快约 20%。

第二个案例发生在更复杂的系统工程场景中。K2.6 对已有 8 年历史的开源金融撮合引擎 exchange-core 进行自主改造。官方披露，模型连续执行 13 小时，迭代 12 种优化策略，发起 1000 多次工具调用，修改 4000 多行代码，并通过分析 CPU 与内存分配火焰图定位隐藏瓶颈。最终，K2.6 将 exchange-core 的核心线程拓扑从 4ME+2RE 调整为 2ME+1RE，实现中等吞吐提升 185%、性能吞吐提升 133%。

这些任务真正的困难之处在于，它们需要模型在一个长程任务中持续读代码、跑测试、看 profiling、判断瓶颈、修改方案，并用最终指标验证结果。换句话说，模型处理的不是单点的代码生成，而是工程环境中的持续问题求解。这也是为什么 K2.6 值得被放在“组织能力”的框架下讨论。

如果说 Chatbot 时代的模型像一个答题者，Agent 时代是一个执行者，那么对于 Multi-Agent 来说，模型则更进一步成为组织者。

这一点对于开源模型尤为重要。闭源模型可以通过产品形态提供更完整的 Agent 体验，开源模型的优势则在于可部署、可改造、可接入企业内部工具链。Multi-Agent 场景天然需要和具体业务结合，开源模型因此有机会进入 IDE、CLI、自动化测试、数据分析和企业内部知识系统，成为更灵活的任务执行底座。

更大、更快的叙事，已经无法回应 Agent 落地的全部需求。今天的模型更像是专家而非经理，组织能力是一片全新的战场。K2.6 并没有终结这场竞争，它只是指出，下一代模型除了思考，还必须成为一个可靠的组织者。补上这份能力的玩家，才有资格争夺那个更底层的位置。

雷峰网文章