orchestrator_prompt_patterns_20260417_manual

方法论库 · 引用级 · none

本页是 <code>contexts/methodology/orchestrator_prompt_patterns_20260417_manual.md</code> 的逐字投影（仅隐私清洗，零改写）。

name: Orchestrator 模式 Prompt 模式（让 Opus 协调 sub-agent 完成复杂任务）
date: 2026-04-17
author: Opus 4.7（基于本次 Level 0 + Level 1 实施 session 的真实观察）
scope: 用户写 prompt 让 Opus 以 orchestrator 模式工作的通用模板
description: orchestrator prompt 模式库
domain: infra
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null

1. 什么时候用这个模式

当任务满足以下任一条件时：

• 涉及 ≥ 5 个独立维度（多个文件 / 多种调研 / 多条并行工作线）
• 需要先调研再设计再实施（不是一步到位的简单任务）
• 有明确的"分工"自然拆分（比如 frontend / backend / 测试）
• Opus 的 context window 是瓶颈（代码和调研结果吃 token 太狠）

不适用的场景：

• 单文件小修改（直接让 Opus 做就行）
• 需要 Opus 深度理解全局才能动手（拆给 sub-agent 会丢信息）
• 强人类互动的探索（Opus 自己来回和你聊更高效）

2. 本次 session 的真实观察

本 session（2026-04-17）从 Level 0 hotfix 到 Level 1 架构重构，Opus 成功协调了 12 个 sub-agent（4 规划 + 4 执行 + 3 审计 + 1 补救），涉及 30+ 个脚本改动，E2E 41 PASS，实际耗时约 5-6 小时（如果全部由 Opus 串行做，至少 2 倍时间 + context 爆炸）。

促成这次成功的 prompt 要素，按贡献度排序：

2.1 明确触发 orchestrator 模式

你说过的触发句（精准起效）：

• 「请你 delegate 给 sub-agent 去写」
• 「你可以把任务分给不同的 agent」
• 「多调用几个 agent」
• 「你不要再耗费任何注意力了」
• 「你是 agent 不是人，两三天本来就不是一个正确的判断」

这些句子的共同点：明确把 Opus 的角色从 executor 切到 orchestrator，并把 executor 的位置让给 sub-agent。没有这些触发，Opus 默认会自己动手写代码（因为它能写，而且写得不错）。

2.2 注意力焦点锁

你说过的焦点锁句：

• 「我们当前的注意力要一直放在修复这个问题上」
• 「不要再做这个增量章节的事，注意力放在修复上」
• 「深度优于广度，宁可把一个做透」

这些句子防止 scope creep。Opus 在多线程任务里容易"顺手"做相邻事情（审查时顺手清理 ref、写 Build Log 时顺手改 zshrc），焦点锁让它不做。

2.3 明确反转

你这次给过几次关键反转：

• 「你这个也不是很全」→ 触发补扫
• 「Level 0 分类不对」→ 我 Edit 修正 open_issues
• 「Worktree 应该只做 git 层隔离」→ 整个 Level 1 架构转向
• 「你是 agent，'两三天' 不是正确判断」→ 我停止用人类时间观

反转不用客气，直接说"不，你这个不对，应该 X"最有效。

2.4 提供具体证据

你展示过：

• 终端截图「Working directory no longer exists」
• 「Not logged in · Please run /login」的真实 session 输出
• 「refs/sessions/ 里有这些」的具体 ref 列表

具体证据比描述性抱怨（"感觉有问题"）有效 10 倍。Opus 能从证据里精确定位代码层。

2.5 授予动态扩展 scope 的权力

你说过：

• 「确保绝对没有问题」→ 隐含授权 Opus 扩展 scope 做额外验证
• 「由你来操作修改这些任务」→ 明确授权 Opus 做 manual action（原本需要用户手动）

这些授权让 Opus 在发现 Level 0 原 3 条不够时主动加 Hotfix #4（cleaner lsof 守卫），而不是等你再问一轮。

3. Prompt 结构模板

3.1 完整版（复杂任务起点）

## 任务目标
[一句话，明确"要达到什么状态"。避免"改 X"这种动作描述，说"让 X 的 Y 行为变成 Z"]

## 执行模式
你作为 orchestrator，把任务拆成 N 个独立维度，每个维度派一个 Sonnet sub-agent
做具体工作。你做审查、集成、反馈。不要自己写代码/调研。

## 注意力焦点
整轮注意力只放在 [具体焦点]。遇到相邻的诱惑（看到旁边有 bug / 有优化机会），
只记录，不处理。

## 验证严肃性
- sub-agent 的自报告不能作为完成证据
- E2E 测试必须亲自实跑看真实输出
- manual action apply 后必须做端到端真实场景验证
- 发现不一致，别客气，直接反馈让 sub-agent 修

## 决策权
悬而未决的小问题（路径命名、命名空间、保留天数之类），你自己决定并记录理由。
不要每个小决策都问我。只有架构级决定或我之前表态过的原则性问题才找我。

## 时间观
你是 agent，sub-agent 并行跑很快。不要用"2-3 天"这种人类时间估算。
"要不要现在就做"的默认答案是"现在做"，除非我明说等。

## 范围
- 做：[in scope 清单]
- 不做：[out of scope 清单]
- 发现的新问题：记录到 TODO，本轮不做

## 验收标准
[可测量的断言，最好是"你自己能跑测试验证"的那种]

3.2 简化版（中等任务）

[任务]。

delegate 给 sub-agent 做，你只做审查和集成。
注意力放在 [X]，不扩。
sub-agent 产出你必须 spot check，不信自报告。
悬而未决的小问题你自己拍板。
完成前 [具体验证命令] 实跑确认。

3.3 最小版（简单协调）

[任务]。多派几个 agent 并行做。你审查结果。验证通过才算完。

4. 反模式（别这样写）

4.1 隐含的"你自己做"

❌ 「帮我修一下这个 bug」

这句话没有 orchestrator 信号。Opus 会自己动手，在复杂任务里耗尽 context。

✅ 「帮我修这个 bug。如果涉及多个文件，delegate 给 sub-agent 并行做。」

4.2 过度细节化

❌ 「先用 agent A 检查 X，然后用 agent B 检查 Y，然后 agent C 看 Z，最后你合成」

把 Opus 变成你的工作流 executor，它失去优化空间。比如它可能发现 X 和 Y 可以并行+复用调研，而不是串行。

✅ 「把这个任务拆成独立维度，每个维度派 agent。你来决定怎么拆。」

4.3 要求列所有选项让你选

❌ 「列出所有可能方案让我选」

Opus 有判断力。列 10 个方案然后等你选是在浪费它。它应该能筛掉 7 个明显不合理的，剩 2-3 个让你选。

✅ 「给出你推荐的方案 + 最多 2 个备选 + 选择理由。如果你觉得推荐方案明显优于备选，直接用不用问我。」

4.4 每步等确认

❌ 「第一步完成后告诉我，我确认后再做第二步」

在 agent 模式下，这把响应延迟从"agent 完成后通知"拉长到"agent 完成 → 汇报 → 你回复 → 继续"，有 5-10 分钟等你的时间窗。除非步骤间的决策真的需要你审，否则让 Opus 一口气做。

✅ 「一口气做完整个流程。只有遇到设计级冲突或破坏性操作才停下来问我。」

4.5 过度谨慎的修饰

❌ 「你觉得方便的话，或许可以考虑...」

Opus 会把你的犹豫当信号，变得保守。明确的指令才有明确的行动。

✅ 「做 X。」或 「不要做 X。」

4.6 把 Opus 当成 Sonnet 用

❌ 「把这个脚本改一下」（单文件简单修改，不需要协调）

Opus 的价值在协调、设计、写作。单文件修改用 Sonnet 更快。

✅ 对简单任务就说「这个直接做」，Opus 会自己判断要不要 delegate。

5. 触发词和反触发词速查

触发 orchestrator 模式

• delegate / 派 / 指派
• sub-agent / 多个 agent / 并行
• 你审查 / 你集成 / 你写作
• 注意力放在 X
• 深度优先 / 一个做透
• 一口气做完 / 闭环
• 验证严肃 / 亲自验证

可能抑制 orchestrator 模式

• 你自己试试 → Opus 会亲自动手
• 先不 delegate → 转为自做模式
• 一步步来 / 慢慢做 → 打断并行节奏
• 等我确认每一步 → 增加等待窗口
• 不要并行 → 强制串行

6. 本次 session 暴露的 orchestrator 模式弱点

即使成功了，本 session 里有几处如果 prompt 写得更好可以避免的损耗：

6.1 需要多轮才锁定真实问题

第 1-2 轮我做了"按用户初始 prompt 的三段式审查"，走到一半才被你展示的 resume 失效证据拉偏。如果你第一轮就说「我现在的主要痛点是 resume 不工作，请先定位这个再做整体审查」，能省 2 轮。

推论：初始 prompt 里包含"具体症状 + 希望优先解决的"比纯"审查一下"更高效。

6.2 Sandbox 审计原本遗漏

Level 1 完成时我以为闭环了，你这次回来问 Sandbox 才派审计 agent。如果你初始 prompt 里说「Level 1 范围要包括 Sandbox 完整性审计」，Opus 会自带。

推论：初始 prompt 里显式列"不能漏的维度"比事后补派更好。

6.3 C agent 声称产出但没落盘

原 open_issues 报告是 C agent 说产出但实际没 Write。Opus 自己没 spot check 就进了下一阶段，后来被用户的"Level 0 是不是都在里面"才发现。

推论：prompt 里应该有一条「每个 sub-agent 产出后 Opus 必须 ls + wc -l 验证文件存在」。

6.4 悬而未决问题集中度

4 个规划 agent 共产生 13 个悬而未决问题，Opus 审查时一次全决。如果 prompt 里预先说「每类问题的默认倾向」（比如 "sandbox 相关从严，性能相关从宽"），Opus 能更快判断。

推论：复杂任务的初始 prompt 可以包含「决策原则清单」让 Opus 套用。

7. 落地到 skill（已于 2026-04-18 升级）

本文档最初是笔记性质，2026-04-18 升级为 draft skill：adhoc_jobs/redundant_archive/skills_dedup_20260708/bestpractice_orchestrator_prompt_patterns.md，已在 rules/skills/INDEX.md 的 Draft 分类下建索引。升级过程和后续修订过程记录在 §9 ~ §17。

本文档保留为证据存档 + 思路演化记录（包含 5 天 JSONL 扫描细节、reframing 过程、跨厂商评审取舍理由）。draft skill 是精简的可复用版本。两者分工：

• 笔记：为什么这样做（证据 + 决策过程）
• skill：具体怎么做（规则 + 模板 + 验收）

升级时遵循了 rules/skills/bestpractice_skill_writing_guide.md 的核心原则：结果确定性优先、Enabling 而非 Prescriptive、触发词清晰、反模式 + 正模式对照。

8. 总结

本 session 的 orchestrator 模式成功有三个支柱：

1. 你明确授权 Opus 做 orchestrator（触发触发词）
2. 你在关键反转点直接给反馈（不客气、不委婉）
3. 你授权 Opus 扩展 scope 和自主决策（不每步等确认）

如果要复用这个模式，把上面的触发词、模板、反模式抄到你未来的 prompt 里。

不要把这份笔记当圣经，当灵活参考。每次 prompt 可以是模板的精简子集，关键是明确信号。

9. 五天样本的统计分析（2026-04-12 到 2026-04-17）

本节把 §1-§8 的单 session 观察扩展到 5 天范围。数据来自 65 份 JSONL（50 份主 session + 15 份 worktree session），由 5 个并行 Sonnet sub-agent 分组 jq 过滤提取，Opus 综合。补充的 retrospective 笔记：contexts/survey_sessions/delegate_mode_retrospective_5days_20260417_manual.md。

9.1 样本清点

主 session 50 份，单份大小 50KB 到 2.8MB 不等，Agent/TaskCreate 工具调用合计约 280 次。Worktree session 15 份，其中 7 份是主 session 通过 Agent 工具派出的 sub-agent session（首 prompt 结构为"你的主线：X"），2 份通过 session_wrap.sh 启动，6 份是交互式用户 session。

覆盖主题：WeClaude v2、Gate 建设、llm_task_fitness 方法论、内容提取重构、LLM Framework 跨厂商评审、Level 1 架构重构、视频/转录工具、Git 工具审查、LLM 能力边界调研。

9.2 日期分布修正

原 retrospective §1 对 04-14 和 04-15 的 Agent 调用估算与时间戳严格统计有偏差：

修正原因是原 retrospective 用 UUID 文件名归属日期估算，没有考虑 session 跨日（9e61c153 从 04-12 跨到 04-14）和只有收尾消息的 session。日期映射建议统一改用"按时间戳严格归类 Agent 调用"的口径。

9.3 触发方式分布

在有 Agent 调用的 session 里，触发来源分为三类：

• 用户显式触发（A）：约 40% 的 session，典型触发句在 §12 列出
• Opus 主动触发（B）：约 40%，HANDOFF 文档驱动或 Opus 识别任务维度后自行拆分
• 混合触发（M）：约 20%，初始用户提目标，Opus 先主动启动调研 agent，用户后期明确要求 delegate 特定任务

79e17826 的"Opus 写落地清单"场景是 A 的纯粹形态，0cf90b8a 的"读 HANDOFF 自行规划"是 B 的纯粹形态，8d1deb40 的 WeClaude v2 session（Opus 先主动，用户后明确"让 sub-agent 去执行"）是 M 的典型。

10. Sub-agent Prompt 模板（五要素版）

原笔记 §3 给出了 orchestrator 层的 prompt 模板，但没有给 sub-agent 层的可复用模板。5 天样本提炼出的模板包含五个要素，任一缺失都会显著降低产出质量：

1. 输出文件绝对路径：contexts/survey_sessions/<topic>_<date>_manual.md。不用相对路径，因为 worktree session 的 cwd 不等于主 repo 根目录（E_worktree 的 96f5735c 案例显示路径随机化风险）
2. 单一聚焦问题：一个 agent 只被问一类问题，不堆砌 5 维度要求。多维度任务靠 orchestrator 启动多个 agent 实现（04-13 session 987835f6 因单 agent 承担 5 维度触发 F4 scope creep）
3. "不做什么" 边界约束：调研 agent 写"不设计新方案"，审查 agent 写"不实施"，诊断 agent 写"不做破坏性操作"
4. 上下文文件路径列表：SOUL/USER/COMMUNICATION/WORKSPACE/git_safety 等规则文件的绝对路径。不内联大段内容，让 sub-agent 自己 Read
5. 任务类型边界（新增，来自 5 天样本）：单个 agent 的主题域 vs 邻近可能越界的领域。62a342b1 的 Topic 3 prompt 明确写 本调研不要求与 LLM 强相关。重点是人类历史和发展过程中成熟的任务分解方法论，防止 agent 把所有问题往主命题上拉

10.1 调研型 vs 审查型 delegate 的 prompt 差异

5 天样本显示这两类 delegate 的约束结构完全不同：

混用两类 prompt 结构会触发 F4 scope creep。04-13 session 987835f6 的审查 agent 被赋予了 5 个维度（已接近调研型 prompt 结构），结果产出了设计建议。71c45f39 是审查型纯形态的对照（9 个 sub-agent 全部只读不写，orchestrator 留下综合判断）。

10.2 产出验证钩子（新）

原 §2.3 说"sub-agent 的自报告不能作为完成证据"，5 天样本把这一条具体化：

硬规则：Opus 收到 sub-agent 的 status: completed 后，在进入下一步前必须执行：

ls -la $OUTPUT_FILE && wc -l $OUTPUT_FILE

文件不存在或行数异常就立即派补救 agent，不要信任自报告。C agent 虚报案例（ef765c0a → 79e17826）就是跳过这一步导致的：C agent 声称产出 git_tooling_open_issues_20260417_manual.md，但磁盘上没有。Opus 在综合阶段没有 ls，直到用户问"Level 0 是不是都在里面"才发现。

进一步的两层 spot check（79e17826 补救阶段学到）：

1. 第一层：文件存在 + 非空（ls + wc -l）
2. 第二层：结构正确（比如 Level 0/1/2 分类栏是否有原始诊断 agent 的核心发现，而不是补救 agent 自作主张的新分类）

11. 反模式扩充（基于 5 天样本）

原 §4 列出了 6 类反模式，5 天样本新增 3 类，原有的反模式 1（scope creep）扩充出一个变体。

11.1 反模式 7：补救 agent 的二次 scope creep（新）

C agent 虚报被发现后，Opus 派"补救 agent"重写产出。但补救 agent 没有原始诊断 agent（A1/A2/A3）的上下文，倾向于用自己的判断重新分类/填补空白。79e17826 session 的原话是：发现问题。open_issues 的 Level 0/1/2 分类跟我给你的方案不一致：它把 launcher pass-through（最关键的 hotfix）根本没列进 Level 0，反而把 cwd 改变和 registry race 归到 Level 1。补救 agent 自作主张重新分类了。

正模式：补救 agent 的 prompt 里必须显式列出要保留的原始结构（"Level 0/1/2 分类按我列出的框架，不要重新分类"），以及原始诊断 agent 的核心发现清单（"这些发现必须在产出里全部保留，缺一条都算失败"）。

11.2 反模式 8：Worktree Daemon idle 竞争（新，架构级）

长时间运行的 worktree session（turns > 200）被 merge_daemon 的 idle 检测误删，导致 cwd 失效、Bash/Grep/Glob 全部失效。5 天样本里 698b7ac8（533 turns，Git 实施）和 99930901（284 turns，ZAI wrapper 开发）都有这个问题，未提交工作丢失。698b7ac8 的救援 agent 报告原文：the new branch points at main, so any uncommitted/unmerged work from the prior session state is lost — only committed history is recoverable。

正模式：sub-agent prompt 里加 "开始执行前运行 pwd 确认 cwd 存在；如果 Bash 报 cwd 不存在，停止所有文件工具操作，只通过 Agent 工具向父 session 汇报状态和已完成的步骤"。同时 merge_daemon 应当排除 active session 的 worktree（这是 §3.5 的硬原则，但 idle 测试运行的 idle=0 参数绕过了保护）。

11.3 反模式 9：英文 prompt 缺少前置必读（新）

6486479b 的 sub-agent 用英文 prompt，没有注入 rules/SOUL.md 等必读文件，也没有绝对输出路径约束。产出质量被用户认定不足，后来在 62a342b1（中文 prompt + 完整约束）重做。这表明"前置必读 + 绝对路径 + 任务类型边界"是与 prompt 语言无关的硬要求，不是中文 prompt 的特殊约定。

正模式：sub-agent prompt 不论中英，都要包含：前置必读（SOUL/USER/COMMUNICATION/WORKSPACE/git_safety 按需）+ 绝对输出路径 + 任务类型边界 + "不做什么" 约束。

11.4 反模式 1 的新变体：调研型 delegate 用在审查型任务上（扩充）

原 §4.1 说"过度 delegate 导致 scope 膨胀"。5 天样本提炼出更精确的变体：把调研型（agent 有探索自由度）delegate 用在审查型（agent 必须约束在观察边界内）任务上。987835f6 的 scope creep 是这个变体的典型表现：用"调研型"的开放 prompt 去做"审查型"的对比任务，agent 产出了设计建议。

正模式：按任务性质选 prompt 结构。§10.1 的表格给出了具体差异。

12. 触发词频次表（5 天 JSONL 合计）

基于 5 个 sub-agent 统计的汇总，触发词在用户 prompt 里的出现次数：

注：注意力 一词在 ef765c0a 中出现 23 次，但大部分是 LLM bad behavior 研究主题（attention drift）的学术讨论，不是 orchestrator 层的注意力焦点锁。原笔记 §2.2 列出的焦点锁句仍然有效，只是 5 天样本里直接使用这类句式的次数少于原笔记给人的印象。

13. 新模式候选（按类别整理）

以下 N5-N22 均为原笔记和原 retrospective（§2 §8）未直接覆盖的模式，来自 5 天 JSONL 扫描。每条附 ≥ 1 个样本 UUID + 原话。

重要 reframing（2026-04-18 补注，用户反馈后修正）：本章节最初把 "身份标签"（N5）、"拟人化名称"（N6）、"动词触发词"等表达方式列为独立的"触发模式"，这是归因错误。真正让 Opus 进入 orchestrator 模式的不是某个关键词，而是用户 prompt 里隐含的任务结构（拆解清晰度 + 背景精细度）。详细反思见 §17。以下 N5-N9 改为 "任务结构传达的语言变体"，保留条目是为了说明"用户可以用多种语言包装同一个任务结构信号"，而不是"这些语言包装是独立有效的触发器"。

13.1 任务结构传达的语言变体（原"触发模式扩展"）

用户表达"这个任务应该被分派、拆解、并行执行"时，会采用以下几种语言包装。这些包装在观察上有效，但起作用的是包装下面的任务结构说明，不是包装本身。去掉包装只保留结构说明，效果通常不变。

N5 身份标签变体（ef765c0a）：你现在应该转为'调度者'的身份。这句话前面跟着 你现在面对的是一个大的 context。我觉得你现在应该... 的上下文说明。真正起作用的是"大 context + 你做协调者 + sub-agent 做执行"这三层的任务责任分配。把"调度者"换成"协调者"、"manager"或者删掉标签只留后半段，效果基本一致。

N6 拟人化名称变体（8d1deb40 / 7f3d4bcb）：请 Sabine 检查每天 9 点推送、你可以请 Submission 去检查。起作用的是"请某个 agent 完成这个具体任务"的结构，Sabine / Submission 是语言习惯，不是触发机制。

N7 渐进 delegate 升级（48411a41）：触发规模从"一个 sub-agent"升级到"多个 Sub-agent"，对应任务从单点修复升级到架构重构。起作用的是任务复杂度的实质增加，而不是"多个"这个量词。如果初始任务本身就是架构重构，一上来就会用"多个 sub-agent"。

N8 精确颗粒度指令（35c9b107）：我希望你在每一个阶段都请一个 agent。起作用的是"用户明确说出任务有 5 个阶段，每个阶段独立"这个任务结构的完整指定。"每一个阶段请一个 agent"是用户对 agent 数量的明确要求，不是一种新的触发模式。

N9 模型降级指令（79e17826）：这个任务你可以调用便宜点的模型去做。这里起作用的确实是"便宜点的模型"这个具体约束，但它触发的不是 orchestrator 模式（模式已经被触发），而是 orchestrator 模式下的模型路由决策 + 上下文注入量调整。Opus 随后把 agent 标为 Haiku 并只注入 COMMUNICATION.md。这一条是本节唯一真正独立的机制，因为"便宜"这个约束有具体的语义后果，不是任务结构的表达变体。

13.2 Orchestrator 设计策略

N10 claim 注入式调研（adcdb77e）：orchestrator 先运行 Phase 1（扫描）产出 claim 列表（含来源和可信度质疑），再把 claim 作为 agent 任务输入。原话：待验证 claim："将任务分解为微小子任务 + 投票机制 = 百万步零错误"，来源：LinkedIn 帖子，引用论文。让 agent 去验证而非去发现，方向控制更精准。

N11 meta-delegate 两步设计（1931a286）：我接下来的计划是：根据你给出的这个 prompt，让另一个 agent 去具体执行架构层中关于"更清晰的设计"这一任务。Opus 先写任务 prompt，再由 sub-agent 执行 prompt。把 prompt 设计责任明确留在 orchestrator 侧，适合 prompt 质量比 agent 执行速度重要的场景。

13.3 任务升级模式

N12 诊断触发升级（6a7e1a8b）：用户问诊断型问题（今天早上又没有收到推送，你告诉我这是为什么），AI 在诊断过程中发现未完成的 TODO（T248 /login、T250 token 预警），主动升级为 delegate 调研 + 实施的完整流程。用户未要求 delegate，升级由 AI 自主判断。

N13 用户先调研 + AI 执行分工（254f7455）：我刚才去进行了一些调研，针对当前的 TODO，我们有一些可以参考的实现。我希望你帮我完成...。用户自己调研（git_todo_reuse_analysis_20260413_manual.md）并把报告作为 context 注入主 prompt，AI 基于用户结论规划 sub-agent。这是不同于"AI 自主调研"的分工模式。

13.4 用户干预变体

N14 元反思 prompt 暴露漂移（5c95b0ee）：我怎么感觉你好像是要在一个 session 中，去把这整个东西完整地实现一下？面对这种大 context 场景下的任务执行，你有没有老实地 follow 最开始的锚点？有没有一些过度的工程化？包括是否出现被带偏、注意力漂移等情况？。不指出具体的技术错误，而是追问"角色定位"（你在做审查还是做实施？）。比直接说"不要实施"更能让 AI 自己承认漂移。

N15 任务意外中断 resume 语式（62a342b1）：好像你的任务没有完成就意外退出了。请检查一下哪些任务没有完成，请你重新开始并完成它们。不重述任务，让 AI 自查未完成项续跑。避免上下文重复，适合 agent 已有完整 context 的场景。

13.5 失败模式扩充

N16 补救 agent 二次 scope creep（79e17826）：补救型 agent 缺原始上下文，倾向用自己的判断填补空白（详见 §11.1）。

N17 Worktree daemon idle 竞争（698b7ac8 / 99930901）：长 session（turns > 200）被 merge_daemon 误删，未提交工作丢失（详见 §11.2）。

N18 三层嵌套 delegate 输出不一致（3777a941 → 6812177e → alignment agent）：主 session 派 3777a941，3777a941 派 6812177e，6812177e 再派一个调研 agent，三层 delegate 链路都正常完成，证明 worktree 不阻止进一步 delegate。但同批 7 个 sub-agent 里 96f5735c 没有把输出写到约定文件路径（而是内联在消息里），输出一致性随深度衰减。正模式：orchestrator 在启动 sub-agent 时显式约定输出路径和格式，并在 prompt 里加 "完成后输出绝对路径让父 session 验证"。

13.6 架构层模式

N19 spawn 模式 pre-delegate（4b39c454 / 66cb6eab / 5c1710a3 / cccecfbf）：WeClaude bridge 通过 spawn_do.md / spawn_think.md 模板直接启动 Claude Code 子进程。任务在到达用户交互式 Opus 之前就已经在 bridge 层完成分类（think 模式用于调研，do 模式用于实施）。这在 Opus 的可见范围之外，但实际构成了两层 delegate 结构（bridge 外层 + session 内层）。

N20 session 间上下文传递（cccecfbf / 5c1710a3）：WeClaude bridge 启动新 worker 时，把上一个 worker 的结论传递进去（cccecfbf 的 prompt 里包含 5c1710a3 的结论作为"上一次相关任务的产出"）。形成异步的、跨 session 的状态接力，不同于 Opus 同步综合 sub-agent 报告的模式。

13.7 低优先级发现

N21 上下文预热 sub-agent（71c45f39）：第一个 sub-agent 只读规则文件返回 100 字摘要，为后续 agent 预热上下文。冗余（各 agent 本身也会读），不推荐使用。列出来只为说明这个模式存在过。

N22 只读型 sub-agent 组（71c45f39）：9 个 sub-agent 全部只读不写，orchestrator 留下综合判断。印证 §10.1 "审查型 delegate 的 sub-agent 只读不写" 的结构特征。

14. 升级 skill 的判断（2026-04-18 已执行）

综合 §9-§13 的 5 天样本统计和模式提炼，判断如下：

升级为 draft skill：可行，已于 2026-04-18 执行。draft skill 路径 adhoc_jobs/redundant_archive/skills_dedup_20260708/bestpractice_orchestrator_prompt_patterns.md。后续经过 §17 的用户 reframing 反馈 + Sonnet sub-agent F 的跨 skill 重叠审查 + ZAI GLM-5.1 / Kimi K2.5 双外部模型评审，共做过三轮共 20 处修订，当前版本 206 行。原笔记 + 本次扩充的证据密度足够（65 份 JSONL、280+ Agent 调用、22 个新模式候选、3 类新反模式带正模式对照）。

升级路径：

• 新文件：adhoc_jobs/redundant_archive/skills_dedup_20260708/bestpractice_orchestrator_prompt_patterns.md
• 索引更新：rules/skills/INDEX.md 的 Draft 分类下新增一条
• 按 bestpractice_skill_writing_guide.md 的要求：结果确定性优先、enabling 而非 SOP、触发词清晰、反模式正模式对照、陷阱来自真实案例

skill 应包含的核心要素：

1. 何时进入 orchestrator 模式（原 §1 + §13.1 触发词扩展）
2. Sub-agent prompt 五要素模板（§10）
3. 调研型 vs 审查型 delegate 的 prompt 差异（§10.1）
4. Orchestrator 对 sub-agent 产出的验证钩子（§10.2）
5. 触发词速查（§12）
6. 已知陷阱（§11，特别是补救 agent creep + worktree daemon 竞争 + 英文 prompt 缺必读）

不升级到 skill 的内容：

• 原 §2（本 session 真实观察）— 保留在笔记里作为产生原委
• 原 §6（本 session 暴露的弱点）— 保留在笔记里
• §9（5 天统计）— 保留在笔记里，skill 只引用结论

对现有 skill 的补丁建议：

rules/skills/workflow_parallel_subagents.md 应该加一条硬规则："Opus 在综合 sub-agent 产出前必须 ls -la $OUTPUT_FILE && wc -l $OUTPUT_FILE 验证文件存在"。这是 5 天样本里 C agent 虚报案例的直接教训，是一条独立于并行度设计的硬要求。

位置建议：加在"整合阶段 Write existing file 必须先 Read"这条下方，单独成段。

不升级到现有 workflow_parallel_subagents skill 的内容：orchestrator 模式特有的触发词、身份标签、调研 vs 审查区分，这些属于 orchestrator prompt pattern skill 的范畴，不属于并行 subagent skill。

15. 5 天样本扫描方法（供未来复用）

本次扩充使用的扫描流程，可以在未来的"N 天 delegate 模式更新"时复用：

Step 1：清点 JSONL

find [session-path] -maxdepth 1 -name '*.jsonl' -newermt '<N days ago>' | xargs ls -la
find [session-path] -maxdepth 2 -name '*.jsonl' -newermt '<N days ago>' | xargs ls -la

Step 2：分组分派 sub-agent
按日期和大小分 4-5 组，每组给一个 Sonnet sub-agent。每个 sub-agent 携带：

• 前置必读（SOUL/COMMUNICATION + 原笔记 + retrospective 笔记）
• 分配的 JSONL 清单（带大小和日期）
• jq 过滤命令模板（不 Read 整份文件）
• 输出 schema（session 表 + 原文 quote + 触发词频次 + 新模式候选）
• 绝对输出路径

Step 3：Opus 综合

• 读 5 份产出
• 合并触发词频次（数字可能有差异，按最大/平均处理）
• 去重新模式候选
• 验证 retrospective 已有模式的统计稳定性
• 写入 §9-§13 章节

Step 4：决定 skill 升级
判断标准：

• 新模式候选 ≥ 10 个 → 考虑升级
• 反模式有正模式对照 ≥ 3 类 → 可以升级
• 至少 3 个来自不同 session 的独立样本支持同一模式 → 升级理由充分

本次扫描在 §14 已完成升级判断：可升级。

16. 参考的 5 天扫描产出（tmp）

本次扩充产生的 sub-agent 原始产出保留在 tmp/delegate_extract_20260417/ 下，包括：

• A_flagship.md：4-17 双旗舰 session（ef765c0a + 79e17826）
• B_0416.md：4-16 七份中型 session
• C_0414_0415.md：4-14 / 4-15 session（含文件日期 vs 时间戳偏差说明）
• D_0412_0413.md：4-12 / 4-13 十一份 session（含 Gate V2 模型分工、Gate E2E 冲突 LLM 仲裁原文）
• E_worktree.md：15 份 worktree session + 中断分析（3 类中断定义）

tmp/ 目录不入 git，但这些文件在分析过程中充当"证据存档"。本次 Opus 综合时引用了所有 5 份的原话和统计。如需追溯某条模式的具体证据，先查这里。

2026-04-18 补充的后续评审产出：

• tmp/delegate_extract_20260417/F_skill_overlap_analysis.md：Sonnet sub-agent F 对 8 个相关 skill 的重叠矩阵、冲突清单、过时内容候选、整合建议（364 行）
• /tmp/cc_selfinvoke/zai_skill_review_output.md：GLM-5.1 的外部独立评审（105 行，4/5 分）
• /tmp/cc_selfinvoke/kimi_skill_review_output.md：Kimi K2.5 的外部独立评审（57 行，4/5 分）
• /tmp/cc_selfinvoke/skill_review_prompt.txt：统一的评审 prompt（用于 GLM 和 Kimi 盲评）

两家外部模型评审的 convergent 发现（两家共识）：语言包装段篇幅与立意矛盾 + overlap 数字多处维护没有 SSOT。divergent 发现（各家独有）：GLM 指出反模式示例歧义 + 关键词行自相矛盾 + 验收标准和产出验证钩子命令重复；Kimi 指出 B3 去重约束过度泛化 + A2"没有依赖"表述过绝对。基于这些评审，2026-04-18 做了 6 处收尾修订，详见 §14 的"20 处修订"汇总。

17. 对"触发词"分析的 reframing（2026-04-18 补注）

17.1 反馈与归因错误

§13.1 的原版本把"身份标签触发"、"拟人化名称触发"、"渐进 delegate 升级"、"精确颗粒度触发"等表达方式列为"新模式 N5-N9"，把它们当作独立有效的触发机制。这是归因错误。用户在 2026-04-18 指出：

回到证据链：ef765c0a 里"你现在应该转为'调度者'的身份"这句话的上下文是：

让 Opus 改行为的不是"调度者"三个字，而是这段话里传达的任务责任分配：(1) observation：用户已无法审阅复杂输出；(2) context 描述：大 context 下；(3) 责任分配：Opus 做协调，sub-agent 做执行。把"调度者"换成"协调者"、"manager"或者删掉标签只留后半段，效果大概一致。

拟人化名称（"请 Sabine 检查每天 9 点推送"）同理。起作用的是"请[某个 agent]完成这个具体任务"的任务结构，Sabine 是语言习惯。

17.2 触发词是现象，任务结构是本质

从这次 reframing 得到的核心原则：

触发词本身不是因果，是用户表达任务结构的副产品。

分析 delegate 触发时，应该区分两个层次：

• 表层（关键词匹配）：用户说了"delegate"、"sub-agent"、"调度者"等词 → 触发 orchestrator 模式。这是现象关联，不是机制解释。
• 深层（任务结构传达）：用户明确说出任务可拆解、给出每个子任务的边界和背景 → Opus 识别出任务结构后进入 orchestrator 模式。这是实际机制。

触发词频次统计（§12）只能说明用户的语言习惯，不能说明触发机制。高频词不等于强触发机制，低频表达也不等于弱触发。正确的解读是：用户多样的表达方式背后，共享的是"清晰传达可拆解任务"这一结构信号。

17.3 什么才是真正起作用的

结合 5 天样本和用户反馈，真正让 Opus 可靠进入 orchestrator 模式并把 delegate 做对的，是两件事：

一是任务拆解清晰度。用户（或 Opus 自己）必须明确说出：

• 任务有几个独立维度（数量）
• 每个维度产出什么（边界）
• 维度之间是否需要串行（依赖）

79e17826 的 "P1 Worktree 无物理化 / P2 Sandbox 独立化 / P3 清理收缩 / P4 测试" 是典型：4 个维度、每个产出一份 patch plan、P1-P3 并行 P4 串行。这种结构本身就是触发。反例是 987835f6，让单个 sub-agent 评估 5 个维度，没有拆分，sub-agent 只能产出一份"什么都有但什么都浅"的报告，scope creep 直接发生。

二是任务背景精细度。sub-agent 不带 Opus 的全局 context 也要能独立完成任务。这对应 §10 的 Sub-agent Prompt 五要素中的 3 项（单一聚焦问题、上下文文件路径、任务类型边界），以及 §11.3 指出的"英文 prompt 缺前置必读"反模式。

62a342b1 的 Topic 3 prompt 本调研不要求与 LLM 强相关。重点是人类历史和发展过程中成熟的任务分解方法论 是精细背景的好例子，一句话画清了任务域边界。6486479b 的英文 prompt 没有前置必读和绝对输出路径，sub-agent 产出质量被用户认定不足，是精细度不够的反例。

17.4 对 §10 五要素的重新认识

原 §10 把五要素并列，这个并列也不够精确。重新权衡：

• 要素 1（绝对输出路径）+ 要素 2（单一聚焦问题）+ 要素 5（任务类型边界） 属于"任务拆解清晰度"
• 要素 3（不做什么约束）+ 要素 4（上下文文件路径列表） 属于"任务背景精细度"

这两组分别对应用户指出的两条原则。五要素缺一不可是因为这两条原则各自都需要落实到具体的 prompt 结构。

17.5 对 §13.1 条目的修正态度

修正后的 §13.1 把 N5-N9 列为"任务结构传达的语言变体"，保留条目是为了记录"用户可以用多种语言包装同一个任务结构信号"，不是为了说明这些包装是独立有效的触发器。N9（模型降级指令）是本节里唯一真正独立的机制，因为"便宜点的模型"有具体的语义后果（路由决策 + 上下文注入量调整），不是任务结构的表达变体。

17.6 方法学教训

这次归因错误的根因是：做模式提取时停在表面关键词，没有追问为什么这个关键词能触发。正确的做法是：

1. 观察：用户说了 X，Opus 做了 Y
2. 追问：X 里的哪一部分让 Y 发生？
3. 消融测试（mental）：去掉 X 的某部分，Y 还会发生吗？
4. 保留真正起作用的部分作为"机制"，其余作为"表达方式变体"

未来做类似分析时，§13 的条目应当先过一遍第 3 步的 mental ablation，再决定是否作为独立模式保留。