Gumloop v10.30.0 "Kyuquot"

功能详情

1. Browser Notifications for Agent Chats（Agent 对话的浏览器通知）

新功能

💡 Agent 跑长任务时用户只能盯着页面或反复切回来看——切走就失去"它跑完了吗 / 它在等我批准吗"的感知，用户被迫在"干等"和"错失审批"之间二选一

"Switch tabs during a long run and your browser tells you when the agent finishes or needs you for an approval, a question, or a connection. The tab icon shows whether the agent is working, blocked, or has something you have not seen. Turn it on from Settings."

[✅ 文档已验证] 开关在 Settings → Profile → Preferences → Agent notifications。三条要点：

浏览器本身必须允许 Gumloop 发通知，首次开启时浏览器会询问，要选 Allow
通知只在 Gumloop 标签页处于后台时触发——你正看着任务时不会弹
设置是按浏览器的（与 Theme 同类），每台机器要各开一次

若此前屏蔽过通知，Gumloop 会明确提示 "Notifications are blocked for this site. Allow them in your browser's site settings."。通知触发点在 HITL 审批。标签页图标区分三种状态：working / blocked / 有未读。

应用场景：(1) 启动 30 分钟以上长任务后切去写文档/开会 (2) 多 agent 并行时靠 tab 图标扫一眼哪个卡住了 (3) HITL 流程不再因为切走而让 agent 干等

价值评分 4/13（战略1 护城河0 用户2 复杂度1 创新0）[未达 SPEC]

📄 帮助中心源：profile_settings.md（已存档 2026-09-20 → gumloop-docs_profile-settings.md）

2. Model Router in the API, SDK, and CLI（Model Router 开放到 API / SDK / CLI）SPEC v1.1 更新 →

新功能

💡 Model Router 此前只在 Gumloop 产品内部生效——用户自己的应用、脚本、CI 里要调模型时，仍然只能自己写死模型或自己造一套路由逻辑，享受不到 Gumloop 用真实生产数据调出来的路由判断

"Ask the Model Router which model to use for a prompt from your own code. Send the prompt and the models you have, and get back the pick and why."

[✅ 文档已验证 · POST /models/route] 关键发现：Gumloop 的路由器内部代号是 Chew（"Gumloop Chew — the model router behind Auto"），响应里 router 恒为 gumloop-chew，实际选中的模型在 route.model。这个端点只返回决策，不执行模型、也不跑 fallback；路由判断本身消耗 credits，并受调用方模型权限约束。

响应字段：route.lane（选中模型的能力档位：micro / light / standard / plus / max）、route.verdict_lane（判断出的需求档位）、route.adjustment（escalated / downgraded / null，这就是"mid-run 升级"的数据表达）、route.fallback_models（排除受限候选）、route.fail_closed（路由未完成时是否用了安全兜底）、candidates（含 status: "restricted" 者，受限者只上报不选中）。

请求参数：input（必填，别名 message）、models（1–50 个候选；省略则用 Chew 的 lane-chain 并集）、history（≤20 轮）、agent（name/description/system_prompt，上下文越锐利路由越准）、team_id（须为真实团队成员）。

应用场景：(1) 在自有应用/agent 框架里复用 Gumloop 的路由判断 (2) CI/CD 或批处理按成本自动挑模型 (3) 把 Gumloop 的模型治理策略延伸到平台外

价值评分 6/13（战略1 护城河2 用户1 复杂度1 创新1）[未达 SPEC，但为战略级 SPEC 的延伸 → 更新 spec_model-router.md v1.1]

📄 帮助中心源：api-reference/models/route-model.md（含完整 OpenAPI，已存档 2026-09-20 → gumloop-docs_route-model-api.md）

3. Organization Webhooks（组织事件外发 Webhook）

新功能

💡 组织内的人事变动（新成员加入）此前只能靠人去后台看或定时轮询导出——下游的入职流程、权限系统、审计台账无法实时响应，只能人工搬运

"Organization admins can register webhook endpoints under Settings, Data Export, Webhooks and get a signed request whenever someone joins the organization. Send a test event, watch the delivery log, and pause or resume an endpoint from the same tab."

[✅ 文档已验证 · 官方文档标题为 Outbound Webhooks] 门槛：需 Enterprise 订阅且具备导出组织数据的权限。入口在 Settings → Organization → Data Export → Webhooks；该 Tab 对 Admin / Manager / Analytics 角色开放，受组织访问策略约束——仅有个人导出权限不等于能用 webhook。

Endpoint URL——必须 HTTPS、必须公网可达、不得内嵌凭据、必须能对测试事件返回 2xx
至少选一个事件——当前只有 Member joined（organization.member.joined），上报的是新建立的成员关系，涵盖接受邀请、基于域名的自动加入、SCIM 供给；仅发出邀请不会触发，给已有成员加角色也不触发
列表显示 Endpoint / Events / Status / Created 与逐行操作，支持搜索与分页；可发测试事件、看投递日志、暂停或恢复

应用场景：(1) 新成员入职自动触发下游 provisioning (2) 把成员变动写入自有审计台账 (3) 用签名 payload 驱动内部通知/看板

价值评分 4/13（战略1 护城河1 用户1 复杂度1 创新0）[未达 SPEC·首个"事件出得去"通道]

📄 帮助中心源：organization_webhooks.md（已存档 2026-09-20 → gumloop-docs_organization-webhooks.md）

4. Attest MCP（消费者研究集成）

集成

"Agents can now run and read Attest consumer research: brand tracking, creative and concept tests, and survey results."

应用场景：市场/品牌团队让 agent 拉取品牌健康度追踪数据、汇总概念测试结论，替代人工登录平台导出

📄 帮助中心源：gumloop.com/mcp

5. TasteLabs MCP（设计系统提取与校验）

集成

"Agents can now extract a design system from any site and check new designs against it with TasteLabs. Bring your own TasteLabs key."

可从任意站点提取设计系统，并用它校验新设计是否一致。需自带 TasteLabs key（BYOK）。

应用场景：设计/前端团队让 agent 抓取品牌站的设计 token，再检查新页面/新素材是否符合既定设计系统

📄 帮助中心源：gumloop.com/mcp

6. Platform Improvements（平台改进 3 项）

平台改进

💡 性能与资源隔离投资；大规模 fan-out 的并发治理是 v10.26 后台 Subagents 之后的补课

Agent turns 启动更快——尤其是身处大量项目、或技能库很大的用户
Subagents 每 chat 有上限——一次大规模 fan-out 不再拖慢其他 chat（资源隔离）
Agent 数据导出与 drains 现在可包含 Evaluations 是否启用（治理数据面补齐）

应用场景：多项目重用户的启动体验；大规模 fan-out 时的平台稳定性；合规导出需要证明 agent 是否受 evals 约束

7. MCP Improvements（Monday.com 附件下载）

集成能力扩展

Monday.com：agent 现在可下载 item 上的附件

应用场景：项目管理系统里的文件资产可被 agent 取出处理（与 v10.29 Airtable 附件上传是一对——一个进一个出）

竞品分析

战略方向判断

v10.30.0 "Kyuquot"（温哥华岛西北岸的 Nuu-chah-nulth 原住民村落）是一个承接版——它没有开出新战线，而是把 v10.29.0 Model Router 这条主线向两个方向压实。

1. Model Router 从"产品内能力"变成"平台 API"。最有信息量的一条是 POST /models/route——Gumloop 把 Auto 背后的路由器整个开放了出来，甚至暴露了内部代号 Chew、五档能力 lane（micro/light/standard/plus/max）、verdict_lane（判断出的需求档）与 lane（最终选中档）之间的 adjustment（escalated/downgraded）。这条 API 把 v10.29 那条"89% 降本"的叙事从营销数字变成了可被第三方验证和依赖的工程接口。

2. fail_closed 字段泄露了 Gumloop 的成本治理哲学。响应里的 route.fail_closed（"路由未能完成时是否用了安全兜底"）说明：路由失败时 Gumloop 选择降级到安全默认，而不是崩溃或越权选模型。这与 v10.22 把新集成默认屏蔽、v10.23 的 Salesforce 记录级权限是同一套 fail-closed 思路。

3. Organization Webhooks 是企业数据出口的第一块砖。目前只有一个事件，但意义不在数量而在方向：此前 Gumloop 的企业集成几乎全是"数据进得来"（连接器、Brain 源），这是第一条"事件出得去"的通道。

4. 同版修复暴露上一轮的欠债。6 项修复里 4 项围绕 v10.26 后台 Subagents 与 Gumball 主动场景——agent 能力跑得比状态管理快，这是所有 agent 平台在进入"多 subagent 并发 + 主动推送"阶段的通病。

与我方对比

Model Router API 是"要不要把内部能力产品化"的一道选择题。Gumloop 选择把路由判断开放出去，代价是路由逻辑被竞争者看得更清楚；收益是第三方一旦接入就产生迁移成本。我方的判断依据应该是：路由判断本身是否是我们真正的差异化来源。

fail_closed 这个设计值得直接抄进我们的 API 契约。任何"平台替用户做决策"的能力（选模型、选数据源、选权限），都必须在响应里显式告诉调用方这次决策是否是降级兜底的结果。这是把"黑盒智能"变成"可审计决策"的最小成本做法。

Organization Webhooks 提醒我们：企业集成的成熟度是双向的。"事件出得去"（webhook / 事件流）和"数据进得来"（连接器）要同步规划——只做入口不做出口，IT 部门会把它当成孤岛。

★★★

一次承接式的平台化补课——Model Router API 把 v10.29 的战略级能力延伸到平台外，Organization Webhooks 开了企业事件出口，但两者用户面都窄，无新 SPEC 候选

关键功能深度点评

Model Router API — 让"成本智能"变成可被第三方依赖的接口。v10.29 的 89% 降本如果只是个产品内黑盒，外界只能选择相信或不信；现在 POST /models/route 让任何人都能拿自己的 prompt 去问 Chew 会选什么、为什么选、判定的档位是什么、是否发生 escalation。这是把营销主张转化为可证伪接口的典型做法，值得我方在介绍任何"智能决策"能力时借鉴。

Chew + 五档 lane + adjustment — 终于看清 Model Router 的骨架。此前只知道"双档路由"，API 暴露的真实结构是五档能力 lane，流程是"先判定需求档位（verdict_lane）→ 再决定是否调整（escalated/downgraded）→ 得最终档位（lane）"。"mid-run 升级"在数据模型上就是这个 adjustment: escalated。这套"判定档 → 调整 → 定档"的三段式比"直接选模型"更容易解释、更容易调参、也更容易向用户交代理由。

Organization Webhooks — 单个事件但方向正确。下次抓取第一件事：复查 webhook 事件列表是否从 1 个扩展到 task 完成、agent 运行失败、credits 阈值等——如果扩到 5+ 事件，它就从治理补强升级为企业集成中枢，需要重新评分。

修复三连指向同一个病：状态诚实性。"subagent 卡片停在 pending"、"connector 报告可用但实际没连"、"Meeting Prep 显示错误的日历文案"——三件事的共性是系统向用户报告了一个与真实状态不符的状态。Agent 平台的信任建立在状态诚实上。建议把它当作 agent UX 的一条硬性验收标准：任何"看似完成/看似可用"的状态都必须有真实依据。