Agent自进化时代，测试开发如何证明AI越改越好？

当Agent开始自己修改Prompt、Skill和Memory，一个被忽视的问题浮出水面：谁来证明它真的变好了？

这不是科幻场景。据B站霍格沃兹软件测试开发的分享，Agent自进化正在成为现实，而测试开发正面临一个全新的课题——当Agent开始自己修改自己，我们如何持续验证它是在变好，而不是越改越偏。

Agent到底在改什么？三层进化模型

理解Agent自进化的第一步，是分清它改动的层次。从下往上，可以划分为三层：

最底层是Answer层，只是把这一次的答案改得更好，属于单次输出优化。再往上是Harness层，改的是Prompt、Skill、Memory、Tool和Workflow——这是Agent的“外挂装备”和“行为策略”。最高一层才是直接修改模型参数，触及模型本身。

对于大部分业务Agent来说，现阶段最值得关注的其实是中间这层Harness。原因很直接：模型参数微调成本高、周期长，而Harness层的改动更频繁、更贴近业务，也更容易引入隐性风险。Prompt改了一个词、Skill换了一个实现、Memory多存了一条记录，都可能让Agent的行为发生连锁变化。

测试开发需要建立对Harness层改动的敏感度：哪些改动是安全的增量优化，哪些可能破坏已有能力，这本身就是新的测试边界。

Harness（可译为“执行框架”或“行为外壳”）是Agent运行时除模型权重之外的全部可控配置的总和，包括系统提示词、工具定义与调用规范、记忆存储与检索策略、工作流编排逻辑以及各类Skill实现。它之所以成为自进化的主战场，是因为修改Harness只需改动文本或配置，无需重新训练模型，迭代周期可从数周缩短到分钟级。代价是这类改动缺乏梯度信号约束，容易在修复A场景的同时悄悄破坏B场景，因此变更影响面评估和回归覆盖比模型微调场景更为关键。

只看最终答案，是Agent评测最大的陷阱

传统大模型评测看什么？看最终输出对不对。但Agent的测试和普通大模型评测有一个本质区别：不能只看最终答案。

答案虽然对了，但Agent可能选错了Skill、走错了路径，甚至跳过了关键步骤。这次侥幸答对，下次换个输入就可能崩掉。

所以现在不仅要做结果评测，还要看Trace和执行路径。Trace记录了Agent每一步的决策和工具调用，它能暴露最终答案掩盖的过程问题。测试开发需要把Trace分析纳入常规评测体系：工具调用顺序是否合理、是否跳过了必要的校验环节、是否在错误的分支上绕了远路。

结果正确只是及格线，路径正确才是稳定性的保障。

Trace（执行轨迹）指Agent在一次任务中产生的完整决策序列，通常包含每一步的思考内容、所选工具及其参数、工具返回结果、状态转移和中间产物。与仅记录输入输出的日志不同，Trace保留了“为什么走到这一步”的因果链，可用于定位错误分支、冗余调用和缺失校验。在工程实践中，Trace常以结构化事件流形式落盘，支持按任务ID回放和逐步骤断言，是构建路径级回归用例的基础数据源。缺少Trace时，团队只能对最终答案做黑盒比对，难以区分侥幸成功与稳定正确。

评测金字塔：规则能解决的，别都交给模型

面对Agent的复杂行为，怎么设计评测策略？分享中提出了一个清晰的评测金字塔思路。

能用规则和自动化断言解决的，就不要全部交给LLM。语义理解和开放任务再交给模型评判，最上面少量高风险结果由人工介入。

这个分层逻辑的价值在于成本与可靠性的平衡。规则断言快、准、可重复，适合覆盖确定性强的检查项；模型评判灵活但存在波动和偏差，适合处理无法用规则描述的语义问题；人工则守住最后一道高风险关卡。

测试开发容易犯的错误是“什么都想用模型评”，结果评测本身成了不可靠的变量。金字塔结构提醒我们：越往下越自动化，越往上越依赖判断，资源要花在刀刃上。

Memory不是聊天记录仓库

Agent的记忆该怎么存？一个常见误区是把所有历史对话都塞进记忆库。但真正有用的记忆应该分层沉淀：从Episode到Facts再到Skills。

也就是说，从“发生过什么”提炼成“知道什么”，最后固化为“以后应该怎么做”。Episode是原始经历，Facts是提炼出的事实，Skills是可复用的行为模式。

这个分层对测试的意义在于：Memory的修改同样需要被验证。当Agent自己往Memory里写入新内容时，测试需要确认写入的是有价值的事实而非噪音，沉淀的Skill是正确模式而非偶然经验。记忆污染是隐性且持久的，一旦错误事实被固化，后续决策会持续跑偏。

记忆污染是指错误或过时的信息被写入Agent的长期记忆，并在后续任务中被反复检索、放大，最终固化为错误行为模式的现象。它与普通幻觉的区别在于持久性：单次幻觉可通过重试消除，而污染一旦进入Memory，会跨会话影响决策，且难以定位源头。典型诱因包括把用户的口误当作事实、将一次性异常经验提炼为通用Skill、以及缺乏时效标注导致旧事实覆盖新事实。防御手段包括写入前的事实校验、为记忆条目附加来源与时间戳、以及定期对高影响记忆做抽样审计和回滚能力建设。

给Agent自进化装上CICD

最关键的问题来了：Agent发现问题后，能不能让它自己改完就上线？答案显然是不能。

分享给出的方案是：像代码CICD一样管理Agent的自进化。完整流程包括诊断问题、生成候选、独立评测、回归测试、安全门控、灰度发布，最后把线上失败样本重新回流。

这个类比很精准。Agent自己生成的修改相当于一次代码提交，必须经过独立评测和回归测试才能进入发布环节。安全门控负责拦截高风险改动，灰度发布控制影响范围，失败样本回流则形成持续改进的闭环。

对测试开发来说，这意味着工作重心的转移：从手工验证单次输出，转向构建自动化、可重复、有门控的自进化验证流水线。评估器本身的质量、回归用例的覆盖度、门控规则的严谨性，都成为新的核心资产。

灰度发布在Agent场景中除了按流量比例放量，还需要按任务类型、用户群体和风险等级做分层控制。与普通软件发布不同，Agent的行为变更往往没有明确的代码差异可审，因此灰度阶段要重点监控路径级指标而非仅看成功率，例如工具调用分布是否偏移、平均步数是否异常增长、特定Skill的触发率是否突变。一旦发现指标漂移，应能快速回滚到上一版本的Harness快照。这要求团队对Prompt、Memory和工具配置做版本化管理，使每一次自进化改动都具备可追溯、可对比、可撤销的工程属性。

自主不等于全自动：控制权要留给人

最后一点关于边界：控制Agent的自主，不等于全自动。

稳定场景可以逐步放权，但安全边界、关键Skill修改、严重回归这些节点仍然需要人来把握。这不是保守，而是对风险的清醒认知。Agent的自进化能力越强，出错时的波及面就越大，关键节点的人工把关是最后的安全阀。

所以Agent自进化真正值得测试同学关注的，不是AI会不会自己变聪明，而是当Agent开始自己修改自己以后，我们怎么持续证明它真的在变好。这是Agent时代测试开发正在出现的新课题，也是评测体系需要补上的新能力。