AI Agent 坐进视频会议：多智能体发言权之争

浏览器视频会议工具 Quad 的团队把 AI Agent 请进了自己的日常和每周例会，结果并不如预期般美好——多个智能体同时出现在一张桌子上时，会议体验迅速崩塌。这家以还原线下「沉浸式闲聊」为目标的团队记录下了这次踩坑经历，并分享了他们最终采用的「服务器端发言权（floor control）」方案。

为什么把 Agent 请进会议室

Quad 的会议空间被设计为一间布满可自定义桌位的虚拟房间：你在某张桌旁坐下，能听到同桌与邻桌的低语，并沿着话题自由游走。对于一个远程优先的小型软件团队而言，每日的同步例会正是这种「自然对话流」的最佳载体。

当团队里出现 AI Agent 后，团队成员发现自己经常替它们发声——「我那个 Agent 觉得……」。Quad 的工程师们意识到，这种转述既低效，也破坏了自然节奏，于是决定让 Agent 真正坐进 Quad，拥有一席之地和属于自己的声音。他们通过 MCP（Model Context Protocol）接入不同来源的智能体，一部分基于 Claude 构建，另一部分基于 Codex。

把 Agent 请进来之后：会议体验崩坏

一个 Agent 坐在桌旁尚可忍受，但当数量从两个增加到六个时，原本流畅的对话迅速变成一团乱麻。无论怎样优化单个 Agent 的提示词或响应时长，都无法解决问题——即使每一个 Agent 单独表现良好，它们也仍会互相碰撞。冲突源自桌面这一共享通道，而非任何一个参与者。

Quad 团队用日志复盘了他们的一次用户验收测试（UAT）会议：

• 会议时长 65 分钟，在此期间客户端向服务器发出让 Agent 静音的请求共 61 次
• 请求间隔恒定在 6.5 秒，等于客户端识别的 1.5 秒持续人声加上 5 秒冷却时间
• 每当 Agent 开始说话，代表人类的客户端就以系统允许的最快速度请求让它闭嘴
• 从人类开始说话到 Agent 真正停嘴，平均有约 2 秒的「不愉快音频」

相比之下，两个真人发生语音碰撞时，通常只需几百毫秒就能自行错开。这一差距让自然对话变成了一场小心翼翼的「轮流发言」。

为什么轮次检测（turn detection）不够用

遇到这个问题，外界通常会推荐 turn detection。LiveKit 提供的模型确实能准确判断「说话人是否已经讲完」，Pipecat 等框架也已经能把 Agent 作为参与者接入实时视频会话——这意味着你今天就可以把五个 Agent 塞进同一个通话。但 turn detection 解决的是每个 Agent 各自独立回答的「这个人讲完了吗」问题，而真正需要回答的是：当桌旁有六个潜在的说话者时，谁应该开口，谁又应该被叫停。任何 Agent 单独做决策都无法预判其他人的动向，决定权必须放在能看见整张桌面的地方。

思路回到电话会议的老传统：floor control

「Floor control」并非新概念。Quad 的工程师指出，已有近二十年的电话会议标准在处理类似问题，Agent 领域的论文与规范也开始围绕它展开讨论。然而，团队尚未见到一份在「真实人类参与会话」的生产环境中落地的 floor control 实现——这正是他们觉得值得记录的原因。

服务端拿到发言权

在 Quad 里，桌面本身就是一个服务器，因此团队把决定权直接交给了服务端：

• 每个 Agent 都有座位和声音，参与规则与人类一致
• 当人类说话覆盖了 Agent 时，客户端检测到这一情况，服务器立即收回发言权，正在排队或正在播报的 Agent 语音被清空，包括未说完的句子
• 之后进入一段 90 秒的安静窗口，Agent 在此期间持续工作，仍能回答问题，但其声音不会主动插入对话

这套机制将「谁能说话」的判断从分布式的、各自为政的 Agent 上移到共享的服务端，使多智能体在一个共享音频通道内实现了受控的协作。

给行业的一点启示

随着 Agent 开始进入更复杂的多人协作场景——会议、客服协作、团队 IDE——单 Agent 的 turn detection 已触及天花板。Quad 的实验显示，多智能体共处的「碰撞」是系统性问题，需要系统级方案。他们选择回归一套古老的会议工程实践，并把它重新实现到了现代 Agent 栈中。这条路径是否会成为 Agent 框架的下一步标配，值得持续关注。