你跟 AI 结对编程的时候，有没有遇到过这种情况：前 20 分钟它写得很顺，代码质量也不错；但到了第 40 分钟，它开始「忘了」最初的约束，反复修改已经正确的部分，甚至引入跟之前矛盾的逻辑。

这不是幻觉，而是上下文漂移（Context Drift）。当一个 Agent 在同一个会话里连续工作超过一定时间，它的注意力窗口会被历史消息填满，早期的指令和约束被「挤出」有效上下文窗口。你给它的 Plan 还在，但它无法可靠地执行 Plan 的全部内容。

这个问题怎么解决？答案可能不是给 Agent 更大的上下文窗口，而是彻底改变 AI 编码的工作模式。

三角色模式：把一个人干的活拆给三个人#

Neal 是一个开源的多角色编码循环工具，它做了一件看似简单却效果显著的事：把编码任务拆给三个独立的 AI 角色。

三个角色分别是：

  • Planner（规划器）：拿到你写的 Plan 文档后，规划器将其细化成结构化的执行计划，定义执行形状、拆分 Scope、补充实现细节。
  • Coder（编码器）：按 Scope 逐个执行，写代码、跑测试、验证结果。每个 Scope 开始时会获得一个全新的上下文。
  • Reviewer（审查器）：只读审查每个 Scope 的产出。不满意就打回重做，满意才放行进入下一个 Scope。

这个设计一点都不花哨。它本质上是在模仿一个成熟工程团队的协作模式：有人写 PRD（Planner），有人写代码（Coder），有人做 Code Review（Reviewer）。只不过三个角色由不同的 AI 模型承担。

为什么评审者必须来自不同厂商？#

Neal 的设计哲学中最关键的一条，是 Coder 和 Reviewer 必须使用不同厂商的模型。

这不仅仅是「多一层审查更安全」的直觉，而是基于一个认知科学层面的洞察：同一个模型审查自己的代码，等于让同一个大脑给自己的作业打分。它会重复自己的盲区、确认自己的偏见、忽视自己的疏漏。

典型的配置是：Codex 负责写，Claude 负责审。两个模型有不同的训练数据、不同的推理风格、不同的强项和弱项。Claude 可能捕捉到 Codex 忽略的边界条件，Codex 可能发现 Claude 不会考虑的工程实践。这是一种真正意义上的「对抗性审查」，而不是同质化的自检。

更有意思的是，Reviewer 是只读的。它在 API 层面被限制不能修改任何文件，这让审查变成纯粹的判断行为，避免了「审查者忍不住自己动手改代码」的常见陷阱。

每个 Scope 重置上下文：对抗漂移的根本手段#

上下文漂移的根源，是 Agent 在长对话中积累越来越多的「包袱」。Neal 的处理方式很直接：每个 Scope 结束后，Coder 的上下文被清空，下一个 Scope 从零开始。

这意味着：

  • Scope 1 的修改不会「污染」Scope 2 的推理
  • 每个 Scope 获得 Coder 的全部注意力
  • Reviewer 的上下文跨 Scope 保持连续，确保整体一致性

这跟人类团队的做法一致：开发者完成一个功能模块后，歇一下，喝杯咖啡，再开始下一个模块。你不会让一个人连续工作 8 小时不做任何休息，为什么要让 AI 这么做？

死锁自愈：当代码改不好时怎么办？#

多角色协作自然会带来一个新问题：如果 Coder 和 Reviewer 陷入死锁怎么办？Coder 的修改总被 Reviewer 打回，改来改去都无法通过。

Neal 的处理方式很务实。它定义了几种死锁类型，并针对每种类型提供了自动恢复策略。比如重复驳回同一类问题时，Neal 会尝试给出更具体的修复指引，或者将当前 Scope 拆分成更小的子 Scope，降低一次性通过的门槛。

如果自动恢复也解决不了，Neal 会把这个 Scope 标记为 blocked，需要人工介入。但它不会因此中断整个 Run，已经完成的 Scope 的结果被安全保存。你可以在任何时候用 neal resume 恢复执行，从中断点继续。

这种「边界化的自主恢复 + 明确的人工介入点」设计，是目前 AI 编码工具里少见的工程化思路。它承认 AI 不是万能的，但尽量让 AI 能处理的部分最大化。

不只是写代码：Plan Review 和拆分子 Scope#

Neal 的另一个亮点是 Plan Review。它不仅仅执行你给它的 Plan，还会在 Planner 阶段对 Plan 本身进行审查和细化。如果你的 Plan 太模糊，Planner 会帮你补充实现细节；如果 Plan 有逻辑矛盾，Planner 会指出问题。

而当 Coder 在执行过程中发现某个 Scope 比预期的大得多时，它可以主动把 Scope 拆分成一个子计划（Sub-Plan），自己生成新的 Scope 列表，然后逐一执行。这解决了「硬着头皮在一个 Commit 里塞太多东西」的问题。

跟 Codex CLI 和 Claude Code 的关系#

Neal 不是要替代 Codex CLI 或 Claude Code，而是把它们当作「执行器」。

在配置层面，Neal 驱动 Codex CLI 来执行 Coder 角色（配置为 approvalPolicy: never 和 sandboxMode: danger-full-access，用于最大化自动化能力），驱动 Claude Code 来执行 Reviewer 角色（配置为 permissionMode: bypassPermissions）。

这意味着你不需要学习新的 Agent 工具链。你已有的 Codex 和 Claude 设置继续有效，Neal 只是在它们之上加了一层编排逻辑。所有交互历史、Scope 产物、审查记录都保存在 .neal/ 目录下，你可以随时回溯。

总结：这不是 Agent，这是流程#

Neal 提供的不是「更好的 Agent」，而是一套编码流程的工程化抽象。

它把 AI 编码从「请一个全能程序员帮你干活」变成了「组建一个微型 AI 工程团队」，有分工、有审查、有失败恢复、有上下文隔离。这种思路在软件工程领域已经验证了几十年，现在被投射到了 AI 辅助编码的场景中。

如果你正在用 Codex 做复杂度较高的项目（跨多个文件、涉及多个模块、需要严格一致性），单 Agent 模式很容易在第三、四个关联模块时开始「犯糊涂」。试试三角色模式，让 Codex 负责它擅长的代码生成，让 Claude 负责它擅长的逻辑审查，让 Planner 负责全局一致性。

工具是开源的，GitHub 仓库在 navels/neal，MIT 许可证。安装只需要一行 npm install -g @navels/neal。

参考来源：Neal — A plan-driven, multi-agent coding loop，作者 navels，MIT 许可证。本文基于项目 README 和设计文档进行原创性中文重写，补充了上下文漂移、死锁恢复、对抗性审查等方面的技术分析。