夜雨聆风Claude 和 OpenAI 的下一战：从聊天助手到工作系统
Claude Cowork 最近提升 usage limits，不是为了让用户多聊几轮。
它给出的典型任务是：跨几十个账户做研究、生成定期报告、处理收件箱、起草回复。
这些任务的共同点是，都不适合在一个聊天窗口里完成。
同一周，OpenAI 发布 Codex for every role。Codex 不再只是给程序员写代码，而是开始进入分析、研究、设计、投研、运营这些知识工作场景。
一个在鼓励用户把更大、更长、更复杂的任务交出去。
一个在把 Codex 推到更多角色、更多工具、更多工作流里。
这说明一个变化已经发生：
AI 产品的核心，不再只是回答问题。
而是接住工作流。
但它们进入这个终点的路径不一样。
Claude 更像在回答：
用户和企业为什么敢把大工作托付给 agent？
OpenAI 更像在回答：
如何让更多人在更多场景里，更低摩擦地启动、迭代和发布工作？
这个差异，比“谁的模型更强”更值得看。
因为 agent 产品的竞争，已经不只发生在模型回答质量上了。
真正的竞争，开始发生在上下文、执行、审阅、信任和产物之间。
01
从聊天助手到工作系统
过去讨论 ChatGPT 和 Claude，大家很容易问几个问题：
谁更聪明？
谁更会写？
谁代码能力强？
谁幻觉少？
这些问题当然还重要，但它们已经不是最核心的产品问题。
今天真正重要的问题变成了：
AI 能不能接住一个真实任务？
能不能读懂上下文？
能不能调用工具？
能不能持续执行？
能不能把中间状态保存下来？
能不能让用户审阅、修改、继续推进？
能不能把结果变成一个真正可用的交付物？
这就是为什么 Claude Cowork、Claude Managed Agents、Codex Sites、Codex plugins、annotations、Workflows、skills、memory、outcomes、grader、sandbox、MCP tunnels，会在同一个时间段密集出现。
它们看起来是不同功能。
底层其实在解决同一个问题：
如何把一次聊天，变成一段可持续、可恢复、可复用、可审阅的工作过程。
这也是为什么我觉得“聊天助手”这个词已经不够用了。
聊天助手的默认假设是：用户问，AI 答。
工作系统的默认假设是：用户给目标，AI 带着上下文去推进任务，人类在关键节点判断和接管。
这两个东西不是同一个产品形态。
02
Claude 先解决“敢不敢托付”
Claude 这条线，最近最明显的关键词不是“更快生成”。
而是 trust、runtime、boundary、eval、observability。
Anthropic 在 2026 年 4 月 23 日发布过一篇 Claude Code 质量复盘。里面有一个很重要的结论：用户感到 Claude Code 变差，并不是因为 API 或 inference layer 出了问题，而是三个产品层变化叠在了一起。
默认 reasoning effort 从 high 改成 medium。
闲置 session 的 thinking history 清理逻辑出 bug。
为了减少 verbosity 加入的 system prompt 限制伤到了 coding quality。
这篇复盘表面上是在解释一次质量事故。
但更深一层，它说明 agent 的质量已经不只是模型能力。
默认参数会影响用户眼里的智能水平。
context retention 会影响 agent 是否记得自己为什么这么做。
system prompt 的一句限制，也可能改变 agent 在工具调用之间的行为边界。
到了长任务 agent，这些都不是小体验。
它们就是产品能力本身。
Anthropic 后来在 Managed Agents 架构文章里，把这个思路继续往下推。
它把 agent 拆成 session、harness、sandbox 三个接口。session 是 append-only log，harness 负责 agent loop，sandbox 负责运行代码和工具。
这件事看起来很底层，但解决的是长任务 agent 的基本问题：
任务不能绑死在一个会挂、会卡、也难审计的容器里。
sandbox 可以失败后重建。
harness 可以从 session log 恢复。
credentials 不需要进入运行模型生成代码的环境。
完整事件流也不必全部塞进 context window，而是可以保存在外部，需要时再读取。
再往企业场景走一步，就是 self-hosted sandboxes 和 MCP tunnels。
Claude Blog 在 2026 年 5 月 19 日发布的 Managed Agents 更新里，重点就是这两件事：工具执行环境可以跑在客户自己的基础设施里，agent 也可以通过 MCP tunnels 访问私有网络里的工具和数据源，而不用把内部服务暴露到公网。
这说明 Claude 想解决的不是“多接几个工具”。
它想解决的是企业真正担心的问题：
内部代码和文件会不会离开边界？
私有 API 和数据库要不要暴露公网？
凭证会不会进到不该进的运行环境？
任务失败以后能不能恢复？
过程能不能审计？
用量和权限能不能控制？
这就是 Claude 路线的核心。
它不是先把入口铺到所有地方，而是先把“可托付性”做深。
让 agent 能跑长任务。
让长任务能恢复。
让恢复有日志。
让执行有边界。
让结果有 grader。
让组织能看见、能限制、能审计。
Claude Cowork 的位置也应该放在这条线里看。
它不是一个更漂亮的聊天框。
它更像是把 Claude Code 的 agentic capabilities 移到知识工作场景里：研究、整理材料、生成项目交付物、做定期更新、处理收件箱和围绕核心工作的重复流程。
Claude 官方在 Cowork enterprise 发布里也提到，很多 Cowork 使用来自工程以外的团队，比如 operations、marketing、finance、legal。
这些团队并不是把最核心判断完全交给 Claude。
他们先把核心任务周围那些可以流程化、可以审阅、但原本占用大量注意力的工作交出去。
这是一条很现实的 adoption path。
不是“AI 替代整份工作”。
而是“AI 先接走那些适合被托付的工作链条”。
03
OpenAI 先解决“怎么让更多人开始用”
OpenAI 的路径不一样。
它当然也在补 agent runtime、企业边界和长任务能力。OpenAI 与 AWS 的官方发布里，就提到 OpenAI models、Codex 和 Managed Agents 进入 AWS，服务企业在既有 security、governance、procurement workflows 中使用 AI。
但从 Codex 和 ChatGPT 近期产品信号看，OpenAI 更明显的路线是：
降低启动成本。
扩大使用入口。
让产物可展示、可发布、可反馈、可复用。
OpenAI 在 6 月 2 日的 Codex 官方文章里，把标题写成了《Codex for every role, tool, and workflow》。
这个标题很直接。
Codex 不再只是给工程师写代码，而是要进入 every role。
官方提到，非开发者已经占到 Codex 用户约 20%，而且增长速度超过开发者 3 倍。
这件事很关键。
因为它说明 coding agent 正在跨出传统工程边界。
Data Analysis、Research、dashboard、brief、creative asset、financial research，这些任务本质上都不是“写代码”。
它们更像一种可编程知识工作。
Codex 的价值，也不只是生成代码文件。
它在把多种材料、数据、工具和输出格式串起来。
这就是为什么 OpenAI 要做 role-specific plugins。
Sales 插件、Data Analytics 插件、Product Design 插件、Creative Production 插件、Investment Banking 插件、Public Equity Investing 插件，本质上是在给不同角色预装上下文、工具、技能和工作流。
过去用户要先写很长的 prompt：
你是一个分析师。
你要用这些数据源。
你要按这种格式输出。
你要遵循这些业务规则。
你要知道这个工具怎么接。
现在 OpenAI 想把这些东西变成 plugins 和 skills。
这就是降低启动成本。
Sites 解决的是另一个问题：AI 产物不应该只停在对话框里。
OpenAI Help Center 在 ChatGPT Enterprise & Edu release notes 里写得很具体：企业用户可以让 Codex 创建、迭代并部署轻量 full-stack JavaScript / TypeScript web apps，得到 hosted site URLs，同时保留 workspace 内部访问控制。
这意味着 ChatGPT / Codex 的输出正在从“文本答案”变成“可访问的软件产物”。
annotations 也很关键。
很多用户不是不能表达需求，而是很难把视觉反馈翻译成 prompt。
在结果上直接标注，让 agent 根据标注修改，是把 human taste 接回 agent loop 的方式。
OpenAI 2 月发布的 harness engineering 文章，其实已经把这件事讲得很清楚。
工程师的角色正在变化。
不只是写代码，而是设计环境、明确意图、建立反馈回路，让 Codex agents 做可靠工作。
把这个思想扩展到非工程岗位，就是：
知识工作者也不只是“问 AI 一个问题”。
他们开始设计自己的工作环境、上下文、工具组合、输出标准和反馈方式。
OpenAI 的优势在于，它有 ChatGPT 这个默认入口。
当 Codex、plugins、Sites、annotations、mobile remote control、Goal mode 都接到 ChatGPT 体系里，用户不需要先理解一套复杂 agent 平台。
他只需要从一个熟悉入口开始，把任务一点点交给系统。
这就是 OpenAI 路线的核心。
它先做 adoption surface。
让更多人开始用。
让更多任务能被放进去。
让结果能被看见、改动、分享和发布。
然后再逐步加深 workflow、memory、governance 和 runtime。
04
真正的变量，是上下文复利
Claude 和 OpenAI 的路径不同，但最后都会撞到同一个变量：
上下文。
这里的上下文，不是“更长的 context window”这么简单。
它包括用户长期项目背景、团队偏好、工具权限、工作流、成功标准、历史失败经验，以及哪些节点必须由人类判断。
Claude 的 dreaming，是把历史 session 和 memory stores 里的隐性经验压缩成可复用 memory。
Claude 的 outcomes，是把“好结果”显式写成 rubric，再让独立 grader 检查。
Claude 的 session log，是把长任务过程放到 context window 外保存，避免未来需要的信息被不可逆删掉。
OpenAI 的 plugins，是把不同角色的上下文、工具和技能打包。
OpenAI 的 Sites，是把生成结果从聊天框里带到可访问、可分享的 artifact。
OpenAI 的 annotations，是把人的视觉反馈和 taste 接回 agent 执行回路。
OpenAI 的 harness engineering，则把 repository knowledge、feedback loop、agent legibility 当成工程生产力的核心。
这些东西都在做同一件事：
把一次性对话变成长期工作资产。
未来 agent 产品的竞争，不会只看“这一次谁回答得更好”。
更关键的是：
用户前 100 次工作，能不能让第 101 次工作变得更快、更准、更符合他的组织和场景。
这就是上下文复利。
一个产品如果每次都从零开始，再强也只是强模型入口。
一个产品如果能持续沉淀用户的工作方式、质量标准、工具环境、审阅偏好和组织边界，它就开始变成工作系统。
05
薄 wrapper 会越来越难
如果你在做 AI 产品，这轮趋势有一个很现实的提醒：
只做单次生成，会越来越难。
Claude 和 OpenAI 都在吃掉这一层。
真正有价值的位置，会出现在更深的 workflow、更稀缺的上下文、更强的信任边界，或者更关键的分发入口里。
面向企业，可以多看 Claude。
权限边界、审计日志、sandbox、私有网络连接、human review、rubric、eval、失败恢复、用量透明度，这些听起来不如 demo 好看，但它们决定企业敢不敢让 agent 进入真实业务。
面向知识工作者和 prosumer，可以多看 OpenAI。
降低启动成本，减少重复提示，让结果可见可改可发布，让 plugins / skills 帮用户少写背景，让 annotations 把人的判断接回系统。这些细节会决定用户第二次、第三次还愿不愿意继续用。
所以这场竞争的关键，不是“谁更像人”，也不是“谁更会聊天”。
而是：
谁能接住真实工作流。
Claude 在补信任、边界、恢复、审计和可托付性。
OpenAI 在补入口、分发、角色插件、可发布产物和低摩擦使用。
一个让用户敢把大任务交出去。
一个让更多人把更多任务放进来。
这就是 Claude 和 OpenAI 的下一战。
聊天窗口还会存在。
但它会越来越像入口，而不是终点。
