Skill 技能

Agent Skill七阶段生命周期与六个治理组件

2026 年 7 月 9 日

从“开发配置”到“企业资产”，Agent Skill的治理框架为何成为企业AI安全的关键一环？核心内容： 1. Skill作为“行为单元”在企业Agent中的核心作用与风险 2. 企业AI Agent Skill的七阶段生命周期管理框架 3. 支撑Skill治理的六个核心组件及其应用价值

讨论 Agent 安全时，我们很容易把注意力放在模型、提示词、工具调用和插件市场上。但在真实企业环境里，真正把风险带进业务流程的，往往是夹在模型与工具之间的 Skill。

模型负责理解任务，工具负责连接外部系统，而 Skill 负责把理解转成动作。它可能是一段工具编排逻辑，也可能是一套提示词、权限配置、工作流、知识库调用策略和异常处理规则的组合。

这意味着，Skill 并不是一个简单的能力标签。它更像 Agent 的“行为单元”。一旦进入生产环境，它就会决定 Agent 可以查什么数据、调用什么系统、修改什么状态，以及在什么条件下需要人工确认。

近期，一篇题为《Governance and Lifecycle Management of AI Agent Skills in Modern Enterprise Systems》的文章，专门讨论企业系统中 AI Agent Skill 的治理和生命周期管理。

点击下方“阅读原文”获取文章

文章提出两个核心框架：一个是 Skill 的七阶段生命周期，包括创建、测试、部署、监控、优化、版本管理和退役；另一个是六个治理组件，包括政策、审计、伦理、监控、安全和人类监督。

这篇文章不是强实验论文，也没有给出复杂攻击方法。它更像一篇治理框架型文章。它真正值得关注的地方在于：它把 Skill 从“开发配置”提升成了“企业资产”。

这个视角很重要。因为 Agent 真正上线之后，企业不只需要管理模型和 API，还需要管理这些会持续演化、持续调用系统、持续产生业务后果的 Skill。

为什么 Skill 要被单独治理？

传统 AI 治理更多围绕模型展开。比如模型是否准确，是否有偏见，是否可解释，是否会输出有害内容。进入大模型时代后，治理对象又扩展到提示词、接口调用、内容安全和数据泄露。

但 Agent 改变了问题的性质。

Agent 不只是回答问题，它会调用工具、读取数据、生成文件、提交工单、修改代码，甚至参与审批和生产流程。此时，风险不再只是“模型说错了”，而是“系统真的被它推动着做了某件事”。

例如，一个客服 Agent 查询订单状态，本身没有问题。但如果相关 Skill 允许它批量导出客户数据，风险就不再是客服问答质量，而是数据权限和隐私泄露。

再比如，一个代码 Agent 可以根据需求修改代码，这也是正常能力。但如果某个 Skill 允许它自动执行脚本、读取密钥文件、绕过代码评审流程，那么风险已经进入供应链和生产安全层面。

这就是 Skill 和普通工具接口的不同。API 通常是确定性接口，输入输出边界相对清楚；Skill 则更复杂，它包含意图理解、工具组合、上下文判断和流程推进。企业很难只靠 API 鉴权解决 Skill 风险。

换句话说，Skill 是 Agent 行为发生前最后一道结构化边界。它不被治理，Agent 的行为就很难被治理。

七阶段生命周期

文章把 Agent Skill 生命周期拆成七个阶段：创建、测试、部署、监控、优化、版本管理和退役。

这个框架本身并不复杂，但它指出了一个容易被忽略的问题：Skill 上线不是结束，而是开始。它会随着模型、知识库、工具权限和业务流程持续变化。如果企业只在上线前做一次评审，后续的风险漂移就很难被发现。

01 创建阶段：先定义边界，再开发能力

Skill 创建阶段，最容易出现的问题是先做能力，后补治理。

很多团队会先把工具接上，让 Agent 能跑通任务，再考虑权限、日志、评测和审批。这种方式适合 Demo，但不适合生产系统。因为一个 Skill 一旦接入真实业务，它就不再只是功能模块，而是带有操作后果的行为入口。

创建阶段最重要的是边界定义。

这个 Skill 到底解决什么业务问题？它需要访问哪些数据？它是否涉及写操作？它能不能触发外部系统状态变化？如果出错，影响范围是单个用户、一个流程，还是整个生产系统？

这些问题不清楚，后面的测试和审计都会变得模糊。

举个例子，“查询订单状态”和“修改订单状态”不应该混在同一个 Skill 里。“读取客户信息”和“批量导出客户信息”也应该拆开治理。前者可能是普通查询能力，后者则已经涉及敏感数据批量流转。

所以，创建阶段的重点不是写一个 Skill 描述文件，而是把业务目标、权限边界和风险等级先确定下来。

02 测试阶段：不只看任务成功率

Agent Skill 的测试，不能只看任务是否完成。

一个 Skill 在正常输入下表现很好，不代表它在异常上下文里仍然安全。Agent 的问题往往出现在多轮任务、间接提示注入、污染知识库、恶意工具返回和权限边界模糊的场景里。

因此，测试阶段应该覆盖完整链路，而不是只测单轮回答。

比如，一个报表生成 Skill 能否正确生成财务报表，只是基础测试。更关键的是，它在遇到异常指令时会不会扩大查询范围，会不会导出不必要的数据，会不会把内部字段写进报告，会不会在工具报错后泄露调试信息。

再比如，一个代码修复 Skill 不仅要测代码能不能修好，还要看它会不会执行未经审查的脚本，会不会访问密钥文件，会不会把外部依赖引入生产工程。

这类测试更接近 Agent 红队，而不是传统功能测试。测试对象不是模型的一句话，而是用户目标、模型规划、工具调用、结果反馈和后续动作组成的完整行为链。

03 部署阶段：Skill 上线要有资产身份

部署阶段的关键，是不要让 Skill 以“临时配置”的方式进入生产。

一个生产级 Skill 至少要有清晰的资产身份。它属于哪个业务系统，由谁负责，依赖哪个模型，调用哪些工具，访问什么数据，风险等级是什么，上线前通过了哪些评测，出问题后如何回滚，这些信息都应该能查到。

否则，Agent 系统会迅速变成一堆不可见能力的集合。某个团队接了一个工具，另一个团队写了一段工作流，还有人临时改了 prompt。短期内看起来效率很高，长期来看会让治理失控。

真正出事故时，企业需要回答的问题往往非常具体：为什么这个 Agent 有这个权限？为什么这个 Skill 可以调用这个接口？为什么高风险操作没有人工确认？为什么上线前没有覆盖这类测试？

如果 Skill 没有资产登记，这些问题很难回答。

所以，部署阶段本质上是在给 Skill 建立生产身份。没有身份，就没有责任；没有责任，就谈不上治理。

04 监控阶段：从日志记录走向行为可观测

Skill 上线后，监控不能只看调用次数、错误率和响应延迟。

这些指标能说明系统是否运行，但很难说明 Agent 行为是否正常。Agent Skill 更需要的是行为可观测：它为什么调用这个工具，在什么上下文中调用，调用路径是否符合预期，是否出现了和历史行为不同的模式。

一个财务分析 Skill 突然频繁访问导出接口，可能不是错误，但值得关注。一个客服 Skill 原本只查询单个用户，最近开始批量查询用户，也未必立刻触发报错，但已经出现了行为偏移。一个代码 Agent 开始访问配置文件和密钥目录，更不能只当作普通文件访问看待。

监控阶段的重点，是把这些“还没有造成事故，但已经偏离预期”的信号识别出来。

这要求企业记录的不只是工具调用日志，还包括任务目标、调用链、数据访问范围、人工确认点、安全策略命中情况和版本变化。只有这些信息组合起来，才能判断一次工具调用到底是正常执行，还是风险链路的一部分。

05 优化阶段：小改动也可能改变行为边界

Skill 会不断被优化。团队会改 prompt，换模型，更新知识库，调整工具描述，扩展权限，或者把原来分散的步骤合成一个更自动化的流程。

这些改动看起来可能都不大，但对 Agent 行为的影响并不小。

工具描述写得更积极，模型可能更倾向于调用它。模型版本替换后，同一个任务可能产生不同的规划路径。知识库更新后，检索结果变化，Agent 的后续动作也可能变化。权限一旦扩大，原本安全的 Skill 也可能进入新的风险区间。

所以，Skill 优化不能只看任务成功率有没有提升，也要看安全边界有没有变化。

一个比较合理的做法是把优化纳入变更管理。prompt、模型、工具、权限、知识库、流程逻辑发生变化时，都应该触发差异评估。不是每次都要走完整审批，但至少要知道改了什么、影响什么、是否需要重新测试。

Agent Skill 的优化，本质上不是单纯的性能调优，而是行为边界的再确认。

06 版本管理：事故复盘不能靠猜

版本管理是这篇文章里最有现实意义的一部分。

Agent Skill 和普通代码不同。它通常由多种东西组成：prompt、manifest、工具描述、权限配置、模型版本、知识库索引、安全策略和流程逻辑。任何一项变化，都可能改变最终行为。

如果没有版本管理，事故复盘会非常困难。

当时运行的是哪个 Skill 版本？工具描述是不是后来改过？模型有没有切换？知识库是不是同一批？权限是不是临时放宽过？人工确认策略当时是否生效？

这些问题如果回答不上来，企业就只能依赖日志碎片和人员记忆。这样的复盘很难支撑问责，也很难支撑改进。

因此，Skill 版本管理不能只管代码仓库。它应该覆盖 Skill 运行所依赖的所有关键要素。尤其是 prompt、工具描述、权限配置和模型版本，这些内容往往不被传统软件工程流程充分管理，但它们对 Agent 行为有直接影响。

从这个角度看，Agent Skill 更像一种半结构化软件资产。它需要类似软件工程的版本机制，也需要 AI 治理的评测机制。

07 退役阶段：旧 Skill 可能比新 Skill 更危险

企业通常重视上线，不太重视下线。

但对 Agent Skill 来说，退役阶段非常重要。一个 Skill 不再被主流程使用，不代表它已经彻底消失。它可能还保留旧权限，仍然能被路由系统命中，仍然持有 Token，仍然连接旧知识库，甚至仍然被某个自动任务周期性调用。

这些“僵尸 Skill”很容易成为隐藏攻击面。

攻击者不一定会攻击最新版本，也不一定会从主流程突破。旧 Skill、旧依赖、旧密钥和旧权限，往往更容易被忽视。

因此，Skill 退役不能只是删除一个配置。它还要清理调用入口、吊销密钥、移除权限、更新路由、归档日志，并保留必要审计证据。如果有替代 Skill，还要确认业务流程已经完成迁移。

生命周期管理如果没有退役环节，就不是真正闭环。

六个治理组件

文章提出的六个治理组件包括政策、审计、伦理、监控、安全和人类监督。单看这些词，它们并不新。但放到 Skill 层面后，含义会变得更具体。

政策解决的是准入和边界。哪些 Skill 可以上线，哪些必须审批，哪些场景禁止自动化，哪些动作必须人工确认，都要在政策层面明确。

审计解决的是可追溯。Skill 的版本、调用链、工具使用、数据访问、审批记录和异常处理，都应该能被复盘。

伦理关注的是业务影响。Agent Skill 如果参与招聘、信贷、客服、医疗、教育等流程，就不能只看效率，还要看是否造成不透明、不公平或不合理的自动化决策。

监控关注的是持续运行。Skill 上线后是否退化，是否漂移，是否出现异常工具组合，是否产生新的高风险链路，都需要持续观察。

安全关注的是攻击和滥用。提示注入、越权调用、敏感数据泄露、恶意工具描述、供应链污染和权限扩散，都是 Skill 层面的典型风险。

人类监督则是责任机制。不是所有环节都需要人介入，但高风险动作、异常行为和不可逆操作必须有明确的人工确认和升级路径。

企业真正缺的是 Skill Registry

如果把这篇文章转成产品语言，我认为核心能力可以概括为一个词：Skill Registry。

也就是企业级 Skill 注册中心。

它不是简单的 Skill 列表，而是一个治理入口。企业需要知道自己部署了哪些 Skill，它们属于哪个业务系统，谁负责，风险等级是多少，调用哪些工具，访问哪些数据，当前运行哪个版本，最近一次变更是什么，上线前做过哪些测试，是否存在异常行为。

没有 Skill Registry，企业对 Agent 能力的掌握就会非常粗糙。表面上看，Agent 平台功能越来越多；实际上，很多能力散落在不同团队、不同系统、不同配置文件和不同第三方平台里。

一旦缺少资产可见性，后续的权限控制、审计、监控、评测和应急都会变得被动。

这也是 Skill 治理最基础的一步：先看见，再约束。

写在最后

这篇文章的框架还不算成熟，也缺少企业案例和实验验证。但它指出了一个很现实的方向：Agent 治理不能停留在模型层。

模型决定 Agent 如何理解任务，工具决定 Agent 能连接什么系统，而 Skill 决定 Agent 如何把理解转成行动。

在企业环境里，真正产生后果的是行动。

所以，Agent Skill 不应该只是开发者手里的配置文件，也不应该只是平台上的一个能力模块。它应该被纳入企业 AI 治理体系，具备资产身份、权限边界、测试记录、运行监控、版本控制和退役机制。

过去我们讨论 Skill 风险，更多关注恶意 Skill、供应链投毒和攻击样本。现在还需要补上治理视角：即使 Skill 本身不是恶意的，只要缺少生命周期管理，也可能在企业环境中变成失控入口。

Agent 时代，治理对象正在从模型扩展到行为。

而 Skill，正是行为进入企业系统之前，最需要被看见、被记录、被约束的一层。

-- end --

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们

Agent Skill七阶段生命周期与六个治理组件

立即咨询 JOTO

想把这些做法用到你的业务里?

开启企业级 AI 落地

填写需求单