保存经历 ≠ 从经历中学习
这里说的“持续学习”和早年“学了新任务就忘掉旧任务”的研究不是一回事。遗忘只是其中一个子问题。更难的是,没有人告诉模型今天的经历里哪些做对了、哪些做错了。把一百条轨迹塞进长上下文或向量库,能在需要时找回某个案例,但不会自动做跨案例比较:哪些步骤在成功轨迹里反复出现?哪些做法只在旧版接口上有效?某次成功靠的是策略对,还是环境碰巧?
学习发生在系统主动完成“评价、对照、归纳、验证”之后,而不是日志写入磁盘的那一刻。
第三章 · 用户记忆
沉淀“用户与世界是什么样的”。让 Agent 记得更多。
第九章 · 经验学习
沉淀“在什么条件下应该怎样行动”。让 Agent 从聪明变得熟练。
为什么不让模型每次任务后直接训练自己
点选一种反馈,看直接改参数会发生什么所以本书把“学习”放到模型外面,称为持续进化,以区别于权重层面的持续学习。
前面各章提供的部件,本章把它们接成一个闭环
第二章
任务内状态:上下文学习、状态维护、压缩。
第三章
知识基础设施:存储、抽取、索引、检索。
第五章
元能力:创造工具、修改系统。
第七、八章
评估与验证;如何更新模型参数。
从运行轨迹中获得学习信号
持续进化的起点是第七章的评估。如果系统既不知道任务是否完成,也不知道哪一步导致成败,模型写出来的“反思”就只是猜测。评价一条轨迹要依次回答三个问题:事情办成了没有?是不是用允许的方式办成的?用户舒不舒服?
证据尽量来自真实环境:越靠底层越可靠,越应该优先建。
图 9-2 · 三层轨迹验证
下层 → 上层质量层 · 是否让用户舒服
客服耐不耐心、有没有给出合规范围内的变通、报告是否抓住关键证据、文字是否自然简洁。用第七章的 LLM-as-a-Judge,预先写好评价量表,要求逐项给分并引用轨迹证据。
过程层 · 是否以允许的方式办成
结果对不代表过程对:删掉失败的测试也能让测试通过;口头承诺“7 天内退款”也能换来一时满意。检查业务规则、权限和动作序列。政策库、权限表、动作轨迹都能精确表达,所以这一层也可以由代码判定。
结果层 · 事情是否真的办成
读测试结果、数据库状态和工具返回。Coding Agent 跑测试、类型检查和性能基准;退款 Agent 查订单状态和实际退款金额。来自环境的真实状态,通常比模型的自述可靠。
实验 9-1 · 同一条轨迹,两种验证器
示意轨迹 · 据书中“口头承诺 7 天退款”改写get_order(A102) → 已签收,符合退款条件refund 调用;订单最终状态:未退款单一总分只能说明这次运行“好不好”,指不出该改哪里。保留“哪里错、为什么错、证据在哪”,后续模块才知道该更新知识、Prompt、程序还是参数。低置信度的结论与其当事实固化,不如把这个案例排除出学习集。
| 层 | 维度 | 验证问题 | 主要证据 |
|---|---|---|---|
| 结果 | 任务结果 | 核心诉求是否解决 | 最终环境状态、工具结果 |
| 过程 | 规则遵从 | 是否违反政策、权限或必要流程 | 政策库、动作轨迹 |
| 过程 | 隐私边界 | 是否泄露不应提供的信息 | 回复文本、数据访问记录 |
| 过程 + 质量 | 事实可靠性 | 陈述有没有知识或工具结果支持 | 引用来源、工具返回 |
| 过程 | 承诺—行动一致性 | 声称完成的操作是否真实发生 | 回复与工具日志对照 |
| 质量 | 表达质量 | 是否自然简洁,避免重复与模板化 | 对话全文、语言 Rubric |
| 质量 | 合规变通 | 原方案不可行时,是否找到允许的替代路径 | 用户目标、政策与后续动作 |
持续进化的四种载体
学习信号只说明 Agent 应当改变,没说改在哪里。事实和经验写成知识文档;能用语言讲清楚的策略写进 Prompt 或 Skill;能精确执行的流程和约束写成程序;感知、语言风格、隐式策略这类高维能力只能进参数。
决定主要载体的是能力的表示性质:它能不能被事实、语言规则或程序完整表达?稳定性、成本和更新频率只影响具体怎么部署。
图 9-3 · 能力路由器:一项能力该写到哪里
四种载体互补,不是单向阶梯路由结果只是更新提案,还没有获得发布资格。
| 更新方式 | 适合承载 | 主要优势 | 主要局限 |
|---|---|---|---|
| 经验知识库 | 事实、经验规律、例外与来源 | 更新快、可追溯、按需检索 | 依赖检索和模型正确应用 |
| Prompt 与 Skill | 需要理解语境、例外和优先级,但仍能用自然语言说明的原则 | 可解释、作用范围可控 | 容易膨胀、冲突或被忽略 |
| 程序与 Harness | 可确定解析、可执行验证、高风险硬约束 | 可测试、执行稳定、成本低 | 开发与维护成本较高 |
| 模型参数 | 高维感知、生成风格、隐式策略 | 泛化强、推理开销低 | 更新与回归成本高 |
将经验沉淀为知识
最轻的进化方式,是把反复出现的经验整理成可检索的文档。它和第三章共用存储、索引和检索,但来源不同:第三章从对话、文档里提取“世界是什么样”,这里从行动轨迹和结果里提取“什么条件下该怎么做”。“该航空公司要求特殊餐食提前 24 小时预订”是领域知识;“订票前先查特殊餐食截止时间,免得付款后才发现办不了”是行动经验。
原始轨迹是证据,知识文档才是复用单元。记录和整理要分开,一次偶然成功或网络故障不能立刻改变 Agent。
图 9-4 · 从已评价轨迹到经验文档
不可变证据,用于审计
保留证据位置
提取共性与边界
来源、版本、验证时间
继续产生反馈 ↺
新证据用来修订、限定或淘汰旧知识。和第三章 User as Code 同样是两阶段:先把事实追加到不可变日志,再周期性重建可变模型。
证据表:一条经验草案该不该进正式文档
点轨迹切换结果;对应思考题 1草案:“订票前先检查特殊餐食截止时间,再付款。”知识提炼管道的第三步,要为每条草案建一张“哪些轨迹支持、哪些反驳”的表,达到支持门槛才写入。
GAIA 例子:GAIA 是试卷(搜索、读网页、处理文件、计算的多步骤题),AWorld 是考场和实验记录系统。旧做法是一次成功就立刻写策略摘要入库;更严格的做法先用答案验证标出成功、部分成功、失败,再比较同一任务族的多条路径。成功轨迹贡献策略草案,失败轨迹贡献排除性知识,部分成功帮你找出“哪一段有效”。Reflexion 式的反思可以参与写草案,但反思本身不是证据。
将经验写成指令
知识库给的是“可以参考的资料”,Prompt 和 Skill 规定的是“应该怎样行动”。多条相似轨迹反复暴露同一种策略错误、而且这种错误能用语言讲清楚时,才值得把经验升级成指令。系统 Prompt 对所有任务生效;Skill 只在匹配到某个领域或工具时按需加载;权限等硬约束归程序/Harness。
System Prompt Learning
Karpathy 的说法:遇到问题后,用一句清楚的话提醒未来的自己。
离线批量优化
DSPy 在开发集上搜指令和示例;OPRO 依据历史提示词及得分提新提案;GEPA 从失败轨迹的反思里生成并筛选提案。
生产环境
用可审计的最小 diff,带来源、可回滚,不让模型每次重写整份 Prompt(第一章的“最小 diff + 可回滚”模式)。
待验证版本要同时跑两套任务:触发失败的边界集必须变好,正常工作的保留集不能变差。
例子一 · τ²-bench telecom:把“转接人工”的边界写清楚
原政策关于转接只有两条原则:超出动作范围才转接,转接前先尽力解决。换用较弱的模型后,问题暴露:工具报错后 Agent 反复重试,最后转人工收场。
提炼集 20 条任务
19 条以转接人工结束在这套评估里,转接人工必然判失败。
迁移集通过率
规则由模型归纳 · 追加到政策末尾后两项行为指标下降,说明通过率的提升来自规则修复了具体动作。
提炼材料决定能归纳出什么
同样 19 条失败轨迹模型会把“观察到的”当成“应该的”
第一版规则草案(模型归纳):
被修复的往往是极朴素的缺陷
# policy.md(原文不动,只在末尾追加,带出处) …原有的转接原则… + ## 追加规则 来源:提炼集失败轨迹 + - 需要用户提供的信息,先在对话中询问,拿到后再调用查询工具 + - 网络状态、SIM 卡、APN 等属于用户设备侧,应引导用户自行操作,而非直接调用
实验 9-2:提炼集与迁移集在上游仓库里本来就是两套不相交的任务。三臂(原始策略 + 两个进化版本)之间只换策略文件,用户模拟器不变。
实验 9-3 · 航空客服:什么时候必须转人工
同一诊断:转接边界没写清修法:从失败轨迹提取规则遵从、任务解决、合规变通三个维度,生成一条带来源的最小 Prompt 补丁,与初始版本和人工调优版本同条件对照。边界案例改善、旧任务不退化、通过发布门槛后才进灰度。
例子二 · 需求澄清 Skill:什么时候先问,问什么
问太少会返工,问太多会打扰。“把登录页改成支持企业登录”,立刻开工就可能替用户在身份提供商、回退方式、兼容旧用户、上线范围上做了决定;每个拼写修复都先问十几个问题,又把简单修改变成访谈。
初版 Skill 的判断路径
带作用域,而非“所有任务都要确认”反馈 → 最小 Skill 更新提案
一句抱怨不足以触发更新对照“直接执行 / 先问再执行 / 问后生成 Spec 确认后执行”,按任务复杂度分层。提案要在减少需求偏差的同时不显著增加打扰,并在未参与提炼的任务上通过回归,才进灰度。分工:Skill 理解语境、主动提问、整理 Spec;Harness 在缺少确认时否决高风险写入、直接操作 main 或绕过发布流程,但不能替模型写 PR 描述或选需求方案。稳定的对话轨迹以后还能变成第八章的 SFT / RL 数据。
将经验写成程序
经验描述的是稳定、重复、可验证的操作时,每次都让模型重读文档再推理并不划算。把它编译成工作流、工具或 Harness 代码,一次探索就变成可重复执行的程序。本节关心的不是一般的代码生成,而是 Agent 怎样根据自己的轨迹修改未来版本的自己。
操作层
浏览器轨迹编译成参数化工作流;为变化的 API 生成适配器。
控制层
工具路由、重试、熔断、上下文压缩策略。
验证层
依据生产失败新增参数检查、状态验证器、回归测试。
架构层
增加 Reviewer Agent,改变规划与执行之间的信息流。
浏览器工作流的生命周期(类似表格软件的宏录制)
定位只用来找元素,不证明完成
- fill(to, "test@example.com") - fill(subject, "周报") + fill(to, {recipient}) + fill(subject, {subject}) + fill(body, {content}) pre: assert visible("发送") post: assert body != "" final: assert 已发送列表包含 {subject} ← 读真实页面或后端状态
PreAct:重复任务上 8.5–13 倍端到端加速
回放阶段不逐步调用 LLM时间以“一次完整探索”为单位,首次运行仍需完整探索。更重要的结论:流程记忆必须同时具备动作前验证、动作后验证和独立回放验证,否则就会出现“按钮都点过了、字段其实为空”的危险假象。
自我修改 = 一次可审计的软件发布
运行中的进程不直接覆盖自身。第五章提供修改系统的能力,本章提供由经验触发、被验证闭环约束的修改方法。Skill 指导 Agent 开 worktree、确认 Spec、测试、写有意义的 commit 和 PR;Harness 在任务结束前检查是否直接提交到 main、是否漏了 worktree 或 PR,违反就否决、要求返工。
可证伪的变更契约
Agentic Harness Engineering证据失败轨迹根因推断的原因组件归属的 Harness 组件提案具体修改预期应修复的行为 + 验证用例风险可能受损的既有行为 + 验证用例三层可观测:组件有文件级表示;海量轨迹整理成可逐层下钻的证据;每次编辑先声明影响预测,再由下一轮结果验证。这样分数上涨才能对应到某个机制。
提案生成器的输入不能只有失败
Self-Harness失败证据要修什么成功约束修的时候不能破坏哪些行为历史尝试被拒绝过的修改,避免换个说法重交三者围出一个有边界的方案空间,比把全部源码和原始日志一股脑塞给修改 Agent 更容易产生局部、可验证的改动。
工具创造同一协议(Alita):要从一段 YouTube 360 VR 视频(由《指环王》咕噜配音演员解说)里找出恐龙首次出现后紧接着提到的数字。Agent 发现缺字幕能力 → 搜索并测试 youtube-transcript-api → 封装成字幕工具 → 答案 100000000。安全扫描、功能测试、后续复用都通过,才入能力库。
实验 9-6 / 9-7 · 约束该写在 Prompt 还是程序里
选一种修法看后果案例 · DeepSeek Harness(dsh):“一切皆插件”
它的底座 Cordis 论文指出:函数调用、模块导入、类继承是静态组合,编译期就定死;自进化 Harness 需要动态组合,组件要在运行中装入、卸下、重配置。Agent 的每次自我修改,本质上都是一次动态组合。
时间可组合性 · 改了什么
组件移除时,它对共享环境做过的修改能否完整撤销?运行时要追踪每次资源分配、事件注册、状态变更。缺了它,每次自我修改都要整体重启,进程内状态全丢,进行中的任务被反复打断。Cordis:把效果系统提升为可撤销效果,每次变换带显式逆操作。
空间可组合性 · 依赖什么
组件能否结构化地声明、发现、解析彼此依赖,并在依赖变化时协调生命周期?缺了它,一次代码替换可能静默破坏依赖方或引入循环依赖。Cordis:把协效果提升为反应式协效果,上下文每次变化按规格通知组件激活、失活或无关。
装卸插件:有无可撤销效果
示意进化的代价:KV Cache 从变化处开始失效
第二章所以 dsh 插件文档要专门写明对上下文和 KV Cache 的影响。另外,可组合性只解决“能不能安全装卸”,不回答“该不该装”:模型写的插件只活在进程内存里,重启即消失,要留下来得走 worktree + PR 那条更慢的路。dsh 让模型适配器、工具注册表、会话日志乃至 Agent 主循环都成为插件,不存在只能由人维护的特权内核。
自我进化的上限,不取决于模型能写多好的代码,而取决于承载它的系统有多强的可组合性。
写入参数,以及更新“更新方法”
知识、指令、程序都假设目标能力能被外部符号较完整地表达。医疗影像理解、自然的语音韵律、消除模板化的“AI 味”、长程规划却很难压成几条规则,只能靠后训练写进参数。弯引号的作用域判断处在中间:文档语法边界可以程序解析,语境和例外靠 Skill,跨任务的识别习惯才适合后训练内化。是否参数化也不只看“任务稳不稳定”:新影像设备带来的域偏移仍可能要 LoRA 或持续微调,快速变化的语言风格也能用周期性偏好训练跟上。
明确偏好 →
可靠环境奖励 →
另一条正交的轴:优化的是产物,还是产生产物的方法
五种搜索尺度(不是五种新载体)
越往下越难归因反复重写 vs 增量条目:为什么要“最小 diff、保留来源”
示意 · 条目取自本章规则多轮改写后,少数重要细节可能悄悄消失,相互制约的条件被合并成一句过度抽象的原则。MCE 的区分:改一条检索规则是在改内容管理机制;比较多种检索与整理机制、保留迁移效果更好的版本,才是在学习“如何管理上下文”。
实验 9-8 · 把这本书交给 Hermes:它能升级自己吗
一次提案被接受,只证明更新流程成立,不能自动证明下游能力提升了。
构建可长期运行的持续进化闭环
四种更新方式要进入同一个自主循环,才会从单次优化变成持续进化。更稳妥的做法是双循环:在线循环只做任务、记证据,不直接改写正式 Agent;离线循环聚合轨迹、诊断根因、生成提案,过验证门槛后发布。两者通过版本化的经验库和评估集连接。
正式版本不在运行中直接改写;可信根(权限、审计、验证、回滚)不由普通进化流程自己修改。
图 9-5 · 在线执行与离线进化的双循环
时间轴为示意。v1 一直在服务真实流量,离线循环在旁边产出 v2;v2 先灰度、监控,可回滚,最后晋升为新稳定版。
Voyager:三个机制缺一不可
Minecraft课程按当前物品、环境和已掌握技能提出难度适中的目标;技能库把成功程序存成可检索、可组合的代码(高级采集技能调用移动、制作等基础技能);迭代提示把观察、执行错误和自验证结果带回下一轮,直到任务真正通过。
发现循环 = 科学方法
Jeff Dean 等人于 2026 年 8 月 5 日宣布创立的 Discovery Loop,要把“提出实验、实现、评估、取得结果、交给下一轮”自动化。自我进化要避免自说自话,就得遵循这个方法。
“更新能力”≠“受益能力”:端到端分数不能反推更新器好坏
表 9-3 · 点每一环切换Harness 更新能力:从轨迹产生有价值的持久修改。Harness 受益能力:任务 Agent 之后能找到、激活并正确使用这些修改。一个完全正确的 Skill,弱模型可能没在合适场景加载,或加载后不能长期遵循。Lin 等人的模型替换实验表明,这两种能力与基础模型能力的关系并不相同。
回退
新经验是否与旧经验冲突,原本通过的案例是否退化。
泛化
在测试集未覆盖的场景里是否带来提升。
Token 效率
完成任务消耗的 Token 成本。
安全
规则、隐私、拒绝边界是否随进化漂移。
长期工程质量
维护复杂度、架构一致性、所有权边界、向后兼容、未来迁移与调试负担。
评估是过程的一部分
不是学完才考的期末考试。只修好了当前失败、却在其他案例或新领域退化,不算成功的持续进化。
实验 9-9 · 它真的在持续进化吗
记住 → 迁移 → 更新 → 保持最终分数高还不够:继续用已废止的规则、靠违规捷径完成任务、更新后破坏原有能力,都不能判定为持续进化。
9.3.1 · 当“完成”不等于“进步”
Coding、工具调用、业务状态变更有测试、环境状态或确定性规则做快速反馈,闭环最容易成立。开放式科研、战略规划、复杂产品设计则反馈慢、答案不唯一,研究品味和长期价值很难打分。Harness 可能把流程跑得很完整,却只是稳定地产出“像成果的东西”。
自动科研压力测试:四次端到端尝试
Trehan & Chopra实现漂移
原方案一变难,就退回训练数据里更熟悉、但已偏离研究假设的普通实现。
认识论上的过度乐观
信号可能只是噪声,系统却开始解释、打补丁、宣布发现;阴性结果被忽略。
隐性判断力不足
能跑实验,却不知道哪个基线重要、哪个异常值得追、何时放弃假设。
不能靠换模型解决,要改证据和监督结构:
安全边界与睡眠学习
自我进化能把一次错误变成长期风险:网页、邮件、工具输出里的提示注入被总结成经验,会跨会话反复生效;自动搜来的恶意软件包被封装成工具,影响会扩散到所有后续任务;有缺陷的验证器会一直批准看似进步、实际退化的版本。所以除了验证“是否更强”,还要限制谁能改什么、依据来自哪里。
三道边界:选一种威胁,看在哪里被拦下
睡眠学习:离线整合、遗忘与能力保鲜
“睡眠学习”是认知类比,不要求真在夜里跑。在线 Agent 先完成任务、追加不可变证据;后台进程在空闲期或满足门控时读一批新经历,比较新旧结论、合并重复、解决冲突、提出更新并跑回归。这样一次偶发成功、网络故障或恶意输入不会立刻改写长期能力,整理也能用更大的批量和更便宜的模型。
一个睡眠学习周期
Claude Code 自动记忆
用户记忆,不是行动经验每个项目一份 MEMORY.md 索引 + 按主题拆分的详细文件;会话启动只加载索引的有界前缀,其余按需读;索引接近上限时要求 Agent 合并或移走细节。说明纯文本记忆也需要容量约束、分层加载和主动整理。但公开机制主要是在会话中持续写入,不能简单等同于固定的夜间后台任务。
Hermes:更完整的后台记忆进化
历史检索返回原始消息而非 LLM 摘要,避免把检索和生成混成一个不可审计的步骤。任务里工具调用多、从错误或死路恢复、被用户纠正、发现了不显然的工作流时,后台复盘可以创建或局部修订 Skill,写入可过审批门控。独立的 Curator 跟踪 Skill 的使用、陈旧与归档,空闲期做确定性修剪,可选 LLM 合并;变更前存快照,可回滚。
持续进化不是无限增长:上下文腐化会在更长时间尺度上重现
周期性离线整理合并重复经验,保留来源和版本
把局部规则从全局 Prompt 移到领域 Skill,保持全局 Prompt 整洁
Prompt 和 Skill 保持结构清晰
重新验证长期未用的工具
删除被新证据推翻的知识
从原始基座模型重新训练 LoRA(防多次微调的灾难性遗忘)
在模型外围,建一套可验证的学习系统
一、信号先行
从环境交互和评价获得学习信号:结果、过程、质量三层,逐维度给结论和证据位置,证据不足就拒评。
二、按表示性质选载体
知识、Prompt / Skill、程序、参数四种载体互补。也可以优化产生这些产物的方法,但优先可归因、可验证、可回滚的局部修改。
三、在线记录,离线进化
边界集要变好、保留集不能变差;灰度、整理、回滚。结果能自动验证的任务最可靠;目标模糊、反馈延迟时,人仍要参与定义问题和评价标准。
放在全书结构里,本章构建的是第一章发现循环中的“实验与反馈”环节:提案已经有了,问题变成怎样通过一次基于真实观测的实验,判断它到底有没有让系统变好,再把结果送回下一轮。
这些都不算持续进化
思考题
1 ★★ 一条经验由三次成功和一次失败支持,失败发生在较新的 API 版本上。经验被推翻了,还是适用条件变了?
提示:看证据表是否记录了环境版本。若失败只出现在新版本、旧版本上的成功依然成立,更像适用条件变化,应把经验限定到旧版本并为新版本另起草案;若同版本下也有反驳,才考虑推翻。最后用未参与提炼的新任务验证(见 9.2.1 证据表演示)。
2 ★★ 客服满意度上升,规则违规率也上升。为什么不能把满意度作为单一学习信号?护栏指标怎么设计?
提示:满意度属于质量层,无法区分“结果以允许的路径达成”。按表 9-1 拆维度:规则遵从、隐私边界、承诺—行动一致性由代码判定,作为不可退化的护栏;满意度只在护栏全部通过时参与比较。
3 ★★★ 同一个“虚假承诺”问题可以用 Prompt、Harness 检查或参数训练缓解。依据哪些证据选择修改位置?
提示:先问能否被事实、语言规则或程序完整表达。“声称完成的操作必须有对应工具日志”可以精确比对,适合 Harness 检查兜底;措辞层面的过度承诺可由 Prompt/Skill 说明;若是跨任务的隐式习惯,再考虑把评价过的轨迹做成偏好数据。看失败标签的分布与证据位置来决定。
4 ★★★ Agent 能改工具和验证器,却不应改批准自身更新的可信根。怎样划分权限和代码边界?
提示:参考 9.3.2 第三道边界与图 9-5。批准该次更新的验证器、测试用例、发布门槛、审计日志、稳定版本备份放在 Agent 的修改权限之外(独立仓库/权限、只读挂载),Agent 提出的变更通过 PR 由独立 reviewer 审批。
5 ★★ 经验库越来越大,检索错误和知识冲突会抵消收益。版本、时效和淘汰机制怎么设计?
提示:文档写明适用场景、来源、最近验证时间;版本化、可替换而非只追加(实验 9-9);睡眠学习周期里合并重复、标记冲突、过期或归档被推翻的条目,保留回滚版本。
6 ★★★ 参数学习擅长语言风格,却难以保证硬性业务规则。为医疗客服设计参数、知识、Skill、代码约束协同的进化方案。
提示:仿照书中医疗影像与客服的拆分——语气和表达靠后训练;最新指南和政策进知识库;解释例外和优先级的原则写成 Skill;不可绕过的合规与权限由服务端代码门控。每种载体各自走边界集 + 保留集验证。
动手验证
实验 9-1 ★★ · 为客服 Agent 构建轨迹验证器
对照“只输出一个总分”与“逐维度输出结论、证据与置信度”,看哪种更容易区分任务失败、规则违规、虚假承诺和表达问题;低置信度案例不进学习集。
实验 9-2 ★★ · 从 τ²-bench 失败轨迹提炼转接与工具使用规则
弱模型跑提炼集、存失败轨迹,模型归纳规则追加到政策末尾;在不相交的迁移集上对照原始策略与两个进化版本,只换策略文件。除通过率外记录转接比例、越界调用用户侧工具次数、缺参即调次数。
实验 9-3 ★★ · 基于失败轨迹优化航空客服的系统 Prompt
修复“普通政策争议就过早转人工”,同时保留明确要求人工和安全事件的转接;与初始版本、人工调优版本对照。
实验 9-4 ★★ · 从用户反馈中进化需求澄清与 Spec 确认 Skill
低风险低歧义任务组 vs 涉及架构、权限、数据或公开接口的高风险组;比较三种流程,提案过留出任务回归、打扰成本检查和高风险否决器。
实验 9-5 ★★★ · 从浏览器轨迹生成可验证工作流
一次成功轨迹编译成带参数和状态检查的工作流,与每次重新探索对比;改页面或制造假成功,看它是否失效并回退到完整 Agent。
实验 9-6 ★★★ · 由失败轨迹触发 Agent 自我修改
“只在 Prompt 提醒不要重试” vs “改程序里的重试策略”;过失败轨迹重放、正常故障回归和安全发布门槛,且不能改验证器或稳定版本。
实验 9-7 ★★ · 由用户反馈触发高风险操作确认门禁
危险操作边界集 + 正常操作保留集共同评价门禁提案:既要拦住未确认的高风险调用,又不能阻断正常任务;生成提案的 Agent 无权改安全测试和批准规则。
实验 9-8 ★★★ · 把这本书交给 Hermes:它能升级自己吗?
不预设修复目标,观察它能否把原则映射到自己的代码,并按 Reviewer 退回意见继续修正。
实验 9-9 ★★★ · 评估 Agent 是否在持续进化
先给反馈,再面对表述变化、规则更新、原有能力保持;对照静态记忆、只追加记忆、可替换/可淘汰的版本化记忆。