Agent 自进化：从评测、记忆到 Skill 更新，工程闭环怎么搭

摘要

AI Agent 开始进入真实业务以后，一个越来越现实的问题出现了：

Agent 跑了几个月之后，真的会比刚上线时更会做事吗？

如果同一种错误反复出现，历史经验没有沉淀，Prompt 和 Skill 修改后也缺少稳定的回归验证，那么 Agent 即使接了再多工具、工作流再复杂，也很难形成真正的持续改进能力。

Agent 自进化真正要解决的，不是“让模型自己变聪明”，而是建立一套完整的工程闭环：

评测发现问题 → 记忆沉淀经验 → Skill / Prompt 更新 → 回归验证 → 灰度发布 → 线上反馈再次进入评测。

对软件测试开发从业者来说，这套体系里包含大量熟悉的工程能力：Agent 评测、自动化测试、Trace 评测、回归测试、版本管理、灰度发布和质量门禁。

---

Agent 自进化，为什么开始成为工程问题

现在很多 Agent 项目已经不再停留在 Demo 阶段。

一个典型的 Agent 往往已经具备：

• 大模型
• Prompt
• Skill
• Memory
• Tool
• MCP
• Workflow
• RAG

但这些能力组合起来，并不等于 Agent 就具备“自进化能力”。

判断一个 Agent 有没有真正进入持续改进阶段，可以先问一个很简单的问题：

它上个月犯过的错误，这个月还会不会继续犯？

如果答案是“会”，说明系统虽然完成了任务，却没有把执行过程中的经验真正留下来。

Agent 自进化要做的，就是让每一次任务执行都能产生反馈，并把有效反馈转化为下一轮能力。

---

一、Agent 自进化，到底在“进化”什么

讨论 Agent 自进化之前，首先要区分三个层次。

层级	修改对象	是否长期生效
Artifacts	答案、代码、方案等当前输出	否
Harness	Prompt、Skill、Memory、Tool、Workflow	是
Model	模型参数	是

Artifacts：只把当前任务做得更好

比如：

第一次代码生成失败，Agent 自己检查后再生成一次。

第二次结果可能更好。

但任务结束以后，这次经验没有进入系统。

下次遇到同类问题，Agent 仍然可能重新犯错。

这类方式更接近 Self-Refine，而不是严格意义上的持续进化。

Harness：让经验跨任务复用

Harness 可以理解成 Agent 外围的运行系统，包括：

• Prompt
• Skill
• Memory
• Tool 配置
• Workflow

比如 Agent 多次在日期格式转换上出错。

评测发现问题后，可以沉淀一条 Skill：

日期转换前先识别源格式，再选择对应转换方法，并在输出后进行格式校验。

这条 Skill 保存以后，后续任务都可以复用。

这也是当前很多 Agent 工程里最值得投入的一层。

Model：直接改变模型能力

再往上一层，就是通过微调、强化学习等方式直接调整模型参数。

这种方式持久性更强，但成本、风险和验证复杂度也更高。

因此对大多数业务团队来说，更现实的路径通常是：

先做好 Harness 层，再考虑模型层面的进化。

---

二、Agent 评测不是打分，而是整个自进化系统的信号源

Agent 想持续改进，第一件事不是“自动改 Prompt”。

而是先回答：

你怎么知道它哪里有问题？

这就是 Agent 评测。

在普通项目里，评测往往只是上线前验证一次。

但在 Agent 自进化系统里，评测至少承担三个作用。

1. 发现问题

Agent 到底哪里表现不好？

可能是：

• 最终答案错误
• Skill 选择错误
• Tool 调用错误
• 参数传递错误
• 执行路径冗余
• Token 消耗过高

2. 判断修改是否有效

修改了一条 Skill 或 Prompt 之后，不能只看原来的问题有没有解决。

还要验证：

原来正常的场景有没有被改坏。

这其实就是测试工程里非常熟悉的：

Regression Testing，回归测试。

3. 判断哪些经验值得保留

一次任务成功，也不意味着整个执行过程都有价值。

只有经过验证的有效经验，才值得进入长期记忆或者升级为 Skill。

所以在 Agent 自进化体系里：

评测不是终点，而是所有后续改进的输入。

---

三、Agent 测试为什么不能只看最终答案

这是 Agent 测试和传统大模型评测之间一个非常重要的区别。

一次 Agent 任务通常包含：

用户输入
↓
任务理解
↓
任务规划
↓
Skill 选择
↓
Tool 调用
↓
中间结果
↓
最终答案

如果只看最终答案，就可能出现一种很危险的情况：

答案是对的，但执行路径是错的。

比如一个 Skill 要求 Agent：

① 查询接口 A
② 校验接口返回格式
③ 调用接口 B
④ 返回最终结果

实际执行时，Agent 跳过了第二步。

这一次数据刚好正常，所以最终答案仍然正确。

如果测试只判断最终结果：

PASS。

但下一次接口格式异常时，这个问题就会暴露出来。

因此 Agent 测试需要逐渐从：

Output Evaluation

扩展到：

Trace Evaluation。

甚至进一步验证：

Path Evaluation。

也就是同时回答三个问题：

• 最终结果对不对？
• Agent 实际执行了什么？
• 执行路径是否符合预期？

这也是 Agent 测试和传统接口自动化、UI 自动化之间最大的变化之一。

---

四、Agent 评测体系，可以借鉴测试金字塔

很多 Agent 项目现在有一个倾向：

什么都交给 LLM Judge。

实际上并不必要。

大量测试指标本身就是确定性的。

例如：

• JSON Schema 是否正确
• SQL 查询结果是否匹配
• HTTP 状态码是否正确
• UI 元素是否出现
• 测试用例是否通过
• 响应时间是否达标

这些问题完全可以直接使用规则、断言和自动化测试。

一套更合理的 Agent 评测体系，可以分成三层。

第一层：规则和自动化测试

适合确定性问题。

特点：

便宜、稳定、可重复。

这是整个评测体系的底座。

第二层：LLM-as-Judge

适合：

• 语义判断
• 开放式回答
• 规划质量
• 内容完整性
• 表达质量

但 LLM Judge 也不能完全默认可信。

最好做到：

• 生成模型和评测模型分离
• 评测输出结构化
• 不同维度分别判断
• 保持评测条件稳定

第三层：人工抽样

人工主要负责：

• 校准 LLM Judge
• 审核高风险结果
• 判断复杂开放任务
• 发现评测体系本身的问题

因此 Agent 评测也可以理解成一种新的测试金字塔：

底层规则大量覆盖，中层模型补充语义，顶层人工负责校准。

---

五、Agent Memory 的重点，不是向量数据库

长期记忆是 Agent 自进化的第二个重要环节。

但“Agent 有记忆”并不等于：

把所有历史对话塞进向量数据库。

真正困难的问题反而是：

• 什么值得记？
• 什么应该忘？
• 信息过期怎么办？
• 两条记忆冲突怎么办？
• 错误记忆怎么发现？
• 检索出来的内容真的相关吗？

如果没有这些治理能力，很容易出现：

记忆越来越多
↓
检索噪声越来越大
↓
上下文越来越长
↓
Agent注意力被干扰
↓
最终效果下降

所以从工程角度看：

Agent Memory 首先是治理系统，其次才是存储系统。

---

六、Agent 记忆可以分成 Episodes、Facts 和 Skills

为了更容易理解，可以把 Agent Memory 简化成三个层次。

Episodes：经历过什么

例如：

• 某次接口失败
• 某次工具调用异常
• 某次排查过程
• 一段历史执行轨迹

这类信息最详细，但同时噪声也最多。

Facts：已经确认的事实

例如：

• 测试环境 A 需要额外 Header
• 某接口默认超时时间为 30 秒
• 项目统一使用 UTC 时间
• 某业务字段不能直接为空

Facts 比原始对话更加稳定。

Skills：以后应该怎么做

Skill 是进一步抽象后的可复用方法。

例如：

遇到接口鉴权失败：

1. 检查 Token 有效期
2. 检查 Header
3. 检查环境配置
4. 重试鉴权接口
5. 记录最终失败原因

从 Episodes 到 Facts，再到 Skills，本质上是：

从经历 → 知识 → 能力。

---

七、Skill 写出来以后，怎么证明它真的有用

这是测试开发非常值得关注的问题。

一条 Skill 被加入系统以后，任务成功了。

能不能直接说明：

Skill 有效？

不能。

因为有可能：

模型本来就会。

所以 Skill 评测至少需要四层验证。

1. 对照实验

同一批 Case：

• 一组加载 Skill
• 一组不加载 Skill

然后比较成功率、Token、延迟和错误情况。

这样才能判断：

Skill 到底带来了多少增量。

2. 难度校准

如果 Case 太简单：

无 Skill：100%
有 Skill：100%

根本看不出 Skill 的价值。

所以测试集需要有一定难度梯度。

3. Trace 验证

即便结果正确，也要继续检查：

Agent 运行时真的调用这条 Skill 了吗？

4. Path 验证

更进一步还要检查：

Agent 是否真正按照 Skill 定义的关键路径执行。

因此 Skill 测试不能只看结果。

它其实已经非常接近一种新的：

Agent 白盒测试。

---

八、Agent 自进化真正落地，需要一条 CI/CD 流水线

评测发现问题之后，并不应该直接让 Agent 修改配置并上线。

比较完整的链路应该是：

线上失败 Case
↓
评测
↓
诊断归因
↓
生成修复候选
↓
独立评测
↓
回归测试
↓
安全门控
↓
人工审核
↓
灰度发布
↓
线上监控
↓
新失败 Case 回流

仔细看，这和软件工程里的 CI/CD 非常像。

过去 CI/CD 管的是代码。

Agent 时代还需要开始管理：

• Prompt
• Skill
• Memory
• Tool 配置
• Workflow

因此可以把它理解成：

Agent CI/CD。

---

九、Agent CI/CD 里，有五个特别重要的工程点

1. 先做失败归因

评测只告诉你失败了，还不够。

必须继续确认问题到底来自：

• Prompt
• Skill
• Tool
• API
• 数据
• 环境

如果工具本身有 Bug，却一直修改 Prompt，很可能出现大量无效迭代。

2. 修改不要只看单次失败

修复方向最好同时结合：

• 本轮诊断
• 历史 Playbook
• 外部知识

避免系统反复尝试已经失败过的方法。

3. 修改尽量使用 Diff

让 LLM 重写整个 Skill 文件，风险很高。

更好的方式是：

只修改需要调整的部分。

这样更容易 Review、回滚和定位问题。

4. 所有变更都应该版本化

每一次 Prompt、Skill、Memory 更新，最好都能追踪：

• 为什么改
• 改了什么
• 哪个 Case 触发
• 用什么数据验证
• 上一版本是什么

出了问题以后才能快速回滚。

5. 通过测试不等于直接全量

候选修改通过离线测试以后，还应该：

灰度发布。

观察成功率、Token、延迟和线上反馈，再决定是否扩大范围。

---

十、Dreaming：解决单次评测看不到的问题

普通评测通常围绕一次任务展开。

但有些问题只有把大量历史任务放在一起，才能看出来。

例如：

100 次任务中，有 30 次都在日期处理上走了弯路。

单独看每一次，可能都只是小问题。

放在一起以后，却是明显的系统性短板。

这类问题可以通过异步 Dreaming 机制处理。

它可以定期回顾一批历史轨迹，寻找：

• 重复失败模式
• 重复低效路径
• 高频知识缺口
• 值得升级为 Skill 的经验

因此：

同步评测解决的是：

这一次哪里错了。

Dreaming解决的是：

最近一段时间，系统反复在哪类地方表现不好。

两者不是替代关系，而是互补关系。

---

十一、为什么 Agent 自进化不能简单理解成“全自动”

让 Agent：

发现问题 → 修改自己 → 自动上线

看起来效率最高，但工程风险也最大。

因为 Prompt、Skill 和 Memory 都可能影响大量后续任务。

所以更合理的方法不是“全自动”，而是：

分级自主 + 渐进放权。

可以简单设计成四个等级：

等级	运行方式
Level 0	Agent 建议，人执行
Level 1	Agent 执行，人审批
Level 2	Agent 执行，人抽检
Level 3	稳定场景下自主运行

系统长期稳定以后，可以逐步提高自主等级。

但出现严重回归时，应当自动降级。

---

十二、有些关键节点，必须保留人工控制

即使自动化程度越来越高，有几个位置仍然不适合完全交给 Agent。

规则级记忆写入

普通历史记录影响有限。

但“以后遇到这种情况必须怎么做”这种规则，会影响大量任务。

写错以后，污染范围非常大。

Prompt / Skill 关键更新

特别是涉及：

• 权限
• 安全约束
• 拒答逻辑
• 业务边界

不能简单自动通过。

回归发生后的决策

出现回归以后：

• 回滚到哪个版本
• 是否冻结后续修改
• 影响哪些业务

都需要业务上下文。

新领域冷启动

没有历史数据的新业务，需要人工提供：

• 第一批 Case
• 初始 Skill
• 安全边界

系统权限边界

Agent 能改什么、不能改什么，本身应该提前定义清楚。

---

十三、测试团队怎么开始做 Agent 自进化

不建议一开始就搭一个非常复杂的“自进化平台”。

更现实的做法，是先跑通最小闭环。

Phase 1：先把评测做起来

准备一批真实 Case，例如：

• 正常场景
• 异常场景
• 边界场景
• Tool 失败
• 参数错误
• 复杂组合任务

先验证：

你能不能稳定发现问题。

Phase 2：开始沉淀 Skill

每次解决问题以后，继续问一句：

这个问题以后还会不会再出现？

如果会，就考虑是否值得沉淀成：

• Fact
• Memory
• Skill

Phase 3：给 Skill 建回归测试

每次 Skill 更新，都比较：

旧版本 vs 新版本。

至少关注：

• 成功率
• Token
• 延迟
• Tool 调用次数
• Trace
• 回归数量

只有确认新版本真的更好，才能继续进入灰度。

Phase 4：再做自动回流

当测试、版本管理和回滚能力都比较稳定以后，再逐渐引入：

• 自动失败样本回流
• Dreaming
• 自动生成 Skill 候选
• 分级自主

这个顺序很重要。

因为：

如果连手动闭环都跑不通，自动化只会把问题放大。

---

十四、Agent 自进化对测试开发意味着什么

Agent 时代，测试对象正在发生变化。

过去我们主要测试：

• 接口
• 页面
• 服务
• 数据
• 代码

以后还需要测试：

• Agent 是否选对 Skill
• Tool 是否调用正确
• 执行路径是否合理
• Memory 是否召回正确
• LLM Judge 是否可信
• Skill 修改有没有回归
• Agent 是否逐渐偏离设计目标

因此 Agent 测试并不是传统自动化测试换一个名字。

它正在出现几个新的技术方向：

Agent Evaluation

Trace Evaluation

Skill Evaluation

Agent CI/CD

Memory Testing

Agent Regression Testing

这些能力很可能会逐渐成为 AI 测试开发中的重要组成部分。

---

结语

Agent 自进化听起来像一个 AI 领域的新概念。

但真正落到工程以后，会发现里面大量方法其实来自我们熟悉的软件质量体系：

评测是测试，失败归因是缺陷分析，Skill 更新需要回归，版本修改需要 CI/CD，线上变化需要灰度和监控。

真正变化的是：

过去被测的是一个相对稳定的软件版本。

以后被测的可能是一个：

会不断修改 Prompt、Skill、Memory 和执行策略的 Agent 系统。

这也给测试开发提出了一个新的问题：

当 Agent 开始自己修改自己以后，我们怎么持续证明它真的变好了？

这可能比“Agent 能不能完成任务”更值得测试从业者关注。