三周前，我写了一篇关于 Kimi K2.6 的介绍，称其为大多数人都低估了的模型。
文章发布后，很多人尝试了它，其中一半人回来问了同样的问题。
"好吧，但我到底要怎么用这个东西来做真正的工作？"
这就是答案，比上一篇介绍更深入，少一点表面，多一点实战技巧。
新功能、大多数操作用户不知道的四种模式、今天就能复制测试的提示词，以及还没人写过的使用案例。
如果你读过第一篇文章，这就是你想要的那个后续；如果你没读过，你也会很快跟上。
快速回顾一下……
Kimi K2.6 是 Moonshot AI 于 2026 年 4 月 20 日发布的开源模型，完全免费，API 输入每百万 token 约 0.55-0.80 美元，根据输出量不同，完成相同工作比 Claude 便宜约 7-10 倍。
其技术亮点是 300 个子 Agent 并行执行 4000 个协调步骤。
这就是 Agent Swarm：一条提示 → 数百个 Agent 同时工作，一个协调器合并结果。
这个数字是大多数文章停下来的地方，但真正的故事在于这个架构存在的根本原因。
为什么单 Agent AI 已经触及结构性天花板
这是 Moonshot 的框架，不是我的，而且它比任何教程都更一针见血。
三年来，AI 行业一直在打磨这把锤子：更快的推理、更长的上下文、更便宜的 token。每次发布都只是让工具变得更好一点。
问题是，木匠仍然只有两只手，一天只有二十四小时。如果瓶颈从来就不是锤子，那更好的锤子也无济于事。
这是大多数人忽略的部分：让一个单 Agent 深度研究工具去调查一百家公司或综合几十篇论文。
随着任务的拖延，上下文窗口被填满，系统不得不依靠历史折叠或摘要来为新 token 腾出空间。
这种压缩是有损的，后续的每一个推理步骤都会变得更差。
这不是一个 bug，也不是暂时的限制。这是单 Agent 顺序执行模型本身所强加的结构性天花板。你无法通过更智能的模型来解决它。你只能通过放弃这个架构来解决它。
这就是 Agent Swarm 的意义所在：不是更好的单 Agent，而是对整个工坊的重构。
K2.5 有 100 个子 Agent 和 1500 个协调步骤。K2.6 有 300 个子 Agent 和 4000 个步骤。
在长期任务上，实际结果比顺序 Agent 执行相同工作快 4.5 倍，最终质量更高，因为 Swarm 在结构上避免了导致单 Agent 崩溃的上下文坍塌。
这些数字是真实的，它们之所以重要，是因为瓶颈已经转移了。
Agent Swarm 是一个自我设计的组织
Moonshot 研究文章中几乎没人引用的一句话：
"这不是关于许多 AI Agent 一起工作的故事。我们正在构建的是一个具有老板、员工和分工的组织结构，只不过这个组织不是由人类设计的。它自我设计。"
当你给 Agent Swarm 一个目标时，你不是在指挥一个助手。你是在雇佣一位 CEO。这位 CEO 然后自行找到研究员、分析师、事实核查员——全部自动完成。
你不需要微观管理。你不需要挑选团队。你定义可交付成果，Swarm 则构建交付所需组织。
🚨 好吧，这是 Agent Swarm 在回答简单问题"展示你能做什么"时给出的答案
这种自我组织才是真正的解锁点。市场上其他所谓的"多 Agent"系统，都是你事先设计好的固定循环中 LLM A 调用 LLM B。
Kimi 的 Swarm 每次从头开始构建组织架构图，大小与面前的工作匹配。
Swarm 的实际运作方式
当你提交一个 Swarm 任务时，后台会发生五件事。
分解。协调器将你的目标分解为领域专业化的子任务。研究交给研究 Agent，综合交给综合 Agent，写作交给写作 Agent。
Agent 匹配。每个子任务根据技能和工具被路由到最合适的子 Agent。这种路由是 K2.6 在 Swarm 模式下于 BrowseComp 上达到 86.3%（K2.5 为 78.4%）的原因——同样的工人，更智能的调度。
并行执行。所有子 Agent 使用各自独立的上下文窗口同时工作，这消除了导致单 Agent 运行崩溃的上下文坍塌问题。
故障恢复。当子 Agent 卡住时，协调器会重新路由和重新分配。Swarm 在运行过程中自我修复。
综合。输出合并为一个连贯的可交付成果，矛盾得到解决。
还有第六件事没人谈到：结构性分歧。独立的 Agent 在重叠问题上自然得出不同结论，协调器强制进行调和，从而在结构上避免群体思维。这就是为什么 Swarm 的输出往往感觉比单个模型生成的更犀利。
Moonshot 自己的例子证明了这一点：Swarm 将分散在个人网站和档案中的 200 多篇 Paul Graham 文章提取出来，整理成 6 个主题文件夹并附带完整摘要报告——一条提示。
另一次运行找到了 100 个小众 YouTube 领域中的前 3 名创作者，自己定义每个领域后再分派 100 个并行子 Agent。
两种模式都一样：一堆需要查找或处理的东西，每个项目都是独立的。这就是最佳用途。对于需要步骤 N 依赖步骤 N-1 的顺序任务，请保持在单 Agent 模式。
Swarm 实际运作方式的第四点。Instant 用于快速查询，Thinking 用于分析和复杂代码，Agent 用于中等自主任务（如 10 页报告），Agent Swarm 仅当工作真正可并行化时才使用。大多数操作用户默认使用 Swarm，为从未使用过的并行付费。将模式与任务规模匹配。
三个未被充分利用的功能以及如何利用它们
在 /swarm 之前运行 /plan，几乎没人教这个。
/plan 会在任何工作开始前精确显示 Kimi 将如何把你的任务分解为子 Agent 和步骤。
你看到计划，如果 Agent 错了就调整，然后提交。
零成本；一个 200 个 Agent 的 Swarm 如果分解错误，则需支付真实费用。
文档转技能：上传你最好的作品——一份精炼的报告、一个着陆页、一个促成交易的演示文稿。Kimi 会捕获结构和风格特征，作为可复用的技能，未来所有 Swarm 都会自动应用。它就在菜单里，但几乎没人用。
编码驱动设计：同样的提示，两种不同的结果。Claude 默认使用干净的模板化布局。Kimi 首先将 UI 视为编码问题，配合 MoonVIT 编码器，生成感觉精心设计的编辑布局。
用"设计 The J 酒店的着陆页"提示两者。Claude 返回带有金色点缀的居中预订表单（海军蓝背景），看起来像每个 AI 酒店页面。
Kimi 返回一个左对齐的编辑布局，带有温暖的英雄照片，"预订住宿"浮动在图像上，排版感觉经过设计。
如果你大规模交付前端，在流程的那部分切换到 Kimi。
今天就可以构建的六件事：
多阶段市场进入策略，一次运行生成 PDF、Excel 和 PowerPoint。
比较性学术深度研究，提取 24 个月的相关论文成为 40 页分析报告。
基于原始 CSV 并整合宏观数据的金融仪表板。
内容库审计，用一致风格重写 50 篇旧文章。
以 300 个潜在客户规模的外联，而不是 30 个顺序进行。
长期代码重构，将 50,000 行遗留代码库按模块拆分，在 24-36 小时内自主运行。
今天要测试的三个真实提示：
这些是专业级别的——范围锁定、来源规则、错误处理和阈值条件——不是那些充斥时间线的通用提示。
测试 1：Agent Swarm 并行研究
将 Kimi 切换到 Agent Swarm 模式，然后粘贴这个。
你应该看到的是：Swarm 将研究任务拆分为多个 Agent，每个 Agent 并行从不同来源提取信息，然后合并为一个干净的可交付成果。对比手动完成这个任务的时间。
测试 2：文档转技能
找到你最好的专业作品——一份报告、提案、演示文稿，任何你引以为傲的东西。上传它并粘贴这个。
你应该看到的是：一个关于完全不同主题的新文档，感觉像是同一位作者写的。这是大规模生成优质输出的解锁点。
测试 3：Swarm 验证的计划模式
在运行任何昂贵的 Swarm 之前，测试分解。
你应该看到的是：Kimi 在投入资源之前，精确展示它将如何攻击这个任务。这是在启动一个 200 个 Agent 的 Swarm 之前能买到的最便宜的保险。
以及最重要的部分之一 | 成本真相，实话实说
一些粗略的数字供你参考：
Kimi 的免费层提供 Instant 和 Thinking 模式。Agent 和 Agent Swarm 需要 Allegretto 计划，不过说实话，我觉得值得。
API 定价约为输入每百万 token 0.55-0.80 美元，输出每百万 token 2.65-3.60 美元，具体取决于端点和路由。
大约比 Claude Opus 完成相同工作便宜 7-10 倍。
一个 100 个 Agent 的研究运行，生成 40 页带有引用的报告和结构化数据集，通常花费 2-6 美元的 token。
同样的工作通过 Claude Code 和手动编排进行，成本为 30-80 美元，并且需要三倍的时间。
如果硬件足够，自托管是免费的，权重在 Hugging Face 上以 Modified MIT License 发布。
—— Leo
