问题不是会不会调用工具，而是任务能不能留下状态

短任务可以靠一次模型调用解决，长程 Agent 不行。它会读材料、拆步骤、调用工具、等待外部系统、收到人类反馈，再继续执行。只要任务跨过一次等待，系统就必须知道它停在哪里。

这就是为什么生产 Agent 需要任务状态机。job 负责描述完整目标，step 负责记录当前动作，checkpoint 负责保存中间状态，handoff 负责把控制权交给另一个 agent 或人。没有这些对象，所谓长程执行只是把一次聊天拉长。

四个公开系统都在暴露同一件事

OpenAI Agents SDK 把工具、guardrails、handoff 和 tracing 放进同一套开发体验。LangGraph 强调 stateful orchestration、持久执行和 human-in-the-loop。Microsoft Agent Framework 也在把 agent、workflow 和企业应用开发收在一起。AWS AgentCore 则把运行时、身份和工具接入放到云服务语境里。

它们的产品形态不同，但共同点很明确：Agent 不再只是一个回答器，而是一段需要被调度、恢复、观测和治理的任务过程。

状态机应该先定义失败语义

设计状态机时，最容易漏掉的是失败。很多团队只设计 happy path：任务开始、工具调用、产出结果。真正上线后，麻烦来自工具超时、权限不足、上下文过期、审批未回、输出不可信和预算耗尽。

所以状态机至少要区分四类失败：可自动重试、需要补充信息、需要人类批准、必须终止回滚。每一类失败都应该有不同状态，而不是统一塞进 error。

第一版可以很小，但字段必须硬

第一版不需要复杂平台。一个能用的 Agent task record 至少要有 goal、owner、input snapshot、current step、checkpoint、tool events、approval status、cost budget、risk class 和 final artifact。

这些字段让团队能回答三个问题：现在做到哪一步，为什么停住，谁有权继续。回答不了这三个问题，Agent 越能干，团队越不敢把关键任务交给它。