Gumloop v11.0.0 "Conche"

功能详情

1. Revamped Agent Builder（Agent 构建器重构）SPEC 新建 →

新功能

💡 组织里 agent 越建越多，但配置面是"六个平铺 Tab"——instructions、connectors、skills、triggers、access 深埋在列表里，改一处要来回跳转；新用户面对空白 builder 不知道从哪开始；而 agent 建完之后的"它表现如何、花了多少钱"散落在别处，"配置"与"运营"是两个割裂的界面

"The agent page is reorganized so instructions, connectors, skills, triggers, and access are easier to find and edit in place. A new agent starts from one question, what should it take care of, then connects the right apps, writes its own instructions, and offers a trigger. Reflections, Evaluations, and Insights live together on a Performance page with spend by model, member, connector, skill, and subagent."

[✅ 文档已验证] 四 Tab：Agent（model / instructions / connectors / skills / knowledge sources / subagents / secrets / abilities）、Triggers（含 AI Managed 开关与 Mine / Team 过滤）、Access（Owners / Users / General Access / File Sharing / Task Visibility / User Permissions）、Settings（Identity / Suggested Prompts / Advanced AI / Chat Summarization / Model Fallback / Destructive）。

In-place 展开——点 section header（如 Connectors）就地展开为带 Agent > Connectors 面包屑的全屏视图，可下钻到连接器的工具再返回而不丢位置。未按 Save（Ctrl/Cmd + S）前一切不保存，Save 旁的箭头撤销未保存更改
Guided setup——全新 agent 先问 "what should it take care of"，据答案自配置（连应用 → 自写 instructions → 提议触发器），而不是直接丢进完整 builder。Profile → Preferences 的 Skip guided agent setup（默认关）可回到旧行为
Performance 页——侧栏新增，把 Insights / Evaluations / Tasks 合流。Credits Over Time 三序列并列（credits / tasks / cost per task，用于区分"花钱变多"和"用量变多"），可按 model / member / connector / skill / subagent 拆消费
侧栏——New Task（Ctrl/Cmd+Shift+O）/ Artifacts / Performance / Channels / Recents；有待批准的工具调用时 Recents 上方出现 pending action request

应用场景：(1) 同时维护多个 agent 的 Owner——改配置不再跨 Tab 跳跃，下钻后可原路返回 (2) 新用户/非技术用户——从"它该负责什么"一句话起手 (3) 需要回答"这个 agent 值不值"的管理者——成本可按 model/member/connector/skill/subagent 归因，与质量、改进同页可见

价值评分 9/13（战略2 护城河1 用户3 复杂度2 创新1）[初始9→质疑-0→最终9] — SPEC 候选（高价值），新建 spec_agent-builder.md

📄 帮助中心源：agents.md + agent_performance.md + profile_settings.md（均已存档 2026-09-20）

2. Agent Owners and Users（Agent 双角色权限模型）SPEC 新建 →

新功能

💡 Agent 要从"个人助手"变成"组织内可安全分发的产品"，但旧的三角色模型（Editor / Viewer / Use Only）粒度太粗——要么给编辑权（危险），要么只能看/用（无法让使用者自助建触发器）。结果是组织级 agent 只能靠"全员 Editor"这种粗暴授权，配方、连接器、提示词全部暴露。而 Task Visibility 缺位又让团队 agent 的对话记录要么全公开要么全私密

"Agents now have two roles. Owners configure the agent and decide what Users can see and do, such as viewing team tasks, reading the instructions and connectors, or creating triggers. Users get a focused chat page and can request Owner access."

[✅ 文档已验证] 旧角色作废：Editor / Viewer / Use Only 不再适用于 agent（技能仍沿用），Editor → Owner，Viewer / Use Only → User。

八项 User Permissions（Show / Hide）：Show Instructions / Model / Connectors / Skills / Knowledge Sources / Subagents / Secrets（只显示 secret 名称）/ Create triggers（Allow / Don't allow）。默认全 Show、Create triggers 默认 Allow，组织管理员可用 Agent Default Settings 改这套默认。

三条铁律：① Visible is not editable（所有 User Permission 都是关于"看"不是"改"）；② Hiding something does not disable it（隐藏 Connectors 后 agent 照常用 Gmail，只是不列给 User）；③ Permissions are per agent, not per person（同一 agent 的所有 User 视图一致，不能一人一策；需要更多权限就提为 Owner 或复制 agent）。

General Access 四档：Restricted（仅 Owner + 邮箱直邀，仅个人 agent）/ Team / Organization / Anyone；团队内 agent 不能 Restricted，Team 是下限；邮箱直邀的授权会存续，即使之后 General Access 降低
最后一个 Owner 不可降级或移除（须先加第二个）
Task Visibility（仅团队 agent，新建默认 Team tasks）：Their tasks only / Team tasks（可读队友 task，但接着跑别人的仍需 Owner）；个人 agent 隐藏该设置
File Sharing：Default / Organization / Anyone
Request Owner access：User 在头部 ⋮ 菜单发起并指定收件 Owner，Owner 在收件箱批准/拒绝
Claim Ownership：Owner 全不可用时同组织管理员可接管，不要求所有原 Owner 都已离职——改 canonical creator 并加一条 Owner 授权，原 Owner 保留；行政访问 ≠ 成为 Owner
Create triggers 关掉时：若 User 已有触发器，Gumloop 询问 Keep running 或 Disable them；重新允许创建不会重新激活已停用的触发器

应用场景：(1) 组织级客服 agent——General Access = Organization、Show Instructions = Hide、Show Connectors = Show、Create triggers = Don't allow（官方范例）(2) 团队 agent 让成员看彼此任务但限制接续 (3) 创建者离职后由管理员 Claim Ownership 接管无主 agent (4) 敏感配置的 agent 只暴露连接器不暴露提示词

价值评分 9/13（战略2 护城河1 用户3 复杂度2 创新1）[初始10→质疑-1→最终9] — SPEC 候选（高价值），新建 spec_agent-owner-user-roles.md

📄 帮助中心源：agent_access.md（已存档 2026-09-20 → gumloop-docs_agent-access.md）

3. Steering is now Instant（引导改为即时生效）SPEC v1.2 更新 →

新功能

💡 排队消息的 "Send Now"（⌘/Ctrl + Enter）此前是破坏性的——它重启当前回合，agent 已经跑完的步骤白费，用户想中途补充信息就得在"等它跑完"和"打断重来"之间二选一

"Send Now and Cmd+Enter on a queued message no longer restart the turn. The agent finishes its current step, reads your message, and keeps going."

[✅ 文档已验证] 官方文档的措辞是 "The agent interrupts its current step and continues with your new input instead of ending the task"——注意关键词 "instead of ending the task"，说明旧行为不仅是重启，而是以结束任务告终。两条边界同样重要：引导不会撤销已经完成的动作，也不会绕过待批准的审批；要真正结束运行请用停止控件而非引导。

应用场景：(1) 长任务跑到一半发现需求补充——即时注入而不丢进度 (2) 发现方向偏差时立刻纠偏且保留已完成步骤 (3) 多步骤任务中连续投放修正，agent 在步骤边界逐一读取

价值评分 6/13（战略1 护城河1 用户2 复杂度1 创新1）[未达 SPEC，但为 Queue and Steer（10/13）的语义升级 → 更新 spec_queue-steer.md v1.2]

📄 帮助中心源：agents.md — Message queue and steering 章节（已存档 2026-09-20）

4. Customer.io MCP（生命周期营销集成）

集成

"Agents can now work with your Customer.io people, segments, campaigns, and messages across email, SMS, push, and in-app."

应用场景：增长团队让 agent 按分群拉取 campaign 表现、起草并投放触达消息、复盘各渠道转化

5. LinkedIn Ads MCP（B2B 广告报表集成）

集成

"Agents can now pull LinkedIn Campaign Manager reporting: ad accounts, campaign groups, campaigns, creatives, and performance analytics."

应用场景：B2B 投放团队让 agent 汇总 LinkedIn 广告层级表现、对比创意效果——与既有的 Meta Ads 合起来覆盖主流付费社媒

6. Marketo Engage MCP（B2B 营销自动化集成）

集成

"Agents can now read and update leads, lists, programs, and campaigns in Adobe Marketo Engage."

可读可写——leads / lists / programs / campaigns。注意这是少数具备写权限的营销类集成。

应用场景：营销运营让 agent 批量更新线索状态、按规则调整名单、同步 campaign 配置

7. Platform Improvements（平台改进 12 项）

平台改进

💡 导航重构与 Gumball 工作台化是 v11 产品面工程的另一半——与 Agent Builder 重构同源：多 agent 时代的"找到它"问题

侧栏新增 Agents 区与 Tasks 区——可搜索近期 task、按来源过滤、用方向键逐个翻阅
Gumball home 把 Daily Chew、Smart Inbox 草稿、connectors 收到一页，并新增 Routines 区设置 Daily Chew 与 Meeting Prep 的运行时间
长对话流式输出更顺滑，且 agent 在回合间复用更多 prompt，每回合启动更快
Create With AI 建触发器改为从 connector picker 起手——让 Trigger Builder 知道要监视哪个 app
无描述的 agent 会依据其配置与使用方式自动生成描述并保持更新；用户手写的描述永不被覆盖
给 agent 连 Slack app 后以 Open in Slack 链接收尾，直接落到 bot DM
Gumball 对 Firecrawl / Apollo / Exa 等可选 connector 改用你自有的 key，仅在你没有时才回落到 Gumloop key（BYOK 扩展到连接器层）
从日历或历史打开 Meeting Prep 会打开它被投递的那个 chat，让你的反馈影响下一次运行
模型选择器显示每个模型跑在哪把 API key 上
Organization Insights 图表可按 day / week / month 分桶
Manage Evaluations 对新 agent 默认开启
Gumball 第六种配色 tangerine

应用场景：侧栏导航重构解决多 agent 时代的"找到它"问题；Gumball home + Routines 把分散的主动能力收成一个工作台；自动描述让 agent 目录在规模化后仍可被理解；BYOK 扩展让企业客户能用自己的配额与账单

8. MCP Improvements（集成能力扩展 3 项）

集成能力扩展

Gmail：agent 现在可读你的邮件签名，草稿的收尾方式与你自己发信一致（输出风格对齐）
Linear：agent 现在可创建与更新挂在 project 或 issue 上的文档
Exa：搜索与页面抓取可固定到某个日期的页面快照（时间点检索，对抗网页内容漂移）

应用场景：Gmail 签名让 agent 代笔的邮件不像机器人；Linear 文档打通让 agent 直接产出项目文档；Exa 快照让"某日期时该页面写了什么"成为可复现的检索

竞品分析

战略方向判断

v11.0.0 "Conche"（纽芬兰大北半岛的渔村）是 Gumloop 的第一个 v11 大版本，而它选择用大版本来做的不是新能力，是产品面的重构——这件事本身就是最强的战略信号。

1. 大版本号给了一次"把产品做对"而不是"把功能做多"的重构。看 v10.x 的轨迹：Brain 平台化（v10.13）、Gumball 诞生（v10.18）、Slack 全员分发（v10.19）、Subagents 后台执行（v10.26）、evals 闭环（v10.27）、Model Router（v10.29）——能力面已经铺得很宽。v11.0.0 的新功能只有 3 个，其中 2 个是产品面重构。这说明 Gumloop 判断：agent 平台当前最大的瓶颈不是"能不能做"，而是"能不能被管理"——建得起来、改得动、看得清、管得住。

2. "配置面"与"运营面"被合并成同一个界面。最有分量的动作是把 Reflections / Evaluations / Insights 三件事收进单 agent 的 Performance 页，并把消费按 model / member / connector / skill / subagent 拆开。这是把 agent 从"一个配置对象"变成"一个被管理的实体"——你建它的时候就在同一个导航里能看到它花了多少钱、做得对不对、该改什么。

3. 双角色模型暴露了 Gumloop 的真正目标客户画像。旧模型 Editor / Viewer / Use Only 是文档协作的思维（谁能编辑这个文件）；新模型 Owner / User 是产品分发的思维（谁能运营这个产品、谁能当它的用户）。更关键的是那条铁律——"Permissions are per agent, not per person"——它明确拒绝了"一人一策"，换来管理员心智的极大简化。这是一个把"管理成本"而非"权限表达力"放在首位的设计取舍。

4. "描述自动生成、且永不覆盖用户手写的"是一个值得记住的产品原则。这条不起眼的小改动展示了 Gumloop 对 AI 生成内容与人类权威的边界处理：AI 可以填补空白，但不能覆盖人类的表达。同类思路在 Smart Inbox "只为之前有邮件往来的人起草回复"中也出现过。

5. 引导的语义修正说明 agent 运行时已经能做"步骤边界插入决策"。Send Now 从"重启回合"变成"跑完当前步骤后读取新输入并继续"，这要求运行时有干净的中断点、可恢复状态与消息注入能力——和 v10.29 Model Router 的 mid-run 升级共用同一套"运行中可干预"的架构。

与我方对比

"大版本做重构"这件事本身值得我们对标。大部分产品把大版本留给"憋了很久的大功能"，Gumloop 却用 v11 来做产品面整合。前提是它认为功能已经够多，多到需要被组织起来。我方若处在"功能铺得很快、但配置面在长"的阶段，应当主动安排一次这样的整合版本——而且要在用户抱怨之前做，而不是之后。

Owner / User 二元模型值得直接跟进，但要注意它放弃了什么。优点是管理员心智极简；代价是 无法一人一策（官方文档明确说 "No today"）。我方设计时要想清楚：我们的客户是否会需要"张三能建触发器、李四不能"这种粒度？如果会，二元模型就不够，需要"角色 + 逐人覆盖"的混合模型。Gumloop 敢做二元，是因为它的客户以中小团队为主；这是一个客群判断，不是一个普适最优解。

"Visible is not editable" 与 "Hiding does not disable" 两条铁律建议直接抄。这两句话把权限设计中最容易出错的两个语义钉死了。我方的任何权限 UI 都应该能用这两句话自检——如果界面上有一个开关同时承担"能不能看"和"能不能改"两种含义，设计就已经错了。

"AI 填空白但不覆盖人"的原则建议写进我们自己的 AI 内容策略。这类约束是产品成熟度的体现，它让用户敢于信任 AI 的自动行为，因为知道它不会越界。

即时引导的实现前提是"可恢复的中断点"，这是运行时能力而非 UI 能力。如果我方 agent 运行时尚不能在任何步骤边界暂停并注入新上下文，那么"Send Now 不重启回合"是做不到的。建议把"步骤边界可干预"列为运行时架构的一项硬性要求，因为它同时解锁了中途换模型与即时引导两件事。

★★★★★

首个 v11 大版本，两个 9/13 高价值重构——Agent Builder 重构 Agent 的建/管/看三面，Owner/User 双角色补齐 agent 分发的治理基座；配合即时引导的语义修正与侧栏/Gumball home 的导航重构，构成一次完整的"agent 平台产品面成熟化"

关键功能深度点评

Revamped Agent Builder — agent 平台从"功能竞赛"转向"可管理性"的标志。它不增加任何 agent 的能力，但改变了人与 agent 的接触面。此前 Gumloop 的能力投资都在回答"agent 能做什么"；v11.0.0 第一次系统性回答"人怎么建它、改它、判断它值不值"。Performance 页把成本、质量、改进三合一，是这次重构中最有战略价值的一块——它让"这个 agent 值得继续投入吗"变成一个可以在一个页面回答的问题。下次抓取第一件事：复查 guided setup 的转化数据是否被披露（它是整个重构的入口假设），以及 Performance 页是否扩展出跨 agent 的横向对比。

Agent Owners and Users — 双角色是"选择简单"而非"选择精确"。这是本次最需要我方做客群判断的功能。Gumloop 主动放弃了 per-person 权限粒度，换来管理员心智的极简。它赌的是客户要的是"agents 能安全发给全公司"，而不是"给每个人配不同权限"。配合 v10.29 的组织级 Agent Default Settings，Gumloop 的 agent 治理模型已经完整：组织定默认 → Owner 调单个 agent → User 只负责用。而 Claim Ownership 解决的是企业里最真实的痛点之一：人员流动导致的资产无主。

"即时引导"是本次被低估的一条。它只有一句话的 changelog，但语义变化是实质性的。这与 v10.29 Model Router 的 mid-run 升级共用同一套运行时能力——"运行中可干预"。我方的技术判断应该是：这不是 UX 功能，而是运行时架构的分水岭——能做到"步骤边界可干预"的平台，才能同时做即时引导与动态模型路由；做不到的平台，这两个功能都只能做成"重启回合"的劣化版本。

sidebar 与 Gumball home 的导航重构——多 agent 时代的"找到它"问题。侧栏新增 Agents 区与 Tasks 区，Gumball home 把 Daily Chew / Smart Inbox 草稿 / connectors 收成一页。这两个改动合计说明 Gumloop 的用户已经拥有多个 agent、多个 task——从"我有一个 agent"进入"我管理一群 agent"。导航重构通常是产品从单对象走向多对象时必然付的债，我方的产品路线图里应该预留这笔债的预算，而不是等用户抱怨再还。

修复里的"一个人重连 MCP connector 导致全组织失效"值得单独警惕。这是 v11.0.0 名单里唯一一条严重缺陷类修复——多租户环境下凭据隔离做错，一个人的正常操作波及全组织。它提醒我方：共享连接器（org-shared MCP / team secrets）的凭据状态必须是租户隔离的，任何"重连"操作都不得影响他人。这类缺陷的修复优先级应当高于任何新功能。