AI 生态热点：OpenAI 把“电脑环境”塞进 Responses API 后，Agent 平台该重写的是运行时
如果你还把 Agent 平台理解成“模型 + tool calling + 一点 prompt 工程”，这轮官方信号已经很难忽略了。
OpenAI 在 2026 年 3 月 11 日发布工程文章
《From model to agent: Equipping the Responses API with a computer environment》，
随后配套公开了 Shell、Skills、Containers 相关官方文档。
这件事真正值得开发者重视的地方，不是单纯“API 现在也能跑 shell 了”，而是：
OpenAI 正在把 Agent 的运行时，从一个你自己拼出来的外部脚手架，往平台内建能力推进。
也就是说，接下来很多团队该重写的，不只是 prompt，而是下面这些东西：
- 执行环境怎么隔离
- 技能和工具怎么挂载
- 网络访问怎么收口
- 高风险动作怎么审批
- 日志、证据和审计链路怎么保留
为什么这轮更新值得现在关注
过去两年里，很多 Agent 系统虽然已经能跑起来，但底层结构大多是“拼装式”的：
- 模型在一边
- tool schema 在一边
- shell / browser / filesystem 在一边
- 技能包、脚本模板、知识片段再塞一层
能跑当然能跑，但工程代价也很明显：
- 运行时环境不统一
- 权限模型很容易散
- 失败恢复、审计、回放都靠自己补
OpenAI 这轮动作的含义，是把“模型调用”往“受控执行环境”继续推近一步。
从官方文档能看到的几个关键词已经很明确：
ShellHosted containersSkillsNetwork accessReview commands and outputs
这说明平台关注点已经不只是“模型会不会调用工具”，而是工具到底在哪里执行、执行时能碰什么、执行后留下什么证据。
它到底更新了什么
1) Shell 不再只是本地 hack，而是官方运行时能力的一部分
OpenAI 的 Shell 指南写得很直接：
它支持在 hosted containers 或你自己的 local runtime 中执行 shell 命令。
这句话的意义很大，因为它把 Agent 的执行位置正式抽象成了两种模式：
- 平台托管环境
- 你自己的本地环境
以前很多 Agent 平台默认只讨论“会不会调工具”；
现在官方文档已经把“工具在哪儿跑”放进了一等公民的位置。
这会影响很多工程决策：
- 你的任务到底该在托管容器里跑，还是落到本地执行器
- 敏感文件、环境变量、依赖安装该怎么隔离
- 失败后该保留哪些执行证据
2) Containers 把“执行上下文”正式资源化了
OpenAI API Reference 里已经把 Containers 做成正式资源：
- 可以
Create container - 可以
Retrieve container - 可以管理
container files - 可以读取
container file content
这意味着平台表达方式变了。
以前很多团队会把“任务上下文”理解成一堆 prompt 和附件；
现在更像是在表达：
任务除了上下文，还需要一个有文件系统、有生命周期、可读可写的执行容器。
这会让 Agent 平台的设计重点从“对话状态管理”前移到“任务沙箱管理”。
3) Skills 不只是提示词片段，而是可挂载、可治理的能力包
Skills 官方文档的描述也非常明确：
- 可上传
- 可管理
- 可附加到 hosted environments
也就是说，Skill 在这里已经不是松散的 prompt 模板，而是更接近“挂载到运行时的能力单元”。
这会直接改变很多团队现有的技能体系：
- 技能不再只是文案片段，而要考虑来源、版本和权限
- 技能和执行环境开始发生绑定
- 技能的安全审查会变成真正的工程问题，而不是文档整理问题
对开发者 / Agent 平台的实际影响
这轮更新落到工程层面，我认为至少会改 3 件事。
1) Agent 平台的核心会从 prompt orchestration 转向 runtime orchestration
以前很多文章讲 Agent，重点都在：
- 怎么写 system prompt
- 怎么做 tool schema
- 怎么做多轮规划
这些当然还重要，但这轮官方动作说明：
真正决定系统上限的，越来越是运行时治理：
- 用哪类容器
- 挂哪些 skill
- 放开什么网络访问
- 出问题时怎么回放与审计
也就是，平台竞争点正在从“谁更会编排 prompt”，转向“谁更会治理执行环境”。
2) 安全边界会前移到网络与 Skill 审核
Shell 文档里明确提醒：
- 默认不开网络访问
- 只应该开放受信任域名
- 外部内容可能包含 prompt injection
- 要审查 shell command 和 execution output
Skills 文档也把风险点说得很清楚：
- Skill 要被当成 privileged code and instructions
- 不要把开放的 Skill 仓库直接暴露给终端用户
- 高风险写操作要显式 approval
这说明未来很多 Agent 平台的首要问题不再是“模型够不够聪明”，而是：
- 你的 Skill 来源是否可信
- 你的网络出口是否收紧
- 你的 write action 是否有审批门
如果这些没有先建好，把 runtime 做得越强，风险也会放得越大。
3) 平台会更强调可回放、可证据化的执行链
Shell 文档要求开发者检查命令和输出；Containers 又把文件和内容留在可访问资源里。
这背后的工程含义是：
Agent 任务不该只是“跑完了没”，而应该能回答：
- 它执行了什么命令
- 它碰了哪些文件
- 它访问了哪些网络目标
- 它为什么做了这个动作
这会把很多团队现在“黑箱式 Agent”逼向更强的审计和回放设计。
谁应该现在就跟进
这轮变化最值得马上关注的，主要是下面几类团队：
- 正在做 coding agent、终端自动化、浏览器自动化的团队
- 已经有内部 skill / prompt pack / tool catalog 的团队
- 希望把长任务执行链从本地脚手架收敛成平台化能力的团队
如果你现在还停留在轻量问答或单步 tool call，这轮变化感知可能没那么强。
但只要你的系统已经开始涉及：
- 多步骤执行
- 文件读写
- shell / browser / connector
- 网络访问
你就已经进入这轮变化的核心影响区了。
风险边界与冷思考
这轮更新很强，但也要避免一个错觉：
官方把 runtime 能力做进平台，不等于安全和治理自动解决了。
恰恰相反，它把很多以前“可以先不碰”的问题提前暴露出来了：
Shell一旦带网络，prompt injection 风险会立刻放大Skill一旦能挂载到 hosted environment，就必须当成特权输入审查Hosted containers让执行更方便，也让数据驻留、日志保留、权限边界变得更敏感
OpenAI 文档里甚至明确提到：
- 连接只应指向受信任域名
- 高影响动作需要审批
- hosted container-based Skills 不能在 Zero Data Retention 下使用
所以更稳的跟进顺序应该是：
- 先建 runtime policy
- 再建 skill 审核和来源治理
- 最后才扩大自动执行范围
如果顺序反了，平台能力越强，事故半径只会越大。
总结
OpenAI 这轮动作最值得关注的，不是单个功能点，而是一个方向已经非常明确：
- 模型不再只是生成答案
- 平台不再只提供 API 调用
- Agent 的执行环境、技能挂载、网络边界和审计证据，正在一起变成正式产品面
如果你这周只能先做一件事，我最建议的是：
先检查你当前的 Agent 平台里，运行时、技能、网络和审批是不是还分散在四套互相看不见的脚手架里。
因为从这轮开始，真正要重写的，很可能不是 prompt，而是 runtime。
参考来源（一手）
- OpenAI Engineering（2026-03-11）：From model to agent: Equipping the Responses API with a computer environment
- OpenAI API Docs：Shell
- OpenAI API Docs：Skills
- OpenAI API Reference：Containers