為什麼「一直加 Agent」會越做越亂？
很多企業導入生成式 AI 的第一步，是從幾個聊天機器人、客服助理、內部 Copilot 開始。接著需求變多，就把 Agent 一個個堆上去：行銷一個、法務一個、採購一個、工程一個。短期看似效率提升，但半年後常見狀況是：
- 功能重疊：不同團隊各自做「摘要」「翻譯」「比對」「寫信」，同樣能力重複開發。
- 成本飆升：每個 Agent 都要維運 prompt、工具、權限、觀測、模型設定。
- 治理失控：資料來源不一致、引用不可追溯、權限外洩風險擴大。
- 交付不穩：同一問題在不同 Agent 得到不同答案，品質難以標準化。
核心問題在於：把 AI 當成「一個個應用」在堆，卻沒有把可重用能力抽象成「企業資產」。
這也是「AI Skills 架構」想解的題：把能力做成可組裝、可治理、可量測、可複用的技能庫，讓每次投入都能複利。
什麼是 AI Skills？和 Agent、Workflow 有何不同
- Skill（技能）：一個可重複使用的能力單元，輸入/輸出清楚，可被不同情境呼叫。例如「合約條款風險標註」「根據公司口吻改寫 Email」「從 ERP 取特定欄位並生成報表」。
- Workflow（流程）：把多個技能串起來完成一個任務，例如「收集需求 → 查詢庫存 → 計算交期 → 寫回覆信」。
- Agent（代理）：帶有目標與自主規劃能力的執行者，會自行決定要用哪些工具/技能、怎麼走流程。
重點不是「不要 Agent」，而是避免「把所有能力都做進 Agent 裡」。在企業場景更務實的做法通常是：
以 Skills 當底座（可治理、可複用），Workflow 做交付（可控、可驗證），Agent 用在需要探索或彈性決策的環節（可選、可收斂）。
技能庫思維：把能力做成產品，而不是一次性專案
要讓 AI 成為可複利資產，技能庫需要具備「產品化」特徵：
- 穩定介面：清楚定義輸入、輸出、錯誤碼、版本。
- 可觀測：每次呼叫的成本、延遲、成功率、命中率、引用來源都可追。
- 可治理：權限、資料邊界、審計與合規能被套用到每個技能。
- 可替換：模型可換、提示可調、工具可替代，不影響上層應用。
這會直接改變組織的交付方式：不再是「某部門做一個聊天機器人」，而是「共用技能由平台團隊維護，各部門在同一套能力上快速組裝自己的流程」。
一個實用的企業級 AI Skills 架構（由上而下看）
以下是一個常見且好落地的分層方式，你可以視公司成熟度取用：
1) 體驗層：使用者入口不必只有聊天
企業落地的入口可能是：客服後台、CRM、Slack/Teams、工單系統、ERP 表單、瀏覽器外掛等。重點是：入口多元，但呼叫同一套技能，避免每個入口各做一套。
2) 協調層：把「任務」拆成可控步驟
這層負責把需求轉成流程（可用規則 + 小幅度智能）：
- 決定要呼叫哪些技能
- 何時要人工確認（Human-in-the-loop）
- 何時要轉交真人
- 失敗重試、降級策略（例如改用較便宜模型或改成檢索式回覆）
在這裡你可以用 workflow engine、簡單的狀態機、或有限制的 agent（例如只能在白名單技能內選擇）。
3) 技能層：企業可複用能力的核心資產
典型技能可以分成幾類，便於管理：
- 文字與內容技能：摘要、改寫、風格校正、雙語轉換、FAQ 生成。
- 知識檢索技能（RAG）：資料切分、索引、引用回傳、來源可信度標註。
- 資料操作技能：查詢資料庫/ERP/CRM、欄位映射、計算與彙整。
- 決策輔助技能：風險提示、規則比對、異常偵測、政策/合約條款檢查。
- 動作技能（Action）：建立工單、寄信、產生報價單、更新 CRM。
每個技能都應該有「契約」：
- Input schema（必填欄位、格式、限制）
- Output schema（結構化輸出，盡量避免純自然語言）
- Policy（可用資料範圍、是否可寫入系統、是否需審核）
- SLA/SLO（延遲、可用性、成本上限）
4) 資料與工具層：把資料邊界做對，技能才會可靠
企業 AI 失敗常不是模型不夠強，而是：
- 資料品質不一、版本混亂
- 權限控管做在應用端，導致漏洞
- 沒有引用與可追溯性
建議把以下能力放在共用層：
- 企業身分與權限（RBAC/ABAC）與資料列級權限
- 文件來源治理（單一事實來源、有效期限、版本）
- 向量索引與檢索策略（含同義詞、分類、權重）
- 工具連接器（DB、CRM、Ticket、Email…）與審計紀錄
5) 治理與營運層：讓 AI 能上線、能長期維運
企業級技能庫要能回答三個問題：
- 誰做的、誰負責？（Owner、維護人、值班）
- 現在表現如何？（品質、成本、成功率、使用率）
- 出了事怎麼查？（輸入、引用、工具呼叫、輸出、決策路徑）
落地要件包括：版本管理、A/B 測試、灰度發布、提示與模型變更審核、稽核報表，以及敏感資料遮罩與 DLP。
從「用得快」到「用得久」：技能設計的 6 個實戰原則
1) 先結構化輸出，再談生成文字
– 例如先輸出 JSON：風險等級、條款編號、建議動作，再由前端組合成易讀文字。
2) 把 prompt 當程式碼管理
– 需要版本、審核、回溯；不要把關鍵 prompt 埋在某個人的聊天紀錄。
3) 把檢索與生成分開評估
– RAG 問題常出在檢索命中率與切分策略，不是模型「不會答」。
4) 技能要能被測試
– 建立測試集：常見案例、邊界案例、反例；每次改版自動跑評測。
5) 預設會失敗：設計降級與防呆
– 工具呼叫失敗怎麼處理？引用不足是否改為「請補資料」而不是硬編？
6) 把成本當成產品指標
– 每次呼叫成本、每件任務成本、每月成本上限；才能避免「用越多虧越多」。
對不同角色的影響：技能庫會改變工作分工
- IT / 平台團隊：從做專案轉向做「AI 平台產品」，負責技能框架、權限、觀測、發布流程。
- 各業務單位：更像在「選配能力」組流程；需求描述會從「做一個聊天機器人」變成「我要一個可審計的報價生成流程」。
- 法務/資安/稽核：治理可下沉到技能層，減少每個應用重做審查；但也需要更早介入規格（例如哪些技能允許寫入系統）。
- 資料團隊：資料目錄、資料品質與版本會更重要，因為它直接影響技能可用性與可信度。
你一定會遇到的限制與爭議：先講清楚比較不會踩雷
- 「技能太多」的新型複雜度：技能庫不是越多越好，缺少分類與淘汰機制會變成技能墓場。
- 過度追求通用：技能抽象過頭，反而難用；建議 70% 共用 + 30% 情境化，並以版本管理而非硬塞參數解決。
- 模型幻覺與責任歸屬：即使有引用，仍可能推論錯誤；高風險場景要有人審核、要有可追溯紀錄。
- 資料外洩與權限繞道：如果技能能查資料又能生成回覆，最容易把不該看的人能看的資料「講出來」。必須做列級權限、輸出過濾與審計。
- 供應商鎖定：技能契約若綁死特定平台或模型 API，後續換供應商成本高。介面標準化、抽象化是關鍵。
入門落地路線圖：用 30 天做出「可複用」的第一批技能
第 1 週：盤點高頻任務，選 3 個共用技能
– 標準：跨部門可用、資料來源相對清楚、可量測成效。
第 2 週：定義技能契約與權限邊界
– 把輸入/輸出結構、引用規則、允許的工具、是否可寫入系統一次講清楚。
第 3 週：建立觀測與評測
– 至少做到：成本、延遲、成功率、引用來源、錯誤類型；並有小型測試集。
第 4 週：用 workflow 串出 1 個可上線的流程
– 先讓流程「可控、可驗證」，再逐步引入 agent 的彈性。
當你能把第一批技能做成可重用、可監控、可治理的資產，後續每個新需求就不是「再做一個 Agent」，而是「組裝既有技能 + 補一個缺口技能」，複利才會開始。
結語：把 AI 當資產管理，才能真的規模化
Agent 很吸引人，因為它看起來像「全能員工」。但企業真正需要的是：可被治理的能力、可預測的交付、可量測的成效。AI Skills 架構把重心放在「能力單元」與「企業級營運」，讓 AI 不只會做事，還能被組織長期、穩定地使用與擴張。
如果你正卡在「越做越多、越用越亂」，從技能庫開始重整，比再堆一個更聰明的 Agent 更可能帶來長期回報。
追蹤以下平台，獲得最新AI資訊：
Facebook: https://www.facebook.com/drjackeiwong/
Instagram: https://www.instagram.com/drjackeiwong/
Threads: https://www.threads.net/@drjackeiwong/
YouTube: https://www.youtube.com/@drjackeiwong/
Website: https://drjackeiwong.com/
