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

# 从模型到代理：为响应API配备计算机环境 来源：https://openai.com/index/equip-responses-api-computer-environment/ 我们正经历一场转变：从擅长特定任务的模型，转向能够处理复杂工作流的代理。通过提示模型，你只能访问其训练获得的智能。然而，为模型提供一个计算机环境，可以实现更广泛的用例，例如运行服务、从API请求数据、或生成更实用的产出物（如电子表格或报告）。 当你尝试构建代理时，会出现一些实际问题：中间文件放在哪里？如何避免将大型表格粘贴到提示中？如何在不造成安全难题的情况下为工作流提供网络访问？如何在不自行构建工作流系统的情况下处理超时和重试？ 我们没有让开发者自行构建执行环境，而是构建了必要的组件，为`响应API`（在新窗口中打开）（https://developers.openai.com/api/docs/guides/migrate-to-responses）配备一个计算机环境，以可靠地执行真实世界任务。 OpenAI的响应API，结合shell工具和托管的容器工作区，旨在解决这些实际问题。模型提出步骤和命令；平台在一个隔离的环境中运行它们，该环境包含用于输入输出的文件系统、可选的结构化存储（如SQLite），以及受限的网络访问。 在这篇文章中，我们将分解我们如何为代理构建计算机环境，并分享一些早期经验，以说明如何使用它来实现更快、更可重复、更安全的生产工作流。 一个良好的代理工作流始于一个紧密的执行循环：模型提出动作（如读取文件或通过API获取数据），平台执行它，结果流入下一步。我们将从shell工具开始——这是观察这个循环的最简单方式——然后介绍容器工作区、网络、可重用技能以及上下文压缩。 要理解shell工具，首先需要了解语言模型通常如何使用工具：执行函数调用或与计算机交互等操作。在训练过程中，模型会看到工具如何被使用以及产生的效果，一步步进行。这帮助模型学习何时使用工具以及如何使用。当我们说“使用工具”时，意味着模型实际上只提出工具调用，它本身无法执行调用。 shell工具使模型变得异常强大：它通过命令行与计算机交互，执行从搜索文本到在你的计算机上发送API请求等广泛任务。基于熟悉的Unix工具，我们的shell工具可以执行你期望的任何操作，开箱即可使用`grep`、`curl`和`awk`等实用程序。 与我们现有的仅执行Python的代码解释器相比，shell工具支持更广泛的用例，例如运行Go或Java程序，或启动NodeJS服务器。这种灵活性使模型能够完成复杂的代理任务。 单独来看，模型只能提出shell命令，但这些命令如何执行？我们需要一个编排器来获取模型输出、调用工具，并将工具响应循环返回给模型，直到任务完成。 响应API是开发者与OpenAI模型交互的方式。当与自定义工具一起使用时，响应API将控制权交还给客户端，客户端需要自己的工具运行框架。然而，该API也可以开箱即用地在模型和托管工具之间进行编排。 当响应API收到提示时，它会组装模型上下文：用户提示、先前的对话状态和工具指令。要使shell执行生效，提示必须提及使用shell工具*并且*所选模型必须经过训练以提出shell命令——模型GPT-5.2及更高版本为此进行了训练。基于所有这些上下文，模型决定下一步动作。如果选择shell执行，它将向响应API服务返回一个或多个shell命令。API服务将这些命令转发给容器运行时，流式返回shell输出，并将其作为下一个请求的上下文输入给模型。然后模型可以检查结果、发出后续命令或生成最终答案。响应API重复此循环，直到模型返回完成且没有额外的shell命令。 当响应API执行shell命令时，它会维护与容器服务的流式连接。随着输出的产生，API几乎实时地将其中继给模型，以便模型决定是等待更多输出、运行另一个命令还是转向最终响应。 *响应API流式传输shell命令输出* 模型可以在一个步骤中提出多个shell命令，响应API可以使用单独的容器会话并发执行它们。每个会话独立流式输出，API将这些流多路复用回结构化的工具输出作为上下文。换句话说，代理循环可以并行化工作，例如搜索文件、获取数据和验证中间结果。 当命令涉及文件操作或数据处理时，shell输出可能会变得非常大，消耗上下文预算而不增加有用信号。为了控制这一点，模型为每个命令指定一个输出上限。响应API强制执行该上限，并返回一个受限的结果，保留输出的开头和结尾，同时标记省略的内容。例如，你可以将输出限制为1000个字符，保留开头和结尾： `开头的文本 ... 截断了1000个字符 ... 结尾的文本` 并发执行和受限输出共同使代理循环既快速又节省上下文，因此模型可以继续对相关结果进行推理，而不会被原始的终端日志淹没。 代理循环的一个潜在问题是任务可能运行很长时间。长时间运行的任务会填满上下文窗口，这对于跨轮次和跨代理提供上下文非常重要。想象一个代理调用技能、获得响应、添加工具调用和推理总结——有限的上下文窗口很快就会被填满。为了避免代理继续运行时丢失重要上下文，我们需要一种方法保留关键细节并删除无关内容。我们不要求开发者设计并维护自定义的摘要或状态携带系统，而是在响应API中增加了原生压缩功能，旨在与模型的行为和训练方式对齐。 我们的最新模型经过训练，能够分析先前的对话状态并生成一个压缩项，以加密的、令牌高效的方式保留关键的先前状态。压缩后，下一个上下文窗口由这个压缩项和先前窗口中高价值的部分组成。这使得工作流能够在窗口边界上连贯地继续，即使在扩展的多步骤和工具驱动的会话中也是如此。`Codex依赖此机制`（https://openai.com/index/unrolling-the-codex-agent-loop/）来维持长时间运行的编码任务和迭代工具执行，而不会降低质量。 压缩既可以在服务器端内置使用，也可以通过一个独立的`/compact`端点使用。服务器端压缩允许你配置一个阈值，系统自动处理压缩时机，消除了复杂的客户端逻辑需求。它允许稍大的有效输入上下文窗口，以容忍压缩前的小幅度超量，因此接近限制的请求仍然可以被处理并压缩，而不是被拒绝。随着模型训练的演进，原生压缩方案会随着每个OpenAI模型版本一同进化。 Codex帮助我们构建了压缩系统，同时也作为它的早期用户。当一个Codex实例遇到压缩错误时，我们会启动第二个实例进行调查。结果就是，Codex通过解决这个问题得到了一个原生的、有效的压缩系统。这种Codex自我检查和改进的能力已经成为OpenAI工作中尤其有趣的部分。大多数工具只要求用户学习如何使用它们；而Codex与我们一同学习。 现在我们来谈谈状态和资源。容器不仅仅是运行命令的地方，也是模型的工作上下文。在容器内部，模型可以读取文件、查询数据库，并在网络策略控制下访问外部系统。 容器上下文的第一个部分是文件系统，用于上传、组织和管理资源。我们构建了`容器和文件API`（在新窗口中打开）（https://developers.openai.com/api/reference/resources/containers），为模型提供可用数据的映射，帮助它选择有针对性的文件操作，而不是进行广泛、有噪声的扫描。 一个常见的反模式是将所有输入直接打包到提示上下文中。随着输入增长，过度填充提示变得昂贵且模型难以导航。更好的模式是将资源暂存到容器文件系统中，让模型决定使用shell命令打开、解析或转换什么。与人类类似，模型在信息组织有序时工作得更好。 容器上下文的第二个部分是数据库。在许多情况下，我们建议开发者将结构化数据存储为SQLite数据库并进行查询。例如，与其将整个电子表格复制到提示中，不如给模型一个表描述——有哪些列，它们的含义——然后让它拉取需要的行。 例如，如果你问“哪些产品本季度销售额下降？”，模型可以查询*仅*相关的行，而不是扫描整个电子表格。这样更快、更便宜，且对更大数据集更可扩展。 容器上下文的第三个部分是网络访问，这是代理工作负载的重要组成部分。代理工作流可能需要获取实时数据、调用外部API或安装软件包。同时，给容器不受限制的互联网访问可能存在风险：它可能向外部网站暴露信息，无意中触及敏感的内部或第三方系统，或者使凭证泄露和数据外流更难防范。 为了在不限制代理有用性的情况下解决这些问题，我们构建了使用边车出口代理的托管容器。所有出站网络请求都通过一个集中的策略层，该层强制执行白名单和访问控制，同时保持流量可观测。对于凭证，我们在出口时使用领域范围的秘密注入。模型和容器只看到占位符，而原始秘密值保持在模型可见上下文之外，并且仅应用于批准的目标。这降低了泄露风险，同时仍支持经过身份验证的外部调用。 Shell命令很强大，但许多任务会重复相同的多步骤模式。代理每次运行都必须重新发现工作流——重新规划、重新发出命令、重新学习约定——导致结果不一致和执行浪费。`代理技能`（在新窗口中打开）（https://agentskills.io/home）将这些模式打包成可重用、可组合的构建块。具体来说，一个技能是一个文件夹包，包含“SKILL.md（在新窗口中打开）（http://skill.md/）”（包含元数据和指令）以及任何支持资源，例如API规范和UI资产。 这种结构自然地映射到我们之前描述的运行时架构。容器提供持久化的文件和执行上下文，shell工具提供执行接口。两者就位后，模型可以在需要时使用shell命令（`ls`、`cat`等）发现技能文件、解释指令，并在同一个代理循环中运行技能脚本。 我们提供了`API`（在新窗口中打开）（https://developers.openai.com/api/reference/resources/skills）来在OpenAI平台上管理技能。开发者上传并存储技能文件夹作为版本化包，之后可以通过技能ID检索。在将提示发送给模型之前，响应API加载技能并将其包含在模型上下文中。这个序列是确定性的： 1. 获取技能元数据，包括名称和描述。 2. 获取技能包，将其复制到容器中并解包。 3. 使用技能元数据和容器路径更新模型上下文。 在决定技能是否相关时，模型会逐步探索其指令，并通过容器中的shell命令执行其脚本。 将所有部分组合起来：`响应API`提供编排，`shell工具`提供可执行动作，`托管容器`提供持久化运行时上下文，`技能`层提供可重用工作流逻辑，而`压缩`允许代理在需要上下文的情况下长时间运行。 有了这些原语，一个简单的提示就可以扩展为端到端的工作流：发现正确的技能、获取数据、将其转换为本地结构化状态、高效查询以及生成持久的产出物。 下图展示了该系统如何从实时数据创建电子表格。 我们很期待看到开发者使用这组原语构建什么。语言模型的意义远不止生成文本、图像和音频——我们将继续发展我们的平台，使其在处理复杂、大规模的真实世界任务方面变得更加强大。