## 摘要

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 层，再考虑模型层面的进化。**

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/3af6edc821fa443247e9e7a1674882b9.png)

---

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

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

而是先回答：

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

这就是 Agent 评测。

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

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

### 1. 发现问题

Agent 到底哪里表现不好？

可能是：

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

### 2. 判断修改是否有效

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

还要验证：

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

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

**Regression Testing，回归测试。**

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

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

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

所以在 Agent 自进化体系里：

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

---

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

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

一次 Agent 任务通常包含：

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

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

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

比如一个 Skill 要求 Agent：

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

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

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

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

**PASS。**

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

因此 Agent 测试需要逐渐从：

**Output Evaluation**

扩展到：

**Trace Evaluation。**

甚至进一步验证：

**Path Evaluation。**

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

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

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


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/f1a33969b2bf9691d858f253d0485944.png)

---

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

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

**什么都交给 LLM Judge。**

实际上并不必要。

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

例如：

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

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

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

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

适合确定性问题。

特点：

**便宜、稳定、可重复。**

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

### 第二层：LLM-as-Judge

适合：

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

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

最好做到：

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

### 第三层：人工抽样

人工主要负责：

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

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

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

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/f7754ebf6e3bdd90583a20b65d76769b.png)


---

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

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

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

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

真正困难的问题反而是：

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

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

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

所以从工程角度看：

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

---

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

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

### Episodes：经历过什么

例如：

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

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

### Facts：已经确认的事实

例如：

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

Facts 比原始对话更加稳定。

### Skills：以后应该怎么做

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

例如：

```text
遇到接口鉴权失败：

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

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

> **从经历 → 知识 → 能力。**

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/1edeac6bb0fde103437855d3d5336b52.png)

---

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

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

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

能不能直接说明：

**Skill 有效？**

不能。

因为有可能：

**模型本来就会。**

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

### 1. 对照实验

同一批 Case：

- 一组加载 Skill
- 一组不加载 Skill

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

这样才能判断：

**Skill 到底带来了多少增量。**

### 2. 难度校准

如果 Case 太简单：

```text
无 Skill：100%
有 Skill：100%
```

根本看不出 Skill 的价值。

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

### 3. Trace 验证

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

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

### 4. Path 验证

更进一步还要检查：

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

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

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

> **Agent 白盒测试。**

---

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

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

比较完整的链路应该是：

```text
线上失败 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、延迟和线上反馈，再决定是否扩大范围。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/b1c9445e3781cbd7541c445a171df845.png)


---

## 十、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 能改什么、不能改什么，本身应该提前定义清楚。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/8f65ee7ae79dc8fb1bb097dfaea7c64c.png)


---

## 十三、测试团队怎么开始做 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 能不能完成任务”更值得测试从业者关注。

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

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

人工智能

架构设计

测试

Agent自进化正从概念转向工程落地，核心并非让模型变聪明，而是建立“评测-记忆-更新-回归-灰度”的闭环。对测试开发者而言，这需将Agent评测、Trace验证、Skill回归及CI/CD等成熟质量体系迁移至AI系统，以持续验证其是否真正变好。

向量数据库

代码解释

强化学习

软件工程

软件测试

回归测试

白盒测试

Self-Refine

数据库

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Agent 自进化：从评测、记忆到 Skill 更新，工程闭环怎么搭-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐