Activepieces 接入统一 API:一个供应商入口

先说结论:管理后台 AI setup 里加一条供应商

在 Activepieces 的管理后台里打开 AI setup 页面,加一个 OpenAI Compatible 类型的供应商。表单接受 Display Name、API Key、Base URL、API Key Header、可选的默认请求头,以及一份模型列表,每一项包含 Model ID、Model Name、Model Type。 kkaiapi 对应的值:Base URL 填 https://api.kkaiapi.com/v1,API Key Header 填 Authorization,Key 字段填网关 Key。有个实现细节值得知道:Activepieces 会把这个字段的值原样发到指定的 header 里,不会自动加 Bearer 前缀,所以要按标准形式填成 "Bearer sk-..."; kkaiapi 同时也接受裸 Key 放在 Authorization 头里,两种写法都能用。然后把想让流程能看到的每个模型加进去,Model ID 要和目录拼写精确一致。

管理后台 -> AI setup -> Add AI Provider
  -> OpenAI Compatible

Display Name:   kkaiapi
Base URL:       https://api.kkaiapi.com/v1
API Key Header: Authorization
API Key:        Bearer sk-你的kkaiapi密钥

Models(Add Model):
  Model ID: claude-haiku-4-5-20251001  Type: TEXT
  Model ID: deepseek-v4-flash          Type: TEXT
  Model ID: claude-sonnet-4-6          Type: TEXT

Activepieces 怎么用一个自定义供应商

Activepieces(GitHub 上约 2.3 万星标)是开源无代码自动化平台里最受关注的一个:流程由触发器和 piece 组成,是 Zapier 的形状但能自部署,piece 框架 MIT 协议,社区目录很大。它的 AI 能力(文本生成步骤、Agent、AI 工具类 piece)通过平台配置的 AI 供应商解析各自的模型,这就是为什么一条供应商配置是一次性影响所有流程的路由决策。 底层实现上,OpenAI Compatible 供应商会针对你的 Base URL 建一个标准客户端,把 Key 挂在你选的 header 名字下,再加上按次运行的元数据请求头标识项目和流程。你注册的 Model ID 会作为 model 字符串传给 chat-completions 请求。这个供应商类型没有模型自动发现:流程能选的正好是你加进列表的那些模型,让选择器保持有意为之,而不是被淹没。 供应商配置是平台级的。管理员配一次,实例上每个项目、每条流程都从注册好的模型里选。这种集中化就是治理上的收益:一个地方决定哪些模型存在,一个 Key 计量全部 AI 步骤,每次请求上的按流程元数据让你读日志时能归因到具体流程。

完整配置与保存时的注意事项

这个表单保存时不校验连接;供应商实现里明确对 OpenAI Compatible 类型跳过了连接检查。这样做的好处是保存时不会去探测你的端点,代价是一个错误的 Base URL 或格式不对的 Key 要等到第一次真正跑到 AI 步骤的流程运行时才会暴露。建议在接进生产流程之前手动验证一次端点,把第一次运行当成配置的一部分来对待。 Model Type 决定了哪些 piece 能用这个条目:文本步骤要选 TEXT 类模型。Model ID 按目录拼写精确注册,Model Name 只是个显示标签,写什么都行,只要可读。如果想让同一个底层模型对不同团队呈现不同的性价比档位,按 Model ID 分别注册,靠显示名字在选择器里区分。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer $KKAIAPI_KEY" | head -50

curl -s https://api.kkaiapi.com/v1/chat/completions \
  -H "Authorization: Bearer $KKAIAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

按自动化步骤选模型

因为供应商是平台级的,模型治理就是一个屏幕的事:加上你认可的 ID,盯一周的按 Key 用量,再修剪掉没人该用的。流程搭建者在你划定的列表里保留自由。

• 自动化里的 AI 大多是量大、提示词短的活:给工单分类、抽取字段、起草一条消息、总结一份 webhook 载荷。claude-haiku-4-5-20251001、gpt-5.4-mini、deepseek-v4-flash 用走量价格覆盖多数步骤
• 给体现判断力的步骤留一个更强的 ID。一个给客户起草回复或做路由决策的流程,值得配 claude-sonnet-4-6,在流程搭建器里按步骤单独选
• MiniMax-M2.7 和 DeepSeek 家族给批量转换类流程(信息流、抓取清洗、数据增强)定价极好,这类场景每天几千次运行是常态
• 流程是无人值守跑的,所以成本等于一个排班表乘以一次运行的 token 数。用量日志给你每次运行的数字,排班表是你自己的
• 刻意只注册少数几个模型。选择器只显示你加进去的东西,一份精心挑选的列表能防止上百个流程搭建者各自选出不一样的结果

主力模型价格

价格按 kkaiapi 中文区实时价格计算,单位 ¥/1M tokens(输入/输出)。

Activepieces 专属的翻车点

保存安静、第一次运行才响。因为 OpenAI Compatible 供应商跳过连接校验,每一个接线错误(Base URL 错、漏了 /v1、Key 错、header 名字错)都会以流程运行里 AI 步骤失败的形式暴露,而不是表单报错。供应商刚改完之后 AI 步骤突然失败,先怀疑供应商条目,再怀疑流程本身。 Bearer 前缀的问题。Key 是原样发到你选的 header 下的。要求带字面 Bearer 前缀的端点需要把它填进 Key 字段;kkaiapi 两种写法都接受,但如果以后把这个供应商指到别处,记住平台不会替你加这个前缀。 Model ID 要精确。一个拼错的 ID 能通过表单(标签是自由文本),运行时才报模型不存在;网关的 /v1/models 输出是权威拼写。 没有自动发现是特性不是 bug。如果流程的选择器里缺了某个模型,是因为它没有注册到供应商上;在管理后台里加,而不是在流程搭建器里翻找。 还要在脑子里把 piece 级连接和这个分开:像 OpenAI piece 这样的单个 piece 可以按连接持有自己的凭据,而这里说的供应商条目驱动的是平台级的通用 AI 能力。如果一个流程用的是带自己连接的厂商专属 piece,那部分流量不会经过你的网关条目。

谁会把 Activepieces 接到一个网关上

• 在几十条流程上标准化 AI 能力的自部署团队,一条供应商配置和一个 Key 替换掉散落在各个 piece 里的凭据
• 想要模型治理的平台管理员:一份精选的模型列表、按 Key 的用量、以及不动流程就能换掉背后端点的能力
• 在一个实例上跑多个客户自动化的代理商,用各自的 Key 计量每个客户的 AI 用量,共用同一份目录
• 流程里混着走量步骤和判断步骤的搭建者,经一个端点按步骤搭配快速 ID 和旗舰 ID
• 拿不到某家厂商官方支付渠道的开发者,充值即用不需要海外卡

验证接入与排查首个 AI 步骤

保存供应商之前先跑上面那两条 curl;它们一起证明了 Key、Base URL 和模型 ID 三者都没问题,这正是表单不会替你检查的部分。 配置好之后一个流程的 AI 步骤失败,先看步骤的报错。认证失败说明 Key 字段或 header 名字错了(或者对一个要求带 Bearer 前缀的端点漏填了前缀)。模型不存在的报错是注册的 ID 和目录拼写对不上。连接错误通常是 Base URL 丢了 /v1。如果步骤找不到任何可选模型,说明供应商保存成功了,但对应模型类型的列表是空的。 流程跑起来之后,kkaiapi 控制台会显示每次请求的模型、token 数和花费。定时自动化的花费会悄悄累积,按 Key 的用量视图是平台管理员在账单出来之前看清哪些流程真正配得上它们花的 token 的地方。

常见问题