智能体图架构与状态机编排（Graph / State-Machine Agent Architecture）

早期的智能体多半写成一个 while 循环：调用模型、执行工具、把结果喂回，直到结束。这种隐式循环在研究和演示里够用，但一旦进入生产，控制流不可见、状态散落在局部变量里、出错后无法从断点续跑，调试与审计都很困难。图架构（Graph Architecture）把控制流显式化为有向图：节点是执行步骤（调用模型、执行工具、更新记忆），边是转移（固定跳转或基于状态的条件跳转），状态是一个显式声明的模式（Schema），每次节点读取状态并回写更新。典型代表是 LangGraph，它把智能体建模为带循环的「状态图」，并把检查点、人机协同、时间旅行作为内建能力。

这种范式与编排者—工作者模式并不冲突，而是关注点不同：后者回答「任务由谁来做」（拆解与分发），图架构回答「控制流如何显式、状态归谁所有、何时能暂停」。许多生产系统把两者叠用——先用编排者拆出子图，再用图来固化每个子图的控制流。

状态成为系统记录是图架构最关键的心态转变。检查点（checkpointer）在每一步之后把通道状态快照写入外部存储（如 SQLite、PostgreSQL、Redis），崩溃后可从最近检查点恢复，无需重跑已完成的模型调用与副作用。由此自然派生两个能力：其一是暂停—恢复，智能体可以停在某个节点（例如「发送邮件前」）等待人工审批，之后携带同一线程状态续跑；其二是时间旅行，任意历史检查点都能作为起点重新加载，便于回放与分叉调试。

人机协同在图架构里是编译期的一等原语而非后加的补丁：开发者把某个节点标记为中断点，运行到该节点时执行停止并把完整状态落盘，人工给出输入或编辑状态后，用同一线程编号再次调用即可从断点继续。这种「提案—门控—续跑」的结构，是生产级智能体可控性的基础。

图架构与编排者—工作者模式、智能体运行外壳、托管运行时构成一套互补的范式谱系。编排者—工作者解决「拆解与分发」，运行外壳解决「单步循环如何跑起来」，托管运行时把这套执行层整体服务化，图架构则专门解决「长任务的控制流如何显式、状态如何持久、如何可审计」。在实践中，一个企业级智能体往往是「图作为骨架、编排作为调度、外壳或托管运行时作为底座」的组合。

落地图架构时，状态模式只放真正重要的字段，避免状态膨胀拖慢检查点与调试；对列表类字段用归约器（reducer）累积而非覆盖；用线程编号隔离多路会话；把条件边要用的路由信号显式放进状态。可观测性要尽早接上：把每一次图执行当作完整追踪来记录节点耗时、模型输入输出与工具调用，并把生产运行沉淀为评测数据集，做到每次图更新都有回归测试。

图架构不是银弹。它的前期成本在于必须显式声明状态、节点与边，对简单线性链路反而啰嗦；状态对象过大（如完整对话历史、内嵌文档）跨多次检查点会推高存储与内存开销。另一条批评是：把控制流硬编码成图，可能削弱模型自主编排的灵活性——当任务难以预先画成图时，纯图方案会遇到表达力瓶颈。业界的一般建议是：循环、分支、回退、人机门控多的长任务用图，简单一次性问答仍用轻量链路。

图架构正从「框架特性」走向「智能体操作系统的内建原语」：更多运行时把状态持久化、人机门控、时间旅行作为默认能力而非可选配置。值得跟踪的方向包括：检查点存储向列式与增量演进以压低成本、状态模式与可观测性的标准化、以及图与模型自主编排之间的边界如何被重新划分——当模型本身更会规划时，显式图的角色可能从「规定流程」退化为「兜底护栏」。