AI 103 · 模組 5
從「有資料」到「Agent 知道如何使用資料」
開始第一節前面的單元讓 Agent 能找到正確的一小段知識。但一位新進員工拿到完整的公司手冊，並不代表他已經會處理客訴。知道「有什麼規定」和知道「怎麼做這件事」是兩回事。
有 Knowledge Base 就等於 Agent 有能力完成工作嗎？答案是：不是。
資訊
Knowledge Architecture 是替 Agent 所需的知識做整體規劃：知識從哪些來源來、分成哪些層次、用什麼形式存放、由誰維護。
| 知識類型 | 例子 | 變動頻率 | 常見形式 |
|---|---|---|---|
| Policies | 請假辦法、資料使用規範 | 低到中 | 文件（非結構化） |
| SOPs | 客訴處理流程 | 中 | 文件（非結構化） |
| Domain Knowledge | 產業術語、法規背景 | 低 | 文件、詞彙表 |
| Examples | 合格報告範本、好的回覆範例 | 低 | 文件、範本 |
| Historical Cases | 過往客訴案件與處理結果 | 持續增加 | 表格、紀錄（結構化） |
| Live Data | 庫存、今日價格、訂單狀態 | 很高 | 資料庫或系統資料（結構化） |
Structured Knowledge（結構化）有固定欄位，適合精準查詢與篩選；Unstructured Knowledge（非結構化）如文件與文章，需要靠切分與檢索。實務上常把知識分層：穩定的原則放上層，經常變動的資料放下層並即時取得。
資訊
下列三項，哪一項最像 Skill，而不是 Knowledge？
知識庫裡的內容並不都同樣可信。Agent 要能判斷「該相信哪一個」，人也要事先為它設計這個規則。
| 概念 | 問題 | 例子 |
|---|---|---|
| Trusted Source | 這個來源是否經過授權與審核？ | 人資部發布的正式辦法，勝過群組裡轉傳的截圖 |
| Source Authority | 兩個來源衝突時，以誰為準？ | 正式公告優先於會議紀錄，會議紀錄優先於個人筆記 |
| Knowledge Freshness | 資訊多新？多久需要更新？ | 價格表每天更新，組織章程可能數年不變 |
建議為每一類知識指定一位負責人、更新頻率，以及發生衝突時的優先順序。這些規則寫下來，Agent 才有依據，人也才知道出錯時該找誰。
注意
知識庫中，正式公告與一份舊的會議簡報對同一項規定說法不同。最合適的做法是什麼？
Agent Skill 是把「如何完成某一類任務」整理成可重複使用的設計。好的 Skill 讓不同的人、不同的次數，都能得到穩定一致的做法，而不是每次重新想一遍提示詞。
一個「客訴分析 Skill」可以整理案件、歸納原因並草擬回覆；但涉及賠償金額的決定，邊界是「交給人核准」，Skill 不能自行下結論。
注意
一個「客訴分析 Skill」被設計成可以自動核准退款金額。這個設計最大的問題是什麼？
一個完整的 Skill 可以用七個部分描述。Agent Skill Card 就是把這七個部分整理成一張讓人能審閱的卡片。
| 部分 | 內容 |
|---|---|
| Purpose | 整理一則客訴，歸納原因並草擬回覆建議 |
| Instructions | 先確認事實，再對照政策，最後分類嚴重程度並草擬回覆 |
| Required Context | 客訴內容（已去識別）、訂單狀態、客服語氣準則 |
| Knowledge | 現行退款政策、客訴 SOP、過往類似案例 |
| Tools | 訂單查詢（唯讀） |
| Output Format | 事實摘要、原因、建議回覆、需人工審核事項 |
| Verification | 核對政策版本與引用來源；涉及賠償由人核准 |
一張 Skill Card 有 Purpose、Instructions 與 Output Format，但沒有 Verification。最大的缺口是什麼？
完成
| Knowledge | Skills | |
|---|---|---|
| 回答 | What to know | How to perform a task |
| 例子 | 政策、SOP、案例、即時資料 | 客訴分析、報告審閱、研究流程 |
| 要留意 | 來源權威性與新鮮度 | 邊界、輸出格式與驗證 |
| 誰負責 | 知識的負責人與維護者 | Skill 的設計者與審核者 |
Agent 現在有 Memory、Knowledge 與 Skills。但資訊越多，並不代表表現越好。下一個單元要問：這麼多資訊，該在什麼時間，把哪些交給 Agent？
