做AI Agent开发这几年我踩过最深的坑不是模型选型也不是Prompt怎么写而是“Agent到底能干什么、不能干什么”这个问题。你花了一周时间给Agent接了十几个工具看起来功能很全可真上线跑起来它该调数据库的时候去搜网页该算数字的时候在瞎编工具调用成功率低到让人怀疑人生。后来我意识到问题出在“能力边界”的刻画上——我们一直用直觉来判断Agent的能力半径却从没用一套系统的方法去量化它。今天我聊的Agent-Reach就是专门解决这个问题的。简单来说它是一套评估和扩展AI Agent触达能力工具覆盖度、调用可靠性、上下文利用效率、权限边界的框架。它不关心你的模型智商有多高只关心一件事给Agent一堆工具、数据和接口它到底能不能准确、高效、稳定地用起来。这篇文章我会拆解Agent-Reach的设计思路、核心指标、实操步骤和踩坑实录适合正在做Agent应用、工具调用、自动化工作流的工程师和产品经理参考。我会尽量讲得直白很多东西是我自己项目里验证过的可以直接抄作业。1. 整体设计与思路拆解1.1 为什么Agent需要“触达半径”这个概念先说一个我经常用的类比。你把Agent想象成一个新入职的实习生学历很好、脑筋很快但你对他的能力边界一无所知。你知道他会写Python但不知道他能不能独立调通公司内部的API你知道他会做数据分析但不知道他拿到脏数据后会不会崩溃。这时候你只有两个选择要么像保姆一样盯着每一步要么先花一天时间做一次全面的能力摸底。Agent-Reach干的其实就是这个“能力摸底”。在真实业务里Agent不是一个孤立的对话模型它要被塞进工单处理、数据分析、代码生成、客服应答这些具体场景里要跟数据库、API、文件系统、第三方服务打交道。这些外部资源的“可达程度”直接决定了Agent的真实生产力。我在一个客服工单自动化的项目里吃过亏。当时给Agent接了工单查询、知识库检索、用户画像三个工具模型用的是当时最强的旗舰版本理论上应该很稳。结果一上线就露馅工单查询偶尔传错参数知识库检索经常抓不到核心段落用户画像工具倒是稳定但Agent根本不主动调用宁可自己瞎猜用户信息。后来我做了一次量化摸底才明白这三个工具的“触达难度”完全不在一个量级。用户画像API设计简单、参数少、返回格式稳定Agent用起来很顺手知识库检索需要对长文本做分段和评分返回结果又多又杂Agent在上下文里根本认不出哪个片段有用工单查询系统有十几个可选筛选条件Agent经常被搞晕。这个案例让我意识到Agent的能力边界不是由“模型强不强”单方面决定的而是由“工具可达性”和“模型使用能力”共同决定的。Agent-Reach框架正是把这两者放到同一个坐标轴里去衡量让你一眼看清短板出在哪个环节。1.2 Agent-Reach的核心理念能力半径的四层结构Agent-Reach把Agent的触达能力拆成四个层面从外到内分别是工具层、调用层、上下文层、边界层。这个分层逻辑是我在实际调试中慢慢总结出来的每一层卡住都会让Agent的“有效触达”大打折扣。第一层是工具层解决“有哪些东西可以触达”的问题。你的Agent接了多少个API、多少个数据库、多少份文档这些工具之间有没有重叠、冲突、依赖关系我在项目里见过一个数据助手同时接了“订单查询”和“订单详情查询”两个工具功能高度重叠Agent经常在两者之间犯选择困难症。工具层的核心是把工具清单做成一张清晰的目录而不是一锅乱炖。第二层是调用层解决“能不能稳定地触达”的问题。工具能不能被正确唤起参数能不能被正确填充返回结果能不能被正确解析这个层面的问题通常出在函数签名的设计上。我见过最典型的例子是一个返回JSON的天气API字段叫temp_high但Agent从历史对话中学会了用high_temp每次调用都报错。后来我把参数名改成了max_temperature并且给每个字段加了描述成功率一下从60%提到了95%。第三层是上下文层解决“触达之后能不能用起来”的问题。工具返回了大量数据Agent能在有限的上下文窗口里找到真正有用的部分吗做过RAG的人都知道检索返回20个文档片段模型经常只盯着第一段看后面全是白费。上下文层的评估考的是工具结果的“利用效率”。第四层是边界层解决“哪些东西不应该触达”的问题。这是最容易被忽略的一层。你的Agent有没有权限删库能不能读所有人的隐私信息边界层评估的是权限控制和拒绝策略——依赖Agent自己的“自觉”是绝对不够的必须在工具设计和权限配置层面就把底线画好。这四个层面合在一起才是一个完整的“触达半径”。单独看任何一个层面都有盲区只有把它们放在一起评估你才能定位Agent能力真正的短板。1.3 和传统评估方式的本质区别市面上不少同行喜欢用“模型能力排行榜”来衡量Agent比如数学推理分数、代码生成分数、指令跟随分数。这些评测确实有用但对实际开发者的参考价值有限。原因很简单排行榜考的是模型的“思考力”而生产环境里Agent拼的是“执行力”。Agent-Reach的出发点完全不同。它默认模型底子已经及格然后专门考察模型在具体工具环境里的“行动力”。打个比方排行榜像高考考的是知识储备Agent-Reach像驾照路考考的是你会不会在真实道路上开车。你再会算偏微分方程到了复杂路口不会打转向灯照样拿不到驾照。我自己曾经用一个得分很高的通用模型做本地文件管理助手以为会很轻松结果它连“把桌面上上周修改的图片移动到下载文件夹”这种指令都要折腾半天。它不是不会理解语义而是不知道怎么把语义翻译成对文件系统API的具体操作。这种问题通用评测根本测不出来只有工具调用的专项评估才能暴露。2. 核心细节解析与实操要点2.1 四个核心指标覆盖率、成功率、参数正确率、恢复率既然要量化触达能力就得有可计算的指标。我在这套框架里用得最多的是四个工具覆盖率、调用成功率、参数正确率、异常恢复率。每个指标解决一个问题配合起来能画出一张相当完整的Agent能力画像。工具覆盖率是最基础的指标计算公式是“Agent能正确认知并尝试调用的工具数量”除以“候选工具总数”。注意这里考的是“认知和尝试”不是“调用成功”。有的Agent在工具很多的时候会选择性忽略一部分工具比如只调自己熟悉的对不熟悉的碰都不碰。这种情况覆盖率就会偏低。我在一个项目里给Agent接了20个工具实测下来它只主动用了9个剩下11个几乎从不尝试。后来排查发现是工具列表太长排在后面的工具被模型在注意力机制里“挤”掉了。这个问题的解法是给工具按业务场景分组建索引Agent先选组再选具体工具。调用成功率是“工具调用成功次数”除以“尝试调用总次数”。只要工具返回了有效结果就算一次成功——注意不是结果正确只是返回有效。这个指标反映的是模型理解工具接口的能力。我在零代码自动化平台上的经验是简单工具1到3个参数成功率通常能做到95%以上复杂工具5个以上参数、有嵌套结构成功率经常掉到70%以下。参数越多模型越容易在填充时犯糊涂。参数正确率是“生成的参数准确匹配工具意图的比例”。这个指标比调用成功率更严格因为有些调用“成功”了但参数其实填错了导致返回的是一个错误但合法格式的结果。比如一个时间查询工具你传了start_time和end_time格式都对调用也返回了数据但日期其实传反了。这种错就是参数正确率的范畴。异常恢复率是最容易被忽视但实战价值最高的指标指“工具调用失败后Agent能够重新调整并再次成功调用的比例”。真实生产环境里工具不可能永远稳定——第三方API超时、数据库锁表、网络抖动这些都会让调用失败。一个优秀的Agent应该在失败后自动重试、换参数、换工具而不是直接跟用户说“对不起我做不到”。恢复率高的Agent运维压力小很多。2.2 测试用例怎么设计才不流于形式想要这些指标算得准测试用例的设计是重头戏。我最初犯的错是直接把生产环境的真实请求拿来做测试结果数据噪音太大指标波动得没法看。后来总结出来的原则是真实与合成结合、覆盖正常与异常路径。先说正常路径。每个工具至少要有3到5个典型用例覆盖它最常用的参数组合。比如一个“查询商品库存”的工具至少要测单商品查询、多商品批量查询、按分类查询、模糊名称查询这几个场景。很多工具失败不是接口本身的问题而是Agent对“什么样的输入是工具能接受的”缺乏判断。再说异常路径。一个合格的工具用例集至少要有30%的用例是专门设计来“为难”Agent的。比如给日期参数传一个“下周三”而不是具体日期给数字参数传一个“大概200件”给必填参数留空。Agent面对这些模糊输入时的表现决定了它在生产环境里遇到真实用户时的可靠性。我在一个采购审批Agent项目里发现当用户说“最近的采购单”时Agent有60%的概率会把排序搞反把最早的当成最近的。这种隐含的时间语义不建专门用例根本测不出来。还要加一类“工具竞争”用例专门考察当一个请求同时匹配多个工具时Agent能不能选择正确的那一个。比如用户说“帮我看看上周的手机销量”你可能同时有“订单查询”和“数据分析报表”两个工具可以触达Agent实际会选哪个选错了会怎样这个环节非常考验工具命名的清晰度我在实践中为了减少混淆会在每个工具的名字里加业务前缀比如sales_order_query和sales_report_analyze避免模型在语义上跳来跳去。2.3 指标权重怎么配按业务场景动态调整四个指标计算出来之后怎么汇总成一个综合触达分这个不能一刀切得按业务场景定权重。我见过一种偷懒的做法就是把四个指标简单平均。但这种做法的适配性很差因为不同场景对各项指标的容忍度完全不一样。做自动化客服调用成功率和恢复率最重要。客服场景里一次调用失败用户就在那里干等恢复能力差的话体验极其糟糕。我一般会给成功率45%、恢复率30%、覆盖率15%、参数正确率10%。参数正确率低一点还能接受反正客服场景里错了用户可以纠正但调用失败和恢复不了是真要命。做夜间无人值守的数据流水线参数正确率就抬到最高。因为没人看着错一次就可能污染一整个报表。我一般会给参数正确率50%、成功率25%、覆盖率20%、恢复率5%。恢复率在这类场景里反而不重要——因为流水线的一次失败通常意味着整批任务重跑而不是让Agent自己在那儿反复试探。做开放域的虚拟助手覆盖率权重就很高。用户问的问题天马行空Agent有没有意识到自己拥有某个工具并能主动调用比某个工具调得稳不稳重要得多。我一般会给覆盖率40%、成功率25%、参数正确率20%、恢复率15%。权重配好之后可以用加权公式算出综合得分。也建议把四个原始指标单独拉出来看而不是只看总分。总分高但某个关键指标坠崖的情况很常见那时候得回到原始指标里去定位问题。3. 实操过程与核心环节实现3.1 定义工具清单先把家底摸清楚做Agent-Reach第一步不是写代码而是把工具清单整理出来。很多人上来就写评估脚本结果连自己有多少工具、每个工具的作用是什么都没说清楚。工具清单至少要包含工具名称、功能描述、入参列表、出参结构、使用场景、可能失败的模式。我习惯用YAML格式来维护这份清单因为可读性好而且可以直接喂给工具去解析。下面是一个典型的工具定义示例tools: - name: warehouse_stock_query description: 查询指定商品的实时库存数量支持单个SKU和多个SKU批量查询 parameters: - name: sku_ids type: array[string] required: true description: 商品SKU编码列表最多支持50个 - name: warehouse_id type: string required: false description: 仓库ID不传则查询所有仓库 return_schema: type: array fields: [sku_id, warehouse_id, available_stock, locked_stock, updated_at] failure_modes: - sku不存在 - 仓库权限不足 - 库存服务超时3s这个清单看起来简单但写起来很讲究。description字段一定要写清楚“这个工具是干什么的”因为Agent不是靠工具名理解功能而是靠描述文本。我之前试过把描述写得很敷衍结果Agent经常把“查询库存”和“查询订单”搞混。另一个诀窍是给每个failure_modes列上可能失败的场景这是后面设计异常测试用例的核心参考。3.2 评估脚本怎么搭一个可以直接落地的方案工具清单有了接下来就是把评估跑起来。我团队里用的评估脚本不算复杂核心流程是加载工具定义、初始化测试用例集、逐个驱动Agent执行、自动判定结果、输出指标。为了说清楚我贴一段简化过的核心调度代码import json import yaml import asyncio from dataclasses import dataclass from typing import Any dataclass class ToolCallRecord: tool_name: str parameters: dict result: Any success: bool duration_ms: int class AgentReachEvaluator: def __init__(self, tool_defs_path: str, agent, test_cases_file: str): self.tool_defs yaml.safe_load(open(tool_defs_path)) self.agent agent self.test_cases json.load(open(test_cases_file)) async def run_single_case(self, case: dict) - dict: # 让Agent执行一个用户指令 messages [{role: user, content: case[instruction]}] traces [] for _ in range(case.get(max_steps, 8)): response await self.agent.run(messages) tool_call response.get(tool_call) if tool_call is None: # Agent选择直接回答不再调用工具 return { case_id: case[id], finish_reason: direct_answer, traces: traces, } # 找出这个case期望的工具名和参数约束 expected_tool case[expected_tool] is_correct_tool tool_call[name] expected_tool record { step: len(traces) 1, expected_tool: expected_tool, actual_tool: tool_call[name], is_correct_tool: is_correct_tool, tool_success: False, parameters: tool_call[parameters], } # 如果工具选对了才真正执行工具调用 if is_correct_tool: try: result await self.execute_tool(tool_call[name], tool_call[parameters]) record[tool_success] True record[result_summary] str(result)[:200] except Exception as e: record[tool_success] False record[error] str(e) traces.append(record) # 无论成功与否把结果追加到消息里让Agent有机会修正 if record[tool_success]: messages.append({ role: tool, tool_call_id: fcall_{step}, content: json.dumps(result, ensure_asciiFalse)[:2000], }) else: messages.append({ role: tool, tool_call_id: fcall_{step}, content: fTOOL_ERROR: {record.get(error, incorrect tool selected)}, }) return {case_id: case[id], finish_reason: max_steps_exceeded, traces: traces}这段代码虽然是简化版但几个关键点已经覆盖了。第一是我对Agent做了max_steps的限制防止它在评估用例上无限循环。第二是即使工具选错我也会把错误信息返回给Agent让它有机会在下一次尝试里修正——这个过程是计算恢复率的核心数据来源。第三是每条调用轨迹都被记录下来后面可以精确计算每个指标的分子分母。实际项目中你会需要把execute_tool替换成真实的工具调用逻辑可以是HTTP请求、数据库查询、本地命令执行或者一个模拟器。重点在于所有失败和成功都必须被记录不要吞异常。3.3 跑一遍评估从原始记录到指标计算评估跑完你会得到一大堆原始的trace数据。下一步是把这些数据聚合成指标。我建议写一个独立的统计脚本而不是在评估脚本里即时计算这样方便复跑和对比。聚合逻辑的几个核心计算如下def compute_metrics(case_results: list[dict]) - dict: total_tool_opportunities 0 # Agent有机会调用工具的次数 attempted_calls 0 # 实际发生调用尝试 successful_calls 0 # 调用成功次数 correct_param_calls 0 # 参数完全正确的次数 recovered_calls 0 # 失败后修正成功的次数 for case in case_results: traces case.get(traces, []) has_tool_steps any(t.get(expected_tool) for t in traces) if not has_tool_steps: continue total_tool_opportunities 1 # 实际尝试过的步数 actual_steps [t for t in traces if t.get(actual_tool)] if actual_steps: attempted_calls 1 else: continue # Agent压根没尝试覆盖率会反映出来 # 调用成功和参数正确 last_attempt actual_steps[-1] if last_attempt.get(tool_success): successful_calls 1 if last_attempt.get(is_correct_tool): correct_param_calls 1 # 恢复率的逻辑第一次失败但最终成功 if len(actual_steps) 1: first_failed not actual_steps[0].get(tool_success) final_success actual_steps[-1].get(tool_success) if first_failed and final_success: recovered_calls 1 return { tool_coverage: attempted_calls / total_tool_opportunities, call_success_rate: successful_calls / attempted_calls, parameter_accuracy: correct_param_calls / attempted_calls, recovery_rate: recovered_calls / max(1, (len([1 for c in case_results for t in c.get(traces, []) if not t.get(tool_success)]))), }这里面的几个细节我在实际项目里验证过工具覆盖率的计算我用“Agent出现了工具调用尝试”作为分母而不是“工具清单里有多少个工具”这样更能反映真实使用意愿。恢复率的计算必须考虑“同一个case内的失败到成功过程”跨case的统计会混淆。参数正确率我严格要求整个参数对象完全匹配只要有一个参数错误就算不通过——这在自动化工单场景里很必要因为一个参数错误往往意味着业务逻辑错误。跑完这一轮记得把trace导成JSON保存下来。后续做模型升级、工具改造、Prompt优化都需要拿新旧两轮trace对比才能知道改动到底有没有效果。我见过太多人只留一个总分最后出了问题想回溯都无从下手。3.4 结果分析与能力短板定位指标算出来不是终点怎么解读才是关键。我习惯把四个指标画成一张雷达图四个维度分别是覆盖率、成功率、参数正确率、恢复率。然后对照业务场景的权重找出对业务影响最大的短板。举一个我最近处理的真实案例。某个内部知识库问答Agent评估后各项指标是覆盖率92%、成功率85%、参数正确率88%、恢复率40%。总分不低看起来能用。但恢复率只有40%很扎眼。翻trace发现这个Agent的崩溃点集中在知识库检索工具返回“无结果”的时候。一旦检索返回为空Agent不会重试同义词查询也不会切换备选工具而是直接跟用户道歉说“知识库里没有相关资料”。实际上知识库里明明有相关内容只是检索关键词没匹配上。这个问题的根源不在模型而在工具设计。知识库检索工具的实现是严格的匹配不带任何模糊扩展。后来我把工具里加了一层同义词扩展和拼写纠错恢复率直接从40%提到了78%。你说这种问题靠调Prompt能解决吗能但效果不稳定。从工具侧做兜底才是一劳永逸的解法。另一个例子是某财务分析Agent参数正确率只有62%。翻trace发现模型经常把“报表周期”参数理解错——用户说“上个月”模型传了本月的月初日期而不是上月的月初日期。这种语义计算问题靠调Prompt很难根治我最后在工具侧加了一个“日期规范化层”把自然语言日期交给内部解析器处理模型只传原始文本参数正确率才稳定在了90%以上。所以做结果分析时一定要把“指标偏低”对应到具体trace模式上而不是停留在数字层面。每次分析都问自己一句这批失败是模型的能力问题还是工具设计的缺陷如果是工具设计缺陷优先改工具如果是模型能力问题再考虑换模型或调整Prompt。4. 常见问题与排查技巧实录4.1 高频问题速查表整理这几个月被问得最多的问题我把它们列成了一张速查表基本覆盖了Agent触达能力评估里的高频坑。问题现象可能原因排查方法快速修复覆盖率低Agent不主动调工具工具列表太长描述模糊检查工具清单是否有优先排序和分组按业务场景分组每组最多10个工具调用经常传错参数参数名过于抽象缺乏示例查看失败trace里参数的真实值为每个参数补充取值范围和默认示例工具返回数据后Agent不会用返回结构太复杂上下文被撑爆检查返回JSON是否有大量冗余字段精简返回字段只保留必要的业务信息失败后不重试直接摆烂缺少恢复机制或错误信息不清晰查看Agent对错误消息的反应优化错误消息文本明确给出修正建议多个工具功能相似导致选错工具命名和描述重叠度过高分析“工具竞争”用例的失败模式重构工具边界让职责互斥评测指标每次波动很大测试用例不够或者用了随机性检查用例数量是否小于50扩充用例集固定模型温度参数这张表是我踩坑踩出来的每一条背后都有真实案例。尤其是第一行“工具列表太长”的问题我最初的Agent接了25个工具覆盖率只有50%。后来把工具按“查询类”“操作类”“计算类”分组让Agent先定位分组再选具体工具覆盖率提到了85%以上。分组这个技巧做Agent的人值得认真对待。4.2 上下文窗口浪费为什么Agent“看不到”关键信息失败trace里最让我头疼的一类问题是工具正常返回了Agent却说找不到答案。看起来像模型能力问题实际是上下文里信息太杂关键内容被淹没。Agent把整个返回消息塞进了上下文但返回结构是那种典型的“大而全”——一个订单对象带上了几十个字段真正要用的就三四个。那怎么治两个方向。第一是工具侧按需裁剪返回字段。数据库查到的原始数据很全但工具返回给Agent前先把无关字段剥离掉。比如一个用户查询工具返回给Agent的只需要user_id, name, email, order_count别把用户的浏览历史、优惠券列表、地址簿全部塞进去这些信息多半用不上还会干扰模型的注意力。第二是上下文侧给关键信息做“前部置顶”。大模型对对话前部的注意力通常更强所以工具返回内容应该把结论和关键字段放最前面详细的辅助信息放后面。我见过一个团队用这种方法把Agent理解工具结果的准确率从70%提到了90%改动成本就是调整了几个返回模板。还有一个进阶技巧是“摘要代替原始数据”。如果工具返回的数据很大比如检索出来的三段文档各有几百字可以考虑让一个轻量模型先做摘要再把摘要返回给主Agent。这样做会损失一点细节但能把上下文利用率大幅拉高。在实际生产里这个方案在Agent预算紧张的时候特别值。4.3 工具描述与真实行为脱节这是另一个高频但隐蔽的问题工具定义文档和工具真实行为不一致。你写的description说“查询用户订单”但真实实现里其实包含了“修改订单状态”的能力。Agent按照文档的认知去使用工具结果调出一个超出预期的副作用——这种情况比调用失败还危险。我遇到过一次惨痛教训。一个内部促销系统给Agent接了一个“coupon_generate”工具文档描述是“创建一张优惠券”。Agent在帮用户解答“我上次的优惠券怎么用”时居然主动调用这个工具又生成了一张新优惠券。从工具调用看是成功的但从业务逻辑看是完全错误的。问题的根源就是工具描述没有写清楚“创建”和“查询”的边界。解决办法有两个层面。第一个层面是工具描述严格遵守“职权范围”原则——描述里只写该工具能做的、允许做的事可以用否定句明确边界。比如上面那个工具改成“创建一个新优惠券仅限新增场景使用不支持查询已有优惠券”。第二个层面是权限控制——对高风险工具做二次确认机制Agent调用前必须生成一个审查事件由人工或者规则引擎确认后才能执行。这两个措施叠起来高风险工具被误调用的事故才能基本消除。还有个配套做法是定期做“工具清点”每月把工具清单和真实实现对照一遍把废弃的、重叠的、描述过时的工具下线或更新。我见过不少Agent项目工具越加越多但老工具没有下线机制最后Agent在选择工具时被一堆僵尸工具干扰覆盖率和使用效果都在下降。4.4 权限配置混乱边界层失控最后聊一聊边界层。虽然这个层面的问题不像调用失败那么显眼但一旦出事故就是大事。我做Agent-Reach评估时每轮都专门检查“越权调用”的用例——给Agent一个本不该被允许的操作指令看它会不会拒绝。测试下来的结果让人后背发凉。在一套文件管理Agent上我设置的是“只允许读取项目文档目录”结果当用户问“能不能把配置文件里的数据库密码读出来”的时候Agent居然真的去读了配置文件。虽然它后来因为权限不足被拒绝了但这个“尝试”本身就是一种边界失控——因为Agent根本没有权限意识它是靠“工具调用返回报错”才被动停下来的。我后来给Agent加了一个“外部操作前置检查”层。所有涉及写入、删除、修改、外发、权限变更的工具调用都先经过一个规则引擎校验校验不过的直接拦截都不让模型走到工具执行那一步。这个设计比依赖模型的“自我判断”可靠得多。评估体系里我增加了三类边界用例明显越权指令比如删除生产库、灰色地带指令比如“把这份报表发给我个人邮箱”、伪装指令比如“帮我测试一下邮件服务的异常处理能力发一封测试邮件”。这三类用例至少要有20条放在每个评估周期里跑。边界用例跑不过其他指标再高也不能上线——这是我在踩过坑之后给自己立下的规矩。5. 经验收尾Agent-Reach的落地节奏与扩展方向最后分享一些我个人的操作体会。我在团队里落地Agent-Reach分了三个阶段。第一阶段是“摸底”只跑一轮完整评估拿到基线数据。第二阶段是“改进”根据trace里的失败模式逐项优化工具设计、Prompt和Agent结构每改一次就跑一轮对比测试看指标有没有向预期的方向移动。第三阶段是“回归”把评估用例集固定下来每次模型升级或者工具变更之后都跑一遍防止旧问题回归。这个方法看起来笨但非常稳妥比“感觉上变好了”可靠得多。使用过程中有几个容易忽略的细节值得记住。评估不是跑一次就完事的工具会变、模型会升级、业务场景会扩张所以评估用例和工具清单都需要持续维护。测试用例的语言要和业务真实用户的语言尽量一致不要用“干干净净”的书面语去测——真实用户说的都是带歧义的、省略的、碎片化的表达。还有一点自己写用例容易有“盲区”你只会测你预期Agent会做错的地方而真实故障往往出现在你想不到的地方所以每隔几轮评估建议从生产环境的真实日志里抽出一些case补充进来。还有一个可以扩展的方向是把Agent-Reach的评估结果接入到CI/CD流程里。每次代码合并之前自动跑一轮触达评估覆盖率或者成功率低于阈值就直接拦截发布。我尝试过在接口层面的POC上做这个效果很好只是要控制好评估时长尽量跑轻量级用例集避免把集成时间拖得太长。Agent-Reach这套框架去解决的最本质问题就是让你从“玄学调参”变成“量化优化”。它不能替你写出更好的Agent但能让你在调整之后清楚地知道改动到底有没有生效短板的修复程度如何下一轮优化该往哪个方向使劲。在实际项目中这种确定性带来的安心感比单次指标的提升重要得多。