我为 Opus 4.8 配备了 300 个 Agent，仅用一个下午就构建了一个可用的 SaaS

一个模型负责思考，三百个模型负责执行。这就是当你不再把 AI 当作聊天机器人，而是当作组织架构图来使用时会发生的事情。

300 个并行 Agent → 每次运行 4,000 步 → 1 个下午 → 0 行手动输入的代码

所有人还在争论哪个聊天机器人最聪明。他们回答的是一个已经不再重要的问题。

两年来，游戏规则一直是在一个聊天窗口中使用单个模型。你打字，它回答，你再打字。现在真正的问题不是 哪个模型回答得最好。而是 你能同时运行多少个，以及谁来负责管理它们。

所以我做了一个实验。我用了 Claude Opus 4.8 来做它世界上最擅长的一件事：思考、规划、决策、检查工作。然后我把实际劳动交给了 Kimi Agent Swarm：一次可并行运行多达 300 个子 Agent，一次启动可达 4,000 步。不是聊天中的 4,000 轮对话，而是单次启动。

目标故意不是一个玩具。交付一个可运行的端到端分析 SaaS，包含实时市场数据和销售演示文稿，而且我自己不写一行代码。

如果 Opus 4.8 是建筑师，那么 Kimi Agent Swarm 就是整个施工队。把它们结合起来，你拥有的就不再是一个聊天机器人了。你拥有了一家公司。

为什么单个 Agent 总会撞墙

这是人们对于单个 Agent（即使是非常出色的 Agent）所忽略的一点。它只会直线工作。Opus 4.8 的推理能力几乎胜过地球上任何东西，但如果一项工作包含 4,000 个不同的步骤，它会一个接一个地执行。你会感受到每一秒的等待。这不是质量问题，而是几何问题。

Kimi Agent Swarm 改变了这种几何结构。它不是让一个工人按顺序完成 4,000 步，而是让你同时拥有多达 300 个工人 同时工作。研究 100 家公司不再是 100 次连续查询，而是 100 个 Agent 同时读取 100 个来源，每个都引用一个真实可点击的源。

但只有原始并行而没有计划，只是 300 种偏离任务的方式。没有方向的快速只是噪音。这正是 Opus 4.8 所扮演的角色：它提供计划和审查，而 Swarm 提供吞吐量。两者缺一不可。

大脑规划。双手执行。大脑检查。

该系统分四个阶段运行。使其有效运作的纪律：Opus 和 Kimi 各自只做自己最擅长的事，绝不越界。大脑从不碰扳手。双手从不做决策。

1. 分解 · Opus 4.8 Opus 将一个目标句分解成一个具体的子任务依赖树：模式、数据接入、API、前端、认证、落地页、演示文稿。它还标记了顺序，即哪些必须先完成才能开始其他任务。
2. 调度 · Kimi Swarm 每个叶子节点变成一个子 Agent。Kimi 最多可启动 300 个。数据 Agent 访问 Binance、Yahoo Finance、IMF 和 World Bank 的实时数据。构建 Agent 编写代码。资产 Agent 生成演示文稿。每个 Agent 在其依赖项清除后立即启动。
3. 执行 · 4,000 步并行 在单次启动中，Swarm 产生可运行的代码、填充好的数据库、研究级图表以及可导出的 PDF、PPT、Excel 和网页输出。不同的格式，同一次运行。
4. 审查 · 回到 Opus 4.8 Opus 读回所有内容，对照规范检查每一项，标记偏差，并组装最终产品。判断层保持敏锐，因为它由前沿推理模型拥有，而不是由脚本控制。

最后这个阶段是大多数“投入更多 Agent”的方法所跳过的，这也是它们产生看起来令人印象深刻但实际却是垃圾的原因。只有当真正有判断力的东西签署确认时，这个循环才算闭合。

观看 300 个 Agent 交付一个 SaaS

这是我给 Opus 4.8 开始运行的提示。请仔细阅读，因为其中最重要的一点是它 没有 要求什么。它从未要求 Opus 编写应用程序代码。它要求 Opus 提供一个可由 Swarm 执行的计划。这一限制正是让大脑保持在其职责范围内的关键。

1orchestrator_prompt.md
2Opus 4.8
3# 角色：你是协调者，不是构建者。
4
5目标：交付一个可运行的分析 SaaS 仪表板。
6数据：实时数据源 — Binance、Yahoo Finance、World Bank。
7
8你的工作：
91. 将其分解为独立的子任务
102. 为每个任务编写规范，以便一个 Agent 可以单独运行
113. 标记依赖关系（哪些必须先完成）
124. 将完整的任务树以 JSON 形式输出给 Swarm
13
14# 不要自己编写应用程序代码。
15# 你的输出是蓝图。Swarm 负责构建。

Opus 返回了一个清晰的依赖树，包含大约 40 个任务，分为六个轨道。它知道数据层必须先解析，后端才能查询它，而前端依赖于后端的 API 形状。这个排序不是一个小细节。它是 Swarm 协调构建还是构建出四个不兼容的应用半成品之间的区别。

我把那个 JSON 直接交给了 Kimi Agent Swarm 作为简报。然后我什么也不做，只是看着反馈。

下面是在那四十分钟内实际发生的事情，按轨道展示。有趣的部分不是速度快，而是这些轨道几乎互不等待。

轨道 1 · 数据层

八十个 Agent 同时出发。一些访问 Binance 获取实时加密货币价格，一些从 Yahoo Finance 拉取股票数据，一些从 World Bank 和 IMF 获取宏观序列。每个 Agent 将其切片标准化为相同格式，并写入共享缓存。由于它们并行运行，整个数据接入层在三分钟内就被填充完成。如果是一个 Agent 按顺序进行相同的爬取，大部分时间都会花在网络往返上。

轨道 2 · 后端

数据模式一旦稳定，六十个后端 Agent 就开始工作。它们生成数据库表，编写 API 路由，配置认证中间件，并从数据轨道刚刚填充的缓存中填充表。这正是 Opus 的依赖排序至关重要的原因。后端从不尝试查询一个尚不存在的表，因为 Opus 已将数据轨道标记为硬性前提条件。

以下是后端轨道产生的其中一个路由文件。我没有做任何编辑。这是运行的结果：

1api/quotes.ts
2swarm output
3import { Router } from "express";
4import { cache } from "../lib/cache";
5import { requireAuth } from "../mw/auth";
6
7const router = Router();
8
9// GET /api/quotes/:symbol  ->  latest normalized quote
10router.get("/:symbol", requireAuth, async (req, res) => {
11  const symbol = req.params.symbol.toUpperCase();
12  const hit = await cache.get(`q:${symbol}`);
13
14  if (!hit) return res.status(404).json({ error: "no feed" });
15
16  res.json({
17    symbol,
18    price: hit.price,
19    change24h: hit.change24h,
20    source: hit.source,        // binance | yfinance | worldbank
21    ts: hit.ts
22  });
23});
24
25export default router;

轨道 3 · 前端

九十个 Agent 根据后端刚刚锁定的 API 形状构建了界面。它们搭建了仪表板，连接了实时套接字使价格无需刷新即可更新，渲染了图表网格，并对移动端进行了响应式处理。前端轨道是最大的，因为它有最多独立的部分，而独立的部分正是 Swarm 最擅长处理的。

轨道 4 · 资产

这个轨道让整个过程看起来不公平。在编写代码的同时，另外七十个 Agent 正在构建产品周围的一切。落地页的英雄区域、开放图谱图像、定价表以及一份完整的麦肯锡风格演示文稿，直接导出为 PowerPoint。不是模型，而是完成的可导出文件，与代码库在同一次运行中生成。

在我粘贴任务树四十分钟后，一个可运行的产品摆在了我面前。不是它的草图，而是真的产品。

仪表板通过五个数据源拉取了实时市场数据。它拥有后端、认证层、响应式前端、落地页和一份麦肯锡风格的演示文稿。演示文稿的部分仍然让我惊讶。它不是事后才运行的单独任务。编写 API 的同一个 Swarm 也在同一次运行中渲染了推销产品的幻灯片，因为 Kimi 原生输出 PDF、PPT、Excel、网页和图像。

演示文稿不是事后才想到的。编写 API 的同一个 Swarm 也渲染了推销它的幻灯片。

最后这一点值得单独说明。大多数工具一次只给一种格式。你先生成报告，然后单独生成幻灯片，再单独生成电子表格。Kimi 通过一次运行就能输出所有这些格式：

与通常的做法比较一下。一个 Agent 可能还在第 40 个任务中的第 9 个，幻灯片是下周的问题，而你因为不耐烦已经自己写了一半的样板代码。

这是又一个 DeepSeek 时刻

暂时从构建中退一步，因为战略图景才是真正的故事。

当闭源实验室还在推出单个 Agent 的聊天机器人时，一家估值 200 亿美元 的中国开源实验室推出了一套可并行运行 300 个 Agent 的系统。他们的开源模型 Kimi K2.6 目前位列 OpenRouter 周榜第一。按使用量计算，它现在是世界上使用最广泛的大语言模型。

我们以前见过这种模式。来自中国的开源发布重新定义了闭源前沿以为属于自己的领域，整个领域不得不在一天内重新调整。这发生在 DeepSeek 身上。Agent Swarm 的发布有同样的特征。

而且它并非偶然地在所有地方都很强大。它恰恰在真正的专业工作发生的地方最强：

• 金融和咨询。 默认输出专业图表、热力图、多年报告分析、麦肯锡级别的幻灯片。
• 学术和研究。 LaTeX 公式渲染、带对比矩阵的文献综述、可追溯到源的引用。
• 超出其他工具规模的处理能力。 单次处理超过 200,000 词的上下文、500 页文档、100 表电子表格、100 页演示文稿。
• 可追溯性。 每个数据点都链接到可点击的源。研究级是默认设置，而不是需要你手动开启的功能。

从开始到结束的设置

你不需要实验室或预算来运行这个。你需要正确连接这两个部分，以及一个让每个部分保持其角色的提示。以下是全部内容。

1. 获取大脑 打开 Claude Opus 4.8。这是你的协调者和审查者。它唯一的工作是规划与检查。一旦你让它开始构建，你就失去了让这一切值得的并行性。
2. 获取双手 打开 Kimi Agent Swarm。这里是 300 个子 Agent 所在的地方，也是实际并行执行发生的地方。这是你的吞吐量层。
3. 连接交接 使用上面的协调者提示，让 Opus 输出一个 JSON 形式的任务树。将该树粘贴到 Kimi Swarm 作为简报。依赖标记越清晰，运行就越顺畅。然后让它去执行。
4. 关闭循环 将 Swarm 的输出反馈给 Opus 进行审查。它会捕捉偏差、填补空白并组装最终交付物。跳过这一步，你就会得到没有判断的量，这是唯一真正重要的失败模式。

1handoff.json
2Opus to Kimi
3{
4  "goal": "analytics SaaS, live market data",
5  "tracks": [
6    { "id":"data",    "agents":80, "feeds":["binance","yfinance","worldbank"] },
7    { "id":"backend", "agents":60, "deps":["data"] },
8    { "id":"frontend","agents":90, "deps":["backend"] },
9    { "id":"assets",  "agents":70, "out":["deck.pptx","landing"] }
10  ],
11  "review": "opus-4.8"
12}

前后对比，一览无余

单 Agent 方式

• 4,000 步串行直线
• 一次一种输出格式
• 幻灯片是单独项目
• 每次构建数小时等待
• 你不耐烦地开始输入代码

大脑 + Swarm 方式

• 4,000 步跨越 300 个 Agent
• 一次运行输出 PDF、PPT、Excel、网页
• 演示文稿与代码库一起交付
• 一个下午交付可运行的 SaaS
• 你自己不写一行代码