Activepieces 触发器机制深度解析TriggerSource、四种策略与轮询去重实战【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces导读本篇文章以 Activepieces 开源仓库中 brain/knowledge/flows-execution/triggers.md 为核心骨架结合packages/server/api/src/app/trigger/下的服务端源码与测试用例系统讲解触发器Triggers如何定义并驱动一个 Flow 的启动包括POLLING、WEBHOOK、APP_WEBHOOK、MANUAL四种策略的注册、事件捕获、测试与去重流程以及TriggerSource记录与启用/停用副作用BullMQ 调度、外部 Webhook 注册的底层实现。读完本文你将掌握 Activepieces 触发器从启用、运行到停用的完整生命周期理解轮询去重的 Redis 实现原理并能规避 TIMEBASED 轮询与 cron 表达式等高频踩坑点。触发器在 Activepieces 中的定位在 Activepieces 中触发器Trigger定义了 Flow 何时以及如何启动。模块整体负责四件事注册registration、事件捕获event capture、测试testing与去重deduplication。每个已启用的触发器都会被持久化为一条TriggerSource记录并由服务端驱动启用/停用副作用——包括 BullMQ 调度任务和外部 Webhook 的注册与注销。从 packages/server/api/src/app/trigger/trigger-source/flow-trigger-side-effect.ts 可以看到触发器启停的核心入口是flowTriggerSideEffect它由triggerSourceService在启用enable和停用disable时调用按触发器类型分派到四种处理函数switch (pieceTrigger.type) { case TriggerStrategy.APP_WEBHOOK: return handleAppWebhookTrigger(...) case TriggerStrategy.WEBHOOK: return handleWebhookTrigger(...) case TriggerStrategy.POLLING: return handlePollingTrigger(...) case TriggerStrategy.MANUAL: return { scheduleOptions: undefined } }核心实体与枚举TriggerStrategy四种触发策略策略枚举定义于 packages/core/piece-types/src/lib/trigger.tsexport enum TriggerStrategy { POLLING POLLING, WEBHOOK WEBHOOK, APP_WEBHOOK APP_WEBHOOK, MANUAL MANUAL, }POLLING按 cron 或滚动间隔轮询外部 API由 BullMQ repeating job 驱动 Redis 去重。WEBHOOK外部服务主动推送事件到 Activepieces 的 Webhook URL。APP_WEBHOOK应用原生事件如 Slack、GitHub经AppEventRouting路由表定向到对应 Flow。MANUAL仅由用户手动触发不产生任何调度与注册副作用。TriggerSource持久化的触发器链接TriggerSource是 Flow 版本与其已注册触发器之间的持久化链接记录。关键约束见 trigger-source-service.ts在停用时软删除softDelete每个(projectId, flowId, simulate)组合唯一——这正是模拟源与生产源可以共存的前提。启用时服务会先查询已有记录含已删除记录withDeleted: true移除旧的 repeating job软删除旧记录再写入一条新记录并执行 enable 副作用若 enable 失败则回滚软删除刚写入的记录对应源码中Rolled back trigger source after enable failure的分支。TriggerEvent测试数据载体TriggerEvent是捕获到的 payload以 File 引用形式存储fileId供构建器builder选择测试数据。sourceName的格式为pieceNameversion:triggerName例如gmail0.5:new_email。生成逻辑位于 trigger-event.service.tspieceName${getPieceMajorAndMinorVersion(pieceVersion)}:${triggerName}。事件 payload 通过fileService保存为 JSON 文件FileType.TRIGGER_EVENT_FILE读取时再反序列化返回实现大 payload 与列表分页的解耦。AppEventRoutingAPP_WEBHOOK 路由表AppEventRouting是 APP_WEBHOOK 的路由表将(appName, event, identifierValue)映射到具体 Flow。启用时handleAppWebhookTrigger会遍历引擎返回的listeners逐条调用appEventRoutingService.createListeners建立路由停用时调用deleteListeners批量删除。启用与停用四种策略的副作用enable流程flow-trigger-side-effect.ts先向引擎提交TriggerHookType.ON_ENABLE钩子经userInteractionWatcher投递到 worker 执行再按策略创建副作用策略启用副作用停用副作用POLLING创建 BullMQ repeating job调度由 piece 的setSchedule决定jobQueue.removeRepeatingJobWEBHOOK提交 ON_ENABLE 钩子注册若 piece 声明WebhookRenewStrategy.CRON另建 renewal repeating job提交 ON_DISABLE 钩子注销有 renewal job 则一并移除APP_WEBHOOK依据引擎返回的 listeners 创建路由记录deleteListeners删除路由MANUAL无副作用无副作用POLLING 的调度决策cron 与 intervalhandlePollingTrigger同上文件 L183-L208展示了默认调度逻辑const pollIntervalMinutes system.getNumberOrThrow(AppSystemProp.TRIGGER_DEFAULT_POLL_INTERVAL) const defaultScheduleOptions: ScheduleOptions { type: TriggerSourceScheduleType.INTERVAL, intervalMs: pollIntervalMinutes * 60_000, } const scheduleOptions engineHelperResponse.response?.scheduleOptions ?? defaultScheduleOptionspiece 的setSchedule可以提供cronCRON_EXPRESSION或滚动间隔INTERVAL→ BullMQevery当 piece 未提供任何调度时默认使用滚动间隔间隔为TRIGGER_DEFAULT_POLL_INTERVAL即环境变量AP_TRIGGER_DEFAULT_POLL_INTERVAL分钟默认值 5 分钟。该环境变量在 system-props.ts 中声明。WEBHOOK 的续期任务handleWebhookTriggerL151-L181支持WebhookRenewStrategy.CRON当 piece 的renewConfiguration声明了 cron 续期策略时服务端会注册一个JobType.REPEATING的RENEW_WEBHOOK任务按renewConfiguration.cronExpressionUTC 时区周期性地通过 ON_RENEW 钩子重新注册即将过期的 Webhook。停用幂等与容错disableL74-L127会先提交 ON_DISABLE 钩子且支持ignoreError容错若开启disable 失败仅记录Ignored error during trigger disable日志而不会抛出随后按策略清理 job 与路由。triggerSourceService.disable在找不到 TriggerSource 时直接返回保证幂等。测试触发器SIMULATION 与 TEST_FUNCTION测试入口为testTriggerServicetest-trigger-service.ts全程使用Redis 分布式锁key 为${flowId}-test-trigger超时 120 秒防止并发测试SIMULATION创建一条simulatetrue的 TriggerSource真正注册一个模拟触发器并收集真实事件再次点击停止测试则走cancel路径ignoreErrortrue地停用模拟源。模拟源与生产源因(projectId, flowId, simulate)唯一约束而互不干扰。TEST_FUNCTION向引擎提交TriggerHookType.TEST钩子把返回的output数组逐个保存为 TriggerEvent保存前先清空该 Flow 的旧测试事件供构建器事件选择器分页浏览。轮询去重Redis INCR 30 秒 TTL轮询场景的去重由 dedupe-service.ts 实现const DUPLICATE_RECORD_EXPIRATION_SECONDS 30 const key ${flowVersionId}:${dedupeKeyValue} const value await incrementInRedis(key, DUPLICATE_RECORD_EXPIRATION_SECONDS) return value 1流程要点从 payload 中提取__DEDUPE_KEY_PROPERTY作为去重键以${flowVersionId}:${dedupeKeyValue}为 Redis key 执行INCR首次出现时附带 30 秒 TTLINCR返回值 1 说明是重复数据予以过滤通过去重的 payload 在返回前会剥离去重键字段removeDedupeKey将其置为undefined确保下游步骤看到的是干净数据。关键 Gotchas必须掌握的三个深坑1. 重新发布保留轮询检查点isRepublish重新发布一个运行中的 Flow 会执行onDisable(old) → onEnable(new)这曾导致lastPoll/lastItem被重置为当前时间静默丢弃发布间隙产生的事件。修复方案是isRepublish标记只有满足以下全部条件时flowService.update才会置isRepublishtrue对已 ENABLED的 Flow 执行LOCK_AND_PUBLISH且触发器未变化——同一 piece、同一 trigger 名、且settings.input深比较相等见flowPublishUtils.isSameTrigger测试覆盖于 flow-publish-utils.test.ts。该标记随 ON_ENABLE job 一路穿透到ExecuteTriggerOperation与触发器上下文context.isRepublishpollingHelper.onEnable据此保留已有检查点。全新启用、手动关→开、更换触发器、修改触发器任意 props仍会重置为当前时间。为什么 props 检查不是锦上添花因为跨 props 变更保留检查点会让检查点指向一个已不再轮询的资源而pollingHelper.poll在获取的页面中找不到LAST_ITEM对应的 idfindIndex → -1时会把它当作无检查点从而全量重发每个 item。不使用pollingHelper的自定义轮询触发器可读取context.isRepublish自行接入。2. 缺失时间戳会永久杀死 TIMEBASED 轮询触发器pollingHelper.poll用items.reduce((acc, i) Math.max(acc, i.epochMilliSeconds), lastPoll)推进检查点而Math.max(n, NaN)的结果是NaN。因此只要有一个 item 的日期字段从未被请求dayjs(undefined).valueOf()→NaNlastPoll就会被写入NaN此后每次轮询都按 NaN过滤恒为 false触发器静默地永不触发且全程无任何报错。两道防护缺一不可在 API 的fields/select 掩码中显式请求日期字段在映射到epochMilliSeconds之前丢弃日期不可用的 item。注意过滤必须检查原始值不能只依赖.isValid()——因为dayjs(undefined)会被解释为当前时间且报告 valid。3. 轮询时间戳可能由客户端提供未来时间戳是致命的以 Google Drive 为例上传时modifiedTime取自本地文件 mtime而非上传时刻因此它可能早于createdTime若上传者机器时钟偏快甚至可能超前数年。TIMEBASED 水位线是max(epochMilliSeconds)一条未来日期的记录会把lastPoll推到未来导致触发器在墙钟追上之前什么都不发。正确做法扣住hold back时间戳晚于Date.now()的 item——它们在时钟越过该时间点后自然触发一次。切勿通过钳制水位线来解决钳制会让同一行数据在每次轮询中反复重发永远无法收敛。触发器健康统计triggerRunStatstrigger-run-stats.ts以 Redis 计数跟踪每次轮询运行的成败Redis key 格式trigger_run:{platformId}:{pieceName}:{date}:{status}其中 status 归一化为COMPLETED/FAILED每次写入时刷新14 天 TTLgetStatusReport通过 SCAN 聚合出按 piece、按天统计的成功/失败数展示于 Cloud 版的 Platform Admin。版本与能力边界四种触发策略在 CE / EE / Cloud 均可用Cloud 额外在 Platform Admin 中展示触发器健康统计。*/Xcron 表达式不等于每 X 分钟——它表示能被 X 整除的分钟因此在 X 30 时会在 :00 和 :X 双重触发X 不能整除 60 时还会不均匀地出现间隙。需要滚动间隔请使用INTERVAL/intervalMscron 只留给墙钟时间表该问题曾影响默认轮询调度直至 GIT-1632 修复。关键源码索引入口flowTriggerSideEffect见 trigger-source/flow-trigger-side-effect.ts由 trigger-source-service.ts 在启用/停用时调用trigger-source/TriggerSource CRUD、实体与各策略的启停副作用trigger-events/TriggerEvent 存储、实体与查询端点test-trigger/模拟与测试函数两种模式及其端点app-event-routing/APP_WEBHOOK 路由表与实体trigger-run/按平台统计触发器健康数据与统计端点dedupe-service.ts基于 Redis 的轮询去重trigger.module.ts模块注册packages/core/shared/src/lib/automation/trigger/TriggerSource schema、TriggerStrategy 枚举、handshake 与调度选项packages/web/src/app/builder/test-step/构建器测试面板、事件选择器与手动 Webhook 测试对话框packages/web/src/app/builder/flow-canvas/触发器节点组件及其上方的添加触发器按钮。相关测试用例可继续阅读 polling-helper.test.ts 与 flow-publish-utils.test.ts 深入验证上述行为。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Activepieces 触发器机制深度解析：TriggerSource、四种策略与轮询去重实战
Activepieces 触发器机制深度解析TriggerSource、四种策略与轮询去重实战【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces导读本篇文章以 Activepieces 开源仓库中 brain/knowledge/flows-execution/triggers.md 为核心骨架结合packages/server/api/src/app/trigger/下的服务端源码与测试用例系统讲解触发器Triggers如何定义并驱动一个 Flow 的启动包括POLLING、WEBHOOK、APP_WEBHOOK、MANUAL四种策略的注册、事件捕获、测试与去重流程以及TriggerSource记录与启用/停用副作用BullMQ 调度、外部 Webhook 注册的底层实现。读完本文你将掌握 Activepieces 触发器从启用、运行到停用的完整生命周期理解轮询去重的 Redis 实现原理并能规避 TIMEBASED 轮询与 cron 表达式等高频踩坑点。触发器在 Activepieces 中的定位在 Activepieces 中触发器Trigger定义了 Flow 何时以及如何启动。模块整体负责四件事注册registration、事件捕获event capture、测试testing与去重deduplication。每个已启用的触发器都会被持久化为一条TriggerSource记录并由服务端驱动启用/停用副作用——包括 BullMQ 调度任务和外部 Webhook 的注册与注销。从 packages/server/api/src/app/trigger/trigger-source/flow-trigger-side-effect.ts 可以看到触发器启停的核心入口是flowTriggerSideEffect它由triggerSourceService在启用enable和停用disable时调用按触发器类型分派到四种处理函数switch (pieceTrigger.type) { case TriggerStrategy.APP_WEBHOOK: return handleAppWebhookTrigger(...) case TriggerStrategy.WEBHOOK: return handleWebhookTrigger(...) case TriggerStrategy.POLLING: return handlePollingTrigger(...) case TriggerStrategy.MANUAL: return { scheduleOptions: undefined } }核心实体与枚举TriggerStrategy四种触发策略策略枚举定义于 packages/core/piece-types/src/lib/trigger.tsexport enum TriggerStrategy { POLLING POLLING, WEBHOOK WEBHOOK, APP_WEBHOOK APP_WEBHOOK, MANUAL MANUAL, }POLLING按 cron 或滚动间隔轮询外部 API由 BullMQ repeating job 驱动 Redis 去重。WEBHOOK外部服务主动推送事件到 Activepieces 的 Webhook URL。APP_WEBHOOK应用原生事件如 Slack、GitHub经AppEventRouting路由表定向到对应 Flow。MANUAL仅由用户手动触发不产生任何调度与注册副作用。TriggerSource持久化的触发器链接TriggerSource是 Flow 版本与其已注册触发器之间的持久化链接记录。关键约束见 trigger-source-service.ts在停用时软删除softDelete每个(projectId, flowId, simulate)组合唯一——这正是模拟源与生产源可以共存的前提。启用时服务会先查询已有记录含已删除记录withDeleted: true移除旧的 repeating job软删除旧记录再写入一条新记录并执行 enable 副作用若 enable 失败则回滚软删除刚写入的记录对应源码中Rolled back trigger source after enable failure的分支。TriggerEvent测试数据载体TriggerEvent是捕获到的 payload以 File 引用形式存储fileId供构建器builder选择测试数据。sourceName的格式为pieceNameversion:triggerName例如gmail0.5:new_email。生成逻辑位于 trigger-event.service.tspieceName${getPieceMajorAndMinorVersion(pieceVersion)}:${triggerName}。事件 payload 通过fileService保存为 JSON 文件FileType.TRIGGER_EVENT_FILE读取时再反序列化返回实现大 payload 与列表分页的解耦。AppEventRoutingAPP_WEBHOOK 路由表AppEventRouting是 APP_WEBHOOK 的路由表将(appName, event, identifierValue)映射到具体 Flow。启用时handleAppWebhookTrigger会遍历引擎返回的listeners逐条调用appEventRoutingService.createListeners建立路由停用时调用deleteListeners批量删除。启用与停用四种策略的副作用enable流程flow-trigger-side-effect.ts先向引擎提交TriggerHookType.ON_ENABLE钩子经userInteractionWatcher投递到 worker 执行再按策略创建副作用策略启用副作用停用副作用POLLING创建 BullMQ repeating job调度由 piece 的setSchedule决定jobQueue.removeRepeatingJobWEBHOOK提交 ON_ENABLE 钩子注册若 piece 声明WebhookRenewStrategy.CRON另建 renewal repeating job提交 ON_DISABLE 钩子注销有 renewal job 则一并移除APP_WEBHOOK依据引擎返回的 listeners 创建路由记录deleteListeners删除路由MANUAL无副作用无副作用POLLING 的调度决策cron 与 intervalhandlePollingTrigger同上文件 L183-L208展示了默认调度逻辑const pollIntervalMinutes system.getNumberOrThrow(AppSystemProp.TRIGGER_DEFAULT_POLL_INTERVAL) const defaultScheduleOptions: ScheduleOptions { type: TriggerSourceScheduleType.INTERVAL, intervalMs: pollIntervalMinutes * 60_000, } const scheduleOptions engineHelperResponse.response?.scheduleOptions ?? defaultScheduleOptionspiece 的setSchedule可以提供cronCRON_EXPRESSION或滚动间隔INTERVAL→ BullMQevery当 piece 未提供任何调度时默认使用滚动间隔间隔为TRIGGER_DEFAULT_POLL_INTERVAL即环境变量AP_TRIGGER_DEFAULT_POLL_INTERVAL分钟默认值 5 分钟。该环境变量在 system-props.ts 中声明。WEBHOOK 的续期任务handleWebhookTriggerL151-L181支持WebhookRenewStrategy.CRON当 piece 的renewConfiguration声明了 cron 续期策略时服务端会注册一个JobType.REPEATING的RENEW_WEBHOOK任务按renewConfiguration.cronExpressionUTC 时区周期性地通过 ON_RENEW 钩子重新注册即将过期的 Webhook。停用幂等与容错disableL74-L127会先提交 ON_DISABLE 钩子且支持ignoreError容错若开启disable 失败仅记录Ignored error during trigger disable日志而不会抛出随后按策略清理 job 与路由。triggerSourceService.disable在找不到 TriggerSource 时直接返回保证幂等。测试触发器SIMULATION 与 TEST_FUNCTION测试入口为testTriggerServicetest-trigger-service.ts全程使用Redis 分布式锁key 为${flowId}-test-trigger超时 120 秒防止并发测试SIMULATION创建一条simulatetrue的 TriggerSource真正注册一个模拟触发器并收集真实事件再次点击停止测试则走cancel路径ignoreErrortrue地停用模拟源。模拟源与生产源因(projectId, flowId, simulate)唯一约束而互不干扰。TEST_FUNCTION向引擎提交TriggerHookType.TEST钩子把返回的output数组逐个保存为 TriggerEvent保存前先清空该 Flow 的旧测试事件供构建器事件选择器分页浏览。轮询去重Redis INCR 30 秒 TTL轮询场景的去重由 dedupe-service.ts 实现const DUPLICATE_RECORD_EXPIRATION_SECONDS 30 const key ${flowVersionId}:${dedupeKeyValue} const value await incrementInRedis(key, DUPLICATE_RECORD_EXPIRATION_SECONDS) return value 1流程要点从 payload 中提取__DEDUPE_KEY_PROPERTY作为去重键以${flowVersionId}:${dedupeKeyValue}为 Redis key 执行INCR首次出现时附带 30 秒 TTLINCR返回值 1 说明是重复数据予以过滤通过去重的 payload 在返回前会剥离去重键字段removeDedupeKey将其置为undefined确保下游步骤看到的是干净数据。关键 Gotchas必须掌握的三个深坑1. 重新发布保留轮询检查点isRepublish重新发布一个运行中的 Flow 会执行onDisable(old) → onEnable(new)这曾导致lastPoll/lastItem被重置为当前时间静默丢弃发布间隙产生的事件。修复方案是isRepublish标记只有满足以下全部条件时flowService.update才会置isRepublishtrue对已 ENABLED的 Flow 执行LOCK_AND_PUBLISH且触发器未变化——同一 piece、同一 trigger 名、且settings.input深比较相等见flowPublishUtils.isSameTrigger测试覆盖于 flow-publish-utils.test.ts。该标记随 ON_ENABLE job 一路穿透到ExecuteTriggerOperation与触发器上下文context.isRepublishpollingHelper.onEnable据此保留已有检查点。全新启用、手动关→开、更换触发器、修改触发器任意 props仍会重置为当前时间。为什么 props 检查不是锦上添花因为跨 props 变更保留检查点会让检查点指向一个已不再轮询的资源而pollingHelper.poll在获取的页面中找不到LAST_ITEM对应的 idfindIndex → -1时会把它当作无检查点从而全量重发每个 item。不使用pollingHelper的自定义轮询触发器可读取context.isRepublish自行接入。2. 缺失时间戳会永久杀死 TIMEBASED 轮询触发器pollingHelper.poll用items.reduce((acc, i) Math.max(acc, i.epochMilliSeconds), lastPoll)推进检查点而Math.max(n, NaN)的结果是NaN。因此只要有一个 item 的日期字段从未被请求dayjs(undefined).valueOf()→NaNlastPoll就会被写入NaN此后每次轮询都按 NaN过滤恒为 false触发器静默地永不触发且全程无任何报错。两道防护缺一不可在 API 的fields/select 掩码中显式请求日期字段在映射到epochMilliSeconds之前丢弃日期不可用的 item。注意过滤必须检查原始值不能只依赖.isValid()——因为dayjs(undefined)会被解释为当前时间且报告 valid。3. 轮询时间戳可能由客户端提供未来时间戳是致命的以 Google Drive 为例上传时modifiedTime取自本地文件 mtime而非上传时刻因此它可能早于createdTime若上传者机器时钟偏快甚至可能超前数年。TIMEBASED 水位线是max(epochMilliSeconds)一条未来日期的记录会把lastPoll推到未来导致触发器在墙钟追上之前什么都不发。正确做法扣住hold back时间戳晚于Date.now()的 item——它们在时钟越过该时间点后自然触发一次。切勿通过钳制水位线来解决钳制会让同一行数据在每次轮询中反复重发永远无法收敛。触发器健康统计triggerRunStatstrigger-run-stats.ts以 Redis 计数跟踪每次轮询运行的成败Redis key 格式trigger_run:{platformId}:{pieceName}:{date}:{status}其中 status 归一化为COMPLETED/FAILED每次写入时刷新14 天 TTLgetStatusReport通过 SCAN 聚合出按 piece、按天统计的成功/失败数展示于 Cloud 版的 Platform Admin。版本与能力边界四种触发策略在 CE / EE / Cloud 均可用Cloud 额外在 Platform Admin 中展示触发器健康统计。*/Xcron 表达式不等于每 X 分钟——它表示能被 X 整除的分钟因此在 X 30 时会在 :00 和 :X 双重触发X 不能整除 60 时还会不均匀地出现间隙。需要滚动间隔请使用INTERVAL/intervalMscron 只留给墙钟时间表该问题曾影响默认轮询调度直至 GIT-1632 修复。关键源码索引入口flowTriggerSideEffect见 trigger-source/flow-trigger-side-effect.ts由 trigger-source-service.ts 在启用/停用时调用trigger-source/TriggerSource CRUD、实体与各策略的启停副作用trigger-events/TriggerEvent 存储、实体与查询端点test-trigger/模拟与测试函数两种模式及其端点app-event-routing/APP_WEBHOOK 路由表与实体trigger-run/按平台统计触发器健康数据与统计端点dedupe-service.ts基于 Redis 的轮询去重trigger.module.ts模块注册packages/core/shared/src/lib/automation/trigger/TriggerSource schema、TriggerStrategy 枚举、handshake 与调度选项packages/web/src/app/builder/test-step/构建器测试面板、事件选择器与手动 Webhook 测试对话框packages/web/src/app/builder/flow-canvas/触发器节点组件及其上方的添加触发器按钮。相关测试用例可继续阅读 polling-helper.test.ts 与 flow-publish-utils.test.ts 深入验证上述行为。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考