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

这是关于AI代理集群的完整A-Z解析——它们是什么、如何使用它们。

以及为什么它们会彻底改变你与AI协作的方式。

趁还没忘记，先收藏起来。

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

真实任务是有宽度的。要研究五十家公司，要分析两百个文件。一打子任务彼此独立，不该排队等待。代理集群就是为此而生的架构。

本指南从训练基础设施到API接口逐层拆解其工作原理，然后介绍我认为当下最重要的模式：Kimi负责执行，Claude Opus 4.8负责规划和验证。

以下是最终工作流的呈现方式：

第一节：什么是代理集群？

代理集群是指多个代理同时对分解后的子任务并行工作，由一个编排器协调并汇总结果。

与顺序链的本质区别就在这里：

• 顺序链： 代理A运行，交给B，B交给C。总时间 = A + B + C。

• 集群： 编排器拆解目标，代理A、B、C同时独立运行各自的子任务，结果合并。总时间 ≈ max(A, B, C)。

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

集群还能解决上下文溢出问题。单个代理处理长任务时，会不断积累token直到窗口被淹没。集群让每个子任务拥有自己受限的上下文，只有结构化输出流回编排器。

六大构建模块

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

把这六点做对了，你就有了一个集群。任何一点出错，你就会陷入昂贵且耗时的调试过程。

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

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

架构规格

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

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

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

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

Muon是一种梯度优化器，比AdamW更节省token。质量相同，训练步数更少。但问题在于：单独使用Muon会在万亿参数规模下导致注意力不稳定。

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

从论文摘要来看：

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

为什么开发者要关心训练细节？因为K2.6能在12小时以上持续执行4000次工具调用而不退化的原因，可以追溯到这一点。训练时存在注意力不稳定的模型，在长上下文、高步数条件下容易产生幻觉。而这正是代理集群所处的运行环境。

第四节：PARL——集群背后的研究

Agent Swarm并非在K2.6之上硬加的一个框架。这种行为是通过一种名为PARL：并行代理强化学习的模式训练到模型中的，详见Kimi K2.5技术论文（arxiv: 2602.02276）。

可训练的编排器，冻结的子代理

构建多代理系统的通常做法是在应用层协调多个实时模型实例。但这样信用分配就成了难题：你的哪个代理让最终答案变好或变坏了？通过整个计算图进行端到端训练在计算上是不可行的。

PARL绕过了这个问题：

• 编排器是可训练的，通过基于结果奖励的RL进行更新
• 子代理是冻结的、固定的中间策略检查点

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

编排器学会了何时进行并行处理、生成多少子代理以及如何分解工作。没有人手动指定这些行为，它们是从奖励最大化中涌现出来的。

三部分奖励函数

编排器根据三个信号进行训练：

一个并行奖励促使它生成并发的子代理，而不是顺序执行。没有这个奖励，模型默认一次只用一个代理：安全、可预测，但慢。

一个完成奖励确保子代理实际完成它们的任务。这阻止了“虚假并行“——即编排器生成一大群不干活的代理只是为了获取并行奖励。

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

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

PARL成果

• BrowseComp： 集群模式在K2.5上达到78.4%，比单代理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%）

• 实际时间： 在可并行任务上比单代理基线减少3到4.5倍

• 并行工具调用： K2.6最多支持4000个协调步骤

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

Moonshot的推理服务基础设施解释了为何K2.6能维持300个并行代理而不崩溃。模型权重只是故事的一半，服务这些模型的系统是另一半。

基础设施为长上下文任务构建良好

基础设施为长上下文任务构建良好

以KVCache为中心的分离式架构

Moonshot的服务平台名为Mooncake，详见其2024年基础设施论文（arxiv: 2407.00079）。这是驱动Kimi大规模运行的引擎，其设计选择不同寻常。

传统的LLM推理将预填充（处理输入提示）和解码（生成token）运行在同一GPU实例上。Mooncake将它们分离到不同的集群中：

• 预填充集群： 处理初始提示，可独立扩展以应对长上下文输入

• 解码集群： 处理token生成，优化吞吐量和延迟

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

这对代理集群为何重要

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

• 已完成子代理的KV缓存可以被卸载到DRAM或SSD，并在需要时召回

• 预填充集群独立处理每个子代理（通常很大）的系统提示

• 调度器在保持每个代理延迟SLO的同时最大化整体吞吐量

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

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

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

LMSYS发布了一个使用预填充-解码分离技术在128块H200 GPU上部署Kimi K2的案例研究，基于SGLang路由器。架构如下：

• SGLang路由器： 轻量级服务，通过标签选择器实现预填充和解码节点的动态服务发现

• 专家并行： K2的384个专家分布在各个节点上，在网络层面进行路由

• OME（开放模型引擎）： 基于Kubernetes的服务层编排

这就是在生产规模下运行K2系列模型的完整技术栈。如果你在自托管K2.6，这就是你的模板。

第六节：代理集群如何一步步工作

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

第一步：任务分解

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

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

第二步：专业代理生成

编排器根据子任务类型生成领域专门的子代理。K2.6动态实例化代理，赋予它们角色特定的指令和目标工具访问权限：

• 网络研究代理： 搜索+浏览器工具

• 数据分析代理： Python执行+电子表格工具

• 写作代理： 综合与文档生成

• 事实核查代理： 交叉引用与验证

每个子代理在其自身受限的本地上下文内运行。它处理一个范围明确的任务，生成结构化输出，然后退出。本地上下文不携带编排器知道的全部信息，只携带该子代理需要的内容。这就是K2.6如何避免在那些任何单个代理窗口都会在几分钟内被填满的任务上溢出。

第三步：分波并行执行

代理分波执行。第一波处理完全独立的任务。

• 随着结果陆续返回，编排器启动第二波处理依赖于第一波输出的任务，依此类推，直到依赖图解析完毕。

• K2.6支持每次会话最多300个子代理和4000个协调步骤。编排器实时监控执行过程，检测失败或停滞的代理，并自动重新分配它们的任务。

• 正是这种容错能力让12小时以上的自主运行成为可能，无需人工监控。

第四步：聚合与输出

一旦所有子代理完成，编排器将结果聚合成最终的交付物：文档、电子表格、网站、演示文稿。

• 它综合各代理的输出，而不是简单拼接，因此最终结果在结构上是连贯的。

• 还有一件值得注意的事：集群结构也是Kimi应对上下文窗口问题的答案。

• K2.6的明确策略是：“一旦上下文窗口超过阈值，只保留最近一轮与工具相关的消息。“集群让这个策略在非常长的任务周期中可持续运行。

第七节：Kimi x Claude Opus 4.8 架构

对于集群的每一层来说，没有哪个单一模型是正确答案。Kimi K2.6是为横向扩展而构建的——跨越数百个代理的并行执行、长时间的自主运行、经济高效的批量处理。

Claude Opus 4.8是为判断力而构建的——规划、细微差别的推理以及发现自身错误。它们在结构上互为补充，每个模型留下的空白都接近另一个模型的优势所在。

模式如下：

为什么用Claude做规划和验证？

Opus 4.8最被低估的变化是诚实度的提升：“Opus 4.8在其所编写代码中放任缺陷不被标记的概率比其前身降低了约四倍。“在代理系统中，虚假自信是灾难性的失败模式。

• 一个说“已完成“但实际并未完成的编排器，会将错误级联传播到300个下游代理。Claude倾向于标记不确定性并在任务中途发现自身错误，这使其成为纠正成本高昂的层级的正确锚点。

• Opus 4.8还支持100万token的上下文窗口，这在将50+并行研究代理的输出拉入单一审查上下文进行验证时非常重要。

为什么用Kimi做执行？

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

• Claude Code中确实有动态工作流功能，但目前处于研究预览阶段，且限于企业版/最大计划。

• Kimi的集群能力现在对所有人开放，通过API即可使用。在规模上，token经济也很重要：K2.6的输入/输出token成本为每百万token 0.95美元/4.00美元。对于批量并行执行来说，这可不是小数目。

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

多代理设计中最常见的错误是：在达到单代理天花板之前就引入集群的复杂性。

以下情况保持单代理：

• 任务能容纳在单个上下文窗口内（实际工作内容约5万token以下）

• 任务本质上是顺序的，每一步依赖于前一步

• 你还在原型设计阶段——单代理的失败模式更容易调试

• 任务无论如何都能在10分钟内完成

以下情况考虑代理集群：

• 任务有n个并行、独立的子任务，且n > 5

• 上下文溢出是真实问题（深度研究、大型代码库、批量操作）

• 你需要领域专门的代理同时工作

• 任务太长，无法在单个顺序会话中保持质量

• 你想要一个评论者或验证者代理来检查另一个代理的工作

以下情况使用Kimi + Claude Opus 4.8混合模式：

• 规划质量很重要，你希望模型在计划有误时提出异议

• 输出直接交付，无需进一步人工审查——因此验证必须内嵌

• 你在运行高容量执行任务，token成本会迅速累积

• 你希望Claude的判断力用于决策层，Kimi的扩展能力用于工作层

第十节：四种集群架构模式

模式一：编排器-工作者（最常见）

中央编排器将子任务分配给工作者，工作者并行执行，结果汇总。

最适合： 子任务可明确分离且工作者数量可变的任务。

模式二：评论者-优化者循环

一个代理生成，另一个评论，重复直到达到质量标准。

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

模式三：层级式

战略层编排器管理领域编排器，再由领域编排器管理工作者。

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

模式四：爪群组（Kimi原生异构集群）

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

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

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

分解提示词：