跨 Agent 共享笔记，是否真能改善修复

让 Claude Code、Codex 和 Copilot 共享笔记，不等于让它们少犯错。作者用 Research Brain 打通了跨客户端读取知识的路径，但后续四项任务的比较中，共享记忆没有给最终修复增加新的决策或检查。

这组实验值得读，恰恰因为它没有把「成功接入 MCP」包装成效率提升。它把两个问题拆开了：过去的经验能不能被另一个 Agent 找到，以及找到以后，究竟改变了什么。

三个 Agent 读到同一份笔记，证明了什么

作者想保存的不是聊天记录，而是解决问题时的推理：什么办法失败过、检查过哪些证据、哪些条件变化后需要重新判断。Research Brain 把这些内容存进本地 Obsidian vault，以 Markdown 记录问题、应对办法、来源、验证、适用条件和未决问题。

项目自身的指令和架构决策仍然需要保留。共享笔记提供的是可迁移的经验，不能代替当前项目的规则。

可选的 MCP 适配器提供两个只读工具：search_knowledge 返回候选笔记，get_concept 打开选中的记录。每个客户端启动自己的本地适配器进程，访问同一批文件，聊天历史彼此独立。保存新发现则走另一条由所有者批准的流程。

第一次试验让三个全新命令行会话，在同一项目初始状态的独立副本中处理 CI 和部署审查。作者只要求它们咨询 Research Brain，没有提供笔记 ID、预设查询或之前的答案。私有测试库共有 9 篇笔记，其中 5 篇来自其他项目的 GitHub Actions 和 Vercel 工作。

工具日志确认，三个客户端都在编辑前读过笔记。但它们使用的模型、权限不同：Claude Code 准备补丁和报告后触及轮次上限；Copilot 超时后需要继续生成报告；Codex 完成任务，与沙箱有关的测试失败另行核查。

所以，这次验证的是三条访问路径都能工作，不能据此给客户端排名。

为什么读过超时教训，仍会提出错误方案

最有代表性的案例是 CI 超时。

旧笔记记录过一次任务接近配置时限时被取消的情况。这个运行时长只说明它被中断了，不能说明它还需要多久才能完成。调整时限之前，应检查已完成运行的耗时、被中断的工作，以及当前环境中的进度证据。

然而，两个 Agent 读完笔记后，仍根据本地测试耗时加余量，建议设置 15 分钟上限。当前项目没有托管环境中的耗时观测支持这个数字，因此审查否决了建议。

经验已经被读到，经验里的约束却没有被执行。

另一个决策是取消旧的验证运行。最终补丁按 workflow、事件类型和 ref 分组，允许同组新运行取消旧运行。它适合「旧验证被新验证取代后可以停止」的工作流；如果业务要求每次运行都完成，就必须重新判断。

集成后，本地测试、健康检查和 lint 通过，原有触发器与验证步骤也保留了。但试验没有启动托管 GitHub Actions 运行，因此没有测量实际取消行为，也没有测量节省了多少 CI 分钟。

部署审查暴露了类似问题。针对 Vercel CLI 上传的补救办法，不能直接用于一个文档明确采用 GitHub import 的项目。Copilot 还据此排除了部署保留策略，但作者指出，Vercel 的保留文档也涵盖 Git 分支部署。最终没有修改保留设置，理由是当前没有证据证明存在保留问题。

这轮试验说明，笔记可以把来源和检查问题带进新会话，审查仍需纠正解释。由于没有安排不使用记忆的对应试验，也无法确认哪些决定原本就会做出来。

四项任务的比较，为什么没有证明记忆有用

作者随后选了两个项目中的 4 项真实未完成任务，让全新上下文分别在三种条件下制定计划：

• 只查看当前项目证据。
• 直接阅读同一批已批准笔记。
• 通过现有 MCP 工具查找笔记。

知识库包含 21 篇概念笔记。各会话看不到彼此答案，计划在实施前冻结，每项修复实施并检查一次。4 项任务乘以 3 种条件，共产生 12 份初次计划，没有重试计划。

结果是，三组核心修复思路兼容，审查没有发现直接阅读或 MCP 为最终采纳的修复增加独有决策或检查。直接阅读提供了提醒，MCP 则没有返回候选笔记。

一个具体缺陷很能说明问题：带时间戳条目的校验放在排序比较函数里。如果输入只有一个条目，比较函数可能根本不执行，无效值就能漏过去。只看项目代码的计划已经提出，在排序前验证输入。笔记强化了这个判断，却没有增加修复步骤。

这也限制了结论的范围。四项任务都是已经定位到一定程度的缺陷，任务描述往往提示了问题机制，而且贡献审查不是盲审。对于需要历史背景、原因隐藏较深的工作，共享记忆是否更有帮助，仍未验证。

耗时也不能拿来宣传效率。作者记录了各组首次规划的时间中位数和四次尝试的总 token，输入计数包含重复上下文及缓存 token，不代表笔记大小或实际账单。当前提供的原文没有展示具体表格数值，无法进一步比较。

尤其是 MCP 没搜到候选笔记，即使规划比直接阅读更快，也不能解释为知识利用更高效。实施、完整审查，以及历史知识的整理维护成本，都没有按条件测量。

读到、适用、带来新增判断，是不同层次的结果。

作者因此提出下一轮更窄的测试：让新会话找回一项当前代码无法解释的历史决策，并检查它能否正确使用其中的限制条件。相比泛化的编程建议，被否决的方案、例外的原因、已经验证的项目约束，可能更难从代码中重建。这是下一步假设，还不是已有结论。

我的判断

我认同作者先验证「相关笔记是否改变工作」，再优化检索。否则，搜索没有结果，很容易变成继续加语义搜索、摘要或知识图谱的理由，却始终没有回答这些知识值不值得读。

但这组结果也不能支持「共享记忆没用」。缺陷已经局部定位，代码本身提供了足够线索，历史笔记自然可能只是重复提醒。相反，错误方案仍被提出，也提醒我们：增加上下文无法替代当前项目的证据核对。

与直接阅读相比，MCP 增加了检索环节，必须分别检查「没找到」和「找到后没贡献」。四项任务里，这两种情况都出现了，不能混成一个成功率。

工具选择上，作者提到 Basic Memory 支持不同客户端使用 Markdown 知识库，QMD 提供命令行和 MCP 本地文档搜索。但原文没有做产品对照测试，不能证明 Research Brain 更好。它保留来源、条件和验证记录的思路有参考价值，自建是否划算，仍要算维护成本。

还有一个复现边界：公开仓库提供适配器、记录模板和批准保存流程，不包含这些私有试验。接入时也要明确哪些客户端和项目可以访问 vault，因为检索文本可能进入托管模型，来源内容仍应作为不可信输入处理。

能拿来做什么

• 给日常 AI 编程留下笔记时，优先记录被否决的修复、否决证据和适用条件。例如 CI 时限缺少托管运行数据，就把这个限制写清楚，避免下一次继续拿本地耗时猜数字。
• 验证共享记忆时，先选真实任务并保存 Agent 的初始计划，再让新会话自行搜索，不提供目标笔记 ID。比较咨询前后增加了哪些决策和检查，而不是只统计工具调用次数。
• 对已经定位的 Node 或前端数据处理缺陷，保留只看项目证据的对照。如果相关笔记没有增加修复步骤，就记录「没有增量」，不用强制每次修复都查询知识库。
• 接入 MCP 前，先直接阅读相关笔记做一次比较。直接阅读有效后，再验证 search_knowledge 能否找到它，以及 get_concept 返回的内容是否足够支持当前判断。