大多数人打开 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: [whats in, whats 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 和人工检查成本也已经真实发生了。所以只要我们检查下计划就能规避掉这种成本开销。毕竟检查计划本身几乎不花什么成本。检查计划时我们主要看三件事它有没有理解任务范围。Agent 数量和任务规模是否匹配。输出计划是不是你真正需要的东西。原文提醒了一个细节4,000 steps 是整个 swarm 的总协调预算不是每个 agent 都有 4000 步。如果是 300 个 agent平均到每个 agent 身上大概只有 13 步左右。这也间接说明一件事这个方案会更适合短而明确的子任务。你可以这样要求 KimiShow 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可以这样提示 KimiCapture 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 runs Opus feedback] - [the mistake you never want repeated] Scope-lock: do not touch anything outside the specs SCOPE block.这一步就是循环开始“记住教训”的地方。第一次运行里被 Claude 标出来的问题第二次运行前就变成硬规则。项目跑得越多constraints 文件越像一份会自动生效的项目文档。9.在新输入上复用 Skill看成本怎么下降到这一步第二次运行就不需要再从空白 prompt 开始了。Kimi 会带着前面保存好的 Skill、文档知识和CONSTRAINTS.md启动。任务流程还是同一套但输入换成了新的材料。因为任务拆分方式、输出格式和验证规则都已经沉淀下来前期设置成本会低很多。原文用 competitive monitoring也就是竞品监控举了一个例子。第一次做竞品监控时你可能要写完整 spec检查 Kimi 的任务分解计划再让 Claude 做一次完整验收。等到这个流程跑过几轮、Skill 也稳定下来之后后面再做类似任务就可以直接交给 Kimi 处理新文件并要求它沿用原来的输出格式只报告和预期不一致的地方。如果要在新输入上复用已有 Skill可以这样提示 KimiRun the saved skill [name] on these new inputs. Apply CONSTRAINTS.md. Use the captured output format. [attach new files] Report only deviations from the skills expected shape.作者给出了数据指标第一次 20 分钟第 50 次 30 秒。这个差距就是为什么要搭循环而不是每次重新写 prompt。10.把稳定循环升级成后台 Agent最后一步是把已经稳定的 Skill 变成后台运行的 Agent。当一个流程经过几轮验证Skill、CONSTRAINTS.md和输出格式都比较稳定之后就不一定需要每次手动启动。你可以给它设置一个触发条件比如固定时间、新文件上传、竞品页面变化、价格页更新等等。触发条件满足后它会按前面已经跑通的流程继续执行启动 swarm、应用约束、验证输出、生成交付物并把这次结果和上一次结果之间的变化整理出来。这样一来人不需要每次重新发起任务只需要关注最终交付物、异常变化以及需要自己判断的部分。如果要把一个稳定 Skill 设置成后台 Agent可以这样提示 KimiRun 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先搭起来再验收再沉淀。