-- 阅读之前记得关注+🌟，每天才能第一时间接收到更新 --
-- 公众号内容会定期同步到模安局网站https://moanju.org，欢迎桌面端访问收藏 --
讨论 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。传统 AI 治理更多围绕模型展开。比如模型是否准确，是否有偏见，是否可解释，是否会输出有害内容。进入大模型时代后，治理对象又扩展到提示词、接口调用、内容安全和数据泄露。Agent 不只是回答问题，它会调用工具、读取数据、生成文件、提交工单、修改代码，甚至参与审批和生产流程。此时，风险不再只是“模型说错了”，而是“系统真的被它推动着做了某件事”。例如，一个客服 Agent 查询订单状态，本身没有问题。但如果相关 Skill 允许它批量导出客户数据，风险就不再是客服问答质量，而是数据权限和隐私泄露。再比如，一个代码 Agent 可以根据需求修改代码，这也是正常能力。但如果某个 Skill 允许它自动执行脚本、读取密钥文件、绕过代码评审流程，那么风险已经进入供应链和生产安全层面。这就是 Skill 和普通工具接口的不同。API 通常是确定性接口，输入输出边界相对清楚；Skill 则更复杂，它包含意图理解、工具组合、上下文判断和流程推进。企业很难只靠 API 鉴权解决 Skill 风险。换句话说，Skill 是 Agent 行为发生前最后一道结构化边界。它不被治理，Agent 的行为就很难被治理。文章把 Agent Skill 生命周期拆成七个阶段：创建、测试、部署、监控、优化、版本管理和退役。这个框架本身并不复杂，但它指出了一个容易被忽略的问题：Skill 上线不是结束，而是开始。它会随着模型、知识库、工具权限和业务流程持续变化。如果企业只在上线前做一次评审，后续的风险漂移就很难被发现。Skill 创建阶段，最容易出现的问题是先做能力，后补治理。很多团队会先把工具接上，让 Agent 能跑通任务，再考虑权限、日志、评测和审批。这种方式适合 Demo，但不适合生产系统。因为一个 Skill 一旦接入真实业务，它就不再只是功能模块，而是带有操作后果的行为入口。这个 Skill 到底解决什么业务问题？它需要访问哪些数据？它是否涉及写操作？它能不能触发外部系统状态变化？如果出错，影响范围是单个用户、一个流程，还是整个生产系统？举个例子，“查询订单状态”和“修改订单状态”不应该混在同一个 Skill 里。“读取客户信息”和“批量导出客户信息”也应该拆开治理。前者可能是普通查询能力，后者则已经涉及敏感数据批量流转。所以，创建阶段的重点不是写一个 Skill 描述文件，而是把业务目标、权限边界和风险等级先确定下来。Agent Skill 的测试，不能只看任务是否完成。一个 Skill 在正常输入下表现很好，不代表它在异常上下文里仍然安全。Agent 的问题往往出现在多轮任务、间接提示注入、污染知识库、恶意工具返回和权限边界模糊的场景里。因此，测试阶段应该覆盖完整链路，而不是只测单轮回答。比如，一个报表生成 Skill 能否正确生成财务报表，只是基础测试。更关键的是，它在遇到异常指令时会不会扩大查询范围，会不会导出不必要的数据，会不会把内部字段写进报告，会不会在工具报错后泄露调试信息。再比如，一个代码修复 Skill 不仅要测代码能不能修好，还要看它会不会执行未经审查的脚本，会不会访问密钥文件，会不会把外部依赖引入生产工程。这类测试更接近 Agent 红队，而不是传统功能测试。测试对象不是模型的一句话，而是用户目标、模型规划、工具调用、结果反馈和后续动作组成的完整行为链。部署阶段的关键，是不要让 Skill 以“临时配置”的方式进入生产。一个生产级 Skill 至少要有清晰的资产身份。它属于哪个业务系统，由谁负责，依赖哪个模型，调用哪些工具，访问什么数据，风险等级是什么，上线前通过了哪些评测，出问题后如何回滚，这些信息都应该能查到。否则，Agent 系统会迅速变成一堆不可见能力的集合。某个团队接了一个工具，另一个团队写了一段工作流，还有人临时改了 prompt。短期内看起来效率很高，长期来看会让治理失控。真正出事故时，企业需要回答的问题往往非常具体：为什么这个 Agent 有这个权限？为什么这个 Skill 可以调用这个接口？为什么高风险操作没有人工确认？为什么上线前没有覆盖这类测试？如果 Skill 没有资产登记，这些问题很难回答。所以，部署阶段本质上是在给 Skill 建立生产身份。没有身份，就没有责任；没有责任，就谈不上治理。Skill 上线后，监控不能只看调用次数、错误率和响应延迟。这些指标能说明系统是否运行，但很难说明 Agent 行为是否正常。Agent Skill 更需要的是行为可观测：它为什么调用这个工具，在什么上下文中调用，调用路径是否符合预期，是否出现了和历史行为不同的模式。一个财务分析 Skill 突然频繁访问导出接口，可能不是错误，但值得关注。一个客服 Skill 原本只查询单个用户，最近开始批量查询用户，也未必立刻触发报错，但已经出现了行为偏移。一个代码 Agent 开始访问配置文件和密钥目录，更不能只当作普通文件访问看待。监控阶段的重点，是把这些“还没有造成事故，但已经偏离预期”的信号识别出来。这要求企业记录的不只是工具调用日志，还包括任务目标、调用链、数据访问范围、人工确认点、安全策略命中情况和版本变化。只有这些信息组合起来，才能判断一次工具调用到底是正常执行，还是风险链路的一部分。Skill 会不断被优化。团队会改 prompt，换模型，更新知识库，调整工具描述，扩展权限，或者把原来分散的步骤合成一个更自动化的流程。这些改动看起来可能都不大，但对 Agent 行为的影响并不小。工具描述写得更积极，模型可能更倾向于调用它。模型版本替换后，同一个任务可能产生不同的规划路径。知识库更新后，检索结果变化，Agent 的后续动作也可能变化。权限一旦扩大，原本安全的 Skill 也可能进入新的风险区间。所以，Skill 优化不能只看任务成功率有没有提升，也要看安全边界有没有变化。一个比较合理的做法是把优化纳入变更管理。prompt、模型、工具、权限、知识库、流程逻辑发生变化时，都应该触发差异评估。不是每次都要走完整审批，但至少要知道改了什么、影响什么、是否需要重新测试。Agent Skill 的优化，本质上不是单纯的性能调优，而是行为边界的再确认。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 的版本、调用链、工具使用、数据访问、审批记录和异常处理，都应该能被复盘。伦理关注的是业务影响。Agent Skill 如果参与招聘、信贷、客服、医疗、教育等流程，就不能只看效率，还要看是否造成不透明、不公平或不合理的自动化决策。监控关注的是持续运行。Skill 上线后是否退化，是否漂移，是否出现异常工具组合，是否产生新的高风险链路，都需要持续观察。安全关注的是攻击和滥用。提示注入、越权调用、敏感数据泄露、恶意工具描述、供应链污染和权限扩散，都是 Skill 层面的典型风险。人类监督则是责任机制。不是所有环节都需要人介入，但高风险动作、异常行为和不可逆操作必须有明确的人工确认和升级路径。如果把这篇文章转成产品语言，我认为核心能力可以概括为一个词：Skill Registry。它不是简单的 Skill 列表，而是一个治理入口。企业需要知道自己部署了哪些 Skill，它们属于哪个业务系统，谁负责，风险等级是多少，调用哪些工具，访问哪些数据，当前运行哪个版本，最近一次变更是什么，上线前做过哪些测试，是否存在异常行为。没有 Skill Registry，企业对 Agent 能力的掌握就会非常粗糙。表面上看，Agent 平台功能越来越多；实际上，很多能力散落在不同团队、不同系统、不同配置文件和不同第三方平台里。一旦缺少资产可见性，后续的权限控制、审计、监控、评测和应急都会变得被动。这也是 Skill 治理最基础的一步：先看见，再约束。这篇文章的框架还不算成熟，也缺少企业案例和实验验证。但它指出了一个很现实的方向：Agent 治理不能停留在模型层。模型决定 Agent 如何理解任务，工具决定 Agent 能连接什么系统，而 Skill 决定 Agent 如何把理解转成行动。所以，Agent Skill 不应该只是开发者手里的配置文件，也不应该只是平台上的一个能力模块。它应该被纳入企业 AI 治理体系，具备资产身份、权限边界、测试记录、运行监控、版本控制和退役机制。过去我们讨论 Skill 风险，更多关注恶意 Skill、供应链投毒和攻击样本。现在还需要补上治理视角：即使 Skill 本身不是恶意的，只要缺少生命周期管理，也可能在企业环境中变成失控入口。而 Skill，正是行为进入企业系统之前，最需要被看见、被记录、被约束的一层。
-- end --
最后记得🌟我，每天都在更新，如果觉得文章还不错的话可以点赞、转发、推荐、评论。
粤ICP备14082021号
免费POC，
零成本试错
