Friday 想给编程 Agent 长期记忆，自托管却不等于数据留在本地
据 Friday 的 GitHub 文档，这个项目试图通过 MCP 为编程 Agent 提供跨会话记忆。但在考虑把项目背景和团队知识交给它之前，有一个比“记得多牢”更基础的问题：这些记忆会经过哪些服务，又能被谁读取？
作者：韩启明｜OC 政策与安全编辑
据 Friday 的 GitHub 文档，这个项目试图通过 MCP 为编程 Agent 提供跨会话记忆。但在考虑把项目背景和团队知识交给它之前，有一个比“记得多牢”更基础的问题：这些记忆会经过哪些服务，又能被谁读取？
一句话结论：Friday 文档中的自托管描述，不能直接等同于纯本地处理；其默认架构涉及外部 API，读取权限也需要部署者单独审视。
一句“自己的记忆”，包含三种不同控制权
把服务运行在自己的机器上，意味着掌握一部分部署与存储。是否仍向外部模型发送内容，是另一回事。服务启动后哪些人能访问，又是第三回事。这三层控制不能用“自托管”三个字一并回答。
Friday 的 README 描述了本地存储组件，同时要求配置 Mem0 与 DeepSeek 的 API 密钥，并把一层记忆能力标为 Mem0 云 API，实体提取流程也涉及 DeepSeek。仅依据这份公开架构说明，就不能把它概括成数据完全不出机器。
这是对项目文档的核对，不是对实际部署流量的独立审计。不同用户可能修改后端或运行方式，但若要声称纯本地，就需要拿出相应配置和数据流证据，而不是沿用自托管标签。
写入上锁，不代表读取也上锁
文档还有一个容易被功能介绍盖过去的默认项：部分事实、图数据及可视化页面允许公开读取，写入则使用密钥保护。它同时说明了监听地址及通过反向代理加强保护的做法。
这不等于任何安装都会直接暴露给互联网；实际可达性还取决于网络、端口和代理配置。但它说明部署者必须分别检查读与写，而不能看到写入需要密钥，就认定知识库整体已经只有自己可见。
对于长期记忆，读取本身就可能是敏感能力。项目路径、内部决策、客户名称和过去的问题，单条看起来普通，聚在一起却能形成完整工作画像。评估访问控制时，不能只以“攻击者能否修改内容”为标准。
记得越久，纠正与删除越重要
记忆服务通常希望保留历史，方便理解一项决定如何改变。但把旧事实标成已被替代，与真正删除它并不相同。检索是否还会返回旧内容、备份是否仍有副本、外部服务是否保留相关记录，都需要另行说明。
这也意味着“自动记住”应有范围。口令、临时凭据以及不必要的个人信息，不应因为曾经出现在对话里，就自然进入长期知识库。能够写入记忆的 Agent，也需要知道哪些内容不该写。
团队使用时还会遇到归属问题：这条记忆属于个人、项目，还是整个组织？一个项目的经验可以帮助另一个项目，但不意味着两个客户的数据可以混合。Friday 文档将多用户隔离列在后续工作中，读者不应把规划当成已经完成的能力。
先画数据路线，再讨论记忆效果
评估这类工具时，可以从一条具体记忆出发：它从哪里产生，发送给哪些服务，保存在哪里，通过什么身份读取，如何更正，最终怎样删除。每一站都有答案之后，才适合继续比较召回效果和使用便利性。
长期记忆确实可能减少重复介绍背景的成本。它也把一次对话的内容变成持续存在的资产。功能越方便，默认配置与数据生命周期越不适合藏在安装说明后面。
关键事实
- 来源：Friday 公开 README；本文未部署项目或审计网络流量。
- 外部依赖：文档列有 Mem0 云 API 与 DeepSeek 相关处理。
- 权限边界：文档区分公开读取端点和需要密钥的写入。
- 规划边界：多用户隔离不能按已交付能力理解。
OC 判断
长期记忆产品不应只回答“能不能记住”，还要回答“谁能读、经过哪里、如何忘掉”。对于开发团队，这些是采用之前的架构条件，而不是上线之后再补的设置。
为什么重要
- 对开发者：自托管不自动排除外部数据处理。
- 对团队：分别核查身份隔离、读取权限和删除路径。
- 对用户：持久记忆可以更便利，也需要更明确的写入范围。
评论
围绕这篇文章补充信息、提出问题或分享观察。