4 月 15 日,OpenAI 发布了 Agents SDK 的重大更新。这不是一次小修小补 — 它标志着 Agent 开发从“各自为战”走向“标准化基建”的转折点。
核心变化:Agent 终于有了自己的工作空间
过去做 Agent 开发,最痛苦的不是模型能力不够,而是基础设施太碎片化。你需要自己搞定文件系统访问、代码执行环境、工具调用协议、状态管理... 每个团队都在重复造轮子。
这次更新的核心是 原生沙箱执行(Native Sandbox Execution)。Agent 现在可以在受控的计算环境中运行 — 读写文件、安装依赖、执行代码、使用工具,全部开箱即用。支持的沙箱提供商包括 E2B、Modal、Vercel、Cloudflare、Daytona 等,也可以用本地 Unix 环境。
from agents.sandbox import Manifest, SandboxAgent
from agents.sandbox.entries import GitRepo
agent = SandboxAgent(
name="Code Reviewer",
instructions="Review the codebase and identify issues.",
default_manifest=Manifest(
entries={"repo": GitRepo(repo="your/repo", ref="main")}
),
)
几行代码就能让 Agent 拥有一个完整的工作空间。这在半年前还需要几百行胶水代码。
标准化原语:MCP、AgentSkills、AGENTS.md
更值得关注的是 SDK 整合的一系列标准化原语:
- MCP (Model Context Protocol):工具调用的统一协议,Agent 不再被锁定在某个供应商的工具生态里
- AgentSkills:渐进式能力披露,Agent 按需加载技能而不是一次性塞入所有上下文
- AGENTS.md:自定义指令的标准格式,类似于 .editorconfig 之于编辑器
- Shell 工具 + Apply Patch 工具:类 Codex 的文件操作能力
这些不是 OpenAI 独创的概念,但把它们整合进一个官方 SDK 并提供开箱即用的体验,意义重大。它降低了 Agent 开发的入门门槛,也在事实上推动了行业标准的形成。
我的判断:方向对了,但还不够
好的方面:
SDK 的设计哲学是对的 — "turnkey yet flexible"。给你一个能跑的默认配置,但不限制你替换任何组件。Manifest 抽象让工作空间定义可以从本地原型无缝迁移到生产部署,这解决了 Agent 开发中最常见的“demo 能跑,上线就崩”的问题。
安全模型也值得肯定。把 harness 和 compute 分离,确保模型生成的代码不会接触到凭证 — 这是很多团队踩过的坑。
需要观察的:
- 多模型支持的深度。SDK 号称 provider-agnostic,支持 100+ LLM,但 harness 的优化显然是针对 OpenAI 自家模型的。用 Claude 或 Gemini 时,能否获得同等的 Agent 体验?
- 生态锁定风险。虽然用了 MCP 这样的开放协议,但 Manifest、SandboxAgent 这些抽象是 OpenAI 特有的。一旦深度使用,迁移成本不低。
- 成本控制。沙箱执行意味着更多的 token 消耗和计算资源。结合前几天 Toby Ord 关于 Agent 成本指数增长的分析,这个问题会越来越突出。
对开发者的实际建议
如果你正在做 Agent 开发:
- 新项目可以直接上 Agents SDK。它的抽象层设计合理,省去了大量基建工作
- 已有项目不急着迁移。等 0.15 或 1.0 稳定版再说,API 还在快速迭代
- MCP 和 AgentSkills 值得现在就学。这两个是跨框架的标准,不管你用什么 SDK 都有价值
- 沙箱执行是刚需。如果你的 Agent 需要操作文件或执行代码,原生沙箱比自己搭 Docker 靠谱得多
在多模型 Agent 架构中,模型选择本身就是一个工程决策。像 OfoxAI(ofox.ai)这样的多模型聚合平台,让你在不同 Agent 节点上灵活切换 Claude、GPT、Gemini,而不被单一 SDK 的模型偏好所限制。
Agent 开发正在从“英雄时代”走向“工业时代”。标准化基建的出现是好事 — 它让开发者可以把精力放在业务逻辑上,而不是反复解决已经被解决的问题。OpenAI 这次更新的方向是对的,执行质量也不错。剩下的问题是:其他玩家会跟进这套标准,还是各搞一套?
我赌前者。因为开发者的耐心是有限的。