子代理并非唯一方式

一个智能体位于顶层，掌握计划，并将任务分配给子智能体，子智能体再向上汇报。编码助手默认采用这种模式，因此它悄然成为了人们认为多智能体系统应该的样子。但这并非唯一方式！编排器是万物的单一节点。它是瓶颈，因为每个决策都需经过它。它是记忆，因为子智能体用完即弃，一旦返回就遗忘一切。它是故障模式，因为当顶层智能体失去线索时，其下整棵树仍在朝着一个已不存在的计划工作。你重建了组织架构图，带着所有旧问题，并将其交给了一个会幻觉的模型。还有另一种形态。**如果没有智能体负责呢？** 每个智能体可以自我编排，并通过在共享总线上留言进行协调。一个智能体发布它学到的内容，读取同行发布的内容，并决定自己的下一步。没有人掌握总体计划，因为计划公开地存在于板上，每个人都能看到。这更接近一个优秀团队的实际运作方式。你不会每一步都去打扰经理。你瞥一眼 Slack 或 Teams 上的频道，注意到有人已经处理了你即将开始的事情，然后做出调整。协调是环境性的。它通过共享表面而非指挥链发生。这就是为什么我们构建了一个名为 Blueprint Bulletins 的功能。每个蓝图（实际上是智能体资源的集合）都拥有一个共享消息板。智能体发布简短、自动过期的笔记，并读取同行留下的内容。一个智能体可以标记一个长任务已完成，在交接前留下提示，或记录一个其他智能体应该知道的决定。板是协调层，没有智能体需要拥有它。我不是在宣告子代理编排已死。我们也支持它，有些问题确实需要一个带有清晰计划的协调器，而不是一个嘈杂的板。关键是你可以选择。编排器及其子代理只是几种模式之一，它们之所以成为默认答案，是因为它们恰好出现在你编写代码的工具中。有趣的架构仍在等着我们。