AI Agent 自我改进怎么做？先看这 5 个条件

如果你已经开始用 Agent 写稿、修代码、整理资料，真正让人卡住的地方常常很具体：你明明纠正过它，它下次还会犯同一个错。

上周写公众号稿，开头又绕去讲行业背景。你改过一次，让它别这么写。下周换个选题，它又来了。

第一次让 coding agent 处理中文路径时，它找错文件。你提醒它先核真实文件名。隔几天再来一次，它还是直接猜路径。

这时你会觉得它很勤快，也很健忘。

很多人讲"自改进 Agent"，听起来像另一种东西：Agent 自己发现问题，自己修复自己，越跑越聪明。这个方向确实在变得越来越具体，但最现实的问题其实很朴素：

一个 Agent 到底靠什么知道自己变好了？

如果没有答案，它多跑十轮也只是多试十次。真正接近自改进的系统，至少要有五件事：可验证任务、结构化反馈、持久化记忆、外环复盘、人工审核。

这五件事凑不齐，自改进很容易变成随机漂移。

多试几次，不等于会成长

先把概念压清楚。

一个模型一次生成多个答案，再选一个看起来最好的，这不算自改进。它只是采样更多，不是学习更多。

一个 Agent 当前轮失败后，让自己反思一下，再重试一次，这比单次回答强。但如果反思没有留下来，下一次新会话还是会从头开始。

更接近自改进的情况，是 Agent 的行为模式真的被过去经验改变了。

可以分三层看。

第一层，同一个任务做得更好。

比如它写摘要，第一次超字数，第二次根据检查结果压缩到要求内。这个改进只发生在当前任务里。

第二层，从错误中学习。

比如它连续几次因为"没有引用来源"失败，于是后续任务开始默认检查来源字段。这已经开始把失败转成规则。

第三层，改变下一次行为。

比如它在任务开始前自动读取反馈日志、Skill、项目规则和已知坑位。下一次遇到相似任务，它会先避开旧错误。

金句：真正的自改进，不是 Agent 更努力，而是它记住了上次为什么失败。

这一层才是普通人现在最值得关注的"自改进"。

它不神秘。它更像一个会看错题本的学生。

第一个条件：结果必须可验证

自改进最适合从代码、分类、问答、数据抽取这类任务开始。

原因很简单：这些任务能验收。

代码有没有通过测试。分类是否命中标准。问答是否给出正确数字。数据抽取有没有漏字段。

Yohei Nakajima 在一篇综述式文章里，把自改进 Agent 的研究路径拆成六类：自反思、自生成数据、自适应模型、自改代码、具身学习，以及验证和安全控制。简单理解：前四类是"怎么让 Agent 变强"，后两类是"怎么知道它真的变强了、而不是跑偏了"。

对个人开发者和内容创作者来说，最适合先上手的是反思、反馈和持久化记录。训练模型和修改 Agent 底层代码都可以放到更后面。

反思本身不够。反思需要被验证。

比如你让 Agent 写一段视频脚本，它说"这次更有网感"。这句话没法进入反馈系统。

换成更具体的检查：

• 前 3 秒有没有给冲突。
• 是否只讲一个判断。
• 是否有一个例子。
• 是否有明确 CTA。
• 是否出现账号禁用句式。

这些检查能过或不过。过了，就保留；没过，就记录失败类型。

MindStudio 的工程文章也强调这一点：自改进循环至少需要任务、评估 harness、诊断反馈和持久学习存储。它还特别提到，二元检查比主观打分更适合做反馈。

这就是为什么"7 分"不如"没有来源链接"有用。

分数只能告诉你不够好。失败项才能告诉你下次改哪里。

第二个条件：失败要有地方留下来

Addy Osmani 写过一篇《Self-Improving Coding Agents》，里面讲到连续编码循环，也就是常被称为 Ralph Wiggum 的技术。

核心做法并不复杂：把开发拆成小任务，Agent 每轮只处理一个任务，写代码，跑测试，通过后提交，更新任务状态，然后清空上下文进入下一轮。

这里有一个关键设计：每轮上下文会重置。

重置能降低混乱。长对话越拖越长，Agent 容易被前面的尝试污染，也容易忘掉当前任务真正要做什么。你可以把它理解为：每轮对话结束后清空聊天记录，只保留关键笔记。

但重置也带来一个问题：经验怎么留下来？

更稳的办法，是把重要经验写进文件，不让同一个会话无限变长。

Addy 文中提到 AGENTS.md 这类持久上下文文件。它可以记录项目约定、踩坑、最近学习到的模式。下一轮 Agent 不必记住所有聊天，只要读取这些经过筛选的规则。

内容生产也一样。

你不需要让 Agent 记住每次改稿的完整聊天。你需要让它记住这些可执行规则：

• 开头先写具体场景，不要先讲大趋势。
• 涉及 2026 年模型、工具、公司计划，起稿前必须重新核验。
• 小红书图文每页只讲一个判断。
• 视频脚本前 3 秒必须给冲突。
• 没有反方证据时，不写成确定结论。

这些规则才会改变下一次行为。

聊天记录是原料。反馈日志和 Skill 才是资产。

第三个条件：要有外环复盘

普通 Loop 负责执行。

自改进需要再加一层外环。

内环做事：读文件、查资料、写稿、跑测试、输出结果。

外环复盘：读取过去的任务记录，找重复失败，判断哪些经验值得写入 Skill、模板或检查清单。

这两层不要混在一起。

如果让执行中的 Agent 顺手决定自己该怎么永久升级，它很容易把临时判断写成长期规则。

比如某篇文章为了小红书传播，需要标题更短、更直白。这是平台适配，不该变成"所有文章都要短标题"。

再比如某次代码任务为了排障临时打开 debug 日志。这是任务需要，不该变成"以后默认输出详细日志"。

外环的价值，是把"这次为什么这样做"放到更冷静的位置上重新判断。

金句：内环求快，外环求稳。混在一起，要么快不起来，要么稳不了。

我更倾向于让外环每天或每周跑一次，不要每次失败马上改 Skill。

它只处理三类东西：

• 重复出现的失败。
• 人工纠偏多次出现的规则。
• 明确能降低下次成本的模板。

其他内容先留在反馈日志里观察。

第四个条件：Skill 更新必须可审、可回滚

这里展开讲一个案例：EvoSkill。

它的论文和开源仓库都把方向说得很清楚：从失败轨迹里自动发现、生成和改进可复用 Skill。

核心机制是这样的：Agent 执行任务时，如果失败了，系统会分析失败轨迹，提取出可复用的操作片段，封装成 Skill。下一次遇到相似任务，Agent 会先检索已有 Skill 库，看有没有能直接用的。如果有，就用；如果没有，就自己尝试，失败后再沉淀新 Skill。

论文里给了几个结果：OfficeQA exact-match 从 60.6% 到 67.9%，SealQA 从 26.6% 到 38.7%，还有一个跨任务迁移例子，SealQA 上进化出的 Skill 迁移到 BrowseComp 后提升 5.3%。

简单理解这些数字：原本 10 道题对 6 道，现在能对 7 道。提升不算巨大，但方向是对的——失败轨迹确实可能变成可复用能力。

但它也提醒我们另一件事：自改进不能只靠"感觉更好了"。

EvoSkill 的思路里有验证集、有选择机制、有版本化的 Skill。每次变化都需要和任务表现挂钩。如果新 Skill 在验证集上表现更差，就会被丢弃，不会进入 Skill 库。

另一个可以放在旁边看的例子，是 Karpathy 的 autoresearch。

它的思路更像自动实验研究：给 Agent 一个小型但真实的 LLM 训练环境，让它修改代码，训练 5 分钟，检查验证指标有没有变好，再决定保留或丢弃这次改动，然后继续下一轮实验。

这和 EvoSkill 的侧重点不同。EvoSkill 更像把失败轨迹提炼成可复用 Skill；autoresearch 更像把研究实验拆成可比较、可回滚的小步循环。

但它们共同指向同一个判断：自改进不能只靠模型"自己想明白"。它需要实验记录、评价指标、选择机制和回滚能力。

个人使用时，不一定马上接入这种工具。但可以先学它的资产形态：

• 失败要有轨迹。
• 规则要能独立成文件。
• 更新要能 diff。
• 合并前要有人审。
• 出问题要能回滚。

Skill 是很好的载体，因为它本来就是文件。

文件能被版本控制，能被比较，能被回滚，也能被团队复用。

这比"让 Agent 记住我说过的话"稳得多。

第五个条件：人必须保留审核权

这里要放一盆冷水。

Reddit LLMDevs 上有一个反方帖子，标题很直接：自改进 AI Agent 短期内不会发生。

帖主的核心经历是：他们试过给 Agent 更多自主权，效果反而变差。真正有效的系统，往往是控制更紧、QA 更明确、监控更充分的系统。

评论区也有一个值得记住的判断：自改进可以发生在有客观度量或人在回路的场景里。

这句话很朴素，也很重要。

当前阶段，人的位置不能省。

人不应该一直盯着 Agent 写每一步。那样只是把自己变成监工。

人更应该站在三件事上。

第一，设边界。

哪些任务能自动做，哪些必须停下来。比如发布、删除、支付、生产配置、隐私信息、价值判断，都不该自动放行。

第二，审规则。

Agent 可以提出 Skill 更新建议，但合不合并，由人决定。

第三，定方向。

Agent 可以优化流程，不能替你决定长期目标。

金句：AI 的执行力越强，人越要把判断权上移。

这也是 Human3.0 视角里最关键的地方。

普通人第一步：给 Agent 建一个错题本

如果你想今天就开始做自改进 Agent，不要先搞复杂平台。

先建一个 Markdown 文件。

名字可以叫：

agent-feedback-log.md

每次 Agent 任务失败，只记录六件事：

任务目标：
预期结果：
实际结果：
验证证据：
失败类型：
下一次规则：

比如：

任务目标：把公众号长文拆成小红书图文。
预期结果：8 页卡片，每页一个判断，有标题、正文、视觉建议。
实际结果：直接压缩长文，页面之间没有独立价值。
验证证据：第 03-06 页都在重复同一个判断。
失败类型：平台适配不足。
下一次规则：小红书图文必须先提炼传播点，再拆页；每页只讲一个核心判断。

这个文件积累一周后，再让 Agent 做一次复盘：

请读取本周反馈日志，只做三件事：
1. 找出重复出现的失败模式。
2. 判断哪些失败值得更新为 Skill、模板或检查清单。
3. 为每个候选更新生成简短 diff 建议，说明证据、收益、风险和回滚方式。

不要自动修改文件。

这就是最小外环。

它不酷，但能跑。

真正的自改进，可以从一个很小的动作开始：让失败变成下一次能用的规则。

写在最后

这篇文章讲了自改进 Agent 的 5 个条件：可验证任务、结构化反馈、持久化记忆、外环复盘、人工审核。

如果你现在用 Agent 还在重复犯同样的错，先别急着换模型或加功能。回头看看这 5 件事，哪件还没做到。

你现在用 Agent 最常遇到的重复错误是什么？ 评论区留言，我整理成错题本模板，下一篇会用。

如果你觉得 5 个条件的检查清单有用，可以收藏这篇文章，下次检查自己的 Agent 工作流时对照使用。

下一篇我会继续拆：从 Loop 到进化，一个会执行任务的 Agent，到底要多出哪一层，才算开始成长。

资料来源

1. Yohei Nakajima, Better Ways to Build Self-Improving AI Agents：https://yoheinakajima.com/better-ways-to-build-self-improving-ai-agents/
2. Addy Osmani, Self-Improving Coding Agents：https://addyosmani.com/blog/self-improving-agents/
3. EvoSkill arXiv：https://arxiv.org/abs/2603.02766
4. EvoSkill GitHub：https://github.com/sentient-agi/EvoSkill
5. Karpathy/autoresearch：https://github.com/karpathy/autoresearch
6. MindStudio, How to Build a Self-Improving AI Agent That Learns From Its Own Mistakes：https://www.mindstudio.ai/blog/self-improving-ai-agent-feedback-loop
7. Reddit LLMDevs 讨论：https://www.reddit.com/r/LLMDevs/comments/1nw3y3c/selfimproving_ai_agents_arent_happening_anytime/