OpenAI 的 Agents API 是 harness，而 ARC 是给 Agent 的新型计算机

2026 年 9 月 10 日，OpenAI 发了 Introducing the Agents API。副标题只有一句：

Build and run cloud agents with the Codex harness, fully managed by OpenAI.

（译：用 OpenAI 托管的 Codex harness，构建并运行云端 agent。）

Harness 这个词值得停一下。模型本身只会接下文。要让它连续干活，外面必须有一层东西：把任务和文件喂进去，调用工具，看结果，再喂回去；上下文快满了就做摘要；事情太大就拆给子 agent。Codex 里跑了很久的，就是这一层。Agents API 做的事很具体：把这层循环收成一条 HTTP API，由他们托管和维护。

我觉得这是一件该被认真看的发布。不是因为又多了一个「agent 平台」这个词，而是因为它把循环、环境和应用之间的分工写进了文档。分工一旦公开，就可以讨论每一层到底解决什么、停在哪里、别的东西该接在哪。

上个月我们写过 Agent 最需要的不是 sandbox，是一台自己的计算机。读完 Agents API 的文档，我更确信那篇文章里的分层是对的。他们把 harness 做成了商品。计算机是另一层。ARC 做的是后一层，并且可以接在前一层已经暴露出来的接口上。

文档里其实只有四块积木

开发者文档把 Agents API 收成四个概念：Agent、Environment、Session、Events。用日常的话说：

Agent 是「用哪个模型、听什么指令、能调哪些工具」。Environment 是「它的手伸到哪」：读文件、跑命令、加载 skill 的那台机器，可以没有，可以是 OpenAI 托管的 sandbox，也可以是你自己机器上的 codex exec-server。Session 是「这个 agent 的一次长期存在」，任务可以跨很多轮接着干，不必每次把对话重新拼起来。Events 是过程：流式输出、webhook、中途介入。

架构页把职责划得更干净。OpenAI 跑 harness：模型循环、工具调度、会话状态、上下文压缩。你的应用发任务、收事件；如果需要文件和命令，再接一个 environment。他们自己的句子是：

OpenAI manages sessions, orchestration, context compaction, and recovery while your application provides tools and chooses its execution environment.

（译：OpenAI 管理会话、编排、上下文压缩和恢复；应用提供工具，并选择执行环境。）

这不是口号，是接口。POST /v1/agents/sessions 一次调用里，你要填的大致就是这几件事：模型、instructions、工具（MCP、内置搜索、programmatic tool calling）、要不要拆子 agent、environment 选哪一种、初始任务是什么。剩下的循环他们跑。

Sandbox 这边，选择是真的。托管环境沿用 Codex / ChatGPT 那套隔离执行；self-hosted 则在你的环境里跑 executor，出站连回 API 收命令、回结果。Plugin 是第三块可插的东西：一个包里放 skill 目录和 MCP 配置，ZIP 上传到托管 sandbox，或把根目录写进 capability_directories。Skill 是给模型看的说明书，MCP 是插座，plugin 把两者打在一起，让 session 启动时环境里已经有这套能力。

所以 Agents API 不是「一个万能 agent」。它是托管的 Codex 循环，外加一块可替换的工作区，外加一种把说明书和插座打进环境的包装格式。顶层对象是 session。文件在 /workspace。身份是组织、项目和 API key。

这层东西值钱在哪

先说它解决了什么。过去两年，不少团队自己写 prompt chain、自己管 tool call、自己做上下文摘要、自己编排子 agent。这些活和模型绑得很紧：模型一换，harness 往往要跟着改。OpenAI 把这件事说白了：新模型的能力常常要靠改 harness 才能用上，所以他们把 harness 跟模型一起维护，并做成带版本的 API。你不必再养一套自己的循环。

几个具体能力，分开看都站得住。自动 compaction 让工作跨过单次上下文窗口，而不必自己实现摘要策略。Tool search 按需加载工具定义，减少把整份 schema 塞进 prompt 的浪费。Programmatic tool calling 允许 agent 在代码里并行调工具、过滤结果，只把有用的东西带回复述。Multi-agent 把独立子任务派给有自己上下文的子 agent。这些都是「让模型在长任务里少翻车」的工程，不是营销词。

Sandbox 和 plugin 同样有用。调查事故、改仓库、写报告，agent 需要一个能跑命令、读写文件、留下中间产物的地方。把 skill 和 MCP 打成 plugin，意味着同一份能力可以进 Codex、进 ChatGPT、也进这条 API。对做工具的人来说，这是一条清楚的分发面。

你可能会觉得：那不就是 agent 平台吗？从「我只想跑起来」的角度看，是的。一次 API 调用，循环、文件、工具、子 agent 都有了。对很多一次性任务，这就够了。一段生成代码、一次日志排查、一篇对比 release note，不必先拥有一台长期计算机。

它停在哪，也要按文档读，不要按愿望读。Harness 记住的是 session。Sandbox 提供的是一块 POSIX 工作区。Plugin 教模型在这块工作区里用哪些工具。根身份来自平台账号。即便 environment 选 self-hosted，文档也写明：会话状态仍在 API 这一侧，并不因此变成 Zero Data Retention。换一种说法：手可以长在你的机器上，记忆和编排还是他们的服务。

这没有对错。这是他们选择托管的那一层。短任务、可丢弃的工作区、以平台账号为根，这套抽象是匹配的。我们八月那篇文章里把这一层执行材料叫「盒子」：能跑代码、能放文件，但根身份还是平台账号。Agents API 让盒子变得更好用、更好接，也让「盒子不是计算机」更容易指给人看。

计算机要回答的是另一组问题。这次行动代表谁？它看见的是哪一棵树，而不是整块盘？权限是不是可衰减、可收回的授权，而不是环境变量里一把长期密钥？干完之后，文件、身份和历史在不在所有者这边，换一条 harness 之后还是不是同一台机器？这些问题，session 和 /workspace 不必回答。它们也确实没有回答。

接到 ARC，接在他们已经拆开的接口上

接口既已拆开，耦合就应该接在缝上，而不是把整台电脑塞进 sandbox。

我们把那台机器叫 ARC：Agentic Realm Computer。底下是 AFS：把数据库、工具、记忆都挂成路径，人和 agent 看见的是按权限投影出来的那一棵树，墙外的东西根本不存在。身份用 DID，换设备、换运行时，还是同一个人或同一个 agent。应用以 blocklet 的形态装在这台机器上，就是一份带边界的可部署单元。CLI 叫 arc。这条命令从第一天就按「客户端」在设计：arc deploy --server 的 server 才是电脑，sandbox 里的进程不是。

所以接法几乎就是他们已经画好的那张图。他们的图是三格：应用发任务，Agents API 跑 harness，sandbox 接手和文件。我们接在第三格后面。最后一跳不是「写进 /workspace」，而是「写进 production ARC」。

前三格沿用 OpenAI 公开的架构图。第四格是我们的位置：sandbox 里跑 plugin 和 arc CLI，身份、AFS 和 deploy 落在 production ARC。虚线仍是他们的 self-hosted compute。

应用、Codex 或 ChatGPT 发一个任务。Agents API 跑 harness：压缩上下文、找工具、拆子 agent。Harness 需要手的时候，伸进你选的 sandbox。Sandbox 里装的是 ARC 的 plugin：skill 说明书，加上 arc mcp 这个插座。MCP 在这里只是运输层，把同一套 AFS 露给 agent，不是另造一个世界。Agent 在 sandbox 里看起来像在调工具，落点仍是路径和权限。最后 arc deploy --server 把产物发到生产上的 ARC。Session 可以结束。机器还在。

谁当电脑、谁当手，一旦搞反，接法就会变成另一种东西：把 ARC 的运行时装进他们的 /workspace，让 session 当电脑。那是把 OS 降成别人循环里的一个进程。Agents API 的 sandbox 是为一次任务准备的执行环境，不是 DID Space、不是长期 blocklet、也不是可以换运营商仍连续的身份。能塞进去的，往往只是 CLI 的一个子集；那个子集很快会变成外面的人以为的「ARC」。

正着接，ARC 看起来会非常合适。不是因为话术接近，是因为接口形状接近。他们要 plugin，我们有 skill booklet 和 arc mcp。他们要 environment 里能跑命令，我们有 arc 二进制。他们要文件和中间产物，AFS 本来就把数据库、工具、记忆当成路径。他们把长循环做成可以插上就用的一层，我们本来就不打算再造一遍 compaction 和子 agent 编排。缺的那截，是 hosted sandbox 里的鉴权：CLI 今天还习惯在本机弹浏览器收凭证，OpenAI 的虚拟机上没有用户的浏览器，plugin 包里也不能塞密钥。短命的 capability 进环境变量，用户在自己这边完成 DID Connect，sandbox 只拿 scoped token 去打 production。这是工程问题，而且是接在他们已经提供的 bearer_token_env_var 上的那种。

还要说清边界。Plugin 是我们正在做的包装，不是已经出现在公共目录里的安装按钮。AFS、arc CLI、arc mcp、arc deploy --server 是现有能力；把它们打成 Agents API 认识的 plugin、并在托管 sandbox 里把鉴权做对，是正在接的那一层。短任务继续用他们的 hosted sandbox 就好，不必先搬进 ARC。ARC 开始有意义的地方，是 agent 要长期代表你，跨工具留下状态，并且你在意身份和历史是不是你的。

市场会把「能跑很久的 agent」做成默认画面。Agents API 会把这幅画面做得很容易。我们要看住的只有一句：循环可以是商品，电脑不能跟着 session 一起扔掉。

他们把 Codex 的 harness 收成了 API，让循环、文件、plugin 都有了官方接口。这是好事。盒子会更好用。接在那道已经拆开的缝上，agent 才同时拥有一双被维护的手，和一台有名字的计算机。

参考