Agent 工具一多就变慢？真正的瓶颈不是上下文窗口，而是工具路由失真

🧠 工具越多，为什么任务反而越慢

不少 Agent 团队在工具还少时，任务表现往往不差：读文件、查网页、跑命令三五个动作就能闭环。可一旦把浏览器、终端、搜索、代码执行、委派子代理都接进来，延迟和失败率常常一起上升。很多人第一时间怀疑上下文窗口不够，开始猛砍系统提示词和历史消息，但压缩之后效果往往并没有明显改善。

更常见的现实是，Agent 先坏在“选错动作”上。一个本该直接web_search的问题，被先拿去read_file；一个明显需要浏览器交互的页面，模型却继续空想页面结构。这样一来，系统不是慢在一次长回答，而是慢在多轮错误试探。⚠️ 工具一多，路由空间会迅速膨胀；如果缺少约束和反馈，模型就会把大量时间浪费在低价值调用上。

🔍 真正的成本，不是工具数量，而是错误路由的连锁放大

工具集扩张后，很多团队只盯着 token 消耗，却忽略了一个更致命的指标：每次成功完成任务前，到底绕了多少无效调用。一次错误路由通常会带来三重放大：🧩 额外等待、错误结果进上下文、补救动作继续消耗判断轮次。

这也是为什么一些 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 才会从“会很多技能”真正进化到“能稳定完成任务”。

工具一多就变慢，问题通常不在上下文窗口先爆，而在工具路由先失真。🙂 你们线上更常见的瓶颈，是工具太少，还是工具太多之后的错误路由？欢迎交流。