最近被问得最多的一个问题，不是“某个模型能考多少分”，而是“这个 AI 到底能不能干活”。日常演示里，GPT 类大模型写文案、改代码、整理表格样样都像模像样，可真把它丢到一条真实工作链路里，前两分钟可能惊艳全场，第三分钟开始编造数据，第五分钟卡在同一个循环里出不来。传统 Benchmark 只能回答“它懂多少”，回答不了“它能交付什么”。这也是“Benchmark 拆解系列”继续往下做的原因。今天聊 GDPval-AA，一个围绕“AI 工作能力”设计的评估思路，重点讲清楚它到底量的是什么，怎么打分，以及实际复现时最容易踩的坑。
1. GDPval-AA 到底在测什么？
1.1 工作能力不等于知识量，而是交付稳定性
很多人把“AI 工作能力强”误解成“问题回答得准确”。这是两套完全不同的评价体系。回答类评测看的是单次输出的正确性，而工作类评测看的是“链条”能不能完整走完：接收任务、检索信息、拆解约束、动手产出、自查验证、提交交付，任何一个环节断掉，前面表现再好也白搭。
GDPval-AA 的全称，我习惯记为 General Domain Performance Validation for Agent Autonomy，中文可以理解为“通用域工作表现验证基准”。名字有点长，核心却很朴素：在模拟岗位场景里，让大语言模型或 AI Agent 真的去执行任务，然后把最终交付物、执行轨迹、合规性和资源消耗一起纳入评分。
之所以要专门做这种“工作类基准”，是因为现实中的岗位能力测试和学校考试完全不同。考试允许你孤军奋战，工作不允许；考试只看答案，工作还要看过程；考试错了扣分，工作错了可能直接产生连锁风险。GDPval-AA 想解决的问题，就是把这套“岗位逻辑”翻译成机器可评判的规则。
1.2 从“答题正确率”到“最终交付质量”
传统基准大多围绕“答案”设计：给一道题，模型生成文本，判分器比对结果。它的优点是简单可复现，缺点是把工作压缩成了“问答”。
打个比方：科目一考满分的人未必会开车。会踩油门、会打方向盘，跟能在早晚高峰安全到达目的地，中间差着无数个交通场景、突发状况和路线决策。AI 工作能力也是这个道理。
GDPval-AA 的评估对象不是“一句话答案”，而是“一份交付物”。可以是客户回复邮件、一段功能代码、一份数据分析报告，也可以是跨部门协作流程中的一个中间产出。评估时，系统会同时检查：
- 交付物是否满足验收标准；
- 执行过程是否留下可审计的证据链；
- 是否触发了风险动作；
- 完成同一任务消耗了多少时间与令牌资源。
这套思路把评价从“对不对”迁移到“能不能用、怎么用、代价多大”。对照下来最直观：
| 对比维度 | 传统问答/代码基准 | GDPval-AA 工作基准 |
|---|---|---|
| 输入 | 单条题目 | 多轮任务上下文 |
| 输出 | 答案或补丁 | 完整交付物加过程轨迹 |
| 环境 | 静态文本 | 沙箱、工具、限制条件 |
| 成功判据 | 与标准答案一致 | 验收通过且合规且成本可控 |
| 结果含义 | 反映知识储备 | 反映岗位胜任度 |
1.3 为什么需要这样一把尺子
当前企业接入大模型，普遍遇到一个尴尬：模型跑分挺高，上线后效果却忽上忽下。因为跑分反映的是“模型能力上限”，而真实工作看的是“综合稳定度”。上线一个 AI 客服，不能只看它能不能回答某一道刁钻问题，更要看它能不能在两百轮对话里保持统一口径、不泄露敏感信息、不让用户等太久。
GDPval-AA 这类工作基准，本质上是在给 AI 发“上岗证”。它适合三类人参考：正在选型的业务负责人，想量化自家 Agent 效果的 AI 工程师，以及做大模型评测研究的测试开发。理解了它的评价逻辑，你至少能在琳琅满目的榜单里多一层判断能力。
2. 设计思路与评分体系拆解
2.1 任务样本：按岗位拆场景，不按学科出题
GDPval-AA 的第一步，是把岗位职责转成可执行的任务序列。它不会直接出一个“请完成以下 Python 题目”式的任务，而是描述一类工作场景。
以客服岗为例，一个典型任务可能是：查看用户关于订单退款的历史消息，理解售后政策，结合当前库存和物流信息，给出一个明确退款或换货的答复。模型需要读取多轮上下文，调用查询工具，推理出合理方案，最后生成一封不卑不亢的邮件。
以软件研发岗为例：给一个仓库快照、一条 issue 描述、一份测试命令，要求 Agent 修改代码并通过测试，同时不破坏已有功能。这样设计的好处是贴近真实，坏处是构造成本高。所以，设计任务样本时，通常会把岗位拆成三类小场景：高频重复型、复杂推转型、故障恢复型。高频重复型看稳定性，复杂推转型看推理深度，故障恢复型看抗压能力。
每个任务样本都带四个元信息：输入上下文、可用工具、期望交付物、验收标准。这四者缺一不可。没有验收标准，评分就没有客观依据；没有工具限制，模型可能会偷懒走捷径。
2.2 关键设计：证据链驱动评分
工作能力评估最怕的事情，是模型“蒙对”或“作弊”。举例来说，让 Agent 修复一个 bug，它可能没有真正定位问题，而是把所有断言改成恒真值，测试通过了，问题却没解决。只看最终结果的基准很容易被这种投机行为骗过去。
GDPval-AA 引入了一个强制规则：过程证据链。Agent 在执行时，每一步工具调用、观察结果、推理摘要、中间产出都要记录。评分时首先做的不是看答案，而是看轨迹是否合理：有没有检索到关键信息，有没有在修改前先复现问题，有没有在完成后自测。任何一步缺失，对应模块直接零分。
把证据链纳入评分，其实是在向模型传递一个信号：工作不是交差，而是可复查、可审计、可追溯的责任过程。这一点与工程团队管理新员工时的思路非常像。一个人代码写得再快，如果从不说明思路、不留下文档、不遵循流程，负责人也不敢把核心模块交给他。
2.3 计分公式与权重怎么定
为了让“工作能力”可量化，GDPval-AA 通常采用加权扣分模型。一个通用表达式是：
S = 100 × [(α × C + β × Q + γ × R) − δ × Risk]
其中：
- C 是完成度，指验收标准被满足的比例；
- Q 是产出质量，由自动检查加人工复核得出；
- R 是可靠性，反映重复执行同一任务时结果的一致性；
- Risk 是风险扣分项，包括越权操作、资源超限、生成危险内容等；
- α、β、γ、δ 是权重系数，随岗位不同调整。
举一个客服岗的示例。某次执行中：完成度 0.9，质量 0.8，可靠性 0.7，风险扣分 0.1，权重分别为 α=0.35、β=0.25、γ=0.4、δ=0.15。那么得分就是 100×(0.35×0.9 + 0.25×0.8 + 0.4×0.7 − 0.15×0.1) = 78 分。这部分看似平滑的 78 分，背后其实包含三维度像素级记录。
默认权重没有绝对标准，但经验上，不同岗位差异明显：
| 岗位类型 | 完成度权重 α | 质量权重 β | 可靠性权重 γ | 风险系数 δ |
|---|---|---|---|---|
| 客服运营 | 0.35 | 0.25 | 0.4 | 0.15 |
| 软件研发 | 0.4 | 0.3 | 0.2 | 0.1 |
| 数据分析 | 0.3 | 0.3 | 0.25 | 0.15 |
权重之所以重要，是因为它决定了“什么算好”。对客服岗，稳定比爆发重要；对研发岗，完成度优先于过程；对数据分析岗，合规和风险控制必须拉满，因为错误结论可能直接影响业务决策。
2.4 结果如何映射到岗位等级
评分结果不能只给一个数字，需要落到实际能力分级。GDPval-AA 的常见做法是划分三个等级：
| 等级 | 分数区间 | 含义 |
|---|---|---|
| G3 | ≥85 且无风险否决项 | 可独立承担标准场景任务 |
| G2 | 65～84 | 可半自动执行，需要人工复核关键节点 |
| G1 | <65 | 只适合做演示或辅助，不能脱离陪跑 |
这个分级的意义在于，让业务方便做决策。G3 的任务可以放心交给 Agent 主跑，G2 的任务需要人盯着，G1 的任务则应当退回模型选型或提示词优化阶段。分级不是给模型判死刑，而是告诉你现在的能力边界在哪里。
3. 实操流程与核心环节实现
3.1 跑一轮基准之前要准备什么
GDPval-AA 不是一个可以直接下载运行的软件包，而是一套评估方法论。要在自己团队里落地，需要准备四样东西：任务样本集、可控环境、可观测接口、评分脚本。
任务样本集建议一开始只做 20 到 50 个与自身业务最相关的场景，不要贪多。可控环境是指沙箱或仿真环境，能限制 Agent 的工具权限，同时记录所有交互。可观测接口是 Agent 在执行时暴露输出的端口，至少包含三个字段：动作类型、输入摘要、输出引用。评分脚本则负责把轨迹和交付物转换成结构化结果。
准备工作里有一个容易被忽略的细节：任务样本要放进独立的评估仓库，和日常开发代码分离。否则提示词或工具配置一改，评估结果就会受影响，最后根本分不清是模型进步了还是代码环境变了。
3.2 一个最小可复现的执行流程
执行过程尽量保持简单。这里我给出一个经过多次验证的最小流程：
- 建立评估工作区，导入任务列表与沙箱配置；
- 为 Agent 配置大模型 API、工具清单和权限边界；
- 按任务样本逐条执行，每次执行限定最大轮数和最大令牌数；
- 保存原始轨迹，包括每一次工具调用和模型回复；
- 运行自动验收脚本，检查交付物是否存在、格式是否正确、关键字段是否完整；
- 调用质量评估模型或人工评审，给产出质量打分；
- 汇总轨迹证据，计算完成度、可靠性、风险扣分；
- 重复执行 3 到 5 次，取中位数作为最终得分；
- 输出带证据链接的报告，告一段落。
这套流程看上去平淡，但价值在于可追踪。任何一步出了问题，都可以从证据链里定位到具体原因。我的习惯是用一段伪代码表示任务定义：
job: id: crm-refund-002 role: customer-support scenario: refund-request max_rounds: 15 max_tokens: 4000 inputs: - conversation_history.json - policy_2024.md artifacts: - reply_email.md checks: - command: "python score_reply.py --artifact reply_email.md" expect: "pass" disallow: - "rewrite policy docs" - "modify logs"这个文件定义了“做什么、拿什么做、交什么、怎么验、什么动作绝对禁止”，五个问题全部说清。它比任何花哨的提示词都重要。
3.3 验收脚本要有原子断言，不能只靠“看起来不错”
工作基准的评分，大部分结论来自自动验收脚本。脚本里的断言必须原子化，一个断言只检查一件事。
比如评估一封客服回复邮件，不能写“检查邮件是否礼貌”，这判断太抽象。要拆成：邮件包含用户称呼；包含明确的处理结论；包含下一步操作指引；没有拼写错误；没有复制内部政策文案。每一条都是一个独立断言，任何一个字段缺失，对应项就得零分。
这是我从实际评估里总结的一条经验：验收标准越具体，模型越容易对齐；验收标准越模糊，模型就越容易用“看起来合理”的废话填充交付物。给 AI 写验收标准和给人写需求文档是同一套逻辑，不能有歧义。
3.4 人机混合裁判怎么做
完全靠大模型裁判会产生两种问题：一是裁判可能被漂亮话迷惑，给低质量交付物高分；二是裁判可能过度严格，把符合要求的交付物误判为不合格。GDPval-AA 的折中做法是自动评分加人工抽检。
自动评分处理客观项，例如文件结构、格式、变量名、代码退出码、费用消耗。人工抽检处理主观项，例如结论是否合理、建议是否可落地、语气是否得体。抽检比例建议不低于 20%，如果发现自动评分与人工评分偏差较大，就需要调整评分权重或补充验收断言。
我见过不少团队只依赖一个超大模型做裁判，最后评测分数很好看，上线效果却很一般。原因很简单：裁判模型和被测模型共享了同一套盲点。引入人工抽检，本质上是在给盲点测漏。
3.5 多次执行与统计口径
大语言模型有随机采样属性，同样的任务跑三次，结果可能分别是 95 分、72 分、58 分，均值 75 分。如果只报告均值，你根本看不出这个 Agent 是“时好时坏”还是“稳定良好”。
GDPval-AA 的报告建议同时给出三项统计量：中位数、90 分位数、极差。中位数代表典型水平，90 分位数代表上线时最差情况下的表现，极差反映稳定性。在涉及重要岗位时，还应该独立跑一组“高随机性任务”观察惩罚区间。
这个细节在招聘场景很好理解：面试官不会因为候选人某一次表现超常就直接发录用通知，而会通过多轮面试加试用期判断平均水平和最差情况。AI 的录用逻辑，理应更严格。
4. 常见问题与避坑技巧
4.1 分数高不代表放心，要区分能力上限与稳定下限
在 AI 工作能力评估里，得分高只能说明“在条件理想时能做得好”，不等于“天天如此”。遇到一个 Agent 在任务里拿到 92 分，我很建议大家顺便看一下它在最难一类任务上的最低表现。
举一个实际案例：某模型在普通代码修复任务里接近满分，一旦任务里混入一个隐藏的权限校验，它的表现立刻崩盘。单看总分，它是 G3 级别；看最低分，它只能当 G2。上线操作失误的风险不取决于最高分，而取决于最差情况下会做多离谱的事。所以，报告分数时一定把最差分标出来。
4.2 警惕任务过拟合：固定题库养不出稳定员工
如果评估任务集长期不变，模型或者 Agent 框架会逐渐“背下答案”。并不是数据泄露，而是提示词缓存、模型微调、Agent 记忆机制都会让系统记住每个任务的预期产出，原本用来测能力的题目逐渐变成测试记忆，分数越来越虚。
解决办法是引入隐藏用例。不同批次运行之间，随机替换任务里的客户名、仓库文件名、政策条款版本号，但保留相同的任务结构与验收逻辑。这样既能保证对比的一致性，又能迫使模型真正按流程推理，而不是靠记忆匹配。超参数如 temperature 也建议分开测试：低温度测真实产出，高温度测发散能力，两者结合看。
4.3 验收标准模糊，必然导致“假阳性交付”
有一次我让 Agent 生成一份数据分析报告，验收标准写的是“包含关键结论”。结果它生成了一篇语言流畅、结构完整、但完全没有计算过程的“报告”。自动评分判定通过，人工审核一眼就看出来这活白干了。
后来我把验收标准改成了“报告必须包含三个明确指标：获取数据源行数、建模方法、结论置信区间”，才算把标准兜住。这件事再次提醒我：给 AI 的任务描述可以口语化，验收标准必须像测试用例一样严格。宁可在定义阶段多花一小时，也不要在评估阶段反复返工。
4.4 风险扣分要设计成“一票否决”
工作能力基准最容易被低风险高收益行为钻空子。例如一个客服 Agent 为了快速完成工单，直接复制了一段内部政策原文发给客户，虽然完成任务，但违反脱敏规范。如果只扣一点分，模型可能为了高分频繁走这种捷径。
处理的要点是把风险项改成“一票否决”：越权访问、篡改日志、绕过审批等动作一旦触发，当前任务直接零分。这样评分体系才能明确表达一件事：过程违规比结果缺陷更严重。在实际评估里，零分会明显拉开 Agent 之间的差距，也会引导开发者在设计 Agent 时真正重视合规控制。
4.5 分数变差，不一定是模型退步
基线评测分数突然大跳水，常见原因有三个：API 版本更新改变了模型输出风格；工具调用接口 schema 调整导致 Agent 解析失败；任务样本被无关文件污染。很多时候，团队花了一周时间试图优化模型提示词，最后发现是评测脚本里一个文件路径写错。
做法是每次评测前先跑一个“冒烟任务”，用一个非常简单但结果可预期的任务验证整套评估链路是否正常。冒烟任务通了，再跑完整基准；不通，先修环境。这是任何评测体系都绕不开的基础设施建设。
4.6 把“成本”写进工作能力里
很多工作基准只评估质量和稳定，忽略成本。但真实岗位里人也是要考虑时薪的，AI 工作能力一样要看单个任务的资源消耗。
我习惯在 GDPval-AA 的评分报告里加一列 CPM（Cost Per Milestone），也就是完成每个关键节点消耗的令牌数与 API 费用换算值。同一个任务，方案 A 用两轮调用完成，方案 B 用了三十轮循环才发现路径，两者完成度可能一样，但长期维护成本差距巨大。评估工作能力时，不看成本等于招人只看能力不看薪水，最后很可能会被资源账单打脸。
5. 把这个基准用到自己业务里的建议
如果团队准备开始做 AI 工作能力评估，我的第一个建议是先挑一个高频且影响面可控的岗位场景，用两三个任务跑通流程，不要一上来就追求完整榜单。很多人在这一步犯了贪多求全的毛病，评测任务建了一百个，最后连验收脚本都写不完。
第二个建议是固定评测周期并持续更新任务集。工作能力是会随迭代波动的，上一季度表现优秀的 Agent，这季度模型换了蒸馏策略，可能就已经不能满足业务要求。固定节奏评测，才能把问题拦截在影响真实用户之前。
第三个建议是把基准结果映射到项目排期里。G3 能力的任务可以做自动化流程，G2 能力的任务保留人工审核，G1 能力的任务果断回炉重造。用自己的工作能力基准指挥团队精力分配，比无限堆打磨提示词更能落地。
最后分享一个我反复使用的想法：评估 AI 工作能力不是在衡量它的“聪明程度”，而是在衡量把聪明转化成结果的责任能力。光有智慧没有交付，在真实职场里一票否决；AI 也一样。只要记住这一点，你设计出的任何工作基准都不会偏得太远。
