AI Agent Swarm 完整指南（从原理到实战）

核心概念

Agent Swarm = 多个 Agent 同时处理分解后的子任务，由编排器（Orchestrator）协调聚合结果。

vs 串行链：

• 串行：A → B → C，总时间 = A + B + C
• Swarm：A、B、C 并行，总时间 ≈ max(A, B, C)

同时解决上下文溢出问题：每个子任务有独立的有界上下文，只有结构化输出返回给编排器。

Swarm 六大组件

组件	作用
Orchestrator	分解任务、分配子任务、监控执行、聚合结果
Subagents	领域专用工作者（研究、代码、分析、写作）
Tools	Agent 可调用的函数：搜索、代码解释器、文件 I/O、API
Memory	共享可读写状态
Handoffs/Routing	Agent 间传递控制或数据的机制
Guardrails	迭代限制、超时、人工介入触发、错误恢复

Kimi K2.6 底层架构

1T 参数 MoE（Mixture-of-Experts），2026.4 开源，Modified MIT 许可。

规格	值
总参数	~1.04T
每 token 激活	~32B（8 专家 + 1 共享）
总专家数	384，跨 61 层
上下文窗口	262K tokens
注意力	Multi-Head Latent Attention (MLA)
视觉编码器	MoonViT-3D（400M 参数，图像+视频）
量化	INT4 QAT，~594GB 磁盘
推理框架	vLLM / SGLang / KTransformers

INT4 跑在 4×H100 80GB，FP16 需 8×H100。

MuonClip 训练稳定性

万亿参数 MoE 训练的核心问题：QK 点积随序列长度无限增长，导致 loss 尖峰。

• Muon：比 AdamW 更高效的梯度优化器，同质量更少步数
• QK-Clip：在 softmax 前对 QK 矩阵做逐 token、逐 head 裁剪
• 两者结合 = MuonClip，支撑 K2.6 在 4000 步工具调用、12+ 小时不退化

PARL：并行 Agent 强化学习

Agent Swarm 不是应用层框架，是训练进模型的行为。

• Orchestrator 可训练（RL + 结果奖励）
• Subagents 冻结（固定中间策略检查点）
• 子 agent 轨迹作为环境观测，不可微

三个训练信号：

1. 并行奖励：推动并发 spawn，避免默认串行
2. 完成奖励：阻止"假并行"（spawn 一堆不干活的 agent）
3. 性能奖励：最终输出质量评分

优化指标是关键路径长度，不是总步数——缩短最长依赖链才真正减少墙上时间。

Benchmark

• BrowseComp：Swarm 86.3%（K2.6），vs 单 agent 60.6%（K2.5），vs GPT-5.2 Pro 77.9%
• WideSearch：Item-F1 从 72.7% 提升到 79.0%
• 墙上时间：可并行任务 3-4.5x 加速
• 最多 300 并行 sub-agent，4000 协调步

Mooncake 基础设施

Moonshot 的推理平台，核心设计：Prefill-Decode 分离。

• Prefill 集群：处理输入 prompt，独立扩展长上下文
• Decode 集群：生成 token，优化吞吐和延迟
• KV Cache 作为一等公民资源：分布式管理 GPU VRAM / CPU DRAM / SSD

300 个 sub-agent 并行时，每个生成独立 KV cache。分离架构下：

• 完成 agent 的 cache 可驱逐到 DRAM/SSD
• Prefill 集群独立处理各 agent 的大 system prompt
• 吞吐提升 525%，实际负载多处理 75% 请求

日处理 1000 亿+ tokens。

推荐架构：Kimi 执行 + Claude Opus 规划验证

[用户目标]
  |
[Claude Opus 4.8 - 规划器]
  分解目标为结构化任务规格
  识别并行 vs 串行子任务
  定义每个子任务的成功标准
  |
[Kimi K2.6 Agent Swarm - 执行器]
  接收结构化任务规格
  Spawn 最多 300 个专用 sub-agent
  并行运行工具调用
  返回结构化结果
  |
[Claude Opus 4.8 - 验证器]
  对照成功标准审查输出
  标记失败、缺口、不一致
  合成最终交付物

Claude 做规划/验证的理由：

• Opus 4.8 诚实度提升 4x（不会放过代码缺陷）
• 1M token 上下文窗口（验证层需要汇总 50+ agent 的输出）
• 不确定性标记 + 自我纠错能力

Kimi 做执行的理由：

• 300 并行 sub-agent + 4000 协调步（训练行为，非应用层包装）
• $0.95/$4.00 per M tokens
• Claude Dynamic Workflows 仍是研究预览，仅限 Enterprise/Max

何时用 Swarm vs 单 Agent

保持单 agent：

• 任务 < 50K tokens
• 天然串行（每步依赖上一步）
• 仍在原型阶段（单 agent 失败模式更易调试）
• 10 分钟内能完成

用 Agent Swarm：

• 5+ 个独立并行子任务
• 上下文溢出是真问题
• 需要领域专用 agent 同时工作
• 单次串行会话太长无法维持质量

四种 Swarm 模式

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

[Claude Opus 4.8 Orchestrator]
  +-- [Kimi Research Agent × N]
  +-- [Kimi Data Agent × N]
  +-- [Kimi Code Agent × N]
[Claude Opus 4.8 Synthesizer]
  → Final Output

模式 2：批评-优化循环

[Kimi Builder] → draft → [Claude Opus Critic] → feedback → [Kimi Builder]
  → (approved) → Final Output

适合：代码生成、技术写作、合规输出。必须设最大迭代限制。

模式 3：层级式

[Claude Opus - 战略编排器]
  +-- [Kimi Swarm - 研究组（50 agents）]
  +-- [Kimi Swarm - 构建组（50 agents）]

适合：大型企业工作流。

模式 4：Claw Groups（异构 Swarm，研究预览）

[Kimi K2.6 Coordinator]
  +-- [Claude Opus - 推理专家]
  +-- [Llama 3.3 本地 - 成本敏感批量任务]
  +-- [Kimi K2.6 agents × N - 执行层]
  +-- [人类审核员 - 审批检查点]

关键 Prompt 模板

任务分解（编排器）

You are a task architect. Decompose this goal into independent, parallelizable subtasks.
Rules:
- Each subtask must be completable by a single specialized agent in isolation
- Subtasks with dependencies must be marked with their dependency chain
- Output as JSON: {task_id, description, agent_type, depends_on, success_criteria}

Goal: {user_goal}
Available agent types: researcher, analyst, coder, writer, verifier

专用 Agent 系统提示

You are a {ROLE} agent specializing in {DOMAIN}.
Task: {subtask_description}
CONSTRAINTS:
- Return ONLY valid JSON matching: {output_schema}
- Do NOT go beyond your task scope
- If you cannot complete: {"error": "reason", "partial_results": [...]}
- Maximum tool calls: {max_tool_calls}
Context: {context_from_orchestrator}

聚合提示

Synthesize research from {n} specialized agents into a coherent output.
1. Read all provided agent outputs
2. Identify where they agree, disagree, or have gaps
3. Produce a {output_type} integrating all findings
4. Call out inconsistencies explicitly - do not silently resolve contradictions
Agent outputs: {agent_outputs_as_json}
Output format: {final_output_spec}

Guardrails 清单

1. 每 agent 最大迭代次数：硬限制，超限通知编排器
2. 会话超时：N 分钟未完成则终止，返回部分结果
3. 结构化输出强制：中间 agent 必须返回 JSON，散文会导致下游解析失败
4. 故障隔离：失败的 sub-agent 不能拖垮编排器
5. 指数退避重试：处理 429 和瞬态错误
6. 人工检查点：写操作（部署代码、发邮件、API 变更）前强制审批
7. 成本监控：设每次运行 token 预算，失控循环先在成本上暴露

入门建议

从三 agent 管线开始（规划 + 并行执行 + 验证），小到一下午能调试完，大到能跑真实任务。

架构不是难点。难点在于"测试通过"和"凌晨 3 点无人值守仍能运行"之间的差距——那个差距全在 guardrails、可观测性和 memory 设计里。

---

来源: Avid @ X