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」,一起看懂技术变化背后的真正机会。
本文首发于 java4u.cn,转载请注明出处。

