如何构建 AI Agent 集群（完整指南）

这是一份从 A 到 Z 全面拆解 AI Agent Swarms（智能体集群）的指南，涵盖它们是什么以及如何使用。

它们为何会彻底改变你与 AI 协作的方式。

在忘记之前，先收藏本文。

Kimi K2.6，Moonshot AI 于 2026 年 4 月发布的开源旗舰模型，是我所见过的对这一理念最严肃的开源实现。

真正的任务是有广度的。研究 50 家公司。分析 200 个文件。十几个彼此不依赖、也不该排队等待的子任务。Agent Swarm 正是为此而生的架构。

本指南将分解其工作原理，从训练基础设施一直到 API，然后介绍我认为目前最重要的模式：Kimi 负责执行，Claude Opus 4.8 负责规划与验证。

以下是最终工作流的样貌：

第一节：什么是 Agent Swarm？

Agent Swarm 是由多个 Agent 同时对分解后的子任务进行工作，并由一个协调器（Orchestrator）聚合结果。

与顺序链的区别是全部关键所在：

• 顺序链： Agent A 运行，交给 B，B 交给 C。总时间 = A + B + C。
• Swarm（集群）： 协调器拆分目标，Agent A、B、C 同时独立运行各自的子任务，结果合并。总时间 ≈ max(A, B, C)。

当任务具有真正的并行结构时，这就是几分钟与几小时的区别。

Swarm 还解决了上下文溢出问题。一个 Agent 处理长任务时，token 会累积直到窗口被撑满。而 Swarm 为每个子任务提供独立的受限上下文，只有结构化输出流回协调器。

六个构建模块

每个 Swarm 都有相同的核心组件：

把这六点做对，你就拥有了一个 Swarm。任何一点出错，你得到的将是一场昂贵的调试。

第二节：Kimi K2.6 到底是什么

在探讨 Swarm 行为之前，有必要先了解它的底层基础。K2.6 是 Moonshot AI 发布的一个 1 万亿参数的混合专家（MoE）模型，于 2026 年 4 月 20 日以修改版 MIT 许可证开源。月收入低于 2000 万美元或月活跃用户低于 1 亿可免费商用——因此对大多数开发者来说几乎是免费的。

0:29

架构规格

INT4 QAT 版本可在 4 块 H100 80GB 上原生运行。FP16 需要 8 块 H100 80GB。所有三个支持的推理框架（vLLM、SGLang、KTransformers）都提供兼容 OpenAI 的 API。

第三节：MuonClip 优化器，或者说为何训练是稳定的

训练一个万亿参数的稀疏 MoE 而不出问题是很困难的。具体的失败模式是：随着序列长度增长，注意力层中的查询-键（QK）点积可能无界增长。你会遇到损失尖峰，而在这种规模下，损失尖峰可能是不可恢复的。

Kimi K2 技术论文（arxiv: 2507.20534）引入了 MuonClip 来解决这个问题。

Muon 是一种梯度优化器，在 token 效率上优于 AdamW。相同质量，更少的训练步骤。但问题在于：Muon 单独使用会在万亿参数规模下产生注意力不稳定性。

QK-Clip 在 softmax 之前直接对 QK 矩阵进行逐 token、逐头的裁剪。这限制了注意力分数的大小，消除了爆炸性病理现象。无需手动调参，无需学习率 hack。

论文摘要中提到：

“我们提出了 MuonClip，一种新颖的优化器，它将 token 高效的 Muon 算法与一种称为 QK-Clip 的稳定性增强机制相结合……使用 MuonClip，Kimi K2 以显著少于 AdamW 基线的训练 token 数达到了有竞争力的性能。”

为什么开发者要关心一个训练细节？因为 K2.6 能够在 12 小时以上的时间里持续进行 4,000 次工具调用而不退化，其根源可追溯至此。一个训练时存在注意力不稳定性的模型，在长上下文、高步骤数的条件下容易产生幻觉。而这正是 Agent Swarm 所处的场景。

第四节：PARL，Swarm 背后的研究

Agent Swarm 并不是一个附加在 K2.6 之上的框架。这种行为是通过 Moonshot 称之为 PARL：并行 Agent 强化学习（Parallel-Agent Reinforcement Learning） 的范式训练进模型中的，该范式在 Kimi K2.5 技术论文（arxiv: 2602.02276）中有描述。

可训练的协调器，冻结的子 Agent

构建多 Agent 系统的通常方式是在应用层协调多个实时模型实例。但这样一来，信用分配就成了一团乱麻：哪个 Agent 导致了最终答案的好坏？通过该图进行端到端训练在计算上是不可行的。

PARL 巧妙地绕开了这个问题：

• 协调器是可训练的，通过结果奖励进行 RL 更新
• 子 Agent是冻结的，固定的中间策略检查点

子 Agent 的轨迹被视为环境观测，而不是可微分的决策点。这样同时解耦了两个难题。信用只归于协调器的动作，而不会归于 300 个并行的子 Agent。同时训练保持稳定，因为只有一个模型在更新。

协调器学习何时并行化、创建多少子 Agent 以及如何分配工作。这些行为并非人工指定，而是从奖励最大化中涌现出来的。

三部分奖励函数

协调器根据三个信号进行训练。

一个并行奖励推动它创建并发子 Agent，而不是顺序执行。如果没有这个奖励，模型默认会一次只运行一个 Agent：安全、可预测，但缓慢。

一个完成奖励确保子 Agent 实际完成任务。这阻止了“虚假并行”，即协调器为了赚取并行奖励而创建一群什么也不做的 Agent。

一个性能奖励根据任务目标对最终输出质量进行评分。这是其他一切所服务的基准事实。

我发现最有趣的细节是：优化指标是关键步骤（关键路径长度），而不是总步骤数。模型因缩短最长依赖链而获得奖励，而不是因为最大化原始并发度。这才是真正减少挂钟时间的东西。

PARL 成果

• BrowseComp： Swarm 模式在 K2.5 上达到 78.4%，相比单 Agent K2.5（60.6%）提升了 17.8 个绝对百分点，当时超过了 GPT-5.2 Pro（77.9%）。K2.6 将其推升至 86.3%。
• WideSearch： Item-F1 提升 6.3 个绝对百分点（从 72.7% 到 79.0%）
• 挂钟时间： 在可并行任务上相比单 Agent 基线减少 3-4.5 倍
• 并行工具调用： 在 K2.6 中可达 4,000 个协调步骤

第五节：Mooncake，Kimi 背后的基础设施

Moonshot 的推理基础设施解释了为何 K2.6 能够在不崩溃的情况下维持 300 个并行 Agent。模型权重只是故事的一半，服务于它们的系统是另一半。

该基础设施为长上下文任务提供了良好的结构。

以 KVCache 为中心的分离式架构

Moonshot 的推理平台称为 Mooncake，在其 2024 年的基础设施论文（arxiv: 2407.00079）中有所描述。它是大规模运行 Kimi 的引擎，其设计选择与众不同。

传统的 LLM 推理在相同的 GPU 实例上执行 prefill（处理输入提示）和 decode（生成 token）。Mooncake 将其分离到不同的集群中：

• Prefill 集群： 处理初始提示处理，针对长上下文输入可独立扩展
• Decode 集群： 处理 token 生成，针对吞吐量和延迟进行优化

KV 缓存，这种使自回归生成高效的中间注意力状态，被作为一等系统资源进行管理。Mooncake 构建了一个分布式 KV 缓存，横跨 GPU VRAM、CPU DRAM 和 SSD，并配备了一个自定义传输引擎在节点之间移动缓存。

这对 Agent Swarm 为何重要

当 300 个子 Agent 同时运行时，每个 Agent 都会生成自己的 KV 缓存。在传统架构中，这会导致巨大的 GPU 内存压力和调度冲突。而使用 Mooncake 的分离式缓存：

• 已完成子 Agent 的 KV 缓存可以被逐出到 DRAM 或 SSD，并在需要时召回
• Prefill 集群独立处理每个子 Agent（通常很大的）系统提示
• 调度器在保持每个 Agent 延迟 SLO 的同时最大化整体吞吐量

摘自 Mooncake 论文：“与基线方法相比，Mooncake 在遵守 SLO 的同时，在某些模拟场景中可实现高达 525% 的吞吐量提升。在实际工作负载下，Mooncake 的创新架构使 Kimi 能够处理多 75% 的请求。”

更新的论文报告称，Mooncake“已在数千个节点上运行，每天处理超过 1000 亿个 token”，并且在 A800 集群上处理请求量比之前的系统多 115%，在 H800 集群上多 107%。

大规模 PD 分离：128 GPU K2 部署

LMSYS 发布了一个使用 Prefill-Decode（PD）分离在 128 块 H200 GPU 上通过 SGLang Router 部署 Kimi K2 的案例研究。其架构如下：

• SGLang Router： 轻量级服务，通过标签选择器对 prefill 和 decode 节点进行动态服务发现
• 专家并行： K2 的 384 个专家分布在节点之间，路由在网络层面进行
• OME（Open Model Engine）： 用于推理层的 Kubernetes 原生编排

这就是在生产规模下运行 K2 家族的软件栈。如果你在自托管 K2.6，这就是你的模板。

第六节：Agent Swarm 如何逐步工作

K2.6 在 Swarm 模式下执行任务时的机械流程如下：

第一步：任务分解

协调器分析任务并构建依赖图：哪些子任务是独立的可以并行运行，哪些依赖于先前的输出。

对于“研究 100 家 YC 公司并生成行业分析”这个任务，协调器识别出 100 个独立的研究任务，然后 1 个聚合任务，再然后 1 个综合任务。第一层是完全可并行的。

第二步：专家 Agent 创建

协调器根据子任务类型创建领域专家子 Agent。K2.6 动态实例化 Agent，并为它们分配角色特定的指令和有针对性的工具访问权限：

• 网络研究 Agent： 搜索 + 浏览器工具
• 数据分析 Agent： Python 执行 + 电子表格工具
• 写作 Agent： 综合与文档生成
• 事实核查 Agent： 交叉引用与验证

每个子 Agent 都在自己独立的受限上下文中运行。它处理一个限定范围的任务，产生结构化输出，然后退出。局部上下文不会携带协调器所知的一切，只携带该子 Agent 所需的信息。这就是 K2.6 避免在那些几分钟内就会填满任何单个 Agent 窗口的任务上溢出的方法。

第三步：多波并行执行

Agent 以波次形式执行。第一波处理完全独立的任务。

1. 随着结果落地，协调器启动第二波，处理依赖第一波输出的任务，依此类推，直到依赖图被解析。
2. K2.6 支持每个会话最多 300 个子 Agent 和 4,000 个协调步骤。协调器实时监控执行，检测失败或停滞的 Agent，并自动重新分配它们的任务。
3. 这种容错机制使得 12 小时以上的自主运行成为可能，无需人工监控。

第四步：聚合与输出

一旦所有子 Agent 完成，协调器将结果聚合为最终交付物：文档、电子表格、网站、幻灯片。

• 它是对 Agent 输出进行综合，而不是简单拼接，因此结果在结构上是连贯的。
• 还有一点值得注意：Swarm 结构也是 Kimi 解决上下文窗口问题的方案。
• K2.6 的明确策略是：“一旦上下文窗口超过阈值，只保留最新一轮与工具相关的消息。” Swarm 使得该策略在非常长的任务范围内得以持续。

第七节：Kimi x Claude Opus 4.8 架构

没有哪个单一模型是 Swarm 每一层的正确答案。Kimi K2.6 专为水平扩展而设计——跨越数百个 Agent 的并行执行、长时间的自主运行、经济高效的批量处理。

Claude Opus 4.8 专为判断力而设计——规划、细致推理以及捕捉自身错误。它们在结构上互补，彼此留下的空白恰好接近对方的优势。

模式如下：

1[用户目标]
2      |
3[Claude Opus 4.8 - 规划器]
4  将目标分解为结构化的任务规范
5  识别并行与顺序子任务
6  为每个子任务定义成功标准
7      |
8[Kimi K2.6 Agent Swarm - 执行器]
9  接收结构化任务规范
10  创建最多 300 个专用子 Agent
11  跨工具调用并行运行
12  返回结构化结果
13      |
14[Claude Opus 4.8 - 验证器]
15  对照成功标准审查 Kimi 的输出
16  标记失败、差距、不一致
17  综合最终交付物

为何用 Claude 做规划和验证？

Opus 4.8 最被低估的变化是诚实度的提升：“Opus 4.8 对自身所写代码中的缺陷视而不见的可能性，比其前代大约低四倍。”在 Agent 系统中，虚假自信是灾难性的失败模式。

• 一个声称“已完成”但实际未完成的协调器，会将错误级联到 300 个下游 Agent。Claude 倾向于标记不确定性并在任务中捕捉自身错误，这使其成为在那些犯错代价高昂的层中正确的锚点。
• Opus 4.8 还支持 100 万个 token 的上下文窗口，这对于验证环节很重要，因为你要将来自 50 多个并行研究 Agent 的输出拉入一个单一的审查上下文。

为何用 Kimi 做执行？

K2.6 的 Agent Swarm 支持每个会话最多 300 个并行子 Agent 和 4,000 个协调工具步骤——这是一种训练出来的行为，而不是应用层的包装。

• Claude 在 Claude Code 中确实有一个动态工作流（Dynamic Workflows）功能，但目前仍处于研究预览阶段，且仅限于 Enterprise/Max 计划。
• Kimi 的 Swarm 能力现在通过 API 对所有人开放。Token 的经济性在大规模应用中也至关重要：K2.6 的输入/输出 token 价格为每百万 $0.95/$4.00。对于批量并行执行来说，这并非小数目。

第八节：何时需要 Swarm（以及何时不需要）

在多 Agent 设计中，最常见的错误是：在尚未触及单 Agent 天花板之前就添加 Swarm 复杂性。

在以下情况保持单 Agent：

• 任务适合单个上下文窗口（实际工作少于约 50K token）
• 任务本质上是顺序的，每一步都依赖上一步
• 你还在原型设计阶段——单 Agent 的失败模式更容易调试
• 任务无论如何都会在 10 分钟内完成

在以下情况下使用 Agent Swarm：

• 任务有 n 个并行、独立的子任务，且 n > 5
• 上下文溢出是真正的问题（深度研究、大型代码库、批量操作）
• 你需要领域专用的 Agent 同时工作
• 任务太长，无法在单个顺序会话中保持质量
• 你需要一个评论家或验证 Agent 来检查另一个 Agent 的工作

在以下情况下使用 Kimi + Claude Opus 4.8 混合方案：

• 规划质量很重要，并且你希望有一个如果计划错误会提出异议的模型
• 输出无需进一步人工审核就直接交付——因此验证必须内建
• 你在运行高量级执行，token 成本会迅速累积
• 你希望 Claude 的判断力用于决策层，而 Kimi 的扩展能力用于工作层

第十节：四种 Swarm 架构模式

模式 1：协调器-工作者（最常见）

一个中央协调器将子任务分配给工作者，工作者并行执行，结果聚合。

1[用户目标]
2    |
3[协调器 - Claude Opus 4.8]
4    +-- [工作者: Kimi 研究 Agent x N]
5    +-- [工作者: Kimi 数据 Agent x N]
6    +-- [工作者: Kimi 代码 Agent x N]
7    |
8[综合器 - Claude Opus 4.8]
9    |
10[最终输出]

最适合： 具有清晰可分离子任务和可变数量工作者的任务。

模式 2：评论家-优化者循环

一个 Agent 生成，另一个评论，重复直到达到质量阈值。

1[Kimi K2.6 构建者] -> 草稿 -> [Claude Opus 4.8 评论家] -> 反馈 -> [Kimi K2.6 构建者]
2                                        |
3                                   (已批准)
4                                [最终输出]

最适合： 代码生成、技术写作、合规敏感的输出。始终设置最大迭代次数限制。

模式 3：层级式

一个战略协调器管理领域协调器，领域协调器再管理工作者。

1[Claude Opus 4.8 - 战略协调器]
2    +-- [Kimi K2.6 Swarm - 研究团队 (50 个 Agent)]
3    +-- [Kimi K2.6 Swarm - 构建团队 (50 个 Agent)]

最适合： 具有不同领域的大型企业工作流。

模式 4：Claw 组（Kimi 原生异构 Swarm）

K2.6 协调运行任何模型的 Agent，包括本地模型、Claude 和 GPT，以及人类工作者，在一个共享的操作空间中。目前处于研究预览阶段。

1[Kimi K2.6 协调器]
2    +-- [Claude Opus 4.8 - 推理专家]
3    +-- [Llama 3.3 本地模型 - 成本敏感的批量任务]
4    +-- [Kimi K2.6 Agent x N - 执行层]
5    +-- [人类审查员 - 批准检查点]

最适合： 需要模型多样性、本地+云端混合或人工介入要求的工作流。

第十二节：Swarm 任务的提示词设计

分解提示词（协调器用）

1你是一名任务架构师。将以下目标分解为独立、可并行化的子任务。
2
3规则：
4- 每个子任务必须能够由单个专用 Agent 独立完成
5- 具有依赖关系的子任务必须标记其依赖链
6- 输出为 JSON：{task_id, description, agent_type, depends_on, success_criteria}
7
8目标：{user_goal}
9可用的 Agent 类型：researcher, analyst, coder, writer, verifier

专家系统提示词（子 Agent 用）

1你是专门从事 {DOMAIN} 领域的 {ROLE} Agent。
2
3任务：{subtask_description}
4
5约束：
6- 仅返回符合以下 JSON 格式的有效 JSON：{output_schema}
7- 不要超出你的任务范围
8- 如果你无法完成任务：{"error": "reason", "partial_results": [...]}
9- 最大工具调用次数：{max_tool_calls}
10
11上下文：{context_from_orchestrator}

聚合提示词（综合器用）

1将来自 {n} 个专家 Agent 的研究综合为一份连贯的输出。
2
31. 阅读所有提供的 Agent 输出
42. 识别它们一致、不一致或有差距的地方
53. 生成一份 {output_type}，整合所有发现
64. 明确指出不一致之处——不要默默地解决矛盾
7
8Agent 输出：{agent_outputs_as_json}
9输出格式：{final_output_spec}

第十三节：七条不可协商的护栏

1. 每个 Agent 的最大迭代次数。 循环达到上限后通知协调器的硬性限制。

2. 会话超时。 如果 Swarm 在 N 分钟内未完成，终止并返回部分结果。

3. 结构化输出强制执行。 强制 Agent 返回 JSON。来自中间 Agent 的散文会造成下游解析失败。

4. 失败隔离。 失败的子 Agent 不得使协调器崩溃。

1async def run_subagent_safely(kimi_client, task, agent_id):
2    try:
3        result = kimi_client.chat.completions.create(
4            model="kimi-k2.6",
5            messages=[{"role": "user", "content": task}],
6            max_tokens=4096
7        )
8        return {"agent_id": agent_id, "status": "success",
9                "output": result.choices[0].message.content}
10    except Exception as e:
11        return {"agent_id": agent_id, "status": "failed", "error": str(e)}

5. 带指数退避的重试。 处理 429 错误和暂时性错误，不将其视为永久性失败。

6. 人工介入检查点。 对于具有写入权限的 Swarm（部署代码、发送电子邮件、进行 API 修改），插入强制批准暂停。

7. 成本监控。 设置每次运行的 token 预算。失控循环总是先以成本异常的形式出现，然后才是质量问题。

首先构建什么

从第九节中的三 Agent 流水线开始。它足够小，可以在一个下午内调试完成；它涵盖了规划、并行执行和验证；你可以在不到一小时的设置时间内针对真实任务运行它。

当它出问题时——它一定会出问题——其失败模式将教会你更多关于 Swarm 设计的知识，胜过再读一个小时的文章。

构建它。故意让它出问题。然后带着具体的参考点回到第十一节中的模式。

架构并非难点。难点在于“在测试中有效”与“凌晨 3 点无人值守时仍有效”之间的差距，而这个差距完全在于护栏、可观测性和记忆设计。

结论

Kimi 2.6 是一场 Agent 的革命，展示了强化学习如何建立 Agent Swarm。

它还展示了长上下文范围如何利用这种基于协调器的基础设施，从而允许创建多个子 Agent 来构建复杂的系统，所有这一切都只需一个

免责声明

本文基于作者笔记中 Kimi 2.6 技术文档和研究论文编写，并由 AI（Opus 4.7）进行编辑。