Agent 评测的 16 反思 + 4 层金字塔：复旦新框架对中国 Agent 工程师的启示
会议：Agentic AICon 2026 智能体应用与架构工程大会
演讲：复旦大学 · 智能体评测新框架
记录人：Mr.Sun（11年华为测试架构师 / AI Agent 方向）
本文：把复旦关于 Agent 评测的 6+1 问题 + 9 大洞察 + 6 大范式 + 4 层金字塔，整理成一份可落地的"Agent 评测工程师自检清单"
📌 写在前面
复旦这场演讲给我最深的冲击是——他们把 Agent 评测从"性能 PK"提升到了"生产级 Agent 价值评估"。整场演讲由 4 个模块组成：
- 6+1 评测现状问题——传统评测哪里不行
- 9 大深度洞察——对评测的全栈反思
- 6 大范式转变——从"性能唯一"到"多维价值"
- 4 层金字塔评测集——理想评测集的架构
本文按这个结构完整记录，并把它和我精读过的 14 篇论文做对照。
一、6+1 评测现状问题（行业被低估的隐患）
1.1 传统评测的 6 大问题
| # | 问题 | 严重度 | 后果 |
|---|---|---|---|
| 1 | 环境太理想化 | 🔴 高 | 评测高分 ≠ 实际能跑 |
| 2 | 未覆盖全流程 | 🔴 高 | 缺需求/设计/运维/迭代 |
| 3 | 缺难度分类 | 🟡 中 | 不知道 Agent 在哪类任务强/弱 |
| 4 | 忽略非功能测试 | 🔴 高 | 安全/性能/质量未测 |
| 5 | 答案泄露 | 🟡 中 | Agent 可能"背答案"过评测 |
| 6 | 过时代码实现 | 🟡 中 | 测试用例是过时"老古董" |
1.2 复旦新提的第 7 个问题：Token 经济学盲点
关键问题：要看经济效益
——"代价多大"和"信任度多高"才是真问题
传统评测： 准不准？多快？
复旦提出： 代价多大？信任度多高？两个新维度：
- 代价——花多少 token / 时间 / 算力
- 信任度——产出有多可信
好 Agent 应该在"低代价 × 高信任度"象限。
二、9 大深度洞察（对 Agent 评测的全栈反思）
洞察 1：比生成代码更重要的是理解代码
传统评测：看 Agent 能生成多少行代码
复旦观点：看 Agent 能理解多少代码理解 vs 生成：
- 生成 = 模仿（训练集里的模式）
- 理解 = 推理（新场景的应用）
真实场景：维护老系统比写新系统更常见——理解能力比生成能力更值钱。
洞察 2：什么样的评测是充分的？
关键原则：
- 真实的原子能力（不能一锅炖）
- 拆解到"最小能力单元"，每个单元独立测
❌ 错误评测：测 Agent "能不能写一个完整 Web 应用"
✅ 正确评测：测 10 个原子能力
├─ API 设计
├─ 数据库设计
├─ 错误处理
├─ 边界条件
├─ 性能优化
├─ 安全防御
├─ 命名规范
├─ 注释质量
├─ 测试覆盖
└─ 部署脚本洞察 3：评测常常忽略 AI Coding 带来的隐形负债
隐形负债类型：
- 代码可读性 ↓
- 后续维护成本 ↑
- 团队理解成本 ↑
- 重构难度 ↑
传统负债（明显）：Bug 数量、技术债
AI Coding 负债（隐形）：代码看起来能跑，但人维护不了这是 AI Coding 工业化的"暗礁"——目前业界关注不够。
洞察 4：评测结果的脆弱性
同一 Agent，不同评测可能给出截然不同的分数。
原因：
- 测试用例的随机性
- 评测环境的差异
- Prompt 模板的差异
- 评分标准的主观性
结论：单次评测分数 = 不可靠的快照，要看多次评测的分布。
洞察 5：评测数据的污染
这是最严重的隐患——评测可能"作弊"。
| 污染方式 | 描述 |
|---|---|
| 训练集泄露 | 测试用例在训练集里 |
| 背答案 | Agent 记忆了具体答案 |
| 搜索作弊 | Agent 在测试时搜索答案 |
| 动态生成泄漏 | 测试用例生成时参考了训练数据 |
| 用例筛选偏差 | 评测者选了对 Agent 有利的子集 |
检测手段：
- 动态生成测试集（避免固定答案）
- 用例筛选审计（防止选择性展示）
- 搜索检测（看 Agent 是不是在"作弊"）
洞察 6：跨语言泛化能力（假想语言）
关注 Agent 对"假想语言"的泛化能力
传统评测：测 Agent 在 Python / Java / Go 上的能力
复旦观点：创造一种"假想语言"，看 Agent 能不能快速学习并应用背后逻辑：
- 真实场景里，Agent 经常遇到新语言、新框架
- 真能力 = 快速学习新语言 + 理解领域逻辑
- 假想语言 = 排除"训练集背答案" + 测真泛化
洞察 7：不能只评测 AI，还要评测人+AI 的复合系统
真实场景：
工程师 + AI Agent = 复合系统
工程师的"指挥能力"直接影响 AI 表现
同样的 AI：
- 给顶级工程师用 = 提效 5x
- 给新手用 = 反而变慢所以评测不能只看 Agent 本身，要看 Agent 在"人+AI 系统"中的表现。
洞察 8：企业需要自建 AI Coding 评测体系
企业必须自己构建评测的 Harness
| 公开评测 | 企业自建评测 |
|---|---|
| 通用任务 | 业务专属任务 |
| 公开数据 | 企业内部数据 |
| 通用能力 | 业务能力 |
| 排名榜导向 | ROI 导向 |
企业自建 Harness 的 4 个步骤：
- 采集真实任务——用公司内部代码做测试集
- 定义业务指标——不是准确率，是"省了多少工时"
- 建立持续评测——每次模型升级都跑一遍
- 评测 Harness 即代码——和业务代码一起维护
这是一个全新的岗位——AI 评测工程师（复旦在指出新职业方向）。
洞察 9：AI Native 思路构建评测（魔法打败魔法）
用 AI 来评测 AI
传统评测：人写测试用例 → Agent 跑 → 人评分
AI Native 评测：Agent 生成测试 → Agent 跑 → Agent 评分 → Agent 找问题4 个应用：
- Agent 生成测试用例（动态生成，避免污染）
- Agent 互相评分（多 Agent 交叉验证）
- Agent 找自己漏洞（Self-Reflection = 评测自己的评测）
- Agent 监控 Agent（生产环境持续评测）
三、6 大范式转变（从"性能唯一"到"多维价值"）
范式 1：面向结果 → 面向过程
旧范式：
Agent 提交代码 → 测试通过 → ✅ 满分
（不管过程多烂）
新范式：
Agent 思考过程 → 工具调用 → 失败重试 → 反思 → 提交
（过程 > 结果）为什么要看过程？
- 结果正确 ≠ 推理正确
- 过程错误 → 下一个任务还会错
- 过程的稳健性 = 长期可用的能力
范式 2：关注功能 → 关注非功能
| 功能测试 | 非功能测试 |
|---|---|
| ✅ 代码能跑 | 🔒 安全性 |
| ✅ 业务逻辑 | ⚡ 性能 |
| ✅ API 调用 | 🔧 可维护性 |
| ✅ 数据处理 | 📚 可读性 |
| 🌐 兼容性 | |
| 📈 可扩展性 | |
| ♿ 可访问性 |
真实工业场景——非功能 bug 占比 >50%（行业经验值）。
范式 3：反向提问能力
Agent 能不能"主动澄清需求"？
用户：写一个用户登录功能
❌ 弱 Agent：直接写代码（猜需求）
✅ 强 Agent：
- 登录方式？手机号/邮箱/SSO？
- 密码强度要求？
- 是否需要验证码？
- 失败重试策略？
- Token 过期时间？
- 多端登录支持？反向提问 = Agent 的"沟通能力"——这是被严重低估的能力。
范式 4：意图保持的半衰期
Agent 在长任务中会不会"忘记"原始意图？
任务："重构这个老系统，从 Java 8 升级到 Java 17"
5 分钟后：Agent 还在做 Java 17 升级
30 分钟后：Agent 开始优化微服务架构
1 小时后：Agent 引入新的数据库
2 小时后：Agent 推翻了原有架构 ← 离原始意图越来越远"意图半衰期"——衡量 Agent 在多轮、长程任务中保持原始目标的能力。
3 种测试粒度：
- 细粒度：每 1 步检查意图
- 中粒度：每 5 步检查一次
- 粗粒度：每 10 步检查一次
范式 5：从单点评分到能力图谱
旧评测（单点）：
Agent 总分 = 85 分（不知道哪里强、哪里弱）
新评测（能力图谱）：
┌──────────────────────┐
│ 代码生成 ★★★★☆ │
│ 调试能力 ★★★☆☆ │
│ 架构设计 ★★★★★ │
│ 安全性 ★★☆☆☆ │ ← 弱项
│ 可维护性 ★★★★☆ │
│ 性能优化 ★★★☆☆ │
│ 沟通能力 ★★★★★ │
└──────────────────────┘
雷达图 / 球型评估能力图谱的价值：
- 一眼看出"短板"
- 决定 Agent 适合什么场景
- 决定需要补什么能力
范式 6：效用经济学评测
看真实使用价值，不是 benchmark 分数
传统评测：
Agent 准确率 95%（在 SWE-Bench 上）
效用经济学评测：
真实场景使用 1 个月后：
├─ 省了多少工时？ → 200 小时/月
├─ 工程师满意度？ → 4.2/5
├─ 返工率？ → 15%
├─ 培训成本？ → 10 小时/人
└─ 实际 ROI？ → 1.5x效用经济学的关键指标：
- 真实使用数据（生产环境埋点）
- 用户满意度（NPS）
- 投资回报率（ROI）
- 长期价值（不是 benchmark 一次性分数）
四、4 层金字塔评测集（理想评测集的架构）
┌─────────────────────────────────────┐
│ 第 4 层：人机高效协作能力 │ ← 最高
│ ├─ 拒绝能力（说不） │
│ ├─ 教育功能（教会人） │
│ └─ 沟通协作 │
├─────────────────────────────────────┤
│ 第 3 层：真实软件工程实践能力 │
│ ├─ 安全性 │
│ ├─ 性能 │
│ ├─ 可维护性 │
│ └─ 其他非功能 │
├─────────────────────────────────────┤
│ 第 2 层：原子能力 + 认知能力 │
│ ├─ 原子能力（生成/调试/重构...） │
│ └─ 认知能力（知道自己不知道） │
├─────────────────────────────────────┤
│ 第 1 层：基础任务能力 │ ← 最低
│ ├─ 代码生成 │
│ ├─ 代码理解 │
│ └─ 简单问题 │
└─────────────────────────────────────┘第 2 层：原子能力 + 认知能力
| 能力 | 描述 | 测试方式 |
|---|---|---|
| 原子能力 | 单点编程能力 | 拆解到最小能力单元测 |
| 认知能力 | "知道自己不知道" | 故意问超纲问题，看 Agent 是否承认 |
"知道自己不知道" 是关键元能力：
❌ 弱 Agent：用户问任何问题都答（幻觉）
✅ 强 Agent：超出能力时主动说"我不确定"第 3 层：真实软件工程实践能力
| 维度 | 测试什么 |
|---|---|
| 安全性 | SQL 注入、XSS、权限绕过 |
| 性能 | 大数据量、并发、内存 |
| 可维护性 | 代码可读性、模块化、文档 |
| 可靠性 | 错误处理、降级、容错 |
| 可测试性 | 是否便于测试 |
这一层 = 测试架构师的主场——11 年经验让你对这些维度最敏感。
第 4 层：人机高效协作能力
1. 拒绝能力（最重要）
Agent 能不能在不合适的时候说"不"？
场景 1：用户要求"删库跑路"
❌ 弱 Agent：执行
✅ 强 Agent："我建议先备份再删除"
场景 2：用户要求"绕过测试直接上线"
❌ 弱 Agent：跳过测试
✅ 强 Agent："跳过测试会引入 X 风险，建议保留"2. 教育功能
Agent 能不能在做事的同时"教会"人？
❌ 弱 Agent：直接给答案
✅ 强 Agent：
- 给答案 + 解释为什么
- 推荐相关学习资料
- 反问用户是否理解
- 引导用户思考3. 沟通协作
Agent 能不能和工程师/PM/客户高效协作？
- 听懂模糊需求
- 反向提问
- 进度汇报
- 冲突管理（"两个需求冲突，先做哪个？"）
五、和 14 篇论文的对照（我的反思）
| 复旦观点 | 对应论文 |
|---|---|
| 1. 理解 > 生成 | Computer Use（理解 UI） |
| 2. 原子能力拆解 | AgentBench（8 环境） |
| 3. 隐形负债 | ❌ 14 篇论文未明确讨论——新洞见 |
| 4. 评测脆弱性 | Reflexion（Self-Evaluation 应对不一致） |
| 5. 数据污染 | Computer Use（benchmark contamination） |
| 6. 假想语言泛化 | Voyager（终身学习新技能） |
| 7. 人+AI 复合评测 | MetaGPT / ChatDev（角色协作） |
| 8. 企业自建 Harness | AgentScope（我的实战） |
| 9. AI Native 评测 | Reflexion（Self-Reflection） |
| 范式 1 过程 > 结果 | Reflexion（Self-Reflection 过程） |
| 范式 2 非功能 ≥ 功能 | Computer Use（行为安全） |
| 范式 3 反向提问 | MetaGPT（SOP 强制澄清） |
| 范式 4 意图半衰期 | MemGPT（长期记忆） |
| 范式 5 能力图谱 | AgentBench（多环境评估） |
| 范式 6 效用经济 | Generative Agents（长期行为） |
| 第 2 层 认知能力 | Reflexion（Self-Evaluation） |
| 第 4 层 拒绝能力 | ❌ 新洞见——待研究 |
| 第 4 层 教育功能 | ❌ 新洞见——待研究 |
| 第 4 层 沟通协作 | ChatDev（角色协作） |
复旦 16+4 框架 = 14 篇论文的"评测维度匹配" + 2 个新研究方向（拒绝能力、教育功能）
六、Agent 评测工程师：下一个新职业？
复旦明确指出：企业自建 Harness = 新岗位 = AI 评测工程师。
这个岗位的核心能力：
- 业务理解（把业务目标转成评测指标）
- AI 知识（理解 Agent 能力边界）
- 工程能力（构建持续评测 Harness）
- 经济学思维（算 ROI，不是算准确率）
对求职的启示：这是 AI Agent 时代的新蓝海岗位——你可以从测试架构师转型。
七、自检清单：你的 Agent 能在 4 层金字塔打几分？
| 层级 | 你的 Agent 得分 | 改进方向 |
|---|---|---|
| 第 1 层 基础任务 | ? | 增加基础任务覆盖 |
| 第 2 层 原子 + 认知 | ? | 拆解原子能力 + 加"拒答"机制 |
| 第 3 层 真实工程 | ? | 强化安全/性能/可维护性 |
| 第 4 层 人机协作 | ? | 加拒绝/教育/沟通能力 |
建议每月做一次自检——看 Agent 在 4 层的能力图谱变化。
八、总结：复旦给我的 6+1+9+6+4 = 26 个核心启发
| 模块 | 数量 | 核心 |
|---|---|---|
| 现状问题 | 6+1 | 传统评测 6 大问题 + Token 经济学 |
| 深度洞察 | 9 | 评测全栈反思 |
| 范式转变 | 6 | 从性能唯一到多维价值 |
| 评测集架构 | 4 | 金字塔 4 层 |
| 合计 | 26 | 完整框架 |
对求职的启示：
复旦新出的 Agent 评测框架把"代价 × 信任度"、"反向提问"、"意图半衰期"、"能力图谱"、"效用经济学"、"拒绝能力"、"教育功能"等维度系统化。这给我做 AI 测试助手最大启发：测试 Agent 的价值不在"自动化率多高"，而在"自动化 ROI 多高"+ "能不能拒绝不当请求"。我下一步会按 4 层金字塔设计 AI 测试助手的评测体系。
附录：参考资料
| 资源 | 链接 |
|---|---|
| AgentBench 论文 | （已精读 11 篇） |
| Reflexion 论文 | （已精读） |
| 我的 Agent 论文精读系列 | sunrong1.github.io |
欢迎交流讨论，我的 blog：sunrong.site
相关阅读：