刚刚，OpenAI自曝：内部如何把“最新GPT模型”改造成“长时程干活智能体”！

今天是 OpenAI Responses API 上线一周年。OpenAI 又出来抖猛料了！

OpenAI 刚刚发布了一篇重磅技术文章，讲述了团队是如何把自家大模型从聊天工具改成一款真正能完成复杂任务的智能体的！

作者是 OpenAI的三位工程师：Bo Xu、Danny Zhang、Rohit Arunachalam。

这篇文章中公开了OpenAI一套新的 Agent 运行架构。

你给它一个需求，它会自己规划步骤、运行程序、查询数据、生成文件，甚至调用外部系统。整个过程就像一个真正的数字员工。

而支撑这一切的核心组件，是：OpenAI Responses API，再加上一整套为智能体准备的运行环境。

开源大神 Simon 闻讯赶来，看罢，甚至已经分不清文中提及许多核心技术，是OpenAI 新推出的，还是对过往技术的总结。

话不多说，这就让我们看看 OpenAI 是如何让擅长单一任务的 GPT 模型向能处理多个复杂任务的“智能体”，完成惊险一跳的？

构建AI智能体的几个痛点

OpenAI的工程师先抛出了一个观点，单纯跟大模型对话，你只是得到了“一棵树”，而如果你为模型提供一个完整的计算机环境，你将收获“一片森林”！

通过提示（prompt）调用模型，你只能访问模型已经训练好的智能能力。

而如果为模型提供一个完整的计算机环境，它能够覆盖的使用场景会大幅扩大，例如运行服务、从 API 请求数据，或者生成更有价值的成果物，比如电子表格或报告。

但问题来了，如何提供呢？作者们指出，构建这样复杂的智能体时，很快就会遇到一些实际问题：

• 中间文件放哪？ AI 生成了一个表格，难道要顺着对话框贴出几万行代码？如何避免把巨大的数据表直接粘进提示词？

• 安全怎么搞？ 给 AI 联网权限，万一它把你的数据库删了或者泄露了密钥怎么办？怎样在不给系统带来安全风险的情况下让工作流访问网络？

• 上下文爆掉： 任务稍微复杂一点，对话记录就长到模型“断片”记不住前面的事。

• 超时和重试：如何处理？而不必自己再构建一整套工作流系统？

OpenAI的答案：给模型一台隔离的“电脑”

为了解决这些，OpenAI自研了一套组件式的解决方案。

构建必要的组件来支持Responses API，利用计算机环境可靠地执行现实世界的任务。

具体讲，OpenAI 的 Responses API 结合 shell 工具和托管容器工作空间，而模型会提出步骤和命令；

平台则在一个隔离环境中运行这些步骤和命令，该环境配备用于输入和输出的文件系统、可选的结构化存储（例如 SQLite）以及受限的网络访问。 

OpenAI团队的早期经验教训

1、核心大招：Shell Tool

一个优秀的智能体工作流程始于一个紧凑的执行循环：模型提出一个操作（例如读取文件或通过 API 获取数据），平台执行该操作，并将结果传递给下一步。

文章指出， Shell Tool 正是观察此循环运行的最简单方法。

同时，作者们解释了一个极重要的概念：模型如何使用工具（比如调用函数或计算机交互）。

其实，语言模型只是在训练过程中，逐步学习了工具的使用示例及其产生的效果。这有助于模型学习何时以及如何使用工具。

而我们所说的“使用工具”，实际上是指模型只是提出工具调用方案，它本身并不能执行该调用。

而理解了这个概念之后，我们就可以把 Shell 工具也视为“另一种工具”。它让模型的能力大幅提升：模型可以通过命令行与计算机交互，从而完成大量任务，例如搜索文本或在本机发送 API 请求。

这个工具比大家熟悉的代码解释器更有优势。以前的 Code Interpreter 只能跑 Python，现在的 Shell Tool 可以说是开了挂。它基于熟悉的 Unix 工具链构建，默认就支持 curl、grep、awk等所有命令行环境的操作，甚至能运行 Go、Java 或 NodeJS。

正是这种灵活性，让模型能够完成更复杂的智能体任务。

它是怎么工作的？

1. 模型提议： 模型发现需要处理数据，提议运行一段 Shell 命令。
2. 平台执行： Responses API 在隔离的容器里执行命令。
3. 结果反馈： 执行结果（如 API 返回的 JSON 或抓取到的网页）实时传回给模型。

2、智能体循环的编排

单独的模型只能提出 shell 命令，但这些命令如何真正执行？这就需要一个编排器（orchestrator），它负责接收模型输出、调用工具、再把工具返回的结果交给模型，如此循环，直到任务完成。

开发者通常通过 OpenAI Responses API 与 OpenAI 模型交互。当配合自定义工具使用时，Responses API 会把控制权交还给客户端，由客户端运行工具。但它同样可以在默认情况下直接在模型与托管工具之间完成编排。

当 Responses API 接收到一个提示词时，它会构建模型上下文：包括用户提示、之前的对话状态，以及工具说明。为了让 shell 执行生效，提示词中必须说明要使用 shell 工具，并且所选模型需要接受过提出 shell 命令的训练——从 GPT-5.2 开始的模型已经具备这种能力。

Responses API 的流式传输 Shell命令

在这些上下文信息的基础上，模型会决定下一步行动。如果模型选择执行 shell，它会返回一个或多个 shell 命令给 Responses API 服务。API 服务会把这些命令发送到容器运行环境中执行，将 shell 输出实时返回，并在下一次请求中作为上下文提供给模型。

接下来模型可以检查执行结果，提出新的命令，或者给出最终答案。Responses API 会不断重复这个循环，直到模型返回一个不包含 shell 命令的最终结果。

当 Responses API 执行 shell 命令时，它会与容器服务保持流式连接。一旦命令产生输出，API 会几乎实时地把结果传递给模型，让模型决定是继续等待更多输出、执行新的命令，还是直接生成最终回答。

模型在一次步骤中也可以提出多个 shell 命令。Responses API 可以通过多个容器会话并发执行这些命令。每个会话都会独立流式返回输出，API 会把这些输出整合为结构化工具结果，再提供给模型作为上下文。换句话说，智能体循环可以并行处理多项任务，例如同时搜索文件、获取数据和验证中间结果。

当命令涉及文件操作或数据处理时，shell 输出可能非常庞大。如果这些内容全部进入上下文，会迅速消耗上下文窗口却未必提供有效信息。为了解决这个问题，模型可以为每个命令指定输出上限。Responses API 会强制执行这个限制，并返回一个被截断但保留开头和结尾的结果，同时标记被省略的内容。例如：

text at the beginning ... 1000 chars truncated ... text at the end

并发执行与输出限制结合在一起，使智能体循环既快速又节省上下文空间，模型可以专注于关键结果，而不会被大量终端日志淹没。

3、三大基石：文件、数据库、安全联网

此外，OpenAI 还为这个“计算机环境”打造了三个核心组件：

• 文件系统（File Systems）： OpenAI摒弃了把大数据往 Prompt 里塞的做法。现在你可以把文件上传到容器里，让 AI 像人一样用 ls 和 cat 去按需读取。

• 结构化数据库（Databases）： AI 现在可以操作 SQLite。当你问“哪款产品销量下滑”时，它不再盲目扫描全表，而是精准写一条 SQL 语句查询结果。

• 侧车Agent联网（Network Access）： 这是一个极其天才的设计。AI 联网时，所有的请求都经过一个“侧车代理（Sidecar Proxy）”。

• 安全： 敏感密钥被替换为占位符，只有发送到获批域名时才会真正注入。

• 可控： 开发者可以设置白名单，防止 AI 乱跑。

4、解决“健忘”：原生的上下文压缩（Compaction）

智能体循环中，有一个大家极为关注的问题：任务跑久了，对话窗口满了怎么办？

为了在任务持续运行时保留重要信息，同时删除冗余内容，OpenAI 在 Responses API 中加入了原生的上下文压缩机制，并让它与模型训练方式保持一致。

而 OpenAI 最新的模型经过专门训练，可以自动分析此前的对话状态，并生成一个“压缩项”，以加密且高效的 token 表示方式保留关键历史状态。

压缩完成后，新的上下文窗口将包含这个压缩项以及之前窗口中最有价值的部分内容。这样一来，即使在长时间、多步骤、频繁调用工具的会话中，工作流仍然可以保持连贯。

这就像是给 AI 做了一份“精简会议纪要”，既省钱（节省 Token），又保命（不丢关键信息）。

趣闻： 这个压缩系统其实是 OpenAI Codex 团队帮着一块儿开发的。Codex 在自测时发现错误，还会自己开个新实例去 Debug 修复自己。AI 进化，指日可待。

小编之前也报道过，Codex 就依赖这一机制来维持长时间运行的编程任务，以及持续的工具调用，而不会出现质量下降。

值得注意的是，这种压缩机制既可以作为服务器内置能力，也可以通过独立的 /compact 接口调用。服务器端压缩允许开发者设置一个阈值，系统会自动决定何时执行压缩，从而避免复杂的客户端逻辑。

系统还允许输入上下文在压缩前略微超过限制，这样接近上限的请求仍然可以被处理并压缩，而不会直接被拒绝。

随着模型训练不断演进，这种原生压缩机制也会随着每次 OpenAI 模型发布持续升级。

5、智能体技能（Agent Skills）

Shell 命令非常强大，但很多任务实际上会反复出现相同的多步骤模式。没有额外机制时，智能体每次执行任务都需要重新发现工作流程：重新规划、重新发出命令、重新学习约定。这会导致结果不稳定，也会浪费执行资源。

这时候就需要 Skills 出场了！

简单理解，Agent Skills 的作用就是把这些模式封装成可复用、可组合的构建模块

一个 skill 本质上是一个文件夹包，其中包含 SKILL.md（存放元数据和说明），以及任何必要的辅助资源，例如 API 规范或 UI 资源。

而 Skills 这种结构，恰恰和前面描述的运行架构非常契合：容器提供持久文件和运行环境，而 shell 工具提供执行接口。

有了这两部分，模型就可以在需要时通过 shell 命令（例如 ls、cat）发现技能文件，读取说明，并在同一个智能体循环中执行技能脚本。

OpenAI 平台上提供了管理 skills 的 API。开发者可以把技能文件夹上传为带版本的 bundle，然后通过 skill ID 在需要时取回。

在把 prompt 发送给模型之前，Responses API 会先加载 Skills，并把它加入模型上下文。这个流程是确定性的：

1. 获取技能元数据，包括名称和描述
2. 获取技能 bundle，把它复制到容器并解压
3. 更新模型上下文，加入技能元数据以及容器中的路径

当模型判断某个技能是否相关时，它会逐步探索技能中的说明，然后通过容器中的 shell 命令执行相应脚本。

最后一步：智能体是如何造出来的？

组件、机制都已经准备后，让大模型变身智能体就差临门一脚：组合拼装。

拼在一起的整体结构非常清晰：

• OpenAI Responses API 负责任务编排

• shell 工具负责执行操作

• 托管容器提供持久化运行上下文

• skills 提供可复用的工作流逻辑

• 上下文压缩（compaction）让智能体能够在长时间任务中保持所需的上下文

借助这些基础原语，一个简单的 prompt 就可以扩展成完整的端到端工作流：发现合适的技能、获取数据、把数据转化为本地结构化状态、高效查询数据，并生成持久化成果。

例如，系统可以根据一个请求自动完成以下流程：

Skills 发现 → 任务规划与环境准备 → 数据获取 → 数据处理 → 成果生成（如电子表格等）

整个过程由 OpenAI Responses API 在后台完成编排。

篇幅关系，这里仅列出Responses API 第一步“Skills 发现”的编排示意图。感兴趣的可以移步 OpenAI 官网博客。

网友：价值含量超高

表面上看，这篇文章是在解释 Responses API 的内部机制，但本质上其实就是一篇公开OpenAI团队如何构建通用智能体的技术手册！

网友们纷纷评价：这要比花哨的 Demo 有价值多了！

有价值的地方可不少。比如一家社区评论道：

缩短执行循环是关键所在。OpenAI这次的文章解决了大多数智能体延迟的问题：比如处理跨文件系统的状态持久化所遇到的瓶颈问题等，是一场重大的机制更新。

不少网友也对于 OpenAI 文中提出的缩短的智能体循环感到惊艳！

另外，还有网友表示，OpenAI提出的安全防护机制的重要性也被低估了。

当然，最多反馈有价值的地方，还是长时程运行智能体的工作流的设计！

参考链接：

https://openai.com/index/equip-responses-api-computer-environment/

https://x.com/OpenAIDevs/status/2031798071345234193

文章来自于“51CTO技术栈”，作者 “云昭”。