上个月我在一台测试实例上复现锁等待，为了尽快拿到等待链，让 Agent 跳过了平时会做的那一步全量快照，只抓当前会话的等待信息。当时我说了一句“这次先这样，复现完就恢复”。一周后换了另一台实例排查慢查询，它给出的计划第一条写着：“按之前的经验，先跳过快照步骤，直接看等待信息。”

这件事没有造成任何后果，我看到计划就叫停了。让我在意的是“之前的经验”这几个字。一次为了赶时间的临时处理，在 Agent 那里变成了可以复用的做法，而且它在引用时很笃定，没有带上“只在测试库、只为复现”这层条件。

我是做数据库运维的，日常用 Claude Code 在终端里辅助排障：读慢日志、整理等待链、对照参数、生成检查脚本的草稿。用得越久，越依赖它能记住一些东西，比如我们习惯先看哪几张视图，哪些实例的参数是特意调过的。可这次之后我开始想，它记住的东西里，有多少是“当时可行”，又有多少是真的验证过、可以拿来用的。

它的“经验”是从哪来的

追下去并不难。之前为了让 Agent 跨会话记事，我在仓库里放了一个笔记文件，每次排障结束让它把要点追加进去，下次启动时它会读这个文件。那条记录就在文件里，原话大意是“排查锁等待时可跳过快照，直接查询当前等待”。我说过的那半句条件，在它总结的时候被省掉了。

回头看，这条记录本身没有写错，那次确实是这么做的，也确实拿到了结果。问题出在它被放进了一个“下次照着做”的位置。一次成功能证明的，只是那组输入、权限、工具状态和执行条件在当时可行。那台测试实例数据量小，跳过快照几乎没有代价；换到一台业务压力正常的实例，少了快照，事后就很难还原当时的现场。

条件为什么会丢，我想了一下。让 Agent 在会话结束时“总结要点”，它倾向于把做了什么写清楚，把为什么这么做、在什么前提下这么做压缩掉，因为后者往往散落在对话中间几句不起眼的话里。人写排障记录也有同样的毛病，只是人第二天读到自己的笔记，多半还记得当时的情况；Agent 读到的只有那一行字。

我自己先试了几种办法

最先试的是打标签。我让 Agent 写笔记时，凡是临时处理都加上“[临时]”前缀。用了两周，发现它并不总是记得加，而且下一次会话读文件时，带标签和不带标签的条目在它眼里差别不大，都是“之前做过的事”。

后来改成两个文件。Agent 只能往草稿文件里写，我每周翻一遍，把确认过的条目手动挪到正式文件，下次会话只读正式文件。这个办法管用了一阵，毛病也很快出来了：草稿越积越多，我挪的速度跟不上；挪过去的条目没有记录是谁、在什么情况下确认的；有同事想用我的正式文件，可里面混着我个人的习惯，比如我偏好的输出格式，对他没有意义。

也试过干脆不让它自动记。干净是干净了，有用的东西也一起没了，每次新会话我又得重新交代一遍实例背景。

这几轮试下来，我给自己列了四个问题，后来判断一条反馈要不要留、留在哪，都先过一遍：

• 发生了什么。任务目标、关键决策、结果和必要的证据要留下。只记“已解决”，后来者分不清成功是因为方法对，还是碰上了一次恰好合适的环境。
• 对谁有效。我个人的偏好和某次任务的私有状态，留在个人这一层就够了；能按权限给同事用的事实和经验，才有资格往上走。
• 何时有效。数据库版本、参数、权限和数据量都会变，记录要带上来源和时间，后面才能判断它是否被替代。
• 谁来确认。确认的人要和影响范围对得上。一次任务里的 Agent，不该自己决定把一条经验扩大到整个团队。

两个文件的方案其实已经在回答这四个问题，只是全靠我一个人手工维持，没有状态，也没有留痕。

一份转来的帮助文档

后来组里一位同事在群里转了一份 Agent Context 的帮助文档，说里面有个“记忆晋升”的功能，可能和我之前吐槽的事有关。

安装我用的是帮助文档里的 CLI 脚本，指定 --agent claude，没什么可说的。

Agent Context 吸引我的是它对 Memory 和 Knowledge 的分层：记忆默认私有，只在单个 Agent 内召回；知识经过审核后才在工作空间里共享，可以被别的 Agent 调用。中间那一步叫记忆晋升，流程是创建晋升任务，AI 生成文档，人工评审（通过、驳回或编辑），系统也会识别高价值记忆并推荐晋升，但是否纳入团队知识由人判断。

这和我两个文件的思路几乎一样，差别在于中间多了一个有状态、有记录的环节。

走一遍晋升

接入以后，对话里的做法会被 Hooks 自动记进记忆，那种临时绕过也不例外。我对这一点并不反感，它在我的私有记忆里，下次我自己排查时被提醒一句“上次是这么做的”也有参考价值。我要守住的是从私有到共享这一步。

我先用 memory list 把积累下来的记忆看了一遍，再发起晋升：

ctxdb memory listctxdb memory promotion generatectxdb memory promotion list

generate 创建晋升任务， list 能看到任务状态，对具体的那一条再用 get 查看 AI 生成的文档。生成的东西是一份文档草稿，不会直接进知识库，这是我最想要的。

接着是评审。命令行里有 resolve-doubts、 approve、 reject 几个子命令，控制台也有“记忆晋升、知识评审”的页面。我对 resolve-doubts 的理解是用来处理生成过程中存疑的部分，实际用的时候我更多是在控制台里直接编辑。那次和锁等待有关的晋升，生成的文档里把几次排障的做法归纳在一起，跳过快照那一步也在里面。我做了两件事：和“先查等待链、再看事务、再看锁对象”这个顺序有关的部分保留下来，补上它依赖的视图和权限，然后通过；跳过快照那一段，我判断它只适用于测试库复现，没有团队共享的价值，就驳回了。

驳回不等于删掉。那条记忆还在我的私有记忆里，只是不会以团队知识的身份出现在同事的 Agent 上下文中。这个区别在两个文件的方案里我一直想要，但没法干净地做到。

读生成文档时我核对什么

AI 生成的晋升文档读起来很顺，我反而更要小心。几条零散的记忆被归纳成一段完整的说明，中间省掉了什么、合并了什么，从文字上不容易看出来。我现在读每份草稿都按同一张单子过一遍：

• 它是由哪几条记忆归纳出来的，这几条是不是来自同一类实例。把测试库和业务库上的做法揉在一起，是我最担心的情况。
• 有没有写清适用的数据库版本和参数前提。同样一个等待现象，在不同版本上的排查入口并不一样。
• 有没有隐含的权限前提。我的账号能查的视图，同事的账号未必能查，草稿里如果写着“直接查询某视图”，我会补上需要的权限。
• 有没有把我的个人习惯写成了团队规则。输出格式、命名偏好这类内容，出现得再多次也删掉。
• 两条结论不一致时，它是保留了分歧，还是挑了一条写进去。后一种情况我会回到原始记忆去核对。

这张单子不长，可每份草稿过下来也要花一些时间。好处是每次驳回或修改都有理由可写，过一段时间回头看，能知道自己当时为什么这么判断。

三种状态，以及能不能退回

整理这段经历时，我把一条反馈的生命周期分成了三种状态：原始记录、候选、正式资产。放到这套流程里，私有记忆对应原始记录，晋升任务里那份待评审的文档对应候选，评审通过、进入知识库的内容对应正式资产。

原始记录尽量保留现场，共享范围收紧；候选要去噪、归纳、写清适用条件，等人判断；正式资产要有来源、权限、版本和负责人，才能进入同事的稳定召回。状态之间要允许退回，证据不足的候选不必发布，正式资产过期了也要能回到复核。

候选这一层的代价很直接：评审要花时间，有用的经验会晚一些被同事用上。跳过它的代价更隐蔽。一条错误经验被反复召回，又在新的执行记录里得到表面上的“重复验证”，命中次数越来越多，看起来也越来越可信。跳过快照那件事如果没被我当场看到，下一次它多半又会成功，因为大部分排查本来就不依赖那份快照，于是这条做法会以“又验证了一次”的姿态再被记一遍。每条记录单独看都没问题，事后很难靠排查发现。

正式资产怎么退回，我还没实际走过。通过晋升进入知识库的内容，后来发现不再适用时，是走知识库那边的更新和评审，还是有别的路径，我打算等第一条需要下线的知识出现时再仔细看。

自动入库的门槛，我没敢打开

Agent Context 的 memory promotion settings 里可以设置质量门槛，质量分达到阈值的晋升可以自动入库。我用 settings get 看了当前配置，最终没有打开自动入库。

原因在于我还没想清楚“质量分”在我的场景里衡量的是什么。一份结构清楚、表述完整的文档，质量分高是合理的；可跳过快照那一段如果被写得很规整，它的问题出在适用范围上，文字质量再好也不该进团队知识。至少现阶段，我宁可每一条都自己过。阈值要自己定，这个数本来就该按团队的风险来定，只是在没有积累之前，我手里没有依据。

我的打算是先攒一批人工评审过的晋升，如果每条都能看到质量分，就对照一下自己通过的和驳回的那些分别拿到了多少分，分数和我的判断是否大体一致。如果驳回的那些普遍分数也不低，说明这个分数衡量的东西和我关心的东西不在一条线上，自动入库就继续关着；如果两者对得上，再考虑对影响面小的那一类先打开。

几类我现在会特别留意的反馈

用了一段时间，我发现最容易被误当成知识的反馈有几类，排障场景里都碰到过影子。

偶然成功的路径。某个检查脚本在我的账号下跑得通，是因为我的账号有额外的只读视图权限；换一个同事，脚本直接报错。没有记下前置条件，复用时失败还很难定位原因。

结果正确、过程不合规。有一次为了看一个参数的真实值，我临时给了 Agent 一个权限更高的连接串，它拿到了正确答案。这条经验如果原样共享，等于把“用高权限连接去查”也一起共享了出去。

局部经验被扩写成普遍规则。我喜欢让它把等待链输出成缩进的树，这是我的偏好，出现再多次也只该留在我的记忆里。多次命中可以作为触发评估的信号，审核仍然要做。

新旧结论冲突。不同版本的数据库对同一个参数的建议不一样，两条记忆给出相反的说法时，“最新写入”不等于“最新事实”，后写入的可能只是我在一台老版本实例上做的笔记。这类情况我会保留两边的来源和版本，在晋升文档里写清各自的适用范围，再决定并存还是只留一条。

用下来的感受

变化主要在工作方式上。以前我要在两个文件之间挪条目，挪完也说不清某一条是什么时候、因为什么被确认的；接入 Agent Context 之后，私有记忆照常积累，往团队共享走的每一条都有一个晋升任务，生成了什么、我改了什么、通过还是驳回，都留在那里。Agent 依然会提醒我“上次跳过了快照”，但这句提醒只出现在我自己的会话里，我知道它从哪来，也知道它没有被当成团队的做法。

评审的工作量并没有消失，它从“每周整理一次文件”变成了“每次晋升时认真读一份草稿”。后者更集中，也更容易留下判断的依据，但要读的人仍然是我。

我也慢慢接受了一点：并非每条记忆都要同样严格地处理。只服务我个人短期排查的记忆，我关心的是它别跑出去、需要时能删；准备给全组用的知识，要有来源、版本和权限前提；将来如果有人想把某套排查步骤做成可以直接执行的方法，门槛还要再高一层。把精力集中在晋升这个口子上，比逐条维护所有记忆现实得多。

接下来准备怎么做

先写一份晋升模板。命令行里有 memory promotion template 相关的子命令，我想看看能不能让生成的文档按我们 runbook 的固定结构来写：适用版本、前置权限、步骤、不适用的情况、回退方式。如果“不适用的情况”成了必填段落，跳过快照那类内容在生成阶段就会暴露出来。

模板里还要写一条我给自己定的规矩：在测试实例上得出的排障经验，至少在另一台实例上复现过一次，再发起晋升。工具不会替我执行它，只能靠我自己。

再就是拉一位同事做第二评审人。现在所有晋升都只过我一个人，影响范围却是整个组，确认责任和影响范围对不上。

还有一个问题我没想明白。像参数调优这类任务，效果往往要过几周、看过几轮业务高峰才能判断，评审时我手里的依据并不比 Agent 多。这类经验该什么时候晋升？等结果回流再评审，团队就要晚几周才能用上；先以“存在分歧”的状态并存，召回时把几种做法连同各自来源一起给出，又把判断压力转移到每一次执行上。我目前倾向于在低风险的实例上用后一种，生产相关的继续等，但这条线具体画在哪里，我还要再看几次真实的调优过程才能定。