Hello folks，我是 Luga。今天我们来聊聊大语言模型（LLM）在 AI 应用中的关键支撑组件——Agent Skills。
在过去两年中，“AI Agent”几乎成为所有智能系统讨论的中心词汇。然而在大量实践中，一个反复出现的困惑是：模型已经足够强大，Agent 却依然“做不好事”。究其根本，问题并不出在模型推理能力本身，而在于系统层面对“能力”的组织方式。
这正是 Agent Skills 概念的由来。
如果说大模型提供的是通用认知能力（General Intelligence），那么 Agent Skills 解决的，则是如何把这种能力结构化、约束化、工程化，使其在真实系统中可被调用、组合、治理与演进。
从架构角度看，Agent Skills 并不是 Prompt 的集合，而是 Agent 操作系统中的“能力指令集”。
本文不谈 Prompt 工程，也不讲 LangChain 使用，而是从平台架构师视角，拆解如何构建一个安全、可靠、可观测的 Agent Skills 体系。”
—01 —
架构视角： Skill 不是“函数”，而是“语义能力载体”
众所周知，在传统软件架构中，我们习惯了这样的交互模式：调用方 → [API 接口] → 返回数据。
然而，这种模式有个隐含前提： **调用方知道自己要什么** 。开发者编写代码时，清楚地知道要调用哪个接口、传什么参数、返回什么格式。
但 LLM Agent 不一样，它面对的是模糊的自然语言意图，需要在运行时动态理解“用户想干什么”，然后选择合适的能力去执行。这就像让一个只会看说明书的人(传统程序),突然要去理解客户的口头需求并自主决策。
这种差异导致了根本性的架构矛盾：
-
LLM 的世界是概率性的、语义化的、容错的
-
IT 系统的世界是确定性的、结构化的、严格的
Skill 架构要解决的，就是如何在这两个世界之间建立稳定的桥梁。在生产系统中，一个 Skill 不应被理解为“可调用代码”，而应被视为一个自包含的架构单元（Architectural Primitive） 。
一个工程级 Skill，至少应包含三层定义：
1、语义层：Semantic Manifes （给 LLM 看的）- 不是接口文档，是认知协议
传统 API 文档告诉你"怎么调用"，而语义层要解决的是"为什么调用"和"该不该调用"。这不是技术接口，而是 **认知接口** ——它让 LLM 理解这个能力的业务价值和使用边界。
这是 Skill 的**认知接口** ，而非技术接口。通常而言，此层往往会回答如下三个问题，具体如下：
问题 1：这个能力解决什么意图？ 不是简单描述功能，而是明确业务场景。例如：
-
❌ 错误示范："查询用户信息接口"
-
✅ 正确示范："当需要获取用户的实名认证状态、会员等级或联系方式时使用，适用于客服场景和风控审核"
问题 2：什么情况下不应该用？（反向意图） 明确能力边界，避免 LLM 的误用。例如：
-
"此接口不适用于批量数据导出（超过100条请使用批量接口）"
-
"不应在用户未授权的情况下调用敏感字段"
-
"当只需要验证用户是否存在时，使用轻量级的 checkUserExists 接口"
问题 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 真正的"能力单元"。
—02 —
安全边界：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 系统。
—03 —
那么，到底该如何理解 “Agent Skills”
在实际的工程实践场景中，Agent Skills 面临的根本问题，从来不是模型“够不够聪明”，而是一个更残酷、也更现实的命题：
这个系统，是否具备承载不确定性的结构能力。
我们都知道，大语言模型的本质决定了它永远是一个概率系统，具体体现在如下 3 点：
-
推理路径不可预测
-
输出存在波动
-
行为难以穷举验证
这并不是缺陷，而是其能力来源。但问题在于——概率系统一旦获得“执行权”，风险就不再是理论问题。
因此，在 Agent 架构中必须清晰区分两个层次：
（1）LLM 决定系统“能力的上限”：决定了 Agent 能理解多复杂的意图、能规划多长的任务链、能覆盖多广的场景。
（2）Skill 架构决定系统“风险的下限”：决定了当模型犯错、误判或越界时，系统会发生什么，以及最坏情况下会坏到什么程度。
一个没有下限设计的 Agent 系统，本质上是将不确定性直接暴露给生产环境。同时，Agent Runtime 的复杂度，本质上接近操作系统，而不是业务框架
因此，只有当：Skill 像微服务一样被设计，Agent Runtime 像操作系统一样被构建，Agent 才会从一个“看起来很聪明的 Demo”，真正演进为一个可以进入生产环境的系统级能力。
这不是模型演进的问题，而是系统工程是否成熟的问题。
今天的解析就到这里，欲了解更多关于 “大模型技术”相关技术的深入剖析，最佳实践以及相关技术前沿，敬请关注我们 的微信公众号或视频号：架构驿站（ArchHub），获取更多独家技术洞察！
Happy Coding ~
Reference ：
[1] https://agentskills.io/what-are-skills
[2] https://www.cloudnativedeepdive.com/using-agent-skills-in-vs-code/
Adiós !
··································
Hello folks，我是 Luga，AI 创业者，资深架构师，Traefik Ambassador，Jakarta EE Ambassador， 一个 15 年+ 技术老司机，从 IT 屌丝折腾到码畜，最后到“酱油“架构师。如果你喜欢技术，不喜欢呻吟，那么恭喜你，来对地方了，关注我，共同学习、进步、超越～