流程自动化

流程自己跑——该等人的时候,等人。

拿一个真实流程来说:订单金额超过 10 万,财务必须签核,结果要同步 ERP,负责人要收到通知。这就是一次分支、一次人工等待、一次对外调用和一条通知——恰好是 ObjectOS 流程为之而生的形状:持久、多步,你的 Agent 用元数据写出来,你的团队在画布上画出来。

ObjectOS product surface connecting business data, applications, and AI agents
AI 编写元数据 对象、权限、流程、工具
审阅 diff 业务权限、数据访问、审批
运行时 执行策略 UI、API、审计、MCP、动作
16+
画布上的类型化节点——判断、等待、审批、脚本、子流程
持久
流程为人暂停、恢复时状态一分不丢
Outbox
Webhook 投递由持久重试队列背书

一份读得懂的流程

升级策略本身就是 diff。

这是一条完整可运行的策略:工单 SLA 超时,提升优先级并在收件箱通知负责人。你的 Agent 用几行可读的定义写出它——同一条流程在可视化设计器里就是一张图。

import { defineFlow } from '@objectstack/spec';

export const EscalateBreachedCases = defineFlow({
  name: 'support_escalate_breached',
  label: 'Escalate SLA Breaches',
  type: 'autolaunched',
  nodes: [
    {
      id: 'start',
      type: 'start',
      label: 'On SLA Breach',
      config: {
        objectName: 'support_case',
        triggerType: 'record-after-update',
        condition: 'sla_breached == true && previous.sla_breached != true',
      },
    },
    {
      id: 'raise',
      type: 'update_record',
      label: 'Raise Priority',
      config: {
        objectName: 'support_case',
        filter: { id: '{record.id}' },
        fields: { priority: 'urgent' },
      },
    },
    {
      id: 'notify',
      type: 'notify',
      label: 'Notify Case Owner',
      config: {
        topic: 'case.sla_breach',
        recipients: ['{record.owner}'],
        channels: ['inbox'],
        severity: 'warning',
        title: 'SLA breached: {record.subject}',
        actionUrl: '/support_case/{record.id}',
      },
    },
    { id: 'end', type: 'end', label: 'End' },
  ],
  edges: [
    { id: 'e1', source: 'start', target: 'raise' },
    { id: 'e2', source: 'raise', target: 'notify' },
    { id: 'e3', source: 'notify', target: 'end' },
  ],
});

搭建流程

跟着那笔 10 万的订单走一遍流程

下面每一步都是同一份定义里的一个类型化节点——那些通常演变成不可维护 worker 代码的部分,在这里保持声明式、保持可审阅。

按业务条件分支

判断节点给订单分路:10 万以下直接进入履约;超过的走审批路径。条件是写在真实字段上的表达式,不是埋在 worker 里的代码。

等财务——持久地等

审批节点让流程停驻。就算签核花了两周,状态也扛得住每一次部署与重启,然后从这个节点精确恢复。

更新、通知、对外调用

批准之后:update_record 节点翻转状态,notify 节点送达负责人收件箱,http_request 节点把订单推给 ERP。

把不顺利的路也画进去

ERP 超时是定义的一部分——重试与错误边直接画在流程里,失败路径和其他部分一样要过审阅。

把人放进流程里

屏幕流节点在流程中途收集输入——驳回原因、替补供应商——待办步骤出现在经办人的队列里。

流程设计器

画布上画,队列里跑,历史里查

每条流程都能在开源控制台的可视化设计器中打开——Agent 写的那份定义,就是运营团队能接手的那张图。

16+ 类型化节点的面板

把 start、判断、等待、审批、创建/更新记录、http_request、脚本、循环、并行、子流程节点拖上画布;把节点丢到边上即可在路径中间插入。

能打标签的分支

边可以携带条件与标签——approve、reject、超阈值——校验把断路标成可点击的徽标,任何东西运行之前就能看到。

上线之前先模拟

在画布上单步推演:走过的节点和边会高亮,不碰任何数据就能看到一条记录会走哪条路。

测试运行与运行历史

用类型化输入发起一次测试,然后看运行表——状态徽标、时长、每次运行的输出——点开任何一次运行,看每个步骤到底做了什么。

带预览的调度

Cron 表达式边输入边显示接下来五次触发时间,"每月最后一个周五"在真正运行之前就被验证。

启动、定时、对外连接

流程开始的每一种方式——以及走出系统的方式

触发器、调度和投递都是运行时服务,不需要为每个流程单独做基础设施。

记录变更触发器

带条件地响应创建、更新与删除——折扣超过 15% 时、工单重新打开时、阶段易手时。

定时运行

Cron 与间隔调度承担周期性工作:每夜汇总、续约提醒、SLA 巡检。

API 触发器

从外部系统或 AI 工具调用启动流程,输入按定义校验。

后台作业与队列

长耗时工作移入带重试的持久队列,请求保持轻快,流程保持可靠。

Webhook 投递

对外调用经由带重试与投递记录的持久 outbox——集成不再悄悄丢事件。

决策面

改什么、谁来审、跑什么

业务需求AI 编写运行时供给
10 万以上的订单等财务签核一个判断节点和一个审批节点持久等待、队列、锁定与恢复
每夜升级逾期工单一条带条件的定时流程执行、重试与运行历史
已批准订单同步 ERP审批之后的一个 http_request 节点持久 outbox、重试、投递记录
运营改流程不用发版什么都不用写——画布编辑的就是同一份元数据可视化设计器、校验与模拟

评审清单

自动化评审应确认

  • 每条流程都有明确的负责人和一句读得懂的用途。
  • 等待状态配有超时与升级路径。
  • 对外调用走 Webhook outbox,而不是临时 fetch。
  • 失败路径画在流程里,而不是心照不宣。
  • 流程变更以 diff 形式到达,带审批轨迹。

FAQ

这一页应该回答的问题

部署或重启时,正在运行的流程会怎样?

流程状态是持久的。等待某个人或某个定时器的流程会从暂停处精确恢复——重启和部署不会丢失或重复任何工作。

可视化设计器在开源版里吗?

在。流程画布、节点面板、校验、模拟、运行历史和调度预览都随开源控制台发布——连同流程、全部三类触发器、后台队列和 Webhook 投递。

下一步

继续完善你的评估材料。