这几年做AI Agent落地项目，我注意到最多的问题不是“哪个模型更强”，而是同一个Agent在概念演示时干得漂漂亮亮，一接真实业务就像换了个人：任务复杂一点、数据脏一点、中间出点小岔子，它就原地打转，或者交出一份错误结果。模型能力明明在涨，任务能力却上不去，瓶颈渐渐落在一个很少被正式讨论的指标上——Agent-Reach，也就是Agent从任务起点出发，能稳定“够到”多远的最终目标。这篇内容我结合自己的项目经验，把这个概念掰开讲清楚：它到底是什么、为什么传统评测方式一直没抓住它、在实际链路里它被哪些环节消耗掉，以及我用来评估和提升Reach的一套工程手段。
1. Agent-Reach这件事，其实早该被单独拎出来讲
1.1 定义一个Agent能“够到”多远的目标
我在团队内部最早用“Reach”这个词，是因为一句话很难说清楚某个Agent到底行不行。比如有人说“我们的智能体完成了数据分析任务”，这句话的信息量其实非常低。它可能意味着Agent在一个干净的数据集上跑了一个SQL查询，也可能意味着Agent要自己读文档、配环境、处理缺失值、调试查询、解释结果、画图、生成报告——这两种情况完全不是一回事。
Agent-Reach是我用来描述“智能体在真实多步任务中，能够一路稳定执行到目标完成的能力边界”的概念。它的核心不只是“最终做没做出来”，而是“从中途任意一个状态出发，它还能不能继续往前走”。你可以把它理解成攀岩中的“攀爬范围”：一个人能摸到岩壁顶部不叫能力，真正的能力是他从某一段卡住之后还能不能重新找到路径，从中间状态继续向上。这个视角对工程落地非常重要，因为真实业务从来不是一条直线的流水线，而是到处有岔路、断层和意料之外的状态。
我实际用下来，Reach可以拆出三个观察维度：
- 任务深度：Agent能在一条执行链上连续完成多少层子任务，才算真正到达终点。一个“浅”的Agent可能只做一步查询，一个“深”的Agent能独立完成“理解需求—拆解步骤—调用工具—验证结果—迭代修正”的完整闭环。
- 覆盖广度：同一个任务拆出多个并列子任务时，Agent能完整覆盖多少分支。漏掉分支是真实项目里最隐蔽的失败，表面看起来结果对了，实际上有一半的数据源根本没接上。
- 恢复能力：执行过程中一旦出现失败、异常、环境变化，Agent是直接放弃，还是能诊断问题、调整策略、继续推进。我做项目时最深的感受是：一个不会恢复的Agent，Reach再长也是脆的。
之所以要把这三个维度分开看，是因为很多失败的根因并不一样。深度不足往往是规划和工具链的问题，覆盖不足往往是任务理解不完整，恢复不足则通常是上下文管理和错误反馈机制的问题。如果不拆开定义，出了问题就只知道笼统地“加提示词”“换模型”，方向很容易错。
1.2 为什么传统“任务成功率”指标不够用
大多数Agent项目还在用“成功率”衡量效果：一百次任务，成功七十次，所以成功率70%。这个数字很直观，但它有个致命缺陷——它把失败的中间过程完全丢掉了。
我曾经做过一个对比实验：同一个Agent，在A组任务里做的是“查询某公司公开信息并生成摘要”，在B组任务里做的是“从十几个数据源提取数据、清洗、合并、再按指定格式生成报表”。单看成功率，两组可能差不多；但看Reach差异就非常大。A组任务的失败通常发生在一两步之内，成功率的波动主要受模型理解能力影响；B组任务的失败则会发生在链条的不同位置，有时候是环境依赖，有时候是工具返回格式的问题，很难用同一个概率去描述。
成功率只告诉你“行或不行”，Reach才能告诉你“卡在哪里、剩下多少路走不完”。而后者对工程优化恰恰是唯一有用的信息。
传统评测还有一个问题：它倾向于让Agent在受控环境中跑完整个任务，过程中一旦出现意外就标记为失败，然后换个案例重来。真实业务不给这个机会。用户不会重新点一次“开始”，数据不会因为查询失败就自动变干净，外部API更不会因为Agent超时就跟你说声抱歉。一个Agent如果对中途状态没有“延续能力”，那它做得再快也落不了地。
把Agent-Reach当一个独立指标之后，我后面所有的调优动作都有了靶子：不是把成功率从70%改成75%，而是搞清楚“到底是深度丢了、覆盖丢了、还是恢复丢了”。这篇内容的后面几节，就是围绕这个靶子展开的。
2. 在真实业务里，Reach主要被三个环节吃掉
评估一个Agent的Reach，不能只盯着模型本身。我的经验是：模型输出的推理能力只是一个起点，工程链路里的三个环节会把Reach慢慢吃掉。很多人觉得“Agent不给力是模型智商不够”，其实大部分真实损耗来自执行层的设计缺陷。
2.1 规划环节：开局方案就偏离了实际环境
Reach最早就容易在任务拆解这一步丢。Agent拿到任务后，第一步往往是按它对世界的理解做出一个行动规划。问题在于，它脑海中的世界图和真实环境经常对不上。
举一个我踩过的例子。当时我们做一个舆情分析的Agent，需要让它抓取指定网站的数据。模型的规划写得很好：第一周，写爬虫；第二周，清洗；第三周，生成报告。但它根本不知道目标网站的访问频率限制、页面需要登录、部分数据藏在异步接口里这些信息。结果爬到一半就被服务器拒绝，然后Agent开始反复重试同一个错误请求，一直重试到超时。
这个问题的本质是：规划并没有建立在工具的真实可用能力上。Agent对工具的描述是一回事，工具实际能做什么、不能做什么、限制条件是什么，完全是另一回事。如果你不给Agent足够多的“环境知识”——比如访问限制、字段格式、依赖关系、失败模式——它的规划就只是一个看起来合理、实际走不通的“理想路线图”。
要减少规划阶段的Reach损耗，关键不是让模型“更聪明”，而是要在任务输入阶段就把环境约束补齐。我常用的做法是给Agent提供一份结构化的“环境说明”，包括可用工具、各工具的边界条件、已知的常见失败模式。这相当于给Agent一张正确的地图，而不是让它边爬山边猜路线。
2.2 工具执行环节：接口的细枝末节损耗最多
第二块Reach损耗几乎每次都出在工具调用上。模型语言处理能力很强，但到一个具体工具的真实接口面前，它经常栽在非常小的细节上：参数名拼错了、数据类型给错了、必填字段没填、返回值里多了个嵌套层级、分页参数没处理、时区格式不一致。
做过一个很典型的例子：一个Agent需要调用组织内部的工时统计API，接口文档写得很完整，Agent也“读懂”了，但调用时它把日期格式传成了标准ISO格式，而接口只认习惯用的“YYYY/MM/DD”，结果连续三次都返回“参数校验失败”。它甚至没有意识到错误信息里已经告诉它正确格式是什么，只是一遍一遍地重试同一个错误调用。
这个问题的根因在于，大多数情况下Agent是通过自然语言描述来“理解”工具的，但工具的契约其实是严格的、结构化的。自然语言有歧义，接口参数却一点歧义都不能有。我后来把工具定义改造成“契约式”的：每个工具入参、出参都用严格的JSON Schema写清楚，并在工具描述中直接附加一个成功调用的示例。改动之后，这一类的Reach损耗直线下降。
如果工具是内部API，你还可以在契约里加一层“宽容性校验”：对日期格式、字段别名做规范化处理，把“比较宽容”的部分留在底层，让Agent少操一点心。这一步不花多少功夫，但能显著提高工具执行链路后半段的稳定性。
2.3 上下文环节：Agent的“工作记忆”被污染
第三个吃Reach的大户是上下文管理。多步任务跑起来之后，Agent面对的不再是“一条用户指令”，而是大量中间产物：查询结果、错误日志、推理片段、历史对话。这些东西如果堆在一起带着跑，会出现两种典型的“记忆病”：
- 关键信息被淹没。原始任务目标还挂在消息列表的第一条，但几十步执行之后，Agent的注意力被大量中间输出占满，模型开始“忘记”最终要交付的目标是什么。它会沉浸在当前子任务的细节里，越走越偏，最后产出一个局部正确、整体跑偏的结果。
- 错误信息持续污染。一次工具调用返回了一个异常堆栈，Agent没有清理掉这段内容，后续每一步决策都被这个异常带着跑，最终把错误信息当成已知事实，甚至编造出并不存在的“修复结果”。
把上下文比作办公桌非常贴切：一个Agent的工作桌上堆满了旧笔记、废纸和咖啡渍，它再聪明也难以在桌上写出一份整洁的答复。上下文管理的本质，就是给Agent开辟一个干净的“工作台”，把当前目标、当前任务状态、最近一次执行结果放在显眼位置，把历史噪音归档到外部存储。
这里也是Reach和单纯的上下文窗口长度产生分歧的地方。上下文窗口再大，也只是让Agent“看到更多”，不代表它“组织得更清”。哪怕模型支持200k的上下文，只要信息组织得混乱，Reach依然会被压缩。真正有效的手段是设计专门的状态管理模块，用结构化摘要定期压缩历史信息，只保留与当前目标有关的要素。
在实际工程里，这三个环节的损耗经常会叠加。规划一开始就偏了，执行中工具反复报错，错误日志又污染了后续推理，三个问题会互相喂养，最终Agent在一个非常浅的任务深度上就彻底放弃。这也是为什么我认为Reach值得被当作一套系统的指标来审视，而不是靠“加几个few-shot示例”来碰运气。
3. 给Reach装上量尺：用任务树和四个指标评估Agent能力边界
前两节讲的都是“Reach为什么重要、在哪里丢掉”，这一节说怎么把它量化出来。没有量化之前，团队讨论都是“感觉提高了”“感觉还是不行”，没有任何说服力。我把评估方法整理成一个可抄回去的小框架，不需要太重的基础设施，跑一轮评测脚本就能得到一组可对比的数值。
3.1 把任务拆成树
Reach量化第一步，是把一个目标任务表示成“任务树”。这个思想脱胎于传统的层次任务分解：一个根节点代表最终交付物，它的下一层是若干必须完成的子任务，每个子任务下面还能继续拆成更细的叶子任务，直到叶子是“可被Agent单步执行”的动作。
比如“生成月度销售分析报告”可以拆成“读取销售数据”、“计算同比环比”、“绘制趋势图”、“生成结论建议”、“按指定格式输出文档”五个一级子任务；“读取销售数据”又可以拆成“连接数据库”、“执行查询”、“校验无缺失”三个叶子任务。叶子任务越接近“单步可执行”，评估结果越能反映Agent的真实执行力。
我在评估时不会先要求Agent做一次性规划，而是直接把这些叶子任务做成一个清单，观察Agent能否自主完成全部路径。这样做的好处是：你能同时观察它的规划能力（是否选择正确顺序）、执行能力（每个叶子做没做出来）、恢复能力（一个叶子失败后能否调整）。
3.2 四个可以直接算出来的指标
围绕任务树，我用四个指标描述Reach，每次跑完脚本后统一输出：
- 最大可达深度：从根节点出发算起，Agent能连续完成多少层节点。这个指标衡量任务深度上的“天花板”。
- 叶子覆盖率：成功完成的叶子节点数除以总叶子节点数。覆盖率低于100%，说明有子任务被跳过或没做完。
- 路径完整率：按照任务树的一个完整路径，从根到某个叶子都成功，算该路径通过。完整通过路径数除以总路径数，反映“从头到尾一路走通”的能力。
- 失败恢复率：叶子节点第一次执行失败后，Agent不靠人工干预、自己完成修正并最终成功的比例。这是恢复能力的直接数值。
在实际计算中，我不建议只看单个指标。最大深度高但覆盖率低，说明Agent“能做长链路但是会漏任务”；恢复率高但深度低，说明Agent能纠错但规划上限不高。只有四个指标放在一起看，Reach的长短板才会清晰暴露出来。
下面是一个简化的Python评估脚本，演示如何根据一轮评测过程中记录的轨迹数据，计算这四项指标。实际使用时，你只需把Agent执行过程中产生的“成功/失败/重试”事件按任务树节点记录下来，喂给脚本即可。
# -*- coding: utf-8 -*- """ 输入: node_depth: 每个节点深度（根节点深度为0） all_leaves: 叶子节点总数 done_leaves: 成功完成的叶子节点数 path_success: 完整路径成功数 path_total: 路径总数 recover_success: 首次失败后自动恢复成功的次数 first_fail_total: 首次失败的总次数 输出: reach_metrics: 包含四个指标的字典 """ def compute_reach_metrics(node_depth, all_leaves, done_leaves, path_success, path_total, recover_success, first_fail_total): # 最大可达深度：取成功完成的节点中最大的深度 max_depth = max(node_depth.items(), key=lambda x: x[1] if x[0] in done_leaves else -1) max_reachable_depth = max_depth[1] if max_depth[1] >= 0 else 0 # 叶子覆盖率 coverage = done_leaves / all_leaves if all_leaves else 0 # 路径完整率 path_completion = path_success / path_total if path_total else 0 # 失败恢复率 recovery = recover_success / first_fail_total if first_fail_total else 0 return { "max_reachable_depth": max_reachable_depth, "leaf_coverage": round(coverage, 4), "path_completion_rate": round(path_completion, 4), "recovery_rate": round(recovery, 4) } # 用法示例 if __name__ == "__main__": # 假设一场评测中，叶子总数20，成功完成16个； # 完整路径69条里通过了51条； # 首败发生的次数为10次，其中自动恢复成功7次 metrics = compute_reach_metrics( node_depth={"gather_sales_data": 1, "run_query": 2, "plot_chart": 1, "write_report": 1}, all_leaves=20, done_leaves=16, path_success=51, path_total=69, recover_success=7, first_fail_total=10 ) print(metrics)我实际跑下来，这套指标有两点特别值得注意。第一是“叶子覆盖率”对真实业务最敏感。很多Agent在演示里表现良好，一到真实业务就漏数据源、漏审批、漏邮件发送，这些本质都是覆盖率下降，但传统评测根本不会告诉你。第二是“失败恢复率”，它直接决定了Agent在前半程出错后还能走多远。恢复率低于0.3的Agent，哪怕模型再强，也不能放上生产链路，因为一次随机波动就能把它卡死。
3.3 用Reach曲线代替单点指标
单轮评测得到的四个数值仍然受随机性影响，我建议的做法是跑多轮，然后把结果画成一条衰减曲线：横轴是任务深度（或任务复杂度），纵轴是完成率。这一做法是从“压测”思路移植过来的——不是问“Agent能不能做”，而是问“Agent在多大的复杂度下还能保持稳定”。
举个例子，同样是电商客服智能体，让它处理“退款咨询”这种轻任务时，二十轮里十九轮成功；加进“多包裹合并退款”之后，成功率掉到一半；再加进“与外部支付渠道对账”这个子任务，成功率直接跌到0.3。这条曲线一出来，问题一目了然：Agent的Reach存在明确边界，边界之后就是崩溃区。你不需要去辩论“Agent聪不聪明”，只需明确“它的操作安全区和风险区分别在哪里”。
画这条曲线不需要额外搭建平台，我自己就是拿评测脚本批量运行，把结果导成表格，再画个折线图。成本很低，但对项目排期的帮助极大：哪些任务必须加人工兜底，哪些任务可以放全自动，全看这条曲线在哪一段。
4. 一次周报Agent优化实录：Reach从0.35提到0.78
指标归指标，没落到具体优化上就是纸上谈兵。这一节我复盘一个真实优化过程：一个自动生成项目周报的Agent。它在最初版本几乎不能用，四个Reach指标都很惨，经过两轮整改后回升到可上线状态。整个过程很典型，可以用来对照检查你自己的Agent。
4.1 初始状态和问题表现
我们的周报Agent需要完成的任务不算复杂：每周从内部工时系统、Jira、Git仓库和三份业务Excel表里读取数据，根据项目进度状态生成一篇包含本周产出、风险点和下周计划的周报，最后发送到项目群。
最初版本的执行链路是：
- 调用工时统计API，获取各成员本周工时
- 查询Jira，获取本周完成和进行中的任务
- 读取Git提交记录，统计代码变更
- 解析三份Excel表格，提取里程碑状态
- 汇总以上数据，调用大模型生成周报文本
- 发送到IM机器人
只看形式，这条链路设计得很合理。但真实运行起来，二十轮评测只有七轮完整跑通，Reach综合评估约0.35。主要表现是：一半的任务卡在第二步或第三步，还有几次是数据都读齐了，但生成的周报漏了某个项目章节，最后发了出去。后一种问题最危险，因为它表面上是完整的，实际内容残缺。
4.2 损失点的排查与定位
我没有急着改提示词，而是先把二十轮评测轨迹逐条过了一遍，把每个节点的失败次数标在任务树上。结果非常直观：
- “读取Git提交记录”这个节点失败了9次，是所有节点里失败率最高的。原因不是Agent不会调Git，而是内部Git服务在特定时间段返回了一个自定义的“限流”错误码，Agent没有识别这个错误码的含义，一直在用同样的参数重试。
- “解析Excel”节点失败5次，原因是其中一张表里有一个合并单元格，读取结果在某个字段上出现了列表嵌套，Agent把这个异常值当成了正常值塞进周报，导致后续文本生成出现幻觉性描述。
- “查询Jira”节点失败3次，原因是Jira的分页参数必须从响应头里取，Agent直接从响应体里找，找不到就开始编造“下一页不存在”的结论。
- 根治这些问题的关键，不是换更强的模型，而是让Agent在处理异常返回时“知道该怎么做”。我意识到，Reach损耗不只是模型能力的问题，更是底层工具可诊断性的问题。
4.3 三类修复动作
基于排查结果，我做了三个改动：
第一，给所有外部工具的返回信息加上显式的“状态类别”。在工具返回的JSON里，不只是给一个“success/fail”字段，而是给出具体错误类型码，比如限流（rate_limited）、数据格式异常（format_error）、分页缺失（pagination_required）。Agent看到错误类型码之后，能直接触发对应的处理策略，而不是靠猜。
第二，在Excel解析前增加一层“数据清洗校验”。遇到合并单元格或空值，清洗逻辑会把表格结构归一化，并给Agent提供一个干净且可预期的视图。同时在Agent的指令里明确要求：发现解析异常时，优先报告异常而不是自行填空。
第三，在任务链中增加一个“中间校验节点”。每个子任务完成之后，Agent需要生成一行结构化摘要，内容包括该子任务是否成功、数据形状是什么、是否影响最终周报。这不仅是给人看的，也是给后续阶段用的：后续生成文本的时候，可以用这个摘要来对照，避免漏章节。
这三个改动跑完，同一批二十轮评测里成功跑通十五轮，Reach综合评估升到0.78。效率的提升很明显，但更让我在意的变化是：那些失败的任务不再是“完全中断”，而是大多卡在一个可诊断、可定位的节点上，人工接手成本大幅下降。这一点对于生产系统极其关键——不是所有失败都必须自动解决，但所有失败最好都能让人类秒懂发生了什么。
提示：优化Reach时，我最大的体会是“先诊断后开药”。如果不在任务树上标注失败点，你根本不知道应该修工具、修上下文还是修模型提示。做评估不是为了打分，而是为了定位。
5. 想把Reach做大，我在工程侧用的四板斧
做完一次专项优化之后，我把能够稳定提升Reach的工程手段做了个总结。这些手段不依赖特定模型，适配各种常见Agent框架，核心思路都是减少执行链路上的不确定性。
5.1 反馈闭环：让Agent每做一步都自检成败
很多Agent失败，是因为它在“盲走”：又完成了一步，但不知道这一步做得对不对，硬着头皮往下走，最后错误累积到不可收拾。解决这个问题最直接的办法，是在每个子任务结束后，强制Agent生成一个结构化的执行报告，包含三个字段：
- 这一步的目标是什么
- 实际得到的结果是什么
- 结果与目标是否匹配，不匹配的原因是什么
这三个字段其实就是给Agent装了一个“血压计”。它可以很短，但必须有。我在实践中发现，即便只是强制输出这三行字，Agent后续步骤的决策质量都会提高，因为它在每个节点都被迫校准了一次自己的判断。
这个机制也相当于给人类观察者留了检修口。Agent哪一步开始跑偏，从结构化执行报告里一眼就能看到，不用去翻几万字的中间日志。
5.2 分层记忆：把短期工作区从长期档案中分离
Reach的上下文损耗本质上是“记忆管理失败”。比起一股脑把所有中间输出塞进上下文，我建议把Agent的记忆分成两层：
- 工作记忆区：保存当前任务的“最近状态”，包括最近一次工具返回值、当前子目标、已完成的子任务清单。这个区域要保持极简，最好只有几百个token的量级，随时能被模型看到。
- 长期档案区：保存历史执行记录、旧数据查询结果、上次任务的完整报告。这些内容不应该默认出现在上下文里，而是在需要时通过检索调用。
我自己的简化实现是一个嵌入向量库。长期档案写入向量库，工作记忆区保存向量库返回的Top-K相关摘要。这样Agent既不会忘记历史经验，也不会被历史噪音干扰当前目标。如果你用的是现成Agent框架，可以找一个支持外部记忆插件的方案，避免所有历史全部堆在主上下文里。
一开始做这个改动时，我刚拿到Spark环境的一个项目上，效果立刻体现在“可诊断性”上：那些在几轮之后出现的幻觉判断，大部分都能在工作记忆区找到原因——要么是某个关键值没有被写入，要么是检索到了不相关的旧记录。只要记忆分层清楚了，绝大多数上下文问题就有了下手修的地方。
5.3 工具契约：能让接口“傻瓜化”就绝不自由发挥
第三个板斧是对工具的接口定义做“防御性封装”。原则是：不要让Agent面对一个需要猜测参数格式、解析复杂返回值的工具，尽量把复杂性封装在一层薄的适配器里。
具体做法包括：
- 所有时间参数统一成同一种格式，内部适配器负责转换。
- 返回体统一成一个规范结构：status、error_code、data、meta。
- 异常信息要写明“下一步建议”，而不仅仅是报错堆栈。
- 对非标准数据源做预处理归一化后再暴露给Agent。
这里有一个成本权衡：封装工具层需要额外开发，但ROI非常高。Agent每调用一次工具，就减少一次因接口细节出错的可能性。你自己想一想，如果一个Agent在调用工具时90%的问题都出在格式差异上，那你把格式吞到适配器里，等于直接把Reach的基数扩大了一大截。
我见过很多团队反感“打磨工具”，觉得“工具能用就行，重点是模型”。但我的实测结论恰恰相反：在同一个模型下，工具契约清晰度和Agent-Reach几乎成正比。工具层透传原生API，和做一个封装后的“傻瓜接口”，最终任务成功率可以相差一倍。
5.4 降级策略：主链路走不通时要有备选路径
Reach不应该只在“一切顺利时”成立。真实链路里，外部服务总会有波动，数据总会有对不上的时候，配置总会被改坏。这时一个没有降级策略的Agent，就像一个不带备用轮胎的司机，爆胎就只能停路边。
我建议在设计任务树时，为每个关键子任务标注一条降级路径。举几个例子：
- 主数据库连不上的时候，降级到缓存库或离线快照。
- 主工具返回格式异常的时候，降级到用简单规则抽取关键字段。
- 核心依赖彻底不可用的时候，降级到输出“当前无法获取该数据”的显式占位提示，而不是编造数据。
降级路径的设计原则不是“用低级方案替代高级方案”，而是“宁可结果不完整，也不要过程造假”。因为Agent一旦开始编造缺失数据，最终交付物的可信度就归零了。我见过太多失败项目，问题不是Agent“不够能干”，而是它“在不能干的时候不肯承认”，这一步降级策略能救回来不少悬案。
这个策略还有一个额外收益：它会逼着你在设计阶段把“这个任务到底哪些数据是刚需、哪些是锦上添花”想清楚。很多Agent任务的边界不清，就是因为你根本不知道缺失了某个数据源会导致什么。
6. 一个容易被忽略的结论：Reach不需要无限大
聊完评估和优化，我想收敛一下：不是所有场景都要追求把Reach推到极限。这个问题很多人没想清楚，结果把一个周报工具硬是调成六个微服务加三个向量库的“巨兽”，最后ROI非常难看。
6.1 每提升一截Reach，背后都有隐性成本
我实际评估过一种情况：一个任务原本在“调用外部API获取天气并生成建议”这个深度上已经做到0.95成功率，有人非要再加一步“自动对比历史天气趋势并生成异常分析报告”。为了这一步，团队多接了数据仓库、写了额外的清洗逻辑、增加了一轮模型推理，成功率却因为多了一个环节降到0.85。
这个例子想说明的是，Reach每上升一段，新增的每一步都带来新的不确定性来源。技术上能做到“更长链路”和业务上“需要那么长链路”是两回事。很多任务的用户真实需求深度只有两三级，硬要做到六级，反而会引入更多故障点、更多延迟和更复杂的排查链路。
我在项目中定了一个“Reach预算”的思路：先根据业务需要，确定哪些任务必须全自动、哪些必须人工确认、哪些可以半自动。然后只对这些必须全自动的任务做高Reach优化，其他任务控制在“失败时能快速转人工”的程度就够了。这样资源投入有主次，系统的整体可维护性也更健康。
6.2 从实际使用中得到的建议
如果让我给一个刚接触Agent-Reach概念的团队列三条建议，会是这样的：
第一，先跑两轮评估，把Reach四个指标测出来，再决定要不要优化。很多团队上来就调整提示词，连失败分布都不知道，这是舍本逐末。先花半天时间把轨迹数据打点清楚，省下的调试时间往往是以天计算的。
第二，优先修复“恢复率”，而不是“最大深度”。一个能在失败后自动恢复的Agent，哪怕深度一般，也可以比较稳妥地放在生产环境里；反过来，一个“能一次跑通但一遇到异常就死掉”的Agent，只适合Demo，上线就出事。恢复能力是生产级Agent的底线工程。
第三，把工具契约封装当成第一类优先级需求来排期，而不是“有空再优化”。在我的经验里，工具层优化带来的Reach提升，比换更强模型带来的提升更稳定，也更可控。模型可以换，知识可以更新，但一套设计良好的工具契约能长期压低执行链路的失败率。
Reach这个视角本身并不复杂，它就是提醒你：Agent不是一段“输入输出”的黑盒，而是一段需要持续维护的执行长廊。你在哪个环节为它搭好了护栏，它就能在哪个环节多走一步。能做到“每一步都可靠”，已经比很多“一步超神、五步翻车”的Agent方案强得多了。
