1. 为什么是“Reach”Agent评测缺的不只是一个分数做AI Agent相关应用的开发者大概率都经历过这样一段模糊期Agent看起来“挺聪明”能理解任务会调用工具多轮对话也有来有回但一旦要回答“它到底行不行”大家都只能支支吾吾。我去年搭建一套内部智能体应用时就卡在这个问题上。不是不知道要测而是没有一个合适的维度去测。最终结果能不能跑通只是最粗的一个信号真正让我头疼的是一个任务失败了我根本说不清楚是模型理解错了是工具调用错了还是中间某一步链路断了。那段时期我做了大量“感觉型评测”——换个模型试一下觉得效果好一点改一版提示词觉得更听话了。但这类反馈没法沉淀成可复用的结论换个任务场景一切归零。所以我后来动手做了一个叫Agent-Reach的评测脚本专门用来回答一个问题给定一条任务链路和一个智能体它能从初始状态出发成功触达多少个关键节点1.1 只盯最终结果是不够的大多数团队评测Agent习惯看“完成率”也就是最终目标有没有实现。这个指标最容易统计但也是最迟钝的指标。打个比方你让一个智能体去处理一笔异常订单链路包含读取订单号、查客户信息、核对库存、生成处理建议、更新订单状态。如果最终状态没更新成功完成率就是0可是这0背后可能是五种完全不同的原因——可能订单号读错了可能客户信息查不到可能库存接口返回了空数据也可能模型压根没想过去查库存。只用一个完成率所有这些失败模式全被混在一起你拿不到任何定位信息。我做Agent-Reach时第一个决定就是不要只盯着最终输出而是把任务链路拆成里程碑逐个检查智能体到没到过、有没有做对。1.2 从图论“可达性”借鉴一个思路“Reach”这个词说白了借用了图论里的可达性Reachability概念。在一个有向图里从一个节点出发沿着边能走到哪些节点哪些走不到这是有明确答案的。Agent执行任务的过程在形式上非常像在图上做状态迁移每个状态是一个节点每次工具调用是一条边模型每走一步就决定了下一条边通向哪里。如果把“智能体完成任务”抽象成“从起点走到终点”那么评测的核心就变成了它在每一步到底能走多远哪条边断了哪个节点永远到不了。Agent-Reach要做的就是把这种抽象还原成工程上的度量——给你一份指标报告告诉你智能体覆盖到哪个里程碑卡在哪个里程碑瓶颈是什么。1.3 Agent-Reach 到底测什么、适合谁用Agent-Reach本身不是一个产品而是一套评测思路加配套脚本。它适合下面几类场景你在对比两个模型在Agent任务上的表现不想只靠“体感”。你在迭代提示词想确认改动到底提升了哪部分能力。你在搭建Agent应用需要知道哪段链路是薄弱环节。你想给外部交付一个可量化的Agent效果说明而不是一句“效果不错”。我在这篇文章里会把Agent-Reach的完整设计思路、评测流程、指标计算方式、以及我在实际跑测中遇到的三个高频问题全部摊开讲。如果你正在被“Agent效果无法量化”这个问题困扰这套东西可以直接抄作业。2. Agent-Reach的评测对象与里程碑设计一条工单处理链路的拆解演练2.1 为什么选“工单处理助手”当评测样本评测一个Agent首先要有一个足够有代表性的任务场景。我选的是“工单处理助手”原因是它天然具备一条完整的工具调用链而且每一步都有清晰的业务语义读工单、查客户、查库存、给建议、更新状态。这个链路在真实业务里非常常见无论是客服系统、运维工单还是售后流程结构都差不多。评测场景太短没有区分度所有模型都是满分太长噪音太大很难定位问题。工单处理链路处在“中等长度”——五个关键节点既能暴露模型差异又能让失败模式可以追溯。2.2 五个工具与五种失败模式我在Agent-Reach的第一个版本里定义了一个模拟工具集让智能体在沙箱环境里操作而不是直接对接真实业务系统。这样做的原因是评测环境必须可控真实系统有太多不确定性你没法分清楚失败是因为Agent能力不足还是因为上游接口抽风。工具名称功能说明评测中注入的失败模式read_ticket根据工单ID读取工单基本信息部分工单缺少产品SKU字段lookup_customer根据客户ID查询客户档案部分客户地址字段为空check_inventory根据产品SKU查询库存部分SKU返回库存为0或不存在generate_action根据已有信息生成处理建议当输入信息不完整时该节点视为不可触达update_ticket更新工单状态并留备注状态字段非法时返回错误需要重试每个工具都预留了失败分支而这些分支就是评测的“陷阱”——Agent必须在信息缺失、数据为空、结果非法的情况下做出正确判断无论是重新请求、请求补充信息还是明确说明无法继续。评测真正想看的就是智能体面对这些分支时怎么走。2.3 里程碑Milestone怎么定义才算不留后门设计里程碑是整个Agent-Reach里最需要较真的环节。定义得太宽松起不到筛选作用定义得太死板又会把允许绕路的情况误判成失败。我最终把一条工单处理链路拆成五个里程碑M1正确读取了工单编号和工单基本信息。M2成功查询到客户档案并在后续推理中实际使用了客户信息。M3成功查询到库存状态并正确关联到工单中的SKU。M4基于M1-M3的信息生成处理建议没有凭空捏造字段。M5成功调用更新状态工具工单状态变更合法。特别要注意M2里的“实际使用”。如果一个智能体查了客户信息但完全没有在后续决策中参考它这个里程碑只能算“经过”不能算“触达”。Agent-Reach记录的不只是“有没有调用过某个工具”而是“这个工具返回的信息有没有进入后续决策链”。这一条是防止评测分数虚高的关键。2.4 评测对象可以横向对比什么在评测对象上我同时对比了两个维度模型维度一个商用闭源模型一个开源小参数模型看它们在完全相同任务集的条件下覆盖率差距。提示词维度同一模型下对比自然语言风格的工具描述和结构化三段式的工具描述。模型对比能帮你做选型提示词对比能帮你做迭代。两件事放在同一套评测框架里跑效率非常高。我第一次跑完就发现开源小模型在节点独立触达率上和商用模型差距并没有想象中那么大真正的差距出现在“把信息串联起来”的环节——这直接改变了后来我对提示词工作的投入方向。3. 一次完整评测的执行流程与核心指标计算3.1 一份评测任务的完整执行序列Agent-Reach的执行流程并不复杂但每一步都有讲究构造评测任务集我准备了10个工单场景覆盖正常场景和各类异常场景。每场景跑多轮每个场景跑3轮一共30条独立的Agent轨迹。记录完整过程每一轮都保存完整对话历史、每次工具调用的请求与返回、每一步的时间戳。里程碑判定用规则脚本对每条轨迹做自动标注标出M1-M5各节点是否触达。人工抽查随机抽取20%的轨迹做人工复核防止规则漏判或误判。跑一轮完整评测总耗时大概40分钟到1小时大头都花在模型推理上脚本本身的性能开销可以忽略。评测脚本只做“记录”和“判定”不干预Agent的决策过程这是保证结果可信的前提。3.2 三个核心指标ReachK、里程碑覆盖率、节点独立触达率在指标设计上Agent-Reach最终沉淀出了三个核心指标各有分工。ReachK借鉴信息检索里RecallK的思路定义为“在K次工具调用之内智能体触达目标里程碑的比例”。这个指标回答的问题是给智能体足够多的尝试机会它能不能摸到那个关键节点。我在评测里默认取K15也就是一条轨迹里最多允许15次工具调用。里程碑覆盖率整条链路从头到尾全部触达的比例也就是M1到M5全部完成的轨迹数除以总轨迹数。这个指标等价于“成功完成率”但它比最终状态成功率高得多因为每一步都被显式确认过。节点独立触达率单独看每个里程碑在多少条轨迹中被触达用于定位瓶颈。比如M3的触达率只有40%而其他节点都是80%以上那问题大概率出在“查库存”这个环节。三个指标配合使用才能完整刻画一个Agent的能力。单独看覆盖率你会误以为它“还行”单独看某个节点的触达率你又会忽略链条整体可能很差。它们的组合逻辑是ReachK观察上限覆盖率观察整体节点触达率观察瓶颈。3.3 判定逻辑的工程化机判为主、人工抽查为辅里程碑判定是整个评测里最容易被低估的工作。规则定好了但执行规则也需要工程化否则大量轨迹靠人肉看效率太低而且主观性太强。我采用的是“日志结构化规则机判人工抽查”的方案。每一轮评测里Agent每调用一次工具脚本就自动记录一条结构化的调用记录大致长这样{ round_id: case_03_run_02, step: 7, tool: lookup_customer, source: read_ticket, target: customer_profile, result_status: ok, milestones_reached: [M1, M2], timestamp: 2025-06-12T14:33:21Z }之后用一段判定逻辑去跑这些结构化记录判断每个里程碑是否真正触达def check_milestone(trace, milestone_id): if milestone_id M2: # 必须实际调用过lookup_customer calls [s for s in trace if s[tool] lookup_customer] if not calls: return False # 且后续步骤里出现过客户信息的引用例如传入generate_action或update_ticket customer_info_used any( customer in str(s.get(input, )).lower() for s in trace[trace.index(calls[-1]):] ) return customer_info_used return False人工抽查用于兜底。规则脚本覆盖不了的情况比如模型在自由文本里提到了某个数据但没体现在工具调用里这种就需要人来判断。最终抽查下来机判和人工评判的一致率在90%以上遇到不一致的案例我会回头调整规则让定义更精确。3.4 为什么每个场景需要跑多轮这条经验是我在第一版评测里吃了一次亏之后学到的。最开始每个场景只跑1轮结果一个模型在某些任务上表现出色换一批同样的任务又一塌糊涂。后来发现Agent存在随机性单次成功可能只是运气好单次失败也可能是偶发抖动。每个场景跑3轮可以把“能力问题”和“随机波动”分开。如果一个节点3轮里触达了2次以上说明智能体具备这项能力但不够稳定如果3轮全失败才能确认这是一个真瓶颈。稳定性本身也是一个隐藏指标——有些模型上限很高但方差奇大在真实业务里这种模型其实很难用因为不可预测。4. 跑测中踩到的三个高频问题与完整排查链路4.1 问题一模型在工具返回缺失字段时“脑补”数据第一次拿到Agent-Reach的报告数据显示M3查库存的触达率异常低。我翻了轨迹日志发现一个诡异的现象智能体确实调用了check_inventory但传入的产品SKU从来没有出现在之前的任何工具返回里。也就是说模型自己编了一个SKU出来。这类问题我当时判断为“生成式幻觉”。模型在上下文里找不到某段信息但它不愿意承认自己不知道于是基于概率推导出一个“看起来合理”的值。排查链路是这样的先确认数据源检查工单原始数据确认缺失SKU。再比对调用链用日志搜索SKU是否在read_ticket和lookup_customer的返回里出现过结果没有。最后做控制测试同样场景换一个提示词版本要求模型“拿不到确切字段时必须明确说明”结果触达率显著回升。解决方案是在工具返回结构里加入一个完整性标记字段大体思路是{ status: ok, data_quality: complete, is_truncated: false, record: { ticket_id: T-2025-0117, product_sku: null } }当is_truncated为true或者某个关键字段为null时Agent必须主动请求补充信息而不是自己“圆”。评测脚本也会把这类情况单独标记出来不记为正常触达。经验总结工具返回里主动暴露“缺失”比让模型自己猜测省心得多。4.2 问题二在同一个工具上无限循环空转另一个高频故障是无限循环。我翻日志时发现某条轨迹连续调用了十几次同一个工具参数几乎不变模型像是在撞墙但始终不死心。这个现象在当时很让人崩溃因为一轮评测卡在一个循环上后续所有步骤全部停摆。排查链路第一步用一段简单脚本统计每条轨迹里相同工具名的连续调用次数找出数值异常的轨迹。第二步回看触发循环前最后一条正常消息确认上下文里已经拿到了足够信息。第三步检查工具描述发现原文只写了“根据SKU查询库存”没有说明重复调用不会带来新信息。模型判断不出“这个工具已经没用了”就会试图靠反复调用来蒙一个结果。修复方案分两层。一是把工具描述改成更加明确的版本“检查指定SKU的实时库存。注意如果最近一次调用已完成重复调用不会返回新的信息请勿多次重试。”二是加了一道硬约束在Agent-Reach里设置单轨迹工具调用深度上限默认15层超限直接终止该轮评测判定为“未触达”。这道硬约束不是给模型用的是给评测框架用的——防止无限循环拖垮整个评测任务。4.3 问题三模型对工具的“偏好性绕路”第三个问题最隐蔽跑数据的时候你没觉得哪里坏了但统计结果就是不对劲。我对比两个模型时发现开源小模型在M3上的触达率明显偏低但它并没有报错也没有循环而是总在绕路。回看轨迹这个模型非常偏好使用read_ticket几乎每走一步都想重新读一次工单却很少主动调用check_inventory。这不是技术上做不到而是模型在策略层面有偏好——它“习惯”了某个工具就会倾向于反复使用它哪怕当前任务更需要另一个工具的数据。这种事情用覆盖率指标看是“性能差”但必须区分一种失败类型触达失败模型调用了工具但结果错误或者根本没想过去调用。策略性绕路模型有能力调用工具但因为策略选择问题导致多走了弯路。区分这两类的办法是看结果如果绕路之后还是完成了任务说明能力没问题是策略问题如果绕路导致任务失败那就是策略能力不足以支撑任务。Agent-Reach的指标设计里我把节点独立触达率和“首次触达时机”分开记录——后者专门用来识别这种偏好性绕路毕竟一个节点虽然最终触达了但如果中间多浪费了8次调用稳定性必然受到影响。对于这个问题的修复我在测试里调整了工具描述的交代表达明确在generate_action的说明里写上“生成建议前优先检查库存库存为0时不可建议发货”。这相当于给模型一个决策顺序上的提示把偏好往正确的路径上引。5. 用评测结果反推Agent调优我把工具描述重写了一遍5.1 差距主要藏在中段节点而不是终点第一轮完整评测跑完后我最直观的结论是两个模型在最终里程碑覆盖率上的差距确实存在但并没有大到“一个能用、一个废掉”的程度。真正的差距集中分布在M2和M3这两个中段节点也就是“查客户”和“查库存”之后的信息串联。这其实颠覆了我一开始的直觉。我最开始以为模型差距会体现在最难的那个节点M4生成处理建议上但数据告诉我几乎所有模型都能生成一段像模像样的建议难的是“敢不敢在信息不完整的时候停下来”。商用闭源模型相对更擅长处理M2/M3这类“先取数再判断”的场景遇到缺失字段时更倾向于显式求助开源小模型则总想靠生成来弥补不确定性。这个发现直接影响了我后续的调优策略——我没有急着换更大的模型而是先去改工具描述、改交互约束因为成本和收益的性价比更高。5.2 工具描述的三段式重写触发条件、入参约束、返回值承诺根据Agent-Reach的评测结果我总结出了一套工具描述写法也就是“三段式”。拿check_inventory举例改写前查询库存。输入SKU返回库存数量。改写后tool: check_inventory trigger: 当需要确认某SKU是否有货、是否可承诺发货时必须调用此工具 params: sku: string, 必填必须来自工单记录或库存查询返回中的原样字段禁止自行生成 returns: - { sku: string, stock: int, status: in_stock | out_of_stock | not_found } - 若sku不存在或库存为0返回statusnot_found/out_of_stock此时不得建议发货 constraints: - 同一SKU短时间内重复调用不会返回新结果请勿连续重试这套写法每个字段都有明确作用trigger告诉模型“什么时候该用这个工具”解决偏好性绕路。params里明确“禁止自行生成”直接在源头压制脑补问题。returns里把异常状态显式列出来让模型知道“遇到这种情况该怎么走”。constraints里的重复调用提示是为了减少空转循环。只改这一处工具描述同一个模型在M3节点上的触达率提升了15个百分点左右。这是Agent-Reach带给我的最大收益——评测不只是用来打分的它能反推出最值得修改的那一个点。5.3 评测场景设计的两个边界教训设计评测场景的过程中我也踩过一些认知上的坑这里值得单独说明。第一个坑是“把评测场景设计成只有一条正确路径”。最开始我构造的任务集里每个工单的“最优解”都是唯一的。这样评测起来确实干净但反过来也会掩盖模型的真实能力——现实世界里的问题有很多种合法解法智能体可能绕了一点路但结果完全正确这种轨迹在严格路径判定里会被误杀。后来我在Agent-Reach里加入了“策略合法性”判定只要最终结果正确且没有违反业务约束的路径都算有效触达。代价是规则稍微复杂了一些但评测结果的可信度明显上升。第二个坑是“正常数据太多异常数据太少”。如果评测语料里全是顺利场景任何模型触达率都会虚高区分度也就没了。我在任务集里故意塞了大约三成的异常场景——缺失字段、库存为0、状态不合法——这样才能真正拉开差距。实际做Agent应用的时候难点从来都不是正常流程而是那些“不知道该怎么办”的边界情况。5.4 把Agent-Reach从模拟场景扩展成真实业务链路的做法模拟场景跑通后把Agent-Reach接到真实业务系统是一种顺理成章的扩展。核心做法是把模拟工具替换成真实服务的接口把里程碑定义成业务操作日志里的关键事件判定逻辑则对齐真实系统的状态变更。我在这个扩展过程中踩过一个实际的坑真实系统里不是每类操作都有明确的“操作日志”可查很多结果只能从自由文本里推断。但自由文本恰恰是大模型最容易犯错的领域。后面我强制要求Agent在每一步都输出结构化中间结果比如确定一个动作时先输出一个JSON片段再执行对应工具。这个习惯养成了之后判定逻辑一下子变得简单可靠。另外如果要在真实场景里长期跑评测数据里必须留一小部分“脏数据”比如故意损坏的字段或模拟超时的接口返回让Agent知道系统不是每次都配合。这听起来像是在给评测加难度但它恰恰保证了覆盖率不会虚高。毕竟一个真实可信的Agent不是那种只能在顺境里表现完美的系统而是知道在数据不好的时候该怎么兜底的系统。对我个人来说Agent-Reach最大的价值不是给出了分数而是把评测从“玄学”变成了“工程问题”。每次改动之后跑一遍哪个节点变好、哪个节点变差一目了然。如果你也在跟Agent打交道卡在调优没有方向的状态里建议你也建一套类似的可视化链路评测先搞清楚智能体到底能走到哪一步——剩下的调优就只是力气活了。