智能体与工作流引擎：编排、状态管理与持久化

智能体进入生产，绕不开工作流引擎的老问题

Agent 的原始形态是一个 while 循环：调模型、执行工具、把结果喂回去，直到模型不再发起调用。这个循环在演示里足够优雅，但在生产里立刻撞上工作流引擎领域几十年前就回答过的三个问题：编排——几十个步骤、多个角色、带审批的流程，「接下来做什么」藏在模型决策里，代码里看不见系统的形状；状态——任务要跨请求、跨进程、跨天执行，内存里的变量活不过一次重启；持久化——执行到第 30 步进程崩了，是从头再来还是从断点继续，直接决定长任务是否可行。这三问不是智能体发明的新问题，是所有工作流系统（从 Airflow 到 Temporal 再到 BPM 引擎）的公共课题。智能体工程当下真正发生的，是把模型的不确定性叠加到这套老机制上：编排图里多了「由模型现场决策」的节点，状态里多了「会膨胀的消息历史」，恢复语义多了「重放时模型可能给出不同输出」。本文沿编排形态、状态管理、持久化恢复、既有引擎集成、人机协同编排五个面，梳理当前的工程共识。

编排的三种形态：代码图、可视化画布与声明式 DSL

当前的编排实现收敛成三种形态，各有清晰的能力边界。代码优先的图编排（LangGraph、OpenAI Agents SDK 的 handoff 图、Anthropic Agent SDK）把控制流写成显式的状态图：节点是处理步骤，边是流转条件，图即架构、可版本管理、可单测——代价是学习曲线与样板代码，团队需要建立「图思维」。可视化画布（Dify、n8n、Coze、Copilot Studio）用拖拽表达流程，门槛低、所见即所得，业务人员能上手——代价是表达力受限：复杂条件分支、动态循环、精细错误处理在画布上很快变成蜘蛛网，工程团队最后往往在自定义代码节点里「越狱」。声明式 DSL（YAML 风格，GitHub Actions 与 Airflow 的血统）用配置描述步骤与依赖，运维友好、易审计、天然适合 GitOps 流程——代价是逻辑表达受限，复杂逻辑仍要外挂代码。三个形态正在互相渗透：画布平台拼命增强代码节点与表达式能力，代码框架补可视化调试器（LangGraph Studio 把执行过程画出来），AWS Step Functions 这类老牌编排也开始为 AI 语义加专用节点。选型判断有一条朴素主线：流程由工程师维护选代码图，流程由业务人员维护选画布，流程要过变更审计选 DSL——编排形态的本质是谁拥有流程。

状态管理：共享状态、合并策略与上下文的分工

状态设计是编排里最容易失控的部分。第一个共识是最小充分原则：状态里只放下游节点真正需要的字段，把所有中间产物无脑塞进状态是新手最常见的灾难——状态膨胀拖慢序列化、污染 checkpoint、让调试变成考古。第二个共识是显式声明合并策略：多节点并行执行时，各自对状态的写入按什么规则收拢？覆盖、追加还是按键合并？LangGraph 的 Reducer 机制把这个问题变成了声明式配置（消息列表配追加、标量字段配覆盖），自研编排也应当有等价物，否则并行聚合就是隐式竞态。第三个共识是分层存放：热状态（当前回合的对话与任务上下文）放内存与模型上下文窗口；温状态（任务元数据、中间产物引用）放数据库；冷状态（大文件、完整工具输出）外置对象存储，状态里只存引用指针——把一段 2MB 的网页抓取原文塞进状态字段，是 checkpoint 与上下文窗口的双重灾难。消息历史的膨胀管理值得单独一提：长任务动辄积累几十轮工具调用记录，成熟做法是按策略淘汰与摘要（保系统提示、保最近 N 轮、保关键决策点，中间过程压成摘要），很多「上下文超长」的报错，病根在状态管理而不是模型。

持久化与断点恢复：checkpoint 是长任务的生命线

只要任务可能运行超过一次请求的生命周期，每步落盘的 checkpoint 就是刚需。设计要点有四个。落盘粒度：每个关键节点完成后持久化一次完整状态快照，按线程 ID 组织——粒度太粗恢复时重做太多，太细则序列化开销上升，通常以「一次模型调用加一组工具执行」为一个检查点单元。恢复语义：崩溃后从最近的一致检查点继续，已完成的幂等步骤直接跳过，未完成步骤重新执行——这要求每个步骤尽量幂等，写操作带幂等键（上一批文章反复出现的主题，在这里再次成为恢复正确性的前提）。确定性重放的边界：模型调用重放时输出可能不同，对结果敏感的环节要把检查点级别的产物（模型当次的完整输出）一并落盘，恢复时复用产物而不是重新生成。时间旅行与调试：检查点让「回退到第 10 步换个决策重跑」成为标准操作，这既是调试利器（复现问题现场），也是运营能力（用户否决了某个方案后从那个点重来）。存储选型上，单机与原型用 SQLite，生产用 Postgres，高频并发场景叠加 Redis 缓存热检查点；无论哪种，都要配套检查点的清理与压缩策略——一个跑半年 Agent 平台的检查点表，比业务表先撑爆磁盘是常见事故。

与既有工作流引擎的集成：别急着自研，先看看 Temporal

智能体编排与既有工作流基础设施的结合，2025 年以来出现了一条清晰路线：把 Agent 步骤当作持久化执行引擎里的活动。Temporal 是这条路线的代表——它的持久化执行思想（代码即工作流，框架自动记录事件历史，故障后重放事件恢复现场）与智能体的长任务需求严丝合缝：Agent 的一整个多小时任务在 Temporal 里是一个 Workflow，模型调用与工具执行是 Activity，活动天然带重试策略与超时，Worker 崩溃后事件重放自动恢复，人审批这类长等待用 Signal 挂起而进程零占用。国内字节的 Coze Studio 开源版、不少企业内部平台都走了类似路线。与 Temporal 对比，专门为 Agent 设计的 LangGraph 类框架的优势在模型侧语义（消息流、reducer、token 级流式），劣势在分布式执行的基础设施厚度（任务队列、Worker 调度、版本迁移）。选型上的实用判断：团队已有 Temporal/Cadence 基础设施，把 Agent 嵌进去，编排层复用存量运维能力；从零起步且核心是 Agent 语义，选 LangGraph 类框架，但要把持久化后端直接配生产级存储，别用内存实现上线。事件总线（Kafka、Redis Stream）在多智能体场景是第三条路：智能体之间通过事件解耦，谁也不直接调谁，天然获得削峰、重放与审计——代价是链路追踪与端到端调试变难，需要配套的追踪上下文传播。

人机协同的编排位：审批节点与异步等待

生产级智能体流程几乎都需要人工介入位：高危操作前审批、模型产出后校对、歧义处向用户求证。编排层把人机协同做成一等公民有三个要点。第一，等待必须持久化：人审批可能过夜甚至过周，「同步等人」的线程挂起实现是灾难——正确做法是中断并把状态落盘（LangGraph 的 interrupt、Temporal 的 Signal 都是为此设计），审批完成事件到达后从断点恢复，等待期间不占任何计算资源。第二，审批要有升级与超时路径：请求悬置 24 小时未处理自动提醒，72 小时自动升级给上级或自动按预设策略处理（放行、拒绝或转人工全量执行），否则流程会死在审批队列里。第三，介入点要在图上显式可见：审批节点是流程的一部分，画在图上、计入耗时统计、写进审计日志，而不是藏在某个工具的实现细节里——这决定了流程审计时「谁在什么时候批准了什么」能否被回答。人机协同位的设计水平，是区分「玩具编排」与「企业编排」最灵敏的一根指标线。

执行可观测性：编排层的追踪与回放

编排框架要为整个执行链路提供观测能力，这是运维与调试的共同地基。结构化执行历史：每个节点的输入、输出、耗时、token 消耗与错误信息按执行 ID 落库，配合 OpenTelemetry 的 GenAI 语义约定可以把整条链路的 span 串起来——一个任务失败后，工程师要能在分钟级定位「卡在哪个节点、输入是什么、为什么错」，而不是翻日志考古。成本归因：编排层天然掌握每个节点的模型调用明细，按任务、租户、节点维度聚合 token 与费用，是成本治理的数据底座——没有编排层的归因，「这个月 Agent 账单为什么涨了三倍」这类问题无法回答。回放与差异比对：执行历史让「同样的输入重跑一遍」成为一键操作，配合版本管理还能做「改了提示词后同一批历史任务的重放对比」——这是提示词迭代最可靠的验证手段，比凭感觉评估强一个量级。三个能力的实现成本都不高（编排框架本来就经过每个节点），省掉它们的代价会在第一次线上事故时一次性付清。

flowchart LR
    A["任务启动"] --> B["节点执行 模型调用与工具"]
    B --> C["状态按 Reducer 合并"]
    C --> D["写入 checkpoint 落盘"]
    D --> E{"下一步是什么"}
    E -->|"条件边路由"| B
    E -->|"需要人工审批"| F["中断 状态持久化 等待审批"]
    F -->|"审批通过 事件恢复"| B
    F -->|"超时升级"| G["自动策略或上级接管"]
    E -->|"进程崩溃"| H["从最近 checkpoint 重放"]
    H --> B
    B --> I["任务完成 归档状态"]

小结

智能体与工作流引擎的关系，本质是新负载与老基础设施的融合：模型的不确定性被叠加到编排、状态、持久化这套几十年打磨的机制上，而不是推翻它。工程要点收敛为五条：编排形态按「谁拥有流程」选，代码图给工程师、画布给业务、DSL 给审计；状态遵循最小充分与显式合并策略，热温冷分层存放，消息历史要有淘汰与摘要机制；长任务以 checkpoint 为生命线，落盘粒度、恢复语义、产物复用与清理策略四个设计点缺一不可；已有 Temporal 类持久化执行引擎的团队优先复用，别急着自研调度；人机协同做成图上一等公民，等待持久化、审批有升级路径、介入点可审计。一个务实的判断：2026 年这个时间点，自研一套完整编排引擎已经不是明智选择——问题不再是「有没有轮子」，而是「选哪个轮子、以及如何避免被框架绑死」。编排层选型的真正风险不是功能不足，而是迁移成本，所以越是核心流程，越要把业务逻辑写在框架无关的纯函数里，把框架当作可替换的执行外壳。