了解 AI Agent 技能：為什麼驗證安全至關重要
技能令 AI 變成主動操作者，但要在眾多工具間安全、範圍限定地管理憑證，使得驗證成為其中最困難的挑戰之一。
Product & Design
問題：只能對話的 AI
傳統的大型語言模型（LLM），如 ChatGPT 或 Claude，在理解和生成文本方面非常強大。但它們本身做不到：
- 從網絡存取即時數據
- 發送電郵或通知
- 將資訊儲存到資料庫
- 生成圖像或音訊
- 與外部 API 互動
AI agent 技能通過賦予 AI agent 必需的工具，解決了這個限制，令 AI agent 可以在現實世界中採取行動。
什麼是 AI agent 技能？
想像一下你有個私人助理，能管理電郵、更新試算表、跨不同平台發送訊息以及協調多個工具，而且無需你不斷監督。
這就是由技能驅動的 AI agent所能實現的。
技能是預建的整合，教導 AI agent 如何與特定服務互動。
簡單來說，技能 是一種結構化描述，指示 agent 如何 使用 API 以及可以執行哪些操作。
你可以把技能想像成手機上的 app，每一個都解鎖獨特能力，擴展 agent 可做的事。
- 通訊：Slack、Discord、電郵平台
- 開發：GitHub、GitLab、CI/CD 工具
- 數據：Google Sheets、資料庫、分析
- 創意：圖像生成、影片剪輯
- 生產力：項目管理、文件處理
毋須為每個整合苦寫自訂程式碼，只需啟用技能並提供所需憑證，AI agent 立刻便能使用該服務——連同內置錯誤處理和最佳實踐。
可以把 AI agent 當成一位極具智慧的員工。LLM（Claude、GPT 等）就是員工的大腦——負責推理、規劃和作決定。技能就是這個員工的工具和能力，令他能執行實際工作。
| Component | Analogy | Function |
|---|---|---|
| LLM | 員工的大腦 | 推理、規劃、決策 |
| 技能 | 工具及能力 | 執行動作、調用 API、處理數據 |
| Prompt | 任務分配 | 指定要完成的事項 |
**沒有技能：**只能討論任務的 AI
**有了技能：**能討論、規劃，並執行任務的 AI
AI agent 技能 vs. 函式調用 vs. MCP
理解 AI 工具整合的生態系統：
| Concept | Description | Scope |
|---|---|---|
| 函式調用（Function Calling） | LLM 原生功能，能調用預先定義的函式 | 單一 API 互動 |
| MCP（Model Context Protocol） | Anthropic 用以工具整合的標準協定 | 互通標準 |
| AI Agent 技能 | 預封裝、可投入生產的能力模組 | 完整整合方案 |
AI Agent 技能 = 函式調用 + 設定 + 認證 + 最佳實踐
技能把下列複雜問題抽象化：
- API 認證及 token 管理
- 錯誤處理與重試
- 限流及配額管理
- 回應解析與驗證
使用 AI agent 技能的好處
即插即用整合
無需從頭編寫整合程式碼。引用一個技能，提供憑證，即可馬上使用。
安全的密鑰管理
API 金鑰與 token 通過安全的環境變量（${{ secrets.API_KEY }}）管理，從不會暴露在代碼中。
組合性
可以將多個技能組合，創建複雜的自動流程。例如，一個新聞摘要 agent 會用到：
- hackernews → 抓取新聞
- elevenlabs → 產生語音
- notion → 儲存內容
- zeptomail → 發送通知
版本控制
可鎖定技能到特定版本以保穩定，也可始終追用最新版以獲新功能。
社群驅動
開源技能庫讓任何人都能貢獻新整合與改進。
認證的難題
這裡有個關鍵問題：AI agent 如何證明自己有許可權存取外部服務？
答案就是認證憑證，即授權你存取最重要系統和數據的數位鑰匙。
這些憑證的形式多樣：API key、用戶憑證、OAuth token，以及其他委派式存取機制。每一種都代表不同的信任模型與安全邊界。
挑戰在於，現代 AI agent 並非只調用單一 API，它們會統籌數十項服務、工具及跨環境整合。連線系統越多，要安全管理認證就越複雜。
以往一個簡單 secret，現時已變成分散式安全問題：
即自動化流程中，這些憑證如何發放、設定範圍、輪替、儲存及撤銷。
這正是大多數 agent 架構開始出現問題的地方，導致故障不在智能，而在身份認證與存取控制上。
憑證類型：你其實在保護什麼？
API 金鑰：靜態共用密鑰
定義：
API key 是用作驗證請求的靜態 bearer token。只需持有 key 就可存取服務。
技術特性：
- 預設長期有效或不會過期
- 通常以帳戶或專案層級定範圍
- 無內建身份綁定或會話資訊
- 無法分辨是人、服務還是自動化使用
安全性：
- 無內建輪替或到期強制
- 無天生支援細緻權限分離
- 一旦洩漏，必須手動輪替前都徹底失守
威脅模型：
影響範圍大。API 金鑰常通過日誌、前端代碼或 CI/CD 錯誤配置洩漏。
常見用途：
簡單服務整合、內部工具、舊式 API、初創開發者平台。
OAuth token：委派及範圍限定授權
定義：
OAuth token 是授權伺服器發出的短期憑證，代表用戶或應用已授權的存取權限。
技術特性：
- 有時間限制（幾分鐘至數天）
- 以範圍限定的授權模型
- 基於標準 OAuth 2.0 / OIDC Flow
- 可與用戶憑證獨立撤銷
安全性：
- 藉由範圍限制降低損害範圍
- 支援 token 輪替和刷新
- 專為第三方及交叉服務存取而設計
威脅模型：
風險中等。雖然作用範圍和有效期有限，但在高權限環境下仍屬敏感資料。
常見用途：
SaaS 整合、企業 SSO、面向用戶的 API、第三方 app 存取（GitHub、Google Workspace、Slack）。
個人存取令牌（PAT）：用戶範圍的自動化憑證
定義：
個人存取令牌是針對特定用戶身份發出的長期 token，適用於自動化和非互動式流程。
技術特性：
- 綁定用戶帳戶，非應用程序
- 通常手動建立與撤銷
- 大多支援細緻權限範疇
- 常用於 CLI 工具及 CI/CD pipeline
安全性：
- 可控性較 API key 高，功能卻比 OAuth access token 強
- 在無頭或共用環境下風險會增加
- 無自動選項的話多未設自動輪替或過期
威脅模型：
中至高風險。洩漏的 PAT 於其授權範圍內幾乎等同於用戶本人。
常見用途：
GitHub/GitLab 自動化、CI 流程、開發者工具、基建腳本。
安全認證的四大支柱
最小權限：只給最基本存取
憑證應當遵循最小權限原則，只授權完成任務所需的最少權限。
例如，社交媒體發布 bot 不應獲得刪除內容、查看分析或管理帳單的最高權限，而應僅獲准發佈內容，設下每日配額及有效期限。這樣即使憑證被洩漏，傷害也十分有限。
安全儲存：絕不硬編碼
| 不要做 | 要做 |
|---|---|
| 把憑證寫進原始碼 | 用環境變數 |
| 提交到 Git 倉庫 | 實施機密管理系統（如 HashiCorp Vault、AWS Secrets Manager） |
| 透過 Email 或 Slack 分享 | 憑證靜態加密存放 |
| 保存在明文檔案 | 儘可能使用臨時憑證 |
定期輪替：經常換鎖
即使你認為憑證沒有外洩，也要定期替換憑證。
建議頻率：
- **API Key（關鍵）：**每 30-90 天
- OAuth Token： 自動刷新
- 安全事件後： 立即更換
為什麼重要？能縮短被盜憑證的利用窗口，並強迫檢討哪些憑證仍有必要保留。
持續監控：保持警覺
監控憑證使用時，要關注可能濫用的異常行為，例如突然增加登入失敗、出現異地存取、API 叫用暴升，或試圖提升權限。比如，正常活動是一個已知辦公室 IP 於辦公時間內每日 1,000 次 API 呼叫；而可疑活動則是短時間內、夜深人靜從陌生國家發出數萬次請求。
主流認證解決方案
在 AI 驅動系統時代，token 及 API key 若散落在代碼、腳本和環境中，已不可接受。密鑰散佈不僅是不良習慣，更是安全風險。
現代認證平台以安全憑證儲存和密鑰管理功能來 應對這一問題。這類內建金庫讓敏感 token 能以加密方式存放、輪替，並於執行時安全存取，而非寫死或手動流轉。
供應商如 Auth0、Logto、WorkOS 都原生支援安全保存和管理憑證，方便你控制權限、減少機密洩漏及完善從服務到 agent 的生命週期管理。