跳到主内容Loading...
企业知识搜索项目最常见的失败原因，不是模型效果差，而是团队把“连接器安装完成”误认为“知识已经可用”。真正的上线工作包括数据边界、身份映射、权限测试、内容质量、搜索评估、员工教育和事故响应。本教程给出一套从小范围试点到可治理 Agents 的 Glean 落地流程。
这篇教程会完成什么
完成后，你应该得到以下交付物：
- 一份数据源与内容所有者清单；
- 一组用于验收的真实问题和不可见性测试；
- 两到三个已完成初始抓取的试点连接器；
- 一套 Search 与 Assistant 的质量指标；
- 一套权限、反馈、回滚和审计流程；
- 一个只读或低风险的首个 Agent 工作流；
- 一份是否扩大采购范围的试点结论。
这不是 Glean 后台按钮的逐屏说明，而是部署方法。不同客户的管理员界面、合同模块和连接器权限可能变化，实际操作应以当前 Glean Help Center、目标数据源文档和企业合同为准。
开始前需要准备
先指定四类负责人
至少需要以下角色参与：
- 业务负责人：决定试点要解决的问题和成功标准。
- IT 或身份负责人：负责 SSO、用户目录、群组和离职流程。
- 安全与隐私负责人：审核数据范围、跨境、子处理者、保留和事件响应。
- 知识域负责人：确认哪些文档有效、哪些应归档、谁处理反馈。
一个人可以承担多个角色，但责任不能空缺。若没有人愿意维护源数据，搜索质量会在演示后迅速下降。
选择一个窄而有价值的试点
不要第一天连接全公司的所有系统。优先选一个查找成本高、资料来源明确、权限结构能验证的部门，例如：
- 客户支持：产品文档、历史工单和事故复盘；
- 工程：GitHub、Jira、Confluence 和值班手册；
- 销售支持：获批案例、产品资料和 CRM 账户信息；
- 员工入职：政策、团队术语、组织信息和常见流程。
排除一开始就需要自动改客户数据、发送外部邮件、做财务审批的场景。首个目标应是“更快找到并验证信息”，而不是“让 Agent 自动管理公司”。
第一步：建立数据源清单
为每个候选数据源记录：
| 项目 | 要确认的内容 |
|---|
| 业务用途 | 谁使用、解决什么问题 |
| 内容范围 | 文档、消息、工单、代码还是 CRM 记录 |
| 权威性 | 哪些内容是正式来源 |
| 所有者 | 谁处理过期、重复和错误 |
| 身份模型 | 用户、群组、角色如何同步 |
| 敏感等级 | 是否包含个人信息、客户数据、财务或商业秘密 |
| 删除要求 | 删除和权限变更多久应传播 |
| 连接方式 | 原生连接器、Push API、Website、MCP 或自定义方式 |
常见问题
- Glean 第一次应该连接多少个数据源？
- 建议先连接两个到三个高价值、权限结构清楚的数据源。范围太大时，很难定位数据缺失、权限错误和搜索质量问题。
- Glean 初始同步需要多久？
- 取决于数据量和来源 API 限额。官方文档提示，大型或限流严格的数据源可能需要数天；应等抓取数量稳定并完成抽样后再验收。
- 如何测试 Glean 没有泄露权限？
- 使用有权限、无权限和特殊权限三类账号，既搜索标题，也询问文档中的独特内容。每个连接器都要验证权限、删除和群组变更的传播。
- 应该先上线 Glean Search 还是 Agents？
- 先验证 Search，再小范围启用 Assistant，最后才做 Agents。检索和权限尚未稳定时开放自动写入，会把错误扩散到业务系统。
- Glean 试点该看哪些指标？
- 至少跟踪权威来源命中率、引用正确率、无答案处理、找资料耗时、持续使用率、反馈修复时间和零权限越界。
- Glean 项目失败后如何退出？
- 提前约定停用连接器、撤销 OAuth 与服务账号、导出必要配置、删除索引、取得删除证明和恢复原流程，合同中也要写清数据保留与终止责任。
Glean 官网在 2026 年列出 275+ 个开箱即用连接器，但数量不是采购指标。真正重要的是你使用的具体系统是否支持需要的对象、附件、记录级权限、增量更新和删除传播。
不要把所有连接器当成同一种权限模型
原生连接器通常会抓取内容和权限映射；Website 连接器则有特殊限制。Glean 文档提示，Website 数据源不会继承网页级细粒度权限，能访问该数据源的用户可能看到被抓取页面。自建 Push API 也需要你自己正确提供身份和 ACL。
因此每个连接器都要单独写威胁模型。不能用“Glean 支持权限感知搜索”一句话通过全部安全评审。
第二步：清理身份和权限
对齐唯一身份
确认 SSO、邮箱、员工目录和各来源系统账号能映射到同一个人。重点检查：
- 改名或邮箱域迁移产生的重复账号；
- 承包商、外部协作者和共享账号；
- 离职员工与休眠账号；
- 嵌套群组和动态群组；
- 管理员、服务账号与爬虫凭据；
- 多个 Slack、Microsoft 或 Google 租户。
如果身份映射错误，结果可能不是“搜不到”，而是“错误的人搜到了”。后者必须作为阻断上线的问题。
建立不可见性测试
- 应该看到内容的普通成员；
- 不应该看到该内容的其他部门成员；
- 拥有特殊权限的管理员或项目成员。
测试不仅要搜索文件标题，还要询问文档中的独特句子、人员、客户名称和摘要。生成式答案可能引用或概括内容，即使原文件没有直接出现在结果列表里。
第三步：连接两个到三个高价值数据源
在 Glean Admin Console 中添加数据源时，按官方文档完成 OAuth、应用安装或凭据配置。只授予文档要求的权限，并保存批准记录。
限制初始抓取范围
如果连接器支持范围限制，先只抓取试点团队的空间、项目或站点。这样可以：
- 更快发现字段与权限问题；
- 降低误索引敏感内容的影响；
- 缩短初始同步时间；
- 让内容负责人能人工抽样；
- 便于出现问题时回滚。
Glean 文档说明，大型数据源或低 API 限额的数据源，初始同步可能需要数天。不要在 Items synced 数量仍快速增长时宣布上线。
检查抓取状态
- 已发现对象数量；
- 成功索引数量；
- 失败、跳过和仅元数据对象；
- 权限用户与群组数量；
- 最近增量更新时间；
- 删除和权限变更传播时间；
- API 限流与重试情况。
如果数量明显低于源系统预期，先检查授权范围和爬取限制，再联系支持。不要用少量演示问题掩盖数据缺失。
第四步：建立搜索质量基准
收集真实问题，不要自己编演示题
从试点用户最近一月的 Slack 提问、支持升级、入职问题和搜索日志中整理 50 至 100 个问题，并获得必要授权。问题应覆盖：
- 明确文件名；
- 业务术语和缩写；
- 同名项目；
- 时间限定；
- 跨两个以上系统；
- 没有答案的问题；
- 包含敏感关键词但测试者无权查看的内容；
- 已删除或刚修改的内容。
为每个问题记录期望来源、可接受答案和权限条件。答案不应只判“看起来不错”，而应检查来源是否正确、是否过期、是否漏掉权威文档。
推荐的验收指标
- Top 3 结果包含权威来源的比例；
- Assistant 答案有可用引用的比例；
- 引用与结论一致的比例；
- 无答案时明确承认不足的比例；
- 权限越界事件：必须为零；
- 平均找资料耗时；
- 用户是否回到原搜索或询问同事；
- 反馈问题的平均修复时间。
把基准保留下来。每次新增连接器、调整范围或升级重要功能后重新运行，避免质量在扩容时悄悄下降。
第五步：小范围上线 Glean Assistant
官方文档允许把 Assistant 先启用给测试组。建议首批只包含试点用户、知识负责人、安全人员和支持人员。
给用户三条明确规则
- 引用是验证入口，不是正确性保证；
- 合同、政策、价格、生产操作和外发内容必须打开原文；
- 发现过期或越权内容立即通过统一渠道上报，不要只点差评。
可以提供十个高价值示例，例如“找到当前退款政策并引用生效日期”“比较两个事故复盘的共同原因”“列出这个客户最近 30 天已批准的关键更新”。避免用“帮我做所有工作”这类无法评估的提示。
区分检索问题和内容治理问题
- 源文档本身是否错误或过期；
- 连接器是否抓取完整；
- 权限和身份是否正确；
- 检索、排序或生成是否错误。
只有最后一层才主要是模型问题。建立分类后，问题才能分派给正确负责人。
第六步：再引入 Glean Agents
等 Search 与 Assistant 的引用和权限稳定后，再选择一个低风险 Agent。好的第一个 Agent 具备：
- 输入来源明确；
- 只读或只生成内部草稿；
- 输出有固定格式；
- 每一步能审计；
- 失败不会影响客户、财务或生产；
- 有人工确认点；
- 可以与人工流程比较时间和质量。
示例：每天读取获批项目更新，生成内部周报草稿，并把缺少负责人或日期的条目标出来。不要让首个 Agent 自动发送外部邮件、修改 CRM 关键字段或关闭工单。
为 Actions 设置边界
- 使用谁的身份执行；
- 可以读取和修改哪些对象；
- 是否需要确认；
- 超时、重复执行和部分失败如何处理；
- 日志保留多久；
- 如何暂停与撤销；
- 谁能创建、发布和修改 Agent。
Glean 的治理能力能提供控制点，但组织仍需决定哪些操作允许自动化。
第七步：评估价格与合同
由于官网没有统一公开固定价格，向销售请求可比较的书面报价。至少拆分：
- Search、Assistant、Agents 或平台模块；
- 用户、访客、外部协作者和测试账号；
- 原生与自定义连接器；
- 模型或 FlexCredits 用量；
- 实施、迁移和高级支持；
- 数据驻留、私有网络或特殊部署；
- 沙盒和测试环境；
- 续约、超量和提前终止。
同时要求安全文档、子处理者列表、数据处理协议、删除证明、事故通知时限和服务等级。中国团队还要评估网络可用性与跨境数据要求。
第八步：做出扩容或停止决定
试点结束时，不要只展示“员工很喜欢”。用最初的基准回答：
- 找资料时间减少了多少；
- 权威来源命中率是否提高；
- 引用是否足以支持验证；
- 权限测试是否全部通过；
- 哪些问题需要持续人工维护；
- 年度总成本与节省时间是否匹配；
- 员工是否在四周后仍主动使用；
- 停止后能否删除索引并恢复原流程。
如果权限问题未解决、数据所有者缺位或价值只存在于少数演示问题，应该缩小范围或暂停，而不是用更多连接器掩盖问题。
常见错误
一次连接所有系统
范围过大导致无法判断哪个连接器、权限或数据源造成问题。先窄后宽更容易建立信任。
只测试管理员账号
管理员能看到全部内容，无法发现权限泄漏。普通账号和无权限账号才是必要测试对象。
把旧文档问题归咎于 AI
搜索系统会放大源内容的混乱。建立权威来源和过期流程，通常比继续调提示更有效。
先做高风险自动化
检索和身份尚未稳定时开放写入 Actions，会把错误从答案扩散到业务系统。先只读、后草稿、再审批写入。
忽略退出方案
合同结束、试点失败或安全事件发生时，需要知道如何停用连接器、撤销凭据、导出必要配置、删除索引并取得证明。
最终检查清单
Glean 的正确上线顺序应是：先治理身份和数据，再验证 Search，然后启用 Assistant，最后才扩大 Agents。顺序颠倒，会让自动化速度超过组织发现错误的速度。
