一、为什么需要 Skill / Plugin：Agent 自身的局限性

一个大语言模型在出厂时只有三件事：参数化的语言能力、有限的上下文窗口、对外的文本接口。它不是专家系统，不是业务系统，不是安全平台，更不是所有企业里每个数据源和 API 的连接器。

要让 Agent 真正在企业里干活，至少要解决四类问题：

1. 知识陈旧：模型参数停在训练截止日，不知道今天的 CVE、今天的告警、今天的资产状态。

2. 能力缺失：模型不会真正执行 SQL、不会提交工单、不会隔离终端、不会渲染 PPT。

3. 环境隔离：企业的数据、工具、API 都在防火墙后面，模型够不到。

4. 复用与治理：每个任务都重新写一遍工具调用脚本，既低效也无法审计和共享。

Skill、Plugin、Tool、MCP 都是为解决这些问题而出现的不同形态的能力扩展机制。 它们的目标相近，但抽象层次、生命周期和管理方式不同。混用是常见现象，但混用 ≠ 等价。

---

二、四个概念，先把边界划清楚

下面这张表是后面所有讨论的基础。建议直接读三遍。

维度	Tool（工具）	Function Calling（函数调用）	Plugin（插件）	Skill（技能）	MCP（Model Context Protocol）
抽象层次	原子能力（一个具体动作）	协议层机制	平台级扩展包	任务级能力包	协议/标准
典型例子	query_siem_logs、isolate_endpoint	OpenAI tools 字段、Claude tool use	ChatGPT Plugin、Coze 插件	文档型/代码型 Skill	MCP Server
谁来提供	工程师写一段代码	模型厂商提供接口规范	平台运营方审核上架	用户/团队自行编写或由官方提供	协议作者 + 任意实现者
生命周期	临时/常驻	协议，无生命周期	平台审核、安装、卸载	编写、测试、发布、版本化、下架	协议 + 实现
调用方式	LLM 决定调哪个	LLM 决定如何填参数	用户在 UI 里启用	Agent 运行时按需加载	LLM 按 schema 调用
适合表达	“隔离这台主机”	“我要让模型能调函数”	“让 ChatGPT 能联网”	“如何写一份调研报告”	“让任何模型都能连这个数据库”
是否模型无关	不一定	不一定	多数强绑平台	多模型可复用	设计上模型无关

2.1 Tool：原子动作

Tool 是最小的可执行单元。一个 Tool 解决一件事：查一条日志、算一个 hash、提交一个工单。它通常包含：

• 名称和用途描述（用于 LLM 选择）

• 输入参数 schema

• 返回结构

• 错误语义

• 权限范围

• 是否需要审批

Tool 不携带“流程知识”，只携带“能力描述 + 执行代码”。它是最基础也最危险的一层——权限配错、参数不校验、错误不收敛，就会把 Agent 变成事故放大器。

2.2 Function Calling：让模型“会”调 Tool

Function Calling 本身不是 Tool，是 LLM 的一种结构化输出能力。模型在判断当前任务需要外部信息或动作时，会按预定义的 schema 吐出参数，由宿主程序（agent runtime）解析后再去执行真实代码。

没有 Function Calling，Agent 调 Tool 只能靠正则解析自然语言——这是早期 LangChain 痛苦经历的来源。今天所有严肃的 Agent 系统都建立在结构化 tool call 之上。

2.3 Plugin：平台级能力包

Plugin 的代表是 ChatGPT Plugin、Coze 插件、Dify 工具插件。它通常包含：

• 一组 Tool

• 一份面向 LLM 的描述文件（manifest）

• 一组可选的 UI 元素

• 平台审核过的发布渠道

Plugin 的特征是“绑平台”。它把 Tool 打包成一个可以在平台市场里安装/卸载的产物，强调“发现-安装-调用-更新”的完整产品体验。优点是开箱即用，缺点是跨平台不通用、跨模型不通用。

2.4 Skill：任务级能力包

Skill 是 2024 年之后随着 Claude / Mavis / 类似系统普及起来的概念。它强调三件事：

1. 任务级封装：Skill 描述的是“如何完成一类任务”，而不是“如何调一个 API”。比如“写一份安全事件复盘报告”是一个 Skill，里头可能包含调用多个 Tool、读多份模板、按步骤检查的逻辑。

2. 可携带的指令与知识：Skill 通常包含一份 markdown 形式的 SKILL.md，写明能力描述、适用场景、不适用场景、调用流程、注意事项。

3. 可选的执行代码：很多 Skill 是纯文档+提示词（让模型照着做），也有 Skill 配套 Python 脚本、shell 命令或 MCP Server。

Skill 不是取代 Tool，而是 Tool 之上的“做事方式”。Tool 是手，Skill 是工作流。

2.5 MCP：模型与工具之间的开放协议

MCP（Model Context Protocol）由 Anthropic 在 2024 年提出，目标是把“模型怎么调用工具、读取资源、获取提示”这件事变成一个跨厂商的标准协议。

类比一下：USB-C 让不同设备用同一种物理接口，MCP 让不同模型用同一种“工具接口”。MCP Server 描述自己提供哪些 tool/resource/prompt，模型按 schema 调用。

MCP 解决的是“协议碎片化”。但它不解决：

• Tool 自身是否安全

• 数据是否合规

• 错误如何处理

• 谁来审核 Server

重要判断：MCP 是基础设施，Skill 是产品形态。两者层级不同。

---

三、Skill 真正解决了哪些问题

把 Skill 单独拎出来，是因为它对应一种新的工程范式。原文反复强调“Agent 的价值在流程设计、证据链、权限治理”，Skill 正是把这些“流程和治理”沉淀下来的载体。

3.1 把专家经验沉淀成可复用资产

一位高级安全分析师的判断力，本质是十几年经验压缩成的模式识别。这些经验在传统组织里只能口口相传。Skill 是一份“可以被 Agent 阅读并执行”的经验文档。

举个例子：一个 SOC 高级分析师的“钓鱼邮件分诊经验”，可以写成这样的 Skill：

# Skill: 钓鱼邮件分诊
​
## 适用场景
- 用户上报的疑似钓鱼邮件
- 已触发邮件安全告警
​
## 不适用
- 已确认为内部安全演练
- 附件无下载行为的纯文字广告
​
## 标准流程
1. 提取邮件头、发件人 IP、SPF/DKIM/DMARC 结果
2. 抓取所有 URL，查询威胁情报与首次出现时间
3. 解压附件到沙箱，记录行为（进程、网络、文件）
4. 关联收件人近期异常登录
5. 给出 1-5 的风险分 + 证据列表
6. 高风险自动建议隔离终端 + 撤销 OAuth token
​
## 必须人工复核的条件
- 涉及高管或财务账号
- 沙箱无法启动但附件可执行
- 评分 ≥ 4 且无明确 IOC

这段 markdown 本身就是一个 Skill。它不依赖任何代码，但被加载进 Agent 后，Agent 会按它去调用工具、组织输出、保留人工审批点。

3.2 把分散的工具组织成有边界的工作流

Tool 是离散的。一个 SIEM 查询 Tool、一个 EDR 隔离 Tool、一个 IAM 禁用 Tool 分别属于不同团队。没有 Skill 的时候，模型只能临时拼装这些 Tool，出了错也无处追溯。

Skill 把这些调用关系写成“标准操作程序”，并且：

• 标注每一步的输入前置条件

• 标注每一步的失败回退

• 标注关键决策点的审批要求

• 保留对每一步证据的要求

这样即便 LLM 换了、Tool 换了，流程不会跟着换。

3.3 让 Agent 在面对陌生任务时“有说明书”

工程实践中，最尴尬的事情不是 Agent 不会做，而是它会做但做错。比如：

• 让它写一份合规报告，它引用了没出处的法规

• 让它做漏洞排序，它把内部资产和外网资产混在一起

• 让它生成 YARA 规则，它生成了能匹配自家业务的规则并删了文件

Skill 是“这次任务，请这样做”的说明书。它在加载到上下文时，会显式告诉 Agent：

• 任务范围是什么

• 关键术语如何定义

• 哪些操作是禁止的

• 输出格式是什么

• 出现分歧时优先听谁

这相当于把一个团队的工作手册变成了可被 Agent 加载的运行时配置。

3.4 让权限和审计有承载物

Skill 本身在设计上可以携带：

• 所需的 Tool 列表

• 所需的数据范围

• 是否允许自动执行

• 是否需要审批

• 默认的审计要求

一个组织可以把“允许自动执行”这件事从“相信 Agent”变成“允许这个 Skill 在这个范围内自动执行”。这两件事的差别巨大。

3.5 让能力可被多个 Agent 复用

这是最朴素也最关键的一点。一旦一个 Skill 写好，它可以被不同的 Agent 加载：一个聊天机器人、一个自动化流水线、一个 CI 里的代码评审机器人，都可以共享同一份 Skill。

没有 Skill 的 Agent 生态是孤岛化的；有了 Skill，团队内可以形成“能力市场”。

---

四、Skill、Plugin、Tool 的关系图

把上面这些关系画到一张图上更清楚。原文中的架构图（第二章）是横向的“数据-知识-推理-工具-安全”五层；这里画的是纵向的“模型—Skill—Plugin—Tool—外部系统”调用链。

要点：

• LLM 在最上层。它不直接接触外部世界，只负责理解和决策。

• Skill 在第二层。它向 LLM 描述“这一类任务怎么做”，并决定要调哪些 Plugin/Tool。

• Plugin 在第三层（可选）。它是平台化的工具包，常常把多个 Tool 包成一个发布单元。

• Tool 在第四层。每个 Tool 对应一个具体动作。

• MCP 横跨第三和第四层。它是一种协议，让 Tool 描述变得可移植。

• 外部系统在最底层。SIEM、EDR、CI/CD、CRM、Jira、文档系统都在这里。

判断一个组织 Agent 成熟度的简单指标：

成熟度等级	表现
L0 聊天	只能聊，不能干活
L1 Tool 接入	能调几个 Tool，但每次都要现写
L2 Skill 沉淀	有标准 Skill 库，新任务先查 Skill
L3 Plugin 生态	内部出现 Skill/Plugin 上架、审核、计费
L4 跨 Agent 复用	多 Agent 共享 Skill 库，权限可声明
L5 治理闭环	Skill 自身有红队、审计、版本、合规要求

原文第十二章对“安全 Agent 长期竞争力”的判断，落到工程层面其实就是这一张表的差距。

---

五、推荐 Skill：选得对，比写得快重要

这一节给一个“为什么要推荐”的框架，再列几类值得长期投入的方向。Skill 好不好用，取决于它是不是真的把“判断+流程+工具”三件事组合好，而不是名字好不好听。

5.1 评估一个 Skill 的 6 条硬标准

无论你用哪个平台的 Skill，建议先用这 6 条做最低限度筛选：

1. 能力边界是否清晰 Skill 必须在文档里写明“适用 / 不适用”。凡是那种“什么都能做”的 Skill，要么是营销稿，要么实际效果差。

2. 证据要求是否明确 好的 Skill 规定每一步要保留什么证据（事件 ID、日志行、查询语句、决策理由）。没有证据要求的 Skill 等同于黑盒。

3. 失败回退是否写明 Tool 调用失败、沙箱拒绝、权限不足、网络异常，每一种失败应该怎么处理？如果 Skill 没写，就是把设计责任甩给模型。

4. 危险动作是否标记 隔离终端、撤销 token、删除文件、对外发送消息——这些动作必须显式标出，不能藏在自然语言里。

5. 数据范围是否声明 这个 Skill 会读到哪些日志、哪些用户、哪些业务？涉及敏感数据时是否声明了脱敏或审批？

6. 版本与所有者 任何可上线的 Skill 都该有版本号、作者、最后审核时间。否则 6 个月后没人知道它在干什么。

5.2 几类值得长期投入的方向

下面列的不是某一家产品的 Skill 名单，而是判断哪些类别值得自己团队投入资源去写或集成的指南。每一类都给出“为什么要做”和“典型代表”。

类别 A：信息检索与外部事实类

• 解决什么：模型知识陈旧、引用不可信。

• 典型能力：网页搜索、抓取、引用源、读取 X/Twitter、读 PDF 论文。

• 为什么值得：所有研究类、合规类、威胁情报类任务都依赖它。质量差时整条链路都被污染。

• 代表能力：web_search、web_fetch、x-link-reader、带源引用的 PDF 解析。

• 评估重点：是否声明来源、是否标注引用版本、是否处理反爬与登录墙。

类别 B：结构化文档处理类

• 解决什么：企业里的报告、合同、报价单、扫描件是模型最不愿意处理的东西。

• 典型能力：读取和生成 DOCX、PDF、PPTX、XLSX；按模板套版；保格式。

• 为什么值得：报告生成是安全、合规、咨询、IT 部门最常见的“写报告”任务。能保住格式和可追溯性，节省的不是 10%，是 5 倍。

• 代表能力：docx、pdf、pptx、xlsx 这类专用 Skill。

• 评估重点：表格、字体、页眉页脚、母版、公式、嵌入对象能不能保住。

类别 C：研发与代码协作类

• 解决什么：让 Agent 安全地碰代码、跑测试、提 PR。

• 典型能力：读仓库、写补丁、跑单元测试、安全扫描、生成 changelog。

• 为什么值得：开发者场景下最大痛点从来不是“能不能写代码”，而是“会不会碰坏主干”。Skill 能强制流程。

• 代表能力：把 code-reviewer、tester 类能力封装成 Skill，并配最小权限。

• 评估重点：是否限制仓库、是否禁止 push、是否必须人类合并。

类别 D：工作流与协作平台类

• 解决什么：把 Agent 嵌进飞书、Slack、邮件、Jira、Notion。

• 典型能力：发消息、建工单、回评论、上传文档、读日历。

• 为什么值得：Agent 的最大价值在于“把信息推到人面前”，而不是等人在终端里查。

• 代表能力：lark-tools、邮件/IM 类 Skill、Jira/Linear 集成。

• 评估重点：消息发送是否可审计、@人是否走审批、外部群消息是否阻断。

类别 E：数据查询与可视化类

• 解决什么：让自然语言直接对接数据仓库、BI 平台、数据库。

• 典型能力：自然语言转 SQL、自然语言生成图表、dashboard 截图。

• 为什么值得：业务人员最常用、最不擅写代码的场景。做好了覆盖面极大。

• 代表能力：基于 MCP 的数据库连接 Skill、BI 平台 Skill。

• 评估重点：只读 vs 写、列级权限、是否禁止生产环境写入、是否带 SQL 解析校验。

类别 F：垂直领域专业类

• 解决什么：让 Agent 在一个具体领域（安全、医疗、法务、运维）里有真正的判断力。

• 典型能力：安全事件分诊、漏洞优先级排序、合同审查、病例摘要。

• 为什么值得：通用模型永远不够“专”。Skill 是把领域专家经验模型化的最便宜路径。

• 代表能力：安全 SOC triage、漏洞优先级排序、应急响应剧本。

• 评估重点：是否引用行业框架（MITRE ATT&CK、OWASP、NIST）、是否允许建议改生产配置。

如果只能选一类先做，建议从 F（垂直领域）和 E（数据查询）入手。它们的 ROI 最直接，且不容易被通用模型自带能力快速替代。

---

六、安全 Agent 的 Skill 生态：原文的延伸

原文已经讲了安全 Agent 能做什么、能用在哪些环节。这里给一个“Skill 视角的再切分”：每一种安全任务，更适合用哪种 Skill 来承载。

6.1 SOC 告警分诊的 Skill

• 核心 Tool：SIEM 查询、威胁情报查询、资产上下文、用户上下文。

• 核心 Skill：分诊决策树（按告警类型路由）、误报模式库、相似事件检索。

• 关键设计：所有结论必须给事件 ID + 时间窗 + 证据命令。

6.2 事件调查的 Skill

• 核心 Tool：跨 SIEM/EDR/IAM/邮件查询。

• 核心 Skill：MITRE ATT&CK 映射剧本、时间线拼接剧本、影响范围扩散剧本。

• 关键设计：调查计划要可被人工预审；每一步要可回滚。

6.3 检测工程的 Skill

• 核心 Tool：Sigma 规则仓库、测试集、日志回放平台。

• 核心 Skill：规则生成→回测→误报评估→灰度发布 流程封装。

• 关键设计：禁止直推生产；必须带 dry-run 模式。

6.4 漏洞与修复的 Skill

• 核心 Tool：漏洞库、资产库、补丁库、CI/CD。

• 核心 Skill：受影响资产定位、补丁测试、修复说明生成。

• 关键设计：不允许改生产代码；合并必须有 PR review。

6.5 钓鱼与身份安全的 Skill

• 核心 Tool：邮件网关、URL 沙箱、IAM 系统。

• 核心 Skill：钓鱼初筛剧本、账号异常分析剧本、条件访问策略审阅剧本。

• 关键设计：高管账号强校验；策略变更必须双签。

6.6 云与配置安全的 Skill

• 核心 Tool：CSPM、IaC 仓库、云 API。

• 核心 Skill：组合风险识别、漂移检测、修复回滚剧本。

• 关键设计：禁止绕过 IaC 在控制台改；改前必须生成 plan。

这些 Skill 单独看都不复杂，难的是把它们统一治理起来——谁写、谁审、谁签、谁背锅。这正是原文第八章“Agent 自身安全”必须延伸的领域：Skill 也是供应链的一部分。

---

七、如何自己写一个 Skill：从工程到上线的全过程

这一节是给要动手的读者写的。写一个 Skill 容易，写一个能上线的 Skill 难。下面按时间顺序展开。

7.1 第一步：选场景，先回答 4 个问题

在写任何代码或文档前，先回答：

1. 这个任务在团队里发生的频率是多少？ 每月不到 5 次的，不要做 Skill，要么写文档，要么人做。

2. 有可参考的人工标准流程吗？ 没有 SOP 的任务不要做。Agent 不能创造流程，只能执行流程。

3. 能列出成功的定义吗？ 至少 3 条可观测的判断标准（比如：风险分给出、证据完整、未触发禁区动作）。

4. 能在沙箱里验证吗？ 跑不到测试环境的，先做能跑通的最小版本，不要直接上生产。

7.2 第二步：拆任务，分清“模型做”和“代码做”

把任务拆到每一步，标记每一步是：

• 模型任务：需要自然语言理解（摘要、判断、解释）。

• 代码任务：确定性逻辑（解析、计算、查询、写入）。

• 审批任务：必须人工确认（隔离、删除、对外通讯）。

经验法则：能用代码做就不要让模型做。 模型做的部分越少，整体可靠性越高。

7.3 第三步：写 SKILL.md（核心交付物）

一份合格的 SKILL.md 应至少包含：

# Skill: <名称>
​
## 适用场景
- ...
- ...
​
## 不适用
- ...
- ...
​
## 前置条件
- 所需 Tool 列表
- 所需数据范围
- 所需权限
- 依赖的外部系统
​
## 标准流程
1. ...
2. ...
3. ...
​
## 输入输出契约
- 输入 schema
- 输出 schema
- 错误码定义
​
## 危险动作与审批
- ...
​
## 证据要求
- 每个结论必须保留的最小证据集
​
## 失败回退
- 各类失败的处理方式
​
## 评测样例
- 至少 3 个正向样例
- 至少 3 个负向样例
- 至少 1 个对抗样例
​
## 版本与所有者
- 版本：vX.Y.Z
- 作者：
- 审核人：
- 最近评审时间：

7.4 第四步：搭建工程目录

一个最小可工作 Skill 的目录结构：

my-skill/
├── SKILL.md              # 必填，Skill 描述文件
├── README.md             # 给人看的快速说明
├── scripts/              # 可执行代码
│   ├── main.py
│   └── helpers.py
├── prompts/              # 提示词片段
│   └── triage_prompt.md
├── tests/                # 评测样例
│   ├── positive/
│   ├── negative/
│   └── adversarial/
├── examples/             # 调用样例
│   └── sample_input.json
├── schemas/              # 输入输出 schema
│   ├── input.schema.json
│   └── output.schema.json
├── docs/                 # 设计文档、ADR
│   └── design.md
└── CHANGELOG.md

为什么强调目录？ 因为 Skill 不是一次性脚本。它会演进、会出 bug、会被同事接手。没有结构，3 个月后没人能维护。

7.5 第五步：实现 Tool 与脚本

• Tool 的输入参数必须严格 schema 化。

• Tool 的返回必须结构化（JSON 优先）。

• Tool 必须显式声明权限（只读、可逆、破坏性、需要审批）。

• 任何外部 API 调用必须带超时、重试、熔断。

• 任何敏感数据（密钥、token、个人信息）禁止打到日志。

7.6 第六步：写评测集

没有评测集的 Skill 不可上线。最低要求：

• 正向样例 ≥ 3：典型输入，期望输出。

• 负向样例 ≥ 3：常见误用、模糊输入、超出场景。

• 对抗样例 ≥ 1：提示词注入、误导信息、伪装权威。

• 回归样例：历史上修过的 bug 不能再现。

评测方式可以是：

• 模型打分（粗评，效率高）

• 规则校验（输出必须包含特定字段、证据 ID）

• 人工抽样（关键样例必须人工复核）

7.7 第七步：发布与版本管理

• 用语义化版本号（SemVer）：主版本表示不兼容变更，次版本表示新增能力，修订版本表示 bug 修复。

• 每次发布更新 CHANGELOG.md。

• 对危险动作，必须保留降级路径——能回滚到上一版本。

• 在 Skill 库注册：作者、所有者、最后审核、过期时间。

7.8 第八步：上线后持续运营

Skill 不是写完就结束。它需要：

• 运行监控：调用次数、失败率、平均时长、Token 消耗。

• 质量监控：抽样人工复核、用户投诉、误报漏报。

• 攻击监控：异常输入、提示词注入尝试、越权请求。

• 定期复审：每季度或重大变更后重新审核一遍。

• 退役机制：长期不用、问题多、有更好替代品时及时下架。

7.9 写 Skill 时的 10 条反模式

反模式	为什么是反模式	正确做法
把 Skill 当万能工具	没有边界，Agent 误用	显式写明适用/不适用
把所有逻辑塞进 prompt	模型扛不住	拆到代码，prompt 只描述流程
危险动作隐藏在自然语言里	不可审计	显式标出并配审批
Tool 无 schema	参数错乱	严格 JSON schema 校验
没有失败回退	一次失败整链崩溃	显式写每种失败的处理
评测只有正向样例	边界全黑	必须有负向和对抗样例
没有版本号	行为漂移不可控	SemVer + CHANGELOG
敏感数据打到日志	泄露风险	显式脱敏，日志分级
一个人写、一个人审、一个人用	治理失效	至少两人审、责任分离
写完不维护	半年后失效	入库时设过期时间、季度复审

---

八、Skill 与 MCP 的关系：协议 vs 资产

常常被混淆的还有 Skill 和 MCP。这里再做一次切分：

• MCP 解决的是“模型怎么找到、调起来、传参、读回结果”。它是协议，关心的是兼容性和可移植性。

• Skill 解决的是“模型面对这一类任务应该怎么做”。它是资产，关心的是流程、判断和经验。

一个 Skill 可以：

• 完全不依赖 MCP（纯文档+prompt）

• 调用 MCP Server（用 MCP 协议连工具）

• 调用传统 Tool（用 Function Calling）

• 混合上述三种

所以把 MCP 当 Skill 的替代品是错的。 真正高水平的工程实践是：

1. 底层用 MCP 统一工具接口（换模型不换工具）。

2. 上层用 Skill 沉淀工作流（换工具不换流程）。

3. 中间用 Function Calling 让模型能调（这是协议本身）。

层次	关心的问题	典型问题示例
协议层（MCP / Function Calling）	模型怎么找到、调起工具	schema 怎么定义、超时怎么处理
资产层（Skill）	面对任务怎么做	风险分怎么算、证据怎么留
资源层（Tool / MCP Server）	工具本身怎么实现	SQL 怎么写、权限怎么校验

---

九、Skill 自身的供应链与安全

原文第八章讲了 Agent 自身的风险。Skill 也是攻击面：

• 恶意 Skill：模仿合法 Skill 名字，诱导 Agent 加载并泄露数据。

• 污染 Skill：作者埋入提示词注入或工具滥用，几个月后被调用时触发。

• 过时 Skill：行为漂移到不再适合当前环境，但仍在被调用。

• 越权 Skill：作者声明的能力范围与代码实际行为不一致。

缓解措施：

• 签名与来源验证：只加载白名单 Skill，校验作者签名。

• 静态扫描：上架前扫描 SKILL.md、脚本、依赖。

• 沙箱运行：高风险 Skill 在隔离环境跑。

• 版本固定：禁止 Skill 在运行时自动升级。

• 红队评测：每季度对核心 Skill 做对抗测试。

• 运行时监控：监控 Tool 调用频次、参数分布、错误率，偏离基线即告警。

OWASP Agentic AI Top 10（2025）已经明确把“工具滥用”、“供应链”列入风险，和这一节的判断一致。

---

十、给团队的三条具体建议

最后给三条可执行建议，不是泛泛而谈。

10.1 把“Skill 化”作为 Agent 项目的硬性要求

任何新 Agent 任务，如果不能在 4 周内沉淀成一个可复用的 Skill，要么说明这个任务不该上 Agent，要么说明你的流程没梳理清楚。这条规则比任何架构图都管用。

10.2 建立一个内部 Skill 评审委员会

成员至少包括：业务负责人、安全负责人、平台工程。每月过一遍新 Skill、季度过一遍存量 Skill。所有上架 Skill 必须有版本号、作者、所有者、过期时间。

10.3 把 Skill 数量当作指标

但要分两类看：

• 好指标：复用人次（一个月被调用多少次）、成功率、用户主动收藏数。

• 坏指标：Skill 总数（容易催生大量低质量 Skill）。

长期看，复用率比数量重要 10 倍。

---

十一、本节与原文的衔接点

原文章节	本节的衔接
二、技术架构	把“工具层”展开为 Skill / Plugin / Tool / MCP 四层
三、应用场景	给出每类安全任务应该对应哪种 Skill
八、Agent 自身风险	强调 Skill 自身就是供应链
十、未来发展	指出“Skill 库”是衡量组织 Agent 成熟度的核心指标
十二、结论	落到工程：Agent 的长期价值 = 数据 × 工具 × Skill × 治理

---

十二、一句话总结

Tool 是手，Skill 是工作流，MCP 是接口标准，Plugin 是平台分发。 真正让一个组织的 Agent 从“能用”走向“好用”的，不是更多 Tool，而是一套被验证、被治理、可被复用的 Skill 库。 安全场景尤其如此——流程和证据比“能不能聊天”重要得多。

---

附录 A：快速对照表

你是……	你应该关心什么
Agent 用户	挑 Skill 时看边界、证据、危险动作标记
业务负责人	推动把高频任务 Skill 化，关注复用人次
平台工程	建设 Skill 库、版本管理、签名审核
安全团队	把 Skill 当供应链治理，做红队评测
模型研究者	关注 Skill 是否被加载到上下文、如何影响推理
创业者	选一个垂直领域，做“领域 Skill + MCP 服务”

附录 B：延伸阅读

• OWASP Agentic AI Threats and Mitigations (2025)

• NIST AI Risk Management Framework

• Anthropic Model Context Protocol 规范

• 各平台官方 Skill 文档（Claude / Mavis / 类似系统）

资料可靠性说明同原文： 产品功能引用厂商公开资料；评测、复用人次、危险动作等建议需在企业真实环境中验证；本节不构成对任何具体产品的购买建议。