Marico's space

最近在找一个靠谱的 AI 工作流自动化平台，踩了几个坑，终于找到 OrcFlows 这套方案，用下来感觉解决了几个痛点，这篇把核心点说清楚。

TL;DR：OrcFlows 是一个面向生产级自动化的工作流平台。每个执行都是一个持久化的 Temporal 工作流，不怕崩溃、不怕部署。AI Agent 留有完整的决策轨迹。变更有版本管理、可对比变更、可测试，审批通过后才能从开发环境推到生产环境。可视化画布，用 Go 写的，跑在 Temporal 之上。有免费版，定价简单，不按任务收费。

凌晨 3 点的崩溃问题

想象一个简单的工作流：收到订单的 webhook 触发后，第一步扣款，第二步发欢迎邮件，第三步在钉钉群里发通知。

现在，在第一步和第二步之间把 worker 进程 kill 掉。可能是部署、内存溢出、或者节点被调度走了——这种事迟早会遇到。然后呢？完全取决于你的自动化工具把状态存在哪。如果状态在进程内存里，结果就是两个坏选项之一：要么这个执行直接消失（钱扣了，但用户没收到欢迎邮件），要么从头重跑（用户被扣了两次钱）。

很多自动化工具最早就是给简单的 SaaS webhook 场景设计的，"重试一下" 是可以接受的答案。但如果某一步是转账、发邮件、或者部署代码——这答案就不够用了。更别说当 LLM 是决定下一步做什么的那个角色时，情况只会更糟。

我们做 OrcFlows，就是为了那些凌晨 3 点失败但早上 9 点很重要的执行。

OrcFlows 是什么

OrcFlows 是一个可视化的工作流和 AI Agent 构建工具。你可以把触发器、Agent、工具和连接器拖到画布上——或者用自然语言描述工作流，让生成器帮你连好——每一次执行都跑在一个持久化引擎上。

画布界面。一个钉钉消息触发一个 AI Agent。橙色虚线是 Agent 可以调用的工具。

核心组件：

• 30+ 触发器 — webhook、定时任务、钉钉、Telegram、WhatsApp、邮件、Gitee、支付宝和更多。
• 120+ 连接器 — 钉钉、Gitee、支付宝、邮箱、Google Sheets、飞书、Jira、HubSpot、阿里云、腾讯云、Kafka、MQTT、Snowflake、PostgreSQL 等。类型化、已认证，不是伪装成 webhooks 的那种。
• AI Agent 节点 — 一个带工具的 ReAct 循环，有持久化记忆和知识库。支持通义千问、ChatGPT、DeepSeek、硅基流动、NVIDIA NIM、Ollama 或任何 OpenAI 兼容端点——自己带 key 来就行。
• 代码和自定义节点 — 在沙箱化的 Docker 容器里跑 Python、Node.js 或 shell，或者不重新部署自己定义节点类型。

这是每个自动化工具都有的功能列表。这篇文章的重点是底层有什么不一样。

1. 天生持久化

每一个 OrcFlows 执行都是一个 Temporal 工作流，每个步骤都是一个 Temporal 活动（Activity）。Temporal 会持久化执行的完整事件历史——每个步骤的输入、输出、重试和信号——所以状态永远不会只存在于一个随时可能挂掉的进程里。

同样的工作流，同样的崩溃。没有检查点的话执行从头开始，会扣两次款。有了检查点，从第二步恢复。

实际使用中的好处：

• 崩溃和部署不会丢工作。 如果 worker 在执行中途挂了，会从最后一个完成的步骤恢复。已经完成的步骤不会重新执行。
• 每步独立重试。 每个步骤有自己的重试次数和延迟，所以一个不稳定的 API 或限流只会重试这一步，不会把前面的步骤都跑一遍。
• 等待不花钱。 一个执行可以在审批环节挂起好几天，不占用任何线程、连接或定时器。
• 每次执行都可回放。 完整的事件历史可用于调试——也用于重试按钮，可以重新运行失败的任务，但保留已成功步骤的结果。

诚实说一下限制：正在执行中的步骤如果 worker 挂了，会被重试——这是所有持久化系统都这样的。对于扣款、发邮件这类有副作用的调用，在目标 API 支持的情况下传一个幂等 key。你不会遇到的状况是：已完成步骤跑两次，或者整个执行悄悄消失。

2. 能等好几天的人工审批

有些步骤不应该没人确认就执行：超过限额的退款、生产环境部署、发给大客户的重要邮件。审批步骤会把执行挂起，通过钉钉、飞书或应用内通知相关人员。一旦他们响应，执行立刻恢复——或者如果被拒绝，就停在那。

左：执行在 request-approval 处挂起。右：同样的审批消息发到了 Telegram，点一下就能通过或拒绝。评论会写入审计日志。

底层是 Temporal signal，所以等待不花任何代价，而且不怕重启。这也是你可以用来实现任何"等待外部事件"模式的机制。

3. 能看清内部的 Agent

一个在 demo 里表现很好但在生产环境出奇怪行为的 Agent，就是个调试噩梦。所以 OrcFlows 把 Agent 执行当作数据来对待：

• 每次执行都有完整决策轨迹 — 每个工具调用的输入、输出、耗时和错误，加上每步的 token 用量和成本。
• 会话时间线 — 对话中的每一轮归到一个视图里，所以"为什么 Agent 在第三轮说了那句话？"是有答案的。
• 持久化记忆 — Agent 从 PostgreSQL 后端的记忆中记住之前的对话轮次和之前的执行，按会话维度索引。

会话时间线。每一轮是独立的执行，会话把它们串在一起。

工作流也可以暴露给其他 AI 客户端使用：把一个工作流标记为 MCP 启用，它就会作为工具出现在你工作空间的 MCP 服务器上。

4. 像软件一样发布自动化

在很多自动化工具里，工作流就是数据库里的一行，你在线编辑。这就是为什么周五下午 4 点一个字的 prompt 改动就直接进了生产。OrcFlows 给工作流配备了和代码一样的护栏。

每次保存都是版本——可以对比任意两个版本。

两个版本之间 prompt 只改了一行。另一个护栏：推到生产了，但要等管理员审批才生效。

带审批的环境。 工作流有 dev、staging 或 prod 环境标识。提审会先打快照当前版本，所以可以回滚。提审到生产会把工作流停在 pending_approval 状态，直到负责人或管理员确认。

发布前先模拟。 模拟用真实的触发数据跑一遍工作流，有真实的 AI 推理和真实的分支——但连接器、HTTP、浏览器和审批步骤会被 stub 或自动通过。你能看到改动会做什么，但不会真的发出一条钉钉消息或扣一笔款。

模拟：回放最近一次执行的触发数据，或者粘贴你自己的 JSON。

Git 作为事实来源，想用就用。 把工作流定义推到你控制的仓库里，再拉回来，这样自动化变更就像其他代码一样在 pull request 里 review。

Git 同步：指向仓库、分支和路径前缀，token 存为 secret。

5. 真正有用的 Eval

"这个改动让 Agent 变好了还是变差了？"不应该靠感觉来回答。OrcFlows 内置了评估功能：

• 测试用例数据集 — 单轮或完整的多轮对话。任何过去的执行都能一键转成测试用例，所以 bug 报告会成为永久的回归测试。
• 七种评估器类型 — 文本匹配、数字（带容差）、JSON、相似度、工具调用轨迹、LLM 评判，以及结果检查——后者会自己发一个独立的请求来验证真实系统状态。最后这种适合"Bot 说退款成功了——到底有没有？"
• 真实执行。 每条数据集都通过和生产环境一样的持久化引擎跑真实的 workflow——不 mock 任何东西。
• 每行多次试验，支持 pass@k 和 pass^k，因为一个跑了三次只成功一次的 Agent 不算通过。
• 发布门禁。 给一个命名评估设一个最低通过率，在最近一次运行达标之前，禁止提审到 staging 或生产。这就是自动化领域的 CI 检查。

发布流水线。评估失败会阻止提审；评估通过后，生产环境还需要管理员审批。

其他该有的都有

• AI 工作流生成器。 用自然语言描述自动化需求，得到一个完整的工作流——包括节点、表达式、数据映射和连接——整个画布都可以继续编辑。
• 知识库。 上传文档或指向 URL，从工作流和 Agent 里查询。
• Secret。 加密存储（AES-256-GCM），通过 {{ secret.NAME }} 引用；不会出现在工作流里。
• 团队和权限。 角色加细粒度权限覆盖；企业版有组织、SSO 和审计日志。
• 从 n8n 迁移过来？ 导入 n8n 导出文件，得到迁移报告：哪些节点转换干净、哪些需要手动处理、哪些没有对应功能。导入的定时触发和服务触发工作流默认是禁用状态，所以在 secret 配置好之前不会误触发。
• 支持四种语言 — 中文、英文、西班牙语和法语。

底层架构

无聊但成熟的组件，组合起来实现持久化。

三个组件——Go API 服务、Go Worker 和 SvelteKit 控制台——跑在 Temporal、PostgreSQL 和 Redis 之上。Worker 监听两个任务队列：main 队列处理 Agent、代码和文档处理这类重活，fast 队列处理转换、HTTP 调用和条件判断这类亚秒级操作。一个 30 秒的 LLM 调用永远不会让一个 20 毫秒的转换排队在它后面。

选 Go 不是营销噱头。Worker 是编译好的二进制，内存占用小，并发便宜。

基准测试（以及局限性）

我们对整个技术栈做了压测，不是 hello world 端点。Locust 在 8 分钟内跑了 200 并发用户，覆盖 20 种端点类型——认证、CRUD、触发器、执行、secret、知识库。每个触发器都启动一个真实的五步持久化工作流（set → HTTP → transform → condition → set），每步都持久化到 PostgreSQL。API、Worker、Temporal、PostgreSQL 16 和 Redis 7 都跑在本地 Docker 上。

结果：216,474 请求，0 失败，451 请求/秒持续吞吐，满负载下 Go 堆只有 19 MB。

带点 grain of salt 来看。这是我们在自己的机器上测的，测的是 API 和触发路径——不是你的工作流对下游的调用，也不是 LLM 延迟，而后者在任何 Agent 执行中都会是主要瓶颈。可以把它当作引擎不会成为瓶颈的证据，但别当作你工作负载的承诺。

定价

那些按任务收费的自动化工具，自动化越多收费越多。OrcFlows 不这样：每个版本都包含无限次执行。

达到 Free 版的工作流上限时不会出问题：已有工作流继续跑，只是不能再激活第十一个，除非升级或停用一个。也可以在自己的基础设施上自托管社区版——看文档里的部署说明。

适合谁、不适合谁

适合的场景： 自动化的东西失败有代价（支付、客服、运营、DevOps），在构建需要追踪和评估的 AI Agent，想要像代码一样 review 和门禁自动化变更，或者现有工具的可靠性或按任务计费模式已经不够用了。

暂时不适合的场景： 需要长尾的、成千上万个冷门 SaaS 集成的——OrcFlows 有 120+ 连接器加 HTTP 和自定义节点来弥补，但没有那么大的市场。还在 公开 beta：变化快，有些边角粗糙。另外如果只是需要在两个常用应用之间做个两步的简单联动，轻量级工具可能就够了。

试试看

1. 免费注册 — 不用信用卡。
2. 用自然语言描述工作流，或者从 n8n 导入已有的。
3. 第一次提审生产前加一个评估。 未来的你会感谢现在的自己。

看文档，有问题欢迎反馈。

今天就部署你的第一个持久化工作流：orcflows.com