从 Loop 到 Graph：为什么 Agent 工作流本质上是状态机

这两年做 AI Agent 的人几乎隔一阵子就会换一个说法。先是chain然后是loop现在又轮到graph。看起来像是范式升级实际上很多时候只是把同一件事换了个名字。这件事就是有限状态机Finite State Machine, FSM。如果你把一个系统里“当前处于什么状态”“发生了什么事件”“接下来应该去哪里”这三件事单独拎出来看你会发现很多工作流框架最后都在逼近同一个结构。这不是学院派的抽象游戏而是一个非常务实的工程结论。因为一旦你把控制流显式建模成状态机很多原本靠经验、注释和补丁维持的复杂逻辑就会变得可枚举、可测试、可恢复。先把核心问题讲透状态机只回答一个问题在当前状态下发生某个事件后系统应该进入哪个下一个状态写成函数就是transition几乎所有程序都在做这件事。• React 组件会根据当前状态和用户动作更新 UI• 后端服务会根据请求结果决定成功、失败还是重试• 游戏循环会根据输入和碰撞事件切换行为• AI Agent 会根据工具结果、评估结果和人工反馈继续执行、重试、暂停或结束也就是说程序天然就有状态机的形状。差别只在于你是把这套逻辑显式写出来还是让它散落在各个if、回调和布尔变量里。为什么很多系统会失控看一个最常见的前端例子letfalselet falselet falselet nullletnull乍看很正常但问题马上就来了。3 个布尔值会产生2^3 8种组合可真正有意义的状态可能只有 3 种。于是像isLoading isError这种组合在语义上根本说不通却完全可能在竞态条件下出现。这就是很多线上诡异 bug 的来源• 加载中转圈还没消失错误提示已经弹了• 成功态的数据还在页面上失败态的 toast 又叠了一层• 用户双击提交后两个请求同时跑起来本质原因不是“你防守不够严”而是你的状态表示方式允许不合法状态存在。如果改成typeStateidleloadingsuccessfailure那“既在 loading 又在 error”这种状态根本写不出来。这就是函数式编程里常说的那句话Make illegal states unrepresentable.状态机最有价值的地方不只是“组织代码更清晰”而是它能把一整类矛盾状态直接从模型层面删掉。状态机带来的两个硬约束一旦你显式建模立刻得到两个非常强的保证系统任意时刻只处于一个明确状态系统只能沿着你定义过的转移路径移动第二点尤其重要。在散乱的 flag 代码里任何事件处理器都可能随时改动任意东西但在状态机里如果当前状态没有定义某个事件的转移那这个事件就什么都做不了。这意味着很多“补救型工程技巧”会自然消失。比如用户双击提交按钮• 第一次SUBMITidle - loading• 第二次SUBMIT此时还在loading• 因为loading没定义SUBMIT第二次事件直接无效于是你不需要额外再发明一个isSubmitting来兜底也不需要手搓 debounce 才能避免重复提交。最朴素的状态机实现最简单、也最干净的方式就是把转移逻辑当成数据表constinitialidlestates idleFETCHloadingloadingRESOLVEsuccessREJECTfailureCANCELidlesuccessREFETCHloadingfailureRETRYloadingfunctiontransitionstate,event returnstates这个实现有几个非常实在的好处• 行为全集能在一个地方看全• 代码评审时diff 直接对应行为变化• 规则可以序列化、存库、网络传输甚至自动画图• 测试可以把“状态 × 事件”的有限表完整遍历一遍当你的系统能被枚举测试方式就会从“抽样碰碰运气”变成“系统性穷举”。真正的程序为什么还能叫“有限”状态机很多人第一次接触 FSM 会卡在这里现实系统里还有表单内容、时间戳、数组、计数器这些怎么可能是有限的答案是把状态拆成两层•有限状态系统处于哪种模式比如idle、loading、editing•上下文context和模式同行的具体数据比如输入值、重试次数、拉取结果于是转移函数从transition扩展成transition比如失败后允许最多重试 3 次functiontransitionstate,ctx,eventiffailuretypeRETRYifretries3returnloadingretriesretries1fetchreturngaveUpnotifyUser这里顺手带出三个很重要的概念•Guard守卫条件决定同一个事件在不同条件下走哪条边•Action副作用描述状态机负责决定“应该做什么”真正执行动作的是外部解释器•Entry/Exit Action进入或离开某个状态时统一触发的行为比如进入 loading 开 spinner退出 loading 统一清理 timer这套设计的妙处在于控制流和副作用被拆开了。也正因为如此状态转移函数可以保持纯净测试时不需要一堆 mock。这和 Agent Graph 有什么关系关键就在这里。一个 Agent Graph本质上就是在描述• 当前处于哪个节点• 收到什么结果或信号• 下一步跳到哪里把它翻译成状态机语言就是• 节点 S• 事件 Σ• 边 δ• 起点 s0• 终点 F也就是说graph 并没有摆脱状态机它只是把状态机画出来了。一个很典型的 Agent 工作流可能长这样constinitialplanningstates planningPLAN_READYexecutingNEEDS_INFOawaitingHumanexecutingTOOL_RESULTevaluatingTOOL_ERRORexecutingBUDGET_EXCEEDEDfailedevaluatingVERIFIEDdoneNOT_GOOD_ENOUGHplanningUNSAFEawaitingHumanawaitingHumanAPPROVEDexecutingREJECTEDfailedCLARIFIEDplanningdone failed这就是一个标准状态机只不过现在大家更喜欢叫它“agent graph”。为什么这对 Agent 尤其重要Agent 和普通程序相比有两个额外麻烦模型输出本身是不稳定的工作流经常需要长时间运行、暂停、恢复、人工介入显式状态机刚好能处理这两个问题。1. 不要让模型直接控制流程如果你把“是否结束”“是否安全”“是否要重试”直接交给模型自由发挥系统很容易出现一种经典事故任务其实没完成但模型说自己完成了。状态机的做法不是让模型直接决定下一步而是先把模型输出归类成事件比如•VERIFIED•NOT_GOOD_ENOUGH•UNSAFE然后再由状态机检查这个事件在当前状态下是否有合法转移模型可以胡说但胡说出来的事件如果没有合法边就不会改变系统状态。这比“把规则写进 system prompt 里希望模型听话”可靠得多。2. Retry 逻辑终于能被结构化表达很多 agent loop 之所以失控是因为重试逻辑只是一个while加计数器靠人记得在合适的时候停。如果改成状态机重试就是一条带 guard 的边•evaluating - planning前提是attempts maxAttempts这样一来死循环不是“希望不要发生”而是模型结构上就不允许无限发生。3. 长任务可以自然持久化一个等待人工审批 3 天的 agent不需要整个进程一直活着。你只要把下面这对值存起来(currentState,context)等审批 webhook 到了再把它恢复出来继续跑就行。这也是为什么很多工作流引擎比如 Temporal、AWS Step Functions会天然跟状态机思路靠得很近。状态机不是万能钥匙也别走到另一个极端。以下情况就不一定值得上状态机• 纯顺序流程A 跑完接 BB 跑完接 C中间没有等待、分支、失败恢复• 连续数值系统比如物理模拟、数值求解• 简单到只需要一个二元开关的场景一个很实用的判断信号是当你代码里出现第二个会互相影响的布尔变量或者开始写“只有当前处于某种状态时才能……”这种注释时基本就该考虑状态机了。进一步扩展为什么还会有 statechart平面状态机也有自己的扩展性上限。比如一个编辑器里bold、italic、underline都能独立切换。如果你硬把它们全部拍平成状态很快就会组合爆炸。这时就会进入statechart的世界在普通状态机基础上引入层级、并行区域和历史状态。这部分可以展开很多但对大多数工程实践来说记住一句就够了statechart 不是推翻状态机而是给大状态机做压缩和组织。所以无论是 UI 框架、工作流引擎还是 Agent orchestration library只要开始认真处理复杂控制流最后大概率都会朝这个方向靠。最后的判断标准以后再看到新的工作流框架、agent runtime 或 orchestration 抽象其实可以只问三个问题它有没有清楚定义状态它有没有清楚定义事件它有没有清楚定义转移如果这三件事都能回答清楚那它大概率只是一个状态机的变体值得你用工程方法去分析、测试和验证。如果回答不清那往往只是把控制流重新打散再换一套营销语言包装出来。AI Agent 领域现在从 loop 走向 graph看起来像升级但从计算机科学的视角看更像是大家终于开始重新发明那个几十年前就已经很好用的轮子。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】