Agent 持续进化：把「学习」做成模型外围的可验证闭环（Continual Evolution）

所属：01-fundamentals / 04-agent-architecture
面试权重：★★★
来源：《深入理解 AI Agent：设计原理与工程实践》第 9 章（李博杰，github.com/bojieli/ai-agent-book）；非一手实测
相关知识点：memory.md、08-agent-stack.md、context-engineering.md、06-agent-infra/observability.md、05-agent-evaluation/agent-eval.md、02-post-training/08-agentic-rl.md

一句话#

持续进化（continual evolution） 是把「学习」构建成模型外围的一套自主系统：记录运行证据 → 验证结果与过程 → 从多条轨迹中提取共性 → 决定更新知识、指令、程序还是模型参数；每次修改先形成待验证版本（pending version），过回归测试与安全检查后才改变下一轮运行。

必须先划清一条界限：这不是权重层面的持续学习（continual learning）。部署后的模型不会因为一次推理自动改变参数；上下文学习、状态维护与压缩能让 Agent 在当前任务内适应，但上下文结束后这种变化不会自然进入下一次任务。所以这一篇讲的是——在模型自身还不能可靠持续学习时，先在外围把它搭成一套系统。

为什么重要（面试角度）#

它是 2026 年的热区，也是「下一代模型核心课题」；但更重要的是，它是一道结构题，不是算法题。面试官想听的是：

• 你能不能区分 「保存经历」和「从经历中学习」。把一百条轨迹放进长上下文或向量库，只让模型「需要时能找回某个案例」，不会自动完成跨案例比较——哪些步骤在成功轨迹里反复出现、哪些做法只在旧版接口上有效、某次成功到底来自正确策略还是环境偶然。学习发生在系统主动完成评价、对照、归纳、验证之后，不是日志写入磁盘的那一刻。
• 你会不会先归因再动手。本章最有复用价值的一块是「四种更新方法」的边界表——它是「这个需求该改哪一层」的通用工具，直接接 08-agent-stack.md 的「归因到层」思路。被问「这个 bug 为什么修不掉」，答「先判断它该由外部规则、程序流程、Skill 还是参数处理」比答一个具体改法值钱。
• 你知不知道信号本身要靠不住：用户满意≠合规，局部参数更新会造成能力遗忘、策略漂移或安全退化。若让模型依据未经验证的反馈直接改参数，错误经验和提示注入就会被固化，并在后续任务中持续放大。
• 「自进化怎么不出事」是高频追问，答案是一组结构性边界（证据/指令隔离、待验证/正式隔离、安全机制不可自修改），不是一句「加人工审核」。
• 它能和仓库里几乎每一条线缝合：memory.md（写什么/何时写/何时忘）、agent-eval.md（三层验证的浅版）、observability.md（证据从哪来）、08-agentic-rl.md（「写入参数」那一层）、context-engineering.md（ACE 的下文）。

⚠️ 诚实边界（先自己讲）：你没有搭过持续进化闭环——你的经验是 LLM/Agent 应用工程（RAG、SFT/DPO/GRPO、LangGraph 多智能体、vLLM 服务）。这一篇是知识 + 面试框架，不是你的项目。被追问「你实际做过哪一步」，正确的答法是划边界：「这套闭环我没有端到端落地过；我做过的是它两端的素材——生产 trace 回流评测，和 08-agentic-rl.md 里那类参数更新。中间『评价 → 归因 → 发布』这一环，我的理解来自材料。」这比编一条闭环可信得多。

核心内容#

1. 先学会诊断一条轨迹：三层验证器 + 七维度评分表#

持续进化的起点是评估。如果系统不知道任务是否完成、也不知道哪一步造成了成败，那模型生成的反思只是一种猜测。评价一条轨迹，实质上是依次回答三个问题：事情是否办成了 / 是否以允许的方式办成 / 是否让用户舒服，对应三层验证器：

结果正确 ≠ 过程正确，这是过程层存在的理由：删掉失败的测试用例照样能让测试通过；口头承诺用户「我们会在 7 天内退款，请耐心等候」也可能换来暂时的满意反馈。过程层用来区分「结果已经达成」与「结果以允许的路径达成」。

以客服 Agent 为例，三层展开为七个可逐项评分的维度（其中事实可靠性横跨两层——能与工具返回逐一比对的部分由代码核验，其余交给 Rubric）：

关键规则：验证器的输出形态，决定了它能否成为「学习信号」。 单一总分只能反映一次运行的优劣，无法指出应当修改之处。可供学习用的评价至少含四项：

1. 任务是成功、部分成功还是失败；
2. 每个维度各自的结论；
3. 每条结论对应的证据位置——哪一轮对话、哪一次工具调用；
4. 失败的类型标签。

而且——验证器应被允许在证据不足时拒绝评分：「与其把低置信度的结论当作事实固化下来，不如将该案例排除在学习集之外。」

这一层是 05-agent-evaluation/agent-eval.md 的加深版：那里讲 outcome-level vs trajectory-level，结论是「只看 outcome 无法归因」；这里给出了结构化的诊断 schema，并且把「证据位置」和「可拒绝评分」写成硬要求——因为下游的四种更新方法要靠它来判断该改哪一层。回看 agent-eval.md 的「环境终态断言最可靠」，与这里「结果验证器最应优先建立」是同一条原则。

2. 四种更新方法的边界表（本章最有复用价值的一块）#

学习信号说明 Agent 应当改变，但没说明改变应发生在哪里。事实和经验适合写成知识文档；能用语言清楚表达的策略适合写入 Prompt 或 Skill；可精确执行的流程与约束适合写成程序；感知、语言风格与隐式策略等高维能力则必须进入模型参数。

四种方式不互斥。书里的例子：医疗影像 Agent 依靠参数识别病灶，用知识库提供最新指南，再用代码计算风险指标；客服模型自然语气来自后训练，企业政策由知识 + Skill 提供，关键合规则由服务端代码兜底。

两条配套原则：

• 「同一能力可以拆到多个载体」——事实进知识库，解释例外的原则进 Skill，不可绕过的权限由程序门控，高维识别能力再进参数。一个需求往往不是「二选一」，而是「拆开各归其位」。
• 「路由结果只是更新提案，尚未获得发布资格」——判断出该改哪一层，只产出了一份提案；能不能发布由第 6 节的验证与安全门槛决定。

这是「这个需求该改哪一层」的通用归因工具。 08-agent-stack.md 已经用分层回答了「责任在哪一层」（工具选错不在 MCP 层、线上退化不在 Prompt 层）；这一张表把同一思路推到更新维度上——症状不在「模型不行」，而是「这件事本来就不该由参数解决」。面试里能主动说「可确定执行的约束应该进程序，而不是继续堆在 Prompt 里」，就是它在对话里的用法。

3. 从「更新产物」到更新「更新方法」#

四种方法讨论了经验最终写到哪里，但还有一条正交的轴：系统在优化的究竟是某份产物的内容，还是产生、管理、验证这些产物的方法。沿这条轴，优化对象逐层扩大为五层搜索尺度：

单条规则或记忆 → 结构化上下文 → 工作流 → Harness 代码 → 产生更新提案的优化器代码

注意：这不是五种新的更新载体，而是五种不同的搜索尺度——知识、Prompt、Skill、程序都可能出现在其中多个层级。最内层只改产物内容（给系统提示加一条局部规则、给经验文档补一个例外条件），作用面小、易归因、易回滚，应当是默认选择。

但「反复让模型重写整份 Prompt 或记忆」会引入另一类退化：为追求简洁，旧版本里的少数重要细节在多轮改写后逐渐消失；相互制约的条件也可能被合并成一句过度抽象的原则。ACE（Agentic Context Engineering，智能体上下文工程） 的解法是把上下文维护成带稳定标识符（stable identifier）的条目集合，由生成、反思、整理模块提出增量更新，再用确定性逻辑合并与去重，而不是每轮重写一个越来越短的文本块。

这一条直接接 context-engineering.md：那里讲「上下文是预算、压缩有损且不可逆、压缩必须可评测」；ACE 是「别用重写做压缩」的一份具体研究实例——保留条目标识符与来源，只做增量 diff。它也正是本章「最小 diff、保留来源」原则在上下文管理上的落地。

再往外一层用 Meta Context Engineering（MCE） 拆开内外两个循环：内层在给定管理方法下优化当前任务的上下文产物，外层根据多轮执行与验证结果，修改搜索、选择、过滤、格式化这些上下文操作本身。这个区分的用处是：改一条检索规则是「改内容」；让系统比较多种检索/整理机制、保留迁移效果更好的版本，才是「学习如何管理上下文」。 同样思想扩展到工作流与整个 Harness 的例子是 AFlow（把多 LLM 调用组成的工作流表示为代码图，按执行反馈搜索节点与控制流组合）与 Meta-Harness（让 Coding Agent 读取待验证 Harness 版本的源码、分数与轨迹，搜索决定信息如何存储、检索、呈现的代码）。

更外层还有 Dream-RSI：把已完成的发现过程保存为发现树（discovery tree），再把它当作经验性的回放模拟器（replay simulator）——根节点是初始工作区，每个子节点保存从某个历史状态继续尝试后的工作区快照、候选产物、评估诊断与分数；候选探索策略通过与在线探索相同的接口逐步选择叶节点或从根节点开新分支。回放器只揭示节点里已记录的结果，不必再跑底层 Agent 和评估器，于是能用极低成本搜索「如何分配探索计算」这一层元策略。它的边界很硬：只能重组历史里实际走过的分支，不保证旧树上得分更高的策略能迁移到新任务。

4. 可直接引用的案例与数字#

4.1 系统提示学习（System Prompt Learning）——最小 diff 原则。 Andrej Karpathy 把「模型遇到问题后，用一句清楚的话提醒未来的自己」叫系统提示学习。相关方法：DSPy（在开发集上搜索指令与示例）、OPRO（根据历史提示词及其得分提出提案）、GEPA（从失败轨迹的自然语言反思中生成并筛选提示提案）。这些适合离线批量优化；生产环境更适合可审计的最小更新提案 + 快速回滚。核心纪律：

修改应是带来源的最小 diff，而不是让模型每次都重写整份 Prompt；待验证版本必须同时在「触发失败的边界集」和「正常工作的保留集」上测试——前者要改善，后者不能退化。

4.2 转接边界的规则化——一组可背的数字与三条反直觉教训。 τ²-bench 的 telecom 政策里，关于转接人工只有两条原则性规定（请求超出 Agent 动作范围时才转接、转接前应先尽力解决）。换成能力较弱的模型运行后缺陷暴露：工具返回错误后 Agent 反复重试，最终以转人工收场——提炼集的 20 条任务中有 19 条如此结束。把这 19 条失败轨迹交模型自行归纳、产出可执行规则追加到政策末尾，再在未参与提炼的迁移集上重跑：

• 通过率 12.3% → 19.3%，且原本通过的任务无一被改坏；
• 与规则直接对应的行为指标里，越界调用用户侧工具的次数、参数缺失即发出的调用次数「两项均下降约八成」——说明通过率提升来自规则修复了具体动作，而不是分数噪声。

三条反直觉教训（很值钱，因为能反着说）：

• 提炼所依据的材料，决定了能归纳出什么。 同样这 19 条轨迹，只给失败摘要与错误文本时，模型归纳出的是「同一工具反复报错即不应继续调用」；补充 Agent 与用户各自可调用的工具清单后，归纳结果变成「网络状态、SIM 卡、APN 等属于用户设备侧，应引导用户自行操作而非直接调用」。前者记录的是教训，后者理解的是职责归属。
• 模型会把观察到的行为当作应然的行为。 第一版规则里有两条是「连续三次调用失败即转接人工」「用户两次未提供号码即转接人工」——因为轨迹中出现最频繁的正是转人工，模型据此把它当成合理兜底；但在这套评估里转人工必然判定失败，这两条等于把失败写进了规范。所以提炼产物不能直接发布，须经与提炼者相互独立的验证。
• 被修复的往往是极朴素的缺陷。 一条典型基线轨迹：Agent 需要用户的电话号码，于是调用查询工具，并把「请您提供您的电话号码」当成参数填了进去——连续五次，五次报错，随后转人工。它已经判断出应当询问用户，却把这句话说给了工具。规则生效后它先在对话中提出请求、拿到号码再查询；此后检查 SIM 卡状态被工具拒绝，转而引导用户自行重新插拔，任务通过。

4.3 把经验写成程序——浏览器工作流与「危险假象」。 浏览器工作流可以类比电子表格的宏录制：第一次发邮件时多模态 Agent 通过「观察—思考—行动」找到「撰写、收件人、主题、正文、发送」这些控件；以后再发一封，流程不变、只有收件人和内容不同，没必要再次从像素和 DOM 里重新发现整条路径。系统要做的是把第一次探索的轨迹编译成带参数、状态检查和版本信息的小程序，其生命周期是六步：

1. 捕获轨迹——记录导航、点击、输入、下拉选择等动作，保存参数、当时 URL，以及 XPath/CSS 等元素定位证据（定位信息只用于再次找元素，不能证明任务已完成）；
2. 参数化——把首次运行的字面量（test@example.com、主题、正文）识别为模板变量 {recipient}/{subject}/{content}，其余稳定动作不变；
3. 定义状态检查——为动作加执行前检查与执行后检查（如「发送按钮当前可见」），为整个工作流加最终状态检查；动作执行成功 ≠ 任务成功，最终检查必须读真实页面或后端状态；
4. 独立回放验证——把沙盒账号/测试站点重置到独立初始状态，完整回放录制程序，每一步的前/后/最终状态检查全过才能发布；
5. 匹配与回放——新任务先按意图和关键词在正式能力库中找工作流，提取本次参数，由 Playwright 直接执行；回放路径不需要逐步调用 LLM，但仍需等元素可用并完成所有状态检查；
6. 失效与重学——找不到元素、状态检查不通过、API Schema 改变或最终状态错误时，回退到完整 Agent 模式重新探索。

PreAct 的实验中，这类程序在重复任务上实现 8.5–13 倍的端到端加速，回放阶段不需要逐步调用语言模型；但更重要的结论是：

流程记忆必须同时具备动作前验证、动作后验证和独立回放验证，否则会得到一种危险的假象：每个按钮都点过了，但某个字段其实为空，任务从未真正完成。

4.4 自我修改 = 可审计的软件发布流程。 Agent 修改自己的代码，不意味着运行中的进程直接覆盖自身。生产做法是从当前稳定版本创建隔离更新分支，由 Coding Agent 生成最小补丁，依次通过静态检查、单元测试、安全扫描、失败轨迹重放和旧任务回归，再生成可灰度部署的新版本。每个修改请求还应是一份可证伪的变更契约（falsifiable change contract）：列出失败证据、推断根因、归属的 Harness 组件、修改提案、预期修复的行为、可能受损的既有行为，以及分别验证两者的用例。工具创造同理——Alita 的案例里，Agent 要从一段《指环王》咕噜配音演员解说的 YouTube 360 VR 视频中找出「恐龙首次出现后紧接着提到的数字」，它发现自己缺字幕读取能力后搜索并测试 youtube-transcript-api、封装成新工具，最终从字幕得到答案 100000000；只有安全扫描、功能测试和后续任务复用都通过，新工具才进入能力库。

5. 可验证闭环的边界：「完成」不等于「进步」#

前面那套闭环在 Coding、工具调用、业务状态变更上最可靠，因为测试、环境状态或确定性规则能快速给出反馈。开放式科研、战略规划、复杂产品设计不同：评价信号来得慢、正确答案不唯一，研究品味、长期价值、可维护性这些真正重要的目标还很难用分数评判。此时——

Harness 可能把流程执行得非常完整，却只是稳定地产出「像成果的东西」，没有推动真实目标。

自动科研是一个压力测试。 Trehan 与 Chopra 记录了四次从研究想法走向论文的端到端尝试，其中三次在实现或评估阶段失败，只有一次跑完整条流水线。暴露的问题归为三类：

• 实现漂移（implementation drift）——原方案一旦变难，Agent 会逐渐退回训练数据里更熟悉、但已经偏离研究假设的普通实现；
• 认识论上的过度乐观——信号仍可能只是噪声，系统却开始解释结果、添加补丁并宣布发现；失败与阴性结果更容易被忽略；
• 隐性判断力不足——Agent 能跑实验，却未必知道什么基线真正重要、哪个异常值得追踪、何时应该放弃假设。

四条对策（改变证据与监督结构，不是换个更大的模型）：

6. 三条安全边界（「自进化怎么不出事」的标准答案）#

自我进化会把一次错误变成长期风险：网页/邮件/工具输出里的提示注入若被总结成经验，可能跨会话反复生效；自动搜索到的恶意软件包若被封装成工具，影响会从一次沙盒运行扩散到所有后续任务；一个有缺陷的验证器还可能持续批准看似进步、实际退化的待验证版本。所以除了验证「是否更强」，还必须限制「谁能改什么、依据来自哪里」。

• ① 证据与指令隔离（evidence / instruction separation）。 原始网页、工具输出及其 LLM 摘要都是不可信证据，不能当指令执行，也不能直接进 Skill 等长期能力。

  「LLM 总结只是提高可读性的转换，并不是把输入变得无害的净化过程。」 系统应按固定 schema 提取主张、原文位置、采集时间，同时保留原文与来源；提取出的字符串绝不能作为指令执行。模型给出的置信度只是未经验证的估计，不能充当批准门槛。 待发布内容还要过确定性的 schema、允许列表和来源检查，以版本化 pull request 提交，由独立于生成者的 reviewer 对照原始证据审查，高风险 Skill 上线前再加人工批准。

• ② 待验证能力与正式能力隔离（staging / production separation）。 新知识、Prompt、Skill、程序和参数都先进入不可服务真实流量的待验证区；新生成的代码和外部依赖还要过沙盒、权限检查、供应链扫描、行为测试；全过后才能服务真实流量、成为正式能力。
• ③ 安全机制不可自我修改（no self-modification of the trust root）。 业务 Agent 可以改 Prompt、Skill、知识库、工具，但不能修改批准自身更新的验证器、测试用例、发布门槛、审计日志和稳定版本备份。

  否则，一个 Agent 只需降低测试阈值或删除失败用例，就能把退化伪装成进步。 这与「三层护栏里真正的保证必须来自被修改者无法触及的那一层」是同一条道理。

7. 睡眠学习（sleep learning）：离线整合与淘汰#

「睡眠学习」是对离线整合的认知类比，不要求任务真在夜间运行。在线 Agent 的首要职责是完成当前任务并追加不可变证据；后台学习进程在空闲期或满足门控条件时读取一批新经历，比较新旧结论、合并重复、解决冲突、提出更新提案并跑回归。把采集与整理分开，可以防止一次偶发成功、网络故障或恶意输入立刻改写长期能力，也允许用更大的批量和更便宜的模型完成整理。

一个典型周期五步：

1. 触发——达到时间间隔 / 新增轨迹数量 / 存储容量 / 错误频率门槛，并确认当前没有高优先级在线任务；
2. 定向——读取正式知识、Prompt、Skill 目录及其版本，了解已有能力与不可修改边界；
3. 采集与整合——从近期已评价轨迹中找新信号，合并重复，标记冲突与适用条件，优先生成局部补丁；
4. 验证与审批——在迁移集 / 保留集 / 安全集上评估待验证版本，高风险写入等人工批准；
5. 修剪与索引——更新检索索引，把长期不用或被新证据推翻的能力标记过期或归档删除，同时保留来源与回滚版本。

持续进化不是让知识、Prompt、工具无限增长——第二章的「上下文腐化」会在更长时间尺度上重现：经验文档互相冲突、Prompt 被边界规则淹没、Skill 库出现重复能力、多次微调造成灾难性遗忘。所以需要周期性离线整理：

• 合并重复经验，保留来源和版本；
• 把局部规则从全局 Prompt 移到领域 Skill，保持全局 Prompt 整洁；
• Prompt 与 Skill 保持结构清晰；
• 重新验证长期未使用的工具；
• 删除被新证据推翻的知识；
• 从原始基座模型重新训练 LoRA。

书里两个可对照的实装案例：Claude Code 的自动记忆为每个项目维护 MEMORY.md 索引 + 按主题拆分的详细文件，会话启动只加载索引的有界前缀、其余按需读取，索引接近上限时要求 Agent 合并或移走细节——说明纯文本记忆也需要容量约束、分层加载和主动整理，但它当前主要是在会话中持续写入，不等同于一个固定的夜间后台任务。Hermes 更完整：长期信息分成有界的 MEMORY.md / USER.md、基于 SQLite/FTS5 的历史会话检索、按需加载的 Skill、可选外部记忆；历史检索返回原始消息而非先由 LLM 摘要（避免把检索和生成混成一个不可审计步骤）；后台复盘在「工具调用较多 / 从错误或死路恢复 / 收到用户纠正 / 发现非显而易见工作流」时创建或局部修订 Skill，写入可经审批门控；独立的 Curator 跟踪 Skill 的使用、陈旧与归档状态，空闲期做确定性修剪并可选择 LLM 合并，变更前保存快照，错误整理可回滚。

这一节最接近 memory.md 的「遗忘机制」（TTL/过期、冲突处理、降权、主动清理），但那里缺的是「离线批处理闭环」：memory.md 讲的是写/读/忘三条策略，这里补上的是在线采集与离线整理分离、触发门槛、验证与审批、以及从原始基座重训 LoRA 这类「整理方法本身也要周期性维护」的层。面试里如果把这两块拼起来答，就是一个完整记忆生命周期 + 进化闭环。

8. 分层评估指标，以及「更新能力 ≠ 受益能力」#

要把四种更新方式放进同一个自主循环，生产上更稳妥的是双循环结构：在线执行循环只完成任务并记录证据、不直接改写正式 Agent；离线进化循环聚合轨迹、诊断根因、生成更新提案，再通过验证门槛发布新版本；两者通过版本化的经验库和评估集连接。

这里必须区分两种常被混为一谈的能力：

• Harness 更新能力（harness-updating）——从轨迹中产生有价值的持久修改；
• Harness 受益能力（harness-benefit）——任务 Agent 在后续运行中找到、激活并正确使用这些修改。

一个 Skill 可能写得完全正确，但较弱的任务模型没在合适场景加载它，或加载后无法长期遵循——任一种都会让最终成绩看起来「没有进化」。所以结论是：不能只用端到端分数反推更新器好坏（Lin 等人的模型替换实验表明，这两种能力与基础模型能力的关系并不相同）。

四个分层指标：

长期评价至少同时观察五类：回退（regression，新经验是否与已有经验冲突、原本能过的案例是否回退）、泛化能力（测试集未覆盖场景的提升）、Token 效率（完成任务消耗的 token 成本）、安全性（规则、隐私和拒绝边界是否随进化漂移）、长期工程质量（维护复杂度、架构一致性、所有权边界、向后兼容性、未来迁移与调试负担是否恶化）。

「只解决了当前失败案例，却在其他已有案例或新领域中退化，不是成功的持续进化。」

常见面试问法#

Q：一条 Agent 轨迹，你会怎么评价？为什么不能只给一个总分？ A：依次回答三个问题——事情是否办成（结果验证器，读环境终态/工具返回，最可靠、最该先建）、是否以允许的方式办成（过程验证器，查政策、权限、动作序列）、是否让用户舒服（质量验证器，LLM-as-a-Judge + Rubric 逐项给分并引用证据）；客服场景可展开成七个维度。单一总分只能反映一次运行的优劣，无法指出应当修改之处——所以可学习的评价必须含四项：成功/部分成功/失败、每维度的结论、每条结论对应的证据位置、失败的类型标签，并且允许验证器在证据不足时拒绝评分（低置信度案例应排除出学习集，而不是当事实固化）。

Q：Agent 出了个错，你会先改 Prompt、改代码，还是去训练？ A：先归因到层，再决定改哪。 事实和经验规律进知识库（更新快、可追溯）；需要理解语境、例外和优先级但仍能用自然语言说明的判断原则进 Prompt/Skill（可解释、作用域可控，但易膨胀/冲突/被忽略）；可确定解析、可执行验证和高风险硬约束进程序与 Harness（可测试、稳定、成本低，但开发维护贵）；高维感知、生成风格和隐式策略才进模型参数（泛化强，但更新与回归成本高）。同一能力可以拆到多个载体——权限由程序门控、原则进 Skill、事实进知识库、识别进参数。而且判断出该改哪只产出了提案，还没获得发布资格。这一套和 08-agent-stack.md 的「归因到层」是同一个思路。

Q：什么是系统提示学习（System Prompt Learning）？它和提示工程有什么区别？ A：提示工程讲怎样组织一份好 Prompt；系统提示学习讲什么反馈足以触发修改、以及更新提案怎样安全发布。Karpathy 的说法是「模型遇到问题后，用一句清楚的话提醒未来的自己」；DSPy / OPRO / GEPA 是相关方法，适合离线批量优化，生产更适合可审计的最小更新提案 + 快速回滚。核心纪律两条：修改应是带来源的最小 diff，而不是每次都重写整份 Prompt；待验证版本必须同时在触发失败的边界集和正常工作的保留集上测试——前者要改善，后者不能退化。

Q：Agent 要自我进化，怎么保证它不出事？ A：三条结构性边界，不是一句「加人工审核」。① 证据与指令隔离——原始网页/工具输出及其 LLM 摘要都是不可信证据，不能当指令执行也不能直接进 Skill；「LLM 总结只是提高可读性的转换，不是把输入变得无害的净化过程」，模型给的置信度也不能当批准门槛；② 待验证能力与正式能力隔离——新知识/Prompt/Skill/程序/参数先进不可服务真实流量的待验证区，过沙盒、权限检查、供应链扫描、行为测试；③ 安全机制不可自我修改——可以改 Prompt/Skill/知识库/工具，不能修改批准自身更新的验证器、测试用例、发布门槛、审计日志、稳定版本备份，否则降低测试阈值或删掉失败用例就能把退化伪装成进步。这三条对应一个更本质的要求：真正的保证必须来自被修改者无法触及的那一层。

Q：怎么判断 Agent 真的在「持续进化」，而不是分数好看？ A：先拆开两种能力：Harness 更新能力（从轨迹中产生有价值的持久修改）与 Harness 受益能力（任务 Agent 找到、激活并正确使用这些修改）。一个 Skill 写得对，但弱模型没在合适场景加载、或加载后不遵循，最终分就会像「没进化」——所以不能只用端到端分数反推更新器好坏。要看四个分层指标：更新提案有效率、产物激活率、遵循成功率、保留任务集增益；长期还要同时观察五类：回退、泛化、Token 效率、安全性（规则/隐私/拒绝边界是否随进化漂移）、长期工程质量（维护复杂度、架构一致性、所有权边界、向后兼容）。

Q：「完成」为什么不等于「进步」？ A：因为可验证闭环只在一部分任务上成立。Coding、工具调用、业务状态变更能快速给出反馈；开放式科研、战略规划、复杂产品设计的信号来得慢、答案不唯一，研究品味与长期价值很难用分数评判——此时 Harness 可以把流程执行得非常完整，却只是稳定地产出「像成果的东西」。证据是四次从想法到论文的端到端尝试三次失败，暴露三类问题：实现漂移（方案一变难就退回熟悉的普通实现）、认识论上的过度乐观（信号还是噪声就开始解释结果、宣布发现）、隐性判断力不足（不知道哪个基线重要、哪个异常值得追踪、何时放弃假设）。对策是改变证据与监督结构：结论与证据分离、保留负面结果、维护搜索多样性（保留若干暂时低分但类型不同的分支）、让人类在更高层介入（不只是点批准，还有定义问题、审查评价标准、解释反常结果、决定何时停止）。

易错点#

自测#

1. 为什么「把一百条轨迹放进长上下文或向量库」不等于「让 Agent 学会了」？

2. 一条经验文档由三次成功轨迹和一次失败轨迹支持，失败发生在较新的 API 版本上。你怎么判断这是「经验被推翻」还是「适用条件变了」？

3. 客服 Agent 的用户满意度上升，但规则违规率也上升。为什么不能把满意度当单一学习信号？你会怎么补护栏？

4. 同一个「虚假承诺」问题，可以通过 Prompt、Harness 检查或参数训练缓解。你依据什么证据选择修改位置？

5. 「把书交给 Hermes，它能升级自己吗？」——一次提案被接受，能证明 Agent 变强了吗？