OpenAI最近发了篇新文章。我看完了，觉得他们搞了件大事。简单说，他们想让大模型不只是聊天，还能自己做事。
我觉得他们说的很对。你光跟一个大模型聊天，它只是告诉你一些东西。就像你看到一棵树。但是，如果你给它一台电脑，让它自己去操作，那它就能给你一片森林。
模型自己能用程序，能从API拿数据，还能做表格、写报告。这样一来，它能做的事情就太多了。就像一个真正的数字员工。
但是，想让AI这么干，其实挺难的。他们也提到了几个大问题，我听着都觉得麻烦：
- 文件存哪儿？ 比如AI生成了个大表格。你不可能让它把几万行内容都贴到对话框里吧？那怎么办？
- 安全咋办？ 如果给AI上网的权限，它万一乱来怎么办？比如删掉数据库，或者把密码泄露了？我们怎么保证安全？
- AI容易忘事：任务稍微复杂一点，对话内容就长了。模型自己就记不住之前说了什么，做过什么。这不就“断片”了吗？
- 任务失败咋办？ 如果任务超时了，或者出错了，怎么重试？难道每次都得人去管吗？
这些问题，如果解决不好，AI智能体就没办法真的干活。OpenAI想了个办法。
OpenAI的答案：给模型一台隔离的“电脑”
为了解决这些麻烦，OpenAI自己做了一套东西。
他们不是光给模型一个对话框。他们给模型配了一台隔离的“电脑”。
这台“电脑”其实是一个容器工作空间。它有文件系统，就像你电脑里的文件夹。它也有数据库（SQLite），能存结构化的数据。而且，它能上网，但有严格的限制。
OpenAI的 Responses API 是核心。它和 shell 工具一起用。模型会说它想干什么，提出步骤和命令。
这个平台就在那个隔离环境里跑这些命令。结果会实时反馈给模型。这样，模型就知道下一步该怎么做了。
我觉得这很聪明。就像给AI一个工具箱，还给它一个自己的小房间。它在里面爱怎么折腾就怎么折腾，但不会影响到外面。而且，它每做一步，你都能看到结果。
OpenAI团队的早期经验教训
OpenAI在这个过程中，学到了不少。
1、核心大招：Shell Tool
我觉得，让AI干活，最关键的就是这个循环。就是：模型提出一个操作 → 平台执行 → 结果反馈给模型 → 模型再决定下一步。
他们说， Shell Tool 就是看这个循环跑得好不好的最简单方法。
他们还解释了一个重点。模型怎么用工具？其实，模型不是真的会用工具。它只是学过很多例子。它知道在什么情况下，该“说”出调用哪个工具，以及会得到什么结果。
就像一个项目经理。他知道该让哪个工程师写哪段代码，他不用自己会写。
所以， Shell 工具对模型来说，就是另一种工具。但是，这个工具非常厉害。它让模型能通过命令行跟电脑打交道。
以前的 Code Interpreter 只能跑 Python。现在这个 Shell Tool，就厉害多了。它用了 Unix 的命令行工具。像 curl、grep、awk 这些命令，它都能用。甚至能跑 Go、Java 或 NodeJS 的程序。
有了这个，模型能做的事情就多了。它能处理更复杂的任务。
它是怎么工作的？
- 模型提建议：模型需要处理数据。它会提出要跑一段 Shell 命令。
- 平台执行：Responses API 会在隔离的容器里跑这段命令。
- 结果反馈：命令跑完的结果，比如从API拿到的数据，或者抓下来的网页内容，会马上传给模型。
模型拿到结果后，它就能决定接下来是继续跑命令，还是给出最终答案。我觉得，这个过程特别直接有效。
2、智能体循环的编排
模型光能提出 shell 命令还不行。这些命令谁来执行？结果谁来传给模型？这就需要一个编排器。
这个编排器就像是总指挥。它接收模型的输出，然后去调用工具，再把工具执行后的结果传回给模型。这样一直循环，直到任务完成。
开发者平时用 OpenAI Responses API 和模型打交道。如果用自定义工具，API会把控制权交回给开发者。但是，他们现在能让API自己在模型和工具之间直接完成编排。
当 Responses API 收到一个请求时，它会准备好模型需要的上下文信息。这些信息包括你的问题、之前的对话，还有工具的使用说明。要让 shell 执行生效，你得在请求里告诉它用 shell 工具。而且，模型本身也得训练过，知道怎么提出 shell 命令。他们说，从 GPT-5.2 开始的模型，就有这个能力了。
Responses API 的流式传输 Shell命令
有了这些信息，模型就决定下一步干啥。如果模型想执行 shell 命令，它会给 Responses API 返回一个或几个命令。API 服务会把这些命令发到容器环境去跑。
Shell 跑出来的结果会实时传回。API会把这些结果作为上下文，在下次请求时再提供给模型。
然后，模型会看这些结果。它可以提出新的命令，或者给出最终答案。Responses API 会一直重复这个过程。直到模型给出最终结果，不再需要执行 shell 命令。
当 Responses API 跑 shell 命令时，它和容器服务是一直连接着的。命令一有输出，API就马上把结果给模型。这样，模型能实时决定是继续等输出，还是跑新命令，或者直接给出答案。我觉得这个“实时”特别重要。
而且，模型在一次步骤里可以提出好几个 shell 命令。Responses API 能同时用几个容器来跑这些命令。每个容器会独立返回结果。API 会把这些结果整合起来，再给模型。
这意味着，AI可以同时干好多件事。比如，它能一边找文件，一边拿数据，还能一边检查中间结果。这效率就高多了。
但是，命令跑出来的东西可能很多。如果都塞给模型，会占满上下文窗口，还没啥用。所以，模型可以为每个命令设置一个输出限制。
Responses API 会执行这个限制。它会返回一个开头和结尾都在的结果，中间多余的就截断。它还会标记被省略的部分。比如，你会看到“开头文字…省略1000字…结尾文字”。
这样，AI跑得又快，又不浪费上下文空间。模型能专注于重要的结果，不会被太多没用的信息淹没。这就像我们看报告，只看总结和关键数据，不用看所有原始日志。
3、三大基石：文件、数据库、安全联网
除了核心工具，OpenAI还为这个“电脑”加了三个重要功能。
- 文件系统：我们以前不能把大数据给模型。现在好了。你可以把文件直接上传到容器里。AI就像人一样，可以用 ls 和 cat 命令去按需要读文件。这样就方便多了。
- 结构化数据库：AI现在能操作 SQLite 这种数据库了。你想问“哪个产品卖得不好？”AI不会傻傻地把所有数据都看一遍。它会自己写一条SQL语句，直接查出结果。这查数据就精准又快速。
- 侧车Agent联网（Sidecar Proxy）：这个设计，我觉得特别棒。AI想上网时，所有的请求都得先经过一个“代理”。
- 安全：你把敏感的密码给AI，它不会直接暴露。这些密码会被替换成占位符。只有AI真的要发送请求到被允许的网站时，密码才会被注入进去。这样就很安全。
- 可控：我们开发者可以设置白名单。只让AI去访问特定的网站，防止它乱跑。这样就不用担心AI会去干坏事了。
这三个功能，让AI的“电脑”变得更完整、更安全。
4、解决“健忘”：原生的上下文压缩（Compaction）
智能体跑任务久了，上下文窗口会满。AI就容易忘事。这个问题，大家都很关心。
为了让AI长时间跑任务时也能记住重要信息，同时删除没用的内容，OpenAI在 Responses API 里加了一个功能：原生的上下文压缩。
OpenAI说，他们新的模型专门训练过。模型能自动分析之前的对话状态。然后它会生成一个“压缩项”。这个压缩项用一种高效的加密方式，把关键的历史状态保留下来。
压缩好之后，新的上下文窗口就会包含这个压缩项。还有之前窗口里最有价值的一些内容。这样一来，即使任务时间长、步骤多、老是调用工具，AI也能保持清醒，不会“断片”。
这就像给AI做了一份**“会议纪要”。它省钱**，因为节省了Token。它也保命，因为没有丢掉关键信息。
他们还说了个小故事。OpenAI的 Codex 团队也参与了开发。Codex在测试时发现错误，还会自己开一个新的实例去调试、修复自己。这真的说明AI的能力在进化。
而且，这个压缩功能可以自动在服务器端运行。你也可以通过一个独立的接口去调用。服务器端压缩很方便，开发者不用自己写复杂的逻辑。你设个限度，系统自己决定什么时候压缩。
系统还允许输入上下文稍微超出限制，然后再压缩。这样，快要超限的请求也能被处理，不会直接被拒绝。这个设计挺人性化的。
OpenAI说，他们的模型训练一直在进步。这个原生压缩机制也会跟着模型更新，越来越好用。
5、智能体技能（Agent Skills）
Shell 命令很好用，但是有些任务，其实是重复的步骤。每次都让AI重新想一遍怎么做，那效率就不高，结果也可能不稳定。
这时候，**Skills（技能）**就派上用场了。
简单说，Agent Skills 就是把这些重复的模式打包起来。变成可以重复使用、组合起来的“模块”。
一个 skill 其实就是一个文件夹。里面有 SKILL.md 文件，放着这个技能的说明和信息。还有一些需要的辅助文件，比如API的说明文档。
Skills 的结构，和前面说的运行架构很搭。容器提供持久的文件和运行环境，shell 工具提供执行接口。
有了这两样，模型就能在需要时，用 shell 命令去发现这些技能文件。它会读说明，然后在同一个智能体循环里，去执行技能里的脚本。
OpenAI的平台有 API 来管理这些 skills。开发者可以把技能文件夹上传上去，系统会给它一个版本。以后需要用的时候，就通过 skill ID 来拿。
在你把请求发给模型之前， Responses API 会先加载这些 Skills。然后把它们加入模型的上下文。这个过程是固定的。
它会：
- 拿到技能的名字和描述。
- 拿到技能包，复制到容器里，然后解压。
- 更新模型上下文，告诉它技能的信息和路径。
当模型觉得某个技能有用时，它会一步步地看技能里的说明。然后通过容器里的 shell 命令，去执行对应的脚本。
我觉得，这就像是给AI造了一本**“专业手册”。遇到常见问题，它不用从头思考，直接翻手册就能找到解决方案，然后执行。这样就能让AI干活更快、更准**。
最后一步：智能体是如何造出来的？
所有这些组件和机制都准备好了。把它们组合起来，就成了真正的智能体。
整个结构其实很清楚：
- OpenAI Responses API 负责任务的总指挥。
- shell 工具负责实际操作。
- 托管容器提供一个稳定的工作环境。
- skills 提供可以重复利用的工作流程。
- 上下文压缩让AI在长时间任务中也能记住重要的信息。
有了这些基础的东西，你给AI一个简单的问题，它就能变成一个完整的、端到端的工作流程。它会自己找合适的技能，获取数据，处理数据，最后生成你需要的东西，比如一个电子表格。
举个例子。你让它帮你分析销售数据。系统可能会自动干这些事：
- 找技能：先看看有没有现成的技能，能处理销售数据。
- 规划任务，准备环境：它会规划好步骤，准备好容器环境。
- 获取数据：去数据库或者文件系统里，把销售数据拿出来。
- 处理数据：用 shell 命令或者其他工具，对数据进行分析。
- 生成结果：最后生成一份报告或者电子表格给你。
整个过程，都是 OpenAI Responses API 在后台自动编排的。这就像一个项目经理，自己带着团队，把所有活都干完了。
网友：价值含量超高
看到网友们对这篇文章的看法，我觉得他们说得特别到位。
有人说：“这比那些花里胡哨的演示有价值多了！”我同意。概念再好，也要看能不能落地。OpenAI这次是真的把技术细节都摆出来了。
有个社区说，缩短执行循环****非常关键。他们说OpenAI解决了智能体延迟的问题，还解决了文件系统状态保存的难点。我觉得这是一个很大的进步。
很多网友也觉得 OpenAI 缩短的智能体循环****很厉害。
还有网友说，OpenAI提出的安全防护机制，大家低估了它的重要性。AI能上网干活，但又特别安全，这真的很不容易。
当然，大家觉得最有价值的，还是长时间运行智能体的工作流设计。因为现实中的任务，很少是几秒钟就搞定的。让AI能长时间、有条理地干活，这才是真本事。
我觉得，OpenAI的这篇文章，其实就是告诉大家，他们是怎么让AI变得更像人一样干活的。它不是个遥远的梦想，而是一套看得见、摸得着的架构和工具。
