300 个 Agent 一起干活，Claude 负责验收：一次自进化的 Loop Engineering 实践

大多数人打开 Kimi，只是把它当成一个聊天框。输入一个问题，等它回答，然后关掉页面。当然这用法没毛病，但 0xMovez 给出了他的 Kimi 最佳实践，在本文中我们将一同感受他是如何让 300 个 Agent 一起干活，并让 Claude 当“包工头”验收成果的。

我们可以重点关注下 Kimi K2.6 里的 Agent Swarm。Kimi K2.6 可以从一个 prompt 启动最多 300 个并行 sub-agents，在 4,000 个协调步骤中完成复杂任务。它能产出真实文件，比如报告、表格、数据集、图表、代码，而不只是聊天窗口里的一段回答。

有意思的是，这个 swarm 每次运行结束后，不只产出一份结果，还会把这次任务里的有效经验留下来。这些经验可能是一套可复用的 Skill，可能是一份写得更清楚的 spec，也可能是一条新的约束，用来避免下次任务重复今天的错误。

原文里有一句话，直接引用下：

The swarm that ran your task yesterday should be smarter than the one running it today.

这就是 Self-Improving Loop。在这个循环里，Kimi 负责执行任务和沉淀流程；Claude Opus 4.8 放在验证关口，专门检查输出有没有问题。这里的分工很直接：Kimi 是干活的引擎，Claude 是验收的人。

随着现在大模型更新得越来越频繁，不少人会纠结到底该选哪个模型，也有人会盯着榜单看谁又超过了谁。还有人会用 LangGraph 之类的框架搭工作流，再花时间调 DAG。

但，无论你怎么选，最后大概率会遇到同一个问题：第 50 次运行和第 1 次运行做的事情几乎一样。

0xMovez 这套玩法，重点在于让每一次运行都能留下东西。下一次再启动时，系统可以带着上一次的 Skill、约束和验证反馈继续工作。

下面是这套循环的 10 个步骤。

1.写 spec，不要只写 prompt

听到 Kimi 支持 “300 个 Agent”之后，不少人的第一反应，可能是给 Kimi 丢一句类似“调研一下健身 App 市场”的话。但，0xMovez 认为这是最容易浪费资源的用法。

像是这样一句话的 prompt 会把太多决策权交给 swarm：它要自己判断调研范围、信息来源、输出格式、有效标准，以及遇到冲突时该怎么处理。复杂任务里，这些地方都容易出错。

因此，相对友好的方式，是把 swarm 当成一个承包团队，而不是许愿池。你要写的是 spec。

这个 Spec 要说清楚几件事：收集什么，什么算有效，允许使用哪些来源，输出格式是什么，遇到冲突怎么办，什么时候应该停下来汇报。

可以参考作者给出的一个模板：

# PROJECT: [name] GOAL: [one sentence — the deliverable, not the topic] SCOPE: [what's in, what's explicitly out] RULES: [validation — what counts as a verified row/finding] SOURCES: [official posts, papers, primary only — no aggregators] OUTPUT: [file type / count / naming / format details] ON CONFLICT: flag the row, never resolve silently STOP CONDITION: [when to halt and report instead of guessing]

需要注意的是，你不需要像 CrewAI（多 Agent 协作框架）那样自己定义每个 agent，也不需要像 LangGraph 那样手动连图，或者像 AutoGen 那样先把结构搭出来。

你只要能描述目标，Kimi 自己会做任务拆分。而 spec 是整个循环里最重要的起点。后面保存 Skill 时，它会变成可复用流程的种子。

2.先看任务分解计划，再开始执行

提交 spec 之后，不要急着让它直接跑。可以让 Kimi 先展示执行计划：会用多少个 sub-agents，每个 sub-agent 负责什么，依赖顺序是什么，大概需要多少步骤。

这一步很容易被我们跳过，但它可能是最省钱的一步。如果一个 200-agent 的 swarm 一开始就拆错了方向，后面就算能继续跑完，消耗掉的时间、token 和人工检查成本也已经真实发生了。所以，只要我们检查下计划，就能规避掉这种成本开销。毕竟，检查计划本身几乎不花什么成本。

检查计划时，我们主要看三件事：

1. 它有没有理解任务范围。
2. Agent 数量和任务规模是否匹配。
3. 输出计划是不是你真正需要的东西。

原文提醒了一个细节：4,000 steps 是整个 swarm 的总协调预算，不是每个 agent 都有 4000 步。如果是 300 个 agent，平均到每个 agent 身上大概只有 13 步左右。

这也间接说明一件事，这个方案会更适合短而明确的子任务。

你可以这样要求 Kimi：

Show me the proposed decomposition before running: - how many sub-agents, and what each one handles - the dependency order (what blocks what) - estimated step budget - where the biggest quality-drop risk sits Do NOT execute yet. Wait for my confirmation.

3.允许它“浪费”，这是 swarm 的本意

确认完任务的分解计划之后，再让它执行。根据作者的实践，Kimi 最多支持 300 个 sub-agents 分批并行启动。第一批先处理彼此独立的子任务；等这些结果回来之后，协调器再继续安排下一批依赖这些结果的任务，直到整个任务链路跑完。

这里的重点不只是速度。如果让一个单独的 Agent 连续处理很长的任务，它的上下文会越堆越多。到后面，为了继续推进，它可能需要压缩、总结前面的信息，细节也更容易在这个过程中丢掉。任务越长，后面的判断就越容易受影响。

Swarm 的处理方式，是把大任务拆成多个更小的子任务。每个 sub-agent 只处理自己那一段，在相对独立的上下文里完成工作，再把结构化结果交回协调器。这样一来，单个 Agent 不需要把整条长任务从头扛到尾。

因此，它更适合那些信息量大、链路长、单一 Agent 容易撑不住的任务。

这里提下 Kimi 2.6 的价格：输入 $0.95/M tokens，输出 $4.00/M tokens，缓存命中时输入价格会更低。作者想表达的是，当并行执行的成本足够低时，使用方式也会变。第一次跑得不够好，可以根据结果和验证反馈调整 spec，再重新跑一轮。虽然成本依然存在，但它低到足以支持这种“先跑、检查、再修正”的工作方式。

在确认任务拆分合理之后，就可以让 Kimi 按这份 spec 执行完整流程。这是可参考的执行提示词：

Execute the spec end to end. Parallelize wherever the plan allows. Report progress every 30 steps. Flag any blocker immediately — do not work around it silently. If a sub-agent stalls >10 min, reassign or report. Merge everything into the OUTPUT defined in the spec.

4.要真实文件，不要只在聊天窗口里的回答

原文强调，swarm 的输出不应该只是窗口里的一段文字。如果任务真的要进入工作流，输出应该是可以直接使用的文件，比如 PDF、表格、数据集、幻灯片、代码文件。

所以 spec 里一开始就要写清楚输出。

“写一份完整报告”这种输出要求太宽泛，Agent 很容易在信息还不充分的时候提前收尾。相比之下，“40 页 PDF + 一个 20,000 行 CSV + 14 张可导出的 PNG 图表”会给它一个更明确的交付目标。

输出要求可以这样写：

OUTPUT: [file type] / [count] / [naming] / [format detail] # strong examples: OUTPUT: 1 .xlsx, one row per model, + 200-word brief OUTPUT: 30 HTML files, one per store, named by business OUTPUT: 40-page PDF + 20,000-row CSV + 14 PNG charts

输出要求越具体，验收标准越清楚。

5.让 Claude 看输出，再问它哪里有问题

这一步不是 Kimi 的工作。是 Claude Opus 4.8 负责的“验证关口”工作。

Swarm 的一个常见问题是，如果没有明确要求验证，它可能会生成看起来很完整的结论，但其中一些判断缺少可靠引用。多个 sub-agents 独立处理不同子任务时，也可能因为信息来源和判断标准不同，最后出现相互矛盾的结果。

“看起来完成了”和“结果正确”是两件事。

因此，作者把 Opus 4.8 放在最后，专门挑错。它在这里承担的是验收角色：检查输出里有没有静默错误、引用问题、冲突内容，以及没有经过验证的结论。

原文没有给出这一步的具体提示词。按照它对 Opus 的定位，我们可以把验证环节补成一段更明确的 prompt，让 Claude 只做验收，不继续扩写内容：

Review the output as a verifier, not a co-writer. Your job is to find problems, not to improve the writing style. Check for: - Unsupported claims - Missing primary sources - Contradictions across sections - Figures, rows, or findings that should be flagged - Places where the output sounds confident but the evidence is weak For each issue, return: - Location: section / paragraph / row / file name - Issue type - Severity: high / medium / low - Why it matters - What evidence is missing - Suggested fix Rules: - Do not praise the output. - Do not rewrite the whole deliverable. - Do not silently resolve conflicts. - If a claim cannot be verified from the provided sources, mark it as “needs verification”. - Return only problems, fixes, and severity.

6.把整套工作流保存成 Skill

这是整套 Loop 真正开始积累的地方。

如果一次运行的流程以后还会重复执行，就可以让 Kimi 把它保存成一个可复用 Skill。这个 Skill 保存的内容不只是最终结果，还包括输入格式、agent 执行步骤、输出结构、命名规则和验证标准。

这样做的好处是，下一次遇到类似任务时，不需要再从零写 spec、重新摸索任务拆分方式，也不用重新定义输出格式。Kimi 可以直接从这个 Skill 启动，沿用已经跑通的流程。

按照原文的说法，这套流程第一次运行可能要 20 分钟，因为它要从零开始搭流程；等它被保存成 Skill 之后，后面再跑类似任务，就可以复用已有的输入格式、执行步骤和输出结构，启动速度会快很多。

这里积累的并不是模型权重，而是模型外部的流程资产。Skill library 会越来越完整，约束文件会越来越清楚，未来的 swarm 也能自动应用这些已经验证过的流程。

让 Kimi 保存这套 workflow 时，可以这样保存：

Save this entire workflow as a reusable Skill: "[name]" Capture: - input format (what files / spec shape it expects) - the agent steps that worked - the output format and naming convention - the validation rules from the spec Next time I run this, I attach new files and get the same shape.

这一步留下的是过程资产。下一次不需要从空白 prompt 开始。

7.把自己的文档变成 swarm 知识

前一步保存的是工作流程：这类任务怎么拆、怎么跑、怎么输出、怎么验证。

这一步处理的是你已经认可的高质量文档。原文建议，把成交过的 proposal、打磨过的报告、已经验证有效的 deck 上传给 Kimi，让它分析这些材料的结构、表达节奏、分析深度和格式习惯。

这样做的目的，是让 Kimi 把“这类文档应该怎么写”也沉淀成 Skill。后面再启动新的 swarm 时，它就可以参考这些材料里的写法和质量标准，减少通用 AI 味。

如果要把一份文档沉淀成 Skill，可以这样提示 Kimi：

Capture this document as a reusable skill. Identify what makes it work: - structure and section order - tone and voice register - depth of analysis per section - the writing rhythm and formatting decisions Save it as "[name]". Then produce a new document on [different topic] using the captured skill — match the quality bar, not the content.

这个步骤的重点，是让它学习结构和质量标准，而不是复制原文内容。

8.把验证反馈写成永久规则

第 5 步能抓住一次错误。

第 8 步要防止下次再犯。我们不只要修正当前这份输出，还要把 Claude 发现的问题变成长期规则。

比如某次验证里发现数据没有主来源、冲突内容被悄悄合并、任务范围被扩大，就可以把这些问题写进CONSTRAINTS.md。以后 Kimi 每次启动任务前，都会先读取这些约束，避免重复踩坑：

# CONSTRAINTS.md — loaded automatically - every claimed figure must trace to a primary source or be flagged - no silent conflict resolution — surface contradictions - [rule distilled from last run's Opus feedback] - [the mistake you never want repeated] Scope-lock: do not touch anything outside the spec's SCOPE block.

这一步就是循环开始“记住教训”的地方。

第一次运行里被 Claude 标出来的问题，第二次运行前就变成硬规则。项目跑得越多，constraints 文件越像一份会自动生效的项目文档。

9.在新输入上复用 Skill，看成本怎么下降

到这一步，第二次运行就不需要再从空白 prompt 开始了。

Kimi 会带着前面保存好的 Skill、文档知识和CONSTRAINTS.md启动。任务流程还是同一套，但输入换成了新的材料。因为任务拆分方式、输出格式和验证规则都已经沉淀下来，前期设置成本会低很多。

原文用 competitive monitoring，也就是竞品监控，举了一个例子。

第一次做竞品监控时，你可能要写完整 spec，检查 Kimi 的任务分解计划，再让 Claude 做一次完整验收。等到这个流程跑过几轮、Skill 也稳定下来之后，后面再做类似任务，就可以直接交给 Kimi 处理新文件，并要求它沿用原来的输出格式，只报告和预期不一致的地方。

如果要在新输入上复用已有 Skill，可以这样提示 Kimi：

Run the saved skill "[name]" on these new inputs. Apply CONSTRAINTS.md. Use the captured output format. [attach new files] Report only deviations from the skill's expected shape.

作者给出了数据指标：第一次 20 分钟，第 50 次 30 秒。这个差距就是为什么要搭循环，而不是每次重新写 prompt。

10.把稳定循环升级成后台 Agent

最后一步，是把已经稳定的 Skill 变成后台运行的 Agent。

当一个流程经过几轮验证，Skill、CONSTRAINTS.md和输出格式都比较稳定之后，就不一定需要每次手动启动。你可以给它设置一个触发条件，比如固定时间、新文件上传、竞品页面变化、价格页更新等等。

触发条件满足后，它会按前面已经跑通的流程继续执行：启动 swarm、应用约束、验证输出、生成交付物，并把这次结果和上一次结果之间的变化整理出来。

这样一来，人不需要每次重新发起任务，只需要关注最终交付物、异常变化，以及需要自己判断的部分。

如果要把一个稳定 Skill 设置成后台 Agent，可以这样提示 Kimi：

Run skill "[name]" on a weekly schedule. Trigger: [schedule / new file / monitored URL] On each run: execute the swarm, apply CONSTRAINTS.md, verify, then deliver the OUTPUT + a diff vs last run. Only ping me if a deviation crosses [threshold].

这样，人需要做的事情会少很多。你设定问题，它定期跑流程。你只看输出、偏差和需要决策的地方。

小结

小结一下，这篇原文讲的不是某个模型单点变强，而是一套 Agent 工作流怎么积累经验。

Kimi 负责拆任务、跑 swarm、生成文件；Claude 放在最后验收，检查输出里有没有不可靠的地方。任务跑完之后，流程被保存成 Skill，错误被写进CONSTRAINTS.md，高质量文档也可以变成后续任务的参考。

下一次再跑类似任务时，系统就不用回到空白 prompt，而是带着已有流程、规则和反馈继续执行。

这就是原文里的 Self-Improving Loop：先搭起来，再验收，再沉淀。