进化闭环
四种更新方式只有进入同一个自主循环，才会从单次优化变成持续进化。更稳妥的是双循环：在线执行循环只完成任务并记录证据、不直接改写正式 agent；离线进化循环聚合轨迹、诊断根因、生成候选，再通过验证门槛发布。两者靠版本化的经验库和评估集连接。
四种更新方式只有进入同一个自主循环，才会从单次优化变成持续进化。生产系统更稳妥的是双循环：在线执行循环只完成任务并记录证据，不直接改写正式 agent；离线进化循环聚合轨迹、诊断根因、生成候选修改，再通过验证门槛发布新版本。两者通过版本化的经验库和评估集连接。
Voyager 在 Minecraft 里展示了一个较完整的循环，由三个互相咬合的机制组成：自动课程生成器（据当前能力提出难度适中的下一个目标，使探索不是随机漫游）、技能库（把成功程序存为可检索、可组合的代码）、迭代提示机制（把环境观察、执行错误、自验证结果带回下一轮代码生成，直到任务真正通过）。三者缺一不可：只有技能库没有课程，agent 不知道下一步学什么；只有自我反思没有环境验证，技能库会积累错误；只有探索没有持久化，每次任务仍从头开始。
从问题定位到经验沉淀
同一个表面问题可能需要不同的修改方式：客服 agent 的幻觉可能因知识库缺事实，也可能因 Prompt 没要求引用；虚假承诺既可用指令纠正，也可由 Harness 强制检查回复与工具状态。进化模块应先定位根因，再选最小、最容易验证和回滚的修改对象。证据不足的偶发故障不应立即触发学习，而应继续积累样本。这种选择也随经验变化：一条新策略先作为经验文档供检索，多个案例反复验证后再提升为 Skill；若步骤稳定、无需自然语言理解则编译成工具代码；若它反映广泛的隐式决策能力，则进入后训练。
验证、发布与回滚
所有修改首先产生候选能力或候选 agent，而不是直接覆盖生产版本：知识文档要验证检索后是否提高新任务表现，Prompt/Skill 要检查边界案例与旧任务回归，程序要在沙盒和重置环境中跑测试，参数更新要检查遗忘、安全和分布外任务。验证通过后仍应灰度发布观察真实流量，关键指标恶化时自动回滚到已知安全版本。
验证还要区分两种常被混在一起的能力：Harness 更新能力（从轨迹中产生有价值的持久修改）与 Harness 受益能力（任务 agent 在后续运行中找到、激活并正确使用这些修改）。一个 Skill 可能写得完全正确，但较弱的任务模型没在合适场景加载它、或加载后无法长期遵循——任一种都会让成绩看起来“没有进化”。所以不能只用端到端分数反推更新器好坏。分层评估：
| 指标 | 回答的问题 |
|---|---|
| 候选修改有效率 | 更新器是否提出了有价值的修改 |
| 产物激活率 | 任务 agent 是否在正确场景加载了新 Skill/记忆/工具 |
| 遵循成功率 | 激活后是否按新规则或流程执行 |
| 留出任务增益 | 整体是否改善了未参与进化的任务 |
诊断可用双向模型替换：固定候选 Harness、只换任务模型——强模型能受益而弱模型从不激活新产物，瓶颈在检索/路由；都能激活但只有强模型正确执行，瓶颈在指令遵循；所有模型都退化，才更该怀疑修改本身。反过来固定任务模型、换负责提出修改的模型，单独比较更新器质量。长期评价至少同时观察五类结果：回退（新经验是否与旧经验冲突、原本能过的案例是否回退）、泛化、Token 效率、安全性（规则/隐私/拒绝边界是否漂移）、长期工程质量（维护复杂度、架构一致性、向后兼容）。只解决当前失败案例、却在其他案例或新领域退化，不是成功的持续学习。
可验证闭环的边界：当“完成”不等于“进步”
这套闭环在 Coding、工具调用、业务状态变更等任务上最容易成立，因为测试或环境状态能快速给反馈。开放式科研、战略规划、复杂产品设计则不同：信号来得慢、正确答案不唯一，真正重要的目标（研究品味、长期价值、可维护性）很难写成即时分数——此时 Harness 可能把流程执行得非常完整，却只是稳定产出“像成果的东西”。自动科研的压力测试暴露三类问题：实现漂移（方案一变难，agent 退回训练数据里更熟悉但已偏离假设的普通实现）、认识论上的过度乐观（信号可能只是噪声，系统却开始解释结果、宣布发现，失败更容易被忽略）、隐性判断力不足（能跑实验，却未必知道哪个基线重要、何时该放弃假设）。这类任务不能靠换个更会写论文的模型解决，而要改证据与监督结构：结论与证据分离（每类声明链到可审计来源）、保留负面结果（失败与被拒候选写入不可变日志、有同等检索地位，否则进化模块只看到幸存方案、反复探索已证伪的路径）、维护搜索多样性（候选池按机制差异保留若干暂时低分但不同质的分支，避免收敛成同一个易得分模板）、让人类在更高层介入（定义问题、审查评价标准、解释反常、决定何时停止，而不只是危险工具调用前点批准）。
同样的限制也存在于普通软件工程：单测全过只证明当前可观察行为满足测试，不证明代码库数月后仍易维护——所以长期工程质量要作为独立指标，而非指望当前成功率顺便覆盖这些延迟外部性。持续进化的上限，最终取决于系统能否评价它真正关心的目标，而不只是最容易测量的代理指标。
持续进化的安全边界
自我进化能把一次错误变成长期风险：网页/邮件/工具输出里的提示注入若被总结成经验，会跨会话反复生效；自动搜索的恶意软件包若被封装成工具，影响从一次沙盒运行扩散到所有后续任务；一个有缺陷的验证器还可能持续批准看似进步、实际退化的候选。因此自我进化系统除了验证“是否更强”，还必须限制“谁能改什么、依据来自哪里”——评价器、权限边界与审计日志始终位于 agent 可修改范围之外。
睡眠学习：整合、遗忘与能力保鲜
“睡眠学习”是对离线整合的认知类比，并不要求任务真在夜间运行。在线 agent 的首要职责是完成当前任务、追加不可变证据；后台学习进程则在空闲期或满足门控条件时读一批新经历，比较新旧结论、合并重复、解决冲突、提出候选更新并跑回归。把采集与整理分开，能防止一次偶发成功、网络故障或恶意输入立刻改写长期能力，也让整理能用更大批量和更便宜的模型完成。一个典型周期五步：
- 触发：达到时间间隔 / 新增轨迹数 / 存储容量 / 错误频率门槛，且当前没有高优先级在线任务；
- 定向：读取正式知识、Prompt、Skill 目录及其版本，了解已有能力和不可修改边界；
- 采集与整合：从近期已评价轨迹中找新信号，合并重复、标记冲突与适用条件，优先生成局部补丁；
- 验证与审批：在迁移集、保留集、安全集上评估候选，高风险写入等人工批准；
- 修剪与索引：更新检索索引，把长期不用或被新证据推翻的能力标为过期 / 归档 / 删除，保留来源与回滚版本。
两个案例把它从比喻变成可运行的能力生命周期。Claude Code 的自动记忆为每个项目维护 MEMORY.md 索引 + 按主题拆分的详细文件，启动只加载索引的有界前缀、其余按需读取，索引接近上限时要求 agent 合并或移走细节——说明纯文本记忆也需容量约束、分层加载与主动整理。Hermes 更完整：有界的 MEMORY.md / USER.md、基于 SQLite/FTS5 的历史检索（返回原始消息而非先摘要，避免检索与生成混成不可审计的一步）、按需 Skill，任务包含较多工具调用 / 从死路恢复 / 收到用户纠正时后台复盘创建或局部修订 Skill；独立的 Curator 跟踪 Skill 的使用、陈旧与归档，空闲期做确定性修剪、变更前存快照可回滚。
持续进化不是让知识、Prompt、工具无限增长——上下文腐化会在更长时间尺度上重现：经验文档相互冲突、Prompt 被边界规则淹没、Skill 库出现重复能力、多次微调造成灾难性遗忘。所以要周期性离线整理：合并重复经验（保留来源与版本）、把局部规则从全局 Prompt 移到领域 Skill（保持全局 Prompt 整洁、像给新员工的指导书而非“99 条军规”式罗列）、重新验证长期未用的工具、删除被新证据推翻的知识、必要时从原始基座重训 LoRA。