说实话“Agent-Reach”这个词第一次出现在我面前的时候我琢磨了好一会儿。近两年AI圈里带“Agent”的名词实在太多了什么Agent框架、Agent编排、Agent记忆加上Reach这个后缀乍一看像个新框架的名字仔细一琢磨它其实讲的是一个非常务实、也非常痛的问题你的智能体到底能“够到”多远的东西我见过太多这样的项目——对话能力惊艳四座一问一答行云流水可真让它去查一条数据库记录、调一个内部API、读一份PDF里的某个合同条款它立刻就“断手”了。Agent-Reach的核心就是把这个“够到的能力”拆开、量化、落地。它解决的从来不是“模型聪不聪明”而是“手能不能伸到数据、工具、系统和人那里”的问题。这篇文章我就从自己的实操经验出发把Agent-Reach到底在讲什么、四个触达层怎么拆、一个最小闭环怎么搭、以及我踩过的坑完整捋一遍。正文大概会有点长但这话题确实值得一次讲透。不管你是在做企业内部Copilot、自动化流程、还是多智能体协作系统Agent-Reach这套思路都能直接套进去用。1. 核心思路先想明白“够得着”和“够不着”的差距在哪1.1 一针见血你的Agent为什么一干活就“断手”先把Agent-Reach这句话翻译成人话Reach这个词在工程语境里指的是“可达范围”。一个智能体的Reach就是它能够触达的全部外部资源的总和——文件、数据库、API、内部系统、其他Agent、甚至真实世界里通过硬件操作的东西。我刚接触这个方向的时候第一反应是这有什么好讲的给Agent装上工具不就完了吗真上手之后才发现“装工具”三个字能引出一连串我完全没预料到的问题第一光有工具的“接口”远远不够。你的工具列表列了一百个API可Agent不知道每个API背后是什么业务逻辑、什么参数含义、什么调用约束。就像给了人一个工具箱却不说清哪个扳手是拧哪种螺丝的结果就是Agent凭感觉瞎猜猜一次错一次。第二触达不是单向的。真正的“Reach”意味着Agent不仅要能主动调用外部资源还要能被外部资源触达——回调、事件推送、异步任务状态同步甚至多Agent之间互相传递信息。我最早做的几个Agent系统全都死在这个点上Agent调完一个工具要么卡在等同步响应要么工具回传完结果之后Agent直接忘了下一步该干什么。第三距离越远成本越高。这个“距离”不只是网络层面的延迟还包括上下文成本、权限隔离成本、状态同步成本。我见过团队为了一个RAG查询把几十万字的资料全部塞进上下文结果一轮对话下来token费用顶得上普通人一天的话费账单——这种Reach是“硬够”不是“够得快”。所以Agent-Reach这个概念本质上是帮你把“触达能力”从玄学变成工程。它要求你回答几个非常具体的问题Agent知道有哪些资源可以用吗它知道什么时候该用哪个资源吗它调用资源的过程安全吗它在多轮交互里能持续保持对资源状态的感知吗不解决这些问题你的Agent永远是隔靴搔痒。1.2 四个触达层知识、工具、系统、协同把上面那堆问题拆开Agent-Reach在实践中会清晰地分成四个层面每个层面解决一类“够不着”的痛点也对应一套不同的技术栈。这样拆不是学术上的洁癖而是你在设计架构时必须分而治之——不然一旦出了问题你连查都不知道从哪查。知识触达层解决的是“Agent知道什么”。模型训练时学的知识是静态的、过时的而企业里真正有用的信息都在数据库、文档库、告警系统里躺着。这一层要解决的核心问题是怎么让Agent在回答问题时能实时、精准地“想起”这些外部知识——也就是RAG检索增强生成这一套切分、向量化、召回、重排、再喂给大模型。工具触达层解决的是“Agent能做什么”。一个只能聊天的Agent永远只是个聊天机器人能给Agent接上数据库查询、API调用、脚本执行这些“手”它才能干活。这一层的难点在于工具的描述方式——你要让模型读懂API是干嘛的参数怎么传才能不炸返回结果怎么处理才能继续下一步。系统触达层解决的是“Agent敢不敢进系统”。企业内部有ERP、CRM、知识库、告警平台……Agent能连上这些业务系统才算真正进入了生产环境。这一层拼的是安全性和权限控制——能读哪些库、能写哪些表、操作之前要不要审批、操作日志放哪里全部要提前设计。协同触达层解决的是“Agent之间怎么协作”。复杂任务往往不是单个Agent能搞定的——一个负责理解需求一个负责查数据一个负责生成报表。这一层要解决的是消息传递、任务路由、结果合并以及最容易被忽视的“上下文接力”前一个Agent的结论如何无缝传给后一个Agent继续用。这四个层不是孤岛。知识触达是地基工具触达是抓手系统触达是门槛协同触达是放大器。你做的Agent能触及多少个层、每层触及得多深直接决定了它的实际战斗力——这也是我用Agent-Reach这个词来概括整套能力框架的原因。2. 核心技术点拆解四层触达分别怎么实现2.1 知识触达让Agent在关键时刻“想得起”知识触达落地最常用的方案就是RAG流程本身不复杂拿文档切段向量化存向量库用户提问时做相似度检索把命中的片段拼进Prompt让模型参考这些内容回答。听起来简单做起来处处是坑我按踩过坑的先后顺序列一遍。分块策略直接决定召回质量。我最早做知识库的时候简单粗暴地按固定字符数切段每段512个字。结果就是一个合同文件被拦腰切成好几段模型一检索前后文关系断裂得一塌糊涂。后来换成按语义边界切比如Markdown标题、段落、列表项召回准确率明显上来了。分块大小我也做过测试小分块128-256字符适合问答场景因为命中的内容更聚焦大分块512-1024字符适合摘要场景因为上下文更完整。没有万能参数必须按你实际业务的数据形态调。召回策略上必须上重排Rerank。纯向量检索的短板是“语义相关”≠“答案相关”。举个例子你问“这个季度的退款政策是什么”向量检索可能捞出来一堆讲“退款流程”“退款时效”的文章但真正的政策条款原文排在很后面。加了Rerank模型之后它会对候选段落做二次排序把真正能回答问题的那段顶到最前面去这一下命中率大概能从60%涨到85%以上。这不是玄学Rerank模型本身就是专门训练出来做“问题-段落匹配度”打分的比纯向量相似度靠谱得多。Embedding模型的选型也值得多花心思。通用embedding模型对中文长文本、专业术语的理解往往不够。我实际对比过几个方案用领域微调过的embedding模型对专业词汇的召回效果明显好过通用模型。如果你的知识库是密集技术文档、法律合同这类专业内容强烈建议专门评估一下领域embedding别拿通用模型凑合。2.2 工具触达让Agent在需要时“调得动”再强的知识检索也只是让Agent“会说话”工具调用Function Calling才是让它“会干活”的关键。目前主流的实现路径就是给模型定义一批JSON Schema格式的函数声明模型根据用户意图决定调用哪个函数、传什么参数然后由你的业务代码真正去执行函数把结果返回给模型继续生成答案。这里最核心的工程实践我总结成一句话工具描述要像给小学生写说明书一样写。我见过太多人把工具描述写成一句话“get_order_info根据订单号获取订单信息”。模型不是人它对“订单号是什么格式”“返回结果里status字段有哪几种取值”“这些取值分别代表什么状态”完全没有概念只能瞎猜。一个合格的工具描述至少要包含这几个维度功能的边界说明这个工具能做什么、不能做什么参数的完整定义类型、格式、允许的取值范围、必填还是选填返回结果的说明关键字段的业务含义、可能的异常情况使用场景提示什么时候该用这个工具跟其他工具怎么区分我以前做过一个订单查询Agent刚开始工具描述太简略模型老把“user_id”当订单号传给“订单查询”接口传了十次错十次。后来我把描述改成“user_id是用户唯一标识格式为8位数字订单号order_id是20位字母数字混合以ORD开头”一次错都没再出过。写工具描述这十分钟的功夫省下的是上线后无数个故障工单。工具如果多了还需要做工具路由和工具分类。比如你有五十个工具函数总不能全塞给模型让它自己挑——一是上下文会爆炸二是函数多了模型决策的准确率会直线下降。我自己常用的方案是先做一个“工具路由器”用一个轻量分类模型或者规则引擎先把用户意图映射到某个工具分组再把该组的三五个工具定义传给主模型。这把“五十选一”的难题直接降维成“三选一”调用准确率肉眼可见地上去了。2.3 系统触达让Agent安全地进入生产环境知识触达和工具触达更多是“开发环境里的技术活”系统触达则直接把Agent扔进了生产环境。这里面的风险一下子高了好几个数量级。一个写错参数的API调用可能把一条真实订单改错一个没加权限控制的Agent可能让任何人都能读到机密数据。所以系统触达层我首先聊的不是怎么连而是怎么敢连。最小权限原则在这里不是一句口号。Agent能读什么库、能写哪些表、能调用哪些接口必须由统一网关控制而不是让Agent裸奔在数据库连接串上。我实际搭建的方案里Agent对外部服务的所有访问都走一层API网关网关做三件事身份认证Agent是谁、权限校验这个Agent允不允许做这个操作、审计日志所有操作留痕。这样即便Agent抽风调错了接口网关也能把它拦下来不至于直接打进生产数据库。敏感操作必须加双重确认。涉及到写操作、删除操作、资金操作这类高风险的调用我强制要求Agent先输出一个“操作意图声明”由人工确认之后才真正执行。这看起来降低了自动化程度但换来的是可控风险——尤其在金融、医疗、企业后台这类场景里没有这个确认环节根本不敢让Agent放手干。审计日志是最后一道防线也是排查问题最快的入口。每次Agent调用外部系统我要求记录哪个会话、哪个Agent、调了哪个工具、传了什么参数、返回了什么结果、耗时多久、最终成败如何。有了这张全链路日志表后面排查所有“为什么Agent干错事”的问题效率都会高一个量级。没有审计日志你可能连Agent那天干了什么都不知道。2.4 协同触达让多个Agent形成“流水线”单个Agent的触达能力终归有限所以Agent-Reach的另一半是多Agent之间的协同触达。说白了就是让多个Agent像流水线上的工人一样协作传递半成品、交换信息、一个干完传给下一个接着干。这里涉及几个关键设计点。任务编排是骨架。你得先定义清楚一件事这个复杂任务应该拆成哪几步每步由哪个Agent执行前一步的输出怎么变成后一步的输入我常用的两种模式是“流水线式”和“路由器式”。流水线式适合步骤明确的固定流程比如“理解需求→查数据→生成报告”路由器式适合一个复杂的请求进来先判断它属于哪类任务再分发给对应的Agent处理。两者的区别就像工厂里的固定生产线和人工分拣站前者稳定高效后者灵活应变。消息通道和状态同步是最容易翻车的地方。我最早做多Agent协作直接用同步HTTP调用来互相传结果结果一个Agent超时就把整条链卡死了。后来改成消息队列比如Redis Stream或者RabbitMQ每个Agent异步消费任务消息、处理完把结果写回队列主流程不再等待链路的健壮性一下就上来了。另外一个实践是定期做任务状态持久化——每个Agent处理完一步把当前进度、中间结果、下一步计划都写进状态存储这样任何环节挂了都能断点续传不用整条流水线重来。上下文接力是效果的关键。多个Agent协作最大的信息损耗出在“前一个Agent的结论如何传给下一个Agent”。直接把大段原始文本塞给下一个Agent既浪费token又容易信息过载。我一般会在这一步插入一个“摘要Agent”把前序输出压缩成结构化摘要——关键数据、结论、待办事项、风险提示——下个Agent基于摘要继续干活效果远好于把所有历史一股脑传递下去。这就像工厂流水线上传的不是整箱零件而是一张清晰的图纸。3. 实操全流程一个具备Agent-Reach的最小闭环怎么搭光讲概念不落地方都是纸上谈兵。这节我直接用一个我近期做过的真实小项目来做演示一个面向企业内部客服团队的“智能工单处理助手”。需求很简单客服人员扔一个问题进来Agent要能判断这是什么类型的问题去企业知识库找答案如果涉及订单信息还要实时查订单系统最后生成一个处理建议草案发给人工复核。3.1 整体的系统架构与模块划分这个项目规模不大但已经覆盖了前面说的四层触达很适合作为参考模板。整体拆成五个模块入口与意图识别模块接收客服输入判断问题类型售前咨询、订单问题、售后退款、知识询问等知识检索模块对应知识触达层负责从企业文档库中检索相关文档片段工具调用模块对应工具触达层封装订单查询API、退款政策查询API由模型按需调用权限网关与审计对应系统触达层所有工具调用都经过网关检查与记录多Agent编排对应协同触达层主Agent负责任务理解和总结专门的知识Agent负责检索工具Agent负责调用API最后汇总模块划分完之后关键是设计好每个模块之间的接口——特别是Agent和工具之间的调用协议。我用的是标准的Function Calling格式也就是JSON Schema定义工具函数模型负责决定调用哪个业务代码负责执行。3.2 关键参数怎么定别拍脑袋算一算几个最关键的参数我详细说一下我的取值逻辑你可以根据自己的业务场景调整。知识库分块大小我最终选了350字符左右的分块大小。原因是这个知识库里的文档大多是对外公告和政策条款350字符大约对应2-3个自然段既能包含完整的语义单元又不会因为太长导致命中信息不聚焦。如果你们是长报告类文档建议512到800如果是短问答对128到256更合适。没有绝对但总得有个出发点然后根据召回率测试迭代。检索召回数量top-k我设为5。这里有个权衡召回太少容易漏掉关键信息召回太多会让喂给模型的上下文膨胀。5个片段、每个约350字合计大约1750字大概折合1500个token左右这个量级对上下文压力不大也给Rerank留下了充足的候选池。Rerank之后我再取最高的2-3段喂给模型这俩参数配合着用效果最好。相似度阈值0.35。这是指向量检索阶段的最低相似度门槛低于这个分数就直接判“知识库里没找到”。阈值设高了容易漏召回Agent会说“我不知道”设低了会召回一堆不相关的内容带偏模型。0.35是我在当前embedding模型下测出来的一个相对稳的值你要是换了embedding模型这个值一定得重新测。工具调用的超时时间我统一设了15秒。为什么是15秒订单查询API的P95延迟约5秒加网络开销和模型决策时间15秒足够覆盖绝大多数情况再长的话用户体验就非常差了用户会以为Agent卡死了。超时之后Agent会走“能力降级”路径明确告诉用户“当前系统暂时繁忙请稍后再试”而不是傻等。上下文预算我给单轮对话设置的上下文上限是14000个token。粗算一下系统Prompt约1500 token工具定义约2000 token检索返回的知识约1500 token公司历史对话和场景信息约5000 token留给模型生成的余量约4000 token——这样单轮不会撑爆大多数主流模型的上下文窗口也能控制成本。3.3 工具接入实战以“订单查询”为例订单查询是这个Agent最核心的动作我拿它的实现过程完整走一遍。先定义工具Schema下面是精简过的示例{ name: query_order_by_id, description: 根据订单ID查询客户订单信息。当用户询问订单状态、物流信息、付款金额等具体订单相关问题且提供订单号时调用此工具。, parameters: { type: object, properties: { order_id: { type: string, description: 订单号20位以ORD开头的字母数字组合例如ORD2026050001 } }, required: [order_id] } }这段描述看起来简短每一句都有用意。开头的“description”明确了工具的用途和使用场景帮助模型在“该不该调用”这个决策上少犯错参数的“description”用了格式和一个示例模型就不会再传错格式。我当时还特意测试过加了“订单号是ORD开头”这句话之后模型把用户ID当订单号传给这个工具的错误率直接降到了零。模型决定调用工具之后真正执行业务动作的是我们自己写的服务端函数。下面是Python的示意实现注意所有调用都进网关做权限校验结果里包含明确的“status”和“message”字段模型才能正确解读执行结果。import httpx async def query_order_by_id(order_id: str) - dict: # 1. 参数校验 if not order_id.startswith(ORD): return { status: error, message: 订单ID格式不正确订单号应以ORD开头例如ORD2026050001, data: None } # 2. 通过内部网关调用订单系统API网关统一处理权限与审计 async with httpx.AsyncClient(timeout15) as client: try: resp await client.get( http://gateway.internal/orders/ order_id, headers{X-Agent-ID: 工单助手-v1} ) resp.raise_for_status() except httpx.TimeoutException: return { status: error, message: 订单系统响应超时请稍后重试, data: None } data resp.json() # 3. 将原始返回整理成模型易于理解的业务摘要 return { status: success, data: { order_id: data[order_id], order_status: data[order_status], product_name: data[product_name], total_amount: data[total_amount], shipping_address: data[shipping_address] }, message: 订单查询成功返回了订单状态、商品、金额、收货地址 }这里有一个细节值得多说一句工具函数返回结果时不只是返回原始JSON还加了一个“message”字段用自然语言描述“查询成功了、返回了什么”。模型读自然语言比读嵌套的JSON快且准得多。这个小改动让Agent后续生成回答的准确率和流畅度都提升了不少。3.4 多轮场景下的上下文接力设计希望你能理解到上下文接力实际上是“Agent-Reach”在时间维度上的延伸——触达不只是单次动作还是多次动作间的状态持守。我在工单助手项目里把上下文接力做成了显式的数据结构每次对话结束都会刷新一次“会话状态快照”{ session_id: session_20260518_001, intent: order_status, extracted: { order_id: ORD2026050001 }, knowledge_hits: [退换货政策-第3块, 物流时效说明-第1块], tool_results: { query_order_by_id: success }, next_action: 生成工单摘要等待人工确认答复 }这份快照的核心价值在于多轮对话中可以继续沿用之前调用过的工具结果模型不用每次都重复调API。用户问完“订单到哪了”下一句又问“那我申请退款怎么操作”我直接把之前拿到订单ID传给退款政策查询工具全程模型都清楚自己“已经知道什么”“下一步需要什么”。这是很多初级Agent系统容易漏掉的细节——只做单轮触达没做多轮状态保持导致用户在第二、第三轮必须重头再说一遍这体验谁用谁知道。3.5 成本与性能的取舍经验运行一段时间后我发现这套系统最大的成本大头并不在模型生成的token而在于“无效检索”和“过度工具调用”。举个例子用户只是随口问了一句“退款一般多久到账”Agent居然先去查了一遍订单系统再去知识库搜了三轮花了6000多token、两次API调用才给出答案。后来我调整了两个策略一个是给工具加上“前置条件提示”在系统Prompt里明确写“只有用户明确提供了订单号或者明确表示要查询某个具体订单时才调用订单查询工具否则只回答通用政策知识”。二是给Agent增加了“低成本先答、高成本再查”的行为准则优先用系统Prompt和记忆里的通用知识回答通用问题只有问到实时、个性化数据时才启动检索或调用工具。这两条规则一出整体token成本下降了三成左右响应速度也快了不少。4. 常见问题与排查技巧实录这部分是踩坑记录。我按问题的高频程度排个序每个问题给出症状、根因和解决路径基本覆盖了Agent-Reach实践中最常见的九成故障。4.1 答非所问Agent“好像知道但答偏了”症状是最明显的问了“退货需要什么条件”Agent答非所问讲了一堆“退货流程怎么走”。最常见根因有两个。一是知识检索的召回结果不对——检索回来的片段本身就不是用户问题的答案模型只能基于错误材料生成错误答案。二是工具调用时机错了——本该先查自己的记忆模型却去调工具或者知识库拿到了无关数据自然跑偏。排查思路我按这个顺序走先看检索阶段召回的几个候选片段跟问题是否相关再检查是向量召回的问题还是重排的问题如果是模型答偏了重点看Prompt里是否明确告诉模型“用检索结果作答、不要自由发挥”。我在Prompt里加了强制要求“只依据检索和工具返回的信息来回答信息不足时明确说不知道”答非所问的问题少了一半。4.2 工具调用失败调用逻辑对但执行就报错工具调用的错误花样百出但我总结下来无非三类连不上超时、网关挂了、接口改了、参数错模型传了错误格式、字符串里带多余的空格、枚举值没匹配上、权限被拒网关拦下一般日志里能看到403。排查工具问题时我最依赖的就是审计日志和工具执行的完整链路记录。日志里能看到Agent到底传了什么参数、网关是否放行、上游API返回了什么错误码。绝大多数“工具失败了”都能在日志的前三行里找到答案。这也是我在系统触达层坚持必须记录全链路日志的原因——它不只是审计用更是排障的第一助手。4.3 RAG召回质量差明明知识库里有Agent就是“不知道”这个问题的隐蔽性很高因为错误不会直接显现。症状是Agent说“根据现有资料我无法回答”但人工去知识库里一查答案明明就在第七十页。我的排查思路集中在可能存在的四个环节嵌入阶段embedding模型没理解专业术语、切分阶段切成碎片导致上下文断裂、召回阶段top-k太小或者阈值太高把正确答案过滤掉了、重排阶段重排模型对领域文本的排序权重不合理。解决办法也是逐层优化最先做的是调整阈值和top-k这个改动成本最低见效最快然后是重新选分块策略把大段长文按语义边界切分再然后是换embedding模型或者对RAG链路做评测看是哪个环节分数最低。注意这块最忌讳的就是“凭感觉调”你最好做一个包含几十条真实问题的评测集每条都标好标准答案然后每次改动都拿评测集跑一遍召回率让数字说话。4.4 响应太慢Agent每轮都像“思考人生”Agent响应慢先分清慢在哪。我用过最有效的办法是给链路的每一步都打点计时用户输入到意图识别、检索耗时、Rerank耗时、模型生成耗时、工具调用耗时拆开之后你就知道瓶颈是哪个环节。常见情况按优先级排列模型生成太长减少生成上限和思维链长度、检索太慢向量库加索引、缩召回范围、重排太慢换更轻量的模型、工具调用慢加缓存或并行调用。我实际调过一个案例整体时延从38秒降到11秒拆解出来最大头其实是模型一次生成了1700字的“思考过程”我把生成上限截短到900字、同时把“思考”环节限制在三步内时间直接砍掉七成。别迷信“思考越长越准”Agent的思考时长和回答质量并不线性相关。4.5 问题速查表症状可能的根因优先排查方向Agent答非所问检索召回内容不匹配、Prompt缺乏约束检查召回Top5内容、Review系统Prompt回答过于泛化、没细节没触发工具调用、知识检索没命中看工具调用日志、检查分块与阈值工具反复传错参数工具描述不清晰、参数格式没说明补全工具描述、加参数示例、写枚举范围工具调用超时上游API慢、网络分段、并发过高看链路计时、加超时、做缓存降级同一问题每次答案不一致RAG召回不稳定、模型温度过高固定检索策略、调低temperature多Agent协作丢信息消息传输出错、上下文被截断检查消息队列、状态快照完整性成本快速增长过度检索、过度工具调用、输出过长加前置条件、控制上下文与生成长度5. 评估与量化不能量化你永远不知道自己的Agent“够得有多远”Agent-Reach不能只停留在理念上必须要能度量。我给自己定了一套指标每次改完架构或者调完Prompt都会跑一遍用数字确认到底有没有变好。任务完成率Task Success Rate是北极星指标用一组覆盖典型场景的测试任务看Agent能多大比例地正确完成。建议至少准备50条真实场景的任务每次都跑一遍记录完成比例。没有这个数字一切调优都是自嗨。工具调用成功率指Agent发起工具调用的次数中成功执行的比例。低于90%基本说明工具Schema写得有问题或者工具本身的稳定性不过关。知识命中率Answer Hit Rate指Agent回答中引用的信息与标准知识库答案的匹配程度。这个指标需要人工或者评判模型去比对最直接反映RAG链路的质量。平均触达时延指从用户发问到得到最终完整回复的总时间。按场景拆解后如果某个环节显著超标直接定位优化目标节点。系统覆盖率指Agent能触达的内部系统数量/总系统数量。如果你的Agent还连不上某个核心系统那Reach就是缺了一角。这个指标更多用来做能力盘点不追求100%但要让关键路径的系统都在覆盖范围内。成本效率指完成一次标准任务的平均token消耗和API调用成本。这个指标决定了你的Agent能不能规模化。我见过很多项目技术演示很成功一算账吓死人就是因为没盯着成本指标做优化。这几项指标都跟调优方向直接挂钩。任务完成率低就看哪类任务拉低的分数工具调用成功率低就逐条工具做Schema审查知识命中率低就回到检索链路做评测迭代时延高就做链路拆解找瓶颈。这套循环本质上就是把Agent-Reach变成一套可迭代、可量化的工程能力而不是不可捉摸的“智能”。6. 写在最后的一些体会Agent-Reach这套东西我越做越觉得它更像一把尺子——它不直接给你答案但能量出你的Agent到底有几斤几两。很多团队为了“智能”砸重金升级模型、堆巨量训练数据最后发现卡住项目进度的根本不是模型聪明不聪明反而是这些最基础的“触达工程”没做扎实。我个人实际操作中最大的一个体会先别急着追求Agent“什么都能干”先把一两个核心场景的触达链路做到极致——知识查得准、工具调得稳、系统接得安全、多轮状态不丢——再慢慢扩能力边界。一个能把“查订单状态”做到99%准确率的Agent远比一个什么都懂但什么都办不成的Agent有价值得多。最后分享一个小技巧每当你觉得Agent“变蠢了”先不要怀疑模型能力去查它的触达链路——是不是检索没召回正确的资料是不是工具返回的结果格式变了模型读不懂是不是权限网关悄悄把它拦住了九成以上的“变蠢”都藏在触达链路里而不是模型本身。祝你的Agent手够长路够宽脚踩得稳。