OpenAI Agents API 发布：Codex 执行框架、子 Agent 与成本
这次发布真正值得回答的问题比“什么是托管 Agent”具体得多：客户端断开后，任务能否接着做？上下文压缩后，关键约束还能不能保留？子 Agent 并行节约的时间，是否值得额外花费？OpenAI 接管 harness 后，哪些工作仍留在应用里？
这次到底发布了什么？
| 问题 | 当前答案 | 对采用决策的影响 |
|---|---|---|
| 只有预告，还是上游已经提供产品？ | OpenAI 于 9 月 10 日宣布公开测试 | 依据 beta 文档评估，不能当作已经承诺的 GA 合同 |
| 是 Agents SDK 改名吗？ | 不是；API 是托管运行时，SDK 在应用里运行 | 迁移会改变运维责任 |
| Codex harness 就是模型吗？ | 不是；它组织模型调用、工具和持续执行 | 应评估完整工作流，而不仅是模型质量 |
| EvoLink 可以调用了吗？ | 正在接入，暂未开放调用 | 保留已验证路径，同时准备候选工作负载 |
| 发布 API 是否意味着开放模型权重？ | 不能从这次运行时发布推导出权重或模型许可证 | 执行框架源码、托管服务条款和模型许可需分别判断 |
命名混淆会直接影响接入判断。安装 Agents SDK 的教程可以有价值，但不能证明它调用了新的托管 API。同样，“兼容 OpenAI”的模型端点也不能证明支持持久 Agent 会话。复用示例之前，先识别它实际针对哪种产品。
把 Codex harness 开放成 API，价值在哪里？
对于编码或数据分析产品，模型调用只是工作的一部分。应用还要决定下一步使用什么工具、把结果带入后续步骤、维持足够上下文，并在中断后继续。托管服务把这些交互组织成一个运行时。团队花在维护运行时上的工作越多，这次发布就越值得评估。
先盘点当前的工程投入：多少用于提高业务任务质量，多少用于维护执行基础设施。只有后者占比足够大，且服务边界适合产品时，托管运行时才可能带来有意义的运维收益。
长任务与上下文压缩：核心价值是连续完成工作
可以设计一个仓库维护任务：修复分页、保持公开响应结构、不改动鉴权，并附上相关测试输出。在多轮调查和修改后，再追加一个边界情况。最终需要回答的是：补丁是否仍遵守最初的约束。保存了一段很长的对话，并不能回答这个问题。
把验收规则保存在应用自己的任务记录里。审查时，将变更文件、响应样本和测试证据与规则逐项对应。这样才能区分是上下文处理失败，还是最初的任务定义不足；以后换一个运行时，也有独立的比较基准。
数据分析同理。一份报告可以读起来很连贯，却悄悄换了统计窗口，或漏掉用户要求排除的记录。应显式测试这些不变量，不能把“持久会话”直接写成所有业务约束都能在每次续接中保留的保证。
工具搜索与程序化调用，减少的是两种不同开销
以一个候选客户分析助手为例：CRM 中有许多操作，但某个问题只用得到几个；与此同时，它可能需要读取多份客户记录并计算汇总。这是两个独立的优化机会。找到正确操作，并不等于消除了拉取和处理数据的成本。
因此，评估时要保留两类记录：是否选中了正确工具，计算结果是否与独立计算一致。最终回答变短，不代表聚合正确。测试数据应包含缺失记录、空结果和单位不一致的情况。
我们的建议是：让分析先生成拟议变更，最终面向客户的写入由应用代码校验目标和权限后执行，避免把它隐藏在难以检查的聚合步骤中。这是工作流设计建议，不代表 EvoLink 已经支持上述工具机制。
子 Agent 并行：适合可拆分任务，不等于自动提速
可以设计一个故障调查任务：分别检查部署变化、错误样本和依赖健康状态。每个只读子任务必须交付证据、假设和不确定性，再由主 Agent 检查解释是否相互一致，最后提出缓解建议。
如果换成三个 Agent 同时修改同一份配置文件，看似并行的工作可能变成冲突和额外合并。起步时先并行收集独立证据，最终修改由一个执行者负责。衡量从开始到验收通过的总时间，包括综合结论与解决冲突，不能只看最快的子任务。
有价值的对照是：同一批故障样本，分别使用单 Agent 和受限的子 Agent 配置。时间之外，同时记录总费用和人工修正。如果并行后回答更快，却更难验证，优化就没有满足产品要求。
托管沙箱、自有环境，还是根本不需要沙箱？
| 候选任务 | 优先评估的起点 | 原因 | 应用责任 |
|---|---|---|---|
| 通过业务函数查询客户 | 无沙箱 | 需要的是服务返回值，而非本地计算 | 用户鉴权及记录级访问控制 |
| 分析 CSV 并生成工作簿 | 托管沙箱 | 文件、依赖包与输出产物是核心 | 验证合计并保存通过验收的交付物 |
| 依赖特殊工具链的仓库任务 | 自托管环境 | 既有计算资源或工具可能很重要 | 计算资源的创建、隔离、恢复与释放 |
/workspace/outputs 的文件会在该轮完成后发布为不可修改的产物。获取报告时，应同时匹配已完成轮次和文件路径，避免用户追加分析后仍下载到上一版。已发布产物会在环境到期后保留；删除会话前，应先保存需要长期留存的副本。/workspace/outputs，也不会通过 OpenAI Artifacts API 发布。对于同一个 CSV 对账功能，这意味着客户看到的是同一个“下载报告”按钮，应用背后却需要两种不同的下载适配方式。文件获取与生命周期。
从 Agent 执行到客户下载报告
下面是针对该 CSV 任务建议的产品流程。这些是应用状态，不是 API 事件名称：
| 客户看到的状态 | 应用执行什么 | 进入下一步的条件 |
|---|---|---|
| 正在处理 | 将业务任务关联到托管会话，跟踪执行进度 | 已产生可以检查的结果 |
| 正在核对结果 | 获取正确版本的报告，检查合计与异常记录 | 工作簿通过预先保存的验收规则 |
| 可以下载 | 保存合格结果，并检查用户的下载权限 | 文件确实可以获取 |
| 正在恢复连接 | 事件流中断后读取原会话与已保存的工作 | 查明原任务仍在执行，还是已有结果 |
| 需要处理 | 保留可用输出，说明尚待解决的问题 | 修正输入、人工复核或按规则重试 |
“API 不额外收费”到底省去了什么？
预算应建立在任务账本上：模型费用、工具费用、环境费用、失败尝试与通过验收的结果。自身运维和人工审查时间单独列一栏，避免拿只有 token 的估算与完整生产成本相比。
哪些 beta 限制会直接改变选择？
第一轮评估怎样产出真正可用的结论？
选择一个边界清楚的报告任务：核对两份 CSV 导出、解释未匹配行、产出工作簿和摘要。下面是编辑建议的测试设计，并未宣称已经得到结果。
| 测试情况 | 样本或中断方式 | 验收证据 |
|---|---|---|
| 普通输入 | 两份已知匹配总额的导出 | 工作簿合计等于独立计算结果 |
| 数据歧义 | 重复标识符和缺失币种 | 明确暴露歧义，不静默捏造匹配 |
| 客户端断开 | 任务开始后关闭事件流 | 能定位已有工作，不盲目重新提交 |
| 指令变化 | 执行中追加一个排除条件 | 最终合计与说明符合修订后的范围 |
| 获取输出 | 保存结果后结束计算资源 | 应用仍能获取并打开已验收交付物 |
| 预算复核 | 纳入整批的全部尝试 | 费用与合格输出数量可以对应 |
FAQ
OpenAI Agents API 什么时候发布的？
OpenAI 于 2026 年 9 月 10 日宣布 public beta。这个日期不代表 GA，也不是 EvoLink 上线日期。
它是 Codex 模型，还是 Agents SDK？
它是围绕 Codex harness 提供的托管服务。模型选择与在应用中运行 SDK 编排，是另外两个概念。
自动上下文压缩等于无限记忆吗？
不等于。要评估长任务中关键约束和证据是否仍能正确使用，并将业务验收记录保存在对话之外。
子 Agent 一定能降低费用或延迟吗？
不能仅从并行执行得出普适结论。比较时应计入协调、重复工作和最后的核验。
Agents API 免费吗？
没有单独额外 API 费，不意味着模型、工具或环境免费。本文算例只解释核算方法，EvoLink 尚未公布报价。
可以让所有数据都留在自己的 VPC 吗？
不能仅凭自托管沙箱作出这个判断。执行环境与 OpenAI 托管服务仍是不同边界，当前驻留和保留限制依然需要满足。
EvoLink 已经可以调用了吗？
哪些变化会触发本文更新？
新的 beta／GA 合同、环境或数据控制变化、网关能力验收，以及可复现的任务测试结果。应更新对应事实与建议，而不只是刷新日期。
