voice agent 最让人头疼的问题之一就是聊着聊着把前面说过的话忘了。给 voice agent 加一个 inner monologue内心独白让它用内部自我对话来对抗 forgetting遗忘这个思路我觉得比单纯拉长上下文更值得聊。它的核心不是“记住更多内容”而是“在每轮对话前先确认自己记住了什么”。这一下把遗忘问题从模型能力问题变成了工程状态管理问题。如果你正在做语音助手、客服机器人、具身语音对话或者任何需要多轮持续跟踪用户目标的 agent这篇内容应该有用。下面我会按实际落地顺序拆开先讲遗忘是怎么发生的再讲 inner monologue 机制到底改了什么然后给一套可以照着跑的最小实现和验证方法最后聊边界和坑。1. 先搞清楚voice agent 的“遗忘”到底是怎么发生的1.1 遗忘不是单点问题而是链路问题很多人把遗忘归结为“模型上下文不够长”。其实在语音场景里遗忘的根源往往在链路不在模型本身。一个 voice agent 的典型链路是语音识别 ASR 把用户说话变成文本对话管理模块维护状态大模型或规则引擎生成回复语音合成 TTS 把回复读出来。用户听到的是最后一段语音但实际决定“记不记得”的是中间的对话管理模块和传给模型的输入组装方式。常见的遗忘现场有三种ASR 识别把关键信息丢了。比如“周六晚上七点”被听成“周六晚上”时间约束直接消失后面所有推理都跟着偏移。多轮输入组装时只带最近两轮用户消息。早前确定的菜品、地点、预算全部不在上下文里模型想记也记不住。模型回复本身没有把已确认信息固化下来。用户后来说“还是换成靠窗座位”agent 已经忘了之前订的是六人桌。第一种是识别问题第二种是上下文组装问题第三种是状态没有沉淀。inner monologue 主要解决第二种和第三种但如果你不先排查 ASR 丢字加了独白也可能无法完全根治。我一般会先把链路拆开分别记录每一层看到的输入输出。只盯着模型层看“记不记得”很容易把账算错。1.2 为什么单纯加长上下文解决不了问题一种朴素的方案是把所有历史对话全部拼进 prompt。看起来“记住”了实际用起来问题很多。第一上下文变长之后模型对早期信息的注意力会下降。中间几轮的关键约束很容易被后面更长的闲聊冲淡。这不是说长上下文完全没用而是说你不能假设“放进去”等于“记住了”。第二语音场景对延迟更敏感。每次请求都把完整历史重发一遍首字延迟会明显上升成本也会线性增加。对话进行到第 20 轮时请求体可能已经非常大甚至超过模型输入限制。第三重复信息会制造冲突。用户在前面说过“不吃辣”后面闲聊时顺口说了句“川菜也行”如果你把原话全部塞进去模型可能分不清哪个才是当前有效约束。inner monologue 的思路是不盲目堆历史而是让 agent 每轮先压缩出一段内部状态只把状态和当前用户输入送进下一步。相当于给对话做了一个结构化记忆层。这个层可以是一个 JSON、一段短文本也可以是一条内部 prompt。关键是它比原始对话更可靠因为它经过了显式的状态更新而不是让模型从大片历史里自己找重点。2. inner monologue 机制在做什么2.1 用“内部状态”替代每轮盲猜inner monologue 这个名字听起来玄实际做起来就是把“agent 内部在想什么”变成可读取、可更新、可校验的数据。传统多轮对话里agent 的“记忆”藏在 prompt 的历史消息中模型自己决定关注什么。你没法准确知道它每轮保留了哪些信息、丢掉了哪些信息。给 agent 加内心独白之后每一轮都会生成一段内部文本或状态明确写出用户当前想要什么已经确认了哪些条件还有哪些信息没确认这轮用户消息纠正了之前的哪个判断这段独白不直接播给用户听但它决定了后续生成回复时使用的上下文。相当于在模型外面加了一个“显式工作记忆”让记忆可观测、可调试。我自己的体验是加了这层之后很多“莫名其妙忘掉约束”的问题变成了“状态更新逻辑写错了”的问题。后者容易排查得多。2.2 一个最小可运行的对话流程不需要一开始就做成复杂框架。先写一个能跑的最小循环能直观看到状态变化就行。我通常会这样拆session_state { goal: None, confirmed: [], pending: [], last_inner_monologue: } while True: user_input get_user_speech() # ASR 转文本 if not user_input: continue # 1. 用内心独白更新状态 monologue generate_inner_monologue(user_input, session_state) session_state update_state(session_state, monologue) # 2. 用更新后的状态生成回复 reply generate_reply(user_input, session_state) # 3. TTS 播放 speak(reply)这个伪代码里最关键的是generate_inner_monologue和update_state。前者让模型基于当前输入和历史状态生成一段独白文本后者把独白里的关键信息写回结构化状态。你可以先用大模型 API 跑一版 prompt 来实现这两个函数不用自己写复杂的状态机。等验证有效后再考虑把状态更新逻辑固化下来。2.3 内部状态应该包含哪些内容内部状态的字段不是越多越好多了反而容易冲突。我先列一组通用字段你可以按场景剪裁字段含义示例goal用户当前的核心目标“订周六晚 19:00 的四人位”constraints已知硬性条件“不要靠窗、预算 500 以内”confirmed已经和用户确认过的信息“六人桌已确认”pending还需要向用户确认的信息“是否需要加儿童椅”last_turn_action上一轮 agent 做了什么“推荐了三家餐厅”updated_at状态更新时间用于判断过期其中 constraints 是最容易被遗忘的字段。我建议单独拿出来每次状态更新时先对比新输入有没有推翻旧约束没有推翻就保留推翻了就替换并记录替换原因。等到需要排查时这个结构化状态会比一段长历史好用得多。你一眼就能看出“用户目标”是否还正确“待确认项”是否越积越多。3. 从能跑通到能落地模块和参数怎么设计3.1 触发条件不是每轮都要生成独白给 voice agent 加 inner monologue 最容易犯的错是让模型每轮都生成一大段“内心戏”。这样延迟和成本都很难接受而且很多轮次根本不需要重新总结。我建议把对话轮次分成三类信息变更轮用户新增、修改、撤销了某个条件。这类轮次必须更新状态并写入独白。确认轮用户回答“可以”“不行”“换一个”。这类轮次需要把确认结果写回 confirmed 或 constraints。闲聊轮用户说“今天天气不错”。这类轮次不需要更新业务状态可以直接跳过内心独白。落地时可以用一个简单分类器或规则先判断当前轮属于哪一类只有前两类才触发模型生成独白。这样既能减少调用次数又能保证状态更新集中在关键节点。我实测下来大概只有 30% 到 50% 的对话轮次需要生成独白其他轮次直接按现有状态回复就行。这里给的是一个经验范围实际比例取决于任务复杂度。3.2 记忆写入、覆盖和过期状态更新不是把新独白追加进列表就结束。真正的难点是“什么时候覆盖旧值什么时候保留旧值什么时候丢弃旧值”。我一般按四个步骤处理提取新信息从用户输入和模型独白里抽取目标、约束、确认项。做冲突检测如果新信息和旧状态冲突先别急着覆盖。要么问用户要么在独白里标注“用户可能改变了主意”。写入状态统一更新到结构化状态同时保留一条变更记录。设置过期时间如果某个约束超过 N 轮没有再次提及可以降级为“待确认”状态避免旧信息一直占优先级。这里最容易被忽视的是过期。长会话中用户之前说的“预算 300 以内”可能在第 10 轮已经被新预算替代但因为旧字段还在后续推荐仍然被旧值约束。我建议每次更新时都做一次全字段比对发现过期字段就移到历史记录而不是留在当前状态里。3.3 延迟、成本和并发的取舍加内心独白相当于每一轮多了一次模型调用而语音场景对延迟非常敏感。如果你不做取舍体验会明显变差。可以优化的方向有几个把内心独白的输入输出控制在较短长度比如限制 200 到 300 个 token 以内。独白不是写论文只保留状态变化。用并行调用。用户输入先走 ASRASR 结束后同时启动两个任务一个生成独白一个直接生成回复。如果回复不依赖独白结果可以先输出如果依赖就把独白作为前置步骤。把状态更新从大模型换成小模型或规则。等状态结构稳定之后用规则解析比每次都让大模型重写整个状态更便宜、更稳定。如果你准备支持多用户并发还要考虑状态存储。每个 session 需要独立的session_state更新时要加版本号或锁防止同一会话多个请求同时写入。这里建议先不过度设计。先用单机内存存储跑通流程再根据并发量换 Redis 或数据库。4. 怎么验证它真的不忘了4.1 单轮任务验证不要一上来就跑长对话。先拿一轮最简单的任务验证机制是否生效。比如用户说“帮我订周六晚上七点的餐厅四个人不吃辣。”你期望 agent 内部状态里出现{ goal: 订周六晚上七点的餐厅, constraints: [四人, 不吃辣], pending: [] }这时候检查三件事状态是否被正确写入约束里有没有“四人”和“不吃辣”回复是否引用了这些约束比如推荐餐厅时自动排除了川菜馆。状态结构和预期是否一致字段命名有没有混乱单轮验证成功才继续多轮。4.2 多轮状态一致性验证第二类验证是看状态在后续轮次里是否保持。我给你一个常用的测试脚本用户先给出三个约束A、B、C。下一轮用户只提到 B没有提 A 和 C。第三轮用户问“帮我推荐一下”看 agent 推荐时是否还记得 A 和 C。很多方案会在第 3 轮丢约束。加了 inner monologue 之后A 和 C 应该还在状态里模型不需要从历史原文里重新提取直接用状态即可。如果发现丢了按顺序排查第一轮结束后状态里有没有 A、B、C。第二轮生成独白时有没有把 state 作为输入传进去。第三轮组装 prompt 时用的是 state 还是又倒回去拼历史消息。这里有个容易踩的坑第二轮的独白把状态重写了一份如果重写时只基于当前用户输入没有参考旧状态A 和 C 就会丢。我在最初实现时经常犯这个错。解决办法是生成新独白时prompt 里必须同时给当前用户输入和上一轮状态并明确要求“保留所有未改变的有效信息”。4.3 长会话稳定性测试单轮和多轮验证通过后再跑长会话压力测试。长会话的重点不是看模型能不能记住而是看状态会不会越积越乱。我建议这样测连续跑 20 到 30 轮对话中间包含信息变更、确认、闲聊。每轮结束后导出结构化状态人工检查是否有重复字段、失效约束、冲突项。统计状态更新平均耗时看生成独白是否拖慢了整体响应。判断标准状态里的 confirmed 和 pending 不能无限膨胀。用户明确提出修改后旧约束不能还留在当前状态。状态更新耗时不能随着轮数线性上涨。如果上涨过快说明每次独白都在重读全部历史没有做到只处理增量。长会话最容易暴露的问题是“状态漂移”一开始状态很干净跑了几轮之后字段越加越多有的字段含义已经变了但名字还是旧的。这种问题靠测试脚本很难发现只能定期人工抽检状态内容。5. 这类方案的边界和排查经验5.1 哪些情况不要依赖内心独白inner monologue 很适用但不是万能。如果你的场景是一次性问答用户不会连续多轮修正目标加独白就是纯增加延迟。比如天气查询、查百科直接走短上下文更合适。如果你的任务状态非常复杂比如跨多天的项目管理包含大量历史变更记录单靠一句话独白也存不下全部信息。这种情况下要做分层记忆短期工作记忆用 inner monologue长期记忆进数据库或向量检索不能混在一起。还有一种情况是 ASR 错误率很高。用户说的关键信息本身就被听错了状态里存的就是错的。此时必须先做识别置信度判断低置信度时触发澄清而不是盲目把错误内容写进状态。5.2 常见问题的排查顺序如果发现加了 inner monologue 之后依然遗忘不要急着调 prompt按这个顺序查查状态是否更新成功。先把 session_state 打出来看看关键字段有没有写进去。查独白生成时是否包含旧状态。如果只给当前用户输入模型会丢掉旧约束。查 prompt 里最终给模型的是状态还是原始历史。有人辛辛苦苦维护了状态组装 prompt 时仍然把整段历史拼进去状态就没起到作用。查状态覆盖逻辑。是不是每次独白都生成一个全新对象导致旧字段被清空。查状态读取时机。多轮并发时如果同一 session 有多个请求同时读写后写的可能覆盖先写的要加版本控制。我遇到过最隐蔽的问题状态更新成功了但回复生成时用的不是更新后的状态而是从缓存里读的旧状态。排查时先看日志里每轮的 state 值再看回复 prompt 里实际传入的 state比对两个版本很快就能定位。5.3 把方案落地时我会怎么做最后整理一下我自己的落地顺序供你参考。第一步先跑最小闭环ASR 转文本、状态更新、回复生成、TTS。不要一开始就接复杂业务系统。第二步把 session_state 设计成可序列化结构最低要求是 JSON。这样测试、调试、排查都方便。第三步写一个带 trace 的日志每轮记录用户输入、生成的独白、更新后的状态、最终回复。之后所有“怎么又忘了”的问题都能靠日志还原。第四步把对话轮次分类只有关键轮次触发独白减少延迟。第五步稳定后再考虑状态库、并发、小模型替代等优化。这个方案真正落地时最该盯住的不是“模型有多聪明”而是状态读写是否一致、冲突处理是否正确、过期清理是否及时。很多遗忘问题最后查出来都不是模型能力不够而是中间状态管理乱了。先跑稳单任务再考虑批量用户和复杂场景是我个人比较推荐的路子。