编排模式
上下文视角：不同编排模式决定了上下文如何在多步骤、多分支间流动、分裂与汇合。
上一节解决了"喂什么"。这一节解决"怎么组织执行"。
单个任务太复杂，Agent 没法一口气吃下。它需要把任务拆成步骤，按特定方式组织这些步骤——这就是编排模式。
为什么你需要懂？因为它直接影响你怎么下指令：
- 你知道 Agent 能并行处理子任务，就会主动把需求拆成几块可以同时开工的独立部分。
- 你知道 Agent 会先做计划再执行，就能在计划阶段介入，一句话纠正后续走向，而不是等它错到底再返工。
- 你知道它会循环验证，就会给它一个明确的"完成"信号，让它退出循环。
你的理解和 agent 的实际行为对上了，你给的指令质量会完全不同。
别抢操控权
别抢方向盘。
你告诉司机去机场，就别在每个路口都去抢一下。Agent 正在改文件，你中途插一嘴让它改同一个文件的另一处？上下文和磁盘内容马上不一致，大概率冲突。
要么等它停稳（任务结束），要么直接叫停（终止任务）。别在它开车的时候当副驾。
读操作并行，写操作谨慎
人脑一次只能想一两件事。Agent 能同时处理多少，取决于编排器。
串行是一次一件事，稳，但慢。并行是一次十件事，快，但容易掉链子。
经验法则：读操作（搜索、研究）尽管并行，写操作（改代码）谨慎并行。读很少冲突，写经常会。
常见模式
Agent 的编排模式就像电路板：串联、并联、或者更复杂的组合。我们不关心底层框架怎么实现，只关心它呈现给你的行为模式。
先记住一条行业共识：简单循环优先。能用单 Agent 顺序执行搞定的，别上并行。能用一层循环解决的，别套两层。复杂编排不是"更强"，是"更多失败点"——每多一层抽象，上下文对齐的难度翻倍。
先从最简单的模式开始，真正不够用了再升级。
1. 顺序执行 (Sequential)
最简单的模式：一步接一步。
Agent 完成步骤 1，把结果放进上下文，然后基于新上下文开始步骤 2。这是最符合直觉的模式，适合依赖关系明确的任务链。
使用场景：
- 代码重构：先读文件 → 再分析依赖 → 再修改代码 → 最后运行测试。一步错，后面全停。
- 数据处理：下载数据 → 清洗数据 → 转换格式 → 加载到数据库。
上下文是单线流动的，每一轮都建立在上一轮的完整产出之上。
2. 并行分支 (Parallel)
当一个任务可以拆成多个互不依赖的子任务时，Agent 会选择并行处理。
它会同时启动多个独立的执行分支（通常通过 Sub Agent 实现），每个分支都在自己的隔离上下文中工作。所有分支完成后，结果被汇总，交回主上下文。
使用场景：
- 跨文件操作：同时修改 5 个不同文件里的同一个函数名。
- 信息收集：同时从三个不同 API 获取数据。
- 多角度分析：要求 agent 从“性能”、“安全”、“可读性”三个角度审查同一段代码。
上下文在这里分裂成多份，独立演进，最后汇合。这极大提升了效率，但也引入了上下文碎片化的风险。
这也是最自然的上下文减法。每条分支独立探索，弯路和噪声留在分支里。合并回主线时只带结论和证据，不带过程垃圾。你已经在用 Git 做同样的事——feature branch 上随便造，merge 进 main 的只有通过 review 的干净代码。Agent 的并行分支逻辑一模一样。
3. 计划-执行 (Plan-and-Execute)
面对复杂、高风险或路径不明确的任务，agent 会先生成一个行动计划，有时还会请求你批准。
── 第 1 轮：计划 ──
你给出一个模糊目标：“优化我的应用的 Docker 镜像大小”。
Agent 返回的不是代码，而是一个计划：
好的，优化 Docker 镜像大小，我计划分四步：
1. **分析当前镜像**：使用 `docker history` 和 `dive` 分析镜像层，找出最大的部分。
2. **优化基础镜像**：检查是否能从 `ubuntu` 切换到更小的 `alpine` 或 `distroless` 镜像。
3. **优化 Dockerfile**：合并 `RUN` 指令，清理缓存，使用多阶段构建。
4. **验证**：构建新镜像并运行测试，确保功能正常且体积减小。
请确认这个计划是否可行？── 第 2 轮：执行 ──
你回复“可行，但跳过第 2 步，基础镜像不能换”。
Agent 收到你的反馈，调整计划，然后才开始逐一执行工具调用。
使用场景：
- 探索性开发：“帮我用一个新技术栈搭建个原型”。
- 高风险操作：“重构数据库 schema”。
- 多步骤部署：涉及数据库迁移、服务重启、CDN 缓存刷新等复杂流程。
上下文在这里经历了“草稿”（计划）和“定稿”（经你确认后的执行）两个阶段。还记得三角关系吗？Plan-and-Execute 是 Human-in-the-loop 最自然的切入点——你在计划阶段就是审批者。
4. 迭代循环 (ReAct / Reflect)
执行 → 验证 → 修正 → 再执行。
Plan-and-Execute 在动手前纠偏，迭代循环在动手后纠偏。Agent 执行一步后，停下来看结果：符合预期吗？不符合，原因是什么？下一步怎么调？
不是一条道走到黑，而是小步快跑，随时调整。
使用场景：
- Debug：运行测试 → 看到报错 → 读取错误日志 → 猜测原因 → 修改代码 → 重新运行测试。
- API 对接：尝试发送请求 → 收到 400 错误 → 阅读 API 文档 → 修正请求体 → 再次发送。
每一轮循环的上下文都比上一轮多一条信息：上次错在哪。
并行，然后呢？
并行分支好理解，开几个独立的 Sub Agent 就行。难的是治理。
同时开三个会话改同一个项目，每个会话都有自己的上下文，互相看不见。没人协调，很容易变成一场灾难。
切干净 并行的前提是任务能切干净。每个会话负责一个独立区域——不同的文件、不同的模块。如果要改同一个文件，就别并行。按文件边界切，通常更稳妥。
用文件系统同步 三个会话各自跑了一段时间，进度如何？看文件。文件系统是天然的共享总线。每个会话的产出（新文件、修改）直接落盘。其他会话不需要“收通知”，读最新的文件状态就行。但上下文不共享。一个会话的“顿悟”需要你手动同步给其他会话。
冲突了怎么办？ 两个会话改了同一个函数，改法还不一样。Git 会告诉你冲突了，但不会告诉你谁对。收敛策略很简单：
- 谁快谁赢：谁先提交，谁的代码就是新的基线。后来者自己解决冲突。
- 你来决定：两个方案都看看，你选一个，或者你来合并。
- 别到这一步：分区切得好，冲突会少很多。
在合并后验收 所有分支都跑完了，不代表大功告成。每个分支的测试都通过了，不代表合在一起不出错。验收必须在合并后做：全量构建、全量测试。别偷懒。
并行 vs. 串行
| 场景 | 推荐 |
|---|---|
| 任务间无文件重叠 | 并行 |
| 任务间有顺序依赖 | 串行 |
| 不确定有没有依赖 | 先串行 |
| 改动范围大，不确定 | 串行 + 逐个验证 |
并行会话 + Sub Agent 处理复杂任务时，你不再一行行写代码，而是分活、盯进度、验收结果。
与 Sub Agent 的关系
Sub Agent 是实现某些编排模式（特别是并行分支）的手段，但它本身不是编排模式。
- 编排模式是更高层的组织方式（怎么组织步骤）。
- Sub Agent是更底层的执行单元（谁来干活）。
你可以用 Sub Agent 实现顺序执行（一个 Sub Agent 把结果交给下一个），也可以不用 Sub Agent 实现顺序执行（主 Agent 自己一步步来）。
想象交响乐团的指挥者：指挥不演奏任何乐器，但控制节奏、分配段落、协调声部。当你用并行会话 + Sub Agent 处理复杂任务时，你扮演的就是这个指挥者——分发任务、跟踪进度、验收结果。代码不是你写的，但整体走向由你把控。
本节小结
- 上下文流动：顺序模式是线性累积；并行模式是分裂再汇合；计划-执行模式是草稿到定稿；迭代循环是每轮带着上一轮的教训再跑一遍。
- 风险提示：并行分支可能导致结果冲突，需要设计好汇合逻辑。计划-执行阶段，agent 可能会在计划中产生幻觉，需要你仔细审查。迭代循环可能陷入死循环，需要有退出机制。
- 可审计性：所有编排模式的执行路径、分支决策、中间结果都应被记录。这让你能追溯 agent“当时是怎么想的”，并重放整个过程。
下一节看 Sub Agent——编排模式是组织方式，Sub Agent 是执行单元。当任务需要并行或隔离上下文时，主 Agent 会派生出独立的子代理来干活。