回路 / The Loop — 提出有价值的问题，比直接获取答案更重要。
这个专题收集和整理我与 Gemini、ChatGPT、Claude 等 AI 的对话记录。每一篇对应一次完整的提问与回答过程。通过留存这些层层追问，还原日常思考的真实轨迹。
概要
这一期从两篇 Anthropic 官方博客的追问开始：
- Building Effective Agents（Erik Schluntz（埃里克·施伦茨，Anthropic 应用 AI 团队工程师） 与 Barry Zhang（张斌，Anthropic 应用 AI 团队工程师），2024-12-19）——业内公认的 Agent 架构入门经典，明确划分工作流（Workflows）与智能体（Agents），给出 5 种基础工作流模式
- A harness for every task: dynamic workflows in Claude Code（Thariq Shihipar（塔里克·希希帕，Anthropic Claude Code 团队工程师） 与 Sid Bidasaria（西德·比达萨里亚，Anthropic Claude Code 团队工程师），2026-06-02）——2026-05-28 官方公告《Introducing Dynamic Workflows》发布数日后的深度拆解，介绍 Claude Code 动态工作流的 6 种编排模式
追问路径大致是这样：先看 harness 那篇讲了什么 → 整理它列的 6 种 pattern → 再补上《Introducing Dynamic Workflows》官方发布公告里的关键落地案例（Bun 团队用 11 天把 Zig 重写成 Rust）→ 反过来问 Evaluator-Optimizer 到底归哪一类，除了它还有哪些常见的 agent workflow pattern → 再回头看《Building Effective Agents》的 5 种基础模式 → 最后做统一整理。
争到最后收敛到一个直观的分层认知：
- 5 种基础模式是 AI 应用的”静态积木”，路径确定、可预测，适合在应用层通过代码硬编码编排
- 6 种动态工作流模式是 Claude Opus 4.8 面对大规模、长周期、对抗性极强任务时，由用户触发（直接说 “create a workflow” 或使用
ultracode触发词）后，在独立于主对话的上下文里编写 JavaScript 脚本，编排数十到数百个子智能体的运行态组合方式
两者不冲突，是同一套设计思想的静态版和动态版。这一期把这两组模式各自解决什么失败模式、什么场景该用哪种，一并捋清楚。
Q: Anthropic 2024 年那篇《Building Effective Agents》为什么被称为 “Agent 工程界的经典”？它的核心区分是什么？
因为它做了一件当时市面上大部分文章都没做的事：把 “Agent” 这个模糊词切成两半。
原文明确写道，“Agent” 一词业界用法混乱，Anthropic 内部把所有变体统称 agentic systems，但架构上严格区分：
- Workflows are systems where LLMs and tools are orchestrated through predefined code paths.
- Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.
翻译过来：
- 工作流（Workflows）：LLM 和工具被预定义的代码路径编排。LLM 是流水线上的执行者。
- 智能体（Agents）：LLM 自主决定下一步做什么、调什么工具，掌控整个执行过程。
区分之所以重要，是因为它直接决定了工程决策——工作流用于确定性任务（拆得清、能预测），Agent 用于开放式任务（步数不定、需要 ground truth 反馈）。
Anthropic 在同一篇里给了一条硬核建议：先用最简单的方案（一次 LLM 调用 + retrieval + few-shot），只有在真的证明简单方案不够用时才升级复杂度。原文原话：
When more complexity is warranted, workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale.
这条 “从简开始” 的原则，后来被 Claude Code 团队在动态工作流那篇里再一次强调（“most traditional coding tasks do not need a panel of 5 reviewers”）。
Q: 那 5 种基础工作流模式（Workflow Patterns）具体是哪 5 种？
按《Building Effective Agents》原文的顺序：
1. Prompt Chaining（提示词链）
把复杂任务线性拆分为多个顺序步骤，上一步的输出作为下一步的输入。中间可以插入编程式检查（原文叫 “gate”）来确保没跑偏。
适用场景：任务能干净拆成固定子任务，且愿意用延迟换准确率。原文举例：先写营销文案，再翻译成另一种语言；先写文档大纲，检查大纲达标后再基于大纲写正文。
2. Routing（路由）
前置一个分类器（可以是 LLM，也可以是传统分类模型），根据输入类型分流到下游专门的提示词或工具链路。
适用场景：任务有明确不同的类别，分开处理效果更好——混合类型客服工单（一般问题、退款、技术支持走不同流程），或者按难度路由到不同模型（简单问题给 Haiku 4.5，复杂问题给 Sonnet 4.5，节省成本）。
3. Parallelization（并行化）
多个 LLM 并发处理，最后聚合。有两种变体：
- Sectioning（分块）：把任务拆成独立子任务同时跑。原文举例：一个模型处理用户请求，另一个模型并行做内容审核（护栏效果比一个模型两件事都干要好）；或者评估 LLM 表现时，每个评估维度独立跑一次。
- Voting（投票）：同一个任务跑多次或用不同提示词，靠投票或阈值筛出稳定结果。原文举例：多个提示词同时审代码漏洞，任一发现就标记；多个提示词同时判定内容合规性，用不同阈值平衡漏报和误报。
4. Orchestrator-Workers（编排者-工作者）
一个中央 LLM 动态拆解任务、分给多个 worker LLM 并行执行，再由编排者收集合成结果。
和 Parallelization 的关键区别：Parallelization 的子任务是预先定义好的，Orchestrator-Workers 的子任务由编排者根据输入现场决定。
适用场景：多文件复杂修改（修改哪些文件、每个文件怎么改，都要看具体任务）；多源信息研究（要检索哪些来源、每个来源问什么，事先没法固定）。
5. Evaluator-Optimizer（评估者-优化者）
一个 LLM 生成初稿（Optimizer），另一个 LLM 拿着 rubric 严格审计（Evaluator），二者在条件循环里迭代直到达标。
两个判断依据：一是”人类明确表达反馈时 LLM 输出确实能改善”，二是”LLM 自己也能生成这种反馈”。原文举例：文学翻译（初译容易漏掉语言细腻处，评估器可以挑出来让优化器再译一遍）；复杂搜索任务（评估器决定要不要再多搜几轮）。
原文另外单独讲了一种 Autonomous Agents（自主智能体）——不算工作流，因为它不走预定路径。核心机制是：LLM 拿到任务后，在”环境反馈-思考-行动”的循环里自主推进，每一步从环境里拿 ground truth（工具调用结果、代码执行结果、真实 API 报错）判断是否达成目标，直到完成或触发停止条件（比如最大迭代次数）。
Claude Code 本身就是一个典型的 Autonomous Agent。而它 2026 年 6 月发布的动态工作流，是给 Autonomous Agent 加装的”高级模式”。
Q: 那 Claude Code 的动态工作流又是什么？为什么需要它？
《A harness for every task》里 Thariq Shihipar 给出的动机很清晰：默认 Claude Code harness（在此指 Claude Code 的 agent 运行时框架，负责调度 LLM 与工具之间的循环执行；本专题第 003 期已作过完整拆解）让模型在同一个上下文窗口里既规划又执行——对多数编码任务够用，但在长周期、大规模并行、高度结构化或对抗性强的任务上，会遇到三个可复现的失败模式：
- Agentic laziness（智能体惰性）：任务有 50 项，改到第 35 项就宣告”搞定了”
- Self-preferential bias（自偏好偏差）：让同一个模型既写代码又当裁判，它倾向于赞同自己
- Goal drift（目标漂移）：轮次越多、上下文压缩越多，最初的边界条件（比如”不要动 X”）越容易被丢
动态工作流的解法是：Claude 现场生成一段 JavaScript 脚本，脚本调用几个特殊函数（agent()、parallel()、pipeline() 等）来 spawn 和协调子智能体（subagents）。每个子智能体跑在独立的上下文窗口里，任务边界干净，规划和执行分离。
关键性质：
- 中断（用户手动打断、终端退出）后，重开会话可以断点续传
- 可以为每个子智能体指定不同的模型（Haiku 处理分类、Opus 处理复杂推理）和 worktree 隔离
- 子任务之间通过结构化输出通信（可以要求返回 JSON schema），不是靠”继续在对话里描述”
触发方式两种：直接说 “create a workflow”，或者 prompt 里加关键词 ultracode（也可以在 Effort 菜单里长期打开 ultracode 设置，让 Claude 自主决定何时触发工作流）。
Q: 动态工作流的 6 种模式，具体怎么划分？
按 Thariq 那篇原文：
1. Classify-and-act（分类并执行）
用一个分类器 agent 判断任务类型，路由到不同的下游 agent 或行为。也可以放在末尾，用分类器决定输出格式。
适用场景：任务类型混合，需要不同专业度或不同模型。前面 Anthropic 5 大模式里的 Routing 就是它的静态版。
2. Fan-out-and-synthesize（扇出与合成）
大任务拆成多个小步骤，每个步骤由一个 subagent 处理，最后再由 synthesize agent 合成。同步屏障（barrier）等所有 fan-out agent 完成才继续。
原文重点说了”clean context window”这个理由——每个 subagent 上下文全新，不会互相污染。这直接对应 5 大模式里 Parallelization / Sectioning，但动态版做得更极端：可以是几百个并发。同时它也可以视为 Orchestrator-Workers 的动态版——由 Claude 现场生成的脚本充当 orchestrator，动态决定拆几路、每路做什么。两组模式并非严格一一对应，而是”5 种基础模式的静态定义” ↔ “6 种动态模式的运行态组合”这样的多对多关系。
适用场景：大规模代码迁移（Bun 从 Zig 重写到 Rust 就是这个模式的极限案例）、深度研究（/deep-research 命令内置就是它）。
3. Adversarial verification（对抗性验证）
每个 spawned agent 输出后，另派一个（或多个）verifier agent 拿着 rubric 反向审计。红蓝对抗结构。
原文原话：
For each spawned agent, run a separate spawned agent to adversarially verify its output against a rubric or criteria.
这条是专门治自偏好偏差的。让同一个模型审自己写的代码它会放水，让独立视角的另一个 agent 拿着挑剔的 rubric 来审就不会。
适用场景：安全审计、合规校验、事实核查（比如博客文章发布前把每个技术断言都对着代码库验一遍）。
4. Generate-and-filter（生成与过滤）
多个生成器并发宽口径产出想法，再走过滤器——按 rubric 打分、去重，最后只留下高质量少数。
和 Adversarial verification 的区别：这里主打”多样性 + 收敛”，不是”红蓝对抗”。生成阶段鼓励发散，过滤阶段收敛。
适用场景：测试用例生成（宽口径覆盖 → 去重 → 保留边界用例）、方案头脑风暴、简历海筛。
5. Tournament（锦标赛）
不拆任务，而是让 N 个 agent 用不同思路/不同模型独立解同一个任务，然后走两两对决（pairwise judges）的淘汰赛，直到决出最优。
原文特别强调了一句关键工程直觉：“comparative judgment is more reliable than absolute scoring”——两两对比比给绝对分数更稳定。
适用场景：对主观品味（taste）依赖强的任务——CLI 工具起名、UI 方案选型、算法思路选择。原文举了个巧妙的例子：要给 1000+ 条支持工单按严重度排序，塞进一个 prompt 质量必崩溃，但用 pairwise-comparison pipeline，“确定性循环持有 bracket，只有当前对比进入 context”，就能完成精准排序。
6. Loop until done（循环直至完成）
工作量未知的任务，持续循环 spawn agent，直到停止条件满足（“没有新发现” 或 “日志里没有新错误”），而不是跑固定轮数。
这是专治智能体惰性的——固定 N 轮迭代，模型学会”演到 N 轮就说完了”；换成动态终止条件，它必须真的没发现新东西才能停。
适用场景：debug 长尾根因、持续 triage、自动化修复循环。原文给的组合技：配合 /loop 让它按固定间隔跑，配合 /goal 设硬性完成要求。
Q: 那 Evaluator-Optimizer 到底属于 6 种动态模式的哪一类？
Gemini 的答复是：在动态工作流的分类里，Evaluator-Optimizer 是 “Adversarial Verification” 与 “Loop Until Done” 的复合体。
拆开看：
- Optimizer 生成/优化 → 对应 Adversarial Verification 里的 worker
- Evaluator 拿 rubric 审计 → 对应 Adversarial Verification 里的 verifier
- 两者反复迭代直到达标 → 对应 Loop Until Done 的动态终止条件
反过来说也成立：5 种基础模式里的 Evaluator-Optimizer，是把 6 种动态模式里的 Adversarial Verification + Loop Until Done 的组合，做成了一个可复用的静态积木。
这个观察很关键——它揭示了两组模式的关系：
5 种基础模式 是静态积木（build-time），
6 种动态模式 是运行态编排（runtime），
运行态由智能模型（Opus 4.8）现场把积木拼起来。
Q: 两组模式并排放，什么任务用哪一种？
我把 Gemini 的选型指南整理成一张对照表，加了一列”典型失败模式”来说明每种模式在治什么病：
| 模式 | 属于 | 拓扑 | 治的失败模式 | 什么时候用 |
|---|---|---|---|---|
| Prompt Chaining | 5 基础 | 线性顺序 | 单次 prompt 步骤太多导致质量下滑 | 任务能干净拆成固定子步骤，且愿意用延迟换准确率 |
| Routing / Classify-and-act | 5 基础 / 6 动态 | 前置分类分流 | 混合任务用同一个 prompt 相互干扰 | 输入类型清晰可分类，需要不同专业度或不同模型 |
| Parallelization / Fan-out-and-synthesize | 5 基础 / 6 动态 | 并发 + 合成栅栏 | 单窗口上下文过长、信息交叉污染、目标漂移 | 子任务独立、可并发；追求速度或多视角 |
| Orchestrator-Workers | 5 基础（动态版本包含在 Fan-out-and-synthesize 里） | 中央动态拆分 | 子任务静态预定义时关键步骤被遗漏 | 多文件修改、多源研究，任务粒度和数量随输入变化 |
| Evaluator-Optimizer / Adversarial Verification | 5 基础 / 6 动态 | 生成 ⇄ 审计闭环 | 自偏好偏差 | 有清晰评估标准，且反馈能有效改善输出 |
| Generate-and-filter | 6 动态 | 多路发散 → 漏斗收敛 | 单次生成方案单一 | 需要覆盖率优先、后过滤（测试用例、方案探索） |
| Tournament | 6 动态 | 多路独立尝试 → 两两淘汰 | 单次绝对评分不稳定、主观判断结果发散 | Taste-based 决策（命名、UI、算法思路） |
| Loop until done | 6 动态 | 状态机环路 | 智能体惰性、任务边界未知 | 长尾 debug、持续 triage、直到”没有新发现”才停 |
Q: 有具体的工业级案例可以看吗？
有一个非常极端的案例，可以体会动态工作流真正投产时能做多大事——Bun 团队用 11 天把整个运行时从 Zig 重构为 Rust。
这个案例首次披露在 Anthropic《Introducing Dynamic Workflows in Claude Code》公告（2026-05-28）里，创始人 Jarred Sumner（贾里德·萨姆纳，Bun 运行时创始人、Oven 公司 CEO） 后来在 X 上给出了完整流水线细节。梳理一下他描述的流程：
- 生命周期映射：先跑一个工作流，把 Zig 代码里每个 struct 字段精准映射到 Rust 的 lifetime 上
- 海量并行重写：spawn 数百个 subagent 并发把
.zig文件重写成行为等价的.rs，每个文件配两个独立的 reviewer agent 做代码审计 - 编译修复闭环：进入 fix loop，持续跑 build 和测试直到零报错
- 隔夜性能调优：合入后夜间自动排查冗余 data copy，自动开 PR 供人工 review
总代码量约 75 万行 Rust（Anthropic 官方公告数字；Jarred 自己在 X thread 里报的阶段性数字更大，约 96 万行），重构后跑通了原有测试集的 99.8%。需要注意的是，Anthropic 公告特别说明”截至发稿时该重构尚未合并进 Bun 生产环境”——这是官方原文的限定语，不是”已经全量上线”的成品案例，而是在极限规模上验证动态工作流可行性的示例。
从 6 种模式的视角看这条流水线：
- 步骤 2 里的并发重写 = Fan-out-and-synthesize
- 步骤 2 里的 reviewer agent 审计 = Adversarial Verification
- 步骤 3 的 fix loop = Loop until done（停止条件：build & test 双双绿）
- 步骤 4 的 性能调优 = 又一次 Loop until done（停止条件：找不到新的 unnecessary copy）
这就是把 4 种模式串联/嵌套起来完成一个跨季度工程量的项目。这种”由智能模型现场决定拼哪几种”的能力，就是 Anthropic 官方定义的 “a harness for every task”——每个任务一套定制的编排器。
Q: 什么时候不该用动态工作流？
Thariq 原文明确警告了：动态工作流不是每个任务都需要，Token 消耗远超普通会话。
原则是：
most traditional coding tasks do not need a panel of 5 reviewers.
也就是说——问自己一个问题：这个任务真的需要更多算力吗？
- 单文件小改动 → 不需要
- 明确的一次性问题 → 不需要
- 高价值、大范围、错一次代价高的任务 → 值得
这也和《Building Effective Agents》的**“Start Simple”**原则完全一致：先用最简单的方案，能证明不够用再升级。
Q: 落到我个人日常，这两组模式该怎么用？
我的初步用法：
日常应用架构层面（写代码、搭 pipeline）——用 5 种基础模式作为静态积木清单：
- 有清晰步骤的流水线 → Prompt Chaining
- 混合类型输入 → Routing
- 独立子任务 + 追求速度 → Parallelization
- 子任务不定 + 需要中央调度 → Orchestrator-Workers
- 有评估标准 + 需要自动纠错 → Evaluator-Optimizer
Claude Code 会话层面（做研究、大规模重构、审计）——用 6 种动态模式作为意图关键词（可以用中文自然描述，也可以直接用英文原短语；下面括号里给的是 prompt 措辞示例，不是必须的固定指令）：
- 需要覆盖 50+ 项且怕漏 → 描述 “把这些逐一处理再合成结果”（对应 fan out and synthesize）
- 涉及安全或合规审计 → 描述 “让另一个 agent 独立审我的输出”（对应 adversarial verification）
- 起名 / 挑方案 → 描述 “生成 N 个候选跑一场锦标赛”（对应 run a tournament）
- 未知长尾 debug → 描述 “反复找直到没有新发现才停”（对应 loop until done）
- 任务量大到不确定 → 直接在 prompt 里加
ultracode，让 Claude 自主决定是否触发工作流
关键是记住这两组模式不是竞争关系，是同一套设计思想的不同抽象层：5 是编译期的类型定义，6 是运行时的实例化组合。
参考资料
- Building Effective Agents — Anthropic Engineering，Erik Schluntz & Barry Zhang，2024-12-19。Agent 架构入门经典，5 种基础工作流模式的原始出处。
- A harness for every task: dynamic workflows in Claude Code — Thariq Shihipar & Sid Bidasaria，2026-06-02。动态工作流深度技术拆解，6 种编排模式的原始出处。
- Introducing Dynamic Workflows in Claude Code — Anthropic 官方发布公告，2026-05-28。首次披露 Bun 11 天重构案例的完整流水线（原文明确说明”尚未合并进生产”）。
- Claude Opus 4.8 — 支撑动态工作流的底层模型公告，说明为什么”Claude 现在聪明到能自己写 harness”。
- Model Context Protocol — 《Building Effective Agents》里提到的工具增强层协议，与本文的模式讨论互补。
- Jarred Sumner 的 X thread — Bun 团队 Zig → Rust 重构的第一手技术细节。