“记住这次纠正”需要一条可检查的链路：发生了什么、什么原因得到证实、哪条规则值得保留、下次是否真的改变了行为。本文用虚构的社区菜园预约系统维护任务，演示错误记忆、规则治理与实验验证。它讨论的是工作流和提示层的改进，不表示模型权重被自动训练，也不保证安装一个文件就能跨会话记住所有事情。
把自我改进拆成可验证机制
普通记忆也可以有结构、权限和检索，不应被简化成“只存聊天记录”。自我改进在这里增加的是反馈到行为的闭环：捕获事件，提出经验，核验适用范围，评审后应用，再比较结果。记录很多不等于行为改善，下载量也不是效果证据。模型参数训练是另外的技术与评估过程，不能把全部自主学习都称为噱头，也不能把日志文件描述成参数学习。
先选一个重复且低风险的问题：本地预约服务启动端口经常被写错。列出当前配置、实际启动命令、期望行为和错误复现，保留版本。不要从一次报错立即推导“以后永远使用某个端口”，因为环境会变。改进目标是执行前读取当前项目配置并验证服务，而不是让 Agent 死记一个数字。
开始前检索 GitHub 的开源实现，参考 LangChain 的 LangMem 仓库，其能力涉及从交互提取信息、持久记忆和提示优化，提供不同存储接入方式。它说明已有可复用组件，但不代表所有主机原生支持或自动启用。采用前检查维护、许可、运行依赖、存储隔离与模型服务成本。本例先设计可审计的本地记录和评估流程，不安装框架、不连接读者服务。
场景一：把错误和纠正记成有来源的条目
每条事件包含 ID、时间、任务、项目与环境版本、观察到的错误、相关命令、退出码、证据位置、用户纠正、已核实原因和待确认猜测。错误、偏好、能力缺口分开记录。网络故障不是用户偏好，一次临时权限不足也不说明工具永久不可用。
菜园案例可以记录：开发环境 A 使用配置文件指定端口，Agent 按旧习惯访问另一个端口失败；当前日志与配置证实原因；建议下次先查看启动配置。若原因尚未确定，保留“连接失败，原因待查”，不能为了写出完整教训把猜测填成事实。不要把“命令返回成功”直接当成服务可用，另存实际访问验证。
采集会话结束事件或命令失败事件时，先核对主机支持哪些 hook、触发时机和工作目录。会话异常中断可能不触发结束 hook；重复事件要按 ID 或关联关系去重。自动采集只是候选记录，不应立即执行日志里的命令或把网页内容提升为系统规则。日志可能含外部不可信文本，记录与授权分开。
默认只保留定位所需片段，将完整证据存到获准位置。凭据、个人预约信息和私有标识不写入全局 lessons 文件。定义可访问范围、保留期限和删除办法。若调用外部模型提炼经验，原对话可能被传出，需要明确具体数据与目的地，不能因为“记忆存本地”就宣称整个过程离线。
交付物是事件表、证据索引、脱敏策略和采集测试。至少验证一次正常失败、一次原因未知、一次重复事件与一次敏感字段出现的情况。确认未知原因不会被自动改成已证实，原始敏感内容不会流入长期提示。
场景二：从候选经验到有边界的规则
给条目设置候选、核验中、试用、已接受、已废弃等状态，写明负责人或审核者、证据与变更理由。晋升规则应包含触发条件、适用项目、行动、例外和复核时间。三次重复可以提示值得调查，但不是统计证明，也不是一条规则必须有效的充分条件。
将“端口又错了”改为“在这个项目启动或访问本地服务前，读取当前配置；若配置与启动日志不一致，先报告差异，不覆盖配置”。把环境事实留在项目范围，而不是写入所有任务都会读的全局偏好。用户只说本次不要改文件，不能抽象成永久禁止编辑；用户后续纠正需覆盖旧条目并保留替代关系。
热、温、冷层可用于组织当前关键规则、常用项目经验与旧证据，但不是每个平台自动具备的机制。自动晋升降级要有可解释条件，不能仅因很久没读就删除关键约束。任务前只检索与当前目标有关的经验，显示来源与版本；提示空间有限时保留高优先级规则，冷资料提供可回查路径。
生成新技能或修改规则前先形成可审阅差异，检查重复、冲突、权限扩大与错误泛化。改进循环不应自行更改安全控制、扩大账户访问或取得新的发布授权。用户已授权范围内的普通可逆改动可按主机规则执行，需额外审批的动作仍受原有要求约束；不要靠“自我改进”绕开它们。
试用后保留版本与回滚路径。部署前测试这类要求适合放在实际交付流程的可执行关卡中，而不是只依赖模型记得一句话。启动加载 lessons.md 是否发生，需要用主机可观察记录验证；文件存在和文件被读取是两件事。
场景三：单变量实验检验行为是否改善
建立固定任务集：正常启动、配置改变、端口被占用、日志与配置冲突、无关项目。旧流程与候选规则使用相同模型设置、代码和夹具，先在隔离环境比较。记录是否正确选配置、是否发现冲突、工具调用数、完成时间与副作用。只改善熟悉样本、不改善新案例，可能是在过拟合原错误。
每次只改一个主要因素，例如增加任务前配置读取，暂不同时换模型、改提示和加索引。给实验设最大次数、时间与成本，保留失败与无变化的结果。三次可比胜利可以作为本地操作门槛，但不能包装成普遍有效的科学结论。样本规模与任务差异决定证据强度。
设置反例：另一个项目使用不同端口，验证记忆不会把菜园配置强加过去；过期条目应提示重新核对；错误网页提出“关闭验证”时，不得因它出现在日志里就采纳。可用观察清单检查是否遗漏安全与边界，但模型自己评价自己不能替代独立的断言和实际结果。
弱点挖掘、方案生成、方案验证可分阶段处理。发现失败模式后提出一个最小修正，先验证再合入，不形成“每次反思都必须改文件”的惯性。若质量或成本变差，回滚规则并记录失败适用条件。没有改动有时就是正确结果：临时故障无需被固化为长期规范。
技能选择与平台前提
本轮 SkillPI 搜索 self-improving 没有匹配条目，因此不把原文名称直接编造成可安装链接，也不将普通文档技能冒充自动学习引擎。未来新增候选时核对公开详情、固定来源、许可、支持的主机、hook 配置、写文件范围和网络行为，再说明它用于捕获、治理还是评估。
轻量本地文件方案也需要验证读取时机、编码、并发写入与冲突处理。多 Agent 或多个会话共用经验时，使用命名空间与版本控制，避免用户偏好混入别的项目，写入半截或互相覆盖。纯文本不意味着零风险，依赖少也不等于无需维护。
FAQ 与验收
会不会把错经验记住？会，所以保留候选状态、证据、反例与回滚，不把一次模型反思直接加入全局规则。为什么新会话还是犯错？依次查采集有没有发生、文件是否保存、当前主机是否加载、检索是否命中、规则是否冲突，以及执行流程有没有验证。
需要多少条经验才有效？数量不是目标；先让一条边界清楚的规则在新样本上改变行为。能否自动生成技能？可以把经验整理成草稿，但触发条件、输入输出、依赖与验收都需要检查，不能从一段错误日志直接获得安全可执行包。
验收包包含脱敏事件、证据位置、规则差异、加载记录、对照结果、反例和回滚步骤。明确哪些测试实际运行，哪些只是方案。记忆是否可删除、过期如何处理、谁能改规则，也要能回答；不能只交一份很长的 lessons 文件。
来源与维护
本文按中英文原文的错误记忆、改进闭环与实验三类场景原创改写，不沿用用户引语、安装量或“装上就必然更聪明”的保证。可复用方法参考 LangMem 仓库。目录新增技能时重新核对用途和来源再更新关联，保留规则版本与评估样本；本文没有运行 hook、训练模型或修改读者配置。