consensus
consensus

独立开发2.4：多Agent系统的架构演进(系列终篇)

我们之前写了4篇文章来探讨在AIcoding工具中构建多agent协同系统的可行性。

本篇文章，我们回过头，重新审视一下【操作员+AI模型+多agent协同+智能路由】的架构和【操作员+AI模型】的架构的优劣，并解释为什么最终我还是选择了【操作员+AI模型】的架构。

最终的方案已经放到github：一套vibecoding文档管理和agent提示词系统

在AI技术快速发展的今天，构建智能协作系统成为许多开发者的目标。本文基于实际探索经验，深入分析了多Agent系统架构的演进过程，从最初的理想化四层架构设计，到发现其根本性问题，最终提出更加务实的中和方案。

一、原始四层架构的设计理念

1.1 架构设计

最初的多Agent系统采用了经典的四层协作架构：操作员 → AI模型 → TOA任务编排Agent → 具体专业Agent

  • 操作员：提出需求和约束条件。
  • AI模型：理解和解析操作员意图。
  • TOA（Task Orchestration Agent）：担任中央协调者，负责任务分解、依赖管理和执行调度。
  • 专业Agent：包括架构师、产品经理、前端工程师、后端工程师、QA测试、项目管理等角色。

1.2 理论优势

  • 专业化分工：每个Agent专注于特定领域，能够提供专业化的决策和执行。
  • 智能协调：TOA能够理解复杂任务的依赖关系，合理安排执行顺序。
  • 可扩展性：新增专业角色只需添加对应Agent，架构具有良好的扩展性。
  • 自动化程度高：理论上可以实现从需求到交付的全自动化流程。

1.3 预期工作流程

  • 操作员提出"增加聊天功能"的需求。

  • TOA会自动制定包含需求分析、架构设计、前后端开发、测试验证等完整工作流，并协调各个专业Agent按序执行，最终交付完整功能。

二、现实中的根本性问题

2.1 信息损失的数学必然性

  • 语义压缩损失：每一层对上层信息的理解都是一次有损压缩，关键细节在传递过程中逐步丢失。
  • 噪声累积效应：每层的微小理解偏差会在传递中放大，最终导致"谬以千里"的结果。
  • 上下文稀释：长链条的信息传递使得原始意图在最终执行层变得模糊不清。

2.2 Memory共享的技术壁垒

  • AI的伪记忆本质：当前AI的"记忆"实际上是pattern matching，每次调用都是stateless的重建过程。
  • 全局状态缺失：子Agent无法获取完整的项目上下文，如CLAUDE.md、项目规则、架构状态等关键信息。
  • Memory压缩的工程难题：如何压缩和传递Memory本身就是高难度的工程问题，目前没有成熟的解决方案。

2.3 Token经济学的现实约束

  • 指数级成本增长：四层协作中，每增加一轮交互，Token消耗可能指数级增长。
  • 不可预测的执行时间：Agent间的循环交互可能导致无限延长的执行时间。
  • 调试成本高昂：问题排查需要分析整个协作链条，成本极高。

2.4 工程实践的复杂性陷阱

  • 故障定位困难：系统出错时很难确定是哪个环节的问题。
  • 测试复杂性：每个Agent都受其他Agent影响，无法进行独立测试。
  • 维护成本失控：修改一个Agent可能影响整个系统的稳定性。

三、中和方案：架构简化的智慧选择

3.1 核心思路：保持现有架构文档不变，但重新定义使用方式

  • Agent定义从"AI角色塑造"转变为"工作流程约束文件"。

  • 四层交互简化为两层：操作员直接与AI模型协作。

  • 操作员承担TOA的任务编排职责。

3.2 实现机制

  • 直接调用模式：
操作员：按照ArchitectAgent.md的流程，为聊天功能设计技术架构
AI：[切换到架构师角色，按照ArchitectAgent.md的约束执行]

操作员：现在按照BackendEngineerAgent.md的流程，实现聊天API
AI：[切换到后端工程师角色，按照BackendEngineerAgent.md的约束执行]
  • 角色切换而非协作：同一个AI在不同prompt约束下扮演不同角色，而不是多个AI的真实协作

3.3 方案优势

  • 信息零损失：操作员的完整意图直接传递给AI，无中间解释层。
  • 全局记忆保持：AI模型本身拥有全局记忆，自然解决了Memory共享问题。
  • 成本可控：每次交互都是确定的操作员→AI模式，Token消耗可精确预测。
  • 调试简化：问题直接定位到具体的prompt和响应，调试过程清晰明了。

四、两种方案的理论对比

4.1 技术适应性分析

  • 四层架构：试图在当前AI技术基础上实现分布式智能协作，但超越了技术成熟度。
  • 中和方案：基于当前AI的"超级个体智能"特征，发挥其单体处理能力的优势。

4.2 认知负荷分配

  • 四层架构：操作员：低认知负荷，但失去控制权；系统：高技术复杂度，容易失控。
  • 中和方案：操作员：承担战略决策（发挥人类直觉、创新优势）；AI：承担执行层工作（发挥系统性、一致性优势）。

4.3 控制论视角

  • 四层架构：反馈链路长，故障传播快；控制粒度固化，适应性差；多故障点，鲁棒性弱。
  • 中和方案：最短反馈环（操作员↔AI）；动态控制粒度，适应性强；最少故障点，鲁棒性好。

4.4 工程实践对比

  • 调试难度：四层架构极高，中和方案低。
  • 成本可预测性：四层架构差，中和方案优。
  • 扩展性：四层架构理论上好但实际上差，中和方案线性扩展。
  • 稳定性：四层架构不稳定，中和方案稳定。
  • 学习曲线：四层架构陡峭，中和方案平缓。

结语

经过比较，我们可以看出在当前的阶段，以操作人为中心的组织方式仍然会是比较稳定可行的方案。多agent的架构由于存在比较致命的缺陷，只在理论上具有可行性。

从四层架构到中和方案的演进，反映了技术发展过程中理想与现实的博弈。在AI技术快速发展但仍不完全成熟的阶段，选择务实的、可控的架构方案往往比追求理论上的完美更有价值。

这个探索过程的核心启示是：好的架构不是最先进的架构，而是最适合当前技术条件和实际需求的架构。中和方案通过重新分配人机职责，既保持了系统的专业化能力，又确保了可控性和稳定性，为当前阶段的AI应用提供了一个现实可行的路径。

未来的发展可能会证明多Agent协作的价值，但在那个未来到来之前，中心化的人机协作模式可能是我们能够掌控和依赖的最佳选择。技术的进步不仅在于突破边界，更在于在现有条件下找到最优解。

补充一点信息：从其他人对claudecode的逆向工程破解看来，subagent机制的主要作用是为主模型缓解context压力，从而节约“内存”，从侧面提升主模型的能力。其次才是给subagent赋予各种角色进行专业化工作。

这也说明，在当前subagent并不应该成为任务的主力，我们还是应该将主要精力放到与主模型的交互中。

阅读更多