摘要AI Agent 开始进入真实业务以后一个越来越现实的问题出现了Agent 跑了几个月之后真的会比刚上线时更会做事吗如果同一种错误反复出现历史经验没有沉淀Prompt 和 Skill 修改后也缺少稳定的回归验证那么 Agent 即使接了再多工具、工作流再复杂也很难形成真正的持续改进能力。Agent 自进化真正要解决的不是“让模型自己变聪明”而是建立一套完整的工程闭环评测发现问题 → 记忆沉淀经验 → Skill / Prompt 更新 → 回归验证 → 灰度发布 → 线上反馈再次进入评测。对软件测试开发从业者来说这套体系里包含大量熟悉的工程能力Agent 评测、自动化测试、Trace 评测、回归测试、版本管理、灰度发布和质量门禁。Agent 自进化为什么开始成为工程问题现在很多 Agent 项目已经不再停留在 Demo 阶段。一个典型的 Agent 往往已经具备大模型PromptSkillMemoryToolMCPWorkflowRAG但这些能力组合起来并不等于 Agent 就具备“自进化能力”。判断一个 Agent 有没有真正进入持续改进阶段可以先问一个很简单的问题它上个月犯过的错误这个月还会不会继续犯如果答案是“会”说明系统虽然完成了任务却没有把执行过程中的经验真正留下来。Agent 自进化要做的就是让每一次任务执行都能产生反馈并把有效反馈转化为下一轮能力。一、Agent 自进化到底在“进化”什么讨论 Agent 自进化之前首先要区分三个层次。层级修改对象是否长期生效Artifacts答案、代码、方案等当前输出否HarnessPrompt、Skill、Memory、Tool、Workflow是Model模型参数是Artifacts只把当前任务做得更好比如第一次代码生成失败Agent 自己检查后再生成一次。第二次结果可能更好。但任务结束以后这次经验没有进入系统。下次遇到同类问题Agent 仍然可能重新犯错。这类方式更接近 Self-Refine而不是严格意义上的持续进化。Harness让经验跨任务复用Harness 可以理解成 Agent 外围的运行系统包括PromptSkillMemoryTool 配置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 太简单无 Skill100% 有 Skill100%根本看不出 Skill 的价值。所以测试集需要有一定难度梯度。3. Trace 验证即便结果正确也要继续检查Agent 运行时真的调用这条 Skill 了吗4. Path 验证更进一步还要检查Agent 是否真正按照 Skill 定义的关键路径执行。因此 Skill 测试不能只看结果。它其实已经非常接近一种新的Agent 白盒测试。八、Agent 自进化真正落地需要一条 CI/CD 流水线评测发现问题之后并不应该直接让 Agent 修改配置并上线。比较完整的链路应该是线上失败 Case ↓ 评测 ↓ 诊断归因 ↓ 生成修复候选 ↓ 独立评测 ↓ 回归测试 ↓ 安全门控 ↓ 人工审核 ↓ 灰度发布 ↓ 线上监控 ↓ 新失败 Case 回流仔细看这和软件工程里的 CI/CD 非常像。过去 CI/CD 管的是代码。Agent 时代还需要开始管理PromptSkillMemoryTool 配置Workflow因此可以把它理解成Agent CI/CD。九、Agent CI/CD 里有五个特别重要的工程点1. 先做失败归因评测只告诉你失败了还不够。必须继续确认问题到底来自PromptSkillToolAPI数据环境如果工具本身有 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 0Agent 建议人执行Level 1Agent 执行人审批Level 2Agent 执行人抽检Level 3稳定场景下自主运行系统长期稳定以后可以逐步提高自主等级。但出现严重回归时应当自动降级。十二、有些关键节点必须保留人工控制即使自动化程度越来越高有几个位置仍然不适合完全交给 Agent。规则级记忆写入普通历史记录影响有限。但“以后遇到这种情况必须怎么做”这种规则会影响大量任务。写错以后污染范围非常大。Prompt / Skill 关键更新特别是涉及权限安全约束拒答逻辑业务边界不能简单自动通过。回归发生后的决策出现回归以后回滚到哪个版本是否冻结后续修改影响哪些业务都需要业务上下文。新领域冷启动没有历史数据的新业务需要人工提供第一批 Case初始 Skill安全边界系统权限边界Agent 能改什么、不能改什么本身应该提前定义清楚。十三、测试团队怎么开始做 Agent 自进化不建议一开始就搭一个非常复杂的“自进化平台”。更现实的做法是先跑通最小闭环。Phase 1先把评测做起来准备一批真实 Case例如正常场景异常场景边界场景Tool 失败参数错误复杂组合任务先验证你能不能稳定发现问题。Phase 2开始沉淀 Skill每次解决问题以后继续问一句这个问题以后还会不会再出现如果会就考虑是否值得沉淀成FactMemorySkillPhase 3给 Skill 建回归测试每次 Skill 更新都比较旧版本 vs 新版本。至少关注成功率Token延迟Tool 调用次数Trace回归数量只有确认新版本真的更好才能继续进入灰度。Phase 4再做自动回流当测试、版本管理和回滚能力都比较稳定以后再逐渐引入自动失败样本回流Dreaming自动生成 Skill 候选分级自主这个顺序很重要。因为如果连手动闭环都跑不通自动化只会把问题放大。十四、Agent 自进化对测试开发意味着什么Agent 时代测试对象正在发生变化。过去我们主要测试接口页面服务数据代码以后还需要测试Agent 是否选对 SkillTool 是否调用正确执行路径是否合理Memory 是否召回正确LLM Judge 是否可信Skill 修改有没有回归Agent 是否逐渐偏离设计目标因此 Agent 测试并不是传统自动化测试换一个名字。它正在出现几个新的技术方向Agent EvaluationTrace EvaluationSkill EvaluationAgent CI/CDMemory TestingAgent Regression Testing这些能力很可能会逐渐成为 AI 测试开发中的重要组成部分。结语Agent 自进化听起来像一个 AI 领域的新概念。但真正落到工程以后会发现里面大量方法其实来自我们熟悉的软件质量体系评测是测试失败归因是缺陷分析Skill 更新需要回归版本修改需要 CI/CD线上变化需要灰度和监控。真正变化的是过去被测的是一个相对稳定的软件版本。以后被测的可能是一个会不断修改 Prompt、Skill、Memory 和执行策略的 Agent 系统。这也给测试开发提出了一个新的问题当 Agent 开始自己修改自己以后我们怎么持续证明它真的变好了这可能比“Agent 能不能完成任务”更值得测试从业者关注。