OpenAI Agents SDK 添加了用于生产代理的本机沙箱、内存和线束控制
OpenAI 于 4 月 15 日发布的 Agents SDK 不仅仅是又一次 SDK 更新。这是堆栈的向上移动：从模型访问和工具调用到运行时层，它实际上决定了代理是否安全、耐用且可负担得起的操作。
OpenAI 实际发货了什么
OpenAI 表示，更新后的 SDK 现在为开发人员提供了一个模型原生工具，可以检查文件、运行命令、编辑代码以及跨长期任务进行操作。该版本添加了可配置内存、shell 和补丁原语、对 MCP 和技能风格渐进公开的支持，以及具有用于塑造工作空间的可移植清单模型的本机沙箱执行。
实际的转变是，OpenAI 正在打包代理工程中更多无聊但昂贵的部分：如何挂载文件、输出去哪里、容器死亡后如何恢复运行以及如何将凭证排除在模型生成的执行环境之外。
为什么这比其他工具列表更重要
大多数代理演示在生产中失败的原因相同：沙箱后期缝合在一起，提示状态与运行时状态混合，并且每次重试都从头开始。这将一个聪明的原型变成了令牌泄漏。 OpenAI 显然试图使默认路径更加固执己见：受控的工作空间、更清晰的线束边界以及通过快照和补水实现的持久执行。
这对于构建编码代理、研究代理、质量保证代理和内部工作流程自动化的团队来说很重要。现在，SDK 看起来不再像模型调用的包装器，而更像是 OpenAI 认为应如何构建生产代理的参考架构。
TRH 角度：运行时错误是令牌浪费
构建者经常关注模型选择而忽略运行时形状。那是倒退。嘈杂的线束中的强大模型仍然会浪费代币。宽内存存储、过度宽松的工具和重复使用的沙箱使代理收集的状态超过任务所需的状态。结果是重复的文件检查、过时的假设和永远不会改变最终工件的额外推理循环。
如果您希望每个付费计划交付更多工作，请像下面的设计一样设计线束。决定代理可以读取什么、可以在哪里写入、可以调用哪些工具、设置检查点的状态以及何时应停止运行而不是搜索更多上下文。
建设者下一步应该做什么
对于全新的代理，从最小的沙箱和最小的内存表面开始，仍然可以让任务成功。将凭据保留在代理执行的计算之外。记录收集的上下文、调用的工具和实际更改的文件之间的比率。如果该比率持续上升，则说明您的代理正在养成错误的习惯。
对于现有的自动化，此版本是一个很好的强制功能，可以审核您当前的工具是否正在执行过多的自定义工作，而 SDK 现在可以更安全地拥有这些工作。