初始上下文

功能
把 Brain 数据源从 6 个内置 native source(Notion/GDrive/Slack/GitHub/Confluence/Zendesk)扩展到 connector library 里 100+ 任意 app——通过 AI setup chat 自动探查 app、提议同步计划、用户审批,把任意 connector 变成 Brain 源
版本起源
v10.13.0 "Holberg" (2026-07-21)
解决的问题
Brain 此前只能用 6 个内置源,但企业知识散落在 Gmail(邮件)、Linear/Jira(项目)、Intercom/HubSpot(客户)、SharePoint(文档)等 100+ connector 里。没建 native source 的 app,Brain 就索引不到——覆盖率被"官方有没有专门适配"卡死
战略动机
native source 模式覆盖率线性增长(受限于官方工程投入)。Any Connector 打破瓶颈——任何已有 connector 的 app 都能通过 AI setup chat 自动变源,覆盖率变成"跟 connector 生态走"(指数级扩展)。Brain 从"特色功能"到"通用企业知识平台"的定位跃迁
评分
9/13(战略3→2 护城河3→2 用户3→2 复杂度2 创新2→1)[初始13→质疑-4→最终9] · ✅ SPEC 候选(Brain 平台化跃迁)

1. 概览

背景:Brain 从"固定 6 源"到"任意 connector 生态"

┌──────────────────────────────────────────────────────────────────────┐
│                  Brain 数据源版图 — 演进                                │
├──────────────────────────────────────────────────────────────────────┤
│  Phase 1(v10.8.0):5 个 native source                                  │
│  ┌────────┬──────────┬────────┬────────┬────────────┐                 │
│  │ Notion │ GDrive   │ Slack  │ GitHub │ Confluence │                 │
│  └────────┴──────────┴────────┴────────┴────────────┘                 │
│                                                                        │
│  Phase 2(v10.11.0):+1 native source(首个客服域)                       │
│  ┌──────────┐  Zendesk(Help Center + 工单 comment thread)              │
│  └──────────┘                                                          │
│                                                                        │
│  Phase 3(v10.13.0)⭐:任意 connector 皆可作源(platform 化)             │
│  ┌──────────────────────────────────────────────────────┐             │
│  │  Gmail · Linear · Intercom · HubSpot · Jira ·          │             │
│  │  SharePoint · … connector library 100+ app             │             │
│  │  (AI setup chat 自动探查 + 审批 → 变 Brain 源)         │             │
│  └──────────────────────────────────────────────────────┘             │
│                                                                        │
│  例外(不可作 BYO 源):已有 native source 的 5 app / action-only 抓取类  │
│                        / raw database / warehouse(需 write 权限)       │
│                                                                        │
│  + File uploads(用户上传文件)                                           │
└──────────────────────────────────────────────────────────────────────┘

覆盖率增长模式的质变

模式覆盖率增长瓶颈
native source(Phase 1-2)线性——每个源需官方工程团队专门适配受限于官方工程投入
Any Connector(Phase 3)⭐指数级——跟 connector 生态(100+ app)自动扩展仅受限于 connector library 覆盖面

目标

  1. 打破覆盖率瓶颈——覆盖率从"靠官方适配"变成"跟 connector 生态走"
  2. 降低接入成本——AI setup chat 把"理解 app 数据模型"的认知负担从用户转给 AI
  3. 保持统一心智模型——BYO 源行为完全同 native source,零额外学习成本
  4. 守住企业安全底线——setup chat 和持续同步都严格 read-only

2. 核心机制 [文档已验证]

2.1 添加 BYO 源(4 步 AI 引导流程)

步骤动作
① Pick the app「Add a source」搜 app,无 native source 的出现在 Build your own
② Connect account + 可选描述选读取账户;可选写"our support emails",留空则 setup chat 给合理默认
③ Approve proposed planAI 探查 app + 提议同步计划。Looks good 进选择屏 / Request changes 调整
④ Choose what to sync基于计划的选择屏细选,用 app 自己的概念(labels/folders/channels),Add source

2.2 AI setup chat(核心创新)

┌──────────────────────────────────────────────────────────────────────┐
│  AI setup chat — 4 个能力                                               │
├──────────────────────────────────────────────────────────────────────┤
│  ① Inspects the app     学习内容怎么组织、哪些部分值得做可搜索            │
│  ② Proposes a plan      自然语言摘要"你将得到什么",而非设置清单          │
│  ③ May ask a question   当选择真属于用户时(workspace/username),        │
│                          总是给选项让用户选,不开放填空                    │
│  ④ You approve/change   Looks good → 选择屏 / Request changes → 重做计划  │
│                                                                        │
│  🔴 read-only 铁律:只读连接的账户来规划和同步,                          │
│     绝不 create/edit/delete 用户 app 里的任何东西                        │
│                                                                        │
│  💡 Tip:connect 步骤给提示可得更定制计划,如                             │
│     "just our #announcements channel"——提到的内容带到选择屏,不必重填     │
└──────────────────────────────────────────────────────────────────────┘
💡 灵魂所在

AI setup chat 把"理解 app 数据模型"这个最重的认知负担从用户转给 AI——产品用 AI 降低自己的使用门槛,而非让用户填一堆配置表单。这是 agent 智能用在产品 onboarding 环节本身的范式创新。

2.3 选择屏(基于审批过的计划构建)

控件作用
Sync byapp 多维组织时选同步维度(如 Gmail Labels vs 搜索查询)
Sync everything索引整个源,含后续新增内容
Select what to sync手选勾选的容器(特定 labels/folders/channels)
What to includetoggle 哪些内容流被索引(正文 vs 评论);核心默认开
Search box / queries对只能按标识符/查询触达的内容,输入值拉取

2.4 行为完全同 native source

审批 + 细选后,BYO 源行为与其他源一致:Preparing → Active;进入 sources 列表 / knowledge graph / agent citations;自动持续同步(connector 类默认约每小时);上游删除 → 下次成功同步时移除;可 re-sync / pause / edit / delete;scope 继承(Personal/Team/Organization)。attach 到 agent 后,agent 自动获得 Search Company Brain(混合搜索)+ Read document(取全文)两个内置工具,自主决定何时搜索。

2.5 什么不能这样加(关键约束)

┌──────────────────────────────────────────────────────────────────────┐
│  不能作 BYO 源的 4 类                                                     │
├──────────────────────────────────────────────────────────────────────┤
│  ❌ 已有 native source 的 app:Notion / GDrive / Slack / GitHub /         │
│     Confluence——用专用 setup,不出现 Build your own 区                    │
│                                                                        │
│  ❌ action-only / 抓取类平台:web-scraping、enrichment——无内容库,隐藏      │
│                                                                        │
│  ❌ raw database / warehouse:安全同步需 write 权限,Brain 永远不用         │
│                                                                        │
│  ⚠️ Empty accounts / missing permissions:setup chat 告知而非创建空源,    │
│     setup 无法完成(含 credits 耗尽)显示 Setup failed + 简短原因          │
└──────────────────────────────────────────────────────────────────────┘
🔴 数仓为何不开放

Brain 永远只用读权限,任何需 write 权限才能安全同步的系统(数仓的细粒度权限模型)都被排除。这就是 v10.13.0 同版 "Key-Pair Auth for Snowflake" 让 agent 直连数仓但作为 Brain 源的原因:数仓走 connector(on-demand 查询),不进 Brain(全量索引)。清晰的"知识索引 vs 数据查询"边界。

2.6 计费

Indexing:内容处理时计费(首次添加 + 内容变更)。BYO 源内容量取决于 app,大邮箱/大项目库首次索引成本较高。Searching:按查询计费,计入 agent run。

3. 功能需求

模块 A — BYO 源添加(AI 引导)

ID触发场景系统行为优先级
A1搜索无 native source 的 app出现在 Build your own 区P0
A2选 app进 connect account 步骤P0
A3连接账户 + 可选描述启动 AI setup chat,可携用户提示P0
A4setup chat 探查AI 读 app 内容组织,提议同步计划P0
A5计划需用户决策AI 问选择题,给选项P1
A6用户审批Looks good 进选择屏 / Request changes 重做P0

模块 B — 选择屏(细选)

ID触发场景系统行为优先级
B1进选择屏基于审批计划构建控件(随 app 变)P0
B2Sync by 切换app 多维组织时切维度P1
B3Sync everything / Select全量或手选容器P0
B4What to include toggle选内容流,核心默认开P1
B6Add sourceGumloop 接管爬取、索引、同步P0

模块 C — AI setup chat(核心)

ID触发场景系统行为优先级
C1启动 setup chatinspect app 内容组织P0
C2探查完成propose 同步计划(自然语言摘要)P0
C4全程严格 read-only,绝不 create/edit/deleteP0
C5账户空/权限缺告知而非创建空源,提示换账户P1
C6setup 无法完成源显示 Setup failed + 简短原因P1

模块 D / E / F — 索引同步 / Agent 使用 / 约束

ID触发场景系统行为优先级
D1-D4首次添加/内容变更/上游删除/源管理索引 + 约每小时同步 + 移除 + re-sync/pause/edit/delete(同 native)P0
E1-E3attach / agent 判断 / agent 回答获 Search+Read 工具 / 自主搜索 / 引用来源P0
F1app 有 native source不出现 Build your own,走专用 setupP0
F2action-only/抓取类隐藏(无内容库)P0
F3raw database/warehouse不开放(需 write 权限,Brain 不用)P0

4. 用户场景

场景 1 — 把 Gmail 客服邮件灌进 Brain,agent 基于邮件历史回答

作为客户成功负责人,我希望把 support Gmail 接进 Brain——不用填配置,让 AI 帮我搞清怎么同步,agent 就能基于历史邮件回答客户问题。

画像:林运营,31 岁,SaaS 公司客户成功负责人。团队用 Gmail 处理 support 邮件,历史邮件沉淀大量"客户怎么问、我们怎么答"的记录,但 Brain 此前接不进 Gmail。

验收标准:

  • Add a source 搜 Gmail,Build your own 区选取,连 support 账户,写"our support emails"
  • AI setup chat 探查 Gmail,提议按 Labels 同步(INBOX + 自定义 support label)
  • Looks good 审批,选择屏按 Labels 细选,Add source,Preparing → Active
  • attach 到"客户成功助手 agent",约每小时自动同步
  • 客户问"上季度怎么处理 X 类问题"→ agent 搜索 Gmail 索引,引用历史邮件回答
  • 全程 read-only,Gmail 里没有任何邮件被改动

场景 2 — 把 Linear 项目数据作 Brain 源,工程 agent 知道项目上下文

作为 tech lead,我希望把 Linear 项目数据灌进 Brain,让工程 agent 能语义搜索"这个 epic 涉及哪些 ticket、各自状态",而非一个个 ticket 调 connector 查。

画像:陈工,33 岁,工程团队 tech lead。团队用 Linear 管 epic/ticket,agent 此前只能通过 connector 逐个查 ticket(慢且无法跨 ticket 语义搜索)。

验收标准:

  • Add a source 搜 Linear,Build your own 区选取,连接账户,提示"所有 active projects"
  • AI setup chat 探查 Linear(teams/projects/issues 结构),提议同步计划
  • 审批 + 选择屏按 team/project 细选,Add source
  • attach 到"工程助手 agent"
  • 问"Authentication epic 现在卡在哪"→ agent 跨多 ticket 语义搜索
  • 归纳该 epic 涉及的 ticket + 阻塞状态,比 connector 逐个查更快

5. 竞争分析

竞品任意 connector 作知识源优势劣势
Glean可索引大量企业 app企业搜索覆盖广,权限成熟非 agent 平台;无行动能力;固定表单配置
Guru可接多源知识知识管理专精非 agent 平台;无 AI setup chat
ChatGPT/Claude(GPTs/Skills)仅文件上传/少量连接器无法同步企业 SaaS;无 connector 生态
Zendesk AI / Intercom Fin自家客服系统客服场景专精绑死自家系统;非通用知识层
Gumloop Brain(v10.13.0 后)任意 connector(100+ app)agent 平台 + AI setup chat 零配置 + 既有 connector 生态复用 + read-only 安全单 connector 层面可抄;BYO 源无 Document access

关键洞察

  1. "接任意源到 RAG"是已知模式,AI setup chat 才是真差异化——Glean/Guru 早接很多源,单 connector 无壁垒。但 AI setup chat 把"理解 app 数据模型"这个最重认知负担从用户转给 AI,是产品用 AI 降低自己门槛的范式创新。竞品仍是固定表单
  2. Brain 真护城河是复合优势,非单源——"既有 100+ connector 生态(agent 已用来 take action)+ Brain scope/Document access 权限模型 + AI setup chat 体验"三重叠加。connector 生态是 agent 平台天然资产,复用到知识层(同一 connector 既让 agent 行动又喂 Brain),这是搜索工具(Glean)没有的协同
  3. raw database/warehouse 不开放是关键安全设计——Brain 永远只用读权限。清晰的"知识索引 vs 数据查询"边界,体现产品对企业安全底线的把握
  4. "覆盖率增长模式质变"是战略意义核心——native source 线性增长(受限于官方投入),Any Connector 指数级(跟 connector 生态)。Brain 从"特色功能"到"通用企业知识平台"的定位跃迁

6. 遥测

漏斗阶段事件名称指标/KPI优先级
采用brain_byo_source_addedBYO 源连接数(按 app 分布)P0
采用brain_byo_setup_chat_approved审批通过率(vs Request changes)P0
采用brain_byo_source_attachedattach 率P0
执行brain_byo_searchBYO 源查询数/日P0
影响brain_byo_coverage_apps组织 Brain 覆盖系统数提升P0
风险brain_byo_setup_failed失败率(按原因:credits/权限/空账户)P1

7. 未来演进方向

阶段时间线里程碑状态
Phase 1 — Any Connector 作源v10.13.0AI setup chat + 选择屏 + 100+ connector 可作源已发布
Phase 2 — Document access 扩展到 BYO 源v10.x+BYO 源支持文档级权限继承(目前仅 GDrive)推断/规划
Phase 3 — 跨源联合检索v11.xnative + BYO 源混检,Brain 成"企业单一知识入口"探索
Phase 4 — AI setup chat 进一步自动化远期主动建议"该同步这个 app"、跨 app 知识图谱自动建模探索

关键演进判断

  1. Document access 会扩展到 BYO 源——含 PII 的 BYO 源(Gmail 邮件、Intercom 客户对话)只受粗粒度 scope 保护是企业风险。把 GDrive 文档级权限继承推广到 BYO 源是大概率下一步
  2. 跨源联合检索是 Brain 的终局——native + BYO 都接入后,任意源混检(Gmail + Confluence + Linear 联合)。那时 Brain 才真正成为"企业单一知识入口",这是原生单系统工具做不到的
  3. AI setup chat 范式会扩散——"AI 探查 + 提议 + 审批"可推广到 connector 配置、trigger 设置、数据映射等所有"接入外部系统"场景,做成通用 AI 引导配置基础设施
  4. 数仓边界可能松动——目前为安全排除数仓。若设计出"只读 + 细粒度权限 + 不全量索引"安全模式(如 view 级索引),数仓接入是高价值方向
📚 源文档参考

docs.gumloop.com/core-concepts/brain(Build your own sources / The setup chat / Choosing what to sync / What you can't add this way 章节,完整验证)

父规格:Gumloop Brain(公司知识库) — 10/13 · 关联:Zendesk 源(v10.11.0,前一个源扩张)