OpenAI的工程师先抛出了一个观点单纯跟大模型对话你只是得到了“一棵树”而如果你为模型提供一个完整的计算机环境你将收获“一片森林”今天是 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。正是这种灵活性让模型能够完成更复杂的智能体任务。它是怎么工作的模型提议模型发现需要处理数据提议运行一段 Shell 命令。平台执行Responses API 在隔离的容器里执行命令。结果反馈执行结果如 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 SystemsOpenAI摒弃了把大数据往 Prompt 里塞的做法。现在你可以把文件上传到容器里让 AI 像人一样用ls和cat去按需读取。结构化数据库DatabasesAI 现在可以操作 SQLite。当你问“哪款产品销量下滑”时它不再盲目扫描全表而是精准写一条 SQL 语句查询结果。侧车Agent联网Network Access这是一个极其天才的设计。AI 联网时所有的请求都经过一个“侧车代理Sidecar Proxy”。a.安全敏感密钥被替换为占位符只有发送到获批域名时才会真正注入。b.可控开发者可以设置白名单防止 AI 乱跑。4、解决“健忘”原生的上下文压缩Compaction智能体循环中有一个大家极为关注的问题任务跑久了对话窗口满了怎么办为了在任务持续运行时保留重要信息同时删除冗余内容OpenAI 在 Responses API 中加入了原生的上下文压缩机制并让它与模型训练方式保持一致。而 OpenAI 最新的模型经过专门训练可以自动分析此前的对话状态并生成一个“压缩项”以加密且高效的 token 表示方式保留关键历史状态。压缩完成后新的上下文窗口将包含这个压缩项以及之前窗口中最有价值的部分内容。这样一来即使在长时间、多步骤、频繁调用工具的会话中工作流仍然可以保持连贯。这就像是给 AI 做了一份“精简会议纪要”既省钱节省 Token又保命不丢关键信息。趣闻这个压缩系统其实是 OpenAICodex团队帮着一块儿开发的。Codex 在自测时发现错误还会自己开个新实例去 Debug 修复自己。AI 进化指日可待。小编之前也报道过Codex 就依赖这一机制来维持长时间运行的编程任务以及持续的工具调用而不会出现质量下降。值得注意的是这种压缩机制既可以作为服务器内置能力也可以通过独立的/compact接口调用。服务器端压缩允许开发者设置一个阈值系统会自动决定何时执行压缩从而避免复杂的客户端逻辑。系统还允许输入上下文在压缩前略微超过限制这样接近上限的请求仍然可以被处理并压缩而不会直接被拒绝。随着模型训练不断演进这种原生压缩机制也会随着每次 OpenAI 模型发布持续升级。5、智能体技能Agent SkillsShell 命令非常强大但很多任务实际上会反复出现相同的多步骤模式。没有额外机制时智能体每次执行任务都需要重新发现工作流程重新规划、重新发出命令、重新学习约定。这会导致结果不稳定也会浪费执行资源。这时候就需要 Skills 出场了简单理解Agent Skills 的作用就是把这些模式封装成可复用、可组合的构建模块一个 skill 本质上是一个文件夹包其中包含SKILL.md存放元数据和说明以及任何必要的辅助资源例如 API 规范或 UI 资源。而 Skills 这种结构恰恰和前面描述的运行架构非常契合容器提供持久文件和运行环境而 shell 工具提供执行接口。有了这两部分模型就可以在需要时通过 shell 命令例如ls、cat发现技能文件读取说明并在同一个智能体循环中执行技能脚本。OpenAI 平台上提供了管理 skills 的 API。开发者可以把技能文件夹上传为带版本的 bundle然后通过 skill ID 在需要时取回。在把 prompt 发送给模型之前Responses API 会先加载 Skills并把它加入模型上下文。这个流程是确定性的获取技能元数据包括名称和描述获取技能 bundle把它复制到容器并解压更新模型上下文加入技能元数据以及容器中的路径当模型判断某个技能是否相关时它会逐步探索技能中的说明然后通过容器中的 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