鹅厂九人谈：如何让Agent自动持续进化

“落地一个 Agent 容易，但通过一定机制自动持续优化 Agent 却很难。” —— 一位鹅厂员工的灵魂拷问

前几天读到一篇文章，收录了 9 位鹅厂员工关于「Agent 如何自动持续进化」的讨论。说实话，看完之后我在椅子上坐了好一会儿没动——这些观点里有好几个，精准地戳到了我最近在用 AI 工具时一直隐隐感觉到、但没想明白的东西。

我们这个行业现在有一个很尴尬的现状：人人都在搭 Agent，但几乎没人说得清楚怎么让 Agent 越用越聪明。首版能跑，demo 炫酷，老板点头，然后呢？上线三个月，Agent 还在犯同样的错，用户还在重复同样的纠正，每次对话都像第一次上岗的实习生——永远在同一个坑里反复踩。

这篇文章不是简单的转述。我想做的，是把这 9 位的观点展开、补充、串联起来，结合我自己使用 Claude Code 等 AI 工具的体感，尝试回答一个问题：Agent 进化到底是一套什么样的系统？

1. 先别急着优化，先学会量化

第 1 位分享者说了一句话，听起来像废话，但其实是整件事的基石：

“关键的关键是建立自己业务的评估体系：对于你的 Agent 经常执行的任务，该怎么评价 AI 每次执行结果的好坏，有了量化指标之后才能谈优化。”

这话为什么重要？因为我见过太多团队在”优化 Agent”的时候，做的第一件事是——改 prompt。改了一版觉得好像好了，又改一版觉得好像又不行了，来回折腾三天，最后发现根本不知道到底是变好了还是变差了。

这跟写代码一个道理。你不会在没有测试的情况下重构一个核心模块对吧？TDD 的核心思想是”先写测试再写代码”，Agent 优化也是一样——先建评估体系，再谈优化策略。

具体量化什么？我觉得至少要覆盖这四个维度：

指标	含义	为什么重要
任务完成率	Agent 在无人干预的情况下成功完成任务的比例	最基本的能力衡量
Token 效率	完成同一任务消耗的 token 数	越少说明上下文管理越好
人工干预频率	用户需要纠正、补充、重试的次数	直接反映 Agent 的可靠性
错误恢复率	Agent 犯错后自主修复的比例	衡量”越用越聪明”的核心指标

没有这些数字，所谓的”优化”就是盲人摸象。你甚至不知道自己在改善什么。

2. 临时工和正式工：两种记忆策略

同一位紧接着说了一句更有意思的话：

“如果你对 AI 的定位是临时工，每次都是一锤子买卖，比如 Coding Assistant，Skill 和 Rule 比较合适；如果 AI 的定位是长工，需要它自身有成长，则还需要依赖记忆模块。”

这个”临时工 vs 正式工”的比喻太形象了。

临时工模式就是每次干完活就走，下次来还是从零开始。你靠的是给他一份详细的操作手册（Skills/Rules），让他照着做就行。Claude Code 的 CLAUDE.md 就是典型的”操作手册”——在上一篇文章里我们详细聊过它的用法。每次 Claude 犯一个错，你就加一条规则。久而久之，这份手册越来越完善，Agent 的表现也越来越好。但本质上，这不是 Agent 自己变聪明了，而是你给它的说明书写得更好了。

正式工模式就完全不一样了。你需要 Agent 记住上周犯过的错、上个月学到的经验、这个项目的特殊偏好。这就需要记忆模块——短期记忆处理当前任务的上下文，长期记忆沉淀跨会话的知识。

记忆策略的选择取决于你的业务场景：

高频重复任务（代码审查、测试生成）→ Skills/Rules 足矣，写好手册就行
长期陪伴场景（个人助理、项目管理）→ 需要记忆模块，Agent 要能成长
混合场景（大多数实际情况）→ 两者结合，手册兜底 + 记忆增强

我个人的感觉是，大多数人目前还停留在”临时工”阶段，CLAUDE.md 写得再好也只是一份更好的说明书。真正的突破点在于——让 Agent 像正式工一样，自己积累经验。

3. 失败比成功更值钱

第 2、3、5 位从不同角度说了同一件事，合并起来就是一个极其深刻的洞察：

“好数据并不是全部都正确的数据，恰恰是那些有问题但包含了纠正的数据。”

这话听着反直觉对吧？我们通常觉得，训练 AI 当然要用高质量的、正确的数据。但仔细想想——人类自己是怎么学习的？

你还记得高考备考的时候吗？考完试之后，老师会让你做一件事：整理错题本。不是让你把做对的题再做一遍，而是把做错的题反复看、反复练。为什么？因为错题里包含了你的知识盲区，而知识盲区正是提升空间最大的地方。

Agent 也是一样。一个 Agent 顺利完成了一百个任务，这一百条记录有价值吗？有，但有限。它说明 Agent 在这类任务上已经足够好了。真正珍贵的是那些“翻车 + 纠正”的数据——Agent 犯了什么错、用户怎么纠正的、最终正确的做法是什么。这些才是驱动进化的燃料。

这就是所谓的数据飞轮：

1
2
3

Agent 执行任务 → 犯错 → 用户纠正 → 记录"错误 + 纠正"数据对
    → 反馈给 Agent/模型 → Agent 下次遇到类似问题时避开坑
    → 犯新的错 → 继续循环

第 2 位说得很实在：”不然每次都像第一次上岗，永远在同一个坑里反复踩。”这句话应该贴在每一个搞 Agent 的人的工位上。

但这里有一个残酷的现实，第 3 位也提到了——很多 Agent 在数据飞轮转起来之前就被推翻了。因为用户使用频率低、容忍度有限，Agent 还没攒够足够的纠正数据就被宣判死刑了。这是一个先有鸡还是先有蛋的问题：Agent 需要犯错才能进步，但用户不给它犯错的机会。

4. 人在回路：安全员的智慧

第 3 位和第 6 位都提到了 Human-in-the-Loop（人在回路），但第 3 位用了一个绝佳的类比——自动驾驶安全员。

“在我们使用 Claude Code 过程中，Human-in-Loop 环节每次选择/ESC 取消/补充问题修正等过程，相当于人类在帮助 Agent 进行数据纠正（和自动驾驶安全员类似）。”

你想想自动驾驶安全员是怎么工作的？他坐在驾驶座上，大部分时间不动方向盘，让自动驾驶系统自己开。但他的眼睛一刻都没离开路面。当系统要做一个危险决策的时候，他会介入——接管方向盘、踩刹车、修正路线。而这每一次介入，都会被记录下来，成为训练自动驾驶系统的宝贵数据。

我们用 Claude Code 的时候，其实就是这个角色。想想你日常的操作：

显性反馈：点击确认（✓）或取消（ESC）—— 相当于安全员说”这步没问题”或”停，不对”
隐性反馈：看了 Agent 的建议但自己手动改了 —— 相当于安全员默默接管了方向盘
纠正数据：取消之后补充新的指令 —— 相当于安全员接管后手动把车开到正确位置

这三种信号的价值是递增的。显性反馈告诉 Agent 对不对，隐性反馈暗示了哪里不够好，纠正数据直接示范了正确做法。

这里有一个美妙的悖论：你干预得越多，未来需要干预的就越少。每一次纠正都在训练 Agent，每一次”安全员接管”都在让自动驾驶系统更可靠。前提是——这些干预数据被记录下来并反馈到系统中。如果你的 Agent 没有这个反馈机制，你就是白白当了一个永远不被倾听的安全员。

5. 冻结的大脑 vs 流动的上下文

第 5 位用了一个特别精准的数学类比，把 LLM 的知识来源说清楚了：

“模型矩阵和上下文向量，粗暴地说最后是要乘到一块去的。但模型是被冻结的部分，上下文是不断改变的部分。”

翻译成人话就是：大模型有两个大脑——一个是固定的（参数），一个是临时的（上下文）。你跟 ChatGPT 聊天时塞进去的所有内容，就是那个”临时大脑”。而模型本身那几十亿上百亿的参数，是”固定大脑”——一旦训练完就冻结了。

这就意味着，Agent 想要持续进化，只有两条路：

路径一：解冻固定大脑（模型可塑性）

让模型本身能够持续学习。这是 Online Learning / Continual Learning 领域的方向，技术门槛极高，目前只有大厂和顶级实验室在探索。普通开发者别想了。

路径二：巧用临时大脑（上下文工程）

既然模型参数改不了，那就把上下文做到极致。通过更好的 prompt 设计、更聪明的记忆管理、更精准的信息检索，让每次对话时塞给模型的”临时知识”更有效。

第 5 位说：”第一条留给训模高手来做。第二条是当下的最热方向，创新空间巨大。”

我完全同意。对于绝大多数人来说，上下文工程才是正道。你不需要训练一个新模型，你需要的是——在有限的上下文窗口里，塞进最有价值的信息。这包括：

任务相关的历史记录（Agent 之前在类似任务上犯过什么错）
用户偏好和习惯（你喜欢什么风格的代码、什么程度的解释）
领域知识的精准片段（不是整本文档，而是此刻最相关的那几段）

上下文窗口就像一个容量有限的工作台，你不可能把整个仓库都搬上来。聪明的做法是——只放此刻真正需要的工具和材料。

6. 让 Agent 学会反思

第 4 位只说了六个字：”强化学习了解一下！” 但第 6 位把这个方向展开到了一个让我非常兴奋的层面——元认知。

“结合元认知和本体论思想来设计 Agent：一方面依托本体知识库赋予 Agent 理解世界的能力，另一方面依托元认知赋予 Agent 对思考本身进行思考和进化的能力。”

元认知这个词听起来很学术对吧？但其实概念很简单——思考自己的思考。

人类之所以能持续进步，不只是因为我们会做事，更因为我们会反思。你写完一段代码之后会回头看看：”这段写得好不好？有没有更好的写法？我是不是又犯了上次那个错？”这种自我审视的能力，就是元认知。

强化学习提供了一种机制，让 Agent 通过”奖励”和”惩罚”来调整行为。但如果只有强化学习，Agent 学到的是”什么行为能获得奖励”，而不是”为什么这个行为好”。加上元认知，Agent 就不只是在试错，它还在理解自己为什么错了。

想象一个理想的 Agent 反思流程：

1. 执行任务 → 得到结果
2. 自我评估："这个结果好不好？哪里不够好？"
3. 归因分析："问题出在哪一步？是理解错了用户意图，还是选错了工具？"
4. 策略调整："下次遇到类似情况，我应该先确认意图再动手"
5. 记忆沉淀：把这条经验存下来

这不就是一个有自我意识的学习者吗？说实话，每次想到这里我都会有一种奇妙的感觉——我们在讨论的，到底是软件工程，还是认知科学？

7. 用 AI 优化 AI：自动进化的 System Prompt

第 7 位提供了一个非常落地的方案——用 AI 模型来逐步优化 system_message。

这个思路特别务实。我们都知道 system prompt 对 Agent 行为的影响有多大——一个好的 system prompt 和一个随便写的 system prompt，出来的效果可能天差地别。但问题是，怎么知道你的 system prompt 是好是坏？怎么系统性地改进它？

第 7 位的回答很直接：让 AI 自己来做这件事。

这里他还提到了一个重要的细节：XML 格式的结构化规则 >> 随手写的字符串。

<!-- 好的 system prompt -->
<rules>
  <rule name="error_handling" priority="high">
    当遇到页面加载超时时，先截图记录当前状态，
    然后等待 3 秒重试，最多重试 2 次。
  </rule>
  <rule name="form_filling" priority="medium">
    填写表单前先检查所有必填字段是否已定位到，
    未定位到的字段用日志标注并跳过。
  </rule>
</rules>

<!-- 不好的 system prompt -->
"你是一个浏览器自动化助手，帮我填写网页表单，遇到错误要重试。"

结构化的好处在于：模型能更清晰地理解每条规则的边界、优先级和适用条件。随手写的字符串呢？模型只能靠猜。

把这些串联起来，一个完整的 system prompt 自动优化闭环长这样：

运行 Agent → 收集执行数据和错误日志
    → 度量关键指标（完成率、错误率等）
    → 把数据喂给另一个 AI，让它分析问题并提议修改 system prompt
    → A/B 测试新旧 prompt
    → 择优上线 → 继续循环

这不就是”用 AI 优化 AI”吗？而且这个流程里，人类甚至不需要亲自动手改 prompt——只需要审核 AI 提出的修改建议是否合理。

8. 测试驱动的 Agent 进化

第 8 位的观点是整篇讨论中最系统化的，他直接描绘了一套多 Agent 测试流水线：

“设想：在每一次测评中，引入另外一个 multi-agent，用于 AI 产品的测试。Spec Agent 评测最终结果的质量与正确性。若它认为某个测试用例不通过，那么将自主分析错误原因、分派任务给 Coding SubAgent。后续则由 SubAgent 重新复盘、优化系统提示词，并提交 PR 给人类 review。”

翻译一下这个流水线：

Spec Agent（裁判）    →  评测 Agent 的输出是否达标
    ↓ 不达标
错误归因 Agent        →  分析哪里出了问题、置信度多高
    ↓ 高置信度
Coding SubAgent      →  修改 prompt / 代码 / 配置
    ↓
提交 PR              →  人类 Review
    ↓ 通过
合并上线              →  进入下一轮评测

这个设计有几个特别聪明的地方：

用 Agent 测试 Agent：LLM-as-Judge 不是新概念了，但把它系统化地嵌入迭代流程里，这是关键一步
置信度阈值：不是所有错误都触发自动修复，只有高置信度的归因才进入修复流程——避免误判导致越改越差
人类是守门员，不是执行者：人类不再需要手动分析错误、手动改 prompt。人类只需要 review PR，决定合不合并

第 8 位最后说了一句让我很有感触的话：”AI 时代所谓的测试驱动开发的最佳范式，人类大概率会彻底从执行者变为守门员和裁判了。”

这不是遥远的未来。现在用 Claude Code 的时候，我已经越来越多地在做”守门员”的工作——不是我在写代码，而是 Agent 在写，我在 review。不是我在调试，而是 Agent 在调试，我在判断它调得对不对。

写在最后

把 9 位的观点串联起来看，会发现 Agent 进化不是某一个单点技巧，而是一套完整的系统。如果要用一张图来概括：

┌──────────────┐
│   评估体系    │  ← 量化，才能谈优化
└──────┬───────┘
       ↓
┌──────────────┐
│   反馈闭环    │  ← 错误 + 纠正 = 进化燃料
└──────┬───────┘
       ↓
┌──────────────┐
│   记忆系统    │  ← 临时工 or 正式工
└──────┬───────┘
       ↓
┌──────────────┐
│   自我反思    │  ← 思考自己的思考
└──────┬───────┘
       ↓
┌──────────────┐
│   自动迭代    │  ← 用 AI 优化 AI
└──────────────┘