文章目录1 为啥我们要搞延迟工具 deferred tools1.1 优先用厂商原生能力别重复造轮子2 自己实现延迟工具的基础架构3 发现新工具之后两种调用实现方案3.1 方案a搜索出来直接塞进tools列表Qwen‑Code的实现思路3.2 方案b统一封装DeferExecuteTool代理执行WorkBuddy实现思路4 方案怎么选简单总结P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看 传送门https://blog.csdn.net/qq_344193121 为啥我们要搞延迟工具 deferred tools做Agent开发的小伙伴应该都踩过一个大坑工具一多直接原地翻车。你想想啊几十上百个工具一股脑塞进去每个工具的description、schema全要占token。这就好比你点外卖把全城所有餐馆菜单全部打印出来塞你手里别说AI模型了换成年人看都头大。最搞笑的是什么token哗哗烧钱就算了模型还开始犯迷糊。明明这个工具就在列表里它愣是看不见输出瞎写参数。尤其对接MCP的时候这个现象会被放大bug多到你怀疑是不是自己代码写得有问题。所以核心思路就来了不要一次性把全部工具扔进去搞渐进式加载也就是延迟工具。1.1 优先用厂商原生能力别重复造轮子很多人上来就咔咔手写一大段逻辑实现延迟加载熬两个通宵写完结果发现Anthropic、OpenAI本身就自带渐进式加载工具功能。这场景就像你费劲搓木钻准备生火转头发现墙角摆着打火机。不是说造轮子不行就怕你辛辛苦苦写完还没有官方现成的稳定纯纯消耗加班时长。原生能力是我们的第一选择。2 自己实现延迟工具的基础架构如果业务特殊要对接别的模型原生能力用不上那只能我们自己手动实现这套逻辑。整体设计思路其实不难理解。初始阶段只放少量即时可用工具再加一个tool_search工具。这个tool_search专门用来搜索、发现我们那些延迟加载的工具。系统提示词里面简单描述下那些还没加载进来的延迟工具告诉模型有这堆东西存在但是现在不能直接调用。这里打个比方tool_search相当于工具的检索目录。不是把所有工具摆桌面上需要哪个先查目录找到再拿出来用。总不能把仓库全部货物都摊在办公桌上吧桌子直接挤爆。3 发现新工具之后两种调用实现方案最关键的问题来了tool_search搜到目标工具接下来怎么让模型调用它目前主流就两套玩法各有各的坑没有完美选项。3.1 方案a搜索出来直接塞进tools列表Qwen‑Code的实现思路逻辑流程调用tool_search找到需要的工具后续大模型请求的时候把这个工具直接追加进tools数组里面。模型就可以像普通原生工具一样直接调用。听着是不是特别美好原生调用体验参数校验全部交给模型底层。但是坑点一点不少。整个Agent状态机直接变复杂到处要维护tools集合写业务逻辑的时候头都大。改一处好几处连带受影响。工具集膨胀风险调用过一堆杂七杂八工具之后tools列表越堆越长好不容易降下来的token开销又涨回去属于治标之后又复发。那什么时候适合选a方案如果你业务场景要对接不同领域MCP服务对工具调用精准度要求高选它就合适。牺牲一部分维护成本换调用准确度。3.2 方案b统一封装DeferExecuteTool代理执行WorkBuddy实现思路这套就不改动原始tools数组。哪怕搜到再多延迟工具tools列表保持原样不动。所有延迟工具统一走一个代理工具DeferExecuteTool(toolname,params)。把目标工具名字、调用参数打包传给这个代理工具由代理层去真正执行对应的业务逻辑。代码示意伪代码片段{name:DeferExecuteTool,parameters:{toolname:目标延迟工具名,params:对应工具入参}}优点显而易见代码写起来省事tools集合不用动态增删状态管理几乎零成本。对于开发人员简直是摸鱼福音少写一大堆状态维护代码。但是坑也躲不开工具不是模型原生识别的套了一层包装壳。相当于套娃一层包一层参数传递过程很容易出bug。模型一不小心就把参数嵌套搞错调用直接报错。适用场景延迟工具的schema结构简单参数不复杂优先选b。实现简单整体出错概率反而更低。4 方案怎么选简单总结很多同学纠结到底a好还是b好其实不用死磕标准答案。多领域MCP接入、追求调用精度 → 选方案a接受复杂状态维护的代价。工具schema简单希望少维护代码项目迭代节奏快 → 选方案b接受包装层带来潜在参数错误风险。千万不要幻想有一个万能写法啥场景通吃。写Agent开发久了你就懂大部分技术选型本质都是做取舍就跟点外卖一样想便宜又想吃顶配基本很难实现。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/qq_34419312