跨 Agent 记忆系统最容易做错的地方

这类系统最迷惑人的地方是：
它在前期通常看起来进展很快。

你会看到：

• 数据能写进去
• 搜索能搜出来
• 多个 Agent 也确实能共享一些经验

但很多系统真正开始失控，恰恰是在“已经能跑之后”。

所以这篇不讲它能做什么，而是讲它最容易在哪些地方翻车。

1. 最大的风险不是记不住，而是共享污染

很多人会本能地把“多写一点”当成记忆系统进步。
但在跨 Agent 场景里，污染比遗忘更危险。

为什么？

因为遗忘通常只会让某次任务少了一些帮助，
而污染会让多个 Agent 一起带着错误上下文继续工作。

典型污染来源包括：

• 未经确认的推断被当成稳定经验
• 临时调试结论被升级成共享规则
• 只适用于一个项目的约束被全局扩散
• 带强上下文依赖的内容被抽离后误共享

所以共享层最重要的原则不是“尽量多”，而是“尽量准”。

2. 检索失真往往比存储失败更常见

很多系统前期都很关注“能不能存”。
真正开始使用后，问题通常变成“搜出来的东西到底准不准”。

检索失真常见有三种：

1. 搜到了看似相关、实际无用的内容

也就是误召回。

2. 搜到了旧经验，却没有意识到已经过期

这在项目约束和配置场景尤其危险。

3. 搜到了局部正确的经验，却缺少适用边界

看起来像答案，实际一用就错。

这也是为什么 Agent Memory System 这类项目不能只依赖模糊检索。
标签、来源、领域、重要度和版本信息都很重要。

3. 没有权限设计时，共享会迅速滑向混用

早期做原型时，大家很容易说：

“先别管权限，先共享起来。”

这句话短期没问题，但如果系统真的准备继续活下去，权限设计很快就会变成硬需求。

你至少要回答：

• 哪些经验是全局可见
• 哪些经验只对某个项目可见
• 哪些经验只允许创建者或部分 Agent 访问
• 哪些 Agent 只能读，哪些能写

如果没有这些边界，后面最常见的问题就是：

• 共享层越来越脏
• 问题很难追责
• 团队开始不信任这套系统

4. 只做写入和搜索，不做回查，系统迟早没人敢用

跨 Agent 记忆系统一旦开始承载真实协作，就一定会出错。
真正决定它能不能继续用下去的，不是“会不会出错”，而是“出错后能不能回查”。

更现实地说，你至少要能回答：

• 这条经验是谁写的
• 它什么时候写入的
• 它原来基于什么上下文
• 它是否已经被更新或覆盖

如果这些都没有，团队很快就会退回到：

• 不敢信
• 不敢依赖
• 不敢共享

5. 共享经验和本地记忆一旦混用，治理成本会指数上升

这是最经典的结构性错误之一。

共享经验应该更像：

• 已验证方法
• 团队规则
• 项目共识

本地记忆应该更像：

• 当前 Agent 偏好
• 个人上下文
• 临时过程信息

一旦混在一起，就会出现：

• 本地偏好被错误共享
• 团队规则被临时状态覆盖
• 后续检索根本分不清应该相信哪一层

6. 太早自动化写回，会把系统推向失控

很多人最想做的是“工作流一结束就自动沉淀经验”。
这当然诱人，但也是最容易把系统快速推脏的地方。

更稳的做法通常是：

1. 先只允许人工确认后的高价值内容写回
2. 再逐步放开特定类型的自动写回
3. 最后才考虑更广泛的自动沉淀

原因很简单：
写入门槛一旦太低，后面检索和治理的成本会远高于你今天省下的那点人工成本。

7. 只看“记忆条数变多”，是很危险的假指标

这类系统最容易自我感动的指标，就是：

• 新增了多少条共享经验
• 累积了多少记忆
• 存了多少标签

这些都可能有参考价值，但绝不是核心指标。

更值得看的反而是：

• 命中的共享经验有多少真的被后续任务采用
• 错误召回率有多高
• 需要人工回滚的比例有多高
• 是否明显减少了重复解释和重复试错

如果这些指标没有变好，记忆条数越多，可能只是噪声越多。

8. 一个更现实的工程取舍

如果你问我，这类系统更稳的取舍是什么，我会给出下面这组偏保守的选择：

宁可先少共享，也不要先全共享

因为共享错误比共享不足更贵。

宁可先强依赖元数据，也不要只赌语义搜索

因为后期治理靠的不是“感觉像相关”，而是可解释边界。

宁可先只服务一个高价值场景，也不要一开始覆盖所有工作流

因为真实价值来自闭环，而不是覆盖面。

宁可先把回查和回退补上，也不要继续堆新功能

因为没有治理能力的共享系统，越大越难收。

一个更像治理视角的伪代码

function approveSharedExperience(candidate: MemoryCandidate, reviewer: Reviewer) {
  if (!candidate.isVerified) {
    return { approved: false, reason: "unverified" };
  }

  if (isOutOfScope(candidate)) {
    return { approved: false, reason: "scope-mismatch" };
  }

  const versioned = createVersionedRecord(candidate, reviewer.id);
  saveSharedExperience(versioned);
  writeAuditTrail(versioned.id, reviewer.id, "approve");

  return { approved: true, id: versioned.id };
}

function rollbackSharedExperience(recordId: string, operator: string) {
  const current = loadRecord(recordId);
  const rollbackPoint = loadPreviousVersion(recordId);

  markCurrentAsSuperseded(current.id, operator);
  restoreVersion(rollbackPoint.id, operator);
  writeAuditTrail(recordId, operator, "rollback");
}

这里的重点不是复杂，而是：

• 写共享层要经过边界判断
• 回滚是一级能力，不是临时补丁
• 审计要伴随全流程

什么时候说明系统已经开始偏离正确方向

如果你观察到下面这些迹象，通常说明系统已经开始变质：

1. 团队成员开始绕过共享层，宁可重复解释
2. 搜索结果越来越多，但真正有用的越来越少
3. 没人说得清某条规则是谁写的
4. 新 Agent 接进来后，反而更容易带偏任务

这时候最该做的不是“再加点检索优化”，而是回头重查边界和治理。

更值得保留的最终判断

跨 Agent 记忆系统真正有价值，不是因为它看起来复杂，而是因为它能做到三件事：

1. 让经验真正可复用
2. 让共享边界清楚可控
3. 让错误能被发现、追踪和回退

只要这三点还没站稳，就不该继续追求更大的自动化野心。

延伸阅读

• 什么是 Agent Memory System：一个把跨 Agent 共享经验和本地记忆拆开的实战项目
• Agent Memory System 该怎么设计：共享经验、本地记忆、Gateway API 和适配边界
• Agent Memory System 实战部署指南：MySQL、CLI、SDK 和跨 Agent 接入怎么落地
• Agent Memory System 和 Agent workflow 的关系，更适合去看这组主线文章