流程自動化
流程自己跑——該等人的時候,等人。
拿一個真實流程來說:訂單金額超過 10 萬,財務必須籤核,結果要同步 ERP,負責人要收到通知。這就是一次分支、一次人工等待、一次對外呼叫和一條通知——恰好是 ObjectOS 流程為之而生的形狀:持久、多步,你的 Agent 用後設資料寫出來,你的團隊在畫布上畫出來。
- 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 投遞。
下一步