#0135 让 AI Agent 学会自我进化：自主迭代框架设计

type

Post

status

Published

date

Feb 28, 2026

slug

315a745569bb81e083a9e3b1ab10c967

summary

你的 AI Agent 系统上线一个月了，一切看起来运转正常。直到某天你发现：一个健康评分模块已经连续两周给出虚高的分数——明明没有任何运动记录，评分却稳定在 95 分。

让 AI Agent 学会自我进化：自主迭代框架设计

你的 AI Agent 系统上线一个月了，一切看起来运转正常。

直到某天你发现：一个健康评分模块已经连续两周给出虚高的分数——明明没有任何运动记录，评分却稳定在 95 分。定时任务有三个已经悄悄失败了一周，没有人收到告警。交互按钮因为服务重启全部过期，用户点了没反应。

没人犯错。系统只是在正常运行中慢慢腐烂。

这就是 AI Agent 系统的"熵增"问题——不是某个灾难性的故障把系统搞挂，而是一堆微小的退化悄无声息地堆积，直到有人偶然发现时，已经烂了很久。

你不需要更聪明的 Agent，你需要免疫系统

大多数人优化 AI Agent 系统的思路是：prompt 写得更好、模型换更强的、工具链接更多 API。

这些都对，但解决不了熵增问题。

你真正需要的是一套免疫机制——系统能自动发现问题、诊断原因、修复它、然后确保同样的问题不会再出现。

整个闭环长这样：

看起来简单？魔鬼在细节里。

采集层：零 token 成本的"体检"

很多人一上来就想让 LLM 去"巡检"系统——每小时跑一轮分析。

别这么干。 Token 成本会把你吃穷。

正确的做法是：用纯脚本做数据采集，零 LLM 消耗。只在发现异常、需要分析的时候，才让 LLM 介入。

采集脚本应该跑这些指标：

定时任务成功率：多少个跑成功了，多少个失败了，有没有连续失败的

Token 消耗：今天花了多少，跟过去 7 天均值偏离多少

连续失败列表：哪些任务已经连着挂了两次以上

输出一个 JSON，里面有个关键字段：needs_iteration。

触发条件很简单：

定时任务成功率低于 90%

Token 消耗偏离 7 日均值超过 50%

任何任务连续失败 2 次以上

命中任何一个，{{CODE，启动诊断。否则完全静默。}}

这个设计的好处是：正常情况下，你的迭代系统每天只消耗一次脚本执行的成本——大约等于零。只有出问题时才烧 token，而出问题时你应该烧这些 token。

三级权限：为什么不能全自动也不能全手动

发现了问题，要修。但修到什么程度？谁来决定？

我们设计了三级权限机制：

L1 - 自动执行：安全的小修复，直接做。

比如某个定时任务 timeout 30 秒太短经常超时？改成 60 秒。这种改动风险极低，自动执行 + 记录变更日志就行，没必要每次都来问你。

L2 - 通知建议：需要你知道，但不需要你立刻动手。

比如今天 token 消耗比平时高了三倍——可能是你今天用得多，也可能是某个 prompt 泄漏了。系统会推一条通知告诉你，附上分析和建议，你有空再看。

L3 - 审批改动：动核心配置、改提示词、调模型——必须你点"确认"才执行。

为什么不能全自动？因为 AI Agent 不该有不受限的自我修改权限。一个能随意改自己提示词的系统，距离跑偏只差一个幻觉。

为什么不能全手动？因为你总会错过通知。那些 timeout 从 30 秒调到 60 秒的琐碎修复，如果每个都要你审批，你会在第三天开始无视所有通知。

三级权限的本质是：把你的注意力用在刀刃上。

真实踩过的坑（脱敏版）

讲三个真实案例，你大概率也会遇到。

案例一：评分虚高——数据不等于洞察

某个健康评分模块，会综合多个维度给出一个日度得分。其中有个"运动"维度，逻辑是根据活跃时长来打分。

问题是：API 返回的"活跃时长"包含了日常步行——从卧室走到厨房也算。所以哪怕你一整天没有任何正经运动，这个维度照样能拿 90+ 分。

更讽刺的是，系统确实拉取了详细的运动记录列表，列表是空的——但评分逻辑根本没检查这个字段。

一个合格的自主迭代系统应该能自动捕捉到这个矛盾：运动记录为空，但运动评分 95？这不对劲。触发诊断，标记为 L2 通知用户。

教训： 采集指标时不要只看最终得分，要检查得分和原始数据之间的一致性。高分不代表没问题，低分也不一定是坏事。

案例二：按钮过期——重启是系统的遗忘

很多 Agent 系统用交互按钮跟用户沟通——"确认/取消"、"通过/拒绝"之类的。

问题是：服务重启后，之前发出的按钮全部失效。用户点了没反应，也不知道为什么。

解决方案是引入状态文件机制：每个待确认的操作不只是发个按钮，同时写一个状态文件。重启后扫描未完成的状态文件，重新发送按钮。

这个问题的本质是：你的系统必须假设自己随时会被重启。 内存里的状态不可信，文件系统才是持久化的唯一来源。

案例三：采集停了两周没人发现

最荒诞的一个。

日度数据采集任务停了。原因可能是配置被误改、依赖服务挂了，或者就是 cron 配置丢了。

它安静地停了两周。没有告警。没有人发现。

因为"负责监控的"和"被监控的"是同一个系统。相当于你让一个人自己汇报自己有没有在工作——他不上班了，自然也不会汇报缺勤。

解决方案：独立的看门狗。 采集任务和监控任务必须解耦。用一个独立的定时任务去检查"采集任务到底有没有跑"。你可以检查采集输出文件的最后修改时间——如果超过 36 小时没更新，立刻报警。

教训： 监控自己的系统不能只靠自己。至少要有一层独立的"谁来监控监控者"机制。

防回退三层防线

修了一个 bug，过两周又出现了。

在传统软件里这叫回退测试。在 AI Agent 系统里更常见，因为 Agent 是无状态的——每次新会话开始，它不记得上次踩过什么坑。

你需要三层防线：

第一层：代码层。 修复逻辑本身。该改的配置改了，该加的校验加了。这是最基础的。

第二层：记忆层。 把踩过的坑写进系统的持久化记忆里。格式类似：

这样哪怕 Agent 的会话重置了，它加载记忆后仍然知道这条规则。

第三层：巡检层。 加一个定时检查。每天自动验证一次"运动记录为空时评分是否合理"。

三层都到位，同一个问题才真的不会回来。

只改代码，Agent 下次忘了。只写记忆，记忆可能被压缩丢失。只加巡检，巡检本身也可能挂。三层冗余，任何一层失效，另外两层兜底。

熔断：知道什么时候该停

自动化最怕的不是不够聪明，是太"勤快"。

以下情况必须立即停止自动迭代，通知人类介入：

单次自动修复超过 3 个文件 — 改多了大概率要出事

连续 3 天触发迭代 — 说明问题是系统性的，不是一个小修能搞定

自动改动导致新的任务失败 — 越修越烂，赶紧停

Token 消耗突然翻倍 — 可能有死循环或幻觉导致的无限重试

熔断的本质是：承认系统不是万能的。 有些问题需要人来判断，自动化能做的是尽早发现并喊停，而不是硬撑着把小问题变成大灾难。

日/周/月三级节奏

迭代不是想到才做，而是系统性地执行：

日度（每天晚上）：跑一次采集，有问题就分析修复，没问题就完全静默。大部分日子是静默的——这才对。如果你的系统每天都在触发迭代，说明根上有问题。

周度（每周末）：回顾一周的趋势。成功率是在涨还是在跌？成本曲线什么走势？有没有反复出现的同类问题？周度分析关注的不是单点故障，而是趋势。

月度（每月初）：架构级审视。哪些定时任务其实可以合并？哪些 Agent 利用率很低可以裁掉？整体成本结构是否合理？月度不是修 bug，是做减法。

可复制性：你也能用

这个框架不依赖特定的技术栈。核心就三件事：

一个采集脚本：纯脚本，零 LLM 消耗，输出 JSON

一套权限规则：L1/L2/L3，在你的配置文件里定义好

一组定时任务：日/周/月三个节奏

如果你用 OpenClaw，可以直接在 cron 里配置这三个节奏的任务。如果你用其他框架，道理一样——把采集和分析分开，把权限分级，把修复和防回退绑定。

具体搭建步骤：

写采集脚本，跑一次确认输出格式

定义你的触发条件（成功率阈值、成本阈值、连续失败次数）

配置日度定时任务，先跑一周观察

加上周度和月度任务

建好变更日志，所有改动可追溯

一周之内就能跑通。

写在最后

AI Agent 系统的终极问题不是"能不能做某件事"，而是"能不能持续稳定地做某件事"。

单次执行靠 prompt 工程。持续稳定靠系统工程。

让你的系统有免疫力，不是让它永远不生病，而是让它生了病能自己发现、自己吃药、知道什么时候该去看医生。

这就是自主迭代框架的全部哲学：不追求完美，追求能修。