別蓋超級 Agent：monday.com 用血淚換來的 AI 架構原則

本文整理自《AI and the Future of Work》2026 年播出的第 383 集。

{{< youtube JY_Wl2deg7I >}}

{{< spotify "episode/2R6xYtBbwqm1J7Vf88vpvG" >}}

{{< apple-podcast "tw/podcast/383-from-zero-to-one-to-a-billion-in-arr-why-monday/id1476885647?i=1000759811118" >}}

---

Demo 很驚豔，Production 很慘烈

每個建過 AI agent 的團隊大概都經歷過這個時刻：你在 demo 上展示一個能自主完成複雜任務的 agent，在場所有人都被震撼。然後你把它推到正式環境，開始讓它接觸真實客戶、真實資料、真實業務邏輯，災難就開始了。

monday.com 技術長丹尼爾．萊雷亞（Daniel Lereya）在近期的 podcast 訪談中，坦率地分享了他的團隊在這條路上踩過的坑。作為一個服務六成財星五百大企業、有二十五萬付費客戶的平台，他們犯的錯誤和學到的教訓，對所有正在建構 agent 系統的團隊都有參考價值。

核心教訓只有一句話：不要蓋超級 Agent。

超級 Agent 為什麼失敗

Lereya 描述的反模式很典型：團隊一開始的直覺是打造一個「什麼都能做」的大型 agent。給它廣泛的權限，讓它自主判斷要做什麼、怎麼做。邏輯聽起來很合理。AI 的強項就是處理模糊、非確定性的任務，那為什麼不讓它盡可能多做一點？

問題出在生產環境的現實。當一個大型 agent 擁有廣泛的裁量權，它的行為就變得不可預測。不是偶爾不可預測，是系統性地不可預測。你無法確定它在什麼情況下會做出什麼判斷，因為「裁量權」本身就意味著你放棄了對結果的精確控制。

更棘手的是除錯。當一個擁有廣泛權限的 agent 做出了錯誤判斷，你很難追溯它的推理路徑。它為什麼選擇 A 而不是 B？它在哪個環節對情境產生了誤判？因為整個決策過程是不透明的，你能做的只有事後檢驗結果，然後猜測中間發生了什麼。在 demo 環境裡這不是問題，因為你會手動檢查每個結果。但在每天處理數萬個真實業務流程的平台上，這種不可追溯性是致命的。

正確做法：把 Agent 包在剛性工作流裡

monday.com 的團隊把架構完全反轉了。不是讓 agent 來實作工作流，而是讓工作流來包裹 agent。

具體來說，這個架構有三個層次。最外層是確定性的工作流，它定義了明確的輸入是什麼、輸出應該是什麼、每一步的權限範圍、以及可以產生哪些副作用。中間層是小型、模組化的 agent，每個 agent 只負責一個狹窄的任務。最內層才是 AI 的非確定性能力，在那個狹窄的範圍內自由發揮。

monday.com 平台本身扮演的角色是「交易性的事實來源」（transactional source of truth）。這個概念很關鍵：平台控制權限、定義哪些資料可以進入每個步驟、限制 AI 能產生的副作用範圍，然後提供一個結構化的帳本，讓 AI 的所有產出都流回來供人類檢視。AI 只在那些確實需要非確定性能力的節點被觸發，而不是從頭到尾都在運作。

Lereya 用了一個很清楚的說法：你不能在 AI 的裁量權「裡面」去引導它，那個內部本來就應該是流動的。你該做的是設計好「框架」：精確定義輸入、輸出、合約、可見性。讓裡面流動，把外面鎖死。

當 Agent 越界：「人類 TODO」模式

理論歸理論，真實的 agent 總會找到你沒預料到的方式來「超越職責」。Lereya 分享了一個很具體的內部案例。

他們有一個 agent 的任務是拆分一個 monolith（單體架構），把大型程式碼庫拆成較小的模組。任務定義很清楚：辨識邊界、拆分模組、確保介面正確。但這個 agent 在拆分的過程中，開始「順便」修正它發現的邏輯錯誤。從 agent 的角度看，這是合理的判斷：它看到了一個 bug，順手修了。但從團隊的角度看，這完全超出了授權範圍。一個負責「拆分架構」的 agent 不應該同時在「修改業務邏輯」，因為業務邏輯的修改需要人類理解完整的上下文才能判斷對錯。

團隊沒有選擇限制 agent 的觀察能力，也沒有懲罰它的「多管閒事」。他們的解法是建立一個「人類 TODO」頻道。agent 觀察到的問題不再直接修正，而是寫成註解，標記為需要人類審閱的待辦事項。這樣 agent 的洞察力被保留了（它確實看到了有價值的問題），但行動權回到了人類手上。

這個模式的精髓在於：不是對抗 AI，而是把它的湧現行為導引到人類可以操作的介面上。

另一個教訓：鬼會議

第二個案例更貼近終端使用者。monday.com 內部有一個排程 agent，任務是幫業務團隊安排客戶通話。有一次，agent 成功地安排了一通客戶電話，發出了邀請、對方也確認了。但沒有任何一個 monday.com 的人知道這件事。結果就是客戶準時上線，另一端空無一人。

這是一個 demo 和 production 之間差距的完美案例。在 demo 環境裡，你看到 agent 完成排程會覺得「太厲害了」。但在真實業務中，agent 必須確保它安排的每件事都有人類知情、有人類負責。排程本身只是動作，確保有人赴約才是完整的流程。

這個事件讓團隊更加確信：agent 的每個動作都必須有對應的可見性機制。不是事後可以查詢，而是主動通知相關的人。

負責任 AI 的四個操作原則

從這些經驗中，Lereya 歸納出四個具體的工程原則。

第一是明確列舉包含項（allow-list）。不要說「agent 可以存取所有資料，除了 X、Y、Z」，而要說「agent 只能存取 A、B、C」。排除清單永遠有漏洞，因為你無法預見所有該排除的東西。包含清單的預設是「什麼都不能碰」，只有明確列出的才被允許。

第二是跨步驟的資料隔離。把 AI 工作流拆成離散的步驟，每個步驟只看到它需要的資料。不要讓任何單一 agent 能看到整個流程的所有資訊。這降低了任何單一環節出錯的爆炸半徑，也創造了可稽核性。

第三是精確定義輸入和輸出合約。每個 agent 的介面要像 API 一樣清楚：它會收到什麼格式的資料，它必須回傳什麼格式的結果。中間可以是非確定性的，但邊界必須是確定性的。

第四是投資可見性。記錄 agent 的實際步驟、副作用、資料存取。這不是為了除錯（雖然也能用），而是為了讓人類能在需要時介入。你引導 AI 的方式是設計框架，而不是試圖控制它內部的推理。

67% vs 80%：重新定錨期待

最後一個觀點跟技術無關，但對所有正在部署 AI agent 的團隊很重要。Lereya 說，他們推出一個準確率 80% 的 agent，使用者的反應通常是：「怎麼不是 100%？」

於是他們去查了同一項任務由人類完成時的準確率。答案是大約 67%。

這不是說 80% 就夠好了，不需要繼續改善。而是說，當你在決定「這個 agent 能不能上線」的時候，正確的比較基準不是完美，而是人類目前的表現。一個 80% 準確率的 agent 搭配適當的防護欄和人類監督，已經是對客戶的淨正向貢獻。把標準定在 100% 才能上線，等於永遠不上線，等於讓客戶繼續忍受 67% 的人類表現。

這個重新定錨，可能比任何技術決策都更影響一家公司能不能真正把 AI 推進生產環境。