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 的价值。任务拆解不是简单地把负责需求拆碎就完事，衡量拆解质量的标准，是模型能否交付一套可协作、可审查、可合并的工作单元拆解方案。