商业产业 Hacker News Agent 2026-10-11T20:34 正文 ok 1373 words

多 Agent 编排框架需要独立的消息通道

英文标题：🔶 Multi-agent harnesses need separate message channels

当前多 Agent 编排框架通常将用户指令、子 Agent 状态、同级协作和 CI 告警混入同一个聊天窗口，导致人类监督者难以辨别消息来源、权限与优先级。文章提出，单个 Agent 实际需要上游、下游、横向、同级和告警五类通信通道，并应在同一上下文中保留明确标签和独立审计视图。作者认为，仅靠提示词标签无法解决人类介入和审计困难，框架层必须负责消息路由、权限约束以及告警分级与去重。对于开发者而言，这意味着多 Agent 系统的核心瓶颈正从模型能力转向协作界面、治理机制与可观测性。

打开原文相关 3 · 机会 1

125.6 KB

中文

如今，每条消息都会进入同一个聊天框。上游、下游、横向、同级协作和告警，各自都需要独立的通道。

最近，我一直在用自己每天都在使用的同一套框架把 Agent 连接起来。一个 Agent 负责规划，几个 Agent 负责执行，一个 Agent 负责审查，而我则坐在中间某处推动事情向前。这套方式能运转，但很快就会变得混乱，而感到困惑的并不是模型，而是我。

每条消息都落入同一个聊天框。来自我的请求、子 Agent 的状态更新、负责监督该 Agent 的 Agent 发来的“请澄清一下”、同级 Agent 的备注，以及 CI 失败，表面上看起来完全一样：都是一条文本，堆在一个不断延伸的滚动窗口里。二十分钟后，我已经分不清是谁要求了什么。Agent 能分清，因为它拥有完整上下文，并可以推断是谁说了什么。但负责监督的是我，最后我只能手动重建整个过程。

一种解决办法，是让 Agent 使用工具给我生成一张图，画出谁向谁发送了什么消息。这可行，但只是在混乱之上打补丁。更干净的解决办法，是从一开始就不要混合这些信息流。为每一类通信提供独立通道，让我能够单独阅读和审计。

一个界面，五种关系

如今的框架假设只有一段对话：一个人类与一个 Agent 交谈。一旦 Agent 之间开始互相交谈，这个假设就失效了。团队中处于中间位置的 Agent，实际上会同时面对五条信息流：

上游：它的监督者。 将任务交给它、设定目标并等待结果的 Agent（或人）。上游始终位于具体工作之外，不会直接修改代码或文档。它的职责是元工作：决定工作是什么、是否走在正轨上，以及是否已经完成。这里的消息关乎范围、优先级和进度汇报。
下游：它管理的 Agent。 被它拆分任务并分派工作的执行者。指令向下发出，进度、结果或阻塞问题向上传回。
横向：与它共同工作的那个人类。 通常是拥有该 Agent 的人，与它处在同一项工作中，查看相同的文件、相同的 diff，以及同一份尚未完成的草稿。这里不存在汇报关系，而是结对协作。横向是唯一一个每条消息都来自人类的通道：由人亲自输入，而非由 Agent 生成，例如“嘿，实际上应该这样做”“你为什么这么选”“停下，这是错的”。
同级：处于相同层级的其他 Agent。 同一监督者下的兄弟 Agent，或相邻团队中的 Agent。这里没有任何一方管理另一方。消息用于协调：“我正在编辑 auth.ts，先别动”“你的 API 返回什么结构”“我已经修好了，跳过它”。
告警：并非由任何人发起的事件。 构建失败、测试变红、计时器触发、webhook 到达，或预算即将耗尽。没有人在提问，但某些状态发生了变化，Agent 可能需要作出反应。

最容易混淆的一对是上游和横向，因为两者都可能是人类在给出方向。区别在于他们所处的位置。上游站在工作之外，谈论的是_关于_工作的事：目标、截止日期、验收。横向站在工作之内，谈论的是工作_中的_事：这一行、这个函数、这一段文字。监督者会问：“登录流程完成了吗？”共同工作的同事会说：“那个重定向不对，应该使用回调 URL。”同一个人可以同时扮演这两种角色，但任意一条具体消息只能属于其中之一。

这些通道承载着不同的权威级别、不同的紧急程度，以及不同的回复预期。把五者压缩进同一条信息流，就像把你与经理、下属、联合创始人、队友和寻呼告警系统之间的全部工作，都塞进同一个邮件线程。

混在一起时会发生什么

权威来源丢失。 来自子 Agent 或同级 Agent 的指令，看起来与来自人类的指令完全一样。Agent 通常可以根据上下文分辨“我的执行 Agent 建议 X”和“我的负责人要求 X”，但这没有任何保证；而我如果不重读全部内容，就无法核查。
回复发往错误的地方。 Agent 在只有人类能看到的位置回答下游的问题，或者向它的监督者汇报本该发给执行 Agent 的内容。
同级 Agent 发生冲突。 没有直接的横向通道时，兄弟 Agent 只能通过监督者协调，或者根本不协调。两个 Agent 会编辑同一个文件，或同时修复同一个 bug，监督者只能事后才发现。
告警被淹没，或反过来劫持工作。 聊天滚动流中间的一条构建失败通知很容易被忽略。或者反过来，Agent 将每一条通知都当作新命令，丢下当前任务去追逐噪声。
人类无法清晰地介入。 如果我想在某个 Agent 执行任务的中途纠正它，我的消息会和其他所有消息进入同一个队列。它不会被标识为来自真正负责的人。
审计记录变成一团糨糊。 回头查看时，没人能还原是谁做了什么决定，或是什么触发了某个行动。而这恰恰是在出错时最重要的信息。

前四个问题可以打补丁，尽管并不干净。为每条消息标注发送者，增加“这条消息来自我的负责人”的标记，在告警前加上 [ALERT] 前缀，Agent 大多数时候就能整理清楚。但后两个问题无法这样解决，因为它们关乎人类，而不是 Agent。到达的消息实在太多、太快，任何试图介入或回溯的人都会迷失在滚动信息流中。如果我仍然得阅读一千条带标签的消息，才能找出那条重要内容，标签对我没有帮助。

框架应该做什么

更聪明的模型无法解决这个问题。框架需要具备结构：

一个上下文中的五个通道。 Agent 保持单一的工作记忆，但每条消息都被标记为上游、下游、横向、同级或告警。模型能看到这个标签，框架则强制执行它。这不是某人贴进提示词里的约定。
面向人类的独立视图。 为每个通道提供一个面板或过滤器。当我打开一个 Agent 时，我希望能看到它的上级提出了什么要求、它的执行 Agent 在说什么、它的同级 Agent 正在协商什么、发生了什么事件，以及我说了什么，而不是一次滚动浏览所有内容。每个通道都是独立日志，因此我可以一次审计一种关系。
回复需要明确寻址。 当 Agent 响应时，它要选择一个通道。“向上汇报”“向下指示”“回答我的人类协作者”和“通知我的同级 Agent”是不同的动作，而不是一个通用的 send。告警不应得到“回复”，而应被确认、处理或升级。
权威应随通道而定。 上游设定目标，并决定目标何时达成。负责人的横向消息可以覆盖具体应如何完成工作，细至某一行代码。下游提供的是输入，而不是命令。同级 Agent 可以询问和告知，但永远不能命令。告警传递的是事实，而不是指令。框架可以强制执行这一排序，而不是寄希望于模型从语气中自行领会。
告警应有自己的规则。 严重性、去重和路由应由框架负责。失败的部署应当中断当前工作；不稳定的 lint 警告则可以留在队列中等待。Agent 决定如何处理告警，但不应还要判断告警是不是一个人。

我们早已在其他地方这样做了。组织架构图长期以来就区分了这些关系。电子邮件的邮件头中有收件人、抄送人和老板的名字。Slack 将私信与频道分开，没有人会把 PagerDuty 页面告警误认为是经理发来的消息。我们却在一个假定团队中只有一个人的聊天 UI 上构建多 Agent 系统。

为什么是现在

单 Agent 框架已经足够成熟，因此人们开始将它们串联起来。这个链条正在成为工作单元，而聊天框无法随着它一起扩展。我希望下一套我使用的框架，能让 Agent 和我都一眼看清：是谁在说话，以及是否根本没有人在说话。

上游、下游、横向、同级、告警。一个上下文中的五段对话。仅仅为了这一点，我就愿意切换框架。

English / 原文

Today every message lands in one chat box. Upstream, downstream, sideways, peers and alerts each need their own channel.

Lately I've been wiring agents together using the same harnesses I use every day. One agent plans, a few others execute, one reviews, and I sit somewhere in the middle nudging things along. It works. It also gets confusing fast, and the models aren't the ones getting confused. I am.

Every message lands in the same chat box. A request from me, a status update from a sub-agent, a "please clarify" from the agent supervising this one, a note from a sibling agent, and a CI failure all look the same: a line of text in one long scroll. After twenty minutes I can't tell who asked for what. The agent can, since it has the whole context and can work out who said what. But I'm the one supervising this, and I end up reconstructing it by hand.

One fix is to have the agent build me a picture, using tools to draw who sent what to whom. That works, but it's a patch on top of the mess. The cleaner fix is to never mix the streams in the first place. Give each kind of communication its own channel, one I can read and audit on its own.

One interface, five relationships

Today's harnesses assume a single conversation: one human talking to one agent. Once agents talk to each other, that breaks. An agent in the middle of a team actually has five streams going at once:

Upstream: its supervisor. The agent (or person) that handed it the task, set the goal, and is waiting on the result. Upstream is always outside the work. It doesn't touch the code or the doc. Its job is the meta work of deciding what the work is, whether it's on track, and whether it's done. Messages here are about scope, priorities, and reporting back.
Downstream: the agents it manages. The workers it split the task across. Instructions go out, and progress, results, or blockers come back.
Sideways: the human co-working with it. Usually the person who owns the agent, sitting inside the same work and looking at the same files, the same diff, the same half-finished draft. There's no reporting line here, it's pairing. Sideways is the one channel where every message comes from a human, typed by a person rather than generated by an agent: "hey, actually do it this way," "why did you pick that," "stop, that's wrong."
Peers: other agents at the same level. Siblings under the same supervisor, or agents on a neighboring team. Nobody here is in charge of anybody. Messages are coordination: "I'm editing auth.ts, hold off," "what shape does your API return," "I already fixed that, skip it."
Alerts: things that aren't anyone talking. A build broke, a test went red, a timer fired, a webhook landed, a budget is nearly spent. Nobody is asking a question, but something changed and the agent may need to react.

The easiest pair to blur is upstream and sideways, since both can be a human giving direction. The difference is where they stand. Upstream stands outside the work and talks about it: goals, deadlines, sign-off. Sideways stands inside the work and talks in it: this line, this function, this paragraph. A supervisor asks "is the login flow done?" A co-worker says "that redirect is wrong, use the callback URL." The same person can play both roles, but any single message is one or the other.

These carry different authority, different urgency, and different expectations about a reply. Squashing all five into one stream is like running your whole job out of a single email thread with your manager, your reports, your cofounder, your teammates, and your pager all on it.

What goes wrong when they're mixed

Authority gets lost. An instruction from a sub-agent or a peer looks exactly like one from the human. The agent can usually tell "my worker suggests X" from "my owner says X" by context, but nothing guarantees it, and I can't check without rereading everything.
Replies go to the wrong place. The agent answers a downstream question somewhere only the human sees, or reports to its supervisor something that was meant for a worker.
Peers collide. Without a direct lateral channel, siblings coordinate through the supervisor, or not at all. Two agents edit the same file, or both fix the same bug, and the supervisor finds out afterwards.
Alerts drown, or hijack. A red build in the middle of a chat scroll gets missed. Or the reverse happens and the agent treats every notification as a new order, dropping its task to chase noise.
Humans can't step in cleanly. If I want to correct one agent mid-task, my message goes into the same queue as everything else. It isn't marked as coming from the person who's actually responsible.
The audit trail is mush. Looking back, nobody can rebuild who decided what, or what triggered it. That matters most exactly when something went wrong.

The first four can be patched, uncleanly. Tag each message with its sender, add a marker for "this came from my owner," prefix alerts with [ALERT], and the agent will mostly sort it out. The last two can't be patched that way, because they're about the human, not the agent. There are just too many messages arriving too fast, and anyone trying to step in or look back gets lost in the scroll. Tags don't help me if I still have to read a thousand tagged lines to find the one that matters.

What the harness should do

A smarter model won't fix this. The harness needs structure:

Five channels in one context. The agent keeps a single working memory, but every message is tagged upstream, downstream, sideways, peer, or alert. The model sees the tag, and the harness enforces it. It's not a convention someone pastes into a prompt.
Separate views for the human. Give me a pane or filter per channel. When I open an agent, I want to see what its boss asked, what its workers are saying, what its peers are negotiating, what fired, and what I said, without scrolling through all of it at once. Each channel is its own log, so I can audit one relationship at a time.
Replies are addressed. When the agent responds, it picks a channel. "Report up," "instruct down," "answer my human," and "tell my peers" are different actions, not one generic send. Alerts don't get replies. They get acknowledged, handled, or escalated.
Authority follows the channel. Upstream sets the goal and decides when it's met. Sideways from the owner can override how the work gets done, down to the line. Downstream is input, not orders. Peers can ask and inform but never command. Alerts carry facts, not instructions. The harness can enforce that ordering instead of hoping the model picks it up from tone.
Alerts have their own rules. Severity, dedupe, and routing belong to the harness. A failing deploy should interrupt. A flaky lint warning can wait in the queue. The agent decides what to do about an alert, but it shouldn't have to work out whether an alert is a person.

We already do this everywhere else. Org charts have had it forever. Email has To, CC, and the boss's name in the header. Slack keeps DMs apart from channels, and nobody confuses a PagerDuty page with a message from their manager. We're building multi-agent systems on a chat UI that assumed a team of one.

Why now

Single-agent harnesses got good enough that people started chaining them. The chain is becoming the unit of work, and the chat box doesn't scale with it. I want the next harness I use to make it obvious, to the agent and to me, who is talking, and whether anyone is talking at all.

Upstream, downstream, sideways, peers, alerts. Five conversations in one context. I'd switch harnesses for that alone.

A plug

Do you run multiple agents together? Do you want to manage them across vendors, harnesses, and machines, all from one place? Do you want to do it from any browser and your phone? Try reminal.