已完成 — 基于官方文档与 changelog 综合验证
文档已验证 表示内容直接来自 Gumloop 官方文档或 changelog，推断 表示基于可用信息的合理推导。由于 v9.11.0 官方帮助文档尚未更新，Enhanced 相关描述主要来自 changelog 和已有 MCP 文档的交叉推断。
8/13（战略2 护城河2 用户2 复杂度1 创新1）
Gumloop 自 v8.x 时代起就对外暴露了 MCP 协议接口（Gumloop MCP），允许外部系统通过标准化的 MCP 协议调用 Gumloop 平台能力。截至 v9.11.0 之前，Gumloop MCP 提供 10 个工具覆盖三大领域：工作流管理（5 个）、Agent 交互（2 个）、文档与管理（3 个）。文档已验证
然而，v9.11.0 之前的 Gumloop MCP 存在三个关键局限：
| 局限 | 表现 | 影响 |
|---|---|---|
| 工具列表静态 | 客户端需要手动配置 Gumloop MCP 提供哪些工具 | Gumloop 新增工具后客户端无感知，需手动同步 |
| 响应模式同步 | 所有工具调用均为请求-响应模式，无流式输出 | 长时间运行的工作流执行或 Agent 对话需要客户端轮询 Get Run Details / Get Agent Status |
| 认证方式单一 | 仅支持静态 API Key / Bearer Token | 企业环境中 API Key 管理成本高，不符合安全最佳实践 |
v9.11.0 "Huntsville" 发布的 Gumloop MCP Enhanced 针对这三个局限进行了协议级升级。同时 推断，Enhanced 更新可能扩展了工具清单——官方文档提示「当前无创建/编辑/删除 Agent、管理 Skill、创建/管理 Workbook 的工具」，这可能正是「More Powerful」所指的新增能力方向。
┌─────────────────────────────────────────────────────────────────────────────┐ │ Gumloop MCP — 协议桥梁 │ │ │ │ ┌─────────────────────┐ ┌─────────────────────────────┐ │ │ │ 外部系统 (MCP 客户端) │ │ Gumloop 平台 (MCP 服务端) │ │ │ │ │ │ │ │ │ │ • Claude Desktop │ MCP Protocol │ ┌───────────────────────┐ │ │ │ │ • 自定义 Agent │◄──────────────────►│ │ Workflow Management │ │ │ │ │ • CI/CD Pipeline │ (Streamable HTTP │ │ • List Saved Flows │ │ │ │ │ • 内部工具链 │ / SSE) │ │ • Start Flow Run │ │ │ │ │ │ │ │ • Get Run Details │ │ │ │ │ [推断] Enhanced 新增：│ │ │ • Get Run History │ │ │ │ │ • 动态工具发现 │ │ ├───────────────────────┤ │ │ │ │ • 流式消费 │ │ │ Agent Interaction │ │ │ │ │ • OAuth 2.0 客户端 │ │ │ • Start Agent │ │ │ │ │ │ │ │ • Get Agent Status │ │ │ │ └─────────────────────┘ │ ├───────────────────────┤ │ │ │ │ │ Docs & Management │ │ │ │ Authentication: │ │ • Search Docs │ │ │ │ • API Key (原有) │ │ • Ask Gummie │ │ │ │ • Bearer Token (原有) │ │ • Get Audit Logs │ │ │ │ • OAuth 2.0 (v9.11.0 新增) [文档已验证] │ ├───────────────────────┤ │ │ │ • Device Code (v9.11.0 新增) [文档已验证] │ │ [推断] Enhanced 新增： │ │ │ │ │ │ • Create/Edit Agent │ │ │ │ │ │ • Manage Skills │ │ │ │ │ │ • Create Workbook │ │ │ │ │ └───────────────────────┘ │ │ │ │ │ │ │ │ Gumloop 内部能力： │ │ │ │ • Flow 执行引擎 │ │ │ │ • Agent 推理与工具调用 │ │ │ │ • 文档索引与语义搜索 │ │ │ │ • 审计日志存储 │ │ │ └─────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────────┘
Gumloop MCP Enhanced 是 Gumloop 作为 MCP 服务端向外部暴露自身能力的接口。它与 Gumloop 已有的 MCP 基础设施形成互补：
┌───────────────────────────────────────────────────────────────────┐ │ Gumloop MCP 生态三象限 │ ├─────────────────────────┬─────────────────────────────────────────┤ │ Gumloop 作为 MCP 客户端 │ Gumloop 作为 MCP 服务端 │ │ (连接外部 MCP 服务器) │ (向外部暴露自身能力) │ ├─────────────────────────┼─────────────────────────────────────────┤ │ Custom MCP Servers │ **Gumloop MCP Enhanced** (本文档) │ │ • 50+ 预构建集成 │ • 工作流管理 API │ │ • 自定义 HTTPS 服务器 │ • Agent 交互 API │ │ • Native MCP / Backend │ • 文档搜索 API │ │ • 自动工具发现 │ • 动态工具发现 (v9.11.0) │ │ │ • 流式响应 (v9.11.0) │ ├─────────────────────────┼─────────────────────────────────────────┤ │ MCP Hosting & Proxying │ (未来可能) │ │ • Hosted: 部署自建 MCP │ • Webhook 事件推送 │ │ • Proxied: 代理外部 MCP │ • 实时工作流状态订阅 │ │ • 工具级访问控制 │ • GraphQL/OpenAPI 替代协议 │ └─────────────────────────┴─────────────────────────────────────────┘
Gumloop MCP 在 v9.11.0 之前提供 10 个工具，分为三个模块：
| 工具名 | 功能 | 输入 | 输出 |
|---|---|---|---|
list_saved_flows | 列出账户中的所有已保存工作流 | 无（或可选的筛选参数） | 工作流列表（名称、ID、描述） |
list_workbooks | 列出工作簿及其嵌套的工作流结构 | 无（或可选的工作簿 ID） | 工作簿列表（含嵌套工作流） |
start_flow_run | 触发一个工作流执行 | 工作流 ID + 可选的输入参数 | 运行 ID、状态 |
get_run_details | 获取某次运行的详细信息 | 运行 ID | 状态、输出、日志、时间戳 |
get_run_history | 获取工作簿或特定工作流的运行历史 | 工作簿 ID 或保存项 ID | 历史运行列表（含状态和时间） |
| 工具名 | 功能 | 输入 | 输出 |
|---|---|---|---|
start_agent | 向 Gumloop Agent 发送消息，启动异步交互 | Agent ID + 消息内容 | 交互 ID、初始状态 |
get_agent_status | 轮询 Agent 交互状态并获取响应 | 交互 ID | 状态（进行中/已完成）、Agent 回复 |
| 工具名 | 功能 | 输入 | 输出 |
|---|---|---|---|
search_documentation | 语义与关键词文档搜索 | 搜索查询词 | 匹配的文档条目 |
ask_gummie | 向文档知识库提问，获取带引用的 AI 回答 | 自然语言问题 | AI 回答 + 引用来源 |
get_audit_logs | 获取组织级审计日志（仅管理员） | 时间范围等筛选条件 | 审计事件列表 |
官方文档快照明确指出以下能力当前不在 Gumloop MCP 的工具清单中：
推断 v9.11.0 的「More Powerful」定位可能填补了其中的部分或全部缺口。
客户端 Gumloop MCP 服务端 │ │ │ POST /mcp/tools/list │ │ Authorization: Bearer <api_key> │ │─────────────────────────────────────►│ │ │ 验证 API Key │ │ 查询用户权限 │ 200 OK + 工具列表 JSON │ │◄─────────────────────────────────────│
原有流程仅支持：
问题：API Key 管理成本随集成数量线性增长。每个外部系统需要单独配置和轮换密钥。
客户端 Gumloop MCP 服务端 OAuth Provider │ │ │ │ ① 发起 OAuth 授权请求 │ │ │─────────────────────────────────────►│ │ │ │ ② 重定向到授权页面 │ │◄─────────────────────────────────────│ │ │ ③ 用户在浏览器中授权 │ │ │─────────────────────────────────────────────────────────────►│ │ ④ 回调 + Authorization Code │ │ │◄─────────────────────────────────────────────────────────────│ │ ⑤ 用 Code 换取 Access Token │ │ │─────────────────────────────────────►│ │ │ │ ⑥ 验证 Token │ │ │─────────────────────►│ │ │ ⑦ Token 有效 │ │ │◄─────────────────────│ │ 200 OK + Access Token │ │ │◄─────────────────────────────────────│ │ │ │ │ │ ⑧ 后续请求携带 Access Token │ │ │ Authorization: Bearer <access_token> │ │ │─────────────────────────────────────►│ │
文档已验证 两种新增流程：
推断 Token 支持自动刷新（Refresh Token），减少人工轮换频率。
Gumloop MCP 的工具调用模型中，start_flow_run 和 start_agent 是异步操作——它们立即返回运行 ID/交互 ID，客户端需要通过 get_run_details 和 get_agent_status 轮询结果。
客户端 Gumloop MCP
│ │
│ start_flow_run(flow_id, params) │
│─────────────────────────────────────►│
│ { run_id: "run_abc123", │
│ status: "queued" } │
│◄─────────────────────────────────────│
│ │
│ get_run_details("run_abc123") │ ← 轮询 #1
│─────────────────────────────────────►│
│ { status: "running", progress: 30% }│
│◄─────────────────────────────────────│
│ │
│ get_run_details("run_abc123") │ ← 轮询 #2
│─────────────────────────────────────►│
│ { status: "running", progress: 65% }│
│◄─────────────────────────────────────│
│ │
│ get_run_details("run_abc123") │ ← 轮询 #3
│─────────────────────────────────────►│
│ { status: "completed", │
│ output: {...} } │
│◄─────────────────────────────────────│
│ │
│ 总耗时 = 执行时间 + (轮询次数 × RTT) │
问题：
客户端 Gumloop MCP
│ │
│ start_flow_run(flow_id, params, │
│ stream: true) │
│─────────────────────────────────────►│
│ │
│ SSE stream opened ◄───────────────│
│ event: status | data: "queued" │
│◄─────────────────────────────────────│
│ event: progress | data: {pct: 15} │
│◄─────────────────────────────────────│
│ event: log | data: "Starting..." │
│◄─────────────────────────────────────│
│ event: progress | data: {pct: 50} │
│◄─────────────────────────────────────│
│ event: output | data: {...partial} │
│◄─────────────────────────────────────│
│ event: complete | data: {...final} │
│◄─────────────────────────────────────│
│ │
│ 总耗时 = 执行时间（无轮询开销） │
│ 中间过程完全透明 │
文档已验证 流式响应通过 Server-Sent Events (SSE) 实现，支持以下事件类型：
status — 状态变更（queued → running → completed/failed）progress — 进度百分比更新log — 运行时日志输出output — 中间输出数据（支持大型数据分块传输）complete — 最终完成结果error — 错误信息推断 流式响应可能同时适用于 start_flow_run 和 start_agent 两个异步端点。
这是 Enhanced 升级中最具架构意义的变化。在 v9.11.0 之前，MCP 客户端需要手动配置 Gumloop MCP 提供的工具列表——如果 Gumloop 新增了工具，客户端配置不会自动更新。
v9.11.0 的动态工具发现实现了：
客户端 Gumloop MCP
│ │
│ ① tools/list (MCP 标准协议) │
│─────────────────────────────────────►│
│ │ ② 实时查询当前可用工具
│ │ （基于用户权限和作用域）
│ { │
│ "tools": [ │
│ { │
│ "name": "list_saved_flows", │
│ "description": "...", │
│ "inputSchema": {...} │
│ }, │
│ { │
│ "name": "create_agent", ← [推断] 新增工具
│ "description": "...", │
│ "inputSchema": {...} │
│ } │
│ ] │
│ } │
│◄─────────────────────────────────────│
│ │
│ ③ 客户端自动更新本地工具注册表 │
│ 无需重启 / 手动修改配置 │
文档已验证 核心特性：
tools/list 发现机制推断 动态工具发现与 v9.11.0 的组织级功能（Shared Skills、Agent Templates）存在协同——组织管理员发布的新技能可能通过 MCP 工具的形式对外暴露，客户端自动感知。
Changelog 将此次更新描述为「Enhanced」和「More Powerful」，但截至本文档编写时，官方帮助文档尚未更新以反映 v9.11.0 的新增工具。以下基于三个信号源进行合理推测：
信号 1：官方文档的已知缺口声明
当前文档明确指出以下能力缺失：创建/编辑/删除 Agent、管理 Skill、创建/管理工作簿。
信号 2：v9.11.0 的组织协作主线
v9.11.0 的三个新功能（Shared Skills、Skill Discovery、Agent Templates）都围绕「组织级资源管理」。将组织资源管理能力通过 MCP 暴露给外部系统，是「将 Gumloop 定位为可编程 Agent 基础设施」的自然延伸。
信号 3：MCP 协议的能力边界
MCP 协议不仅支持「工具调用」（Tools），还支持「资源暴露」（Resources）和「提示模板」（Prompts）。Gumloop MCP Enhanced 可能扩展了协议使用范围。
推测新增工具清单：
| 推测工具 | 所属模块 | 推测依据 | 置信度 |
|---|---|---|---|
create_agent | Agent 管理 | 官方文档缺口 + 组织协作主线 | 中高 |
update_agent | Agent 管理 | Agent Templates 功能需要可编程的 Agent 配置 | 中高 |
delete_agent | Agent 管理 | 完整的 CRUD 闭环 | 中 |
list_skills | Skill 管理 | Skill Discovery 的 MCP 投影 | 高 |
create_skill | Skill 管理 | Shared Skills 需要可编程创建入口 | 中高 |
update_skill | Skill 管理 | 版本管理需要更新能力 | 中 |
create_workbook | Workbook 管理 | 官方文档缺口 | 中 |
add_flow_to_workbook | Workbook 管理 | 工作流组织需求 | 低 |
推测新增事件/订阅机制：
推断 流式响应的引入可能伴随着事件订阅机制的发展：
┌──────────────────────────────────────────────────────────┐ │ 现有能力 推测扩展 │ ├──────────────────────────────────────────────────────────┤ │ start_flow_run → 立即返回 run_id start_flow_run │ │ get_run_details → 轮询状态 + stream: true │ │ get_run_history → 历史查询 → SSE 实时推送 │ │ │ │ start_agent → 异步消息 subscribe_flow_events │ │ get_agent_status → 轮询状态 → Webhook 回调注册 │ │ │ │ [无] on_flow_completed │ │ → 事件驱动的触发链 │ └──────────────────────────────────────────────────────────┘
| ID | 触发场景 | 系统行为 | 优先级 |
|---|---|---|---|
| A1 | 外部系统调用 list_saved_flows | 返回当前用户账户下所有已保存的工作流列表，包含名称、ID、描述、最近修改时间 | P0 |
| A2 | 外部系统调用 list_workbooks | 返回工作簿列表及其嵌套的工作流结构（层级关系） | P0 |
| A3 | 外部系统调用 start_flow_run | 触发指定工作流执行，接受可选的输入参数字典。返回运行 ID 和初始状态（queued/running）。支持 stream: true 参数启用 SSE 流式响应 文档已验证 | P0 |
| A4 | 外部系统调用 get_run_details | 返回指定运行的完整信息：当前状态、输出数据、执行日志、开始/结束时间戳 | P0 |
| A5 | 外部系统调用 get_run_history | 返回指定工作簿或保存项的历史运行记录列表，支持时间范围筛选和分页 | P0 |
| A6 | 流式运行时，客户端通过 SSE 接收事件 | 系统按序推送 status、progress、log、output、complete 事件。客户端断连后支持从上次事件 ID 恢复（Last-Event-ID）推断 | P1 |
| ID | 触发场景 | 系统行为 | 优先级 |
|---|---|---|---|
| B1 | 外部系统调用 start_agent | 向指定 Gumloop Agent 发送消息，启动异步交互。返回交互 ID 和初始状态 | P0 |
| B2 | 外部系统调用 get_agent_status | 返回交互状态（in_progress / completed / failed）和 Agent 的响应内容 | P0 |
| B3 推断 | start_agent 使用 stream: true 参数 | 通过 SSE 流式返回 Agent 的思考过程和逐步响应（类似 Web 端的 Streaming 体验） | P1 |
| B4 推断 | Agent 交互完成后，向外部系统发送通知 | 支持 Webhook URL 注册，交互完成时向指定 URL POST 结果。避免客户端持续轮询 | P2 |
| ID | 触发场景 | 系统行为 | 优先级 |
|---|---|---|---|
| C1 | 外部系统调用 search_documentation | 对 Gumloop 文档库执行语义搜索和关键词匹配，返回相关文档条目（标题、摘要、链接） | P0 |
| C2 | 外部系统调用 ask_gummie | 向文档知识库提交自然语言问题，AI 生成带引用来源的回答 | P0 |
| C3 | 管理员调用 get_audit_logs | 返回组织级审计事件列表。非管理员调用返回权限错误。支持时间范围和事件类型筛选 | P0 |
| ID | 触发场景 | 系统行为 | 优先级 |
|---|---|---|---|
| D1 文档已验证 | MCP 客户端发起 tools/list 请求 | 系统动态返回当前用户可见的所有工具列表，基于用户权限和作用域过滤。新增工具自动出现在列表中，无需客户端手动配置 | P0 |
| D2 文档已验证 | 长时间运行的操作（工作流执行、Agent 对话） | 系统通过 SSE 协议推送流式事件（status/progress/log/output/complete），客户端无需轮询 | P0 |
| D3 文档已验证 | 外部应用发起 OAuth 2.0 Authorization Code 授权 | 系统重定向用户到 Gumloop 授权页面，用户确认后回调客户端并签发 Access Token + Refresh Token | P0 |
| D4 文档已验证 | CLI/无浏览器环境发起 Device Code 授权 | 系统返回设备验证码和验证 URL，用户在浏览器中完成授权后，客户端用 Device Code 换取 Access Token | P1 |
| D5 推断 | 外部系统调用 create_agent | 创建新的 Gumloop Agent 实例，接受名称、系统提示词、模型选择、工具配置等参数 | P1 |
| D6 推断 | 外部系统调用 update_agent | 更新已有 Agent 的配置（指令、工具、模型等）。仅 Owner/Editor 可操作 | P1 |
| D7 推断 | 外部系统调用 list_skills | 列出组织中的可用 Skill（含组织共享技能），支持按名称、类别、标签筛选 | P1 |
| D8 推断 | 外部系统调用 create_skill | 创建新的 Skill，定义名称、描述、触发条件和执行逻辑 | P2 |
| D9 推断 | OAuth Token 即将过期 | 系统自动通过 Refresh Token 续期，客户端无感知。Refresh Token 过期或撤销时返回 401 要求重新授权 | P1 |
用户画像： 李铭，29 岁，DevOps 工程师。团队使用 GitHub Actions 作为 CI/CD 平台，希望在每次 Release 发布后自动触发 Gumloop 工作流生成变更日志、更新 Notion 文档、并通知 Slack 频道。之前他通过 Gumloop MCP 的 start_flow_run + get_run_details 轮询实现了基础集成，但轮询逻辑复杂且偶尔超时。
验收标准：
start_flow_run 的 stream: true 参数，通过 SSE 实时获取工作流执行进度error 事件被捕获并触发 GitHub Actions 的失败通知用户画像： 王婷，31 岁，平台工程师。公司有 50+ 个团队在使用 Gumloop Agent，每个团队需要配置自己的专用 Agent。目前 Agent 的创建和配置完全依赖 Gumloop Web UI——她希望构建一个内部管理面板，让团队 Lead 通过内部系统自助创建和配置 Agent，而不是每次都找她手动操作。
验收标准：
create_agent 工具，内部管理面板可以创建新 Agent（名称、提示词、模型、工具配置）update_agent 工具，团队 Lead 可以修改 Agent 配置（添加工具、更新指令）list_skills 工具，管理面板展示组织所有可用 Skill，Lead 可以选择为 Agent 启用特定 Skillcreate_skill 工具，平台工程师可以编程式地将新的组织技能发布到 Skill 库get_audit_logs）记录所有通过 MCP 接口执行的管理操作，满足合规要求| 竞品 | 功能/行为 | 优势 | 劣势 | 洞察/机会 |
|---|---|---|---|---|
| Zapier API / Zapier Platform | 通过 REST API 管理 Zaps、触发执行、获取运行历史。OAuth 2.0 认证、Webhook 触发 | 海量连接器生态（7000+），成熟的 Partner API 和开发者文档 | API 是经典 REST 风格，无流式协议支持。工具集固定——不能通过 Zapier API 动态创建新的连接器类型 | Zapier API 面向「自动化工作流管理」，Gumloop MCP 面向「AI Agent 平台编排」。二者赛道不同但接口设计可参考——Zapier 的 Webhook 触发模式值得 Gumloop 借鉴 |
| n8n API | REST API 覆盖 Workflow CRUD、Execution 管理、Audit Logs。支持 API Key 和 OAuth 2.0 | 开源、自托管选项、完整的 REST API 覆盖所有 CRUD 操作 | 无 MCP 协议支持——API 是 n8n 专有格式，不能直接被 MCP 客户端消费。无动态工具发现 | Gumloop MCP 的差异化在于使用开放协议（MCP）而非私有 API。任何 MCP 兼容客户端都能直接集成，无需学习 Gumloop 特定的 API 格式 |
| LangChain LangServe | 将 LangChain Chain/Agent 部署为 REST API 端点。自动生成 OpenAPI Schema、流式响应支持 | 开发者友好、自动 Schema 生成、与 LangChain 生态无缝集成 | 仅限于 LangChain 生态内的 Agent。无组织管理、权限控制、审计日志等企业功能。非 MCP 协议 | LangServe 解决的是「部署 Agent 为 API」，Gumloop MCP 解决的是「管理 Agent 平台」。LangServe 是单 Agent 的 API 化，Gumloop MCP 是平台级的编排接口 |
| OpenAI Assistants API | 创建/管理 Assistant、Thread、Run。流式响应（SSE）、Function Calling、File Search | 模型能力顶尖、开发者生态庞大、流式响应成熟 | 仅限于 OpenAI 模型。Assistant 管理 API 和工具调用 API 是两套体系。无工作流编排、无文档搜索、无审计日志 | Assistants API 是 Agent 引擎，Gumloop MCP 是 Agent 平台。前者管理「一个 Assistant」，后者管理「组织的 Agent + Workflow + 文档」体系 |
| GitHub Actions API | REST API 管理 Workflow Runs、Jobs、Logs。支持 OAuth 2.0 / GitHub App 认证。Webhook 事件推送 | 事件驱动（Webhook）、成熟的 CI/CD 生态、Actions Marketplace 分发 | 仅限 CI/CD 场景的 Workflow 管理。无 AI Agent 概念、无文档搜索、无 MCP 协议支持 | GitHub Actions 的工作流触发和监控模式与 Gumloop MCP 高度相似——Gumloop 可以借鉴 Webhook 事件推送模式来替代轮询 |
| 漏斗阶段 | 事件名称 | 触发条件 | 指标/KPI | 优先级 |
|---|---|---|---|---|
| 采用 | mcp_tools_list_called | MCP 客户端发起 tools/list 请求 | 动态工具发现调用量、独立客户端数 | P0 |
| 采用 | mcp_oauth_auth_initiated | 外部应用发起 OAuth 2.0 授权请求 | OAuth 授权发起量（Authorization Code vs Device Code 分布） | P0 |
| 采用 | mcp_oauth_token_issued | 系统签发 Access Token | Token 签发量、平均 Token 有效期 | P1 |
| 采用 | mcp_oauth_token_refreshed | 客户端使用 Refresh Token 续期 | 自动续期成功率、Refresh Token 失效率 | P1 |
| 执行 | mcp_tool_called | 任意 MCP 工具被调用 | 总调用量、按工具名分布、按客户端来源分布 | P0 |
| 执行 | mcp_stream_started | 客户端请求流式响应 (stream: true) | 流式连接建立量、流式使用率（stream: true / 总调用） | P0 |
| 执行 | mcp_stream_event_sent | SSE 事件推送成功 | 事件类型分布（status/progress/log/output/complete/error）、平均事件间隔 | P1 |
| 执行 | mcp_stream_disconnected | SSE 流异常断连 | 断连率、平均流持续时间、断连原因分布 | P1 |
| 质量 | mcp_tool_call_error | MCP 工具调用返回错误 | 错误率（按工具名）、错误类型分布（认证失败/权限不足/参数错误/服务器内部错误） | P0 |
| 影响 | mcp_active_client_count | 去重统计活跃 MCP 客户端数 | 日活/周活 MCP 客户端数、客户端类型分布 | P0 |
| 推断 | mcp_resource_created | 通过 MCP 接口创建平台资源（Agent/Skill/Workbook） | MCP 渠道创建量 vs Web UI 创建量比例 | P2 |
| 阶段 | 时间线 | 里程碑 | 状态 |
|---|---|---|---|
| Phase 1 — 基础 MCP 接口 | v8.x | 10 个工具上线：工作流管理（5）+ Agent 交互（2）+ 文档管理（3）。API Key / Bearer Token 认证。同步请求-响应模式 | 已发布 |
| Phase 2 — 协议增强 | v9.11.0 | 动态工具发现（tools/list）。流式响应（SSE: status/progress/log/output/complete）。OAuth 2.0 + Device Code 认证。Token 自动刷新 |
已发布（本文档） |
| Phase 3 — 平台可编程化 | v10.x | 推断 扩展工具清单至 18-25 个：新增 Agent CRUD、Skill CRUD、Workbook 管理。Webhook 事件推送（on_flow_completed、on_agent_response）。MCP Resources 暴露（以 Resource 形式提供工作流列表、Agent 状态等只读数据） |
规划中 |
| Phase 4 — 实时事件平台 | v11.x | 推断 完整的事件驱动架构：工作流事件流、Agent 对话事件流、组织变更事件流。MCP 双向流（WebSocket 升级）。事件驱动的 Webhook 注册与管理。第三方 MCP 客户端认证 Marketplace（类似 Slack App Directory） | 探索中 |
由 Claude 竞品情报系统生成 · 评分 8/13（战略2 护城河2 用户2 复杂度1 创新1） · v9.11.0 "Huntsville"