企業智慧體系統：從 AI 助手到可治理、可執行的 Agent 團隊

過去，企業引入 AI 的方式通常是增加一個聊天視窗：員工輸入問題，模型給出回答；市場團隊用它寫文案，客服團隊用它回覆常見問題，管理者用它總結檔案。這些用法有價值，但它們大多停留在個人效率層面。AI 幫助員工完成一項任務，卻未必改變企業任務如何被組織、交接、執行和衡量。

企業智慧體（Enterprise Agent）帶來的變化，是讓 AI 從一個被動響應的工具，逐步成為能夠理解目標、讀取授權上下文、規劃步驟、呼叫工具、協同其他 Agent，並在明確邊界內完成任務的業務參與者。它可以參與工作，但不應該脫離業務責任和治理機制獨立行動。

真正的企業智慧體系統，不是把幾十個機器人放在一個介面裡，而是把企業知識、資料、業務應用、流程、人員和 AI 能力組織成一套可管理、可審計、可評估、可持續改進的執行體系。

企業 Agent 正在加速採用，但組織準備度仍然不足

McKinsey 與 Deloitte 的樣本、定義和調查範圍不同。40%指大型企業受訪者報告規模化 Agent；其餘三項來自 Deloitte 對美國500多名企業與 IT 領導者的調查。

生成式 AI 首先改變了資訊工作的方式：閱讀、總結、寫作、翻譯、研究和創意。隨後，模型開始透過工具訪問檔案、搜尋資訊、呼叫 API、更新業務記錄。Agent 的關鍵變化不只是能夠使用工具，而是能夠圍繞目標動態決定下一步需要什麼資訊、選擇什麼工具、如何處理結果，以及何時需要暫停或請求人工介入。

McKinsey 2026 年調查顯示，80%的受訪者認為 AI 提升了個人工作效率，但只有37%的受訪者表示 AI 已對企業 EBIT 產生一定影響。這兩個指標衡量的不是同一件事：個人效率改善，並不自動意味著企業流程、收入結構或經營結果已經改變。

企業需要的不是把每個員工的聊天視窗升級成更復雜的聊天視窗，而是重新設計一部分值得改變的工作流程，讓 AI 能夠在真實業務上下文中完成明確任務，並把結果交還給負責的人員和業務系統。

行業對 Agent 的定義並不完全統一。Anthropic 對 Agentic Systems 的一種實用區分是：Workflow 透過預先定義的程式路徑組織模型與工具；Agent 則允許模型在任務執行過程中動態決定步驟和工具使用。實際產品可以把兩種方式組合起來。

這不是一條必須逐級升級的產品路線。簡單任務不需要 Agent；穩定且可預測的任務通常適合 Workflow；只有當任務需要動態判斷、探索或根據結果調整步驟時，才值得引入 Agent。Anthropic 也建議從最簡單、足夠可靠的方案開始，不要為了追求“智慧體”概念而增加不必要的複雜度。

因此，企業設計 Agent 的第一步，不是問“要建立幾個 Agent”，而是問“這個業務任務的輸入是什麼、需要做出什麼判斷、可以呼叫哪些工具、結果由誰負責”。

通用聊天機器人可以理解自然語言，卻通常缺少企業獨有的產品事實、客戶上下文、流程規則和系統狀態。它可能知道如何寫一份報價說明，卻不知道企業當前的價格版本、客戶折扣許可權、庫存情況、審批人和合同約束。

• 缺少業務上下文 — 企業產品、客戶、合同、價格、庫存、服務政策和歷史記錄分散在不同系統。

• 缺少系統連線 — 無法可靠查詢或更新 CRM、ERP、訂單、專案、財務和內容平臺。

• 缺少任務狀態 — 不知道一項任務已經由誰處理、停在哪裡、是否失敗或是否需要繼續。

• 缺少許可權邊界 — 無法僅憑一句自然語言判斷使用者是否有權讀取、修改或批准某項業務資料。

• 缺少結果驗證 — 生成一段回答不等於業務系統已經完成操作，更不等於目標已經實現。

• 缺少持續治理 — 模型、提示詞、工具、知識、版本和成本變化需要持續管理。

企業 Agent 必須在企業授權的上下文中執行：知道自己代表哪個應用、哪個使用者或服務身份；能夠訪問哪些知識和工具；哪些操作只讀、哪些可以寫入；哪些必須等待人工批准；任務完成後如何記錄結果。

企業 Agent 不是一段 Prompt。它是一個由職責、上下文、知識、工具、執行策略和治理機制共同構成的系統物件。不同業務可以採用不同實現方式，但至少需要明確以下要素。

1. Role & Instructions｜角色與職責 — 明確 Agent 服務誰、負責什麼、哪些事情不負責，以及任務完成的標準。

2. Context｜業務上下文 — 提供當前專案、客戶、產品、任務、時間和使用者意圖等相關資訊。

3. Knowledge｜企業知識 — 透過授權檢索獲取產品資料、業務規則、文件、FAQ 和經過確認的事實。

4. Memory｜持續上下文 — 在授權範圍內保留必要的互動歷史、偏好、任務狀態或長期專案上下文；不能把所有資料混成一個無限記憶庫。

5. Tools & Connections｜工具與連線 — 透過受控介面查詢客戶、建立線索、讀取訂單、生成內容或提交審批。

6. Workflow & Orchestration｜流程與協同 — 管理步驟、條件、任務分派、Agent 交接、審批和異常分支。

7. Runtime & Harness｜執行環境 — 管理狀態、超時、重試、預算、暫停恢復、執行記錄和工具呼叫。

8. Governance & Evaluation｜治理與評估 — 管理身份、許可權、質量、安全、成本、審計、版本和人工接管。

這些要素並不意味著每個 Agent 都需要複雜的多 Agent 框架。一個專門查詢產品資訊的 Agent 可能只需要檢索、許可權和清晰輸出格式；一個負責跨系統處理客戶投訴的 Agent，則需要任務狀態、工具呼叫、審批、異常處理和更嚴格的評估。

當一個任務涉及多個專業領域時，可以由一個 AI Manager 或 Orchestrator 負責理解目標、拆解工作、分派給專業 Agent、整合結果並向負責人彙報。專業 Agent 可以分別承擔市場研究、產品、銷售、內容、客服、資料分析或運營職責。

這種結構的重點不是讓每個 Agent 都擁有完整的自主權，而是讓它們在清晰的職責邊界內協作。研究 Agent 可以提供帶來源的市場結論；銷售 Agent 可以讀取經授權的客戶記錄並準備跟進建議；內容 Agent 可以根據品牌規範起草內容；釋出動作則由流程和授權人決定。

多 Agent 協作必須有明確的任務契約：輸入是什麼、輸出格式是什麼、需要哪些證據、能呼叫哪些工具、失敗時如何返回，以及由誰接收結果。沒有這些規則，Agent 數量越多，反而越容易出現重複勞動、互相矛盾和責任不清。

企業 Agent 系統需要連線 AI 技術、資料智慧和業務應用，但三者必須分工清楚。否則會出現重複維護客戶資料、業務狀態不一致、AI 越權修改交易資料等問題。

BASE 提供 Agent 執行能力，但具體業務應用可以自己擁有 Agent 定義、Prompt、Workflow 和業務上下文；對於沒有獨立管理後臺的輕量應用，也可以選擇由 BASE 託管 Agent 配置。這兩種模式可以共存。

同樣，Knowledge 與 Memory 也要區分：Knowledge 是可以檢索的企業資料和事實；Memory 是經過授權的持續互動和任務上下文。客戶訂單和財務交易仍然應由業務系統儲存，不應因為 Agent 需要上下文就複製到一個不受控制的記憶庫。

AIEASE 的這一架構原則是：BASE 提供能力，不接管業務；業務應用擁有自己的業務邏輯和資料；Runtime 負責執行；DI 提供研究、證據與分析。這樣既能共享底層能力，也能讓不同企業、產品和行業保持自己的業務邊界。

企業 Agent 最容易發生風險的環節，不是生成一段文字，而是執行寫操作。例如建立客戶、修改訂單、釋出內容、傳送郵件、調整價格或觸發支付。模型給出的建議不能直接變成資料庫修改。

更可靠的執行方式，是把 Agent 的意圖轉換成結構化 Action，再由業務應用和策略層判斷是否允許執行。只有在身份、許可權、引數、業務規則和必要審批全部滿足後，才透過正式工具或業務介面完成操作，並返回可追溯的執行回執。

1. Request / Event — 來自使用者指令、定時任務或業務系統訊號。

2. Context & Plan — 讀取授權的企業知識、當前任務狀態和相關業務記錄，形成執行計劃。

3. Proposed Action — 生成結構化動作，包括操作物件、引數、目標系統和預期結果。

4. Identity & Policy Check — 驗證使用者或服務身份、App、Scope、資料範圍、風險等級和業務規則。

5. Approval Gate — 涉及高風險、不可逆或對外承諾的動作時，等待授權人員批准。

6. Tool Execution — 透過受控 Tool、Connector 或 Domain Adapter 呼叫業務系統，不允許任意 SQL 或任意 HTTP 寫入。

7. Receipt & Outcome — 儲存執行記錄、業務系統返回狀態、錯誤、操作者、審批和後續結果。

這條鏈路的關鍵，是把模型推理與業務執行分開。Agent 可以提出動作，但動作是否被允許、由誰執行、何時執行、結果是否成功，都必須由明確的系統規則和責任人管理。

Agent 獲得的許可權越大，潛在收益和風險也越大。企業不應把“能夠呼叫工具”理解為“可以呼叫所有工具”，也不應把“能夠自動執行”理解為“無需審批”。許可權設計應該從最小必要訪問開始，並根據任務風險逐步開放。

• 身份與歸屬 — 明確 Agent 代表哪個使用者、業務應用或服務身份執行，禁止身份混用。

• 最小許可權 — 只開放任務所需的資料和工具；區分讀取、建立、修改、刪除、傳送和支付等許可權。

• 人工審批 — 對付款、退款、價格調整、合同、重要對外發布和敏感資料匯出設定審批門檻。

• 資料隔離 — 按客戶、專案、應用、部門和角色控制訪問範圍，避免跨租戶或跨專案洩露。

• 審計與追蹤 — 記錄輸入、上下文來源、工具呼叫、策略結果、審批人、執行回執和模型版本。

• 異常與回滾 — 處理超時、重複執行、工具失敗、錯誤引數和業務衝突；可逆操作優先設計撤銷或補償流程。

• 成本與質量 — 監控模型呼叫、工具次數、執行時長、失敗率、人工接管率和任務完成質量。

OpenAI 的企業 Workspace Agents 文件展示了一個具體的治理實踐：連線應用時可以選擇使用者身份或 Agent 自有身份；寫操作預設要求執行過程中詢問；還可以為特定工具動作增加約束。NIST 的生成式 AI 風險管理框架則提供了跨行業的風險識別與治理參考。它們都說明，許可權與責任必須成為 Agent 系統的一部分，而不是上線後再補充。

企業不應該把所有流程都改造成 Agent。Agent 不是比 Workflow 更高階的萬能替代品。選擇架構時，需要考慮任務是否存在不確定性、是否需要動態規劃、是否需要跨系統獲取資訊，以及出錯後可能產生的後果。

Agent 系統通常會增加模型呼叫次數、執行延遲和執行成本，也可能帶來更難預測的錯誤。因此，設計目標不是最大化自主性，而是在任務價值、準確性、速度、成本和風險之間找到合適的平衡。

一個實用的判斷方法是：如果流程可以用清晰規則穩定完成，就優先用 Workflow；如果必須根據中間結果動態決定下一步，且這種靈活效能夠帶來足夠價值，再考慮 Agent。

這些場景的共同點，是 Agent 並不替代企業現有系統，而是成為連線資訊、人員和系統的智慧協作層。CRM 仍然管理客戶記錄，ERP 仍然管理訂單和庫存，財務系統仍然管理真實交易；Agent 負責理解任務、呼叫授權能力並推動流程前進。

企業 Agent 專案不應該從“先建設一個多 Agent 平臺”開始。更穩妥的方式，是選擇一個真實、頻繁、價值明確且風險可控的流程，先建立基線，再逐步擴充套件。

1. 選擇業務流程 — 找到人工耗時高、資訊分散、重複性強或響應速度影響客戶體驗的流程。

2. 定義成功指標 — 記錄當前處理時間、準確率、人工介入、轉化率、錯誤成本和客戶體驗。

3. 梳理資料與系統 — 確認資料來源、業務記錄所有者、API、工具許可權和例外情況。

4. 設計 Agent 邊界 — 明確角色、輸入、輸出、工具、許可權、禁止事項、審批和失敗處理。

5. 建立評估集 — 用真實但經過脫敏或授權的代表性任務，覆蓋正常情況、邊界情況和困難例外。

6. 小範圍上線 — 先在一個團隊或流程中執行，保留人工複核和快速回退機制。

7. 監控與持續改進 — 跟蹤質量、延遲、成本、任務完成率、異常、使用者採用和真實業務結果。

8. 複製成功能力 — 把成熟的 Agent、Skill、Workflow、聯結器、評估集和運營經驗沉澱為可複用能力。

評估不能只看 Agent 回答是否流暢。還要看它是否找對資料、呼叫正確工具、遵守許可權、處理異常、把任務交給正確的人，以及業務系統是否真正完成了預期操作。一次成功演示不能替代生產環境中的持續評估。

當企業流程複雜、資料分散、系統環境獨特，或現有標準產品無法可靠完成任務時，企業可能需要 FDE（Forward Deployed Engineering，前沿部署工程）方式。FDE 讓工程人員與業務團隊共同識別關鍵流程、連線系統、構建 Agent、驗證質量並進入生產環境。

Microsoft 在2026年10月對 FDE 的觀察指出，FDE 正從單一工程崗位擴充套件為小型跨職能交付團隊，涵蓋軟體與 AI 工程、領域專家、資料、流程、交付管理和安全治理。其目標不只是交付一個原型，而是重構關鍵流程、建立生產級系統，並把能力轉移給客戶團隊。

FDE 並不是所有 Agent 專案的預設模式。簡單問答、內容生成和成熟產品已經能夠可靠完成的任務，優先使用標準能力即可。只有當業務上下文、系統整合、流程重構、生產可靠性或組織採用成為關鍵障礙時，才值得進行深入工程部署。

AIEASE 的企業 Agent 體系不是讓每個客戶重複建設一套模型、Agent Runtime 和工具平臺，而是以 BASE 提供共享 AI 能力，以業務應用擁有自己的業務上下文和資料，再根據企業複雜程度連線 DI、Workflow、業務系統與長期運營能力。

對於業務應用，AIEASE BASE 同時支援 App-owned Agent 和可選的 BASE-managed Agent：成熟業務系統可以在自己的後臺管理 Agent、Prompt 和業務流程，再呼叫 BASE 的執行能力；輕量應用則可以選擇由 BASE 託管配置。這樣既保持業務所有權，也避免重複建設通用技術底座。

對於長期運營專案，可以由 AI Manager 作為主要互動入口，協調產品、營銷、銷售、客服和資料等專業 Agent。專案目標、任務、審批、操作記錄和結果反饋由業務運營系統管理，業務系統繼續儲存真實的客戶、訂單和交易事實。

企業不缺少可以回答問題的 AI 工具。真正稀缺的是能夠理解企業上下文、連線業務系統、在許可權邊界內執行任務，並持續驗證結果的智慧化工作體系。

未來企業的競爭優勢，不會來自部署了多少 Agent，而來自哪些工作流程被重新設計、哪些業務知識被沉澱、哪些任務能夠穩定協作完成，以及組織是否能夠持續管理和改進這些能力。

Agent 是新的工作參與者，Workflow 是組織執行的路徑，業務應用是事實與交易的載體，治理機制是信任的基礎。只有這些要素共同工作，AI 才能從個人效率工具走向企業生產力系統。