模式矩阵 /模式白皮书/A4

A4 · Minimal Tool Set · 最简工具集

它解决什么问题

工具不是越多越好。某电商客服 agent 第一版抱着"能做到一切人工客服能做的事"的目标接入了 67 个工具，第一周客户满意度从 78% 掉到 51%。复盘日志里，agent 面对"我的订单什么时候到"这种简单问题，要在 14 个订单类工具里反复试错——错调三次、八秒后才给出答案，约 70% 的 thinking token 耗在工具选择上。工具列表太长，模型"看晕了"。

Minimal Tool Set 是一个反直觉的设计原则：给 agent 的工具，少而精胜过多而全。Anthropic、GitHub、Block 在 2026 年公开了同一组数据——工具数从 30 多砍到 10 左右，准确率反而提升。这件事从边际优化升级成了必修工程。

为什么坐标是「行动 × 约束」

这是本模块里唯一一个不落在具体拓扑列上的模式，需要专门说清楚。

• 纵轴 · 行动：它管的是行动端的工具数量，属于动作设计，所以纵轴落在行动模块。
• 横轴 · 约束（而非结构）：路由（A1）、链式（A3）、层级（A5）这些是结构模式，它们规定 agent "怎么把动作组织起来"。最简工具集不规定结构——它不告诉你怎么挑工具、怎么串步骤、怎么套夹层，它只给所有这些结构加一条横切约束：工具总量要有上限。换句话说，它是一条贯穿全模块的设计戒律，而不是一种可以画成拓扑图的执行形态。它的作用对象正是路由——工具集越干净，router 的选择准确率越不容易掉；工具污染越少，模型的 attention 越不被稀释。所以坐标记为"行动 × 约束"，强调它是 cross-cutting 的设计原则，落地时附着在 A1 这类结构模式之上。

核心机制

阈值的物理根源在 attention。Anthropic 的内部 benchmark 反复验证：单 agent 工具数超过 30 到 50 时，selection accuracy 显著下降；tool description 加起来超过约 5000 token，列表末尾的工具会出现"lost in the middle"现象，选不出来或选错。30 到 50 大致是这个 token 阈值的换算，10 到 15 是甜区。

砍工具的策略有三条：

与砍工具配套的是渐进披露（progressive disclosure）。Claude Code 自己有 40 多个工具，但默认在 system prompt 里只装载 10 到 12 个，其余通过 Tool Search 按需检索加载。这是 2026 年工具管理的事实标准——核心工具常驻，扩展工具 on-demand。

适合的生产场景

• 延迟敏感、准确率敏感的用户体验场景：客服、对话、消费级 agent。这是 Minimal Tool Set 价值最高的地方。
• 接入外部工具协议时控制单次暴露：哪怕底层有上百个工具，单次 dispatch 也要把可见工具压在 30 以内，配合 Tool Search 让 agent 主动找罕见工具。
• 多职能 agent 拆分前的体检：当一个 agent 的工具逼近上限，往往是该拆 sub-agent 的信号。

什么时候不适用：任务本身极复杂的代码类 agent（Cursor、Claude Code 这类必须 30 多个工具）、以及企业多职能 agent。强行砍到 10 个反而会丢能力。

容易出错的地方

• 把"全能"当目标：追求"一个 agent 干所有事"必然导致工具膨胀，是 67 工具事故的根源。应该按"用户想要什么结果"组织工具（outcome-oriented），而不是按"系统有什么能力"罗列。
• 合并时丢了语义边界：把语义差别大的工具硬合成一个，会让单个工具的 description 变模糊，selection 反而更难。合并的前提是功能真的高度重叠。
• 只砍不配渐进披露：直接删掉低频工具会让罕见任务彻底没法做。正确姿态是下沉加 Tool Search，而不是一刀切删除。
• 砍完不复盘：工具集是活的，新功能会不断加回来。需要固定的 evict 周期，否则几个月后又长回 67 个。

关键指标

• 单 dispatch 工具数（健康区 10 到 15，硬上限 30 到 50）：超过上限就该砍或拆 sub-agent。
• tool description 总 token（健康区 <5000）：超过这条线就触发 lost-in-the-middle，是准确率下降的先行指标。
• 默认装载 / 总工具比（健康区偏低，配合 on-demand）：Claude Code 是 10-12 / 40+。比例过高说明渐进披露没做。
• 工具选择准确率（健康区 >90）：砍工具后的直接收益。客服案例砍完准确率升约 10 个点。

最小骨架

prune(all_tools, stats, target_size=12):
    对每个 tool 打分 = 30天调用次数 × 成功率
    按分数降序，取前 target_size 个常驻
evict_stale(stats):
    返回 30 天调用次数为 0 的工具      # 下线候选
merge_similar(tools, threshold=0.5):
    用 embedding 算 description 相似度，>threshold 的推荐合并
# 其余工具不删除，转入 sub-agent + 挂到 Tool Search 入口

工程落地要点：core 工具 always-on，extended 工具 on-demand；按使用频次加成功率打分剪枝；保留 Tool Search 入口让罕见任务仍可达。

企业落地一例

翻译/本地化 agent 的六个决策点：核心 5 到 7 个工具撑全流程（translate / detect_lang / glossary_lookup / quality_check / format_preserve / cultural_adapt）；OCR、PDF 解析、图片翻译这些低频工具下沉到专门的 sub-agent；设 30 天 evict 周期；相似工具自动提示合并；保留 Tool Search 入口让用户问罕见任务时 agent 能找到；core always-on 加 extended on-demand 的渐进披露配置。六个决策做对后，agent token 成本降约 35%、准确率升约 10 个点。回到那个电商客服案例：团队把 67 个工具砍到 18 个，一周后客户满意度回到 79%，比 67 工具的初版还高 1 个点。

与其他模式的关系

• 工具调度（A1）：同格的一对，姿态相反。A1 解决"给定工具集怎么挑得准"，A4 解决"挑之前先把工具集砍到挑得动"。A4 是 A1 准确率的前置条件——工具污染少了，router 才不掉点。
• 分层保留（记忆模块）：渐进披露与记忆模块的分层加载同源，都是"核心常驻、其余按需取"的 attention 管理思路。
• 规划-执行（A2）：当工具逼近上限，拆 sub-agent 往往与 A2 的任务分解同时发生——把次要能力连同它的工具一起下沉。

一句话记住它

最简工具集不是在裁剪工具，而是在给 agent 留下专注力——LLM 的 attention 是稀缺资源，同时打开 50 个工具就像同时开 50 个浏览器标签页，谁都没法深度思考。

本页属于 ADPS 33 模式白皮书。返回 模式矩阵与白皮书目录， 或查看配套 可运行代码目录。