为什么你的代码仓库不应该成为你的记忆
摘要
本文警告不要将代码仓库用作组织的决策和知识记忆库,主张建立独立的知识管理系统,以避免信息噪声和关键资料被埋没。
我在AI项目中看到的最大扩展错误之一,就是将代码仓库当作组织的记忆库。起初这感觉很方便:
* 在仓库里放笔记
* 在仓库里存调查结果
* 在仓库里保存故障报告
* 在仓库里保留架构讨论
六个月后:
* 搜索结果变得嘈杂
* 智能体发现过时的信息
* 重要的决策被埋没了
* 没人知道哪个文档是权威的
我们最终学会将以下内容分离:
**系统**
* 代码
* 运行时状态
* 配置
* 运维资产
与 **知识**
* 经验教训
* 故障分析
* 架构转向
* 准则
* 运维观察
代码仓库是为软件优化的。组织是为学习优化的。这两者不是一回事。
你如何处理那些需要跨越多次重构和系统代际而存活下来的运维知识?
相似文章
也许编程代理不需要更大的记忆。也许它们需要连续性
文章认为,编程代理需要连续性——即在仓库中保存执行历史和项目状态——而不是简单地拥有更大的记忆或上下文窗口,以避免在会话之间丢失操作线程。
为什么代码有版本控制但AI记忆没有?
文章指出,与代码版本控制相比,AI记忆系统缺乏版本控制和可观测性,并质疑当前记忆历史工具的状态。
我们是否都在悄悄重建记忆系统,因为当前AI的长期记忆实际上并不奏效?
文章讨论了当前AI记忆方案在生产中常见的失败情况,如事实陈旧、摘要漂移和供应商锁定,指出真正的瓶颈在于记忆治理而非检索。
智能体记忆不仅仅是基于用户事实的RAG
文章认为,简单的基于RAG的智能体记忆系统在生产中会失败,原因包括过时的偏好、遗漏的关键词和提示注入等问题,并主张采用分层记忆架构,具备主动选择、确定性回退、治理和测试等功能。
如果无法忘记不良示例,智能体记忆的作用就会降低
文章认为,有效的智能体记忆必须能够忘记不良示例,因为保留这些示例会降低性能。