目 录CONTENT

文章目录

为Responses API配备计算机环境:从模型到智能体

Administrator
2026-03-12 / 0 评论 / 0 点赞 / 0 阅读 / 0 字

📢 转载信息

原文链接:https://openai.com/index/equip-responses-api-computer-environment

原文作者:Bo Xu, Danny Zhang, and Rohit Arunachalam


我们正处于一个从擅长特定任务的模型转向能够处理复杂工作流程的智能体的转变之中。通过提示模型,你只能获取已训练的智能。然而,为模型提供一个计算机环境可以实现更广泛的用例,例如运行服务、从API请求数据,或者生成更有用的制品,如电子表格或报告。

当你尝试构建智能体时,会出现一些实际问题:中间文件存放在哪里、如何避免将大表格粘贴到提示中、如何在不引发安全难题的情况下为工作流提供网络访问权限,以及如何在不自己构建工作流系统的情况下处理超时和重试。

我们没有将构建执行环境的责任推给开发者,而是构建了必要的组件,为 Responses API 配备了一个计算机环境,以可靠地执行现实世界的任务。

OpenAI的Responses API,连同Shell工具和一个托管的容器工作区,旨在解决这些实际问题。模型提出步骤和命令;平台在隔离的环境中运行它们,该环境具有用于输入和输出的文件系统、可选的结构化存储(如SQLite)以及受限的网络访问。

在本文中,我们将分解我们如何为智能体构建一个计算机环境,并分享一些关于如何使用它来实现更快、更可重复和更安全的产品工作流的初步经验。

Shell工具

一个好的智能体工作流始于一个紧密的执行循环:模型提出一个操作(如读取文件或通过API获取数据),平台执行该操作,然后将结果反馈给下一步。我们将从Shell工具开始——这是观察此循环运行的最简单方法——然后介绍容器工作区、网络、可重用技能和上下文压缩。

要理解Shell工具,首先了解语言模型如何使用工具(Tool)至关重要:例如调用函数或与计算机交互。在训练期间,模型会逐步看到如何使用工具及其结果影响的示例。这有助于模型学习何时使用工具以及如何使用工具。当我们说“使用工具”时,我们指的是模型实际上只提出了一个工具调用。它不能自行执行该调用。

The shell tool is "just another tool" with diagram

Shell工具使模型功能得到极大增强:它通过命令行与计算机交互,以执行广泛的任务,从搜索文本到在你的计算机上发送API请求。我们的Shell工具基于熟悉的Unix工具构建,开箱即用地提供了grepcurlawk等实用程序,可以完成你所期望的任何操作。

与我们现有的只能执行Python的代码解释器相比,Shell工具支持更广泛的用例,例如运行Go或Java程序或启动NodeJS服务器。这种灵活性使模型能够完成复杂的智能体任务。

编排智能体循环

模型本身只能提出Shell命令,但这些命令是如何执行的呢?我们需要一个编排器来获取模型输出、调用工具,并将工具响应在一个循环中传回给模型,直到任务完成。

Responses API是开发人员与OpenAI模型交互的方式。当与自定义工具一起使用时,Responses API将控制权交还给客户端,而客户端需要自己的用于运行工具的框架(harness)。然而,此API也可以开箱即用(out of the box)地在模型和托管工具之间进行编排。

当Responses API收到提示时,它会组合模型上下文:用户提示、先前的对话状态和工具说明。要使Shell执行正常工作,提示中必须提及使用Shell工具,并且所选模型必须经过训练以提出Shell命令——GPT‑5.2及更高版本的模型为此进行了训练。有了所有这些上下文,模型就会决定下一步操作。如果它选择Shell执行,它会向Responses API服务返回一个或多个Shell命令。API服务将这些命令转发到容器运行时,将Shell输出流式传输回来,并在下一个请求的上下文中将其提供给模型。然后,模型可以检查结果、发出后续命令或生成最终答案。Responses API会重复此循环,直到模型返回一个不带额外Shell命令的完成响应。

Agent loop diagram: Responses API orchestrates model and shell execution in container

当Responses API执行Shell命令时,它会与容器服务维护一个流式连接。随着输出产生,API几乎实时地将其中继给模型,这样模型就可以决定是等待更多输出、运行另一个命令,还是进行到最终响应。

Streaming shell command execution output
Responses API会流式传输Shell命令的输出

模型可以在一步中提出多个Shell命令,并且Responses API可以使用单独的容器会话并发执行它们。每个会话独立地流式传输输出,API将这些流多路复用回结构化的工具输出作为上下文。换句话说,智能体循环可以并行化工作,例如搜索文件、获取数据和验证中间结果。

Responses API multiplexes command execution sessions

当命令涉及文件操作或数据处理时,Shell输出可能会变得非常大,并在不增加有用信号的情况下消耗上下文预算。为了控制这一点,模型会为每个命令指定一个输出上限。Responses API强制执行该上限,并返回一个有限的结果,该结果保留了输出的开头和结尾,同时标记了被省略的内容。例如,你可以将输出限制为1000个字符,并保留开头和结尾:

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

并发执行有限输出共同作用,使智能体循环既快速又高效地利用上下文,这样模型就可以持续对相关结果进行推理,而不是被原始终端日志淹没。

当上下文窗口满载时:压缩

智能体循环的一个潜在问题是任务可能运行很长时间。长时间运行的任务会填满上下文窗口,这对于跨轮次和跨智能体提供上下文非常重要。想象一个智能体调用一个技能,得到一个响应,添加工具调用和推理摘要——有限的上下文窗口会很快填满。为了在智能体继续运行时避免丢失重要上下文,我们需要一种方法来保留关键细节并移除任何多余内容。我们没有要求开发者设计和维护自定义的摘要或状态携带系统,而是在Responses API中添加了原生压缩功能,旨在与模型的行为及其训练方式保持一致。

我们最新的模型经过训练,可以分析先前的对话状态,并生成一个压缩项,以加密的、高效的Token表示形式保留关键的先前状态。压缩后,下一个上下文窗口将由这个压缩项和先前窗口的高价值部分组成。这使得工作流能够在窗口边界上保持连贯性,即使在扩展的多步骤和工具驱动的会话中也是如此。Codex 依赖于这种机制来维持长时间的编码任务和迭代工具执行,而不会降低质量。

压缩可以通过内置在服务器端或通过一个独立的/compact端点来使用。服务器端压缩允许你配置一个阈值,系统会自动处理压缩时机,无需复杂的客户端逻辑。它允许一个稍大的有效输入上下文窗口来容忍压缩前的小额超额,这样接近限制的请求仍可以被处理和压缩,而不是被拒绝。随着模型训练的演进,原生压缩解决方案会随着每一次OpenAI模型发布而不断发展。

Codex在为它提供服务的同时,也帮助我们构建了压缩系统。当一个Codex实例遇到压缩错误时,我们会启动第二个实例进行调查。结果是,Codex通过解决这个问题获得了原生、有效的压缩系统。Codex这种检查和完善自身的能力,已成为在OpenAI工作的一个特别有趣的部分。大多数工具只要求用户学习如何使用它们;Codex与我们一起学习。

容器上下文

现在我们来介绍状态和资源。容器不仅是运行命令的地方,也是模型的工作上下文。在容器内部,模型可以在网络策略控制下读取文件、查询数据库和访问外部系统。

A diagram that shows inside the runtime container: Files, databases, skills, and a policy-controlled network

文件系统

容器上下文的第一部分是用于上传、组织和管理资源的文件系统。我们构建了containerfile API,为模型提供可用数据的地图,并帮助它选择有针对性的文件操作,而不是执行广泛而嘈杂的扫描。

一种常见的反模式是将所有输入直接打包到提示上下文中。随着输入的增长,提示会过度填充,这既昂贵又难以让模型导航。一个更好的模式是将资源暂存在容器文件系统中,让模型决定使用Shell命令打开、解析或转换哪些内容。就像人类一样,模型在使用组织良好的信息时表现更好。

数据库

容器上下文的第二部分是数据库。在许多情况下,我们建议开发人员将结构化数据存储在SQLite等数据库中并进行查询。例如,你不需要将整个电子表格复制到提示中,而是可以向模型提供表的描述——包含哪些列以及它们的含义——让它只提取所需的行。

例如,如果你问:“本季度哪些产品的销售额下降了?”模型可以只查询相关的行,而不是扫描整个电子表格。这更快、更便宜、对大型数据集更具可扩展性。

网络访问

容器上下文的第三部分是网络访问,这是智能体工作负载的关键组成部分。智能体工作流可能需要获取实时数据、调用外部API或安装包。同时,为容器提供不受限制的互联网访问可能存在风险:它可能向外部网站泄露信息、无意中接触敏感的内部或第三方系统,或者使凭证泄露和数据渗出更难防范。

为了在不限制智能体实用性的情况下解决这些担忧,我们构建了托管容器,使其使用旁路出口代理(sidecar egress proxy)。所有出站网络请求都流经一个集中的策略层,该策略层执行允许列表和访问控制,同时保持流量的可观察性。对于凭证,我们在出口时使用域范围的密钥注入。模型和容器只能看到占位符,而原始密钥值则保留在模型可见的上下文之外,并且仅应用于已批准的目的地。这降低了泄露的风险,同时仍然支持经过身份验证的外部调用。

Diagram of controlled network access via access egress proxy: container setup

智能体技能

Shell命令非常强大,但许多任务会重复相同的多步骤模式。智能体每次运行时都必须重新发现工作流——重新规划、重新发出命令和重新学习约定——这会导致结果不一致和执行浪费。Agent skills 将这些模式打包成可重用、可组合的构建块。具体来说,一个技能是一个文件夹包,其中包含SKILL.md(包含元数据和说明)以及任何支持资源,例如API规范和UI资产。

这种结构自然地映射到我们前面描述的运行时架构。容器提供持久文件和执行上下文,而Shell工具提供执行接口。在两者都就位的情况下,模型可以在需要时使用Shell命令(如lscat等)发现技能文件,解释说明,并在同一个智能体循环中运行技能脚本。

我们提供API来管理OpenAI平台上的技能。开发人员将技能文件夹作为版本化包上传和存储,之后可以通过技能ID检索。在将提示发送给模型之前,Responses API会加载技能并将其包含在模型上下文中。这个顺序是确定的:

  1. 获取技能元数据,包括名称和描述。
  2. 获取技能包,将其复制到容器中并解压。
  3. 使用技能元数据和容器路径更新模型上下文。

在决定一个技能是否相关时,模型会逐步探索其说明,并通过容器中的Shell命令执行其脚本。

Skill loading pipeline diagram: registry, bundle, runtime

智能体的构建方式

将所有部件组合在一起:Responses API 提供编排Shell工具提供可执行操作托管容器提供持久运行时上下文技能层提供可重用工作流逻辑,而压缩则允许智能体在所需的上下文中长时间运行。

有了这些基本组件,单个提示就可以扩展为端到端工作流:发现正确的技能、获取数据、将其转换为本地结构化状态、高效查询它,并生成持久的制品。

下图展示了该系统如何协作,以根据实时数据创建电子表格。

Diagram of request lifecycle: from one prompt to durable artifacts, skill discovery
Responses API编排智能体任务

构建你自己的智能体

要深入了解如何将Shell工具和计算机环境结合用于端到端工作流,请参阅我们的开发者博客文章Cookbook,其中逐步介绍了如何打包技能并通过Responses API执行它。

我们很高兴看到开发者使用这套基本组件构建出什么。语言模型的用途不仅仅是生成文本、图像和音频——我们将继续发展我们的平台,使其在处理复杂、真实的任务和规模化方面更具能力。




🚀 想要体验更好更全面的AI调用?

欢迎使用青云聚合API,约为官网价格的十分之一,支持300+全球最新模型,以及全球各种生图生视频模型,无需翻墙高速稳定,文档丰富,小白也可以简单操作。

0

评论区