多智能体框架需要独立的消息通道

如今每条消息都落进同一个聊天框。上游、下游、横向、同级和对齐告警，各自都需要自己的通道。

最近我一直在用日常使用的同一套工具把智能体连接起来。一个智能体负责规划，另外几个负责执行，一个负责审查，而我坐在中间某个位置推动事情前进。这行得通。但它也很快就会变得混乱，而搞混的并不是模型。是我。

每条消息都落进同一个聊天框。我发出的请求、子智能体的状态更新、监督这个智能体的那个智能体发来的“请澄清一下”、同级智能体发来的备注，以及一次 CI 失败，看起来全都一样：一条长滚动记录里的一行文字。二十分钟后，我就分不清谁要了什么。智能体能分清，因为它拥有完整上下文，能推断出谁说了什么。但负责监督的人是我，最后我只能靠手工去重建。

一个解决办法是让智能体给我画一张图，用工具画出谁向谁发送了什么。这行得通，但只是在这个烂摊子上打了个补丁。更干净的解决办法是一开始就不要把各种流混在一起。给每种通信各自一条通道，让我可以单独阅读和审计。

一个界面，五种关系

如今的工具默认只有一段对话：一个人对一个智能体说话。一旦智能体之间开始互相交谈，这种假设就崩了。团队中间的一个智能体实际上同时有五条流在跑：

上游：它的监督者。把任务交给它、设定目标并等待结果的那个智能体（或人）。上游始终在工作之外。它不碰代码或文档。它的职责是元工作：决定工作是什么、是否在正轨上、是否完成。这里的消息关乎范围、优先级和汇报。
下游：它管理的智能体。它把任务拆分给的那些执行者。指令发出去，进度、结果或阻塞项传回来。
横向：与它协作的人类。通常是拥有这个智能体的人，身处同一项工作之中，看着同样的文件、同样的 diff、同样写了一半的草稿。这里没有汇报关系，这是结对。横向是唯一一条每条消息都来自人类的通道，由人输入而不是由智能体生成：“嘿，其实应该这样做”“你为什么选那个”“停，那不对。”
同级：同一层级的其他智能体。同一个监督者下的兄弟智能体，或相邻团队里的智能体。这里没有人管任何人。消息是协调：“我在编辑 auth.ts，先别动”“你的 API 返回什么形状”“那个我已经修好了，跳过吧。”
告警：不是任何人在说话的事情。构建挂了、测试变红了、定时器触发了、webhook 到达了、预算快用完了。没有人在提问，但某些东西变了，智能体可能需要做出反应。

最容易混淆的一对是上游和横向，因为两者都可能是人在给出指示。区别在于他们所处的位置。上游站在工作之外，谈论的是关于工作的事：目标、截止时间、验收。横向站在工作之内，谈论的是工作之中的事：这一行、这个函数、这一段。监督者问“登录流程做完了吗？”协作者说“那个重定向不对，用回调 URL。”同一个人可以同时扮演两种角色，但任何一条单独的消息只能是其中一种。

它们承载着不同的权威、不同的紧迫性，以及对回复的不同期望。把全部五种都塞进一个流里，就像把你整个工作都塞进一个邮件线程里，而你的经理、你的下属、你的联合创始人、你的队友和你的寻呼机全都在这个线程里。

混在一起时会出什么问题

权威会丢失。来自子代理或同级的指令看起来和来自人类的指令一模一样。代理通常能根据上下文分辨“我的下属建议 X”和“我的主人说 X”，但没有任何东西能保证这一点，而且我不重新读一遍所有内容就无法核实。
回复会发错地方。代理在只有人类能看到的地方回答了一个下游问题，或者向它的主管汇报了本该发给下属的内容。
同级会冲突。没有直接的横向通道，同级之间要么通过主管协调，要么根本不协调。两个代理编辑同一个文件，或者都去修同一个 bug，而主管事后才发现。
警报会被淹没，或者劫持注意力。聊天滚动中一条红色的构建失败会被错过。或者反过来，代理把每条通知都当成新命令，丢下任务去追噪音。
人类无法干净地介入。如果我想在任务中途纠正某个代理，我的消息会和其他所有东西一起进入同一个队列。它没有被标记为来自真正负责的人。
审计线索是一团浆糊。回头看时，没人能重建谁决定了什么，或者是什么触发了它。而这恰恰在出问题时最重要。

前四个可以打补丁，但不干净。给每条消息打上发送者标签，加一个“这来自我的主人”的标记，给警报加上 [ALERT] 前缀，代理基本就能理清。后两个没法这样打补丁，因为它们关乎人类，而不是代理。消息实在太多、来得太快，任何想介入或回看的人都会迷失在滚动中。如果我还是得读一千行带标签的内容才能找到重要的那一条，标签帮不了我。

框架应该做什么

更聪明的模型解决不了这个问题。框架需要结构：

一个上下文中的五个通道。代理保持单一工作记忆，但每条消息都被标记为上游、下游、横向、同级或警报。模型看到标签，框架强制执行它。这不是让人粘贴到提示词里的约定。
为人类提供独立视图。给我每个通道一个窗格或过滤器。当我打开一个代理时，我想看到它的上级问了什么、它的下属在说什么、它的同级在协商什么、什么被触发了，以及我说了什么，而不用一次性滚动浏览全部内容。每个通道是独立的日志，这样我可以一次审计一段关系。
回复是有地址的。当代理回应时，它选择一个通道。“向上汇报”“向下指示”“回复我的人类”和“告诉我的同级”是不同的动作，而不是一个通用的 send。警报不会得到回复。它们被确认、处理或升级。
权威跟随通道。上游设定目标并决定何时达成。来自主人的横向消息可以覆盖工作如何完成，直到具体执行。下游是输入，不是命令。同级可以询问和告知，但绝不能命令。警报携带事实，而非指令。框架可以强制执行这种顺序，而不是指望模型从语气中领会。
告警有自己的规则。严重程度、去重和路由属于框架的职责。部署失败应该打断你。偶发的 lint 警告可以排队等待。Agent 决定如何处理告警，但它不应该去琢磨某个告警是不是一个人。

我们在其他所有地方都已经这么做了。组织架构图一直如此。电子邮件的头部有收件人、抄送和老板的名字。Slack 把私信和频道分开，没人会把 PagerDuty 的告警和经理发来的消息搞混。我们却在一个假设团队只有一个人的聊天界面上构建多 Agent 系统。

为什么是现在

单 Agent 框架已经足够好，人们开始把它们串联起来。这条链正在成为工作的基本单位，而聊天框无法随之扩展。我希望我用的下一个框架能让 Agent 和我都清楚地知道谁在说话，以及是否有人在说话。

上游、下游、横向、对等方、告警。一个上下文里有五段对话。光是为了这一点我就愿意换框架。

一个插件

你会同时运行多个 Agent 吗？你想跨供应商、框架和机器，从一个地方统一管理它们吗？你想从任何浏览器和手机上做到这一点吗？试试 reminal。