Agent不是多想几步就能上线：用状态机管住自动行动
内容提要
文章以AWS自动补货方案为例，指出生产级Agent不能只依赖模型多步推理，而应用状态机将AI推理与系统执行分离。状态机由状态、事件、转换规则和终止状态组成，可限制非法跳转、暴露进度、支持失败恢复，并配合幂等键防止重复下单。模型仅提出事件候选，经程序校验后才改变状态。该方案适合退款、采购等有限流程，不适合开放式研究。
延伸解读
状态机为何是生产级Agent的必需品
文章以AWS自动补货方案为例，指出Agent直接调用工具不等于适合操作生产系统。状态机通过定义有限状态和合法转换，限制非法跳转，让进度可见，并支持失败恢复。模型仅提出事件候选，程序校验后才改变状态，从而将AI的“想”与系统的“做”分离。这种分层设计能避免模型用自信回答掩盖异常，适合退款、采购等有限流程。
幂等键：防止重复副作用的最后防线
当Agent执行下单、支付等真实副作用时，重试可能导致重复操作。文章强调必须使用幂等键，确保同一请求即使因重试到达两次，也只产生一次订单。示例中，相同SKU和批次生成同一幂等键，避免重复执行。此外，失败后不能直接重跑整个Agent，而应先用幂等键查询，确认外部动作是否已成功。
人工审批不是安全按钮，状态设计才是
文章指出，有人工审批不等于安全。如果审批页面不展示金额、来源和将调用的工具，人只是盲点按钮。状态机应记录操作者与原因，便于追责和回放。同时，状态名称应描述业务事实，如REJECTED、EXPIRED、FAILED_RETRYABLE，而非“模型觉得可能失败”这类不可验证的句子。只有状态设计清晰，人工介入才有意义。
状态机的适用边界：有限流程与开放式任务
状态机适合步骤有限、状态可枚举、动作有明确副作用的流程，如退款、采购、发布和工单流转。但它不适合穷举开放式研究的每个思考分支。对于开放式任务，可让模型自由探索，但在下载、发信、付款等边界重新接入状态机。部署时，状态应持久化到数据库或工作流引擎，而非仅留在模型上下文，以便进程重启后继续。
Q&A
生产级Agent为什么不能只靠模型多步推理？
因为模型推理可能被自信回答掩盖异常，且无法保证外部动作的安全。文章指出，生产级Agent应使用状态机将AI推理与系统执行分离，由程序验证转换是否合法，从而限制非法跳转、暴露进度并支持失败恢复。
状态机由哪些部分组成？
状态机由状态集合、事件集合、转换规则和终止状态组成。Agent可以建议下一个事件，但程序负责验证转换是否合法。
在自动补货场景中，状态机如何防止重复下单？
通过幂等键：同一SKU和批次生成同一幂等键，即使请求因重试到达两次，也只能产生一次订单。文章示例中，可执行状态时生成幂等键并进入终态。
状态机适合哪些类型的流程？不适合哪些？
适合步骤有限、状态可枚举、动作有明确副作用的流程，如退款、采购、发布和工单流转。不适合用状态机穷举开放式研究的每个思考分支；那类任务可让模型自由探索，但在下载、发信、付款等边界重新接入状态机。
部署状态机时需要注意什么？
需要把状态存进数据库或工作流引擎，而不是只留在模型上下文。进程重启后，程序应从持久化状态继续；多人审批时，应使用版本号或事务避免两个人同时推进同一任务。模型输出只是事件候选，只有通过校验的事件才能真正改变状态。每次转换还应记录操作者与原因，便于追责和回放。
关于状态机有哪些常见误区？
误区一，把模型的自然语言计划当状态；误区二，认为有人工审批就安全，但审批页面不展示关键信息时人只是盲点按钮；误区三，失败后直接重跑整个Agent，而外部动作可能已成功；误区四，把所有异常都交给模型自我修复；误区五，只记录成功终态，忽略REJECTED、EXPIRED和FAILED_RETRYABLE等状态。
