內部文件讓 AI Agent 來查，之前要先決定什麼能引用

先把文件分成「可對外說」和「僅供內部整理」

不是所有內部資料都該進 Agent 的檢索範圍。已核准的服務說明、公開流程、標準 FAQ，比較適合作為回答依據。還在討論中的草案、未公布的價格策略、個別客戶的特殊條件，頂多讓人在覆核時參考，不該直接變成對客文字。混在一起的結果通常是：Agent 把內部討論當成既定政策。

每一份可引用資料都要有主人。產品說明是誰更新、退換貨規則是誰核准、過期誰下架。沒有主人的文件，最後會變成「大家都覺得應該還對」。Agent 一引用，錯的內容就會被複製到更多對話裡。

常見的衝突是官網寫七天鑑賞、倉庫 SOP 寫拆封不退、客服群組又流傳一版主管口頭答應的例外。人遇到還會去問；Agent 可能三份都讀到，然後產出一個聽起來折衷、但其實誰都沒核准過的說法。這種時候缺的不是更大的模型，而是先指定哪一份才是對外依據。

• 可引用：已核准、有日期、有負責人的文件與系統欄位
• 僅內部：草案、談判空間、未公開成本與例外承諾
• 禁止：來路不明的截圖、過期表單、個人筆記本

引用要看得見，覆核的人才敢放行

知識型 Agent 若只給一段通順說明，覆核者很難判斷它是讀到了正確段落，還是把兩份文件拼在一起。較能用的輸出是：答案、依據文件、該段更新日期，以及有沒有找不到依據的部分。找不到就該明說，而不是用語氣補齊。

即時性資料也不該靠文件硬查。訂單是否已出貨、剩餘堂數、預約是否額滿，應打進授權系統看當下狀態。文件負責穩定規則，系統負責當下事實。兩者角色反過來，過期 PDF 就會開始「查庫存」。

AgentTech 會把知識檢索設計成 Agent 的一種工具，而不是讓模型在所有上下文裡自由發揮。它要查規定時才呼叫已核准的知識集合；要查訂單時走系統查詢。工具分開，之後要抽換來源或停用某一批文件，才不會動到整條流程。

更新流程比第一次匯入更重要

第一次整理文件很累，但還能靠專案撐過去。難的是下個月價格改了、退貨條件改了，知識集合有沒有跟著改。若更新仍靠有人想起要重傳檔案，Agent 會在最不該錯的時候用舊規定。

比較能維持的做法是：對外有效的規則只活在一個地方，例如正式知識庫或系統設定，再同步給 Agent。不要官網一份、客服一份、資料夾再一份。同步可以分期，但來源要先指定。誰改了正式內容，誰就觸發一次知識更新與抽樣檢查。

抽樣不必天天做。每週抽幾筆高頻問題，看引用的是不是最新版本，通常就夠讓問題提早出現。發現過期引用，先下架該文件再談是不是要微調提示詞。順序反過來，模型會更努力把舊內容講圓。

知識 Agent 可以起草，不一定能直接對客

即使來源乾淨，涉及承諾的句子仍建議經過人。例如能不能客製、能不能提早交付、違約怎麼算，文件裡可能有原則，個案仍要判斷。Agent 的價值是把相關段落找出來、標出缺漏，讓人在較短時間內做決定，而不是替公司做決定。

這點和客服自動回覆不同。自動回覆處理的是已核准、低風險、可完整引用的內容；知識 Agent 常被拿來處理比較長、比較像在「查規定」的問題。兩者可以共用知識來源，但送出權限不該自動視為相同。

第一批知識不必多，但要能代表真實會被問的事

不要從「把所有歷史檔案向量化」開始。先列出過去一個月真正被問、而且有正式答案的二十到四十題，把對應文件整理到可引用狀態，再讓 Agent 只在這個集合裡找。範圍小，錯了找得到；範圍一開成整個雲端硬碟，錯了只能說模型有時會幻覺。

驗收時用真實問法，不要只用文件標題。客戶很少說「請引用退貨政策第三條」，他們說「拆過能不能退」。若 Agent 找不到，應回報缺文件，這本身就是知識缺口清單，也比硬答更有用。