vshulcz

如果一个编程智能体每次新会话都要重新认识项目，问题未必出在模型能力，而可能出在记忆没有成为独立、可迁移的工作层。 GitHub 上新发布的这个开源项目，尝试用 SSH 同步编程 AI 智能体的记忆数据，让智能体跨会话保留上下文。它不依赖特定云服务，用户可以自托管；代码已经开源，也为开发者留下了集成和定制空间。 这套思路的价值，不是单纯“记住更多”，而是把记忆从某个智能体或某次会话里拆出来。只要同步层能够进入现有工作流，用户就有机会自己掌握记忆数据，并在会话变化时继续使用，而不必完全依赖特定云端产品提供的连续性。 但“能通过 SSH 同步”只回答了数据怎么移动，没有回答什么值得被记住。编程智能体的有效记忆可能涉及项目约定、已做决策、任务状态和历史错误；如果不加筛选地长期累积，旧信息也可能干扰新任务。同步能力与记忆质量是两个不同问题，前者不能自动保证后者。 同样需要区分自托管与低成本。自托管意味着控制权和维护责任都回到用户手里。输入没有说明项目的记忆结构、检索方式、冲突处理、权限设计、数据保护、清理机制或规模表现，因此现在还不能判断它是否适合敏感代码库、多人协作或长期生产环境。 我会用四个问题评估这类方案： 一，记忆是否可读、可查、可删除，而不是只会不断写入； 二，跨会话恢复的究竟是有效决策，还是未经整理的聊天残留； 三，SSH 同步如何进入现有开发流程，会增加多少配置与维护工作； 四，切换智能体或设备后，数据能否继续被实际使用，而不只是完成文件传输。 对个人开发者，较稳妥的采用方式是先在非敏感项目中测试一个边界明确的任务，观察新会话能否正确继承必要上下文。对团队，则应先确定哪些记忆可以共享、谁负责更新，以及错误信息如何纠正，再讨论全面接入。 这个项目值得关注，因为它把编程智能体竞争中的一个隐性问题摆到了台前：模型会不会写代码是一层，长期协作时能不能保留正确上下文是另一层。SSH 同步提供了一个开放、自托管的实现方向；它最终能否降低重复说明成本，要看记忆治理是否与同步机制一起成立。 github.com/vshulcz/deja-vu