Agent记忆不是聊天记录：用三层存储构建可追溯的 AI 工作流

最近 Hugging Face 发布了 Funes，一个给 Claude Code、Codex、pi、Hermes 等编码 Agent 使用的持久记忆层。它解决的不是"让模型记住更多聊天"，而是把本机已有执行轨迹变成可检索、可追溯的工作记忆。

这件事对内容 Agent 同样重要。许多系统把产品资料、旧文章、操作日志和临时要求全部塞进长上下文，结果会话越来越贵，事实却不一定更可靠。真正需要设计的，是记忆的数据模型、检索链路和权限边界。

会话日志为什么还不是 Agent Memory

一份历史会话只是档案。它要成为工作记忆，至少要补齐四项能力：

1. 可检索：可以按任务找到相关片段，而不是线性翻阅全部历史。
2. 可追溯：答案能回到原始文本、会话、时间和执行者。
3. 有时效：同一事实出现多个版本时，新旧信息不能平权。
4. 有权威级别：官网确认的价格不能被一次临时讨论覆盖。

Funes 的做法提供了一个有意思的参考。它把不同编码 Agent 的 trace 解析为统一的 turn/block 结构，增量写入本地 Lance 数据集。查询阶段不是只做向量相似度，而是组合向量检索与 BM25，进行排名融合、交叉编码器重排、时效加权，并附带邻近片段。

可以抽象成：

agent traces
  -> normalize(turn/block)
  -> incremental index
  -> vector + BM25
  -> rank fusion + rerank
  -> recency weighting
  -> original passages + provenance

另一个关键取舍是：原始内容在写入时不先压成一条"长期事实"。recall 返回原文，并标注 Agent、时间、会话和轮次。摘要当然更短，但它可能把条件、否定和失败原因压没。涉及事实核验时，能回到证据比得到一句流畅结论更重要。

Funes 官方还展示了 recall 与 handoff、compaction 的成本对比。不过那只是两个特定任务，不适合直接推成所有 Agent 都能节省固定倍数。更值得借鉴的是它的结构，而不是某个数字。

内容工作流需要三层记忆模型

编码轨迹相对同构，内容运营的数据更杂：品牌口径、素材、调研来源、成稿与平台状态更新频率完全不同。将它们混进一个向量库，检索命中不等于业务上可信。

1. 业务底稿层：经过确认的相对稳定事实

典型字段包括：

• 产品功能与限制；
• 价格和活动口径；
• 目标受众、品牌语气、禁忌词；
• 案例、授权素材与引用范围；
• 负责人、来源、版本和更新时间。

这层是事实源，不应由普通任务日志自动覆盖。价格变化时应生成新版本，并明确旧版本的失效时间。

2. 过程证据层：追加式工作轨迹

这里记录调研来源、候选方案、失败尝试、人工审核意见和关键取舍。它类似事件日志，适合 append-only，再通过索引检索。

最终稿只能告诉你结果；过程证据解释为什么选择这个结果。下次复盘"为什么头条标题改短""为什么放弃某个竞品比较"时，这层比聊天摘要有用。

3. 交付资产层：可继续使用的终态与状态

内容、图片、视频、摘要、标签、平台分类、发布时间、审核状态和作品链接都属于这一层。它应该按项目、渠道与版本组织，并明确哪一份才是实际发布版本。

新任务读取上一轮终稿时，不应从十几个附件中猜测。

检索边界比"记得多"更重要

一个实用的 retrieval policy 可以写成：

query
  -> 识别岗位与任务
  -> 限定项目/客户
  -> 选择资料层级
  -> 过滤权限与时效
  -> 取回少量原文
  -> 证据不足则明确返回 miss

不要把所有记忆注入每一个请求。这样既浪费上下文，也会把无关岗位的资料与权限带进当前任务。

例如，博客编辑要写一篇新品文章，可以读取共享的产品底稿、这次调研证据和最近发布资产；它没有必要看到闲鱼运营的全部会话，更不该自动获得那个账号的操作权限。共享的是业务认知，岗位经验和执行权限仍然隔离。

Tipkay 为什么采用岗位化的沉淀方式

这里说明一下关系：我们在做 Tipkay。官网把它定位为专业 AI 员工平台，强调结合业务资料、历史内容和账号数据工作，也强调会话记录、品牌资料和工作资产的持续沉淀。

我们的取舍是让不同岗位读取同一份业务底稿，同时保留各自的流程、Skill、MCP 和工具边界。内容岗位完成选题与成稿，博客发布助手处理 CSDN、掘金、头条等平台字段和预填；岗位之间交接明确资产，而不是复制整段聊天。

桌面端可以使用本地素材和本机平台登录态，发布等关键操作由用户确认。这样做牺牲了一点"所有事都在一个入口里自动发生"的戏剧感，但资料归属、权限范围和人工确认点更清楚。

落地前的五项检查

准备给 Agent 增加记忆能力时，先回答：

1. 哪些数据是正式事实源，谁能修改？
2. 哪些过程必须保留原文和出处？
3. 最终交付物如何确定版本？
4. 每个岗位能检索哪些层、拥有哪些权限？
5. 检索失败时，系统是否允许明确说"没有证据"？

如果这五项没有定义，再大的向量库也只是更难整理的聊天仓库。

Agent Memory 的终点不是"永不遗忘"。一个成熟的工作系统应该知道什么值得长期保存、什么只能作为历史证据、什么已经失效，以及每次任务究竟需要取回哪几段内容。

参考资料：

• Hugging Face, Give Your Coding Agents a Memory You Own：https://huggingface.co/blog/funes
• Tipkay：https://www.tipkay.com/