流程自動化

流程自己跑——該等人的時候,等人。

拿一個真實流程來說:訂單金額超過 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 投遞。

下一步

繼續完善你的評估材料。