一个 Coding Agent 已经可以独立完成不少工作。很自然地，我们会想让多个 Agent 一起干活，比如三个 Agent，一个改后端，一个改前端，一个补测试。看起来速度会加倍，但实际上可能会出大问题，例如两个 Agent 同时编辑同一个文件，后写的覆盖了先写的；后端的 Agent 改了 API 格式，前端的 Agent 还在按旧 API 格式写调用；一个 Agent 跑测试的时候，另一个 Agent 重装了整个依赖环境。
目前常见的解法是硬隔离：每个 Agent 一个 Git Worktree 或者一个容器，各自干完再合并，但代价很明显，Agent 之间在过程中完全看不到彼此，重复劳动和方向背离要等到最后才暴露，而串行合并又抵消了并行带来的速度。
任务要求
本题希望你设计并实现一套 Agent 之间的信息同步与协调机制，让多个 Agent 能够在同一个代码库上协同完成一个复杂任务，并且效果和速度都优于纯粹的硬隔离方案。
技术选型不限。Agent 可以使用任何现有的 Coding Agent（Claude Code、Codex、Pi Agent、OpenCode 等），也可以自己基于模型 API 搭建。你不需要从零实现一个 Coding Agent，重点在它们之间的协调层。协调机制如何接入 Agent 也不限。可以通过 MCP 工具、Hook、文件系统约定、封装 Agent 的运行时，或者修改开源 Agent 的源码。
请准备一个真实的测试任务：一个规模适中的代码库，加上一个需要至少三个 Agent 分头协作才有意义的需求。任务本身不必复杂，但要真的会产生冲突。如果任务天然可以完全拆开互不干扰，那它无法验证你的方案。
单人完成本题时，完成 Lv1 和 Lv2 即可，Lv3 不作要求。
Lv1：状态共享与冲突识别
Lv1 解决最基础的问题：让每个 Agent 知道其他 Agent 在做什么。因此至少需要存在一个所有 Agent 都能读写的共享状态，记录每个 Agent 当前的任务、正在修改或计划修改的范围、已经完成的变更、用户决策的记录。Agent 在动手之前应强制查看这个状态，在做出重要变更之后应该更新它。
同时，你应该能够检测到冲突，例如两个 Agent 试图修改同一个文件或者同一个函数，或者一个 Agent 依赖的接口正在被另一个 Agent 修改。
Lv1 注意，不要求解决冲突，但要求冲突在发生时或者发生前被发现，而不是在合并时才暴露出来。
Lv2：协调与沟通
冲突被看见以后，需要有一套规则决定怎么协调。可能的方式很多：比如可实现按文件、目录或者符号粒度的编辑锁，先申请上锁再进行修改，并在读取时记录 inode 数据，判断 inode 出现变化则重新读取等；也可以按模块划分所有权，其他 Agent 只能向模块的所有者提交修改请求；还可以进行接口格式的设计，然后各自进行实现；或者允许并发修改，但在合并时做语义级别而非文本级别的合并。注意，你不需要实现所有方式，但需要选择并解释。粒度太粗会让并行退化成串行，粒度太细会让协调本身的开销超过收益。协议还需要考虑失败情形。一个 Agent 申请了租约然后卡死了怎么办？两个 Agent 互相等待对方释放资源怎么办？
冲突只是协作问题的一部分。还有可能并没有直接冲突，但需要进行沟通的情况，即一个 Agent 做出了某个决定，另一个 Agent 需要知道，例如：接口的返回格式变了，公共工具函数新增了一个参数，某个测试被标记为已知失败。这些信息如果不同步，其他 Agent 会在错误的前提下继续工作。你需要设计信息在 Agent 之间流动的方式。是广播、点对点通信、订阅，还是主动推送？亦或是在 Agent 下一次读取共享状态时才看到？哪些信息值得同步，哪些只是噪音？注意这里有一个现实的约束：每一条同步给 Agent 的信息都会占用它的上下文。同步得越多，Agent 越可能被无关信息淹没。
Lv2 要求给出量化的对比。请至少在同一个测试任务上比较三种方案：单个 Agent 串行完成；多个 Agent 在各自 Worktree 中完成后人工或自动合并；多个 Agent 使用你的协调机制完成。比较维度可以包括总耗时、Token 消耗、冲突数量、合并所需的人工介入、最终代码的测试通过率。注意，如果你的方案在某些维度上不如基线，请如实报告并分析原因。这比一个看起来完美的数据更有价值。
Lv3：更难的场景
Lv3 是可选方向，选择下面一个即可：
- 跨厂商的 Agent 通信：Claude Code 等产品已经有点对点的通信了，但如果现在是 Claude Coder、CodeX、omp 等不同 Agent 参与协作，甚至运行在不同的机器上，你的协调协议是否仍然可用？可以参考 A2A 等已有协议，也可以设计自己的。
- Human in the loop：当一个人类开发者也在同一个代码库上工作时，Agent 应该如何对待人的修改？人应该如何看到 Agent 之间的协调过程？如何在过程中更好的引导人类开发者完成内容并跟随人类开发者的决策进行开发？
- 动态任务分解：任务的拆分不是一开始就固定的。当一个 Agent 发现自己的任务需要拆分，或者需要另一个 Agent 的帮助时，系统能否支持？
加分项：多 Agent 系统可观测性设计
多个 Agent 同时工作时，出问题几乎是必然的。你的系统应该能够在事后回放整个协作过程：每个 Agent 在什么时候做了什么，看到了什么共享状态，为什么等待，等待了多久，哪些冲突被检测到，如何被解决。一条按时间排列的全局事件流是最基本的要求。如果能进一步可视化 Agent 之间的依赖与等待关系，会更有价值。
推荐使用技术栈：OpenTelemetry
思考题
- 协调层应该由一个中心化的服务承担，还是让 Agent 之间点对点沟通？
- Agent 应该主动遵守协议，还是协议应该由运行时强制执行？如果 Agent 忽略了协议怎么办？
- Worktree 这样的硬隔离真的一无是处吗？什么情况下它反而是正确的选择？
- Agent 之间的沟通应该使用自然语言，还是结构化的消息？
- 如果协调本身也由一个 Agent 来负责，它和被协调的 Agent 之间的关系应该是什么？
- 多 Agent 系统的可观测性，还能观测什么信息？应该怎么分层处理？
这些问题没有标准答案。我们更关心你如何定义问题、做出取舍，并解释自己的设计。