初始上下文

功能
Slack Workspace Agent Access(Organization Service Accounts)— 让一个 Gumloop agent 被整个 Slack workspace 的所有人使用,包括没有 Gumloop 账号的员工。无账号成员的消息运行在一个共享的组织级 service account 上,而非任何个人凭据
版本起源
v10.19.0 "Tilting" (2026-08-10)
解决的问题
企业 agent 的触达半径被"账号数"硬约束。绝大多数员工(IT/HR/财务/运营)永远不会登录 Gumloop,但需要随时问"全公司 helpdesk agent"。强制每人开账号既成本高又阻力大,导致"全公司公共服务型 agent"无法落地
战略动机
三层:(1) 分发范式跃迁——agent 用户基数从"平台账号数"扩展到"整个 IM workspace 成员数",agent 从"自动化工具"迈向"全公司公共服务"。(2) 渠道优先采用——Slack-first 大规模推广,不为每个员工预配账号。(3) 治理与开放并存——用 service account 隔离身份 + agent-owned 凭据 + fail-closed 默认,让"开放全员访问"不牺牲企业可控性
评分
11/13(战略3 护城河2 用户3 复杂度2 创新1)[初始11→质疑-0→最终11] · ✅ 战略级 SPEC 候选(agent 分发范式跃迁)

1. 概览

背景:agent 触达的账号瓶颈

┌──────────────────────────────────────────────────────────────────────┐
│                   Gumloop agent 触达模型演进                            │
├──────────────────────────────────────────────────────────────────────┤
│                                                                        │
│  Before v10.19                          v10.19 "Tilting" ⭐            │
│  ─────────────────                      ──────────────────             │
│  Slack @agent → 需 Gumloop 账号          Slack @agent → 无账号也能用     │
│  agent 运行在【该人】凭据上              agent 运行在【service account】  │
│  触达半径 = 平台账号数                   触达半径 = 整个 workspace 成员数  │
│  每人各自的连接/行为                      同一身份、同一行为              │
│                                                                        │
│  瓶颈:全公司 helpdesk agent 无法落地    解锁:IT/HR agent 全员可用       │
│                                                                        │
└──────────────────────────────────────────────────────────────────────┘

三条件门控(全部满足才生效)

核心原则
无账号者的请求仅当三条件全部满足才运行在 service account 上:(1) 有 active service account;(2) 其 workspace 已注册;(3) 该 agent 已 opt-in。任缺一即回退注册提示。功能对所有 agent 默认关闭,fail-closed。

目标

  1. 零账号 agent 访问——无 Gumloop 账号的 Slack 成员能使用 opted-in agent
  2. 共享执行身份——所有无账号请求运行在一个隔离的组织 service account 上,而非任何个人凭据
  3. fail-closed 安全——默认全关,三条件任缺即回退;service account 隔离、不可提权
  4. 完整可审计——运行归属 service account,但原始 Slack actor 记录在侧;setup 全进审计日志

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

2.1 三条件门控

┌──────────────────────────────────────────────────────────────────────┐
│  无账号 Slack 成员发起请求                                              │
│         │                                                              │
│         ▼                                                              │
│  ┌─────────────────────┐  否                                          │
│  │ ① 有 active service  │──────► 回退注册提示(fail-closed)            │
│  │    account?         │                                              │
│  └─────────────────────┘                                              │
│         │ 是                                                           │
│         ▼                                                              │
│  ┌─────────────────────┐  否                                          │
│  │ ② 该用户的 workspace │──────► 回退注册提示                            │
│  │    已注册?          │      (Grid 不继承,per-workspace)            │
│  └─────────────────────┘                                              │
│         │ 是                                                           │
│         ▼                                                              │
│  ┌─────────────────────┐  否                                          │
│  │ ③ 该 agent 已开启     │──────► 回退注册提示(默认全关)                │
│  │    opt-in 开关?     │                                              │
│  └─────────────────────┘                                              │
│         │ 是                                                           │
│         ▼                                                              │
│  请求运行在 service account 上(用 agent-owned 凭据)                   │
│  记录原始 Slack actor(workspace ID + user ID + 显示名)                │
└──────────────────────────────────────────────────────────────────────┘

已有 Gumloop 账号的人不受影响:若 Slack 用户邮箱匹配到 Gumloop 账号,请求照常运行在其自己账号和凭据上——service account 只服务无账号者。

2.2 Step 1:创建 service account

Settings → Organization → General → Service account → Create account。Gumloop 生成一个合成的组织成员,无人可登录:

属性
Email自动生成,*.gumloopserviceaccount.com 结尾。不收邮件,不可登录
组织角色plain member(不能持 Admin/Security 或任何提权角色)
Custom Roles组织默认角色,可调整

每个组织一个 active service account——它是所有无账号 Slack 请求(跨所有 opted-in agent)的统一身份。

最佳实践
给 service account 一个专用紧 Custom Role,而非沿用组织默认。一个紧角色是限制大范围 Slack 访问爆炸半径的单一最优杠杆。点击 account 行 → Manage Access 分配 Custom Role;三点菜单可复制 ID 或移除(移除立即停全组织无账号访问)。

2.3 Step 2:注册 Slack workspace

同一设置页 → Slack workspaces → Add workspace → Slack OAuth 弹窗 → 选准要授权的 workspace。每行记录 workspace 名、Slack workspace ID(T…)、添加者、时间。可注册多个 workspace,各自独立授权、独立移除。

⚠️ 关键约束
注册是 per Slack workspace,不是 per Slack Enterprise Grid 组织。若公司用 Grid 跑多个 workspace,admin 必须逐个添加。仅"在同一 Grid"不够。

2.4 Step 3:逐 agent opt-in

打开 agent → Share,两件事必须:(1) General Access 设为 Organization;(2) 开启 "Allow Slack members without Gumloop accounts"。开关仅在可编辑 + agent 属本组织 + GA=Organization + Enterprise 时渲染。

setup 不全时显示对应 setup 链接(4 种状态文案):

看到的内容含义
Create a service account for Slack access…workspace 已注册,缺 service account
Verify a Slack workspace for Slack access…service account 存在,未注册 workspace
Set up Slack access for people without Gumloop accounts两者都没配
setup 链接灰掉 + tooltipsetup 不全且你没权限修
为何 Organization 而非 "Anyone"?
Public agent 不能携带 agent-owned 凭据,所以绝不继承 service account。Organization 级 share 才门控 service account 执行。若把 GA 改为 Anyone,无账号 Slack 访问立即停止。

2.5 凭据:agent 实际能碰什么(最易出错处)

service account 是全新身份,无任何已连 app——它不能借 admin 的个人连接,也不能借 Slack 用户的连接。因此要让工具工作,agent 的 connector 必须设为 agent-owned。若留 user-owned,请求失败报错:

<Integration> is configured on this agent, but external Slack users can
only use it when the credential is agent-owned. Ask an organization admin
or the agent owner to set an agent-owned credential for this integration.

无账号者从不看到"连接此 app"提示——没有账号可供连接。配置流程:agent Apps → 选 connector → 选具体账号 → Credential ownership 设为 Agent-owned(组织内默认受限,需 admin 先在 Custom Role 开启 Agent-owned credentials feature toggle)。

⚠️ 空间绑定
agent-owned 钉子绑定 agent 所在空间。克隆 agent、用作模板、移到其他 team 会丢弃 agent-owned 钉子,connector 回退 user-owned。若移动/复制 opted-in agent,需复查凭据所有权。

2.6 归属、credits 与审计

  • 运行执行为 service account——权限、Custom Role 限制、org policy 全部对 service account 求值,不对 Slack 个人,也不对创建它的 admin
  • Slack 个人仍被记录——每请求存储原始 Slack actor(platform、workspace ID、Slack user ID、显示名)在对话旁
  • 用量取自组织 credits——不取任何个人余额
  • setup 变更进审计日志——service account 创建/移除、workspace 注册/移除都发审计事件

2.7 资格(谁能用)

注册一个 workspace 授权其 full members。Gumloop 刻意排除若干类,全部回退到注册提示:

能无账号用 opted-in agent?
已注册 workspace 的 full member✅ 是
未注册 workspace 的 member❌ 否
Slack Connect 外部用户(共享频道)❌ 否
单/多频道 guest❌ 否
停用用户 / bot❌ 否
任何人,当 agent 开关关时❌ 否

2.8 三级撤销

撤销层级效果
关 agent 开关撤销单个 agent
移除 Slack workspace撤销单个 workspace,其余不动
移除 service account一次性停全组织所有无账号 Slack 访问

三级都对后续请求生效;现有对话历史保留。

3. 功能需求

模块 A — Service Account 管理

  • P0 组织设置生成合成身份(*.gumloopserviceaccount.com,不可登录,plain member)
  • P0 每组织仅一个 active service account
  • P0 Manage Access 分配 Custom Role(控 app/tool/scope/node/model + 上限)
  • P0 三点菜单:复制 ID / 移除(移除立即停全组织)
  • P0 service account 不能持任何提权组织角色

模块 B — Slack Workspace 注册

  • P0 Slack OAuth 授权,记录 workspace 名/ID/添加者/时间
  • P0 多 workspace,各自独立授权与移除
  • P0 per-workspace 授权,Grid 不继承

模块 C — Agent Opt-in

  • P0 Share → GA=Organization + 开启无账号开关
  • P0 开关渲染条件(可编辑 + 属本组织 + GA=Org + Enterprise)
  • P0 GA 改 Anyone → 无账号访问立即停
  • P0 per agent,不经一般保存路径

模块 D — 执行与凭据

  • P0 无账号请求运行在 service account 上
  • P0 已有账号者照常运行在自己账号(邮箱匹配)
  • P0 connector 必须 agent-owned,否则失败报错
  • P0 无账号者从不看到"连接 app"提示

模块 E — 归属、审计与撤销

  • P0 权限/Custom Role/org policy 对 service account 求值
  • P0 每请求记录原始 Slack actor
  • P0 用量取自组织 credits
  • P0 setup 变更进审计日志
  • P0 三级撤销,后续请求生效,历史保留

模块 F — 资格过滤

  • P0 仅已注册 workspace 的 full member 可用
  • P0 排除未注册 workspace 成员 / Slack Connect 用户 / guest / 停用用户 / bot
  • P0 DM 永远走个人 Gumball,不走 service account

4. 用户场景

场景 1:全公司 IT Helpdesk Agent 落地

画像:王 IT,2000 人科技公司 IT 主管,用 Slack 全公司沟通。想部署 IT helpdesk agent 回答 VPN/密码/软件申请问题,但 90% 员工不会登录 Gumloop。

作为 IT 主管,我希望部署一个 agent,让任何员工在 Slack #it-help @agent 就能得到回答——无需 Gumloop 账号,运行在隔离的 service account 上但仍可审计是谁问的。

验收:admin 创建 service account + 紧 Custom Role(只读 IT 知识 + 提工单)→ 注册 Slack workspace → agent Share 设 Organization + 开无账号开关 → 加到 #it-help。无账号员工 @agent 能得到回答不被要求注册;回答基于 agent-owned Notion 连接;审计日志可追溯每个请求的 Slack 用户;关掉开关立即全员停访问。

场景 2:凭据配置错误的修复

画像:李 HR,HR agent 查员工信息(BambooHR)。开启无账号 Slack 访问后,员工反馈 agent 说用不了 BambooHR。

作为 HR agent 构建者,我希望明确的报错指引我把 connector 改成 agent-owned,让无账号员工的查询恢复正常。

验收:user-owned connector 在无账号请求中明确报错并提示修复路径;改为 agent-owned 后请求正常;报错文案指引找 admin/agent owner。

5. 竞争分析

竞品对标能力Gumloop 差异
Slack 原生 AI / 第三方 Slack bot无账号即可用它们是固定功能 bot;Gumloop 让任意自定义 agent 无账号可用,且 service account 隔离 + agent-owned 凭据 + 完整审计
Microsoft Copilot for M365组织级服务账号执行,全员可用绑定微软生态;Gumloop 是跨应用 agent 平台
Zapier / n8n Slack 集成Slack 触发 workflowreactive 自动化非对话 agent;无 service account 身份模型
自定义 Slack bot + 后端 LLM完全可控需自建身份/凭据/审计/治理全套——Gumloop 封装成开箱即用

关键洞察

  • "无账号 agent 访问"是企业 agent 触达的范式跃迁——此前 agent 平台都困在"每个使用者要平台账号"。Service Accounts 用共享执行身份打破约束,agent 从"工具"到"基础设施"
  • 真正护城河是治理工程密度——合成身份隔离、agent-owned 凭据强制、运行归属与 actor 记录分离、fail-closed 默认、三级撤销、全审计、资格过滤、per-workspace 授权。这套让"开放全员访问"与"企业可控"同时成立
  • service account 是可迁移的设计范式——"隔离合成身份承载共享访问,权限对其求值,actor 记录在侧"不限于 Slack,任何渠道全员访问都可复用
  • 凭据铁律暴露企业分发真实复杂度——service account 不能借任何人连接,必须 agent-owned。这个"最易出错处"是企业级分发与个人玩具的分水岭

6. 遥测(推荐)

阶段事件指标优先级
采用service_account_created创建率/组织P0
采用slack_workspace_registered注册 workspace 数/组织P0
采用agent_slack_access_opted_inopted-in agent 数P0
执行service_account_request_executed无账号 Slack 请求/日P0
错误agent_owned_credential_missing凭据配置错误率P0
治理service_account_revoked撤销频次(三级各计)P1
成本service_account_credits_consumedorg credits 中占比P1

7. 未来演进方向

阶段里程碑状态
Phase 1 — Slack 渠道service account + workspace 注册 + agent opt-in + agent-owned 凭据 + 审计 + 三级撤销✅ 已发布 v10.19.0
Phase 2 — Teams 渠道同一模型扩展到 Microsoft Teams,跨 IM 渠道零账号分发⬜ 探索中
Phase 3 — 细粒度授权per-agent service account、按频道/角色限定 agent、per workspace 配额⬜ 探索中
Phase 4 — 渠道无关分发抽象为任意渠道全员访问(Web/邮件/嵌入),agent 成组织基础设施⬜ 探索中

关键演进判断