工程化Agent评测实战：羲和XiheAgent在GAIA上的全流程解析

1. 为什么工程化 Agent 的评测和普通模型评测完全是两码事1.1 从“跑个分”到“跑完全流程”的认知转变很多人第一次接触 Agent 评测脑子里想的还是那套老思路准备一批测试集跑一遍算个准确率收工。我一开始也是这么想的直到真正把羲和 XiheAgent 放到 GAIA 上跑了一圈才发现事情远没有这么简单。普通模型评测本质上是一个单轮映射问题输入一段文本输出一段文本对比标准答案算分。整个过程是封闭的、确定的、可复现的。但 Agent 不一样。一个工程化的 Agent 在运行时会经历任务理解、规划拆解、工具调用、中间结果观察、错误重试、上下文管理、最终答案生成这一长串环节。任何一个环节出问题最终结果都会崩。更麻烦的是你很难判断到底是哪个环节崩的——是规划错了还是工具选错了还是工具返回的结果没被正确解析还是上下文太长把关键信息挤掉了这就是为什么我说Agent 评测的核心不是算分而是归因。你不仅要告诉别人“这个 Agent 在 GAIA 上得了多少分”还要能说清楚“它为什么得这个分”“它在哪类任务上强”“它在哪个环节容易翻车”。羲和 XiheAgent 的 GAIA 全流程实践恰恰就是围绕这个思路展开的。GAIA 这个基准本身也很有意思。它不是那种“给你一道选择题让你选 ABCD”的简单评测集而是一套需要多步推理、多工具协作、真实信息检索的任务集合。题目看起来往往很朴素比如“某个特定年份某部电影的导演的出生地现在的人口是多少”但你要回答它得先查到电影、再查到导演、再查到出生地、再查到人口数据中间任何一步查错或者推理错答案就偏了。这种设计天然适合评测 Agent因为它逼着 Agent 把“规划—执行—验证”这条链路完整走一遍。所以如果你是一个正在做 Agent 开发的工程师或者是一个需要选型 Agent 框架的技术负责人这篇文章就是写给你的。我会把羲和 XiheAgent 在 GAIA 上的整套评测流程拆开讲清楚包括设计思路、关键细节、实操步骤、踩过的坑以及那些文档里不会写的经验。你看完之后应该能直接把这套方法搬到自己手头的 Agent 项目上。1.2 GAIA 基准到底在考什么在展开评测流程之前有必要先把 GAIA 这个基准的脾气摸清楚。GAIA 的全称是 General AI Assistants benchmark它的设计哲学和传统的 NLP 评测集有本质区别。传统评测集考的是知识记忆和单步推理比如“法国的首都是哪里”“这段话的情感是正面还是负面”。GAIA 考的是任务完成能力它假设你是一个能上网、能调工具、能多步推理的助手然后给你一个真实世界里的复杂问题看你能不能把它解决掉。GAIA 的题目大致可以分成三个难度层级。第一层是“单步但需要工具”的任务比如查一个实时数据第二层是“多步且需要多个工具”的任务比如先搜索再计算再验证第三层是“多步且需要复杂规划”的任务中间可能涉及文件处理、代码执行、多源信息交叉验证。这三个层级对应的是 Agent 能力的三个台阶会用工具、会组合工具、会规划工具组合。这就意味着评测一个 Agent 在 GAIA 上的表现你不能只看最终准确率。你得看它在每一层上的通过率看它在多步任务中的中间步骤正确率看它在工具调用失败后的恢复能力。羲和 XiheAgent 的评测方案之所以值得讲就是因为它把这些维度都覆盖到了而不是只盯着一个总分。还有一个容易被忽略的点GAIA 的答案往往是唯一且精确的比如一个数字、一个日期、一个名字。这就要求 Agent 不仅要“大致答对”还要“精确答对”。这对工程化实现提出了很高的要求——你的工具返回结果要能精确解析你的推理链要能保持精度你的最终答案提取要能准确格式化。任何一个环节的模糊处理都会导致最终答案偏差。2. 羲和 XiheAgent 的评测架构是怎么搭起来的2.1 整体设计思路把评测当成一个 Agent 任务来做羲和 XiheAgent 的评测架构最核心的一个设计决策是不把评测当成一个外部脚本而是把评测本身也当成一个 Agent 任务来编排。这个思路听起来有点绕但实际操作下来非常香。传统的评测做法是写一个 Python 脚本循环读取测试集调用 Agent 接口拿回答案对比标准答案统计分数。这种做法的问题在于它把 Agent 当成一个黑盒只能看到输入和输出看不到中间过程。一旦某个任务失败你只能知道“它答错了”但不知道“它为什么答错”。羲和 XiheAgent 的做法是在 Agent 的执行链路里埋入可观测性钩子。每一次规划、每一次工具调用、每一次中间结果观察、每一次重试都会被记录下来形成一个结构化的执行轨迹。评测脚本不只是拿最终答案而是拿整条轨迹然后对轨迹做分析。这样一来你不仅能算总分还能算“规划准确率”“工具选择准确率”“中间步骤正确率”“重试成功率”这些细粒度指标。这个设计的好处是评测结果直接可以指导优化。比如你发现某个任务的失败原因是“工具选择错误”那你就去优化工具描述和选择逻辑如果失败原因是“中间结果解析错误”那你就去优化解析器。评测不再是终点而是优化的起点。2.2 评测环境的隔离与复现工程化 Agent 评测有一个绕不开的问题环境一致性。GAIA 的很多任务需要联网检索、需要调用外部工具、需要执行代码这些操作在不同环境下结果可能不一样。今天跑出来 80 分明天跑出来 75 分你都不知道是 Agent 变差了还是网络波动了。羲和 XiheAgent 在这块的处理方式是分层隔离。第一层是 Agent 本身的运行环境用容器化方式固定依赖版本和系统配置第二层是工具层对每个外部工具做接口封装并在封装层做缓存和重试第三层是评测数据层把 GAIA 的题目和标准答案固化下来避免评测过程中数据变动。这里有个细节值得说缓存策略。对于检索类工具同样的查询在短时间内返回的结果通常是一样的所以可以在工具封装层加一层短期缓存。这样既能保证评测的可复现性又能减少对外部服务的压力。但缓存的有效期要控制好太长会导致结果过时太短又起不到稳定作用。我的经验是对于 GAIA 这种评测场景缓存有效期设置在评测周期内即可评测结束后清空。另一个细节是随机种子的固定。Agent 在规划时如果用了带随机性的策略比如采样一定要固定随机种子否则同样的输入可能产生不同的执行轨迹评测结果就不可比了。羲和 XiheAgent 在评测模式下会强制固定所有随机源确保每次运行的可复现性。2.3 评测指标的设计不只看准确率前面说了羲和 XiheAgent 的评测不只看最终准确率。那它到底看哪些指标我整理了一个表把核心指标和它们的含义列出来。指标名称计算方式反映的能力优化方向最终准确率正确答案数 / 总题数整体任务完成能力全链路优化分层准确率各难度层正确答案数 / 该层题数不同复杂度下的能力针对性补强规划准确率规划步骤与标准步骤匹配数 / 总规划数任务拆解能力优化规划提示词工具选择准确率正确工具调用数 / 总工具调用数工具使用能力优化工具描述中间步骤正确率中间结果正确数 / 总中间步骤数执行精度优化解析和推理重试成功率重试后成功数 / 总重试数错误恢复能力优化重试策略平均步数总执行步数 / 总题数执行效率优化规划粒度平均耗时总耗时 / 总题数执行速度优化工具和推理这张表里的指标前四个是核心后四个是辅助。核心指标告诉你 Agent 行不行辅助指标告诉你 Agent 哪里可以更好。比如你发现最终准确率不错但平均步数很高说明 Agent 在做很多无效尝试效率有优化空间如果重试成功率很低说明错误恢复机制有问题需要重点排查。提示指标不是越多越好。刚开始做评测时建议先盯住最终准确率和分层准确率这两个把基线跑出来再逐步加入细粒度指标。一上来就搞十几个指标很容易被数据淹没反而找不到优化重点。3. GAIA 全流程评测的实操步骤3.1 评测前的准备工作在正式跑评测之前有几件事必须先做好否则跑到一半出问题会很麻烦。第一件事是确认 Agent 的工具集。GAIA 的任务需要哪些工具根据我的经验至少需要这几类网页检索、网页内容提取、代码执行、文件读写、计算器。羲和 XiheAgent 在评测前会先做一次工具自检确保每个工具都能正常调用返回格式符合预期。这个自检步骤看起来简单但能避免很多“跑了一半发现某个工具挂了”的尴尬。第二件事是准备评测数据集。GAIA 的官方数据集包含题目、标准答案和难度标注。你需要把它转换成 Agent 能理解的输入格式。羲和 XiheAgent 的做法是把每道题包装成一个任务描述包含问题文本、可用工具列表、输出格式要求。这里有个细节输出格式要求一定要明确。GAIA 的答案往往是精确的字符串或数字如果 Agent 输出“大约是 100 万”而标准答案是“1000000”那就算错了。所以在任务描述里要明确告诉 Agent“只输出最终答案不要解释不要单位不要千分位”。第三件事是配置评测参数。包括最大步数限制、单步超时时间、总超时时间、重试次数上限。这些参数直接影响评测结果。最大步数设太小复杂任务做不完设太大简单任务浪费资源。我的经验是GAIA 第一层任务设 10 步上限第二层设 20 步第三层设 30 步基本能覆盖大部分情况。单步超时设 60 秒总超时设 10 分钟重试次数设 2 次这套参数在实测中比较稳。3.2 单任务执行流程拆解一个 GAIA 任务在羲和 XiheAgent 里的完整执行流程大致可以分成六个阶段。我把每个阶段的关键动作和注意事项列出来。阶段一任务理解。Agent 读取任务描述提取核心问题、约束条件、输出格式要求。这个阶段的关键是不要过度解读。有些 Agent 会在这里做很多额外的推理结果把简单问题复杂化了。羲和 XiheAgent 的做法是任务理解阶段只做信息提取不做推理推理留给规划阶段。阶段二规划拆解。Agent 根据任务描述生成一个执行计划把大问题拆成若干子问题并标注每个子问题需要用什么工具。这个阶段是 Agent 能力的核心体现。规划得好后面执行就顺规划得差后面就是一团乱麻。羲和 XiheAgent 在规划阶段会生成一个结构化的计划每个步骤包含“目标”“工具”“预期输出”三个字段。阶段三逐步执行。Agent 按照计划逐步执行每一步调用相应工具拿到结果后判断是否满足预期。如果满足进入下一步如果不满足触发重试或重新规划。这个阶段的关键是中间结果的验证。不能工具返回什么就信什么要做基本的合理性检查。比如检索返回的结果是否包含关键词代码执行是否报错计算结果是否在合理范围内。阶段四中间结果整合。当所有子问题都解决后Agent 需要把中间结果整合成最终答案。这个阶段容易出问题的地方是信息丢失。如果中间结果很多上下文很长关键信息可能被挤掉。羲和 XiheAgent 的做法是在整合阶段显式地把所有中间结果列出来然后逐步推导最终答案而不是让模型自己去“回忆”。阶段五答案格式化。根据任务描述里的输出格式要求把最终答案格式化成指定形式。这个阶段看起来简单但实际很容易出错。比如要求输出数字Agent 输出了带单位的字符串要求输出名字Agent 输出了带解释的句子。羲和 XiheAgent 在格式化阶段会做一次严格的格式校验不符合就重新格式化。阶段六结果记录。把最终答案、执行轨迹、各阶段耗时、工具调用次数等信息记录下来供后续分析。这个阶段是评测的基础记录得越详细后续分析越有依据。3.3 批量评测与结果统计单任务跑通之后就可以做批量评测了。批量评测的核心是并发控制和结果聚合。并发控制方面不能无限制地并发否则外部工具会被打爆反而影响评测稳定性。羲和 XiheAgent 的做法是设置一个并发池池的大小根据工具的实际承载能力来定。检索类工具并发可以高一些代码执行类工具并发要低一些因为代码执行通常更耗资源。我的经验是检索类并发设 5 到 10代码执行类并发设 2 到 3整体评测速度和质量比较平衡。结果聚合方面除了前面说的那些指标还要做失败归因分析。把所有失败的任务拿出来按失败原因分类是规划错误、工具选择错误、中间结果解析错误、还是最终答案格式错误。这个分类统计能直接告诉你 Agent 的短板在哪里。羲和 XiheAgent 的评测报告里失败归因分析是单独一个章节占比很重。还有一个实用技巧保存所有执行轨迹。不要只保存最终答案要把每个任务的完整执行轨迹保存下来。这样当你想深入分析某个失败案例时可以直接回放轨迹看每一步到底发生了什么。这个习惯在调试阶段特别有用我靠回放轨迹定位过好几个隐蔽的 bug。4. 评测中常见的坑和排查方法4.1 工具调用层面的典型问题工具调用是 Agent 评测中最容易出问题的环节。我整理了几类常见问题和对应的排查方法。问题一工具选择错误。Agent 面对一个子任务选了一个不合适的工具。比如该用检索的时候用了计算器该用代码执行的时候用了检索。这种问题的根源通常是工具描述不够清晰。Agent 是根据工具描述来判断用哪个工具的如果描述模糊Agent 就容易选错。解决办法是优化工具描述把每个工具的适用场景、输入格式、输出格式写清楚最好配上示例。问题二工具参数错误。Agent 选对了工具但传的参数不对。比如检索时关键词太宽泛代码执行时语法错误。这种问题的根源通常是参数生成逻辑不够健壮。解决办法是在工具封装层加参数校验参数不合法时返回明确的错误信息让 Agent 知道怎么改。问题三工具返回结果解析错误。工具返回了正确结果但 Agent 解析错了。比如检索返回了一段文本Agent 从中提取了错误的信息。这种问题的根源通常是解析逻辑太脆弱。解决办法是让工具返回结构化数据而不是纯文本减少解析歧义。问题四工具超时或失败。外部工具不稳定调用超时或返回错误。这种问题的根源是外部依赖不可控。解决办法是加重试机制和降级策略。重试时可以考虑换一个等价的工具或者调整参数再试。4.2 推理链路层面的典型问题推理链路层面的问题比工具调用层面更隐蔽也更难排查。问题一规划粒度过粗或过细。规划太粗一个步骤包含太多子任务执行时容易乱规划太细步骤太多执行效率低而且中间任何一步出错都会影响全局。这个度很难把握需要根据任务复杂度动态调整。羲和 XiheAgent 的做法是先按中等粒度规划执行过程中如果发现某一步太复杂再动态拆解。问题二中间结果丢失。多步任务中前面的中间结果在后续步骤中被遗忘了。这种问题在上下文很长时特别容易出现。解决办法是显式地维护一个“中间结果清单”每一步执行前都把相关中间结果注入上下文而不是依赖模型的记忆。问题三错误传播。某一步出了错但 Agent 没有发现继续往下执行导致最终答案错误。这种问题的根源是缺乏中间验证。解决办法是在每个关键步骤后加验证逻辑验证不通过就触发重试或重新规划。问题四死循环。Agent 在某个步骤反复重试始终不成功也不放弃。这种问题的根源是缺乏退出机制。解决办法是设置重试次数上限超过上限就标记任务失败进入下一个任务。4.3 评测结果层面的典型问题评测结果层面也会出问题而且往往更让人头疼因为这时候你已经跑完评测了发现问题意味着要重跑。问题一结果不可复现。同样的 Agent同样的数据集两次评测结果不一样。这种问题的根源通常是随机性没有控制好。检查所有随机源包括模型采样的温度参数、工具调用的随机性、并发调度的顺序等全部固定下来。问题二评测集泄露。Agent 在评测前见过评测集的题目或答案。这种问题在工程化评测中很隐蔽但影响很大。解决办法是严格隔离评测集和训练数据评测集只在评测时加载评测完立即卸载。问题三指标计算错误。评测脚本本身有 bug导致指标算错了。这种问题最坑因为它会让你基于错误的数据做优化决策。解决办法是对评测脚本做单元测试用已知答案的小数据集验证指标计算逻辑。问题四环境漂移。评测跑了一段时间后环境发生了变化导致结果不可比。比如某个外部工具的接口变了或者某个依赖库升级了。解决办法是固定环境版本评测期间不做任何环境变更。注意排查问题时一定要先复现再定位后修复。不要看到问题就急着改代码先想办法稳定复现问题然后通过日志和轨迹定位根因最后才动手修复。跳过复现和定位直接改代码很容易改出新问题。5. 从评测结果到优化动作的转化5.1 如何读懂评测报告跑完评测拿到报告接下来最重要的事情是读懂报告。一份好的评测报告不只是数字的堆砌而是能告诉你“哪里好、哪里差、为什么差、怎么改”。羲和 XiheAgent 的评测报告通常包含这几个部分总体指标概览、分层指标对比、失败归因分析、典型失败案例、优化建议。看报告时我的习惯是先看总体指标建立整体印象再看分层指标找出能力短板然后看失败归因定位问题环节最后看典型失败案例理解具体场景。这里有个经验不要只看平均值。平均值会掩盖很多问题。比如总体准确率 70%看起来还行但如果第一层准确率 95%、第三层准确率 20%那说明 Agent 在复杂任务上能力严重不足。分层看指标才能发现这种结构性问题。5.2 针对性的优化策略根据评测结果优化动作可以分成几个层次。提示词层优化。如果失败归因显示规划错误占比高那优先优化规划提示词。把规划的要求写得更明确给出更多示例约束规划的粒度和格式。提示词优化见效快成本低应该优先做。工具层优化。如果失败归因显示工具选择错误或参数错误占比高那优先优化工具描述和参数校验。把工具描述写得更清晰加上适用场景和示例在工具封装层加参数校验参数不合法时返回明确的错误提示。架构层优化。如果失败归因显示中间结果丢失或错误传播占比高那可能需要调整 Agent 的架构。比如引入显式的中间结果管理加入中间验证环节调整上下文管理策略。架构层优化见效慢但影响深远。数据层优化。如果发现某些类型的任务普遍表现差可以考虑针对性地补充训练数据或示例。比如多步推理任务差就多给一些多步推理的示例文件处理任务差就多给一些文件处理的示例。5.3 迭代评测的节奏把控优化不是一次性的而是一个迭代过程。每做一轮优化就要重新跑一次评测看指标有没有提升。但迭代节奏要把握好不能太频繁也不能太稀疏。太频繁的问题是你还没改完就急着看结果数据噪声大看不出真实效果。太稀疏的问题是你改了很多东西才评测一次出了问题不知道是哪个改动导致的。我的经验是每完成一个独立的优化动作就跑一次小规模评测比如抽 20% 的题目快速验证效果每完成一轮完整的优化就跑一次全量评测看整体指标变化。还有一点很重要保留历史评测结果。每次评测的结果都存档这样你可以对比不同版本的 Agent 表现看优化是否真的有效。羲和 XiheAgent 的评测系统会自动存档每次评测的结果并生成趋势图方便追踪优化效果。6. 一些实操心得和避坑建议6.1 评测环境搭建的心得搭建评测环境时我的第一条建议是先跑通单任务再跑批量。不要一上来就搞全量评测先拿一道题跑通确认 Agent 能正常执行、工具能正常调用、结果能正常记录然后再扩展到批量。这样出问题时排查范围小定位快。第二条建议是日志要详细。Agent 执行过程中的每一步都要打日志包括输入、输出、耗时、状态。日志级别可以分 DEBUG 和 INFO评测时开 DEBUG平时开 INFO。日志详细了出问题时才有据可查。第三条建议是评测脚本要幂等。同样的输入跑多少次结果都应该一样。这要求你控制好所有随机源固定好所有环境变量处理好所有外部依赖。幂等性看起来是基本要求但实际做起来很容易忽略细节。6.2 评测过程中的经验教训评测过程中我踩过几个印象比较深的坑分享出来供参考。第一个坑是工具缓存导致结果过时。有一次评测某个检索类工具的结果被缓存了后续任务复用了缓存结果导致答案错误。后来调整了缓存策略对时效性敏感的工具禁用缓存问题才解决。第二个坑是并发过高导致工具限流。有一次为了加快评测速度把并发调得很高结果外部工具触发限流大量任务失败。后来把并发降下来加了退避重试才稳定下来。第三个坑是答案格式校验太严格。有一次评测Agent 的答案在语义上是对的但格式上差了一个空格被判定为错误。后来调整了校验逻辑对答案做标准化处理去空格、统一大小写、统一数字格式再对比准确率提升了不少。第四个坑是评测集泄露。有一次不小心把评测集的题目混进了 Agent 的示例库导致 Agent 在评测时“见过”这些题准确率虚高。后来严格隔离了评测集和示例库问题才解决。6.3 持续优化的建议Agent 评测不是一次性工作而是持续优化的过程。我的建议是建立一套评测驱动的优化闭环评测发现问题分析定位原因优化解决问题再评测验证效果。这个闭环转起来Agent 的能力就会持续提升。闭环的关键是快速反馈。从发现问题到验证效果周期越短越好。所以评测要尽量自动化从数据加载、任务执行、结果统计到报告生成全流程自动化减少人工干预。羲和 XiheAgent 的评测系统就是全自动化的跑一次全量评测大概几个小时跑一次小规模评测几十分钟反馈速度可以接受。最后再分享一个小技巧建立失败案例库。把每次评测中失败的案例收集起来分类整理形成一个案例库。这个案例库不仅是优化的依据也是回归测试的素材。每次优化后除了跑标准评测集还可以跑一遍失败案例库看之前失败的案例有没有被修复。这个习惯能帮你避免“优化了一个问题引入了另一个问题”的情况。这个内容后续还可以这样扩展把评测从 GAIA 扩展到其他基准比如需要多轮对话的任务、需要长上下文的任务、需要多 Agent 协作的任务。不同基准考的能力不同组合起来能更全面地评估 Agent 的能力边界。另外评测的自动化程度还可以再提升比如加入自动归因分析让系统自动定位失败原因并给出优化建议进一步缩短优化闭环的周期。