智能体面试准备三十四智能体编排与流程引擎实战——从硬编码脚本到可控流程本篇是 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 节点通常两种形态决策节点RouterLLM 根据上下文选下一跳转人工 or 自动回复。要设兜底默认分支防止 LLM 选了不存在的分支。执行节点WorkerLLM 在固定步骤里做生成/抽取/调用输出喂给下一步。# 一个 DAG 节点的伪代码含 LLM 决策 兜底defroute_node(state):decisionllm_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 可控有约束、可解析、可审计比纯硬编码灵活计划按需生成。代价是计划解析 校验的工程复杂度。planllm_plan(user_goal,toolsWHITELIST,constraintsCONSTRAINTS)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 判断节点就够了别硬上图引擎。第二档多步可并行、有依赖用 DAGLangGraph / 自建图调度适合先查多个源再汇总的分析型 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变化大→动态规划或 ReAct2有没有必须人工把关的节点有→必须把人编进流程奔着显式编排去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 为静态批处理设计不适合运行时成形的对话驱动流程。