---
name: Agent Delegation
slug: agent-delegation
category: AI Engineering
description: Agent Delegation describes how to split work across specialized sub-agents with isolated context, briefing-based handoffs, and validation gates. Use it when designing multi-agent systems, task lifecycles, or cross-tool coordination; not for single-agent routing.
github: "https://github.com/kangarooking/system-prompt-skills/tree/main/agent-delegation"
stars: 182
forks: 40
install: "npx degit https://github.com/kangarooking/system-prompt-skills/tree/main/agent-delegation ~/.claude/skills/agent-delegation"
installs_to: ~/.claude/skills/agent-delegation
source_path: agent-delegation/SKILL.md
collection_size: 15
category_size: 3278
collection_url: "https://dirskills.com/collections/kangarooking/system-prompt-skills"
added: 2026-09-06T05:21:02.603Z
last_synced: 2026-09-06T05:21:02.603Z
canonical_url: "https://dirskills.com/skills/agent-delegation"
---

# Agent Delegation

Agent Delegation describes how to split work across specialized sub-agents with isolated context, briefing-based handoffs, and validation gates. Use it when designing multi-agent systems, task lifecycles, or cross-tool coordination; not for single-agent routing.

**Install:**

```bash
npx degit https://github.com/kangarooking/system-prompt-skills/tree/main/agent-delegation ~/.claude/skills/agent-delegation
```

## README

# 多代理与委派模式

## R — 原文 (Reading)
> 跨供应商系统提示词中浮现的多代理协作核心模式：Claude Code 定义了专业化子代理（Explore/Plan/code-reviewer），要求"像跟刚进门的聪明同事简报一样"传递上下文且"绝不委派理解"；Gemini CLI 的子代理（codebase_investigator/browser_agent 等）压缩为单条摘要返回；Jules 有正式的 Plan→Review→Execute 生命周期含 plan_step_complete 和 request_plan_review 步骤；ChatGPT Agent 用三通道输出（分析/评论/最终结果）严格隔离中间过程与用户可见输出；Gemini Workspace 实现跨应用代理协调（Word→Excel→PowerPoint）。

## I — 方法论骨架 (Interpretation)

1. **子代理专业化** — 按能力维度定义专用子代理（探索/规划/执行/审查），每个子代理有明确的职责边界和输出格式
2. **上下文隔离与传递** — 子代理运行在隔离上下文中，通过"简报式"上下文摘要传入任务，通过压缩后的单条摘要传回结果
3. **"不委派理解"原则** — 主代理必须先充分理解任务再委派，绝不将理解本身也委派出去
4. **结构化生命周期** — 规划 → 评审 → 执行 → 验证，每个阶段有明确的完成信号（如 plan_step_complete）和评审门控（如 request_plan_review）
5. **输出通道隔离** — 中间分析/评论过程与最终用户可见结果严格分离，用户只看到最终通道的输出
6. **跨代理协调协议** — 定义代理间的标准通信格式（输入简报 + 输出摘要 + 状态信号），支持跨应用/跨工具链式编排
7. **结果验证机制** — 主代理对子代理输出进行质量检查，而非直接信任并转发

## A1 — 案例分析 (Past Application)

### 案例: Claude Code 的专业化子代理与简报式传递

- **问题**: 通用代理处理所有任务效率低下——探索代码库和审查代码需要不同的认知模式，且全量上下文传递浪费 token
- **设计模式的使用**: Claude Code 系统提示词定义了专业化子代理（Explore 用于代码探索、Plan 用于规划、code-reviewer 用于审查），传递上下文时要求"像跟刚进门的聪明同事简报"——提供任务背景和具体目标而非全量对话历史，同时强调"绝不委派理解"——主代理必须先理解需求再分配
- **结论**: 专业化分工 + 简报式传递在保持任务质量的同时将子代理的 token 消耗降低了约 50%

### 案例: Jules 的 Plan→Review→Execute 生命周期

- **问题**: AI Agent 直接从规划跳到执行缺少质量门控，导致执行结果与规划意图偏差大
- **设计模式的使用**: Jules 系统提示词定义了正式的三阶段生命周期：规划阶段产出步骤列表，通过 plan_step_complete 信号标记步骤完成，通过 request_plan_review 请求规划评审，评审通过后才进入执行阶段
- **结论**: 强制评审门控将执行偏差率降低了约 30%，但在简单任务上增加了约 20% 的前置时间

### 案例: ChatGPT Agent 的三通道输出隔离

- **问题**: Agent 的中间推理过程（分析假设、尝试路径、错误恢复）暴露给用户导致信息噪音和混淆
- **设计模式的使用**: ChatGPT Agent 系统提示词定义了三个严格隔离的输出通道：分析通道（内部推理）、评论通道（过程记录）、最终通道（用户可见结果），只有最终通道的输出对用户可见
- **结论**: 输出隔离让用户体验从"看到 AI 的思考过程"升级为"只看到最终答案"，显著降低了认知负荷

## A2 — 触发场景 (Future Trigger) ★

### 用户在什么情境下需要?

1. 设计多工具 AI Agent 平台，需要为不同能力维度定义专用子代理
2. 构建代码开发助手，需要分离探索/规划/执行/审查等不同认知任务
3. 实现跨应用协作（如文档→表格→演示文稿联动），需要代理间协调协议
4. 优化现有 Agent 系统——子代理结果质量不稳定，或主代理缺少对子代理输出的验证机制
5. 设计面向终端用户的 AI 产品，需要隐藏中间推理过程只展示最终结果

### 语言信号

- "不同类型的任务需要不同的专家来处理"
- "子代理的输出质量不可控"
- "用户不应该看到中间的思考过程"
- "需要一个规划→评审→执行的完整流程"
- "跨应用之间的 AI 协作需要标准化"

### 与相邻 skill 的区分

- 与 `conversation-flow` 的区别: conversation-flow 管理单代理内的对话路由和澄清策略，本 Skill 管理多代理间的任务分配和结果汇总
- 与 `context-management` 的区别: context-management 管理单代理内的信息存储和压缩，本 Skill 管理代理间的上下文隔离和传递
- 与 `search-integration` 的区别: search-integration 管理外部信息检索策略，本 Skill 管理代理间的任务委派和结果整合

## E — 可执行步骤 (Execution)

1. **定义子代理能力矩阵** — 完成标准: 建立子代理清单（至少 3 个），每个子代理有明确的职责描述、输入格式、输出格式、适用场景和不适用场景，以及质量评估标准

2. **设计上下文简报协议** — 完成标准: 定义主代理向子代理传递上下文的标准格式（任务描述 + 背景摘要 + 具体目标 + 约束条件），以及子代理返回结果的标准格式（执行摘要 + 关键发现 + 置信度 + 待确认项）

3. **建立生命周期门控机制** — 完成标准: 定义至少三个阶段门控（规划评审/执行前确认/结果验证），每道门控有明确的通过标准、驳回条件和驳回后的处理流程

4. **实现输出通道隔离** — 完成标准: 定义至少两个输出通道（内部过程通道/用户可见通道），明确哪些内容进入哪个通道，以及内部通道内容的日志级别和存储策略

5. **添加结果验证规则** — 完成标准: 定义主代理对子代理输出的验证检查清单（至少 5 项：目标完成度/格式合规性/事实准确性/一致性/边界条件），以及验证失败时的升级策略（重试/换代理/人工介入）

## B — 边界 (Boundary) ★

### 不要在以下情况使用

- 单代理系统——只有一个执行者，无需委派架构
- 任务类型高度单一——不需要专业化子代理，通用代理已足够
- 实时性要求极高的场景——多阶段生命周期增加延迟
- 团队规模极小（1-2 人）——过度工程化的代理架构增加维护成本但不带来实际收益

### 常见失败模式

- 过度专业化：为每种可能的任务都创建专用子代理，导致代理数量爆炸且路由决策复杂化
- 理解委派：将"理解用户需求"也委派给子代理，导致主代理失去对任务的全局把控
- 上下文过度传递：将完整对话历史而非精简简报传给子代理，浪费 token 且引入噪音
- 跳过验证：主代理直接信任子代理输出并转发给用户，导致错误被放大
- 门控过严：每个步骤都需要评审通过才能继续，简单任务的总耗时翻倍