给AI Agent造一个第二大脑：本地存储+3D图谱的Cohestry

每天用AI Agent干活的人都会撞上同一个尴尬：Agent在会话中产出了大量有价值的上下文——PRD、架构笔记、调试记录、调研文档——但会话一结束，这些内容就成了无人认领的"死重"。下次开新会话，还得靠人肉记住哪些文件重要，再手动指给Agent看。Reddit上一位开发者把这个问题拆得很直白：文件明明存在，记忆却不在。他为此做了Cohestry，一个专门给Agent用的第二大脑。

Agent的产出很多，可复用的却很少

这个痛点不是个例。Agent的工作模式决定了它天然是"上下文生产机"：写代码时顺手生成设计说明，调试时留下排查路径，调研时整理出对比结论。这些Markdown文件躺在项目目录里，理论上都是资产，实际上却很难被下一次任务调用。

作者的观察很准确——真正缺的不是存储，而是索引和召回。人记不住三个月前某个架构决策的来龙去脉，Agent更不会主动去翻旧文件。结果就是每个新会话都从零开始，前期积累的经验值被反复清零。Cohestry的切入点正是这个断层：把Agent产出的零散笔记变成可被检索、可被关联的长期记忆。

Cohestry做了什么：本地存储、自动关联、3D图谱

Cohestry的核心设计可以拆成三层。

第一层是本地存储。 所有Markdown笔记保存在本地，不走云端。对经常处理敏感项目的人来说，这一点比功能本身更重要——Agent的产出往往包含内部架构、密钥线索和未公开的调研结论，本地化是底线。

第二层是自动关联。 系统会识别相关笔记并建立连接。作者提到，这些连接的实际价值超出了他的预期：他可以沿着相关节点跳转，重新发现那些早已忘记的旧决策、旧想法和项目历史。这其实是在模拟人脑的联想式回忆——不是靠精确搜索关键词，而是靠"这条笔记让我想起另一条"。

第三层是3D知识图谱。 随着使用时间增长，知识会积累成一张可视化的网络。图谱的意义不在于好看，而在于让"我到底积累了什么"变得可见。对于长期项目，这种全局视角能帮助发现被埋没的关联。

MCP桥接：让Agent自己去找记忆

真正让Cohestry区别于普通笔记工具的是MCP桥接。接入之后，Agent可以用工具主动搜索这个大脑，只取回需要的笔记，而不是把整个文件夹一股脑塞进上下文窗口。

这个设计解决了两个现实问题。其一是上下文膨胀：把所有历史文档加载进窗口既浪费token又稀释注意力，按需检索才是正解。其二是安全：作者提到在内容交给Agent之前，API Key、p8密钥这类机密会被脱敏处理。Agent调用外部记忆时，不该顺带把凭证也暴露出去。

从工程角度看，这相当于给Agent配了一套外部记忆的读写协议：写入靠日常产出，读取靠工具调用，中间隔着一层检索和脱敏。比起把记忆硬塞进prompt，这种架构更接近人类使用笔记本的方式。

MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出并开源的协议，用于标准化大模型应用与外部工具、数据源之间的连接方式。它常被类比为“AI 应用的 USB-C 接口”：过去每个 Agent 框架接入数据库、文件系统或 API 都需要定制适配，而 MCP 定义了一套统一的客户端—服务器交互规范，工具提供方只需实现一次 MCP Server，任何支持该协议的 Agent 客户端都能直接调用。在 Cohestry 的场景中，记忆库以 MCP Server 的形式暴露“搜索笔记”“读取笔记”等工具，Agent 在需要时发起工具调用即可，无需平台方针对每个模型重写集成代码。这也意味着记忆层与具体 Agent 产品解耦，用户更换模型或框架时，第二大脑仍可继续使用。

第二大脑赛道正在升温

Cohestry不是孤例。围绕Agent长期记忆的产品近来密集出现，路线大致分两类：一类做托管式记忆服务，把记忆放在云端由平台管理；另一类像Cohestry这样强调本地优先和用户可控。两条路线各有取舍——云端方案省心但涉及数据托管，本地方案可控但需要用户自己维护。

作者的思路偏向后者，并且把"人类可读的Markdown"作为记忆的底层格式。这是个务实的选择：Markdown既是Agent容易生成和解析的格式，也是人可以直接翻阅、编辑、迁移的格式，不会被某个平台的私有格式锁死。

值得观察的是这类工具的实际使用门槛。自动关联的质量、图谱在笔记量变大后是否仍然可用、MCP检索的召回精度，这些都需要真实项目来检验。作者目前给出的更多是个人体验，尚缺规模化使用的数据。

小结

Cohestry抓住了一个被普遍忽视的环节：Agent不缺产出能力，缺的是跨会话的记忆连续性。本地Markdown存储、自动关联、3D图谱加MCP按需检索，这套组合把Agent的日常副产品转化成了可复用的上下文资产。对于长期跑Agent工作流、又在意数据自主权的人来说，这个方向值得关注；至于它能否从个人工具长成通用基础设施，还要看检索质量和生态接入的后续表现。

背景补充

自动关联在工程上通常依赖向量检索与语义相似度计算：把每条笔记切分后通过嵌入模型转为向量，再根据余弦相似度找出内容相近的笔记建立连接。这类方法能捕捉“换了说法但讲的是同一件事”的关联，而不依赖关键词完全匹配。另一种常见补充手段是知识图谱式抽取，即从笔记中识别实体与关系，形成结构化节点。两种方式各有短板——向量检索容易召回语义相近但主题无关的内容，图谱抽取则受限于抽取质量。因此实际产品往往混合使用，并允许用户手动增删连接。评估这类工具时，关联的精确率比召回率更值得关注，因为错误的连接会把 Agent 引向无关上下文。

脱敏（redaction）指在数据离开受控环境前，识别并遮蔽敏感信息的过程。常见实现是正则匹配与模式识别相结合：针对 API Key、私钥、令牌等高熵字符串设定检测规则，命中后替换为占位符。需要留意的是，脱敏并非万无一失，密钥可能以非常规格式出现，或分散在多条笔记中拼接后才具备敏感性。对安全要求高的项目，更稳妥的做法是将凭证与笔记物理隔离存放，脱敏仅作为额外防线，而非唯一保障。