知識與整合
Codeer 會用兩種方式接到你的業務：
- Agent 回答時會用到的知識
- 團隊或產品執行流程時會用到的整合
接進來的資料應該服務你要 Agent 處理的已驗證情境。資料不是越多越好。
以簡單客服 Agent 來說，第一批資料可能只需要包括：
- 第一批情境需要的核准政策或服務事實
- 超出第一版範圍時的 handoff 邊界
- 已核准動作情境需要的表單、API 或 channel 細節
這一段要幫你決定什麼
這裡其實只有兩個核心決策：
- 原始資料要放在哪裡
- 什麼時候需要整合，而不只是託管好的 channel
第一個決策發生在 Knowledge Base。第二個決策則是在某個已驗證情境證明 Agent 需要工具或 API 驅動流程時。
先想知識，再想整合
Knowledge Base 這一區有兩個主要用途：
Folders：整理 Agent 可能會用到的檔案Connections：查看外部帳號與連接來源
實務上，大多數 operator 平常主要都待在 Folders。
如果是產品或後端整合，分工會是：
- API Access：決定哪個 workspace 供整合使用並發出 key
- API Reference：讓工程團隊實作技術請求流程
給 operator 的實用判準
在你接任何資料前，先問三件事：
- 哪個已驗證情境需要這份來源？
- 這份知識是不是每一輪都一定要遵守？
- 它是不是只在某些情境下才需要？
- 這份來源現在夠乾淨，適合給 Agent 看嗎？
通常答案就會指向正確位置：
| 如果這份資訊是... | 最適合的位置 |
|---|---|
| 每一輪都必須遵守 | Instructions |
| 只在特定情境才需要查的參考資料 | Knowledge Base tool |
| 目前還很雜、重複多、噪音高 | 先整理乾淨，再接進來 |
| 需要由你自己的產品或後端來執行 | API Access 加 API Reference |
如果目前沒有已驗證情境需要這份來源，先不要放進來。等失敗 case 清楚顯示知識缺口時，再補。
資料應該被當成受管理的快照
接進來的檔案比較像是受管理的副本，不是會自動跟著外部來源變動的神奇同步。
當原始文件改了之後，請回頭判斷目前連進來的版本是否也該更新。