今年做AI应用我最大的感受是模型能力已经溢出但绝大多数Agent项目都死在了“够不着”这三个字上。客户要的是一个能自己查库存、比价、下单、再发通知的助手结果我交付的Agent连公司内部系统的数据都读不出来最后只能做PPT演示用。后来我把整套方案推倒重来做了一个专门解决“Agent触达能力”的项目代号Agent-Reach。这篇文章不聊抽象概念就把我在这个项目里踩过的坑、重写三版才稳定的工具调用层、以及真实压测数据一次性倒出来。如果你也在做AI Agent、智能客服、RPA替代方案或者正为大模型只能聊天不能办事发愁这篇应该能解决你一半以上的问题。1. 我第一次做Agent时“够不着”的真实教训Agent-Reach的起点先讲项目背景。去年我接了一个供应链场景的智能化需求业务方提得很具体让AI Agent根据库存水位自动补货缺货时找替代供应商并发起审批。听起来不难但真正动手才意识到Agent的能力边界根本不在模型智商上而在它能不能触达企业内部散落的系统——ERP、WMS、审批流、消息网关每一个都是独立的体系接口风格完全不一样。1.1 为什么聪明模型做不了实事我当时用的方案很粗暴把所有API的调用说明塞进Prompt让大模型自己决定“现在该调用哪个函数”。演示环境里一切正常模型能认得出函数名也能生成参数但只要把环境换到生产数据问题立刻暴露。最典型的一个场景是模型要从ERP取库存数又从WMS取在途数再结合供应商主数据去判断“该补多少”。这三步要连续调用三个不同系统但Prompt里塞了三十多个函数说明模型开始选择困难要么调用错函数要么把参数格式写错。有一次它把supplier_id传成了supplier_code下游系统直接报错整个工作流卡死。数据对比很扎眼只有5个函数时模型选对工具的成功率是92%函数超过30个时成功率直接掉到68%。而且每增加一个函数Prompt的token消耗就涨一截响应延迟从1秒拉到3秒以上。这条路走不通。1.2 “触达”应该是一个独立工程问题我后来想明白一件事人做事靠手脚去够东西Agent做事靠什么靠工具调用、靠上下文读取、靠和其他Agent协作。这三件事本质上都是“触达”Reach。传统做法是把触达逻辑散落在提示词里让模型即兴发挥这等于让一个新手司机在没有路标的高速公路上一边开车一边认路。Agent-Reach的核心思路就是把“触达”从模型对话里剥离出来做成一个独立的工程层。它负责三件事把外部世界抽象成一组稳定可控的“触达端点”把模型选工具的决策过程用规则和校验兜住把每一次触达行为记录下来方便复盘和优化。你可以把它理解成给Agent装了一副“长臂”——模型负责思考Reach层负责够东西各干各的活。2. Agent-Reach的触达层设计会话、工具与多Agent三条通路Agent要真正做事触达的对象无非三类对话里的上下文、外部系统和数据、以及其他协作单元。Agent-Reach针对这三类对象设计了三条并行的通路互不干扰又能组合使用。2.1 会话触达让模型“看得见”所有该看的信息很多Agent连已有的业务数据都“看不见”不是因为权限不够而是上下文里根本没带。Agent-Reach的会话触达层做了一个轻量级记忆管理每个业务实体会维护一个动态摘要Agent开始干活前先把与当前任务相关的摘要拉到上下文里而不是把所有历史记录全部倒进去。我用一个零售库存场景举例。Agent被问到“A商品还能卖几天”它需要知道日均销量、库存余量、采购在途量。这些数据分散在三个系统里传统做法是把这三张表都喂给模型。Agent-Reach的做法是先把原始数据处理成一条结构化摘要再附上数据来源和时间戳让模型既拿到答案也拿得到可靠依据。这样上下文占用从2000多token降到了300多token回答准确率反而更高。2.2 工具触达把API包装成“可信端点”这是Agent-Reach最核心的部分。它不要求模型懂API细节而是把每个业务操作包装成一个端点端点声明自己需要什么参数、返回什么结构、有哪些限制条件。模型只需要从“端点目录”里选择参数校验和错误处理全部由触达层接管。我们做了一个工具描述规范核心字段包括工具名称、一句话说明、入参Schema、出参Schema、访问级别、超时设置。模型被约束为只能看名称和说明来做选择等选中之后参数解析走的是程序化校验不靠模型自由发挥。这一步看起来简单实际效果立竿见影工具选择准确率从68%回到了93%以上。2.3 多Agent触达协作时“谁找谁、怎么找”要有约定单Agent能做的事情终究有限。我测试过一个采购流程一个Agent管需求分析一个Agent管供应商寻源一个Agent管合同生成。三个Agent各有专长但它们之间如果只靠“聊天”协作信息损耗特别大。Agent-Reach的多Agent触达层给每个Agent注册了能力清单和消息格式协作不再靠自然语言聊天而是走结构化消息总线——A Agent发出“寻源请求”里面带上商品类目、数量、交期、预算B Agent消费这个请求处理后返回候选供应商列表和评分依据。整个过程消息结构固定任何一环出错都能快速定位。3. 工具调用层重写三版之后才稳定的核心实现我估计很多团队会走到我原来的老路上先试自然语言直连再试JSON Schema最后才想到要做独立触达层。下面把我在Agent-Reach里最终稳定运行的实现拆开讲每一步都附上为什么这么做。3.1 第一版函数全暴露模型自己挑——失败典型第一版代码看起来很美functions [ { name: get_stock_quantity, description: Get stock quantity by sku, parameters: { type: object, properties: { sku: {type: string}, warehouse: {type: string} } } }, # 共30个函数... ] response llm.chat(messages, functionsfunctions)问题出在描述冲突和参数幻觉。几个函数的语义边界模糊时模型会选错参数格式写得稍微含糊模型就编造值。有一次我没有约束warehouse的枚举值模型生成了“华东大仓”而系统里实际叫“EAST-CHINA-01”调用直接失败。3.2 第二版加参数校验但还是在模型端打补丁第二版我在模型层加了校验规则比如枚举值检查、必填项检查失败就重试一次。这个改动把参数格式类的错误降了一半但解决不了根本问题模型依然要在几十个工具里做选择选择本身就容易错。而且每次重试都是额外的token开销一次成功的调用平均要烧掉将近5000 token成本实在扛不住。3.3 第三版声明式端点加路由仲裁最终方案Agent-Reach最终落地的架构有三层。第一层是端点目录每个端点带精细的入参校验逻辑第二层是一个路由仲裁器它接收模型的工具选择结果但不盲信而是根据上下文的相关性打分低于阈值就主动向模型追问一次第三层是可观测管道每一次调用的入参、出参、耗时、失败原因全部落日志。核心的端点声明长这样{ endpoint: inventory.query_balance, summary: 查询商品实时可用库存, params: { sku: {type: string, required: True, pattern: ^SKU-[0-9]{6}$}, warehouse: {type: string, enum: [EAST-CHINA-01, NORTH-02, SOUTH-03]} }, output: {schema: InventoryBalance, expiration: 60}, access: internal.read, timeout_ms: 2000 }模型看到的只是一句话“查询商品实时可用库存”参数和规则全部由仲裁器掌控。好处是模型的选择负担变轻了token消耗少了参数错的概率也大幅下降。如果模型传了非法参数仲裁器直接拦截并返回可选值不需要模型自己猜。三版对比下来最终方案的综合表现最好版本工具选择准确率参数错误率平均单次耗时平均token消耗v1 全函数暴露68%18.5%3.2s6200v2 加校验重试79%9.2%2.6s5400v3 声明式端点仲裁94%1.8%1.1s1900别小看这个设计它的本质是把“模型的自由发挥”限制在了一个安全笼子里模型只做决策不碰执行细节。4. 一次压测复盘Reach能力在极限情况下的衰减与应对架构定了不等于万事大吉。Agent-Reach在受控环境里跑得很顺但一上真实业务流量各种边界问题就冒出来了。这里分享一次完整的压测复盘整个过程挺有代表性。4.1 压测场景与指标设定压测场景选的是电商订单履约Agent从用户下单开始需要依次执行库存预占、优惠计算、地址校验、支付状态确认、物流单创建共涉及7个不同系统、12个端点调用。测试流量模拟了真实业务分布其中20%的请求包含历史遗留脏数据比如非法SKU、缺失地址、重复优惠券。我盯的核心指标有四个任务成功率、单任务平均延迟、错误恢复率一次失败自动转人工或重试的成功比例、极端情况下的可用性。4.2 数据结果最大的坑是上下文长度压测开到并发50时还好任务成功率在90%左右并发升到200问题开始出现。第一批请求还没跑完第二批请求就已经把Agent的上下文撑爆了——每个任务执行过程中都要读取订单详情、库存信息、优惠明细这些内容叠加在一起很快突破模型的上下文窗口限制。数据很直观上下文长度超过60K token时Reach层的路由准确率开始小幅下降超过100K时任务成功率从90%跌到55%。模型不是变笨了而是上下文太长之后它开始遗忘早期步骤里的约束条件偶尔会反复调用同一个端点甚至把之前的工具结果当作新的查询参数。4.3 解决方案把“触达过程”和“触达产物”分开存Agent-Reach后来引入了执行记忆压缩机制。每个任务进行中时系统会实时把已完成的工具调用结果提炼成一行摘要旧上下文从几十条完整JSON压缩成几条文本描述模型需要追溯细节时再按ID去取详情。这个改动上线后长任务成功率回到了87%上下文峰值从110K降到25K左右模型反而更专注了。我还给每个端点设了独立超时与熔断阈值。下游系统偶发抖动时Reach层会快速失败并触发备选路径不让单点故障拖死整条链路。比如查库存服务超时就让Agent先读取昨天的缓存快照哪怕数据差了30秒也比卡死在99%的进度上好。5. 能力边界的“栅栏”安全与外联控制防止Agent摸太宽Agent的能力越强越要克制。我在Agent-Reach里最看重的一项设计不是让Agent能触达多少东西而是让它“不该碰的绝对不能碰”。5.1 权限的最小化工具白名单与数据脱敏所有端点默认都是不可用的只有进入白名单才允许被调用。白名单的粒度不是“系统级别”而是“动作级别”比如Agent可以读库存但不能改库存可以查供应商联系方式但不能直接发送对外邮件。权限配置写死在触达层不放在Prompt里这样即使模型被诱导也有最后一道闸拦住。数据脱敏我也放在了触达层。只要Agent请求的字段属于敏感范围比如真实手机号、银行账号、个人身份证号返回前自动打码模型拿到的永远是脱敏后的数据。宁可让Agent多问一次“需要完整号码请联系人工”也不要让它在对话里复述敏感信息。5.2 外联审批与防滥用机制Agent不止要“读”还要“写”。我测试过让Agent自动发出采购订单结果它差点真的给一家供应商发了PO邮件。虽然参数都对但业务方根本没批准这笔采购。Agent-Reach因此加了一条铁律所有外联动作分为自动执行和人工审批两类下单、删数据、发对外消息这类一律走审批流。触达层拦截后生成审批链接由人来决定放不放行。我也记录过模型访问频次和模式用来识别异常调用。某个Agent单日重复调用同一端点超过正常水平十倍Reach层会直接限流并告警。这么做不是为了防范恶意外部攻击主要是防自己人毕竟模型在极端情况下可能陷入循环调用烧token是小事打垮下游业务系统才是大麻烦。5.3 一个真实的误用案例有一回测试“数据归档”功能业务方说“把三年前的历史订单清理掉”。Agent正确识别出了归档目标但参数解析时把“历史订单表”误映射到了“订单全量表”要不是触达层的范围校验发现删除行数远超预期险些把最近三个月的真实订单一起清理。这个教训让我坚定了一个原则Agent能触达的范围必须是人先画好的圈模型只能在这个圈里做最优选择绝不能自己扩展边界。6. 从Reach到Sustain后续扩展与给同行的一套落地清单Agent-Reach目前已经跑通了供应链场景里的大部分主流程但离一个通用的“触达层基础设施”还有距离。我下一步准备做三件事一是把端点目录从手工登记改成半自动发现连接企业内部API网关后自动生成端点Schema二是给多Agent协作增加更细的信用评分避免某个Agent长期“划水”拖累整个任务三是把压测能力内置到触达层里每次改完端点配置自动跑一遍全链路仿真。如果你也想在自己项目里引入类似思路这里有一套可以照搬的清单把所有工具调用收口到一个服务里不要散落在各个业务代码中工具描述用“一句话说明Schema”别让模型读大段文档参数校验必须程序化不能指望模型自觉每次调用落日志至少保留入参、出参、耗时、失败原因四样外联写操作一律走人工审批再可靠的Agent也不配拥有“自动下单”的权限上线前做一次超长上下文压测看看你的Agent在窗口边缘还醒不醒按这个清单执行哪怕你完全不用Agent-Reach的代码只把这套原则落地也能避开我在第一版里踩过的那些大坑。我个人在实际操作中的体会是Agent项目能不能成模型只占三成剩下七成都在“触达工程”上。把Agent-Reach做扎实之后我发现团队的关注点从“怎么让模型更聪明”变成了“怎么让模型不被环境绊倒”。这种转向带来的稳定性提升远比调几个Prompt参数来得实在。最后再分享一个小技巧给每个关键端点起一个“人话名称”比如把inventory.query_balance叫做“查可用库存”模型选工具时会更少出错。这种命名上的小改动很多时候比优化模型温度参数更管用。