如何用 Codex 强兼 Claude Code 生态（并被它教做人）
输入“/”快速插入内容
如何用 Codex 强兼 Claude Code 生态（并被它教做人）
如何用 Codex 强兼 Claude Code 生态（并被它教做人）
用户4242用户42425月27日修改
原创 EstreWolf EstreWolf EstreWolf2026年5月26日 20:42 上海
写在前面：
- 我的 Claude Code 已经攒了一整套生态：memory、skills、vault、hooks，全是过去几个月一点点搭起来的。
- 但Codex在模型和产品的更新下，体感和Claude Code五五开，甚至在某些领域更强，但它对我之前搭好的生态一无所知。这篇文章记录我怎么把 Codex 接入这套生态，以及把设计文档丢给它做 review 时，它怎么三次抓出我自己看不见的设计漏洞。
- 你甚至可以把这篇文章丢给Codex，让它自动强兼Claudecode
1. 背景：为什么需要两个 Agent
我日常用 Claude Code 做产品思考、知识管理这类需要深度判断的工作。 但伴随着opus降智，codex迭代，我感觉，有些时候Opus4.7真不如Gpt 5.5好用吧，并且我开始产生大量的coding工作了 ；
问题来了：两个 Agent 各有一套私有配置（ .claude/ 和 .codex/ ），但它们服务的是同一个人、同一套知识库、同一批任务。 如果不做协调，Claude 刚做的决策 Codex 不知道，Codex 改完的代码 Claude 下次开会问"上次改到哪了？" 。两边各自维护一份"用户画像"，两周后就分叉了。更麻烦的是两个 Agent 可能同时改同一个配置文件，谁覆盖谁没有规则。
云端的多 Agent 编排（LangGraph、CrewAI）解决的是不同问题，它们协调的是同一个运行时里的多个角色。我的场景是两个独立运行时，各有自己的启动链路、记忆系统和工具集，但需要共享部分状态。更接近微服务间的 API 契约，而不是同一进程内的线程协调。
这套协作层跑起来之后，最直接的变化是不用每次手动跟 Codex 同步「我们做到哪了」，它启动时自动拿到 Claude 最新的任务列表和当日进展。但真正让我觉得值得搭的是另一件事：第二个 Agent 变成了独立审查者，视角和我手上的 Claude 不一样，抓到了几个我自己 review 时没看出来的设计缺陷。这部分后面会展开。
长期知识归 Claude、执行验证归 Codex 这个分层，反而是搭完回过头才看清楚的结果，不是一开始的设计目标。
2. 架构核心：三层分离
代码块
┌─────────────────┐ ┌─────────────────┐
│ .claude/ │ │ .codex/ │
│ (Claude 私有) │ │ (Codex 私有) │
│ rules/skills/ │ │ config/auth/ │
│ memory/hooks │ │ sessions/logs │
└────────┬────────┘ └────────┬────────┘
│ 不跨写对方私有层 │
│ │
┌────┴──────────────────────┴────┐
│ ~/.agents/ (共享契约层) │
│ contracts/ 共治协议 │
│ manifests/ 边界定义 │
│ shared/ 中立数据接口 │
│ handoff/ 异步交接 │
└───────────────┬────────────────┘
│
┌──────────┴──────────┐
│ vault (知识SSOT) │
│ 长期知识的唯一来源 │
└─────────────────────┘
一条铁律：不跨写对方私有层。Claude 不碰 .codex/ ，Codex 不碰 .claude/ 。所有协作通过中间的 ~/.agents/ 共享层完成。
这条规则看似简单，但在设计过程中被违反了两次（后面会讲），每次都是 Codex 在 review 时抓出来的。
Phase 0-2：从目录到验证
Phase 0：建共享层
创建 ~/.agents/ 目录结构，包括契约文件、边界定义、symlink（临时方案）、交接区。