企业级智能体平台进入标准化产品阶段
2026 年 9 月 10 日,OpenAI 把内部驱动 Codex 的 Agent harness 拆出来,作为"Agents API"开放公测,任何持有 API key 的开发者都能调用同一套会话管理、子代理编排和沙箱执行基础设施。这件事让 Agent 工程正式进入了"标准化产品"阶段 —— 不再是企业 IT 需要从零搭建 Agent 工具栈,而是从 API 提供商那里选择现成的服务。一周内 OpenAI 已经把 9 个沙箱供应商(Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel)接入到同一套 API 调用路径上,这种基础设施级别的合作密度在过去一年里持续抬升。
Agents API 公开 beta 的发布,意味着 Agent 平台的能力矩阵从"少数头部公司的专属产品"变成了"任何企业 IT 都能消费的标准服务"。这种转变的工程意义,在于企业 IT 不再需要自己搭建 Agent 的会话管理、上下文压缩、错误恢复、子代理编排、沙箱调度这一整套复杂基础设施,只需要选一家 API 提供商并接入。这种转变对应到企业 IT 治理上,就是把 Agent 工程的预算从"自研基础设施"转向"标准化服务采购",工程重点从"能搭起来"转向"能治理好"。
从四个 primitives 看 Agent 平台的能力矩阵
Agents API 围绕四个明确的工程原语组织:Agent、Environment、Session、Events/items。Agent 是模型、指令、工具和 MCP 服务器的组合;Environment 是 Agent 代码运行的地方;Session 是跨多轮对话持续存在的会话实例;Events/items 是会话内发生的事情的结构化记录。这四个原语的设计理念是把"Agent 的身份"、"Agent 的运行环境"、"Agent 的会话"、"Agent 的行为记录"分开管理,每个原语可以独立选择、独立配置。
这种设计在工程上有几个具体表现。第一,会话是长生命周期的,客户端不需要在每轮对话重新构建上下文,API 自己处理。第二,Environment 是可插拔的,可以是 OpenAI 自己的托管沙箱,可以是企业自建基础设施,也可以是 9 个合作伙伴之一的沙箱产品。第三,Agent 可以拆解任务给子代理,子代理数量通过 max_concurrent_subagents 参数配置。第四,所有发生的事情都有结构化记录,这些记录本身就是 MCP 资源可以被独立验证。
这种设计的工程价值在于,它把企业 IT 关心的"Agent 是否可信"问题,转化为"原语配置是否合理"问题。企业 IT 不需要理解 Agent 怎么工作,只需要检查:Agent 的指令是否合理、Environment 的隔离是否符合合规要求、Session 的生命周期是否可控、Events/items 的审计是否完整。这种工程价值让 Agent 平台从"黑盒产品"变成了"可治理的平台"。
从 Codex harness 共享到 Agents API 商业化的工程意义
Agents API 公开 beta 之前,OpenAI 内部已经在 ChatGPT 和 Codex 里使用同一套 harness 来管理 Agent 会话。这种内部使用让 harness 已经被反复验证过 —— 不是新写的、未经生产验证的代码,而是被证明能在真实大规模流量下稳定运行的工程基础。把这种 harness 通过 API 商业化,意味着任何企业都能消费到和 OpenAI 自己用的同一套运行时基础设施,而不需要自己实现会话管理、上下文压缩、错误恢复、子代理编排。
这种"内部基础设施商业化"的做法在云服务时代很常见 —— AWS 把亚马逊内部用的工具开放给外部客户、谷歌把内部 Borg 系统演变成 Kubernetes、Cloudflare 把内部的反爬能力做成 SaaS。Agent 时代的这个模式延续了同样的逻辑:大公司在内部用某个工具验证了它的能力,然后把它包装成产品对外销售。这种商业化的好处是工具的成熟度有保证,客户不需要承担"这是新写的、可能有 bug"的风险。
但这种商业化也带来一个被广泛关注的局限:定价权掌握在大公司手里。在公测期间,Agents API 不支持 Zero Data Retention,即使企业选择 self-hosted 沙箱。这种限制让一些有强合规要求的企业被迫继续自建 Agent 平台,而不能用标准化服务。这说明 Agent 平台标准化不是单一方向 —— 标准化的服务适合大多数场景,合规要求严格的企业仍需要自建能力。把这条认知落实到企业 IT 治理里,就是承认"标准化 + 自建"的双轨并行是 Agent 平台未来几年的主流形态。
从 9 个基础设施合作看生态成熟度
Agents API 上线第一天的 9 个基础设施合作伙伴,代表了 Agent 平台在 2026 年下半年的生态成熟度。这 9 个合作伙伴覆盖了从单一租户的零配置方案(OpenAI 托管、E2B、Modal),到企业级的合规基础设施(Oracle、自托管),到针对特定场景的优化方案(Cloudflare 的 isolates、Runloop 的 agent 运行时、Vercel 的边缘部署)。这种密度的基础设施合作在一年前是不可能的,反映了 Agent 平台作为一个工程品类已经被市场接受。
这种生态成熟度给企业 IT 的采购提供了具体的选项空间。金融行业的企业 IT 可以选择 Oracle 的隔离沙箱来满足合规要求;创意工作室可以选择 Modal 的 GPU 优化沙箱来跑视觉类 Agent;开源爱好者可以选择 Blaxel 或 E2B 这种开发者友好的方案;已经在 Cloudflare 基础设施上的企业 IT 可以继续用 Cloudflare 的 isolates 作为 Agent 运行环境,不需要为 Agent 单独搭一套基础设施。
这种"同一套 API 接入多种基础设施"的模式,意味着企业 IT 在选 Agent 平台时,可以保持基础设施选型的独立性。这种独立性对企业 IT 的多云策略、合规策略、供应商多元化策略都是好消息。它和传统云服务"被一家供应商绑定"的格局完全不同,是一种更适合企业 IT 多供应商治理的 Agent 平台形态。
从 API 设计到企业落地的工程新基线
把 Agents API 的能力矩阵和生态布局放回企业 IT 治理,可以看出 Agent 平台标准化后企业落地有五条新的工程基线。第一条基线是 Agent 平台必须支持多基础设施部署,而不是绑定单一供应商。9 个合作伙伴覆盖了不同的合规、性能、成本场景,企业 IT 应该有根据业务场景选择合适沙箱的能力,而不是被供应商锁定。
第二条基线是 Agent 平台必须支持会话状态可追溯。Session 和 Events/items 的设计是 API 层提供的,但企业 IT 必须在内部建立"这个会话为什么被创建、谁授权了、最后为什么结束"的完整审计链,不能依赖 API 提供的原始数据。
第三条基线是 Agent 平台必须支持子代理配置可管理。max_concurrent_subagents 这种参数必须由企业 IT 统一配置,而不是每个 Agent 实例自己决定。子代理的并发数直接影响资源消耗和攻击面,企业必须有统一的策略。
第四条基线是 Agent 平台必须有明确的数据边界。Agents API 在公测期间明确指出 data residency 仅 US、Zero Data Retention 不支持,这种透明的信息披露是企业 IT 评估合规风险的基础。企业 IT 必须基于这种披露做风险评估,在企业内部决定哪些工作流可以走 API、哪些必须本地。
第五条基线是 Agent 平台必须支持与现有模型协议的兼容性。MCP 标准化、Responses API 兼容性、跨模型支持,这些都是平台必须具备的兼容性能力。Agent 平台不应该要求企业 IT 抛弃现有的 MCP 工具或模型选型,而应该把新平台融入现有的工具栈。
从工程新基线到企业 Agent 平台的标准化采购
把 Agents API 的发布放回企业 IT 的整体 Agent 平台采购语境,可以看出 2026 年下半年 Agent 平台市场正在进入标准化阶段。这种标准化阶段给企业 IT 的预算分配、流程设计、风险评估都带来了具体的工程基线变化。
在预算上,Agent 平台从"年度大合同"变成"按调用量计费",预算的可预测性和灵活性都改善了。在流程上,Agent 平台从"年度评估"变成"持续接入新能力",企业 IT 需要建立持续评估的流程,而不是一次性选型。在风险上,Agent 平台从"单点故障"变成"多基础设施可切换",供应商风险显著降低。
把这三个变化落地到企业 IT 的具体工作里,就是把 Agent 平台的采购决策从"选哪一家"转向"如何接入多家"。这种转向不是技术上的复杂性,而是治理上的成熟度。把这种治理成熟度落实到企业 IT 的工程基线里,就是 2026 年下半年 Agent 平台标准化阶段最直接的下一步动作。
