Enterprise Search 数据源管理指南Source Management 技能的原理与实战【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins导读在 Claude Cowork / Claude Code 环境中企业搜索插件enterprise-search通过 MCPModel Context Protocol同时接入聊天、邮件、云盘、知识库、项目跟踪与 CRM 等多种数据源让一条查询搜遍全公司。本篇文章聚焦该插件中的source-management数据源管理技能——它负责回答当前有哪些数据源已连接、如何引导用户接入新数据源、查询时数据源优先级如何排定、遇到速率限制如何优雅降级等一系列问题。读完本文你将掌握该技能定义的完整数据源分类体系、五种查询类型下的优先级策略、速率限制的检测与处理流程以及如何通过.mcp.json扩展自定义数据源。该技能对应的源码位置为 source-management/SKILL.md与之配合的还有 search-strategy、search、knowledge-synthesis、digest 四个技能以及 CONNECTORS.md 连接器说明文档。技能定位企业搜索的连接中枢在 enterprise-search 插件的整体架构中五个技能各有分工构成一条完整的搜索流水线技能职责触发方式source-management感知已连接数据源、引导接入新源、管理源优先级、处理速率限制自动user-invocable: falsesearch-strategy查询分解、按源翻译查询语法、结果排序、歧义与降级处理自动search跨所有已连接数据源执行单条查询并综合结果用户命令/searchdigest跨源生成每日/每周活动摘要用户命令/digestknowledge-synthesis多源结果去重、置信度评分、归因汇总自动source-management 是这条流水线的起点与兜底搜索前它负责盘点现在能搜哪些源搜索中它负责按查询类型调整源优先级搜索失败或受限时它负责告知用户如何补充连接、如何处理限流。user-invocable: false意味着它不会被用户直接调用而是在搜索流程中由 Agent 自动触发。该技能通过~~category占位符表示数据源类别。根据 CONNECTORS.md 的说明插件是**工具无关tool-agnostic**的~~chat可以代表 Slack也可以代表 Microsoft Teams 或 Discord~~email可以是 Microsoft 365也可以是任何带 MCP 服务器的邮件工具。这类占位符会在搜索结果中以~~chat:、~~email:的形式作为来源标签出现运行时动态解析为实际连接的工具。检查已连接的数据源技能首先定义了六类标准数据源及其关键能力数据源关键能力~~chat搜索消息、读取频道与线程~~email搜索邮件、读取单封邮件~~cloud storage搜索文件、获取文档内容~~project tracker搜索任务、typeahead联想搜索~~CRM查询记录账户、联系人、商机~~knowledge base语义搜索、关键词搜索判定规则非常直接只要某个工具前缀tool prefix可用就代表对应数据源已连接且可搜索。即 Agent 在执行搜索前先检查当前可用工具列表available tool list依据工具前缀判断哪些源在线。例如在 .mcp.json 中预配置了slack、notion、guru、atlassian、asana、google calendar、gmail等 MCP 服务器当这些服务器的工具出现在工具列表中时对应的~~chatSlack、~~knowledge baseNotion/Guru、~~project trackerAtlassian/Asana等类别即为可用状态。如果在检查过程中看到不熟悉的占位符或想核对哪些工具已连接可随时查阅 CONNECTORS.md其中给出了每个类别对应的默认 MCP 服务器与可替换选项类别占位符默认内置服务器其他可选Chat~~chatSlackMicrosoft Teams、DiscordEmail~~emailMicrosoft 365—Cloud storage~~cloud storageMicrosoft 365DropboxKnowledge base~~knowledge baseNotion、GuruConfluence、SliteProject tracker~~project trackerAtlassian (Jira/Confluence)、AsanaLinear、monday.comCRM~~CRM未预配置Salesforce、HubSpotOffice suite~~office suiteMicrosoft 365Google Workspace注意~~CRM在仓库中并未预配置具体服务器需要用户自行在 MCP 设置中补充如 Salesforce 或 HubSpot 的 MCP 服务器这印证了CRM 连接数通常最少的实操现状。引导用户接入新数据源当用户发起搜索但连接的数据源很少甚至为零时技能要求 Agent 主动引导用户扩展连接而不是直接给出搜不到。技能提供了两种标准引导话术模板。场景一数据源数量不足——向用户明确当前连接数列出可接入的类别及其用途强调连接越多、搜索结果越完整You currently have [N] source(s) connected: [list]. To expand your search, you can connect additional sources in your MCP settings: - ~~chat — messages, threads, channels - ~~email — emails, conversations, attachments - ~~cloud storage — docs, sheets, slides - ~~project tracker — tasks, projects, milestones - ~~CRM — accounts, contacts, opportunities - ~~knowledge base — wiki pages, knowledge base articles The more sources you connect, the more complete your search results.场景二用户询问某个尚未连接的具体工具——给出三步接入指引[Tool name] isnt currently connected. To add it: 1. Open your MCP settings 2. Add the [tool] MCP server configuration 3. Authenticate when prompted Once connected, it will be automatically included in future searches.这两段模板的要点在于连接动作发生在用户侧的 MCP 设置中插件无需改动——新源一旦接入后续搜索会自动包含它。这与 search/SKILL.md 中的行为一致当零数据源连接时Agent 会提示Check your MCP settings to add ~~chat, ~~email, ~~cloud storage, or other tools同样把连接动作引导到 MCP 设置。数据源优先级排序不同查询类型受益于不同的搜索顺序。source-management 技能给出了按查询类型与默认两套优先级并明确说明优先级用于加权结果而不是跳过某些源Use these priorities to weight results, not to skip sources。按查询类型划分的优先级决策类查询What did we decide...——决策发生在对话中其次才是正式确认与记录1. ~~chat决策发生的对话 2. ~~email决策确认、公告 3. ~~cloud storage会议纪要、决策日志 4. Wiki若决策有文档化记录 5. Task tracker若决策被捕获到任务中状态类查询Whats the status of...——任务跟踪器是权威状态来源聊天是实时补充1. Task tracker~~project tracker——权威状态 2. ~~chat实时讨论 3. ~~cloud storage状态文档、报告 4. ~~email状态更新邮件 5. Wiki项目页面文档类查询Wheres the doc for...——云盘是主要文档存储1. ~~cloud storage主要文档存储 2. Wiki / ~~knowledge base知识库 3. ~~email通过邮件共享的文档 4. ~~chat在频道中共享的文档 5. Task tracker链接到任务的文档人员类查询Who works on... / Who knows about...——先看消息作者与频道成员再看任务负责人、文档协作者1. ~~chat消息作者、频道成员 2. Task tracker任务负责人 3. ~~cloud storage文档作者、协作者 4. ~~CRM账户负责人、联系人 5. ~~email邮件参与者事实/政策类查询Whats our policy on...——官方文档优先1. Wiki / ~~knowledge base官方文档 2. ~~cloud storage政策文档、手册 3. ~~email政策公告 4. ~~chat政策讨论默认优先级一般查询当查询类型不明确时采用覆盖最广的默认顺序1. ~~chat体量最大、最实时 2. ~~email正式沟通 3. ~~cloud storage文档与文件 4. Wiki / ~~knowledge base结构化知识 5. Task tracker工作任务 6. CRM客户数据与 search-strategy 的呼应这套优先级并非孤立设计它与 search-strategy/SKILL.md 的查询类型分类表一一对应决策、状态、文档、人员、事实/政策、时间、探索七类查询各自有不同的策略且 search-strategy 为不同查询类型给出了可量化的相关性权重例如决策查询中 Keyword match0.3、Freshness0.3、Authority0.2、Completeness0.2事实查询中 Authority 权重升至 0.4以及随查询类型变化的权威层级——事实/政策类问题遵循Wiki/官方文档 共享文档 邮件公告 聊天消息状态类问题遵循任务跟踪器 近期聊天 状态文档 邮件更新。可见 source-management 的优先级顺序是 search-strategy 排序权重在数据源选择层面的落地体现。速率限制感知与处理MCP 数据源普遍存在速率限制rate limitsource-management 技能要求 Agent 优雅地处理限流避免粗暴重试。限流信号的识别速率限制响应通常呈现为以下形态HTTP 429 响应错误消息中出现 rate limit、too many requests 或 quota exceeded 字样响应被节流throttled或明显延迟限流时的处理流程当某个数据源被限流时按以下四步处理不要立即重试——尊重限制避免加剧限流继续使用其他数据源——不要让单个源的限流阻塞整个搜索与 search-strategy 的降级策略一致Rate limited: Note the limitation, return results from other sources, suggest retrying later告知用户给出明确的提示模板Note: [Source] is temporarily rate limited. Results below are from [other sources]. You can retry in a few minutes to include [source].对于 digest 摘要场景——若在扫描中途被限流需要注明限流发生前已覆盖的时间范围避免用户误以为摘要覆盖了完整窗口。预防性措施避免不必要的 API 调用——查询前先判断该源是否可能有相关结果优先使用定向查询而非宽泛扫描digest 场景下尽量批量请求在 API 支持的前提下利用缓存意识——如果刚刚执行过相同搜索不要立刻重复同样的查询。在 digest/SKILL.md 中同样能看到限流降级的呼应任何源失败或不可达时生成Could not reach [source name]...提示并坚持不要让单个失败的源阻止摘要生成从可用源中产出尽可能好的摘要。数据源健康状态跟踪技能要求在会话期间持续跟踪各数据源可用性并维护一份运行状态清单Source Status: ~~chat: ✓ Available ~~email: ✓ Available ~~cloud storage: ✓ Available ~~project tracker: ✗ Not connected ~~CRM: ✗ Not connected ~~knowledge base: ⚠ Rate limited (retry in 2 min)这份清单覆盖三种状态可用✓、未连接✗与限流⚠含建议重试时间。更重要的是在汇报搜索结果时必须说明本次搜索覆盖了哪些数据源——这让用户清楚答案的覆盖范围scope。这与 search/SKILL.md 的partial results处理一脉相承部分源失败时明确列出成功源与失败源零结果时同样要列出已搜索的源清单帮助用户判断是真没有还是源没连上。添加自定义数据源enterprise-search 插件不绑定任何特定供应商——任何通过 MCP 连接的数据源都可以被搜索。随着新的 MCP 服务器出现只需修改.mcp.json配置即可扩展数据源search 与 digest 命令会根据可用工具自动检测并纳入新数据源无需改动插件代码。添加新数据源的完整步骤将 MCP 服务器配置添加到.mcp.json按提示完成身份认证如 OAuth该数据源将在后续搜索中自动包含仓库中的 .mcp.json 展示了预配置的 MCP 服务器结构。以其中配置为例一个标准 HTTP 类型 MCP 服务器包含type与url字段Slack 服务器还演示了 OAuth 认证配置clientId与callbackPort字段而google calendar、gmail则预留了空 URL等待用户填入自己的端点{ mcpServers: { slack: { type: http, url: https://mcp.slack.com/mcp, oauth: { clientId: 1601185624273.8899143856786, callbackPort: 3118 } }, notion: { type: http, url: https://mcp.notion.com/mcp }, guru: { type: http, url: https://mcp.api.getguru.com/mcp }, atlassian: { type: http, url: https://mcp.atlassian.com/v1/mcp }, asana: { type: http, url: https://mcp.asana.com/v2/mcp }, google calendar: { type: http, url: }, gmail: { type: http, url: } } }结合 CONNECTORS.md 可看出插件工具无关的设计意图.mcp.json只是预配置了默认服务器任何同类别的 MCP 服务器如用 Microsoft Teams 替换 Slack、用 Salesforce 接入 CRM都能无缝工作——这正是 source-management 技能能够以类别为单位管理数据源的底层前提。最佳实践小结综合 source-management/SKILL.md 及关联技能数据源管理的最佳实践可归纳为搜索前盘点先检查工具列表确认已连接数据源零连接时主动引导用户配置 MCP而不是直接报无结果按类型加权根据决策/状态/文档/人员/事实/政策等查询类型选择数据源优先级优先级用于加权而非跳过任何源限流不阻塞单源限流时立即转战其他源保留retry in X minutes信息digest 场景记录已覆盖的时间范围透明汇报覆盖范围每次报告搜索结果时说明搜索了哪些源用户才能正确解读答案的边界配置即扩展新数据源通过.mcp.json添加并完成认证即可自动生效无需修改插件代码。掌握这套数据源管理逻辑后你可以像操作一个全公司级搜索引擎一样让 Agent 在正确的时间、以正确的优先级、查询正确的一组数据源——这也是 enterprise-search 插件一次查询、多源并发、综合成答体验的地基。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考