核心摘要
- 环境沙箱化：OpenAI 推出结合 Responses API 的 shell 终端和原生托管容器环境（Container Workspace）。通过这套基建，Agent 现在不仅能“提议操作”，还能在一个隔离的真实 Linux 环境里“执行命令”。
- 解决基建痛点：过去开发者构建 agent 时面临的安全限制、状态存储、重试与网络访问等麻烦的底层问题，如今均可由 Responses API 原生接管：它包含生命周期一致的文件系统、SQLite 隔离存储以及白名单式的网络管理。
- 上下文压缩技术：为了防止反复的 CLI 操作（比如 grep 生成大段无用文本）挤爆 Token 上下文窗口，OpenAI 引入了底层级自动过滤与折叠功能，只将有效结果或报错状态反馈到对话上下文中。
原文链接 Original English Version
作者：Bo Xu, Danny Zhang, 及其 Rohit Arunachalam
目前，我们正处于一个从单纯使用执行特定任务擅长的“基础模型”，向使用能够处理复杂工作流的“核心智能体（Agents）”转变的时期。单纯向模型输入提示词，意味着您只能访问它在预训练阶段被投喂过的静态智能。然而，如果能为该模型提供一个真正的计算机执行环境，它的应用场景将极大地扩展：例如运行微服务、从各种 API 获取实时数据，或是直接输出类似于电子表格或长报告的终极可用产物。
当您尝试在本地构建这种自主智能体时，往往会面临一系列棘手的工程问题：过程生成的中间文件该放在哪？怎么避免把一张超大的数据表直接粘贴进你的 Prompt 里导致超出长度？该如何为它的长链条工作流开放受控的网络权限而又不引发系统灾难？如何在不用从零自己写一套 DAG 工作流引擎的前提下处理各种 API 的超时与重试？
现在，开发团队不再需要自己去构建这类代码的运行沙盒（Execution environments）。我们为 Responses API 构建了原生必备的运行组件，直接为 API 接入一台虚拟的计算机环境，以便它能够可靠地在现实世界中执行任务。
OpenAI 的 Responses API 搭配了全新的 shell 终端工具和托管环境容器（hosted container workspace），专门被设计用来解决上述开发痛点。该模型会“提出”它的执行步骤和终端命令；随后平台会将它们拿到一个沙箱化的、完全隔离的环境中去运行。在这个环境里自带完整的输入输出文件系统、可选的结构化存储方案（例如 SQLite 库），同时网络限制也处于严格管控之下。
在这篇文章中，我们将带大家拆解：我们是如何一步步为智能体搭建这样一套操作系统层的，并且分享我们得到的一些初步经验，展示开发者可以如何借此来实现更小延迟配置、更高并发度以及更安全的生产环境工作流。
一个优秀的 Agent 工作流往往源自一个严密的执行反馈闭环（Execution loop）：模型提议采取什么操作（如读取文件或者发送 API 请求调取数据），随后平台将其执行落地，并且原样把终端里的输出结果返回给下一个链条作参考。我们将从 shell 工具讲起——它是观察这个执行闭环最直观的窗口——之后我们会覆盖讲述容器的工作空间、网络环境、可复用技能卡片，以及至关重要的上下文压缩（Context compaction）机制。
为了彻底理解何谓 shell tool，我们首先应该回头理解大语言模型在更广义层面上是如何看待“工具使用（Tool Use / Function Calling）”的：无非就是让其调用一个固定结构的函数或是和一台具体的电脑发生交互。
在受训阶段，我们会向模型展示大量的工具使用案例（即触发动作和随后的产生效果，一步接一步的逻辑拆解）。这有助于模型学会并预判在某个情境下“何时用工具”以及到底“怎么用工具”。然而，我们在过去谈论所谓“使用工具”时，我们指的仅仅是“模型成功提供了一次请求调用（proposes a tool call）”，基础的语言模型此前实际上并不能自己完成那个函数的执行环节（它不得不等待客户端程序把运行结果带着回填进去）。
而此次加入 API 阵营的shell tool使模型变得前所未有一致的强大：它能够直接越过人类中介、通过命令行在计算机上与之交互执行任务，能够做到的事情可以从最基础的本地文本检索涵盖到复杂的发送 API 数据请求。因为该环境底层构筑于最为人熟知的 Unix 工具链，因此您所熟悉的如 grep、curl 以及 awk 等原生套件，都可以立刻开箱即用。
(全文总结部分节选翻译)
开发者行动指南： 我们鼓励您将需要大体量操作或重复批处理循环的工作直接移交部署至有状态驱动的计算机级环境中，通过隔离与安全的 Responses API 及其 Shell Tool 重大拓展 AI 的工作能力边界。