1. 为什么“答对问题”和“办成事情”是两回事1.1 一个让所有Agent开发者焦虑的测试结果如果你手上有一个AI Agent项目你迟早会面对一个尴尬的测试结果模型理解用户意图的准确率明明有95%但端到端任务成功率只有六成出头。这正是我当初搭建Agent-Reach这套评测流程的直接原因。“Agent-Reach”这个项目名听起来有点抽象但拆开看就很直白Agent是一个智能体Reach是触达。它要测量的不是模型“知不知道答案”而是智能体“能不能触及任务的终点”——从用户抛来一句话开始到完成工具调用、拿到真实结果、把结果交回用户手上的完整闭环。我见过太多团队在模型榜单上纠结BLEU分数、ROUGE分数热衷于对比“哪个模型回答更像人”却忽略了真正决定Agent能不能落地的东西端到端的任务达成率。你让Agent帮用户查一个订单状态它可能把话说得很漂亮但调用订单接口时传错了订单号最后对着一个404报错敷衍地回一句“暂时无法查询”。这种体验用户不会给你第二次机会。Agent-Reach要做的事情就一件把这条链路拆开用一套固定流程去测量每个环节的触达质量找到任务失败的真正断点。适合谁来参考正在开发Agent应用的工程师、接入大模型工具调用的产品经理、负责Agent质量保障的测试开发甚至是你只是用Agent跑一些自动化脚本的个人开发者——只要你的Agent需要调用外部工具或数据源这篇文章里的思路就能直接用。1.2 从“意图准确”到“结果交付”的隐性断层先讲一个我实际测过的例子。一条测试任务是“帮我把上海明天下午的会议推迟到后天上午并通知参会人”。如果只测意图理解模型表现会很好它能准确识别出“上海”“明天下午”“会议”“推迟到后天上午”“通知参会人”这几个实体和意图。可一旦进入真实链路问题就接踵而至日历系统的会议ID从哪来推迟操作需要什么权限“通知参会人”要调邮件接口还是IM接口参会人的邮箱地址有没有存到配置里断点往往不发生在“理解”环节而是发生在“动作”环节。真实世界的任务不是填空题而是一连串依赖前置条件的动作。前置条件缺失、工具参数名不一致、接口返回格式变化、权限不足任何一个环节出了岔子Agent都可能卡住。更麻烦的是Agent的“卡住”和人的卡住不一样——它不会停下来问而是会硬着头皮编一个结果或者干脆放弃换一条路最后给你一个表面成功实则失败的回答。Agent-Reach的核心设计逻辑就是把这条链路上的每一个动作都变成可以打分的检查点。这不只是测试更是在回答一个根本问题你的Agent究竟能“摸到”用户真正想要的那个结果吗2. 五个触达层级的判据设计把一个“感觉不行”的问题变成精确的分数2.1 从一句话到交付物的五层拆解我刚做Agent-Reach时踩过一个思维误区想用一个笼统的“任务成功率”来评判所有Agent结果发现这分数啥也说明不了。任务失败在意图理解阶段和失败在工具调用阶段处理方式完全两回事。后来我参照软件测试里“分层测试”的思路把Agent的执行链路拆成了五个触达层级每一层都有独立的判据和打分方式。你接手任意一条Agent任务都可以沿着这五层去定位问题。触达层级名称判定标准典型失败表现L0意图触达模型是否正确提取用户核心目标和关键约束目标理解偏了后续全错L1资源触达是否找到并锁定完成任务所需的工具或数据源找不到工具、选错工具L2动作触达工具调用是否成功参数是否合法权限是否足够参数幻觉、API报错、权限拒绝L3结果触达拿到返回结果后是否做了正确校验和后续动作拿到错误结果不自知、停止链路L4交付触达最终输出是否完整覆盖用户需求格式是否可用答非所问、结果残缺、未通知用户这五层覆盖了一条任务从“接收”到“交付”的全部动作。L0解决的是“干没干对的事”L1到L4解决的是“把事干成没有”。其中L2是最容易翻车的层级因为大多数Agent应用的失败都发生在工具调用这个细节密集的阶段。回到前面“推迟会议”的例子。L0层模型必须知道用户要求的是“改期”加“通知”缺一不可。L1层它需要定位到日历工具的“查询会议”接口和“更新会议”接口以及通讯工具的通知接口。L2层查询会议时传的会议ID必须存在更新会议时传的时间格式必须符合接口规范。L3层更新接口返回成功后Agent要确认返回码是“success”而不是“pending”还要把新的时间回填给通知动作。L4层最终给用户的回复要同时包含“会议已改期到后天上午10点”和“已通知6位参会人”这两条信息最好还要附上新时间的会议邀请摘要。这样拆完你会发现原本一个模糊的“任务没办成”变成了“L2层动作触达失败会议ID参数不存在”这样一个可以直接修复的具体问题。2.2 判据必须可观测不能靠“感觉差不多”设计判据时我最想强调的一点是一切不能自动判定的规则都不要写进Agent-Reach的评测体系。听起来像废话但很多团队做Agent评测时依然在用“人工看结果、凭感觉打分”的方式。一次两次行任务一多就彻底不可复现——同一个任务上午测通过下午测失败你根本不知道是模型抽风还是工具抖动还是评估规则不一致。Agent-Reach对每个层级都定义明确的可观测信号。例如L2层“动作触达”判据不是“模型说出了正确的工具名”而是“截获的实际HTTP请求中URL路径、请求方法、关键参数都匹配预期值”。这意味着评测系统必须记录Agent在运行过程中的完整轨迹而不是只看最后的聊天输出。实现上也很简单。我在这套体系里给Agent挂了一个透明的日志探针把每一次工具调用的方法名、入参、返回值全部写入结构化日志。评测时每一层的打分器只认这个日志里的客观字段不认模型自己写的“总结”。用生活里的例子类比这就好比验收一份外卖你不能只听骑手打电话说“送到了”你得真的看到外卖放在了门口、打开了袋子确认菜没洒。Agent-Reach要求的是后者动作发生了、参数对了、结果回来了、内容完整了才算真正触达。3. 搭建Agent-Reach测试环境不接真实API也能跑出可信数据3.1 为什么我坚持用Mock工具集做基准评测设计评测环境时很多人第一反应是“直接接上真实API跑”。我一开始也这么干然后被现实教育了。真实API有三个无法回避的问题一是依赖外部环境接口升级、限流、网络抖动都会污染测试结果你分不清是Agent不行还是接口不行二是难以注入边界情况比如你想测“API返回500时Agent怎么处理”真实接口很难稳定复现500三是不可重复同一个任务今天能过明天不能过回归测试根本没法做。所以Agent-Reach的基准测试环境里所有的外部依赖都用Mock工具替代。这里说的Mock不是简化版伪装而是完全复刻真实接口行为的高保真模拟器。我搭建的Mock工具集包含四个常用工具一个模拟订单查询服务的接口一个模拟日历系统的接口一个模拟文档检索的接口还有一个模拟通知推送的接口。每个工具的数据都放在本地SQLite里可以随时重置。这样做的好处是测试完全可控我可以让订单接口对指定订单号返回“不存在”也可以让日历接口随机报一次“服务繁忙”用来测Agent的抗干扰能力。3.2 一个最小可跑的评测管线Agent-Reach的评测管线不复杂核心就三步加载任务集、运行Agent收集轨迹、按层级判据打分。下面是去掉业务细节后的核心骨架基于Python实现用LangChain的Agent框架做演示。import json from typing import List, Dict, Any from dataclasses import dataclass, field dataclass class TaskCase: id: str user_query: str expected_l0: str # 预期意图 expected_tool: str # 预期工具名 expected_params: Dict # 预期关键参数 expected_result: str # 预期结果特征 dataclass class ReachRecord: task_id: str layer: str # L0/L1/L2/L3/L4 passed: bool detail: str class AgentReachRunner: def __init__(self, agent, task_cases: List[TaskCase], trace_store: Dict): self.agent agent self.task_cases task_cases self.trace_store trace_store def run(self) - List[Dict[str, Any]]: results [] for case in self.task_cases: # 抓取Agent执行过程中的工具调用轨迹 trace {tool_calls: []} original_tool self.agent.tools[0] if self.agent.tools else None # 这里用monkey patch方式记录每次工具调用的入参与返回值 def tracing_wrapper(func): def wrapper(*args, **kwargs): result func(*args, **kwargs) trace[tool_calls].append({ args: kwargs or args, result: result }) return result return wrapper for tool in self.agent.tools: tool.run tracing_wrapper(tool.run) # 伪代码真实项目按框架API调整 final_answer self.agent.run(case.user_query) self.trace_store[case.id] trace results.append(self._score(case, trace, final_answer)) return results def _score(self, case, trace, final_answer) - Dict[str, Any]: # 按五个层级逐一判分每层只依赖trace中的客观字段 checks { L0: self._check_l0(case, final_answer), L1: self._check_l1(case, trace), L2: self._check_l2(case, trace), L3: self._check_l3(case, trace), L4: self._check_l4(case, final_answer, trace), } return {task_id: case.id, checks: checks, trace: trace}这段代码的核心思路很清楚拦截Agent调用工具的入口把每一次动作的入参和结果记录下来之后每一层判据都只在这些记录上做检查。L0看最终回答里有没有覆盖用户目标关键词L1看轨迹里有没有出现预期工具名L2对比预期参数和实际参数的匹配度L3看工具返回结果是否被正确消费L4检查最终回答是否包含交付要素。实测下来这套管线的可靠性很高——只要Mock工具和判据写得足够精确同一任务跑十次结果一致。3.3 任务集设计难度递增和故障注入任务集是评测的灵魂。我最初只写了二十条“顺利任务”测试结果一片飘红看着好看但什么问题都暴露不出来。后来逐步改成三个梯度第一梯度是“直路任务”所有工具都按预期工作参数齐全考察Agent的基础能力。第二梯度是“绕路任务”需要Agent先调用查询接口拿一个ID再用这个ID发起第二个动作考察跨工具数据传递。第三梯度是“故障任务”我会在Mock工具里预设以下故障接口返回500、数据不存在、参数类型不匹配、权限不足、返回结果字段缺失。故障注入听起来复杂实现其实很简单。就拿订单查询接口举例我在Mock工具里加了一个配置项class MockOrderService: def __init__(self): self.fail_rates {not_found: 0.1, server_error: 0.05} def query_order(self, order_id: str): if order_id.startswith(ORD) and order_id not in self.valid_ids: raise ValueError(f订单 {order_id} 不存在) if random.random() self.fail_rates[server_error]: raise TimeoutError(上游服务超时) return self._fake_order(order_id)这样每条任务都能以固定概率触发指定异常Agent会不会在异常发生后换一条路、重试一次、或者如实告知用户一目了然。这类“故障任务”才是Agent-Reach评测体系里最有价值的部分因为它测的正是Agent在真实部署时遇到最多的状况。4. 触达失败的三类典型坑从故障日志反推断点的完整链路4.1 参数幻觉模型生成了一个不存在的订单ID第一个让我印象深刻的失败样本来自一个“查订单物流”的任务。用户说“帮我看看订单12345到哪了”这个订单号本身不存在。模型在L0层理解得完全正确L1层也选对了订单查询工具L2层却出了问题——它在调用查询接口时没有用用户原话里的“12345”而是自己“脑补”成了“ORD20240809-8873”。为什么会这样我翻了模型的结构化轨迹发现它在执行前做了一个“语义归一化”动作把用户口语中的订单号强行补全成了系统里更常见的带命名空间的ID格式。这个动作本身在训练数据里可能是合理的但在这个场景里工具接口明确要求传入原始订单号归一化反而制造了不存在的参数。这个案例说明了一个重要教训Agent在L2层的参数传入必须遵循“忠实原义”原则而不是“猜测补全”原则。评测判据里我把L2层的参数检查从“参数存在”强化为“参数值与用户输入或前置查询结果完全一致”凡是出现凭空生成的ID直接判L2失败。4.2 工具选择偏离明明该查A库却查了B库第二个案例更有意思。任务要求“查一下商品SPU编号为3250的库存”Mock环境里同时存在商品库存接口和销售订单接口。Agent在L1层选工具时错误地选中了销售订单接口然后对着一个库存查询需求传递了SPU编号。销售订单接口也不知道为什么没报错居然返回了一条不相关的订单一周数据。链路走到L3层时出了状况工具返回的数据里没有“库存量”字段但Agent没有发现这个问题而是从返回数据里找到一个“订单数量”字段直接当成库存量展示给用户。从用户角度看Agent“成功”地给出了一个数字但这个数字根本不是他想要的。这个案例的根源在L1层的工具选择策略。后来我在Agent的prompt里加入了一段显式的工具边界声明让模型优先根据“查询实体类型”匹配工具名而不是根据“动作动词”模糊匹配。同时在L3层增加了“结果字段-需求字段映射检查”的判据要求工具返回结果必须包含用户需求对应的关键字段否则判失败不允许拿近义字段代替。4.3 过早放弃遇到一次404就宣布“做不到”第三个案例触目惊心而且我猜很多Agent项目里都在频繁发生。任务需要先调用文档检索工具查一份内部规范再根据规范内容调用审批工具提交一个申请。结果文档检索工具因为一个临时配置错误对关键词返回了404。Agent没有重试没有换关键词也没有改调用另一个搜索接口直接回到用户面前说“无法完成申请因为找不到相关规范”。从评测轨迹来看L0、L1、L2全部通过但Agent在L3层遇到外部故障后选择了“终止链路”而不是“绕行或重试”。这暴露了一个工程问题很多Agent的默认行为策略是“只要收到异常就回退到通用回答”而不是“收到异常时先触发既定的重试或降级策略”。修复这个问题的关键在于Prompt不背全部的锅更需要在Agent的运行时加上异常处理机制。我给Agent的每条工具调用外层套了一层重试逻辑并追加了一条行为规则遇到“数据不存在”类错误时必须尝试一次同义词改写再查询遇到“服务不可用”类错误时连续重试两次间隔1.5秒。经过这个调整同类任务的触达成功率提升了接近三成。5. 把触达成活率从62%拉到89%可复用的四步优化清单5.1 在Prompt里写入工具边界声明而不是泛泛的角色设定经历了前面那几个失败样本之后我开始系统性地优化Agent。第一个改动就是在系统Prompt里增加了一段落清晰的“工具边界声明”。很多团队的Prompt只写“你是一个助手可以使用以下工具”这远远不够。模型对工具的误用往往不是因为不理解任务而是因为不知道每个工具的适用范围和参数口径。我最终使用的Prompt模板是下面这样的结构核心要点是每条工具都标注了“适用场景”“关键参数口径”和“禁止事项”你只能使用以下工具完成任务。每个工具都有明确边界 1. query_order(order_id: str) - 适用查询订单状态、物流、金额。 - 参数口径order_id 必须是用户原话中的订单号禁止自行拼接或补全前缀。 - 禁止查询库存、查询商品信息。 2. query_stock(spu_id: str) - 适用查询商品库存、SKU余量。 - 参数口径spu_id 必须是8位数字编号若用户提供的不是8位数字先向用户确认。 - 禁止用作订单查询。 3. create_approval(form_data: dict) - 适用提交审批申请。 - 注意提交前先调用查询接口确认前置条件不允许直接猜测字段。这个Prompt让L1层的工具选择错误率下降非常明显。实测对比中加上工具边界声明后一百条任务里L1层的通过率从78%上升到了94%。5.2 强制“先规划、再执行、后验证”的三段式工作流第二个关键改动是改变Agent的执行节奏。默认的Agent框架往往是“想到哪步做哪步”模型可能直接跳过了“查询会议ID”直接去“更新会议时间”结果参数不完整。Agent-Reach评测显示这种情况占了L2层失败原因的相当比例。我的解法是给Agent加了一步“执行前规划”的强制环节每次响应之前模型必须先输出一个JSON格式的Plan包含要执行的步骤序列、每步用到的工具名、依赖的前序步骤、以及每步的预期产出。这个Plan会经过一个轻量的规则校验器检查有没有“跳步”或“缺参”。这不只是质量保障手段也大大提升了评测的可解释性。现在我看Agent-Reach的评测日志一眼就能看出问题是出在“规划错误”还是“执行错误”规划阶段输出里步骤缺失是规划错误规划完整但步骤执行参数传错是执行错误。两类错误的修法完全不同。5.3 用失败样本做回归而不是随手改Prompt优化Agent最忌惮的事情之一是“按下葫芦浮起瓢”——修好了A类任务结果B类任务全崩了。Agent-Reach的评测体系天然适合用来做回归测试关键在于要让失败样本沉淀成回归集。我给自己定了一个工作规矩每修复一批失败样本就把它们连同难度相近的若干“对照组”任务一起合并进回归任务集并把Agent-Reach的预期判据锁定。这样每次改动Prompt或调整工具后我都能快速重放一遍历史任务集确认此次没有引入新的触达失败。具体执行起来一百多条回归任务在我本地跑完只需要几分钟成本极低但带来的安全感极高。现在我对任何Prompt改动都不再有“会不会改坏别的功能”的担忧因为回归测试会在两分钟内给出答案。5.4 从评分到优化的闭环让数据帮你定位下一个必改项最后一步是把Agent-Reach跑出来的数据抄进一张持续更新的“触达短板表”里。我习惯按层级统计通过率然后每两周看一次哪层通过率最低就集中人力修哪一层。举个例子最初一次评测的结果是L0通过率94%L1通过率78%L2通过率62%L3通过率55%L4通过率88%。一眼就能看出L3层是最大短板而L3层最大的失败原因就是4.3节提到的“遇到外部异常直接放弃”。后面我调整重试策略后L3层通过率涨到81%整体触达成活率也随之到了接近九成。评测批次L0L1L2L3L4端到端成功初始基线94%78%62%55%88%62%工具边界声明95%94%71%58%89%71%重试与降级机制95%95%84%81%91%84%回归集锁定96%96%89%85%93%89%这个表格是我真实项目里的一组数据优化路径很清楚先修L1的工具选择再修L3的异常处理最后用回归测试稳住L2的参数可靠性。每次只改一个变量观察Agent-Reach分数的变化效果立竿见影。我在这个项目里最大的体会是Agent的开发不能靠“感觉跑通了”那只是运气好遇上了一条顺畅的路。Agent-Reach这套流程让我第一次能把“智能体到底行不行”变成一个可以量化、可以追踪、可以持续改进的工程指标。如果你手上正好有Agent项目卡在“答非所问”或“工具调用翻车”的坎上不妨也把任务链路拆成触达层级先回答一个最基本的问题你的Agent真正摸到用户想要的结果了吗没摸到那就从最短的那块板开始补吧。