初始上下文

功能
agent 的公司知识库。连接企业已有知识源(Notion/Drive/Slack/GitHub/Confluence/文件),Gumloop 索引并同步,agent 从真实内容回答并附引用
版本起源
v10.8.0 "Trinity" (2026-07-08)
解决的问题
此前 agent 能"做事"(connector)和"按流程做事"(skill),但不知道"公司知道什么"——文档、Slack 讨论、过往决策散落各处,agent 遇到内部知识只能靠幻觉猜测。这是企业 agent 进生产最大的能力缺口
战略动机
agent 能力栈补齐最后一块核心拼图。Connectors + Skills + Brain 三位一体,agent 具备完整的"数字员工"能力——能做事、懂规矩、知内情。代号 "Trinity"(三位一体)直接暗示这一架构完整性
评分
10/13(战略3 护城河1 用户3 复杂度2 创新1)[初始11→质疑-1→最终10]

1. 概览

背景:agent 能力的三块拼图

Gumloop 官方把 agent 的有用性拆解为三块,每块回答不同问题。Brain 之前,agent 遇到"我们退款政策是什么"这类问题只能靠模型预训练知识或幻觉——企业真实文档它看不到。Brain 补齐这块缺口。

┌──────────────────────────────────────────────────────────────────────┐
│                  Gumloop Agent 能力栈 — 三块拼图                       │
├──────────────────┬───────────────────┬───────────────────────────────┤
│  Connectors      │  Skills           │  Brain(v10.8.0 新)            │
│  (行动)         │  (流程)          │  (知识)                      │
├──────────────────┼───────────────────┼───────────────────────────────┤
│  实时操作能力      │  可复用任务指令     │  可搜索的知识                  │
│                  │                   │                               │
│  "发这条 Slack    │  "用我们的序列    │  "我们的退款政策               │
│   消息"           │   起草 outreach"   │   怎么说?"                    │
└──────────────────┴───────────────────┴───────────────────────────────┘

核心心智模型

Indexing a source makes knowledge available; attaching it to an agent makes that knowledge usable by that agent.

索引一个源 → 知识可用(available);attach 到 agent → 该 agent 能用(usable)。这是两层解耦设计:知识先进入组织知识池(可被治理、可被多个 agent 复用),再按需 attach 给特定 agent。一个 Notion 知识库可以索引一次,被客服 agent、销售 agent、HR agent 分别 attach 使用。

目标

  1. 让 agent 知道公司知道什么——基于真实内容回答,而非幻觉
  2. 统一企业知识权限——scope 与 Composable Roles / Permission Groups 集成,而非孤立文件上传
  3. 闭环工作→知识——agent 产出的 artifact 反向成为知识源,形成飞轮
  4. 零运维索引——Gumloop 自动读取、索引、同步,用户不管理 sync

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

2.1 知识源与索引内容

Brain 连接企业已有知识存储(不要求重新上传),Gumloop 读取并索引文本内容:

索引内容
Notion连接的页面和数据库的完整页面内容
Google Drive所选 drive/folder 的文件内容,含 Docs/Sheets/Slides(转换后索引)。Folder 只组织结果,本身非文档
Slack所选公开频道的消息,含 thread reply
GitHub连接的 repo 的文件
Confluence连接的 Confluence space 的页面
文件上传PDF/Office(.docx/.pptx/.xlsx)/rtf/Markdown/JSON/XML/YAML/text,单文件约 400MB

2.2 三层 scope(知识权限)

每个源有一个 scope,决定谁能看和搜索。添加时选择,之后可用 Share 修改。关键差异化:scope 与 Composable Roles / Permission Groups 深度集成——知识权限 = 企业身份权限,而非孤立文件 ACL。不同角色看到不同知识池。

Scope可见性
Personal(私有)只有创建者可见可搜索
Team(团队共享)一个团队/project 的成员可见
Organization(全公司)整个组织可见可搜索

2.3 索引与同步(零运维)+ 状态

源添加后,Gumloop 全权接管同步,用户不管理。

状态含义
Active连接正常,同步中
Paused同步暂停,直到恢复
Syncing同步运行中
Indexed单项已处理,可搜索
Failed上次同步出错,需重试或检查账户
Partial上次同步完成但部分项未索引

2.4 Knowledge Graph(3D 知识图谱)

每个 Brain 视图含交互式 3D 知识图谱——所有索引内容的可视化地图。每个点是一块知识,按源聚类着色(Slack 红、Drive 蓝、Confluence 绿...),可全屏拖拽探索。企业知识从"扁平列表"变成"可导航的空间"。

2.5 Agent 使用:两个内置工具

attach 源到 agent 后,agent 自动获得两个内置工具(无需配置)。agent 自主决定何时搜索——判断问题是关于内部内容时才调用 Brain,引用找到的内容,并在片段不足时打开完整文档。

┌─────────────────────────────────────────────────────────────────┐
│  用户问内部知识问题                                                │
│         │                                                        │
│         ▼                                                        │
│  ┌─────────────────────┐                                         │
│  │ Search Company Brain │ ── 混合搜索 attached 源                  │
│  │ (agent 自主触发)    │ ── 返回最相关片段                         │
│  │ chat: "Searching     │ ── 可并行多次搜索                         │
│  │  Company Brain"      │                                         │
│  └─────────────────────┘                                         │
│         │ 片段不够时                                               │
│         ▼                                                        │
│  ┌─────────────────────┐                                         │
│  │ Read document        │ ── 取特定文档全文                        │
│  │ chat: "Reading       │                                         │
│  │  document"           │                                         │
│  └─────────────────────┘                                         │
│         │                                                        │
│         ▼                                                        │
│  Agent 引用来源回答(citations)                                   │
└─────────────────────────────────────────────────────────────────┘

2.6 Artifact 索引(工作→知识飞轮)

除用户连接的源,Gumloop 还能索引 agent 产生的 artifacts(chat 中生成的文件),让 agent 搜索复用过往工作而非从零开始:

  • Artifact 在 Personal(你的 artifact)或 Team(项目 artifact)级索引
  • 每个 artifact 只索引最新版本,新版本产出时原地更新
  • agent 用同样的 Search Company Brain / Read document 工具找到——"调出我们上周做的 deck" 像普通知识查询

这形成闭环:agent 工作(产出 artifact)→ 索引为知识 → 下次 agent 复用 → 更好的工作。

2.7 Credits 计费

  • Indexing(索引):内容处理时计费。大部分成本在首次添加源和内容变更时
  • Searching(搜索):按查询计费。agent 的 Brain 搜索计入该 agent 的 run

3. 功能需求

模块 A — 知识源管理

ID触发场景系统行为优先级
A1打开 Brain左 sidebar 独立入口,All/Mine/Organization tabs + Source 添加P0
A2添加源选源类型(Notion/Drive/Slack/GitHub/Confluence/文件上传),授权连接P0
A3添加时选 scope(Personal/Team/Organization),之后可 Share 修改P0
A4文件上传支持 PDF/Office/rtf/Markdown/JSON/XML/YAML/text,约 400MBP0
A5源添加后Gumloop 自动接管同步,无需用户管理P0

模块 B — 索引与同步

ID触发场景系统行为优先级
B1源内容首次添加索引文本内容(按源类型索引页面/文件/消息)P0
B2源内容变更持续同步,增量更新索引P0
B3同步出错状态置 Failed/Partial,提示重试或检查账户P0
B4暂停/恢复状态置 Paused,恢复后继续P1
B5源列表展示Name/Docs/Activity/Access/Status 五列P0

模块 C — Agent 知识 attach

ID触发场景系统行为优先级
C1attach 源到 agent该 agent 获得 Search Company Brain + Read document 工具P0
C2agent 判断涉及内部知识自主调用 Search Company Brain 混合搜索,返回片段P0
C3片段不足agent 调用 Read document 取全文P0
C4agent 回答引用来源(citations),可并行多次搜索P0
C5agent 产出 artifact索引到 Personal/Team 级,仅最新版本P1

模块 D — 可视化与治理

ID触发场景系统行为优先级
D1查看 Brain3D 交互式 knowledge graph,按源聚类着色,可全屏拖拽P1
D2点击源detail page:项列表+Overview+Search this source+EditP0
D3scope 与角色集成知识可见性遵循 Composable Roles / Permission GroupsP0

4. 用户场景

场景 1 — 新员工通过 agent 了解公司政策

作为新员工,我希望问公司的 HR/客服 agent "退款窗口多久""上季度定价怎么定"——agent 基于真实文档回答并给链接,而不是凭空猜测。

画像:张明,28 岁,新入职产品经理。对公司政策、流程、过往决策不熟悉,每次提问要翻文档或问同事。

验收标准:

  • HR 团队把 Notion 政策、Confluence 流程、Slack #decisions 索引到 Organization scope
  • attach 这些源到"入职助手 agent"
  • 张明问"退款窗口"→ agent 显示 "Searching Company Brain",搜索索引内容
  • 返回答案 + 引用 Notion 退款政策文档链接
  • 问"上季度定价决策"→ 搜索 Slack #decisions,引用相关 thread
  • 答案全部基于真实内容,无幻觉

场景 2 — agent 复用过往工作产出

作为销售 lead,我希望问 agent "调出我们上周做的 Q3 deck"——agent 能从过往 artifact 找到并基于它做 Q4 版本,而不是从零开始。

画像:李华,销售 lead。上周让 agent 做了 Q3 方案 deck,现在做 Q4 方案希望复用。

验收标准:

  • 上周 Q3 deck 作为 artifact 被 Team 级索引(仅最新版本)
  • 李华让 agent 做 Q4 方案,提示"参考上周 Q3 deck"
  • agent 调用 Search Company Brain 找到 Q3 deck artifact
  • 基于其内容生成 Q4 版本,复用结构和数据
  • 形成"工作→知识→更好的工作"闭环

5. 竞争分析

竞品知识能力优势劣势
ChatGPT (Custom GPTs)文件上传知识库用户基数大,易用孤立文件上传,无企业源连接;权限简单;无 artifact 闭环
Claude Projects项目级知识 + 文件权限清晰,引用好无原生企业源同步;项目级非组织级
Glean企业搜索专精企业搜索深度强搜索工具非 agent 平台;无行动/流程能力
Notion AI原生 Notion 知识与 Notion 深度集成绑定 Notion,无跨源;无 agent 编排
Gumloop Connectors实时查询源实时数据,无索引成本每次查询,非预索引;消耗 API 配额

关键洞察

  1. "三块拼图"是正确的 agent 架构观——行动(Connectors)+ 流程(Skills)+ 知识(Brain)比竞品的"知识库 + 聊天"更完整。竞品多停留在"上传文件 + 问答",Gumloop 是企业知识层 + 行动层 + 流程层的统一
  2. 三层 scope 与角色集成是关键差异化——ChatGPT/Claude 的知识是孤立文件,权限简单。Brain 的 scope 与 Composable Roles 绑定,知识权限 = 企业身份权限。企业知识成为"有治理的组织资产"而非"散落文件"
  3. artifact 索引是独特闭环——agent 工作产出反向成为知识源。竞品知识库是静态的,Brain 是动态的(agent 持续产出知识)。这是 agent 平台特有优势——搜索工具(Glean)做不到
  4. 实时 connector vs 预索引 Brain 分工——Connectors 适合实时数据(当前库存、最新 ticket),Brain 适合历史知识(政策、决策、文档)。两者互补:agent 既知"现在"又知"过去"

6. 遥测

漏斗阶段事件名称指标/KPI优先级
采用brain_source_added源数/组织P0
采用brain_source_attached_to_agentattach 率P0
执行brain_search_executed搜索查询数/日P0
执行brain_document_read全文读取数P1
质量brain_citation_used引用率P0
影响agent_answer_from_brain幻觉下降率P0
飞轮artifact_indexed_and_reused工作复用率P1

7. 未来演进方向

阶段时间线里程碑状态
Phase 1 — 核心知识层v10.8.06 源连接 + 三层 scope + 混合搜索 + artifact 索引 + knowledge graph已发布
Phase 2 — 权限精细化v10.x知识访问审计日志、按字段/页面级权限、知识过期与保留策略规划中
Phase 3 — 主动知识v11.xagent 主动建议索引新源、知识缺口检测、与 Reflections 联动探索中
Phase 4 — 知识治理平台远期知识血缘追踪、合规导出/审计(SIEM)、跨组织知识市场、知识质量评分探索中

关键演进判断

  1. 主动知识是下一跃迁——当前 Brain 是被动索引。真正飞跃是"主动知识":agent 发现知识缺口("用户常问 X 但 Brain 没有")并建议索引。与 Reflections 联动可形成"对话暴露缺口 → 建议索引 → 知识更完整 → 回答更好"闭环
  2. artifact 索引的飞轮潜力被低估——长期看,组织工作产出持续沉淀为可搜索知识,Brain 会成为"组织记忆"。这是搜索工具(Glean)无法复制的
  3. 知识治理是企业深水区——三层 scope 是起点。企业真正需要知识血缘、合规审计(GDPR 删除)、保留策略。这是 Brain 进入受监管行业的前提
📚 源文档参考

docs.gumloop.com/core-concepts/brain(Brain 官方帮助文档,已完整验证)