上个月参加一个 Agent 产品的内部评审，产品经理拿出一张 benchmark 表格：准确率 92%、响应时间 1.2 秒、幻觉率 3%。数字很漂亮，领导很满意。
然后我问了一个问题：“这个 92% 的准确率，是在什么任务上测的？”
回答是一组通用 QA 数据集。
我又问：“你的目标用户是电商运营，你有没有用电商运营真实工作场景的任务来测？”
会议室安静了五秒钟。
这就是今天 Agent 评测的核心矛盾：我们在用"通用考试"的成绩来预测"专业岗位"的表现。 这就像用高考数学成绩来判断一个人能不能当好外科医生——逻辑上不成立，但大家都在这么干。
一、为什么通用 Benchmark 在 Agent 评测中失效
先说清楚问题的本质。
当前主流的 Agent benchmark（SWE-bench、WebArena、GAIA 等）有一个共同特征：它们测的是 Agent 的"底层能力"——推理、工具使用、多步规划。 这些很重要，但远远不够。
打个比方：你要招一个财务分析师。通用 benchmark 相当于测他的智商、阅读理解和数学计算能力。这些当然是基础，但你真正关心的是：
- 他能不能准确做出一张现金流预测表？
- 面对模糊的业务数据，他会不会做出合理假设？
- 他产出的分析报告，CFO 能不能直接拿去做决策？
能力 ≠ 胜任力。 通用 benchmark 测的是能力，但业务需要的是胜任力。
这个 gap 有多大？我们在实际项目中观察到的数据：
| 场景 | 通用 benchmark 表现 | 实际业务任务完成率 | 差距 |
|---|---|---|---|
| 电商客服 Agent | 90%+ | 62% | -28% |
| 法务合同审查 Agent | 88%+ | 45% | -43% |
| HR 简历筛选 Agent | 91%+ | 71% | -20% |
| 运维告警处理 Agent | 89%+ | 58% | -31% |
差距来自哪里？ 三个层面：
- 领域知识缺失： 通用 benchmark 不测"你知不知道《劳动合同法》第 39 条"，但 HR Agent 必须知道。
- 流程适配不足： 每个岗位有自己的 SOP，Agent 是否能嵌入而非打断现有流程，benchmark 完全不覆盖。
- 输出格式错配： 运维要的是可执行的 shell 命令，财务要的是符合会计准则的报表格式——通用评测只看"答对没有"，不看"输出能不能直接用"。
二、分层评测框架：从通用到行业到岗位
解决方案不是扔掉通用 benchmark，而是在它上面叠加两层。
┌─────────────────────────────────┐
│ L3: 岗位级评测（Role-level） │ ← "这个具体岗位的活，干得怎么样"
├─────────────────────────────────┤
│ L2: 行业级评测（Industry-level）│ ← "这个行业的规则和知识，懂不懂"
├─────────────────────────────────┤
│ L1: 通用能力评测（General） │ ← "基本功扎不扎实"
└─────────────────────────────────┘
每一层回答不同的问题，用不同的方法来测。
L1：通用能力层——Agent 的基本功
这一层已有成熟方案，简单列一下核心维度：
| 维度 | 测什么 | 典型 benchmark |
|---|---|---|
| 推理能力 | 多步逻辑推导 | MMLU, ARC, GSM8K |
| 工具使用 | API 调用准确率 | ToolBench, API-Bank |
| 指令跟随 | 理解并执行复杂指令 | IFEval, MT-Bench |
| 多步规划 | 任务分解与执行 | SWE-bench, WebArena |
| 上下文管理 | 长对话一致性 | RULER, LongBench |
L1 是门槛，不是终点。通过 L1 只能说明"这个 Agent 有潜力"，不能说明"它能胜任某个岗位"。
L2：行业级评测——领域知识与合规性
这一层测的是 Agent 对特定行业的理解深度。不同行业差异极大，以下是四个典型行业的评测维度设计：
金融行业
# 金融行业 Agent 评测维度
domain_knowledge:
- 会计准则理解（CAS/IFRS 关键条款识别与应用）
- 金融产品知识（债券、衍生品、结构化产品）
- 监管政策理解（银保监会、证监会最新规定）
compliance:
- 反洗钱规则遵循（可疑交易识别准确率）
- 信息披露规范（格式、时限、内容完整性）
- 客户隐私保护（PII 脱敏处理）
numerical_precision:
- 财务计算准确度（小数点精度、四舍五入规则）
- 汇率/利率计算（T+0/T+1 规则理解）
- 税务计算（增值税、所得税、跨境税务）
医疗健康
# 医疗健康行业 Agent 评测维度
clinical_knowledge:
- 诊断逻辑（症状→疾病的推理链准确性）
- 药物知识（适应症、禁忌症、药物相互作用）
- 检验指标解读（正常范围、临床意义）
safety_boundaries:
- 诊断建议的免责声明（是否主动提示就医）
- 紧急情况识别（是否能识别需要急救的信号）
- 禁止行为边界（不开处方、不替代医生）
terminology:
- 医学术语准确性（ICD-10 编码、药品通用名）
- 患者沟通语言（专业术语转化为通俗语言）
法律行业
# 法律行业 Agent 评测维度
legal_knowledge:
- 法条引用准确性（法条号、条款内容是否真实存在）
- 司法解释理解（最新司法解释的适用）
- 案例检索相关性（判例与当前案情的匹配度）
reasoning_quality:
- 法律推理链完整性（大前提→小前提→结论）
- 多方利益分析（原告/被告/第三方视角）
- 风险评估的保守性（是否倾向于提示风险而非忽略）
output_standards:
- 法律文书格式（起诉状、合同、法律意见书的规范性）
- 引用格式（法条、案例的标准引用方式）
电商零售
# 电商零售行业 Agent 评测维度
business_knowledge:
- 平台规则理解（淘宝/京东/抖音各平台规则差异）
- 营销知识（ROI 计算、投放策略、促销机制）
- 供应链概念（库存周转、采购周期、物流时效）
data_literacy:
- 数据指标理解（GMV、UV、转化率、客单价的关系）
- 数据异常识别（刷单、异常退货、流量波动）
- 趋势分析（同比/环比、季节性因素）
platform_operations:
- 商品信息规范（标题优化、属性填写、图片要求）
- 客服话术合规（广告法禁用词、承诺底线）
L3：岗位级评测——真实工作场景的任务完成度
这是最关键也最难的一层。L3 不是问 Agent"你知不知道"，而是让它"做一遍"。
核心设计原则：从岗位的真实工作任务中抽取评测用例。
具体方法：
第一步：拆解岗位的日常任务清单。
以"电商运营"岗位为例：
电商运营日常任务
├── 数据分析（30%）
│ ├── 日报/周报制作
│ ├── 竞品数据监控
│ └── 活动效果复盘
├── 商品管理（25%）
│ ├── 商品上架/编辑
│ ├── 价格策略调整
│ └── 库存预警处理
├── 营销推广（25%）
│ ├── 活动策划执行
│ ├── 广告投放管理
│ └── 优惠券/满减设置
└── 客户运营（20%）
├── 客户分群
├── 会员权益管理
└── 客诉升级处理
第二步：为每个任务设计评测场景。
不是出选择题，而是给一个完整的任务情境，让 Agent 产出完整的工作交付物。
# 岗位级评测用例示例：电商运营 - 日报制作
# generated by hugo's coding agent
eval_case = {
"role": "电商运营",
"task": "制作昨日店铺运营日报",
"context": {
"store": "XX旗舰店",
"platform": "淘宝",
"data_source": "生意参谋导出的 CSV 数据",
"date": "2026-03-30"
},
"input": "attached_csv_file.csv", # 真实脱敏数据
"expected_output": {
"format": "markdown_table + key_insights",
"required_metrics": [
"访客数及环比变化",
"支付转化率",
"客单价",
"GMV 及目标达成率"
],
"required_analysis": [
"流量来源变化分析",
"转化率异常归因",
"至少一条可执行的优化建议"
]
},
"scoring": {
"data_accuracy": 0.3, # 数字是否正确
"insight_quality": 0.3, # 分析是否有价值
"actionability": 0.2, # 建议是否可执行
"format_compliance": 0.1,# 格式是否规范
"efficiency": 0.1 # 完成时间
}
}
第三步：定义"合格"的标准——对标人类岗位能力。
这一步最容易被忽略，也最重要。评分标准不是拍脑袋定的，而是来自对人类员工的分级：
| 等级 | 人类对标 | Agent 需要达到的标准 |
|---|---|---|
| L0 - 不可用 | 实习生第一天 | 输出无法使用，需要全部重做 |
| L1 - 辅助级 | 实习生一周后 | 能产出初稿，但需要大量修改 |
| L2 - 可用级 | 初级员工 | 产出可用，只需少量调整 |
| L3 - 独立级 | 熟练员工 | 产出可直接使用，质量稳定 |
| L4 - 专家级 | 资深员工 | 产出超过一般人类水平 |
Agent 产品的上线门槛应该是 L2，而不是 L3。 因为 Agent 的价值公式是：
Agent 价值 = (人类时间成本 × 节省比例) - (Agent 产出修正成本 + Agent 运行成本)
只要修正成本低于从零开始做的成本，Agent 就有正向价值。
三、七个岗位的评测维度速查表
讲了方法论，接下来给干货。以下是七个典型岗位的 L3 评测维度设计，可以直接拿来用（其中电商运营给出了最详细的完整方案）。
1. 客服专员
评测任务 核心指标 权重
──────────────────────────────────────────────────────
意图识别 识别准确率 20%
知识库问答 回答准确率 + 引用准确性 20%
情绪安抚 用户情绪转化率（负→中/正） 15%
多轮对话管理 上下文一致性 + 追问合理性 15%
工单流转判断 升级/转接决策准确率 15%
违禁词/敏感信息管控 零容忍（一票否决） 15%
关键评测场景：给 Agent 一段愤怒客户的投诉录音转写文本，要求它完成安抚、问题定位、解决方案提供、工单创建的全流程。
2. 数据分析师
评测任务 核心指标 权重
──────────────────────────────────────────────────────
SQL 编写 查询正确率 + 性能合理性 20%
数据清洗 异常值识别率 + 处理合理性 15%
可视化制作 图表选型合理性 + 标注完整性 15%
分析报告撰写 洞察深度 + 结论可靠性 25%
统计方法应用 方法选择正确性 + 假设合理性 15%
业务指标定义 口径理解准确率 10%
关键评测场景：给 Agent 一份原始销售数据（含脏数据），要求输出一份完整的月度分析报告，包括数据清洗说明、核心趋势、异常解释和建议。
3. 内容运营
评测任务 核心指标 权重
──────────────────────────────────────────────────────
内容策划 选题相关性 + 角度新颖性 20%
文案撰写 品牌调性一致性 + 可读性 25%
SEO 优化 关键词覆盖 + 结构化合理性 15%
多平台适配 不同平台格式/字数/风格适配 15%
数据复盘 内容指标归因分析质量 15%
热点响应 时效性 + 品牌关联度 10%
4. 法务专员
评测任务 核心指标 权重
──────────────────────────────────────────────────────
合同审查 风险条款识别率 + 修改建议质量 30%
法律研究 法条引用准确性 + 分析完整性 25%
合规检查 违规点识别率 + 整改建议可行性 20%
法律文书起草 格式规范性 + 逻辑严密性 15%
风险提示 风险等级判断准确性 10%
关键评测场景：给 Agent 一份真实的商业合同（脱敏），要求标出所有对我方不利条款，给出修改建议，并出具一份法律风险评估意见。
5. HR 招聘专员
评测任务 核心指标 权重
──────────────────────────────────────────────────────
简历筛选 匹配度评分准确性 + 理由合理性 25%
JD 编写 岗位要求完整性 + 吸引力 15%
面试问题设计 问题针对性 + 覆盖度 20%
候选人沟通 专业度 + 温度感 + 信息完整性 15%
人才画像分析 维度全面性 + 判断准确性 15%
背调要点梳理 风险维度覆盖 + 问题设计质量 10%
6. 财务分析师
评测任务 核心指标 权重
──────────────────────────────────────────────────────
财务报表分析 比率计算准确性 + 趋势解读 25%
预算编制 假设合理性 + 数字一致性 20%
成本分析 归因准确性 + 优化建议质量 20%
现金流预测 预测模型合理性 + 敏感性分析 20%
审计支持 凭证匹配率 + 异常标记准确率 15%
关键评测场景：给 Agent 三年的财务报表数据，要求输出一份包含杜邦分析、现金流预测和风险提示的管理层报告。
7. 电商运营
电商运营是本文反复用来举例的岗位，因为它天然适合 Agent 介入——任务标准化程度高、数据密集、时效性强。下面给出一套可以直接落地的完整评测方案。
评测维度总览
评测任务 核心指标 权重
──────────────────────────────────────────────────────────
数据看板与日报 数据准确性 + 洞察质量 20%
商品上架与优化 信息完整性 + 平台规则合规 15%
活动策划与执行 方案可行性 + ROI 预估合理性 20%
广告投放分析 投放策略合理性 + 优化建议质量 15%
客户分群与触达 分群逻辑 + 触达方案转化预估 15%
竞品监控与分析 信息抓取完整性 + 差异化洞察 10%
异常预警与应急 响应速度 + 处置方案可行性 5%
五个核心评测场景
场景一：跨平台日报生成（数据分析能力）
# 电商运营日报评测用例
# generated by hugo's coding agent
eval_daily_report = {
"task": "根据多平台数据生成跨渠道运营日报",
"context": {
"platforms": ["淘宝天猫", "抖音电商", "京东"],
"date": "2026-03-30",
"store_tier": "年 GMV 5000 万级",
"data_inputs": [
"生意参谋_流量概览.csv",
"抖店_罗盘数据.csv",
"京东_商智数据.csv"
]
},
"expected_output": {
"required_sections": [
"全渠道 GMV 汇总及目标达成率",
"各平台核心指标对比（UV/转化率/客单价）",
"流量来源结构变化（自然流量 vs 付费流量）",
"TOP10 商品动销排行及库存预警",
"关键异常标记（转化率下降>10%、退货率上升等）",
"次日重点待办事项（至少 3 条可执行建议）"
],
"format": "结构化 markdown，含数据表格和环比箭头标记"
},
"scoring": {
"data_accuracy": 0.30, # 数字、百分比、环比计算是否正确
"cross_platform_insight": 0.25,# 跨平台对比分析是否有增量价值
"actionability": 0.20, # 建议是否具体到可直接执行
"format_compliance": 0.15, # 是否符合运营团队的日报模板
"anomaly_detection": 0.10 # 是否主动发现了数据中的异常
}
}
场景二：大促活动策划（营销策划能力）
# 电商运营大促策划评测用例
# generated by hugo's coding agent
eval_campaign = {
"task": "策划 618 大促期间的店铺营销方案",
"context": {
"platform": "淘宝天猫",
"category": "家居日用",
"budget": "推广预算 50 万",
"historical_data": "去年 618 销售数据 + 竞品活动复盘",
"constraints": [
"主推 3 款新品，库存各 5000 件",
"老客复购率目标 35%",
"ROI 不低于 3.0"
]
},
"expected_output": {
"required_sections": [
"活动节奏（蓄水期/预热期/爆发期/返场期各阶段策略）",
"商品分层策略（引流款/利润款/形象款定价与库存分配）",
"推广费用分配（直通车/引力魔方/万相台各渠道预算占比）",
"优惠券与满减梯度设计",
"预估 GMV 及 ROI 测算过程",
"风险预案（库存不足、流量不达预期、竞品低价打击）"
]
},
"scoring": {
"strategy_coherence": 0.25, # 各阶段策略是否逻辑自洽
"budget_rationality": 0.20, # 预算分配是否有数据支撑
"roi_calculation": 0.20, # ROI 测算过程是否可验证
"creativity": 0.15, # 玩法设计是否有差异化亮点
"risk_awareness": 0.10, # 风险预案是否覆盖主要场景
"platform_rules": 0.10 # 方案是否符合平台活动规则
}
}
场景三：商品标题与详情页优化（商品运营能力）
给 Agent 一组商品（含现有标题、主图、属性、近 30 天搜索词报表），要求它：
- 诊断当前标题的关键词覆盖问题
- 基于搜索词报表重新组合标题（30 字以内，核心词+属性词+长尾词）
- 输出详情页卖点提炼框架（痛点→方案→证据→促单）
- 标注违反广告法的禁用词风险
评分标准：关键词覆盖率（25%）、标题可读性（20%）、卖点提炼精准度（25%）、合规性（20%）、与竞品的差异化（10%）。
场景四：广告投放诊断与优化（付费推广能力）
# 广告投放优化评测用例
# generated by hugo's coding agent
eval_ad_optimization = {
"task": "诊断直通车计划表现并给出优化方案",
"context": {
"platform": "淘宝",
"campaign_data": "近 14 天直通车分日报表 + 关键词报表 + 人群报表",
"current_status": {
"daily_budget": 3000,
"avg_ppc": 2.8,
"roi": 1.5,
"target_roi": 3.0,
"click_rate": "3.2%",
"conversion_rate": "1.8%"
}
},
"expected_output": {
"required_sections": [
"当前投放问题诊断（至少 3 个具体问题及数据佐证）",
"关键词层面优化（删词/加词/调价的具体操作清单）",
"人群溢价调整建议（各人群包的出价系数）",
"创意优化方向（基于点击率数据）",
"预期优化效果（调整后 ROI 预估及测算逻辑）"
]
},
"scoring": {
"diagnosis_accuracy": 0.30, # 问题定位是否命中真因
"optimization_specificity": 0.30, # 建议是否具体到可直接操作
"data_reasoning": 0.20, # 每条建议是否有数据支撑
"roi_projection": 0.10, # 优化后 ROI 预估是否合理
"platform_knowledge": 0.10 # 是否了解最新的投放产品功能
}
}
场景五：客户分群与精准营销（用户运营能力）
给 Agent 一份脱敏的客户 RFM 数据（最近购买时间、购买频次、累计消费金额，约 1 万条），要求它：
- 设计客户分群模型（不少于 5 个层级）
- 每个层级给出标签定义、客户数量占比、典型画像
- 针对每个分群设计差异化触达策略（渠道、时机、内容、优惠力度）
- 给出"沉睡客户唤醒"专项方案，包括预期唤醒率和成本估算
评分标准：分群逻辑合理性（25%）、策略差异化程度（25%）、预期效果可量化（20%）、成本测算合理性（15%）、方案可执行性（15%）。
电商运营 Agent 的"一票否决"项
除了上面的常规评分，电商运营 Agent 有几条红线，触碰任意一条直接判定为不合格：
| 否决项 | 说明 | 为什么是红线 |
|---|---|---|
| 价格计算错误 | 满减、折扣、优惠券叠加后的到手价计算有误 | 直接影响利润，可能导致亏本销售 |
| 广告法违规 | 使用"最"“第一"“国家级"等绝对化用语 | 面临平台处罚甚至行政罚款 |
| 库存超卖建议 | 活动方案中的预估销量超过实际可用库存 | 超卖导致批量退款和店铺评分下降 |
| 平台规则违反 | 建议的促销方式违反平台当期活动规则 | 导致活动资格取消或店铺降权 |
| 数据口径混淆 | 混淆 GMV 与实收、UV 与 PV 等基础概念 | 基于错误数据做出的决策全部无效 |
评测数据准备建议
电商运营的评测数据相比其他岗位有一个天然优势：数据高度结构化，且容易脱敏。 具体操作：
- 导出真实数据： 从生意参谋、抖店罗盘等后台导出 CSV，将店铺名/商品名/客户信息替换为虚构值
- 保留数据分布： 脱敏时保持数据的统计特征（均值、方差、趋势），否则评测场景会失真
- 标注"金标准”： 让团队里最优秀的运营针对同一份数据产出一份标准答案，作为对照
- 覆盖季节性： 评测集应包含大促期、日销期、淡季等不同阶段的数据，避免只在某一类场景下测试
四、评测数据从哪来：三条实用路径
方法论有了，最大的难题是：评测数据从哪来？
路径一：从真实工作记录中抽取（推荐）
日常工作 → 脱敏 → 标注 → 评测集
- 找到目标岗位表现最好的 3-5 个员工
- 收集他们过去一个月的典型工作交付物
- 脱敏后作为"标准答案”
- 用同样的输入让 Agent 做一遍，对比差异
优点： 最贴近真实场景，评测结果最有参考价值。
成本： 高，需要岗位专家配合标注。
路径二：用 LLM 生成模拟任务（快速启动）
# 用 GPT-4/Claude 生成特定岗位的模拟评测数据
# generated by hugo's coding agent
prompt = """
你是一个有 10 年经验的电商运营总监。
请生成 5 个电商运营日常工作的评测场景，每个场景需要包括：
1. 任务背景描述
2. 提供给 Agent 的输入数据（模拟真实数据格式）
3. 期望的输出格式和内容
4. 评分标准（列出各维度及权重）
要求：
- 场景要覆盖数据分析、商品管理、营销推广、客户运营四个方向
- 难度分为简单/中等/困难三个级别
- 输入数据要足够具体，不能是笼统描述
"""
优点： 速度快，成本低，一天内可以搭建初版评测集。
缺点： 可能与真实场景有偏差，需要岗位专家 review。
路径三：众包 + 专家审核（规模化）
众包标注 → 专家审核 → 一致性检验 → 入库
适合需要大规模评测集的场景。众包解决数据量问题，专家审核解决质量问题，一致性检验（Kappa 系数 > 0.7）解决标注一致性问题。
五、评测的反模式：这些坑不要踩
在实践中，我见过太多评测做砸了的案例。总结几个典型反模式：
反模式一：“准确率焦虑症”
只盯着准确率一个数字，忽略了其他维度。一个准确率 95% 但每次回答都需要 30 秒的客服 Agent，不如一个准确率 88% 但 3 秒内回答的。响应速度、输出格式、交互体验，都是评测维度。
反模式二：“实验室环境自嗨”
在干净数据上测得很好，一遇到真实世界的脏数据就翻车。评测数据必须包含：
- 模糊输入（“帮我看看那个数据”）
- 错误输入（数据格式错误、信息矛盾）
- 对抗输入（用户故意试探边界）
- 多轮上下文切换（中途换话题再换回来）
反模式三：“一次评测定终身”
Agent 是动态系统——模型升级、Prompt 调整、知识库更新都会影响表现。评测应该是持续集成的一部分，不是一次性的验收。
每次发布 → 自动回归测试 → 核心指标对比 → 异常告警
反模式四：“自己评自己”
用 LLM 评判 LLM 的输出（LLM-as-Judge）很方便，但要注意偏差。最可靠的方案是：
评判方式 适用场景 可信度
──────────────────────────────────────────
人类专家评判 高风险决策 ★★★★★
人类 + LLM 混合 大规模评测 ★★★★
LLM 交叉评判 快速迭代 ★★★
单一 LLM 评判 内部 A/B 测试 ★★
六、一个可执行的落地路线
如果你明天就要开始做 Agent 评测，建议按这个顺序来：
第 1 周：定义岗位任务清单
- 找到目标岗位的 3 个核心任务
- 每个任务准备 5 个评测用例（1 简单 + 2 中等 + 2 困难）
- 用路径二（LLM 生成）快速产出初版
第 2 周：跑第一轮评测
- 让 Agent 跑一遍所有用例
- 请岗位专家打分（1-5 分）
- 记录所有"Agent 不及格"的用例，分析原因
第 3 周：迭代评测集 + 修复 Agent
- 根据评测结果优化 Agent（Prompt、工具、知识库）
- 根据专家反馈修正评测标准
- 补充路径一（真实数据）的评测用例
第 4 周：建立持续评测流水线
- 自动化评测脚本
- 核心指标看板
- 每次发版自动回归
总结
Agent 评测不是一道选择题——“好不好用"不能用一个分数来回答。它是一道论述题，答案因行业而异、因岗位而异、因任务而异。
三条核心原则：
- 分层评测： 通用能力是地基，行业知识是框架，岗位任务是装修。三层都要测，不能只看地基。
- 以岗位任务为锚点： 评测的终极标准不是"Agent 的能力有多强”，而是"这个岗位的活，Agent 干到什么水平"。
- 持续迭代： 评测体系和 Agent 一样，需要不断进化。今天的评测维度，三个月后可能需要重新设计。
最后一句话：如果你的 Agent 评测报告里没有出现任何一个具体岗位的名字，那这份报告大概率是给投资人看的，不是给用户看的。