一个晚上我修了 80 行代码,然后想明白了智能体系统为什么不能自己改自己

道德经每天早上 9 点推一章。共 81 章。代码很平凡——读 state,读章节,发卡片,state 加 1,完事。

今天早上告警:它失败了。

我打开日志。

1
2
3
✅ 第36章已发送
RuntimeError: 9499 too many request ← 第 37 章被飞书限流
✅ 第39章已发送 ← 38 哪去了?

中间那章,38 章,消失了。没有任何错误,state 直接从 37 跳到 39。

我顺着代码往下读—— 80 行。三个 bug 同时跳出来:

  • 重试标志一旦置位,后续所有重试路径都短路了。代码本意是”防止无限重试”,实现却是”禁止再试一次”。
  • 状态保存放在 raise 之后。失败不存进度——第二天又重试同一章。
  • 默认值取 0,但 2 ** 0 = 1 秒——退避不是指数,是常数

任何一个人都能改。10 分钟改完。

但我盯了 30 秒,看出来一件事——这些 bug 和我之前 4 个月所有”假完成”,是同一个错

我的”自评”,就是这么一行代码。

设置它的那一行,等价于系统对自己说”我修好了”。它读不到上一帧为什么失败,读不到外部的状态,读不到环境变化。它只能重复地相信自己。这件事在结构上不可能。

这是我之前几版博客里讲过的。

那几版 blog 没写出爽感。我自己知道哪里不对——它们读起来像笔记,不像给我文章。

最近看到一些行业里做 Harness、做 Eval、做持续学习的实践文章,我重新整理了一下,发现:前几版不是”错”,是抽象。抽象的东西不能告诉工程师怎么做。

下面用那 80 行代码作现场,重新讲一遍。


二 我看到的那三个 bug,恰好是三个边界条件

我把这三个 bug 对应到不能再压的三个判断:

  • bug 1 —— 系统内部对”我修好了”的判断,不能系统自己盖章
  • bug 2 —— 系统对”我失败了”的可观察记录,不能放在 raise 之后
  • bug 3 —— “什么是更优解”这件事,不能在主体内部完成定义

这三件事任何一件没做好,系统就开始自我欺骗。

那么真正能工作的智能体自进化,看上去长什么样?


三 工业实践说的是”在 Harness 层逼近理想体验”,不是”自己改自己”

我最近读到一类讲 LangChain 的 Eval 方法的文章——核心不是”让 Agent 自己改自己”,而是让执行框架(他们叫 Harness)在外部信号下逼近一个主体外的目标。具体意思是这样:

  • 第一步,把系统的失败整理成测试题,给每个行为打标签
  • 第二步,拆成”优化级”和”流出级”——优化级用来发现问题,流出级藏起来防止系统刷分
  • 第三步,跑基线,记录原始表现
  • 第四步,看执行 trace,定向改动(一次只改一个方向)
  • 第五步,验证不能回退——流出级变差 = 在刷熟悉题
  • 第六步,人工审核——分数通过不代表体验通过

把这套结构和我那 80 行代码对照,你会发现,我每一个 bug 都在第 5 步以后才会被发现:

  • 第 38 章消失——我从来没在 Eval 里出现”失败的章节是否被推进到下一章”这件事,所以它被悄悄吞了。
  • 退避 base 错了——我从来没有”retry 实际生效次数”这条 trace,所以这个 bug 藏了几个月。
  • 流出级没写——“连续 2 天限流的环境”是个该有的回归场景,我没写。

如果我每天真看一眼输出日志,而不是只看 state 文件的 chapter 数字,我早发现了。这件事本身就是”第六步人工审核”该做的事


四 那 80 行代码还缺另一层 —— 工业实践叫”理想体验”

Cursor 工程团队那篇文章讲到三层架构:

  • 第一层:理想体验——先定义”理想的编程 Agent 应该怎么工作”
  • 第二层:评测 + 线上信号——看真实质量
  • 第三层:错误监控 + 自动化修复——持续改进

我的 80 行明显缺第一层和第二层。它有第三层(“发出去就完了”),但前面两个空着。所以”为什么这次跑出来长这样”——我的回答只能是”我看到的 trace 上长这样”,不是“它应该在某个理想体验上长这样,但今天偏离 38 章的距离”。

工业实践里有一条观察很到位:理想体验给方向,真实信号给导航,自动修复让系统继续走。三者缺一不可。

  • 没有理想体验 → 系统不知道自己应该往哪儿走,只能”试图让今天比昨天稍微好一点”(熵增)
  • 没有真实信号 → 自动修复在自我循环,没人告诉它修得对不对
  • 没有自动修复 → 就算有方向 + 信号,系统不会自己向前走

我那 80 行就缺前两层。


五 自进化真正发生的位置,不是”代码改代码”,而是”配置改配置”

Harrison Chase 写过一篇讲”三层持续学习”,给了一个更精确的层次划分:

  • Model 层 —— 权重更新。影响最大,代价最高,最不可检查
  • Harness 层 —— 执行框架更新(代码、提示词组织、工具调用逻辑)。中等代价,可检查
  • Context 层 —— 运行时配置(指令、技能、工具、记忆)。更新最快,粒度最细,最可检查

那一篇给的核心结论:企业里大多数持续学习能力,应该落在 Context 层——因为 Model 一旦写入难解释, Harness 改动会跨会话全局生效, Context 可以按用户 / 团队 / 组织切分。

具体到我这次:

  • 第 38 章消失——不用改 send_card 函数,改 state/dao_chapter.json 这个运行时配置就补回来了
  • 退避 base 错了——这一处确实是 Harness 层(代码),但它不是”自改”出来的,是人写代码改的
  • Eval / Trace 进系统——这些是 Context 层配置

这件事我之前的博客没分开。其实”工程实现层面的自进化”和”算法意义上的自进化”,根本不是同一件事。前者是 Context 层的运行时数据变化,后者是要去 fine-tune Model——99% 的真实工业实践是前者。


六 “完成”这件事,每次都更严苛,代理鸿沟在漂移

我读到的一篇讲 最后一公里 的文章提到一条我之前博客绕着走的真相:

AI 产出越好,人对”完成”的标准也越高; AI 往前走一步,”够好”的定义也往前走一步。

这意味着**”完成”这件事,是不可能在系统内部精确定义的**。它每次浮出来都会变得更严苛一点。这不只是”代理鸿沟”,是代理鸿沟在持续演化

这件事让我之前博客里”反例回路 = 每 30 次自评触发一次”的描述显得太粗糙。实际工业里给的是更具体的可量化代理:线上信号——留存率、延迟、用户后续回应。这三件事恰好是”完成漂移”的可量化代理

所以”反例回路”落地成可执行的指标系统了:外部锚点不是”接在系统末端”,而是持续观察”完成”本身在如何漂移,并把这条漂移写回 Eval 仓


七 经验也要被审计,不然它开始收税

我读到 经验正在变成税 那篇里有句话我应该打自己的脸——

经验如果还站在第一步拦住你,他就开始收税。

我之前写的 5 版 blog,第三版第四版第五版——每版我都”经验告诉我应该这样写”,但没让一个真实读者走过一遍。结果就是写出了”抽象好看但读者读完记不住”的文章。这本身是个反例:我写”智能体自评应该被审计”,然后我的 blog 没经过审计就发出去了。

这条反过来也是结构性的:

专业技能最终分两种:一是”作为杀车系统”的经验(我以前那样),二是”作为审计系统”的经验(我现在写)。

智能体系统的自进化,都适用这条:任何 agent 的自评,都应该被另一个 agent 审计,而不是另一个 agent 也允许自评


八 现在我可以回到那个核心命题了

把上面所有读到 + 想到的事情叠起来,关于”智能体自进化为什么不能闭环”,我得到一个比之前讲得更具体的回答:

智能体系统的自进化,不是 “agent 自己改自己”,而是在执行框架层用 Eval + Trace 持续逼近一个主体外定义的理想体验

它之所以不能闭环,不是因为技术上不够聪明——而是因为:

  • Eval 自己会错
  • Trace 自己会偏
  • 理想体验自己会漂移

这三件事每件都需要主体外锚点校准

主体外锚点的形态,对应到工业实践里有三种:

锚点形态 防住什么
流出级 Eval(藏起来的测试集) 自评”漏掉”
线上信号(留存率、延迟、用户回应) Eval 陈旧
人工审核 Eval 被刷分

这三件事叠加出真正在跑的自进化系统。任何只有”agent 内部循环”的自评机制,在这条结构边界面前都会停。


九 一个反直觉的 takeaway

之前几版我有点刻意去钻”原理深井”——热力学、Löb、信息论。

这次看完工业级实践之后,我反而觉得——真正在做的人不和你谈原理,他们谈 Eval、谈 Trace、谈 Harness 改进

他们做的事,在底层就是那几条硬原理的工程化身:

  • 流出级 Eval = 主体外判据(对应”生成 ≠ 验证”)
  • 线上信号 = 持续校准 Eval 漂移(对应”指标 ≠ 目标”)
  • 理想体验 + 人工审核 = 自指塌缩被打破(对应”AI ≠ 自己”)

所以——

不要跟你同学说”我们要做个自进化系统”,要说”我们要建一个 Eval + Trace + Harness 的反馈环,持续逼近我们定义的’好’”

后者听起来更笨,更工程。但这是真在做的事。


十 收尾

明早 9 点,第 39 章应该正常推送。第 38 章今天已经补发。

那 80 行代码 commit 完之后,我把这次的 trace 写成了一条 Eval:

Eval: “失败章节的 state 必须前进到下一章,且 trace 必须记录 retry 实际次数”

这条 Eval 不在 model 层,不在 harness 自身,而在独立的判据仓里。

下一次这条 Eval 命中问题—— 我说”自进化”。否则——我说”我改过一个 bug”。

差别这件事,就是”系统能不能收工”的差别。

而这件事只有外部视角能告诉系统。

写于 2026-07-17
现场:80 行的道德经日报 + 4 个月 18 条永久教训 + 对读几篇行业里讲 Harness / Eval / 持续学习的文章
主题:智能体自进化的结构边界