Agent Skills 2026 年中盘点：架构、落地与开放问题
截至 2026 年 6 月，Agent Skills 已从 Anthropic 的内部实验演变为 19+ 平台支持的开放标准，Skill + CLI 成为主流执行模式，安全威胁从假设变为现实（OWASP 已出专项框架）。但版本管理、自动编排、大规模检索等问题仍未收敛。本文基于 Anthropic 官方规范、LlamaIndex / LangChain 工程实践、OWASP 安全框架、Milvus 实测数据及多篇行业分析，对 Agent Skills 的架构机制、生产落地现状和尚未解决的开放问题做一次阶段性梳理。
问题的起点：Tool 够用了吗？
2023–2024 年间，Function Calling / Tool Use 成为 LLM Agent 的标配能力。Agent 调用外部 API，拿回结果，再基于结果推理。这套模式在任务边界清晰时工作得很好，但有三个结构性限制：
-
Tool 只执行不推理。 一个 fill_pdf_form() 函数能填表，但不会告诉 Agent 什么时候该用哪个库、异常怎么处理、表单填写的最佳实践是什么。Agent 需要的不只是一个函数签名，而是围绕这类任务的完整操作知识。
-
Tool 数量扩展困难。 LlamaIndex 在构建 LlamaAgents Builder 时发现，MCP 工具超过 10–20 个后，Agent 的工具选择准确率明显下降——每个工具都需要通过名称和描述被发现，都需要遵循特定的输入 schema，认知负荷随数量线性增长。Cursor 的工程团队甚至设置了 40 个工具的硬上限，因为超过这个阈值质量会显著下降。
-
Tool 不携带工作流知识。 Tool 是原子化的：输入 → 执行 → 输出。但真实任务是多步的、有条件分支的、需要领域判断的。把这些逻辑全塞进 system prompt 又回到了单体 prompt 的老路。
Skill 就是在这个缝隙里长出来的。
Skill 到底是什么
Anthropic 2025 年 10 月发布 Agent Skills，12 月作为开放标准发布。定义很直接：Skill 是一个目录，包含一个 SKILL.md 文件和可选的资源文件（脚本、模板、参考文档）。 它把指令、知识和可执行代码打包成一个可复用的能力单元。
与 Tool 的本质区别：
- Tool 解决的问题是"Agent 能调用什么函数"——关注的是执行。
- Skill 解决的问题是"Agent 该如何思考和处理一类任务"——关注的是能力的完整封装。
LlamaIndex 的表述更精确：MCP 工具一旦被选中，底层就是一个带有明确输入输出 schema 的 API 调用；而 Skill 只是给 Agent 提供了"能做什么、怎么做"的自然语言指令，Agent 需要自己理解和执行这些指令。这意味着 Skill 的挑战不只是"选哪个"，还包括"怎么用"——后者完全依赖模型的推理能力。
这不是一个纯粹的优势，也不是纯粹的劣势。它是一个设计取舍：Skill 获得了灵活性和表达力，代价是执行的确定性不如 Tool。
Skill 与 MCP：不是替代，是不同层次
这是 2026 年社区讨论量最大的话题。LlamaIndex 在实际构建 coding agent 时做了直接对比实验，结论值得细看：
LlamaIndex 的发现：
- 文档类 MCP 提供的上下文通常足以让 Agent 正确生成代码
- Skill 很少被主动触发，且在有 MCP 的情况下没有显著提升结果质量
- 但最终他们选择了 MCP 而非 Skill 的关键原因是：SDK 更新太快，Skill 里的代码示例会过时，而 MCP 连接的文档会随发布自动更新
LlamaIndex 给出的决策框架：
- 如果领域知识变化快、需要 single source of truth → 用 MCP
- 如果操作相对稳定、需要轻量本地执行 → 用 Skill
这说明两者的选择不是"谁更先进"，而是取决于具体场景的信息时效性和执行模式。
值得注意的一个工程细节：MCP 的 context 开销在规模化时非常显著。Milvus 团队的实测数据显示，仅连接 3 个 MCP server（GitHub + Playwright + IDE），工具定义就占据了 200K context window 的约 72%（~143K tokens），Agent 还没开始工作就已经三分之二满了。工具选择准确率从 43% 降到 14%。这也是 Skill 的渐进式加载（启动时只加载 metadata，按需展开）在工具数量多时优势明显的原因。
另一个澄清：Perplexity CTO Denis Yarats 在 ASK 2026 上说的是 deprioritize MCP over stdio（本地进程间通信），而非全面放弃 MCP。MCP over HTTP 在企业内部仍有价值——集中权限管理、统一 OAuth、标准化遥测日志。两种传输模式的适用场景不同，不能一概而论。
更准确的定位：
| 维度 |
MCP |
Skill |
| 本质 |
连接外部服务的通信协议 |
注入领域知识的指令包 |
| 执行 |
网络调用，有延迟 |
本地文件读取，零网络开销 |
| 确定性 |
高（固定 schema，相同输入相同输出） |
低（依赖 LLM 对指令的理解） |
| 扩展瓶颈 |
工具数量超过 10–20 个后发现困难 |
渐进式加载，百个无压力 |
| 维护成本 |
与上游 API 同步即可 |
需要手动维护指令和示例 |
生产环境的两种典型组合：
- Skill + MCP：Skill 提供"如何处理 Jira 工单"的工作流知识，MCP 提供实际调用 Jira API 的工具，Agent 读取 Skill 后通过 MCP 执行具体操作。适合需要结构化 API 调用的场景。
- Skill + CLI：Skill 提供"如何审查 PR"的工作流知识，Agent 读取后直接通过
gh pr diff、gh pr view 等 CLI 命令执行。适合已有命令行工具覆盖的场景——这是 2025–2026 年增长最快的模式（后文"Skill + CLI"一节展开）。
Skill 在架构中的位置
在进入具体工程机制之前，先看 Skill 在 Agent 架构全景中的位置。这里有两个互补的视角：
宏观架构选择：Cobus Greyling 在 2025 年的分析中梳理了三种已收敛的方向：
- 单体 Agent：所有能力集中在一个 Agent 中。适合原型验证和简单任务，但在专业化和长链任务上可靠性不足。
- 多 Agent 工作流编排：多个专业化 Agent 协作，有明确的编排层。适合复杂、可分解的任务。代价是协调开销和调试复杂度。
- LLM Skills（模块化能力扩展）：单一核心 LLM + 可组合的 Skill 库。不增殖 Agent 数量，而是通过 Skill 注入专业知识。
到 2025 年末，行业的实际走向是混合：Workflow 负责编排 + Skill 负责专业化 + 高效模型负责推理。没有哪种单一架构在所有场景下都最优。
单系统内的编排模式选择：LangChain 在 2026 年的多 Agent 架构文档中将 Skills 列为五种编排模式之一（与 Subagents、Handoffs、Router、Custom Workflow 并列），粒度更细，关注的是"在一个系统内部，Agent 之间如何分工"。后文"Skill 与工作流编排"一节会展开这个视角。
两个视角的关系：Cobus Greyling 的三分法回答"选哪条路"，LangChain 的五模式回答"选了之后怎么和其他模式组合"。
从文件系统层面看，2026 年还形成了 AGENTS.md（行为层，常驻）+ SKILL.md（能力层，按需加载）+ MCP/CLI（执行层）的三层分离模型。Skill 在其中只管"遇到这类任务该怎么做"，不管 Agent 身份（AGENTS.md 管）也不管工具调用（MCP/CLI 管）。
渐进式加载：让几百个 Skill 共存成为可能
Agent Skills 的核心工程设计是 Progressive Disclosure（渐进式披露）。Anthropic 的官方规范定义了三层加载机制：
Level 1 — Metadata（启动时常驻）
---
name: pdf-processing
description: Extract text and tables from PDF files, fill forms, merge documents.
Use when working with PDF files or when the user mentions PDFs.
---每个 Skill 的 name + description 在 Agent 启动时注入 system prompt，每个约消耗 ~100 tokens。这意味着安装 100 个 Skill，启动开销也只有 ~10,000 tokens。Agent 此刻只知道"这些 Skill 存在，以及什么时候该触发它们"。
Level 2 — Skill Body（任务匹配时加载）
当用户请求与某个 Skill 的 description 匹配时，Agent 通过文件系统读取完整的 SKILL.md 主体（建议 <500 行，约 <5,000 tokens）。这里包含工作流指令、最佳实践、代码示例。
Level 3 — Resources（执行中按需引用）
SKILL.md 中可以引用子文档（REFERENCE.md、FORMS.md）和脚本。Agent 只在当前任务确实需要时才读取。脚本可以直接执行，输出进入 context 但脚本代码本身不进入——这从根本上解除了资源规模与 context 占用之间的耦合。
Token 经济学对比：
渐进式加载（100 个 Skill）：
启动 = 100 × ~100 tokens = ~10,000 tokens
单任务 = 10,000 + 1~2 个 Skill body ≈ 15,000–20,000 tokens
全量加载（旧模式）：
启动 = 100 × ~5,000 tokens = ~500,000 tokens ← 超出绝大多数 context window
这就是为什么一个内部工具 Skill 可以挂载上百个子 GUIDE 而不会出问题——它们不会同时展开，只有被触发的那一两个会进入 context。Anthropic 的规范文档原文："the amount of context that can be bundled into a skill is effectively unbounded."
大规模 Skill 的分层设计：bytedcli 的实际案例
当 Skill 数量达到几十上百个时，组织方式变得关键。当前已验证有效的模式是"单一入口 + 多子领域"。bytedcli 的结构就是这个模式的典型落地：
bytedcli/
├── SKILL.md # 顶层入口（1 个）
└── references/subskills/
├── bytedance-bytedoc/GUIDE.md # 文档服务
├── bytedance-cache/GUIDE.md # 缓存服务
├── bytedance-log/GUIDE.md # 日志服务
├── bytedance-deploy/GUIDE.md # 部署相关
└── ... (共 156 个子领域 GUIDE.md，225 个文件)
这个结构直接对应 Anthropic 规范的三层加载机制：
| 层级 |
bytedcli 中的对应 |
何时加载 |
Token 开销 |
| Level 1 Metadata |
SKILL.md 的 frontmatter（name + description） |
Agent 启动时 |
~100 tokens |
| Level 2 Body |
SKILL.md 主体（能力总览 + 子域路由表） |
用户提到 bytedcli 相关任务时 |
<5,000 tokens |
| Level 3 Resources |
156 个 GUIDE.md |
Agent 判断具体属于哪个子域后，只读对应的 1–2 个 |
按需，每个 GUIDE 独立 |
设计意图：
- SKILL.md 是能力路由层：告诉 Agent bytedcli 整体能做什么、156 个子域怎么分类（文档、缓存、日志、部署……）、什么任务该深入哪个子域
- 各 GUIDE.md 是领域知识层：只在 Agent 判断当前任务属于该领域时才被读取。比如用户问"怎么清 bytedoc 的缓存"，Agent 只需读取
bytedance-bytedoc/GUIDE.md 和可能的 bytedance-cache/GUIDE.md，其余 154 个 GUIDE 不进入 context
- Agent 的正确使用路径是：读 SKILL.md → 判断归属 → 只读对应 GUIDE → 通过 shell 执行
bytedcli <subcommand>
这不是"156 个独立 Skill 同时冒出来"，而是 1 个统一入口下的按需展开。如果把 156 个 GUIDE 全量加载，按每个平均 3,000 tokens 计算，总量达 ~470,000 tokens——远超任何模型的 context window。渐进式加载不是优化，是必要条件。
Anthropic 规范的原文建议：当 SKILL.md 超过 500 行时，把详细内容移到 references/ 目录，在主文件中保留清晰的指向。bytedcli 的 156 个子域显然不可能塞进一个文件，分层是唯一可行的组织方式。
自动发现机制也在成熟。以 GitHub CLI v2.90 的 gh skill 为例，Skill 放进指定目录后零配置自动识别，不再需要在主配置里手动维护路径列表。bytedcli 的 Skill 结构天然兼容这类发现机制——目录结构本身就是索引。
按业务场景定制 Skill
Skill 不只是用来封装工具操作知识。另一类高频用法是：为特定业务场景（代码审查、需求评审、部署检查）编写独立的工作流 Skill。
2026 年已有大量开源实践：
微软 HVE Core 的做法更进一步：review agent 运行时动态扫描 workspace 中的 **/SKILL.md，按 diff 涉及的语言匹配加载对应 skill。新增一个 SKILL.md 就扩展了 review 覆盖范围，不改 agent 代码。
这类场景 Skill 和前一节的"工具操作 Skill"（如 bytedcli）是两个不同层次：
- 工具操作 Skill：教 Agent 怎么使用某个 CLI/API（bytedcli 的 156 个 GUIDE 属于此类）
- 业务场景 Skill：教 Agent 怎么完成一项业务任务，内部可能调用工具操作 Skill
两者可以组合：一个"需求评审"Skill 里写"用 bytedcli bytedoc 拉取文档"，Agent 读到后知道去查 bytedcli 的对应 GUIDE 获取具体操作方式。这是能力的分层复用。
场景 Skill 的管理方式和代码一致——放在仓库的 .agents/skills/ 目录下，走 PR 流程，用 description 控制触发条件。同一套 Skill 在 Claude Code、Codex、Cursor 里都能用。
Skill + CLI：Agent 时代的执行层复兴
2025–2026 年间出现了一个看似反直觉的现象：在 GUI 和 SDK 已经高度成熟的今天，CLI 正在经历一轮结构性复兴——而 Skill 是推动力之一。
为什么 Agent 偏好 CLI
Zylos Research 在 2026 年 2 月的调研中指出：2025 年 2 月到 2026 年初，每一家主要 AI 实验室都发布了终端原生的 Agent 运行时（Anthropic → Claude Code, OpenAI → Codex CLI, Google → Gemini CLI, Block → Goose, Sourcegraph → Amp）。这不是巧合，而是结构性选择。
原因有三：
-
Agent 的"手"是 bash，不是 SDK。 当 Agent 需要做它不内置的事情时，最便宜的路径是 shell 命令。CLI 的输出是模型训练数据中的通用交换格式——gh、stripe、aws、kubectl 这些命令 Agent 见过无数遍。写 Python 脚本意味着安装依赖、导入模块、学习 API surface、执行脚本，而 CLI 一条命令跳过所有中间步骤。
-
CLI 天然可组合、可管道、可无头运行。 Unix 的 pipe 哲学直接适配 Agent 编排——一个 Agent 的输出可以 pipe 给另一个工具。IDE 插件运行在扩展 API 内部，结构上不适合编排 shell 命令、管理进程或在 CI pipeline 中无头运行。
-
CLI 覆盖了 Agent 需要的全部操作面。 文件系统、git 历史、环境变量、测试运行器、构建系统、外部 API——全部已经在 shell 中可用，不需要额外的集成层。
Galtea 的工程博客把这个关系说得很直接：
"Agent 需要的不只是一个命令，而是一个 playbook——告诉它调用哪个命令、什么顺序、什么坑要避开。Skill 就是那个 playbook，CLI 就是它教 Agent 去操作的手。"
Skill 和 CLI 的具体配合关系
两者不是平级关系，而是上下层配合：
| 层 |
角色 |
实际内容 |
| Skill（知识层） |
教 Agent "做什么、怎么做、什么顺序、什么坑" |
SKILL.md 里的自然语言指令 |
| CLI（执行层） |
Agent 实际操作的工具 |
gh、stripe、aws、bytedcli 等命令行工具 |
一个典型的 Skill 内容：
---
name: pr-summary
description: Summarize changes in a pull request
---
When asked to summarize a PR:
1. Run `gh pr diff <number>` to get the diff
2. Run `gh pr view <number> --json title,body,labels` for metadata
3. Analyze the changes and produce a summary grouped by component
Skill 不暴露新的 API，它教 Agent 如何组合已有的 CLI 命令来完成一个工作流。这比写一个专门的 MCP server 轻量得多，也更容易维护——改一行 Markdown 就能更新工作流，不需要重新部署服务。
行业落地动作
这不是概念讨论，是已经发布的产品功能：
- GitHub CLI v2.90（2026 年 4 月）：新增
gh skill 命令，支持 Skill 的发现、安装、版本锁定、发布和更新。支持 --agent claude-code/cursor/codex/gemini 跨 Agent 安装。内置供应链安全——immutable releases、content-addressed change detection、版本 pinning。
- OpenAI Codex：采用与 Anthropic 相同的 SKILL.md 格式（基于 agentskills.io 开放标准），CLI/IDE/App 三端共享 Skill。明确支持 Skill 内引用 CLI 命令作为执行手段。
- Anthropic Claude Code：Skill 内大量引用 CLI 工具——
gh pr diff、bash 脚本、本地命令行工具——作为 Agent 的执行路径。
- Galtea：同时发布 CLI + Agent Skill，CLI 从 OpenAPI spec 自动生成全量命令（
galtea <noun> <verb>），Skill 教 Agent 按正确的工作流使用这些命令。
适用边界
CLI + Skill 不是万能的。Galtea 给出了清晰的适用边界：
- CLI + Skill 适合：short-lived、ad-hoc、conversational workloads——快速查询、一次性脚本操作、Agent 驱动的多步编排
- SDK 适合：long-lived、deployed application 内部的结构化工作——生产服务中的 trace 采集、带重试和异常处理的定时任务、需要类型安全的业务逻辑
bytedcli 的 Skill 结构（1 个 SKILL.md 入口 + 156 个 GUIDE.md + shell 执行 bytedcli <subcommand>）就是这个"Skill 提供操作知识 + CLI 提供执行能力"模式的内部落地。
Skill 与工作流编排：从"能力单元"到"流程载体"
Skill 在编排体系中的位置
前文"Skill 在架构中的位置"一节介绍了宏观架构选择。这里展开另一个视角：在一个系统内部，Skill 和 Workflow 是什么关系？
Anthropic 在 2024 年 12 月的《Building Effective Agents》中区分了两类系统：
- Workflow：预定义控制流（Prompt Chaining、Routing、Parallelization 等），LLM 在固定节点执行特定任务
- Agent：LLM 自主决定控制流和工具调用序列
核心建议是：能用 Workflow 解决的问题不要用 Agent。
LangChain 的多 Agent 架构文档给出了 Skills 模式与其他编排模式的适用场景矩阵：
| 模式 |
分布式开发 |
并行化 |
多跳推理 |
用户直接交互 |
| Subagents |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐ |
| Skills |
⭐⭐⭐⭐⭐ |
⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
| Handoffs |
— |
— |
⭐⭐⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
| Router |
⭐⭐⭐ |
⭐⭐⭐⭐⭐ |
— |
⭐⭐⭐ |
Skills 模式的特点：单 Agent 保持控制权，按需加载专业化 prompt 和知识。适合简单聚焦任务、需要多跳推理但不需要并行执行的场景。劣势是 context 累积——多域任务下 token 用量高于 Subagents 模式。
Azure Architecture Center（2026 年 2 月更新）则从企业工程角度归纳了 Sequential、Concurrent、Group Chat、Handoff、Magentic 五种编排模式。Skill 在这些模式中充当"能力原子"——无论编排模式如何选择，每个节点执行的具体能力都由 Skill/Tool 提供。
Skill 正在变成工作流载体
2026 年出现的一个重要演进：Skill 不再只是"被编排的能力单元"，它本身开始承载工作流逻辑。
LangChain 发布的 Interpreter Skills 是这个方向的代表。传统 Skill 只包含自然语言指令，Agent 读了之后"希望它能正确执行"。Interpreter Skill 在 SKILL.md 之外附带一个 TypeScript 模块——确定性的流程逻辑用代码表达，Agent 只决定"何时调用"和"传什么参数"：
skills/github-triage/
├── SKILL.md # 告诉 Agent 何时使用、如何调用
└── index.ts # 确定性的 triage 逻辑（代码，可测试、可 review）
LangChain 对此的定位很明确：
"Prompt-only 的流程遵循是脆弱的——Agent 会跳步、重排、混入无关请求。Interpreter Skill 把确定性部分放进代码，把判断力留给模型。"
这改变了 Skill 的角色定位：
- 传统 Skill（2025）：Agent 的知识注入——"这类任务怎么做"
- Interpreter Skill（2026）：Agent 的可执行工作流——"调用这个函数就能按标准流程完成"
当前的实际架构
生产环境中的主流选择仍然是混合式——但 Skill 在其中的位置已经从"被调用的知识"扩展到"可以编排子流程的独立单元"：
主 Agent（路由 + 决策）
├── 固定 Workflow 节点（预定义流程，LangGraph / Azure Agent Framework）
├── Skill 节点（prompt-driven 专业化能力，按需加载）
├── Interpreter Skill 节点（代码-driven 确定性流程，Agent 触发后自动执行）
└── MCP/Tool 层（外部服务调用）
模式间可以嵌套：一个 Subagents 架构的子 Agent 可以使用 Skills 模式加载领域知识；一个 Interpreter Skill 内部可以 spawn 子 Agent。LangChain 文档原文："You can mix patterns! Subagents can use the skills pattern to load context on-demand."
安全：不是理论风险，是正在发生的事
OWASP 于 2026 年发布了 Agentic Skills Top 10 安全风险框架——这是第一个专门针对 Agent Skill 生态的安全标准。背景不是假设性的：
- ClawHub（类似 npm 的 Skill 注册中心）在 2026 年 Q1 被系统性投毒，最受欢迎的 7 个 Skill 中有 5 个被确认为恶意软件
- Check Point 披露了 Claude Code 的两个严重漏洞（CVE-2025-59536, CVSS 8.7），仓库级配置文件可以在用户无感知的情况下触发远程代码执行
- Palo Alto Networks 和 Simon Willison 定义了"致命三角"：当一个 Skill 同时拥有私有数据访问权 + 接触不可信内容 + 外部通信能力时，风险最高——而大多数生产部署满足全部三个条件
OWASP 的十大风险覆盖从注册中心投毒（Supply Chain）到 Prompt Injection via Skill、过度权限、跨 Agent 传播等。
实践层面的直接建议：
- 对第三方 Skill 执行与对待未审核的第三方代码相同的审计标准
- 强制 Skill manifest 签名验证
- 沙箱化所有 Skill 的执行上下文
- 区分信任层级：官方认证 > 合作伙伴 > 社区贡献 > 用户自建
这不是远期规划，是当下已经需要落实的工程实践。
什么是确定的，什么还在演进
有充分工程验证的：
- 渐进式加载是大规模 Skill 生态的标准做法，已被 Anthropic 写入开放规范并被多平台采用
- Skill 和 Tool/MCP 是互补关系而非替代关系，选择取决于场景的信息时效性和执行模式
- 大型 Skill 的正确组织方式是分层入口 + 按需展开，而非平铺
- Skill + CLI 是 Agent 工具链的标准形态：Skill 提供操作知识，CLI 提供执行能力，GitHub/OpenAI/Anthropic 已同步落地
- 安全威胁已经是现实问题，OWASP 已有专项框架
- 跨平台可移植性在核心层已基本实现：截至 2026 年 5 月，SKILL.md 在 19+ 平台原生运行（Claude Code、Codex CLI、Gemini CLI、Cursor、Copilot 等），agensi.io 实测 10 个 Skill 跨 6 平台，8 个零修改通过。差异仅在 agent-specific 扩展字段（如
context: fork、allowed-tools），其他 Agent 静默忽略
- 生产级 Skill 的标准结构已收敛：确定性操作走
scripts/ 目录（可测试、可审计），判断性工作留在 SKILL.md 指令中——多个生产 Skill 库和 MLflow 的工程指南均将此作为第一原则
- Skill 以代码标准管理：放入版本控制、走 PR 审查、frontmatter 含 version 字段、变更可 diff——与软件制品相同的 DevOps 实践已成为默认做法。Anthropic 官方的 Skill Creator 进一步将 create → eval → improve → benchmark 封装为标准化开发流程，内置子 Agent 做并行测试、盲评对比和 description 触发优化
仍在演进中的：
- Skill 自动发现与动态索引：当 Skill 库达到数百上千个时，纯靠 description 匹配不够。注册中心侧的搜索已落地——ClawHub（10,700+ Skill）内置 OpenAI embeddings 向量搜索，2026 年 4 月已合入 UI。检索系统侧，SkillFlow 在 36K SKILL.md 语料上实现四阶段检索流水线（bi-encoder → cross-encoder rerank → LLM 筛选），SkillsBench 上 Pass@1 提升 78%。但 Agent 运行时的动态发现仍未解决——OpenClaw 自身承认当前是静态加载，runtime skill search 仍在提案阶段
- Skill 间的自动编排：Agent 自主决定调用哪些 Skill 的组合，目前仍是"更多 art than science"（社区从业者原话）
- Skill 的版本管理与生命周期：已有多个包管理器出现——skpm（manifest + lockfile + SHA256 校验，支持
outdated/prune/diff 退役检测）、agentskills（Rust 实现，支持 semver）、agentdeps（声明式 YAML）等。gh skill 提供 immutable releases + version pinning。agentskills.io 规范仓库已有manifest 标准化提案。生态正在快速发展，但尚未收敛到单一标准
- 元数据 Schema 标准化：核心格式（SKILL.md + YAML frontmatter 的
name/description）已跨平台统一，但 scope、triggering conditions、dependencies、safety constraints 等扩展字段各平台定义不同。skillporter 在做跨格式兼容映射，agentskills.io 有标准化提案，但尚未收敛为统一 schema
- 确定性与灵活性的平衡：Interpreter Skills 提供了初步解法（代码承载确定性，模型保留判断力），但这个方向仍在早期
参考来源
- Equipping agents for the real world with Agent Skills — Anthropic Engineering (2025)
- Agent Skills — Claude API Docs, Specification Overview
- Agent Skills Specification — Anthropic Skills
- Three AI Agent Architectures Have Emerged — Cobus Greyling (2025)
- Skills vs MCP tools for agents: when to use what — LlamaIndex (Feb 2026)
- OWASP Agentic Skills Top 10 (2026)
- Building Production-Ready AI Agents in 2026 — MLflow
- Building Effective Agents — Anthropic Research (2024)
- A Developer's Guide to Building Scalable AI: Workflows vs Agents — Towards Data Science
- Towards Secure Agent Skills: Architecture, Threat Taxonomy — arXiv:2604.02837 (2026)
- Why AI coding agents are bringing the CLI back — Galtea Blog (2026)
- AI Agent CLI Frameworks: Terminal-Native Agent Runtimes — Zylos Research (Feb 2026)
- Manage agent skills with GitHub CLI — GitHub Changelog (Apr 2026)
- Agent Skills — Codex, OpenAI Developers (2026)
- Build a Multi-Tool Agent Skill Pack for Your Engineering Team — noqta.tn (2026)
- Code Review — HVE Core, Microsoft (2026)
- review-forge — Structured Code Review Agent Skill (2026)
- playmoreai/agent-skills — PRD & Review Implementation Skills (2026)
- Multi-agent Patterns: Skills — LangChain Docs (2026)
- Interpreter Skills: Building Workflows for Agents — LangChain Blog (2026)
- AI Agent Orchestration Patterns — Azure Architecture Center (Feb 2026)
- Is MCP Dead? MCP vs CLI vs Agent Skills Compared — Milvus Blog (2026)
Agent Skills 2026 年中盘点：架构、落地与开放问题
问题的起点：Tool 够用了吗？
2023–2024 年间，Function Calling / Tool Use 成为 LLM Agent 的标配能力。Agent 调用外部 API，拿回结果，再基于结果推理。这套模式在任务边界清晰时工作得很好，但有三个结构性限制：
Tool 只执行不推理。 一个
fill_pdf_form()函数能填表，但不会告诉 Agent 什么时候该用哪个库、异常怎么处理、表单填写的最佳实践是什么。Agent 需要的不只是一个函数签名，而是围绕这类任务的完整操作知识。Tool 数量扩展困难。 LlamaIndex 在构建 LlamaAgents Builder 时发现，MCP 工具超过 10–20 个后，Agent 的工具选择准确率明显下降——每个工具都需要通过名称和描述被发现，都需要遵循特定的输入 schema，认知负荷随数量线性增长。Cursor 的工程团队甚至设置了 40 个工具的硬上限，因为超过这个阈值质量会显著下降。
Tool 不携带工作流知识。 Tool 是原子化的：输入 → 执行 → 输出。但真实任务是多步的、有条件分支的、需要领域判断的。把这些逻辑全塞进 system prompt 又回到了单体 prompt 的老路。
Skill 就是在这个缝隙里长出来的。
Skill 到底是什么
Anthropic 2025 年 10 月发布 Agent Skills，12 月作为开放标准发布。定义很直接：Skill 是一个目录，包含一个 SKILL.md 文件和可选的资源文件（脚本、模板、参考文档）。 它把指令、知识和可执行代码打包成一个可复用的能力单元。
与 Tool 的本质区别：
LlamaIndex 的表述更精确：MCP 工具一旦被选中，底层就是一个带有明确输入输出 schema 的 API 调用；而 Skill 只是给 Agent 提供了"能做什么、怎么做"的自然语言指令，Agent 需要自己理解和执行这些指令。这意味着 Skill 的挑战不只是"选哪个"，还包括"怎么用"——后者完全依赖模型的推理能力。
这不是一个纯粹的优势，也不是纯粹的劣势。它是一个设计取舍：Skill 获得了灵活性和表达力，代价是执行的确定性不如 Tool。
Skill 与 MCP：不是替代，是不同层次
这是 2026 年社区讨论量最大的话题。LlamaIndex 在实际构建 coding agent 时做了直接对比实验，结论值得细看：
LlamaIndex 的发现：
LlamaIndex 给出的决策框架：
这说明两者的选择不是"谁更先进"，而是取决于具体场景的信息时效性和执行模式。
值得注意的一个工程细节：MCP 的 context 开销在规模化时非常显著。Milvus 团队的实测数据显示，仅连接 3 个 MCP server（GitHub + Playwright + IDE），工具定义就占据了 200K context window 的约 72%（~143K tokens），Agent 还没开始工作就已经三分之二满了。工具选择准确率从 43% 降到 14%。这也是 Skill 的渐进式加载（启动时只加载 metadata，按需展开）在工具数量多时优势明显的原因。
另一个澄清：Perplexity CTO Denis Yarats 在 ASK 2026 上说的是 deprioritize MCP over stdio（本地进程间通信），而非全面放弃 MCP。MCP over HTTP 在企业内部仍有价值——集中权限管理、统一 OAuth、标准化遥测日志。两种传输模式的适用场景不同，不能一概而论。
更准确的定位：
生产环境的两种典型组合：
gh pr diff、gh pr view等 CLI 命令执行。适合已有命令行工具覆盖的场景——这是 2025–2026 年增长最快的模式（后文"Skill + CLI"一节展开）。Skill 在架构中的位置
在进入具体工程机制之前，先看 Skill 在 Agent 架构全景中的位置。这里有两个互补的视角：
宏观架构选择：Cobus Greyling 在 2025 年的分析中梳理了三种已收敛的方向：
到 2025 年末，行业的实际走向是混合：Workflow 负责编排 + Skill 负责专业化 + 高效模型负责推理。没有哪种单一架构在所有场景下都最优。
单系统内的编排模式选择：LangChain 在 2026 年的多 Agent 架构文档中将 Skills 列为五种编排模式之一（与 Subagents、Handoffs、Router、Custom Workflow 并列），粒度更细，关注的是"在一个系统内部，Agent 之间如何分工"。后文"Skill 与工作流编排"一节会展开这个视角。
两个视角的关系：Cobus Greyling 的三分法回答"选哪条路"，LangChain 的五模式回答"选了之后怎么和其他模式组合"。
从文件系统层面看，2026 年还形成了
AGENTS.md（行为层，常驻）+SKILL.md（能力层，按需加载）+ MCP/CLI（执行层）的三层分离模型。Skill 在其中只管"遇到这类任务该怎么做"，不管 Agent 身份（AGENTS.md 管）也不管工具调用（MCP/CLI 管）。渐进式加载：让几百个 Skill 共存成为可能
Agent Skills 的核心工程设计是 Progressive Disclosure（渐进式披露）。Anthropic 的官方规范定义了三层加载机制：
Level 1 — Metadata（启动时常驻）
每个 Skill 的 name + description 在 Agent 启动时注入 system prompt，每个约消耗 ~100 tokens。这意味着安装 100 个 Skill，启动开销也只有 ~10,000 tokens。Agent 此刻只知道"这些 Skill 存在，以及什么时候该触发它们"。
Level 2 — Skill Body（任务匹配时加载）
当用户请求与某个 Skill 的 description 匹配时，Agent 通过文件系统读取完整的 SKILL.md 主体（建议 <500 行，约 <5,000 tokens）。这里包含工作流指令、最佳实践、代码示例。
Level 3 — Resources（执行中按需引用）
SKILL.md 中可以引用子文档（REFERENCE.md、FORMS.md）和脚本。Agent 只在当前任务确实需要时才读取。脚本可以直接执行，输出进入 context 但脚本代码本身不进入——这从根本上解除了资源规模与 context 占用之间的耦合。
Token 经济学对比：
这就是为什么一个内部工具 Skill 可以挂载上百个子 GUIDE 而不会出问题——它们不会同时展开，只有被触发的那一两个会进入 context。Anthropic 的规范文档原文："the amount of context that can be bundled into a skill is effectively unbounded."
大规模 Skill 的分层设计：bytedcli 的实际案例
当 Skill 数量达到几十上百个时，组织方式变得关键。当前已验证有效的模式是"单一入口 + 多子领域"。bytedcli 的结构就是这个模式的典型落地：
这个结构直接对应 Anthropic 规范的三层加载机制：
设计意图：
bytedance-bytedoc/GUIDE.md和可能的bytedance-cache/GUIDE.md，其余 154 个 GUIDE 不进入 contextbytedcli <subcommand>这不是"156 个独立 Skill 同时冒出来"，而是 1 个统一入口下的按需展开。如果把 156 个 GUIDE 全量加载，按每个平均 3,000 tokens 计算，总量达 ~470,000 tokens——远超任何模型的 context window。渐进式加载不是优化，是必要条件。
Anthropic 规范的原文建议：当 SKILL.md 超过 500 行时，把详细内容移到 references/ 目录，在主文件中保留清晰的指向。bytedcli 的 156 个子域显然不可能塞进一个文件，分层是唯一可行的组织方式。
自动发现机制也在成熟。以 GitHub CLI v2.90 的
gh skill为例，Skill 放进指定目录后零配置自动识别，不再需要在主配置里手动维护路径列表。bytedcli 的 Skill 结构天然兼容这类发现机制——目录结构本身就是索引。按业务场景定制 Skill
Skill 不只是用来封装工具操作知识。另一类高频用法是：为特定业务场景（代码审查、需求评审、部署检查）编写独立的工作流 Skill。
2026 年已有大量开源实践：
code-reviewnw-po-review-dimensionsreview-implementationprd微软 HVE Core 的做法更进一步：review agent 运行时动态扫描 workspace 中的
**/SKILL.md，按 diff 涉及的语言匹配加载对应 skill。新增一个 SKILL.md 就扩展了 review 覆盖范围，不改 agent 代码。这类场景 Skill 和前一节的"工具操作 Skill"（如 bytedcli）是两个不同层次：
两者可以组合：一个"需求评审"Skill 里写"用
bytedcli bytedoc拉取文档"，Agent 读到后知道去查 bytedcli 的对应 GUIDE 获取具体操作方式。这是能力的分层复用。场景 Skill 的管理方式和代码一致——放在仓库的
.agents/skills/目录下，走 PR 流程，用 description 控制触发条件。同一套 Skill 在 Claude Code、Codex、Cursor 里都能用。Skill + CLI：Agent 时代的执行层复兴
2025–2026 年间出现了一个看似反直觉的现象：在 GUI 和 SDK 已经高度成熟的今天，CLI 正在经历一轮结构性复兴——而 Skill 是推动力之一。
为什么 Agent 偏好 CLI
Zylos Research 在 2026 年 2 月的调研中指出：2025 年 2 月到 2026 年初，每一家主要 AI 实验室都发布了终端原生的 Agent 运行时（Anthropic → Claude Code, OpenAI → Codex CLI, Google → Gemini CLI, Block → Goose, Sourcegraph → Amp）。这不是巧合，而是结构性选择。
原因有三：
Agent 的"手"是 bash，不是 SDK。 当 Agent 需要做它不内置的事情时，最便宜的路径是 shell 命令。CLI 的输出是模型训练数据中的通用交换格式——
gh、stripe、aws、kubectl这些命令 Agent 见过无数遍。写 Python 脚本意味着安装依赖、导入模块、学习 API surface、执行脚本，而 CLI 一条命令跳过所有中间步骤。CLI 天然可组合、可管道、可无头运行。 Unix 的 pipe 哲学直接适配 Agent 编排——一个 Agent 的输出可以 pipe 给另一个工具。IDE 插件运行在扩展 API 内部，结构上不适合编排 shell 命令、管理进程或在 CI pipeline 中无头运行。
CLI 覆盖了 Agent 需要的全部操作面。 文件系统、git 历史、环境变量、测试运行器、构建系统、外部 API——全部已经在 shell 中可用，不需要额外的集成层。
Galtea 的工程博客把这个关系说得很直接：
Skill 和 CLI 的具体配合关系
两者不是平级关系，而是上下层配合：
gh、stripe、aws、bytedcli等命令行工具一个典型的 Skill 内容：
Skill 不暴露新的 API，它教 Agent 如何组合已有的 CLI 命令来完成一个工作流。这比写一个专门的 MCP server 轻量得多，也更容易维护——改一行 Markdown 就能更新工作流，不需要重新部署服务。
行业落地动作
这不是概念讨论，是已经发布的产品功能：
gh skill命令，支持 Skill 的发现、安装、版本锁定、发布和更新。支持--agent claude-code/cursor/codex/gemini跨 Agent 安装。内置供应链安全——immutable releases、content-addressed change detection、版本 pinning。gh pr diff、bash 脚本、本地命令行工具——作为 Agent 的执行路径。galtea <noun> <verb>），Skill 教 Agent 按正确的工作流使用这些命令。适用边界
CLI + Skill 不是万能的。Galtea 给出了清晰的适用边界：
bytedcli 的 Skill 结构（1 个 SKILL.md 入口 + 156 个 GUIDE.md + shell 执行
bytedcli <subcommand>）就是这个"Skill 提供操作知识 + CLI 提供执行能力"模式的内部落地。Skill 与工作流编排：从"能力单元"到"流程载体"
Skill 在编排体系中的位置
前文"Skill 在架构中的位置"一节介绍了宏观架构选择。这里展开另一个视角：在一个系统内部，Skill 和 Workflow 是什么关系？
Anthropic 在 2024 年 12 月的《Building Effective Agents》中区分了两类系统：
核心建议是：能用 Workflow 解决的问题不要用 Agent。
LangChain 的多 Agent 架构文档给出了 Skills 模式与其他编排模式的适用场景矩阵：
Skills 模式的特点：单 Agent 保持控制权，按需加载专业化 prompt 和知识。适合简单聚焦任务、需要多跳推理但不需要并行执行的场景。劣势是 context 累积——多域任务下 token 用量高于 Subagents 模式。
Azure Architecture Center（2026 年 2 月更新）则从企业工程角度归纳了 Sequential、Concurrent、Group Chat、Handoff、Magentic 五种编排模式。Skill 在这些模式中充当"能力原子"——无论编排模式如何选择，每个节点执行的具体能力都由 Skill/Tool 提供。
Skill 正在变成工作流载体
2026 年出现的一个重要演进：Skill 不再只是"被编排的能力单元"，它本身开始承载工作流逻辑。
LangChain 发布的 Interpreter Skills 是这个方向的代表。传统 Skill 只包含自然语言指令，Agent 读了之后"希望它能正确执行"。Interpreter Skill 在 SKILL.md 之外附带一个 TypeScript 模块——确定性的流程逻辑用代码表达，Agent 只决定"何时调用"和"传什么参数"：
LangChain 对此的定位很明确：
这改变了 Skill 的角色定位：
当前的实际架构
生产环境中的主流选择仍然是混合式——但 Skill 在其中的位置已经从"被调用的知识"扩展到"可以编排子流程的独立单元"：
模式间可以嵌套：一个 Subagents 架构的子 Agent 可以使用 Skills 模式加载领域知识；一个 Interpreter Skill 内部可以 spawn 子 Agent。LangChain 文档原文："You can mix patterns! Subagents can use the skills pattern to load context on-demand."
安全：不是理论风险，是正在发生的事
OWASP 于 2026 年发布了 Agentic Skills Top 10 安全风险框架——这是第一个专门针对 Agent Skill 生态的安全标准。背景不是假设性的：
OWASP 的十大风险覆盖从注册中心投毒（Supply Chain）到 Prompt Injection via Skill、过度权限、跨 Agent 传播等。
实践层面的直接建议：
这不是远期规划，是当下已经需要落实的工程实践。
什么是确定的，什么还在演进
有充分工程验证的：
context: fork、allowed-tools），其他 Agent 静默忽略scripts/目录（可测试、可审计），判断性工作留在 SKILL.md 指令中——多个生产 Skill 库和 MLflow 的工程指南均将此作为第一原则仍在演进中的：
outdated/prune/diff退役检测）、agentskills（Rust 实现，支持 semver）、agentdeps（声明式 YAML）等。gh skill提供 immutable releases + version pinning。agentskills.io 规范仓库已有manifest 标准化提案。生态正在快速发展，但尚未收敛到单一标准name/description）已跨平台统一，但 scope、triggering conditions、dependencies、safety constraints 等扩展字段各平台定义不同。skillporter 在做跨格式兼容映射，agentskills.io 有标准化提案，但尚未收敛为统一 schema参考来源