waves

WAVES — Workers · Aggregate · Verify · Extend（Cursor）

在一个本地 Cursor 会话中运行波次式编排。波次是一个有界回合：隔离的 Agent 并行工作，随后进行一轮验证返回结果，再审慎决定是否基于结果继续推进，而不是无限循环。你是编排者：负责调研，将目标拆分为相互独立的切片，将它们分派给并行的工作者（在一条消息中调用多个 Task 工具，并在界面支持时将其置于后台），读取每位工作者的结构化交接内容，进行验证，并综合出一份交付成果。工作者彼此隔离，且每位只返回一份交接内容。

每个波次的结构 — WAVE：

• W — Workers（工作者）。 将相互独立的切片分派给隔离的工作者（有界并行回合）。
• A — Aggregate（汇总）。 等待所有工作者完成，并在综合阶段汇总其结构化交接内容。
• V — Verify（验证）。 关键所在：在相信任何交接内容之前，先检查其依据。
• E — Extend（扩展）。 审慎决定是否启动下一波，或就此停止。

循环不知道何时该停止；波次知道，因为验证就是停止函数。（通过 /waves 显式调用：一次运行会生成比平常更多的 Agent，因此需由用户选择启用，不会自动触发。）

Waves 取代云端编排。它采用 Cursor 团队在其云端 orchestrate 插件中验证过的原则——规划者负责规划，工作者向上提交交接内容，彼此不交谈——但通过本地子 Agent 运行，无需任何设置：不需要单独的云端 Agent、API 密钥或运行时。本地子 Agent 运行就是全部。

适用场景

• 目标较大，且可拆分为相互独立的切片（研究领域、数据块、文件/模块、审计维度）。
• 工作主要是阅读 / 调研 / 分析——这是最适合在本地并行处理的任务（原因见“并行写入”）。
• 单次线性处理会很慢，而你希望通过并发获得实质性的提速。

不适用场景

• 小型或线性任务（直接处理即可——分派的开销不值得）。
• 需要步骤间频繁往返或共享可变状态的工作。
• 并行编辑相同文件——本地工作者共用一个文件系统。

核心原则

改编自 orchestrate。这些原则可确保运行持续收敛，无需协调。

1. 编排者负责规划和综合，不负责承担繁重工作。 调研、拆分任务、阅读交接内容以及撰写最终交付成果是你的工作。大量阅读、调研和分析工作应委派给工作者。
2. 工作者彼此隔离。 子 Agent 无法访问用户消息、你之前的步骤或其他工作者。 每条工作者提示词都必须完整自包含：目标背景、确切的任务切片、查找位置以及返回内容。
3. 一位工作者，一个切片，一份交接内容。 工作者的最终消息是你唯一会读回的内容。明确规定其确切格式（见 references/handoff-format.md）。
4. 并行处理用于阅读，而非写入。 本地工作者共用工作区；同时写入有重叠的路径会互相破坏。
5. 持续推进。 交接内容可能会揭示新的工作。启动第二波（由交接内容中的缺口或新的用户请求触发）。只有在每个切片都已完成且综合工作已结束后才停止。
6. 先验证，再相信。 工作者的 Status: success 只是声明，不是证据。在将交接内容纳入综合结果前，先依据可重新打开查看的内容逐项核验。见下文“验证”以及 references/verification.md。
7. 拆分任务就是降低熵。 模糊的目标具有高熵——许多看似合理的计划都可能符合要求。你的首要任务是在拆分之前缩小可能范围（先进行本地调研，再查阅附加资源，只有确有必要时才询问用户）；拆分高熵目标会导致切片重叠、大小不当。见“熵优先的任务拆分”。

优先降低熵进行拆解

在分派任务前，先把目标视为一个降低熵的问题：缩小与你掌握的信息相符的可能解释和计划的范围。模糊的高熵请求（“构建一款 Flappy Bird 游戏”“让我的应用更快”）还无法清晰拆分——先降低不确定性，再拆解低熵版本。指出不确定之处，因为两类不确定性的解决方式不同：

• 规格不确定性——用户想要什么（目标含糊、缺少验收标准、约束未说明）。通过明确陈述假设并继续推进来解决；只有在猜错代价高昂时才提问。
• 环境／知识不确定性——你尚不了解但可以获取的事实（代码库结构、架构、API 行为、当前文档、数据量）。通过收集信息来解决，而不是提问。

优先采取成本最低、能带来最多确定性的行动——这就是信息增益阶梯——并针对答案能排除最多方案的未知项进行探查：信息量最高的问题，是能将剩余解释大致一分为二的问题，而不是最容易查到答案的问题。

1. 先在本地深入了解（成本低）。 在主会话中调用工具（列出文件、读取架构／README、grep、抽样数据）。这就是第 0 步，只不过以降低熵的方式表述；通常无需额外成本就能消除大部分不确定性。
2. 然后从附加资源获取信息。 如果环境中没有答案，就启动一小轮侦察任务，让研究工作者获取信息（网页、Exa/Ref MCP、文档）——将这些以阅读为主的任务交给成本低、速度快的模型（参见“为各任务片段选择模型”）。
3. 最后才询问用户，并且只有在值得时才问。 只有当剩余的规格不确定性较高，且问题的预期信息增益明显超过提问成本时才提问。大多数请求提供的信息足以让你基于明确陈述的假设继续推进；过度提问本身就是一种失误。

然后层层推进：一个高层请求变成一轮拆解任务（理解 → 找出未知项 → 起草计划）→ 验证 → 一轮执行任务，逐项完成已排序的子任务；只要熵仍然较高，就继续开展更多侦察子轮次。按由浅入深的顺序安排计划——先完成第一阶子任务，让每项已验证的结果降低下一步的不确定性。用 TodoWrite 维护动态计划，并在熵足够低、可以采取行动时停止继续降低熵：验证关卡也相当于检查“是否已将不确定性降至足以承诺行动的程度？”。需要注意的是，先规划再执行只能补上遗漏步骤，无法纠正误解目标——只有前文的规格检查能发现方向错误，因此它必须先于规划。（示例、任务轮次结构和研究依据：references/examples.md。）

工作循环

用 TodoWrite 跟踪进度，让各轮任务清晰可见。

第 0 步 — 先探索（串行，在主会话中）

不要盲目分派任务。在主会话中花少量时间调用成本低的工具，了解问题的整体情况：列出目录、读取架构、抽样数据、确认覆盖范围／规模。这能帮助你确定自然的拆解方式（分成多少块、划分哪些工作流）。跳过探索会导致任务片段彼此重叠或规模不合适。

步骤 0.5 — 准备数据（数据来自远程或格式杂乱时）

explore worker 默认只读，而只读模式会阻止所有 MCP 工具（Cursor 员工已确认），因此它们无法访问数据库或基于 MCP 的数据源。如果数据来自远程或夹杂着噪声，编排器必须先准备好干净的输入，再分发任务：

• 将远程数据拉取到本地。 使用 SSH/rsync/导出，将相关数据放到本地临时目录中，供只读 worker 读取（例如，以只读方式查询远程 SQLite，导出行数据，或 rsync Markdown 文件）。
• 集中清理并规范化一次。 移除包装层、样板内容和二进制数据块（base64、日志）；修正时间戳。集中处理一次，胜过让每个 worker 都重新推导一遍（还可避免噪声进入它们的上下文）。
• 提前为 worker 分块。 拆分为精确对应各 worker 的文件或范围，让每条提示词都能指向一个路径。
• 每次运行使用一个临时目录。 将准备好的输入、worker 产物以及各轮之间的综合结果放在同一处（例如 .waves/<run>/，其中包含 staging/、handoffs/、synthesis-wave-N.md），这样提示词可以引用路径，而不用粘贴内容；后续轮次也能重新读取文件，而不是翻查聊天记录。
• 启动 worker 前先验证。 打印数量和每个切片的范围；确认分区总和等于总数（例如 8 个数据块 × 约 388 = 3,097），确保没有任何切片成为无声的盲区。集中修复异常（排序错误、重复项），然后重新检查。（详情：references/verification.md §1。）

实际操作中，这种串行准备往往是耗时最长的阶段；输入清理完成后，并行分发会很快。

步骤 0.7 — 分诊：先确定运行规模，再为每个切片分类

先明确说明运行规模。 评估广度（有多少个独立切片）、深度（每个切片需要多少推理）、模糊程度（目标定义得有多清楚——参见“先按熵进行分解”）和风险（错误答案的代价有多高——这决定验证等级），然后在启动前用一句话说明选定的方案，例如：Run shape: one wave, 4 workers (3 research + 1 data chunk); second wave only if handoffs expose gaps.。如果在两种方案之间犹豫，就选较小的方案并说明原因。如果分诊后认为无需分波，就直接在当前流程中完成任务并说明这一点——绝不能把当前流程中的工作说成分波覆盖。

然后从三个维度为每个切片分类——这是“分类并处理”的模式，能将合适的工作交给合适的处理者：

• 工作者类型——只读（explore）／网络研究（generalPurpose）／shell／竞争式尝试（best-of-n-runner）／专项审查（bugbot、security-review）。（参见“选择 subagent_type”下方的表格。）
• 依赖关系——该切片需要哪些切片（如果有）的已验证输出。大多数切片应无依赖；真正的依赖关系才会划分出不同波次。
• 验证等级——根据切片的风险，确定需要多少检查：auto-accept（低风险、有佐证）→ single verifier（中等）→ multi-model panel（高风险）→ debate（存在争议、没有事实依据）。应将验证预算花在错误声明代价高的地方，而非平均分配。

将分诊结果记录为波次清单——每个切片一行，并在启动前写好（放入 TodoWrite 或 .waves/<run>/manifest.md）：

切片	范围	工作者类型	模型	depends_on	验证等级
1	消息 1–500	explore	（默认快速）	—	auto-accept
2	语音技术栈研究	generalPurpose	（默认）	—	single verifier
3	语音构建试验	generalPurpose	（默认）	2	single verifier

depends_on 定义了波次边界：一个波次包含所有尚未运行且依赖关系均已满足的切片——只有在交接内容已通过验证（步骤 3）后，依赖关系才算满足，而不只是切片已返回。并行启动波次 1（无依赖项）；启动每个有依赖的切片时，将提炼并验证过的发现结果（或其 .waves/<run>/ 路径）纳入其自包含提示词中；无关的切片则保持并行。清单也是你的完成门槛：启动了 N 行，就必须收集并核对 N 份交接内容后才能综合结果——缺少交接内容的波次就存在未被发现的缺口（步骤 3）。

步骤 1 — 分解为独立切片

沿着能让切片彼此独立的维度进行拆分：

• 数据块——将大型数据分区，并为每个工作者分配互不重叠的范围（例如，消息 1–500、501–1000，……）。
• 工作流——分开研究／分析领域（例如，“研究语音技术栈”“研究 Notion SDK”“审查身份验证代码”）。
• 文件／模块——分配互不重叠的路径集合。

每个切片都需要：一行说明范围、说明要查看的内容，并定义输出。对于大型波次（大约 5 个或更多工作者），在启动前先向用户说明分解方案，以便他们能轻松调整。如果切片很多，就分波次展开（启动一批，等待完成，再启动下一批），而不是一次全部启动，这样才能遵守实际的并发限制。

步骤 2 — 并行分发

发送一条包含多个 Task 工具调用的消息——每个依赖已满足的切片各调用一次（交接内容必须经过核验，而不只是已返回）——这样才能让它们并发运行（这是官方文档记载的并行机制）。根据切片选择 subagent_type（见下表）。为每个任务提供一个 3–5 个词的 description，以及一条自包含的 prompt，并以规定的交接格式结尾。

后台运行取决于具体界面：文档记载的开关是自定义子 Agent 的 frontmatter 字段 is_background: true；某些界面支持逐次调用的 run_in_background: true 参数，但该参数未记录在文档中（有些界面也不支持，例如云端 Agent）——如果架构定义中提供了该参数，就传入；否则不要依赖它。后台工作者的最终消息会包含在完成通知中。（/multitask 是 Agents Window 中面向用户的独立命令，并非此技能的机制。）

后台工作者运行时，结束当前轮次。 每个工作者完成时，你都会收到通知——不要调用 AwaitShell、轮询或循环读取输出文件。当界面以同步方式运行 Task 调用时，整批任务仍会并发执行，并在完成后一并返回。

步骤 3 — 收集并综合

首先执行完成门槛检查： 对照本轮清单逐一核对每份交接——启动了 N 个任务，就必须确认 N 份交接。未返回、发生错误，或状态为 partial／blocked 的工作者，都会造成任务缺口；若绕过该缺口直接综合，就会悄悄遗漏一个切片。工作者失败处理流程：（1）缩小范围后重新分配一次——如果切片只需继续，就让同一工作者续接（每次 Task 都会返回 Agent ID，可在保留上下文的情况下继续；已完成的子 Agent 会持久化检查点，因此即使工作者已完成，续接时也能恢复先前上下文）；或者重新启动一个新工作者，缩小范围，并说明先前返回的内容。仅在继续同一切片时才续接——续接的工作者会保留旧切片的上下文，这会污染无关任务；（2）如果再次失败，就在主会话中自行处理该切片；（3）如果仍然受阻，就在综合结果中明确将该切片标记为 not-covered——绝不要把缺失切片当作覆盖完整，直接取平均或综合。

收到交接后，逐份阅读：记录 Status、提取 Key findings，并梳理 Open questions／Suggested follow-ups——其中每个要点都可能成为第二轮任务。协调不同工作者之间的矛盾。

不要因为交接写着 success 就轻信其中内容。 核验每项发现的证据（引用的文件行号／URL／指标是否存在，且是否支持所述主张），重新统计源材料中的关键数字，并将置信度低、存在冲突或引用较多的主张交由核验者检查（步骤 3.5）。参阅下文的“核验”。只有通过这些检查，且清单中所有要求核验者审核的主张都已收到结论，本轮交接才算通过核验——仅靠简单检查，无法满足“单个核验者”或更高级别的要求。

完成后，才在屏障处压缩内容：将提炼后的综合结果写入 .waves/<run>/synthesis-wave-N.md，并以该文件为后续工作的依据——下一轮任务提示词应引用临时目录中的路径，绝不要重新粘贴原始交接内容。依赖切片和后续轮次会读取此文件，因此未经核验的内容不得作为发现写入其中：仍待核验的主张只能以明确的 pending-verification 条目保留。

压缩过程中保留所有约束。 每个综合文件和每份轮次间摘要都必须逐字保留本轮清单、停止条件／预算，以及任何安全或范围规则——绝不可改述或省略。上下文压缩会悄悄丢失约束（实测显示，违规率会在压缩后从 0% 升至 30–59%；固定保留约束后又恢复至 0%——arXiv 2606.22528）；停止条件在压缩时被删掉的任务，就会陷入循环或随机退出。

步骤 3.5 — 验证者审核（层级要求时）

在编写波次综合内容之前，为清单层级为 single verifier 或更高的每项主张，以及任何有争议、令人意外、仅有单一来源或置信度较低的内容，安排专门的验证者。向每位验证者提供主张及其引用来源，不提供生成者的推理，也不提供作者标签（参见“验证”）。验证者可以在你起草其他内容时并行工作，但他们的裁定决定着波次综合能否进行，而不仅仅影响最终交付物：在裁定返回之前，主张只能以明确的 pending-verification 条目出现在 synthesis-wave-N.md 中——绝不能作为已确定的发现，也绝不能出现在依赖切片的提示词中（步骤 0.7 的仅在验证通过时才满足规则）。

步骤 4 — 后续波次（持续推进）

如果交接暴露出缺口或后续事项——或者已验证的交接刚刚解除依赖清单切片的阻塞——就以同样的方式再启动一个并行波次。重复此过程，直到没有切片处于 pending 状态，也没有出现新问题。仍有真正的后续事项却提前停止，正是此技能要防范的失败模式；停止条件是清单加上已声明的预算（参见“有界波次”），绝不是“我们已经做过一两个波次了”。

只有在以下三种情况下，跳过后续波次才合理——决定时请说明适用的是哪一种：剩余未解决事项已经过一手来源验证（验证者无法改进现有证据）、受时间限制（外部事件发生前无法解决，应将其作为明确的未决事项保留），或确实存在争议（独立的高质量来源意见不一；增加采样也无法评判偏好——应记录分歧）。

步骤 5 — 交付

将所有交接内容综合成用户要求的单一成果（路线图、报告、摘要、计划）。在有帮助时注明哪位工作者产出了哪项发现，并保留每项主张的置信度（verified / single-sourced / unverified）——绝不能把 low 置信度包装成确定的表述。

然后自行编写代码/文件，或启动专门的实现波次（注意“并行写入”）。验证交付物，而不仅仅是交接内容：重新运行/curl/验证已提供的产物，对相邻路由进行回归检查，并重新阅读你编写的关键文件（参见 references/verification.md §6）。

有界波次——规模、预算和停止函数

波次有意设定边界——但边界取决于完成情况和预算，而非波次数量。“循环直到完成”的无界模式会浪费大量 token，却收益甚微：候选方案的生成成本低，筛选效果会趋于平缓，而额外轮次的效果并非单调——更多迭代可能会降低质量，而不只是增加成本。另一种失败同样真实：清单中仍有未完成的切片，却提前停止。 有界波次既保留探索过程，又避免失控，绝不放弃尚未终结的工作。

• 宽度：每波 N = 3–8 个工作者。 设置 N 时，确保你能全面验证所有 N 个。只有在廉价的自动检查（测试、架构、执行）能把关结果时，才扩大规模。（依据：同质 Agent 团队的效果在 N≈4–8 时趋于平缓——新增工作者提供的证据会重复，突破上限靠的是多样性，而非人数——arXiv 2606.02646、2602.03794。实际情况是，Cursor 员工确认没有固定的子 Agent 上限，但约 40 个并发工作者可能会使扩展宿主不堪重负：应分批执行。）
• 深度：清单就是停止函数。 只要清单中有任何切片尚未终结，且上一波取得了经验证的进展，就继续扩展。只有满足以下三种条件之一时才停止：完成（所有切片均已终结，且综合整理已完成）、停滞（某一波没有带来新内容，且其输出与上一波高度重复，或质量下降），或预算耗尽。在运行配置行中预先说明预算——设置工作者或 token 预算，而非波次数量（例如 budget: ~20 workers）。不要因为经过了整数波次就停止；实际运行往往会在三波中分别安排 12 + 3 + 1 个工作者，而针对模糊目标的分解级联也可能合理地运行更多波次。（依据：由验证驱动的重规划循环依据完整性阈值、收益递减和 token 预算停止——而非固定迭代上限——arXiv 2603.11445；在质量相当时，基于收敛的停止策略优于固定的 max_iterations，arXiv 2606.27009。）
• 侦察成本低——别让它耗尽预算。 降低熵的波次（侦察、分解）使用廉价模型，并与执行预算分开计算。绝不要在执行开始前就因发现阶段耗尽上限，而以“波次用尽”为由结束运行。
• 预算分配：约 60% 用于生成 / 40% 用于验证。 筛选才是稀缺资源；把预算花在那里。
• 根据难度匹配宽度： 简单 → 1 + 一轮轻量优化；中等 → 3–5；困难／开放式 → 5–8，以增加方法多样性；最难／新颖 → 不要循环，升级模型。
• 防污染交接： 只把提炼过且经过验证的交接内容（胜出方案 + 简短评议）带入下一波——绝不带原始对话记录或落选方案。冗长且无关的上下文会显著降低推理能力。

只有在以下所有条件都满足时，循环直到完成才合理： 存在廉价且可靠的~ground-truth 验证器；信号清晰且可操作（例如测试失败，而不是“再努力些”）；每次迭代都能显示可衡量的进展；工作难度为简单到中等；并且始终设有严格上限。这适用于附带测试的代码任务和执行反馈流水线；不适用于开放式研究、写作或设计（应改用有界波次进行验证）。

验证

编排器最能发挥杠杆效应的工作。你无法在推理时让工作者变得更聪明，但验证交接的成本远低于产出交接；在多轮运行中，一个未经检查的错误交接会不断累积，最终影响综合结果。

• 生成前设关卡 — 检查数量、覆盖范围和分区总和（步骤 0.5）。
• 每次交接都做低成本检查 — 是否提供证据且证据可解析、范围是否匹配、快速检查是否存在矛盾、引用是否确实支持相关论点。
• 在提示词中加入自检要求 — 要求提供引用或删除论点、添加置信度标记、完整阅读、使用实时来源、标记未经验证的内容。（不要依赖随意的“再检查一遍”；应提供判定依据或安排独立验证者。）
• 对高风险、有争议或引用密集的论点，安排专职验证工作者 — 提供论点和来源，但不要提供生成者的推理，也不要标明作者身份（评判者会偏向标记为自己产出的内容；应对其隐藏作者身份），并要求其先依据评分标准或参考资料进行推理，再给出结论（参考资料引导 + CoT 是最具成本效益且可靠的评判者升级方案）。绝不要向生成者展示验证者的评分标准（防止其钻空子）。对于风险最高的判断，可使用多模型评审组 + 综合检查，进一步加强验证（参见“多模型扇出”）。
• 衡量并交叉核对 — 重新运行判定依据，从来源重新计数，并要求至少有 2 个独立来源确实蕴含该论点（存在引用 ≠ 论点得到支持）。
• 对低置信度或相互矛盾的发现进行升级处理（使用更严格的提示词重新分配任务 → 安排专职验证者 → 询问用户，用户可以选择更强大的模型），而不是将其纳入结果。

这套方法最适用于客观、可核查的工作（计数、代码、有来源支撑的事实）；对于品味和判断，应验证子论点，不要伪造评分。诚实表述结论：隔离可以减少错误传播和路径依赖，但不要声称它能以量化方式“防止投毒”——目前没有仅针对隔离的消融实验。完整指南：references/verification.md。

选择 subagent_type

切片类型	使用	备注
只读代码／数据探索	explore	快速，按设计为只读——而只读模式会阻止所有 MCP 工具。传入详尽程度：「quick」／「medium」／「very thorough」。
需要网页／MCP（Exa、Ref、文档）的研究	generalPurpose	多步骤；可使用可用的网页／MCP 工具。不要设置 readonly: true（只读会阻止所有 MCP）。
混合读取与轻度推理的多步骤工作	generalPurpose	通用主力工具。
以 Shell／git 为主的调查	shell	命令执行专家。
浏览器测试／UI 验证	browser-use	可浏览并截屏。有状态：会自动恢复同一个共享实例，因此不要并行分发多个 browser-use——使用单个串行 UI 切片。需要 Agent 模式（不能为 readonly）。
针对同一任务的多种竞争方案	best-of-n-runner	每个方案都在隔离的 git worktree／分支中运行——不会互相覆盖共享检出内容；之后可比较方案并合并胜出的方案。

不同界面中的命名差异。 Cursor 文档将内置类型称为 explore、bash 和 browser，而 Task 工具的架构会公开 因界面而异的取值（generalPurpose、explore、shell、browser-use、 best-of-n-runner、审查专家等）。请从 Task 工具读取实时的 subagent_type 枚举， 不要想当然地使用此表中的名称——角色保持稳定，标签则会变化。

自定义子 Agent 与缺失类型的回退方案。 自定义子 Agent（项目中的 .cursor/agents/、用户目录下的 ~/.cursor/agents/，或插件提供的类型）会显示为独立的 subagent_type 取值——如果某个角色会在多次运行中重复执行（例如验证者、文档研究员），值得为其定义一个类型，让它的提示词、固定的 model、readonly 和 is_background 默认值都保存在同一个文件中。两条已验证的注意事项 （经员工在论坛确认，文档中未提及）：新的 Agent 文件只有在重启 Cursor 后才会注册；如果枚举中缺少某个类型，并不意味着 可以跳过该角色——应改用 generalPurpose 运行，并将该角色的指令直接写入工作 Agent 的提示词中（调用时传入预期的 model）。关于嵌套：平台现在允许主 Agent 及其直接子 Agent 启动子 Agent（多一层，不可更深——SDK 文档也说明了相同的层级限制）；但本技能仍按策略仅允许编排器进行分发，因为嵌套分发会导致清单无法追踪工作，也会绕过验证关卡。

按切片选择模型（成本／速度路由）

模型选择是调节成本和速度的手段——应按需路由，而不是让每个切片都使用前沿模型：

• 侦察／分解／以阅读为主的探索 → 便宜、快速的模型。 Cursor 内置的 explore 和搜索子 Agent 默认就使用 Composer 快速系列（例如 composer-2.5-fast），正是为此而设计：速度快、成本低，并针对代码库理解和工具使用进行了优化，因此读取阶段默认成本就很低，而且通常无需设置 model。若要指定模型，可在 Task 工作线程上传入 model: "composer-2.5"，或者在自定义 .cursor/agents/ 子 Agent 中设置 model 字段（inherit | 模型 ID）。对于 GPT 系列中上下文较短的轻量切片，提高推理力度后使用 gpt-5.6-luna，其单位工作成本表现最佳——但绝不要让 Luna 读取长上下文（根据 OpenAI 自己的 MRCR 表格，它在 256K+ 上下文中的回忆能力会大幅下降；应将大型文件切片路由到更强的级别，或切分得更小）。它是减少熵的主力模型。
• 各模型的选项写在模型 ID 后的方括号中（文档规定的语法）： gpt-5.6-sol、claude-opus-4-8[effort=high,context=300k]、 composer-2.5[fast=false]、composer-2.5[]（空方括号会指定标准非快速版本）。使用 [effort=…]，不要猜测单独的“thinking”版本名称。
• 高风险验证、综合分析或多模型小组 → 审慎选择更强的推理能力 （例如使用 effort=high 的前沿级别，仅在某个切片仍未解决时才提高推理力度）。对于用户要求的或高风险的多模型小组，请询问要使用哪些模型；不要猜测版本名称（参见“多模型扇出”）。
• 其他情况下，遵循用户指定的模型；如果所请求的模型不可用，应明确说明，不要悄悄换用其他模型。

注意事项：可用性因情况而异（Max Mode、套餐或管理员限制可能会强制回退到兼容模型；不支持 Max Mode 的旧版按请求计费套餐无论 model 配置如何，都会让子 Agent 使用 Composer）；版本名称可能会变动，因此应从 Cursor 的模型选择器中查看，而不要硬编码易变的名称；inherit 在某些界面中可能不可靠（省略 model 以继承）。如果自定义 Agent 的模型选择很重要，请在 frontmatter 中指定模型，并且在 Task 调用中传入匹配的 model——某些情况下该字段会被忽略（文档记录的回退行为和已确认的 Bug 报告均有说明），因此，如果工作线程的输出质量不理想，请考虑它可能没有运行预期的模型。无论这里的默认设置是什么，都应尊重用户对成本和模型的偏好。

对于审查／审计切片，Cursor 还提供专用子 Agent（如 bugbot、security-review、ci-investigator、ci-watcher）；在这些切片类型中，优先使用它们。

多模型扇出（面板 + 综合）

默认的扇出会让一个模型处理每个 切片。对于 高风险 切片—— 例如架构／设计决策、高风险的正确性问题、安全或审计审查， 或关键研究综合——将 同一个 切片扇出给由不同模型组成的 面板，然后由你充当裁判并进行综合。

要协调各方结果，不要简单拼接。标注 CONSENSUS（2 个或更多模型达成一致） 与单模型发现，解决矛盾、去除重叠内容，并在统一答案中保留每项结论的置信度。 大部分价值都来自综合环节——根据 OpenRouter 的 Fusion 研究，大约四分之三的提升 来自综合步骤，而非模型多样性——因此应把精力投入综合，而不是把输出生硬地拼在一起。 证据：由多个独立模型、裁判和综合器组成的面板，在高难度深度研究问题上 达到并超越了单个顶级模型（OpenRouter，Surpassing Frontier Performance with Fusion，openrouter.ai/blog/announcements/fusion-beats-frontier/）。

在 Cursor 中运行：为同一切片上的每个同级 Task worker 传入不同的 model， 并在一条消息中启动它们（并行运行；如果当前界面支持，则放到后台），然后进行综合。 这是模型路由中面向高风险任务的一端——只有在用户要求进行多模型审查 或该切片明确属于高风险时，编排器才会选择前沿模型——因此应询问要使用哪些模型； 不要猜测 slug。（低成本的一端——将侦察和以读取为主的任务波路由到 Composer 2.5—— 见“按切片选择模型”。）

注意：面板会成倍增加 token 成本（每个 worker 都要付费），也会增加延迟—— 应仅将其用于高风险切片，而非日常任务。对抗式多模型审查（由审查模型组成的面板

• 一个综合判定）就是将同一模式应用于代码审查。特别是对于评分面板， 从互不重叠的模型家族中选出的裁判，在与人类意见一致方面胜过单个前沿裁判， 同时降低了自我偏好偏差和成本（PoLL）——发挥作用的是模型家族的多样性， 而非模型数量。

生成与筛选及锦标赛

对于开放式构思或“产出最好的一个 X”，应生成多个候选项并进行筛选—— 不要只相信一次尝试：

• 先做低成本筛选。 在花费裁判 token 之前，先用接近真实情况的检查 （测试、schema／exec、去重／聚类）筛选候选项——生成成本低，评判成本高。 （AlphaCode 的做法：生成大量候选项 → 通过测试筛掉约 99% → 聚类 → 提交少数几个。）
• 采用筛选梯级，而非全量两两比较。 去重／聚类 → 列入候选名单 → 仅在最终候选项之间进行两两评判。 朴素的 O(N²) 锦标赛会把大部分 token 花在比较落选者上。
• 对相互竞争的实现尝试（每个尝试都在自己的 git worktree 中）使用 best-of-n-runner， 然后自行检查、测试并合并获胜者。
• 对于高风险的判断决策，可使用上文的多模型面板，它相当于用于验证的生成与筛选。
• 检查预算。 在成本相同的情况下，k 次独立尝试加多数投票或低成本筛选通常优于批评／辩论循环—— 在为任何迭代循环付费之前，先以此基线进行基准测试。

Worker 提示词 = 契约

Worker 不能追问。提示词描述不充分，工作就会悄然偏离。 每个提示词都要写得像只有一次机会。每个 Worker 提示词都包含：

1. 总体目标（仅作背景——“不要试图包揽整个目标”）。
2. 该 Worker 的确切工作范围（互不重叠的范围／区域／路径）。
3. 查阅位置（目录、文件、数据范围，以及要使用的 MCP／工具）。
4. 返回内容——采用 references/handoff-format.md 中的结构化交接格式。
5. 自我验证规则——每项声明都要引用依据，否则删除；标注置信度 （high|med|low），并说明哪些内容无法验证。分析 Worker： “完整阅读（N 行）并报告行数。”研究 Worker：“使用实时来源，而非训练数据。”
6. 范围边界——明确说明哪些内容不在范围内（避免与同级 Worker 重叠）。
7. 只返回交接内容，并保持精简。 Worker 的整条最终消息都会成为你的上下文——要求它只返回结构化交接内容，最多约 15 条发现，每条附一行证据；任何大型产物（表格、日志、完整清单）都写入文件，并引用路径，不要直接粘贴。
8. 编辑 Worker：你并非独自工作。 对于实现工作范围，要提醒 Worker：同级 Worker 可能同时在工作；只能修改列出的路径，不要撤销他人的更改，并且绝不可自行启动子 Agent（只有协调者负责分派）。

请参阅 references/handoff-format.md，获取可直接复制的 Worker 交接模板；参阅 references/examples.md，查看完整的实战运行示例（截图中的健康教练研究任务）和可复用的拆解方案。

并行写入（本地的注意事项）

本地子 Agent 共用同一个工作目录。 并发写入重叠文件会互相覆盖。

• 并行读取／研究／分析：始终安全。这是默认用法。
• 互不重叠且都要保留的编辑：只有路径集合严格互不重叠时，才使用常规 Worker；否则，等研究阶段完成后再串行编辑。
• 针对同一任务的竞争性尝试：使用 best-of-n-runner（每个尝试都在自己的 git worktree／分支中），然后由你检查、测试并合并选中的结果——worktree 可以避免互相覆盖，但不能避免合并冲突。

采用 Waves，而非云端编排

Waves 有意作为云端分派的替代方案，而非迈向云端分派的垫脚石。本地子 Agent 运行涵盖了此技能所针对的全部工作负载——研究、审计、数据分析、探索和有界实现——并提供隔离、并行、续跑和验证，同时无需任何云端配置（独立 VM、API 密钥、运行时）。Cursor 团队云端 orchestrate 插件中值得保留的经验，已经融入此技能：规划者负责规划，Worker 向上级交接，不相互交流，以磁盘／git 作为持久媒介。使用 Waves 时，不要启动云端 Agent；如果某次运行确实超出单台机器的能力（持续数天的任务群、每项任务各开一个 PR 的流水线），那就该选择其他工具，由用户决定——说明这一点并让用户自行决定。

此处关于 Cursor 子 Agent 机制的信息于 2026-07-19 根据当前文档、更新日志和员工论坛回复核实：在一条消息中并行调用 Task 是文档记录的分派方式；is_background frontmatter 是文档记录的后台开关，而每次调用的 run_in_background 虽然已在使用中，却未见于文档，且并非所有界面都支持；已完成的子 Agent 会保留续跑检查点（CLI 版本于 2026-07-06 发布）；嵌套最多额外一层；只读模式会屏蔽所有 MCP；文档未规定并发上限，但员工报告称，约 40 个并发 Worker 可能会使扩展宿主不堪重负——应分批运行。最可能发生变化的细节包括：Task 参数名称、subagent_type 枚举值和模型 ID 的方括号选项。如果这些信息对你的运行很重要，请重新核实。

检查清单

• 拆分前先了解问题的整体形态。
• 切分前先降低不确定性（先本地调查 → 再查阅附带资源 → 只有确有必要时才询问用户）；切分低不确定性的目标。
• 启动任务前用一行说明运行形态（拿不准时 → 选择较小的形态）；绝不把内联工作说成覆盖了多个波次。
• 对每个切片进行分类（工作者类型 + 依赖项 + 验证级别）。
• 将侦察 / 阅读密集型波次分配给便宜且快速的模型（Composer 2.5，或仅用于短上下文切片的 gpt-5.6-luna）；将前沿模型 / 专家组模型留给高风险切片；绝不让 Luna 类模型处理长上下文阅读。
• 各切片相互独立（数据 / 区域 / 路径不重叠），否则就在清单中记录其 depends_on 边。
• 启动前编写波次清单（切片 / 工作者类型 / 模型 / depends_on / 验证级别）；只有在依赖项的交接内容经过验证后，才启动依赖切片（将提炼后的发现纳入其提示词）。
• 每个工作者提示词都完整自洽（不依赖聊天记录）。
• 每个波次的 Task 调用都在一条消息中发送；在界面支持的情况下放到后台运行（is_background / run_in_background）。
• 结束本轮，等待后台任务完成——不要循环轮询。
• 不让两个并行工作者写入相同路径。
• 启动前验证覆盖范围（数量 / 边界 / 分区总和）。
• 收集时逐项核对清单中的所有行（完成门槛）；对缺失 / 受阻的切片执行失败处理阶梯——不得悄然丢弃任何切片。
• 阅读每份交接内容；针对未解决的问题启动后续任务。
• 波次受清单 + 明确预算约束（宽度 ≈3–8；侦察波次单独计数）：只要切片尚未结束且进度已验证，就继续推进；仅在完成、停滞或预算耗尽时停止——跳过后续波次时，须说明适用的三种无需启动第二波情况中的哪一种。
• 后续只传递提炼后的交接内容；在每次综合 / 压缩过程中，逐字保留清单、停止条件和预算。
• 验证每份交接中的证据（不只检查其 Status）；对低置信度 / 相互矛盾 / 未引用来源的发现升级处理；仅根据已通过结论审核的发现编写 synthesis-wave-N.md（待验证主张须标记为 pending-verification，绝不传递给依赖切片）。
• 验证最终交付物（重新运行 / 验证；重新检查关键写入内容）。
• 根据交接内容综合形成一份交付物。