谈谈 Claude Code 与 Codex 的设计差异
虽然我个人非常非常讨厌 Anthropic 这家公司，但是老实讲，Claude Code 这个产品我真的很难不承认它做的确实非常好，仅从产品设计上，我真的很喜欢 Claude Code。
深度使用过 Claude Code 和 Codex 的人，大概都能很明显地感受二者的差异。Claude Code 像一个坐在你旁边、会主动指出问题的资深工程师。Codex 像一个领了任务就埋头干完、中途不废话的执行高手。这种差异到底来自哪里呢？是模型更强，还是产品在设计上走了不同的路？
Claude Code 有个 /btw 命令，by the way，我特别喜欢这个指令，名字简洁又精准——执行过程中有新想法，一个 /btw，它立刻就会响应。而现在甚至连 /btw 都不需要了，在 Claude Code 执行任务过程中，你有了任何新的想法，都可以随时输入，随时插话，它可以随时响应，而不中断当前的任务。我在实践里经常出现的场景大概是这样：用 /goal 起了任务，半小时后发现问题，直接在 session 里纠正，它立刻就能调整方案。这种随时可以转向的安全感，是它设计上最大的价值。这也是我一直离不开类 Claude Code 设计 Agent 的原因。
而 Codex 走的是完全不同的路径。在 /goal 执行过程中，你没办法随时插入新想法。这两种风格背后，是两套截然不同的设计哲学。
接下来我会试着根据我个人的实践和理解来解释一下 Claude Code 和 Codex 的设计差异，以及未来可能的演进方向。
GPT-5.5 和 Codex 的上下文窗口到底有多大？
先看数字。OpenAI API（gpt-5.5）支持约 105 万 token 的上下文，最大输出 128K。但到了 Codex 产品层面，官方标称值是 400K——而且这 400K 并非全部可用于输入。系统要预留输出空间，实际可用的输入部分通常只有约 272K，你看到的 258K 是再留了一道安全余量。
所以当你听到"Codex 只有 400K"时，准确的说法是：模型有能力做到更大，但产品层面设了上限。
既然 OpenAI API 能做到 1M，为什么 Codex 只有 400K？
这不是技术差距，是产品取舍。四个原因：
产品定位不同。 Claude Code 的定位是长时间、超大代码库开发，所以优先给 1M。Codex 更强调自主执行任务和单步推理质量，而不是尽可能多塞上下文。
成本与延迟。 上下文越大，每步推理需要处理的 token 越多，成本和延迟都会显著增加。OpenAI 更倾向于通过自动压缩和总结来控制上下文，而不是始终保留全部历史。
大上下文并非总是更好。 Anthropic 官方文档也承认这一点——上下文越长，注意力质量可能下降。1M 是能力上限，不代表一直塞满效果最好。Claude Code 在实际运行中也会做服务器端压缩。
这不是模型能力的差距。 GPT-5.5 API 已经支持百万级窗口，开放给 Codex 用户只是时间或策略问题。中等规模项目，Codex 的 258K–400K 通常够用；超大型单体仓库或多仓库联动，Claude Code 的优势才体现出来。
如果说上下文窗口的差异是产品策略的选择，那么两家在更深层的东西——产品设计哲学上的分歧——要鲜明得多。
仅就 CLI 而言，Claude Code 和 Codex 在设计上有什么本质区别？
二者代表了两种完全相反的思路：
| 维度 | Claude Code CLI | Codex CLI |
|---|---|---|
| 定位 | AI Pair Programmer（长期协作） | AI Agent（执行任务） |
| 工作方式 | 偏对话式，与开发者协作 | 偏任务式，替开发者执行 |
| 默认行为 | 边想边沟通，边做边确认 | 自主完成再汇报 |
| 项目理解 | 强调整个代码库上下文 | 强调当前任务相关上下文 |
| 修改代码 | 逐步讨论、逐步修改 | 倾向于直接完成任务 |
| 长会话 | 更擅长保留上下文 | 更容易压缩上下文 |
| 架构讨论 | 很强，乐于探讨 | 较保守，避免发散 |
| 对用户干预 | 希望你参与和指导 | 希望你完全放手 |
Claude Code 的设计：人在回路。 Anthropic 从第一天起就没打算把它做成一个"执行器"。你说"我要重构整个权限系统"，它通常不会直接动手，而是停下来问："我看到现在有三套权限模型。你是希望统一成一种权限模型，还是保持向下兼容？我建议先做设计。"整个过程像一位 Staff Engineer——不断确认、解释、同步思路。官方和第三方分析都认为，它的设计重点就是协作式开发。
Codex 的设计：自主 Agent。 理念更接近"任务交给我，你别管了"。下达任务后，它开始：搜索 → 修改 → 测试 → 修 Bug → Commit，最后告诉你一句"Done"。很多人觉得 Codex 很安静，因为它是故意设计成这样的。OpenAI 希望你写一句 prompt，去喝咖啡，回来看结果，而不是一直陪它聊天。
这种体感差异来自模型还是工程层？
来自 Harness（工程层），而不是模型本身。
真正决定 CLI 体验的是：Prompt 设计、Tool Calling 机制、Memory 管理、权限控制、Context 管理——模型只是其中的一层。很多开发者忽略了一个关键事实：Agent ≠ Model，Harness 往往对体验的影响更大。
这种影响具体体现在两个维度。
维度一：主动性 vs 不跑偏。
Claude Code 的系统提示非常强调一条：如果发现用户遗漏了问题，请主动指出。比如你让它"给登录页加验证码"，它很可能会说："我注意到登录接口没有 Rate Limit，建议一起补上。Session Token 生命周期也有问题。"Reddit 上有人总结得很精辟："Claude Code tries to create initiative."
Codex 的 Prompt 则相反：不要做用户没要求的事情。你让它修一个 Bug，它就只修这个 Bug，不会顺手重构。所以很多人觉得 GPT 比 Claude 保守——这其实是 Harness 故意设计的边界感。
这种不用专用命令、随时可以插话的设计，本身就是"人在回路"哲学最直接的体现。
这也带来了一个反直觉的优势：Codex 很少过度设计。Claude 容易出现"这里可以抽象、那里可以封装，我建议整个重构"——本来改 20 行，最后改 800 行。Codex 一般不会，它更像"Fix exactly what you asked"。很多生产环境依赖这种克制。
维度二：上下文管理策略。
| Claude Code | Codex | |
|---|---|---|
| 思路 | 尽量保留，越长越好 | 上下文是消耗品 |
| 手段 | 保持完整对话历史 | 持续 Compact / Summarize / Prune |
| 优势 | 长重构很舒服，上下文不丢 | 始终聚焦当前任务，不跑偏 |
| 代价 | 容易过度设计、发散 | 同 Session 做多件事后，容易忘掉前面设计 |
如果说交互习惯可以通过适配来弥补，那么一个更根本的问题是：当任务变长、需求变多时，Agent 如何保持方向感？这就引出了 /goal 和 dynamic workflows。
Goal 和 Dynamic Workflows 是一回事吗？
/goal 最早是由 Codex 率先支持的功能，顾名思义，也没什么好解释的了。dynamic workflows 是 Claude Code 随着 Claude Opus 4.8 一并发布的，Opus 4.8 配合 Ultracode 可以实现动态工作流。表面上看二者都极大解放了人力，一定程度上实现了任务的 Agent 托管，但是实际上它们完全是两个不同层面的东西，不是互相替代的关系。
Goal 定义 Agent 应该追求什么结果（What）。 这相当于一个长期约束："把这个仓库升级到 React 19，同时保证所有测试通过。"Agent 可以自己决定先扫描哪些文件、先改依赖还是改代码、什么时候跑测试——但始终围绕这个 Goal。它的特点是生命周期长、可跨阶段、关注最终是否达成。
Dynamic Workflows 定义 Agent 在实现过程中如何组织工作（How）。 关注的是：这个阶段应该先调查再动手，还是边改边验证？Goal 没变，Workflows 可以完全不同。比如 Goal 一直是"修复 CI"，方案可以是先读日志找原因再改，也可以先试最常见的问题不行再扩大搜索，甚至并行分析多个可能的原因。
一个是锚定终点，一个是组织路径。
所以当 Claude Code 这样一个原本以过程协作为核心的产品开始引入 Goal，背后的逻辑并不是它要转变方向，而是开发者希望 Agent 不再只是执行一段流程，而是真正对最终目标负责。有了 Goal，即使中途插话、新增约束、调整计划，Agent 仍然知道最终要完成的是什么。二者不冲突，反而互补。
如果 Goal 持续几天，Codex 不会越跑越偏吗？
这个问题触及了当前所有 Coding Agent 的核心痛点，包含两个不同层面的挑战。
第一层：需求会变化，这是软件开发的常态。 现实从来不是"第一分钟定义完美需求，后面照做"。更常见的是：开始只有大方向 → 做到一半发现设计有问题 → 产品经理新增约束 → 自己读代码后推翻初案 → Review 后再调整。一个优秀的 Coding Agent 应该能够演化 Goal，而不是死脑筋地坚持最初的版本。Claude Code 的优势之一就是执行过程中可以不断吸收新输入。
第二层：上下文窗口大小不是最根本的问题。 很多人归咎于"200K 不够"，但这只是表象。
真正的问题是：Agent 是否拥有稳定的长期记忆结构。
假设有一天上下文变成了 10M——如果 Agent 还是每次把几天杂乱的聊天历史全部塞进去，它迟早还是会遇到信息冗余、检索困难、注意力分散的问题。仅靠扩大窗口解决不了长期协作。
Claude Code 目前更稳，不是因为窗口大，而是因为它倾向于维护项目状态（Project State），而不是单纯累积聊天记录。它会不断提炼：当前目标是什么？已完成哪些阶段？哪些约束仍然有效？哪些信息已经过时？
Codex 面临的风险是：如果 Goal 持续几天，依赖聊天历史加上不断 Compact，Agent 就必须依赖摘要。任何摘要都有信息损失，时间越长，损失越容易累积——最终必然偏离 Goal。
未来的解法可能长这样：
Project Goal
├── 当前目标
├── 已完成事项
├── 已确认约束
├── 未决问题
├── 决策记录（ADR）
├── 风险
└── 下一阶段计划
这不是聊天记录，而是一个由 Agent 自动维护、不断更新的结构化文档。Agent 每次工作时不需要回忆几十万 token，而是读取这份结构化状态，再结合当前代码和最近的上下文。Compact 不再意味着丢失核心信息，Goal 可以持续几天甚至几周，用户中途新增要求也只是更新状态。
Goal、btw、Dynamic Workflows ——它们共同指向一个方向：Agent 不再是一次性完成任务，而是在持续维护一个不断演化的软件工程项目。 上下文窗口仍然重要，但它负责的是当前工作集，而不是整个项目的历史。
Claude Code 和 Codex 其实在往同一个方向走？
这正是整个讨论中一条容易被忽略的暗线。
Claude Code 的起点是 Pair Programming。 它天生擅长协作、讨论、探索，但早期缺少一个"最终目标"锚点——容易在探索中发散，或者在一个设计方向上走太远而忘记原本要交付什么。所以它紧随 Codex 其后，引入了 Goal，给自己的过程协作加了一个终点约束。
Codex 的起点是 Task Execution。 它天生擅长聚焦、执行、交付，但面对软件开发中需求不断变化的现实——开始只有大方向、做到一半推翻设计、产品经理新增约束——它那种"一次性任务"模式越来越吃力。它需要变得能吸收中途输入、能演化目标、能在数天的开发周期中保持上下文一致。
换句话说：
Claude Code 在给自己补"目标感"，Codex 在给自己补"过程弹性"。
从相反的方向出发，走向同一个中间点。我想大概可以用下面这句话来描述这种融合的方向：
"未来开发体验会更像管理一位资深工程师：你负责告诉他最终要达到什么目标，以及过程中出现的新约束；至于每个阶段具体怎么推进，则由他根据当前情况动态调整，并在必要时与你沟通。"
当然，Codex 也不是在原地踏步。最近的一个更新就很能说明问题：之前多轮交互中，前面的推理过程经常被丢弃，导致 Agent 每次都要重新分析上下文、重新发现依赖关系，结果是重复的 token 消耗、KV 缓存失效，复杂任务里的跟进能力越来越弱。现在推理上下文会在 turn 之间保留，KV 缓存命中率提升，延迟和成本都降下来了。更关键的是，在处理代码库、长文档或多步规划这类需要持续思考的场景时，Agent 的行为变得更连贯、更可靠。
这是在 Codex 自身的设计思路上，保持长会话可靠性的一个关键更新——不是改成交互式，而是用工程手段解决上下文连贯性问题。方向不同，目标一致。
Goal、btw、Dynamic Workflows、长期上下文、Project State——这些不是孤立的功能。把它们串联起来，就是这两条产品线正在趋同的路线图。
Harness 会消失吗？
如果关注社区的变化，我们会发现 Superpower 这样的框架在逐渐从一线开发人员的视线里消失，这是因为，人们慢慢地意识到这一类 Harness 能力逐渐被 LLM 内化了。当然，这不代表 Harness 会消失。Harness 可以分成两类：
第一类：为弥补模型能力不足而存在的 Harness——确实正在快速消失。 复杂的 Prompt 拼接、多轮 Prompt 链、手工设计的 Reflection、各种 CoT 包装、自建 ReAct 框架——模型能力弱的时候，这些是必需品；模型变强以后，一句"先分析再计划再验证"模型自己就能完成。这类 Harness 的消亡是健康的，它们是过渡时期的拐杖，不是终点。
第二类：软件工程基础设施（Engineering Harness）——会越来越重要。 Goal、Dynamic Workflows、中途插话、Long-running task、Context Compact、Project State——这些已经不是 Prompt Engineering 了，它们属于软件工程基础设施。
一个 Agent 要开发三天，它需要知道：当前 Goal 是什么？哪些需求后来改了？哪些设计已经确定？哪些 Commit 已完成？哪些测试还挂着？哪些 TODO 还没做？
这些信息不可能、也不应该全部塞进 LLM 的上下文窗口。它们必须被存放在一个持续演化的工程状态管理器里。这已经不是模型能力的问题了。
| LLM | Harness | |
|---|---|---|
| 擅长 | 理解需求、推理、写代码、Debug、规划 | 生命周期、状态管理、权限、工具调用、Git、Sandbox、Cache、Memory、Context、Workflows |
| 本质 | Thinking（思考） | Operating（运营） |
一个贴切的类比：CPU 和操作系统。 今天已经没有人说"CPU 越来越强，操作系统就没用了"。CPU 负责计算，OS 负责调度、文件系统、权限、网络、生命周期——这不是 CPU 该干的事。未来的 LLM 和 Harness，大概率也是类似的关系。
为什么我们的讨论几乎没触及 Transformer 这些底层？
不是偶然的。这篇文章讨论了这么久——Claude Code、Codex、Goal、btw、Dynamic Workflows、Compact、长期任务——几乎没有触及模型底层。
原因是：当模型能力达到一定水平以后，开发者真正感受到差异的地方，越来越来自 Agent 层，而不是底层 LLM。
今天大家说 Claude Code "好用"，很少是因为 Claude Sonnet 在 Benchmark 上多了几个百分点。更多是因为：工作流舒服、不容易跑偏、能随时打断、理解整个项目——这全是 Harness 的价值。
模型优势从来就不稳固。君不见 Gemini 从御三家堕落为“美国豆包”只需要三个月...就在一个月前，GLM 5.2 发布的时候，Elon Musk 还在 Twitter 上讲，中国的模型能力可能在明年初就能追上 Fable 5，结果就在今天，Kimi K3 就震惊了全世界。开发者们太精明了，如果希望靠一两次的模型领先就绑住开发者们，那就太天真了。或许你也发现了，Dario 最近都不怎么吭声了...
未来几年的竞争会分化成两个方向：
- 模型（LLM）竞争——谁拥有更强的推理、代码理解和生成能力。这决定了 Agent 能思考到什么水平。
- Agent/Harness 竞争——谁能把这种能力稳定地应用到持续数天、数周甚至数月的软件工程中。这决定了 Agent 能否真正参与工程实践。
第一类 Harness（弥补模型不足的 Prompt 编排）会越来越少。但第二类 Harness（管理项目状态、工作流、工具、长期记忆和协作）的重要性只会越来越强。
最终格局不会是"LLM 完全接管 Agent"，而更像是：
LLM 成为 Agent 的推理引擎，Harness 成为 Agent 的操作系统。
模型负责思考，Harness 负责把这些思考组织成一个可持续、可协作、可恢复的软件工程过程。Goal、btw、动态工作流、长期上下文——这些几乎都属于后者。而这些能力，很难仅靠把模型做得更大、更强就自然获得。
这也是我认为的，不管是 Claude Code 还是 Codex，还是其他的 Coding Agent，在未来，设计上一定会趋同。而体现各家产品竞争力的关键就在于，如何更好地将自家的 LLM 模型与 Harness 结合在一起。
无独有偶，Kimi K3 的博客也提到了这一点：“K3 was trained in the preserved thinking history mode. If the agent harness fails to pass back all the historical thinking content as required, or if an ongoing session with another model is switched over to K3, generation quality may become highly unstable”。翻译过来就是“K3接受了保存式思维历史模式的训练。如果代理机束未能按要求回传所有历史思考内容，或者从另一个模型的持续会话切换到K3，生成质量可能会变得极不稳定”。
2026-07-16