Lesson 0002 · 约 15 分钟

Agent Runtime 控制什么

本课把“模型不可靠”变成可以实现和评审的系统合同。完成后，你应该能为模型、Runtime、策略和工具划清责任。

模型不是 Agent 进程

模型调用是一次无状态计算：接收当前上下文，返回文本或结构化动作。真正让 Agent 持续运行的是 Agent Runtime：它维护任务状态、调用模型、校验动作、执行工具、写入观察，并决定继续、暂停还是停止。

模型提出下一步；Runtime 决定这一步是否允许、如何执行，以及执行后系统处于什么状态。

OpenAI Agents SDK 的 run loop 会反复调用模型、处理 tool call 或 handoff，并受 turn limit 等运行配置约束。这些都是 Runtime 责任，而不是模型能力。查看运行生命周期。

用退款 Agent 看清边界

用户说：“把订单 A123 的 1,280 元退给我。”一个合理的系统不会把这句话直接变成支付接口调用。

读取事实Runtime 从订单系统读取金额、状态和用户身份
提出动作模型建议退款，并给出原因与所需参数
策略门禁超过 1,000 元，Runtime 将任务暂停等待审批
幂等执行审批后用稳定 action id 调用退款工具
确认结果根据支付凭证更新状态，而非相信模型描述

模型负责语义判断；Runtime、策略和工具共同控制真实副作用

“不可靠”具体指什么

非确定性

相同输入可能产生不同动作。对策是有限 action schema、参数校验和 turn budget，而不是期待 prompt 永远生效。

输入不可信

网页、邮件和工具结果可能包含 prompt injection。对策是把数据与权限分离，并在执行侧重新授权。

没有事务语义

模型不知道超时的退款是否已经发生。对策是 action id、幂等 API、状态查询、对账与补偿。

自报成功无效

模型说“已完成”不是证据。成功必须由支付凭证、数据库状态或其他外部判定器确认。

Runtime 的六个合同

  1. 事实源：结构化任务状态在 Runtime 中；prompt 只是为本轮构造的视图。
  2. 动作：模型只能提出有限、带类型、可校验的 action proposal。
  3. 策略：权限、风险、预算和审批在动作执行前强制检查。
  4. 副作用：写操作必须幂等，或具有补偿、确认和人工恢复路径。
  5. 生命周期：明确 done、failed、paused、cancelled、timeout 和 turn limit。
  6. 恢复：在关键边界保存检查点，重启后不能重复已经成功的动作。

LangGraph 的 durable execution 文档把持久化、恢复、确定性重放和副作用封装放在同一问题下；AWS 关于幂等 API 的文章则解释了为什么重试必须携带稳定的请求标识。阅读持久执行，阅读幂等重试。

失败时，先分类再处理

模型选错工具是语义失败，可以通过上下文、提示、模型或评测改进；网络超时是操作失败，应该由 Runtime 有界重试；“超时但可能已经退款”是未知结果，绝不能直接重试，必须先按 action id 查询或对账。

重试只解决瞬时失败。未知结果下盲目重试，可能把一次故障变成两次扣款。

责任归属练习

问题 1：谁决定 1,280 元退款必须经过人工审批？

问题 2：谁为退款动作生成可重试的稳定 action id？

问题 3：下面哪项最适合交给模型负责？

本课主阅读

OpenAI Agents SDK: Running agents。阅读时找出 run loop 的停止、handoff、tool call 和 turn limit 分别由谁控制。

完成后，请不用“模型不可靠”这句概括，直接说明：退款 Agent 为什么需要 action id、策略门禁和外部成功凭证。也可以把你熟悉的一个 Agent 场景代入这六个 Runtime 合同。