近一年來，AI Agent 幾乎成為企業導入人工智慧最熱門的關鍵字之一。從 OpenAI、Anthropic 到微軟與 Google，各家科技公司都在強調 Agent 將能協助企業執行工作、操作系統、處理流程，甚至逐步承擔部分知識工作者的日常任務，而這也是許多企業對 Agent 最感興趣之處。
相較於聊天機器人提供資訊查詢和內容生成，Agent 則更進一步，期待能直接參與工作流程，協助完成客服處理、報價作業、採購流程、專案追蹤、文件整理和跨系統操作等任務。換句話說，Agent 的價值不只在於回答問題，更在於推動企業內部流程自動化，讓工作更有效率。
當企業開始嘗試將 Agent 融入實際工作場景時，一個常被忽略的問題也慢慢浮現。企業流程之所以能順利運作，不完全依賴系統和文件，許多關鍵判斷其實來自長期累積的隱性知識。這些知識涵蓋了部門之間的協作習慣、例外處理原則、客戶分類方式、風險判斷標準，以及資深員工多年累積的寶貴經驗。這些知識可能沒有記錄在資料庫或 SOP 裡，卻對企業每天的運作方式有著深遠的影響。
因此，企業導入 Agent 的第一個挑戰，往往不在於學習哪一套開發工具，而在於如何在導入前整理這些知識，並在導入後持續維護與管理。這就像為 Agent 打造一個知識寶庫，讓它能更有效地協助企業運作，讓員工能更專注於創造價值，而不是花時間尋找資訊。
就在市場熱烈討論 Agent Framework、MCP 與工作流設計之際，Google 也趁勢推出 Open Knowledge Format（OKF）。Google 表示，OKF 是一套開放、不偏袒任何供應商，而且人類和 AI Agent 都能讀懂的知識格式，目的是幫助企業以方便攜帶、互相分享的方式描述資料、系統、指標、API、流程和業務背景。
從表面上看，OKF 就像是一套新的知識格式規範；但如果從產業發展的角度來看，它更像是一個重要的訊號：隨著 AI Agent 開始進駐企業，知識整理和知識治理正逐漸成為導入 AI Agent 的關鍵。
Agent 的自動化能力，取決於它理解多少企業脈絡
許多企業談到 Agent，第一個想到的就是自動化。想像一下，自動整理文件、回覆客戶、更新系統、產出報表、提醒異常，甚至協助內部人員完成跨部門作業，這些自動化的願景都令人振奮，因為它們都指向一個共同目標：讓 AI 幫助企業減少人力重複處理的工作流程。
然而，企業的流程並非只有重複處理的任務。以客服流程為例，表面上，它涉及識別問題、查詢訂單、回覆客戶，必要時還需要人工介入。但在實際運作中，客服人員會根據客戶等級、互動歷史、商品類型、活動規則、內部折扣標準以及品牌語氣做出判斷。這些判斷不一定都寫在系統裡，卻是讓客服流程順利運作的關鍵。
採購、業務、財務、人資、法務和專案管理也是如此。企業的每一個流程背後，都有一個由正式規則和非正式經驗交織而成的知識網絡。Agent 要融入這些流程，就必須理解這些脈絡。
如果 Agent 只知道操作步驟，卻不了解企業為什麼這樣做，它很容易把流程自動化變成錯誤放大器。因為速度變快了，錯誤也可能更快地擴散。因此，Agent 需要具備理解和適應這些脈絡的能力，才能真正提升企業的效率和品質。
最難被自動化的，常常是沒有寫進 SOP 的判斷
許多企業認為，只要將 SOP、產品手冊、客服話術和內部文件交給 Agent，就能開始推動流程自動化。這個想法雖然有其道理，但也容易忽略企業知識的複雜性。
企業流程中最重要的部分，往往不是已經寫下來的規則，而是那些尚未正式文件化的判斷。例如，哪些客戶可以破例處理？哪些供應商需要特別關注？哪些專案風險需要提前介入？哪些數字異常時需要主管確認？哪些狀況雖然符合系統規則，現場人員仍會選擇暫緩處理？
這些判斷通常來自資深員工多年累積的經驗，以及企業在市場中不斷調整後形成的工作默契。它們很少完整地寫進 SOP，卻經常決定流程能否順利完成。Agent 要真正參與企業流程，最困難的工作不只是理解文件，還要如何讓這些隱性知識被整理、維護和持續更新。這也是為什麼企業導入 Agent，不能只被視為技術專案，它同時也是一場組織知識整理工程。
Google 發佈 OKF，點出 Agent 落地前的知識問題
Google 這次發佈的 OKF 其指標性在於，Google 嘗試把已經在 AI 社群出現的 LLM Wiki 做法，整理成一套可交換、可移植、可互通的開放標準。它讓企業知識有機會以一種人類與 Agent 都能閱讀、交換與維護的方式被組織起來。
根據 Google 官方說明，OKF 的設計包含 Markdown 文件、YAML Frontmatter、目錄結構與文件之間的連結。每一份文件可以描述一個概念、一張資料表、一個指標、一組 API、一段流程或一項內部知識。這些文件再組成知識包，讓不同工具與 Agent 能夠取得一致的上下文。雖然這種設計看起來樸素，但卻很貼近企業導入 AI 的現實需求。因為企業並不是都需要更複雜的知識系統。很多時候，企業需要的只是一套清楚、可以管理版本、可移植、可以維護，也可以由 Agent 使用的知識表達方式。
同時 Google 也把 OKF 與 Knowledge Catalog 連結。Knowledge Catalog 被 Google 定位為能提供企業資料脈絡與治理能力的目錄系統，目的是讓 AI Agent 能建立在較可信的企業知識基礎上，而不是只依賴零散文件或即時搜尋結果。
從 Google 推出 OKF 的時機點來看，這項發佈也反映出產業開始重視 Agent 所需的知識管理與上下文問題。企業導入 Agent，會先碰到知識維護問題，即使企業完成第一輪知識整理，問題也不會就此結束，因為，企業知識不是靜態資產。產品會更新，價格會改變，法規會變動，組織會調整，客戶分群會重新定義，內部流程也會隨著管理需求而修正。當 Agent 開始依賴企業知識執行任務時，知識的維護頻率與責任分工就會變得更加重要。
因為，如果知識庫沒有更新，Agent 可能根據過期規則回覆客戶。如果權限沒有設計好，Agent 可能接觸不該接觸的敏感資訊。如果資料來源沒有標示清楚，企業就很難追蹤 Agent 的判斷依據。如果每個部門都用自己的方式維護知識，跨部門流程自動化就會再次卡住。
因此，Agent 導入後，企業需要的不只是一次性的知識整理，還需要有一套長期維護機制。誰負責更新？誰審核內容？哪些知識可以被 Agent 使用？哪些任務必須保留人工覆核？當 Agent 出錯時，如何回溯它使用了哪一份知識？
這些問題會讓企業意識到，AI 導入不只是資訊部門或數位轉型部門的事情。它會牽涉到業務、營運、法務、資安、人資與管理層共同參與。而 當Agent 越深入流程時，知識治理的需求，就越難以迴避。
新創機會可能藏在知識層的角落
對新創團隊來說，OKF 帶來的機遇不一定是要立刻圍繞 OKF 做產品，而是要重新思考 AI Agent 產業鏈中哪些環節正在產生需求。
過去很多 AI 新創都把重點放在使用者界面、聊天體驗、模型串接和單點工具上。但是隨著基礎模型能力越來越普及，這些表層功能會越來越容易被大型平台吸收。相對地，真正接近企業現場的知識整理、資料定義、流程建模和 Agent 部署，反而可能會形成更深層的服務門檻。
總之，新創可以藉由 OKF 切入的方向有很多，像是企業知識盤點工具、SOP 結構化平台、垂直產業知識圖譜、內部文件轉換服務、Agent 可用的上下文管理系統、資料目錄與權限治理工具，以及協助中小企業把現有文件轉換成 Agent-ready 知識庫的服務。這些產品可能沒有最炫的展示效果，但卻更接近企業願意持續付費的需求。因為，企業買的不是會聊天的 AI，而是能讓流程更順暢、更準確、更可控的工作能力。
如果新創能協助企業把散落在文件、系統和員工經驗中的知識整理出來，再讓 Agent 安全地接入流程，就可能成為 AI 落地過程中的關鍵角色。
Agent 時代，企業知識管理將迎來全新面貌！
過去，企業談到知識管理，通常會想到內部文件整理、員工教育訓練或是交接工作。這些當然很重要，但往往不太被視為緊急事項。然而，隨著 AI Agent 的出現，情況開始發生變化。
當企業希望 AI 參與流程時，知識管理就不再只是簡單地保存文件，而是影響自動化能否順利運作的關鍵基礎。如果知識管理不夠完善，Agent 也可能會跟著出現問題。知識過期了，Agent 也可能會沿用過時的資訊。如果沒有對知識的閱讀權限和責任進行設計，企業就很難信任 Agent 的執行結果。
AI Agent 的未來發展，不僅僅是看誰能開發出更多工具，更重要的是看企業能否將自身的知識整理成一個能讓人與機器共同使用的基礎設施。對於創業者、產品團隊和企業主管來說，這個訊息值得提前了解。因為在未來的幾年裡，企業導入 AI 的成效差距，很可能不僅僅來自於模型的能力，也將取決於企業對自身知識的掌握程度。
當 Agent 從展示走向部署，知識整理就不再只是後台工程，而會成為企業 AI 化的前置門檻。
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出