工程化 Agent 的评测和评测一个普通函数、一个 Web 服务甚至和一个纯 Prompt 的聊天机器人完全不是一回事。函数看输入输出就行Web 服务看 QPS 和错误率就行聊天机器人看回复质量就行——但 Agent 是一个会自己规划、自己调工具、自己多轮迭代、自己决定什么时候停下来的系统。它的失败模式极其分散可能是规划错了可能是工具选错了可能是参数填错了可能是循环停不下来也可能是前面都对但最后一步汇总时把答案写歪了。所以当我第一次认真思考“怎么给一个工程化 Agent 做评测”这个问题时我意识到单点指标根本不够用必须有一套端到端、可复现、能定位到具体环节的评测流程。这篇文章要聊的就是围绕羲和 XiheAgent 这个工程化 Agent怎么用 GAIA 这套基准做一次完整的全流程评测实践。我会把评测目标怎么定、GAIA 为什么适合、环境怎么搭、跑批怎么设计、结果怎么拆解、失败样本怎么归因、以及踩过的那些坑全部摊开讲。适合正在做 Agent 开发、准备给自家 Agent 做质量把关、或者想搞清楚“评测一个 Agent 到底要评什么”的工程师和产品同学。读完你至少能拿到一套可以直接抄作业的评测骨架而不是停留在“跑个分就完事”的层面。1. 先想清楚工程化 Agent 的评测到底在评什么很多人一上来就问“你的 Agent 在 GAIA 上多少分”这个问题本身没错但如果只盯着一个总分评测的价值会被浪费掉一大半。工程化 Agent 和 Demo 级 Agent 最大的区别在于它要在一个相对稳定的系统里长期运行要面对真实用户的多样输入要在成本和效果之间做权衡。所以评测的目标不是拿一个漂亮数字而是回答几个具体问题它在哪类任务上强、哪类任务上弱、失败是出在哪个环节、改一个模块之后整体是变好还是变坏。1.1 从“单点能力”到“端到端任务完成率”的视角切换传统评测习惯拆成单点能力意图识别准确率、工具调用准确率、检索召回率。这些指标当然有用但它们有个致命问题——单点都对串起来不一定对。我见过太多案例意图识别 95%工具选择 92%参数填充 90%看起来每个环节都不错但端到端任务完成率只有 40% 出头。为什么因为误差会累积而且 Agent 的多轮特性会让一次小错误被放大成整条轨迹的崩溃。所以工程化 Agent 评测的第一原则是以端到端任务完成率为主指标单点指标为辅用来做归因而不是做结论。GAIA 恰好就是端到端导向的基准它给的是真实感很强的复合任务要求 Agent 自己规划、自己找信息、自己综合出最终答案。这正好对应工程化 Agent 最需要证明的能力。1.2 评测目标要落到“可归因”而不是“可炫耀”我在设计这次评测时给自己定了一个硬性要求任何一个失败样本我都要能回答“它是在哪一步开始错的”。如果评测只能告诉我“这个任务失败了”那这次评测的工程价值就很有限。为了做到可归因我在 XiheAgent 里加了完整的轨迹记录每一步的思考、每一次工具调用的入参和返回、每一轮的中间状态全部落盘。这样评测结束后我不只是看分数而是能拿着轨迹一条条复盘。提示如果你的 Agent 还没有结构化轨迹日志先别急着做大规模评测。没有轨迹评测就只是打分不是工程实践。1.3 成本、时延、稳定性必须和效果一起评工程化 Agent 不是实验室产物它要上线、要花钱、要扛并发。所以我在评测里同时采集了三类非效果指标单任务平均 token 消耗、单任务平均时延、以及连续跑批时的失败重试率。这三个指标经常被忽略但它们往往决定了一个 Agent 能不能真正落地。一个 GAIA 分数很高但每个任务烧掉几十万 token 的 Agent在生产环境里是要被砍掉的。2. 为什么选 GAIA 作为这次评测的主基准选基准这件事很多人是跟风选的别人用 GAIA 我也用 GAIA。但基准选错了评测结论会直接跑偏。我选 GAIA 是经过对比的下面说说理由也说说它的局限。2.1 GAIA 的任务形态和工程化 Agent 的真实负载高度吻合GAIA 的任务不是那种“给定一段文本回答问题”的简单 QA它更像真实用户丢过来的一句话需求比如“帮我查一下某个东西的某个属性然后和另一个东西对比给出结论”。这种任务天然需要多步规划、多工具协作、信息综合。它和工程化 Agent 面对的真实负载非常接近用户不会把任务拆好给你你得自己拆。对比一下常见的几类基准纯知识问答类基准主要考记忆和推理不考工具编排代码类基准考的是单点生成能力而 GAIA 考的是“把一堆能力串起来解决一个复合问题”。对工程化 Agent 来说最后这种才是最有参考价值的。2.2 GAIA 的分级设计让归因更有层次GAIA 按难度分了级别Level 1 相对直接Level 2 需要多步Level 3 更复杂。这个分级对评测特别友好因为它让我能看出 XiheAgent 的能力边界在哪是简单任务就掉链子还是简单任务稳、复杂任务崩。这两种情况的优化方向完全不同。前者说明基础能力有问题后者说明规划和长程一致性有问题。2.3 GAIA 的局限别把它当成唯一真理GAIA 也有明显局限。它的任务偏信息检索和综合对某些垂直领域比如强交互、强操作类任务覆盖不足它的答案判定有时依赖精确匹配对表述差异不够宽容它的任务数量有限跑一次全量成本不低。所以我的做法是GAIA 作为主基准定基调再补一套自建的领域任务集做补充验证。两者结合结论才稳。基准类型主要考察对工程化 Agent 的参考价值本次是否采用纯知识 QA记忆与推理低不涉及工具编排否代码生成单点生成中偏专项否GAIA端到端复合任务高贴近真实负载是主基准自建领域集垂直场景高补充覆盖是辅基准3. 评测环境搭建那些文档里不会写的细节环境搭建看起来是最没技术含量的部分但实际上它是整个评测里最容易翻车的地方。我前后搭了三遍才稳定下来这里把关键细节都讲清楚。3.1 XiheAgent 的可评测化改造XiheAgent 本身是一个工程化 Agent直接拿来跑评测会有几个问题它的日志格式不统一、它的工具调用没有统一埋点、它的停止条件不够明确。所以我先做了一轮“可评测化改造”核心是三件事。第一统一轨迹结构。我定义了一个标准的轨迹 schema每一步包含 step_id、thought、action、action_input、observation、timestamp。所有模块的输出都往这个结构里塞保证后面能统一解析。第二给工具调用加埋点。每次工具调用都记录工具名、入参、返回、耗时、是否成功。这样我才能统计工具层面的成功率并在失败时快速定位是不是工具的问题。第三明确停止条件并记录停止原因。Agent 停下来可能是因为任务完成、达到最大轮数、或者触发了某种保护机制。这三种情况的评测含义完全不同必须区分记录。{ task_id: gaia_l1_001, steps: [ { step_id: 1, thought: 需要先确认目标对象的属性, action: search, action_input: {query: ...}, observation: ..., timestamp: 1700000000 } ], stop_reason: task_completed, total_tokens: 12345, total_latency_ms: 45678 }3.2 评测执行器的设计并发、重试与隔离跑 GAIA 全量任务如果串行跑时间成本高到无法接受。所以我写了一个评测执行器支持并发跑批。但并发带来两个问题一是资源竞争导致时延数据失真二是某个任务卡死会拖垮整批。我的处理方式是并发度控制在资源允许的范围内并且给每个任务设置硬超时时延统计只取成功任务避免被超时任务污染每个任务在独立的执行上下文里跑避免状态串扰。重试策略上我只对“基础设施类失败”比如工具临时不可用做重试对“能力类失败”比如规划错了不重试因为重试也救不回来反而会掩盖真实问题。注意重试策略一定要区分失败类型。无差别重试会让你的评测分数虚高掩盖真实的能力短板。3.3 答案判定精确匹配之外的容错设计GAIA 的官方判定偏严格但实际跑下来很多失败样本其实是“答案对了但表述不同”。如果完全按精确匹配会低估 Agent 的真实能力。我的做法是分层判定先做归一化去空格、统一大小写、统一数字格式再做精确匹配不中的话用规则做等价判断比如“1,000”和“1000”视为相同最后对少量疑难样本做人工复核。这套判定逻辑我单独抽成了一个模块方便复用和调整。这里的关键是判定逻辑本身也要可评测不能是个黑盒。4. 跑批设计与指标采集让数据能说话环境搭好之后就进入正式的跑批阶段。这一步的核心不是“跑”而是“设计怎么跑”和“采集什么数据”。4.1 任务集划分与采样策略GAIA 全量任务不少全跑一遍成本高。我的策略是先做分层采样按难度级别和任务类型各抽一部分做快速迭代确认稳定后再跑全量。快速迭代阶段用 Level 1 和 Level 2 的样本因为这两级最能反映基础能力和多步规划能力Level 3 留到全量阶段重点看。采样时我特别注意了任务类型的均衡避免某一类任务占比过高导致结论偏斜。比如检索类、计算类、综合类任务我都保证有一定比例。4.2 核心指标定义与采集口径指标定义不清楚采集出来的数据就没法比。我把这次评测的指标分成三组每组都有明确口径。指标组具体指标采集口径效果指标任务完成率、分级完成率按判定模块结果统计分母为该级任务总数过程指标平均步数、工具调用成功率、规划有效率从轨迹日志解析工具成功以返回无异常为准成本指标平均 token、平均时延、重试率只统计成功任务重试率按失败类型分类这里要特别说“规划有效率”这个指标。它不是标准指标是我自己定义的如果 Agent 的第一步规划和任务目标方向一致就算规划有效。这个指标能帮我快速判断失败是出在规划阶段还是执行阶段。4.3 跑批过程中的监控与异常处理跑批不是启动了就完事中间要盯着。我主要监控三件事任务是否卡死、token 消耗是否异常飙升、工具调用失败率是否突增。有一次跑批时发现 token 消耗突然翻倍排查后发现是某个任务触发了 Agent 的循环一直在重复调用同一个工具。这种问题如果不监控跑完才发现就浪费了一整批时间。# 简化的跑批监控逻辑 def monitor_batch(running_tasks): for task in running_tasks: if task.elapsed_ms TASK_TIMEOUT_MS: task.abort(reasontimeout) if task.token_used TOKEN_ALERT_THRESHOLD: alert(ftask {task.id} token spike) if task.tool_fail_rate 0.5: alert(ftask {task.id} tool failure spike)5. 结果拆解从总分到可行动的结论跑完批拿到一堆数据这时候最容易犯的错就是只看总分。总分是结论的起点不是终点。我拆解结果时遵循一个原则每一层拆解都要能指向一个具体的优化动作。5.1 分级完成率揭示的能力边界先看分级完成率。如果 Level 1 完成率明显低于预期说明基础能力有问题优先查工具调用和答案汇总如果 Level 1 稳、Level 2 掉说明多步规划有问题如果 Level 2 稳、Level 3 崩说明长程一致性和复杂信息综合有问题。这次评测里XiheAgent 在 Level 1 表现稳定Level 2 有波动Level 3 明显吃力这个分布直接告诉我优化重点在长程规划。5.2 失败样本归因把失败拆到具体环节失败样本是评测里最有价值的部分。我把失败分成几类规划失败、工具选择失败、参数填充失败、信息综合失败、停止条件失败。每一类对应不同的修复方向。归因时我会逐条看轨迹标记出“第一个出错的步骤”因为后面的错误往往是连锁反应。失败类型典型表现修复方向规划失败第一步方向就偏了优化规划 Prompt 或规划器工具选择失败选错工具或漏选工具完善工具描述与选择逻辑参数填充失败工具选对了但参数错加强参数抽取与校验信息综合失败中间都对但结论错优化汇总环节停止条件失败该停不停或提前停调整停止判定逻辑5.3 成本与效果的权衡分析光看效果不够还要看成本。我做了个简单的权衡分析把任务按 token 消耗分档看每一档的完成率。结果发现高 token 消耗的任务完成率并没有显著更高说明存在“无效消耗”。进一步看轨迹发现部分任务在信息已经足够的情况下还在反复检索。这直接指向一个优化点加强“信息充分性判断”让 Agent 知道什么时候该停。6. 踩坑实录评测过程中真实翻过的车这部分是我最想写的因为文档里永远不会告诉你这些。6.1 轨迹日志格式不统一导致解析失败第一次跑批我兴冲冲地准备分析数据结果发现轨迹日志格式五花八门有的模块用 JSON有的用纯文本解析脚本直接崩了。后来我强制统一了 schema并且加了一层校验格式不对的直接报错而不是静默跳过。这个坑的教训是评测基础设施的健壮性比评测本身更重要。6.2 并发跑批时的资源竞争让时延数据失真前面提过并发跑批会让时延数据失真。我第一次跑的时候没注意统计出来的平均时延比实际高了一大截差点误判 Agent 的性能。后来我把时延统计改成只在低并发下采集高并发只用于功能验证。这个区分很重要不然你会拿着错误的数据做错误的决策。6.3 判定模块的“假阴性”差点让我误判 Agent 能力有一次评测完成率比预期低很多我差点以为 Agent 退化了。结果人工复核发现相当一部分“失败”其实是判定模块太严格把正确答案判成了错。修正判定逻辑后完成率回升了十几个百分点。这个坑告诉我判定模块本身也要被评测不能默认它是对的。6.4 工具临时不可用被误判为能力问题还有一次某个外部工具临时不稳定导致一批任务失败。如果我不看轨迹就会把这些失败归因到 Agent 能力上。后来我在归因流程里加了一步先排除基础设施类失败再做能力归因。这个顺序不能反。7. 从评测结论到优化动作的闭环评测的最终目的是驱动优化所以最后一环是把结论转成动作并且验证动作是否有效。7.1 优化项的优先级排序不是所有优化项都值得马上做。我按“影响面 × 修复成本”排序影响面大、修复成本低的先做。比如“信息充分性判断”这个优化影响面大减少无效消耗、成本可控就排在前面而“重写规划器”影响面也大但成本高排在后面。7.2 优化后的回归验证每做一个优化都要跑一次回归验证确认目标指标变好且没有引入新的退化。回归验证用的任务集要和基线一致否则没法比。我一般会保留一个固定的“回归集”专门用于验证优化效果。7.3 建立持续评测机制一次评测只能反映一个时间点的状态。工程化 Agent 是持续迭代的所以评测也要持续。我的做法是把评测执行器接入 CI每次重要改动后自动跑一遍回归集指标异常就报警。这样评测就从“一次性项目”变成了“常态化能力”。我在实际做这套评测的过程中最大的体会是评测一个工程化 Agent本质上是在给一个复杂系统建立可观测性。分数只是表象真正有价值的是你能透过分数看到系统内部发生了什么、哪里卡住了、改哪里最有效。羲和 XiheAgent 这次 GAIA 全流程实践让我把评测从“跑个分”升级成了“一套能持续用的工程能力”这个转变比任何单个指标都重要。如果你也在做类似的事建议先把轨迹和判定这两块基础设施打牢后面的路会顺很多。