Gumloop 功能规格 - Agent Owners and Users

初始上下文

1. 概览

背景

在 v11.0.0 之前，agent 沿用与技能相同的三档角色：Editor 能改一切、Viewer 只能看、Use Only 只能跑。这套模型对"个人用的助手"够用，但对"要发给整个组织的产品"完全不够——它只有"编辑 / 看 / 用"三个离散档位，中间那一大片"能自助使用但不能碰配置"的空间无处安放。

于是组织级 agent 的落地长期卡在一个二选一：

• 给全员 Editor → 提示词、连接器、secrets 全部暴露，且任何人都能改坏
• 只给 Viewer / Use Only → 使用者连"给自己建个定时触发器"都做不到

v11.0.0 用一个角色 × 能力矩阵替换掉离散档位：编辑权收归 Owner，使用体验交给 User，可见性由 Owner 逐项开关决定。

设计取向

只有"能不能管"这一个维度，没有第三档（想给更多能力 → 提为 Owner）；可见性是与角色解耦的配置（同一个 User 身份，两套开关就是两种产品）；默认取对 User 友好的全 Show / Allow，唯一不可逆的约束是"最后一个 Owner 不能走"；权限按 agent 而非按人，避免"N 个人 N 套视图"的组合爆炸。

目标

1. 可安全分发：把 agent 变成组织内可放心分发的产品，同时控制提示词、连接器、secrets 的暴露面
2. 自助而不失控：让 User 能在授权范围内自助（运行、建自己的触发器、看队友的 task），但不触碰配置
3. 职责可转移：创建者离职/不可用不会让 agent 变成孤儿（Request / Claim / 行政访问三条路径）
4. 与组织级模型划清边界：agent 内角色只作用于一个 agent；组织级角色（Composable Roles）与技能角色各管各的

2. 竞品分析

3. 核心机制 文档已验证

3.1 角色 × 能力总览

┌────────────────────────────────────────────┬──────────┬──────────────────┐
│  能力                                       │  Owner   │      User        │
├────────────────────────────────────────────┼──────────┼──────────────────┤
│  运行 agent / 发起 task                     │    ✅    │       ✅         │
│  看 instructions/model/connectors/skills/   │    ✅    │ 仅 Owner 选择展示 │
│  knowledge/subagents/secret 名              │          │                  │
│  编辑以上任何一项                            │    ✅    │       ❌         │
│  创建自己的触发器                            │    ✅    │  仅 Owner 允许    │
│  管理 agent 上所有触发器（含他人的）           │    ✅    │       ❌         │
│  增删 Owner/User、改 General Access          │    ✅    │       ❌         │
│  设置 User Permissions 与 Task Visibility    │    ✅    │       ❌         │
│  看 agent 上的每一个 task                    │    ✅    │ 取决于 Task Vis. │
│  删除 agent                                  │    ✅    │       ❌         │
└────────────────────────────────────────────┴──────────┴──────────────────┘

角色对齐规则：旧的 Editor → Owner；旧的 Viewer / Use Only → User（其可见性由 User Permissions 调节）。技能（skills）仍沿用 Editor / Viewer / Use Only 三档，本变更只作用于 agent。

3.2 八项 User Permissions（Owner 永远全可见）

• 这一组开关是 per agent 的，控制的是 User 的视图；Owner 永远全可见，不受任何开关影响
• 组织管理员可用 Agent Default Settings 改写这套默认值（见 3.10）

3.3 三条关键规则

1. Visible is not editable（可见 ≠ 可改）：Show Instructions 让 User 读提示词，但永远不能改。所有 User Permission 都只关乎"看见"，不关乎"编辑"
2. Hiding something does not disable it（隐藏 ≠ 停用）：隐藏 Connectors 后，agent 照常使用 Gmail，只是不把 Gmail 列给 User 看。开关控制的是"展示"，不是"能力"
3. Permissions are per agent, not per person（按 agent 不按人）：同一 agent 的所有 User 看到的完全一样。想给某人更多 → 提为 Owner，或复制一份不同配置的 agent。今天不支持一人一策

3.4 可见性设置在 agent 内的位置

┌────────────────────────────────────────────────────────────────────────┐
│  Agent Builder 四个 tab： Agent │ Triggers │ ▶ Access ◀ │ Settings       │
├────────────────────────────────────────────────────────────────────────┤
│  Access tab（本功能全部落在这里）                                        │
│    Owners           [ 谁有编辑与治理权 · 可加多个 ]                        │
│    Users            [ 谁能使用 · GA 进来的都是 User ]                      │
│    General Access   [ Restricted / Team / Organization / Anyone ]        │
│    File Sharing     [ Default / Organization / Anyone ]                  │
│    Task Visibility  [ Their tasks only / Team tasks ] ←仅团队 agent       │
│    User Permissions ────────────────────────────────────────────────┐   │
│      Show Instructions · Show Model · Show Connectors                │   │
│      Show Skills · Show Knowledge Sources · Show Subagents           │   │
│      Show Secrets · Create triggers                                  │   │
│  注：Share 弹窗与 Access tab 是同一份配置的双入口                         │
└────────────────────────────────────────────────────────────────────────┘

3.5 General Access 四档

• 团队内的 agent 不能设为 Restricted——Team 是下限
• 通过 General Access 进来的人一律是 User，没有角色选择器
• 邮箱直邀的授权会存续：即使之后 General Access 被降低，直接授予仍继续生效

3.6 Task Visibility（仅团队 agent）

一个 task = 与 agent 的一次对话。

• 该设置只存在于团队 agent，新建团队 agent 默认 Team tasks
• 个人 agent 上 User 只看到自己的 task，因此该设置被隐藏
• Owner 在任何类型的 agent 上都看得到全部 task；任何一个 task 也可单独分享
• 看到 task 包含其 task 关联的 artifacts，但不授予他人私有持久工作区文件的访问

3.7 File Sharing

Default behavior 为 agent 生成的每个文件设定分享范围：

3.8 触发器治理（Create triggers 关掉时）

若把 Create triggers 切到 Don't allow，而 User 已经有触发器，Gumloop 会询问怎么处理：

• Keep running — 它们继续触发。User 不能创建、编辑、启用触发器，但仍可查看、停用、删除自己的
• Disable them — 直接关掉

Owner 仍可在 Triggers tab 管理这些触发器。重新允许创建不会重新激活已停用的触发器。

示例配置（内部支持 agent 全员可聊）：General Access = Organization、Show Instructions = Hide、Show Connectors = Show、Create triggers = Don't allow。

3.9 治理闭环：三种取得权限的路径

• Claim Ownership 不要求所有原 Owner 都已离职，它是"接管 + 保留"而非"替换"
• 最后一个 Owner 不能被降级或移除，必须先加第二个 Owner——agent 永远需要一个能管它的人

3.10 与 Composable Roles 的边界

4. 功能需求

模块 A：双角色与八项 User Permissions

模块 B：访问范围、Task Visibility 与 File Sharing

模块 C：触发器治理与权限闭环

模块 D：组织级默认与治理边界

5. 用户场景

6. 战略意义

• 这是 agent 分发的治理基座——v10.19 解决"发给谁"（Slack 全员），v10.29 解决"新 agent 长什么样"（组织默认），v11.0.0 解决"发出去之后谁管什么"（权限面）。三件套齐备，agent 才从"工具"变成"组织内部产品"。缺了权限面，前两件都是裸奔
• "可见性"是这一轮真正的产品抽象——八项正交开关把"能用"与"能看见什么"解耦，这是大多数 agent 平台没有的一层。它让"透明但不可改""可用但隐藏配方"这类中间态成为一等公民，而不是要靠复制 agent 绕过
• 治理深度体现在三条铁律的一致性上——"可见≠可改""隐藏≠停用""按 agent 不按人"，每一条都对应一个容易做错的产品决策。加上触发器关闭时的存量处置、Claim 与行政访问的区分，这套设计的工程密度高于概念新颖度，恰是难以照抄之处
• 与数据级权限形成纵深——v10.23 的 Brain Salesforce 记录/字段级权限管数据可见性，本功能管 agent 自身配置可见性。两条正交轴叠起来，"敏感数据 + 敏感配置"的组合场景才有完整答案
• Claim Ownership 是组织级 agent 可长期存续的前提——任何组织级产品都会遇到创建者离职。把"接管"与"行政访问"分开，既不滥用管理员权力，又保证 agent 不会变成孤儿，这是把 agent 当基础设施运营的标志

7. 遥测

8. 路线图与未来演进方向

关键演进判断

1. "按 agent 不按人"是能力上限也是下一个突破口：今天的限制保证了简单，但真实组织里"同组人需要不同视图"很常见。公告里已明说"若某人需要更多权限，就提为 Owner 或复制一份 agent"——这个 workaround 迟早会被按人/按组的可见性取代 推断
2. Visibility 与 Channels 的交叉是未解之题：当 agent 同时活在 Web、Slack、Teams、Hosted Page 上时，八项可见性开关在各渠道如何呈现，目前留白 推断
3. Audit 是治理闭环的下一块拼图：'谁把 Show Instructions 改成了 Hide''谁在什么时候被提为 Owner'目前未有对应审计能力，而企业合规必然要求 推断
4. Claim Ownership 会向更细的继承语义演进：当前 Claim 保留原 Owner 授权。若原 Owner 长期不可用，是否需要"挂起/退休原 Owner"的中间态，是托管长期 agent 的必然问题 推断

📚 源文档参考

本规格由 Claude 竞品情报系统自动生成 · 2026-09-20 · 来源 Agent Access 官方文档 · 评分 9/13（战略 2 护城河 1 用户 3 复杂度 2 创新 1）