Back to Details

waves

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

WAVES — Workers · Aggregate · Verify · Extend (Cursor)

WAVES — Workers · Aggregate · Verify · Extend（适用于Cursor）

Run wave-based orchestration inside one local Cursor session. A wave is a bounded round of isolated agents working in parallel, then a round that verifies what came back, then a deliberate decision to build on it — not an open-ended loop. You are the orchestrator: you discover, decompose the goal into independent slices, fan them out to parallel workers (multiple 
Task
tool calls in one message, backgrounded where the surface supports it), read each worker's structured handoff, verify it, and synthesize one deliverable. Workers are isolated and return exactly one handoff.
The shape of every wave — WAVE:
  • W — Workers. Fan out isolated workers across disjoint slices (the bounded parallel round).
  • A — Aggregate. Wait for all of them and merge their structured handoffs at the synthesize barrier.
  • V — Verify. The moat: check the evidence behind each handoff before you trust it.
  • E — Extend. Decide — deliberately — whether to launch another wave, or stop.
A loop doesn't know when to stop; a wave does, because verification is the stop function. (Invoked explicitly with 
/waves
: a run spawns more agents than usual, so it's opt-in, not auto-triggered.)
Waves runs in place of cloud orchestration. It adopts the principles the Cursor team proved out in their cloud 
orchestrate
plugin — planners plan, workers hand off up, no cross-talk — but runs them on local subagents with zero setup: no separate cloud agents, no API keys, no runtime. Local subagent runs are the whole story here.
在单个本地Cursor会话中运行基于波的编排。一个波是指一轮受限的、由独立代理并行执行的任务，之后是一轮对返回结果的验证，再是决定是否基于结果继续推进——而非无限循环。你作为编排器：负责发现目标、将目标分解为独立切片、将切片分发到并行的工作代理（在一条消息中调用多个
Task
工具，在支持的环境中后台运行）、读取每个工作代理的结构化交付结果、验证结果，并合成最终交付物。工作代理相互隔离，且仅返回一份交付结果。
每一波的核心流程——WAVE：
  • W — Workers（工作代理）：将独立工作代理分发到互不重叠的任务切片（受限的并行轮次）。
  • A — Aggregate（聚合）：等待所有工作代理完成，在合成阶段合并它们的结构化交付结果。
  • V — Verify（验证）：安全屏障：在信任交付结果前，检查每个结果背后的证据。
  • E — Extend（扩展）：自主决定是否启动下一波，或停止流程。
循环不知道何时停止，但“波”清楚停止时机，因为验证就是停止触发条件。（通过
/waves
显式调用：一次运行会生成比常规更多的代理，因此是可选触发，而非自动执行。）
Waves可替代云编排运行。它采用了Cursor团队在云
orchestrate
插件中验证过的原则——规划者负责规划，工作代理向上交付结果，无交叉通信——但在本地子代理上运行，无需任何设置：无需独立云代理、API密钥或运行时。本地子代理运行就是整个流程的全部内容。

When to use

适用场景

  • A large goal that splits into independent slices (research areas, data chunks, files/modules, audit dimensions).
  • The work is mostly read / research / analysis — the safest thing to parallelize locally (see "Parallel writes" for why).
  • A single linear pass would be slow and you want real speedup from concurrency.
  • 大型目标可拆分为独立切片（研究领域、数据块、文件/模块、审计维度）。
  • 工作内容以读取/研究/分析为主——这是本地并行处理最安全的场景（参见“并行写入”说明）。
  • 线性处理速度过慢，希望通过并发实现实质性提速。

When to skip

不适用场景

  • Small or linear tasks (just do them — fan-out overhead isn't worth it).
  • Work needing tight back-and-forth or shared mutable state between steps.
  • Parallel edits to the same files — local workers share one filesystem.
  • 小型或线性任务（直接处理即可——分发带来的开销得不偿失）。
  • 需要步骤间紧密交互或共享可变状态的工作。
  • 对同一文件进行并行编辑——本地工作代理共享同一个文件系统。

Core principles

核心原则

Adapted from 
orchestrate
. These keep the run converging without coordination.
  1. Orchestrator plans and synthesizes; it does not do the heavy lifting. Discovering, decomposing, reading handoffs, and writing the final deliverable are your job. The bulk reading/research/analysis is delegated to workers.
  2. Workers are isolated. A subagent has no access to the user's message, your prior steps, or sibling workers. Every worker prompt must be fully self-contained: goal context, its exact slice, where to look, what to return.
  3. One worker, one slice, one handoff. The worker's final message is the only thing you read back. Define its exact shape (see 
    references/handoff-format.md
    ).
  4. Parallelism is for reading, not writing. Local workers share the workspace; concurrent writes to overlapping paths corrupt each other.
  5. Continuous motion. A handoff can reveal new work. Spawn a second wave (driven by a handoff gap or a new user request). Stop only when every slice is terminal and the synthesis is complete.
  6. Verify before you trust. A worker's 
    Status: success
    is a claim, not evidence. Check each handoff against something re-openable before folding it into the synthesis. See "Verification" below and 
    references/verification.md
    .
  7. Decomposition is entropy reduction. A vague goal is high-entropy — many plausible plans still fit it. Your first job is to shrink that space (dig locally, then pull from attached resources, then ask the user only if it pays) before you slice it; slicing a high-entropy goal yields overlapping, mis-sized slices. See "Entropy-first decomposition."
改编自
orchestrate
插件。这些原则确保流程收敛且无需额外协调。
  1. 编排器负责规划与合成，不承担繁重工作。发现目标、分解任务、读取交付结果、撰写最终交付物是你的职责。大量的读取/研究/分析工作会委托给工作代理。
  2. 工作代理相互隔离。子代理无法访问用户消息、你的历史步骤或其他同级工作代理。每个工作代理的提示必须完全独立：包含目标上下文、具体任务切片、查找位置、返回要求。
  3. 一个工作代理、一个切片、一份交付结果。工作代理的最终消息是你唯一需要读取的内容。需定义交付结果的精确格式（参见
    references/handoff-format.md
    ）。
  4. 并行适用于读取，而非写入。本地工作代理共享工作区；对重叠路径的并发写入会导致数据损坏。
  5. 持续推进。交付结果可能揭示新的工作内容。启动第二波（由交付结果的缺口或新的用户请求驱动）。仅当所有切片完成且合成工作结束时才停止。
  6. 验证后再信任。工作代理的
    Status: success
    只是一个声明，而非证据。在将结果纳入合成前，需对照可重新查看的来源检查每个交付结果。参见下文“验证”部分及
    references/verification.md
    。
  7. 分解是熵减过程。模糊的目标熵值高——许多可行计划都符合该目标。你的首要任务是缩小这个范围（先本地探索，再从附加资源中获取信息，仅在必要时询问用户）之后再进行切片；对高熵目标切片会导致任务重叠、大小不均。参见“先熵减再分解”。

Entropy-first decomposition

先熵减再分解

Before you fan out, treat the goal as an entropy-reduction problem: shrink how many plausible interpretations and plans still fit what you know. A vague, high-entropy request ("build a Flappy Bird game", "make my app faster") doesn't slice cleanly yet — reduce the uncertainty first, then decompose the low-entropy version. Name what's uncertain, because the two kinds resolve differently:
  • Specification uncertainty — what the user wants (ambiguous goal, missing acceptance criteria, unstated constraints). Resolve by stating an explicit assumption and proceeding — or, only when a wrong guess is expensive, by asking.
  • Environment / knowledge uncertainty — facts you don't have yet but can get (repo shape, schema, API behavior, current docs, data size). Resolve by gathering, not by asking.
Spend the cheapest action that buys the most certainty first — an information-gain ladder — and aim each probe at the unknown whose answer eliminates the most plans: the highest-information question is the one that splits the surviving interpretations roughly in half, not the one easiest to look up.
  1. Dig locally first (cheap). Tool calls in the main session (list, read the schema/README, grep, sample data). This is Step 0, framed as entropy reduction; it often collapses most of the uncertainty for free.
  2. Then pull from attached resources. If the environment doesn't hold the answer, spawn a small scouting wave of research workers to fetch it (web, Exa/Ref MCP, docs) — route these read-heavy slices to the cheap, fast model (see "Picking the model per slice").
  3. Ask the user last, and only when it pays. Ask only when residual specification uncertainty is high and the question's expected information gain clearly beats its cost. Most requests carry enough to proceed on a stated assumption; over-asking is its own failure mode.
Then cascade: one high-level request becomes a decomposition wave (understand → locate unknowns → draft the plan) → verify → an execution wave that builds the ordered subtasks, with more scouting sub-waves wherever entropy stays high. Order the plan least-to-most — do the first-order subtasks first and let each verified result lower the uncertainty for the next. Keep the living plan in 
TodoWrite
, and stop reducing when entropy is low enough to act: the verification gate doubles as "is the uncertainty low enough to commit?" One caution: a plan-then-execute pass fixes missing steps, not a misread goal — only the specification check above catches wrong framing, which is why it comes before planning. (Worked example + wave shape + paper grounding: 
references/examples.md
.)
在分发任务前，将目标视为熵减问题：缩小符合当前认知的可行解释与计划的范围。模糊、高熵的请求（如“制作一款Flappy Bird游戏”、“让我的应用更快”）无法清晰切片——先降低不确定性，再对低熵版本进行分解。明确指出不确定的内容，因为两类不确定性的解决方式不同：
  • 需求不确定性——用户想要什么（目标模糊、验收标准缺失、未说明的约束）。通过明确假设并推进来解决——仅当错误猜测成本高昂时，才询问用户。
  • 环境/知识不确定性——你尚未掌握但可以获取的事实（仓库结构、 schema、API行为、当前文档、数据规模）。通过收集信息解决，而非询问用户。
先执行能获取最大确定性的最廉价操作——即信息增益阶梯——并将每个探索指向能排除最多计划的未知内容：最高信息价值的问题是能将剩余解释大致一分为二的问题，而非最易查找的问题。
  1. 先本地探索（成本低）。在主会话中调用工具（列出目录、读取schema/README、grep、抽样数据）。这是第0步，以熵减为目标；通常能免费消除大部分不确定性。
  2. 再从附加资源中获取信息。如果环境中没有答案，生成一个小型侦察波研究工作代理来获取信息（网页、Exa/Ref MCP、文档）——将这些读取密集型切片分配给廉价、快速的模型（参见“为切片选择模型”）。
  3. 最后才询问用户，且仅当值得时。仅当剩余的需求不确定性高，且问题的预期信息增益明显超过其成本时才询问。大多数请求包含足够信息，可基于明确假设推进；过度询问本身就是一种失败模式。
然后分层推进：一个高级请求变为分解波（理解→定位未知→草拟计划）→验证→执行波，构建有序子任务，在熵值仍高的地方启动更多侦察子波。按从易到难的顺序规划：先完成一阶子任务，让每个已验证的结果降低后续任务的不确定性。将动态计划保存在
TodoWrite
中，当熵值低到可执行时停止熵减：验证关口同时也是“不确定性是否足够低以执行？”的判断标准。注意：先计划再执行的流程能修复缺失步骤，但无法修复对目标的误解——只有上述的需求检查能发现错误框架，因此它必须在规划之前进行。（示例+波流程+理论依据：
references/examples.md
）

The loop

流程循环

Track it with 
TodoWrite
so the waves stay visible.
使用
TodoWrite
跟踪流程，确保波的进度可见。

Step 0 — Discover first (serial, in the main session)

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

Do not fan out blind. Spend a few cheap tool calls in the main session to learn the shape of the problem: list the directory, read the schema, sample the data, confirm coverage/size. This is what tells you the natural decomposition (how many chunks, which workstreams). Skipping discovery produces overlapping or mis-sized slices.
不要盲目分发任务。在主会话中执行几次低成本工具调用，了解问题的结构：列出目录、读取schema、抽样数据、确认覆盖范围/规模。这能告诉你自然的分解方式（分多少块、哪些工作流）。跳过探索会导致切片重叠或大小不均。

Step 0.5 — Stage the data (when it's remote or messy)

第0.5步——准备数据（当数据远程或杂乱时）

explore
workers are read-only by design, and read-only mode blocks all MCP tools (Cursor staff-confirmed), so they can't reach databases or MCP-backed sources. If the source is remote or wrapped in noise, the orchestrator must stage clean inputs before fanning out:
  • Pull remote → local. SSH/
    rsync
    /export the relevant data to a local scratch dir so read-only workers can read it (e.g. query a remote SQLite read-only, export the rows, 
    rsync
    the markdown).
  • Clean + normalize once, centrally. Strip wrappers, boilerplate, and binary blobs (base64, logs); fix timestamps. Doing this once beats making every worker re-derive it (and keeps noise out of their context).
  • Pre-chunk for the workers. Split into the exact per-worker files/ranges so each prompt can point at one path.
  • One scratch dir per run. Keep staged inputs, worker artifacts, and between-wave syntheses in one place (e.g. 
    .waves/<run>/
    with 
    staging/
    , 
    handoffs/
    , 
    synthesis-wave-N.md
    ) so prompts cite paths instead of pasting content and later waves re-read files, not chat history.
  • Verify before you spawn. Print counts and per-slice bounds; confirm the partition sums to the total (e.g. 8 chunks × ~388 = 3,097) so no slice is a silent blind spot. Fix anomalies (bad sort, dups) centrally, then re-check. (Details: 
    references/verification.md
    §1.)
In practice this serial prep is often the largest phase; the parallel fan-out is fast once inputs are clean.
explore
工作代理设计为只读模式，且只读模式会阻止所有MCP工具（Cursor团队已确认），因此它们无法访问数据库或MCP支持的数据源。如果数据源是远程的或包含大量噪声，编排器必须在分发任务前准备干净的输入：
  • 远程→本地拉取。通过SSH/
    rsync
    /导出将相关数据拉取到本地临时目录，以便只读工作代理读取（例如，查询远程只读SQLite，导出行数据，
    rsync
    markdown文件）。
  • 集中清理与标准化一次。去除包装器、样板代码和二进制 blob（base64、日志）；修复时间戳。集中处理一次比让每个工作代理重复处理更高效（还能避免噪声进入它们的上下文）。
  • 为工作代理预分块。将数据拆分为每个工作代理对应的精确文件/范围，以便每个提示可指向单个路径。
  • 每次运行使用一个临时目录。将准备好的输入、工作代理产物、波间合成结果保存在一个位置（例如
    .waves/<run>/
    下的
    staging/
    、
    handoffs/
    、
    synthesis-wave-N.md
    ），以便提示引用路径而非粘贴内容，后续波读取文件而非聊天历史。
  • 生成前验证。打印数量和每个切片的边界；确认分区总和等于总量（例如8块×约388=3097），确保没有切片被遗漏。集中修复异常（错误排序、重复），然后重新检查。（详情：
    references/verification.md
    第1节）
实际上，这个串行准备阶段通常是最大的阶段；输入清理完成后，并行分发任务会很快。

Step 0.7 — Triage: size the run, then classify each slice

第0.7步——分类：确定运行规模，然后对每个切片分类

Size the run first, out loud. Weigh breadth (how many independent slices), depth (how much reasoning each needs), ambiguity (how well-formed the goal is — see "Entropy-first decomposition"), and stakes (how costly a wrong answer is — this sets verification tiers), then state the chosen shape in one line before spawning — e.g. 
Run shape: one wave, 4 workers (3 research + 1 data chunk); second wave only if handoffs expose gaps.
On the fence between two shapes, pick the smaller and say so. And if triage says no wave is needed, do the task inline and say that — never present inline work as wave coverage.
Then classify each slice on three axes — this is the classify-and-act pattern, routing the right work to the right handler:
  • Worker type — read-only (
    explore
    ) / web-research (
    generalPurpose
    ) / shell / competing-attempt (
    best-of-n-runner
    ) / specialized review (
    bugbot
    , 
    security-review
    ). (See the table under "Choosing 
    subagent_type
    ".)
  • Dependencies — which slices (if any) this one needs verified output from. Most slices should have none; a real dependency edge is what separates waves.
  • Verification tier — how much checking the slice's stakes justify: 
    auto-accept
    (low-stakes, corroborated) → 
    single verifier
    (medium) → 
    multi-model panel
    (high-stakes) → 
    debate
    (contested, no ground truth). Spend the verification budget where a wrong claim is expensive, not uniformly.
Record the triage as a wave manifest — one row per slice, written before you spawn (in 
TodoWrite
or 
.waves/<run>/manifest.md
):
slicescopeworker typemodeldepends_onverification tier
1msgs 1–500explore(default fast)—auto-accept
2voice-stack researchgeneralPurpose(default)—single verifier
3voice build spikegeneralPurpose(default)2single verifier
depends_on
defines the wave boundaries: a wave is every not-yet-run slice whose dependencies are all met — and a dependency is met only when its handoff has been verified (Step 3), not merely returned. Launch wave 1 (no dependencies) in parallel; launch each dependent slice with the distilled, verified findings (or their 
.waves/<run>/
path) folded into its self-contained prompt — and unrelated slices stay parallel. The manifest is also your completion gate: N rows spawned means N handoffs collected and checked off before synthesis — a wave with a missing handoff has a silent hole in it (Step 3).
先明确运行规模。权衡广度（独立切片数量）、深度（每个切片所需的推理量）、模糊性（目标的明确程度——参见“先熵减再分解”）和风险（错误答案的成本——这决定了验证层级），然后在生成前用一句话说明所选的流程形态——例如
流程形态：一波，4个工作代理（3个研究+1个数据块）；仅当交付结果暴露缺口时启动第二波
。如果在两种形态间犹豫，选择较小的形态并说明。如果分类表明不需要波，直接在本地处理任务并说明——绝不要将本地工作伪装成波处理。
然后从三个维度对每个切片分类——这是分类执行模式，将合适的工作分配给合适的处理者：
  • 工作代理类型——只读（
    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
）：
切片范围工作代理类型模型依赖项验证层级
1消息1–500explore（默认快速模型）—auto-accept
2语音栈研究generalPurpose（默认）—single verifier
3语音构建原型generalPurpose（默认）2single verifier
depends_on
定义了波的边界：一波包含所有未运行且依赖项已满足的切片——且依赖项仅在其交付结果已验证（第3步）时才视为满足，而非仅返回结果。并行启动第1波（无依赖）；将提炼后的已验证发现（或其
.waves/<run>/
路径）纳入独立提示后，再启动每个依赖切片——无关切片保持并行。清单也是你的完成关口：生成N个切片意味着要收集并检查N个交付结果——缺少交付结果的波会存在隐性缺口（第3步）。

Step 1 — Decompose into independent slices

第1步——分解为独立切片

Split along whichever axis makes slices independent:
  • Data chunks — partition large data and give each worker a disjoint range (e.g. messages 1–500, 501–1000, …).
  • Workstreams — separate research/analysis areas (e.g. "research voice stack", "research the Notion SDK", "audit auth code").
  • Files / modules — disjoint, non-overlapping path sets.
Each slice needs: a one-line scope, what to look at, and a defined output. For a big wave (roughly 5+ workers), state the decomposition plan to the user before spawning so they can redirect cheaply. If you have many slices, fan out in waves (launch a batch, let it complete, launch the next) rather than all at once, so you stay within practical concurrency limits.
沿使切片独立的任一维度拆分：
  • 数据块——分割大型数据，为每个工作代理分配互不重叠的范围（例如消息1–500、501–1000等）。
  • 工作流——分离研究/分析领域（例如“研究语音栈”、“研究Notion SDK”、“审计认证代码”）。
  • 文件/模块——互不重叠的路径集合。
每个切片需要：一行范围说明、查找位置、定义好的输出。对于大波（约5个以上工作代理），在生成前向用户说明分解计划，以便他们能低成本调整。如果切片数量多，分波分发（启动一批，完成后再启动下一批）而非一次性全部启动，以保持在实际并发限制内。

Step 2 — Fan out in parallel

第2步——并行分发

Send one message with multiple 
Task
tool calls — one per slice whose dependencies are met (handoffs verified, not just returned) — that is what makes them run concurrently (this is the officially documented parallelism mechanism). Pick 
subagent_type
per slice (table below). Give each a 3-5 word 
description
and a self-contained 
prompt
ending with the required handoff format.
Backgrounding is surface-dependent: the documented switch is the 
is_background: true
frontmatter field on custom subagents; a per-call 
run_in_background: true
parameter exists on some surfaces but is undocumented (and absent on others, e.g. cloud agents) — pass it when the schema exposes it, and don't rely on it elsewhere. Background workers include their final message in the completion notification. (
/multitask
is a separate user-facing Agents Window command, not this skill's mechanism.)
When workers run in the background, end your turn. You are notified as each completes — do not 
AwaitShell
, poll, or read output files in a loop. The 
Task
call itself confirms the launch. When the surface runs Task calls synchronously, the batch still executes concurrently and returns together.
发送包含多个
Task
工具调用的一条消息——每个调用对应一个依赖项已满足（交付结果已验证，而非仅返回）的切片——这是实现并发的官方文档方式。为每个切片选择
subagent_type
（见下表）。为每个调用设置3-5个单词的
description
和一个包含所需交付结果格式的独立
prompt
。
后台运行取决于环境：文档化的开关是自定义子代理上的
is_background: true
前置字段；某些环境存在每调用一次的
run_in_background: true
参数，但未文档化（且在其他环境中不存在，如云代理）——当架构支持时传递该参数，否则不要依赖它。后台工作代理会在完成通知中包含最终消息。（
/multitask
是独立的用户侧Agents Window命令，不属于本技能的机制。）
当工作代理在后台运行时，结束你的回合。每个工作代理完成时你会收到通知——请勿使用
AwaitShell
、轮询或循环读取输出文件。
Task
调用本身即可确认启动。当环境同步执行Task调用时，批处理仍会并发执行并一起返回。

Step 3 — Collect and synthesize

第3步——收集与合成

Completion gate first: check off every handoff against the wave manifest — N spawned means N accounted for. A worker that never returns, errors out, or comes back 
partial
/
blocked
is a hole in the wave, and synthesizing around it silently drops a slice. Worker failure ladder: (1) re-task once, narrower — resume the same worker (each 
Task
returns an agent ID that resumes with context preserved; completed subagents persist checkpoints, so a resume restores prior context even after the worker finished) when the slice just needs continuation, or re-spawn fresh with a narrower scope and a note about what came back. Resume only for continuation of the same slice — a resumed worker carries its old slice's context, which contaminates an unrelated assignment; (2) if it fails again, do that slice yourself in the main session; (3) if it stays blocked, carry the slice into the synthesis explicitly as 
not-covered
— never average over a missing slice as if coverage were complete.
As handoffs arrive, read each one: note 
Status
, extract 
Key findings
, and mine 
Open questions
/ 
Suggested follow-ups
— each bullet may become a second-wave task. Reconcile conflicts across workers.
Don't trust a handoff because it says 
success
. Verify each finding's evidence (cited file:line / URL / metric resolves and says what's claimed), recount headline numbers from the source, and route low-confidence, conflicting, or citation-heavy claims to a verifier (Step 3.5). See "Verification" below. A wave's handoffs count as verified only when these checks pass and every claim whose manifest tier demands a verifier has its verdict back — cheap checks alone don't clear a 
single verifier
or higher tier.
Only then compress at the barrier: write the distilled synthesis to 
.waves/<run>/synthesis-wave-N.md
and work from that file — next-wave prompts cite paths into the scratch dir, never re-paste raw handoffs. This file is what dependent slices and later waves consume, so nothing unverified enters it as a finding: a claim still awaiting its verdict is carried only as an explicit 
pending-verification
line.
Pin the constraints through the compression. The wave manifest, the stop conditions/budget, and any safety or scope rules are carried verbatim into every synthesis file and every between-wave summary — never paraphrased or summarized away. Compaction silently drops in-context constraints (measured: violation rates rise from 0% to 30–59% after compaction; pinning restores 0% — arXiv 2606.22528), and a run whose stop conditions got compressed out is a run that loops or quits at random.
先检查完成关口：对照波清单核对每个交付结果——生成N个切片意味着要确认N个结果都已到齐。从未返回、出错或返回
partial
/
blocked
的工作代理是波的缺口，忽略它进行合成会隐性丢失一个切片。工作代理故障处理阶梯：(1) 重新分配一次更窄的任务——恢复同一个工作代理（每个
Task
返回一个代理ID，恢复时会保留上下文；已完成的子代理会保留检查点，因此即使工作代理已完成，恢复也会恢复之前的上下文），当切片仅需继续处理时；或重新生成一个新的工作代理，使用更窄的范围并说明之前的返回结果。仅在同一切片的延续时恢复——恢复的工作代理会携带旧切片的上下文，这会污染无关任务；(2) 如果再次失败，在主会话中自行处理该切片；(3) 如果仍被阻塞，在合成中明确标记为
not-covered
——绝不要将缺失切片视为已覆盖而进行平均处理。
当交付结果到达时，读取每个结果：记录
Status
、提取
Key findings
、挖掘
Open questions
/
Suggested follow-ups
——每个要点都可能成为第二波任务。协调工作代理间的冲突。
不要因为交付结果显示
success
就信任它。验证每个发现的证据（引用的文件:行/URL/指标是否存在且符合声明），从来源重新统计关键数字，将低置信度、有争议或引用密集的声明路由到验证者（第3.5步）。参见下文“验证”部分。一波的交付结果仅在这些检查通过且所有清单层级要求验证的声明都已得到验证结果时，才视为已验证——仅低成本检查无法满足
single verifier
或更高层级的要求。
只有在此时才在合成关口压缩结果：将提炼后的合成结果写入
.waves/<run>/synthesis-wave-N.md
并基于该文件工作——下一波提示引用临时目录中的路径，绝不重新粘贴原始交付结果。该文件是依赖切片和后续波的输入，因此未验证的内容不会作为发现纳入：仍在等待验证结果的声明仅会作为明确的
pending-verification
行保留。
在压缩过程中固定约束条件。波清单、停止条件/预算以及任何安全或范围规则会逐字纳入每个合成文件和每波间的总结——绝不改写或概括。压缩会隐性丢失上下文约束（实测：压缩后违反率从0%升至30–59%；固定约束后恢复至0%——arXiv 2606.22528），停止条件被压缩的流程会随机循环或终止。

Step 3.5 — Verifier pass (when the tier demands it)

第3.5步——验证者处理（当层级要求时）

Before writing the wave synthesis, spawn dedicated verifier workers for every claim whose manifest tier is 
single verifier
or higher — and for anything that arrived contested, surprising, single-sourced, or low-confidence. Give each verifier the claim + its cited sources, no generator reasoning, no authorship labels (see "Verification"). Verifiers can run while you draft around them, but their verdicts gate the wave synthesis itself, not just the final deliverable: until its verdict returns, a claim may sit in 
synthesis-wave-N.md
only as an explicit 
pending-verification
line — never as a settled finding, and never in a dependent slice's prompt (Step 0.7's met-only-when-verified rule).
在写入波合成结果前，为所有清单层级为
single verifier
或更高的声明生成专用验证工作代理——以及所有有争议、意外、单一来源或低置信度的结果。为每个验证者提供声明及其引用来源，不提供生成者的推理过程，不标注作者（参见“验证”）。验证者可在你起草合成结果时运行，但它们的验证结果是波合成结果的关口，而非仅最终交付物的关口：在验证结果返回前，声明只能作为明确的
pending-verification
行出现在
synthesis-wave-N.md
中——绝不能作为已确定的发现，也不能出现在依赖切片的提示中（第0.7步的“仅验证后才满足依赖”规则）。

Step 4 — Second waves (continuous motion)

第4步——第二波（持续推进）

If handoffs exposed gaps or follow-ups — or verified handoffs just unblocked dependent manifest slices — spawn another parallel wave the same way. Repeat until no slice is 
pending
and nothing new surfaced. Stopping early while genuine follow-ups remain is the failure mode this skill guards against; the stop function is the manifest plus the stated budget (see "Bounded waves"), never "we've already done a wave or two."
Skipping a follow-up wave is legitimate in exactly three cases — name which one applies when you decide: the remaining open items are primary-source-verified (a verifier can't improve on the evidence), time-gated (unresolvable until an external event, carry them as explicit open items), or genuinely contested (independent quality sources disagree; more sampling won't settle taste — record the disagreement instead).
如果交付结果暴露了缺口或后续任务——或已验证的交付结果解除了清单中依赖切片的阻塞——以相同方式启动另一并行波。重复此过程，直到没有切片处于
pending
状态且无新内容出现。在仍有真实后续任务时提前停止是本技能要避免的失败模式；停止触发条件是清单加上既定预算（参见“受限波”），而非“我们已经完成一两波了”。
仅在以下三种情况下跳过后续波是合理的——决定时需说明适用哪种情况：剩余未解决项已经主要来源验证（验证者无法改进证据）、受时间限制（需外部事件才能解决，明确标记为未解决项）或存在真实争议（可靠独立来源存在分歧；更多采样无法解决偏好问题——记录分歧即可）。

Step 5 — Deliver

第5步——交付

Synthesize all handoffs into the single artifact the user asked for (roadmap, report, summary, plan). Cite which worker produced which finding when it helps, and carry each claim's confidence through (
verified / single-sourced / unverified
) — never launder a 
low
into a confident sentence.
Then write any code/files yourself, or spawn a dedicated implementation wave (mind "Parallel writes"). Verify the deliverable, not just the handoffs: re-run/
curl
/validate served artifacts, regression-check sibling routes, and re-read the critical files you wrote (see 
references/verification.md
§6).
将所有交付结果合成为用户请求的单个产物（路线图、报告、摘要、计划）。必要时注明哪个工作代理生成了哪个发现，并保留每个声明的置信度（
已验证 / 单一来源 / 未验证
）——绝不要将“低置信度”伪装成确定的表述。
然后自行编写代码/文件，或生成专用的实现波（注意“并行写入”）。验证最终交付物，而非仅验证交付结果：重新运行/
curl
/验证已部署的产物，回归检查同级路由，重新读取你编写的关键文件（参见
references/verification.md
第6节）。

Bounded waves — size, budget, and the stop function

受限波——规模、预算与停止触发条件

A wave is bounded on purpose — but bounded by completion and budget, not by a wave count. "Loop-until-done" unbounded burns tokens for little gain: candidate generation is cheap, selection plateaus, and extra rounds are non-monotonic — more iterations can lower quality, not just cost. Equally real is the opposite failure: stopping while the manifest still has open slices. Bounded waves keep the exploration, drop the runaway, and never abandon un-terminal work.
  • Width: N = 3–8 workers per wave. Size N so you can fully verify all N. Go wider only when a cheap automatic check (tests, schema, exec) gates the results. (Grounding: homogeneous-agent teams plateau around N≈4–8 — added workers contribute redundant evidence, and diversity, not head count, is what escapes the ceiling — arXiv 2606.02646, 2602.03794. Practically, Cursor staff confirm no fixed subagent cap but that ~40 concurrent workers can overwhelm the extension host: batch into waves.)
  • Depth: the manifest is the stop function. Keep extending while any manifest slice is non-terminal and the last wave added verified progress. Stop only on one of three conditions: completion (every slice terminal and the synthesis done), stagnation (a wave surfaces nothing new and its outputs near-duplicate the last, or quality dropped), or budget exhaustion. State the budget up front in the run-shape line — a worker or token budget, not a wave count (e.g. 
    budget: ~20 workers
    ). Do not stop because a round number of waves has passed; a realistic run is often 
    12 + 3 + 1
    workers across three waves, and a decomposition cascade on a vague goal legitimately runs more. (Grounding: verification-driven replan loops that stop on completeness thresholds, diminishing returns, and token budgets — not fixed iteration caps — arXiv 2603.11445; convergence-based stopping beats a fixed 
    max_iterations
    at parity quality, arXiv 2606.27009.)
  • Scouting is cheap — don't let it eat the budget. Entropy-reduction waves (scouting, decomposition) run on cheap models and count separately from the execution budget. Never end a run "out of waves" when the caps were consumed by discovery before execution started.
  • Budget split: ~60% generation / 40% verification. Selection is the scarce resource; spend there.
  • Match width to difficulty: easy → 1 + a light refine; medium → 3–5; hard/open-ended → 5–8 for approach diversity; hardest/novel → don't loop, escalate the model.
  • Anti-poisoning handoff: carry only a distilled, verified handoff (the winner + a short critique) into the next wave — never raw transcripts or losing candidates. Long, irrelevant context measurably degrades reasoning.
Loop-until-done is justified only when ALL hold: a cheap, reliable ~ground-truth verifier exists; the signal is crisp and actionable (a failing test, not "try harder"); each iteration shows measurable progress; the work is easy–medium difficulty; and it stays hard-capped. That fits code-with-tests and exec-feedback pipelines; it misfits open-ended research/writing/design (verify in bounded waves instead).
波的设计自带限制——但限制基于完成度和预算，而非波的数量。“循环直到完成”的无限制模式会浪费令牌却收效甚微：候选生成成本低，筛选效果会停滞，额外轮次的效果不稳定——更多迭代可能降低质量，而非仅增加成本。另一种真实的失败模式是：清单仍有未完成切片时就停止。受限波保留探索能力，避免失控，且绝不放弃未完成的工作。
  • 宽度：每波N=3–8个工作代理。设置N的大小，确保你能完全验证所有N个结果。仅当存在廉价自动检查（测试、schema、执行）作为结果关口时，才增加宽度。（理论依据：同质代理团队在N≈4–8时达到性能瓶颈——新增工作代理提供的证据冗余，而多样性而非数量才是突破瓶颈的关键——arXiv 2606.02646、2602.03794。实际中，Cursor团队确认没有固定的子代理上限，但约40个并发工作代理可能导致扩展主机过载：分批处理为波。）
  • 深度：清单是停止触发条件。只要清单中仍有未完成切片且上一波带来了已验证的进展，就继续扩展。仅在以下三种情况之一时停止：完成（所有切片已完成且合成工作结束）、停滞（一波未发现新内容，输出与上一波近乎重复，或质量下降）或预算耗尽。在流程形态说明中提前声明预算——工作代理或令牌预算，而非波的数量（例如
    预算：约20个工作代理
    ）。不要因为完成了整数波就停止；实际运行通常是三波共
    12 + 3 + 1
    个工作代理，针对模糊目标的分解分层流程合理运行更多波次也是正常的。（理论依据：基于验证的重规划循环在完成阈值、收益递减和令牌预算时停止——而非固定迭代次数——arXiv 2603.11445；基于收敛的停止方式在质量相当的情况下优于固定
    max_iterations
    ——arXiv 2606.27009。）
  • 侦察成本低——不要让它耗尽预算。熵减波（侦察、分解）使用廉价模型，且与执行预算分开计算。绝不要因为发现阶段耗尽了限额就“无波可用”而结束运行。
  • 预算分配：约60%用于生成 / 40%用于验证。筛选是稀缺资源，应投入更多预算。
  • 宽度匹配难度：简单→1次+轻量优化；中等→3–5；困难/开放式→5–8以获取方法多样性；极难/新颖→不要循环，升级模型。
  • 防污染交付：仅将提炼后的已验证交付结果（最优解+简短评价）带入下一波——绝不带入原始记录或未选中的候选结果。冗长、无关的上下文会显著降低推理质量。
仅当以下所有条件满足时，“循环直到完成”才合理：存在廉价、可靠的近似基准事实验证者；信号清晰且可操作（测试失败，而非“再努力试试”）；每次迭代都有可衡量的进展；工作难度为简单–中等；且有严格上限。这适用于带测试的代码和执行反馈流水线；不适用于开放式研究/写作/设计（改用受限波验证）。

Verification

验证

The orchestrator's highest-leverage job. You can't make a worker smarter at inference time, but verifying a handoff is far cheaper than producing it, and in a multi-wave run one unchecked bad handoff compounds into the synthesis.
  • Gate before spawn — counts, coverage, partition-sums (Step 0.5).
  • Cheap checks every handoff — evidence present + resolves, scope match, contradiction skim, citations actually support the claim.
  • Self-checks in the prompt — cite-or-drop, confidence tags, "read COMPLETELY", live sources, flag-unverified. (Don't rely on freeform "double-check yourself"; give an oracle or a separate verifier.)
  • Dedicated verifier worker for high-stakes / contested / citation-heavy claims — give it the claim + sources but not the generator's reasoning nor any authorship label (judges favor output marked as their own; blind them), and have it reason against a rubric/reference before its verdict (reference-guided + CoT is the cheapest reliable judge upgrade). Never show the generator the verifier's rubric (anti-gaming). For the highest-stakes calls, a multi-model panel + synthesis checks harder still (see "Multi-model fan-out").
  • Measure & cross-check — re-run the oracle, recount from source, require ≥2 independent sources that actually entail the claim (a citation being present ≠ the claim being supported).
  • Escalate low-confidence / conflicting findings (re-task with a tighter prompt → dedicated verifier → ask the user, who may choose a stronger model) instead of folding them in.
Strongest on objective, checkable work (counts, code, facts-with-sources); on taste/judgment, verify the sub-claims, don't fake a grade. Keep claims honest: isolation reduces error propagation / path dependency, but don't claim a quantified "prevents poisoning" — there's no isolation-only ablation. Full playbook: 
references/verification.md
.
这是编排器价值最高的工作。你无法在推理时让工作代理更智能，但验证交付结果的成本远低于生成结果，在多波运行中，一个未检查的错误交付结果会在合成中不断放大。
  • 生成前关口——数量、覆盖范围、分区总和（第0.5步）。
  • 每个交付结果的低成本检查——证据存在且可访问、范围匹配、矛盾扫描、引用确实支持声明。
  • 提示中的自检规则——引用或放弃、置信度标签、“完全读取”、实时来源、标记未验证内容。（不要依赖自由形式的“自行复查”；提供预言机或独立验证者。）
  • 针对高风险/有争议/引用密集声明的专用验证工作代理——为其提供声明+来源，但不提供生成者的推理过程或任何作者标签（评判者会偏向标记为自己的输出；让他们盲评），并要求其对照规则/参考进行推理后给出验证结果（基于参考+思维链是成本最低的可靠评判升级方式）。绝不要让生成者看到验证者的规则（防止作弊）。对于最高风险的调用，多模型评审团+合成检查会更严格（参见“多模型分发”）。
  • 测量与交叉检查——重新运行预言机，从来源重新统计，要求至少2个独立来源真正支持声明（存在引用≠声明得到支持）。
  • 升级处理低置信度/矛盾/无引用的发现（使用更严格的提示重新分配任务→专用验证者→询问用户，用户可能选择更强的模型），而非纳入合成。
在客观、可检查的工作（计数、代码、有来源的事实）中效果最佳；对于品味/判断类工作，验证子声明，不要伪造评分。保持声明诚实：隔离减少错误传播/路径依赖，但不要声称量化的“防止污染”——没有仅靠隔离的对照实验。完整指南：
references/verification.md
。

Choosing 
subagent_type

选择
subagent_type

Slice is…UseNotes
Read-only code/data exploration
explore
Fast, read-only by design — and read-only mode blocks all MCP tools. Pass thoroughness: "quick" / "medium" / "very thorough".
Research needing web / MCP (Exa, Ref, docs)
generalPurpose
Multi-step; can use available web/MCP tools. Do not set 
readonly: true
(read-only blocks all MCP).
Multi-step work mixing read + light reasoning
generalPurpose
The general workhorse.
Shell/git heavy investigation
shell
Command execution specialist.
Browser testing / UI verification
browser-use
Navigates and screenshots. Stateful: auto-resumes one shared instance, so don't fan out 
browser-use
in parallel — use a single serial UI slice. Needs agent mode (not 
readonly
).
Competing attempts at the same task
best-of-n-runner
Each runs in an isolated git worktree/branch — safe from shared-checkout clobbering; you then compare attempts and merge the winner.
Naming drift across surfaces. Cursor's docs describe the built-ins as 
explore
, 
bash
, and 
browser
, while Task-tool schemas expose surface-dependent values (
generalPurpose
, 
explore
, 
shell
, 
browser-use
, 
best-of-n-runner
, review specialists…). Read the live 
subagent_type
enum off the Task tool rather than assuming this table's names — the roles are stable, the labels drift.
Custom subagents and the missing-type fallback. Custom subagents (project 
.cursor/agents/
, user 
~/.cursor/agents/
, or plugin-provided) show up as their own 
subagent_type
values — worth defining when a role repeats across runs (a verifier, a docs researcher) so its prompt, pinned 
model
, 
readonly
, and 
is_background
defaults live in one file. Two verified gotchas (staff-confirmed on the forum, not in docs): new agent files register only after a Cursor restart, and a type missing from the enum is not permission to skip the role — run it as 
generalPurpose
with the role's instructions inlined in the worker prompt (passing the intended 
model
on the call) instead. Nesting note: the platform itself now allows the main agent and its direct subagents to launch subagents (one extra level, no deeper — the SDK docs state the same cap); this skill still keeps fan-out orchestrator-only as policy, because nested fan-out hides work from the manifest and the verification gate.
切片类型…使用的子代理类型说明
只读代码/数据探索
explore
速度快，设计为只读模式——且只读模式会阻止所有MCP工具。可指定细致程度："quick" / "medium" / "very thorough"。
需要网页/MCP（Exa、Ref、文档）的研究
generalPurpose
支持多步骤；可使用可用的网页/MCP工具。请勿设置
readonly: true
（只读模式会阻止所有MCP工具）。
混合读取与轻量推理的多步骤工作
generalPurpose
通用主力子代理。
大量Shell/git操作的调查
shell
命令执行专用子代理。
浏览器测试/UI验证
browser-use
可导航并截图。有状态：自动恢复单个共享实例，因此请勿并行分发
browser-use
子代理——使用单个串行UI切片。需要代理模式（非
readonly
）。
同一任务的多轮尝试
best-of-n-runner
每轮尝试在独立的git工作树/分支中运行——避免共享 checkout 冲突；之后你可以对比尝试结果并合并最优解。
不同环境的命名差异。Cursor文档将内置子代理描述为
explore
、
bash
和
browser
，而Task工具架构暴露的是环境相关的值（
generalPurpose
、
explore
、
shell
、
browser-use
、
best-of-n-runner
、专业评审子代理…）。请从Task工具的实时
subagent_type
枚举中读取，而非假设本表格的名称——角色稳定，但标签会变化。
自定义子代理与缺失类型的 fallback。自定义子代理（项目
.cursor/agents/
、用户
~/.cursor/agents/
或插件提供的）会作为独立的
subagent_type
值出现——当某个角色在多次运行中重复时值得定义，这样其提示、固定
model
、
readonly
和
is_background
默认值可保存在一个文件中。两个已验证的问题（论坛上Cursor团队已确认，未在文档中说明）：新代理文件仅在Cursor重启后才会注册；枚举中缺失的类型不允许跳过该角色——改为使用
generalPurpose
，并在工作代理提示中内嵌该角色的指令（调用时传递指定的
model
）。嵌套说明：平台现在允许主代理及其直接子代理启动子代理（最多额外一层，不能更深——SDK文档也规定了相同限制）；本技能仍仅允许编排器进行任务分发，因为嵌套分发会使工作脱离清单和验证关口的监控。

Picking the model per slice (cost / speed routing)

为切片选择模型（成本/速度路由）

Model choice is a cost/speed lever — route it, don't put every slice on a frontier model:
  • Scouting / decomposition / read-heavy exploration → the cheap, fast model. Cursor's built-in 
    explore
    and search subagents already default to the Composer fast family (e.g. 
    composer-2.5-fast
    ) for exactly this: fast, cheap, and tuned for codebase understanding and tool use — so read waves are cheap by default and you often need not set 
    model
    at all. To pin it, pass 
    model: "composer-2.5"
    on the 
    Task
    worker, or set the 
    model
    field (
    inherit
    | a model ID) on a custom 
    .cursor/agents/
    subagent. For lightweight short-context slices on the GPT side, 
    gpt-5.6-luna
    at a higher effort is the cost-per-unit-of-work champion — but never give Luna long-context reads (its recall collapses on 256K+ contexts per OpenAI's own MRCR tables; route big-file slices to a stronger tier or chunk smaller). This is the entropy-reduction workhorse.
  • Per-model options ride in brackets on the model ID (documented syntax): 
    gpt-5.6-sol
    , 
    claude-opus-4-8[effort=high,context=300k]
    , 
    composer-2.5[fast=false]
    , 
    composer-2.5[]
    (empty brackets pin the standard, non-fast variant). Use 
    [effort=…]
    instead of guessing separate "thinking" slugs.
  • High-stakes verification, synthesis, or a multi-model panel → stronger reasoning, chosen deliberately (e.g. a frontier tier at 
    effort=high
    , escalating effort only for a slice that stays unresolved). For a user-requested or high-stakes multi-model panel, ask which models to use; don't guess slugs (see "Multi-model fan-out").
  • Otherwise honor a model the user named; if a requested model is unavailable, say so rather than silently substituting.
Caveats: availability varies (Max Mode, plan, or admin restrictions can force a fallback to a compatible model; legacy request-based plans without Max Mode run subagents on Composer regardless of 
model
configuration); slugs drift, so read them off Cursor's model picker rather than hardcoding volatile ones; 
inherit
can be unreliable in some surfaces (omit 
model
to inherit). When a custom agent's model matters, pin it in the frontmatter and pass the matching 
model
on the 
Task
call — the field has been ignored under some conditions (documented fallbacks plus confirmed bug reports), so if a worker's output quality looks off, consider that the intended model may not have run. Respect the user's cost and model preferences over any default here.
For review/audit slices, Cursor also exposes specialized subagents when available (e.g. 
bugbot
, 
security-review
, 
ci-investigator
, 
ci-watcher
) — prefer them for those slice types.
模型选择是成本/速度杠杆——按需路由，不要将所有切片都放在前沿模型上：
  • 侦察/分解/读取密集型探索→廉价快速模型。Cursor内置的
    explore
    和搜索子代理默认使用Composer快速系列（例如
    composer-2.5-fast
    ），正是因为它们速度快、成本低，且针对代码库理解和工具使用进行了调优——因此读取波默认成本低，你通常无需设置
    model
    。要固定模型，在
    Task
    工作代理中传递
    model: "composer-2.5"
    ，或在自定义
    .cursor/agents/
    子代理中设置
    model
    字段（
    inherit
    | 模型ID）。对于GPT侧的轻量短上下文切片，
    gpt-5.6-luna
    在高effort设置下是单位工作成本的最优选择——但绝不要让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=…]
    而非猜测单独的“思考”标签。
  • 高风险验证、合成或多模型评审团→故意选择更强的推理模型（例如前沿层级设置
    effort=high
    ，仅对仍未解决的切片升级effort）。对于用户请求或高风险的多模型评审团，询问使用哪些模型；不要猜测标签（参见“多模型分发”）。
  • 否则遵循用户指定的模型；如果请求的模型不可用，说明情况而非默默替换。
注意事项：可用性因环境而异（Max Mode、计划或管理员限制可能会强制 fallback 到兼容模型；无Max Mode的旧版基于请求的计划无论
model
配置如何，都会在Composer上运行子代理）；标签会变化，请从Cursor的模型选择器中读取，而非硬编码易变的标签；
inherit
在某些环境中不可靠（省略
model
以继承）。当自定义代理的模型很重要时，在前置字段中固定模型并在
Task
调用中传递匹配的
model
——该字段在某些情况下会被忽略（文档化的fallback加上已确认的bug报告），因此如果工作代理的输出质量不佳，可考虑是否运行了指定的模型。优先尊重用户的成本和模型偏好，而非此处的默认设置。
对于评审/审计切片，Cursor还会在可用时暴露专用子代理（例如
bugbot
、
security-review
、
ci-investigator
、
ci-watcher
）——对于这些切片类型优先使用它们。

Multi-model fan-out (panel + synthesize)

多模型分发（评审团+合成）

The default fan-out runs each slice on one model. A high-stakes slice — an architecture/design call, a risky correctness question, a security or audit pass, or a key research synthesis — fan the same slice out to a panel of different models, then act as judge and synthesizer.
Reconcile; don't concatenate. Label CONSENSUS (2+ models agree) vs lone-model findings, resolve contradictions, dedupe overlap, and carry each claim's confidence into one answer. The synthesis is where most of the value lives — per OpenRouter's Fusion research, roughly three-quarters of the gain comes from the synthesis step, not the model diversity — so invest there rather than stapling outputs together. Evidence: a panel of independent models + a judge + a synthesizer matched and surpassed a single top-tier model on hard, deep-research problems (OpenRouter, Surpassing Frontier Performance with Fusion, openrouter.ai/blog/announcements/fusion-beats-frontier/).
Run it in Cursor: pass a different 
model
 to each sibling 
Task
worker on the same slice, launch them in one message (parallel; backgrounded where the surface supports it), then synthesize. This is the high-stakes end of model routing — the orchestrator picks frontier models only when the user asks for a multi-model pass or the slice is explicitly high-stakes — so ask which models to use; don't guess slugs. (The cheap end — routing scouting and read-heavy waves to Composer 2.5 — is under "Picking the model per slice.")
Caveat: a panel multiplies token cost (you pay every worker) and adds latency — reserve it for high-stakes slices, not routine ones. The adversarial multi-model review (a panel of reviewer models + one synthesized verdict) is this same pattern applied to code review. For grading panels specifically, judges drawn from disjoint model families beat a single frontier judge on human agreement while cutting self-preference bias and cost (PoLL) — the family diversity, not the head count, is what does the work.
默认分发是每个切片在一个模型上运行。对于高风险切片——架构/设计决策、高风险正确性问题、安全或审计检查、关键研究合成——将同一个切片分发到不同模型组成的评审团，然后作为评判者和合成者行动。
协调结果；不要简单拼接。标记共识（2+模型一致）与单一模型发现，解决矛盾，去重重叠内容，并将每个声明的置信度带入最终答案。合成是价值所在——根据OpenRouter的Fusion研究，约四分之三的收益来自合成步骤，而非模型多样性——因此在此投入精力，而非简单拼接输出。证据：独立模型评审团+评判者+合成者在深度研究难题上的表现匹配并超越了单个顶级模型（OpenRouter，通过Fusion超越前沿性能，openrouter.ai/blog/announcements/fusion-beats-frontier/）。
在Cursor中运行：为同一切片的每个同级
Task
工作代理传递不同的
model
，在一条消息中启动它们（并行；在支持的环境中后台运行），然后合成结果。这是模型路由的高风险场景——仅当用户要求多模型处理或切片明确为高风险时，编排器才选择前沿模型——因此询问使用哪些模型；不要猜测标签。（低成本场景——将侦察和读取密集型波路由到Composer 2.5——参见“为切片选择模型”。）
注意：评审团会增加令牌成本（你要为每个工作代理付费）并增加延迟——仅保留给高风险切片，而非常规任务。对抗性多模型评审（评审模型评审团+合成验证结果）是将此模式应用于代码评审。专门用于评分的评审团中，来自不同模型家族的评判者在人类一致性上优于单个前沿评判者，同时降低自我偏好偏差和成本（PoLL）——家族多样性而非数量才是关键。

Generate-and-filter & tournaments

生成与筛选&锦标赛

For open-ended ideation or "produce the single best X", generate several candidates and filter — don't trust one attempt:
  • Cheap filter first. Gate candidates through a near-ground-truth check (tests, schema/exec, dedup/clustering) before spending judge tokens — generation is cheap, judging is not. (AlphaCode's shape: generate many → filter ~99% by tests → cluster → submit a few.)
  • Selection ladder, not all-pairs. Dedup/cluster → shortlist → pairwise-judge only among finalists. A naive O(N²) tournament spends most of its tokens comparing also-rans.
  • Use 
    best-of-n-runner
     for competing implementation attempts (each in its own git worktree), then inspect/test/merge the winner yourself.
  • For high-stakes judgment calls, the multi-model panel (above) is the generate-and-filter of verification.
  • Budget check. At equal cost, k independent attempts + a majority vote or cheap filter usually beats critique/debate loops — benchmark any iterative loop against that baseline before paying for it.
对于开放式构思或“生成最优X”，生成多个候选并筛选——不要信任单次尝试：
  • 先进行低成本筛选。在花费评判令牌前，通过近似基准事实检查（测试、schema/执行、去重/聚类）筛选候选——生成成本低，评判成本高。（AlphaCode的模式：生成大量候选→通过测试筛选约99%→聚类→提交少数候选。）
  • 筛选阶梯，而非全对比。去重/聚类→入围→仅在决赛者间进行两两评判。朴素的O(N²)锦标赛会将大部分令牌浪费在对比次要候选上。
  • 使用
    best-of-n-runner
    处理竞争性实现    尝试（每个在自己的git工作树中），然后自行检查/测试/合并最优结果。
  • 对于高风险评判决策，多模型评审团（上文）是验证的生成与筛选模式。
  • 预算检查。在成本相同的情况下，k次独立尝试+多数投票或低成本筛选通常优于评审/辩论循环——在付费前，将任何迭代循环与该基准进行对比。

Worker prompt = the contract

工作代理提示=契约

A worker cannot ask follow-up questions. Under-specified prompts drift silently. Write each as if you get one shot. Every worker prompt includes:
  1. Overall goal (context only — "don't try to own the whole goal").
  2. This worker's exact slice (the disjoint range / area / paths).
  3. Where to look (dirs, files, data ranges, which MCP/tools to use).
  4. What to return — the structured handoff from 
    references/handoff-format.md
    .
  5. Self-verify rules — cite-or-drop every claim, tag confidence (
    high|med|low
    ), and state what you could not verify. Analysis workers: "read COMPLETELY (N lines) and report the count." Research workers: "use live sources, not training data."
  6. Scope boundaries — what's explicitly OUT of scope (so it doesn't overlap a sibling worker).
  7. Return only the handoff, and keep it a digest. The worker's entire final message becomes your context — tell it to return only the structured handoff, capped at roughly 15 findings with one-line evidence each, and to write any large artifact (tables, logs, full lists) to a file and cite the path instead of pasting it inline.
  8. Edit workers: you are not alone. For implementation slices, warn the worker that siblings may be active: own only the listed paths, don't revert others' changes, and never spawn its own subagents (only the orchestrator fans out).
See 
references/handoff-format.md
for the copy-paste worker handoff template and 
references/examples.md
for a full worked run (the health-coach research job in the screenshots) plus reusable decomposition recipes.
工作代理无法提出跟进问题。提示说明不足会导致结果偏离。每个提示都要按单次尝试的标准编写。每个工作代理提示包含：
  1. 整体目标（仅上下文——“不要试图包揽整个目标”）。
  2. 该工作代理的精确切片（互不重叠的范围/领域/路径）。
  3. 查找位置（目录、文件、数据范围、使用哪些MCP/工具）。
  4. 返回内容——
    references/handoff-format.md
    中的结构化交付结果。
  5. 自检规则——每个声明都要引用来源或放弃，标记置信度（
    high|med|low
    ），并说明无法验证的内容。分析工作代理：“完全读取（N行）并报告数量。”研究工作代理：“使用实时来源，而非训练数据。”
  6. 范围边界——明确排除的内容（避免与同级工作代理重叠）。
  7. 仅返回交付结果，且保持摘要形式。工作代理的整个最终消息会成为你的上下文——告诉它仅返回结构化交付结果，限制为约15个发现，每个发现带一行证据，将大型产物（表格、日志、完整列表）写入文件并引用路径，而非粘贴到消息中。
  8. 编辑工作代理：你不是独自工作。对于实现切片，提醒工作代理可能有同级代理在活动：仅负责指定路径，不要回滚他人的更改，且绝不自行启动子代理（仅编排器可分发任务）。
可复用的工作代理交付结果模板参见
references/handoff-format.md
，完整运行示例（截图中的健康教练研究任务）及可复用分解方案参见
references/examples.md
。

Parallel writes (the local gotcha)

并行写入（本地陷阱）

Local subagents share one working directory. Concurrent writes to overlapping files clobber each other.
  • Parallel reads/research/analysis: always safe. This is the default use.
  • Disjoint edits you keep all of: use regular workers only when path sets are strictly disjoint, or do the edits serially after the research waves finish.
  • Competing attempts at the same task: use 
    best-of-n-runner
    (each in its own git worktree/branch), then inspect, test, and merge the chosen result yourself — worktrees prevent clobbering, not the merge.
本地子代理共享同一个工作目录。对重叠文件的并发写入会导致数据损坏。
  • 并行读取/研究/分析：始终安全。这是默认使用场景。
  • 互不重叠的编辑（全部保留）：仅当路径集合严格互不重叠时使用常规工作代理，或在研究波完成后串行编辑。
  • 同一任务的竞争性尝试：使用
    best-of-n-runner
    （每个在自己的git工作树/分支中），然后自行检查、测试并合并所选结果——工作树防止冲突，但不负责合并。

Waves instead of cloud orchestration

用Waves替代云编排

Waves is deliberately the replacement for cloud fan-out, not a stepping stone to it. Local subagent runs cover the whole workload this skill targets — research, audits, data analysis, exploration, and bounded implementation — with isolation, parallelism, resume, and verification, and none of the cloud setup (separate VMs, API keys, runtimes). The lessons worth keeping from the Cursor team's cloud 
orchestrate
plugin are already folded into this skill: planners plan, workers hand off up, no cross-talk, disk/git as the durable medium. Do not spawn cloud agents for a waves run; if a run truly outgrows one machine (days-long fleets, PR-per-task pipelines), that is a different tool choice for the user to make — say so and let them decide.
Cursor subagent mechanics here were checked on 2026-07-19 against current docs, changelogs, and staff forum replies: parallel Task calls in one message are the documented fan-out; 
is_background
frontmatter is the documented background switch while per-call 
run_in_background
is live but undocumented and absent on some surfaces; completed subagents persist resume checkpoints (CLI release 2026-07-06); nesting is capped at one extra level; read-only mode blocks all MCP; there is no documented concurrency cap, but staff report ~40 concurrent workers can overwhelm the extension host — batch into waves. The details most likely to drift: Task parameter names, the 
subagent_type
enum, and model-ID bracket options. Re-verify those if they matter to your run.
Waves特意设计为云分发的替代方案，而非过渡方案。本地子代理运行覆盖了本技能针对的所有工作负载——研究、审计、数据分析、探索和受限实现——具备隔离、并行、恢复和验证能力，且无需任何云设置（独立VM、API密钥、运行时）。Cursor团队云
orchestrate
插件中值得保留的经验已融入本技能：规划者负责规划，工作代理向上交付结果，无交叉通信，磁盘/git作为持久介质。不要为Waves运行生成云代理；如果运行确实超出单台机器的能力（数天的集群、每个任务对应PR的流水线），这是用户需要做出的不同工具选择——说明情况并让用户决定。
此处的Cursor子代理机制已于2026-07-19对照当前文档、更新日志和团队论坛回复进行了验证：一条消息中的并行Task调用是文档化的分发方式；
is_background
前置字段是文档化的后台开关，而每调用一次的
run_in_background
是可用但未文档化的参数，在某些环境中不存在；已完成的子代理会保留恢复检查点（CLI版本2026-07-06）；嵌套最多一层；只读模式会阻止所有MCP；没有文档化的并发上限，但团队报告约40个并发工作代理可能导致扩展主机过载——分批处理为波。最可能变化的细节：Task参数名称、
subagent_type
枚举和模型ID括号选项。如果这些对你的运行很重要，请重新验证。

Checklist

检查清单

  • Discovered the problem shape before decomposing.
  • Reduced entropy before slicing (dug locally → pulled from attached resources → asked the user only if it paid); sliced the low-entropy goal.
  • Stated the run shape in one line before spawning (on the fence → the smaller shape); never presented inline work as wave coverage.
  • Triaged each slice (worker type + dependencies + verification tier).
  • Routed scouting / read-heavy waves to the cheap fast model (Composer 2.5, or 
    gpt-5.6-luna
    for short-context slices only); reserved frontier / panel models for high-stakes slices; never gave Luna-class models long-context reads.
  • Slices are independent (disjoint data/areas/paths), or their 
    depends_on
    edges are recorded in the manifest.
  • Wrote the wave manifest (slice / worker type / model / depends_on / verification tier) before spawning; launched dependent slices only after their dependencies' handoffs were verified (distilled findings fed into their prompts).
  • Each worker prompt is fully self-contained (no reliance on chat history).
  • Each wave's 
    Task
    calls sent in one message; backgrounded where the surface supports it (
    is_background
    / 
    run_in_background
    ).
  • Ended turn to await background completions — no polling loop.
  • No two parallel workers write the same paths.
  • Verified coverage before spawning (counts/bounds/partition-sum).
  • Checked every manifest row off at collection (completion gate); ran the failure ladder on missing/blocked slices — no slice silently dropped.
  • Read every handoff; spawned follow-ups for open questions.
  • Waves bounded by the manifest + stated budget (width ≈3–8; scouting waves counted separately): continued while slices were non-terminal and progress was verified; stopped only on completion, stagnation, or budget — and named which of the three no-second-wave cases applied when skipping a follow-up.
  • Carried only distilled handoffs forward; manifest, stop conditions, and budget pinned verbatim through every synthesis/compaction.
  • Verified each handoff's evidence (not just its 
    Status
    ); escalated low-confidence / conflicting / uncited findings; wrote 
    synthesis-wave-N.md
    only from verdict-cleared findings (pending claims tagged 
    pending-verification
    , never fed to dependent slices).
  • Verified the final deliverable (re-ran/validated; re-read critical writes).
  • Synthesized one deliverable from the handoffs.
  • 分解前已探索问题结构。
  • 切片前已降低熵值（先本地探索→从附加资源获取信息→仅当值得时询问用户）；对低熵目标进行切片。
  • 生成前用一句话说明流程形态（犹豫时选择较小形态）；绝未将本地工作伪装成波处理。
  • 对每个切片进行分类（工作代理类型+依赖关系+验证层级）。
  • 将侦察/读取密集型波路由到廉价快速模型（Composer 2.5，或仅针对短上下文切片使用
    gpt-5.6-luna
    ）；将前沿/评审团模型保留给高风险切片；绝不给Luna类模型分配长上下文读取任务。
  • 切片相互独立（互不重叠的数据/领域/路径），或其
    depends_on
    关系已记录在清单中。
  • 生成前已编写波清单（切片/工作代理类型/模型/依赖项/验证层级）；仅在依赖项的交付结果已验证（提炼后的发现已纳入提示）后才启动依赖切片。
  • 每个工作代理提示完全独立（不依赖聊天历史）。
  • 每波的
    Task
    调用在一条消息中发送；在支持的环境中后台运行（
    is_background
    /
    run_in_background
    ）。
  • 结束回合等待后台完成——无轮询循环。
  • 没有两个并行工作代理写入同一路径。
  • 生成前已验证覆盖范围（数量/边界/分区总和）。
  • 收集时已核对清单中的每一行（完成关口）；对缺失/阻塞的切片执行故障处理阶梯——无切片被隐性丢失。
  • 已读取每个交付结果；为未解决问题生成后续任务。
  • 波受清单+既定预算限制（宽度≈3–8；侦察波单独计数）：切片未完成且有已验证进展时继续；仅在完成、停滞或预算耗尽时停止——且跳过后续波时说明适用的三种情况之一。
  • 仅携带提炼后的交付结果向前推进；清单、停止条件和预算逐字纳入每个合成/压缩步骤。
  • 已验证每个交付结果的证据（而非仅其
    Status
    ）；升级处理低置信度/矛盾/无引用的发现；仅从已通过验证的发现中编写
    synthesis-wave-N.md
    （待验证声明标记为
    pending-verification
    ，绝不传递给依赖切片）。
  • 已验证最终交付物（重新运行/验证；重新读取关键写入内容）。
  • 已将交付结果合成为单个交付物。",