更精简的执行框架和可执行代码的智能体更适合开放式任务，因为过于僵化的编排可能限制模型性能。
因此，代码执行和沙箱现已成为智能体系统的核心架构议题。
在我们的测试中，Agents SDK 可将构建代码执行智能体所需的复杂度和代码量最多降低至六分之一。
长期以来，智能体系统的进步主要源于编排能力的提升：更出色的提示设计、工具接口和上下文管理，以及更严密的控制流。但随着编码智能体的能力不断增强，这种平衡正开始转变。
在许多开放式工作流中，瓶颈不再是智能体循环本身，而是执行层：模型在沙箱中编写代码、运行命令、检查输出并反复迭代。随着越来越多任务级推理转移到这一环境中，外围编排需要进一步简化，才能让模型充分发挥能力。
新版 Agents SDK 所实现的正是这种转变。在抢先体验期间的测试中，我们发现，它没有再增加一层框架逻辑，而是让执行层更加模块化、可组合，从而使系统其余部分保持精简。
在执行框架工程领域，将执行框架精简到可有效运作的最小形态已成为一种趋势。从宏观上看，执行框架是围绕模型构建的软件：它负责管理上下文、工具、控制流和反馈循环，让模型能够可靠地完成工作。
过去几年，智能体性能的许多提升都来自这一层的强化。更好的工具、更出色的记忆与检索、更明确的任务拆解，以及更严密的编排，往往能让系统更加可靠、更有能力。在这种范式下，进步主要意味着将更多任务逻辑编码到模型外围的软件中。
如今，至少对一类开放式任务而言，这一模式正在弱化。越来越多的项目和论文表明，执行框架变得更具规定性时，性能未必总会提高。在辅助编码、长时间运行的任务、浏览器使用和长上下文任务中，同一种模式反复出现：一旦模型足够智能，强行在外围软件中加入过多任务结构，反而可能成为限制，而非优势。
因此，执行框架的作用正在改变。执行框架不再试图通过僵化的编排预先覆盖任务的各种情况，而是越来越多地提供简洁的执行界面：模型可在沙箱中检查状态、运行代码、从错误中恢复并调整自身方法，同时仍受系统接口和安全措施约束。这与 Andrej Karpathy 在 Software Engineer 3.0 中描述的转变非常相似：过去存在于软件中的部分逻辑上移到了“提示”中。
这并不意味着智能体系统应当彻底取消结构。许多任务仍能从明确的工作流、启发式方法和确定性护栏中受益，尤其是范围较窄、处理量较大或成功标准明确的任务。正如我们在上一篇有关智能体系统设计的启发式方法的文章中所述，当可靠的逻辑流既可行又可取时，强大的编排仍然至关重要。
对于开放式任务，关注重点正在转变。挑战不再是设计日益复杂的编排层，而是构建足够简洁、可观测且模块化的执行环境，使模型能够在其中高效工作。
一旦智能体能够读取文件、编写代码、运行 shell 命令并启动长时间运行的任务，工程挑战就会发生变化。难点不再只是优化提示或路由工具。智能体如今在真实系统上运行，这使其能力显著增强；但与此同时，更大的安全风险面也使其变得更加敏感。例如，如果环境隔离不当，可执行代码的智能体可能采取有害操作（参见 AISI 的 Sandbox Bench）。
因此，沙箱正成为智能体框架中的关键议题。在早期系统中，执行通常被视为附加功能：一个外挂到执行框架上的工具。但当执行开始涉及状态、长时间运行或远程操作时，这种方法便难以为继。管理沙箱本身及其生命周期、状态和接口，并将其接入智能体循环，很快就会成为一个独立的系统设计问题。这正是如今越来越多提供商开始提供托管代码执行环境的原因之一，包括 OpenAI 的 Container API 和 shell 工具，以及 Modal、Cloudflare、Daytona、E2B 等。
这一边界至关重要，因为与执行框架的其他部分相比，代码执行需要更强的隔离和更严格的运行时控制。在实践中，实现不当的代码执行智能体可能带来三项攸关业务的风险：计算支出失控、对内部系统采取破坏性操作，以及敏感信息泄露。通过适当的容器化、隔离和运行时安全措施，可以将这些风险控制在实际部署可接受的水平。
可以这样理解：与其把整间办公室的钥匙交给智能体，不如给它一个独立封闭的工作区。它仍能在其中完成有用的工作，但只能在明确界定的边界内行动。你可以限制其计算资源用量，限定它可访问的系统和文件，并从源头控制它能获得哪些信息。
这并不能彻底消除风险，却能将问题从“一个在基础设施中不受约束的智能体”转变为“一个在受控环境中运行的智能体”。如果这一层将成为智能体系统的标准组成部分，框架本身就需要为其提供一等支持。这样一来，沙箱便成为模块化执行层，提供可移植的基础组件，方便开发者快速采用、跨提供商切换，并在无需不断改造智能体逻辑的情况下扩展。
智能体一旦开始执行代码，沙箱本身也需要编排。从本地概念验证转向远程执行、多种后端或长时间运行的会话，会使运维负担急剧增加。你需要以一致的方式创建和停止环境、暂停与恢复环境、创建状态快照、稍后重新连接，并跨提供商管理这一切。
这些工作在概念上并不炫目，但在实践中至关重要。如果每个团队都从头重建智能体管线，这类基础设施就会带来很多麻烦；尤其是在它未集成到智能体框架中时……
这正是更完善的框架支持变得重要的地方。我们抢先体验了新版 OpenAI Agents SDK，并用它自行构建了采用沙箱的智能体。最引人注目的是其架构重心的转变：SDK 将执行视为一等层，而不是外围工具。在实践中，这意味着你能用更少的代码启动采用沙箱的智能体、创建沙箱快照或恢复执行（在我们的部分测试中，代码量约为原来的六分之一），然后切换后端，而无需重写外围的智能体逻辑。
这种更清晰的关注点分离，让执行框架能够专注于推理、上下文和工作流。执行层则可专注于隔离、可移植性和运行时状态。借助这种抽象，开发者可以更轻松地构建能力更强且更易演进的编码智能体，使其能在本地与远程执行之间迁移、支持长时间运行的任务并更换执行后端，而不必重新设计整个系统。
随着越来越多任务级逻辑从执行框架转移到模型中，部分系统复杂性也随之下沉到执行层。代码执行和沙箱现已成为智能体系统的核心架构议题，对重度编码和开放式任务而言尤其如此。设计智能体管线固然重要，但同样重要的是设计一个能让智能体长期安全、可靠运行的环境。
这正是沙箱执行的高层抽象至关重要的原因。新版 OpenAI Agents SDK 正朝这一方向发展，将执行视为系统的模块化层：可跨后端移植、在长时间运行的任务中保持状态，而且足够易用，无需为每种新配置重复构建同一套基础设施。
更广泛的启示是，下一代智能体框架的关键或许不在于增加多少编排逻辑，而在于能否妥善构建智能体日益依赖的执行环境。