OpenAI Agents API 与 Agents SDK 区别：如何选择？
API、SDK 和 Responses，究竟改变应用的哪一部分？
| 决策 | Agents API | Agents SDK | 直接使用 Responses API |
|---|---|---|---|
| 谁运行编排？ | OpenAI 托管服务 | 你的应用运行 SDK | 应用或已有工作流引擎 |
| 持续执行的工作记录在哪里？ | 托管会话，再关联业务任务 | 自选的会话与状态存储集成 | 工作流记录，加上实际使用的 API 状态能力 |
| 业务工具怎样执行？ | 函数工具仍由应用处理 | SDK 工具与应用代码集成 | 自己的调度逻辑处理客户端工具 |
| 主要工程取舍是什么？ | 少维护运行时，接受外部服务边界 | 控制运行时，同时承担部署责任 | 直接组合能力，明确管理工作流 |
| 更换运行时后什么能保留？ | 你在服务之外有意保存的可迁移记录 | 独立维护的业务记录和适配层 | 保留的业务记录与工作流契约 |
最后一行是架构建议。任何产品标签都不能保证可迁移性。一个工具函数可以复用，但待执行调用、审批状态和返回格式仍可能需要适配。
Agents API 会替代 LangGraph 或现有 Agent 框架吗？
我们的判断是：取决于框架在产品中承担什么。如果它主要维护通用的模型与工具循环，托管运行时可能替代相当一部分工作；如果它定义了业务分流、审批转换、截止时间和持久业务状态，这些职责仍需要明确归属。
例如，保险文档工作流可能先提取信息，再等待有权限的人员审查，最后将签核结果送入下游。推理步骤可以换运行时，但谁能批准不能因此改变。因为一个执行步骤变成托管，就替换整个工作流，会把业务规则和基础设施选择混在一起。
先把现有组件分成三类：业务规则、执行机制、集成适配器。再判断托管服务究竟能替换哪些执行机制。这样得出的迁移工作量，比比较两个 quickstart 的代码行数更有用。
混合架构也合理：保留确定性的外层工作流，将一个范围明确的调查步骤交给 Agents API。为这个步骤定义单一输入、应返回的证据和结束条件。避免外层工作流与内部运行时各自决定重试同一次外部写入。
这里并不是声称所有被提到的框架都缺少托管功能，或某个框架已经过时。要判断的是你当前实现中的责任，而不是给框架品牌排一个通用名次。
会话、记忆与审批，是不同的状态
对于退款审查助手，至少在概念上区分三种记录：
| 记录 | 内容示例 | 为什么单靠对话不够 |
|---|---|---|
| 工作上下文 | 已取得的证据和候选解释 | 它帮助推理，但不是授权记录 |
| 执行状态 | 当前运行、待处理工具调用、续接引用 | 它说明工作可以从哪里继续 |
| 业务状态 | 客户、拟退款金额、审查人、最终交易标识 | 它证明允许了什么、实际发生了什么 |
这些是建议的应用记录，不是要求必须建三张表，也不是 OpenAI 字段定义。目的在于让恢复后的任务先回答“这个动作现在仍获授权吗”。如果客户在等待审批时取消了任务，恢复执行不应重新启用旧许可。
采用托管会话时，将服务引用关联到业务任务；采用 SDK 时，决定会话和暂停状态存在哪里，以及 worker 怎样取回；直接用 Responses 时，在已有工作流中定义对应的续接方式。每种方案都应该测试等待审批期间进程重启，不能把内存中的成功演示当作恢复证据。
私有沙箱等于自己托管整个 Agent 吗？
画出真正的数据路径。调查数据库问题时，区分数据库查询、返回行、送给模型的工具结果，以及为调试保存的追踪。数据库在 VPC 里，并不意味着查询结果永不离开 VPC。
如果多模型选择是硬要求，应该怎么处理？
区分模型接口与运行时接口。使用网关的应用可以通过多个模型入口进行选择，但这不代表所有提供方具有相同的会话生命周期或工具协议。
评估可以分两阶段。第一阶段在可行时固定模型、工具、数据和验收规则，只比较运行时。第二阶段在选定架构内比较不同模型。如果某个候选必须使用不同模型或工具配置，应标为整套系统比较，不能把所有变化都归因于运行时。
对 SDK 路径，实际验证适配器的输入消息、工具参数和结果、结构化输出、流式、usage 与错误处理。能返回一段文本，远不足以证明适合工具密集的 Agent。对托管 API，也不能从 SDK 的提供方灵活性推导出它支持任意网关模型。
可操作的回退边界通常是一个新的业务任务：将新任务交给已验证的替代路径，并创建新的执行记录。把已经运行到一半的托管会话换到另一模型或运行时，需要明确的状态转换与重放政策；改一个 base URL 不是这样的政策。
按工作负载选择，也明确什么时候继续用现有方案
| 工作负载与现有系统 | 首先评估 | 为什么合理 | 什么情况会推翻这个选择？ |
|---|---|---|---|
| 小团队、长短不一的研究任务、几乎没有既有编排 | Agents API | 运行时运维是新增的大块工作 | 数据边界不符，或质量／运维没有收益 |
| 已有自定义审批和应用 worker 的产品 | Agents SDK | 执行逻辑可贴近现有控制 | worker 与状态运维成本超过控制收益 |
| 可靠工作流引擎中几个固定的模型步骤 | 直接用 Responses | 复用已有状态机 | 任务需要自适应循环，而团队无法经济地维护 |
| 使用特殊内部计算资源的文件任务 | SDK，或 API 加自托管环境 | 两者都值得按真实基础设施评估 | 所需连接、隔离或文件获取路径无法满足 |
| 多个互相独立的证据收集任务 | 托管或 SDK 编排 | 并行可能缩短关键路径 | 综合、重复工作或核验成本抵消收益 |
在最可能重复执行业务动作的地方测试恢复
准备一个非生产工单系统。任务先调查问题，获批准后创建且只创建一张工单。让客户端在目标系统已接受工单、但应用尚未记录工具结果时中断。这是建议的故障注入场景，不是已经发现的上游缺陷。
只有应用能够解释工单是否存在、避免重复创建，并使任务恢复或结束在明确状态，测试才算通过。如果结果不明确，转入审查。盲目重试可能让看似韧性很强的 demo 在生产中更不可靠。
比较每份合格结果的成本，而不只是 token
使用每份合格结果的直接费用，并把工程投入分开记录。纳入失败尝试、工具、环境和救回任务的成本。运行时可能降低运维工作但增加 API 费用，也可能相反；这种取舍应看得见。
迁移还有回本点。假设团队内部估算集成与验证需要 $1,200，后续经过验证的稳定任务每个合格结果节省 $0.04，则需要 30,000 个合格任务才能收回这笔投入，尚未计入持续运维差异。这里都是假设输入，应换成团队自己的数据；如果任务量达不到这个规模，小幅单位节省未必值得迁移。
延迟也必须使用可比口径：首次进度、可验收产物完成、人工审查分别计时。不能将流式首 token 与完全验证的报告交付时间相比。环境要记录启动、清理与活跃处理时间，才能看清冷启动或等待是否主导结果。
Trace 导出帮助诊断，但不等于业务审计
但导出的追踪与通过验收的业务结果回答的是不同问题。在工单测试中，将应用任务关联到运行追踪、工具调用和目标工单。让没有参与测试的人解释为什么创建了这张工单、是否获得授权。如果证据不能支持这个解释，单纯导出更多 span 不能补齐审计缺口。
核对之前，将模型／工具观察与最终计费分开记录。仪表盘截图不能证明最终单位经济性，记录到一次工具调用也不能证明下游变更已提交。
有明确回退边界的迁移方案
- 冻结基线。 保存任务样本、工具版本、验收检查与当前结果。至少包括长任务、歧义输入、等待审批、外部动作失败。
- 成对试跑。 尽可能固定模型和预算；无法固定时记录差异。波动较大的任务保留多次尝试，报告样本数，不能只挑最佳结果。
- 只读影子验证。 比较候选输出，但不让影子 Agent 发消息或重复写入。同一套规则判定结果。
- 从新任务开始小流量切换。 新业务任务启动时决定运行时，并在整个生命周期保持归属。不要让两个未同步的控制器同时管理一项进行中的任务。
- 明确回退。 新任务回到基线；进行中的任务则等待原运行时完成，或先核对工具实际影响和产物，再启动替代执行。保留能够解释切换过程的证据。
看结果之前先定门槛：质量满足现有产品验收要求；未授权写入和重复副作用应阻止放量；成本与延迟预算来自实际业务。不存在一个可以代替这些条件的通用“95% 就能生产上线”分数。
一个迁移例子：保留客服流程，只替换调查步骤
假设现有 SDK 应用接收客服问题、收集客户证据、等待审批，再创建工单。首轮迁移可以只替换证据收集：托管任务返回草稿与引用，现有应用继续负责审批和创建工单。这是建议的设计，不是已完成的迁移实测。
| 现有组件 | 保留还是适配？ | 具体需要做什么 |
|---|---|---|
| 用户身份、客户记录权限、工单结构 | 保留业务约定 | 向候选提供相同的可访问记录与必需输出字段 |
| SDK 调查执行器 | 替换试点中的这个步骤 | 创建托管会话，并把会话引用关联到原业务任务 |
| 工具实现 | 合适时复用，适配调用分发 | 转换参数与结果，保留权限检查并记录工具失败 |
待审批动作与已保存的 RunState | 进行中的任务保留原归属 | 完成旧任务或先核对实际结果，不能将序列化状态视为托管会话的导入格式 |
| 界面进度与最终结果 | 适配应用侧状态 | 区分调查中、草稿待审，以及工单已经创建成功 |
| 追踪与计费记录 | 添加新引用 | 将候选运行关联到同一任务、验收结果与成本账本 |
所以，首轮试点可以结束在“草稿可以审查”，无需一次搬走整个流程。如果调查有改善，但审批恢复出现退步，就保留应用内审批并缩小迁移范围，不必接受非全换不可的结果。
RunState 包含待处理工作与审批决定，但反序列化不会验证提交者身份。应由应用保存状态，核对审查人是否有权处理该动作，并协调恢复执行，避免同一次审批被重复消费。即使更换调查运行时，这些具体的应用工作仍然存在。FAQ
Agents API 会让现有框架过时吗？
它可能替代通用运行时工作，但业务规则、审批转换和领域状态仍需明确归属。应评估组件，而不是因为框架名称就整套替换。
Agents SDK 没有持久状态吗？
不是。SDK 文档包含会话及持久化实现；应用仍需运维实际采用的部署与存储方案。
SDK 能保留人工审批吗？
可以，官方流程包含中断运行与可恢复状态。应在自己的部署中测试进程重启和授权变化，不能只依赖内存演示。
自托管计算让 Agents API 支持 ZDR 吗？
当前官方文档明确不支持。SDK 方案也需审查完整数据路径，本地编排不是数据保留保证。
换 base URL 就能更换运行时吗？
不能这样假设。工具实现可能可复用，但会话、待处理调用、状态和结果处理需要明确适配与测试。
哪个方案最便宜？
比较相同的合格业务结果，纳入失败与救回尝试，再考虑迁移和运维投入。上文是示意算例，不是胜负结论。
Agents API 能导出 trace 吗？
当前官方文档描述了 OTLP JSON 导出。可以先规划它与现有监控系统的连接；EvoLink 的接入方式以上线文档为准。
现在可以通过 EvoLink 使用吗？
来源与范围
一手技术文档放在对应声明旁。HN 与 Reddit 仅用于识别 API／SDK 和框架替代问题。工作负载、算例与放量建议属于编辑方案，本文不声称已完成受控运行时测试、不承诺普适节省，也不证明生产网关兼容性。
