Skip to content
cccskills
FreePublished on GitHub

agent-delegation

当系统提示词需要设计多代理协作架构、子代理专业化分工、代理间上下文隔离与传递机制、任务生命周期管理时调用此 Skill。适用于 AI Agent 平台、多工具编排系统、代码审查流水线、跨应用协作场景等。不适用于:单代理系统(无委派需求)、简单工具调用(无子代理概念)、纯 API 编排(无 AI 决策)。

当需求聚焦于"单代理内的对话路由"而非"多代理间的任务分配"时,应该用 conversation-flow 而非本 Skill。

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md7.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

多代理与委派模式

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 且引入噪音
  • 跳过验证:主代理直接信任子代理输出并转发给用户,导致错误被放大
  • 门控过严:每个步骤都需要评审通过才能继续,简单任务的总耗时翻倍

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

当系统提示需要设计引用格式、信息溯源机制、来源标注系统时调用。适用于文档问答、搜索增强生成(RAG)、代码引用、浏览器辅助等需要让用户追溯信息来源的场景。不适用于纯创作类输出(如故事、诗歌),不适用于无需溯源的常识问答,也不适用于注入防御(虽然两者都涉及内容可信度)。

The English summary is being prepared. Showing the original description.

kangarooking/system-prompt-skills213Updated May 4, 2026

当系统提示面向编程代理(Coding Agent)场景时调用。适用于构建代码编辑、文件操作、Git 工作流、自动化编程助手的系统提示。不适用于代码解释或教学场景(无文件修改),不适用于 DevOps 基础设施配置(非代码层),不适用于纯对话式代码问答(无工具调用)。

The English summary is being prepared. Showing the original description.

kangarooking/system-prompt-skills213Updated May 4, 2026

当系统提示词需要设计 token 预算分配、上下文压缩策略、延迟加载机制、记忆持久化方案时调用此 Skill。适用于长对话 AI 助手、代码编辑器集成、研究型 Agent、多会话系统等需要精细管理上下文窗口的场景。不适用于:单轮交互系统(无上下文管理需求)、纯无状态 API(无对话历史)、简单的 prompt 模板设计。当需求聚焦于"如何搜索外部信息"而非"如何管理已有信息"时,应该用 search-integration 而非本 Skill。

The English summary is being prepared. Showing the original description.

kangarooking/system-prompt-skills213Updated May 4, 2026

当系统提示词需要定义 AI 如何分类用户意图、路由到不同处理流程、决定澄清策略和自主度级别时调用此 Skill。适用于多任务型 AI 助手、客服机器人、编程工具、研究助手等需要结构化对话管理的场景。不适用于:纯问答型系统(无任务执行)、单轮交互(无对话状态)、简单的 prompt 模板(无路由逻辑)。当需求仅涉及"输出什么格式"而非"如何决定输出什么"时,应该用 output-formatting 而非本 Skill。

The English summary is being prepared. Showing the original description.

kangarooking/system-prompt-skills213Updated May 4, 2026

当系统提示需要防御提示注入、越狱攻击、社会工程、内容信任边界突破等安全威胁时调用此 Skill。适用于构建 AI Agent、聊天机器人、文档处理助手等任何接受外部输入的系统提示。不适用于纯内部工具调用场景或已完全隔离的沙箱环境,也不适用于 UI 布局或响应格式设计。

The English summary is being prepared. Showing the original description.

kangarooking/system-prompt-skills213Updated May 4, 2026

当需要为 AI 设计记忆存储、检索、应用和更新机制时调用此 skill。典型场景包括:设计持久化记忆架构(用户偏好、历史上下文、项目知识)、定义记忆的创建/读取/更新/删除生命周期、实现静默记忆应用(不在回复中透露记忆内容)、管理敏感记忆边界。 不适用于:定义工具接口(tool-specification)、定义安全规则(safety-guardrails)、定义人格风格(personality-system)。 关键 trigger 信号:AI 需要跨会话记住用户信息、记忆内容可能敏感、需要在回复中隐式应用记忆而非显式引用、用户要求"记住这个"。

The English summary is being prepared. Showing the original description.

kangarooking/system-prompt-skills213Updated May 4, 2026

See all skills by kangarooking

Report a problem with this skill