本地模型只是故事的一半。我也想要本地的代理记忆

最近观察到人们在 Claude、GPT/Codex 和本地模型之间频繁切换，让我意识到一个很明显的事实：模型的替换比围绕它们的工作流更容易。上个月大家可能都在深入使用 Claude Code。然后 Codex 变强了，GPT 再次变得诱人，本地模型在某些方面追了上来，于是人们又开始调整他们技术栈的组成部分。我甚至不是说哪个更好。我也不一样，针对不同的任务使用不同的模型。但这让我开始思考一个我一直忽视的依赖项：记忆。模型是一回事，你可以替换它。但如果你的代理的长期记忆、它实际习得的经验，存在于一个由供应商控制的黑盒中，你就并不真正拥有它。你只是在租用你的代理的大脑。对于爱好项目来说，这也许没问题。但对于实际工作，尤其是任何涉及客户敏感内容的工作，这很快就会让人感到不适。也许你需要可审计性。也许你需要解释数据存在哪里。也许你只需要证明你的代理的记忆没有消失在某个黑盒 SaaS 层中。令人烦恼的是，“记忆”听起来很简单，直到你真正尝试将其用于代理工作。聊天记录是不够的。向量数据库也不够。诚然，它可以检索相似的片段，但这并不自动意味着代理记住了发生了什么。例如，如果一个代理花费半个小时解决部署问题，我不只希望它记住我们讨论过 Docker。我希望它记住哪个命令失败了，哪个修复方法有效，什么不应该重复，以及什么可以在下次重用。编码代理也是如此。如果它了解到一个仓库使用 pnpm，或者某个变通方法只是临时的，这应该成为其工作经验的一部分。否则，它每隔几个会话就会重新发现相同的事实。因此，我一直在将我的代理技术栈转向更侧重本地化和透明化。这不仅是为了隐私，更是为了控制力和可调试性。作为背景，我的设置并不那么奇特：大部分代理工作使用 Hermes Agent，类似的实验使用 OpenClaw，当我需要更多控制时，通过兼容 OpenAI 的端点使用本地模型。模型方面实际上是容易的部分。我低估的部分是记忆。我想要的是更接近可检查的经验层的东西：执行轨迹、策略、项目知识和可重用的技能。而不仅仅是一堆旧消息被塞回上下文中。目前我找到的最接近的东西是 MemOS Local 插件。让我觉得合理的是它整体的“执行即学习”角度。不是那种“保存更多聊天记录”的记忆，而是这样的记忆：代理执行任务，看到什么有效，什么失败，并将这些经验转化为可重用的东西。这更接近我实际想要的东西。我坚持使用它的原因并非什么神奇的记忆主张。而是因为记忆是极其直观可见的。对于 Hermes，它将运行时数据保存在本地，而不是隐藏在云端仪表板后面。你可以在自己的机器上看到配置、本地数据库、技能包和日志。没有任何神秘之处。我可以检查它、备份它、比较差异，或者在不等待某个 SaaS 仪表板暴露正确按钮的情况下清除不良状态。后端设置也很灵活。嵌入和 LLM 后端是分开配置的，因此你可以保持所有内容本地化，指向兼容 OpenAI 的本地端点，或者如果设置需要，也可以使用云提供商。这就是说服我的部分。感觉不那么像“作为云功能的记忆”，而更像是作为代理本地文件系统一部分的记忆。更重要的是，记忆不仅仅是“聊天历史”。它更接近执行记忆。代理做了什么？什么有效？什么失败了？什么应该成为可重用的技能，而不是每次都要重新发现？我们花了太多时间讨论代理循环、工具使用、评估和错误处理。但我认为记忆所有权是技术栈中最重要的部分之一，而且往往被忽视。本地模型很棒。云模型也有用。但如果代理的习得经验仍然存在于其他地方，那么技术栈并不真正属于你。开发者应该对其代理的经验拥有完整的 CRUD 控制。你是将代理记忆保留在本地，使用托管的记忆层，还是目前仅将记忆视为可丢弃的上下文？