Knowledge Base
當 Agent 需要查的是穩定的參考資料，而不是最新外部資訊時，就用 Knowledge Base。
以 Consultation Desk 為例，Knowledge Base 很適合放服務定義、分流規則、收案注意事項，或交接邏輯這類希望每次都一致的內容。
正式的來源清單、支援格式、直接上傳單檔 50 MB 限制與處理方式，請看 支援的來源與檔案格式。
先選對資料位置
可以用這個簡單判斷：
| 如果這份知識是... | 建議放這裡 |
|---|---|
| 很小、每一輪都必須遵守 | Instructions |
| 要看情境查找的參考資料 | Knowledge Base |
| 從 CSV、XLSX 活頁簿或 Google Sheet 精確查資料列、篩選、排序或計算 | 透過 Knowledge Base 自動發現；來源必須固定時使用 Tabular Data Tool |
| 今天可能會變的公開資訊 | Web Search |
步驟 1：先整理一個聚焦的資料夾
先在 workspace 裡準備一個乾淨、主題明確的資料夾，再把需要的文件放進去。
好的 Knowledge Base 內容通常有三個特徵：
- 主題夠聚焦，查詢時比較不會撈到雜訊
- 給維護的人更新起來不費力
- 內容是 agent 真的會反覆查的
如果原始資料很鬆散，先整理成濃縮版本，通常會比直接丟大量原始素材更好。
步驟 2：在 Agent Editor 加入 Knowledge Bases
回到 Editor，在 Tools 裡按 Add Tool，選 Knowledge Bases，再勾選這個 Agent 可以使用的資料夾或檔案。
Knowledge Base 只看同一個 workspace 的內容
如果你在 Tool Picker 裡看不到想要的資料夾，先檢查它是不是建在別的 workspace，或是資料夾裡目前還沒有可用檔案。
自動發現表格資料
如果選取的 Knowledge Base 裡有已可使用的 CSV、XLSX 或 Google Sheets，而且 Agent 沒有明確設定 Tabular Data Tool，它就能自動尋找並查詢相關資料表。有多個合理候選時，Agent 會先請使用者確認。
來源必須固定且可預測時，請使用明確設定的 Tabular Data Tool。只要加入任何明確的表格資料工具，就會停用該 Agent 的自動發現，因此不會 fallback 到 Knowledge Base 裡的其他資料表。
步驟 3：把 When to Use 寫窄一點
要讓 Agent 知道，它在什麼問題上應該先查這份知識。
例如：
Use this knowledge base when the user asks about consultation types, routing rules, or handoff expectations that should stay consistent across conversations.
這種寫法會比下面這種有效得多：
Use the knowledge base when needed.
步驟 4：用 Live Test 驗證檢索是否合理
拿幾個明顯應該查 Knowledge Base 的問題來測：
Initial Consultation 跟 Specialist Consultation 的差別是什麼？什麼情況下 Consultation Desk 應該改建議真人回電？
檢查兩件事：
- Agent 有沒有真的去查 Knowledge Base
- 回答是不是忠於文件內容，而不是自己補完
操作建議
- 如果不同類型知識差很多，拆成不同資料夾通常會比較好查
- 一個乾淨的資料夾，通常比一個什麼都丟的大資料夾更好維護
- 如果某條規則每一輪都必須遵守，它應該直接寫在
Instructions，不要只藏在檔案裡 - 重要文件更新後，記得用真實問題再測一次
常見錯誤
把所有文件都塞進同一個資料夾
這通常會讓檢索結果變吵，也更難除錯。
拿 Knowledge Base 查最新資訊
如果答案會因為日期而改變，應該用 Web Search。
用文件檢索做精確表格計算
如果答案取決於精確資料列、篩選、排序、計數或彙總，請把已可使用的資料表放在 Agent 設定的 Knowledge Base，讓它自動發現。只有來源必須固定時，才使用明確的 Tabular Data Tool。
把核心規則只放在檔案裡
如果某條規則每次都必須成立，它也應該出現在 Instructions。