AI 代理就緒的企業

Agent-Ready-X 的挑戰與機會

2025 年底，有一件事情悄悄地發生了。

Cursor 的使用者數量在幾個月內翻了好幾倍。GitHub Copilot 的 Workspace 功能開始有工程師認真地在日常開發中使用。社群媒體上，工程師們開始分享讓 AI 獨立完成整個功能實作的經驗，而不只是補全某一行程式碼。

一位工程師朋友，在 2025 年底告訴我：「有一個任務，我本來預估要做兩天，結果讓 agent 跑了一個晚上，早上起來，幾乎都做完了，而且品質還不錯。」

從 2025 年第四季開始，coding agent 從「有點有用的工具」，突然變成了「讓整個開發流程重新設計」的力量。

這揭示了什麼？

coding agent 為什麼會在這個時間點大量被採用？而且一路向上。

表面上的解釋是：「模型變強了。」這個解釋有一定道理，畢竟從 GPT-4 到 Claude 3.5 Sonnet、再到 Claude 3.7 Sonnet 這一代模型，能力的提升是實質且巨大的。

更關鍵的問題是：為什麼同一批模型，在幫助工程師寫程式的時候如此強大，但是在協助企業處理客服流程、採購審批、行銷規劃的時候，卻相對受限許多？

模型沒有不同。一樣的 Claude，一樣的 GPT。差別不在模型，差別在領域。那些還沒有被 agent 處理得好的領域 (Domain)，並不是在等待更好的模型。它們是在等待自己準備好。

這就是代理就緒（agent-ready）的概念。

代理就緒的兩個條件

一個領域要成為 agent-ready，至少需要兩個核心條件：

一、Agent 要可以取得 Feedback

Coding agent 之所以有效，一個非常重要的原因是：它可以立刻知道自己做得對不對。

Agent 寫了一段程式碼，就呼叫 compiler 看看有沒有 syntax error；寫完之後，跑 test suite 看看有沒有 regression；如果改了 API，就起一個 server、打一個 request，看看回傳是否正確。

整個過程裡，feedback 非常明確，而且是即時的。這個特性讓 agent 可以進入一個非常短的「行動 → 觀察 → 修正」循環。

而現在多數公司的 CRM 系統裡的銷售流程，可以讓 agent 做一個操作、然後立刻知道結果正確不正確嗎？你的採購審批流程，有沒有任何 CLI 可以呼叫，讓 agent 確認一個動作是否成功？

大多數企業的答案是：沒有。

二、Agent 要可以取得 Context

這是第二個條件，也是更難滿足的那一個。

Coding agent 為什麼能理解一段陌生的程式碼？因為程式碼本身就是 formal language。函數名稱有語意，資料結構有定義，呼叫關係是顯式的。當 agent 讀了程式碼，就可以相當程度地理解它的 what（這段程式碼做什麼）、how（用什麼方式做）、甚至 why（為什麼這樣設計）。

這不是偶然。程式語言本來就是為了讓機器（和人）都能理解而設計的。它天然就是結構化的、語意清晰的。

但企業裡大多數的業務知識，並不是這樣的。

採購流程的規則散落在各種 Word 文件、電子郵件和員工的腦袋裡。「客戶 A 跟我們有特殊約定，超過一定金額的訂單，要提前三天通知」——這種知識，通常根本沒有被結構化儲存。

這就是 agent-ready 的本質挑戰：很多企業的知識，現在的存在的形式只適合讓人理解，不適合讓 agent 理解。

代理就緒的資料倉儲

寫程式也許離一般人較遠，再從一個相對有機會「代理就緒」的例子來說明：資料倉儲。

Text-to-SQL 是一個很美好的想法：「讓使用者用自然語言問問題，AI 自動轉成 SQL 查詢，從資料庫裡取得答案。」以今日的模型來講，寫 SQL 不是難事，但 Text-to-SQL 要在企業成功地落地，卻仍然困難重重。

問題不是在於模型不夠聰明，而是在於 context 不夠。

你問 AI：「上個季度，我們的客戶流失率是多少？」

AI 必須知道很多事情，才能把這句話轉成正確的 SQL：

• 「客戶」在這家公司的資料庫裡，對應的是哪一張資料表？是 users、accounts、還是 customers？

• 「流失」的定義是什麼？是超過 90 天沒有登入？是主動取消訂閱？還是連續三個月消費金額為零？

• 「上個季度」的計算邏輯是什麼？是自然季？還是公司自定義的財會季度？

• 如果「客戶流失率」是一個跨多張資料表的計算，join 的條件是什麼、分母是什麼、分子是什麼？

這些知識，不在 SQL schema 裡。SQL schema 只告訴你資料表有哪些欄位，不告訴你這些欄位的業務語意。

這正是為什麼，想要讓 Text-to-SQL 可靠地運作，往往需要先導入現代資料棧 (Modern Data Stack)。一旦有了類似 dbt 這樣的工具，讓分析工程師在撰寫 data model 的時候，同時建立詳盡的 metadata。

一個設計好的 dbt model，它的欄位說明可能長這樣：

- name: churned_at
  description: >
    客戶流失的時間戳記。定義為訂閱狀態轉為 ‘cancelled’ 且超過 30 天未重新訂閱的時間點。
    若客戶尚未流失，此欄位為 NULL。
    計算邏輯參考 finance team 2024-Q2 的定義文件。

這段描述，就是在把業務語意，結構化地附著在資料上。有了這樣的 metadata，AI 才有足夠的 context 來生成正確的 SQL。

然而，這邊有一個挑戰：「 dbt Model 的 metadata 要如何生成呢？」

這邊引用〈分析工程師〉一文裡有談到的：分析工程師的核心價值，在於他同時懂業務和技術——能夠把業務部門的語意需求，轉化成資料模型的定義。這個能力，在 agent-ready 的資料倉儲裡，變得比以往更加重要。沒有這樣的人在中間搭橋，AI 就算再聰明，也不知道「流失」在這家公司的意思是什麼。

資料倉儲要變成 agent-ready，需要的不只是 Text to SQL 的系統，更需要的是，有人一步一步把業務語意釐清，仔細地寫進 metadata。這很可能是分析工程師的工作，因為是一項需要同時懂技術和業務的人才能做好的工作。

如果你正在評估從資料倉儲開始切入代理就緒 (Agent-Ready-Data)，並考慮導入資料平台，《從試算表到資料平台》裡有系統性地討論 Modern Data Stack 的導入與應用，包括技術選型、資料分析與組織推動。

代理就緒的企業

如果把 Agent-Ready-X 框架從資料倉儲延伸到整間企業，問題會變得更複雜，還是更清晰呢？

客戶關係管理（CRM）

Salesforce 是全球最大的 CRM 平台，理論上具備成為 agent-ready 系統的條件。

然而現實的挑戰在於：當一位業務員在 Salesforce 裡更新了一個 opportunity 的階段，這個動作可能觸發通知、更新報表，或者什麼都不做——取決於這家公司如何設定自動化規則。這些規則分散在 Flow、Validation Rule、Apex Trigger 等不同機制裡，透過 UI 建立，雖然技術上可以透過 Metadata API 或 Salesforce CLI 匯出，但格式並非為 agent 設計，需要額外解讀才能轉化成可用的 context。

更根本的問題是高度客製化。每一家公司的 Salesforce 設定幾乎都不同，同一個欄位在不同公司可能代表完全不同的業務語意。這使得通用的 agent 很難在沒有人工轉化的情況下，理解特定公司的業務規則。

業務流程管理（BPM）

BPM 系統（如 SAP、Oracle EBS、各種 ERP）面臨類似但更複雜的挑戰。

一個典型的採購流程，可能長這樣：提出申請 → 部門主管核准 → 財務確認預算 → 採購部門詢價 → 提出採購單 → 副總核准 → 執行採購。

每一個步驟背後，都有對應的規則：誰可以核准、核准條件是什麼、核准者不在時誰可以代理。這些規則在傳統 ERP 系統裡，通常透過圖形化介面設定，且散落在多個不同的設定頁面裡。

要讓 agent 理解這個流程，一樣需要二樣東西：

• 一個可以描述業務語意的 metadata 層

• 一個可以執行每個步驟並取得結果的介面 (API 或 CLI)

SAP、Oracle EBS 等系統確實提供 API（如 SAP 的 BAPI、OData，Oracle 的 REST API），但這些介面的設計目標是系統整合，而非讓 agent 查詢「流程規則本身」。核准條件、代理邏輯等業務規則，覆蓋範圍不完整，或以不適合 agent 直接使用的格式儲存在系統內部。

圖形化介面是一道牆

正如〈AI, CLI 程式, 與 DSL〉一文裡談到的，CLI 和 DSL 對 AI 的重要性，是常常被低估的。一個只有圖形介面、沒有 CLI 的系統，agent 必須靠截圖、靠視覺理解、靠模擬滑鼠點擊，才能操作它。這個方法不只低效，而且非常脆弱。

過去三十年，企業軟體的設計哲學是：讓它盡可能地「好用」，意思是做成漂亮的圖形介面，讓不懂程式的業務人員可以輕鬆操作。

這個方向，其實在不知不覺間，把 agent 擋在了門外。

一個只有 UI 設定、沒有 DSL 的流程定義，agent 沒有辦法「閱讀」這個流程的規則，更沒有辦法「推理」在不同情境下應該怎麼處理。圖形化設計，這個本來為了讓人更容易使用而設計的思路，反而成了 agent 進入的門檻。

代理就緒的 BPM 或 CRM，應該是這樣的：

• 每一個業務流程，都有一個結構化的定義 (DSL)，可以用程式讀取

• 每一個操作，都有一個 API 端點或 CLI 可以呼叫，並且回傳清楚的成功或失敗訊號

• 每一個業務物件（客戶、訂單、採購單），都有清楚的 metadata，說明這個物件在這家公司裡代表什麼語意

這些條件，在大多數現有的企業系統裡，是不存在的。或者說，它們只存在於部分系統的 API 文件裡，但沒有被有意識地管理成 agent 可以取用的 context。

知識圖譜的困境與出路

如果說，讓整間企業變成 agent-ready，需要的是「一份完整描述企業所有知識的 context 庫」，那麼，這個概念其實並不新。

這正是知識圖譜（Knowledge Graph）一直在嘗試解決的問題。

知識圖譜的想法是：把企業裡所有的概念、物件、關係，用圖形的形式表示出來。「客戶」是一個節點，「訂單」是另一個節點，它們之間有一條「下訂」的邊。「產品」是節點，「分類」是節點，它們之間有「屬於」的邊。把這張圖建好了，理論上，任何問題都可以被回答。

但理論上和現實中，往往差距很大。

大型的企業知識圖譜，是出了名的難以建立、更難以維護。難在哪裡？

第一，企業知識不是靜態的。 客戶的定義會改變，業務流程會調整，組織結構會重組。一個需要人工維護的大型 KG，往往在建好的那一刻就已經開始過時了。

第二，跨部門的語意衝突很難解決。 「客戶」這個詞，在業務部、財務部、產品部，可能有完全不同的定義。在 CRM 裡，客戶可能是「曾經接觸過的潛在買家」；在財務系統裡，客戶可能是「曾經產生發票的付款方」；在產品資料庫裡，客戶可能是「有開通帳號的使用者」。要把這三個定義統一到一個知識圖譜裡，需要大量的溝通、談判和妥協。

第三，ROI 不明確。 知識圖譜的建立成本極高，但它創造的價值，很難被量化。這讓很多企業在投入初期預算之後，往往在專案中途放棄。

試圖在單一企業裡建立一個涵蓋所有知識的大型 KG，失敗的案例遠多於成功的案例。

聯邦式 Domain-Specific Context Layer

我認為，答案不是建立一個「超級知識圖譜」，而是建立一個多個 Domain-Specific Context Layer 的聯邦。

這個想法是：不要試圖用一個統一的圖譜描述所有知識，而是讓每一個 domain 負責自己的 context：

• 資料倉儲有資料字典，描述業務指標的語意

• CRM 系統有流程定義，描述銷售流程的規則

• ERP/BPM 有業務物件 schema，描述財務和採購的邏輯

這些 context layer 各自維護自己的領域，不需要強制統一語意。Agent 在需要時，透過 MCP（Model Context Protocol）或類似的協議，向各個 context layer 取用它需要的 context。

這個方式的優點是：每個 domain 的複雜度是可管理的，維護的責任是分散的，局部的更新不會影響整個系統。

但這個方式也有一個嚴重的限制：跨 domain 的推理。

想像一個問題：「這個客戶的採購訂單，是否符合我們的信用條件？」

這個問題，需要同時取用 CRM（這個客戶的歷史記錄）、財務系統（客戶的信用額度和付款記錄）、採購系統（這筆訂單的金額和條款）的 context，然後套用某個規則，做出判斷。

如果每個 domain 的 context layer 是獨立的，agent 要回答這個問題，必須分別從三個不同的 context layer 取得資訊，再把這些資訊整合在一起，套用跨 domain 的推理規則，得出結論。

這個推理步驟，是問題所在。 agent 可以嘗試自己推理，但當推理規則複雜、涉及多個 domain 的語意時，agent 很容易撞到能力的上限，產生錯誤的結論。

這裡就出現了一個不常被討論的技術需求：某種推理引擎，用來處理跨 domain 的推理。 Datalog 就是一種特別適合用來做推理的形式語言，若有先把「推導規則」顯式地定義出來，那 Datalog 查詢引擎就可以自動應用。

給定「客戶 A 的信用評級是 B+」、「信用評級 B+ 以上的客戶採購上限是一百萬」、「這筆訂單金額是八十萬」，Datalog 引擎可以自動推導出「這筆訂單符合信用條件」。

如果沒有這樣的推理引擎，靠 agent 做跨 domain 推理，agent 每次都要「自己想」，而且想的結果可能不穩定、不可解釋。有了推理引擎，複雜的跨 domain 規則可以被顯式地定義，推理的過程是可驗證、可稽核的。

這個方向，是接下來幾年，企業 AI 架構裡最值得關注的空白地帶之一。

壓力是真實的，挑戰也是真實的

回到最開始的問題：為什麼 coding agent 突然大量爆發？

因為軟體開發這個領域，剛好同時滿足了 agent-ready 的兩個條件：

1. Feedback 明確：有 compiler、有 test、有執行結果

2. Context 清晰：程式碼是 formal language，語意邊界清楚

模型到位了，環境也到位了，所以爆發了。

現在，模型繼續在到位。Claude Opus 4、Claude Sonnet 4.5、未來的模型，會持續地越來越強。但企業的其他領域，環境還沒有到位。

這是一個壓力很大、但挑戰也很真實的處境。

壓力很大，因為競爭對手可能比你更早把環境建好，讓 agent 在他那裡可以做你的工程師做的事。競爭對手一旦先就緒，它的執行速度就有機會大幅提高，而迭代加速常常就是一種競爭力。

挑戰很真實，因為建立 agent-ready 的環境，不是買一個軟體、裝一個插件就能完成的事情。它需要：

• 為系統建立可程式化的介面：API、CLI、DSL，讓 agent 可以操作和閱讀系統狀態，得到 feedback。

• 把業務語意結構化：哪些概念是重要的？它們的定義是什麼？這需要對業務有深度理解的人來做。

這兩件事裡，特別是後者，它絕對是「人的工作」。沒有辦法靠 AI 自動完成，因為它需要對這家企業的業務有深入的理解。

那麼，需要什麼樣的人？

這個人需要同時懂業務、懂技術、懂 AI 的能力邊界——甚至還要跨部門推動改變。

問題在於，這樣的人，多數的企業通常沒有。根本的原因是，多數企業的文化，也不會自然培養出這樣的人：業務端和技術端長期各自為政，AI 的理解又是另一個專業。這三者的交集，在組織內部幾乎不會自然形成。

這也是為什麼，想要快速跟上 agent 浪潮的企業，往往需要從外部引入專業人士的協助。