n8n Agent 开发者的多操作统一工具节点

在 n8n 上构建 AI Agent 的开发者想把 Gmail、Slack、Notion、GitHub 等 SaaS 服务作为 Agent 的工具，但每个操作（读取、发送、草稿）都必须单独添加一个工具节点，导致画布臃肿、凭据链接冗余、工作流僵化。正如社区功能请求所述："connecting service nodes as tools to an AI Agent requires adding separate tool nodes for every individual operation"。此外，n8n 官方节点对 API 能力的覆盖也不完整——例如 Google Workspace Admin 节点只暴露少数用户属性，设置 org unit、recovery email、职称或办公地点时只能退回手写 HTTP Request，手动配置 OAuth2 凭据、手写 JSON body，且没有字段验证。

使用 n8n 构建 AI Agent 并集成 SaaS 服务的自动化开发者/独立开发者，以及用 n8n 做 Google Workspace 用户配置的 IT 自动化管理员。市场规模定性看：n8n 社区活跃且 AI Agent 工作流是其增长方向，但两条信号均来自单一社区、零互动，需求广度待验证。

构建一个面向 n8n 的动态多操作工具节点/工具层：

• 统一 Schema 动态工具选择：一个节点内声明服务的全部可用操作，由 Agent 根据用户意图动态调用，而非每个操作一个节点
• 凭据复用：同一服务的所有操作共享一套凭据连接，消除冗余链接
• 渐进覆盖高频服务：优先做 Gmail、Slack、Notion、GitHub 这几个信号中点名的服务
• 字段级 API 覆盖：参考 Google Directory API 的完整可写属性（org unit path、recovery email/phone、organizations、addresses 等），避免官方节点字段缺失导致用户退回 HTTP Request AI 的角色：LLM Agent 通过读取统一 Schema 自主决定调用哪个操作，替代人工预先编排每个操作的节点连接。

信号显示用户已开始在解决思路中对标 MCP、Composio 等统一工具协议/产品，说明 Agent 工具生态正从"每个操作一个节点"向"统一 Schema 动态选择"的范式转移，n8n 官方尚未提供原生支持，存在第三方补位窗口。

首版只做一个覆盖 3-5 个高频服务（Gmail、Slack、Notion、GitHub）的 n8n 自定义节点，支持按统一 Schema 动态选择读取/发送/草稿等操作，复用一套凭据。不做：自有云服务托管、通用 MCP 服务器市场、Google Workspace Admin 节点字段扩展（可作为后续 PR 贡献）。

平台依赖：产品完全构建在 n8n 生态之上，n8n 官方若自行实现动态工具节点（信号显示已有用户提出该请求），第三方方案可能被吞并。竞争风险：Composio 和 MCP 已提供统一工具层思路，且被用户直接点名，先发者可能占据生态位。维护成本：需持续跟进各 SaaS API 的 Schema 变更。付费意愿：目标用户是开源自动化社区开发者，两条信号均无付费意愿，商业化路径不明。证据薄弱：两条请求均为零评论、pain 评级 3（中等），需求强度未经社区验证。