741 个工具下准确率跌到 13.6%，用实测讲透工具该怎么选
The 100-Tool Agent Is a Trap - Sohail Shaikh & Ankush Rastogi, Prosodica · Sohail Shaikh
全片 28 分钟·真正值得盯屏约 5 分钟·2 个必看点
- 0:01 – 4:12略
问题是怎么长出来的
从最朴素的做法讲起：每次请求都把全部工具的名称、描述和参数结构交给模型。十来个工具时毫无问题，目录膨胀后就开始调错函数、混淆相似工具，甚至凭空编出不存在的工具名。
出问题的不是某个工具写得不好，而是架构本身强迫每个请求都背着整个目录走。
这一段配的是文字型幻灯片和一组 token 开销数字，其中 03:35 附近那页把「七百多个工具、光描述就占十二万多 token，而这还没算上用户真正的问题」摆在一起，值得停下来看一眼，其余部分听着过一遍即可。▶ 跳到 0:01讲者 · Sohail Shaikh - 4:15 – 7:30略
准确率为什么会塌方
拆解崩塌的三重原因：无关工具在选择集里互相竞争、超长上下文中间位置的内容不被可靠使用，以及描述相近的工具彼此干扰。同时把成本和延迟的恶化曲线一并摊开。
准确率不是线性下滑而是过某个规模后塌方，成本与延迟同时恶化，三者是同一个原因。
整段是把失败原因逐条列在幻灯片上再口头展开，讲者反复指向屏幕上的条目。看一遍列表比听完整段更省时间，具体举例可以听着掠过。▶ 跳到 4:15讲者 · Sohail Shaikh - 7:33 – 11:07看
换个架构：给工具做检索
把单体式全量注入和分层的检索式注入并排对照，然后讲原理——离线为每个工具写清描述并向量化入库，运行时用同样的方式处理用户提问，取出最接近的少数几个工具。
这本质上就是把检索增强那一套用在工具上，已有向量检索基础设施的团队几乎不用新建东西。
两张架构流程图的并排对照就是这一段的核心信息，光听描述很难在脑子里还原分层结构；09:35 之后讲者逐级指着离线建库与运行时检索的两条链路走了一遍。▶ 跳到 7:33讲者 · Ankush Rastogi - 11:10 – 14:15听
按需注入与「减法」效应
讲随用随取的注入方式：只把检索到的三到五个参数结构交给模型，token 开销从十几万降到千级。并点出一个常被忽略的好处——不相关的工具从模型的可选项里彻底消失。
路由的价值一半在于给对工具，另一半在于让错的工具根本不出现在选项里。
这一段基本是纯口头推演，屏幕上没有新增值得看的内容，边做别的事听完全不损失信息。▶ 跳到 11:10讲者 · Ankush Rastogi - 14:15 – 17:30略
基准测试怎么做、结果如何
交代评测设定后给出对照结果：全量注入的准确率随目录规模从约七成八一路跌到一成出头，检索式注入始终稳在八成以上；首个响应字的等待时间前者陡升、后者几乎不随目录变化。
工具目录可以继续长，但模型每次真正面对的工作集必须保持很小。
价值集中在两张对照图上，看清曲线走向和坐标轴刻度就够了，讲者对评测流程的口头补充信息密度不高。▶ 跳到 14:15讲者 · Ankush Rastogi - 17:33 – 23:25略
代码怎么写、上线怎么推
逐段过实现代码：遍历目录嵌入描述入库、运行时嵌入提问做相似度检索、最后只把命中的工具传给模型。接着是实战示例和一份七步上线清单，含从取五个候选起步的建议与评估方法。
改动量集中在「传给模型的工具列表从全量换成检索结果」这一处，对多数团队是一个 sprint 的活，不是平台重写。
屏幕上是代码片段和步骤清单，翻着看关键几行比顺着听更快；如果打算动手实现，18:00 前后那几屏代码建议逐行看清楚。▶ 跳到 17:33讲者 · Sohail Shaikh - 23:30 – 28:20略
风险、适用门槛与资源
讲两类主要风险——该命中的工具没被检索到，以及描述写得太差导致长期不被选中——并给出扩大候选数、二次检索、回退到更宽工具组等对策。最后给出采用门槛和参考资料。
工具数在一二十个时别过度设计，超过五十个或已经出现混淆和延迟问题时再上路由。
风险与对策是条目式罗列，扫读即可；结尾 27:20 之后是一页参考链接和讲者联系方式，需要的话截图留存，不需要就直接结束。▶ 跳到 23:30讲者 · Sohail Shaikh