OpenAI Workspace Agents：不是 GPTs 2.0，而是把 Codex 变成了通用 Agent 运行时

这篇文章帮你搞懂：OpenAI 昨晚发布的 Workspace Agents 到底新在哪，为什么它不是 "GPTs 换个名字"，以及对程序员和团队意味着什么。

一、先讲结论

2026-04-22，OpenAI 发布了 Workspace Agents，目前在 ChatGPT Business / Enterprise / Edu / Teachers 做 Research Preview，免费到 2026-05-06，之后改为 credit 计费。

表面上，它是 Custom GPTs 的"组织版升级"：一个团队可以共享、带权限、能调工具的 Agent。

但真正值得看的，是它底下那一层——它把原本用来写代码的 Codex，抽象成了一个通用的 Agent 执行环境：有文件、有代码沙箱、有工具、有持久 memory、能长时间异步运行、能被 Slack 触发、可以被审批、可以被合规监控。

所以这次发布你看到的是一个"企业 Agent 产品"，但我认为它背后真正的信号，是 OpenAI 把 Codex 从 "coding agent" 拧成了 "agent runtime"。两件事看起来差不多，做产品的人写代码的人应该能感觉到差别。

顺带一提：这条路线 OpenAI 并不是独走。就在两周前（2026-04-08），Anthropic 发布了 Claude Managed Agents，底层理念几乎一样——托管的 harness + sandbox + 工具 + memory + tracing。两家同一个月先后出手，说明这个抽象层已经不是赌博了，是共识。差别在于谁做成什么形态，这个后面第五节会细讲。

谁适合读这篇：做 Agent 产品的、在企业内部推 AI 落地的、或者你就是个好奇这东西底层怎么跑的工程师。

二、它在解决什么问题

先看 Custom GPTs 的尴尬处境——2023 年底发布、红了半年、然后基本停滞。不是没人做，而是做出来以后没地方用。原因也不神秘：

• GPTs 是"问答式"的。你给它一段 prompt，它回你一段内容。没有状态、没有后台、没有定时、没有事件。
• GPTs 是个人的。你做了一个 "SQL 助手"，分享给团队，每个人打开都是一个空白新会话，谁用谁负责记上下文。
• GPTs 对工具的接入是 Action 级别的。调一次 API、拿一次数据、写进回答里，就结束了。要做一个"监控三个 Slack 频道，每天汇总成 ticket"的流程？GPTs 做不到。
• GPTs 没有企业级的治理。哪些人能建、能用哪些工具、敏感操作要不要审批、出了事怎么追——基本上靠自觉。

这套东西落到公司里就变成一个很别扭的东西：比 Slack Bot 笨，比 RPA 贵，比真的自动化流程还脆。大多数企业用它写了几个 prompt 模板就没下文了。

Workspace Agents 想补的，就是这几块：任务而非问答、团队而非个人、事件驱动而非人驱动、可治理而非裸奔。

三、它是怎么工作的

官方的描述非常克制，只说"powered by Codex in the cloud"。但如果你在 2025 下半年跟过 Codex，这句话的信息量其实很大。

2025 年重生版的 Codex（注意不是 2021 年那个老的 code-davinci）是一个 云端 coding agent：它有自己的容器、自己的文件系统、可以安装依赖、可以执行命令、可以连 GitHub、可以跑单元测试。它本质上不是一个"模型"，是一个"带壳的执行环境 + 模型"。

Workspace Agents 做的事，就是把这个壳从 "写代码" 场景拎出来，变成一个通用 Agent 运行时：

几个关键点值得展开。

1. 运行时是 Codex 容器，不是"调模型 + 拼 prompt"

这意味着 Agent 可以写脚本、跑脚本、持有文件、下载数据、缓存中间结果。对程序员来说最直观的比喻是：每个 Agent 背后是一个你 SSH 不进去但它自己能用的开发环境。

容器有几层含义经常被混为一谈，这里单拎出来：

• 文件系统：Agent 在一次 session 内读写的文件是持久的，它可以"下载三份 CSV、拼出一个透视表、再生成 PDF"——中间产物不用每次都重新算。
• 代码执行：它不是 Python tool call 式的"一行一调"，而是可以 apt install、pip install、跑完整脚本、拿 exit code。这是 Codex 这个底座带过来的能力。
• 网络：容器带 egress，可以调任何 HTTP API。这意味着你的"内部 API"只要能网达，Agent 就能用——不一定非得走官方 Connector。
• 隔离：每个 Agent 有独立 workspace，避免串号。这是企业场景里必须的。

这四件事合起来，才是"runtime"这个词的重量。只给第一条的叫"有状态会话"，只给第二条的叫"code interpreter"，四个都给才叫 agent runtime。

2. Memory 是跨 session 的

不是 "conversation memory"，是 workspace 级别的持久记忆。它记得上周你纠正过的"月度收入应该剔除内部账"，这周它不会再犯。官方描述是 "retain information across sessions" 和 "can be corrected mid-conversation, they should get better with use"。

需要警惕的是：这个 memory 的数据模型、检索策略、TTL、可审计性 OpenAI 都没公开。对 GDPR/SOC 2 敏感的公司，这一层是个悬着的问号。

3. 触发模型从 request/response 变成 event-driven

除了人在 ChatGPT 里 @它，它还可以被 cron 定时启动、被 Slack 的消息/提及/关键词触发。这是和 GPTs 最本质的差别——Agent 有"自己的循环"。

对照 serverless 的演进很有启发：AWS Lambda 刚出时也只能被 HTTP 同步调，后来加了 EventBridge、SQS、S3 事件触发器，才真正变成一个生态。Agent 正在走同样的路。

4. 权限和审批是一等公民

官方明说了：enterprise/edu 的管理员可以通过 role-based controls 决定"哪些用户组能建/能分享 agent"、"能用哪些工具"、"哪些操作（发邮件、建日程）需要审批"。还有 analytics 和 Compliance API 用来追事后。

把审批列为一等公民这件事我觉得是 Workspace Agents 最值得 Anthropic 学的地方——Managed Agents 的文档里权限主要是 scoped permissions 和 tracing，没有明显的 human-in-the-loop approval 原语。一个能改 Jira、发邮件、下单的 Agent，不配审批机制是不能进真实公司的。

四、举一个具体例子

官方给的例子里，我挑一个最能体现"为什么非得是 Agent 不可"的：Product Feedback Router。

任务描述：监听 Slack 中的用户反馈频道、客服工单、公开论坛，把反馈转成结构化的 ticket，每周一生成一份优先级摘要发给 PM。

你用 Custom GPT 做不了——GPT 不会主动监听。你用 Zapier 能拼一半——但 Zapier 很难做"这条反馈到底是 bug 还是 feature request、该分给哪个模块 owner"这种需要判断的事。你自己写也行——但你要写个守护进程、做 rate limit、维护分类规则、处理异常。

Workspace Agent 的跑法大概是这样：

sequenceDiagram
    autonumber
    participant Slack
    participant Agent as Feedback Router (Workspace Agent)
    participant Mem as Memory
    participant Tracker as Linear/Jira Connector
    participant PM

    Slack->>Agent: 新消息事件 (channel #feedback)
    Agent->>Mem: 拉取"已知模块 owner / 历史分类"
    Agent->>Agent: Codex 沙箱里跑分类脚本 + LLM 判断
    alt 是 bug
        Agent->>Tracker: 创建 ticket (待审批)
        Tracker-->>PM: 审批请求 (sensitive action)
        PM-->>Tracker: 批准
    else 是 feature request
        Agent->>Mem: 累加到本周摘要
    end
    Note over Agent: 每周一 09:00 cron
    Agent->>Agent: 汇总本周 memory
    Agent->>PM: Slack DM 发送优先级摘要

对工程师的意义是：你不再需要写一个带状态的小守护进程。你把"这个 Agent 要做什么、能用哪些工具、什么操作要审批"描述清楚，剩下的循环 OpenAI 帮你跑。

代价是什么？你把调度、存储、执行都搬到了一个你看不到日志细节的黑盒里。这是第六节要讲的。

五、它和相似方案有什么区别

把主流的"团队/企业 Agent 平台"放一起对比，差异就清楚了：

维度	Workspace Agents	Custom GPTs	Claude Managed Agents	Microsoft Copilot Studio
发布时间	2026-04-22	2023-11	2026-04-08	2024 GA
主要面向	企业终端用户（ChatGPT 里建）	个人/业务用户	开发者（API / SDK）	开发者 + 业务
形态	团队共享的任务型 Agent	问答型助手	托管的 Agent API（harness + sandbox）	低代码 Agent 编排
执行环境	Codex 云沙箱（文件 + 代码）	无真实沙箱	托管容器 Environment（Python/Node/Go 等）	自有 runtime + 外部工具
持久 memory	是，跨 session	否	是（research preview）	需自建
事件驱动	Slack / cron	否	由开发者触发 / 嵌入产品	是，强
工具接入	Connectors + 内建	Actions (OpenAPI)	Bash / File / Web / MCP	最广，老牌企业集成
权限治理	原生 role-based + 审批	弱	scoped permissions + tracing	强，AAD 集成
定价	免费至 2026-05-06，之后 credit（细节未公开）	订阅内含	token + $0.08/session-hour + Web search$10/1k	按 message / capacity pack
典型落点	公司内部自动化流程	轻量个人工具	嵌入到 Notion / Asana / Rakuten 等产品	企业 IT 流程

特别对比：和 Claude Managed Agents 的关系

你如果看完上面的表格觉得 "Workspace Agents 和 Claude Managed Agents 好像是一回事"——这个直觉是对的。两家在同一个月先后发布、底层叙事几乎一致：

自己搭 Agent 的脏活（sandbox / checkpoint / credential / permission / tracing）要好几个月，我们帮你托管，你只管声明 Agent 要做什么、能用什么工具、有什么约束。

甚至价值主张的原话都像同一个团队写的。Anthropic 官方博客："Shipping a production agent requires sandboxed code execution, checkpointing, credential management, scoped permissions, and end-to-end tracing. That's months of infrastructure work." OpenAI 这次的描述本质上是同一个意思的企业包装。

但两者处在完全不同的层。下面这张图把"谁服务谁"画清楚：

flowchart LR
    subgraph Anthropic[Anthropic 走法]
        A1[Claude Managed Agents API]
        A2[开发者集成进自己的产品]
        A3[终端用户在 Notion/Asana 里用]
        A1 --> A2 --> A3
    end

    subgraph OpenAI[OpenAI 走法]
        O1[Codex Cloud Runtime 内部底座]
        O2[Workspace Agents 产品]
        O3[终端用户在 ChatGPT/Slack 里用]
        O1 --> O2 --> O3
    end

• Claude Managed Agents 是 primitive（基础设施）。 它是一套 API：你 Create an agent → Create an environment → Start a session → 发 events，Claude 在它自己的 harness 里跑。Notion、Asana、Rakuten 已经在集成。类比起来像 AWS Lambda——你不会直接给用户用 Lambda，你用 Lambda 构建给用户的产品。
• OpenAI Workspace Agents 是 end-user product。 业务人员在 ChatGPT 里点按钮建 Agent，在 Slack 里 at 它，管理员在后台管权限。底下的 Codex runtime 目前没有作为独立 primitive 开放出来。类比起来像 Salesforce 上那种"不用写代码就能用的自动化"。

其它几个值得注意的差别：

• 定价透明度。Anthropic 明码标价：standard token rates + $0.08/session-hour active runtime +$10/1000 web searches，空闲时间不计。OpenAI 目前只说"免费到 2026-05-06，之后 credit"，具体怎么算没公开。对采购来说一边可以算账，一边只能等。
• 工具抽象。Claude Managed Agents 的外部工具接入走 MCP（Anthropic 自己发起的开放协议），OpenAI Workspace Agents 走 Connectors（自家生态）。这是两家长期风格的延续：Anthropic 更愿意开协议，OpenAI 更愿意做闭环。
• 内置工具。Claude Managed Agents 文档里列得很直白：Bash、File、Web search/fetch、MCP。OpenAI 这边除了 "Codex 写代码 + run" 和 Slack connector，公开的清单很少。
• 上手难度倒过来了。做一个 Workspace Agent，业务人员 30 分钟能搞定；做一个 Managed Agent，你得写代码。

Managed Agents 还有两个 Workspace Agents 目前看不到的东西：

• Outcomes 模式（research preview）：Anthropic 文档里说 "You define outcomes and success criteria, and Claude self-evaluates and iterates until it gets there"，并引用内部测试说这种模式比"标准 prompting loop"在任务成功率上高 10 个百分点。这是一个很 Anthropic 风格的抽象——用户只需声明结果，不用定义步骤。Workspace Agents 目前还是"人告诉它做什么"的心智。
• Multi-agent（research preview）：Managed Agents 明确列出多 Agent 协作能力，允许一个主 Agent 调用子 Agent。Workspace Agents 这次的官方材料里没看到明确的 multi-agent 原语，单个 Agent 之间如何协作还不清楚（这点合理推断：OpenAI 更可能走"一个 Agent 挂多个 tool"的扁平化路线）。

一个合理推断（官方没证实，标注为个人判断）：OpenAI 底下的 Codex runtime 大概率已经具备了 Managed Agents 那种 API 形态——agent / environment / session / events 这层抽象在 Codex CLI 和 Codex Cloud 里早就存在。只是 OpenAI 选择先把它包装成 Workspace Agents 这个产品卖给终端用户，而不是像 Anthropic 那样先卖给开发者。后面会不会也开放一个 "Agent Runtime API"，值得盯。

选型：到底什么场景选哪个

如果你是决策者，上面这些细节太碎了。把问题压到"我该选哪个"这一层：

你的场景	推荐	理由
公司内部流程自动化（月度对账、反馈分流、报表生成）	Workspace Agents	业务部门能自己搭，权限治理到位，集成 ChatGPT/Slack 就够用
把 Agent 嵌入自家 SaaS 产品给外部客户用	Claude Managed Agents	primitive 更干净，branding 可自定义，计费透明，能算进自己的 COGS
已经深度用 M365/Teams/Dynamics	Copilot Studio	生态深度无可替代
需要代码级定制的 Agent loop、不愿被 harness 绑死	自建 + Messages/Completions API	两家 Managed 路线都是"你放弃一点控制换一堆脚手架"，不接受这个 trade-off 就自己搭
对数据出境、审计合规极敏感	先都别选	两家的 memory 存储位置、数据驻留、审计粒度目前都不够清晰

我自己的实操建议：

• 如果你是业务负责人、内部没有专职 AI 工程团队 → 从 Workspace Agents 开始，免费期正好摸边界。
• 如果你是产品工程师、要做对外的 Agent 功能 → 起手就用 Managed Agents，别自己造 harness；但用之前把 $0.08/session-hour × 预期并发算清楚，小流量划算，大流量未必。
• 如果你已经在自己搭 Agent 框架、跑了几个月 → 别急着迁，先看它们成熟度再说。两家都在快速改，一个月之后的文档可能和现在不一样。

其它几点看法

• 和 GPTs 的关系不是升级，是替换。OpenAI 说之后会提供 GPTs → Workspace Agents 的转换工具，但底层抽象不一样，迁移多半是重做。
• 和 Copilot Studio 是正面竞争。微软靠深度集成 Teams/M365/AAD 卡住了大企业，OpenAI 靠 ChatGPT 生态和 Codex 的代码执行能力打差异。中小公司 OpenAI 更容易进，大企业微软更难被撼动。
• 和 Claude Projects/Claude Cowork 是不同的东西。Projects 是面向个人/小组的长上下文会话容器，Cowork 是 Anthropic 面向团队协作的产品线。这次要对标的是 Managed Agents，不要混淆。

六、局限与坑

这个产品正式推出才一天，我没实装过，但已经能看到几块值得警惕的地方：

1. Credit 定价还没披露细节。 免费到 5-6，之后改 credit。一个 Agent 跑 cron、跑代码、调外部 API，Token 消耗只是其中一项，Codex 沙箱时间、工具调用次数怎么算？目前没答案。对工程师来说这是最大的成本黑盒——一个"每 5 分钟扫一次 Slack"的 Agent，月末账单可能非常魔幻。

2. Memory 是双刃剑。 跨 session 记忆听起来很好，但它也意味着：错误的修正会被保留，过时的约定会被延续，从某个同事那里学到的偏见会渗透给整个团队用的 Agent。而且 memory 的检索/裁剪策略不透明，你很难确定这次它"想起"的是哪条记忆。

3. Prompt injection 仍是活的威胁。 OpenAI 提到了 "safeguards designed to block prompt injection"。在真实的 Feedback Router 场景里，Agent 要读 Slack 里陌生用户发来的消息——这正是 indirect prompt injection 最喜欢的入口。对抗性测试还没上量，最好别一上来就给敏感工具赋权。

4. 生态锁定在加深。 memory、workspace、connector 都在 OpenAI 那头。做久了迁移成本是指数的。对于"不想把流程绑定在一家厂商"的团队，这是结构性风险。这个批评对 Claude Managed Agents 同样成立——VentureBeat 在 Managed Agents 的报道里标题就点了 "raises vendor 'lock-in' risk"。Managed runtime 的商业本质就是把脚手架替你搭好，代价就是你搬不出来。没有哪家是例外。

5. 调试体验可能很糟。 当 Agent 在一个你看不见的 Codex 容器里跑代码、读文件、调接口，出错时你拿到的只有一段自然语言 trace。企业级 Agent 最后都会撞上这堵墙——可观测性。Compliance API 解决审计，不解决调试。相比之下 Anthropic 在这点上更明确：Managed Agents 的 Console 提供 "inspect every tool call, decision, and failure mode" 的 session tracing，这是开发者场景必须的。OpenAI 作为"给业务人员用"的产品，可能短期不会把这层完全暴露——但这反过来意味着工程团队想用来做关键流程会很难排查。

6. Research preview 的含义不要误读。 OpenAI 这次明确标的是 "research preview"。历史上 OpenAI 的 research preview 产品（比如早期的 Operator）行为会在几个月内明显变化——prompt injection 防御、计费、工具清单、memory 策略都可能改。现在基于它定设计决策是危险的。免费期是给你摸边界的，不是给你压生产的。

七、最后总结

Workspace Agents 这个产品本身，我的评价是：方向对，抽象对，生态对，落地难度被低估。

但我想说的不是产品。

这次发布真正的信号是：OpenAI 开始把 Codex 当成通用 Agent runtime 卖了。过去两年大家都在问"Agent 落地差哪块"，答案一直是那三块老问题——执行环境、持久状态、治理。模型好不好从来不是瓶颈。

Codex 2025 年重生的时候解决的是第一块（云端真实执行环境），这次 Workspace Agents 把第二块和第三块补上了。把"能跑代码的容器"抽象成"能跑任务的容器"只需要在产品设计上迈一步，但这一步迈过去，格局就变了：Agent 不再是模型的应用层，而是一个带运行时的新平台。

而且这不只是 OpenAI 一家的押注。Anthropic 两周前用 Claude Managed Agents 给出了同一个命题的不同解法：一边把 runtime 当 primitive 开放给开发者，一边把 runtime 包成产品卖给企业员工。两条路都成立，两家都在赌"托管 Agent runtime"这个抽象层本身是长期市场。这才是这个月最重要的事。

这对我们意味着几件事：

• 短期，做"内部 AI 工具平台"的团队，价值会被稀释——OpenAI 直接把工程脚手架给你了。
• 中期，真正稀缺的不再是"能写 Agent"的人，而是"知道哪些流程该变成 Agent"的人。这更接近产品经理和业务专家的工作，而不是工程师。
• 长期，如果 Codex runtime 这一层真的跑通，它会是下一代的 "Agent 版 AWS Lambda"。问题是 OpenAI 会不会把它开放成一个独立平台——目前还看不出来。

我会装一个试试。但在敏感流程上，我暂时不会把关键路径交给它。

---

参考资料

• Introducing workspace agents in ChatGPT — OpenAI 官方公告
• OpenAI launches workspace agents that turn ChatGPT from a chatbot into a team automation platform — The Decoder
• OpenAI unveils Workspace Agents, a successor to custom GPTs for enterprises — VentureBeat
• OpenAI updates ChatGPT with Codex-powered 'workspace agents' for teams — 9to5Mac
• Scaling Codex to enterprises worldwide — OpenAI 官方企业化公告
• Claude Managed Agents: get to production 10x faster — Anthropic 官方公告
• Claude Managed Agents overview — Anthropic 官方文档（agent/environment/session/events 抽象、内置工具、定价）
• Anthropic rolls out Claude Managed Agents — InfoWorld
• Anthropic's Claude Managed Agents gives enterprises a new one-stop shop but raises vendor 'lock-in' risk — VentureBeat