在过去两年中，“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），获取更多独家技术洞察！
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
