我們公司怎麼跑出 20+ AI 流程？系列第 2 篇：排程治理 SOP——時間表、重試、報警、版本管控 4 維度 + 5 條紅線

過去三天的早上七點，我們公司的「每日部落格 AI 寫稿」cron 連續跑了三次都沒有產出文章——agent 自己看完當天 pipeline、查重、預算盤點之後，自決跳過。一週前我們公司內部跑的 AI 流程數量正式破 20 個，這三天的「自決跳過」反而讓我看到一件事：流程多到讓 agent 自己會「拒絕做不該做的事」，比流程數本身更值得寫一篇出來。

這篇是「我們公司怎麼跑出 20+ AI 流程？」系列的第二篇。第一篇拆的是 內部報價自動化 SOP——把單一流程的節點、LLM 分工、fallback 兜底寫得很細。這一篇把鏡頭拉遠，談「20 個流程同時跑」的時候，**真正會讓老闆夜裡爬起來的，是治理層面的東西，遠超過任何單一流程壞掉本身**：誰跑、什麼時候跑、壞了怎麼處理、誰會被叫醒、改一行設定誰要簽字。下面這四個維度，會決定你公司有沒有資格說「我們在跑 N 個 AI 流程」。

我們團隊「20+ AI 流程」現在長什麼樣

先把我們內部正在跑的流程攤開——這不是宣傳，是讓接下來的治理規則有對應的真實 case。下表是節錄到今天為止 22 個流程的觸發方式與成熟度，產品名沿用我們內部慣用稱呼（Claude Code / N8N / Skill 庫是我們的 git repo），不是廠商分類。

最痛的學習是：剛跑到 5 個流程的時候，每加一個流程就像加一個新員工——記得了。跑到第 12 個，我就開始忘記「上週禮拜三半夜跑壞那一個是哪一條」。跑到第 18 個，我已經沒辦法在腦袋裡裝下「全部流程的時間表 + 失敗模式」。

把這個焦慮翻譯成一句話：**流程數量翻倍，治理複雜度是翻四倍**。blckalpaca 在 2026 的一份 production AI workflow 報告裡也提到同樣觀察：「企業跑 AI 流程的失敗率，在第 10～20 個流程之間會出現一個治理斷層」。真正會把企業帶進這個斷層的，不是工具難用，是沒有人提早把「治理層」當成第一級資產來投資。

排程治理的四個維度——少做一塊就會吃悶虧

我們最後抽出來的四個維度很簡單：時間表（什麼時候跑）、重試（壞了怎麼辦）、報警（誰被叫醒）、版本（誰能改）。少投資任何一塊，後面三個月一定會出事。先給總圖再展開。

時間表設計：哪些走 cron、哪些走 webhook、哪些走 manual

時間表這件事不是寫個 crontab 就結束。最常見的失敗模式是：一開始什麼都 cron，後來流量大了之後 cron 之間互撞——同一台機器同時跑 5 個 LLM 任務，token 配額被打爆 + 互相搶 IO + 監控 dashboard 一片亮紅。我們現在的分配原則簡單到一張表能講完。

我們公司內部有一條很硬的規則：**新流程上線的前 30 天一律走 manual**，跑穩了才升 cron / webhook。這條規則是某次「自動排程把客戶詢價回信寄錯地址、隔天才發現」之後加的。學的是 n8n 官方對 production deployment 的建議——他們在 2026 best practice 寫的 15 條裡，第一條就是「flow staging」：所有新 flow 要先在 staging env 跑 30 天才能進 production。

一個小決策框架：cron 還是 webhook？

如果你還在猶豫某個新流程要排 cron 還是接 webhook，問自己這三個問題就夠：

• 資料來源「能不能等」：等 1 小時還算可接受 → cron；不能等 30 分鐘 → webhook
• 失敗如果沒人發現、後果嚴不嚴重：客服回信晚了 4 小時可能掉單 → webhook + 重送；報表晚 1 天頂多被罵 → cron
• 資料量會不會「洪峰」：年中大促一天進 500 筆詢價 → webhook 必加 queue；穩定一天 10 筆以下 → 隨便 cron

失敗重試策略：哪些該重試、哪些不該重試

這一段我寫得最久——因為踩過的雷最多。最痛的一次是：客戶詢價自動回覆流程裡，LLM 回來「rate limit 429」我們設了「無限重試 + 指數退避」，結果 OpenAI 那邊配額一直沒釋放，我們的流程整夜不斷重試把今天的 token 預算燒光、隔天早上正常請求全部回 429——這是「該重試但策略錯」。

另一次是「該重試但被吃掉」：N8N 一個 node 拋 timeout，我們以為自己有 retry 設定，結果是上游 webhook 已經 ack 過了、retry 拿到的是 stale data、回覆給客戶的內容是「我們已收到您 3 天前的詢價」——但客戶 1 小時前才送出。客戶當場退單。Fast.io 在 AI agent retry patterns 那份 2026 文章講過：「retry 的本質是『把不確定的失敗變成確定的延遲』，不能把『不該重試的東西』也丟進來」。

我們把這張表寫進 Skill 庫的 retry-policy.md，每個新流程上線時 reviewer 一定會問「你的 retry 對應到哪幾條？」沒答上來不准 merge。MetaCTO 的 error handling for AI workflows 那篇也呼籲類似做法——把 retry policy 從 ad-hoc 升級成「機制化的決策」。

報警邊界：什麼狀況該叫醒老闆、什麼狀況該靜默

這一段直接決定老闆睡得好不好。我們公司報警分四級，過去三個月修了三次——每次都是「警報太多麻木 vs 警報太少漏掉」之間調平衡。現在的分級長這樣。

這張表看似簡單，但難在「P0 / P1 / P2 之間的判定」。我們的判定原則只有一條：「客戶或老闆會因此打電話來嗎？」——會 → P0 / P1，不會 → P2 / P3。聽起來很主觀，但實際運作半年，誤判率比我們之前列十條規則的版本還低。

配套是 AI agent observability tools：每個流程都有自己的 dashboard（成功率、平均執行時間、token 消耗、cost per run）。dashboard 上的指標統一塞進 Sentry custom event，週報 cron 跑的時候自動撈一份 trend 報告——這樣老闆每週末都看得到「20 個流程這週整體健康度是 87% 還是 92%」，不必每天問。

版本管控：Skill 庫、prompt、DB schema 的三軌治理

這一段最常被忽略，也是出事時最後悔沒做的。AI 流程的「程式碼」其實散在三個地方：

• **Skill 庫 / agent 設定**：我們的 .claude/commands/*.md 與 SOP markdown 都在一個獨立 git repo（sheep-skill），每次改都過 PR + 兩個 reviewer。
• **prompt template**：寫死在腳本裡的 prompt 也算「程式碼」，改 prompt 就要 commit。我們 2026-05 踩過一次：某 agent 直接在 production 改了 system prompt 沒 commit、隔週 cron 因為某個 nuance 走錯路徑、回頭沒人記得當天改了什麼。
• **DB schema 變動**：每改一個 collection 欄位，schema 必須先在 dev 跑過 + push 到 prod，再 deploy code。我們在 2026-06-19 因為「先 deploy code 才 push schema」全站 404 一小時——詳見 [記憶memory db-schema-workflow]。

配套的工程實踐：每次 cron 跑完之後寫一條紀錄到 `/audit-log` 表，欄位包含「執行時間 / agent 版本 hash / prompt 版本 hash / 結果 hash」。如果跑壞了，可以用「結果 hash」反推當時的 agent + prompt 組合。這個習慣是抄 Anthropic Agentic Coding Trends Report 裡提到的「auditable trace」概念——production agent 的可追蹤性，要做到事後能完整還原當時的決策路徑。

# 我們 audit-log 表的最小版本
CREATE TABLE audit_log (
  id BIGSERIAL PRIMARY KEY,
  run_at TIMESTAMPTZ NOT NULL,
  flow_name TEXT NOT NULL,
  agent_version_hash TEXT,
  prompt_version_hash TEXT,
  result_status TEXT,
  result_hash TEXT,
  cost_usd NUMERIC(6,4),
  token_input INT,
  token_output INT,
  notes JSONB
);
CREATE INDEX idx_audit_flow_time ON audit_log(flow_name, run_at DESC);

5 條治理紅線——中小企業老闆採購評估時直接拿來用

如果你正在評估「該不該找廠商幫忙跑 N 個 AI 流程」——下面這五條可以當成跟廠商面談時的快速濾網。任何一條對方答不出來 / 答得很 vague，這個合作風險就很高。我們公司自己內部也用這五條當「流程是否成熟」的驗收標準。

你的公司也想跑 20+ AI 流程？從這 6 個決策開始

最後一段給「剛起步、想知道從哪邊開始」的老闆。我們公司花了 14 個月從 3 個流程跑到 22 個——這條路不是線性的，但有六個決策節點是每家公司都要做的：

• **決策 1**：第一個流程選什麼？建議選「重複性高 + 結果可驗證 + 失敗無痛」——例：每日報表抓取、log 分類、客戶分群統計。**不要**第一個就挑「客戶溝通」這種對外、不可逆、容錯低的流程。
• **決策 2**：自己跑還是找廠商？看內部有沒有人能寫程式 + 願意 oncall。沒有 → 找廠商但 5 條紅線必問；有 → 先自己跑前 3 個建立 know-how。
• **決策 3**：選哪個編排工具？N8N（low-code 視覺化）、Make.com（同類）、純程式碼（Python / Node）+ cron——選你團隊裡半夜被叫醒能修的。
• **決策 4**：第 5 個流程之前要不要先建治理層？我們的建議是：**到第 5 個流程之前就要把這四個維度的最小版本跑出來**——否則第 6 個流程上線那一刻會吃悶虧。
• **決策 5**：什麼時候請第二個工程師？跑到第 10 個流程 + 一週至少有 3 件 P1 事件 = 該找人了。在這之前都還能一人撐。
• **決策 6**：要不要 OKR 化？跑到第 15 個之後，每個流程要有自己的 KPI（成功率、平均耗時、cost per run、節省的人力 hour）。沒有 KPI 的流程就像沒有預算的部門——遲早被砍。

看到這裡，如果你也在想「我們公司現在跑了 3-5 個 AI 流程，要不要升級治理層」——可以把現況丟過來，我們很樂意 聽你聊聊現在的實際狀況，一起看看哪一條最該先升、哪一條先暫緩。或如果你還在思考「該不該找客製化廠商幫你做底層工程」——可以看一下我們的 客製化系統開發服務，理解我們怎麼把治理層當成第一級交付物（而不是事後補的文件）。