Agent 测试平台的自进化方案与多用户评分体系

一、自进化方案分类

参照 A Survey of Self-Evolving Agents (arXiv 2507.21046) 的 "What/When/How to Evolve" 框架，测试平台的自进化可按进化对象分四层：

1. 记忆进化（最常用，成本最低）

• 从成功轨迹中提炼可复用经验：Workflow 模板（如 AWM 从成功 trajectory 归纳工作流）、failure case 库、用户偏好画像

• 短期记忆 → 长期记忆的沉淀：会话内 Reflexion 式反思只改当前输出；跨会话则需要把反思结论写入持久记忆库

• 测试平台场景：积累"哪类 prompt 容易触发误判"、"某用户的评审偏好"等

2. 工具/技能进化

• 自动生成和注册新工具：遇到现有工具解决不了的任务时，让 agent 自己写代码封装成工具，验证后入工具库

• 工具文档/描述的迭代：根据调用失败日志优化 tool description，提升选择准确率

3. 工作流与 Prompt 进化

• 多步 pipeline 的结构优化：增减反思节点、调整规划粒度

• 用 DSPy / 自动 prompt 优化，基于评测集分数离线搜索更好的 prompt

4. 模型权重进化（成本最高）

• 用积累的反馈数据做 SFT / DPO / RLHF（或 RLAIF）

• 适合平台数据量足够大、且有自建模型的场景；否则前三层性价比更高

按触发时机分

• 在线进化：会话内自我修正（reflection、自我批评），效果即时但不可持久

• 离线进化：周期性批处理——收集轨迹 → 评测 → 提炼 → 更新记忆/工具/prompt → 回归评测。这是平台级方案的主流，因为可控、可回滚

二、多用户体系下的评分设计

多用户的核心难点：信号稀疏、偏好不一致、不同用户标准冲突。建议分层评分。

1. 信号采集（三个来源）

来源	例子	特点
显式反馈	点赞/点踩、打分、修改后的最终版本	稀疏（通常 <5% 会话有），但最可靠
隐式反馈	是否采纳结果、是否追问/重试、会话时长、复制行为	量大但有噪声，需校准
自动评测	LLM-as-Judge、Agent-as-a-Judge（评估整条轨迹而非单个输出）、规则校验	全覆盖，但 judge 本身有偏差，需定期用人工标注校准（参考 LangChain 的校准实践）

2. 聚合策略

• 按用户分桶：全局分 = 各用户群体分数的加权，避免高频用户淹没小众需求

• 区分"客观正确性"（可跨用户共享）和"主观偏好"（必须按用户/群组隔离）——前者进全局记忆和工具库，后者只进该用户的偏好画像

• 给评分附加置信度：样本量小的维度降权，防止早期数据带偏进化方向

3. 冷启动

• 新用户继承同群组（同角色/同业务域）的群体画像，随个人反馈累积逐步个性化

三、如何找到进化方向

把评分变成行动的关键环节，推荐一个闭环：

1. 失败聚类：对低分轨迹做 LLM 归因 + 聚类，形成错误分类体系（如：工具选错 / 规划遗漏步骤 / 输出格式不符 / 领域知识缺失）。没有分类体系，"进化方向"就是口号

2. 影响面量化：每个失败类别计算 频率 × 平均损失分 × 受影响用户数，得到优先级排序

3. 定位进化层级：把失败类别映射到进化对象——知识缺失 → 记忆层；工具能力不够 → 工具层；策略问题 → prompt/workflow 层；系统性能力不足 → 才考虑模型层。优先在成本低的层修

4. 实验验证：每个进化动作（新记忆条目、新工具、新 prompt）走 A/B 或影子流量，用同一张回归评测集（从真实失败 case 沉淀而来）验证，分数无回归才全量

5. 防退化机制：进化库条目带版本和来源，支持回滚；新条目先小流量灰度。自进化系统最常见的死因就是错误经验污染记忆库导致恶性循环

四、总结

用评测闭环驱动进化（失败聚类 → 定位层级 → 灰度实验 → 回归验证）；多用户评分要区分可共享的客观正确性和必须隔离的主观偏好；进化优先级按 频率 × 损失 × 影响面 排序。