架構解析： 別把 Agent Skills 當“工具函數”，它是一套“能力系統”
Hello folks，我是 Luga。今天我們來聊聊大語言模型（LLM）在 AI 應用中的關鍵支撐組件——Agent Skills。
在過去兩年中，“AI Agent”幾乎成為所有智能系統討論的中心詞匯。然而在大量實踐中，一個反復出現的困惑是：模型已經足夠強大，Agent 卻依然“做不好事”。究其根本，問題并不出在模型推理能力本身，而在于系統層面對“能力”的組織方式。
這正是 Agent Skills 概念的由來。
如果說大模型提供的是通用認知能力（General Intelligence），那么 Agent Skills 解決的，則是如何把這種能力結構化、約束化、工程化，使其在真實系統中可被調用、組合、治理與演進。
從架構角度看，Agent Skills 并不是 Prompt 的集合，而是 Agent 操作系統中的“能力指令集”。
本文不談 Prompt 工程，也不講 LangChain 使用，而是從平臺架構師視角，拆解如何構建一個安全、可靠、可觀測的 Agent Skills 體系?！?/p>
一、架構視角： Skill 不是“函數”，而是“語義能力載體”
眾所周知，在傳統軟件架構中，我們習慣了這樣的交互模式：調用方 → [API 接口] → 返回數據。
然而，這種模式有個隱含前提：調用方知道自己要什么。開發者編寫代碼時，清楚地知道要調用哪個接口、傳什么參數、返回什么格式。
但 LLM Agent 不一樣，它面對的是模糊的自然語言意圖，需要在運行時動態理解“用戶想干什么”，然后選擇合適的能力去執行。這就像讓一個只會看說明書的人(傳統程序),突然要去理解客戶的口頭需求并自主決策。
這種差異導致了根本性的架構矛盾：
- LLM 的世界是概率性的、語義化的、容錯的
- IT 系統的世界是確定性的、結構化的、嚴格的
Skill 架構要解決的，就是如何在這兩個世界之間建立穩定的橋梁。在生產系統中，一個 Skill 不應被理解為“可調用代碼”，而應被視為一個自包含的架構單元（Architectural Primitive）。
一個工程級 Skill，至少應包含三層定義：
1. 語義層：Semantic Manifes （給 LLM 看的）- 不是接口文檔，是認知協議
傳統 API 文檔告訴你"怎么調用"，而語義層要解決的是"為什么調用"和"該不該調用"。這不是技術接口，而是認知接口——它讓 LLM 理解這個能力的業務價值和使用邊界。
這是 Skill 的認知接口，而非技術接口。通常而言，此層往往會回答如下三個問題，具體如下：
(1) 問題 1：這個能力解決什么意圖？不是簡單描述功能，而是明確業務場景。例如：
- 錯誤示范："查詢用戶信息接口"
- 正確示范："當需要獲取用戶的實名認證狀態、會員等級或聯系方式時使用，適用于客服場景和風控審核"
(2) 問題 2：什么情況下不應該用？（反向意圖）明確能力邊界，避免 LLM 的誤用。例如：
- "此接口不適用于批量數據導出（超過100條請使用批量接口）"
- "不應在用戶未授權的情況下調用敏感字段"
- "當只需要驗證用戶是否存在時，使用輕量級的 checkUserExists 接口"
(3) 問題 3：使用它的最佳上下文是什么？給出具體的使用場景和前置條件，讓 LLM 知道"在什么劇本里扮演什么角色"。
如下為典型的內容結構：
Semantic Manifest = {
Intent: 明確的業務意圖
Anti-Intent: 明確的禁用場景
Constraints: 調用約束（權限、頻率、數據量）
FewShotExamples: 典型使用示例
RiskWarnings: 潛在風險說明
Prerequisites: 前置條件檢查項
}在實際的業務場景中，很多團隊把 Skill 說明寫在 System Prompt 里，這是架構上的退化。正確的做法是：
- 語義層必須是獨立的元數據管理單元
- 支持版本化、可索引、可動態加載
- 能被 Skill Registry（技能注冊中心）統一管理
- 可以根據上下文動態選擇性暴露給 LLM
這樣做的好處是：當你有 100 個 Skill 時，不會把所有說明都塞進 Prompt，而是讓 LLM 先通過元數據檢索找到相關 Skill，再加載詳細的語義定義。
一句話總結：Semantic Manifest 必須是結構化元數據，而不是散落在 Prompt 里的自然語言。
2. 執行層：Execution Runtime（給系統跑的）- 不只是業務代碼，是安全防線
執行層看起來是"干活的代碼"，但在 Agent 架構中，承擔著更重要的職責：對抗 LLM 的不確定性。
通常而言，LLM 可能給出模糊參數、可能重復調用、可能觸發危險操作，執行層必須是一道堅實的防線。其核心設計責任涉及如下幾個層面：
- 參數校驗與語義映射
- 冪等性保證
- 重試與降級
- 副作用邊界控制
- 協議轉換
一句話總結：執行層必須對 LLM 的不確定性具備防御能力。
3. 感知層：Observation Interface（反饋給 LLM）- 從"數據返回"到"認知反饋"
大部分團隊認為"API 返回了數據就算完成了"，但這對 LLM 來說是災難性的——它看見了一堆 JSON，卻不知道這意味著什么。
因此，從架構層面而言，感知層不是簡單的字符串拼接，它需要：
- 上下文感知：知道當前對話的目標是什么
- 業務規則引擎：判斷什么是"正常"什么是"異常"
- 動態模板：根據數據特征選擇合適的反饋結構
- 可追溯性：保留原始數據的訪問路徑（可供深入查詢）
傳統軟件架構關注的是"正確性"和"性能"，而 Agent Skill 架構還要關注"可理解性"和"意圖對齊"。這不是三個獨立的模塊，而是一個完整的認知-執行-反饋閉環。缺少任何一層，Skill 都只是一個脆弱的工具調用，而無法成為 Agent 真正的"能力單元"。
二、安全邊界：Agent 時代的零信任執行模型
在 Agent 時代，我們必須假設 AI 可能被誘導、被欺騙、或產生意外行為。因此，安全機制不是"錦上添花"，而是系統架構的基石——每一個 Skill 執行，都必須經過身份驗證、權限控制和行為約束。
1. 身份傳播：OBO 模式是底線
通常而言，在 Agent 系統中，Skill 本質上不是“能力”，而是“代執行者”。一旦 Agent 被允許以自身身份調用 Skill，系統就已經失去了“責任主體”的錨點。
因此，在架構層面必須明確一個不可妥協的前提：Agent 不應、也不能擁有任何業務權限。所有 Skill 的執行行為，都必須被嚴格建模為 On-Behalf-Of（OBO）模式，即：
這意味著，每一次 Skill 調用在技術上都必須滿足以下條件：
從架構實現角度看，這要求 Skill Runtime 與 OAuth2 / OIDC 進行深度集成，而不是簡單“接入認證”：
- Token 的簽發、透傳、刷新、吊銷必須是系統級能力
- Skill 不得自行生成、緩存或放大權限
- Agent 不得擁有任何“特權 Token”
這是一個架構邊界問題，而不是安全策略問題。
2. 沙箱隔離：副作用的物理約束
在 Agent Skill 體系中，一個被反復低估的事實是：真正的風險不來自“模型判斷錯誤”，而來自“副作用的不可逆擴散”。
對于可能產生系統級影響的 Skill（代碼執行、命令調用、腳本運行），單純的權限控制是不夠的，必須進行物理隔離。
通常而言，邏輯控制（如權限檢查）依賴于代碼的正確性，但代碼可能有漏洞、AI 可能構造惡意輸入、或出現意外的邊界情況。
而物理隔離（如 MicroVM）是在操作系統層面進行的強制約束——即使代碼邏輯有問題，惡意代碼也逃不出沙箱邊界。就像把危險操作關在一個"虛擬的小房間"里，房間外的世界是安全的。
3. 人機協同熔斷：審批是系統能力，不是 UI 設計
從系統角度看，審批不是交互問題，而是執行路徑的控制問題。因此，Skill 必須在架構層面進行風險分級建模。
一種合理且可落地的分級方式是：
以上三點放在一起，你會發現它們并非零散的安全建議，而是指向一個更本質的結論：
Agent Skills 的架構設計，本質上是在重建“權限、隔離與責任”的現代執行模型。這不是“更安全的 Agent”，而是一個在工程上真正成立的 Agent 系統。
三、那么，到底該如何理解 “Agent Skills”
在實際的工程實踐場景中，Agent Skills 面臨的根本問題，從來不是模型“夠不夠聰明”，而是一個更殘酷、也更現實的命題：
這個系統，是否具備承載不確定性的結構能力。
我們都知道，大語言模型的本質決定了它永遠是一個概率系統，具體體現在如下 3 點：
- 推理路徑不可預測
- 輸出存在波動
- 行為難以窮舉驗證
這并不是缺陷，而是其能力來源。但問題在于——概率系統一旦獲得“執行權”，風險就不再是理論問題。
因此，在 Agent 架構中必須清晰區分兩個層次：
- LLM 決定系統“能力的上限”：決定了 Agent 能理解多復雜的意圖、能規劃多長的任務鏈、能覆蓋多廣的場景。
- Skill 架構決定系統“風險的下限”：決定了當模型犯錯、誤判或越界時，系統會發生什么，以及最壞情況下會壞到什么程度。
一個沒有下限設計的 Agent 系統，本質上是將不確定性直接暴露給生產環境。同時，Agent Runtime 的復雜度，本質上接近操作系統，而不是業務框架
因此，只有當：Skill 像微服務一樣被設計，Agent Runtime 像操作系統一樣被構建，Agent 才會從一個“看起來很聰明的 Demo”，真正演進為一個可以進入生產環境的系統級能力。
這不是模型演進的問題，而是系統工程是否成熟的問題。
Happy Coding ~
Reference ：
- https://agentskills.io/what-are-skills
- https://www.cloudnativedeepdive.com/using-agent-skills-in-vs-code/
Adiós !
