Agent 编排：工作流、自主与混合（Agent Orchestration）

所属：01-fundamentals / 04-agent-architecture
面试权重：★★★
来源：《深入理解 AI Agent：设计原理与工程实践》第 1 章「Harness 工程 / 编排模式：工作流与自主」（李博杰），另引第 10 章「多 Agent 协作」；框架对比表同出处。五种工作流模式（提示链 / 路由 / 并行化 / 编排者-工作者 / 评估者-优化器）的命名取自 Anthropic《Building Effective Agents》（书第 1 章脚注所引），书中只给了「工作流 = 预定义代码路径」的定义与订票、文生图两个例子，未逐一命名这五种模式，此处标渠道，未做一手考证
相关知识点：agent-react.md（单体的 ReAct 循环与循环控制：Thought→Action→Observation、最大步数/预算、无进展检测 —— 本篇不复述循环本身）、multi-agent.md（多 Agent 的收益判据与拓扑：supervisor / router / 判据层与机制层、LangGraph 共享状态、handoff）、13-multi-agent-coordination.md（协作的机制层：数据平面 / 控制平面 / 冲突治理三层）、../07-distributed-systems/state-machine.md（跨机器后的持久化执行：状态机与 checkpoint）

一句话#

编排（orchestration）回答的是：一条任务从入口到出口，路径是谁定的、在哪定的。 书里的判断顺序是从简单到复杂 —— 先考虑单次 LLM 调用；能用提示与上下文示例解决就别上 Agent 系统；需要多步且能清晰分解成固定子任务就用工作流；只有需要动态决策与灵活路径才用自主 Agent。而 Agent 系统本质是用延迟和成本换任务性能，这笔交换值不值，是这道题真正的考点。

为什么重要（面试角度）#

• 它考的是「架构判断力」而不是名词量。 面试官想听的不是「工作流和自主 Agent 的区别是……」，而是你能不能在动手前选对形态。「该用一个提示解决的事别上多 Agent」这句话答得出来，比会背五种工作流模式更值钱。
• 这是对你项目的正面提问。 你在 Race Bot 里做的是 Agentic Workflow（外层固定骨架）、在 Writing Copilot 里做的是 LangGraph 上的多智能体（编排层 + 共享状态） —— 两条都是真实经验，会被顺着往项目里挖。这一篇给你把「路径是谁定的」讲清楚的坐标系。
• 混合形态是分层点。 大多数人只会答「要么工作流、要么自主 Agent」；能答出「先由自主 Agent 把工作流写出来，再由工作流确定性执行」的人立刻分层，而且这条正好接上第 10 章的 Claude Code Workflow 工具实例。
• 它是通篇的总入口。 单体的循环在 agent-react.md、多 Agent 的判据与拓扑在 multi-agent.md、协作机制在 13-multi-agent-coordination.md —— 这一篇讲的是它们之上那一层：路径怎么定。

⚠️ 边界声明：Race Bot 的编排式工作流与 Writing Copilot 的 LangGraph 多智能体是你的一手经验，可以讲。框架横向对比不是 —— 你只用过 LangGraph 一家，书里那张表（Codex Harness / n8n / Dify / CrewAI / OpenClaw…）是书里的口径，其余框架你没有实际选型过，面试用「按这张表我会这么选」的口径讲，不要讲成「我用过这些框架」。大规模分布式编排同理，见本篇 §8。

核心内容#

1. 先给判断顺序：默认不上 Agent#

书里给的原则很直接：从简单到复杂。

还有一句定义性的表述要记住：Agent 系统通常是用延迟和成本换取更好的任务性能，所以要权衡这笔交换值不值 —— 不是「更自主就更好」。

反面例子（书里给的，能直接引）。 为「从百万条聊天记录中提炼个人记忆」设计 Agent，很容易迅速画出一条看似严谨的流水线：切分对话片段 → 提取 → 证据核验 → 身份解析 → 记忆整理 → 合并复核，再建事实图、覆盖账本、不可变版本。每个部件单看都有道理，组合起来却很低效、不可靠：因为复杂工作流的执行拓扑是固定的，遇到新例外就继续加节点，架构越来越复杂、通用性越来越差，而模型原本能按上下文做的语义判断，反而被工作流写死了。

书把这种取舍概括成 Manus 那句「Less structure, more intelligence.」：先给一个能力足够的 Agent 清晰的目标、必要的上下文和可组合的工具，用自然语言告诉它如何查证、比较、处理冲突；程序只固化必须始终成立的边界（权限、不得覆盖原始材料、原子发布）。只有业务约束本身要求，或评测反复暴露出某类稳定失败时，才把对应步骤升级成专门的验证器、独立 Agent 或确定性流程。好的结构不是替 Agent 预演全部思考，而是守住边界、把边界内的决策空间还给模型。

Anthropic 三原则里的第一条也是这个：保持简单 —— 直接的 API 调用优于复杂的框架，清晰的代码优于聪明的抽象，因为每多一层抽象都会成为以后调试时新的盲区。

2. 工作流模式逐个拆#

工作流 = 通过预定义的代码路径来编排 LLM 和工具，执行路径是确定性的、由开发者预先设计，LLM 只在每个节点内部负责理解和生成（定义出自书第 1 章）。书给的最简单例子是文生图：提示词改写 → 图片生成 两个固定节点，改写那一步的 LLM 做的是「把人话翻译成生图模型听得懂的格式」—— 书把这种给工具能力短板打补丁的 Harness 代码叫适配层。

下面五种模式是工程里最常见的工作流骨架。命名取 Anthropic《Building Effective Agents》（书脚注所引，书中未逐一命名）：

两条要展开说清楚的边界：

• 投票 / 辩论不等于「多个脑子」。 同一模型 + 相似上下文产生的多条结论不能自动当作独立证据；书第 10 章引的研究（Tran & Kiela, 2026）在多跳推理上对比单 Agent 与五种多 Agent 架构，思考 token 预算对齐后单 Agent 持平甚至更好，并给了信息论解释（辩论中多个 Agent 处理的是完全相同的文本信息，串行转述只可能丢信息）。真正有效的「多次」要么是独立采样再聚合（自一致性 / 多数投票），要么利用生成与验证的难度不对称。 判据见 multi-agent.md 的判据层：协作是否引入了单个 Agent 拿不到的新信息。
• 评估者-优化器必须有外部证据，否则退化成不可靠的自审。 GPT-4 在没有外部反馈时自审，把对的改错的次数多于把错的改对的 —— 详细证据见 multi-agent.md。给评估者接上测试执行结果 / 渲染截图 / 外部工具验证，它才真正有效。

与 multi-agent.md 的分工：那一篇从拓扑视角讲 supervisor / router / pipeline；这一篇从编排模式视角讲同几件事。实现上 supervisor 不神秘 —— 它就是一个「读状态 → 决定下一个节点 → 写状态」的节点，去掉包装就是一个分类器加一段调度代码（见 multi-agent.md）。所以别把两篇的内容互相当成新知识重复讲。

3. 工作流的两个真实优势（书里的口径）#

书明确给了工作流的两个核心优势，都不在「省成本」上：

1. 严格的流程控制。 关键步骤不被跳过或乱序执行，「付款前不能预订」这类业务规则由代码强制执行，不依赖 LLM 的判断。这是合规场景的硬要求 —— 把正确性建立在代码上，而不是建立在模型「记得住」上。
2. 安全性。 因为执行路径确定，提示注入或模型犯错最多只能影响当前节点内部的处理，无法让 Agent 跳到不该执行的分支 —— 攻击面被限制在单个节点内。

局限也要一起说：缺乏变通性。 出现预设流程未覆盖的情况（比如用户在付款环节临时想改签、或航班取消需要推荐替代方案），固定节点路径无法灵活应对，只能走预设的异常分支，或把控制权交还给人类。

4. 自主 Agent：路径由环境反馈实时决定#

自主 Agent 与工作流的核心区别只有一条：执行路径不是预先定义的，而是 Agent 根据环境反馈实时决定的。 仍以订票为例，自主 Agent 不预定义四个节点：它会自行决定先搜索航班 → 发现要登录 → 先核实身份 → 回来搜索 → 发现最便宜的航班要转机 → 主动询问用户 → 按用户答复调整条件……

书里的几个要点：

• 自主 Agent 需要自主规划能力，还要能识别失败、调整策略，而不只是出错时停下。
• 自主性不等于无限制 —— 必须有显式的停止条件，否则容易陷入死循环或过度执行。书给的退出条件是：调用最终输出工具、模型返回没有任何工具调用的响应、遇到错误、达到最大轮数。
• 适用场景：开放式、难以预测所需步骤数的问题 —— Coding Agent 解 SWE-bench、Computer Use、需要迭代搜索与分析的研究任务。
• 代价：更高的成本 + 复合错误风险。部署时要在沙盒中充分测试、设置护栏与监控，并在关键决策点考虑加入人机协作检查点。

循环内部的机制（ReAct 的 Thought/Action/Observation、最大步数与预算、无进展检测、终止后返回什么）见 agent-react.md。本篇只说编排视角：路径的决策权在模型手里，而且必须给它一个出口。

5. 混合形态：这一篇的高分点#

工作流与自主 Agent 并非非此即彼。书给了两种混合方式。

混合方式一：按环节分工。 关键的、有严格合规要求的流程用工作流确保可靠性，需要灵活决策的部分切换到自主模式。以订票客服系统为例（书中参考答法）：主体用工作流四节点「身份核实 → 搜索 → 付款 → 预订」保证「付款前不能预订」等合规顺序、把注入攻击面限制在单节点；而开放性环节（理解需求、改签、航班取消后的替代方案推荐）切换为自主 Agent；高风险操作（大额付款、退款）加人工确认。书里提到 n8n 这类工具允许在同一个系统里同时使用工作流节点和自主 Agent 节点。

混合方式二（更值钱）：先由自主 Agent 把工作流写出来，再由工作流去执行。 这是书第 1 章提出、第 10 章展开的形态：

Agent 读完任务后自行决定拓扑并生成一段编排代码；代码一旦生成，执行阶段就退回工作流的确定性。

它解决一个具体痛点：管理者模式里，管理者始终待在循环中 —— 每派发一个子任务都要模型做一次决策，上下文随调用次数增长。 换成本方式后，「决定拓扑」只发生一次，后续的每一次调度都是确定性的代码。既保留了自主 Agent 面对未知任务的灵活性，又不必让模型在每次调度上都参与决策。

书第 10 章给的实例是 Claude Code 内置的 Workflow 工具：它给 Agent 提供 agent()、parallel()、pipeline() 几个原语，每个 agent() 是拥有独立上下文的子 Agent，schema 约定它只返回结构化结论而非完整轨迹。例如「为一篇技术稿件核实七组事实」——先按方向并行调研，再对每条发现逐条独立核实，最后统一汇总（pipeline 编排两个阶段 + parallel 展开逐条核实）。

判据一句话：把「决定拓扑」和「按拓扑执行」拆到两个时间点 —— 前者作一次性的、可审查的决策，后者是确定性的、可缓存的执行。任务的拓扑是否稳定，决定这条值不值得用：拓扑每次都不同就退化成方式一的自主模式；拓扑一旦定下来就能重复用，这条最划算。

6. 编排的工程要素#

不管哪种形态，一条编排落地的工程问题就这几件，每件给一句话判据：

状态传递这一条要单独记住一句话（它是错误级联的根源）：进程之间传字节是逐位保真的，Agent 之间传语义每转述一次都是有损重编码（见 13-multi-agent-coordination.md）。所以 handoff 走结构化字段、不走自然语言总结 —— 有 schema 才可校验、可评测。可观测性在多节点编排里从加分项变成必需品：单 Agent 的轨迹是一条线，多节点编排的失败点可能在任意节点，没有每节点的输入输出就无法定位（机制层见 13-multi-agent-coordination.md）。

7. 框架对比：讲定位差异，不讲参数#

书第 1 章给了一张选型表。它按「核心定位 + 编排模式 + 开发方式」分档，比参数罗列有用得多：

怎么讲定位差异（这才是这道题要的）：

• 第一档（LangGraph）给你显式的图 + 共享状态，控制流可枚举、可测试、可画出来 —— 你在 Writing Copilot 里用的就是这一档的真实经验。代价是你要自己设计 state schema。
• 第二档（n8n / Dify）把编排交给拖拽，适合业务自动化与非技术团队；代价是控制流藏在框架的画布后面。
• 第三档（Codex Harness / Claude Agent SDK / Pi）是自带自主循环的运行时 —— 你不自己写编排，框架替你跑循环，你只定义工具与边界。
• 第四档（CrewAI）是角色化多 Agent 的封装。

书明确给了选型的总判据：关键考量不在于框架本身的复杂度，而在于它能否用尽可能少的抽象层让你专注于业务逻辑；而且框架发展迅速，学会某个具体框架的用法并不重要。呼应 §1：每多一层抽象都是以后调试时新的盲区。

⚠️ 这一节是书里的表格口径。你实际用过的是 LangGraph 一家（Writing Copilot）；其余框架的定位差异属于「我知道它们各自站在哪一档」，不是「我选过型」。

这张表只回答「站在哪一档」。 每个工具到底属于框架 / 运行时 / Harness / 持久化执行引擎的哪一类、各自的核心抽象是什么、以及怎么选型（含面经直接题里的 Eino），见 ./16-agent-runtime-tools.md。一句话联系：这一篇的七件工程要素（§6）就是运行时替你兜的那几件事，所以「要不要上运行时」的判据，和「这七件你打不打算自己写」是同一个问题。

8. 把线接到分布式：跨机器之后，问题换了#

前面所有讨论都默认编排在单机 / 单进程内。一旦编排跨进程、跨机器、要重启后继续，问题就从「谁定路径」变成「路径执行到一半，机器挂了怎么办」—— 后者是 07-distributed-systems/ 那一套：

一句话收口：单机内的编排问题是「谁定路径」，跨机器之后是「路径执行到一半、部分失败怎么继续」 —— 后者要面对部分失败、消息重复投递、状态一致性这些单机里不存在的问题。这也是这一篇存在的理由：它讲的是入口，出口在 07-distributed-systems/。

常见面试问法#

Q：什么时候用工作流，什么时候用自主 Agent？ A：先按「从简单到复杂」的顺序排除：先考虑单次 LLM 调用，优化提示与上下文示例能解决就别上 Agent 系统；需要多步且能清晰分解成固定子任务，就用工作流；只有步骤依赖中间结果、事先无法枚举，必须动态决策时，才用自主 Agent。要记住 Agent 系统本质是用延迟和成本换任务性能，不是更自主就更好。书里的反面例子：给「从百万条聊天记录提炼记忆」一上来画六七个 Agent 的流水线，每个部件都合理、组合起来很低效 —— 因为固定拓扑遇到新例外只会不断加节点，把模型本来能做的语义判断写死了。

Q：工作流比自主 Agent 好在哪？ A：书里的口径是两点，都不在省钱上。 ① 严格的流程控制：「付款前不能预订」这类规则由代码强制执行，不依赖 LLM 判断；② 安全性：执行路径确定，所以提示注入或模型犯错最多影响当前节点内部，无法跳到不该执行的分支，攻击面被限制在单节点内。代价是缺乏变通性 —— 流程未覆盖的情况只能走预设异常分支或交还人类。所以生产系统常用混合：合规流程走工作流，开放环节切自主模式。

Q：除了「一部分工作流、一部分自主」，还有什么混合方式？ A：「先由自主 Agent 把工作流写出来，再由工作流去执行」 —— Agent 读完任务自行决定拓扑并生成编排代码，代码生成后执行阶段退回确定性。它解决的问题是：管理者模式下管理者始终待在循环里，每派发一个子任务就要模型决策一次、上下文随调用次数增长；换成本方式后**「决定拓扑」只发生一次**。书第 10 章的实例是 Claude Code 的 Workflow 工具（agent() / parallel() / pipeline()，每个 agent() 独立上下文、只返回结构化结论）。判据是任务的拓扑稳不稳定：每次都不同就退化成自主模式，稳定可复用才划算。

Q：一条编排在工程上要处理哪些事？ A：七件，每件一句话判据：任务分解（子任务有没有独立成功判据）、路由与分发（分类置信度可判吗、低置信有兜底吗）、状态怎么传（参数传递还是共享状态；Agent 间传语义每转述一次都是有损的，所以 handoff 走结构化字段）、失败与补偿（有没有回到上一稳定状态的检查点）、幂等（节点重跑会不会重复副作用）、并发与限流（瓶颈在哪、并发上限防打满配额）、可观测（哪一步慢、哪一步贵能不能单独看出来）。多节点编排没有可观测性等于不可运维 —— 单 Agent 的轨迹是一条线，多节点的失败点在任意节点。

Q：你的编排什么时候会从「单机」变成「分布式问题」？ A：一旦跨进程、跨机器、要重启后继续，问题就从「谁定路径」变成「路径执行到一半挂了怎么办」。 这时要面对部分失败、消息重复投递、状态一致性 —— 单机里不存在的问题。对应到三块：状态机与持久化执行（每步 checkpoint）、任务队列（解耦与背压）、超时重试幂等（重跑不重复副作用）。判据是：任务能不能在一次进程生命周期内跑完 —— 能，就还是编排问题；不能，就要 07-distributed-systems/ 那套。

易错点#

自测#

1. 有人要做一个「从百万条聊天记录提炼个人记忆」的系统，方案是六七个 Agent 串成的流水线（切分 → 提取 → 证据核验 → 身份解析 → 记忆整理 → 合并复核）。你按书里的原则怎么评价？

2. 一个订票客服系统：「付款前不能预订」是硬合规要求，但用户经常临时改签、或航班取消要推荐替代方案。你会怎么设计？

3. 「先由自主 Agent 把工作流写出来，再由工作流去执行」是什么意思？它比让 Agent 一直待循环里好在哪？什么任务不适合它？

4. 一条三段式编排（检索 → 生成 → 校验）要上生产。除了「能不能跑通」，你还要考虑哪些事？

5. 面试官说「我们的编排现在跑在一台机器上，挺好的，为什么要考虑分布式」—— 你怎么答？