Agent会调用工具，不等于它适合直接碰订单、邮件和生产系统。AWS在9月14日发布自动补货方案：模型预测需求，Agent发现激增，流程核对供应商，常规情况自动下单，规则不匹配就交给人。读懂它，你会掌握一个长期有用的基础概念——用状态机把AI的“想”和系统的“做”分开。

最新事件里真正值得学的东西

这套方案用Chronos-2预测未来7天需求；Databricks Genie Agent找出预测均值至少为过去14天1.5倍、且历史均值不低于1的商品；Amazon Quick再读取供应商数据，选择能覆盖需求的最低价供应商，通过API（应用程序编程接口）下单。没有单一供应商满足条件时，流程创建人工复核任务。

亮点不是“AI自己买货”，而是每一步都有输入、规则和退出条件。外部动作只发生在前置状态已经确认之后，异常不会被模型用一句自信回答掩盖。

状态机解决什么问题

状态机把流程表示为有限状态和允许的转换。例如订单只能从“已检测”到“已决策”，再到“待审批”或“可执行”；不能从“刚收到预测”直接跳到“已下单”。它解决三个问题：让当前进度可见、限制非法跳转、让失败后知道从哪里恢复。

可以把它类比成机场登机：值机、安检、登机口核验都有明确状态，缺一步就不能上飞机。类比的边界是，软件状态机还要处理并发、重复消息和外部API失败，不是排队走完步骤就必然成功。

准确地说，状态机是一个由状态集合、事件集合、转换规则和终止状态组成的模型。Agent可以建议下一个事件，但程序负责验证转换是否合法。若执行会产生真实副作用，还需幂等键：同一请求即使因重试到达两次，也只能产生一次订单。

最小实践

下面用纯Python模拟补货状态机，不需要第三方依赖或密钥。保存为workflow.py，运行python3 workflow.py。金额超过1000元时进入人工审批；相同SKU（库存保有单位）和批次生成同一幂等键，避免重复执行。

from dataclasses import dataclass
from hashlib import sha256

@dataclass
class Job:
    sku: str
    batch: str
    amount: int
    state: str = "DETECTED"

def advance(job: Job, approved: bool = False) -> str:
    if job.state == "DETECTED":
        job.state = "NEEDS_REVIEW" if job.amount > 1000 else "READY"
    elif job.state == "NEEDS_REVIEW" and approved:
        job.state = "READY"
    elif job.state == "READY":
        key = sha256(f"{job.sku}:{job.batch}".encode()).hexdigest()[:12]
        job.state = f"EXECUTED:{key}"
    return job.state

job = Job("SKU-42", "2026-09-17", 1800)
print(advance(job))
print(advance(job, approved=True))
print(advance(job))

第一段定义业务字段与初始状态。第二段只允许三条转换：检测后按金额分流、人工批准后进入可执行、可执行时生成幂等键并进入终态。最后三行演示高金额订单依次得到NEEDS_REVIEW、READY和带键的EXECUTED。本次任务已在Python 3实际运行，输出符合上述顺序。

至少三个常见误区

误区一，把模型的自然语言计划当状态。计划会改写，状态必须由程序持久化。误区二，有人工审批就安全；如果审批页面不展示金额、来源和将调用的工具，人只是盲点按钮。误区三，失败后直接重跑整个Agent；外部动作可能已成功，只是响应丢失，必须先用幂等键查询。误区四，把所有异常都交给模型自我修复；权限、预算和合规冲突应进入确定性拒绝或人工队列。

还有一个常见误区是只记录成功终态。生产系统同样需要REJECTED、EXPIRED和FAILED_RETRYABLE等状态，否则运维人员只能从日志猜测任务究竟在等人、已过期还是可以安全重试。状态名称应描述业务事实，不要写成“模型觉得可能失败”这类不可验证的句子。

适用与不适用

它适合步骤有限、状态可枚举、动作有明确副作用的流程，如退款、采购、发布和工单流转。不适合用状态机穷举开放式研究的每个思考分支；那类任务可让模型自由探索，但在下载、发信、付款等边界重新接入状态机。

部署时还要把状态存进数据库或工作流引擎，而不是只留在模型上下文。进程重启后，程序应从持久化状态继续；多人审批时，应使用版本号或事务避免两个人同时推进同一任务。模型输出只是事件候选，只有通过校验的事件才能真正改变状态。

每次转换还应记录操作者与原因，便于追责和回放。

我的判断与5分钟实践题

我的判断是，生产Agent的竞争力不只来自模型智力，而来自“自由推理、确定执行”的分层。模型负责理解模糊目标，工作流负责预算、权限、审批、重试和终态。越接近真实世界副作用，越应该让后者占主导。

5分钟实践：给示例增加REJECTED终态；当approved=False且审核已明确拒绝时进入该状态，并保证之后任何调用都不能变成READY。再写两个断言：被拒任务不执行；同一SKU和批次的幂等键保持一致。

你的业务里，哪一种Agent动作必须在执行前停下来等人确认？

关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。