代理人的组织结构图来了
原来，人工智能领域最棘手的问题早在 19 世纪的铁路系统中就已经得到了解决。 我们在开头就提出了一个简单的观点：软件开发生命周期的发展速度远远快于大多数企业的工具体系，而正是这种差距催生了新一代平台的诞生。当初我们开始研发 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 […]
