为什么你的代码仓库不应该成为你的记忆
摘要
本文警告不要将代码仓库用作组织的决策和知识记忆库,主张建立独立的知识管理系统,以避免信息噪声和关键资料被埋没。
我在AI项目中看到的最大扩展错误之一,就是将代码仓库当作组织的记忆库。起初这感觉很方便:
* 在仓库里放笔记
* 在仓库里存调查结果
* 在仓库里保存故障报告
* 在仓库里保留架构讨论
六个月后:
* 搜索结果变得嘈杂
* 智能体发现过时的信息
* 重要的决策被埋没了
* 没人知道哪个文档是权威的
我们最终学会将以下内容分离:
**系统**
* 代码
* 运行时状态
* 配置
* 运维资产
与 **知识**
* 经验教训
* 故障分析
* 架构转向
* 准则
* 运维观察
代码仓库是为软件优化的。组织是为学习优化的。这两者不是一回事。
你如何处理那些需要跨越多次重构和系统代际而存活下来的运维知识?
相似文章
也许编程代理不需要更大的记忆。也许它们需要连续性
文章认为,编程代理需要连续性——即在仓库中保存执行历史和项目状态——而不是简单地拥有更大的记忆或上下文窗口,以避免在会话之间丢失操作线程。
为什么代码有版本控制但AI记忆没有?
文章指出,与代码版本控制相比,AI记忆系统缺乏版本控制和可观测性,并质疑当前记忆历史工具的状态。
我开始觉得“记住一切”对AI记忆来说是个错误目标
本文批判了企业AI记忆系统中“记住一切”的思路,主张将当前状态与历史记录分开存放,以防智能体使用过时信息。
我尝试构建自己的持久化记忆系统,然后意识到真正的问题是在数百次提交和重构后保持其可信度。为什么没有其他人这样做呢?
作者开发了'mex',这是一个工具,通过验证和修复记忆与代码库变更的一致性,为编程代理维护持久记忆,确保其长期保持可信度。
我们是否都在悄悄重建记忆系统,因为当前AI的长期记忆实际上并不奏效?
文章讨论了当前AI记忆方案在生产中常见的失败情况,如事实陈旧、摘要漂移和供应商锁定,指出真正的瓶颈在于记忆治理而非检索。