第 23 章 · 受控自进化

核心观点 + 逻辑框架（调优篇 · 让走通的方法被稳定采用，反复问题逐渐减少，同时控制成本）

原书章节 ↗

▍速览

一句话版（开场，约 20 秒）

受控自进化 = 让已经走通的方法被稳定采用。路径是：先选一类值得反复做好的任务，建经验库并检查挖掘质量，把经验接入 Agent 并亲自验证召回，用实验决定召回多少、什么时候用，把稳定方法整理成 Skill/SQL/Script/Workflow 资产，用失败样本推动 Skill 甚至 Harness 的改进，最后按成熟度从人工选择候选走向受控自动采用。

一段话版（完整表达，约 90 秒）

排障 Agent 解决过某类问题，下次相似故障仍可能重新探索、尝试错误参数甚至遗漏关键步骤——自进化的目标是让验证过的方法稳定复用，让反复出现的问题逐渐减少，同时控制每次任务的时间和成本。第一步选任务：目标明确、重复出现、能检查结果；先判断 Agent 是缺方法、重复生成，还是被工具或运行环境阻碍——相似故障总在重新探索就建经验库，漏掉前置检查就补 Skill，反复写相近脚本就整理 SQL 模板与 Script，固定流程靠人盯就接 Workflow，重复提交、恢复后状态不明就改 Harness。经验库保存"遇到什么情况可以怎样处理"，先确认有可用轨迹（能看到用户目标、关键工具调用与结果），再创建并选来源，检查代表经验三件事：解决什么问题、建议什么动作、什么条件下适用，并回到来源 Trace 确认动作真的出现、结果支持建议；泛化要求（"仔细分析、正确调用工具"）要补代表性轨迹。接入：安装召回 Skill、配置库地址与 API Key、允许必要调用，然后执行一次真实查询验收——口头说"参考了历史经验"必须对应真实调用；按现象定位：没发起查询查 Skill 启用与权限、查询失败查地址凭证、为空查库内容与表达、命中未采用查上下文与前提。召回策略用实验定：保留不用经验的 Baseline，换新会话重发同请求；调整召回阈值、返回数量、触发时机、放置位置与长度、使用要求，验收回到业务（排障看根因与证据、代码看测试、报告看口径），再比耗时 Token 工具调用费用，波动时重复测试，用未参与挖掘的同类任务检查；某条经验反复误导就缩小使用范围或停止采用，保留出问题任务作反例。稳定做法资产化：SQL 模板把现场值变参数并附口径说明，Script 封装重复工作，Skill 说明何时用和怎样核对，Workflow 接固定步骤——不必一次交齐四种，先解决最大开销；采用前换参数验证、加空数据与字段变化异常样本、新任务端到端验证。失败样本改进：写清"应该在哪一步采取什么行动"，SkillForge 依据轨迹生成局部补丁，审查是否解决问题、是否保留原有有效方法；Harness 改进针对执行机制——以"提交后会话恢复再次提交"为例，恢复行为区分尚未开始、已开始但结果未知、已完成，结果未知先核对业务状态再决定动作，并在可控环境针对性验收。受控采用按成熟度渐进：手动调优=专家挑问题改一条资产；半自动=系统生成候选人比较决定；受控自动=规定范围内自动检查实验、满足条件采用、异常交人。每次采用确认四件事：目标问题改善、原有任务不退化、额外代价可接受、目标 Agent 实际使用了被验证内容；记录原版本、候选差异、实验结果与采用范围，保留回退办法。有效方法留给下次执行，反例交回 Dataset 与评估实验——数据飞轮的价值最终体现在任务更稳定地完成。

• 选任务 目标明确·重复出现·能检查结果；先判缺方法/重复生成/环境阻碍
• 经验库 "遇到什么情况可以怎样处理"；检查三件事+回来源验证
• 接入 装召回 Skill→配置→授权→真实查询验收；口头参考≠真实调用
• 实验 五因素调召回（阈值/数量/时机/位置/要求），验收回业务
• 资产化 SQL/Script/Skill/Workflow 组合；失败样本推动 Skill/Harness

收尾

团队调整的是具体使用方法，而不是笼统地判断"经验有没有用"。

▍逻辑框架（记忆卡片）

① 命题：让走通的方法被稳定采用

• 排障/代码 Agent 解决过某类问题，下次相似场景仍可能重新查资料、试错误参数、漏关键步骤
• 目标：已走通的方法被稳定采用 · 反复出现的问题逐渐减少 · 控制每次任务的时间与成本
• 路径：选任务 → 建经验库 → 接入验证召回 → 实验定策略 → 资产化 → 失败样本推动 Skill/Harness → 受控采用

数据飞轮的价值最终体现在任务更稳定地完成，以及团队能说明每一项改进为什么值得保留。

② 先选一类值得反复做好的任务

• 选：目标明确、重复出现、能检查结果的业务；负责人先说明什么算完成，维护者从 Trace 找成功+失败任务对照
• 先判断 Agent 是缺方法、重复生成相同代码，还是被工具/运行环境阻碍
• 五现象→先尝试：相似故障总重新探索→建经验库；漏前置检查/测试→补 Skill；反复写相近查询脚本→SQL 模板/Script 工具；固定流程靠人盯→接 Workflow；重复提交/恢复状态不明/长任务忘约束→改 Harness

例：排障 Agent 查询范围过大，先在 Skill 补"按故障时间和对象缩小范围"；查询工具不支持过滤，就由工具维护者补能力。

③ 建好经验库，让团队能检查挖掘出了什么

• 经验库保存**"遇到什么情况，可以怎样处理"**；"先找首次异常再分析连续重试"比某次故障的最终答案更有复用价值
• 先确认有可用轨迹：打开真实任务，检查用户目标、关键工具调用与结果可见；只有最终回答先补接入
• 创建并选来源：围绕一类相近任务选取近期数据，时间范围覆盖成功、失败及失败后恢复；不必为条数纳入规则已过时的历史
• 检查代表经验三件事：解决什么问题 / 建议什么动作 / 什么条件下适用；回到来源 Trace 确认动作真的出现、结果支持建议

例："查询不到日志时扩大时间窗口"——先判断当时是窗口太短还是数据根本没采集：前者可复用查询方法，后者应先处理接入。来源与不适用条件帮助团队避免把一次现场处置变成所有任务的固定要求。

④ 把经验接入 Agent，并亲自验证一次召回

• 1 安装召回 Skill：alibabacloud-agentloop-experience，确认 Agent 能发现该 Skill（装的是访问能力，经验运行时查询）
• 2 配置当前经验库：库地址 + API Key + 召回开关；核对实际工作目录与生效配置，避免连到另一项目的库
• 3 允许必要调用：Skill 白名单、工具权限按目标 Agent 接入方式配置
• 4 执行一次真实查询：用已检查过的经验测试返回内容与来源，再让 Agent 跑完整任务观察在哪一步使用；口头说"参考了历史经验"必须对应真实调用记录

按现象定位：没发起查询→Skill 启用/触发说明/工具权限；查询失败→地址空间库名凭证；成功但为空→库内容、查询表达、过滤范围；命中未采用→返回内容是否进上下文、前提是否适用。分开排查，避免反复调阈值却没解决接入问题。

⑤ 用实验决定召回多少、什么时候用

• 经验缩短探索也会增加检索阅读开销——短任务多查一次未必划算，复杂排障一条方法可能省多轮试错，策略按业务实验选
• Baseline=不使用经验；换 Session ID 重发同请求，重置任务依赖状态，避免上轮答案/文件让下轮变容易
• 五因素：召回阈值（严格 vs 宽松）/ 返回数量（一条 vs 多条）/ 触发时机（规划前 vs 失败后）/ 放置位置与长度（精简冗余）/ 使用要求（历史参考、采用前检查当前条件）
• 验收回业务：排障看根因/证据/无效查询减少；代码看需求满足/测试有效；报告看口径；再比耗时/Token/工具调用/费用，召回开销计入；波动重复测，保留不需经验的对照任务，决定采用前用未参与挖掘的同类任务检查

某条经验让 Agent 反复扩大范围、照搬历史参数→先缩小使用范围或停止采用，保留出问题任务作反例；下一轮修改内容或召回策略后再验证。

⑥ 把稳定方法变成资产，用失败样本推动 Skill/Harness

• 四类资产可组合：SQL 模板=去重计数分组逻辑+现场值变参数+字段/时区/空结果说明；Script/工具=封装分页解析汇总，短参入结构化出；Skill=何时用、先确认什么口径、字段变化怎么办、完成后如何核对；Workflow=固定步骤+空数据/失败/口径不匹配的异常分支
• 不必一次交齐：最大开销在重复生成查询→先 SQL 模板；常漏验收→先修 Skill；步骤与异常分支稳定→再接 Workflow
• 采用前验证：换一组时间与应用参数执行；加空数据/重复记录/字段变化样本；新任务端到端确认 Agent 能找到资产并正确调用
• 失败样本改进 Skill：写清"应在哪一步采取什么行动"；SkillForge 依轨迹生成局部补丁——表格 Agent 例：写入前确认目标工作表、提交前检查公式、完成后回读目标单元格，逐项对应执行证据
• Harness 改进：以"提交已发生、会话恢复再次提交"为例——恢复行为区分尚未开始/已开始结果未知/已完成，结果未知先核对业务状态再决定动作；可控环境模拟提交前中断与结果未保存，检查是否重复操作、最终业务状态正确；验证任务须真正触发原问题

新 Skill 用目标 Badcase + 原本成功任务 + 不应触发的任务一起检验，确认修复没有变成所有任务的额外负担；这类调优让稳定部分少依赖临场生成，把口径与验收方法分享给整个团队。

⑦ 从人工选择候选，到受控采用改进

• 手动调优：专家挑问题看轨迹，维护者改一条 Skill/查询/配置 → 一项具体修改+验证结果
• 半自动调优：系统整理失败模式/挖掘经验/生成候选，人比较方案、安排实验、决定采用 → 经审查的候选+实验差异+采用范围
• 受控自动调优：规定范围内由接入流程自动运行检查与实验，满足条件采用、异常交负责人 → 按规则采用的改进+可检查的运行反馈
• 每次采用确认四件事：目标问题是否改善 · 原有任务是否退化 · 额外代价是否可接受 · 目标 Agent 是否实际使用了被验证内容；记录原版本/候选差异/实验结果/采用范围，保留异常恢复办法

经验召回出问题要调召回或采用设置——仅暂停挖掘不会停止旧经验继续影响任务；适合先自动化的动作：高频、范围清楚、结果容易检查。自动化程度提高，证据要求与授权边界不降低。

发布管控：版本绑定（证据/批准/实际版本一致） · 缺证阻断（关键依据不完整不发布） · 例外可追溯（记录理由/责任人/允许范围）

▍逻辑全景图（受控自进化闭环：经验库质量门禁 → 接入召回 → 实验定策略 → 资产化 → 受控采用）

让已验证的方法稳定复用，反复问题减少，代价受控，改进可解释可回退

• 经验建设与质量门禁
• 接入与实验
• 资产化与改进
• 受控采用

示意 · 按第 23 章正文与图 23.2 质量门禁、图 23.7 三档演进重构

▍书中关键图（SVG 重绘版·示意）① 经验随任务反馈修订：质量门禁流转

示意 · 按原书图 23.2"经验随任务反馈修订"重绘

▍书中关键图（SVG 重绘版·示意）② 从人工选择候选到受控采用

示意 · 按原书图 23.7"从人工选择候选到受控采用"重绘