Workflow / 状态机让 Agent 从“能跑”变成“可控运行”一、介绍1. 什么是 Workflow / 状态机在 Agent 设计中Workflow / 状态机是一类非常“工程化”的范式。可以用一个直观的对比来理解ReAct边查边想Plan-and-Execute先规划再执行Workflow / 状态机先把流程图画清楚再按规则运行它的核心目标不是让模型更自由而是让系统更可控、更稳定、更可审计。2. 为什么企业场景特别需要它很多真实业务本质上就不是“自由发挥”的问题而是标准流程问题比如有固定步骤有审批节点有异常分支有状态流转有明确的进入和退出条件例如报销审批工单处理订单流转故障处理发布流程这些场景的共同特点是流程本身比模型能力更重要。如果没有明确的流程约束即使模型很强也可能出现跳步骤重复执行在错误阶段做错事高风险操作没有拦截中断后无法恢复无法追溯执行过程Workflow / 状态机就是用来解决这些问题的。3. Workflow 和状态机的区别简单但关键这两个概念经常一起出现但关注点略有不同Workflow流程编排关注“事情怎么走”步骤顺序并行 / 串行关系重试机制人工审批点更像流程图、任务编排图状态机State Machine关注“对象怎么变”当前处于什么状态什么条件可以进入下一个状态哪些动作在哪些状态才允许发生哪些是终态、异常态更像订单状态、工单生命周期一句话总结Workflow 关注“流程”状态机关注“状态”。在 Agent 系统中两者通常是结合使用的。4. 优缺点放在介绍里更直观优点可控性强不会乱跑易审计每一步都有记录易测试路径是确定的支持失败恢复从状态继续易接入权限控制和人工审批适合多人协作和系统集成尤其在高风险操作中比如付款、删数据、发通知优势非常明显。缺点前期设计成本高流程设计过细会变得僵硬对变化快的任务适应性较差状态一多维护复杂度上升不适合强探索型问题可以总结为它用“控制力”换“灵活性”。二、核心原理1. 把 Agent 从“生成文本”变成“状态驱动系统”这种范式的核心变化是Agent 不再是连续生成文本而是按结构化规则推进。一个最小模型通常包含State状态当前在哪个阶段Event事件触发变化的条件Transition转移状态如何变化Action动作进入状态后执行什么Guard条件是否允许转移可以抽象为当前状态 触发事件 条件判断 → 下一个状态 → 执行动作2. 和 ReAct 的本质区别两者最大的差别在于“决策权”ReAct每一步更依赖模型临场决定状态机每一步更多由预定义规则约束换句话说ReAct 问的是“接下来我该做什么”状态机问的是“我现在在哪个状态”三、两个典型例子1. 报销审批 Agent标准状态机状态定义draftsubmittedmanager_approvedfinance_reviewingpaidrejected状态流转draft → submitted → manager_approved → finance_reviewing → paid↘ rejected每个状态可以绑定动作submitted通知主管审批finance_reviewing校验发票paid发送打款通知rejected生成退回原因这里的关键是模型不能跳状态也不能越权操作。2. 客服工单 Agent更典型的 Agent 场景状态可能包括newclassifyingwaiting_for_userresolvingescalatedclosed流程大致是新工单进入系统自动分类信息不足则等待用户补充可自动解决则处理超出能力则升级人工最终关闭这种设计带来的好处是只有特定状态允许特定动作已关闭的工单不会被再次处理升级后的工单不会被 AI 擅自处理这在企业系统里非常关键。四、实践建议与常见坑1. 状态必须“工程化存在”一个非常关键但常被忽略的点状态不能只存在于 prompt 里必须持久化到系统中。否则你得到的不是状态机而只是“模型自以为记住了状态”。真正的状态机应该是可查询可恢复可审计可回放2. 常见设计坑下面这些问题在实践中非常常见1状态和动作混在一起状态应该表示“阶段”而不是“做了什么”。❌ 错sending_email✅ 对pending_notification2转移条件模糊如果没有明确条件系统会变得不可预测。3没有异常分支只设计“成功路径”忽略失败和中断。4没有超时和重试机制现实系统一定会有失败需要设计恢复路径。5没有人工接管入口高风险或复杂场景必须允许人介入。6状态过多或过细会导致系统难以维护。3. 一个最小状态机示例可以用一个简化代码理解state newwhile state not in [closed, rejected]:if state new:classify_ticket()state classifyingelif state classifying:if info_missing():ask_user()state waiting_for_userelif can_auto_resolve():state resolvingelse:state escalatedelif state waiting_for_user:if user_replied():state classifyingelif state resolving:resolve_issue()state closedelif state escalated:handoff_to_human()break这里的核心思想是不是一直问“下一步做什么”而是先判断“当前在哪个状态”。