一个研究员把 40 篇学术论文丢给 Kimi 的 Agent Swarm 功能，用一个提示词，产出了一份 10 万字的文献综述。
这不是开玩笑。这是当前 AI agent 并行化处理能力的一个具体案例。
什么是 Agent Swarm
Kimi 的 Agent Swarm 是一个内置的并行 agent 调用功能。它不是让你手动启动多个 agent，而是：你发一个提示词，系统自动把任务分解、分配给多个子 agent 同时执行、最后合并结果。
对于 40 篇学术论文这个案例，它的实际工作流程是：
- 系统读取 40 篇论文的标题和摘要
- 同时启动多个子 agent，每个子 agent 负责处理其中几篇
- 每个子 agent 提取自己负责的论文里的关键信息：研究问题、方法论、核心结论、局限性
- 结果汇总到一个主 agent，生成最终的综合文献综述
你不需要等第一篇处理完再处理第二篇。40 篇同时处理。
这就是"300 个并行 agent"在实践中的意义：不是同时跑 300 个完全独立的 agent，而是系统能够根据任务规模自动扩展并行度。
Agent Swarm 的实际应用场景
Agent Swarm 不是只有一个用法。这个功能最强大的地方在于它把"规模化"变成了一个零技术门槛的操作。
场景 1：100 份职位 JD → 100 份定制简历
如果你是一个招聘者，你需要为一个职位写 100 份不同的 recruitment email。传统做法是写一个模板然后改。或者你雇一个人来做这件事。
用 Agent Swarm，你只需要发一个提示词："为这 100 份职位 JD 各写一封定制 recruitment email"。系统自动分解任务，并行生成，合并输出。
场景 2：40 篇学术论文 → 10 万字文献综述
这是对研究者最有价值的场景。系统性文献综述通常需要几周时间——先找论文、读论文、提炼观点、归类、分析。这 40 篇论文如果串行处理，可能需要几天。但并行处理加上最后的综合生成，可能在几小时内完成。
场景 3：30 家线下门店 → 30 份运营分析报告
每个门店有自己独特的问题和客群。Agent Swarm 可以同时处理 30 家门店的数据，分别生成分析报告，每个报告都是基于该门店的数据量身定制的。
技术指标值得关注
Agent Swarm 的底层模型在 SWE-Bench Pro 上得分 58.6%。对比参考：Claude Opus 4.6 的得分是 53.4%。
成本方面：**每百万输入 tokens 5.00/百万——便宜了 8 倍以上。
这两个数字加在一起说明一个现实：并行 agent 执行的成本，第一次变得对普通用户来说可以接受。不再是大公司的特权，而是任何人都可以使用的能力。
为什么大多数 Kimi 用户没用过这个功能
Kimi 的 Agent Swarm 入口在左侧边栏。但根据作者观察，大多数 Kimi 用户从来没有点击过这个按钮。
这不是因为功能隐藏——而是因为用户不知道自己需要这个功能。大多数人用 Kimi 的方式还是"一次一个任务"的思维模式：你问一个问题，Kim i回答一个问题。但当你有一批需要同时处理的任务时，这个功能就变得非常有价值了。
使用 Agent Swarm 的前提是你先要有"批量思维"：当一个任务可以拆分成多个相似子任务时，才值得用并行 agent。不是所有任务都值得并行——对于只需要一个答案的问题，标准对话更高效。
Agent Swarm vs 传统 API 调用的核心差异
如果你想用代码实现类似的并行 agent 能力，你需要处理：任务分解逻辑、agent 调度、结果合并、超时处理、重试机制。这些都不是小事。
Agent Swarm 把这些全部封装成了一个按钮。你只需要描述你想要什么，系统决定怎么拆、怎么跑、怎么合并。
这对于不懂技术但有真实需求的用户来说，是一个很大的门槛降低。
什么任务适合 Agent Swarm
适合的场景：
- 多个相似但独立的子任务（简历生成、门店分析、论文处理）
- 每个子任务的输入和输出格式相对标准
- 任务的总处理量很大，单个 agent 会很慢
不太适合的场景：
- 强逻辑依赖的任务（需要先有 A 的结果才能做 B）
- 需要深度对话和迭代的任务
- 输入输出格式高度非标准化的创意任务