3 个工具 = 97% 准确率，18 个 = 51%：工具数量曲线

工具选择准确率随工具数量急剧下降。数据很明确：3 个工具 97%，5 个 94%，8 个 82%，12 个 68%，18 个 51%。甜蜜点是每个 agent 4-5 个工具。需要 15+ 工具的系统应该分布到专门的子代理中。

准确率曲线

18 个工具时，一半的工具调用去了错误的工具。3-5 个时，准确率接近完美。这组数据驱动了所有工具分配决策。

角色专属工具集

每个 agent 只拿到角色所需的工具：

• 账单 agent：[get_customer, get_payment_history, process_refund]（3 个工具）
• 安全审查 agent：[Read, Grep, Glob]（3 个工具，只读）
• 测试运行 agent：[Bash, Read, Grep]（3 个工具）

“以防万一”的工具是反模式。7 个额外的”可能用到”的工具把一个 3 工具 agent 推到 10 个，准确率从 97% 掉到约 82%。

工具过多导致角色越界

一个有 15 个工具的综合 agent（包括搜索和数据库工具）在综合过程中偶尔发起搜索查询——增加延迟、产出冗余数据。它有不该有的搜索工具，而且它用了。

修复：限制到 [format_output, generate_summary]。没有搜索工具，综合 agent 就在现有发现上工作，而不是冗余地重新搜索。

类似的：安全 agent 用了 Edit（应该只读）、测试 agent 用了搜索工具（应该只跑测试）、文档 agent 用了 Bash（超出角色）。都是工具过度分配的后果。工具限制确定性地执行角色边界——prompt 指令做不到。

多 agent 作为扩展模式

系统需要 18 个工具。一个 agent 51% 准确率 → 拆成 4 个专门 agent，每个 4-5 个工具 → 每个 agent 94%+ 准确率。协调者把查询路由到对的 agent（4 个中选一个，简单选择），每个 agent 在聚焦的工具集中选择（每 agent 高准确率）。

扩展：添加新工具

当前：4 个 agent × 4 个工具 = 16 个总计。需要加 5 个新工具（21 个总计）。

错误：全加到一个 agent（9 个工具 → 82%）。也是错误的：加到所有 agent（每个从 4 变 9）。

正确：为新工具创建第 5 个专门 agent，或分配到现有 agent 但确保每个不超过 5 个。原则：没有 agent 超出 4-5 的可靠范围。

一个角色需要 8 个工具时

分析 agent 需要 8 个功能（安全、性能、风格、依赖、许可、覆盖率、复杂度、文档）。8 个工具 = 82% 准确率。

修复：拆成 2 个聚焦的子代理——analysis-security（安全、依赖、许可、覆盖率 = 4 个工具）和 analysis-quality（性能、风格、复杂度、文档 = 4 个工具）。每个 94%+ 准确率。协调者处理路由。

范围化验证 vs 完整搜索访问

综合 agent 偶尔需要验证一个事实。错误：给它全部 5 个搜索工具。正确：给它一个范围化的 verify_fact 工具做简单查询。复杂查询路由回协调者 → 搜索 agent。这提供了验证能力但没有完整搜索工具集的准确率惩罚。

一句话总结： 工具选择准确率遵循清晰曲线（3 个工具 97%，18 个 51%）——每个 agent 保持 4-5 个工具，更大的工具集分布到专门子代理，用范围化单用途工具代替给偶尔需要某个能力的 agent 完整的搜索/写入访问。