单个智能体调用的工具数量建议：不超过 5–7 个，理想情况 3–5 个
这是一个在实践中经过验证的经验值，背后涉及认知负荷、提示工程、执行可靠性与可维护性等多个因素。下面详细解释原因与例外情况。
1️⃣ 为什么不宜过多？
（1）认知与提示长度限制
LLM 的上下文窗口有限，工具描述（名称、参数说明、用途）会占用大量 token。
工具数量越多，prompt 中需要塞入的描述越长，留给实际任务指令和中间结果的上下文空间越少，容易导致“忘记”工具或误用。
（2）决策混淆与错误率上升
面对很多工具，智能体在每一步需要推理“该用哪一个”，选择压力增大。
容易出现选错工具或参数填错的情况，尤其当工具功能相近时（例如两个搜索 API、两个数据库查询接口）。
（3）可观测性与调试困难
调用链复杂时，排查“哪一步工具返回异常”变得困难。
日志、trace 信息被大量相似调用淹没，定位问题成本高。
（4）职责单一原则
单个智能体的设计理念应是职责聚焦，工具过多意味着它试图承担太多不同类型的任务，违背“单一职责”，不利于复用与维护。
2️⃣ 经验数值与依据
场景 | 建议最大工具数 | 说明 |
|---|---|---|
通用任务智能体 | ≤ 5 个 | 保证选择清晰，减少混淆 |
专用领域智能体 | 3–5 个 | 专注某一类任务（如只做数据查询与分析） |
原型/POC | ≤ 7 个 | 可适度放宽，但需关注错误率 |
生产环境 | 3–5 个（强推荐 ≤ 5） | 确保稳定、易调试 |
认知心理学类比：人类短期记忆容量约 7±2 项（米勒定律），LLM 在“工具选择”上也有类似限制，超出后性能下降。
业界实践：LangChain Agent 官方示例通常控制在 3–5 个工具；AutoGen 在多智能体拆分时也强调把工具按功能分给不同智能体，而不是堆给一个。
3️⃣ 如何突破限制？
当任务确实需要很多工具时，不要硬塞给一个智能体，可采用以下模式：
（1）按功能拆分智能体
将工具分类（如“搜索类”“数据库类”“计算类”），每类由一个专职智能体负责，主智能体只负责“路由”任务给对应子智能体。
例：主智能体收到请求 → 判断属于“数据分析” → 转交给“数据分析智能体”（它只有 3 个相关工具）。
（2）分层编排
第一层智能体做任务拆解与路由，第二层各智能体执行具体工具调用。
可用LangGraph、CrewAI、AutoGen 实现这种层级结构。
（3）动态工具加载（谨慎使用）
某些框架支持运行时根据上下文动态决定可用工具列表（减少 prompt 中固定工具描述长度），但这会增加复杂性，需严格测试稳定性。
4️⃣ 最佳实践建议
每个智能体只保留核心必需工具，无关工具移到其他智能体。
工具描述要简洁明确：名称、功能、参数格式一目了然，减少歧义。
监控工具调用错误率：若某智能体错误率随工具数量增加明显上升，应拆分。
生产环境优先稳定性：宁可增加智能体数量，也不要让单个智能体过载工具。
结论：
硬性上限：建议 ≤ 7 个（原型可试），生产环境强烈建议 ≤ 5 个，理想 3–5 个。
核心原则：工具数量与智能体的职责范围匹配，超量则拆分智能体，用多智能体协作代替“单智能体全能”。
