multi

Multi

并行子 Agent 编排的权威来源。

通过宿主 Task 工具并行运行互不依赖的子 Agent（Cursor：Subagent）。仅作为编排内核——入口技能负责定义任务方案和领域特定的综合分析。

快速参考

需求	位置
必须启动的约束	不可妥协事项
模型路由（成本 + 适配度）	references/model-routing.md
对抗式 / 分阶段辩论	references/adversarial.md
通用任务提示词	references/task-prompt.md
每位成员的输出格式	references/member-schema.md
通用综合报告	references/output-format.md
Agent 发现（机械式）	references/agent-discovery.md
研究依据（校准）	references/research-basis.md

校准某项操作或提出研究结论时，请阅读研究依据。不要习惯性加载。

不可妥协事项

当此技能适用时（用户附加了 multi、入口技能调用并行分派，或计划选择了 N ≥ 2 位成员）：

1. 启动真正的成员——按计划成员数量，每位成员使用选定的 subagent_type 和模型调用一次宿主 Task 工具，具体遵循模型分配。并行使用 read_file / grep / 其他工具不能替代成员运行。
2. 成员运行后再综合——综合关卡会合并成员输出。未先运行这些 Task 调用就撰写综合报告，属于违规，而非优化。
3. 禁止的合理化理由——不要因为你已经阅读过代码库、预期发现会重叠、想降低延迟、想节省 token，或差异属于“仅文档”“skills/agent-infra”或“单一主题”而跳过启动成员。
4. 可跳过的情况——仅在以下情况下省略并行启动：用户拒绝或要求单次处理；任务符合适用性检查，且没有入口技能已调用并行分派；宿主无法运行 Task；或计划中只有一位成员。

**模型路由：**为每位成员应用模型分配 / model-routing.md。遇到用量限制 / 额度耗尽时 → 用量限制重试。

适用性检查

在规划 N ≥ 2 之前，明确指出一个单次处理的替代方案：由一个 Agent 在连续上下文中进行更深入的主要检查，并使用更多工具完成同一任务。只有当各部分互相独立，且该替代方案无法覆盖这种独立性（真相来源不同、必须淘汰的权限不对称，或确实需要广泛覆盖）时，才启动并行成员。

适用 multi：成员互相独立，且并行工作能提升覆盖面、速度或信心——例如多来源信息收集、广泛探索、正交研究主题，或混合式信息收集。

跳过 multi：单次处理的替代方案已足够、工作流程是顺序式、成员会重复工作而不会增加信心，或用户希望获得单一权威结论。

入口技能例外：当 code-review（或其他入口技能）升级为并行分派 / 委员会，或 second-opinion 要求分阶段辩论时，适用性检查不适用。不要重新争论“一个 Agent 是否足够”。请遵循该技能的成员预算和不可妥协事项。

调度模式

• 覆盖 — 按来源、子系统、领域或制品拆分。例如：一名成员梳理数据流，另一名成员梳理调用点。
• 视角 — 针对相同材料，采取不同立场。如果提示词相同，仅模型多样化还不够。
• 对抗式 — 视角模式的特例：击杀任务、上下文不对称、收敛／发散式综合。完整方案 → adversarial.md。
  • 并行 — 一轮；成员彼此独立（升级时使用 code-review；存在争议时使用 investigate）。
  • 分阶段辩论（Goal: adversarial-staged）— 第 1 轮攻击方 → 第 2 轮辩护方，可接收协调者整理的第 1 轮简报。这是允许的顺序执行例外，适用于同轮隔离规则；不是成员间实时聊天。

硬性规则： 绝不能并行运行模型和提示词都相同的成员。当所有成员都继承 Auto 时，通过不同提示词和／或立场实现多样化——共享 Auto 是预期行为。跨模型的对抗式多样化 → adversarial.md § 模型路由叠加层（仅限指定的上级或用户请求；绝不能仅为实现多样化而提升层级）。

工作流

1. 分类

适用时，加载入口技能的方案；否则手动规划：

• 工作类型：research | explore | gather | mixed
• 事实来源：web | repo | plan
• 目标：覆盖 | 多视角 | 对抗式 | 分阶段对抗式 | 两者兼顾
• 独立性：如果同一轮中的成员需要彼此的输出，那就属于顺序执行——不要并行启动。例外： 分阶段辩论（adversarial.md § B）会在第 1 轮后启动第 2 轮，并使用协调者整理的简报。

2. 规划并启动

1. 发现 — 可能适用 council Agent 时，使用 agent-discovery.md；否则直接选择宿主内置的 subagent_type 值。
2. 调度计划 — 在启动前编写。除非适用入口技能的例外条款，否则应包含单轮对手（说明为何一个 Agent 加上更深入的一轮不足以完成任务）。

Task: [What the user asked]
Classification: [research / explore / gather / mixed]
Source of truth: [web / repo / plan]
Goal: [coverage / perspectives / adversarial / adversarial-staged / both]
Single-pass rival: [one agent + deeper pass — why insufficient, or "entry-skill carve-out"]

Parent model: [Auto | <named model>]
User model overrides: [none | member=slug, …]
Auto reachable: [inherit-auto | model=auto | no]
Host supports: [Task model enum values checked]
Billing pool: [first-party | API | mixed]
Explicit model slugs used: [none | slug + slice-fit reason + cost note]
Fast variants used: [none | slug + explicit latency reason]

Selected members:

- [subagent_type] · tier=[Fast|Standard|Premium] · model=[inherit-auto | slug] · stance=[id or n/a]: [sub-task and expected output]
- [subagent_type] · tier=[Fast|Standard|Premium] · model=[inherit-auto | slug] · stance=[id or n/a]: [sub-task and expected output]

Why these members: [brief justification]
Synthesis plan: [how outputs will be merged or adjudicated]

inherit-auto 仅是调度计划标记——它表示省略 Task/Subagent 的 model 参数。它不是模型标识符。绝不能将 inherit-auto 转换成任意明确的标识符。只有当宿主 Task 枚举明确包含 auto 时，才传入 model=auto。

3. 启动前检查 — 执行启动前模型路由检查，遇到矛盾时拒绝执行。在每位成员都确定了与计划一致的模型操作之前，不要发出 Task/Subagent 调用。
4. 启动 — 为每位成员并行发起一个 Task。按照 task-prompt.md 编写提示词。计划与工具语法： 计划中的 model=inherit-auto → 工具调用中省略 model；计划中的 model=<slug> → 仅当该 slug 在宿主枚举中时，才传入 model="<slug>"。遇到用量／额度错误时 → 用量限制重试。

成员规划默认方式：

• 研究 → 每个独立主题安排一名成员
• 探索 → 每个领域、子系统或制品类型安排一名成员
• 收集 → 每个事实来源或覆盖视角安排一名成员
• 混合 → 仅当各部分彼此独立时才合并角色

3. 综合

应用综合检查。

综合把关

前提条件： 每个计划成员至少完成一个 Task（除非适用上述有效跳过条件）。如果没有成员参与，不要编造多方报告。

成员返回后：

1. 合并一致的发现；以共同置信度中的最高等级陈述一次。
2. 保留冲突——不要抹平分歧。
3. 高风险矛盾 → 根据 model-routing.md 进行一次顺序仲裁（优先选择 Auto，否则选择最合适的更强模型），或升级给用户处理。
4. 按照 output-format.md 编写一份综合报告。

领域专属综合（评审提交、调查结论、第二意见章节）→ 使用入口技能配方。

回退矩阵

当 council Agent 不可用，或任务仅使用宿主内置功能时：

需求	首选	回退
仓库概览	explore	generalPurpose
Web 研究	docs-researcher	generalPurpose
计划结构评审	generalPurpose + 立场	如果 HOST 中有 council Agent，且 dispatch.contexts 包含 plan，则使用 council Agent

在 availability log 中记录跳过的 council Agent 和所选回退方案。

模型分配

使用当前宿主允许的 Task 工具 model 枚举值。切勿自行编造 slug。以够用且成本最低为目标——不要默认选择能力最强的模型。

完整流程 → model-routing.md：路由优先级（规范顺序）、感知父级的路由、计划与工具语法、生成前模型路由把关、失败时关闭（不要生成）、显式路由（仅限具名父级）、反快速（并行）、使用 Auto、用量限制重试。

不变量： Parent model = Auto 且用户未覆盖模型 ⇒ 每次 Task/Subagent 调用都省略 model 属性。inherit-auto 仅是分派计划哨兵值——绝不可将其转换为任意显式 slug。在 Auto 父级下，层级标签绝不用于选择 slug。

Agent 数量

范围	数量	适用情况
小型	2–3	聚焦功能，探索 + 验证
中型	4–6	多个相关领域或混合信息收集
大型	7–10	广泛探索或全面研究

成员超过 10 个时，应拆分为多次 multi 运行。

限制

• 最多 10 名成员
• 同一波次的成员独立工作；成员之间无法通信（分阶段辩论的第 2 波次可能会收到协调者整理的第 1 波次简报——adversarial.md）
• 适用于并行独立工作，不适用于顺序工作流（分阶段对抗式工作流除外）
• 对于微小任务，启动开销会造成浪费

输出格式

遵循 output-schema.md。综合运行遵循 references/output-format.md。

消费方绑定

项目配方索引和 council Agent 路径会在读取技能时作为项目专属注入上下文提供。不要直接编辑同步副本。