AI Agent 掌握專業領域完整方法

官方 Agent Skills 架構把能力拆成 3 個載入層級：啟動時只載入約 100 tokens 的中繼資料，觸發後再讀取主要指令，需要時才讀取參考檔案或執行程式碼。(platform.claude.com) 這說明一件容易被忽略的事：只做 RAG 不等於 AI Agent 掌握專業領域。你需要讓 Knowledge Base 負責「知道什麼」、Agent Skills 負責「怎麼做」、工具呼叫負責「實際操作」，再用評估集確認結果是否可靠；四層缺一，領域 Agent 就很難穩定部署。

這篇適合正在開發專業領域 Agent 的 AI 工程師、需要沉澱內部 SOP 與動態知識的平台團隊，以及準備把 Agent 放進持續運行環境的專案負責人。如果你只想讓模型回答一般問題，本文的權限與驗收部分可以先略讀；如果 Agent 會接觸企業資料、修改系統或執行部署，則不應跳過。

先劃清四層能力的責任邊界

專業領域 Agent 常見的失敗，不是模型完全不會回答，而是不同責任被塞進同一個提示詞、知識庫或 Skill，最後沒有人知道錯誤究竟來自資料、流程、工具還是評估方式。

可以先用下面的分工建立架構：

• Knowledge Base：保存可追溯的事實、規範、案例、版本與來源。
• Agent Skills：描述穩定的工作流程、條件判斷、輸出格式與檢查規則。
• 工具呼叫：查詢系統、建立檔案、執行程式、提交變更或觸發外部服務。
• 評估集：測試知識問答、流程執行、拒絕邊界、過期內容與工具故障。

官方文件將 Skill 定義為可重複使用的領域專業資源，內容可包括指令、工作流程、參考資料和腳本；這種設計與單次對話提示詞不同，適合把組織內的做事方式長期封裝起來。(platform.claude.com)

Knowledge Base 和 Agent Skills 有什麼區別？

Knowledge Base 是「證據層」，回答某項規則、參數或事實目前是什麼；Agent Skills 是「流程層」，規定遇到特定任務時先做什麼、何時分支、如何檢查與用什麼格式交付。前者應保留較完整的原始內容，後者則應保持精簡，避免把整個知識庫複製進 Skill。

第一步：建立可追溯的 Knowledge Base

先不要急著收集大量文件，應從一個邊界清楚的專業領域開始，例如 CI/CD 事故處理、企業內部帳號申請、設計檔案交付或伺服器維運。

每份資料至少保留以下欄位：

• 文件名稱與所屬領域。
• 原始來源與負責人。
• 生效日期、版本與預計下次檢視日期。
• 適用範圍，例如開發環境、正式環境或特定部門。
• 權限等級與可被哪些 Agent 使用。
• 已知限制、例外條件與衝突文件。

檢索結果不能只回傳一段看似合理的文字，而要能回到原始證據，例如文件名稱、章節、段落或資料表欄位。否則你無法分辨 Agent 是真的找到規範，還是依照模型自身的訓練知識猜測。

注意： 動態事實不應固化在長期不更新的 Skill 中。價格、服務狀態、部署版本、庫存、權限名單和當日排程，都應優先從可更新的 Knowledge Base 或即時工具取得。

領域知識應該放 RAG 還是 Skill？

會變動、需要引用原始證據、可能由不同團隊維護的內容，放進 RAG 或其他 Knowledge Base；穩定的操作順序、判斷條件、輸出格式和驗收規則，才適合寫入 Skill。若一段內容既包含事實又包含流程，應拆成「引用資料」與「執行規則」兩部分，而不是整段塞進同一個檔案。

第二步：把 SOP 封裝成 Agent Skills

一個可維護的 Skill，不是「請以專業方式完成任務」這種抽象提示，而應該像一份新進工程師可以照著執行的工作指引。

建議用以下結構撰寫：

1. 觸發條件：什麼任務或關鍵情境才使用這個 Skill。
2. 輸入要求：缺少哪些欄位時必須先追問。
3. 執行流程：依序列出查詢、判斷、工具呼叫和檢查。
4. 分支條件：哪些情況走一般流程，哪些情況必須拒絕或升級。
5. 輸出格式：固定欄位、格式、引用方式和錯誤說明。
6. 驗收規則：什麼結果才算完成，什麼結果只能標記為待人工確認。

官方建議 Skill 保持精簡，因為主要指令載入後會與系統提示、對話內容和其他能力共同競爭上下文空間；詳細參考資料、範例與腳本可以分開存放，按需讀取。(platform.claude.com)

Skill 只引用所需知識，不要把整個 Knowledge Base 複製進去。這樣做有兩個好處：資料更新時不必同步修改大量 Skill；流程改版時，也不會意外改動原始規範。

第三步：為工具呼叫設定權限與失敗路徑

工具呼叫是 Agent 從「回答問題」走向「執行任務」的分界，也是風險最高的一層。你至少要把工具分成四類：

• 只讀：查詢工單、讀取監控、取得文件或檢查部署狀態。
• 可寫入：建立草稿、更新標籤、寫入待審核紀錄。
• 可執行：執行測試、建置程式、重啟服務或提交部署。
• 需審批：刪除資料、變更正式環境、發送外部通知或使用高權限憑據。

每個工具的輸入與輸出都應結構化。不要只回傳「操作完成」；至少要包含 status、operation_id、changed_items、error_code 和 next_action 等欄位，讓 Agent 能判斷成功、失敗、部分完成或需要人工介入。

工具伺服器也不能只依賴模型自律。工具規格應驗證輸入、執行存取控制、限制呼叫頻率、清理回傳內容，並記錄使用紀錄；涉及敏感操作時，應提供人工確認。相關工具規範也明確要求客戶端驗證結果、設定逾時並保留稽核紀錄。(modelcontextprotocol.io)

專業 Agent 的工具權限應該如何設計？

可以採用「預設只讀、逐步升級」：第一階段只允許查詢，第二階段允許建立草稿，第三階段才開放可寫入或可執行工具；任何會影響正式環境、外部使用者或不可逆資料的動作，都要停在人工確認之前。

若工具透過標準化協定連接外部服務，授權應綁定具體資源與範圍，不要把一組可跨服務重用的高權限憑據直接交給 Agent。授權規範也要求伺服器驗證存取權杖、避免將不適用的權杖轉交下游服務，並使用安全的重新導向與權杖管理流程。(modelcontextprotocol.io)

第四步：建立能抓出錯誤的領域評估集

「Agent 看起來回答得不錯」不是驗收標準。你需要建立固定題目，讓每次 Knowledge Base、Skill、工具或模型更新後，都能比較基線是否變好。

最小評估集至少包含五類：

1. 知識問答：答案是否引用正確版本與原始證據。
2. 流程執行：是否依照 SOP 完成步驟，而不是跳過必要檢查。
3. 邊界拒絕：資料不足、權限不足或任務超出範圍時，是否正確拒絕。
4. 過期資訊：舊版本文件與新版本文件同時存在時，是否選用有效內容。
5. 工具故障：工具逾時、回傳格式錯誤或部分成功時，是否停止、重試或交由人工處理。

測試案例不要只收集正常路徑。以運維 Agent 為例，除了「查詢服務狀態」外，還要測試無權限帳號、監控資料延遲、服務名稱不存在、重啟操作被拒絕等情境。

如何驗證 AI Agent 真的掌握專業知識？

至少要同時檢查「答案正確」、「證據可追溯」和「行動符合規則」。只測問答準確率，會漏掉錯誤工具呼叫；只測任務成功率，則可能掩蓋 Agent 使用了過期資料或越權執行。

第五步：處理更新、衝突與過期知識

知識更新不是單純重新切分文件。你應該先定義誰負責確認內容、多久檢視一次，以及衝突發生時哪一份資料優先。

建議採用以下更新順序：

1. 由資料負責人確認新規範或新版本。
2. 更新 Knowledge Base 的來源、版本、生效日期和權限。
3. 重新執行過期資訊與衝突內容測試。
4. 判斷變更是否影響 Agent Skills 的流程或輸出格式。
5. 若流程受到影響，再修改 Skill 並建立新版本。
6. 重新執行完整評估集，通過後才推送到部署環境。

如果只是服務端點、操作參數或政策內容變動，通常先更新 Knowledge Base；如果步驟順序、判斷條件或審批規則變動，才需要同步修改 Skill。不要因為文件更新就直接重寫所有 Skill，否則很難追蹤錯誤來源。

經驗： 每次更新都要留下變更說明，並保留可回滾版本。Agent 失效時，能快速回到上一個通過評估的版本，比在生產環境臨時修改提示詞可靠得多。

第六步：用清單完成部署前驗收

在把領域 Agent 放進持續運行環境前，你可以按以下項目逐一確認：

• [ ] 每份核心資料都有來源、版本、負責人與更新日期。
• [ ] 動態事實沒有被硬編碼到長期不更新的 Skill。
• [ ] Skill 明確列出觸發條件、輸入要求、分支規則與輸出格式。
• [ ] 只讀、寫入、執行和審批工具已分開授權。
• [ ] 高風險動作在執行前一定會要求人工確認。
• [ ] 工具回傳包含成功、失敗、部分完成與下一步欄位。
• [ ] 評估集涵蓋正常路徑、過期知識、錯誤流程和工具故障。
• [ ] 憑據沒有直接寫入提示詞、Skill 檔案或日誌。
• [ ] Agent、Knowledge Base、工具和評估集都有可追蹤版本。
• [ ] 伺服器隔離、日誌、狀態恢復與並發限制已完成測試。
• [ ] 低風險內部輔助與外部自動操作採用不同的上線門檻。
• [ ] 任一核心元件升級後，都會重新執行固定評估集。

Agent 設定本身也應被視為可版本化的部署資產，因為它通常同時包含模型、系統提示、工具、外部連線與 Skills；只更新其中一層而不重新驗收，容易造成「文件已更新、流程未更新」或「工具權限已改、評估仍沿用舊規則」的狀況。(platform.claude.com)

放在結尾前的方案選擇：本地、雲端與臨時環境

如果你目前使用的是共享本地環境，常見問題是權限邊界不清、測試結果難以重現，以及 Agent 執行期間容易受到個人設定或其他程式干擾；若改用一般雲端伺服器，又可能遇到 Mac 工具鏈相容性、圖形介面操作和硬體驗證不完整等限制。對於短期建立領域 Agent、測試工具呼叫或驗收部署流程的團隊，租用 ZavCloud 的 Mac 環境通常比立即購買設備更容易控制前期成本與試錯範圍；你可以先參考 ZavCloud Mac 雲端租用服務，再按照隔離、日誌、憑據和狀態恢復條件評估是否適合。

如果你的工作是長期穩定重負載、需要實體介面，或必須讓設備常駐企業內部網路，自購 Mac 仍可能更合理；若只是需要臨時算力、跨平台測試環境或部署驗收節點，則不必一開始就承擔完整硬體與維護責任。環境建好後，還應配合 ZavCloud 幫助中心確認遠端連線、檔案管理與使用限制，並在正式導入前保留一個可回滾的驗收版本。

真正可交付的專業領域 Agent，不是把更多文件丟進 RAG，也不是把更多指令塞進 Skill，而是讓知識、流程、操作權限和評估結果彼此對得上。當你能回答「這個答案來自哪裡」、「這個步驟為何這樣做」、「這個工具可以改動什麼」以及「更新後是否仍然通過測試」，Agent 才算具備可部署、可維護和可驗收的專業能力。