知識與整合
Codeer 會用兩種方式接到你的業務：
- Agent 回答時會用到的知識
- 團隊或產品執行流程時會用到的整合
資料接上之後，Agent 才會從一個客氣但泛用的回答者，變成真正建立在你業務規則上的入口。
對 Consultation Desk 來說，這些資料通常包括：
- consultation 類型與服務定義
- 分流規則與升級邊界
- intake 需要掌握的重點
- 必須保持一致的政策或 handoff 細節
這一段要幫你決定什麼
這裡其實只有兩個核心決策：
- 原始資料要放在哪裡
- 什麼時候需要整合，而不只是託管好的 channel
第一個決策發生在 Knowledge Base。第二個決策則是在你把資料接進 Instructions、Attachments、Knowledge Base tool，或 API 驅動的流程時。
先想知識，再想整合
Knowledge Base 這一區有兩個主要用途：
Folders：整理 Agent 可能會用到的檔案Connections：查看外部帳號與連接來源
實務上，大多數 operator 平常主要都待在 Folders。
如果是產品或後端整合，分工會是：
- API Access：決定哪個 workspace 供整合使用並發出 key
- API Reference：讓工程團隊實作技術請求流程
給 operator 的實用判準
在你接任何資料前，先問三件事：
- 這份知識是不是每一輪都一定要遵守？
- 它是不是只在某些情境下才需要？
- 這份來源現在夠乾淨，適合給 Agent 看嗎？
通常答案就會指向正確位置：
| 如果這份資訊是... | 最適合的位置 |
|---|---|
| 每一輪都必須遵守 | Instructions 或 Attachments |
| 內容較大，只在特定情境才需要查 | Knowledge Base tool |
| 目前還很雜、重複多、噪音高 | 先整理乾淨，再接進來 |
| 需要由你自己的產品或後端來執行 | API Access 加 API Reference |
資料應該被當成受管理的快照
接進來的檔案比較像是受管理的副本，不是會自動跟著外部來源變動的神奇同步。
當原始文件改了之後，請回頭判斷目前連進來的版本是否也該更新。