转载说明：本文翻译并转载自 OpenAI 于 2026 年 3 月 11 日发布的文章 From model to agent: Equipping the Responses API with a computer environment。原文作者：Bo Xu、Danny Zhang、Rohit Arunachalam。从模型到智能体：为 Responses API 配备计算机环境 作者：Bo Xu、Danny Zhang、Rohit Arunachalam 我们正处在一个从“使用擅长单点任务的模型”转向“使用能够处理复杂工作流的智能体”的阶段。单靠提示词，你能调用的只是模型已经训练出来的智能能力。但如果给模型配上一套计算机环境，它就可以覆盖更广泛的用例，比如运行服务、向 API 请求数据，或者生成更有用的产物，例如电子表格和报告。 当你真正开始构建智能体时，会很快遇到几个很现实的问题：中间文件该放在哪里、怎样避免把大型表格直接贴进 prompt、如何在不制造安全隐患的前提下给工作流网络访问能力，以及如何在不自己造一套工作流系统的情况下处理超时与重试。 与其把这些执行环境的建设工作都推给开发者，我们选择直接为 Responses API 配上所需组件，让它能够在真实世界任务中稳定使用一套计算机环境。 OpenAI 的 Responses API 连同 shell 工具和托管容器工作区，正是为了解决这些实际问题而设计的。模型提出步骤和命令；平台则在一个隔离环境中运行它们，这个环境提供用于输入与输出的文件系统、可选的结构化存储（如 SQLite），以及受限的网络访问能力。 在这篇文章里，我们会拆解自己是如何为智能体构建计算机环境的，也会分享一些早期经验，说明怎样用它更快、更可重复、也更安全地跑生产级工作流。shell 工具 一个好的智能体工作流，起点是一条紧凑的执行循环：模型提出一个动作，例如读取文件或通过 API 获取数据；平台执行它；执行结果再回流到下一步。我们会先从 shell 工具讲起，因为它是观察这条循环如何运转的最直接方式；然后再依次讲到容器工作区、网络、可复用 skills，以及上下文压缩。 要理解 shell 工具，先要理解语言模型一般是怎样使用工具的：它会调用函数，或者与计算机交互。在训练过程中，模型会看到大量关于工具如何被使用、以及使用后会产生什么结果的逐步示例。这让模型学会判断什么时候该调用工具、又该怎样调用。换句话说，所谓“使用工具”，本质上是模型提出一次工具调用建议；它本身并不能直接执行这个调用。 shell 工具只是“另一种工具”的示意图 shell 工具会显著放大模型的能力边界：它能够通过命令行与计算机交互，完成从文本搜索到在你的计算机上发起 API 请求等一系列任务。因为它建立在人们熟悉的 Unix 工具链之上，所以我们的 shell 工具几乎能完成你预期中的所有事情，像 grep、curl、awk 这类实用工具开箱即用。 相比我们现有的 code interpreter 只能执行 Python，shell 工具支持的用例范围要宽得多，比如运行 Go 或 Java 程序，或者启动一个 NodeJS 服务。这种灵活性让模型能够真正完成复杂的 agentic 任务。编排智能体循环 模型本身只能提出 shell 命令，但这些命令究竟由谁来执行？我们需要一个 orchestrator，从模型输出中接收动作、调用工具、再把工具结果回传给模型，并以此循环下去，直到任务完成。 Responses API 就是开发者与 OpenAI 模型交互的接口。当它与自定义工具一起使用时，Responses API 会把控制权交回客户端，而客户端就必须自己准备一套 harness 来运行这些工具。不过，这个 API 也能够在开箱状态下，为模型和托管工具之间的协作承担编排工作。 当 Responses API 收到一个 prompt 时，它会先组装模型上下文：用户提示、此前的对话状态，以及工具说明。要让 shell 执行真正生效，prompt 里必须明确提到要使用 shell 工具，而且所选模型也必须接受过“提出 shell 命令”这类行为的训练；GPT‑5.2 及之后的模型都具备这种能力。有了这些上下文后，模型会决定下一步动作。如果它选择 shell 执行，就会向 Responses API 服务返回一条或多条 shell 命令。API 服务再把这些命令转发给容器运行时，把 shell 输出以流的形式回送，并在下一轮请求里把它喂给模型。模型随后可以检查结果、继续下发后续命令，或者直接给出最终答案。Responses API 会不断重复这个循环，直到模型返回一个不再包含额外 shell 命令的完成结果。 智能体循环图：Resp…