前端智能体开发（四）：智能体产品实战：从问题到可信答案的完整回合

智能体产品完整回路

这张图把一个智能体产品画成完整回路：用户输入进入系统后，先被改写成可处理问题，再用 RAG 补充事实，随后结合记忆和人设组织回答，最后用语音、插图、听书等方式完成体验。真正能落地的智能体产品，拼的不是单次回答有多漂亮，而是每个回合都能稳定地理解、检索、推理、表达和恢复。

一、智能体产品不是模型 Demo

模型 Demo 通常只展示一次能力：输入一句话，输出一段内容。产品要面对的情况复杂得多。

用户可能表达不清，可能中途修改问题，可能上传不合规文件，可能网络断开，可能重复进入同一会话。模型也可能回答不稳定、事实不准、格式不符合预期。产品要做的不是假设一切顺利，而是给这些不确定性建立处理流程。

一个智能体产品至少包含六个环节：

输入理解：把用户表达变成可处理意图。
上下文补充：找到事实、历史、偏好和业务规则。
推理生成：让模型根据目标产出结果。
结果校验：检查格式、事实、长度、风险。
多模态表达：文本、语音、图片、交互控件。
状态恢复：保存进度、支持重试、避免重复执行。

如果少了前两个环节，模型容易误解问题；少了中间两个环节，结果不可控；少了后两个环节，体验像一次性玩具。

二、第一步：把模糊问题改写成可行动问题

很多智能体失败，不是模型回答能力差，而是输入太模糊。尤其在儿童、教育、面试、客服等场景里，用户经常只给一个词或半句话。

例如孩子问“火焰”。这个输入可能代表很多问题：

火焰为什么会发光？
火焰的温度有多高？
火焰为什么有不同颜色？
火是怎么产生的？

如果直接把“火焰”交给生成节点，答案可能泛泛而谈。更好的做法是先用一个问题改写节点，把模糊输入变成候选问题和搜索词。

{
  "questions": [
    {
      "question": "火焰为什么会有不同的颜色？",
      "query": ["火焰 颜色 原因", "火焰 温度 颜色"]
    },
    {
      "question": "火焰是如何产生的？",
      "query": ["燃烧 条件", "火焰 形成 原理"]
    }
  ]
}

这里的重点不是让模型“多想一点”，而是为后续检索和回答建立明确方向。一个好的改写节点要具备三种判断：

输入已经足够具体时，不要过度改写。
输入过短时，给出多个合理候选。
输入有风险或不适合回答时，进入安全处理。

在产品上，可以把候选问题展示给用户选择，也可以在后台自动选择置信度最高的一项。

三、第二步：用 RAG 降低幻觉风险

科普、面试评价、知识问答和企业助手都不能只依赖模型记忆。模型可能把过期信息、相似概念和推测混在一起。RAG 的价值，是把外部事实放进回答上下文，让模型围绕可信材料组织语言。

最简单的 RAG 可以从搜索 API 开始：

用改写节点生成 query。
调用搜索服务。
抽取摘要、标题、链接和正文片段。
把检索结果整理成上下文。
要求模型只基于上下文回答，并在不确定时说明。

type SearchContext = {
  query: string;
  results: Array<{
    title: string;
    snippet: string;
    url: string;
  }>;
};

企业场景则常用向量检索。把文档、代码、FAQ 或知识库切块，计算 embedding，写入向量数据库。用户提问时，先找相似片段，再交给模型回答。

搜索 API 和向量检索各有边界：

搜索 API 适合公共知识和实时信息。
向量库适合私有文档、代码库和固定知识。
超长上下文适合材料不多但希望一次性读完整内容。
文件系统读取适合结构清晰的项目资料。

不管选哪一种，都要记住：RAG 不是把一堆文本塞给模型，而是选择与问题最相关、质量最高、数量可控的材料。

四、儿童学伴：低龄用户需要更多产品保护

面向儿童的智能体尤其需要谨慎。孩子的问题可能不完整，表达可能来自语音识别，认知水平也与成人不同。因此产品要在四个方面做保护。

第一，语言保护。回答要短句、具体、形象，不要堆抽象概念。例如解释“天空为什么是蓝色”，可以用“空气里的小颗粒更容易把蓝色光散开”这样的表达，再配图说明。

第二，事实保护。科普场景不能随意编造。涉及科学事实时，尽量用检索上下文补充。

第三，情绪保护。孩子问“为什么我不聪明”这类问题时，回答要先接住情绪，再引导积极解释。

第四，交互保护。语音输入可能识别错，系统要允许确认问题；长答案要分段；插图和听书要服务理解，而不是只做装饰。

一个儿童学伴的核心流程可以是：

type DiscoveryFlow = {
  rawInput: string;
  rewrittenQuestions: Array<{ question: string; query: string[] }>;
  selectedQuestion: string;
  references: SearchContext[];
  outline: Array<{ title: string; goal: string }>;
  sections: Array<{ title: string; content: string; imagePrompt: string }>;
  audioScript: string;
};

这份结构让产品有清晰状态：用户问了什么、系统改写成什么、参考了什么、生成了哪些段落、图片和听书内容在哪里。

五、AI 面试官：记忆和时间线比单次回答更重要

AI 面试官不是问答机器人。它需要像一个真实面试官一样，知道当前处于哪个阶段，记得候选人之前说过什么，根据回答决定追问方向。

一个前端面试流程可以分成：

破冰与背景确认。
基础问题。
项目经历深挖。
编程或设计题。
反问与总结。
评估报告。

如果没有时间线，模型可能重复问同类问题；如果没有记忆，模型无法根据候选人的回答追问；如果没有人设，语气和难度会漂移。

可以把面试状态设计成：

type InterviewState = {
  stage: "intro" | "basic" | "project" | "coding" | "summary";
  persona: {
    role: "frontend_interviewer";
    strictness: "medium";
    style: "encouraging";
  };
  timeline: Array<{
    speaker: "ai" | "candidate";
    content: string;
    tags: string[];
  }>;
  memory: {
    strengths: string[];
    risks: string[];
    pendingQuestions: string[];
  };
};

这里有一个重要设计：读写分离。面试中的实时对话可以快速写入 timeline；长期记忆和评估摘要可以异步更新。这样前端不必等待所有分析完成，用户体验更顺。

六、多轮对话要避免“上下文泥潭”

多轮智能体很容易把所有历史消息都塞回模型。这样会带来三个问题：token 成本高、噪声增加、旧信息干扰新判断。

更好的做法是分层记忆：

短期上下文：最近几轮完整对话。
阶段摘要：当前阶段的结论。
长期记忆：用户偏好、关键事实、已确认信息。
检索材料：与当前问题相关的外部资料。

每次调用模型时，只取当前任务需要的部分。

例如面试官追问项目经历时，不需要带入全部基础题回答，只需要带入“候选人做过 Vue 性能优化，提到虚拟列表和缓存策略”这样的摘要。

七、语音、插图和听书不是附加项

多模态功能经常被当作“锦上添花”，但在很多产品里，它们直接决定可用性。

儿童学伴里，语音输入能降低输入门槛；插图能帮助理解抽象概念；听书能让孩子在屏幕外继续使用。AI 面试官里，语音输入能接近真实面试；时间线和记录恢复能避免刷新后丢失状态。

实现多模态时要注意：

语音输入要处理权限、录音状态、识别失败、空结果。
插图生成要有安全过滤和风格约束。
听书文本要口语化，不能直接把书面答案送去 TTS。
音频播放要考虑移动端限制和加载失败。
所有多模态任务都应有任务 ID，方便恢复和重试。

一个实用的做法是把多模态都视为异步任务：

type MediaTask = {
  id: string;
  type: "stt" | "image" | "tts";
  input: string;
  status: "pending" | "running" | "done" | "failed";
  result?: string;
  error?: string;
};

这样 UI 和后端可以共用同一套状态模型。

八、产品容错：刷新、跳过、恢复、重试

智能体产品必须允许用户从异常中恢复。

儿童学伴里，图片生成失败不能影响文本阅读；语音识别错了要能重新录；参考资料没找到，要提示“需要换个问法”。

AI 面试官里，用户刷新页面后应该恢复面试记录；某个阶段卡住时，应该能跳过当前问题；候选人回答太短，系统可以追问，但不能无限追问。

容错设计可以按优先级处理：

核心文本结果必须可用。
图片、音频、动画可以降级。
失败任务可以单独重试。
关键状态要持久化。
用户永远能退出当前回合。

这比追求模型“一次完美回答”更实际。

九、一个面向真实产品的验收清单

做智能体产品时，可以用下面清单检查成熟度：

用户输入模糊时，有没有改写或澄清机制？
需要事实准确时，有没有检索或知识库上下文？
多轮对话是否有阶段、记忆和摘要？
输出是否能被前端结构化展示？
语音、图片、音频任务是否可恢复？
每个模型调用是否有日志和成本记录？
用户刷新或取消时，系统是否保持一致？
失败是否能局部重试，而不是全流程重来？

如果这些问题都没有答案，智能体只是一个模型 Demo；如果这些问题都有设计，智能体才开始接近产品。

十、可信答案来自完整回合

智能体产品的核心不是“模型知道多少”，而是系统如何组织一个完整回合：理解问题、补充事实、结合记忆、生成结果、用合适媒介表达、失败后恢复。

一次可信回答不是生成瞬间才开始，而是从输入理解、事实补充、记忆调用、回答组织、媒介表达到失败恢复的完整过程。用户看到的是答案，工程师要设计的是整个回合。