Plan → Explore → Direct：复杂任务的三阶段工作流

复杂任务需要先理解再行动。组合工作流把探索和实现分开：

1. Plan 模式 — 只读探索。映射依赖、理解架构、设计方案。
2. Explore 子代理 — 从大代码库隔离冗长的发现过程。返回摘要以保护主上下文。
3. 直接执行 — 带着完整理解实现。基于确认的计划修改文件。

每个阶段有特定角色。Plan 模式不能实现（只读）。Explore 子代理不能实现（返回摘要）。直接执行不该深度探索（浪费上下文，有过早改动风险）。

会话日志模式

一次成功的组合工作流会话：

只读探索，清晰的转换，聚焦的实现，零回滚，所有测试通过。探索建立了理解；执行精确地应用了它。

过早切换反模式

一个开发者用 Plan 模式探索了一个 agent 编排模式，然后切到直接执行。实现过程中发现了 2 个额外需要改动的服务，导致上下文溢出和会话重启。

Plan 阶段探索得不够深。在识别所有受影响组件前切到直接执行导致了组合工作流本该防止的返工。

规则：在 plan 阶段完全识别范围、依赖和方案之前不切到直接执行。如果在执行过程中发现新依赖，回到 Plan 模式——工作流是迭代的。

迭代的，不是一次性的

一次多日重构的会话日志：

• 会话 1（Plan）：读了 18 个文件，识别了 3 个服务边界
• 会话 2（Direct）：修改了 2 个服务中的 7 个文件，所有测试通过
• 会话 3（Direct）：修改了 2 个文件，服务 C 上 2 次回滚 → 切回 Plan 模式

会话 3 展示了健康的迭代：服务 C 有初始计划没揭示的依赖。回到 Plan 模式重新探索是正确反应——不是推着多回滚硬来。

即使彻底的规划也可能遗漏只在实现过程中才浮现的依赖。能回到 Plan 模式是优势，不是初始探索的失败。

每种模式何时主导

Plan 模式主导当： 架构未知、多种方案存在、依赖不清楚、或改动跨多个服务的很多文件。

直接执行主导当： 解决方案已知、范围已确定、目标文件清楚。已知的 bug 修复、熟悉代码库中明确指定的特性。

Explore 子代理主导当： 代码库大（500+ 文件）且彻底探索会耗尽主会话的上下文。

混合模式会话

一个流水线中的两个 CI 问题：一个已知的阻塞部署的拼写错误（直接执行）和一个需要基础设施研究的新 canary 部署阶段（plan 模式）。

先用直接执行立即修复紧急拼写错误。然后用 plan 模式研究 canary 阶段的基础设施。每个问题得到匹配其特征的模式。

和 Explore 子代理结合

对于 2,000 文件代码库：Plan 模式开始探索，但读几百个文件会填满上下文。把广泛发现委派给 Explore 子代理（隔离上下文），拿回架构摘要，然后切到直接执行做实现。主会话保留了 88% 的上下文给编辑。

一句话总结： Plan 模式映射什么需要改，Explore 子代理做探索但不填满上下文，直接执行实现确认后的计划——工作流是迭代的，不是一次性的。