Glean 企业知识库落地指南：权限、连接器、搜索质量与 AI Agent 治理

企业知识搜索项目最常见的失败原因，不是模型效果差，而是团队把“连接器安装完成”误认为“知识已经可用”。真正的上线工作包括数据边界、身份映射、权限测试、内容质量、搜索评估、员工教育和事故响应。本教程给出一套从小范围试点到可治理 Agents 的 Glean 落地流程。

这篇教程会完成什么

完成后，你应该得到以下交付物：

• 一份数据源与内容所有者清单；
• 一组用于验收的真实问题和不可见性测试；
• 两到三个已完成初始抓取的试点连接器；
• 一套 Search 与 Assistant 的质量指标；
• 一套权限、反馈、回滚和审计流程；
• 一个只读或低风险的首个 Agent 工作流；
• 一份是否扩大采购范围的试点结论。

这不是 Glean 后台按钮的逐屏说明，而是部署方法。不同客户的管理员界面、合同模块和连接器权限可能变化，实际操作应以当前 Glean Help Center、目标数据源文档和企业合同为准。

开始前需要准备

先指定四类负责人

至少需要以下角色参与：

1. 业务负责人：决定试点要解决的问题和成功标准。
2. IT 或身份负责人：负责 SSO、用户目录、群组和离职流程。
3. 安全与隐私负责人：审核数据范围、跨境、子处理者、保留和事件响应。
4. 知识域负责人：确认哪些文档有效、哪些应归档、谁处理反馈。

一个人可以承担多个角色，但责任不能空缺。若没有人愿意维护源数据，搜索质量会在演示后迅速下降。

选择一个窄而有价值的试点

不要第一天连接全公司的所有系统。优先选一个查找成本高、资料来源明确、权限结构能验证的部门，例如：

• 客户支持：产品文档、历史工单和事故复盘；
• 工程：GitHub、Jira、Confluence 和值班手册；
• 销售支持：获批案例、产品资料和 CRM 账户信息；
• 员工入职：政策、团队术语、组织信息和常见流程。

排除一开始就需要自动改客户数据、发送外部邮件、做财务审批的场景。首个目标应是“更快找到并验证信息”，而不是“让 Agent 自动管理公司”。

第一步：建立数据源清单

为每个候选数据源记录：

项目	要确认的内容
业务用途	谁使用、解决什么问题
内容范围	文档、消息、工单、代码还是 CRM 记录
权威性	哪些内容是正式来源
所有者	谁处理过期、重复和错误
身份模型	用户、群组、角色如何同步
敏感等级	是否包含个人信息、客户数据、财务或商业秘密
删除要求	删除和权限变更多久应传播
连接方式	原生连接器、Push API、Website、MCP 或自定义方式
合规边界	数据驻留、跨境、保留、许可和合同要求

Glean 官网在 2026 年列出 275+ 个开箱即用连接器，但数量不是采购指标。真正重要的是你使用的具体系统是否支持需要的对象、附件、记录级权限、增量更新和删除传播。

不要把所有连接器当成同一种权限模型

原生连接器通常会抓取内容和权限映射；Website 连接器则有特殊限制。Glean 文档提示，Website 数据源不会继承网页级细粒度权限，能访问该数据源的用户可能看到被抓取页面。自建 Push API 也需要你自己正确提供身份和 ACL。

因此每个连接器都要单独写威胁模型。不能用“Glean 支持权限感知搜索”一句话通过全部安全评审。

第二步：清理身份和权限

对齐唯一身份

确认 SSO、邮箱、员工目录和各来源系统账号能映射到同一个人。重点检查：

• 改名或邮箱域迁移产生的重复账号；
• 承包商、外部协作者和共享账号；
• 离职员工与休眠账号；
• 嵌套群组和动态群组；
• 管理员、服务账号与爬虫凭据；
• 多个 Slack、Microsoft 或 Google 租户。

如果身份映射错误，结果可能不是“搜不到”，而是“错误的人搜到了”。后者必须作为阻断上线的问题。

建立不可见性测试

为每个数据源准备三类测试账号：

1. 应该看到内容的普通成员；
2. 不应该看到该内容的其他部门成员；
3. 拥有特殊权限的管理员或项目成员。

测试不仅要搜索文件标题，还要询问文档中的独特句子、人员、客户名称和摘要。生成式答案可能引用或概括内容，即使原文件没有直接出现在结果列表里。

第三步：连接两个到三个高价值数据源

在 Glean Admin Console 中添加数据源时，按官方文档完成 OAuth、应用安装或凭据配置。只授予文档要求的权限，并保存批准记录。

限制初始抓取范围

如果连接器支持范围限制，先只抓取试点团队的空间、项目或站点。这样可以：

• 更快发现字段与权限问题；
• 降低误索引敏感内容的影响；
• 缩短初始同步时间；
• 让内容负责人能人工抽样；
• 便于出现问题时回滚。

Glean 文档说明，大型数据源或低 API 限额的数据源，初始同步可能需要数天。不要在 Items synced 数量仍快速增长时宣布上线。

检查抓取状态

每天记录：

• 已发现对象数量；
• 成功索引数量；
• 失败、跳过和仅元数据对象；
• 权限用户与群组数量；
• 最近增量更新时间；
• 删除和权限变更传播时间；
• API 限流与重试情况。

如果数量明显低于源系统预期，先检查授权范围和爬取限制，再联系支持。不要用少量演示问题掩盖数据缺失。

第四步：建立搜索质量基准

收集真实问题，不要自己编演示题

从试点用户最近一月的 Slack 提问、支持升级、入职问题和搜索日志中整理 50 至 100 个问题，并获得必要授权。问题应覆盖：

• 明确文件名；
• 业务术语和缩写；
• 同名项目；
• 时间限定；
• 跨两个以上系统；
• 没有答案的问题；
• 包含敏感关键词但测试者无权查看的内容；
• 已删除或刚修改的内容。

为每个问题记录期望来源、可接受答案和权限条件。答案不应只判“看起来不错”，而应检查来源是否正确、是否过期、是否漏掉权威文档。

推荐的验收指标

• Top 3 结果包含权威来源的比例；
• Assistant 答案有可用引用的比例；
• 引用与结论一致的比例；
• 无答案时明确承认不足的比例；
• 权限越界事件：必须为零；
• 平均找资料耗时；
• 用户是否回到原搜索或询问同事；
• 反馈问题的平均修复时间。

把基准保留下来。每次新增连接器、调整范围或升级重要功能后重新运行，避免质量在扩容时悄悄下降。

第五步：小范围上线 Glean Assistant

官方文档允许把 Assistant 先启用给测试组。建议首批只包含试点用户、知识负责人、安全人员和支持人员。

给用户三条明确规则

1. 引用是验证入口，不是正确性保证；
2. 合同、政策、价格、生产操作和外发内容必须打开原文；
3. 发现过期或越权内容立即通过统一渠道上报，不要只点差评。

可以提供十个高价值示例，例如“找到当前退款政策并引用生效日期”“比较两个事故复盘的共同原因”“列出这个客户最近 30 天已批准的关键更新”。避免用“帮我做所有工作”这类无法评估的提示。

区分检索问题和内容治理问题

用户反馈“答案错了”时，至少检查四层：

• 源文档本身是否错误或过期；
• 连接器是否抓取完整；
• 权限和身份是否正确；
• 检索、排序或生成是否错误。

只有最后一层才主要是模型问题。建立分类后，问题才能分派给正确负责人。

第六步：再引入 Glean Agents

等 Search 与 Assistant 的引用和权限稳定后，再选择一个低风险 Agent。好的第一个 Agent 具备：

• 输入来源明确；
• 只读或只生成内部草稿；
• 输出有固定格式；
• 每一步能审计；
• 失败不会影响客户、财务或生产；
• 有人工确认点；
• 可以与人工流程比较时间和质量。

示例：每天读取获批项目更新，生成内部周报草稿，并把缺少负责人或日期的条目标出来。不要让首个 Agent 自动发送外部邮件、修改 CRM 关键字段或关闭工单。

为 Actions 设置边界

对每个 Action 记录：

• 使用谁的身份执行；
• 可以读取和修改哪些对象；
• 是否需要确认；
• 超时、重复执行和部分失败如何处理；
• 日志保留多久；
• 如何暂停与撤销；
• 谁能创建、发布和修改 Agent。

Glean 的治理能力能提供控制点，但组织仍需决定哪些操作允许自动化。

第七步：评估价格与合同

由于官网没有统一公开固定价格，向销售请求可比较的书面报价。至少拆分：

• Search、Assistant、Agents 或平台模块；
• 用户、访客、外部协作者和测试账号；
• 原生与自定义连接器；
• 模型或 FlexCredits 用量；
• 实施、迁移和高级支持；
• 数据驻留、私有网络或特殊部署；
• 沙盒和测试环境；
• 续约、超量和提前终止。

同时要求安全文档、子处理者列表、数据处理协议、删除证明、事故通知时限和服务等级。中国团队还要评估网络可用性与跨境数据要求。

第八步：做出扩容或停止决定

试点结束时，不要只展示“员工很喜欢”。用最初的基准回答：

• 找资料时间减少了多少；
• 权威来源命中率是否提高；
• 引用是否足以支持验证；
• 权限测试是否全部通过；
• 哪些问题需要持续人工维护；
• 年度总成本与节省时间是否匹配；
• 员工是否在四周后仍主动使用；
• 停止后能否删除索引并恢复原流程。

如果权限问题未解决、数据所有者缺位或价值只存在于少数演示问题，应该缩小范围或暂停，而不是用更多连接器掩盖问题。

常见错误

一次连接所有系统

范围过大导致无法判断哪个连接器、权限或数据源造成问题。先窄后宽更容易建立信任。

只测试管理员账号

管理员能看到全部内容，无法发现权限泄漏。普通账号和无权限账号才是必要测试对象。

把旧文档问题归咎于 AI

搜索系统会放大源内容的混乱。建立权威来源和过期流程，通常比继续调提示更有效。

先做高风险自动化

检索和身份尚未稳定时开放写入 Actions，会把错误从答案扩散到业务系统。先只读、后草稿、再审批写入。

忽略退出方案

合同结束、试点失败或安全事件发生时，需要知道如何停用连接器、撤销凭据、导出必要配置、删除索引并取得证明。

最终检查清单

在扩大上线前确认：

• 每个数据源有负责人和批准范围；
• 身份、群组、离职和外部协作者测试通过；
• 敏感内容不可见性测试为零失败；
• 初始抓取完成，增量和删除传播符合预期；
• 真实问题集达到目标命中率；
• Assistant 引用可回查且用户理解验证责任；
• Agent 只有必要权限并设置人工确认；
• 合同、报价、数据驻留和退出条款已确认；
• 有反馈、事故、暂停和回滚负责人；
• 试点价值足以覆盖许可证与运营成本。

Glean 的正确上线顺序应是：先治理身份和数据，再验证 Search，然后启用 Assistant，最后才扩大 Agents。顺序颠倒，会让自动化速度超过组织发现错误的速度。