Delegation

委派——Agent 编排与并行化

功能说明

通过六种模式并行处理工作：内置 Agent、隔离在 worktree 中的 Agent、后台 Agent、通过内联任务简报创建自定义 Agent、通过 TeamCreate 创建 Agent 团队，以及并行任务分派。委派还分为两种工作量级别——限制轮次的轻量级单次任务工作者，以及使用工具迭代工作的完整 Agent。工作达到三个或更多相互独立的工作流后，Algorithm 会自动调用此功能。

问题所在

按顺序处理相互独立的工作会浪费时间，但把每个任务都交给重量级 Agent 更浪费——为只需执行一次的分类任务启动完整 Agent，白白耗费 10-30 秒的启动时间。更糟的是，人们会混淆两种不同的系统：没有共享状态、执行即弃的自定义 Agent，以及能够互相发送消息并共享任务列表的持久化 Agent 团队。选错系统，要么会对简单工作过度协调，要么会对复杂工作协调不足。此技能会将每项工作分派给合适的模式，并选择合适的工作量级别。

工作原理

当工作可并行处理或需要 Agent 专业能力时，由 Algorithm 自动调用。

🚨 关键路由规则——两种完全不同的系统

用户说	系统	工具	执行方式
“custom agents”（自定义 Agent）、“specialized agents”（专业 Agent）、“spin up agents”（启动 Agent）、“launch agents”（启动 Agent）	内联任务简报	Task(subagent_type="general-purpose", prompt=<inline brief: name + role + stance>)	针对每个主题编写不同的角色设定
“create an agent team”（创建 Agent 团队）、“agent team”（Agent 团队）、“swarm”（集群）	Claude Code Teams	TeamCreate → TaskCreate → SendMessage	具有共享任务列表、消息协调和多轮协作的持久化团队

这两者并不相同：

• 自定义 Agent = 通过 Task() 启动、身份各异、执行一次的并行工作者，没有共享状态
• Agent 团队 = 通过 TeamCreate 建立的持久化协作团队，具有共享任务列表、消息传递和多轮协作能力

Algorithm 何时应使用此技能

• 在 Extended+ 工作量级别下，存在 3 个或更多相互独立的工作流
• 多个相同且无需串行处理的任务需要并行执行
• 需要专业能力（架构设计、实现、ISC 优化）
• 涉及 5 个或更多文件的大型代码库变更适合由并行工作者处理
• 研究与执行可以同时进行
• 用户提出“Create an agent team”（创建 Agent 团队）——使用 TeamCreate 建立持久化协作团队
• 无人值守的自主工作，且可审计性比速度更重要——Observer 团队模式（只读 Agent 监视工具活动审计日志，并投票决定继续／停止／升级处理）适用于此类场景，但目前尚未实现；该模式随 Agents 技能退役，如需使用，必须先将其重建为独立组件。

委派模式

1. 内置 Agent

⚠️ 内置 Agent 仅用于内部工作流路由。 用户要求自定义、专业或具有独特表达风格的 Agent 时，应为每个 Agent 编写一份内联任务简报（见下文第 4 节），并启动 general-purpose。

使用 Task(subagent_type="AgentType") 调用以下专业 Agent：

Agent 类型	专长	适用场景
general-purpose（+ 角色简报）	代码、架构、设计工作	在提示词中加入资深工程师／TDD 或系统设计简报——Engineer／Architect 类型已退役
Algorithm	ISC 优化、标准相关工作	专用于 ISC 的验证
Explore	快速搜索代码库	快速发现文件／模式
Plan	实施策略	执行前进行设计

**始终包含：**完整上下文、工作量预算、预期输出格式。

2. 工作树隔离的 Agent

使用 isolation: "worktree"，在各自的 git 工作树中运行 Agent，实现文件安全的并行处理：

Task(subagent_type="general-purpose", isolation: "worktree", prompt="Senior engineer, TDD. ...")

• 每个 Agent 都有自己的工作树，不会与其他 Agent 发生文件冲突
• Agent 启动时自动创建工作树，结束时自动清理（除非有更改）
• 多个 Agent 需要编辑相同文件或尝试不同方案时使用
• 可与 run_in_background: true 结合，实现非阻塞的隔离工作
• 在 frontmatter 中设置 isolation: worktree 的内置 Agent，每次启动时都会自动隔离

3. 后台 Agent

使用 run_in_background: true 运行 Agent，实现非阻塞的并行工作：

Task(subagent_type="general-purpose", run_in_background: true, prompt="Senior engineer, TDD. ...")

• 无需立即获取结果时使用
• 使用输出文件路径上的 Read 工具检查输出
• 适用于：研究、耗时较长的构建、并行调查

3b. 前台 Agent（默认模式——与模式 3 对比，并非第七种模式）

运行标准的 Task() 调用，等待其完成后再继续：

• 需要先获取结果才能继续时使用
• 用于有顺序依赖的任务
• 默认模式，也是最常用的模式

4. 自定义 Agent（内联任务说明）

触发词：“自定义 Agent”、“启动 Agent”、“启动 Agent”、“专业 Agent”
**操作：**为每个 Agent 编写不同的任务说明，包括名称、角色／专长和立场，然后使用 Task(subagent_type="general-purpose") 分别启动。没有组合工具；由编排器撰写角色设定。

Task(
  subagent_type="general-purpose",
  prompt=<agent brief: "You are a skeptical security reviewer focused on auth bypass..."> + <task + context>
)

• 为每个 Agent 提供不同的任务说明，确保它们的视角确实有所不同
• 能力强的模型可以编写比任何特征查找都更贴合主题的角色设定
• 适用于：领域专家、对抗性审查者、创意头脑风暴、并行分析

5. Agent 团队（通过 TeamCreate）

触发词：“创建 Agent 团队”、“Agent 团队”、“蜂群”、“Agent 团队”
**操作：**使用 TeamCreate 工具 → TaskCreate → 通过 Task(team_name=...) 启动队友 → 使用 SendMessage 协调

1. TeamCreate(team_name="my-project")           # Creates team + task list
2. TaskCreate(subject="Implement auth module")   # Create team tasks
3. Task(subagent_type="general-purpose", team_name="my-project", name="auth-engineer")  # Spawn teammate (senior-engineer/TDD brief in prompt)
4. TaskUpdate(taskId="1", owner="auth-engineer") # Assign task
5. SendMessage(type="message", recipient="auth-engineer", content="...")  # Coordinate

这与自定义 Agent 是完全不同的系统：

• 自定义 Agent（内联任务说明）＝即发即忘的并行工作者，没有共享状态
• Agent 团队（TeamCreate）＝持久协作的团队，拥有共享任务列表、消息传递和多轮协作

团队指南：

• 对于 Extended+ 中 3 项或以上可独立执行的标准，使用团队
• 大型复杂编码任务最能从中受益
• 每位队友通过共享任务列表独立处理分配的任务
• 由父级通过 SendMessage 协调并整合结果
• 队友在轮次间会进入空闲状态；发送消息即可唤醒他们

何时使用团队，何时使用子 Agent（决策矩阵）

因素	子 Agent（Task）	Agent 团队（TeamCreate）
沟通	即发即忘，不支持成员间消息传递	队友之间可持续传递消息
上下文	每次启动都会获得新上下文，窗口有限	每位队友都有完整上下文窗口，并在多轮间保留
协调	父级收集结果，没有共享状态	共享任务列表、成员间直接私信、空闲／唤醒循环
时长	单轮执行	多轮迭代工作，可随时调整方向
开销	低——启动后即可忽略	较高——需要组建团队、创建任务、路由消息
最适合	并行研究、一次性分析、简单委派	复杂的多文件修改、迭代调试、跨层协调

**决策规则：**如果 Agent 需要彼此沟通或迭代处理共享工作 → 使用团队。如果每个 Agent 执行的都是互不依赖的一次性工作 → 使用子 Agent。

具体示例：

• “并行研究 4 个主题” → 子 Agent（彼此独立，无需协调）
• “构建一个涉及 API、UI 和测试且需共享状态的功能” → 团队（跨层工作，需要协调）
• “按照相同模式更新 10 个文件” → 子 Agent（并行、相同且互不依赖）
• “使用不同假设调试复杂问题” → 团队（需要共享发现并调整方案）

6. 并行任务分派

对于 N 个相同的操作（例如，使用同一模式更新 10 个文件）：

1. 在一条消息中创建 N 个 Task() 调用（并行启动）
2. 每个 Agent 负责一项工作
3. 全部完成后收集结果

按工作量级别扩展

工作量	委派策略
即时/快速	不委派——仅直接使用工具
标准	对独立的子任务，最多使用 1–2 个前台 Agent
扩展	使用 2–4 个 Agent；研究任务使用后台 Agent
高级	使用 4–8 个 Agent；有 3 个以上工作流时组建 Agent 团队
深入	全面协调团队，使用并行工作者
全面	不设上限——团队 + 并行 + 后台

两级委派（轻量级与完整委派）

并非所有委派任务都需要完整的 Agent。应根据任务复杂度匹配委派力度：

轻量级委派

适用于： 一次性提取、分类、摘要，以及针对所提供内容的简单问答。

Task(subagent_type="general-purpose", max_turns=3, prompt="...")

• 模型由每次派发时决定（model 参数；未指定时继承会话模型）
• 设置 max_turns=3——如果 3 轮内无法完成，则需要完整委派
• 在提示词中内联提供所有输入（预期不使用工具）
• 示例：“将这段文本分类为 X/Y/Z”“从中提取 5 个要点”“用 2 句话总结这段内容”

完整委派

适用于： 多步骤推理、需要使用工具（读取文件、搜索、网页）的任务，以及需要自行迭代的任务。

Task(subagent_type="general-purpose", prompt="...")  # or specialized agent type

• 未指定模型时继承会话模型（由 harness 决定行为）
• 不限制 max_turns——Agent 会持续迭代直至完成
• Agent 自主使用工具（Read、Grep、Bash 等）
• 示例：“研究 X 并生成报告”“重构这 5 个文件”“调试测试 Y 失败的原因”

决策规则

请问：“这个问题能否在不使用工具的情况下，通过一次大模型调用回答？”→ 轻量级。否则 → 完整委派。

信号	层级
输入适合放入提示词，输出属于提取/分类	轻量级
需要读取文件、搜索或浏览网页	完整
需要迭代或自我纠正	完整
对所提供内容进行简单转换	轻量级
需要领域专业知识和研究	完整

重要原因： 为一次性提取启动完整 Agent，会浪费约 10–30 秒的启动开销和不必要的上下文。轻量级委派只需 2–5 秒即可返回。在一次包含 10 次以上委派的扩展级及以上算法运行中，这能节省数分钟。此设计受 RLM 的 llm_query() 与 rlm_query() 两级模式启发（Zhang/Kraska/Khattab，2025 年）。

预先把控规模（规划阶段，适用于所有层级）

层级委派下限设定了扇出规模的最低值。此关卡设定的是上限以及你必须提供的证明。任何扇出操作前都要先执行此关卡。之所以设立这道关卡，是因为过度委派是反思日志中反复出现、代价最高的浪费之一：为单文件重写组建团队；写作 Agent 报告“已完成”，却没有写入任何磁盘内容（白白耗费 11 万个令牌）；一次调度 300 个 Agent，导致没有余力验证结果。外部依据是 Cloudflare 按风险层级调度的做法——Agent 数量应与任务规模相匹配。不要为了审查一个错字修复而派出梦幻团队。

• (a) 零 Agent 检查。 如果答案已在工作记忆中，或能在 30 秒内通过 Glob+Grep+Read 找到，或任务仅涉及一个文件，那么就用 0 个 Agent——直接处理。子 Agent 并非免费；启动、加载上下文和处理结果的成本高于直接读取。
• (b) 对每个写入型 Agent 探查磁盘效果。 Agent 声称写入或编辑了文件，在你确认之前都不能信以为真：文件确实存在，而且 diff 非空（用 Read / git diff / Grep 检查所声称的更改）。“已完成”报告只是说法，不是证据。规则 1“实时探查”对委派者的约束与对主 Agent 完全相同。
• (c) 超过约 8 个 Agent 时预留预算。 扇出超过约 8 个并发 Agent 时，必须明确预留验证预算——不能把预算全花在生成结果上，却没有预算确认结果——并在 ## Decisions 中指定一个非 Agent 后备方案，以便应对这一批结果无法使用的情况。这也限制了 5 层嵌套能力：嵌套会使 Agent 数量成倍增加，因此上限针对的是整棵树，而不只是顶层。

委派关卡的输出： 📐 RIGHT-SIZE: [0-agent inline | N agents, disk-probed | N>8, verify-budget reserved + fallback named]。

Agent 简报应采用理想状态提示词

每份内联简报和工作流子 Agent 提示词都应描述理想状态，而不是操作步骤。 说明完成结果应是什么样（以可测试的结果为准）、约束条件以及可用工具——然后相信 Agent 能自行找到方法。编排 Agent 推理过程的简报（“先搜索，再提取，然后验证，最后综合”）属于违反 BPE 的脚手架：它会限制能力强的 Agent，也会随着模型进步而过时。这是系统中数量最多的提示词应用场景（运行时不断编写子 Agent 简报），所以这里尤其需要遵守这项规范。保留四类必要内容——安全关卡、已验证的易错点、工具约定、输出格式约定——并删去流程编排。优先说明覆盖范围的结果，不要硬编码扇出数量（“只有在 3 个以上独立来源一致时才信任匹配结果”，而不是“恰好启动 15 个 Agent”）。完整规范：skills/Prompting/Standards.md § Ideal-State Prompting。

反模式（请勿这样做）

• 不要委派 Grep/Glob/Read 能在 <2 秒内完成的工作
• 不要为单文件更改启动 Agent
• 少于 3 个独立工作流时，不要组建团队
• 不要在缺少完整上下文的情况下给 Agent 分派工作——它们会从头开始
• 不要将内置 Agent 名称用于自定义 Agent
• 用户要求专用或自定义 Agent 时，不要使用未经说明的内置 Agent 类型——应为每个 Agent 撰写独立的内联简报，并启动 general-purpose
• 不要将完整委派用于一次性的提取或分类任务——使用轻量级层级

注意事项

• 委派协调团队时使用 Claude Code 内置的 TeamCreate — 这与一次性自定义 Agent（在 general-purpose 上的内联说明）不同。这是两种不同的模式。
• 有 3 个或更多独立工作流时值得委派。 对于 1–2 项任务，直接处理比团队协调开销更快。
• Agent 团队共享任务列表。 使用 TaskCreate/TaskUpdate 进行协调，不要临时发送消息。
• 对于单文件任务，团队协作是大材小用。（2026 年 3 月的反思：“一个既能读代码又能写 JSX 的 Agent，比三个无法协调的专家更好”）
• 派生子 Agent 会继承主线程的完整对话，并共享其提示词缓存（Anthropic CC v2.1.133+，通过 CLAUDE_CODE_FORK_SUBAGENT=1 环境变量或 Agent frontmatter context: fork 启用）。将派生子 Agent 用于依赖细微语境的工作：设计变体、后续研究，以及任何依赖主线程已建立语境的工作。代码审查不要使用派生子 Agent — 派生的审查者会为自己的代码辩护（R Amjad：“倾向于为自己的代码辩护”）。对于需要达成一致的问题，并行运行一个派生 Agent 和一个非派生 Agent，然后查看它们的分歧之处。

示例

示例 1：并行实现

User: "build the frontend and backend in parallel"
→ Creates team via TeamCreate
→ Spawns frontend and backend agents
→ Shared task list for coordination
→ Agents work independently, merge results

示例 2：研究蜂群

User: "launch an agent team to research these 5 topics"
→ Creates team with 5 research agents
→ Each agent handles one topic independently
→ Results synthesized by team lead

执行日志

完成任何工作流后，追加一条 JSONL 记录：

echo '{"ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","skill":"Delegation","workflow":"WORKFLOW_USED","input":"8_WORD_SUMMARY","status":"ok|error","duration_s":SECONDS}' >> ~/.claude/LIFEOS/MEMORY/SKILLS/execution.jsonl

将 WORKFLOW_USED 替换为执行的工作流，将 8_WORD_SUMMARY 替换为简短的输入说明，并将 SECONDS 替换为大致的实际耗时。如果工作流失败，则记录 status: "error"。