AI Agent评价体系
Agent 领域一个很核心的工程问题 —— 怎么知道你的 Agent 做得好不好。
以 IDE（代码助手 Agent，比如 Cursor、GitHub Copilot、Claude Code）为例来拆解。
评价维度
Agent 的评价通常分三层：
第一层：任务完成质量
最直接的问题——它把事情做对了吗？
对 IDE Agent 具体来说：
指标含义怎么测代码正确率生成的代码能跑通吗跑单元测试，Pass Rate需求满足度做的是不是用户要的那件事人工评审 or LLM-as-Judge编译通过率语法有没有问题静态分析工具Bug 引入率改完之后有没有引入新问题回归测试对比
第二层：过程质量
不只看结果，还看 Agent 是怎么完成的——因为过程质量决定了结果的可信度和可维护性。
指标含义步骤效率有没有走弯路、重复调用工具工具调用准确性调了正确的工具（读文件/搜索/执行）吗上下文利用率有没有充分用已有信息，而不是反复询问幻觉率有没有编造不存在的函数、API
第三层：用户体验
指标含义响应延迟等多久交互轮次来回几次才完成任务接受率用户接受了多少比例的建议（不改直接用）打扰度有没有频繁要求用户确认、打断工作流
业界常用的评测方法
1. Benchmark 基准测试
用标准数据集跑分，主要有：
SWE-bench：给真实 GitHub Issue，看 Agent 能不能写出正确的 PR 修复它。目前公认最硬核的代码 Agent 评测，满分 100%，顶级模型 2025 年底能到 50% 左右
HumanEval / MBPP：经典代码生成基准，给函数描述让模型写实现
LiveCodeBench：持续更新题目防止训练集污染
2. LLM-as-Judge
用另一个 LLM（通常是更强的模型）来评价输出质量，打分并给出理由。好处是可以评价主观题（”这段代码可读性如何”），缺点是评价者本身也可能有偏差。
3. 人工评审（Human Eval）
让真实工程师使用后打分，是最贵但最准的方法。Cursor 等公司内部会做大量这类评测。
4. A/B 测试（生产环境）
线上对比，看用了 Agent A 的用户和用了 Agent B 的用户，代码接受率、完成任务时长等指标谁更好。
IDE Agent 评价的特殊难点
IDE Agent 比一般 Agent 难评价，原因有几个：
任务边界模糊
“帮我重构这个模块”——什么叫重构完了？没有标准答案，很难自动判断对错。
上下文依赖极强
同一个问题在不同代码库里答案完全不同，通用 benchmark 分数高不代表在你的项目里好用。
延迟评价问题
Agent 改完代码，三天后上线才发现有 Bug——这个反馈很难及时回流到评测系统。
多步骤归因困难
Agent 做了 10 步操作，第 7 步走错了，最终结果不好——但你很难自动定位是哪一步出了问题。
一个实用的评价框架
如果你自己要评价一个 IDE Agent，可以用这个结构：
① 选定任务集
真实的、有难度梯度的编程任务
（简单：写一个函数 / 中等：修复一个 Bug / 复杂：重构一个模块）
② 定义成功标准
测试通过 + 代码风格合规 + 不引入新问题
③ 跑自动评测
SWE-bench 或自建测试集，得到基础分数
④ 人工抽样评审
重点看 Agent 的推理过程，不只看最终输出
⑤ 生产数据验证
接受率、重新编辑率（用户改了多少 Agent 的输出）
核心结论： 评价 Agent 不能只看”它说的对不对”，要同时看结果正确性 + 过程合理性 + 用户实际采纳情况。三者都好，才是真正好用的 Agent。SWE-bench 是目前代码 Agent 领域最权威的单一指标，但它测的是”能不能自主修复 GitHub Issue”，和你日常使用的补全、重构场景还有差距，最终还是要结合自己的真实使用场景来评。