AI大模型工具的「无限追问」如何实现的?(2/3)

上篇我们讲了底层原理：大模型无状态，靠拼接历史 + 管理上下文窗口来实现"记忆"。这一篇，我们从产品工程的角度，看看"无限追问"在具体产品里是怎么落地的。

一个标准对话系统的"后台剧本"

当你和 AI 工具聊天时，后台其实在演一场精密的剧本：

用户发消息
  ↓
【对话历史管理模块】从数据库取出本 Session 的所有历史
  ↓
【动态上下文组装器】组装最终发给模型的消息列表：
  - 系统指令（System Prompt）——常驻，优先级最高
  - 压缩后的早期历史摘要（如果有）
  - 最近 N 轮原始对话
  - 用户当前消息
  ↓
调用大模型 API
  ↓
【智能摘要生成引擎】判断总 Token 是否接近窗口 70%-80%
  是 → 触发摘要，压缩最旧的历史块
  否 → 直接存储
  ↓
返回回答给前端
  ↓
【追问建议生成器】异步调用 recommend-prompt 接口
  ↓
前端渲染回答 + 3 条追问建议

这个剧本里，每一个模块都是为了让"无限追问"既流畅又不失控。

🔍 案例拆解：Kimi vs 智谱的"追问建议"

Kimi：基于"最后一段回复"

Kimi 在回答完成后，会调用 recommend-prompt 接口，传入 chat_id（对话窗口 ID）和 group_id（本轮回复 ID）。服务端拿到本轮回复内容，基于内置的"问题建议 Prompt"生成 3 条建议。

它的核心 Prompt 类似：

"请根据我提供的信息，通过上下文来猜测用户可能进一步追问的 3 个相关问题，通过序号形式列出。问题表述应与上下文内容紧密相关，保证每个问题不超过 30 个字。"

为什么 Kimi 选择只看最后一段？

1. 节省 Token：不用把整个历史发给模型推理
2. 适配多主题：很多用户在一个窗口里聊完全不同的话题（先聊 AI，再聊奥运，再聊娱乐圈），基于最后一段生成更合理

智谱：基于"整个对话历史"

智谱调用 recommendation/list 接口，只用 conversation_id 一个参数。它会读取整个 history 进行归纳。

实测发现：当你跨界问"金鸡奖获奖后演员们干什么"，智谱返回的追问建议竟是"隐私泄露怎么防范？数据偏见如何消除？责任归属怎么界定？"——回到了前面聊 AI 伦理时的主题。

这说明智谱的追问生成考虑了整轮对话的上下文关联，而不仅是最后一段。

两种策略的取舍

💡 没有绝对优劣。Kimi 的策略更适合"一个窗口聊多件事"的中国用户习惯；智谱的策略更适合"深度探讨一个话题"的场景。

🛠️ 自己动手：构建一个"追问建议"功能

如果你想给自己做的 AI 应用加上"无限追问"体验，核心就是在回答后追加一次模型调用。伪代码如下：

defgenerate_followup_suggestions(chat_history, last_response):
    prompt = f"""
    【输出格式】
    ## 相关问题推荐

    【注意】
    请根据我每次跟你聊天的最后一条记录，通过上下文来猜测
    用户可能进一步追问的 3 个相关问题，通过序号形式列出，
    并保证每个问题不超过 20 个字。

    对话历史：{chat_history}
    最后回复：{last_response}
    """
    suggestions = llm.invoke(prompt)
return parse_json(suggestions)

进阶技巧：

1. 控制长度：每个建议不超过 20-30 字，避免用户选择困难
2. 避免重复：提示词里明确"不要与前文已经提问或回答过的内容重复"
3. 角色匹配：建议问题应匹配用户在对话中的角色和对话类型
4. 异步调用：追问建议在后台异步生成，不阻塞主回答的展示

🔄 当追问变成"智能体"：递归追问与工具调用

普通的"追问建议"只是产品体验优化。但当 AI 变成 Agent（智能体），追问就升级成了自主的多步推理循环。

以检索增强场景为例，一个研究型 Agent 的工作流是这样的：

纯文本
纯文本
1. 检索文档（retrieve_documents）
2. 评估相关性（evaluate_relevance）
   - 如果"充分" → 输出最终答案
   - 如果"不充分" → 改写查询（reformulate_query）→ 回到第 1 步
3. 最多循环 3 次（max_iterations=3）

这个 max_iterations=3 是关键——生产环境必须设置最大迭代次数，防止模糊查询让 Agent 陷入无限循环。

更先进的递归语言模型（RLM）走得更远：当文档大到塞不进上下文窗口时，根模型不直接读文档，而是写代码去切片、检索、委派子模型分析特定段落，中间结果存在 Python 变量里，不占上下文窗口。

💡 亚马逊 Bedrock 的实践显示：处理跨越数百万字符的文档时，必须把"文档大小"与"模型上下文窗口"解耦。RLM 让根模型专注编排，子模型专注语义分析，中间变量留在沙箱里。

⚠️ "无限追问"的三个隐藏陷阱

陷阱一：上下文腐烂（Context Rot）

对话越长，早期信息越容易被"压"在中间区域被忽略。一个在第 3 轮确认过的事实，到第 40 轮可能被模型遗忘。

对策：关键事实在每轮显式重申，或用摘要压缩保留核心节点。

陷阱二：成本爆炸

每轮都把全量历史发给模型，Token 消耗线性增长。第 100 轮对话可能消耗 4 万 Token，单轮成本飙升。

对策：摘要压缩 + 滑动窗口 + 外部记忆（RAG）。

陷阱三：无限循环

Agent 在工具调用时可能陷入"检索→不充分→改写→再检索"的死循环。

对策：设置 max_iterations 硬性上限，到达后强制输出当前最佳答案。

🎯 本篇核心要点

1. "无限追问"在产品层是多模块协作的结果：历史管理、上下文组装、摘要压缩、建议生成
2. Kimi 和智谱走了不同路线：末段优先 vs 全局历史，适配不同用户习惯
3. 真正的"智能体追问"是带最大迭代次数的递归循环
4. 三个陷阱必须防范：上下文腐烂、成本爆炸、无限循环

下一篇预告：了解了原理和产品实现，最关键的是——作为普通用户，我们如何善用"无限追问"让 AI 变成超级助手？ 下一篇给你一套可直接套用的"追问心法"，让每一次追问都更接近你想要的答案。