工具过多会带来什么具体伤害？
- 选择精度: 工具数量超过一百个时，即使最先进的大语言模型也容易在工具选择上出错;
- 上下文成本: 全部平铺进上下文要占去大量 token;
- 缓存: 每一次工具集的变动都会击穿 KV Cache;
- 定位: 这是“工具太多怎么办”的第一层答案——工具定义仍然事先备好，只是不再全量塞进上下文;
按需加载如何只暴露索引？
- 问题规模: 仅仅 5 个 MCP 服务器就可能引入数万 token 的工具定义开销，在 200K 的上下文窗口里还没开始对话就用掉了近三成;
- Cursor 方案: 将工具描述同步到文件夹中，Agent 默认只看到工具名称的索引，需要时再查询具体的定义;
- 效果: A/B 测试显示，这种方式使 MCP 工具相关任务的总 token 消耗减少了 46.9%;
Pi Coding Agent 的架构取舍是什么？
- 取舍: 核心模块刻意不内置 MCP，优先建议把能力封装成带 README 的 CLI 工具、再由 Skills 按需加载；确实需要 MCP 生态时通过扩展接入;
- 社区折中:
pi-mcp-adapter 让模型默认只看到一个约 200 token 的代理工具，通过“搜索→查看定义→调用”按需发现后端工具，MCP 服务器也延迟到首次使用时才启动;
- 结论: 是否采用 MCP 作为互操作协议与是否在会话开始时暴露所有 MCP 工具定义是两个独立决策;
- 建议: 后端保留 MCP 的生态兼容性，前端仍应以 CLI + Skills 或代理工具实现渐进式披露，避免服务器越接越多时上下文和 token 开销同步膨胀;
工具应按什么结构分类组织？
- 方式: 按信息源的性质分类，并在系统提示词中显式说明分类结构，帮助 LLM 快速定位相关工具组;
- 搜索工具: 主动查找信息——网络搜索、知识库搜索、文件搜索;
- 读取工具: 从已知位置提取内容——网页阅读、文档读取、数据库查询;
- 解析工具: 处理非结构化数据——图片 OCR、视频分析、音频转录;
- 查询工具: 访问结构化数据源——天气 API、股票 API、公开数据库;
检索式预筛选的效果如何？
- 机制: 不把全部工具定义一次性注入上下文，而是按语义相似度先筛出一批候选工具再注入;
- 依据: 可用工具达到上百个时，平铺到上下文中既浪费 token 又干扰决策;
- 数据: Anthropic 的实验显示，这种按需检索的方式使 Opus 4 在工具使用基准上的准确率从 49% 提升到 74%;
- 局限: 它按用户的初始查询做一次性匹配，任务中途出现的新需求无法覆盖，见 主动工具发现与动态加载;