四Agent并行：状态文件是保持一致性的关键

一个 Agent 是协作者。四个 Agent 就是并发问题。我现在经常同时跑四个，而混乱与正常运转之间的差异，全靠状态文件：什么东西写到哪里，谁来读，什么时候读。以下是这个方案，包含我们自身 ops 的实际数字。

四个 Agent，两类通道：

research lanes (2): read-only investigation, no code changes
implementation lanes (2): code changes, one task each

分类比数量更重要。研究工作（定位 bug 所在、阅读库源码、梳理 API）消耗上下文极快，产出的是结论而不是 diff。和研究混在一起，意味着实现 Agent 继承了 15 万 token 的探索噪音。分通道解决：研究得出结论，人类或编排层读取结论，实现层拿到简洁的 brief。

每个通道一个状态文件

每个通道只写一个文件，以追加为主：

# state: lane-impl-1
task: add rate limiting to login route
branch: feat/rate-limit
done:
- middleware scaffold + tests
- 429 response shape per api-conventions.md
in-flight: redis-backed counter
blocked: none
next: wire counter into middleware, integration test

规则枯燥但严格：只在任务边界更新，不在编辑中途写入。文件就是交接面。如果某个通道挂了，接替者读取状态文件，几分钟就能继续，而不是花一个小时重新推导上下文。

为什么不用共享计划

试过。共享文档会产生写竞争：同一周内两个 Agent 同时编辑同一个计划文件导致内容损坏，两次。换成每个通道独立文件、单写入者，从未损坏过一次。跨越通道读取的唯一读者是编排层（我，或一个脚本）。

两个实现通道意味着最多同时运行两个任务。当第三个任务在中途诱惑我时，规则是：排队，不启动。原因在于合并面。在我们的 ops 中，两个并行实现分支几乎每次都能干净合并；三个开始产生冲突解决会话，成本超过并行节省的时间。你们的冲突阈值会因代码库规模不同而不同，但存在这么一个阈值，越过它代价高昂。

每个通道的上下文预算

我们运行的实际数字：

research lane:  100-150k tokens typical, conclusions in a report file
impl lane:       40-80k tokens typical, state file + tests as artifacts
reviewer pass:  10-20% of the task's tokens, fresh agent, diff only

reviewer 是被低估的一个：全新的 Agent 没有先前上下文，只对着完成的 diff 对照完成定义来审查。不会对自己的工作有 shared enthusiasm，不会有继承的假设。它比任何单 Agent 审查都更能捕获"测试通过但需求漂移"这类漏网之鱼。

压缩与交接

长通道会触及上下文上限，而压缩后能留下来的只有文件，不是记忆。所以重要的东西都要写出来：边界处的状态文件、决策及被拒绝的替代方案、以及任何通道派生时的 brief 文件。模式与单 Agent 规范相同，只是因为交接更频繁而执行更严格。

仍然会出什么问题

两个 Agent 在同一通道内编辑相邻文件导致冲突（用任务切片解决，不是工具）。研究结论在 impl 通道等待期间过时（报告文件标注日期，过时的报告重新生成，不信任）。还有经典戏码：我"就这一次"启动第三个通道，然后付合并税。系统在小帽不破时运转良好。

压缩后能留下来的是什么：为什么状态文件比内存强。

配置文件与钩子：这一切底下的执行层。

团队标准化 AI 编码 Agent：多人版同类问题。

为多 Agent 工作构建的配置套件（含状态文件模板）：AgentConfig Studio。免费 Next.js 示例（MIT）。