# Subagent First > AI 助手不是不够聪明，是被重活占住了：你让它整理 40 个文件，它一头扎进去十几分钟不抬头——你想问进度、想补需求、想改方向，只能干等。这套作业纪律解决的就是这件事：凡是预计要跑多轮的活（多文件/长研究/批量/长搜索），一律派给后台子代理并行执行，主代理只保留四个动作——拆解、派活、汇总、对话，永远保留随时回你话的能力。我们自己在多智能体团队里天天跑，踩过的 12 个坑全部写进正文：子代理自报成功却发现产出是空的、context 没写全导致跑偏返工、两个子代理并行写同一文件互相覆盖、把需要用户拍板的活派给问不了人的子代理、跨会话长任务错用子代理导致某天悄悄停掉……① 决策树四问判定轻重（一轮工具调用能做完吗/需要用户拍板吗/要活过本次会话吗/能拆成互不依赖的块吗）② 派活四要素（goal / context 必须自包含——子代理看不到你和用户的对话 / output_schema / 验收方式）③ 五步流程：拆解→派活→并行调度→验收→收口 ④ 验收清单：存在性/合规性/真实性/完整性四组逐项打勾，并随机抽一处回一手来源核对 ⑤ 6 种委派模式 + 12 条反模式。配套 scripts/delegation_planner.py：纯标准库零依赖，喂一份任务清单（轮数/文件数/是否研究/是否批量/是否需拍板/是否不可逆/是否跨会话），直接输出「该派子代理 / 自己做 / 转定时任务」+ 并行分组建议 + 主代理必做清单。正文按平台无关的作业纪律写，并附常见平台工具名对照表；Hermes 的字段名/并发上限/后台语义另附一页实况对齐，其他平台按对照表映射即可。触发词：子代理、委派、delegate、任务编排、多智能体、并行执行、上下文管理、主代理被占住、AI不回话、等太久、插话卡住、批量处理、长研究、fork-join、fan-out。 - Skill: `lingyu9495-source/subagent-first` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add lingyu9495-source/subagent-first` - Raw SKILL.md: https://api.skillmd.com/api/skills/lingyu9495-source/subagent-first/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: lingyu9495-source (https://skillmd.com/u/lingyu9495-source) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/lingyu9495-source/subagent-first --- # 子代理优先 · 主代理不下场 > **主代理的注意力属于用户，不属于任务。** > 凡是预计要跑很多轮的活，一律派给子代理后台去做；主代理只负责拆解、派活、验收、收口，始终保留随时响应用户的能力。 很多 agent 用得别扭，根因不是模型不够强，而是**主代理被重活占住了**：用户发一句话，主代理埋头跑二十轮工具调用，中间既不能应答、也不能改向，用户只能干等。等它终于抬头，需求可能已经变了。 本技能提供的是一套**作业纪律**——把"什么时候该派、怎么派、怎么验收"变成可判定的规则，而不是靠手感。纪律是平台无关的：任何支持子代理 / 后台任务的 AI Agent（Claude Code、Codex、Cursor、WorkBuddy、Hermes 以及其他同类工具）都适用，差别只在工具名——映射见本文档的「工具名对照表」一节。 > **落到具体平台时的实况差异**：Hermes 的字段名、并发上限、后台语义与成本口径整理在 `references/hermes-runtime-reality.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 问：这件事一轮工具调用能做完吗？ | 判断项 | 判据 | |---|---| | 工具调用次数 | 你自己数得出来，且 **≤ 1 轮** | | 是否要读多个文件 | **否**（0–1 个） | | 是否有循环 | **否**（没有"对每一个…"） | | 预计耗时 | **秒级** | **四项全部满足 → 自己做。** 任何一项不满足 → 进入第 2 问。 ### 第 2 问：这件事需要用户拍板吗？ - 需要用户在几个方案里选一个 → **自己做**（或先只做信息收集，把选项摆给用户）。 - 涉及不可逆操作（删数据、对外发布、付款、发消息给第三方）且需要即时把关 → **自己做**。 - 只是"需要用户知道"，不需要用户在过程中做决定 → 可以外派，但汇总时要交代清楚。 ### 第 3 问：这件事需要活过本次会话吗？ - 是（定时触发、持续监控、常驻服务）→ **用平台的定时 / 常驻机制**（定时任务、计划任务、后台进程），不用子代理。 - 否，本次会话内跑完就行 → 进入第 4 问。 ### 第 4 问：能拆成互不依赖的几块吗？ - 能 → **并行派多个子代理**，各自归各自的文件 / 目录 / URL / 数据集，最后主代理合并。 - 不能，但有明确先后 → **串行派**，或者单派一个子代理把整条链跑完（它也比你下场省事）。 - 拆不动、又不长 → 回到第 1 问再确认一次，多半是自己做。 ### 量化速查表 | 活的性质 | 典型耗时 | 处置 | |---|---|---| | 查一下某个值、读一个文件的某段 | 秒 | 自己做 | | 改一处文案、跑一条命令 | 秒 | 自己做 | | 读 3 个文件并汇总 | 1–2 分钟 | 可做可派；用户正在等你时派 | | 读 8 个文件、逐份摘要 | 数分钟 | **派** | | 多源检索 + 交叉比对 | 数分钟到十几分钟 | **派**（可分块并行） | | 批量处理 N 个输入（N ≥ 5） | 随 N 增长 | **派**（切片并行） | | 需要用户从方案里选 | 不定 | 自己做（收集 + 摆选项） | | 每天定时跑一次 | 跨会话 | 定时任务（不是子代理） | --- ## 五步流程 ### 第 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（写工单 + 等返回 + 回读验证）的总耗时，不划算就自己做。 --- ## 验证方法：怎么证明这次委派是对的 委派本身也该被验证。事后用这五个指标自评，答不上来的说明这次派得有问题。 | 指标 | 怎么证明 | 不达标的含义 | |---|---|---| | **主代理没被占住** | 描述一下：派活期间用户如果发消息，你能不能立刻回 | 不能 → 你其实下场了，纪律没执行 | | **产出可回读** | 给出产出路径，并当场用平台的读文件 / 执行工具回读一次 | 回读不了 → 产出不存在或路径错 | | **结论可追溯** | 抽一条关键结论，指出它的来源（文件/命令输出/URL） | 指不出来 → 结果不可信 | | **时间净收益** | 估算：自己做的耗时 vs 写工单+验收的总耗时 | 没省 → 这个规模的活下次自己做 | | **质量不掉** | 产出的完整度/准确度，与自己做时相比是否下降 | 掉了 → 工单写得不够细，补 context 再派 | **一句话自检**：如果用户问"这活是谁干的、干得怎么样、凭什么这么说"，你能否立刻给出三个明确的答案？ --- ## 工具名对照表（平台适配层） 同一套纪律，不同平台叫法不同。**下表的抽象动作是不变的，工具名按你平台映射即可。** | 抽象动作 | Hermes（已实测） | Claude Code | Cursor / Codex / WorkBuddy | 其他同类平台 | |---|---|---|---|---| | 派子代理 / 并行任务 | `delegate_task`（一个 `tasks` 数组 = 一次并行委派） | Task / 子代理工具（按你平台的子代理工具映射） | 按你平台的子代理 / 任务工具映射 | 按你平台的子代理 / 任务工具映射 | | 回读产出 | `read_file` / `search_files` | 读文件 / 检索工具（Read / Grep 一类） | 按你平台的读文件工具映射 | 按你平台的读文件工具映射 | | 执行命令做验证 | `terminal` | 命令执行工具（Bash 一类） | 按你平台的命令 / 终端工具映射 | 按你平台的命令 / 终端工具映射 | | 跨会话定时 / 常驻 | `cronjob` / 后台进程 | 系统定时任务（cron / 计划任务）+ 常驻脚本 | 同左：系统定时任务 + 常驻脚本 | 同左：系统定时任务 + 常驻脚本 | | 加载技能 | `skill_view`；技能目录 `/skills/` | 技能目录 `~/.claude/skills/` | 技能目录 `~/.cursor/skills/`、`~/.codex/skills/`、`~/.workbuddy/skills/` | 按你平台的技能 / 提示词目录 | **读表注意（诚实边界）**： - Hermes 一列是本机实测的真实工具名与语义；Claude Code 的技能目录 `~/.claude/skills/`、以及它的全局指令文件 `~/.claude/CLAUDE.md` 为实测路径。 - Cursor / Codex / WorkBuddy 一列**只列技能目录**（这三个目录是各自的通用约定位置）。它们的具体工具名各版本可能变，**本技能不编造命令或字段名**——请按你平台的"子代理 / 任务 / 读文件 / 执行命令"对应工具自行映射。 - 如果你的平台完全没有子代理能力：本纪律退化为两条——① 把重活拆成可中断的小步，每步之间让出对话；② 用平台的定时 / 常驻机制承接长任务。 **示例实现（Hermes）**：字段名（`goal` / `context` / `output_schema` / `group`）、并发上限（`delegation.max_concurrent_children`）、后台语义（派完立即返回、禁止轮询、`list` / `steer` / `stop` 现场控制）、成本口径，全部整理在 `references/hermes-runtime-reality.md`。**其他平台按上表映射即可，不需要读那一页。** --- ## 配套文件 本技能包内的其他文件（各司其职）： - `scripts/delegation_planner.py` —— 零依赖的委派规划器：读任务清单 JSON，输出该不该派、并行还是串行分组、主代理必做清单。 - `templates/派活工单.md` —— 可直接复制的工单模板，四要素留空待填。 - `templates/子代理验收清单.md` —— 逐项打勾的验收清单。 - `references/委派模式库.md` —— 6 种委派模式 + 12 条反模式的适用场景与取舍。 - `references/案例与致谢.md` —— 案例复盘与概念出处。 - `references/hermes-runtime-reality.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，按上面任意方式找我就行。 ![九品锦锂e 微信二维码](https://jinli-vault-1372591613.cos.ap-guangzhou.myqcloud.com/skillhub/hook-wechat-jiupinjinlie.png) 本 Skill 为完整版本，无功能删减。