OpenAI Agents SDK 后续更新：TypeScript 版补齐，沙箱与开源 harness 成为默认叙事

原文链接：https://developers.openai.com/api/docs/changelog 补充原文：https://developers.openai.com/api/docs/guides/agents 来源：OpenAI Developers 发布日期：2026-05-06

速查卡

文章背景

本文是对 2026-04-16 旧文《深度解读 | OpenAI Agents SDK 重大演进：从 Codex 内部架构到开源 Agent 基础设施》的后续追踪。旧文链接：/ai-research/news/2026-04-16/deep-openai-agents-sdk/ 。那篇文章拆的是 OpenAI 首次把 Codex 级 agent runtime 开源出来；本文不重复原有背景，聚焦 2026-05-06 这次新增的 TypeScript 主线、sandbox agents 与 open-source harness 默认化 三个新信号。

如果只看 changelog，这次更新像一句短公告：

• Agents SDK 现已支持 TypeScript
• 支持 sandbox agents
• 内置 open-source harness

但配合同一天的完整 guide 来看，OpenAI 实际上传递的是更大的框架性判断：

Agents 不是“多调几次模型”的脚本，而是会规划、调工具、跨 specialist 协作、并保留足够状态以完成多步工作的应用。

而一旦你接受这个定义，问题就不再是“怎么发 API 请求”，而是：

• 谁来负责 orchestration
• 谁来执行 tools
• 谁来做 approvals
• 谁来保存 state
• 谁来提供可恢复、可观察、可隔离的 runtime

OpenAI 的答案就是：用 Agents SDK。

完整内容还原

1. changelog 给出的新增信号其实有两层

第一层是 2026 年 5 月 6 日的最新更新：

• 更新后的 Agents SDK 已提供 TypeScript
• 支持 sandbox agents
• 内置 open-source harness

第二层是 2026 年 4 月 15 日的前序更新。原文写得更具体：

• running agents in controlled sandboxes
• inspecting and customizing the open-source harness
• controlling when memories are created and where they’re stored

把两次 changelog 放在一起看，逻辑就清楚了：

4 月中旬 OpenAI 先强化了 Agent runtime 的底层能力；5 月初再把这套能力明确推到 TypeScript 受众面前。

2. guide 对 Agents 的定义，已经明显超过“SDK 帮你封装 API”

guide 中的第一句关键定义是：

Agents are applications that plan, call tools, collaborate across specialists, and keep enough state to complete multi-step work.

这句话决定了 OpenAI 对 Agents SDK 的定位：

它不是轻量客户端，而是面向多步工作流的应用框架。

guide 还明确区分了三条路径：

• 想直接发模型请求，用 OpenAI client libraries
• 当应用自己拥有 orchestration、tool execution、approvals 和 state 时，用 Agents SDK
• 只有当你明确想要 hosted workflow editor 和 ChatKit 路线时，才用 Agent Builder

这等于把产品边界画得很清楚：

如果你只是调模型，SDK 不是必须；但如果你要做 agent runtime，OpenAI 希望你进入它的 Agents SDK 轨道。

3. TypeScript 补齐的意义，在于把 agent 框架直接推给主流应用层团队

guide 在“Get the Agents SDK”一节里直接给出两个 GitHub 仓库入口：

• TypeScript SDK
• Python SDK

这不是无关紧要的语言扩展。因为大量真正面向产品、业务系统、Web 应用和现有服务栈的团队，本来就以 TypeScript 为主。

此前如果 Agents SDK 的心智更偏 Python，那么它更容易先进入研究、自动化和基础设施工程语境；现在 TypeScript 被放到同等入口位置，意味着 OpenAI 正把 agent runtime 主张直接推向更广泛的应用开发人群。

4. guide 最有价值的部分，是把整个 agent 开发拆成一条“阅读顺序”

原文没有只给一个 SDK 概览，而是把开发路径拆成模块：

• Quickstart：最短路径跑通一个集成
• Agent definitions：定义单个 specialist
• Models and providers：处理模型选择、默认设置与 transport
• Running agents：理解 runtime loop、streaming 和 continuation strategies
• Sandbox agents：当 agent 需要 files、commands、packages、snapshots、mounts 或 provider links 时使用
• Orchestration and handoffs：多 specialist 情况下决定谁拥有回复
• Guardrails and human review：在高风险工作继续前加验证或人工审批
• Results and state：解释 final output、resumable state 和 next-turn surfaces
• Integrations and observability + agent evals：先用 traces 调试，再进入评估循环
• Voice agents：语音工作流仍是 SDK-first，因为 Agent Builder 还不支持

这段结构透露出 OpenAI 对 agent 开发流程的完整理解：

先定义 specialist，再处理运行循环，再决定何时需要沙箱、多 agent、审批、状态、可观察性与评估。

5. sandbox agents 已经被明确定位为“容器化工作环境”问题

guide 对 sandbox agents 的描述非常关键。它不是泛泛说“更安全”，而是明确写到：

当 agent 需要以下能力时，应使用 sandbox agents：

• files
• commands
• packages
• snapshots
• mounts
• provider links

这说明 OpenAI 把 agent sandbox 视为真实执行环境，而不是只给一点临时工具权限。

尤其 “snapshots” 和 “mounts” 这两个词很重要：

• snapshots 对应可恢复与状态捕获
• mounts 对应和外部文件或环境的受控连接

再结合 4 月 15 日 changelog 里的 controlled sandboxes，可以看出 OpenAI 已把“隔离执行环境”视为 agent 平台的核心基础设施之一。

6. open-source harness 是这次更新最不该被忽略的关键词

changelog 两次都提到 harness：

• 5 月 6 日：open-source harness built in
• 4 月 15 日：可以 inspecting and customizing the open-source harness

官方没有在这两篇原文里展开更多内部实现细节，但有一件事已经足够明确：

OpenAI 不想把 agent runtime 完全做成黑盒托管品，而是允许开发者检查、定制其运行线束。

这很关键，因为企业团队真正担心的往往不是“会不会调模型”，而是：

• tool 调用链到底怎么组织
• 中间状态在哪里接管
• 出错时能不能插入自定义逻辑
• 安全和审计控制能不能接到自己系统里

一个可检查、可定制、且开源的 harness，正是在回答这些问题。

7. memories control 表明 OpenAI 已承认 agent state 不是默认自动就好

4 月 15 日 changelog 还提到：

• 可以控制 memories 何时被创建
• 以及它们存放在哪里

虽然 guide 没有展开 memory 系统的更细节实现，但单凭这条更新就能看出：

OpenAI 已经把 memory 从“默认越多越好”的产品功能，转向“需要开发者和企业自己决定边界”的 runtime 能力。

这对于企业场景尤其重要，因为 memory 本质上会涉及：

• 生命周期控制
• 数据位置
• 合规边界
• 审计与隐私策略

8. SDK 路线和 Agent Builder 路线被官方刻意分流

guide 里一个很重要的产品分层是：

• SDK 适合你的 server 自己拥有 orchestration、tool execution、state 和 approvals
• Agent Builder 适合想要 OpenAI-hosted 的 workflow creation、publishing、ChatKit deployment

这说明 OpenAI 并没有试图用一个产品面向所有 agent 开发者，而是在刻意分层：

• 偏应用工程和可控 runtime 的，去 SDK
• 偏托管工作流与可视化发布的，去 Agent Builder

这种分层也强化了前面那个判断：OpenAI 正在把 Agents SDK 定位成“自己掌控运行时”的那条专业路线。

核心技术洞察

1. OpenAI 抢的是 agent runtime，而不只是 JS 开发者市场

如果只看“TypeScript 支持”，容易误判成一次语言生态补齐。

但结合 guide 里反复强调的 orchestration、approvals、state、sandbox、observability、evals，更准确的理解是：

OpenAI 在争夺 agent runtime 标准层。

谁拥有这层，谁就不只是提供模型，还会影响：

• 多 agent 如何协作
• 工具如何接入
• 审批如何中断流程
• 状态如何续接
• 调试和评估如何做

2. sandbox + harness + memory control，构成了 agent 工程化三件套

从两篇原文里能确认的三大运行时关键词是：

• controlled / sandbox agents
• open-source harness
• memory creation and storage control

这三件事分别对应：

• 执行隔离
• 流程可定制
• 状态可治理

这说明 OpenAI 已经把 agent 工程问题，从“prompt 如何写”推进到了“运行时如何治理”。

3. guide 的结构本身就是 OpenAI 的产品教育

原文不仅在介绍 SDK，也在训练开发者采用一种 OpenAI 认可的 agent 开发顺序：

单 specialist → runtime loop → sandbox → handoffs → human review → results/state → observability → evals。

这套顺序会影响开发者如何理解 agent 架构，也会让 OpenAI 的平台概念逐步变成默认方法论。

横向对比

批判性分析

局限性

1. 5 月 6 日 changelog 很短，新增能力的具体 API 形态和迁移成本并未在 changelog 本文中展开。
2. guide 更像总览和导航页，告诉你能力边界与阅读顺序，但不是完整技术细节说明。
3. 原文确认了 sandbox、harness、memory control 的存在，但没有在这两篇材料里给出性能、成本或安全边界的量化指标。
4. TypeScript 补齐后能否显著改变开发者采用率，还要看后续生态、样例与社区成熟度；这一点原文没有提供数据。

最值得记住的结论

这次更新真正重要的不是“OpenAI 终于有 TypeScript Agents SDK”，而是它在用 TypeScript、sandbox agents 和 open-source harness 一起宣告：未来 agent 竞争的关键，不只是谁的模型更强，而是谁能提供更可控、可恢复、可治理的运行时。