Codex CLI 和 OpenClaw,两种context管理思路区别在哪?

前两篇分别拆过 Codex 和 OpenClaw。合上笔记，很多人会卡在同一句：

我不会给「抄谁」的答案。仓库里改代码的代理，和要可换策略、挂了还得能回用户的系统，约束本来就不一样——抄错对象，比不抄更贵。

别拿功能清单对轰。真正值得比的，就这么几件事：

1. 规则怎么进系统

2. 谁决定这轮塞进上下文窗口

3. 窗口满了谁负责压

4. 子代理边界写在哪

检索找得到和放不放进窗口，最好也分得开；模型谁强、插件谁多、某一版精确 token 数，这篇都不比。

Codex 这边，稳定规则主要靠 AGENTS.md 链：全局 → 仓库根 → 当前目录层层收，越靠近 cwd（当前工作目录）的越靠后。Skills（技能包）是另一路：progressive disclosure（渐进式披露），索引常驻，正文按需加载。规则当项目资产管，能进 Git、能评审。

OpenClaw 更醒目的是另一刀：ingest（先接住消息）接收入口，assemble（组装这轮上下文）才决定塞不塞进窗口。Memory（记忆）只负责找材料，另走一路；放不放行，仍归 Context Engine（上下文引擎）。

自研时这两刀常常都要。没有可版本化规则，聊天里改的规则下次就没了；没有放行边界，检索一多，上下文窗口很快被灌满，看不清重点。差的是你先补哪一刀。

差别最大的，是谁组装这轮上下文。

Codex 用会话 / 任务线程当边界：上下文围着「这一次登录」长出来，靠分层、截断、长输出子任务外置挡噪声。你感受到的是工作流——需求在主线程，扫安全、跑测试这类长输出去子线程。

OpenClaw 把「谁决定这轮看见什么」抽成 Context Engine，挂在 plugins.slots.contextEngine：插件配置里同一时刻只启用一套；没配会用内置 legacy；换上的引擎挂了，还能降回保守默认。

一个用任务边界逼你分层，一个用独占组装入口把放行权写成接口。目标相近，落点不同。

context窗口总有顶上的时候。先别问摘要算法好不好，先问：腾地方这件事，算谁的责任？

Codex 的答法偏流程：触到自动压缩线，单独开一轮压缩——先把前面聊过的内容收成一段「后面还能接着干」的交接摘要（Codex 文档里把这份摘要叫 handoff），再和近期用户原话拼在一起，换掉大半历史；必要时再重挂 AGENTS 一类初始上下文。手动 /compact 和自动压缩做的是同一类事，主要差在谁触发。

OpenClaw 的答法偏归属：compact 挂在引擎生命周期上，再用 ownsCompaction（是否由引擎自己负责压缩）说清楚——压缩归引擎，还是交给 runtime（运行时）。责任方一含糊，手动压缩和溢出恢复最容易一起坏。

摘要保留什么、丢掉什么，可以另写。选型时先把责任方说清楚就够。

Codex 用 agent thread（代理线程）干扫描安全、跑测试这类脏活；主线程握需求与验收，回流只要结构化结论，不把对方读过的全文灌回来。

OpenClaw 给了可选钩子：prepareSubagentSpawn（子代理启动前准备）、onSubagentEnded（结束时清理）；模式可以是 isolated（隔离）或 fork（分叉）；还可以走 lightContext（轻量上下文）瘦启动。边界写进生命周期，比写在注释里可靠。

回传怎么合回主任务，下一篇再拆。

子代理首先服务隔离，边界要有落点。

Codex 把「好上下文」嵌进编码工作流；OpenClaw 把「谁决定看见什么」抽成可挂载能力。

不必去复刻 Codex 的 /compact 一类命令，也不必先照搬 OpenClaw 那套插件配置写法。要迁的是职责怎么切开：规则放哪、谁组装进上下文、压缩归谁、子任务怎么隔离——叫什么名字不重要。

可以借鉴的思路，我会先看这几条：

1. 规则可版本化——学 Codex 的配置分层，别把规则只写在聊天里

2. 规则进系统和塞进窗口分开，组装入口唯一——学 OpenClaw 把放行权收拢

3. 压缩、子任务隔离都有明确落点——两边都要，别散落在业务 if 里

4. 检索供给和放行分家——找得到，不等于自动塞进窗口

可以落到自己 Agent 系统工程里的，更直接的是先问这几个问题，再谈抄谁：

1. 规则要不要进仓库评审？要 → 先做配置分层

2. 策略会不会换、挂了能不能回到保守默认？会 → 组装入口要显式，甚至预留可插拔

3. 现在说不说得清「这轮模型看见了什么」？说不清 → 先做回放，再谈引擎

4. 子任务有没有输入输出契约？没有 → 先别上多智能体热闹

短会话 Demo、策略短期内不会换：分层加上单一组装入口，往往就够。真要「不改核心就换策略」，或策略一挂必须降级，再抽可替换引擎也不迟。

对方问的通常是你会不会做权衡、能不能讲清取舍。常见就这几问：

面试官：Codex 和 OpenClaw 的上下文管理，本质差别是什么？

答：都是在管「这轮模型看见什么」。Codex 更像把规则、任务线程、子任务隔离嵌进编码工作流——规则进 AGENTS.md，扫安全、跑测试这类长输出丢子线程，主线程留结论。OpenClaw 更像把放行权抽成可挂载的 Context Engine：组装独占，还能失败降回保守默认。差在落点：一个偏工作流，一个偏组装放行与降级。

面试官：那到底谁更好？

答：没有绝对更好，看约束。规则要进 Git、场景主要是仓库里改代码，分层思路很贴。策略会换、要可观测、挂了还得能回用户，显式组装入口和降级更贴。面试里可以说清「我选哪套约束」，比硬说「某某更先进」值钱。

面试官：自研最小要有什么？

答：四样就够起步：可版本化的规则、单一组装入口、能回放「这轮看见了什么」、子任务有输入输出契约。这几样不稳，上自动压缩和可插拔引擎，多半是在给糊涂账打补丁。稳了再谈压缩策略和可替换。

面试官：Memory 和组装入口为什么要分开讲？

答：找得到是供给，放不放进窗口、放多少是放行。混在一起，出了问题分不清是检索差还是组装胡来

面试官：什么时候才值得做成可替换引擎？

答：已经出现这几类信号再抽：要不改核心就得换策略；策略失败必须能降级；或者已经说不清这轮模型看见了什么。更早抽，接口和兼容成本往往先砸在你头上，属于过度设计。

先问规则要不要进 Git、说不说得清这轮看见了什么，再谈抄谁。

仓库里改代码，优先把规则分层和任务边界做稳；策略要换、挂了还得回用户，优先把组装入口收拢。对不上自己的约束，功能清单再长也白搭。

你现在的 Agent，更缺「规则分层」，还是更缺「组装放行」？欢迎留言。

机制细节见系列第2、3篇：

《Codex CLI 是怎么管理上下文的？从开发一个登录功能说起》

《OpenClaw 是怎么管理上下文的？从下一轮提问发出去之前开始拆》

参考：

1. Codex 总览

https://developers.openai.com/codex/

2. AGENTS.md

https://developers.openai.com/codex/guides/agents-md

3. Subagents

https://developers.openai.com/codex/subagents

4. OpenClaw Context engine

https://docs2.openclaw.ai/concepts/context-engine

5. OpenClaw 概念页（仓库）

https://github.com/openclaw/openclaw/blob/main/docs/concepts/context-engine.md