关于Gemini Enterprise GitHub连接器的四项技术问题咨询

场景概述 #

正在测试Gemini Enterprise/AI Applications的GitHub连接器，目标是为单个私有仓库打造只读搜索/评审助手，确保无GitHub写入操作。当前配置：

• 手动创建GitHub App，仅授予Contents、Metadata只读权限，Checks/Commit statuses设为无访问，未启用Issues和PRs
• Gemini连接器仅选择Repositories实体，跳过所有GitHub Actions，搜索应用连接至GitHub Data Store

观察到的行为：预览搜索能返回仓库相关文档，但搜索不存在的文件名时，仍会返回索引内语义相关的内容

疑问1：GitHub连接器是实时搜索私有仓库，还是仅搜索已索引的GitHub Data Store？ #

Gemini Enterprise的GitHub连接器基于已索引到GitHub Data Store的内容进行搜索，并非实时查询私有仓库。配置连接器时，系统会将指定仓库的内容同步并索引到Data Store，后续所有搜索操作都基于该索引库返回结果。这也是搜索不存在的文件名时会返回语义相关已索引文档的原因——系统仅在已同步的索引范围内做语义匹配，不会实时校验仓库当前的文件状态。

疑问2：在跳过所有actions且移除GitHub App写入权限的情况下，Gemini应用是否仍存在向GitHub写入的路径？ #

不存在写入路径。你的配置从两方面彻底阻断了写入可能：

• GitHub App仅配置了Contents、Metadata的只读权限，未授予任何写入类权限（Checks/Commit statuses无访问，未启用Issues/PRs）
• 连接器设置中跳过了所有GitHub Actions

Gemini应用的操作权限完全依赖GitHub App的权限配置，没有额外的写入通道，可确保应用无法向GitHub写入数据。

疑问3：Repositories实体是用于精确文件级查找和文件存在性检查，还是仅用于对已索引仓库内容进行语义搜索？ #

Repositories实体的核心作用是将指定仓库的内容同步到GitHub Data Store，供后续语义搜索使用，它本身不具备精确的文件存在性检查能力。从你观察到的行为也能验证这一点：搜索不存在的文件名时，系统返回的是语义相关的已索引内容，而非校验文件是否真实存在。

疑问4：若需实现精确文件存在性检查，是否应使用GitHub API、Developer Connect或其他架构替代Gemini Enterprise GitHub连接器？ #

如果需要精确的文件存在性检查，直接调用GitHub API是最优方案——通过GET /repos/{owner}/{repo}/contents/{path}接口可实时校验文件是否存在，结果明确且实时性强。Gemini Enterprise的GitHub连接器定位是语义搜索助手，不适合做精确的文件状态校验；Developer Connect更多用于集成开发工具链，并非这类场景的合适选择。

内容的提问来源于stack exchange，提问作者lf-poc