代理人的组织结构图来了

我们在开头就提出了一个简单的观点：软件开发生命周期的发展速度远远快于大多数企业的工具体系，而正是这种差距催生了新一代平台的诞生。当初我们开始研发 Blitzy 时，令我们兴奋的是那种以自动化为核心的代码生成技术——一种无需依赖一群专门负责处理“人工智能相关”任务的工程师，就能让智能体发挥作用的软件开发模式。Blitzy 所具备的软件开发生命周期管理功能，即便应用于那些混乱且充满技术债务的环境中，依然能够准确理解各种需求、代码库、测试用例以及开发流程，因为在现实环境中，我们不可能在产品发布之前就对整个开发流程进行彻底重构。同样的技术机制也同样适用于新的项目构建与全新功能的开发——无论是从零开始构建项目还是开发新功能，都是通过相同的知识图谱加并行智能体机制来实现的。

有必要详细说明 Blitzy 究竟是如何实现这一点的，因为其运作机制正是本文要探讨的核心。Blitzy 会对你们的代码库进行逆向工程，从而构建出一个动态的知识图谱——这是一种能够存储整个系统信息、并可进行查询的表示形式。其中包含了企业内部的各种依赖关系、历史记录以及工作规范。随后，它会动态地、按需创建数千个专用智能体，这些智能体完全并行运行，并且都遵循既定的规范。这些智能体并不会将整个代码库存储在内存中，也不会互相传递上下文信息；它们是通过那个共享的知识图谱来协作的，每个智能体都在自己独立的处理范围内工作。这并非由一个超级智能体承担所有任务，也不是由某个主智能体将任务分配给少数辅助智能体——而是基于同一个共享的真相来源来实现的大规模并行处理。请记住这一点。

诱人的错误转向

如果仔细观察众多团队的发展动向，就会发现一个共同的趋势：大家都试图让智能代理默认具备全功能。所谓的“项目管理智能代理”不仅会编写代码、进行质量检测、处理警报，还会创建工单——反正也只是多输入些指令而已。短期内来看，这种方式确实很有吸引力。许多企业级工具也都乐于配合这种做法，把各种职能都整合到同一个无所不能的智能助手身上，让它能够处理所有事务，同时产生的操作记录则让合规团队想要躲进黑暗的房间里去。

具有讽刺意味的是，从智能体系统的角度来看，这种“无所不能”的开发模式既效率低下又十分脆弱。Optiver 在关于基于智能体的软件开发生命周期的研究中指出，一旦将智能体视作一种全新的开发要素，那么相关的架构——包括需求规范、工具、审查流程、可观测性机制，甚至是代码的结构——都需要进行大幅调整。实际应用数据也印证了这一点：根据 CrewAI 的统计，在 12 个月内运行的约 20 亿个智能体工作流中，那些成功投入使用的系统并非都是单体结构。这些是由专业特工组成的团队，每位成员都有明确的职责，由一名协调者负责统一指挥——例如 DocuSign 就在一个有序的流程中安排了身份识别员、研究员、作曲家以及验证者，以此来掌控任务的执行顺序与状态。Warp 的 Oz 则基于这样的理念：当特工数量从少数增加至数百个时，虽然处理速度会提升，但可见性、数据控制以及管理能力却会逐渐下降，因此该系统注重实现可审计性，而非让某个超级特工肆意行事。

你其实应该进行的辩论

该行业早已经历过这样的争论。2025 年 6 月，Cognition（Devin 团队）发表了《不要构建多智能体系统》一文，指出并行子智能体本质上十分脆弱：每个子智能体只能基于任务的部分信息来行事，自行做出隐含决策，而这些决策之间往往会发生冲突。他们在文中举的例子是两个子智能体共同构建一个游戏，其中一个负责生成超级马里奥风格的背景，另一个则负责绘制与主题无关的鸟的图像，因为这两个子智能体无法共享彼此的上下文信息。就在次日，Anthropic 发布了《我们是如何构建多智能体研究系统的》一文，展示了如何通过协调器来指挥并行子智能体工作，这些子智能体共同完成的任务效率甚至高于单个智能体——尽管它们消耗的标记量大约是单个智能体的 15 倍，而较高的标记消耗量也正是其性能提升的主要原因。

有一段时间，这看起来像是一场哲学上的分歧。但现在并非如此了。到 2026 年初，这两个阵营已经悄然走向融合：Cognition 推出了一个协调器，负责规划任务并将各项任务分配给独立的 Devin 实例——这一做法与它之前用来反对多智能体系统的“上下文积累会导致专注力下降”的论点如出一辙；而 Anthropic 则选择让各个子智能体承担明确的角色职能，而非采用广泛的点对点通信方式。由此形成的共识虽然细微，但却非常重要：有一个协调器负责管理上下文，各个临时性的专用智能体根据该上下文执行任务并返回总结结果，不存在所有智能体之间都互相交流的机制。

你现在就可以看到这一选择是如何被转化为实际产品的。Claude Code 同时推出了两种功能相似的组件：subagent，它们在独立的上下文窗口中运行，并将处理结果直接反馈给主代理；另一种则是仍处于测试阶段的 agent teams，团队成员可以共享任务列表并直接互相沟通。Anthropic 的设计理念与之前的研究结果几乎完全一致——当需要能够独立完成工作并反馈结果的智能体时，就使用 subagent；而那些需要大量计算资源（每位团队成员都需要一个完整的上下文窗口）的开放性任务，比如研究、审稿或假设验证，才适合使用 agent teams，因为这类任务要求智能体之间能够进行真正的交流。过去一年来，社区一直在就此展开讨论，显然有很多从业者已经不再使用那种需要多人协作的 team 设置，转而选择由单个主代理搭配 subagent 的组合方式。

我们的观点是：采用“子代理反馈机制”才是最合适的默认方案。对于那些最常见、规模最大的任务类型来说，这种机制比点对点并行处理方式更为适用——比如那些需要按顺序执行、存在诸多依赖关系，或是需要多个代理共同处理同一问题的任务（类似《认知》游戏中的马里奥与鸟类的问题）。只有当任务本身具有并行处理特性且需要探索性解决方案时，点对点协作才能带来优势。让多个代理同时工作这一能力本身并不会消失；真正值得探讨的问题是：在何种情况下才应该使用这种机制。

这重新定义了“智能体应当成为专家吗？”这一问题。问题所在并非专业化，而是架构结构。那种让智能体分别负责编写 PRD、维护 Playwright 测试环境、审查代码，且所有智能体都通过共享通信层进行交流的设计，恰恰就是该领域此前试图避免采用的点对点架构。我们确实需要按功能划分不同的职责层级，但绝不需要那种持续存在、重复冗余的并行处理方式。正如某篇广为流传的关于新 SDLC 流程的分析文章所说，在几乎所有情况下，一个配置完善的通用型智能体都比那些结构脆弱的智能体群更优秀——不过我们还是希望拥有各种类型的智能体。

编曲

现在让我们回到之前让你们思考的那个问题——因为 Blitzy 并非站在那场争论的任何一方，而是选择绕过它来解决问题。回想一下 Cognition 提出的实际反对意见：并行代理之所以会失败，是因为每个代理都是基于片面的信息来工作的，它们之间的隐含决策会相互冲突。Cognition 的建议是将所有内容都放在同一个线程中，并共享完整的上下文信息。不过，这种做法在代码量达到数亿行、且那些代码还是别人留下的旧版 Java 代码时就不再适用了。

Blitzy 的解决方案就是共享知识图谱。它能够运行 Cognition 所警告过的那些数千个并行智能体，但没有任何一个智能体会基于片面的信息来行事，因为真正的共享式、持久化的理解存储在知识图谱中——而非某个单个智能体的上下文窗口，也不是智能体之间的信息传递过程。Cognition 指出的协调问题确实存在；Blitzy 只是通过专门设计的知识图谱数据库来解决这个问题，而非通过拒绝使用并行处理方式。除此之外，它还拥有自我改进的协调机制：当某个智能体遇到难题时，它会尝试各种解决方法，比如更换模型、重新编写自身的提示词、寻求其他智能体的帮助；而那些真正可行且通过测试的解决方案会被重新录入到知识图谱中，这样后续的智能体就无需再重复探索这些解决方案了。

究竟会建成什么

退一步来看，这种结构其实只不过是一张组织结构图罢了。在这样一家公司里，一个人身兼所有职务、掌握所有密码，而且不保留任何记录，这样的做法效率极低——虽然出发点是好的，但实际上却会带来风险，而这正是那种试图包办一切的“超级代理人”所表现出来的特征。在另一类公司中，虽然大家都在同时工作，但却没有人能够共享信息，这就好比把《超级马里奥》的背景图硬贴在《Flappy Bird》的游戏画面之上一样。无论是在软件开发还是企业运营中，真正有效的做法都是进行分工，并建立相应的机制来确保分工的顺利进行：明确定义各人的职责、拥有统一的资讯来源、设置管理层来协调各项工作，同时还要有足够的透明度，以便在问题出现之前就及时发现并解决它。

除了像 Blitzy 这样的完整解决方案之外，或者完全不依赖代码生成的方式——目前还无人能够实现这种方案——另一种办法就是手动为各个智能体设定相同的组织结构。要防止某个智能体悄悄承担所有职责。要让这些并行运行的智能体之间能够真正实现协调，并拥有一个关于其所操作系统的统一模型，同时还要让系统中的异常情况以信号的形式呈现出来，而非意外状况。这正是整个行业正在朝其发展的方向，而相关技术语言也体现了这一点：a16z 提出的“企业级管弦乐团架构”理念，其实就是为机器设计的组织结构——在数据记录系统之上构建协调系统，同时还设有智能体监管者及治理负责人等新角色。

贝塞默从安全角度阐述了审计与人力资源管理职能：它能够实时显示每个智能体的状态以及其被允许操作的范畴。因为如果给某个智能体过大的操作权限，却只让它执行简单的任务，那无疑是一种配置错误，随时可能引发问题。各公司也在探索类似的架构与职责划分——Port.io 致力于实现从人工智能辅助决策到人工智能全面主导决策的转变；思科的 Outshift 团队则让人类负责制定规则和策略，而智能体则负责具体执行任务；在 Latent Space 平台上，则存在着关于自主权与权限分配的激烈争论。

目前的这些企业也在大规模地宣扬同样的理念。在 2026 年 6 月举办的 Data + AI 峰会上，Databricks 将自己定位为“企业级 AI 智能体的操作系统”，并正式推出了相关的架构组件：Genie Ontology 是一种“动态上下文图谱”，它能为每个智能体提供完整的业务语义模型，而非仅部分信息；Unity AI Gateway 则是一个统一的控制平台，负责将各项任务分配到合适的模型中，同时管理整个系统中的成本、MCP 服务器以及安全问题；而 Omnigent 则是一种元级协调工具，能够让各类专用智能体之间实现互相发现、共享上下文信息并协同工作。

有一点值得深思：这里所有的成功案例——Bessemer 的审计与人力资源管理机制、a16z 的协调机制，以及 Databricks 对整个系统的管理——都属于单组织架构下的治理模式，即由一个负责人来统一管理所有系统，将其纳入同一个框架或接口之下。这种模式在由单一主体负责所有事务时是有效的。但将来我们必然需要进一步拓展这种治理模式，实现跨不同系统、供应商和组织的协调与管理，此时便不存在可以共同使用的框架，因此必须依靠中立的信任机制来维持秩序。

—

当然，说起来容易做起来难……只有明确每个人该负责什么工作时，组织结构图才有意义。Blitzy 能够构建这样的结构图，是因为代码是可验证的：代码可以成功编译、测试通过、合并提交，而这些都是可供参考的可靠信号。不过大多数企业并没有这么幸运。在那些无法进行验证的场景中，问题不在于如何协调各个环节，而在于如何生成足够可信的上下文以便实现协调。如果有可用来校验的数据，合成数据就能发挥作用；而在没有此类数据的情况下，合成数据只会带来负面影响。因此，真正的关键或许并非协调层，而是那些能确保生成的上文具有可信度的评估机制。这倒是个适合在另一篇文章中探讨的话题。

目前还没有人设计出最终的架构。不过其大致形态已经足够清晰，可以据此下注。获胜的机构不会把每项任务都交给同一个智能体，也不会将上百个智能体简单组合成一个没有领导层的网络。他们会为这些智能体制定组织结构图：通过明确分工避免某个智能体独占所有职责；设置管理层来协调各项任务，并依据不断更新的系统状态来指导工作；同时还要确保整个系统的运作透明可查。没错，会采用大规模并行处理的方式——但前提是必须要有适当的上下文环境。这正是我们支持 Blitzy 时所下的赌注，也是我们对企业尚未建成的协调层所抱有的期望。