第 23 章 三家架构哲学对比:Claude Code vs Codex vs Cursor

这一章是全书唯一横向对比章。前面 19-22 章讲完了 Subagents、Workflows、Agent Teams,你已经知道 Claude Code 怎么用;这一章回答一个更底层的问题——为什么 Claude Code 是这样设计的,以及什么场景下你该换一把锤子。素材来自对三家泄露 system prompt 的研究分析(2026-07-07),仅作架构哲学探讨,不整段搬运 prompt 原文。

23.1 合规声明(先说清楚)

本章分析的素材来源是 system_prompts_leaks 仓库(公开 CC 协议仓库,曾被《华盛顿邮报》报道),里面是各家 AI 产品 system prompt 的非官方泄露快照。三点必须讲清:

1. 机密性:system prompt 是各家厂商视为专有的内容,本章仅作研究参考分析,不整段搬运原文,只引用极简短的关键短语并标注性质。
2. 时效性:任何一份 prompt 都是某个时间点的快照(本章核对基准为 2026-07-07 仓库版本,对应 Claude Code v2.1.202+ / Opus 4.8、Codex GPT-5.5、Cursor 当前版)。厂商随时迭代,结论会过时。
3. 真伪:仓库以「原样粘贴」为原则降低了失真,但少数条目仍需甄别。本章引用的关键机制均来自完整长 prompt,非碎片,可信度较高。

结论:本章是架构哲学的参照系,不是实现抄录。做产品选型时用来理解分歧,不要照搬某一家 prompt 原文进商业产品。

23.2 结论:选型前先选信仰

三家 AI 编码工具的架构差异,表面是功能不同,底层是对 AGI 路径的信仰不同。选型之前,先选信仰。

	Claude Code	Codex (GPT-5.5)	Cursor
哲学	编排派	推理派	集成派
智能落在哪	多智能体协作 + harness 编排	单模型推理深度 + reasoning 旋钮	IDE 上下文 + 模型可替换
对 AGI 的押注	模型 + scaffolding 同等重要,编排是差异化	单模型 scaling,推理是核心旋钮	模型是商品,集成体验是护城河

一句话压缩:Claude Code 把力气花在「怎么让多个 agent 协作」,Codex 花在「怎么榨干单个模型的推理」,Cursor 花在「怎么把模型嵌进 IDE 并随时换引擎」。

这三条路不是对错之分,是押注方向之分。理解了这一点,你才能回答自己的 Agent 产品该走哪条路——以及为什么本书第四部分的设计动因是「编排密集」。

23.3 为什么对比这三家

两个理由:

第一,做 Agent 产品选型的底层框架。如果你要自建一个 Agent 产品(本书第五部分会讲产品化),第一个架构决策不是选哪个模型,而是选哪种 Context 策略、哪种 Multi-agent 档位、是否模型无关。这三家正好是三种范式的成熟工业实现,省得你从零试错。

第二,理解 Claude Code 设计选择的参照系。本书前面 19-22 章讲了 Subagents、Workflows、Agent Teams,你可能会问:为什么 Claude Code 要做 ToolSearch 分页?为什么 Workflow 是 JS 脚本而不是 prompt?为什么 ScheduleWakeup 要强调避开 300 秒?只有看了 Codex 和 Cursor 的不同选择,你才能理解 Claude Code 这些设计不是随便做的,是在「编排派」信仰下的必然推演。

一句话:没有参照系,就没有理解;没有理解,就只会照搬不会变通。

23.4 Claude Code = 编排派

核心定位:一个 main loop + 五个子系统,把 LLM 从「无状态文本生成器」改造成「有持久状态、有工具、有权限边界、能多智能体协作的工程主体」。智能不在单个模型里,在 harness 的编排层。

23.4.1 ToolSearch 工具分页 = Context 的「虚拟内存」

这是 Claude Code 最精妙的创新。系统可能对接上百个工具(11 个常驻 + 30+ 个 deferred + 任意 MCP),但全量 schema 一次性塞进 system prompt 会吃掉几万 token。Claude Code 的做法:

• 常驻工具(11 个,如 Read/Write/Edit/Bash/Agent/Workflow/Skill 等)schema 全在 prompt 里,随时可调
• Deferred 工具(30+ 个,如 WebSearch、CronCreate、各 MCP 浏览器工具)只暴露工具名,schema 不加载,调用前必须先用 ToolSearch with select:<name> 把 schema「换页」进来

第一性原理:这就是操作系统的虚拟内存 / 按需分页机制。常驻工具是「内存」,deferred 工具是「磁盘」,ToolSearch 是「缺页中断」。

可迁移判据:工具超过 ~15 个就该上这套机制,否则 context 会被工具 schema 撑爆,留给实际任务的空间急剧缩小。本书第 15 章 MCP 服务器、第 19 章 Subagents 的工具设计,都是在这个框架下运作的。

23.4.2 Workflow JS 确定性编排 = MapReduce 搬进 LLM

Claude Code 的 Multi-agent 分三档,按确定性递增:

单任务委派        确定性编排           长期协作
Agent  ──────►  Workflow  ──────────►  Team + SendMessage
(一个子agent)    (JS脚本调度N个)       (命名、可寻址、持久)

Workflow 是重火力,它不是 prompt,是一段 JS 脚本(Dynamic Workflows, research preview),用 agent() / parallel() / pipeline() 确定性调度子 agent。

关键设计是 pipeline vs parallel 的取舍,本质是 MapReduce / 数据流调度哲学:

• barrier(parallel):仅当 stage N 需要 stage N-1 的全部结果做跨 item 聚合(去重、early-exit、对比)时才用
• pipeline:否则一律用,避免「木桶效应」——下游不等上游全部完成就能开工

这套机制让 Claude Code 能跑确定性大批量任务(本书第 20 章学术论文工作流、第 21 章白皮书工作流都是 Workflow 脚本驱动),可复现性远高于「让模型自己决定怎么分工」。

质量模式(做产品质量的武器库):Adversarial verify(N 个反对者投票)、Judge panel(N 方案 + 评分)、Loop-until-dry(连续 K 轮无新发现才停)、Completeness critic(最后专问「漏了什么」)。这些都在 Workflow 层实现,不依赖模型自觉。

23.4.3 system-reminder 动态控制信道

Claude Code 明确告诉模型:<system-reminder> 标签是 harness 注入的,不是用户。这是为了对抗 prompt injection——恶意用户没法伪装成 system-reminder 来下指令,因为模型被训练成区分「系统信道」和「用户信道」。

可迁移:你的 agent 框架必须有「系统信道」和「用户信道」的物理隔离。用户输入永远是用户输入,系统指令永远来自 harness,二者不能混在一个信道里。

23.4.4 ScheduleWakeup 的 cache TTL 经济学

这是 Claude Code 自治系统里藏得最深的一个设计。ScheduleWakeup 用于 /loop 等自治场景的单次延迟唤醒,它的文档里有一句反直觉的告诫(研究参考,非原文搬运):

不要选 300 秒。这是 worst-of-both:你付了 cache miss 的成本,却没有摊销它。

背景:Anthropic prompt cache 的 TTL 是 5 分钟(300 秒)。所以延迟轮询的甜点位是:

• <270 秒:缓存还热,命中,成本低
• >1200 秒:认了 cache miss,换长睡的收益
• 300 秒附近:最差,缓存刚过期又得重算,既没省 token 也没省时间

可迁移:agent 跑长任务的延迟轮询间隔,必须和 LLM 的 prompt cache TTL 对齐。这不是细节,是经济学。本书第 22 章 Agent Teams 的长跑任务、第 18 章调试 Monitor,都受这条约束影响。

23.4.5 编排派的设计动因总结

Claude Code 的智能在「怎么让多个 agent 协作」,所以它的力气花在:工具怎么分页(ToolSearch)、子 agent 怎么调度(Workflow 脚本)、控制信道怎么隔离(system-reminder)、长跑任务怎么对齐 cache 经济学(ScheduleWakeup)。每一个都是编排层的设计,不是模型层的能力。

23.5 Codex = 推理派

核心定位:榨干单个模型的推理深度。智能在模型本身,编排只是辅助。招牌是让推理深度变成用户/编排可调的一等参数。

23.5.1 reasoning_effort 7 档旋钮

Codex 在 spawn_agent / create_thread / automation_update 三处都暴露 reasoningEffort 参数,共 7 档:none | minimal | low | medium | high | xhigh | max。

这意味着推理深度是可调的一等参数,不是黑箱。产品可以让用户选「快速问答(low)」还是「深度研究(max)」,编排器可以根据任务类型自动降档省成本、升档保质量。

对比:Claude Code 的 extended-thinking 是宿主层控制,模型在 prompt 里看不到档位;推理是黑箱,编排才是可见层。Cursor 模型可替换,推理深度跟着模型走,不单独暴露。

23.5.2 238 工具全量装载

Codex 把 238 个工具 schema 全量铺进 system prompt(约 95% 的 token 是 schema)。19 个常驻 + 219 个全量列出。听起来很「暴力」,但这恰恰是 OpenAI 的押注:

• Anthropic 赌:工具/MCP 会爆炸增长 → 必须上 ToolSearch 分页,否则 context 必然撑爆
• OpenAI 赌:context window 会持续扩大到「全量装载无所谓」→ 全量比按需加载更可靠,没有「忘了 ToolSearch 这一步」的失败模式

反直觉的洞察:Codex 全量装载不是落后,是另一种信仰下的合理选择。全量装载的好处是模型永远看得到所有工具,不会因为「没调用 ToolSearch」而漏掉某个能力。代价是 context 压力大,留给实际任务的空间小。

23.5.3 commentary / final 双信道 + ::directive

Codex 的输出分两个信道:

• commentary 信道:模型的「思考过程」,可见但不直接产生副作用
• final 信道:最终输出,产生实际动作

还有一个 ::directive 机制,是机器可解析的副作用指令——模型在 commentary 里发 ::directive,harness 解析后执行特定操作。这让模型能在思考过程中触发结构化动作,而不只是输出文本。

这套设计让推理过程可观察、可干预,符合「推理是核心旋钮」的哲学。

23.5.4 容器化沙箱(公平性说明)

必须澄清一个常见误读:Codex 的泄露 prompt 里安全部分看起来「薄」,但这不是 Codex 安全弱。Codex 的招牌特性之一是容器化沙箱执行,只是这个沙箱实现在 harness 层而非 prompt 层,所以从 system prompt 里看不到。prompt 里只有 sandbox_permissions 字段这个接口。

实际上泄露的这份 dump 是 danger-full-access + approval_policy: never(三闸全开),这是 dump 来源用户的个人配置,不是 Codex 的默认或能力上限。

正确理解:Codex 在 prompt 层薄,在执行隔离层厚,是不同的安全分层选择。Claude Code 把更多安全约束写进 prompt(诚实报告、不可逆确认、防注入段),Codex 把安全放在容器隔离。两种分层,不是高低之分。

23.6 Cursor = 集成派

核心定位:模型是商品,集成体验是护城河。智能不在模型里也不在编排里,在「模型怎么嵌进 IDE 并随时换引擎」。

23.6.1 IDE 状态注入 = 环境耦合

Cursor 的 Context 策略和前两家都不同:它把 IDE 当前状态(打开的文件、光标位置、linter 报错、编辑历史)直接注入 prompt。模型不需要主动去读项目,IDE 已经把「现在在干什么」喂给它了。

这是「内存映射 IO」式的 Context——环境即上下文,模型和 IDE 状态强耦合。好处是模型永远知道当前编辑点,坏点是离开 IDE 这个壳就没用了(Cursor 无法像 Claude Code 那样在纯 CLI / CI 里跑)。

23.6.2 模型无关 + MCP 文件系统自读

Cursor 是三家唯一模型无关的:prompt 里用 {model_name} 占位,后端可以是 Claude、GPT、Gemini 等任意模型。这是「模型是商品」信仰的直接体现。

工具发现机制也很独特:MCP 工具 schema 不在 prompt 里,也不靠专门工具加载,而是让模型自己去 mcps_folder 读 JSON descriptor 文件。把「工具发现」降级成「文件读取」——极简,且天然支持用户任意扩展。

对比三家 Context 策略:

Claude Code:  运行时拼装   ──┐   ToolSearch 分页  =「虚拟内存」
Codex:        全量装载 238 个  ──┤   暴力塞满       =「一次性载入内存」
Cursor:       IDE 状态即 context ─┘   环境耦合       =「内存映射 IO」

23.6.3 best-of-n worktree 择优

Cursor 的 Multi-agent 是最轻最灵活的。核心机制是 best-of-n-runner:在隔离的 git worktree 里跑 N 个方案,然后择优保留一个。这是「要质量、不怕贵」场景的武器——同一个任务让模型跑 N 次,选最好的结果。

对比三家 Multi-agent 哲学:

	机制	智能体现在
Claude Code	Workflow = JS 脚本,确定性 pipeline/parallel,Team 持续协作	确定性编排(脚本保证可复现)
Codex	spawn_agent + explorer/worker 角色硬编码 + 写集不相交才并行	角色分工 + 写冲突规避
Cursor	Task + best-of-n-runner(worktree 跑 N 个择优)+ codex-rescue	择优 + 跨模型救场

23.6.4 codex-rescue = 跨模型救场(全场最妙的设计)

当 Claude(Cursor 默认后端)卡住、想要第二实现或诊断时,Cursor 会 spawn 一个 Codex 子 agent 来救场。这等于承认「没有单一模型永远最强,卡住就换引擎」——这是「模型无关」哲学的极致。

Claude Code 和 Codex 都绑死自家模型,只有 Cursor 设计了跨厂商协作通道。这个设计对自建 Agent 产品的启示巨大:你的主引擎不需要万能,只要有一个 fallback 机制能在卡住时换引擎(详见 23.7 节决策三)。

23.6.5 集成派的代价

Cursor 的代价是无显式自治机制:没有 Monitor、没有 Cron、没有 ScheduleWakeup。它假设人始终在 IDE 前面,模型是被调用的,不是自己跑的。这意味着 Cursor 不适合本书第 22 章讲的那种长跑自治任务(Agent Teams 跑几个小时)——它生来是为交互式编码设计的。

23.7 六维度对比总表

把前面散落的维度合并成一张表,这是本章的核心参考:

维度	Claude Code Opus 4.8	Codex GPT-5.5	Cursor
哲学	编排派	推理派	集成派
定位	CLI + 多平台 agent	desktop app(agent + IDE 壳)	IDE 内嵌,模型无关
Context 策略	system-reminder 动态注入 + deferred tools + ToolSearch 按需加载 + 自动摘要	静态 XML 段 + tool_search + 自动 compaction;238 工具全量铺进	IDE 状态注入 + MCP 让模型自读文件系统 schema
Tools	11 常驻 + 30 deferred	19 常驻 + 238 全量	~20 常驻全列出
Permission	5 档光谱 + sandbox + 危险命名 + 不可逆强制确认 + 诚实报告 + 防注入段	2 档(粗);容器沙箱在 harness 层	4 Mode(Agent/Plan/Debug/Ask)+ git 破坏性命令保护
Multi-agent	Agent + Workflow(JS 脚本 pipeline/parallel) + Team —最重	spawn/wait + explorer/worker 硬编码 + 写集切分 —中	Task + best-of-n worktree 择优 + codex-rescue —最轻
Autonomy	Monitor + Cron + ScheduleWakeup(cache TTL 经济学)	cron + heartbeat 二分 + token_budget 状态机 + 7 档 reasoning_effort	无显式自治机制
Memory	文件 + MEMORY.md 索引(可控可手改)	4 层(memory_summary/MEMORY.md/skills/rollout_summaries)+ 强制引用块	无显式持久记忆(仅 Agent Transcripts JSONL)
对 AGI 信仰	模型 + scaffolding 同等重要	单模型 scaling,推理是核心旋钮	模型是商品,集成是护城河

23.8 三大架构决策(做 Agent 产品的选型框架)

如果你要自建一个 Agent 产品,三个决策按顺序回答:

决策一:Context 策略(取决于工具是否会爆炸)

这是第一个架构决策,因为它决定 prompt 的基本形态。

你的产品工具数量会持续增长吗?重度依赖 MCP 吗?
│
├─ 是(工具 >20 且会增长 / 重度 MCP)
│   → 学 Claude Code:ToolSearch 分页
│   理由:context 会被 schema 撑爆,必须按需加载
│
├─ 否(工具 <20 且基本固定)
│   → 学 Codex:全量装载
│   理由:简单可靠,没有「忘了加载」的失败模式
│
└─ 想要用户自由扩展(插件市场)
    → 学 Cursor:工具 schema 落文件系统,模型自读
    理由:扩展无需改 prompt,天然支持第三方

判断点:工具数量是否会爆炸。会爆炸走分页,不会走全量,要开放扩展走文件系统。本书第 15 章 MCP、第 19 章 Subagents 的工具设计,都是按「会爆炸」假设走的 ToolSearch 路线。

决策二:Multi-agent 档位(按任务确定性选)

你的任务确定性如何?
│
├─ 确定性大批量(论文/白皮书/批量重构)
│   → 学 Claude Code:Workflow JS 脚本(pipeline/parallel)
│   理由:脚本保证可复现,MapReduce 调度哲学
│
├─ 探索 + 写分工(代码考古 + 实现)
│   → 学 Codex:explorer/worker + 写集切分
│   理由:角色分工 + 写冲突规避,适合探索式开发
│
└─ 要质量、不怕贵(关键功能实现)
    → 学 Cursor:best-of-n worktree 择优
    理由:N 个方案选最好的,成本高但质量上限高

判断点:任务是否确定性。确定性高走脚本编排,探索式走角色分工,要质量上限走择优。本书第 20、21 章的工作流都是确定性路线,第 22 章 Agent Teams 是探索 + 长期协作路线。

决策三:是否模型无关(决定要不要做跨模型救场)

你的产品是否需要护城河抗单一模型风险?
│
├─ 是(长期产品 / 用户会卡住)
│   → 学 Cursor:设计 codex-rescue 式 fallback
│   理由:主引擎卡住/低置信时,自动 spawn 另一家模型做第二意见
│   这是「模型无关」护城河的最低成本实现
│
└─ 否(短期 demo / 绑定某家 API 即可)
    → 学 Claude Code / Codex:绑死一家,深度优化
    理由:省事,能吃到该家的全部能力(如 Claude 的 Workflow、Codex 的 reasoning 旋钮)

判断点:产品是否长期、是否怕某家模型短板暴露。长期产品建议做 fallback,短期 demo 绑死一家更高效。

三条决策的安全底线

无论选哪条路,安全必须 prompt 约束 + 执行隔离双层:

• prompt 层(学 Claude Code):诚实报告、不可逆操作强制确认、防注入段、危险命名(如 dangerously 前缀让模型在调用前就被命名提醒)
• 执行层(学 Codex):容器化沙箱、权限光谱、文件系统隔离

只做一层不够。prompt 约束会被 prompt injection 绕过,执行隔离没有 prompt 约束则模型会反复试错撞墙。本书第 5 章权限模型、第 14 章 Hooks 是执行层;CLAUDE.md 的红线边界是 prompt 层。两层都要。

23.9 对本书读者的启示:为什么 Claude Code 适合编排密集型工作流

讲完三家,回答一个直接的问题:为什么本书以 Claude Code 为载体,而不是 Codex 或 Cursor?

因为本书的目标读者场景是编排密集型工作流:学术论文写作(第 20 章,117 个 Agent 并行)、技术白皮书(第 21 章,案例驱动多阶段)、Agent Teams 长跑任务(第 22 章)、一人公司产品化(第五部分)。这些场景的共同特点是:

1. 任务可拆成确定性步骤 → 需要 Workflow 脚本,不是让模型自己猜分工
2. 工具数量会增长(MCP、Skills、Subagents)→ 需要 ToolSearch 分页
3. 要跑很久(几小时到几天)→ 需要 ScheduleWakeup 对齐 cache TTL
4. 要可复现 → 脚本编排比模型自觉更可靠

这三条全是 Claude Code 编排派的强项。Codex 的 reasoning 旋钮在交互式深度问答场景更强,Cursor 的 IDE 集成在编辑器内编码更强,但本书的场景是「把 Claude Code 当成一人公司的自动化引擎」,编排派是唯一合适的选择。

这也解释了为什么本书第四部分(第 19-22 章)的设计动因是编排密集——不是作者偏好,是场景决定的。如果你场景是交互式编码,Cursor 可能更顺手;如果是深度推理问答,Codex 的 reasoning 旋钮可能更合适。没有最好的工具,只有最合适的信仰。

23.10 失败边界:这三家架构不能照搬什么

最后讲清三个失败边界,避免你把本章结论用错:

失败一:生搬硬套某家架构。三家架构是各自场景下的局部最优,不是普适最优。最典型的错误是看到 Codex 全量装载 238 工具就觉得自己也该全量装载——你的 context window 可能撑不住,你的工具集可能还在增长。选型要走 23.8 节的决策树,不是抄某一家。

失败二:忽略自身场景。Cursor 的 best-of-n 择优很诱人,但你的任务如果是确定性大批量(如批量生成 100 个席卡),用 best-of-n 跑 100 次择优是浪费——这种场景 Workflow pipeline 一次过更高效。先搞清自己的任务确定性,再选 Multi-agent 档位。

失败三:忽略 prompt 时效性。本章结论基于 2026-07-07 的 prompt 快照。三家随时迭代:Claude Code 的 Dynamic Workflows 还在 research preview,Codex 的 reasoning 旋钮档位可能调整,Cursor 的 codex-rescue 机制可能变化。做产品选型前,务必核对最新版 prompt 和官方文档,不要拿过时快照当圣经。

失败四:把 prompt 约束当全部安全。看了 Claude Code 把诚实报告写进 prompt,不等于你的 agent 就诚实了——prompt injection 可以绕过。必须配执行隔离。反过来,看了 Codex 容器沙箱就忽略 prompt 约束,模型会反复撞沙箱墙。两层都要,缺一不可。

23.11 本章核心心法

选型前先选信仰:编排派、推理派、集成派,三条路对应三种 AGI 押注。你的场景决定信仰,信仰决定架构,架构决定工具。

三家不是对错之分,是方向之分。Claude Code 适合编排密集(本书场景),Codex 适合推理密集,Cursor 适合集成密集。理解了这一句,你就知道什么时候该用 Claude Code,什么时候该换一把锤子。

---

本章是第四部分(Agent 工程)的横向选型章。承接第 19 章 Subagents、第 20 章 Workflows、第 22 章 Agent Teams 的具体机制,为第五部分(实战)的产品化路径提供选型框架。下一章将把这套框架落地到具体的一人公司产品化场景。

---

下一章:Agent 产品可复用骨架 | 返回目录