频道、花名册与 @ 路由：把多智能体协作塞进聊天界面

频道、花名册与 @ 路由：把多智能体协作塞进聊天界面

【免费下载链接】OpenMausBotOpen-source Grok Bot alternative with a virtual machine that bots can use项目地址: https://gitcode.com/GitHub_Trending/op/OpenMausBot

当“多智能体”从演示 demo 走向日常使用，最先暴露的不是模型能力，而是界面承载方式：一个对话框里塞进三五个 Bot，上下文必然糊成一团；每开一个任务就复制一份 Agent，配置又会分裂成无数个近似副本。OpenMausBot 选择的路线是把协作还原成人类最熟悉的心智模型——频道（Channel/Room）+ 花名册（Roster）+ @ 提及：频道承载场景与共享上下文，花名册定义谁能被叫到，@ 决定这一句话由谁接。

本文不谈概念宣传，而是沿着仓库源码，把这三层拆开看：频道记录里到底存了什么、@ 路由如何在服务端与渲染端保持一致、上下文为什么不会互相干扰，以及“把工作流做成消息流”必须付出哪些工程代价。

一、频道不是复制粘贴的 Bot，而是一份共享记录

在数据模型里，频道就是WireGroup（服务端持久化为GroupRecord），它不是“一个 Bot 的副本”，而是一组指向既有 Bot 的 id 加上一层场景配置。核心字段集中在 shared/wire.ts：

• threadId：频道当前活动任务的会话线程；tasks?: GroupTask[]是频道下并列的多个任务（新任务在前）。也就是说“频道”与“对话线程”是一对多，频道可以不断开新任务而不丢失历史。
• memberIds：花名册，只是对 Bot 记录的引用，所以同一批 Bot 可以同时出现在工作、生活、项目三个频道里，各自的模型、账号、虚拟机配置只有一份。
• bulletin：房间级共享指令（长期约定），与每个成员的 profile 分开；description是标题下的一行短描述，注释特意写明null = explicitly cleared, so a client's shallow merge drops a stale value——客户端浅合并时如何安全清空字段，这类细节在协作型 UI 里比功能本身更容易翻车。
• defaultResponder：无人被 @ 时的兜底路由，取值为everyone/mentions/member/auto。
• cwd/pinnedCwd：房间的共享工作目录。它有一个非常“产品化”的约束，见 server/room-folder.ts：房间会一直保留它创建时的文件夹，如果该目录消失，就直接在回合开始前报错——This room's working folder no longer exists: … Create that folder again: a room keeps the folder it started in.而不是让引擎误把问题算到某个 Bot 头上。
• section：侧边栏分区；audienceFloor：这个房间历史最窄的可见范围——注释写得很直白：Bot 退出不会放宽谁可以看这段对话记录。权限只会收紧，不会因为成员变动被悄悄放大。
• dm?: boolean：Bot 与 Bot 自动建的一对一频道走同一套结构，但被排除在 holds、任务列表、@everyone等群语义之外。

值得注意的是，频道共享的是“场景”（指令、目录、成员、兜底路由），而不是“上下文”——上下文是每个成员各自一份的，这正是下一节要处理的问题。

二、独立上下文：一个频道，N 份互不干扰的会话

多智能体聊天最容易出现的问题叫“上下文串味”：A 的中间推理被 B 当成事实，或者 B 把 A 的临时草稿当作最终结论继续往下推。OpenMausBot 的处理分三层。

第一层：给 Bot 的输入是一个有界窗口，而不是无限长的聊天记录。server/host/room-transcript.ts 负责把线程渲染成给模型看的文本，并且只截取最后GROUP_CONTEXT_MESSAGES条：

export const GROUP_CONTEXT_MESSAGES = DRAIN_COALESCE_MAX_ITEMS; // = 30 ... const context = messages.filter(isRoomContextMessage); const readable = context.filter((m) => !narration.has(m.id)); const shown = readable.slice(-GROUP_CONTEXT_MESSAGES);

isRoomContextMessage只放行三类消息：有正文的text、摘要digest、以及roomRequest.phase === "result"的队友结果回报。工程日志、审批卡片下的过程旁白（roomTurnNarrationIds）不会进入窗口。这个 30 不是随手写死的常量，server/admission.ts 里给出了理由：

Room turns read only the room-context window's last N messages, so a bigger group would append lines the responder never sees.

也就是说，队列合批上限必须小于等于上下文窗口，否则一次合并进 40 条消息，模型只看得到后 30 条，前面 10 条就变成了“说了但没人看见”的幽灵输入。

第二层：每个成员有自己的 token 账本与压缩阈值。server/room-context.ts 的RoomContextTracker是按(threadId, botId)记账的：

record(threadId, botId, reading, model, catalog) // tokens + window dispatch(threadId, botId, instanceId, settings) // { reset, displaced } takeReset(...) // reason: "requested" | "threshold"

默认阈值DEFAULT_ROOM_COMPACT_AT = 0.9，可通过context.roomCompactAt（比例或绝对 token 数）与autoCompact调整，定义在 server/room-context-settings.ts 与 server/config.ts。用户看到的不是一段沉默，而是一行明确说明，由roomResetNote生成：

reset.reason === "requested" ? `compacted ${name}'s context (${reset.percent}% full): fresh session with the room's recent messages` : `${name}'s context was ${reset.percent}% full: compacted to a fresh session with the room's recent messages`

同时dispatched()里有一句关键注释：Each engine keeps one warm process per thread, so this turn closes the other members' processes on its engine.同一引擎在同一线程里只保留一个热进程，轮到别人说话时，前一个成员在该引擎上的进程会被关闭并计入displaced。这既是资源约束，也是隔离手段：不让两个 Bot 的进程在同一线程里共享状态。

第三层：增量续传必须可证明“没漏行”。当context.roomSessions打开（或OMB_ROOM_SESSIONS=1）时，server/host/room-sessions.ts 只把该成员没见过的行追加进它原来的原生会话。文件头第一行就是一条不变式：

// Invariant: every window line is in the text sent, or was shown to this same native session in exactly this form; any doubt sends the whole window.

任何不确定（例如进程被保活跨过了会话起点、strictResume不可用、房间上下文在两次轮次之间被改写）都退化为“整窗重发”，而不是赌一把增量。这与delta-context.ts里“房间帖子/Webhook 帖子从未有过原生会话”的处理是同一套保守策略——宁可多花 token，也不让某个成员基于自己没看到的半截对话行动。

三、@ 路由：一处定义、两端复用、三类边界

渲染端要点亮@Juniper，服务端要据此决定唤醒谁。如果两边各写一套正则，UI 高亮的名字和服务端真正路由的名字迟早会分叉。仓库把最底层的判定抽到了 shared/mention-boundary.ts，前后端共用：

const OPENING_MENTION_BOUNDARY = /[(*_~[{<'"\u2018\u201c\u3008\u300a\u300c\u300e\u3010\uff08]/u; export function isMentionBoundary(text: string, at: number): boolean { if (at === 0) return true; const before = text[at - 1]; return /\s/u.test(before) || OPENING_MENTION_BOUNDARY.test(before); } export function isMentionNameContinuation(value: string | undefined): boolean { return value !== undefined && /^[\p{L}\p{N}\p{M}_]/u.test(value); }

注释解释了取舍：只允许空白与“开括号/Markdown 前缀”作为边界，因此/@bot仍然是 URL 路径，而(@bot)、【@bot】、**@bot**会被认作提及；名字后面紧跟字母、数字、组合符号或下划线则不算命中——所以@Juniper2、@調査担当者不会误伤@Juniper、@調査担当。

在这层之上，服务端的选人逻辑是 server/store.ts 的mentionedBots与roomResponders：

const candidates = peers .filter((p) => !p.hidden && p.name.trim()) .sort((a, b) => b.name.length - a.name.length); // 长名优先，避免短名前缀抢先

排序是关键细节：如果花名册里同时存在Review和Reviewer，长名优先匹配，否则@Reviewer会先被Review吃掉。roomResponders再叠加三层优先级：

1. 出现独立的@everyone（同样走边界与续接判定）→ 所有可见成员；
2. 文本里点名了谁 → 只唤醒被点名者（去重后按出现顺序）；
3. 都没命中 → 按defaultResponder兜底：everyone全员、member指定主责、mentions不唤醒任何人、auto交给决策模型。

auto的实际行为在 server/index.ts 的发送路径里：只有当“无人被 @、没有 goal 协调者、房间成员多于 1”时才走自动路由，并且决策模型的回答是异步的兜底，而不是阻塞——// Auto's responders are a fallback until the decision model answers; the append and the return stay synchronous.消息先落库、接口先返回，路由结果随后补齐，否则每次发消息都要卡在模型延迟上。

渲染端则在 src/lib/group-routing.ts 复刻同一套语义，用于输入框的提示文案（groupComposerHint）、目标协调者（goalCoordinatorForComposer）与发送前预测；src/lib/mentions.ts 再负责把命中的名字转成带颜色的区间（颜色只取MAUS_COLORS白名单值，不把任意字符串塞进 CSS）。src/components/Composer.tsx 里的候选列表、Tab/Enter 选择、Escape 关闭、以及“输入法确认 Enter 不抢候选”的判断，都建立在这套共享判定之上。

三类边界值得单独说明：

• 归档与隐藏成员。被 @ 到已归档的 Bot，不会静默失败，而是在线程里追加一条活动消息：X is archived and can't respond — restore it or mention an active room member.；隐藏成员从一开始就被filter((m) => !m.hidden)排除。
• @everyone 的适用范围。它只在频道成立；在一对一 DM 里既不显示高亮也不进入候选，docs/verification/mentions.md 专门记录了这条验证路径。
• 引用与代码里的 @ 不算点名。maskQuotedAndCode会把代码围栏、行内代码、引用块和引号内的内容折叠成“只保留 @ 名字”的形式，避免文档里的示例提及被当成真实指令。

四、别让“消息流”变成“互相刷屏”：队列、持有与熔断

把工作流画成消息流，最性感的 demo 是“Bot 们互相讨论直到完成任务”，最难的生产问题是同一个：它们会互相回帖到天荒地老。仓库为此准备了三道机制。

1）频道级队列：工作期间的新消息不直接进 transcript。server/channel-queue.ts 的头注释说明了动机：

Follow-ups sent while a channel works stay off the transcript until it settles, so the current responder cannot appear to answer words it never saw.

队列本身是持久化的（saveChatFollowup/settleChatFollowups，status走pending → dispatching → settled/cancelled/interrupted），进程重启后由restoreChannelMessages()从 SQLite 恢复，因此“重启丢消息”不会发生。合批规则在headChannelGroup→drainCoalesceHead：同一发送者、间隔不超过DRAIN_COALESCE_WINDOW_MS = 120_000、最多 30 条合并成一次轮次；而带via: "api"的调用和 goal 模式永不合并（coalesceIdentity返回api:${id}/mode:…），因为它们没有“人在连续打字”的语义。

2）成员级互斥：一次只允许一个 Bot 在这个线程里说话。server/room-member-lock.ts 用一张botId → threadId的占用表封住“Bot 刚被唤醒但还没标记 busy”的窗口：

// Covers the gap before a member turn marks the bot busy: woken waiters must claim in the same synchronous step, or all read the bot as free. claim(botId, threadId): boolean { ... }

配合groupSpeakers（当前发言者）与groupTurnOperations（更宽的“正在处理”，涵盖 setup、排队中的响应者），前端拿到的是RoomQueueEntry（见 server/room-queue.ts），能看到“谁在跑、谁在第几位、在等谁”。这让“排队”变成可展示的状态，而不是一个转圈的加载图标。

3）循环熔断：把“无限自我对话”当故障处理。server/room-post-budget.ts 是这套设计的精华——它不假设 Bot 会自觉。判定顺序是：熔断冷却（5 分钟）→ 60 秒内同 Bot 同文重复 →环检测→ 单发送者 60 秒 10 条 → 5 分钟内无人回应的 Bot 帖子达 2 条就要求升级给人。环检测的写法很克制：

function closesRing(senders: string[], candidate: string): boolean { const tail = [...senders.slice(-3), candidate]; if (tail.length < 4) return false; const [first, second, third, last] = tail; return first === last && new Set([first, second, third]).size === 3; }

也就是A→B→C→A这个最小环一旦闭合，房间发帖立即关闭并设置trippedAt，返回给模型的话术明确到不留后路：Posting into this room is now closed… Do not call post_to_room again for this room — say what you wanted to post in your own reply, where the user will read it.注意Refusals are never recorded: counting them would let a blocked bot deepen its own block.——被拒绝的调用不计入预算，否则越撞墙越出不来。

五、把工作流做成消息流：产品取舍清单

这套设计并非没有代价，源码里到处是“我们选择了哪一边”的痕迹：

• 串行优先于并行。同群发言者串行；要并行必须显式开启并行房间作业（docs/verification/room-coordination.md 记录了这条边界）。串行的好处是读者永远能顺着一条时间线读懂“谁在回应什么”；坏处是长任务会排队。仓库的补偿是把排队显性化（队列位置、waitingForBotId、waitingForTeammates），而不是假装实时。
• 有界窗口优先于全量历史。30 条窗口 + 90% 压缩阈值意味着：频道可以很长，但任何单个成员看到的永远是最近的、有界的片段。这也是为什么长目标必须靠结构化协调而不是靠“大家读完整段聊天”。
• “发帖”与“干活”分离。post_to_room的说明写得很清楚：A post adds one message to the room; it does not start anyone's turn, so nobody replies to it automatically.写进频道 ≠ 触发回合。真正的回合由人的消息、@ 提及、goal 协调者或队友委派驱动。这条分离避免了“发一条状态更新引爆七个 Bot”。
• stop 是房间语义，不是单个 Bot 语义。@X stop会命中hold（server/room-holds.ts），并且在消息入队之前就应用，这样停机能追上正在干活的成员；被 hold 的成员期间收到的点名会被记入heldMessages，等resume或再次 @ 时以“你被暂停期间这些话是找你的”形式补投。stop 词的距离判定（STOP_WINDOW = 2）与对象判定（this/that/my…时不算命令）说明作者踩过“stop this task被误判为停止整个房间”的坑。
• 目标模式是有限回合制的状态机。goal模式下协调者最多 13 轮（GROUP_GOAL_MAX_TURNS = 13，注释：Odd so the final bounded turn always falls to the coordinator for the completion decision），协调者通过<openmaus-goal>控制块输出continue/completed/needs-input/blocked，控制块会从用户可见文本里剥离，避免把内部协议泄到聊天里。
• 空回复是合法回复。roomTurnReply把空串和(pass)视为“不发言”（借鉴 Hermes Agent 的桌面群聊设计，文件头有 MIT 出处说明），并配套一个ROOM_SUMMARY_REASK：如果某个回合结束时既没有最终消息也没有结论，会追问一次“用 1–3 行说结果”。

最后是“谁来管理房间”的问题。频道可以由人来建，也可以由 Chief of Staff Bot 通过工具建：server/drivers/agents-catalog.ts 里的create_room限每回合最多 4 个、只能建在自己部门、成员可选任意部门的活跃 Bot、创建者自动成为默认响应者；list_rooms则只列出“你所属的共享房间”，并在你无权发帖时给出不带 id 的名字和原因。对应的回归覆盖在 docs/verification/channels.md：重命名、改成员、改公告、拒绝外部门成员、以及“停掉拥有该代理的回合后，代理再改房间名会被拒”。

结语：聊天界面真正的价值是“可回看的协作”

把多智能体塞进聊天界面，收益不是“看起来像 Slack”，而是三件工程上可验证的事：

1. 场景与上下文解耦——频道共享指令、目录、成员与兜底路由，上下文按成员独立记账、独立压缩；
2. 路由语义单一来源——isMentionBoundary/isMentionNameContinuation让高亮、候选、服务端选人、Markdown 渲染用同一套判定，避免“亮了的没被叫到”；
3. 把失控当常态设计——队列、互斥锁、环检测、发帖预算、有限回合状态机，都是默认路径上的护栏，而不是出事后的补丁。

代价同样清楚：消息流天然是串行的、有界的、需要人回来拍板的。OpenMausBot 没有假装绕开这些限制，而是把它们做成了界面上可见的状态——谁在说、谁在等、谁被暂停、上下文压缩了多少。对多智能体产品而言，这种“诚实的可见性”比再多一个并发开关更有价值。

【免费下载链接】OpenMausBotOpen-source Grok Bot alternative with a virtual machine that bots can use项目地址: https://gitcode.com/GitHub_Trending/op/OpenMausBot