子代理优先 · 主代理不下场

> 主代理的注意力属于用户，不属于任务。
> 凡是预计要跑很多轮的活，一律派给子代理后台去做；主代理只负责拆解、派活、验收、收口，始终保留随时响应用户的能力。

职责边界（与平台无关，先记住这六条再往下看）

工具名是外壳，纪律才是内核：不同平台把「派子代理」叫 delegate_task、Task、subagent、worker、graph node……都不影响这套分工。

很多 agent 用得别扭，根因不是模型不够强，而是主代理被重活占住了：用户发一句话，主代理埋头跑二十轮工具调用，中间既不能应答、也不能改向，用户只能干等。等它终于抬头，需求可能已经变了。

本技能提供的是一套作业纪律——把"什么时候该派、怎么派、怎么验收"变成可判定的规则，而不是靠手感。纪律是平台无关的：任何支持子代理 / 后台任务的 AI Agent（Claude Code、Codex、Cursor、WorkBuddy、Hermes 以及其他同类工具）都适用，差别只在工具名——映射见本文档的「工具名对照表」一节。

> 落到具体平台时的实况差异：Hermes 的字段名、并发上限、后台语义与成本口径整理在 references/示例实现-hermes运行实况.md（示例实现，其他平台可忽略）。正文只讲纪律，不依赖那一页。

触发条件

出现以下任一情况，就应当按本技能做事（而不是顺手自己干）：

1. 任务预计超过 2–3 轮工具调用：例如"读 8 个文件再汇总""跑一轮检索再整理"。
2. 一次要处理多个相互独立的单元：多文件、多目录、多 URL、多份数据、多个候选方案。
3. 长研究 / 长搜索：需要反复检索、抓取、比对，耗时以分钟计。
4. 批量处理：对一批输入做同样的一套操作（清洗、转换、逐条核对、逐条生成）。
5. 用户明确要求并行或要求"同时做几件事"。
6. 主代理正处在与用户的对话中间：用户可能随时追问、改需求、插新任务。
7. 子任务彼此无依赖、可以同时开工：典型如"三份文档分别校对，最后合并结论"。
8. 重活在后台跑的同时，用户还想继续聊别的（这是本技能最主要的收益场景）。

反过来的触发条件：如果一件事一轮工具调用就能做完，用户发完这句话就不再跟你说话——那自己做。硬派子代理只会更慢。判据见下一节的决策树。

核心原则

1. 主代理不下场做重活。 主代理只做四件事：拆解 → 派活 → 收口汇总 → 跟用户对话。它必须保持"随时可应答"的状态。
2. 重活必派子代理（强制）。 满足上面的触发条件就派，不许"我觉得我快我顺手做了"。判断标准是任务属性，不是主代理的自信程度。
3. 自报不等于事实。 子代理说"已完成"只是它的说法；没有经过验证的产出，一律视为未完成（详见"验收清单"）。
4. 上下文必须自包含。 子代理看不到你与用户的对话历史。你脑子里的背景，它一个字都收不到。派活工单写不全，它一定跑偏——这不是它笨，是你没给。
5. 并行有边界。 无依赖的活才并行；有先后依赖的活必须串行，或者把上游产出喂给下游。
6. 需要用户拍板的不外派。 需要用户确认、需要承担不可逆后果、需要即时把关的，留在主代理手里。
7. 跨会话长任务换机制。 需要活过本次会话的（持续监控、定时触发、常驻进程），用你平台的定时 / 常驻机制（定时任务、计划任务、常驻后台进程），不用子代理——子代理的生命周期跟一次委派绑定。
8. 失败要降级，不要编造。 子代理失败、超时、产出不合格：降级自己动手，或换路径重派。绝不允许把"没拿到的结果"写成"拿到了"。

> 这套原则对应的是工程上公开的 fork-join / fan-out-fan-in 范式：把任务分叉给多个执行单元，再汇合结果（Java 的 ForkJoinPool、以及 Dean 与 Ghemawat 在 OSDI 2004 提出的 MapReduce 都是这一思想的具体实现）。本技能不发明新概念，只把它落成 agent 场景下可执行的作业纪律。

决策树：什么算重活，什么自己做

按顺序回答下列问题，第一个答"是"的分支就是结论。

第 1 问：这件事一轮工具调用能做完吗？

四项全部满足 → 自己做。 任何一项不满足 → 进入第 2 问。

第 2 问：这件事需要用户拍板吗？

• 需要用户在几个方案里选一个 → 自己做（或先只做信息收集，把选项摆给用户）。
• 涉及不可逆操作（删数据、对外发布、付款、发消息给第三方）且需要即时把关 → 自己做。
• 只是"需要用户知道"，不需要用户在过程中做决定 → 可以外派，但汇总时要交代清楚。

第 3 问：这件事需要活过本次会话吗？

• 是（定时触发、持续监控、常驻服务）→ 用平台的定时 / 常驻机制（定时任务、计划任务、后台进程），不用子代理。
• 否，本次会话内跑完就行 → 进入第 4 问。

第 4 问：能拆成互不依赖的几块吗？

• 能 → 并行派多个子代理，各自归各自的文件 / 目录 / URL / 数据集，最后主代理合并。
• 不能，但有明确先后 → 串行派，或者单派一个子代理把整条链跑完（它也比你下场省事）。
• 拆不动、又不长 → 回到第 1 问再确认一次，多半是自己做。

量化速查表

五步流程

第 1 步：拆解

先把活切成边界清晰的单元。每个单元必须能独立回答三个问题：

• 输入是什么：具体到文件路径、目录、URL 列表、数据集名、参数。
• 产出是什么：具体到文件名、格式、路径。
• 怎么算做完：可判定的判据，不是"弄好就行"。

切分时守住两条：

• 写文件不能撞车：两个子代理绝不能写同一个文件。要么各自写各自的文件，最后主代理合并；要么串行。
• 依赖要显式：A 产出喂给 B 的，不能并行派——必须串行，或者让一个子代理把 A+B 都做掉。

> 完成判据（逐项打勾）
> - [ ] 每个单元都写清了输入（含具体路径 / 列表）
> - [ ] 每个单元都写清了产出（文件名 + 格式 + 存放位置）
> - [ ] 每个单元都有可判定的完成判据
> - [ ] 没有两个单元写同一个文件
> - [ ] 所有依赖关系已标注（哪些必须串行）

第 2 步：派活

用你平台的子代理 / 后台任务工具把每个单元派出去（Hermes 下是 delegate_task，其他平台按「工具名对照表」映射），工单按"四要素"写（见下一节）。要点：

• 一个子代理只领一件边界清楚的活，别把三件不相关的事塞进一个工单。
• 工单里把背景写全——子代理看不到你与用户的对话。
• 明确告诉它产出落到哪个路径，以及要回报什么（文件路径？行数？命令输出？）。
• 明确要求它只回报经得起验证的东西：跑了什么命令、拿到了什么输出；没做到就直说。
• 如果平台支持结构化回报 / 输出校验（例如按 JSON Schema 校验子代理的最终答复）——能给结构化就别给自由文本。

> 完成判据
> - [ ] 每个工单四要素齐全（目标 / 背景 / 产出结构 / 验收方式）
> - [ ] 每个工单都指定了产出路径
> - [ ] 每个工单都要求回报可验证的证据（命令 + 真实输出）
> - [ ] 工单里没有"你懂的""照之前那样"这类残缺指代

第 3 步：并行调度

• 能并行的并行派：彼此无依赖的单元一次性派出去，别排队等。
• 有依赖的串行：等上游验收通过，再把它的产出作为下游工单的 context。
• 并行度要有上限：同时开太多会互相抢资源、也增加你汇总时的负担。一次三到五个是常见的舒服区间；再多考虑分批（超上限的后果各平台不同，见「工具名对照表」与平台实况页）。
• 派完立刻回到用户身边：不要站在原地等子代理。这正是本纪律的目的——用户在等你的时候，你应该是可应答的。
• 不要轮询、不要干等：委派调用应当立即返回，结果由平台送回；主代理在等待期间要能接住用户的新消息。如果你的平台默认阻塞，就把委派调用放进后台 / 异步模式再派。
• 给用户留一个现场控制口：平台若支持查看在跑的子代理、给某个子代理补纠正、提前终止并保留部分成果，用它；不支持就退化为"下一批工单里带上纠正"。

> 完成判据
> - [ ] 无依赖的单元已同时派出（不是一个个排队派）
> - [ ] 有依赖的单元已按顺序串行，且下游拿到了上游产出
> - [ ] 并行度在可控范围（没有一次性铺开十几个）
> - [ ] 派完后主代理没有阻塞等待，仍可响应用户

第 4 步：验收

这是最容易被跳过、也最不能跳过的一步。 子代理的"已完成"是待验证声明，不是结论。

按顺序验证（详见"验收清单"）：

1. 产出存在吗：文件真的在吗？路径对不对？读一眼真实内容。
2. 产出合规格吗：格式、字段、行数、范围符合工单要求吗？
3. 结论有证据吗：它声称的关键数字/结论，有没有对应的命令输出或来源？
4. 原文抽查：随机抽 1–2 处，回到一手来源核对。

任何一条不过 → 按第 5 步的失败处置走。

> 完成判据
> - [ ] 每个子代理的产出都用平台的读文件 / 执行工具真实回读过（Hermes 下是 read_file / terminal）
> - [ ] 格式与字段符合工单要求
> - [ ] 关键结论有可追溯的证据
> - [ ] 至少抽查过一处原文，与子代理的说法一致
> - [ ] 失败/不合格的产出已明确标记，没有混进最终结果

第 5 步：收口

汇总给用户时，必须做到三件事：

• 标明来源：哪部分是子代理做的、哪部分是你自己做的。用户有权知道。
• 标明状态：哪些已验证、哪些未验证、哪些失败。不要用"大概""应该是"糊过去。
• 给下一步：需要用户拍板的地方明确摆出来。

失败处置（按优先级）：

1. 降级自己做——活其实不大，那就自己动手。
2. 换路径重派——把失败原因写进新工单，换个方法再来一次。
3. 拆分重派——工单太大导致跑偏，切小了再派。
4. 如实上报——跑不通就跑不通，把卡点和已排除的路径讲清楚。不允许编造结果。

> 完成判据
> - [ ] 汇总里标明了每部分的来源（子代理 / 主代理）
> - [ ] 汇总里标明了每部分的验证状态
> - [ ] 失败的活已处置（自己做 / 重派 / 如实上报），没有隐身
> - [ ] 需要用户决定的事项已单独列出
> - [ ] 没有一句未经证实却被写成事实的话

派活四要素

每个工单都必须包含这四样。缺任何一样，事故概率显著上升。

1. 目标（goal）—— 要做什么

一句话说清目标，用动词开头、结果导向。

• 好：把 3 份 CSV 合并成一份去重后的 combined.csv，保留原始列顺序
• 差：处理一下这几个文件

2. 背景（context）—— 为什么做、凭什么做（必须自包含）

这是四要素里最容易写崩的一个。 原因很简单：

> 子代理看不到你与用户的对话历史。它只知道你在工单里写了什么。你脑子里的背景——用户的偏好、之前踩过的坑、为什么不能用某个方案、数据的口径——它一个字都收不到。

所以 context 里必须显式写：

• 任务背景：这件事服务于什么目标，用户在意什么。
• 硬性约束：必须遵守的口径、格式、命名规则、禁止事项。
• 输入清单：具体的文件路径 / 目录 / URL / 数据集，不写"那几个文件"。
• 已知的坑：之前试过什么不行、哪里有陷阱、容易误解的地方。
• 环境信息：工作目录、可用的工具、依赖是否已安装。

自查方法：把工单单独发给一个完全不了解前情的同事，他能照做吗？ 能，就算自包含。

3. 产出结构（output schema）—— 产出长什么样

把产出结构写死，避免回来还要你再加工一遍。

• 文件类：路径 + 文件名 + 格式（markdown / json / csv）+ 必需的字段或章节。
• 报告类：要求回报的结构（结论 / 证据 / 来源 / 未解决项），而不是一段散文。
• 机器可读优先：能给 json 就别给自由文本——省掉你二次解析的功夫。
• 平台若支持输出校验（按 schema 校验子代理答复），打开它；平台不支持就在工单正文里把结构复述一遍，并要求"照此结构回报"。

4. 验收方式 —— 怎么证明做成了

提前告诉它你要怎么验，它就会照着做；事后才发现没证据，只能返工。

• 要求回报真实执行过的命令与输出（而不是"我检查过了"）。
• 要求产出路径可直接回读。
• 要求明确列出未完成/存疑的部分——主动交代比被你抓出来好。

四要素速查表

验收清单

对每一个子代理产出，逐项过一遍。任何一项"否"，就不算完成。

A. 存在性

• [ ] 产出文件真实存在于工单指定的路径（用平台的读文件 / 执行工具实测，不是只看文件名）
• [ ] 文件非空，内容不是占位符 / 模板残留 / 明显截断
• [ ] 如果是代码或脚本：能真的跑起来（不是"看起来对"）

B. 合规性

• [ ] 格式、字段、命名符合工单要求
• [ ] 数量对得上（要 10 条就是 10 条，不是"大概 8 条"）
• [ ] 没有越界：没改不该改的文件、没写工单之外的位置
• [ ] 并行任务之间没有互相覆盖（检查文件修改时间 / 内容完整性）

C. 真实性

• [ ] 子代理声称跑过的命令，有对应的真实输出
• [ ] 关键结论能追溯到具体来源（文件、URL、命令结果）
• [ ] 随机抽 1–2 处，回到一手来源核对，结论一致
• [ ] 没有"看起来很合理但找不到出处"的数字或论断

D. 完整性

• [ ] 工单要求的每一项都交了
• [ ] 未完成 / 存疑的部分被主动列出，而不是被藏起来
• [ ] 失败项有明确说明（错在哪、试过什么）

E. 汇总前的最后一道

• [ ] 我在给用户的答复里标明了来源与验证状态
• [ ] 我没有把子代理的"自报成功"当成"已完成"写进结论

常见陷阱

1. 为了派而派

把一轮就能做完的小活也派出去，结果主代理花了更多时间写工单、验产物，比自己做还慢。判断标准是任务属性，不是"派了显得专业"。 回到决策树第 1 问。

2. context 缺背景，子代理跑偏

最贵的错误。你脑子里有一堆前情，工单里只写了半句"按上次的口径整理一下"——子代理没有"上次"。它只能猜，猜错就是全盘返工。凡是指代（"上次""那个文件""按用户的意思"），一律展开成具体内容。

3. 子代理自报成功，未验证就交付

"已完成"三个字最危险。常见的是：文件建了但内容是空的、脚本写了但没跑过、声称"已验证"但没有输出。没有真实回读的一律视为未完成。

4. 把需要用户拍板的事丢给子代理

子代理不能替你问用户。让它去选方案、去决定口径、去做不可逆操作，等于把决策权交给一个看不到全局的执行单元。需要拍板的留在主代理手里。

5. 跨会话长任务误用子代理

子代理的生命周期跟一次委派绑定，会话结束它就没了。定时任务、持续监控、常驻服务必须用平台的定时 / 常驻机制（定时任务、计划任务、后台进程）。用错机制，任务会在某天悄悄停掉而没人发现。

6. 并行写同一文件，互相覆盖

两个子代理同时写 output.md，结果留的是谁写的全看运气。规则：一个产出文件只归一个子代理。 要合并，就让它们各写各的，主代理最后合并。

7. 工单太大，子代理中途失控

"把所有资料研究一遍然后写个报告"——这种工单会让子代理在长链路上越走越偏，最后交回一堆你不知道怎么验的东西。切小：研究归研究、写归写、验归验。

8. 有依赖的活被错当成并行

B 需要 A 的产出，却被同时派出去。结果 B 只能自己猜 A 的结果，前后口径必然打架。派活前先把依赖图画清楚。

9. 主代理派完就在原地等

本来是为了让用户随时能找到你，结果派完之后主代理阻塞等待（或反复轮询产物），用户还是干等。派完立刻回到对话状态，去做别的事或主动向用户汇报进展。

10. 失败后编造结果

最严重的一条。子代理超时了、抓不到数据了，却把"合理推测"当成"抓取结果"写进交付物。这比承认失败糟糕得多——失败是可修的，假数据会顺着流程一路传下去。必须如实上报。

11. 把需要用户拍板的活派给子代理（工具级硬约束）

多数平台上子代理问不了人——它没有向用户提问的通道（Hermes 的子代理就没有 clarify；其他平台同理，按你的平台确认）。涉及"选哪个方案 / 口径未定 / 要不要做"的活派出去，只能拿回它自己猜的答案。这类活必须留在主代理，先把选项摆给用户。（同理：很多平台上子代理也建不了定时任务、写不了长期记忆——派活前先确认它有什么权限。）

12. 忘了子代理是独立计费的

每个子代理各自消耗 token / 配额，派 N 个就是 N 份账单。省钱三招：① 工单里要求"只回报结论 + 产物路径"，中间过程别灌回主代理；② 用结构化的回报格式把回报写死；③ 后台活对单轮速度不敏感——优先走低成本的模型或通道。派之前先算：自己做的耗时 vs（写工单 + 等返回 + 回读验证）的总耗时，不划算就自己做。

验证方法：怎么证明这次委派是对的

委派本身也该被验证。事后用这五个指标自评，答不上来的说明这次派得有问题。

一句话自检：如果用户问"这活是谁干的、干得怎么样、凭什么这么说"，你能否立刻给出三个明确的答案？

工具名对照表（平台适配层）

同一套纪律，不同平台叫法不同。下表的抽象动作是不变的，工具名按你平台映射即可。

读表注意（诚实边界）：

• Hermes 一列是本机实测的真实工具名与语义；Claude Code 的技能目录 ~/.claude/skills/、以及它的全局指令文件 ~/.claude/CLAUDE.md 为实测路径。
• Cursor / Codex / WorkBuddy 一列只列技能目录（这三个目录是各自的通用约定位置）。它们的具体工具名各版本可能变，本技能不编造命令或字段名——请按你平台的"子代理 / 任务 / 读文件 / 执行命令"对应工具自行映射。
• 如果你的平台完全没有子代理能力：本纪律退化为两条——① 把重活拆成可中断的小步，每步之间让出对话；② 用平台的定时 / 常驻机制承接长任务。

跨框架概念对应（只写概念，不写未经验证的 API）

上面那张表是「同代工具」之间的工具名映射。如果你用的是多智能体编排框架（而不是一个带子代理的助手），抽象动作仍然一样，只是换成了框架自己的概念：

> 诚实边界：这一表只做概念对应——框架的 API、类名、参数在各版本都会变，本技能不写没实测过的调用代码。
> 拿它对照你手上框架的文档，把「拆解 → 派活 → 并行 → 验收」四步落到对应概念上即可；字段名以你框架当前文档为准。

示例实现（Hermes）：字段名（goal / context / output_schema / group）、并发上限（delegation.max_concurrent_children）、后台语义（派完立即返回、禁止轮询、list / steer / stop 现场控制）、成本口径，全部整理在 references/示例实现-hermes运行实况.md。其他平台按上表映射即可，不需要读那一页。

配套文件

本技能包内的其他文件（各司其职）：

• scripts/delegation_planner.py —— 零依赖的委派规划器（Python 3.8+，只用标准库）：读任务清单 JSON，输出每个任务该派子代理 / 自己做 / 转后台，附并行分组建议与主代理必做清单。

跑起来（先看内置示例，不必先写输入）：

bash python3 scripts/delegation_planner.py --demo # 用内置示例任务，覆盖全部分支 python3 scripts/delegation_planner.py --task-file tasks.json --json # 机读格式

任务清单格式（每个任务这 7 个字段必填；顶层可以是任务数组，也可以是 {"tasks": [...]}）：

json [{"name": "竞品资料检索与摘要", "est_tool_calls": 12, "files_touched": 2, "is_research": true, "is_batch": false, "needs_user_input": false, "irreversible": false, "cross_session": false}]

不用脚本也完全能照本技能做事——决策树四问就是它的判定规则；脚本只是把判定自动化、避免你临时拍脑袋。
- templates/派活工单.md —— 可直接复制的工单模板，四要素留空待填。
- templates/子代理验收清单.md —— 逐项打勾的验收清单。
- references/委派模式库.md —— 6 种委派模式 + 12 条反模式的适用场景与取舍。
- references/案例与致谢.md —— 案例复盘与概念出处。
- references/示例实现-hermes运行实况.md —— 示例实现（Hermes）：真实字段名、并发上限、后台语义、成本口径（其他平台可忽略）。
- 使用说明_README.md —— 快速上手。

参考概念

本技能引用的公开概念（仅列确有出处者）：

• fork-join / fan-out–fan-in：把任务分叉给多个执行单元、再汇合结果的通用并行范式；Java 并发库中的 ForkJoinPool（Java 7 引入，作者 Doug Lea）是其代表性实现。
• MapReduce：Jeffrey Dean 与 Sanjay Ghemawat，MapReduce: Simplified Data Processing on Large Clusters，OSDI 2004。大规模数据处理的"分批并行 + 归约汇总"经典模型。

本技能的价值不在复述这些概念，而在把它们落成 agent 日常作业里可判定的委派纪律——什么时候该派、工单怎么写、产出怎么验、失败怎么办。这部分是可执行的规则，不是概念介绍。

许可

MIT License。可自由用于个人与商业项目，保留作者署名即可。

🙋 关于作者

九品锦锂e ｜ 把踩过的坑封装成"拿来就能跑"的 skill，不写教科书。这个 skill 是我自己每天在用的版本。

微信：ly5419495（加时备注「SkillHub」，我优先通过）
公众号：初五Agent（微信搜一搜，复盘和方法都写在那儿，不加微信也能读）

我另外做的几个能直接跑的工具，都放在这个货架页（复制到浏览器打开）：
https://skillpay.alipay.com/public/jiupinjinlie

用的时候卡住了、或者有别的场景想让我封装成 skill，按上面任意方式找我就行。

本 Skill 为完整版本，无功能删减。