夜雨聆风过去一年，编码 Agent 的核心叙事是"一个工具内部的能力增强"——Claude Code 学会了自己派生子 Agent，Codex CLI 学会了终端内持续运行，Gemini CLI 学会了深度上下文理解。这些进步解决了单 Agent 内部的协作问题：Claude Code 可以在一次会话中生成 20 个子 Agent，各司其职，由一个中枢协调。这很好，但它解决的是工具内的规模问题，而不是跨工具的协调问题。
当团队开始同时使用 Claude Code、Codex CLI 和 Gemini CLI 处理同一个代码库时，一个新问题浮出水面：这些工具之间没有任何共享状态。Claude Code 重构了一个模块，Codex CLI 对着重构前的接口写测试，两边的改动都被保存，测试失败，但没有任何一个工具知道另一个的存在。
这个场景听起来很熟悉。在人类开发者组成的团队中，这是版本控制和 CI/CD 要解决的核心问题。但当参与方变成了多个独立的 AI 编码工具，传统的 Git 工作流并不能提供足够细粒度的协调原语。
多工具不等于多 Agent
首先要理解的是，多工具协调和多 Agent 编排是不同层次的问题。
Claude Code 内部的多 Agent 编排，是在一个封闭的运行时环境中完成的。所有子 Agent 共享同一个进程、同一个文件系统视图、同一个上下文窗口。它们之间的通信由宿主工具管理，不存在状态分歧的可能。这是纵向扩展——让一个工具更强。
多工具协调面对的是完全不同的约束：Claude Code 和 Codex CLI 运行在不同的进程中，使用不同的配置约定，对同一个文件系统的访问没有任何协调机制。它们之间没有共享状态、没有锁、没有通信协议。这是横向扩展——让多个工具在同一个代码库上共存。
在软件工程的历史中，这种问题通常由基础设施层解决。当多个进程需要访问共享资源时，操作系统提供文件锁。当多个开发者协作时，Git 提供版本控制。但当多个编码 Agent 共享同一个代码库时，现有的基础设施假设了一个前提：所有变更都由人类发起和审查。这个前提在 AI 编码工具的高频、并行操作模式下已经不再成立。
编排层的核心原语
从 Forge Orchestrator 的架构设计中，可以看到一组正在成型的编排原语。
文件锁是最基础的协调机制。当一个工具开始编辑某个文件时，编排层获取该文件的独占锁。另一个工具请求同一个文件时，不会产生冲突的写入——它会排队等待，并被告知当前锁持有者。锁带有超时机制，崩溃的工具不会永久持有锁。死锁检测确保不会出现互相等待的僵局。
这看起来像操作系统早就提供的功能。但关键在于，文件锁在编码 Agent 的场景中有特殊的语义要求：它需要与工具的任务上下文关联，而不只是字节级的锁。当一个文件被锁定时，编排层需要能够回答"谁在改它、为什么改、改了多长时间"。这种语义锁的需求是 Agent 时代的新产物。
知识飞轮解决的是跨工具的上下文丢失问题。每个编码 Agent 在独立运行时都会积累关于项目的了解：代码约定、架构决策、技术选型理由。这些知识在单工具会话内部可以被利用，但一旦切换到另一个工具，所有上下文归零。
编排层需要在工具之间建立一个持久化的知识库。每次工具会话中产生的决策、模式和关键发现，被自动分类并存储。Claude Code 会话中积累的项目知识，在 Codex CLI 的下一次会话中可以检索和使用。这个机制的核心价值不在于知识存储本身，而在于它打破了工具之间的上下文孤岛。
漂移检测是第三个核心原语。编码 Agent 的一个已知问题是"约束衰减"——随着时间的推移，实现会逐渐偏离初始规格，因为模型在每一步只看到局部上下文。在多工具场景下，这个问题被放大：每个工具都从自己的局部视角出发，最终实现可能与规格产生系统性偏差。
编排层通过将规格说明解析为依赖感知的任务图，然后持续比较实际实现与任务定义的匹配程度，来检测漂移。早期的漂移检测比事后的人工审查成本低得多。
任务规划连接了规格说明和执行。从一份规格文档自动生成任务图，标记依赖关系，分配工具，然后跟踪进度。这实际上是把软件工程的管理流程——需求分解、任务分配、进度追踪——从人的工作变成了编排层的基础设施能力。
架构设计的选择
Forge Orchestrator 的架构体现了一个重要设计决策：编排层应该是无守护进程的。
状态存储在文件系统上（.forge/ 目录），而不是运行一个后台进程。工具之间通过 MCP stdio 协议通信，而不是通过一个中心化的服务端点。这意味着编排层没有单点故障，不需要数据库，不需要容器编排。它只是一个目录结构加一组约定。
这个选择与编码 Agent 的工作方式是一致的。编码 Agent 本身就是进程级的工具，它们不假设网络上有常驻服务。编排层存在于它们操作的同一个文件系统中，以文件作为状态载体，以进程作为执行单元。
另一个关键设计是多工具适配器模式编排层不强制统一配置语言。Claude Code 通过 MCP stdio 接入，Codex CLI 和 Gemini CLI 通过文件系统约定接入。每个工具使用自己习惯的配置格式，编排层在适配层做转换。这是一种务实的选择——如果编排层要求所有工具改用同一套配置规范，采用阻力会大到不可行。
从编排到基础设施
Forge Orchestrator 的实践表明，编码 Agent 的下一阶段演进可能不是让单个工具更强，而是为多个工具共存提供基础设施。当团队开始混用多个编码 Agent 时，他们需要的不是另一个更强的 Agent，而是一层能够协调这些 Agent 的编排逻辑。
这让人联想到微服务架构的演进路径：先有独立的服务，然后发现需要服务发现、配置中心、API 网关、分布式追踪。编码 Agent 的编排层正在复制这条路径——从工具各自为政，走向共享基础设施层。
值得关注的是，编排层在技术栈中的位置决定了它的设计约束。它不能假定所有工具使用同一个框架、同一个通信协议、同一个配置体系。它必须工作在异构环境中，通过最薄的一层抽象连接不同的工具。这正是基础设施软件的传统挑战——提供通用能力而不侵入上层设计。
对于正在采用多个编码 Agent 的团队来说，编排层的设计选择有直接影响：是使用文件系统作为协调媒介（无运维成本但有状态冲突风险），还是使用中心化服务（有运维成本但提供更强的一致性保证）。目前来看，无守护进程的文件系统方案更适合开发阶段的团队使用，而企业级部署可能最终需要中心化的控制面。
无论如何，一个方向正在变得清晰：编码 Agent 的基础设施层正在从"工具内部"走向"工具之间"。当代码库不再只服务一个人或一个工具时，编排就不是可选项，而是必需品。
#AI应用架构 #AI应用开发 #Agent应用架构 #Agent应用开发 #AI开源项目
