从 Claude Code 的未开放功能，看它与 Codex 对同一问题的不同解法

这两天我并行比较了一下 Claude Code 和 Codex 的源码。我觉得 Claude Code 中最值得关注的，不仅是已经公开的功能，更是那些已经在代码库中长出来、但尚未完全暴露的抽象：

• proactive（Agent 不再只是被动响应，而是能主动推进任务）
• sleep / wake（Agent 可以进入等待状态，并在合适时机恢复工作）
• channel（同一个 Agent 可以拥有多个消息入口或协作通道）
• brief（面向长线程协作的工作摘要 / 工作记忆层）
• remote ingress（外部系统、远端事件或非本地交互如何进入 Agent，而 IM / chat channel 是最自然的第一落点）

分开来看，这些像是一些零散功能；放在一起看，它们其实指向同一个问题：一个 coding agent 如何从“单轮执行器”演化为一个长期在线、可协作、且能被外部世界持续驱动的助手？

从这个角度看，Claude Code 更像在定义一种 assistant-first runtime。它内部甚至已经出现了带有一点 “agent OS” 味道的命名，比如 KAIROS。它关心的不再只是单轮 tool use，而是 Agent 何时该自主推进任务，何时该被事件唤醒，外部消息如何进入系统，以及哪些信息应保留为工作摘要，哪些应直接进入执行流。这些未开放能力并不是边缘功能，而是指向了一条相当清楚的产品方向。

Codex 也在解决同样的问题，但给出了不同的答案。虽然它同样在处理长期状态、后台任务、外部集成和多 Agent 协作，但抽象方式明显不同。Codex 更像是一个可复用的 agent runtime substrate：session / turn / thread / task / event / app-server / MCP server 这些边界都定义得很明确。它并非没有编排能力，而是更倾向于把更高层的 workflow、入口整合和长期在线语义留给外部前端、宿主应用或上层 Agent 系统去定义。

Codex 的 server mode 明显表达了这种意图。无论是 app-server 还是 mcp-server，都说明 Codex 不只想做一个 TUI 的 Agent 应用，它更想成为一种底层运行时能力或者服务，供其他客户端、前端，甚至其他 Agent 系统调用。

相比之下，Claude Code 更倾向于把调度、协作、唤醒机制、brief 和外部入口内置化。因为它试图打造的是一个持续存在的助手，而不仅仅是一个可嵌入的引擎。

可以说：

• Claude 在定义“未来的助手应该是什么样”
• Codex 在定义“支撑这种 Agent 的 Runtime 底层该如何构建”