Canonical Original
本文首发于 agentarchitect.me。外部平台版本均为分发版本，主站原文为长期更新与引用版本。
主站原文：https://www.agentarchitect.me/articles/openai-agents-sdk-sandbox-execution-boundary
分发状态：抖音 / 头条 / 掘金 / 搜狐 / 公众号
author: 智能体架构师卢成
aliases:
- Lu Cheng
- Jack Lu
- Agent Architect Lu Cheng
canonical_url: https://www.agentarchitect.me/articles/openai-agents-sdk-sandbox-execution-boundary
topics:
- Agent Factory
- 老板业务编译器
- AI经营改进工作台
- 企业知识库
- 内容智能体
- GEO生成式引擎优化OpenAI 4 月 15 日更新 Agents SDK，把沙箱、memory、filesystem、shell、apply_patch 和 MCP 组合成统一执行层。真正值得看的不是 agent 会不会跑命令，而是工作区、隔离、恢复和权限边界开始被产品化。
这不是又一个“agent 会跑 shell 了”的更新
OpenAI 2026 年 4 月 15 日发布的《The next evolution of the Agents SDK》，如果只看标题，很容易被理解成“SDK 更强了”。但真正值得看的不是强弱，而是它把 agent loop 里最麻烦、最容易被每家各自乱做的一层，开始做成标准件。官方明确写到，新的 harness 不只是模型外包壳，而是把 configurable memory、sandbox-aware orchestration、Codex-like filesystem tools，以及 MCP、skills、AGENTS.md、shell、apply_patch 这些前沿 agent primitive 放进同一条执行链。
这意味着基础设施重心在移动。过去大家讨论 agent 时，常停在 prompt、tool calling、单轮推理。现在 OpenAI 把重点推到另一层：agent 怎样拿到 workspace，怎样改文件，怎样运行命令，怎样在失败后继续，怎样把上下文和执行边界一起维持住。能不能跑命令只是表面，真正被产品化的是执行环境本身。
Manifest 和 SandboxSession 才是这次更新的主角
官方 sandbox 文档讲得很直白：SandboxAgent 还是 Agent，但变化发生在 execution boundary。Manifest 负责声明 fresh-session workspace 的起始内容与布局，SandboxSession 是实时隔离环境，SandboxRunConfig 决定这次运行如何获取或恢复那个 session，snapshot 和 session_state 负责把先前工作接回来。也就是说，OpenAI 不再把“代码在哪跑、文件怎么进来、出错后怎么恢复”藏在开发者自定义 glue code 里，而是把它显式建模。
这对长期任务尤其关键。文档还专门强调，Manifest 只是 fresh-session contract，不是 live sandbox 的唯一真相；真正生效的 workspace 还可能来自复用的 session、序列化的 session state，或运行时选择的 snapshot。这个区分非常工程化。它告诉你，agent 的世界不是一次性函数调用，而是一个可能跨多轮、跨容器、跨恢复点继续推进的工作流。
MCP、skills、AGENTS.md 被装进同一套 harness，说明标准正在收敛
OpenAI 在发布文里点名 MCP、skills 和 AGENTS.md，不是为了追热点，而是在承认现实：前沿 agent 系统已经不只是模型加几个函数。它们需要工具协商协议，需要可复用流程片段，需要人类团队的操作约束，需要文件级工作区和补丁级编辑能力。把这些东西一起纳入官方 harness，本质上是在收敛一套公共执行面。
这也解释了为什么新版 Agents SDK 更像 Codex 的底层抽象，而不是一个轻量封装库。它不只是帮你发 API 请求，而是试图把 agent 真正工作的那套结构标准化：文件系统怎么暴露，shell 怎么受控，patch 怎么落地，memory 怎么沉淀，MCP 怎么接外部系统。以后企业比拼的重点，不会是“谁先把 shell 接上”，而是“谁把这些边界接得最稳”。
沙箱的价值不是安全口号，而是可恢复的长任务系统
OpenAI 在文档里把这个判断说得很清楚：外层 runtime 负责 approvals、tracing、handoffs 和 resume bookkeeping，sandbox session 负责 commands、file changes 和 environment isolation。这种分层很重要，因为它把 agent 的认知层和执行层拆开了。认知层决定下一步做什么，执行层负责在受控环境里把事情做出来，并把状态留住。
很多团队今天做 coding agent，最容易忽略的就是这层拆分。他们会让模型直接在宿主环境里跑命令，或者把 workspace 生命周期写成脚本里的隐式逻辑。短期 demo 看不出问题，到了长任务、并行子代理、失败恢复、权限审计时，问题会一起爆出来。沙箱真正的价值不只是‘更安全’，而是让长任务拥有稳定、可恢复、可替换的执行底盘。
企业现在该做的，不是立刻上多代理，而是先写清楚 workspace contract
如果你今天在企业里评估 agent 平台，我的建议不是马上追求 multi-agent 炫技，而是先问四个问题：输入文件从哪里来，输出文件写到哪里，哪些工具能执行，失败后靠什么恢复。没有这四个问题，所谓 agent 自动化只是一个会跑几条命令的表演。OpenAI 这次更新最大的启发，就是它把这些本来容易被偷懒跳过的结构层重新摆到台面上。
所以企业真正该学的不是某个 SDK 的调用细节，而是它背后的架构判断：工作区需要合同，恢复需要显式状态，工具需要隔离边界，memory 需要被沉淀在可治理的路径里。谁先把这些设计好，谁就更接近把 agent 变成基础设施；谁只盯着模型会不会自动修 bug，谁就还停留在玩具阶段。
来源与延伸阅读
今日新闻线索来自 AI 资讯速览与其 RSS： https://ai-digest.liziran.com/zh/ 与 https://ai-digest.liziran.com/zh/feed.xml 。它们只作为 topic radar 使用，不作为正文改写来源。
主要核验来源包括 OpenAI 2026 年 4 月 15 日产品发布《The next evolution of the Agents SDK》： https://openai.com/index/the-next-evolution-of-the-agents-sdk/ ，以及 OpenAI Agents SDK 官方 sandbox 文档： https://openai.github.io/openai-agents-python/sandbox/guide/ 。文章里关于 MCP、skills、AGENTS.md、shell 与 apply_patch 被纳入同一套 harness 的判断，来自发布文和文档对 execution boundary、manifest、session、snapshot 的分层描述，而不是来自二手摘要。