让豆包参加圆桌，她为啥总抢话？

你有没有遇到过这样的情况：你对一个语音助手说“先听我们讨论，等我叫你的时候再发表意见”，结果它没听几分钟就忍不住插话了？或者讨论进行到一半，它突然“忘了”前面的关键内容？

昨天活动上，圆桌环节，就拉了豆包进去，过程中就总是抢话，即使你多次嘱咐让她过程中别说话，依然该插话还插话🤣

很多人第一反应是“模型指令遵循能力不行”。但在实时语音/多模态会话（Live API）场景里，问题往往出在更底层——上下文窗口、会话时长、token 消耗速度，以及 Agent 客户端的实现逻辑。这篇文章把我们之前的讨论整理成一篇技术科普，帮你看清这些限制是怎么产生的，以及为什么“先听后说”这种看似简单的需求，其实需要在客户端做不少预处理。

01🍀 一、实时会话的“工作记忆”是怎么算的

普通聊天 API（Chat Completions）是无状态的：每次请求你都要把完整历史塞进去，模型只看你这次发的内容。而 Live API（如 Google Gemini Live、OpenAI Realtime / GPT-Live）是有状态的长连接：音频、文字、图像持续流式输入，模型在同一个会话里持续“听”和“说”。

这个“持续听”的能力受一个硬约束限制：上下文窗口（Context Window）。

• 它以 Token 为单位计算（不是字符数）。系统提示、历史对话、工具定义、音频/视频流、模型自己的输出，全部计入。
• 典型限制：Gemini Live 会话上下文约 128k tokens；部分 OpenAI Realtime 模型窗口更小（例如 32k 左右，还要预留输出空间）。
• 音频流特别“烧”token：Gemini 官方数据大约是每秒 25 个音频 token，视频更高。几十分钟的连续倾听，很容易把窗口填满。

一旦接近或超过上限，系统不会无限记住，而是采取截断或压缩策略。常见做法包括：

• 滑动窗口：丢弃最老的对话轮次，保留系统指令和最近内容。
• 自动截断：超过阈值后从开头丢消息（OpenAI Realtime 可配置为 auto 或 disabled）。
• 上下文压缩 / 摘要：把旧内容总结成更短的摘要，再替换原文（Gemini 的 contextWindowCompression、Claude 的 compaction 等都是这个思路）。

此外还有会话时长和连接时长限制。无压缩时，纯音频会话可能只有十几分钟，音视频更短；连接本身也可能在约 10 分钟后重置。这些不是模型“记性差”，而是工程上的硬边界。

02🍀 二、“先听我们说，等我叫你再发言”——为什么容易翻车

回到开头那个指令：“小贝，你先听我们说，之后我叫你发言的时候，再根据我们的话题发表意见。”

这是一个典型的长时倾听 + 延迟发言需求。模型本身通常能理解这句话，但在 Live 会话里会碰到多层约束：

1. Token 积累速度：持续听的音频/转写会快速消耗窗口，触发自动截断或压缩，早期讨论可能被丢掉。
2. 默认行为倾向：很多实现默认“有输入就生成回复”。没有明确的“静默监听”状态时，模型容易把持续说话误判成需要回应的轮次。
3. 会话生命周期：时长一长，连接重置或强制压缩就可能打断连续性。
4. 上下文质量衰减：即使没超限，极长上下文也可能让模型“注意力分散”（业界常说的 context rot），指令遵循变差。

结果就是：Agent 要么提前插话，要么到真正被点名发言时，已经“忘了”前面的关键内容。这不一定是模型指令遵循能力本身的问题，更多是实现层没有处理好时长、token 预算和状态管理。

03🍀 三、客户端必须做的预处理

要把“先听后说”做得可靠，核心工作得放在 Agent 客户端（或中间层），而不能完全指望模型自己“忍住”。

比较有效的做法包括：

• 状态机管理
  明确划分状态：Listening（只听不说）→ Triggered（收到“小贝你发言”等触发信号）→ Speaking。在 Listening 状态下，持续接收并存储输入，但不触发模型生成回复，或者只做轻量内部处理。

• 外部存储 + 按需组装
  把原始转写持续存到外部（数据库、向量库或内存）。定期用便宜模型或规则做摘要、提取关键点。真正需要发言时，再把“当前话题摘要 + 最近几轮原文 + 系统指令”重新组装成一个相对干净的 prompt 发给模型。这样既避免触达硬截断，又保留长期记忆。

• 善用平台提供的压缩与续接机制
  开启滑动窗口压缩；配合 session resumption 处理连接重置；合理设置 truncation 策略，减少频繁截断对缓存的影响。

• 降低持续输入的压力
  优先用高质量 ASR 转写而不是直接喂原始音频；做说话人分离和内容过滤；设置静默期检测，避免无效 token 积累。

• 系统提示与工具配合
  在系统提示里明确当前状态和触发条件；必要时提供“等待触发”类工具，让模型在未到发言时机时调用工具而不输出文本。

这些预处理做扎实后，模型的指令遵循能力才能真正发挥出来。否则再强的模型也会被会话限制和默认的“有输入就回复”逻辑拖累。

04🍀 四、写在最后

实时 AI 会话把“持续记忆”和“低延迟交互”结合在一起，但也引入了普通聊天 API 没有的约束：token 消耗速度、会话时长、自动截断/压缩策略、以及客户端如何管理状态。

“先听后说、等被点名再发言”这类需求，表面是模型能力问题，实质往往是工程实现问题。理解这些限制，把状态管理、外部记忆和按需组装放在客户端，是做出可靠长时倾听 Agent 的关键。

随着上下文窗口继续变大、压缩技术更成熟，这类场景会越来越顺畅。但在当前阶段，好的 Agent 体验，一半靠模型，一半靠客户端把边界管清楚。