From model to agent: Equipping the Responses API with a computer environment

为什么重要

OpenAI 文章系统阐述其从“模型 Model”走向“智能体 Agent”的平台化思路：单纯提示模型只能调用其已学习能力，而为模型提供可执行的计算机环境后，模型就能运行服务、调用 API、处理文件、生成电子表格和报告。文章核心不是发布单一模型，而是解释 Responses API 如何结合 Shell 工具、Hosted Container Workspace、网络策略、技能和上下文压缩，支撑更接近生产环境的长流程智能体工作流。 技术架构上，OpenAI 将智能体运行抽象为“执行循环”：模型提出操作，例如读取文件、搜索文本、请求 API；Responses API 负责编排；Container Runtime 在隔离容器中执行命令；结果再返回模型继续推理。Shell 工具基于 Unix 工具链，预装 grep、curl、awk 等，并较 Code Interpreter 不再局限于 Python，可运行 Go、Java 程序或启动 NodeJS 服务。文章明确提到，GPT‑5.2 及更高版本模型已接受“提出 Shell 命令”的专门训练。API 还支持流式连接、并发执行多个 Shell 命令、多路复用输出，以及通过 Output Cap 限制终端日志占用上下文。 面向长任务，OpenAI 强调了 Native Compaction。传统智能体在多轮工具调用中会迅速耗尽上下文窗口，导致历史状态丢失。Responses API 可自动生成加密且节省 Token 的 Compaction Item，保留关键状态并移除低价值信息；该能力可由服务器端阈值自动触发，也可通过 /compact 端点调用。OpenAI 称 Codex 已依赖该机制维持长耗时编程任务和迭代式工具执行，并且 Codex 还参与发现和修复压缩系统自身问题，形成“智能体改进智能体基础设施”的闭环。 在生产可用性方面，文章重点讨论文件、数据库和网络三类资源。OpenAI 反对将大文件或完整表格直接塞进提示词，建议把资源放入容器文件系统，由模型按需读取、解析和转换；结构化数据则建议放入 SQLite 等数据库，让模型根据列描述查询相关行，而不是扫描整个表格。这一范式适合需要处理大量报表、日志、表格和外部 API 的企业自动化场景。 安全是文章的另一条主线。托管容器通过 Sidecar Egress Proxy 管控所有出站网络请求，在中心化 Policy Layer 中执行白名单、访问控制和可观测性；凭据采用 Domain-scoped Secret Injection，模型和容器只看到占位符，真实密钥仅在访问获批目标时注入。最后，OpenAI 以“技能 Skills”封装重复工作流：开发者上传包含 SKILL.md、API 规范、脚本和资源的版本化目录，Responses API 将其加载进容器和模型上下文。整体看，这是一套面向企业 Agent 落地的底层运行时，而非简单聊天能力升级。

新进展

• Responses API 被描述为智能体工作流的编排层，可连接模型、Shell 工具、托管容器和工具执行结果。
• Shell 工具让模型可提出 Unix 命令，并支持 grep、curl、awk、Go、Java、NodeJS 等更广泛的执行场景。
• 托管容器提供文件系统、SQLite 等结构化存储和受控网络访问，减少把大文件或完整表格塞进提示词的需求。
• Native Compaction 用于在长时间、多步骤工具调用中保留关键状态，避免上下文窗口被低价值历史信息占满。
• Sidecar Egress Proxy 与域名级密钥注入用于控制联网智能体的出站访问和凭据暴露风险。
• Skills 将重复多步流程封装为带版本的目录包，便于模型在容器中发现、读取并执行相关工作流。