多智能体协作 · RAG 幻觉 · 记忆存储

概念解释 → 涉及的场景 → 解决方案 ｜ 整理于 2026-10-27

目录

1. 多智能体协作
2. RAG 幻觉
3. 记忆存储
4. 三者关系与场景对照
5. 落地顺序建议

---

一、多智能体协作

1.1 是什么

多智能体（Multi-Agent）指把一个大任务拆给多个 LLM 实例分工完成，每个实例有自己的角色、工具、上下文和职责，它们通过消息/共享状态协作。

要区分两个容易混的概念：

• 单 Agent + 多工具：一个模型，多个 function call。本质还是「一个大脑」。
• 多 Agent：多个模型实例，各自独立推理，有编排层协调。本质是「一个团队」。

核心价值只有四条：上下文隔离 工具权限隔离 并行 独立审查。拿不到这四条中的任何一条，多智能体就是纯负担。

1.2 哪些场景涉及

场景	为什么需要多智能体
深度研究/调研报告	需要并行搜多个方向，再汇总；单上下文放不下所有资料
代码生成流水线	写代码 / 写测试 / review 需要不同视角，生成者不该自评
客服工单处理	分类 → 查订单（只读）→ 审批退款（写，需权限）→ 回复，职责边界清楚
数据分析	取数（有 DB 权限）、分析、写报告，权限和上下文都不同
内容生产	策划 → 撰写 → 事实核查 → 润色，每步可独立重跑
企业流程自动化	跨系统操作，每个系统单独授权，失败要能局部重试
模拟/博弈	多个角色互动（谈判、游戏、社会模拟）

不需要多智能体的场景：问答、单轮生成、简单工具调用、流程完全固定且短。这些用单 Agent 或纯代码编排更快更稳。

1.3 怎么解决（设计要点）

第一步：先判断能不能不用

1. 一个 context window 装得下吗？装得下就不拆。
2. 需要并行吗？不需要就不拆。
3. 需要权限隔离或独立审核吗？不需要就不拆。

三个都「否」→ 用单 Agent + 工具 + 代码编排。

第二步：选拓扑

模式	结构	适用	风险
Orchestrator–Worker（默认）	supervisor 拆任务、派发、汇总	绝大多数场景	supervisor 成瓶颈/单点
Pipeline / 固定流程	代码写死 A→B→C	流程确定	不灵活，但最可控
Hierarchical	多层 supervisor	任务层级深	调试难、成本高
Debate / Reflection	多角色互评、投票	高风险决策、写作润色	成本 2–5 倍，易互相附和
Swarm / Handoff	Agent 自主转交	探索型、开放对话	不可预测、难复现，生产慎用

关键认知：能用代码编排的地方不要用 Agent 自主决策。确定性流程用 Pipeline，只有「下一步该做什么不确定」时才交给 LLM 路由。

第三步：定通信契约

Agent 之间传结构化对象，不传自然语言闲聊：

class TaskResult(TypedDict):
    task_id: str
    status: Literal["ok", "failed", "need_info"]
    output: dict
    evidence: list[str]
    confidence: float

理由：可校验、可短路、可落库、可单测。自然语言消息下游解析不稳。

第四步：状态与终止

• 显式共享 state（StateGraph / workflow state），只读写约定字段，不要拿对话历史当状态。
• 必须 checkpoint：可断点恢复、可回放。
• 硬性终止：max_turns、max_tokens、max_cost、schema 校验通过、循环检测（相同 state 哈希重复即中断）。

第五步：隔离与权限

• 每个 worker 只给必要上下文 + 最小工具集。
• 写操作（付款、发邮件、改库）必须带 request_id 幂等 + 人工/verifier 审批。

第六步：可观测

每条 trace 记 agent 名、输入摘要、输出、工具调用、token、耗时、失败原因。没 trace 的多智能体线上无法定位。

常见坑

• 自由对话协商 → 不可复现、成本失控
• 过度拆分 → 延迟翻倍、错误叠加
• 无 verifier，生成者自评 → 错误无人拦
• supervisor 输出非法 JSON 导致全链崩 → 必须 schema 校验 + 重试/兜底
• 无限反思循环 → 必须给轮次上限

---

二、RAG 幻觉

2.1 是什么

RAG（检索增强生成）= 先从知识库检索相关片段，再让模型基于这些片段回答。

RAG 幻觉指模型给出的答案与检索到的证据不符，或根本没有证据却编造。注意：RAG 不是「反幻觉」的银弹，它只是把「模型凭记忆编」换成「模型可能误用材料」，幻觉换了形态而非消失。

2.2 哪几类幻觉（先分类，才能对症）

类型	表现	根因层
检索未召回	需要的证据没进 context	检索
召回被忽略	证据在，模型没用	排序/prompt/上下文过长
召回被曲解	用了但理解错、张冠李戴	模型能力/证据歧义
先验覆盖	训练知识压过材料	prompt 约束弱
无答案硬编	库里没有，模型编	缺拒答机制

2.3 哪些场景涉及

场景	典型幻觉风险
企业知识库问答	制度条款编号、金额、日期被编造
客服/售后	承诺不存在的政策、赔付标准
医疗/法律/金融问答	引用不存在的条款、指南，后果严重
文档助手（合同、财报）	数字张冠李戴、章节错配
代码库问答	编造不存在的 API、函数签名
电商导购	编造参数、库存、价格
学术/新闻摘要	编造引用、作者、结论

共同点：答案需要「可追溯到来源」，且错了有实际代价。纯创意写作不需要 RAG，也就不存在这类问题。

2.4 怎么解决（分层治理）

层 1：检索（收益最大，先做）

• 混合检索：BM25 + 向量，RRF 融合。纯向量在编号/人名/术语上常输。
• Query 改写：多 query 扩展、HyDE、指代消解。
• Rerank：召回 top-50 → cross-encoder 精排 top-5。性价比最高的一步。
• 分块：语义分块；父子块（小块检索、大块喂模型）。
• Metadata 过滤：时间、权限、文档类型。
• 多路召回去重：按来源可信度加权。

层 2：上下文

• 去冗余、压缩、控制总量（宁少而精）。
• 最相关放开头和结尾（中间易被忽略）。
• 给片段编号 [1][2]，为引用做准备。

层 3：生成

• 强制引用：每个事实陈述必须带 [doc_id]，无引用不许说。
• 先抽证据再作答（extract-then-generate）：先列支持结论的原文句子，再组织答案。显著降幻觉。
• 允许说不知道：明确拒答模板 + few-shot 拒答示例。
• 结构化输出：{answer, citations[], confidence, insufficient_evidence}，便于程序拦截。
• 低温度（0–0.2），但别指望温度解决事实性。

层 4：后校验（第二道闸）

• Claim-level 校验：答案拆成原子断言，逐条用 NLI 判断是否被引用片段支持，不支持就删。
• 引用对齐：检查引用的文档是否真含该说法。
• 置信度阈值：低于阈值降级为「未找到可靠答案」。
• 这层可以做成独立 verifier（正好用上多智能体的「生成者≠校验者」）。

层 5：评估与监控（必须最先建）

• 离线：RAGAS 的 faithfulness、answer relevancy、context precision/recall + 几十条人工标注集。
• 在线：抽样人工审、点踩率、引用点击率、拒答率突变告警。
• 没有评估集就无法优化 RAG，这是第一步。

判断口诀

检索不到 → 改检索；检索到没用 → 改排序/prompt/上下文；用了但错 → 加校验/换模型；没有答案 → 加拒答。四类问题四套药，别混调。

---

三、记忆存储

3.1 是什么

记忆 = Agent 能跨会话保留并演化的信息：用户偏好、历史事件、任务状态、学到的规则。

和 RAG 的区别：

	RAG	记忆
读写	只读知识库	读 + 写，持续演化
内容	公共/领域文档	用户偏好、历史交互、任务状态
时效	相对静态	强时间性，会过期、会冲突
隔离	全局共享	必须按用户/租户隔离

记忆的本质是「会写、会忘、会冲突的个性化知识库」。直接套 RAG 会踩坑（无写入去重、无冲突处理、无遗忘）。

3.2 哪些场景涉及

场景	需要记住什么
个人助理	偏好、日程、称呼、长期目标
客服/CRM	历史工单、客户画像、上次承诺
编程助手	项目约定、架构决策、踩过的坑
教育/陪伴	学习进度、薄弱点、性格偏好
游戏 NPC	与玩家的交互历史、关系值
长流程 Agent	任务中间状态、已完成步骤（断点续跑）
多轮复杂对话	早期提到的约束、已确认的决定

不需要记忆的场景：无状态问答、单次请求、隐私要求极高且不允许留存。

3.3 怎么解决（设计要点）

第一步：先别搞复杂，最小可用版

对话摘要 + 用户 profile 表 + 历史向量检索，这三样能覆盖 80% 需求。知识图谱只有明确需要多跳关系推理时才上。

第二步：分层

• 工作记忆：当前对话窗口，天然存在，不用额外存。
• 情景记忆：发生过什么（「上周让我改成蓝色主题」），带时间戳。
• 语义记忆：抽取的事实/偏好（「用户是后端工程师」）。
• 程序记忆：稳定规则/流程，直接进 system prompt，不需检索。

第三步：写入策略（最易被忽视）

• 何时写：显式工具调用（模型主动 save_memory）比全自动抽取可控；也可每 N 轮/会话结束做摘要抽取。
• 写什么：结构化，别存整段对话：

{"type":"preference","key":"theme","value":"dark","source":"turn_12",
 "confidence":0.9,"created_at":"...","updated_at":"..."}

• 去重：写前 embedding 相似度查重，超阈值合并/更新。
• 冲突：同 key 不同值 → 保留最新并标 superseded_by，或让模型裁决；永远留来源和时间。
• 幂等：同一事件重复写入要能去重（事件 id）。

第四步：检索

• 混合打分：score = α·relevance + β·recency + γ·importance（recency 用指数衰减）。
• 多路：向量 + 关键词 + 结构化过滤（user_id、type、时间）。
• 强制按用户/租户过滤，绝不跨用户召回。
• 只取 top-k 小片段注入，别把整个记忆库塞进 context。

第五步：遗忘（必须设计）

• TTL/时间衰减：临时偏好、短期状态自动过期。
• 容量上限：每用户最多 N 条，超了按「重要性 × 最近使用」淘汰。
• 重要性评分：写入时让模型打分或按类型定权。
• 隐私删除：能彻底删（原文+向量+摘要+图谱边），设计时就要考虑，不能事后补。

第六步：存储选型（务实版）

• 短期/会话态：Redis（带 TTL）
• 长期结构化 + 向量：Postgres + pgvector（先一把梭）
• 大规模向量：专用向量库（Milvus/Qdrant）
• 多跳关系：图数据库（有明确需求才上）
• 原文：对象存储，向量里只存 id + 摘要

第七步：安全（记忆是新攻击面）

• 记忆投毒：恶意输入写入长期记忆，持续影响后续所有对话 → 写入要过滤、可溯源、可人工审计。
• Prompt injection 持久化：通过记忆存下注入指令 = 长期后门 → 写入清洗，记忆在 prompt 里标注为「数据」不是「指令」。
• 多租户隔离：查询层强制 tenant_id 过滤。
• PII：写入前脱敏，支持导出/删除。

---

四、三者关系与场景对照

它们不是并列的三件事，而是互相嵌套的：

多智能体（组织层）
  ├─ 每个 Agent 可能各自用 RAG（知识层）
  └─ 每个 Agent 可能读写共享记忆（状态层）

业务场景	多智能体	RAG	记忆
企业知识库问答	可选（复杂查询才拆）	必须	可选（用户偏好）
深度研究报告	必须	必须	可选（研究历史）
客服工单	推荐（分类/查询/审批分离）	必须（政策库）	必须（客户历史）
个人助理	可选	可选（外部知识）	必须
代码助手	推荐（写/审分离）	必须（代码库）	必须（项目约定）
合同审查	推荐（抽取/校验分离）	必须	可选
单轮翻译/写作	不需要	不需要	不需要

典型组合：客服 = 多智能体编排 + 政策知识库 RAG（防编造赔付标准）+ 客户记忆（跨会话连续性）。三者各管一层，缺一层就出问题：没 RAG 会编政策，没记忆会重复问，没编排会权限混乱。

---

五、落地顺序建议

1. 先建评估集（哪怕 50 条），否则后面全是盲调。
2. RAG：混合检索 + rerank + 强制引用 + 拒答 → 跑评估 → 再加 claim 校验。
3. 记忆：摘要 + profile 表 + 向量检索历史，跑出真实需求再分层。
4. 多智能体：最后做。先单 Agent+工具跑通，确实卡在上下文/权限/并行时再拆 orchestrator-worker，且优先代码编排固定流程。

理由：RAG 和记忆是单 Agent 就能验证的基础能力，多智能体是放大器——基础不行，拆得越多错得越快。

风险提示：上面所有阈值（rerank top-k、去重相似度、记忆容量、置信度阈值）都必须用你自己的数据和评估集调，照搬默认值大概率不合适。

---

多智能体协作 · RAG 幻觉 · 记忆存储 — 工程实践笔记