[文档已验证] Skills 现在拥有三级可见性范围，通过 Library 页面的标签页管理：
| 标签页 | 可见范围 | 说明 |
|---|---|---|
| Mine | 仅创建者 | 个人 Skill，仅自己可见 |
| Shared with me | 他人分享或组织共享 | 同事分享给你的 Skill |
| Organization | 整个组织可见 | 全员可见的 Skill 库 |
Agent 技能发现机制：Personal Assistant Agent 自动拥有空间中所有 Skill 的访问权，通过语义搜索匹配 Skill 描述来动态发现；Custom Agent 只看得到显式附加到其系统提示中的 Skill（每个约占 50-100 tokens）。Custom Agent 在对话中创建的 Skill 自动附加；General Agent 创建的则放入库但不自动附加。
已知局限：Skill Editing & Creation 开关是全局的（per-agent，不能针对单个 Skill 锁定）。Skills 不能直接分享给个人用户——需要通过团队或组织范围实现。
[文档已验证] 基于分享基础设施和角色体系的 Skill 权限管控：
| 角色 | 能力 |
|---|---|
| Owner | 完全控制，不可通过分享 UI 移除 |
| Editor | 查看、编辑、删除、管理分享 |
| Viewer | 只读，可查看配置并复制 |
| Use Only | 仅限 Agent——可对话但看不到配置/指令/工具 |
Skill 特有的权限层级：创建者 → 完整管理权；团队成员 → 若 Skill 归属项目则可管理；其他人 → 仅查看和使用。支持软删除：删除的 Skill 标记为非活跃，可通过 Gumloop 支持恢复。支持批量操作（仅限有管理权限的 Skill）。每个 Skill 的 Edits 标签页显示完整文件级变更时间线和修改 Agent。
[推断] 基于已有的 Action Requests 系统，v9.11.0 将访问请求通知扩展到了 Skills 和 Workbooks（Flowbooks）。此前 Action Requests 主要覆盖 Agents，现在当有人请求访问一个 Skill 或 Workbook 时，Owner 会收到通知。
已有机制：用户缺少访问权限时看到 "Request Access" 按钮 → 路由到资源所有者或工作区管理员（Email + Slack 通知）→ In-App Inbox 显示待处理请求（Approve / Open / Reject / Dismiss）→ Slack 一键审批（团队和组织访问请求）。请求生命周期：Pending → Accepted / Rejected / Expired。
[推断] 官方文档尚未更新此增强的细节。Gumloop MCP 是一个允许外部系统通过 MCP 协议管理 Gumloop 工作流和 Agent 的 API 桥梁。当前已文档化的工具：
| 类别 | 工具 |
|---|---|
| 工作流管理 | List Saved Flows、List Workbooks、Start Flow Run、Get Run Details、Get Run History |
| Agent 交互 | Start Agent、Get Agent Status |
| 文档与管理 | Search Documentation、Ask Gummie、Get Audit Logs |
"更强大"可能意味着新增工具能力——推测可能包括 Agent 生命周期管理（创建/更新/删除）、Skill 管理 API、更丰富的 Workflow 操作。此次增强进一步缩小了 Gumloop 作为"可编程 Agent 基础设施"的 API 缺口。
[推断] 官方文档中尚无 Looker MCP 的独立页面（/nodes/mcp/looker 返回 404）。Looker 是 Google 的商业智能（BI）和数据建模平台。推测该集成让 Gumloop Agent 能够通过 MCP 协议查询 Looker 中的数据模型（Looks 和 Explores）、获取仪表盘和报告数据、将 BI 数据集成到 Agent 工作流中。
这是在 BigQuery、Snowflake、Databricks、Sigma Computing 等数据平台集成之后的又一个 BI 工具扩展。Gumloop 正在系统性地覆盖数据栈中的所有主流平台。
[文档已验证] BigQuery Workload Identity Federation 是一种密钥无关的 GCP 认证方式。与传统的服务账号 JSON 密钥文件不同：
| 维度 | 传统 OAuth/密钥 | Workload Identity Federation |
|---|---|---|
| 密钥管理 | 需存储、轮换密钥文件，存在泄露风险 | 无密钥文件——Gumloop 不持有长期凭据 |
| 会话持续性 | 依赖人类会话，可能过期 | 不绑定人类会话，Agent 永不过期 |
| 令牌 | 长期密钥或 OAuth Refresh Token | 每次请求动态铸造 5 分钟短期令牌 |
| 安全控制 | 密钥泄露即失控 | attribute-condition 精确约束到特定 Gumloop 租户 |
认证流程（四步 WIF 链）：1. Gumloop 签发 OIDC 令牌 → 2. GCP STS 验证签名并交换联邦令牌 → 3. 联邦令牌模拟指定 Service Account → 4. 短期 Google 访问令牌用于 BigQuery 调用后即丢弃。
配置需 6 步：创建 WIF 池 → 添加 Gumloop 为 OIDC Provider → 创建 SA + 授权 → 绑定 → 收集凭证值 → 在 Gumloop Credentials 中添加。
v9.11.0 "Huntsville" 是一个组织协作基础设施版本。三个核心信号：
1. Skills 从个人工具变成组织资产：三级共享（Mine / Shared / Organization）+ 权限角色 + 访问通知 = Skills 的治理框架基本完整。Gumloop 正从「个人 Agent 使用 Skills」迈向「组织管理 Skills 库」。这为更大的企业部署场景扫清了障碍。
2. API 可编程性持续增强：Gumloop MCP「更强大」暗示 Gumloop 正在被定位为可编程的 Agent 基础设施——不只是 GUI 平台，而是可通过 API/MCP 编排的后端。这是从「产品」到「平台」的关键一步。
3. 数据生态覆盖系统性推进：Looker MCP 和 BigQuery WIF 都在数据栈方向延伸。WIF 尤其重要——它为安全敏感的企业打开了 BigQuery + Agent 的大门，解决的是「企业不敢用」而非「功能不够」的问题。
Skill 治理框架是 Gumloop 的差异化亮点。将 Skills 从单个 Agent 的附件升级为组织级资源（含权限、共享、通知），与 GitHub Repo 的治理模型类似。如果我方有 Agent/Skill 体系，建议对标其三级共享设计。
Gumloop MCP 的 API-first 方向值得关注。如果竞争者允许第三方系统通过标准协议（MCP）编排其 Agent 和工作流，这会形成生态壁垒——集成越多，切换成本越高。
BigQuery WIF 是一种「信任基础设施」竞争。Gumloop 不是在做功能堆叠，而是在消除企业采购决策中的安全顾虑。这种「降低准入门槛」的产品策略比加功能更聪明。
Skill 治理框架成熟化 + API 可编程性增强 + 企业安全认证补强
Shared & Organization Skills — Skills 从「工具」到「基础设施」的关键一跃。Skills 刚发布时（v7.2, 2月20日）的本质是「Agent 的个性化知识包」——每个 Agent 创建和管理自己的 Skill。v9.11 的三个变化改变了这个定位：(1) 组织可见性——Organization 标签页意味着存在一个「公司技能库」；(2) 权限角色——Creator/Team Member/Viewer 三级管控；(3) 访问通知——请求、审批、驳回，Skill 访问有了治理流程。这构成了完整的「组织知识管理」循环：个人创建 → 团队验证和采纳 → 组织推广为标配。Gumloop 正在用 Skill 体系建立组织知识飞轮——使用越多，积累的 Skill 越多，迁移成本越高。
BigQuery WIF — 消除企业采购的「最后一个不」。很多企业的安全团队有个硬规则：不允许静态服务账号密钥。对 Gumloop 来说，这意味着这些企业的数据仓库团队根本无法使用 BigQuery 集成。WIF 消除了这个障碍——不是加了一个新功能，而是移除了一个阻止现有功能被使用的门禁。