企业官网建设流程全解析

智能体面试准备（三十四）：智能体编排与流程引擎实战——从"硬编码脚本"到"可控流程"

本篇是 B 系列第 34 篇。B12 讲 ReAct 单循环、B15 讲多智能体协作、B29 讲框架、B30 讲生产化。但真实业务里大量 Agent 系统是半结构化的：既有确定的流程步骤（必须按顺序走、某步必须人工审批），又有需要 LLM 灵活判断的分支。这就需要"编排（orchestration）"——把确定性与灵活性编排进同一张图。本文讲清流程引擎怎么设计、状态机/DAG/事件驱动怎么选、人工节点怎么嵌。B33 讲的是 Agent "自我改进"，本文讲的是"把 Agent 装进可控骨架"——两者共同决定 Agent 能不能在生产里长期稳跑。

一、为什么不能只靠 ReAct 裸奔

ReAct 把所有决策交给 LLM：下一步干啥、调哪个工具、何时停。这在 demo 里很爽，但在生产里有三个致命问题：

ReAct 裸奔的坑: 1. 不可控: 该走的合规步骤被 LLM "忘了", 直接跳到结论 2. 不可审计: 流程没有显式节点, 出事说不清走到了哪 3. 难复用: 每个任务的"套路"散落在 prompt 里, 改一处全崩

所以生产级 Agent 普遍采用"显式流程骨架 + LLM 填充血肉"：流程的"必须顺序、必须审批、必须校验"由引擎保证，LLM 只负责流程里"需要智能"的节点。这就是编排的核心思想。

┌─────────────────────────────────────┐ │ 流程引擎 (Orchestrator) │ │ 保证: 顺序/分支/人工/校验/回滚 │ └─────────────────────────────────────┘ │ 在"智能节点"调用 ▼ ┌─────────────────────────────────────┐ │ LLM / 工具 / 子 Agent (灵活填充) │ │ 负责: 理解/生成/调用/判断 │ └─────────────────────────────────────┘

二、三种编排范式：状态机、DAG、事件驱动

2.1 状态机（State Machine）：步骤强顺序

适合"步骤固定、必须按序"的任务，如报销审批、KYC 流程。每个状态有显式转移条件。

[收单] --材料齐全--> [初审] --通过--> [合规校验] --通过--> [主管审批] --通过--> [打款] │ │ │ └--缺材料-->[退回补充] └--不通过-->[拒单] └--不通过-->[拒单]

优点：可控、可审计、逻辑一目了然。缺点：分支复杂时状态爆炸。LLM 常用于"状态内的判断"（如初审合不合规），但转移由规则决定，不被 LLM 带偏。

2.2 DAG（有向无环图）：可并行的步骤编排

适合"多步、部分可并行、有依赖"的任务，如"先并行查三个数据源，再汇总分析"。

┌──> [查库A] ──┐ [入口]──┼──> [查库B] ──┼──> [汇总分析] ──> [生成报告] └──> [查库C] ──┘

DAG 引擎（如 Airflow 思路、LangGraph 的图）负责拓扑排序、并行调度、失败重试、断点续跑（呼应 B22）。LLM 节点是 DAG 里的一类节点，和普通函数节点平起平坐。

2.3 事件驱动（Event-driven）：松耦合、长时

适合"跨系统、异步、长时"的流程。节点通过事件总线通信，彼此不知道对方存在。

[用户提交] --event--> [风控服务] --event--> [通知服务] └--event--> [工单服务]

优点：解耦、可水平扩展、天然支持长时任务（等外部回调）。缺点：链路追踪难、调试复杂。常配合 B20 可观测性做 trace。

┌──────────────┬────────────────────┬────────────────────────┐ │ 范式 │ 适用 │ LLM 的角色 │ ├──────────────┼────────────────────┼────────────────────────┤ │ 状态机 │ 强顺序/审批 │ 状态内判断, 转移走规则 │ │ DAG │ 可并行多步 │ 图里的一类节点 │ │ 事件驱动 │ 异步/跨系统/长时 │ 事件消费者之一 │ └──────────────┴────────────────────┴────────────────────────┘

三、把 LLM 嵌进流程：节点的两种模式

流程里的 LLM 节点通常两种形态：

1. 决策节点（Router）：LLM 根据上下文选下一跳（"转人工 or 自动回复"）。要设兜底默认分支，防止 LLM 选了不存在的分支。
2. 执行节点（Worker）：LLM 在固定步骤里做生成/抽取/调用，输出喂给下一步。

# 一个 DAG 节点的伪代码（含 LLM 决策 + 兜底）defroute_node(state):decision=llm_classify(state["user_msg"],candidates=["自动回复","转人工","查知识库"])# 兜底: LLM 输出必须落在已知分支, 否则默认转人工return{"next":decisionifdecisioninKNOWNelse"转人工"}

关键工程原则：LLM 的输出在进流程前必须被校验/归一化（呼应 B32 注入防御与 B18 Function Calling 校验）。绝不能让 LLM 的自由文本直接驱动状态转移。

四、人工节点（Human Node）：把人编进流程图

B27 讲过人机协作，这里讲"人作为流程的一个节点"怎么落地：

[自动预处理] -> [LLM 草拟] -> [人工审核节点] -> [执行/发送] │ └─ 审核通过 / 驳回修改 / 接管重写

人工节点的技术要点：
-阻塞式等待：流程在此挂起，直到人操作（要有超时与升级机制）。
-上下文呈现：把 LLM 的草拟、依据、风险点完整推给审核人，否则人无法判断。
-审计留痕：谁、何时、改了什么，全记录（合规刚需）。
-可降级：人不在时能否自动驳回/转值班？要有 fallback。

五、错误处理与补偿：流程的"事务性"

真实流程会失败（工具超时、外部 503、LLM 胡说）。编排引擎要提供：

错误处理四件套: 1. 重试(Retry): 指数退避, 对临时故障 2. 超时(Timeout): 单节点超时熔断, 防卡死 3. 补偿(Compensate): 已做的步骤如何回滚 (Saga 模式) 4. 死信(Dead-letter): 多次失败转入人工/告警, 不丢任务

[Saga 补偿示意] T1(扣款) -> T2(发券) -> T3(通知) │ T2 失败 ▼ C1(退款补偿) -> 标记失败, 进死信队列

这把 Agent 流程当成分布式事务来设计——B22 的断点续跑、幂等、重试，在这里都是基础设施。面试能联想到 Saga/补偿，说明你有后端功底而非只会写 prompt。

六、动态编排：让 LLM 在约束内"编流程"

更高阶：不给固定流程图，而是给 LLM 一组"可用工具 + 流程约束"，让它动态生成执行计划（呼应 B17 HTN 规划）。但要让它"在框里跳舞"：

给 LLM 的约束: - 只能用白名单工具 - 必须包含 [合规校验] 节点 - 涉及金额必须过 [人工审批] - 步数上限 20, 超则终止 LLM 输出: 一个可被引擎解析的执行计划 (JSON/DSL) 引擎: 校验计划合法性 -> 按计划调度 -> 监控执行

这比纯 ReAct 可控（有约束、可解析、可审计），比纯硬编码灵活（计划按需生成）。代价是"计划解析 + 校验"的工程复杂度。

plan=llm_plan(user_goal,tools=WHITELIST,constraints=CONSTRAINTS)ifvalidate(plan):# 校验含必须节点/白名单/步数run_plan(plan)# 引擎调度, 非 LLM 直接跑else:fallback_to_static_flow()# 计划非法则走固定兜底流程

七、可观测与版本化：流程也要"上线管理"

编排出来的流程不是写完就完，要像代码一样管理：
-版本化：流程定义进 Git，改流程走 PR + review。
-灰度（B23）：新流程先放 5% 流量，对比旧流程的成功率/成本。
-追踪（B20）：每 nodes 耗时、输入输出、LLM token、工具调用，全 trace。
-回滚：新流程翻车一键切回旧版。

流程上线管理 = 代码评审 + 灰度 + 追踪 + 回滚 这和微服务上线一模一样, Agent 流程本质是"带 LLM 的分布式系统"

八、生产落地深潜：选型与反模式

真正动手搭编排，我建议按"复杂度递进"选型，别一上来就上最重的。第一档：线性/强顺序任务用状态机，规则清晰、审计容易，大部分企业流程（审批、 onboarding）都属于这一类，用状态机 + LLM 判断节点就够了，别硬上图引擎。第二档：多步可并行、有依赖，用 DAG（LangGraph / 自建图调度），适合"先查多个源再汇总"的分析型 Agent。第三档：跨系统、异步、长时、要解耦，用事件驱动，适合嵌入已有微服务架构。第四档：任务千变万化、无法预定义流程，才上动态规划（LLM 编计划），且必须配强校验与兜底。绝大多数业务停在第三档就够，第四档是少数头部场景。

选型里最典型的反模式是"用 ReAct 假装编排"——把整个业务流程塞进一个超长 prompt，让 LLM 自己决定顺序，然后出事了说"模型不稳定"。这本质是把本该由引擎保证的确定性，错误地委托给了有随机性的 LLM。正确分工永远是：确定的顺序/审批/校验归引擎，不确定的理解/生成/判断归 LLM。能一句话点破这个分工，是面试区分"做过生产 Agent"和"只跑过 LangChain 示例"的分水岭。

8.1 编排与多智能体、与成本工程的关系

补一节容易和 B15 混淆的概念——编排（orchestration）和多智能体协作（multi-agent）不是一回事，但经常一起出现。多智能体讲的是"多个角色（规划者/执行者/批评者）怎么分工配合"，编排讲的是"这些角色以及确定性的步骤，如何被一张可控的流程图串起来"。换句话说，多智能体是"参与者结构"，编排是"调度骨架"。一个多智能体系统可以是纯 ReAct（无编排，靠 LLM 临场协调，灵活但不可控），也可以嵌进 DAG（每个 agent 是图里一个节点，可控可审计）。面试能分清这对概念，说明你不止用过框架，还理解框架背后的"控制流 vs 参与者"两层抽象。

再补一个落地细节：流程节点的幂等性是长时编排的生命线。一个"发送通知"节点如果因重试被执行两次，用户就收到两遍短信。所以每个有副作用的节点必须设计成幂等——用任务 ID + 状态表保证"同一指令重复到达只生效一次"（B22 强调过）。很多团队上线后才发现重复发券、重复扣款，根因就是编排层没把节点当"可能被执行多次"来设计。把"重试必然发生"作为前提去写每个节点，是流程引擎成熟的标志。配合死信队列，既保证不丢任务，又保证不重复副作用，这才是生产级编排的完整样子。这一点也和 B26 成本工程呼应——每个节点打上成本标签（token、人力、API 费），月底汇总就能看出哪条流程在烧钱。

8.2 编排引擎选型决策树与"该不该自研"

补一节"怎么向架构师解释为什么不用现成工具"。很多人第一反应是"上 Airflow 编排 Agent"，但 Airflow 是为批处理 DAG、定时触发设计的，不适合"用户实时对话驱动、步骤由 LLM 动态决定"的 Agent 流程——它的调度是静态的，而 Agent 流程是运行时才成形的。反过来，纯 LLM 框架（早年的 AutoGPT 式）又太自由、不可控。所以选型决策树应该是：若是后台批处理、定时跑，Airflow/Celery 足够；若是用户实时交互、需 LLM 灵活决策，用 LangGraph 这类"图+状态"的 Agent 编排框架；若是已融入微服务、要解耦长时，上事件总线（Kafka + 消费者）。把"Agent 编排"和"传统工作流编排"的边界讲清，能避免团队用错工具、事倍功半。

还有个常被问的点：编排引擎本身要不要自己造？我的建议是绝大多数情况不要。LangGraph、Temporal、甚至轻量状态机库都成熟，自研编排引擎会陷入"重写一个半成品 Airflow"的泥潭，还背运维债。除非你的流程有极特殊的约束（比如强合规下每个转移都要独立审计签名），否则优先用现成框架、把精力花在"流程定义"和"LLM 节点质量"上。见过团队花三个月自研编排引擎，结果核心业务价值（Agent 效果）反而没人打磨，本末倒置。这又回到一个反复出现的工程哲学：框架和基础设施是手段，业务效果才是目的——B29 讲过框架不是护城河，这里再次印证。面试时能说出"我为什么没自研、用了什么、踩了什么坑"，比滔滔不绝讲自研架构值钱得多。

8.3 编排的"度"：别把简单事搞复杂，以及可解释与热更新

补一节重要的克制——编排不是越复杂越牛，能线性解决的就别上图。我见过最典型的过度设计：一个三步就能搞定的"查天气→格式化→回复"，非要上 LangGraph 画一张带条件边和状态恢复的豪华图，结果 80% 的代码在维护编排框架本身，真正业务逻辑反而看不清。正确的克制原则是：能用单一提示词 + 少量工具调用解决的，就不编排；能用一个线性状态机的，就不上 DAG；能用 DAG 的，就不上动态规划。每升一档复杂度，都要有"非如此不可"的理由（如必须并行、必须人工、必须跨系统）。这其实是 B30 生产化里"简单性优先"原则在编排上的投影。

再给一个判断"该不该编排"的速查：问自己三个问题——（1）流程步骤是固定的还是每次都变？（固定→状态机/DAG，变化大→动态规划或 ReAct）（2）有没有必须人工把关的节点？（有→必须把人编进流程，奔着显式编排去）（3）失败了要不要回滚/补偿？（要→必须有事务性编排，不能是裸 LLM）。三个问题答完，该用哪种范式基本自明。

最后补两个常被低估的维度。其一，可解释性是合规硬需求：金融、医疗、政务类 Agent，监管要的是"这笔决策走了哪几步、哪步是人工、哪步是模型、依据是什么"的完整链路。状态机/DAG 这类显式编排天生能导出这样的"决策足迹"，而裸 ReAct 的隐式轨迹事后很难还原成可审计记录。所以在这类行业，编排化不只是工程优化，更是合规入场券。显式编排还天然产出结构化 trace，能直接复用 B20 的可观测体系（每节点 token、耗时、输入输出一键导出），二者是组合拳。其二，流程要支持热更新：业务规则天天变（"双十一审批额度上调""新合规加一道校验"），如果每次改流程都要发版重启，业务方会疯。好的编排引擎支持"流程定义外置"（配置中心/低代码画布），改流程无需动代码、甚至运营人员自助改，并接上 B23 的灰度——流程也能灰度发布。把"流程当配置、当可灰度资产"管理，Agent 系统才具备持续演进的敏捷性。

8.4 端到端编排示例：智能报销 Agent

给一个把本文概念串起来的完整例子——一个"智能报销 Agent"：

[用户提交票据照片] --OCR 节点(确定性工具)--> [票据结构化] │ ▼ [LLM 审核节点: 判断票据合规/金额合理] --不合规--> [人工审核节点] │ 合规 │ ▼ │ [风控 DAG: 并行查 预算余额/历史重复/供应商黑名单] --异常--> [人工审核节点] │ 全通过 │ ▼ │ [生成凭证] --Saga 补偿(若打款失败则冲销)--> [自动打款] --> [通知用户]

这个例子里：OCR 是确定性工具节点；LLM 审核是智能节点（带兜底默认"转人工"）；风控是 DAG 并行；人工审核是把人编进流程的 Human 节点；打款带 Saga 补偿防部分失败；全程每步都有 trace 和审计。它既不是纯 ReAct（关键步骤由引擎保证），也不是纯硬编码（审核、风控判断靠 LLM）。这正是"显式骨架 + LLM 血肉"的范本。能凭记忆画出这种图并在面试里逐节点解释，基本稳了。再补一句和成本控制的关系（呼应 B26）：编排里每个节点都可以打"成本标签"——LLM 节点标 token 消耗、人工节点标人力成本、外部调用标 API 费用，月底一汇总就能看出"哪条流程最贵、哪个节点在烧钱"，进而做优化。

8.5 编排与可观测性、版本化的不可分割

最后补两个落地真相。其一，显式编排和可观测性（B20）是组合拳：显式编排最大的隐性收益，是它天然产出结构化 trace。因为每个节点都是图里的显式一环，引擎能自动记录"进了哪个节点、停留多久、调了什么工具、产出什么、为何转移"——这比裸 ReAct 事后从一堆自然语言日志里反推"模型刚才在干嘛"清晰一万倍。所以选编排框架时，要看它和 OpenTelemetry / GenAI 语义追踪的集成度：能一键导出每节点的 token 消耗、耗时、输入输出，你的可观测体系（B20）才能直接复用，而不是为 Agent 单独造一套监控。

其二，流程要当"可灰度资产"管理：新流程定义进 Git、走 PR review，上线先放 5% 流量对比旧流程的成功率/成本（B23），翻车一键回滚。业务规则天天变（"双十一审批额度上调""新合规加一道校验"），如果每次改流程都要发版重启，业务方会疯。好的编排引擎支持"流程定义外置"（配置中心 / 低代码画布），改流程无需动代码、甚至运营人员自助改。把"流程当配置、当可灰度资产"来管理，Agent 系统才具备持续演进的敏捷性。这又把 B30 生产化的主题接上了——编排化本身就是生产化改造里性价比最高的一招。

8.6 动态规划的安全边界与降级

动态编排（LLM 编计划）最危险的是"计划非法或跑飞"。工程上要给三道保险：第一，计划校验前置——引擎解析计划时必须校验白名单工具、必须含节点、步数上限，任一不满足直接走兜底静态流程；第二，执行沙箱化——计划里的工具调用在受限环境跑，禁止越权（呼应 B32 安全对抗）；第三，可中断——长计划支持人工一键暂停 / 接管，避免"模型自己跑了一百步停不下来"。降级策略同样关键：当动态规划连续失败 N 次，自动回退到"人工预设的静态流程"，保证业务不中断，而不是让用户干等模型编计划。这也是 B17 HTN 规划在工程化时的同一组约束——规划能力越强，护栏越要重。能讲清"动态很香但必须配强护栏"，说明你真在生产里用过，而非只在 demo 里炫技。

十补、编排与 B30 生产化的承接收口

收口一句：编排是 Agent 工程里'把灵活变成可控'的那道桥。ReAct 让 Agent 灵活，编排让灵活的 Agent 可信。所有范式、节点、补偿、人工、灰度，最终都服务于一个目标——在享受 LLM 智能的同时，不失去对系统的掌控。这也是 B 系列从 B11 评估一路走到 B34 始终在讲的事：智能体能不能上生产，不取决于它多会聊，而取决于它'在一切都会出错的现实里'是否依然稳、可控、可查、可回。能把编排放进这个大叙事里讲，你的 Agent 认知就立体了。

九、面试速答 + 高频追问清单

面试速答（背下来）：
- 裸 ReAct 三坑：不可控、不可审计、难复用；生产用"显式流程骨架 + LLM 填充血肉"。
- 三范式：状态机（强顺序/审批）、DAG（可并行多步）、事件驱动（异步/跨系统/长时）。
- LLM 嵌流程两种节点：决策节点（Router，需兜底分支）与执行节点（Worker）。
- 人工节点：阻塞等待 + 上下文呈现 + 审计留痕 + 可降级 fallback。
- 错误处理四件套：重试/超时/补偿(Saga)/死信；流程要幂等（B22）。
- 流程上线管理=版本化+灰度+追踪+回滚，Agent 流程即分布式系统。
- 动态编排：LLM 在约束内编计划，引擎校验后调度，非法则走兜底。
- 编排化是生产化性价比最高单招；自研编排引擎多数情况不值得。

高频追问：
1. 什么时候用状态机不用 DAG？答：步骤强顺序、必须按序且要审批，用状态机更可控可审计。
2. LLM 决策节点怎么防乱跳？答：输出归一化+白名单校验+默认兜底分支，自由文本不直接驱状态。
3. 人工节点卡住怎么办？答：超时升级机制+fallback（驳回/转值班），不无限阻塞。
4. 流程失败如何保证不丢不重？答：死信队列防丢，节点幂等设计防重，Saga 补偿已生效步骤。
5. 动态规划和硬编码流程怎么选？答：任务多变无法预定义才上动态规划，且必配强校验兜底。
6. 编排化改造的最大收益？答：一次性补上可控性/可审计性/可回滚性，是生产化性价比最高一招。
7. 为什么不直接用 Airflow 编排 Agent？答：Airflow 为静态批处理设计，不适合运行时成形的对话驱动流程。