一个内部 Agent 刚上线时往往只有两三个工具：搜索、建工单、查日历。半年后变成二十个，因为每个业务队都希望“顺手接上”。工具表变长的那一天，攻击面不是加了二十个按钮，而是出现了组合。
搜索加发送，是外带数据。读代码加终端，是执行。查人加改权限，是身份转移。模型不需要理解“攻击”，它只需要认为这样更有助于完成任务。
01工具爆炸先破坏的是任务边界
每个工具都有自己的说明、失败方式和副作用。数量变多以后，模型更难判断当前任务该用哪一个。描述里任何一个“如果失败可以……”都会把备用路径变成正式路径。
实验室里我们给同一个摘要任务逐步加工具。工具一多，Agent 开始做任务说明书里没写的“额外核对”，于是碰到了本不该出现的导出和通知接口。功能看起来更聪明，范围已经漂了。
02组合权限很难用清单看出来
安全评审如果逐个点头——搜索可以、日历可以、邮箱可以——会漏掉三者连在一起以后的能力。评估要把工具看成图：节点是接口，边是 Agent 可以自主决定的顺序。
一张二十个节点的图，人不该靠直觉保证它走不出危险路径。需要：
- 每个工具的数据入边和出边
- 哪些工具允许在同一任务中共存
- 哪些动作必须停下来等人
03治理办法不是禁止工具，而是按任务发牌
给“会议纪要 Agent”和“事故响应 Agent”两套工具表。不要维护一个全能运行时，再指望提示词让它谦虚。
定期做工具裁剪。没有调用、没有负责人、没有权限说明的工具，默认摘掉。
新工具上线按权限变更评审。接一个能发邮件的 MCP，等同于给系统开了一条出站通道。
二十个工具不是成熟的标志。能说清这二十个工具为什么必须同时在场，才是。