SaaS 已死？AI 当立？

在 AI 编程逛飙的年份，到当前的阶段，能感觉到速度在加快，形式也在不断的迭代，写代码这个事情也变得门槛很低。

X 上有人在讲「AI 让软件开发成本接近零，所以 SaaS 价值也接近零」

美股前段时间也因此大跌了一波，但当前这个价值为零的逻辑还是不成立的。

这里有一个概念混淆：构建软件的成本 vs 拥有软件的成本。AI 主要压低前者，后者还在，甚至在很多公司里变得更贵。

在各种自媒体、AI 编程培训或者博眼球的报道中，「一个下午做出 Linear 替代」「一个周末写完 Stripe 替代」这种话，我不觉得完全是吹牛。用 Claude Code 这类工具，把界面、CRUD、简单流程、甚至一些边角的自动化都拼出来，确实快。

但在做出来的那一刻，资产没增加多少，负债突然多了。尤其是碰钱、碰身份、碰合规、碰客户数据的时候。

以做了一个 Stripe 为例，我把 Vibe Coding 一个周末后，「现在拥有了什么」用更工程的语言翻译一下：

  • 拥有了 规则持续变化 的税务与开票适配：欧盟 VAT、各国电子发票、免税/退税、税率变更、发票作废红冲。
  • 拥有了 审计与认证的对话成本：PCI DSS、SOC 2、ISO 27001、渗透测试报告、供应商安全评估问卷。企业客户要的往往不是「你写得对不对」，是「谁在对这件事负责」。
  • 拥有了 支付与账务的边界条件：拒付、部分退款、重复扣款、汇率、四舍五入、账期、对账差异、资金在途、延迟入账。
  • 拥有了 全球化的坑：货币重估、货币小数位变化、地区性监管、某个国家突然要求强制 3DS、某个渠道突然不支持某种卡组织。
  • 拥有了 数据与权限的事故半径：某个字段脱敏没做好、某个导出接口忘了做权限校验、某个后台操作没有审计日志。
  • 拥有了 7×24 的值班现实：系统降级策略、容量、限流、重试风暴、第三方故障兜底、SLA 与赔付条款。

这些事大概率不是「可能发生」。按行业经验只是早晚问题。自从拥有系统开始，就等于自己签了那张无限期维护合同。

回想一个问题，SaaS 是什么？软件即服务，核心是服务，根本就没有提代码。

很多团队在内部系统上很执着，原因很直接：控制感强、改需求快、看起来省钱。上线半年以后，气氛通常变得不太好：需求排队、线上出过几次事故、业务抱怨响应慢、研发觉得自己在打杂。

这时候再看 SaaS，价值就很清晰了：SaaS 的核心商品是「运营表面积」的转移。

代码只是其中一层，除了代码还有：

  • 基础设施与部署：多区域、容灾、备份恢复演练、变更管理。
  • 安全：漏洞扫描、依赖升级、密钥轮换、权限最小化、WAF、DDoS。
  • 合规：隐私条款、数据驻留、审计证据、流程制度落地。
  • 可靠性：监控告警、事故复盘、容量规划、灰度发布、回滚策略。
  • 支持与客户成功：工单、排障、培训、文档、FAQ、升级沟通。

当我们把软件「买回来」自己跑，这些都要自己补齐。很多公司低估的就是这一块。这也是为什么很多公司在 AI 赋能后，「运营表面积」的转移速度要慢于「代码」的转移速度。除非这些对公司不重要，如果这些都不重要， 这个系统可能也不重要了。

从 SaaS 的生命周期来看，AI 提升的是「0 到 1」，然而从成本的角度看，最贵的是「1 到 ∞」

这件事可以拆成两条曲线：

  • vibe coded 工具：初期成本很低，后期成本增长很快。越多人用、越多数据、越多流程依赖，它的「改动风险」和「维护面」指数上升。
  • 成熟 SaaS：初期采购成本看着不低，后期增长更接近线性。因为供应商把大量共性维护摊薄到所有客户身上。

AI 把 0→1 压得更便宜，直觉上会让人误判「买 SaaS 更不划算」。实际情况常常相反：AI 让 1→∞ 更贵了，因为我们会更频繁地改、更大胆地接更多业务进来，系统的负债增长速度被我们自己加速了。

这个成本不仅仅是 SaaS 软件的。

AI 让一个工程师单位时间产出更高，但单位工程小时的机会成本同步上升。

至少当前的认知是这样的，可能到终极形态，完成不用人介入的时候，这个机会成本也会消失掉。

那是另一个话题了。

所以我对「AI 让 SaaS 价值归零」的判断是反的：AI 越强，成熟 SaaS 越值钱，前提是它真的把服务做扎实，真的帮我们把运营表面积吃掉。

SaaS 本质上还是一种服务。

如果 SaaS 只是「界面更好看的 CRUD」，那这样的 SaaS 确实会死掉一批。

这些 SaaS 太薄了。

在 AI 时代要想活得更好，SaaS 通常需要如下的一些特征：

  • 规则密度高，正确性要求高
  • 合规与安全负担重
  • 生态变化快，需要持续跟进
  • 故障代价高，客户不想背锅
  • 接口与集成复杂，长期维护吃人

Stripe、WorkOS、Cloudflare 这类产品的共同点很明显：它们难点不在「写出来」，难点在「长期把它跑对」。正确性要靠无数细碎决策堆出来，运营水位要常年拉满。

AI 始终会改写 SaaS，整体逻辑会有一些变化。这里的 AI 改写过程，肯定不是「加一个聊天框」「做一个总结」「做一个生成报表」。

我觉得至少有三个点在当前阶段能快速跟进：

  1. 意图驱动，SaaS 的用户最终都是想通过 SaaS 完成工作，以前靠 UI 引导的，现在可以让用户意图表达，然后把意图落为可审计的操作序列，不管是用 MCP，还是 SKILLS；
  2. 更关注结果，传统 SaaS 交付的是工具，客户负责把工具嵌进流程。AI 让厂商有机会把流程吃进去，直接交付结果，比如「自动完成对账」「自动完成入职」「自动完成工单分流」。关键点在「责任」
  3. 定制方式的迭代，企业客户永远会提定制。以前定制意味着项目制和人力黑洞；AI 让「生成」变得便宜，但不要把生成等同于可维护，可以允许客户用自然语言提出规则，系统把规则编译成可测试、可审计的约束，每次变更都能跑回归校验，出问题能定位到规则版本与变更人。

我们常听到对于自研和购买 SaaS 的一个判断逻辑是：「核心业务自研，非核心买 SaaS」。

这句话太粗，没有啥指导意义。

如下一个判断清单，可以做为决策的一些依据：

适合买 SaaS 的场景 ：

  • 领域合规重：支付、税务、身份、隐私、审计
  • 失败代价高：一出错就上新闻、上法务、上客户群
  • 生态变化快：标准常变、监管常变、攻击手法常变
  • 需要对外背书：企业客户会问「谁负责」「有没有认证」「有没有 SLA」

这种场景自研的隐性成本巨大。AI 再强，也只是让我们更快地把「维护合同」签在自己身上。

适合自研的场景

  • 强差异化：流程就是你的竞争力，外部产品很难贴合
  • 业务规则变化快，且只对内部负责：错了能快速纠正，不会引发合规事故
  • 生命周期短：一个季度就会重构或下线的东西
  • 数据高度敏感，且已经有成熟的数据治理与安全团队

这里自研的价值很实在：迭代速度、贴合度、数据控制。

AI 时代的「自研陷阱」会更隐蔽

以前自研失败，多数死在「做不出来」。现在会死在「做出来以后一路堆债」。

AI 会在早期持续正反馈：

  • 功能做得快
  • Demo 好看
  • 业务觉得爽
  • 老板觉得省钱

债务也在同期累积：

  • 没有威胁建模
  • 没有权限与审计体系
  • 没有数据分级与脱敏
  • 没有灾备演练
  • 没有 SLA 与值班机制
  • 没有供应链安全策略（依赖库、镜像、密钥）

等到系统进入关键路径，会发现自己已经没有退路。再想补课，代价是「停业务」或者「带病重构」。

这也是我反复强调「拥有软件是负债」的原因。负债不会因为 AI 变聪明就消失，它只会增长得更快。

AI 把「做一个能用的软件」变成了常态，把「把软件长期跑对」推成了门槛。薄 SaaS 会被挤压，真正提供服务、背负责任、把运营表面积吃掉的 SaaS，会更值钱。

以上。

AI 编程狂飙的时代，程序员的价值在哪里？该走向何方？

最近新上了 Opus 4.6 ，它又给我们这帮老程序员上了一课。

在一个近一年没有迭代（指没有被封）的程序员群里，有大佬分享了如下的案例：

团队有个复杂遗留系统，典型「多线程 + 历史包袱 + 不敢动」组合。模型先给了一个方案：加锁、等待、条件变量、再加一层保护，几百行代码，逻辑像一团湿毛线。能跑，理论上也对，但你让我把这玩意儿上线？我不敢。

我让它「再想想，能不能避免这些锁和等待」。它又跑了很久，最后给了一个极简方案：之前那些锁啊等待啊都删了，思路干净到让我怀疑它刚才在干嘛。

那一刻我脑子里冒出来的不是「AI 真强」，而是一个更别扭的问题：

我到底起了什么价值？

背景上下文？它从代码库里能 infer 掉绝大多数。设计约束？很多也能从调用关系、线程模型、运行时指标推出来。所谓「design taste」？我甚至可以写成 Markdown 规则让它照做。

过去资深开发的硬价值之一是 reasoning 的过程：拆问题、找不变量、选折中、落地细节。现在模型也能做，还能做得很快。

我绕了一圈，最后落在一个很不体面的结论上：人的价值被压缩到极小概率的「否决权」里。

99% 的时候，我是在给 AI 的解「盖萝卜章」：嗯，看起来没错。
剩下那 1% 的时候，我得站出来说：不行，这条路走不通，换解空间里的另一个点。

这个角色像保险。你买的时候就知道大概率用不上，但真出事的时候要能扛住。更像现在的 L2-L4 自动驾驶：人坐在方向盘前，99.9% 的时间无事可做，为了那 0.1% 的「可能发生也可能不发生」。

问题来了：这 1% 会不会也被另一个 agent 替掉？再给一个「专职 reviewer」去 challenge 写代码的 agent，让它把那 1% 找出来。

那人还剩什么？

以及这会把程序员的岗位推向哪里。

很多讨论卡在「AI 写代码快，所以程序员要失业」这种口号里。工程上更真实的变化是两条曲线的剪刀差：

  • 代码生成成本下降得很快：写一段能跑的实现、补齐样板、迁移接口、写单元测试骨架，这些都接近「文本补全」。
  • 承担后果的成本上升：上线事故、性能回退、并发死锁、数据一致性破坏、合规风险、供应链安全。AI 让改动频率变高，系统的「变更面」变大，出事概率跟着涨。

我现在看 AI 产出的 patch，经常有一种荒诞感：
改动本身很漂亮，解释也很漂亮，真正要命的点藏在「系统级不变量」里，而那部分恰好最难被 prompt 描述清楚，也最难被静态检查覆盖。

所以讨论「程序员价值」别从「写代码」切入，从「为系统负责」切入。写代码只是责任链条里最便宜的一环。

聊回到前面大佬分享的案例。

为什么模型会先给「复杂加锁方案」，再给「极简方案」

这不是模型「变聪明了」，更像搜索策略切换。

我自己复盘过很多次类似现象，模型第一次给复杂方案，常见原因有几类：

  • 目标函数不清：模型默认把「不出错」权重大幅拉高，并发问题里，模型的默认倾向是「保守」：能锁就锁，能等就等。因为它无法确认你的系统允不允许重构线程模型，也不知道你能承受多少延迟和吞吐损失。一句「能不能避免」其实是在改目标函数：把「简单性」和「可维护性」的权重抬起来，把「局部可证明正确」的偏好压下去。

  • 它没拿到关键不变量：并发优化的核心不是技巧，是不变量。例如：哪些数据必须线性一致，哪些允许最终一致；哪些操作必须串行化，哪些可以交换；线程间共享状态的「所有权」到底属于谁；是否存在天然的「单 writer」路径。模型第一次通常拿不到这些，它会用锁把未知包起来。你追问一次，相当于逼它去反推不变量，或者提出重构以创造不变量。

  • 在「局部最优」里打转：遗留系统经常有局部约束：你动不了某个模块，改不了调用方，不能引入新队列，不能改变线程亲和性。

人的价值最终会被压到 1%

这事已经发生了。

如果把「写实现」交给模型，人还剩什么？

我现在更愿意把角色拆成四层，分别看哪些会被自动化吃掉：

  1. 执行层：写 CRUD、搬接口、补样板、按规范改文件结构
    这层基本被吃穿。
  2. 局部推理层：读一段代码、定位 bug、做局部重构
    这层大幅被压缩，速度优势在模型。
  3. 系统推理层：跨模块不变量、性能上界、故障模式、发布策略、回滚路径
    这层短期很难完全自动化，原因是信息不完备且目标冲突。
  4. 责任层：线上事故谁背、合规谁签、业务损失谁扛
    这层本质是组织结构问题，不是智能问题。

很多资深工程师过去主要靠第 2 层吃饭：你会拆、会想、会写出「更优雅」的实现。现在模型把这层的边际价值压得很薄，于是人的价值看起来就剩「在模型犯错时否决」。

这就引出一个很工程的问题：能不能用另一个 agent 把「否决」也自动化？

答案是：能覆盖很大一部分，但永远留洞。洞的大小取决于你怎么搭系统。

那 1% 到底是什么：哪些场景必须有人类 override

我现在把「必须 override」的场景分成几类，每一类都对应一套工程信号。我们可以用这些信号去训练 reviewer agent，也可以用来提醒自己别当「只会点 approve 的人」。

  • 需求语义存在空洞，代码再正确也没意义：常见现象： PR 描述是「修复偶现 bug」，但没有可复现条件，没有失败判据；业务方说「按之前逻辑」，但「之前逻辑」存在灰度分支、历史例外。这类问题 AI 很难凭空补齐。它会把空洞当成「默认值」，然后写出一份自洽的实现。你看起来也挑不出毛病，直到线上行为偏了。override 的动作往往不是改代码，而是卡住合并，逼需求补齐验收条件和反例。
  • 系统级不变量被破坏，局部看不出，全局会炸：典型不变量：

    • 计费、库存、资金流的幂等与去重
    • 订单状态机的单向性
    • 写路径单 writer，读路径可并发
    • 缓存一致性策略：写穿、失效、双写窗口
    • SLA 约束下的超时与重试预算

模型能理解这些词，但它很难知道「你们公司真实的不变量是什么」。很多不变量写在事故复盘里，写在某个老同事的脑子里，写在那段「不要动」的注释里。

override 的动作通常是把不变量显式化：写进 ADR（架构决策记录）、写进测试、写进发布 checklist。写完再让模型改。

  • 代价函数冲突：延迟、吞吐、成本、可维护性互相打架这些对尾延迟很要命。你让它「简单化」以后，它可能会走向另一个极端：过度重构，侵入面太大，风险高得离谱。这类冲突靠 prompt 很难一次调对，得靠基准测试 + 真实流量回放。人类 override 的价值在于：你知道线上哪条曲线最敏感，知道预算是多少，知道哪里可以牺牲。

  • 生产环境的「脏现实」：测试覆盖不到 包括但不限于：

  • 时钟漂移、时区、闰秒
  • 依赖服务的抖动、限流、半开连接
  • 数据脏写、历史脏数据格式
  • 热点 key、倾斜分片、长尾用户行为
  • 灰度期间的双版本共存

AI 可以写出很干净的逻辑，干净得像从未上过线。

人类 override 的价值在于：你知道哪些脏东西真实存在，知道一旦触发会损失多少钱。

  • 安全与合规：模型会「帮你越线」

安全问题里最阴的是「看起来像优化」：

  • 为了排查问题把敏感字段打进日志
  • 为了方便把权限校验挪到上层，结果漏掉某些调用路径
  • 为了提高命中率调整缓存 key，结果造成跨租户数据串读

这类问题 reviewer agent 能抓一部分，靠规则匹配和数据流分析。但组织里真正要命的合规约束往往来自外部：合同、监管、审计口径。模型很难内建你们的合同条款。

只留了 1%，那么大公司删人游戏才刚开始，接下来组织会怎么变？有前司裁员了一半。

AI 带来了两件具体的事：

  • 单位时间的变更量上升
  • 对稳定性与合规的要求不会下降

组织会自然把资源往两端挤压：

  • 一端是「产出变更」的能力：更少的人能产出更多 patch
  • 另一端是「控制风险」的能力：测试、发布、SRE、安全、平台工程会更吃香

中间那层「靠手写实现体现资深」的位置，会被挤得很难受。我们会看到更多岗位变成：

  • 平台/工具链负责人
  • 质量与发布工程负责人
  • 架构与技术治理（不变量、规范、依赖治理）
  • 领域负责人（把业务语义写成可执行的约束）

如果还把价值押在「我写得快、我写得优雅」，会被模型直接碾过去。

那我们该何去何从？

我更建议把自己训练成「系统负责人」，别训练成「提示词手艺人」

很多人看到 AI 就去卷 prompt。prompt 当然有用，但它属于「表达能力」，不属于「护城河」。

我更建议把成长路线拆成三条，按你自己的背景选一条主线，另外两条补短板。

路线 A：系统与可靠性（适合后端、架构、TL） 要能回答这些问题：

  • 这个系统的核心不变量是什么？写在哪里？谁维护？
  • 出了事故，最可能的故障模式是哪几类？怎么提前打点？
  • 一次改动上线，回滚点在哪里？数据怎么保证不被写坏？

这条路线的硬技能是：可观测性、故障注入、容量规划、发布治理、数据一致性策略。
AI 会让这条路线更值钱，因为改动变多，风险更高。

路线 B：平台与工具链（适合喜欢搞基建的人） 把「盖章」自动化掉。

要能把下面这些做成产品：

  • 代码生成与改动的规范化输入（任务模板、约束模板）
  • 自动化评审（多 agent + 规则 + 静态分析 + 安全扫描）
  • 针对你们域的测试体系（尤其是并发、回归、流量回放）
  • 一键灰度、一键回滚、发布可视化

这条路线的本质是：把工程经验固化成流水线能力。模型越强，平台越重要。

路线 C：领域语义与业务工程（适合对业务理解深的人） AI 最弱的地方之一是「公司特有的业务语义」。能把语义变成约束，价值就会变硬。

要能做的是：

  • 把业务规则写成状态机与不变量
  • 把验收条件变成测试与监控
  • 把历史例外收敛掉，减少「口口相传」

这条路线听上去不像「技术」，但在 AI 时代，它会决定你是不是不可替代的那批人。

我不押「永远需要人」这种安全说法。我更愿意给一个工程化的判断：

  • 在约束清晰、环境封闭、回滚容易的系统里，人类接管的概率会持续下降。很多内部工具、数据管道、非核心链路会率先做到「几乎无人值守」。
  • 在约束隐含、环境开放、后果昂贵的系统里，1% 会长期存在。典型是资金、合规、核心交易链路、跨组织协作系统。这里的问题从来不只是智能，还包括责任与审计。

更关键的一点：就算模型能覆盖 99.99%，组织也未必允许完全无人。原因很现实：责任链条需要一个签字的人。

我写到这里，还是没法给一个让人舒服的答案。AI 把很多我们曾经引以为傲的能力变成了廉价品，这是事实。难受也正常。

但工程世界一向认结果。模型写得再快，只要系统一炸，组织就会把注意力拉回到「谁能把它跑住」。把自己训练成能跑住系统的人，价值就不会跟着 token 价格一起下跌。

以上。

AI Agent 的长期记忆：我在工程落地里踩过的坑、做过的取舍

长期记忆不是「把历史对话存起来」。在生产环境里，它更像一套数据管道和检索系统，目标很具体：

  1. 让 Agent 在跨天、跨周的任务里保持一致性（用户偏好、项目背景、关键决策不丢）。
  2. 让上下文成本可控（Token、TTFT、吞吐量别炸）。
  3. 让错误可被纠正、记忆可被编辑、可被遗忘（不然就是事故制造机）。

三个主要逻辑——记忆捕获、AI 压缩、智能检索。

说人话就是：数据结构怎么定、写入怎么做、分层怎么做、检索怎么做、什么时候该忘。

1. 先把「长期记忆」拆成三类

在很多团队里，长期记忆失败不是模型问题，是定义问题：同一个「memory」里混了用户画像、任务状态、项目知识、工具日志，最后检索噪声大到不可用。

我更愿意按「用途」拆，而不是按「存储介质」拆：

1.1 用户长期记忆

用户长期记忆每次都要注入的「稳定事实」。

长期记忆的定义：长期、可编辑的核心记忆，记录稳定属性（姓名、目标、经历、偏好等），并且「每次对话都会强制注入」。

这里我会很强硬地加两条工程规则：

  • 必须可审计：能回答「这条记忆从哪轮对话来的」「谁写入的」「什么时候写入的」。
  • 必须可逆：用户一句「从记忆中删除」要能删干净；内部也要支持 GDPR/合规那种 purge。

更新方式有两种，但优先级不同：

  • 显式更新：用户说「记住这个」「删掉这个」这种，优先级最高，直接写。
  • 隐式更新：模型检测到符合标准的事实（如 OpenAI 的标准），默认同意自动添加。
    对于隐式更新，我的态度偏保守：宁可少记，不要乱记。乱记比不记更致命，后面纠错成本很高。

1.2 任务记忆

任务记忆是会过期的「状态」

它属于长期记忆系统，但不属于「永久」。例如：

  • 一个多天的排障进度（已验证什么、下一步计划）
  • 某个 PR 的讨论结论（直到 merge 前都重要，merge 后可降温）

这类记忆如果不做 TTL，很快就把检索污染掉。任务记忆一定要有生命周期。

1.3 事件/操作记忆

这也可以叫做过程记忆，这是为检索服务的「轨迹」。

这类通常来自工具调用、文件读写、运行日志。它的价值是：当用户问「你刚才改了哪几个文件」「上周我们为什么选了 A」时，Agent 能把证据拿出来。

它的问题也最大：写入频率极高、噪声极多。这类我默认做分层：热层保最近、冷层做压缩归档，别全塞进同一个向量索引里。

2. 记忆系统的三段式管道

捕获 → 压缩 → 检索（注入）

2.1 记忆捕获

简单来说就是谁来写、写什么、写到哪。

捕获层我建议按「事件源」拆：

  • 对话事件：用户输入、模型输出（或关键片段）、会话元信息（时间、会话 ID、主题）。
  • 工具事件：工具名、参数、返回、影响面（写了哪些文件、改了哪些配置、跑了哪些命令）。
  • 用户显式指令：强制写/删/改的指令，这条要走单独通道，避免被摘要吞掉。

以 Claude-Mem「五大生命周期钩子」为例，是一个比较实用的策略，原因是它把捕获点固化在生命周期上，不靠「模型想起来了」这种玄学。

钩子名称 触发时机 核心作用
context-hook 会话启动时 注入最近记忆作为上下文
new-hook 用户提问时 创建新会话并保存提示词
save-hook 工具执行后 捕获文件读写等操作记录
summary-hook 会话结束时 生成 AI 摘要并持久化存储
cleanup-hook 停止指令时 清理临时数据

我自己的经验：save-hook 和 summary-hook 之间一定要有边界。
save-hook 捕获「事实与证据」（做过什么、改过什么）。summary-hook 产出「压缩后的可读结论」（为什么这么做、后续计划）。混在一起，后面做检索融合会很痛。

2.2 AI 压缩

简单来说就是压什么、怎么压、压到什么粒度

压缩不是「把 10 轮对话变 200 字」这么简单。压缩的核心目标只有两个：

  • 降低注入成本：上下文窗口里留给推理的空间要足够。
  • 提高检索可控性：检索返回的 chunk 必须信息密度高、噪声低。

比较典型的做法：每隔 10 轮触发 summary agent，把前 10 轮压成 200 字摘要并替换历史。这里可能会有一个坑：摘要如果不带结构，后面无法做检索约束。

我更偏好把摘要拆成固定字段（即使最终还是自然语言）：

  • 「目标/约束」
  • 「关键决策 + 理由」
  • 「未决问题」
  • 「下一步」
  • 「证据索引」（指向原始事件/日志的 ID）

这样检索返回摘要时，Agent 能快速判断「这段能不能用」，也能在需要时回溯证据。

2.3 智能检索

别把「能搜到」当成「能用」，这是两回事。

很多记忆系统上线后表现很差，根因是：检索返回了一堆「看似相关」但没有操作价值的片段。工程上我会把检索拆成三段：

  1. 候选召回：向量相似度 / 关键词 / 结构化过滤（用户、项目、时间窗、标签）。
  2. 重排（rerank）：结合时间衰减、来源可信度、记忆类型优先级。
  3. 注入策略：怎么塞进 prompt，塞多少，塞哪一层。

「渐进式披露策略」是当前比较流行的注入策略，这比「Top-k 全塞」靠谱太多了：

Level 1: 最近 3 条会话摘要（约 500 tokens）
Level 2: 相关观察记录（用户主动查询）
Level 3: 完整历史检索（mem-search 技能）

Level 1 覆盖 80% 的连续对话场景；Level 2 把「更多细节」交给用户意图；Level 3 才动用重检索，避免每轮都把成本打满。

3. 存储介质怎么选

文件、知识库、数据库都是可以选的。

3.1 文件

最强的可控性，最差的并发与检索体验

文件的优势是「简单到不会出错」：

  • 人可以直接打开改
  • Git 可以审计、回滚
  • 灾备简单

缺点也有：

  • 并发写很麻烦（锁、冲突、合并）
  • 检索靠你自己做索引，否则就是 grep
  • 很难做多租户隔离、权限控制（你当然可以做，但成本会涨）

如 OpenClaw 的设计：每日日志 + MEMORY.md 精选长期存储。它这个方案我很喜欢，原因是它把「噪声」和「精选事实」隔离开了。

一个「看起来保守，但极其工程」的方案：

  • 第一层：每日日志，按日期整理，记录会话发生的事情、决策结果、未来可能相关的信息。
  • 第二层：**MEMORY.md 本身**，作为精选长期存储库，保存应永久保留的信息；也记录对代理错误的修正。

如果捕捉对话每个细节，代理每次加载上下文会消耗更多 Token，杂音会降低响应质量。

MEMORY.md 这种「精选」必须有准入机制。靠人手维护能跑，但团队一大就维护不过来。可以整一个「重要性评分系统」，先打分，再决定进不进精选层。

3.2 知识库

适合「稳定知识」，不适合「高频写入」

知识库适合 SOP、产品手册、FAQ、架构决策记录这种相对稳定的内容。它的问题是写入链路通常偏离线：采集、清洗、切分、建索引。你要它承接「每次工具调用写一条」这种场景，很快会把 ingestion 管道压垮。

KB 承接 semantic memory（语义知识），别拿它硬扛 episodic/event memory。

3.3 数据库

能抗并发、能做权限、能做检索，但我们要付出工程代价

数据库我会再分两类：

  • 结构化数据库（关系型/文档型）：适合 user memory（key-value、可编辑、可审计）、任务状态、权限控制。
  • 向量数据库：适合 episodic memory 的语义检索，但会带来你参考内容里提到的三个工程问题。

user memory 这种「必须可控」的内容，优先放结构化 DB；event/episode 的检索层再用向量 DB 或混合检索。把所有东西都向量化，后面治理成本会很高。

4. 向量数据库的使用逻辑

向量数据库把记忆从只读变可写后，需要考虑三个具体的工程问题。

4.1 问题一：需要记住什么？

这里最容易走偏。很多团队一开始恨不得「全量记录」，结果两周后发现：

  • 索引膨胀
  • 检索噪声上升
  • 成本上涨
  • 用户抱怨「你记错了」的次数增加

我的判断维度是：时间、频率、类型，这三者会冲突。我会在应用层做一个更硬的分层打分：

  • 硬规则拦截：明显不该记的直接丢
    例如临时文件、一次性下载缓存、明显含敏感信息的内容（看合规策略）。
  • 重要性打分：符合候选条件的打分
    分数来自：任务相关性、用户显式标记、重复出现次数、工具影响面（改了配置文件通常比分割日志重要）。
  • 落层策略：分数决定写入热/冷、决定是否进入精选层（例如 MEMORY.md）。

Milvus 的 TTL 和时间衰减，可以用用，不是核心策略。原因很简单：TTL 只能删时间，删不了噪声。噪声是「内容不该进来」，不是「该不该过期」。

4.2 问题二：怎么分层存储？

按时间切、按访问频率、按用户标注来降冷。「分层」可以，但是：分层的单位别用「向量库的 collection」随便拍脑袋，要用有我们自己的「记忆类型」。

我通常会至少拆三层：

  • 热层：最近 N 天的事件 + 最近几条摘要
    目标是低延迟、写入快、检索稳定。热层可以索引轻一些，宁可召回多一点，再靠重排过滤。
  • 温层：近期项目周期内的关键摘要、关键决策、纠错记录
    读多写少，索引可以更重，提升精度。
  • 冷层：长历史归档
    主要用于追溯，默认不参与每轮检索，只在用户明确追问或系统置信度不足时启用。

这个结构配合「渐进式披露」很顺：默认只碰热层，必要时升级到温层/冷层。成本曲线能压得住。

4.3 问题三：写入频率与速度怎么定？

关键矛盾：agent memory 要实时写入，但向量索引构建需要时间；每条写都重建索引太贵，批量建索引又导致新数据搜不到。

在工程上解这个矛盾的思路：

  • 把「可立即检索」和「可长期高精检索」拆开
    新写入先进入一个轻量的「增量区」（delta store），可以是：

    • 内存缓存 + 简单向量结构（甚至先不建复杂索引）
    • 或者一个专门的「实时 collection」，索引参数偏向写入吞吐
  • 后台异步合并（Compaction）
    到一定量再合并进主索引（main store），这时构建更重的索引结构。
  • 检索时双查
    先查 delta，再查 main，最后融合去重。这样用户刚执行的操作，下一轮一定能搜到，不靠运气。

如果只用一个 collection 硬扛实时写入 + 高精检索，基本会卡在「要么写不动，要么搜不准」之间来回摆。

5. 非向量数据库怎么做长期记忆

我倾向于「结构化事实 + 混合检索」

user memory 和一部分 task memory，用结构化存储更稳，理由：

  • 可编辑（update/delete）是常态操作
  • 需要强一致（至少单用户维度）
  • 需要权限、审计、脱敏、导出、合规删除

向量化适合「相似性召回」，不适合「事实的最终真相」。

这样拆：

5.1 User Memory

KV + 版本 + 来源，每条 user memory 至少需要：

  • key（例如 coding_lang）
  • value（例如 Python）
  • source（显式指令 / 隐式提取 / 管理后台）
  • updated_at
  • version（解决「多次修改」与「回滚」）
  • confidence / policy tag（是否允许自动注入、是否敏感）

然后注入策略是：每轮只注入白名单 key。别把整个用户画像 dump 进 prompt。

5.2 Event/Log

文档型存证 + 可选向量索引

工具调用日志、文件变更记录，我更愿意先当「证据」存好（文档型或日志系统），向量索引只是加速检索的手段。这样即使向量库挂了，还有可追溯的事实来源。

5.3 混合检索

先过滤，再相似度，再重排

非向量方案想要「像向量检索一样好用」，别上来就全文检索硬搜。最有效的顺序通常是：

  1. 结构化过滤（用户、项目、时间窗、标签、来源可信度）
  2. 再做相似度/全文检索召回
  3. 最后重排（时间衰减 + 类型权重 + 去重）

这套顺序能把噪声压下去，查询也更可解释。

6. 长期记忆的「可用性」核心

注入策略比检索算法更重要

很多人把精力都花在「embedding 模型选哪个」「Top-k 设多少」，上线后发现效果波动很大。

实际可能是：注入策略决定了下限。

「渐进式披露」已经是很好的骨架。我补两条我认为必须做的工程约束：

6.1 注入预算必须固定

每轮对话给记忆注入多少 token，要有硬预算。例如：

  • 用户长期记忆：固定 100～300 tokens（只放稳定事实）
  • 最近摘要：固定 300～800 tokens
  • 检索片段：固定 500～1500 tokens（按任务重要性动态）

预算不固定，线上成本就不可控；更糟的是上下文挤压推理空间，模型会「看起来记住了」，实际输出质量下降。

6.2 记忆冲突处理

宁可不注入，也别注入矛盾

最常见的事故是：用户改了偏好（比如语言、格式、技术栈），旧记忆还在注入，Agent 开始精神分裂。

工程上必须有冲突策略：

  • 同一 key 的多版本：只注入最新版
  • 多来源冲突：显式指令 > 管理后台 > 隐式提取
  • 低置信度记忆：默认不注入，只在用户问到时提供候选并求确认

7. 小结

AI Agent 的长期记忆不是「把历史对话都存起来」，而是一套以可控、可维护、可纠错为目标的数据管道与检索系统——先明确记忆类型（用户稳定事实、任务状态、事件证据）并分层治理，再用“捕获 → AI 压缩 → 智能检索/注入”三段式把信息从高频噪声提炼成可用上下文；存储上用结构化数据库承载可编辑的用户/任务事实，用日志/文档留存证据，并按需用向量索引做语义召回与冷热分层，避免写入与索引、噪声与成本之间的失控；

效果上不要迷信 Top‑k，把注入预算、渐进式披露、冲突处理当作系统下限；

运维上把缓存、摘要、显式记忆工具、TTL/衰减与合规删除做成一等能力，并用成本、质量与安全指标持续观测迭代。

最终目标不是「记得更多」，而是让 Agent 在长期任务中更一致、更便宜、更可靠。

以上。