“给 Agent 加记忆”很容易被实现成两种东西：把摘要不断塞回 system prompt，或者把所有历史扔进向量库，每轮检索几个相似片段。两种方案都能演示，但进入长期工作后，经常会遇到同一个问题：它记得很多，却说不清这条结论从哪来、是否过期、能不能覆盖正式资料。
Hugging Face 这周发布的 Funes 值得关注，原因不是又多了一个 memory 工具，而是它把 Agent trace 当成了可拥有、可检索、能回到原文的数据集。
Funes 的可借鉴之处：Evidence First
Funes 支持 Claude Code、Codex、pi、Hermes。安装后，它从本机会话建立索引，新 turn 增量写入，不需要每次重嵌全部历史。
它公开的查询链路大致是：
Vector Search ─┐
├─ Rank Fusion -> Cross-encoder Rerank
BM25 Search ───┘ |
Recency Weighting
|
Original Chunk + Neighbors
这个组合并不神秘。语义检索找近义表达，BM25 保住精确关键词，重排负责缩小候选，时效权重降低陈旧命中，相邻 chunk 用来恢复局部上下文。
更重要的是写入策略：它不先把 trace 总结成一组抽象事实，而是保留原始片段。recall 命中后会带出 Agent、时间、会话和 turn，必要时可以继续打开完整上下文。
这更像日志系统，而不是一本被模型不断改写的个人传记。摘要可以作为索引或缓存，但不该成为唯一真相。
Memory Store 里最容易混淆的三种数据
把这个思路搬到内容运营时，我会把记忆拆成三个 store，而不是建一个“万能知识库”。
Source of Truth
产品功能、价格口径、目标用户、品牌规则、案例授权等经过确认的数据。它们更新慢，但权威级别最高，需要 owner、version、valid_from/valid_to。
这层不应该被 session trace 自动写回。一次讨论里的假设，不能覆盖官网确认事实。
Decision Log
调研来源、候选标题、失败路线、人工审核意见和最终取舍。它适合 append-only，并且要求 provenance。
很多团队只保存最后的文章，三周后却没人记得为什么删掉某段、为什么改分类。决策日志补的是“why”，而不是再存一份“what”。
Delivery Registry
真正发布的正文、图片、摘要、平台字段、审核状态和公开链接。它需要项目、渠道、版本和状态机，而不是只保存附件路径。
Agent 接到“根据上次头条稿改成 CSDN 技术版”时，应先从 registry 找到确实发布的版本，再读取相关 decision log。否则很容易拿到一份中间稿。
Retrieval 需要岗位作用域
有了三层 store，下一步不是把它们全部注入 prompt，而是先缩小搜索空间：
type MemoryQuery = {
role: "blog-editor" | "xhs-operator" | "video-producer";
projectId: string;
layers: ("truth" | "decision" | "delivery")[];
validAt: string;
permissionScope: string[];
topK: number;
};
这个 schema 里最重要的不是 topK，而是 role、layers 和 permissionScope。
同一份产品底稿可以被多个岗位共享；平台经验、失败记录和登录权限不必全局共享。博客编辑可以引用产品事实，但不应该顺手检索闲鱼私聊，更不应该拿到另一个岗位的执行权限。
命中后还要做三件事：检查版本、附上出处、允许 miss。没有可靠证据时返回“未找到”，比从相似片段补一个合理答案更可控。
长上下文不是持久记忆
长上下文适合当前任务的工作集，不适合承担全部历史。把一整年资料塞进每轮请求，会产生三个副作用：成本增加、注意力被稀释、旧事实污染当前判断。
Funes 官方用两个 handoff 任务比较了 recall、人工交接和 compaction，并报告 recall 成本更低。这个实验样本很小，不能当成通用基准；但它提醒了一个方向：把相关原文按需取回，通常比永久携带整个会话更合理。
我们在 Tipkay 里的取舍
这里披露一下关系：我们在做 Tipkay。产品采用的是岗位化 AI 员工，而不是一个通用 Agent 挂所有工具。官网目前强调业务资料、历史内容和工作资产沉淀，也强调岗位协作、专属员工复制与定时任务。
在记忆边界上，我们希望共享的是经过确认的业务上下文和明确的交付资产；每个岗位仍保留自己的经验、流程、Skill/MCP 与工具。内容岗位写稿，博客发布助手处理平台字段和预填；交接的是成品、状态和证据，而不是把所有历史会话全量复制过去。
桌面端会使用本地素材和本机已有登录态，发布等关键动作由人确认。这能让执行真正落地，同时不必把平台 Cookie 变成一个共享云端记忆。
实施顺序
如果要给现有 Agent 增加记忆，建议先做小闭环：
- 选一个重复任务，定义唯一事实源；
- 对关键决策做追加记录并保存 provenance；
- 建立实际交付版本的 registry；
- 用岗位和项目限制检索范围；
- 回归测试旧事实冲突、检索 miss 和越权查询。
到这一步，再决定是否需要向量库、混合检索或跨设备同步。
一个好用的 Agent 不必记住所有事情。它需要知道哪些东西可信，去哪找，为什么当时这么做，以及这一轮完成后该把什么交给下一位同事。
资料：
