https://codexer.com/tags/neal/Recent content in Neal on CodexerHugozh-cnSat, 08 Aug 2026 09:00:00 +0800https://codexer.com/posts/2026-08-08-neal-multi-agent-coding-loop/Sat, 08 Aug 2026 09:00:00 +0800https://codexer.com/posts/2026-08-08-neal-multi-agent-coding-loop/<p>你跟 AI 结对编程的时候，有没有遇到过这种情况：前 20 分钟它写得很顺，代码质量也不错；但到了第 40 分钟，它开始「忘了」最初的约束，反复修改已经正确的部分，甚至引入跟之前矛盾的逻辑。</p> <p>这不是幻觉，而是上下文漂移（Context Drift）。当一个 Agent 在同一个会话里连续工作超过一定时间，它的注意力窗口会被历史消息填满，早期的指令和约束被「挤出」有效上下文窗口。你给它的 Plan 还在，但它无法可靠地执行 Plan 的全部内容。</p> <p>这个问题怎么解决？答案可能不是给 Agent 更大的上下文窗口，而是彻底改变 AI 编码的工作模式。</p> <h2 id="三角色模式把一个人干的活拆给三个人">三角色模式：把一个人干的活拆给三个人</h2> <p>Neal 是一个开源的多角色编码循环工具，它做了一件看似简单却效果显著的事：<strong>把编码任务拆给三个独立的 AI 角色</strong>。</p> <p>三个角色分别是：</p> <ul> <li><strong>Planner（规划器）</strong>：拿到你写的 Plan 文档后，规划器将其细化成结构化的执行计划，定义执行形状、拆分 Scope、补充实现细节。</li> <li><strong>Coder（编码器）</strong>：按 Scope 逐个执行，写代码、跑测试、验证结果。每个 Scope 开始时会获得一个全新的上下文。</li> <li><strong>Reviewer（审查器）</strong>：只读审查每个 Scope 的产出。不满意就打回重做，满意才放行进入下一个 Scope。</li> </ul> <p>这个设计一点都不花哨。它本质上是在模仿一个成熟工程团队的协作模式：有人写 PRD（Planner），有人写代码（Coder），有人做 Code Review（Reviewer）。只不过三个角色由不同的 AI 模型承担。</p> <h2 id="为什么评审者必须来自不同厂商">为什么评审者必须来自不同厂商？</h2> <p>Neal 的设计哲学中最关键的一条，是 <strong>Coder 和 Reviewer 必须使用不同厂商的模型</strong>。</p> <p>这不仅仅是「多一层审查更安全」的直觉，而是基于一个认知科学层面的洞察：同一个模型审查自己的代码，等于让同一个大脑给自己的作业打分。它会重复自己的盲区、确认自己的偏见、忽视自己的疏漏。</p> <p>典型的配置是：<strong>Codex 负责写，Claude 负责审</strong>。两个模型有不同的训练数据、不同的推理风格、不同的强项和弱项。Claude 可能捕捉到 Codex 忽略的边界条件，Codex 可能发现 Claude 不会考虑的工程实践。这是一种真正意义上的「对抗性审查」，而不是同质化的自检。</p> <p>更有意思的是，Reviewer 是<strong>只读的</strong>。它在 API 层面被限制不能修改任何文件，这让审查变成纯粹的判断行为，避免了「审查者忍不住自己动手改代码」的常见陷阱。</p> <h2 id="每个-scope-重置上下文对抗漂移的根本手段">每个 Scope 重置上下文：对抗漂移的根本手段</h2> <p>上下文漂移的根源，是 Agent 在长对话中积累越来越多的「包袱」。Neal 的处理方式很直接：<strong>每个 Scope 结束后，Coder 的上下文被清空，下一个 Scope 从零开始</strong>。</p>