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

## 一、自进化方案分类

参照 [A Survey of Self-Evolving Agents (arXiv 2507.21046)](https://arxiv.org/html/2507.21046v4) 的 "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](https://arxiv.org/html/2508.02994v1)（评估整条轨迹而非单个输出）、规则校验 | 全覆盖，但 judge 本身有偏差，需定期用人工标注校准（参考 [LangChain 的校准实践](https://www.langchain.com/resources/llm-as-a-judge)） |

### 2. 聚合策略

- 按用户分桶：全局分 = 各用户群体分数的加权，避免高频用户淹没小众需求
- 区分"客观正确性"（可跨用户共享）和"主观偏好"（必须按用户/群组隔离）——前者进全局记忆和工具库，后者只进该用户的偏好画像
- 给评分附加置信度：样本量小的维度降权，防止早期数据带偏进化方向

### 3. 冷启动

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

## 三、如何找到进化方向

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

1. **失败聚类**：对低分轨迹做 LLM 归因 + 聚类，形成错误分类体系（如：工具选错 / 规划遗漏步骤 / 输出格式不符 / 领域知识缺失）。没有分类体系，"进化方向"就是口号
2. **影响面量化**：每个失败类别计算 `频率 × 平均损失分 × 受影响用户数`，得到优先级排序
3. **定位进化层级**：把失败类别映射到进化对象——知识缺失 → 记忆层；工具能力不够 → 工具层；策略问题 → prompt/workflow 层；系统性能力不足 → 才考虑模型层。优先在成本低的层修
4. **实验验证**：每个进化动作（新记忆条目、新工具、新 prompt）走 A/B 或影子流量，用同一张回归评测集（从真实失败 case 沉淀而来）验证，分数无回归才全量
5. **防退化机制**：进化库条目带版本和来源，支持回滚；新条目先小流量灰度。自进化系统最常见的死因就是错误经验污染记忆库导致恶性循环

## 四、总结

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