Kimi Agent Swarm：100 个并发子 Agent 同时打到你的 API 网关时会发生什么

单 Agent 模型存在结构性上限。当任务需要调研 100 家公司、综合 40 篇研究论文或并行运行多角色专家评审时，单个 Agent 会撞上 context 窗口的天花板并开始退化。Kimi Agent Swarm 是 Moonshot AI 给出的答案：一个自组织系统，单次任务最多部署 100 个并行子 Agent，执行超过 1,500 次工具调用，比顺序执行快 4.5 倍。

对于在 Kimi API 上构建应用或设计多 Agent 架构的团队，这不只是一个产品功能——它是一个强制信号，迫使你重新审视 routing 策略、限流预算和单任务计费归因的整体设计。

发生了什么

Moonshot AI 以早期研究预览的形式推出了 Kimi Agent Swarm，初期向高级订阅用户开放。系统运行在 Kimi K2.5 之上，引入了一个自组织编排层：面对复杂任务时，系统会生成一个 Agent 层级结构——一个"CEO" Agent 负责招募专职子 Agent、分配工作范围并汇总输出。

官方公告中的关键数据：

• 单次任务最多 100 个子 Agent 并行运行
• 单次任务执行超过 1,500 次工具调用
• 比顺序单 Agent 执行快 4.5 倍

这一架构规避了单 Agent 在长程任务中因 context 压缩导致的性能退化问题。它不是把历史记录折叠进不断缩小的 context 窗口，而是将工作分发给多个独立 Agent，每个 Agent 都有全新的 context 预算。

为什么 AI 工程团队需要关注

从单 Agent 到 Swarm Agent 的转变，颠覆了大多数 API routing 架构赖以成立的几个基本假设。

并发峰值成为一等公民。 单个用户请求现在可以产生 100 个并发 API 调用。如果你的 routing 层或 provider 账户的限流配置是按顺序工作负载校准的，一次 Swarm 任务会立刻打满它。团队需要按单任务建模峰值并发，而不只是按用户建模。

计费归因变得更难。 当 100 个子 Agent 各自消耗 token 时，单个用户任务的成本不再是一条账本记录。如果没有按 Agent 打标签或按任务聚合成本，你就无法判断哪类任务昂贵、哪类不昂贵。

Provider 限流隔离变得更重要。 如果子 Agent 共享同一个 API key 并命中同一个限流桶，单次 Swarm 任务就能饿死其他工作负载。"按工作负载类型使用独立 API key"这个原本可选的最佳实践，现在变成了必选项。

这个模式具有普遍性。 Agent Swarm 是 Kimi 的实现，但"编排器通过 API 生成并行 worker"这一架构模式已经出现在 OpenAI Codex、Claude Managed Agents 以及自定义的 LangGraph/CrewAI 部署中。无论使用哪家 provider，构建多 Agent 系统的团队都面临同样的 routing 和计费挑战。

Router/Operator 视角

多 Agent 架构暴露了三个单 Agent 场景中很少出现的 routing 问题：

1. 突发并发 routing。 Swarm 任务是一个突发事件。你的 routing 层需要在不到一秒内处理 10–100 个请求的扇出，将它们路由到正确的 provider，并遵守各 provider 的并发限制。如果你路由到一个 10 RPM 限制的 provider，100 个 Agent 的 Swarm 在没有队列或 provider 级扇出逻辑的情况下会立即失败。

2. 按任务成本核算。 每个子 Agent 调用都需要携带一个共享的任务标识符，这样你才能在任务层面聚合 token 用量、延迟和成本。没有这个，你的计费面板只会显示 1,500 条独立请求，无法追溯到发起它们的用户任务。支持请求打标签或自定义元数据透传的 routing gateway 能让这个问题变得可处理。

3. 部分失败的 fallback 策略。 在 100 个 Agent 的 Swarm 中，部分子 Agent 必然会失败——限流、超时、provider 错误。编排器需要 fallback 策略：在另一个 provider 上重试、优雅降级或中止任务。这是 routing 层的关切，不只是应用层的关切。如果你的 gateway 能透明地处理重试，编排器就不需要自己实现 provider 特定的 fallback 逻辑。

采用 Swarm 风格 Agent 的团队决策框架：

• 审计每个 provider 当前的限流余量。100 个 Agent 的 Swarm 至少需要 100 RPM 的持续容量。
• 在每个请求的 header 或元数据字段中加入任务/作业 ID。这是成本归因的最低限度埋点。
• 为 Swarm 工作负载和交互式工作负载分配独立的 API key（或 routing 命名空间）。Swarm 任务不应该能饿死实时用户请求。
• 定义单任务成本上限。没有预算上限，一个配置错误的 Swarm 任务可以在几分钟内消耗一天的 token 预算。

TheRouter 用户应该关注或尝试什么

通过 TheRouter 路由 Kimi API 流量的团队，可以利用请求元数据为 Swarm 任务打上任务 ID 标签，从而在计费账本中实现按任务聚合成本。如果你在任何 provider 上构建多 Agent 系统，同样的模式都适用：通过 routing 层传递稳定的任务标识符，让下游的成本和延迟数据能够汇总到任务层面，而不只是单个请求层面。

更大的信号是：多 Agent 架构正在从研究演示走向生产工作负载。适用于单 Agent 顺序 API 调用的 routing 和计费基础设施，随着 Swarm 风格执行成为复杂任务的默认模式，需要被重新审视。

关注 Kimi 何时将 Agent Swarm 开放给更多用户，以及是否通过 Kimi API 暴露 Swarm 编排原语——届时上述并发和计费影响将直接关系到所有路由到 api.moonshot.cn 的团队。