Cao Note记忆与多智能体
两个问题合在一篇：怎么让它记住（上下文有限、跨会话会忘），和怎么让它分工（一个 Agent 能力有限、串起来又难控）。
一、记忆系统
1. 为什么需要「记忆」
| 约束 | 后果 |
|---|---|
| 上下文窗口有限 | 聊久了必须丢或压 |
| 每次请求都是无状态的 | 换个会话它就忘了你是谁 |
| 长期偏好要跨会话保留 | 需要持久化 |
记忆的本质是「在有限上下文里，选最该带上的信息」 —— 和 RAG 是同一个问题（检索），只是检索的是「历史」。
2. 短期记忆：最近几轮
| 策略 | 做法 | 代价 |
|---|---|---|
| 滑动窗口 | 只带最近 N 轮 | 早期信息丢失（最稳、最常用） |
| 摘要压缩 | 更早的对话压成一段 | 多一次模型调用、有损 |
| 混合 | 最近 N 轮原文 + 更早的摘要 | 推荐 |
配一个 token 预算：
可用 = 窗口上限 − 预留输出 − 系统提示词 − RAG 片段
超了 → 先砍最老的历史 → 再砍 RAG 条数 → 最后重压摘要可用 = 窗口上限 − 预留输出 − 系统提示词 − RAG 片段
超了 → 先砍最老的历史 → 再砍 RAG 条数 → 最后重压摘要3. 长期记忆：三种形态
| 形态 | 存什么 | 实现 |
|---|---|---|
| 向量记忆 | 历史片段，按语义召回 | 存向量库，检索 topK |
| 结构化画像 | 「用户是程序员、在准备考研、讨厌被推销」 | 表/JSON，key-value |
| 事件时间线 | 「3 月 2 日说要退款」「3 月 5 日已处理」 | 按时间排序的事件表 |
三者配合：画像给「底色」，时间线给「最近发生了什么」，向量给「相关的旧事」。
4. 写入策略：什么该记
不是所有对话都值得记。判断标准：
| 该记 | 不该记 |
|---|---|
| 稳定偏好、身份信息（职业、语言） | 一次性的寒暄、语气词 |
| 明确的长期目标 | 临时情绪 |
| 关键事实（订单号、约定时间） | 模型的推测 |
| 已发生的动作与结果 | 重复信息 |
三个必做：
- 去重：同样的偏好不要记 10 遍（写之前先查相似记忆，超阈值就更新而不是新增）；
- 冲突处理：新记忆和旧的矛盾时（「我住北京」→「我搬去上海了」），要覆盖 + 记变更时间，别两条都留着；
- 遗忘/过期：给记忆加 TTL 或重要性分数，定期衰减，避免越攒越乱。
5. 检索记忆：不只是相似度
生成式 Agent 的经典做法是三维加权：
score = α·相关性 + β·时效性(recency) + γ·重要性(importance)score = α·相关性 + β·时效性(recency) + γ·重要性(importance)- 相关性：向量相似度；
- 时效性：越近越重要（指数衰减）；
- 重要性：写入时让模型打 1～10 分（「用户说他要考研」比「用户说了句谢谢」重要）。
只用相似度会出问题：三个月前一句「随便看看」和昨天一句「下周要下单」，语义可能很像。
6. 隐私与隔离（最容易出事的地方）
| 要求 | 做法 |
|---|---|
| 用户隔离 | 记忆按 userId 分库/分区，检索必须带过滤条件 |
| 删除权 | 提供「删除我的记忆」，物理删除 + 索引重建 |
| 敏感信息 | 手机号、身份证等不入记忆，或加密存储 |
| 审计 | 谁在什么时候写入了什么记忆 |
| 跨租户 | 永远不要把 A 的记忆检索给 B（这是重大事故） |
面试口径：记忆是用户数据，不是模型参数。它的隔离、删除、审计要求和业务数据一样严。
二、多智能体系统
7. 为什么要多个 Agent
| 动机 | 说明 |
|---|---|
| 分工专业化 | 检索 Agent、写作 Agent、审核 Agent，各自提示词更短更专 |
| 并行 | 多个子任务同时跑，缩短总时长 |
| 隔离上下文 | 每个 Agent 只看自己那部分，避免上下文爆炸 |
| 可校验 | 一个生成、一个审查，比「自己检查自己」更有效 |
8. 四种协作模式
① Supervisor（主管） ② Pipeline（流水线）
┌──────────┐ A → B → C
│supervisor│
└──┬───┬───┘ ③ Debate（辩论）
┌───▼┐ ┌▼───┐ A ⇄ B → 裁决
│ A │ │ B │
└────┘ └────┘ ④ Group chat（群聊）
共享一个消息池，按规则发言① Supervisor（主管） ② Pipeline（流水线）
┌──────────┐ A → B → C
│supervisor│
└──┬───┬───┘ ③ Debate（辩论）
┌───▼┐ ┌▼───┐ A ⇄ B → 裁决
│ A │ │ B │
└────┘ └────┘ ④ Group chat（群聊）
共享一个消息池，按规则发言| 模式 | 优点 | 缺点 | 适合 |
|---|---|---|---|
| Supervisor | 控制力强、易观测 | 主管是瓶颈 | 任务可分解、需要调度 |
| Pipeline | 简单、确定 | 不能回退 | 有固定步骤（写作→审校→格式化） |
| Debate | 提升准确性 | 成本翻倍 | 需要高置信度的判断 |
| Group chat | 灵活 | 难收敛、易跑题 | 头脑风暴（慎用于生产） |
生产上最常见的是 Supervisor + Pipeline 的组合，Debate 用于关键决策点，Group chat 基本只用于演示。
9. 通信与共享状态
| 方式 | 说明 |
|---|---|
| 共享黑板（blackboard） | 所有 Agent 读写同一个状态对象，最简单 |
| 消息传递 | 点对点/发布订阅，解耦但难追踪 |
| 结构化产物 | 每个 Agent 输出 JSON，下游只读字段（最稳） |
建议：用结构化产物代替自然语言传话。「检索 Agent 输出 {docs:[...], confidence:0.8}」比「检索 Agent 说了一段话让写作 Agent 自己理解」可靠得多。
10. 冲突与收敛
| 问题 | 处理 |
|---|---|
| 两个 Agent 结论矛盾 | 第三方裁决（规则/仲裁 Agent/人工） |
| 无限互相修改 | 最大轮次（2～3 轮）+ 超时就采用最后一版 |
| 责任不清 | 每个 Agent 有明确输入输出契约 |
| 成本失控 | 每个 Agent 独立的 token 预算 |
11. 什么时候不要用多智能体
- 单个 Agent + 好工具就能解决；
- 延迟敏感（多一次往返就多几百毫秒到几秒）；
- 团队没有可观测能力（出问题完全没法查）；
- 任务本身是线性的（那叫工作流，不叫多智能体）。
一句实话：多智能体最大的收益是「上下文隔离」，最大的代价是「调试地狱」。没有强观测能力之前，别上。
12. 速查表
| 问题 | 一句话 |
|---|---|
| 记忆的本质 | 在有限上下文里检索最该带上的历史 |
| 短期记忆怎么存 | 最近 N 轮原文 + 更早的摘要 + token 预算 |
| 长期记忆三种形态 | 向量记忆、结构化画像、事件时间线 |
| 什么该记 | 稳定偏好、长期目标、关键事实、已发生动作 |
| 冲突记忆怎么办 | 覆盖 + 记变更时间，别两条并存 |
| 记忆检索怎么算分 | 相关性 + 时效性 + 重要性加权 |
| 记忆最容易出的事故 | 跨用户串数据，必须按 userId 强隔离 |
| 多智能体为了什么 | 分工、并行、上下文隔离、互相校验 |
| 最常用的协作模式 | Supervisor + Pipeline |
| 怎么传信息 | 结构化产物（JSON），别用自然语言传话 |
| 什么时候别用 | 单 Agent 能解、延迟敏感、没观测能力 |