工具越多为什么任务反而越慢不少 Agent 团队在工具还少时任务表现往往不差读文件、查网页、跑命令三五个动作就能闭环。可一旦把浏览器、终端、搜索、代码执行、委派子代理都接进来延迟和失败率常常一起上升。很多人第一时间怀疑上下文窗口不够开始猛砍系统提示词和历史消息但压缩之后效果往往并没有明显改善。更常见的现实是Agent 先坏在“选错动作”上。一个本该直接web_search的问题被先拿去read_file一个明显需要浏览器交互的页面模型却继续空想页面结构。这样一来系统不是慢在一次长回答而是慢在多轮错误试探。⚠️ 工具一多路由空间会迅速膨胀如果缺少约束和反馈模型就会把大量时间浪费在低价值调用上。 真正的成本不是工具数量而是错误路由的连锁放大工具集扩张后很多团队只盯着 token 消耗却忽略了一个更致命的指标每次成功完成任务前到底绕了多少无效调用。一次错误路由通常会带来三重放大 额外等待、错误结果进上下文、补救动作继续消耗判断轮次。路由策略平均工具调用轮次成功率端到端耗时典型问题完全自由选择6.20.711.00x反复试错动作漂移只靠描述词引导5.40.760.92x同类工具仍容易混用任务分层 失败回退3.80.840.73x需要维护规则分层路由 结果校验3.50.880.69x最适合线上稳定化这也是为什么一些 Agent 在“增加工具”后看上去更聪明实际上却更不稳定。 如果系统没有先判断任务属于检索、操作、计算还是外部交互模型就会把所有工具都当成候选项平均试探。️ 更稳的做法是先压缩决策空间再放开执行能力线上更稳的一条路是把工具先做任务分层而不是一开始就把全部能力平铺给模型。✅ 例如把问题先归到“信息获取”“本地改动”“网页交互”“重推理委派”四类再让每一类只暴露少量候选工具能明显减少误选。对于失败率高的动作还应该在工具层返回结构化原因让模型知道是权限问题、环境缺失还是页面元素没找到。ROUTE_TABLE{lookup:[web_search,web_extract,read_file],local_exec:[terminal,execute_code,patch],browser:[browser_navigate,browser_click,browser_type],delegation:[delegate_task],}defselect_candidates(task_kind:str,needs_interaction:bool)-list[str]:ifneeds_interaction:returnROUTE_TABLE[browser]returnROUTE_TABLE.get(task_kind,[read_file,terminal])这段逻辑的价值不在于写死路由而在于先把决策空间缩到足够小。 当模型只需在 2 到 4 个候选动作里选择时准确率通常比在十几个工具里盲选稳定得多。再往前走一步最好把“工具是否真的解决了问题”也做成反馈信号比如搜索无结果、页面加载异常、命令退出码非零时直接触发回退路径。 接下来 3 到 6 个月Agent 优化重点会从上下文压缩转向动作治理笔者认为未来几个月 Agent 工程真正的竞争点不会只是上下文窗口谁更大而是谁能把工具路由做成一套可观测、可回退、可统计的运行时系统。 单纯扩大窗口只会让错误动作被保存得更久只有把路由命中率、失败重试率和任务级完成时间连起来看团队才能知道系统到底慢在推理还是慢在执行链路本身。对已经接入大量工具的团队来说最值得优先补的通常不是再加一个新工具而是先回答三个问题 哪类任务最容易误选工具 哪些失败应该立即回退 哪些工具根本不该在同一层竞争。把这三件事理顺后Agent 才会从“会很多技能”真正进化到“能稳定完成任务”。工具一多就变慢问题通常不在上下文窗口先爆而在工具路由先失真。 你们线上更常见的瓶颈是工具太少还是工具太多之后的错误路由欢迎交流。