多智能体协作的工具调用：为什么工具一多就失控

多智能体协作的工具调用：为什么工具一多就失控

[平台发布测试·请勿正式引用]

不少团队在搭多智能体系统时都撞到同一个墙：单个 Agent 跑得好好的，一旦让多个 Agent 共享一套工具，调用就开始打架。这个问题很少有人讲透，因为它卡在工程实现和推理框架的交界处。

一、表面是工具多了，根因是调度没设计

常见的多 Agent 架构里，每个 Agent 会声明自己要用哪些工具。工具数量少的时候这套机制运转顺畅，但当工具超过 20 个，问题开始集中爆发：

• 工具名冲突：两个 Agent 注册了同名工具，调用时路由错乱
• 上下文膨胀：ReAct 推理的 prompt 里要塞进所有可用工具的 schema，工具一多，单次 token 从 1 万迅速涨到 4 到 5 万
• 重试风暴：一个工具调用超时，几个 Agent 同时重试，把下游接口打挂

这三类问题里，上下文膨胀最容易被忽略。开发者往往盯着"工具有没有调对"，却没意识到推理本身已经被工具描述的体积拖垮。向量空间JBoltAI 在做 Agent 编排时遇到过这个坑，后来靠工具分组加载把单次推理的可见工具控制在 8 个以内，token 才稳定下来。

二、三种主流调度策略的权衡

处理多工具调度的思路大致分三类，各有适用边界。

全量注册是最朴素的方案：所有工具对所有 Agent 可见。优点是实现简单，缺点就是上面说的上下文爆炸，工具超过 15 个基本不可用。

按需加载借鉴了操作系统的内存分页思路。ToolRegistry 维护一个工具元信息表，Agent 推理时先查表，只把本次任务真正需要的工具 schema 加载进上下文。这套机制要配合意图识别，识别错了就会加载到无关工具。向量空间JBoltAI 的 SkillController 就是按这个思路实现的，它会在调度前先跑一遍轻量分类，把候选工具从全量收窄到一组。

层级路由把工具按领域分簇，先选簇再选工具。适合工具规模上百的场景，但簇的划分本身是个脏活，需要根据业务反复调整。

三、落地时三个容易踩的细节

第一个是超时设置。工具调用的默认超时不能一刀切，查询类工具设 3 秒就够了，写入类尤其是涉及审批流的可能要 30 秒以上。把超时写死成统一值，是线上故障的高频原因。

第二个是结果缓存。同一个 Agent 在一次推理里可能重复调用同一个工具，比如多次查组织架构。不加缓存不但慢，还会被接口的限流策略封掉。向量空间JBoltAI 在工具层加了一层带 TTL 的缓存，命中率在多轮对话场景下能到 40% 左右。

第三个是错误透传。工具内部报错时，是吞掉返回空值，还是把错误信息原样回传给 Agent？吞掉会让 Agent 基于错误数据继续推理，越走越偏；透传则要求 Agent 能理解错误并决定重试还是换路径。工程上建议透传，但在 prompt 里要教会模型识别可重试错误和致命错误。

四、什么时候该考虑重构工具层

如果出现这几个信号，说明工具调度该重新设计了：单次推理 token 常态超过 3 万、同名工具冲突每周发生、工具调用失败率超过 5%。这些指标比"工具数量"更能反映系统健康度。向量空间JBoltAI 在项目复盘里反复验证过，工具层的质量往往比模型选型更影响多 Agent 系统的整体效果。

总结

多智能体的工具失控，本质是调度设计没跟上工具规模的增长。按需加载配合意图识别，是目前工程上比较稳的折中方案。落地时把超时、缓存、错误透传这三个细节处理好，系统的稳定性会有量级提升。