给 Agent 装工具这件事，最近半年变得很容易：写一段 JSON，接一个 MCP server，模型就会调了。真到要把一件业务跑完，卡点往往不在"有没有这个工具"，而在三件很土的事——账号在谁手里、失败重试谁来管、中间要不要人点一下。
Activepieces 是一个开源的 Zapier 替代品，它把这三件事放在了流程层，然后顺手做了一件对 Agent 很关键的事：所有连接器（他们叫 piece）都能直接暴露成 MCP 工具。仓库 activepieces/activepieces 截至 2026-11-14 约 25,500 star、4.5k fork、61,889 次提交，11 月 14 日仍有提交；项目从 2022 年 12 月就开始了，不是新发布。
它的结构：piece 是 npm 包，流程是画布
Activepieces 的核心抽象是 piece：一个用 TypeScript 写的 npm 包，声明某个服务的认证方式、动作和触发器。官方强调所有 piece 都是开源的、发布到 npmjs，其中约 60% 由社区贡献。正因为 piece 是标准化的包，"写完自动变成 MCP 工具"才成立——不用为每个服务单独维护一套 MCP 适配层。
这个数字在两个地方口径不同：README 写的是"280+ 个 piece 可作为 MCP 使用"，仓库 About 写的是"约 400 个 MCP server"。两个数都是官方口径，取哪个都行，但别把它们当成同一时间的精确计数。
画布这层提供的是编排能力：循环、分支、自动重试、HTTP 请求、在 Code 步骤里跑 npm 包、流程版本化。还有两个容易被忽略、但对 Agent 场景特别有用的东西：
- 人工介入（human in the loop）：可以让流程停一段时间，或者要求审批后才继续。官方说这本身就是用 piece 框架搭出来的 piece，所以你能自己造类似的节点。
- 人输入的入口：内置 Chat Interface 和 Form Interface 两种触发方式，人能直接把内容喂进流程。
为什么这算"工作流"，而不是又一个工具包
把 Agent 当调用方看，一个业务流程里最难的部分从来不是调用本身：
| 环节 | 纯 MCP 工具的做法 | 放在工作流层的做法 |
|---|---|---|
| 认证 | 每个 server 各自配 key 或 OAuth，散落在各客户端配置里 | 连接器统一存凭证，流程内复用 |
| 失败 | 模型自己判断要不要重试，重试几次没准 | 节点级自动重试、分支兜底 |
| 审批 | 模型要么直接做，要么停下来问人（往往问得不是地方） | 流程显式停在审批节点，等人放行 |
| 可追溯 | 只留对话记录 | 每次运行有记录，流程有版本 |
换句话说，它卖的不是"280 个工具"，而是"这 280 个工具背后的账号、重试和审批已经有人替你管了"。Agent 只负责决定调哪个，剩下的确定性工作交给流程引擎——这和我之前写的 OpenCodeReview 那条"确定性交给代码、判断交给模型"是同一个分工思路。
接法
对 Agent 客户端来说，它就是一组 MCP server。按官方说法，可以在 Claude Desktop、Cursor、Windsurf 里直接用；自托管则走 Docker Compose 或它们文档里的安装方式，官方强调可以网络隔离部署，数据和凭证留在自己这边。
对开发者来说，加一个连接器就是写一个 piece：TypeScript、有热重载、发布到 npm 后即可被流程引用。这条路比"给每个服务写一个 MCP server"省事，因为认证、分页、错误处理在 piece 框架里是统一约定。
许可这件事，别只看徽章
README 的徽章写 MIT，但许可证是分开的：社区版是 MIT，企业功能走商业许可，企业代码在 packages/ee/LICENSE。这也是 GitHub API 把它标成 NOASSERTION 而不是 MIT 的原因——仓库里不止一种许可。
实际影响：自己部署、自己改社区版，没问题；想用 SSO、细粒度权限、品牌定制这类企业功能，要看商业条款。写选型文档时把这条写清楚，比只写"MIT 开源"有用。
四个真实的坑
- 它不是新项目。2022 年底就开始了，2026 年还在高频提交。写"刚开源"是错的。
- 连接器数量不等于质量。280 多个 piece 里，热门服务维护得好，冷门服务可能只是能跑通基本动作。选之前先看那个 piece 最近的提交。
- 自托管是要运维的。数据库、worker、升级、备份都得自己管。官方提供的 Docker 部署能降低门槛，但没有消除它。
- 每个 MCP 工具背后是一个真账号。把 280 个连接器全开给一个 Agent，等于把这些账号的操作权一起给了它。先用
allow式的白名单思路，只开当下需要的几个。
该信多少
- 本文读了仓库 README、许可说明和项目元数据，没有部署、没有接 MCP、没有跑流程。
- 约 25,500 星、4.5k fork、61,889 次提交、487 个 open issue、448 个 open PR 均为 2026-11-14 抓取，会变。
- "280+" 与 "约 400" 两个数字都来自官方，未逐一核对；"60% 由社区贡献"同样是官方说法。
- 它解决的是编排与凭证，不解决"这个连接器背后服务本身好不好用"。
一句话判断
如果你已经在用 MCP，但每次都要手工给每个 server 配 key、失败了靠模型猜、审批靠人在对话里喊停，Activepieces 这类东西值得认真看：它把不确定的判断留给模型，把确定的认证、重试、审批收进流程。代价是要接受一套自托管的工作流系统，以及"工具多不等于每个都能打"的现实。
来源
- activepieces/activepieces（README、piece 框架、许可说明；约 25,500 星，2026-11-14 读取）
- Activepieces 连接器目录（官方 piece 列表）
- Activepieces 文档（部署与自托管）
说明：本文为官方文档解读，未部署或运行 Activepieces；星数与提交数为 2026-11-14 抓取。社区版 MIT、企业功能商业许可，两者不同。
——诺谱