企业搜索中管理多个 MCP 数据源的连接、优先级与限流

当需要通过多个 MCP 数据源（聊天、邮件、云存储、任务、CRM、知识库）做企业搜索时，检测可用源、引导连接、按查询类型排序优先级并优雅处理限流。

适用场景

解决思路

1. 通过检查可用工具来判断哪些 MCP 源已连接：每个源对应一组 MCP 工具，若某工具前缀可用，则该源已连接且可搜索。
2. 当用户搜索但连接源很少或没有时，列出当前已连接的源数量与清单，并引导用户在 MCP 设置中连接更多源：~~chat（消息、线程、频道）、~~email（邮件、对话、附件）、~~cloud storage（文档、表格、幻灯片）、~~project tracker（任务、项目、里程碑）、~~CRM（客户、联系人、商机）、~~knowledge base（wiki 页面、知识库文章），并说明连接越多搜索结果越完整。
3. 当用户询问某个未连接的具体工具时，告知其未连接，并给出步骤：1. 打开 MCP 设置；2. 添加该工具的 MCP 服务器配置；3. 按提示完成认证；连接后会自动纳入后续搜索。
4. 按查询类型对源进行优先级排序（用于加权结果，而非跳过源）：决策类查询（“我们决定了什么……”）优先级为 ~~chat → ~~email → ~~cloud storage → Wiki → 任务跟踪器。
5. 状态类查询（“……的状态如何”）优先级为任务跟踪器（~~project tracker，权威状态）→ ~~chat → ~~cloud storage → ~~email → Wiki。
6. 文档类查询（“……的文档在哪”）优先级为 ~~cloud storage → Wiki / ~~knowledge base → ~~email → ~~chat → 任务跟踪器。
7. 人员类查询（“谁负责……”/“谁了解……”）优先级为 ~~chat → 任务跟踪器 → ~~cloud storage → ~~CRM → ~~email。
8. 事实/政策类查询（“我们对……的政策是什么”）优先级为 Wiki / ~~knowledge base → ~~cloud storage → ~~email → ~~chat。
9. 当查询类型不明确时使用默认优先级：~~chat → ~~email → ~~cloud storage → Wiki / ~~knowledge base → 任务跟踪器 → CRM。
10. 识别限流：限流响应通常表现为 HTTP 429、提及 “rate limit”“too many requests”“quota exceeded” 的错误消息，或被节流/延迟的响应。
11. 处理限流时：1. 不要立即重试，尊重限制；2. 继续使用其他源，不要阻塞整个搜索；3. 告知用户，例如“[源] 暂时被限流，以下结果来自 [其他源]，可几分钟后重试以包含 [源]”；4. 对于摘要（digest），若扫描中途被限流，记录限流前已覆盖的时间范围。
12. 预防限流：避免不必要的 API 调用，查询前先判断该源是否可能有相关结果；尽量使用有针对性的查询而非大范围扫描；对于摘要，在 API 支持时批量请求；注意缓存，若刚运行过搜索，避免立即重复同一查询。
13. 在会话期间跟踪源健康状态，例如列出各源为 ✓ 可用、✗ 未连接、⚠ 被限流（X 分钟后重试）。
14. 报告搜索结果时，说明搜索了哪些源，让用户了解答案的覆盖范围。
15. 添加自定义源：企业搜索插件可与任何 MCP 连接的源配合，新的 MCP 服务器可加入 .mcp.json 配置；搜索和摘要命令会根据可用工具自动检测并纳入新源。具体步骤：1. 将 MCP 服务器配置添加到 .mcp.json；2. 如需要则完成认证；3. 该源会自动纳入后续搜索。