每天都会发生的事。
把这个收藏好 :)
大多数人使用 AI 的方式，还停留在 2010 年使用 Google 的模式：输入一个问题，阅读答案，再输入下一个问题。一条单线程，一次只喂一个输入。
但一个能够规划和调用工具的模型，并不需要被一次一个地使用。把 100 份 PDF 丢给它，显而易见的做法不是逐个按顺序阅读：而是同时打开 100 个文件，每个文件分配一个阅读器，然后让一个协调员把阅读结果拼接起来。提示词的长度保持不变。工作量在后面展开。你从一条单线程变成了一把扇：一条指令输入，生成一百个工作者，输出一个组装好的交付物。
这就是整个转变的核心，也是在一个周末内读 100 篇论文和在喝杯咖啡的功夫里读完它们的区别。剩下的部分是关于成本计算、设置方法、提示词、仓库、工作流程，以及那些悄悄失灵的地方。
真实的成本画像
这是大多数人还没开始就放弃的地方。他们以为运行 300 个 Agent 一定花费不菲。其实并不会。
以一个真实任务为例：将 100 篇 PDF 研究论文分析成一份带有引用的文献综述。
使用 Claude Opus 4.8 的串行方法： Agent 壁钟时间大约 6 小时，输入标记每百万 5 美元，输出标记每百万 25 美元。根据文档长度，预估成本为 40 到 60 美元。再加上你监督的时间。
使用 Kimi K2.6 Agent 集群的并行方法： 100 个 Agent 同时启动，每个处理一篇论文。协调员负责合并。壁钟时间：12 到 18 分钟。成本：3 到 5 美元。
在同一个任务上，这是 15 倍的速度提升和 10 倍的成本优势。账本根本没法比。
现在把它规模化。分析 50 个支持工单以寻找模式。为 100 封针对特定潜在客户的冷邮件进行个性化定制。将 40 篇学术 PDF 转成一份 10 万字的文献综述并附上引用。抓取 30 家实体店并转化为独立的落地页。这些任务过去任一个都需要要么一个团队的自由职业者，要么一整天的串行工作。
现在只需要一个提示词，一次喝杯咖啡的功夫，花费不到 10 美元。
一个拥有这套工具的独立运营者，不是在和其他独立运营者竞争。他们是在和整个代理机构竞争。
四月份真正发生了什么变化
三件事在同一月发生，让这一切首次成为现实。
Kimi K2.6 于 4 月 20 日发布。 由 Moonshot AI 构建，在修改过的 MIT 许可下开源。该模型原生训练为能够从单个提示词协调多达 300 个子 Agent，跨越 4000 个协调步骤。这是 K2.5 限制的三倍。这种编排能力并不是事后加在聊天界面上的，而是直接内建在模型层中的。总参数量 1 万亿，每个标记激活 320 亿参数，上下文窗口 25.6 万，每次响应最大输出标记 6.5 万。定价：每百万输入标记 0.80 美元，每百万输出标记 3.60 美元。大约比 Claude Opus 4.8 便宜 8 倍。
最重要的几个数据：SWE-bench Verified 上 80.2%，DeepSearchQA 上 92.5%，Terminal-Bench 2.0 上 66.7%，SWE-bench Pro 上 58.6%（与 GPT-5.5 持平）。幻觉率从 K2.5 的 65% 下降到 39%，与 Opus 4.8 的 36% 基本持平。
在实际测试中，K2.6 在 13 小时内自主改造了一个有 8 年历史的金融匹配引擎，迭代了 12 种优化策略，进行了超过 1000 次工具调用，修改了超过 4000 行代码，并实现了 185% 的吞吐量提升。Moonshot 自己的一个团队让它作为一个自主 Agent 连续运行了五天，负责监控、事件响应和系统运维，全程无需人工干预。
Claude Opus 4.8 于 4 月 16 日发布。 子 Agent 的可靠性显著提升。新的 xhigh 努力等级使复杂的 Agent 链更具确定性。SWE-bench Pro 领先，达到 64.3%。视觉能力在分辨率升级后从 54.5% 跃升至 98.5%。在生产代码质量和法律级精确度方面，它仍然是黄金标准。定价仍为每百万标记 5 美元 / 25 美元。
GPT-5.5 于 4 月 23 日发布。 计算机使用能力在 OSWorld-Verified 上跃升至 78.7%，意味着 Agent 现在实际上可以在不崩溃的情况下操作真实的 GUI。长上下文检索达到 74%，而 Claude 在同一基准测试上仅为 32.2%。网络研究在 BrowseComp 上达到 90.1%。定价为每百万标记 5 美元 / 30 美元，但实际每次任务使用的输出标记更少。
模式：一周内出现三个前沿模型，每个都有明确的专长。输家是那些只选了一个并坚持使用的开发者。赢家是那些能将每个任务路由到正确大脑的人。
对于并行 Agent 集群而言，K2.6 是唯一一个从零开始为在如此规模下进行协调而训练的模型，并且其定价让你能够真正使用它。
300 个并行 Agent 实际上是怎样的
这才是最重要的部分。不是规格表，而是实际的交付成果。以下每一个都来自真实用户在 2026 年 4 月运行的真实提示词。
文献综述任务。 上传了 40 篇学术 PDF。输出：一份 10 万字的文献综述，附带完整引用的数据集。40 个 Agent，每人负责一篇论文，通过一个合并步骤进行协调。总运行时间不到 20 分钟。
天体物理学论文转换。 输入一篇天体物理学论文。输出是一份 40 页的研究报告、一个 2 万行的支撑数据集和 14 张达到出版质量的图表。整个输出随后被打包成一个可重用的技能，Agent 系统可以自动将其应用于未来的每一篇天体物理学论文。首次运行耗时 30 分钟。之后，每篇新论文的后续运行只需要 12 分钟，因为该技能捕获了结构。
从谷歌地图到落地页的工作流。 一个提示词：在谷歌地图上搜索洛杉矶目前没有网站的零售店，找出 30 家独特的商家，抓取店面照片和客户评价，为每一家构建一个高转化率的落地页，包含地址、营业时间、针对商家类型定制的价值主张和联系方式。输出：30 个独立的落地页，外加一个列出所有 30 家店铺及其完整元数据的 Excel 表格。运行时间：不到 45 分钟。
求职自动化。 将 100 个职位描述匹配到一份简历。输出：100 份量身定制的简历，每份都针对特定职位的要求和语言进行了优化。这是那种自由职业职业教练每份收费 50 美元的工作。该任务的总成本：不到 4 美元。
杂志封面系列。 一个提示词要求创作 10 份小报风格的杂志封面，使用真实的历史头条。每个 Agent 研究不同的历史时期，生成头条，设计封面。输出：从一个输入提示词得到 10 份精美的杂志封面。
五天的自主运行。 Moonshot 的内部团队将 K2.6 指向他们的监控和事件响应管道。它连续运行了五天，处理警报、开启拉取请求、在 Slack 上发帖、升级真正的事件。完全无需人工干预。这不是一个演示。这就是 2026 年自主值班工程师的样子。
如果你曾经为批量处理工作付过费，你的整个管道现在都被自动化了。
如何实际进行设置
你不需要构建一个框架。你不需要分布式系统的博士学位。基础设施已经准备好了。
方案 1：零设置网页界面
访问 kimi{.}com/agent-swarm。描述你的任务。指定子 Agent 的数量。上传任何文件。运行。这是入口点。无需安装、无需 API 密钥、无需配置。网页 UI 负责处理 Agent 分解、协调和最终输出组装。
何时使用：一次性批处理任务、文档处理工作流、研究项目，或者任何你想在投入代码之前测试任务是否可并行化的时候。
方案 2：用于生产工作流的 API 集成
为了实现编程访问并集成到你自己的管道中，请直接使用指向 K2.6 端点的 Moonshot API。文档位于 github.com/moonshotai/Kimi-K2。
1pip install moonshotai
通过将 agent_swarm 参数设置为 true 并将 max_agents 值设置为最多 300 来启动一个并行任务。模型原生处理分解任务。你提供任务描述和任何参考文件，K2.6 负责其余部分。
对于自托管，官方仓库有 vLLM 和 SGLang 的完整部署指南。权重在 Hugging Face 上。如果需要，你可以完全在自己的基础设施上运行它。
方案 3：使用 K2.6 后端的 LangGraph 编排
如果你想在保持 K2.6 定价的同时完全控制编排逻辑，请使用 LangGraph 作为编排层，并通过 OpenRouter 将模型调用路由到 K2.6。
1pip install langgraph langchain-openai
将模型参数指向 Kimi K2.6 端点，通过 OpenRouter 路由以实现所有模型提供商的统一计费。这就是生产团队正在运行的方案。
何时使用：你有一个复杂的有状态工作流，带有自定义分支逻辑、子 Agent 之间的条件路由，或者需要人工介入的检查点。LangGraph 提供图结构，K2.6 提供定价和并行执行能力。
方案 4：用于混合模型集群的 Claude Code Router
github.com/musistudio/claude-code-router 让你能够使用 Claude Code 的界面，但将特定的子 Agent 路由到最适合该任务的模型。协调员使用 Opus 4.8 以实现高可靠性规划，批量子 Agent 使用 K2.6 以实现成本高效的并行执行，计算机使用子 Agent 使用 GPT-5.5 以实现 GUI 导航。
这是你目前能够构建的最具成本效益的并行堆栈。协调员可能只处理总标记的 5%，且需要最大可靠性。300 个子 Agent 处理 95% 的标记，且需要最大的成本效率。将每一层路由到正确的模型，与在单个模型上运行所有内容相比，总成本可以再降低 60%。
现在就需要安装的提示词
三个系统提示词。一个给协调员，一个给子 Agent，一个给验证器。将它们作为持久化的系统提示词安装到你的集群配置中，或者在任何会话开始时粘贴进去。
给协调员 Agent：
1你是一个协调员，负责编排一个由并行子 Agent 组成的集群。23你的工作：将用户的请求分解成尽可能少、完全独立且能完整覆盖目标的并行任务，将它们分发给子 Agent，并将结果合并成一个连贯的交付物。45规则：6- 识别出可并行工作的最小单元7- 每个子任务必须完全独立，没有交叉依赖8- 指定每个子 Agent 必须返回的确切输出格式9- 在分派任何任务之前定义好合并逻辑10- 如果子任务之间存在依赖关系，则按阶段排序，而不是强行制造并行11- 生成的子 Agent 数量不要超过任务所需1213合并时：14- 明确解决矛盾，不要掩盖15- 保留哪个子 Agent 生成了哪个输出的归因信息16- 在返回之前，对照原始请求验证合并后的输出1718成功标准：最终的交付物是连贯的、完整的，并且可以追溯到特定的子 Agent 输出。
给集群中的每个子 Agent：
1你是一个更大集群中的专业子 Agent。23你的工作：精确完成一个分配的子任务，并按照协调员指定的确切格式返回你的输出。45规则：6- 在做任何事情之前，先阅读完整的子任务说明7- 不要将范围扩展到分配的任务之外8- 以请求的确切格式返回你的输出，不要有前言，不要有评论9- 如果遇到阻碍，返回一个明确的标志，不要猜测10- 如果你的子任务需要分配范围之外的信息，请向协调员标记，而不是试图自己填补11- 在返回之前，对照说明验证你的输出1213成功标准：你的输出可以直接插入到合并步骤中，无需协调员进行清理。
给最后的验证器通行：
1你是已完成集群输出的验证器。23你的工作：检查合并后的交付物是否实际满足了原始用户请求。45规则：6- 将最终输出与原始请求进行比较，而不是与协调员的计划7- 标记出请求内容与交付内容之间的任何差距8- 识别合并输出中的矛盾9- 识别任何在合并过程中被丢弃或误解的子 Agent 输出10- 不要软化调查结果，暴露每一个真实问题1112如果输出不完整：准确列出缺失了什么。13如果输出错误：指出是哪个子 Agent 的输出导致了错误。14如果输出完整且正确：确认并通过。1516成功标准：没有任何破损或不完整的内容能通过你的检查。
这三个提示词决定了你的集群是产出连贯的交付物，还是产出 300 个你需要手动拼接的碎片。
你需要的仓库
这是最重要的部分。收藏每一个。
关于集群本身：
github.com/moonshotai/Kimi-K2 是官方仓库。权重、vLLM 和 SGLang 的部署指南、API 文档、自托管或 API 集成的完整设置。从这里开始。
github.com/chongdashu/cc-kimi-k2-thinking-prompts 展示了如何通过切换单个环境变量，使用 Claude Code CLI 来使用 K2.6。Claude Code 的完整 Agent 循环，由 K2.6 的大脑以极低的成本完成工作。
github.com/dnnyngyen/kimi-agent-internals 包含了 Kimi 所有六种内置 Agent 类型（包括 Base Chat、OK Computer、Docs、Sheets、Slides 和 Websites）的提取系统提示词，以及完整的技能定义和工具模式。这几乎是一本反向工程的剧本来展示 Moonshot 自己的 Agent 是如何构建的。
关于编排：
github.com/langchain-ai/langgraph 是大多数生产级并行 Agent 团队正在运行的开源编排框架。成熟、有状态、完全控制图结构。
github.com/joaomdmoura/crewAI 是更容易的入口点，如果你想在不自己编写图逻辑的情况下进行基于角色的 Agent 定义。功能较少，但上手友好得多。
github.com/microsoft/autogen 是微软的基于对话的多 Agent 协作框架。最适合那些 Agent 需要互相辩论或优化彼此输出，而不是纯粹并行运行的工作流。
github.com/musistudio/claude-code-router 是混合模型集群中缺失的一环。一个界面，多个模型后端，每个子 Agent 类型的路由逻辑。
关于提示词和模式：
github.com/asgeirtj/system_prompts_leaks 将 K2.6、Opus 4.8 和 GPT-5.5 泄露的系统提示词放在了一个地方。研究每家公司如何塑造其模型的行为，是你能做的最具杠杆效应的提示词工程练习之一。
github.com/f/awesome-chatgpt-prompts 拥有 14.3 万+ 颗星，是规范性的提示词库。适用于所有三个模型，提供了几乎所有 Agent 模式的模板。
github.com/CheswickDEV/claude-opus-4.8-prompt-optimizer 是一个元提示词，可以将原始提示词转换为针对新的 xhigh 努力等级优化的、生产级的 XML 结构提示词。当你的协调员运行在 Opus 上时非常有用。
技能：无声的杠杆倍增器
大多数人会跳过这一部分。他们不应该。
K2.6 集群有一个叫做技能的功能。你上传任何文档、任何 PDF、任何电子表格、任何演示文稿，集群会将其结构和风格 DNA 提取成一个可重用的模板。
之前的天体物理学论文例子就变成了一个技能。所以现在，每次新的天体物理学论文运行只需 12 分钟，而不是 30 分钟，因为集群已经知道输出结构、图表样式、引用格式和章节层次。
人们正在运行的现实技能：
一份世界经济论坛风格报告技能，可以接受任何研究输入，并生成一份完全格式化的机构研究出版物，包含适当的字体、色调、双栏布局、图表编号和方法论附录。
一款水墨画演示技能，可以将任何内容转换成优雅的黑白水墨风格幻灯片，带有手绘插图、单色水彩美学和不对称布局。
一个路演方案技能，可以将你的原始商业创意转换成一个精致的、准备好面对投资者的演示文稿。
模式每次都一样：上传一个你最佳输出的示例，集群捕获其 DNA，未来该领域内的每一个任务都自动继承那种质量。
这就是杠杆效应累积的地方。你不再每次都为工作重新发明结构。每个技能都让未来的每一次运行更便宜、更快、更一致。
如果你从整篇文章中什么都不做，请这周就从你过去三份最好的工作中构建三个技能。你的输出质量和速度将永久性地提升。
这个周末就能构建的真实工作流
这些不是假设。以下每一个目前都在生产中运行。
1. 竞争情报管道。 50 个 Agent 指向 50 个竞争对手的网站。每个提取定价、功能、定位、近期更新和客户评价。协调员合并成一份单一的竞争格局报告。每周运行一次。你将比行业中的任何人都更了解市场。运行时间：20 分钟。成本：低于 5 美元。
2. 内容生产组装线。 20 个 Agent 研究同一个主题的不同角度。一个协调员将发现合并成大纲。一个写手 Agent 起草。一个编辑 Agent 润色。四个小时的人力工作变成 15 分钟的 Agent 运行时间。从你最好的文章构建一个技能，未来的每篇文章都会继承其结构。
3. 冷邮件个性化堆栈。 上传 100 个潜在客户姓名和公司。100 个 Agent 各研究一个潜在客户，找到他们近期的工作，识别相关的痛点，用你的语气起草一条定制的沟通信息。不是泛泛的 AI 垃圾。真正的并行执行的个性化。每条信息的成本：不到 5 美分。
4. 遗留代码库审计。 启动 Agent，每个分析大型代码库的不同模块。一个 Agent 生成架构文档。另一个找出死代码。另一个标记安全问题。另一个建议重构候选方案。协调员生成一份单一的审计报告。这种审计咨询公司收费 5 万美元。现在可以在一夜之间以不到 50 美元的成本运行。
5. 批量自由职业服务自动化。 有服务业务？求职信撰写、简历定制、提案起草、市场研究、广告文案变体。构建一个集群，处理从接单到交付的每个工作。一个运营者可以处理整个代理机构的工作量。
6. 文档生成管道。 将 Agent 指向你代码库中的每一个文件。每个为其分配的模块生成文档。协调员合并成一个单一的文档站点。每次提交时自动维护。
7. 自主监控 Agent。 将一个长期运行的 K2.6 Agent 指向你的错误日志和部署管道。当出现问题时，它识别相关的提交，打开一个修复草稿，并在 Slack 上发布上下文信息。你的值班工程师审阅一个拉取请求，而不是在凌晨 3 点盯着空白的终端。
8. 产品发布协调集群。 一个 Agent 编写 PRD。一个设计模型。一个撰写发布博客文章。一个起草社交媒体活动。一个构建落地页。一个起草媒体通稿。全部并行进行，全部合并成一个协调的发布包。
9. 深度市场研究。 就一个研究问题启动 30 到 50 个 Agent，每个覆盖不同的角度。协调员合并并解决矛盾。一份带有完整引用、结构清晰的报告，用时与过去读 10 篇文章相当。
10. SaaS 原型组装。 描述产品、技术栈和功能列表。K2.6 并行搭建前端、后端、DevOps 配置、数据库模式和身份验证层。将输出交给 Opus 4.8 以强化生产关键路径。一个过去需要一个月的最小可行产品现在一个周末就能完成。
实现最大杠杆的模型路由
最聪明的做法不是让所有东西都通过 K2.6 集群运行。最聪明的做法是将集群的每一层路由到最合适的模型。
协调员使用 Opus 4.8。 协调员可能只处理总标记的 5% 和 95% 的战略决策。可靠性比成本更重要。用最好的。
批量子 Agent 使用 K2.6。 300 个子 Agent 处理总标记的 95%。成本效率最重要。K2.6 是唯一一个使得 300 个并行 Agent 在经济上可行的模型。
网络研究子 Agent 使用 GPT-5.5。 当子 Agent 需要浏览和综合网络信息时，GPT-5.5 的 90.1% BrowseComp 分数和卓越的长上下文检索能力超越了其他所有模型。将浏览类子 Agent 专门路由到 GPT-5.5。
视觉子 Agent 使用 Opus 4.8。 任何需要理解图像、设计布局或处理视觉参考的子 Agent，都应路由到 Opus 4.8 的 98.5% 视觉敏锐度分数。
计算机使用子 Agent 使用 GPT-5.5。 GUI 操作、浏览器自动化，任何需要实际界面控制的任务。GPT-5.5 的 78.7% OSWorld-Verified 分数是市场上最高的。
设置一次。使用 Claude Code Router 处理路由逻辑。与单模型执行相比，你的总集群成本将再降低 40% 到 60%。
这就是 2026 年精通的样子。不是忠于单一工具，而是无情地将工作的每一层路由到最好的工具。
诚实的警告
我会给你未经修饰的版本，因为炒作对任何人都没有帮助。
在最复杂的长期任务上，并行 Agent 编排仍然很脆弱。如果你的工作流需要深度串行推理，其中每一步都以非显而易见的方式依赖于上一步，那么并行化不仅没有帮助，还可能有害。当子任务实际上并不独立时，合并步骤开始产生矛盾。
在真正可以并行化的工作上使用集群：研究、批量生成、多文档分析、大规模内容生产，以及任何具有 embarrassingly parallel 结构（即输入 50 个，通过相同转换输出 50 个）的任务。
对于串行推理、单文件调试、新颖的架构决策，或者任何跨数百个依赖步骤的可靠性比吞吐量更重要的任务，你仍然需要一个像 Opus 4.8 这样的高质量模型线性工作。
其他现实警告：
编排开销不可忽视。启动 300 个 Agent 需要几分钟的协调时间。对于相当于不到 10 分钟串行工作的任务，开销会吃掉收益。不要在小任务上强用集群。
K2.6 的工具模式重试率略高于 Anthropic 或 OpenAI。如果你的子 Agent 严重依赖调用结构化工具 API，你会遇到偶尔的重试，这在 Opus 上是看不到的。
K2.6 在纯数学方面并不领先。如果你的子 Agent 需要进行繁重的数值推理，请专门将它们路由到 GPT-5.5。
K2.6 API 目前尚不支持图像输入。图像密集型子任务需要路由到 Opus 或 GPT-5.5。
并行 Agent 不是魔法。它们是合适任务的杠杆。任务匹配时收益巨大；不匹配时损失真实。
思维模式转变
过去两年，每个 AI 工作流的问题都是：哪个模型最适合这个任务？
当模型是顺序执行且彼此差异显著时，这是个好问题。
2026 年的问题不同了：这个任务能否并行化？如果可以，完成每个子任务且质量达标的最便宜模型是什么？
这是思考 AI 工作的全新方式。
10 倍效率的操作者不是拥有最佳单一模型的人，而是将工作分解为 50 个并行子任务——当其他人还在一次运行一个提示时——并将每个子任务路由到正确模型的人。
大多数人会读这篇文章，觉得有趣，然后继续顺序工作。基础设施太新，思维转变太不舒服。这没关系。这也正是机会所在。
那些本周真正改变工作流程的人，将在 30 天内达到完全不同的水平。不是因为他们更聪明，而是因为他们每天尝试的次数比任何竞争对手多 50 到 100 倍。
更多尝试意味着更多学习。更多学习意味着更多产出。更多产出意味着更多杠杆。
这会形成复利。
基础设施已就绪。定价已就绪。工具已就绪。仓库公开，文档完善，提示也都在上面。
唯一的问题是：你是现在构建并行 Agent 栈，还是等到其他人先做？
2026 年在 AI 领域领先的人，不是那些拥有最贵订阅的人，而是那些在并行 Agent 集群变得显而易见之前就理解这一转变的人。
我分解了每一个主要的 AI 工作流和工具栈，这样你就不必独自摸索。
关注我 @eng_khairallah1 获取更多 AI 课程、工具和工作流。每周更新。
希望对你有用，Khairallah ❤️
