工具数量本身不是瓶颈，工具描述之间的语义边界才是。我见过工具不少但跑得挺稳的 agent，也见过工具没几个就开始乱选的——差别不在数量，在于那几个描述读起来像不像同一件事。所以「一个 agent 该挂多少工具」这个问题，正确答案是「取决于你能把描述写得多不重叠」。下面讲我怎么排解法的优先级，以及为什么动态挂载我放在最后。
撞车的描述比多余的工具更致命
模型选工具靠读 description。两个描述重叠的时候——「查订单」和「查订单详情」——它不是不会选，是没有依据选。这时候加多少 few-shot 都是在跟一个信息缺失的问题较劲。
HN 上那个 i-have-adhd 挺有意思，五百多分。它干的事很简单：让 coding agent 别把答案埋在废话后面。一个 skill 文件，不改模型不改工具，只改措辞，行为就变了。反过来想——你那些写得含糊的工具描述，也在用同样的机制悄悄影响行为，只是没人给你打分。
合并是第一优先。两个工具如果参数能用一个 schema 表达，就合成一个。查订单和查订单详情，本来就是一个 query 的 filter 差异。合并之后不是少了能力，是少了一次抛硬币。
合并到头了再分层
工具合并到没法再合，还有二十几个怎么办。分层的做法：一个 router agent，手里就是几个专职 agent 的名字；每个专职 agent 攥着一小把工具。
这事的价值不在架构好看。router 面对的选择空间小，判断准；专职 agent 面对的选择空间也小，也准。把一次几十选一拆成两次几选一，错误率不是线性下降的。
OpenAI 这周发的 Agents API 里 handoff 是一等公民，基本就是这个模式的产品化。它怎么描述 handoff 的触发条件，跟工具描述是同一套问题，值得翻一下文档。
分层的代价是多一跳延迟、多一次上下文传递、多一个可能出错的环节。所以顺序是合并在前，分层在后，不是反过来。
拐点自己测，别抄数字
有人问「是不是超过 N 个就该拆」，这问题没法回答。拐点取决于工具名的区分度、你的任务分布、用哪个模型。别人测出来的数字搬到你这儿没有意义。
能搬的是方法。固定一套评测集——从真实请求里抽几十到几百条，每条人工标注唯一正确工具。然后做消融：从最小工具集开始，每加一批跑一次全量，记三件事：选对的、选错的、还有该调用却没调的。第三个指标最容易被忽略，但工具一多，「不选」往往先于「选错」上升。
danluu 那篇讲 agent 怎么用测试和验证手段 的思路可以借过来：你没法验证的东西，你就不知道它在哪。工具选择的评测集就是这个验证手段。
样本小的时候波动大，跑一次不算数，同一配置多跑几轮看方差。我自己倾向于把「准确率开始明显往下掉」的那一批往回退一格，当成上限。
动态挂载：省了 token，赔上可复现
动态挂载是按当前 query 检索出相关工具再塞进 prompt。听起来合理，工具上千个的时候也确实得这么干。
问题是行为不可复现。同一个输入，两次检索到的工具集可能不一样，模型走的路就不一样。用户报了个 bug，你复现不出来——因为那次检索的上下文已经没了。日志得把检索结果一起记下来，否则 trace 都对不上。
这周 arXiv 上那篇 Procedural Graphs 讲自演化的执行结构。研究视角上漂亮，工程视角上我看到的是：执行图每次可能不同，出问题的时候你面对的是一个会变的东西。类似地，Cognition 讲 Devin 用 GPT-6 Astra 验证自己的工作，前提也是验证过程本身稳定可重复，否则自己验证自己就成了互相糊弄。
我不反对动态挂载，但它的位置在最后。工具集真到了几百上千、合并和分层都做完之后再说。而且那时候它更像个检索质量问题，不是「该挂几个」的问题。
我现在的默认
单 agent，工具控制在个位数，描述之间互相不重叠——这是我的起点。超过了先合并，合并不动拆 router，再往上才谈动态。
按我现在看，大部分团队的 agent 根本没到需要动态挂载的规模，是描述写糊了。也许半年后工具生态变了我会被打脸。但今天，先把那几个名字起得像双胞胎的工具改掉，收益比换架构大。