Glean

Glean 是什么？

Glean 是一个企业级 Work AI 平台，把企业知识、系统与上下文连接起来，让 AI 能在组织内部真正干活，而不是拿着公网知识泛泛作答。它要解决的问题是大型组织特有的：员工做事所需的信息散落在 Slack 对话、Google Drive 文档、Jira 工单、Confluence 页面、SharePoint 站点、GitHub 仓库和 Salesforce 记录里，而任何通用聊天机器人都碰不到这些内容。Glean 把这些材料建成索引，理解谁有权看到什么，然后在其上架起搜索框、助手与一批智能体。

运营主体是 Glean Technologies, Inc. 及其子公司。这里有一处必须说清的边界：官网发布的隐私声明只覆盖网站与商务运营，明确声明不适用于你对其产品与服务本身的使用——换句话说，约束企业数据处理方式的是合同条款，不是这份公开政策。创始人兼 CEO Arvind Jain 曾在 Google 任杰出工程师十余年，领导搜索、地图与 YouTube 团队，此前还联合创办了 Rubrik；联合创始人兼 CTO Vishwanath T R 在 Facebook 担任技术领导近十年。这份履历在这里是有意义的：企业搜索首先是索引与排序问题，其次才是 AI 问题。

官方时间线本身就解释了产品形态：2019 年成立、以隐身模式开发企业搜索，2021 年公开发布时已在 40 多家公司运行，2022 年成为独角兽，2023 年推出对话式 Assistant，2025 年推出 Agents 并达到 72 亿美元估值，2026 年推出 AI coworkers。检索与权限层先建成，生成式能力是后来长在上面的——这与消费级 AI 搜索的路径正好相反：后者从模型出发，再试图给它接上企业数据。

核心功能

• 覆盖企业应用版图的连接器层：连接器不是集成清单，而是整个产品的地基。官方提供 275 个以上开箱即用的连接器，分为原生连接器、基于 MCP 的连接器，以及供系统主动推送数据的 Push API。目录按职能组织——销售与市场、工程与分析、人力资源、文档、项目管理——覆盖多数公司实际在跑的系统。
• 查询时刻强制执行的权限继承：所有数据权限从源系统继承并严格执行，用户只能看到自己本就有权查看的内容；权限变更立即反映到结果，而不是等下一次爬取。这是企业搜索最难的部分，也是评估任何同类产品时最该盯住的一点。
• 建立在索引之上的知识图谱：平台在数据之上构建索引与知识图谱，从而理解业务实际如何运转——谁负责什么、哪些项目属于哪些团队、哪份文档才是权威版本——而不是把每份文档当成孤立的文本块。
• 能接触真实企业上下文的助手：对话层基于内部材料作答，并可调用 35 种以上不同的大语言模型，让组织按成本、能力或供应商政策自行选型，而不被绑定在单一模型厂商上。
• 能执行工作的 Agents 与 Actions：在检索之外，可以用自然语言下达任务，按事件或计划触发智能体，并通过明确的动作边界与执行前的人工审批来约束智能体能做什么。
• 把 token 经济学做成显性卖点：官方的商业主张已从「找得到」转向「省得下」，自述相较开箱即用的 MCP 工具可减少 30% 的 token 用量。逻辑是：预先连接好、结构良好的上下文意味着模型为得到答案所需执行的操作更少。
• 横跨平台、数据与智能体的治理层：Glean Protect 把安全控制分为三层，分别覆盖部署隔离、敏感数据检测与整改，以及自主智能体的行为护栏。

使用场景

1. 减轻专家团队的内部支持负担：多数大公司里，总有少数人反复回答同样的问题，只因为只有他们知道答案在哪。把员工引向一个权限感知的搜索层，等于把这些答案转成自助服务。一位在支持岗位的 PeerSpot 评价者描述，把 Confluence 与 Jira 工单连起来后，视角比分别查询各系统快得多，工单关闭时间约有 5% 的改善。
2. 让新人快速融入庞大的代码库与组织结构：新人往往要花几周才搞清哪份文档是现行版本、某个服务归谁负责、该找谁问。覆盖公司真实系统的知识图谱能压缩这段摸索期；而因为权限是继承的，新人看到的恰好是其岗位有权访问的那部分材料。
3. 不自建 RAG 也能让 AI 有据可依：许多企业尝试自建检索增强生成栈，然后发现真正吃掉工作量的是连接器、权限同步和数据新鲜度。把这一层买下来，等于把一个跨季度的工程项目变成一次部署。
4. 跨部门铺开智能体：因为同一套上下文层服务所有团队，组织往往跨职能部署智能体而非局限于单一部门。官方称 85% 以上的客户在 5 个及以上部门部署，客户案例中亦有单家公司内部构建数千个智能体的记录（厂商自报数字）。
5. 在规模扩张时控制 AI 支出：对于模型账单增速快于 AI 价值增速的组织，一个能减少「每项任务的模型操作次数」的上下文层，是财务部门听得懂的论证。这已成为 Glean 的首要商业主张，而不是附带好处。
6. 盘活沉睡的档案内容：手握数十年材料的组织——研究资料、编辑档案、历史合同——可以把这些语料纳入与在线系统同一个检索面，让沉睡内容变成员工真正查得到的东西。

如何使用 Glean

1. 通过官网的演示申请联系销售团队。产品没有自助注册入口，因此流程从需求界定开始：需要接入哪些系统、多少用户、采用哪种部署形态、落在哪些区域。
2. 选择部署模式。平台可运行在 Glean 托管的单租户环境中，也可部署在你自己的 AWS、Azure 或 GCP 账户内，并按数据驻留义务选择区域。
3. 接入源系统，从窄处起步。先为「承载试点组多数知识」的少数几个系统启用连接器，确认权限继承行为符合预期后再扩大范围。
4. 用带对抗性的方式验证权限。让不同岗位、不同职级的用户去搜索他们本不该看到的材料。这是最重要的验收测试，在试点阶段做的成本，远低于在生产环境中发现问题。
5. 打开敏感内容策略并审阅结果。那些技术上可访问、实际上没人找得到的过度共享文档，会在好用的搜索上线的那一刻变得触手可及，因此要为扫描结果的排查与整改预留时间。
6. 先向一个试点部门推出助手，等搜索行为建立信任后再引入智能体。智能体先以只读或需审批的配置起步，等人机协同流程被证明可靠后，再授予写操作权限。

使用技巧与最佳实践

• 把「发现过度共享」当作一个项目阶段，而不是一场意外：部署企业搜索必然会暴露一件事——源系统里的权限比所有人以为的都松。官方自己就说得很直白：仅靠权限不足以保障企业数据在 AI 场景下的安全，因此内置了敏感数据保护与过度共享内容的排查整改工作流。请为这项清理工作排期，而不是在推广中途才撞见它。
• 按知识密度而非系统数量确定接入范围：接入二十个几乎没有独特知识的系统只会增加噪声与成本；接入三个真正沉淀决策的系统，就能拿到大部分价值。
• 试点期务必用真实查询做延迟测试：有评价者反馈响应速度明显偏慢。一个让人觉得卡顿的搜索工具，无论答案质量多高，都会输给「转头问同事」这个习惯。
• 先约束智能体，再规模化：官方也承认，即便策略再严，智能体本身仍是非确定性的，因此引入了对齐模型在每个写操作执行前进行预扫描，并加上提示注入、恶意代码与有害内容防护。请主动使用这些控制项，而不是默认配置就一定合适。
• 预算要覆盖变革管理，而不只是部署：那些漂亮的采用率数字来自愿意投入培训与内部推广的组织。一次技术上成功但没人使用的部署，回报为零。
• 按真实的使用曲线测算价格：消费型计价意味着成本随采用率上升——而采用率上升正是你追求的结果。请按「成功情形」建模，而不是按试点用量。
• 在搜索层之外保留权威事实源：Glean 呈现和排序的是既有内容，它不会修正互相矛盾或过期的文档。底层内容的治理责任仍在你自己。

适用人群

• 工具版图碎片化的大型企业：核心受众。跑着几十套 SaaS 系统、没有任何一个人说得清东西都在哪的组织。
• 合规要求繁重的行业：金融服务是 PeerSpot 上研究该产品最活跃的行业，其合规认证矩阵本就是为受监管环境准备的。
• 有数据驻留义务的组织：必须把数据留在特定区域、因而需要单租户或自带云部署的团队。
• IT 与内部支持职能：工单量被「明明有文档、就是没人找得到」的问题占据的团队。
• 正在把 AI 战略制度化的企业：截至 2026 年 5 月，公司报告年经常性收入达到 3 亿美元，为 15 个月前 1 亿美元里程碑的三倍，客户包括 Databricks、Reddit、Pinterest 与三星。
• 曾考虑自建 RAG 栈的团队：已经评估过连接器与权限工作量、并认定这不是自身差异化所在的工程组织。
• 不适合个人与小团队：没有免费档、没有自助入口、没有个人套餐。小型组织应转向通用助手或更轻量的知识工具。

支持平台

• Web 应用：主要界面，通过浏览器访问。
• 嵌入已连接工具的使用入口：平台把能力接入工作实际发生的系统，而不是要求用户跑到一个独立目的地；连接器覆盖 Slack、Google Workspace、Microsoft 365、Atlassian 系列等大量应用。
• 单租户云部署：可在完全隔离的单租户环境中运行，既可由 Glean 托管，也可部署在你自己的 AWS、Azure 或 GCP 账户内，并支持 AMER、EMEA、APAC 区域落地以满足数据主权要求。
• 基于 MCP 的互联：除原生连接器外，平台使用 Model Context Protocol 连接器，因而既能消费上下文，也能作为其他 AI 工具的上下文来源。
• 合规认证：官网列出的认证包括 ISO 42001、HIPAA、TX-RAMP Level 2、SOC 2 Type II、ISO 27001 与 GDPR。

价格与套餐

Glean 不公开定价。没有定价页、没有免费档、没有自助注册，进入产品的唯一路径是由销售团队处理的演示申请。这在这个体量的企业软件中是常态，但也意味着：不进入商务流程就无法评估成本，且在不并行走多家采购流程的前提下很难做直接比价。

关于计价结构，已知信息来自 CEO 的采访而非官网：一种是按用量付费的消费型模式，另一种是「按活跃用户收固定月费 + 另计模型消耗费用」的混合模式。实际含义是成本随采用率上升，因此财务模型应按预期的稳态用量来建，而不是按试点量。任何在第三方文章里看到的具体人均价格，都应视为未经核实。（信息待验证）

替代方案

• Microsoft 365 Copilot：对已标准化在微软生态上的组织构成最直接的替代，优势在于原生访问 Microsoft Graph 数据与打包的商务条款，但在非微软系统上覆盖较弱。
• Google Gemini for Workspace：面向以 Google 为中心的组织的同类论证，在 Workspace 内很强，出了 Workspace 相应变弱。
• Amazon Q Business：AWS 的企业助手，在数据版图本就落在 AWS、且采购可走既有云承诺额度时更具吸引力。
• ChatGPT Enterprise 与 Claude for Enterprise：模型优先的产品，后续补上了连接器与检索能力，通常在纯推理上更强，在异构系统上的权限感知索引深度上更弱。
• Elastic Search 等传统搜索平台：PeerSpot 数据显示，Glean 在 Search as a Service 品类的 mindshare 为 4.7%，虽较上一年的 2.3% 翻倍，但仍明显落后于 Elastic Search 的 16.2% 与 Amazon OpenSearch 的 12.3%。它们给你更多控制权与更低许可成本，代价是连接器、权限与 AI 层都得自己建。
• 基于向量数据库自建：对系统数量少、工程能力强的组织是可行选项，但连接器维护与权限同步的持续负担经常被严重低估。

限制与注意事项

• 公开的营收数字需要谨慎解读：TechCrunch 明确指出，这个 3 亿美元的数字不能完全按传统 ARR 理解——消费型计价本身不含严格的经常性成分，因此其中一部分更准确的说法是年化收入运行率。这在评估供应商稳定性时是有意义的，不是说这门生意不好，而是「亮眼的增长数字」与「已签约的经常性收入」并非同一回事。
• 连接器配置与自定义开发存在摩擦：一位在金融服务企业（1,001–5,000 人）任分析师的 PeerSpot 评价者提出三点具体意见：启用连接器需要大量来回沟通而非默认可用；自定义动作缺少可追踪请求如何发往自定义端点的开发者日志；查询延迟明显偏高。同一位评价者把这形容为速度与准确性之间的取舍，并指出响应通常非常准确。
• 智能体的工作流控制仍在成熟中：另一条反复出现的意见是，工作流智能体在所有节点上一律使用 AI 且没有逐节点开关，评价者称这有时会把输出搞乱；同时也有希望支持更多模型、提升路由质量而非过度检索的诉求。
• 公开评价样本量偏小：PeerSpot 上综合评分为 4.3/5，共 12 条评价，100% 的评价者愿意推荐；样本以大型企业为主，但数量小到只能作方向性参考，不能当作统计结论。这个价位的企业软件本就极少产生公开评价，因此客户实名参考电话比星级评分更值得依赖。
• 竞争格局已发生根本变化：Jain 本人承认竞争态势彻底改变——公司存在的头四五年没有任何竞争对手，而如今 Google、Microsoft、OpenAI、Anthropic、Salesforce 与 Atlassian 都在做同类工具。其中若干家还能把该能力打包进你已经持有的合同里。
• 部署质量受限于你的源系统：搜索质量的上限由底层内容与权限的真实状态决定。文档过度共享、重复、陈旧的组织，只会更快地把这些问题暴露出来。
• 公开隐私声明的适用范围：营销站的隐私声明明确不涵盖产品本身，因此约束你企业数据的是合同条款而非公开政策。这类问题应在采购阶段交由法务与安全评审，而不是从官网推断。

常见问题（FAQ）

Q1. Glean 和 ChatGPT 之类的通用 AI 助手有什么区别？

通用助手既接触不到你的内部系统，也没有「谁有权看到什么」的模型。Glean 会为已连接系统中的公司真实内容建索引，并在每次查询时强制执行源系统权限，因此答案扎根于内部知识而非公开训练数据。

Q2. 它会遵守现有的文件与频道权限吗？

会。权限从各源系统继承并严格执行，权限变更会立即反映到结果中，而不是等下一次索引刷新。即便如此，用不同访问级别的账号实测这一行为，仍应是你评估流程的一部分。

Q3. 价格是多少？

Glean 不公开定价，合同经由销售协商。CEO 曾说明存在两种结构：按用量付费的消费型，以及「按活跃用户固定月费 + 模型用量另计」的混合型。请预期成本随采用率上升。

Q4. 可以连接多少系统？

提供 275 个以上开箱即用的连接器，形态包括原生集成、基于 MCP 的连接器，以及供系统主动推送内容的 Push API。

Q5. 可以部署在我们自己的云上吗？

可以。平台支持完全隔离的单租户部署，既可由 Glean 托管，也可运行在你自己的 AWS、Azure 或 GCP 环境中，并可选择 AMER、EMEA、APAC 区域落地。

Q6. 我们的数据会被用于训练模型吗？

Glean 称其与模型供应商签有零留存协议，确保客户数据不会被存储或用于模型训练，并称其 RAG 架构从源头上尽量减少向模型暴露的内容。具体合同条款请在采购阶段确认。

Q7. 如果我们的文档存在内部过度共享怎么办？

好用的搜索会让原本「看不见的过度共享」变得显眼。Glean 提供覆盖凭据、支付数据与医疗信息的敏感内容检测策略，以及排查与整改过度共享文档的工作流；但底层的权限卫生仍由你自己负责。

Q8. 智能体可以执行改动数据的操作吗？

可以，这正是护栏重要的原因。智能体可通过明确的动作边界加以约束、可要求执行前经人工审批，并受对齐模型对写操作的预扫描保护。建议先用「需审批」的配置起步，再考虑授予自主写权限。

Q9. 有免费试用或面向小团队的套餐吗？

没有。既无免费档也无自助入口，产品的设计与定价都面向大型组织。小团队更适合通用助手或更轻量的知识管理工具。