傳統知識庫為什麼撐不起Agent的“上下文”？

AI進入企業業務流程後，很多團隊都會遇到同一個問題：模型能從資料庫中找到相關內容，卻很難據此完成一項真實任務。

以設備異常處理、制度審核或客戶方案準備為例，Agent召回了文檔，並不代表它知道當前該用哪一版規則、這條經驗是否適用、誰應當確認，以及下一步能否執行。很多團隊因此不斷增加文檔、優化RAG，或在應用層拼接數據、提示詞和接口；系統看起來越來越複雜，但Agent依然缺少可用的業務上下文。

問題不只在檢索，而在於企業能否把原始證據、高頻經驗、項目狀態、責任關系和受控行動組織成一條連續的知識供給鏈。

本文解釋傳統知識庫為什麼難以支撐Agent的上下文，並拆解RAG、知識編譯、組織記憶、Skill與結果回流在一次真實任務中分別承擔什麼角色。對希望讓人、流程與Agent更順暢協同、逐步形成“超級組織”能力的企業而言，這是一項需要先補齊的基礎工作。

本文作者嚴超，360AI知識庫產品負責人。全文約5,500字，閱讀約需10分鐘。

01 Agent卡住的地方，不在“找不到文檔”

如果系統只給它幾段語義相近的文本，模型會自行補齊空白。它可能寫出一段很像專家意見的總結，卻未必知道這段經驗來自哪次項目，是否已被新制度替代；也未必知道當前任務是否允許它繼續調用業務系統，或修改結果。

因此，許多企業AI項目在演示階段很順利，進入生產後卻會被業務人員追問：“依據是什麼？”“為什麼是這一版？”“出了問題找誰？”

問題不在於召回文檔不夠多，而在於企業沒有把文檔背後的判斷條件與責任邊界一並交給Agent。

有人把上下文理解為“給模型更多材料”。這是一種常見誤解。

模型上下文窗口再大，也不應該把曆史郵件、會議記錄、制度文件和數據庫結果無差別裝進去。這樣做會增加推理成本和響應時間，也會帶來更多噪聲和更模糊的權限邊界。材料越多，模型越難判斷哪一條才是當前任務真正可以采用的依據。

企業需要的不是“大上下文”，而是一個圍繞任務組織的任務上下文包。它至少包含六類內容：

以現場異常診斷為例，系統不應把“所有設備文檔”交給模型，而應先收攏與本次告警相關的設備、工藝、批次、現行SOP和曆史案例；再過濾掉失效標準、無權資料和不適用案例；最後把處置依據、風險提示和需要人工確認的節點，組成一個可讀、可查的上下文包。

此時，Agent的回答有了明確的事實範圍、規則約束和責任邊界。

把它放到運行時，會得到一條更具體的裝配鏈路：

要理解Agent為什麼需要知識中樞，先要看任務所需的知識從哪裡來。檢索增強生成（Retrieval-Augmented Generation，RAG）擅長從海量原始資料中找回相關片段。它適合處理長尾問題，也適合在用戶需要核對原文、追溯細節時提供證據。

問題在於，原始材料通常沒有為某個具體任務預先組織好判斷條件。一段會議紀要可能記下了“客戶要求延期”，卻沒有把客戶背景、項目階段、承諾、風險和後續結果關聯起來；一份SOP可能有完整條款，卻沒有在檢索時自動表達哪一版有效、哪些設備適用、由誰負責發布。

因此，面向Agent的知識體系通常需要兩條並行鏈路：

在360AI知識中樞的產品設計中，這一過程被稱為“知識編譯”：在解析、智能分塊、摘要提取、標簽和向量化之外，再通過LLM Wiki（由模型輔助生成、保留來源與關聯的結構化知識頁）、場景模板、開放的結構化知識格式和本體等方式，將原始材料組織為更適合Agent調用的知識。

關鍵變化在於：知識不再只是原始文本，而是帶來源、對象、關系、版本和適用條件的可調用單元。

一份原始會議紀要可以只是一段文本；經過編譯的知識單元則會保留來源文件錨點，抽取主題、對象和關系，關聯版本與適用範圍，並為高頻問題沉澱可複用的知識頁或模板。資料更新後，相關知識單元也需要更新、廢棄或重新審核。Agent查詢時，不必從幾十篇會議紀要裡重新推理全部關系，而可以先定位到相應的組織記憶，再按需返回原始證據。

RAG與LLM Wiki不是替代關系。前者保證原始證據和長尾信息可被找回，後者提高高頻任務的上下文密度和可複用性。兩者共同組成“先有可靠知識，再有可靠回答”的供給鏈。

但這還不是幾項彼此獨立的能力。對於一次真實任務而言，RAG先找回原始依據，知識編譯再整理高頻規則和經驗；組織記憶補足項目狀態、責任和曆史決策；在人工確認後，Skill負責執行被授權的動作；最終結果經過審核後回流，成為下一次任務可用的知識。

它們前後接續，才構成Agent所需的完整上下文。

這正是“組織記憶”與“文件集合”的區別。文件集合回答“公司有哪些資料”；組織記憶嘗試回答“在當前對象、條件和風險下，公司過去是如何判斷和行動的”。

但這不意味著企業要把所有人的經驗都自動寫進知識庫。經驗必須經過來源約束、場景歸類、責任確認和持續評測。特別是在合規、質量、金融、政務等高風險場景，Agent可以協助歸納、發現沖突和生成草案，卻不應替代責任人確認標準或批準行動。

所以，組織記憶的形成，依賴企業把原本散落在個人、流程和系統中的Know-how，用可追溯的方式變成可複用的公共資產。

回到開頭的新能源制造場景。企業希望降低對少數專家的依賴：當設備報警、參數異常或批次問題發生時，一線人員能夠更快找到原因、處置依據和曆史經驗，並把處理結果沉澱為下一次可複用的知識。

這類任務的技術重點，是把分散的資料、規則和曆史案例組織為有順序的排查過程。

第一步是接入並識別對象。系統需要從MES告警、設備參數、工藝/機臺/批次信息、SOP和曆史案例中識別這次異常涉及的設備、工序、物料和風險點。此時，文檔解析、表格解析、結構化數據映射和實體識別都不是後臺細節，而是後續判斷能否成立的基礎。

第二步是建立關聯與範圍。同一個參數異常在不同工藝、不同批次、不同版本規範下，處置方式可能不同。系統需要把報警與當前適用的標準、相似案例、已知風險和責任角色關聯起來，並過濾掉已失效或不適用的內容。

第三步是給出受控建議。Agent的輸出應包括已發現的關聯事實、優先排查步驟、有效SOP、相似案例結果、待確認條件和建議決策人。

系統最終交給工程師的，應當是一份可以繼續處理的工作底稿，而不是一句“根因就是某個參數”的結論。

第四步是讓結果回流。現場專家或維修班組完成處理後，工單、最終原因、處置結果和驗證結論不應只留在某次溝通中。經過審核後，它們可以回寫為案例知識，使下一次檢索不必從零開始。

如果工程師確認需要推進後續動作，Agent才在授權範圍內調用Skill（可被Agent調用的受控業務能力），例如創建工單、提醒負責人或提交審批。它不能因為“知道了問題”就自行修改工藝參數或關閉異常。

系統可以推薦排查順序、引用現行標準、生成處置草案；但它不應越過現場複核直接判定根因、修改工藝參數或關閉異常。這個邊界決定了Agent是可靠的協作工具，還是不可控的自動化風險。

這是一條典型的知識閉環：每次輸入都服務於當前任務；經過確認的輸出，則成為下一次任務可複用的起點。

前面討論的是一次異常任務如何獲得上下文。最後再看，這些步驟在知識中樞中分別由什麼能力承接。

產品架構不應是一張能力菜單。對於開頭的現場異常任務，讀者更關心的是：告警進入後，哪些系統負責識別對象，哪些知識可以被引用，誰能批準下一步動作，結果怎樣留下。

在這條鏈路中，360AI知識中樞首先接入告警、工單、文件和業務數據，並識別其中的設備、批次、項目、負責人等業務對象。知識解析、加工與編譯能力把文檔、表格、音視頻和結構化數據整理為可理解、可關聯的知識單元，為後續任務提供有效證據。

當Agent開始處理任務時，系統再結合版本、權限、密級和任務範圍過濾候選信息，避免失效資料、無權內容或不適用的經驗進入上下文。知識治理則持續處理重複、過期、沖突和需要回流的內容。

在人工確認後，Agent可以通過Skill調用已授權的API和專業方法，創建待辦、提交審批或生成業務草案；處理結果再按規則保存為臨時產物、候選知識或正式知識。

其中，“讀取知識”“調用工具”“回寫結果”是三類不同操作。讀取時要校驗知識範圍與版本；調用工具時要校驗執行權限和審批條件；回寫時要確定結果屬於臨時工作產物、候選知識還是正式知識。將它們分開設計，才能避免Agent拿到信息後默認擁有全部行動權限。

在這個意義上，知識中樞的價值不在於層數更多，而在於每一步都能回答：輸入從哪裡來、系統做了什麼、誰對結果負責、出現問題如何回到源頭。

建設知識中樞時，最容易犯的錯誤是把目標定成“一次性接入全域數據”。企業內部的數據量巨大，部門和業務線複雜，且不同知識的質量、責任、權限和更新頻率完全不同。大而全的起步通常會讓項目陷入材料清洗和口徑爭論，遲遲無法驗證業務價值。

更合適的起點，是選擇一個同時滿足四個條件的場景：高頻、價值明確、決策鏈較清楚、結果可回流。會議記憶、項目複盤、合規審核、現場故障診斷、銷售報價都可能成為切口。

以會議記憶為例，企業不必先整理所有會議。可以先從一個明確的經營主題或項目群開始，圍繞“事實、決策、承諾、變化、經驗”建立最小知識模型：哪些會議能進入範圍、哪些結論需要確認、誰負責更新、哪些待辦需要追蹤、上層Agent如何調用。這樣既能驗證知識提煉是否有效，也能把治理責任和權限邊界提前暴露出來。

知識中樞不是一個一次性交付的項目，而是一項持續的知識工程。先讓一個場景跑出“接入—提煉—調用—反馈”的閉環，再擴展到更多對象和業務域，通常比先追求知識數量更穩妥。

傳統知識庫幫助員工找到公司資料；面向Agent的知識中樞，要進一步把資料背後的事實、關系、版本、權限、任務狀態和行動邊界組織起來。

這並不要求企業先建一個無所不包的“企業大腦”。它要求企業在具體場景裡回答幾個更樸素的問題：哪些知識是真正的依據？誰對它負責？它適用於什麼條件？Agent可以據此做什麼？結果又如何回到組織中？

當這些問題有了工程化答案，Agent才不必在每次任務裡重新翻資料、猜口徑、問同事。它能在企業給定的上下文中工作，給出有來源的建議，完成受控的動作，並把新的結果沉澱為下一次可複用的經驗。

這或許才是知識中樞的意義：把企業過去難以傳承的判斷能力，變成可以持續積累、共享和調用的基礎設施。

如果企業準備從一個具體場景開始，建議先選定一種任務，明確它依賴的權威來源、責任人和權限邊界，再定義哪些結果允許回流為組織知識。本文討論的是如何把這些內容裝配成上下文；當上下文進入審核、決策和執行流程後，版本、權限、證據與反馈如何被工程化，將是下一篇討論的主題。

當人的經驗、業務流程和Agent產出能夠持續匯入同一套可治理的知識體系時，企業沉澱的就不只是答案，而是一種能被更多人和更多Agent共同調用的判斷能力。