---
title: '25 自退火工作流'
video_id: MxyRjL7NG18
part: 25
---

> 章节 25 / 37 · [[00-总览|课程总览]] · 起始 [3:41:01](https://youtu.be/MxyRjL7NG18?t=13261)


## 章节主旨

用冶金「退火」作类比,讲一个让 agentic 工作流随运行逐步自我加固的机制:每遇错误就诊断、修复、并把修复经验写回指令,使脆弱系统随时间变得强韧。核心手段只是给系统提示加一段错误处理指令。

## 核心论点

1. **自退火工作流 让系统越用越强,而非越用越脆**——脆弱系统每次出错就崩,自退火系统每次出错都被反向加固。(→ 详解1、2)
2. **秘诀是给系统提示注入「有思考的错误处理」**——把「出错就问用户」的默认模式改成「先自己诊断修复,再更新脚本」。(→ 详解3、5)
3. **自退火跑的是一个四步循环**:出错 → 诊断 → 尝试修复 → 更新指令,循环到成功或撞上真正需要人的墙。([[#3-四步自退火循环-34419|→ 详解3]])
4. **该给 agent 的自主度对标「能自救的员工 B」而非「事事甩锅的员工 A」**——这是判断值不值得授权的直觉标尺。([[#4-创意绕行40-篇博客凑到-50-篇的例子-34558|→ 详解4]])
5. **加固会自发涌现**:retry、指数退避、并行化等改进模型会主动补上,你没预料的边缘情况被逐一吸收。([[#6-如何启用一段指令--涌现式加固-34832|→ 详解6]])

## 知识点详解

### 1. 退火类比:从「一根细线」到「久经战阵的协议」 [3:41:13](https://youtu.be/MxyRjL7NG18?t=13273)

冶金里的 annealing 是把金属加热再缓慢冷却:高温下原子从杂乱移向最低能态、排成晶格,再快速冷却定型,内部错位被消除,得到更强更稳的结构。铁匠打刀几百年都这么干。

把这个概念搬到 agentic 工作流:第一天你手里只有一份粗糙大纲——step 1 做 X、step 2 做 Y,不过是纸上几条 bullet point,即便让 agent 生成 directive 也不够严密。

用满 60 天后,同一个工作流不再是那根「细弱的小线」,而是布满护盾的强韧协议:每个护盾是一处 retry 逻辑,还长出验证步骤、以及你当初没意识到需要的 human-in-the-loop 节点。

### 2. 自退火的本质:把「问题」重定义为「机会」 [3:42:49](https://youtu.be/MxyRjL7NG18?t=13369)

每一次撞上错误、问题或改进机会,系统就强化那条流程一次。区别于 n8n / Make 这类一出错就崩的脆弱系统,自退火系统在出错时反而变结实。

关键心态转变:问题不再是「报错」意义上的麻烦,而是你和模型一起构建边缘情况处理、错误处理、当初没想到的额外步骤的素材。很多情况下,唯一的认知途径就是多跑几遍、把坑一个个踩出来。

### 3. 四步自退火循环 [3:44:19](https://youtu.be/MxyRjL7NG18?t=13459)

进入循环后的机械动作:先出现某个错误,立刻诊断错误来源,尝试某种修复,修复后更新——即真的去改工作流 / 执行脚本本身,然后不断轮转。

一旦跑通,做一次「文档升级」:告诉 directive「这是以前常见的问题,已加固,现在好多了」。下次再出错,同样走 出错 → 诊断 → 尝试修复 → 更新,循环到再也无法循环为止。

agent 会一直跑到操作成功、或撞上真正无法修复、必须人介入的墙。有意思的是,即便某事「不可修复」,agent 常能找到有创意的绕行方案。

### 4. 创意绕行:40 篇博客凑到 50 篇的例子 [3:45:58](https://youtu.be/MxyRjL7NG18?t=13558)

设你的 definition of done 是爬到 50 篇某主题博客,但 scraper 只返回 40 篇,而现实是网上就没有更多了。循环会启动:模型改动最初的一个过滤条件,从 40 拿到 50,技术上完成目标——尽管这已是个根本不同的流程。

因为只做到约 80% 而非 100%,模型会给你发通知:「这大体成了,这个过滤条件也 OK 吗?」你反馈确认后,它把「这个过滤条件也可用」固化下来,防止同样的卡点再次发生。

每一轮循环都让系统比之前更健壮可靠一点。这也是自退火与一次性脚本的分野:脚本永远停在第一天的形态,自退火工作流会长大。

### 5. 员工 A vs 员工 B:该给多少自主度 [3:46:47](https://youtu.be/MxyRjL7NG18?t=13607)

Nick 把 agent 当「许多员工」来想,而人可分两类。员工 A 是「blocker」:一有问题,那问题立刻变成你的问题——「老板我试了 XYZ 没成,能帮我吗」,他不能在没有你干预时推进,全组工作因此停摆,同样的错反复犯、学不会,你沦为他的瓶颈,必须微观管理才行。

员工 B 是明星:遇到同样的问题,但有一条 SOP——先自己试,非必要不上报,尊重你的时间;解决后写文档、在 Slack 广播「遇到 XYZ,可用 XYZ 解决」,让团队永不第二次撞同一个坑。

自退火工作流的行为像员工 B、不像员工 A。这等于给 agent 一个过去多数人会觉得「疯狂」的自主度——但随模型变聪明,「疯狂」的定义会很快改变。这个类比是判断该不该授权的实操标尺。

### 6. 如何启用:一段指令 + 涌现式加固 [3:48:32](https://youtu.be/MxyRjL7NG18?t=13712)

启用只归结为系统提示里的一小段指令:在 CLAUDE.md / GEMINI.md / AGENTS.md 里改掉编程 agent 的默认解题模式。默认模式是「做不到就交回用户、问怎么办」——这对企业级编码合理(小改动可能引发大下游问题),但对模块化、可单元测试、只在 IDE 里跑的简单工作流并不适用。

于是写成:「遇错时先诊断,再修复,再更新脚本与 directive 以应对未来同类错误」;Nick 还会加一句「上报用户前请超级努力地尝试」([3:49:11](https://youtu.be/MxyRjL7NG18?t=13751))。

之后加固自发涌现([3:49:30](https://youtu.be/MxyRjL7NG18?t=13770)):偶发失败处自动补 retry 逻辑、指数退避(exponential backoff)、日志等错误处理;效率改进也自然发生——批量端点、并行化、多 worker;你还能直接反复说「make this thing better」,系统在无持续干预下持续自优化。

## 术语

- self-annealing(自退火):借冶金退火之名,指工作流每遇错即诊断修复并写回指令、随运行逐步加固的机制。
- annealing(退火):加热金属再缓慢冷却使原子归于低能态晶格、消除内部错位、得到更强稳结构的工艺,此处为类比来源。
- definition of done(完成定义):判定任务是否完成的明确标准,如「爬到 50 篇博客」。
- human-in-the-loop(人在环中):在工作流特定节点插入人工确认的设计。
- exponential backoff(指数退避):失败重试时按指数拉长等待间隔的错误处理策略。
- SOP(标准作业程序):此处指员工 B「先自试、非必要不上报、解决即文档化」的处事准则。

## 自检问题

1. 自退火的「四步循环」是哪四步?跑通后额外做什么?
   **答案**:出错 → 诊断 → 尝试修复 → 更新脚本/directive,循环到成功或撞上真正需要人的墙;跑通后做一次「文档升级」,把该问题标记为已加固,供后续复用。[3:44:19](https://youtu.be/MxyRjL7NG18?t=13459)
2. 员工 A 和员工 B 的类比对应 agent 的什么设计取舍?自退火工作流像哪一个?
   **答案**:员工 A(blocker)一遇问题就甩回给你、全组停摆,对应「出错即问用户」的默认模式;员工 B 先自试、非必要不上报、解决即文档化,对应授予高自主度。自退火工作流像员工 B。[3:46:47](https://youtu.be/MxyRjL7NG18?t=13607)
3. 启用自退火在技术上到底改了什么?为什么编程 agent 默认不是这样?
   **答案**:只在 CLAUDE.md / AGENTS.md 等加一段「遇错先诊断、修复、更新指令,上报前超级努力尝试」的指令。默认「做不到就交回用户」是因编程 agent 多用于企业级编码,小改动可能引发大下游问题;而模块化、可单元测试、IDE 内跑的简单工作流不受此限。[3:48:32](https://youtu.be/MxyRjL7NG18?t=13712)
4. 当目标无法 100% 达成时,自退火系统如何处理?
   **答案**:模型找创意绕行(如改过滤条件把 40 篇凑到 50 篇),达约 80% 后主动通知你确认;你反馈后它把该方案固化,防止同类卡点重现,每轮循环使系统更健壮。[3:45:58](https://youtu.be/MxyRjL7NG18?t=13558)