模式矩阵 /模式白皮书/A5
ADPS Agent 设计模式白皮书
A5 · Minimal Tool Set · 最简工具集
把 agent 的工具集控制在合理上限（通常 10 到 30 个），砍掉低频、合并相似、把次要工具下沉到 sub-agent，给模型留下选择的专注力。
文档状态：本页为公开评审稿。模式定义与分类可供讨论和引用；未附来源链接的数字与应用示例只用于说明机制，不作为行业基准。
| 坐标 | 行动 Action × 约束 constraint（跨切，不属于任何单一拓扑） |
| 成本 | 低（砍工具本身省 token，是净收益） |
| 模式组 | 行动模式 |
| 模式简介 | 把 agent 的工具集控制在合理上限（通常 10 到 30 个），砍掉低频、合并相似、把次要工具下沉到 sub-agent，给模型留下选择的专注力。 |
问题
工具不是越多越好。某电商客服 agent 第一版抱着"能做到一切人工客服能做的事"的目标接入了 67 个工具，第一周客户满意度从 78% 掉到 51%。复盘日志里，agent 面对"我的订单什么时候到"这种简单问题，要在 14 个订单类工具里反复试错——错调三次、八秒后才给出答案，约 70% 的 thinking token 耗在工具选择上。工具列表太长，模型"看晕了"。
Minimal Tool Set 是一个反直觉的设计原则：给 agent 的工具，少而精胜过多而全。Anthropic、GitHub、Block 在 2026 年公开了同一组数据——工具数从 30 多砍到 10 左右，准确率反而提升。这件事从边际优化升级成了必修工程。
分类依据：行动 × 约束
这是本模块里唯一一个不落在具体拓扑列上的模式，需要专门说清楚。
- 纵轴 · 行动：它管的是行动端的工具数量，属于动作设计，所以纵轴落在行动模块。
- 横轴 · 约束（而非结构）：路由（A1）、链式（A3）、层级（A4）这些是结构模式，它们规定 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 是甜区。
砍工具的策略有三条：
| 策略 | 做法 |
|---|---|
| 删低频 | 30 天没被调过的工具直接 evict |
| 合并相似 | 功能重叠超 50% 的工具 merge（如 query_order_detail / query_order_status / query_logistics 合成一个 query_order） |
| 下沉次要 | 低频但有用的工具（OCR、PDF 解析、图片翻译）放进专门的 sub-agent |
与砍工具配套的是渐进披露（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 解决"给定工具集怎么挑得准"，A5 解决"挑之前先把工具集砍到挑得动"。A5 是 A1 准确率的前置条件——工具污染少了，router 才不掉点。
- 分层保留（记忆模块）：渐进披露与记忆模块的分层加载同源，都是"核心常驻、其余按需取"的 attention 管理思路。
- 规划-执行（A2）：当工具逼近上限，拆 sub-agent 往往与 A2 的任务分解同时发生——把次要能力连同它的工具一起下沉。
设计结论
最简工具集不是在裁剪工具，而是在给 agent 留下专注力——LLM 的 attention 是稀缺资源，同时打开 50 个工具就像同时开 50 个浏览器标签页，谁都没法深度思考。
企业证据
当前没有与本模式绑定的公开评审案例。模式定义不因此视为已经获得企业验证。
案例收录要求说明业务约束、实现结构、已知失败和迁移边界。参见 贡献与评审规则。