OpenAI 给 Responses API 加上电脑：支持 Shell 与容器，不再只跑 Python

以往让 AI 帮你干活，最尴尬的莫过于让它改一段代码或拉取一段数据，它只能在 Python 解释器里打转。要是想装个依赖、跑个 Go 脚本或者启动一个本地服务，开发者就得自己搭一套沙箱环境，自己处理文件读写和报错重试。

OpenAI 在 3 月 11 日公布了针对 Responses API 的一系列重要升级。他们把原本只能处理提示词调用的接口，直接扩充成了一个带计算机环境的完整执行平台。从 GPT-5.2 开始的模型，不仅能直接写命令行，还能在 OpenAI 托管的隔离容器里真正跑起来。

扔掉单一的 Python 沙箱

这次最直接的改变是加入了 Shell 工具。以前官方提供的代码解释器基本只认 Python，现在的 Shell 工具则基于 Unix 环境打造，内置了 grep、curl、awk 等常用系统工具。

这意味着模型不再只是单纯生成代码，它可以直接启动一个 NodeJS 服务，或者编译运行 Go 和 Java 程序。只要模型判断某个任务需要调外部接口或筛选文件，它就会输出命令行指令，由 Responses API 提交给后台容器执行并流式拿回结果。

为了避免模型在长任务里被海量日志撑爆，OpenAI 还加了并发与输出截断机制。模型单次可以提出多个命令让容器并行跑，同时能设定字符上限，自动保留输出的开头与结尾，省略中间冗余部分。

像人类一样用文件系统和记忆压缩

另一个让开发者头疼的问题是上下文管理。很多团队以前为了让模型分析大表格，只能硬生生把整个 CSV 贴进 prompt，既费钱又容易超出上下文限制。

OpenAI 现在的做法是给容器配了独立的文件系统和 SQLite 数据库支持。开发者可以把数据直接存在容器里，模型根据表结构按需查询特定行，完全不用把整份数据塞进提示词。容器对外联网也受到策略控制，防止模型意外泄漏凭证或访问危险外链。

针对超长任务可能跑爆窗口的问题，API 增加了原生上下文压缩功能。模型会把之前的执行状态压缩成高信息密度的加密表示，只带上关键信息进入下一轮。有意思的是，OpenAI 透露 Codex 不仅是最早用上这个机制的用户，甚至还在研发过程中参与了自我排错：一个 Codex 实例遇到压缩 bug，工程师就让另一个 Codex 去排查修复。

为什么重要

对于做 Agent 应用的开发者来说，这一套组合拳基本免去了自己去折腾 Docker 编排、安全隔离和状态持久化的苦工。你现在可以直接用官方的端到端能力，把任务丢给 GPT-5.2，让它在后台自己拉取数据、跑服务并生成报告，门槛被大幅拉低。

对行业而言，OpenAI 的思路已经非常清晰：单纯卖 Token 和模型的时代正在过去，提供端到端的执行环境成了新的护城河。像 Anthropic 此前推出了让 AI 控制屏幕的方案，而 OpenAI 选择先从稳定的容器命令行切入，这种做法在我们看来更加务实，工程落地的确定性也更高。

不过这种重度绑定的平台化打法也有隐患。当存储、执行和上下文压缩全部托管在 OpenAI 内部，开发者的迁移成本会变得极高。另外，云端容器的网络权限控制哪怕设了策略，在复杂的自动化任务中依然需要团队极其谨慎，防止因指令越界引发安全事故。