我连续两周在生产环境中并行运行了 Kimi K2.6 的 Agent Swarm 和 Claude Opus 4.8 的 Dynamic Workflows。有趣的部分不在于"哪个更好"。它们在 SWE-Bench 上的得分不相上下（80.2 对 80.8）。有趣的是，它们的弱点完全相反，这使得它们能组合成一种两者单独都无法实现的能力。
这篇文章包含了完整的流程、提示词，以及 5 个你今天就能上手的用例。全部拿去用吧。
核心思想一句话概括
Kimi 的 swarm 覆盖面广且成本低廉。Opus 4.8 则深入且昂贵。所以，让 swarm 生成所有候选方案，而你只把 Opus 用在对抗性地剔除那些错误的方案上。
为什么这个方案特别有效：
Kimi 的 swarm 能生成多达 300 个子 Agent，它们会自动分解任务：无需 LangGraph、无需 CrewAI、无需手动编排工作流。这是模型内置的能力。它在宽泛任务上速度快约 4.5 倍，成本约为输入每百万 token $0.60、输出每百万 token $2.50，缓存还能削减 75-83% 的成本。你完全负担得起让它"浪费"一点。
它已知的缺陷是：如果你没有明确要求验证，它会产生引用不足、过度自信的结论，并且子 Agent 之间会相互矛盾。
Opus 4.8 则恰恰相反。它的 Dynamic Workflows 会编写一个编排脚本，运行从独立角度攻击问题的子 Agent，然后部署对抗性 Agent——它们唯一的任务就是反驳已有的发现，并不断迭代直到答案收敛。这是第一个在"不加批判地报告有缺陷结果"这项测试中得分为 0% 的 Claude。它的过度自信程度比 4.7 低了约 10 倍。
它的成本是：单次运行可能生成多达 1000 个 Agent，所以你肯定不希望它去做宽泛的搜索。你希望它去做的是"终结"工作。
大家都在问的那个问题，其实问错了
"我该用哪个模型？"听起来像是个聪明的问题。但它不是。
它暗含了一个假设：你必须与一个模型"结婚"，而与另一个"离婚"。你不需要。
2026 年产出最多的开发者们已经不再思考模型，而是开始思考角色。一个作家不会在打字机和编辑之间二选一。他们会在不同的时刻，为了不同的工作，同时使用两者。
这就是全部的秘密。那么，让我来介绍这两个角色。
认识引擎：为什么 Kimi K2.6 悄然改变了游戏规则
如果说这个工作流有一个明星，那就是 Kimi。而且你越看这些数据，就越觉得它不像是一次升级，更像是一个作弊码。
它的价格几乎可以忽略不计。 官方价格是输入每百万 token $0.95，输出每百万 token $4.00。这大约是高端模型输入端的 5 倍便宜，输出端的 6 倍便宜。甚至还有免费的上手途径：你现在就可以在 kimi.com 上使用它，并通过 Cloudflare Workers AI 的每日免费额度来运行。当尝试新事物的成本降到如此之低时，你就不再会吝啬自己的想法。你只管去执行它们。
它不会疲倦，而且它从不单打独斗。 这是大多数人还没意识到的一点。Kimi 的 Agent Swarm 可以在一次自主运行中启动多达 300 个专门的子 Agent，并在大约 4000 个步骤中协调它们，这是其上一版本能力的三倍。其他所有助手都是一个工人一次只做一件事。Kimi 则是一个协调者，同时将任务分派给几十甚至几百个工人，然后合并结果。
当你放开它时，效果是这样的：
- 人们在一小时内就能生成一个小型代理机构的工作量：找到网站薄弱的本地企业，为每个企业构建一个落地页草稿，撰写外联邮件，并生成一份市场报告——全部来自一个简单的指令。
- 开发者们在一个下午就能将数千行经过验证的数据拉入一个干净的电子表格中，每一行都对照真实来源进行了检查，而这项工作如果交给单个 Agent 需要花费大半天时间。
- 在一次广为流传的运行中，Kimi 被指向一台笔记本电脑上的一个小模型，并被要求让它跑得更快。它在无人值守的情况下运行了 12 小时，执行了超过一千次工具调用，重写了数千行代码，将吞吐量从大约每秒 15 个 token 提升到了近 200 个。全程无需人工干预。只有一个目标。
它也是开源的， 采用修改后的 MIT 许可证发布，并附带一个配套的 CLI 工具，开发者们已经在 GitHub 上为它点了数千星。你不是在租用一个黑盒的访问权。你是在一个你可以检查、托管和构建的东西之上进行开发。
Kimi 就是引擎室。它负责跑量。它运行 swarm。它把"我希望我能试试十个版本"变成了"我在午饭前就试了十个版本"。
但是，一个无人驾驶的引擎只会朝着错误的方向狂奔。而这正是第二个角色登场的地方。
认识终结者：Opus 4.8 的价值所在
如果说 Kimi 负责跑量，那么 Opus 4.8 负责抓错。
Anthropic 这次发布的核心卖点不是某个基准测试。而是"诚实"。据报道，Opus 4.8 让其前代产品更容易放过自身代码中的缺陷而不标记的可能性降低了大约四倍。它虚张声势的次数更少，并且更愿意说"这部分不太可靠"。
在高吞吐量的工作流中，这一特质价值连城。当一个 swarm 产出了堆积如山的工作成果时，你需要的不是另一个不知疲倦的建造者。你需要一双敏锐、怀疑的眼睛来告诉你真相。在你最需要确保质量的方面——生产级精度，以及对文档和视觉内容的高保真解读——Opus 也往往更胜一筹。
它还能为流程的前端带来判断力，即一个良好的架构决策能避免在错误方向上浪费十个小时工作的那个环节。它拥有非常大的上下文窗口，这意味着在写下一行代码之前，它就能将整个问题纳入考量。
它是高级审查员。是架构师。是你信任的那个人，他会审视引擎产出的所有东西，然后冷静地说："这个可以发布，但那个得先修好。"
正面交锋：Opus 4.8 vs Kimi K2.6
这是每个人都想看，但几乎没人会诚实写出来的部分。
Anthropic 让 Opus 4.8 实现了真正的飞跃：更敏锐的判断力，他们制造过的最诚实的模型，在最难的编码和推理测试中获得了最高分。确实是出色的工作。
与此同时，Kimi K2.6 悄无声息地做了一件让人难以反驳的事。它的 Agent 承担着同样的实际工作，在大部分任务上交付的结果并不比前者差多少，而成本却只有几分之一。对于大多数人日常交付的东西来说，输出质量的差距很小，而价格的差距却很大。
以下是两者逐项对比的结果：
- 每 token 价格。 Opus 4.8 是输入每百万 token $5，输出每百万 token $25。Kimi K2.6 是输入每百万 token $0.95，输出每百万 token $4.00，整体便宜约 5 到 6 倍。
- 模型权重。 Kimi 是开源的，采用修改后的 MIT 许可证，因此你可以自行托管。Opus 是专有的。
- 规模和上下文。 Kimi 是一个 1 万亿参数的模型，拥有 256K 的上下文窗口。Opus 拥有 1M 的上下文窗口。
- Agent。 Kimi 的亮点是 swarm：在一次自主运行中，多达 300 个子 Agent 在大约 4000 个步骤中进行协调。Opus 通过 Dynamic Workflows 运行并行的子 Agent。
- 接受的输入。 Kimi 接受文本、图像和视频。Opus 接受文本和图像。
- 最难的编码测试（SWE-bench Verified）。 两者得分都很高。Kimi 在 80 分出头，Opus 略高一点，在 80 分末段。
- 各自最擅长的领域。 Kimi：成本、并行处理能力和开放性。Opus：诚实度、判断力和精确度。
诚实地看待这些数据，结论不是"Kimi 赢了"或"Opus 赢了"。而是它们在不同的领域获胜。一个是你追求绝对正确时使用的精密仪器。另一个是负责跑量、运行 swarm、且几乎不占用你预算的引擎。这正是为什么明智之举不是选边站队，而是让每个模型都发挥其最强的作用。
工作流：规划、群涌、评判、交付
这部分值得保存。四个步骤，两个模型，清晰的交接。
1. 用 Opus 4.8 进行规划（思考环节）。
向 Opus 描述整个问题，并要求它进行架构设计，而不是执行。结构是什么？风险是什么？最清晰的路径是什么？然后，向它索要一件具体的东西：一份书面规范（稍后会解释为什么这很重要）。你在这里有意地花费高级 token。这是你买过的最便宜的一小时，因为它能防止代价高昂的错误。
2. 用 Kimi K2.6 进行群涌（执行环节）。
将规范交给 Kimi，让引擎运转起来。这是产生大量成果的地方：生成代码、编写测试、起草各种变体、跨文件进行重复性的构建工作。让 swarm 并行化处理这些苦差事。因为它非常便宜，你不用担心把第一次尝试扔掉重来。这个阶段以极小的成本完成了 80% 的工作。
3. 用 Opus 4.8 进行评判（说真话环节）。
将 swarm 产出的所有东西反馈给 Opus，并提出那个关键问题：这里面有什么问题？这就是它的诚实度物有所值的地方。它能发现隐藏的缺陷、未经证实的假设、那些看似正确实则不然的东西。你不是在支付高价来生成内容。你是在支付高价来验证内容，这是花高价 token 最有杠杆作用的方式。
4. 回到 Kimi K2.6 进行交付（循环环节）。
拿着 Opus 的笔记，交给 Kimi，让引擎以近乎零成本进行修复和打磨。然后交付。由于在 Kimi 这一端循环成本极低，你明天、后天都可以再次运行，而不用担心费用飙升。
用架构师来规划。用引擎来构建。用说真话者来评判。用引擎来交付。重复。
真正的解锁秘诀：写一份规范，而不是一个提示词
这就是区分那些能从 swarm 中获得魔法的人和那些只能得到昂贵垃圾的人的诀窍。
当大多数人听到"300 个 Agent"时，他们会发出一行提示词，比如"抓取美国所有的数据中心"，然后期待奇迹发生。这是最快烧光额度并得到垃圾结果的方式。
真正的解锁秘诀是把 swarm 当作一个承包商，而不是一个神灯精灵。你不是给它一行指令，而是给它一份两三页的文档，明确定义要收集什么、什么算有效、哪些来源是可接受的、输出格式应该是什么、以及当发现冲突信息时该怎么做。你不是在写一个提示词。你是在写一份规范，而 swarm 会在你去做其他事情的时候，根据这份规范来执行。
现在，这两个角色完美地结合在一起了：世界上编写这份规范的最佳工具，就是你那个谨慎、明智的模型。Opus 4.8 在 PLAN 步骤中将一个模糊的目标转化为精确的规范。Kimi 的 swarm 在 SWARM 步骤中大规模地执行该规范。思考者下达命令。大军执行命令。
那些说 Agent swarm "脆弱"的人，几乎总是意味着他们的提示词很脆弱。基于规范的工作方式彻底改变了结果。
拿去用吧，这是你的架构师编写规范的框架：
把它交给引擎，然后你就可以走开了。
今天就运行这个循环：3 个可以直接用的提示词
你不需要一个大项目来尝试这个。随便找一个你通常会扔给单个模型的任务，用下面这三个提示词跑一遍。填上括号里的内容，然后开始。
提示词 A. 规划（粘贴到 Opus 4.8）
1我想 [用通俗的语言描述你的目标]。2先不要构建任何东西。扮演架构师的角色。3使用以下标题将其转化为一份精确的规范：4目标、范围、规则、来源、输出、停止条件。5在完成之前，指出计划中两个风险最大的假设。
提示词 B. 群涌（粘贴到 Kimi K2.6）
1这是一份规范。从头到尾执行它。2尽可能并行化，然后将所有结果合并到下面定义的最终 OUTPUT 中。3除非规范确实自相矛盾，否则不要问我问题。4[粘贴来自提示词 A 的规范]
提示词 C. 评判（粘贴到 Opus 4.8）
1这是一份规范，以及一个 swarm 根据该规范产生的输出。2保持怀疑态度。你的工作是找出问题所在，而不是赞美它。3列出每一个缺陷、未经证实的声明和隐藏的漏洞，按严重程度排序，4然后给我一个简短的修复清单，我可以直接交回给构建者。5[粘贴规范和输出]
然后，将提示词 C 的修复清单带回给 Kimi，让它修补所有问题，然后交付。这就是循环的一个完整回合，而且再次运行的成本几乎为零。
让你的 CFO 笑逐颜开的数字
这就是为什么这个方案不仅优雅，而且在经济上是显而易见的。
在一个天真的工作流中，你所有操作都使用高级 token。每一次废弃的草稿、每一次测试、每一个愚蠢的实验，都是全价。
在这个工作流中，昂贵的模型只触及两个真正需要判断力的时刻：规划和裁决。中间的一切，占 token 用量 80% 的"执行工作"部分，都由成本低几倍的模型来运行。
你并没有降低质量。你只是削减了那些本就不需要昂贵的部分的价格。
这就是团队如何悄无声息地将 AI 账单削减一大截，同时增加交付量的方法。不是通过减少购买。而是通过精明地购买。
为什么这个组合胜过任何一个单独的模型
更深层的原理比 AI 本身更古老：比较优势。
让不知疲倦的廉价引擎负责跑量。让谨慎的高级大脑负责判断。不要让你最昂贵的思考者去做苦力活，也不要让你最快的建造者拥有最终决定权。
单独一个模型必然导致妥协。全用高级模型会在不需要的任务上烧钱。全用廉价模型则面临交付无人发现的缺陷的风险。双模型循环完全拒绝了这种妥协。它同时获得了廉价模型的经济性和谨慎模型的良知。
这不是什么 hack。这只是良好的劳动分工，终于可以在软件中实现了。
一个会悄然毁掉这个工作流的错误
跳过 JUDGE 步骤。
这是最诱人的偷懒之处，因为 swarm 的输出通常看起来已经完成了。它能编译。它能运行。感觉像是做完了。
"看起来完成了"和"是正确的"是两个不同的星球，而这个工作流之所以安全，完全是因为你指派了一个谨慎、诚实的模型来告诉你两者之间的区别。为了省几分钟而砍掉这个步骤，你就把一个出色的系统变回了一个快速交付 bug 的工具。
只有当有值得信赖的东西在检查工作时，廉价的大规模产出才是一种超能力。保留评判者。
总结
在一个关于哪个模型"最好"的争论越来越激烈的年份里，一个安静的真相几乎有些好笑。原来最好的模型是两个，每个都指向它天生就适合的工作。
Kimi 负责跑量。Opus 负责抓错。一份好的规范是连接它们的桥梁。
还在争论的人会继续争论。你现在有了一个工作流。
去构建那个下个月会让他们写满帖子讨论的东西吧。
保存这篇文章 🔖。
