Claude 做方案，Codex 写代码：多模型协作怎么交接才稳¶

Ch01.878 Claude 做方案，Codex 写代码：多模型协作怎么交接才稳¶

📊 Level ⭐⭐ | 7.3KB | entities/claude-做方案codex-写代码多模型协作怎么交接才稳.md

摘要¶

本文探讨多模型协作中模型之间如何交接上下文和状态的问题。以"Claude 调研设计、Codex 进仓库实现、Gemini 最后核查"这一典型链路为例，指出当前多模型协作面临的核心瓶颈不是模型能力不足，而是模型之间缺少结构化的交接机制——人被迫在多个 AI 之间充当"API"，反复搬运上下文。

文章对比了 Unibase Memory（跨模型对话保存与搜索的 Chrome 扩展）与结构化 HANDOFF 两种方案，论证了完整聊天历史不等同于当前工作状态。作者提出四层上下文架构（归档、知识、状态、交接），并给出了具体的 HANDOFF.md 交接模板和试用建议。

核心要点¶

多模型协作的真实瓶颈是交接损耗，而非模型能力差距
Unibase Memory 能跨 ChatGPT/Claude/Gemini 保存和检索对话，但带不走仓库、测试、权限等工程现场
完整聊天历史属于事件日志，工作现场需要结构化的 HANDOFF 快照
上下文工程应分四层：归档（只追加）、知识（核验后写入）、状态（单一权威版本）、交接（按需生成）
HANDOFF 应包含：任务目标、当前版本、已确认事实、测试结果、阻塞项、下一步动作和停止条件
接收模型应先回传三行确认（版本、范围、边界），再开始执行
权威版本只能有一个，项目状态不能在多个模型间同时演化
共享记忆面临并发写入时的覆盖、陈旧数据和版本冲突问题，需要乐观并发控制
Unibase Memory 的客户端加密基本可确认，但钱包地址上报与文档描述未完全对齐
推荐先跑一周对照试验（完整聊天 vs 结构化 HANDOFF），测量接手成本、版本一致性和总体返工率

深度分析¶

多模型协作的真实瓶颈：交接损耗而非模型能力¶

当前多模型协作面临的核心问题不是某个模型的能力不足，而是模型之间缺少结构化的交接机制。以"Claude 调研设计→Codex 进仓库实现→Gemini 最后核查"这一典型链路为例，人被迫在多个 AI 之间充当"API"，反复搬运上下文。每次换模型，项目状态、设计版本、已确认事实和测试结果都需要重新传递给下一个模型。这种交接损耗是比模型能力差距更紧迫的工程挑战——模型明明会做，拿到的却是错版本或半截结论，结果自然不稳。

四层上下文架构的理论框架¶

文章提出的四层上下文架构（归档→知识→状态→交接）是上下文工程的重要理论贡献。归档层保存原始对话和工具输出，仅供追溯；知识层存放已确认事实和来源，核验后写入；状态层维护当前版本、负责人和阻塞项，只保留一个权威版本；交接层按需生成下一棒需要的目标、证据和停止点。这四层的分离解决了"完整聊天历史不等同于当前工作状态"的核心矛盾——搜索过去的记录和告诉下一棒该从哪里继续是两个完全不同的问题。

HANDOFF.md 模板的工程价值¶

文中给出的 HANDOFF.md 模板（交接编号、任务与完成条件、仓库/分支/基准提交、权威设计及版本、当前状态、已修改文件、已确认事实、关键决策、测试结果、阻塞项、下一步动作、权限边界与停止条件）是一个极简但有效的交接协议。其核心设计原则是"归档可以很全，交给下一棒的工作集要窄"——Claude 交出设计时不必把两小时探索过程原样塞给 Codex，交接包里只需要当前方案、被否掉的方案及其依据就够了。

三行确认与权威版本原则¶

文章提出的"三行确认"机制（接收模型回传三行信息：设计版本/commit、本次范围、仍未确认的边界/停止条件）是一个低成本高回报的工程实践。它只需要在开始执行前多花几行字的确认，却能挡住"模型从错误的起点一路做下去"这类最昂贵的返工。与之配套的"权威版本只能有一个"原则，确保项目状态不会在多个模型间同时演化——三个模型可以各自保留思考过程，但当前状态只能在单一位置被修改。

共享记忆的并发控制挑战¶

Unibase Memory 等共享记忆方案面临的核心工程挑战是并发写入时的覆盖、陈旧数据和版本冲突问题。文章借鉴计算机体系结构中的共享记忆与分布式记忆理论，提出乐观并发控制方案：每条事实带来源、时间、版本和状态；只有当前负责人能改权威状态；更新携带 base_version，版本已变化就拒绝覆盖。这套机制虽然朴素，但已经能挡住大多数"旧结论覆盖新状态"的问题——在引入完整分布式事务之前，这是一个实用的折中方案。

实践启示¶

先检查交接字段，再看角色分工：评估多模型架构时，先看模型之间如何交接状态和证据，再看每个模型的具体角色。交接字段空着，角色名再漂亮也无法落地。
三行确认挡住最贵的返工：接收模型在开始执行前回传三行确认（版本、范围、边界），成本只有几行字，却能避免"从错误起点一路做下去"的完全返工。
归档与交接分开管理：完整聊天历史留作追溯，当前状态用结构化 HANDOFF 快照传递。两者混用会导致下一棒迷失在历史细节中。
权威版本只有一个：不要让多个模型同时修改同一份状态。项目状态只能在单一位置演化，其他模型提交建议而非直接修改。
先跑对照试验再全面推广：用复杂度相近的两个任务做对照（完整聊天 vs 结构化 HANDOFF），测量接手时间、追问次数、版本误用和返工率，用数据验证交接方案的有效性。