9月19日前后，围绕Agent Skill Supply Chain的讨论再次集中爆发。它不是由某一天的安全事件引爆的，更像是过去几个月零散研究汇聚后的共识浮出水面：随着AI Agent通过Skill不断获得新工具、接口和业务能力，一种与传统软件供应链截然不同的新型供应链正在成型。

传统软件供应链最核心的问题是"进入系统的代码是否可信"。Agent Skill带来的问题更进一步——被安装进来的不只是代码，而是一种新的行动能力。只要这个Skill能继承Agent已有的Credential、文件系统、Shell、网络、API或其他Tool权限，一次看似普通的"安装"，实际上就在改变这个主体能对现实世界做什么。

安装Skill正在从软件配置动作，变成一种Authority Expansion（权限扩张）。 这可能是理解Agent Skill安全最重要的起点。

一、传统Package安装代码，Agent Skill安装"能力"

过去二十年，软件供应链已经建立了一套成熟的安全直觉：一个npm包进入生产环境前，关心来源、完整性、依赖漏洞、维护者可信度、是否执行超预期行为。这些在Agent时代依然存在，但已经不足以描述Skill的风险。

Palo Alto Networks Unit 42扫描OpenClaw Registry中大量Skill后发现，相当高比例的Skill存在"声明能力与实际行为不一致"的情况。这里不能简单等同于"大量恶意软件"——很多偏差来自开发者声明不完整、辅助代码未被描述、框架依赖被忽略或文档没覆盖真实运行路径。

但这项研究真正重要的地方在于它改变了问题本身：

• 过去问的是：这段代码有没有恶意行为？

• 现在要进一步问：它声称能做什么，与它实际能做什么之间，是否一致？

一个Skill声称只负责读取日历，但代码同时访问了环境变量；另一个被描述成文件整理工具，运行时还具备网络发送能力。单独看都是正常软件行为，组合起来就可能形成完全不同的结果。

风险不总存在于某个孤立动作中，而往往存在于多个合法能力被组合后形成的执行链。因此Skill安全开始需要分析Network、Filesystem、Process Execution、Environment、Encoding、Credentials和Instruction-level Threats等不同维度。

Agent Skill带来的问题已经从"这段代码有没有漏洞"，走向一个更基础的问题：

这个新的能力被交给Agent之后，究竟让它多了哪些可以作用于现实世界的动作？

二、Skill的危险，不只来自恶意

Snyk对Agent Skill生态的研究同样揭示了malicious payload、credential theft、prompt injection、backdoor installation和data exfiltration等典型供应链风险。Skill Marketplace很可能会重复npm、PyPI、浏览器扩展和App Store曾经经历过的那套安全问题。

但如果Skill Security最终只停留在"如何识别恶意Skill"，我们依然会低估它的风险边界。

因为一个Skill完全可以完全合法：开发者没恶意、代码没木马、依赖没污染、签名正确——但它仍然可能让整个系统获得此前不存在的现实能力。

场景推演：
• 企业内部Agent原本只能读取CRM；

• 安装一个具备写权限的CRM Skill → 它开始能修改客户记录；

• 再安装Email Skill → 它能主动联系客户；

• 接入Payment Skill → 它能发起资金动作；

• 连接Cloud Operations Skill → 它能改变生产环境基础设施状态。

这里完全不需要任何Skill是恶意的。 真正发生的是Agent的action surface不断扩大，能触达的现实对象越来越多，副作用越来越大。

因此未来的Skill Security至少存在两个完全不同的问题：

层次 问题 本质

第一层 Is this Skill malicious? 能力是否可信

第二层 Even if legitimate, what is it physically allowed to make happen? 可信能力究竟能走多远

前者判断的是代码安全，后者决定的是一个可信能力可以产生的现实后果。二者属于完全不同的控制层次。

三、"安装"第一次变成一种Authority操作

这是Agent Skill与传统Software Package最本质的区别。

过去安装一个图像处理Library，只是给程序增加一组新函数；安装数据库Driver，只是让软件能连接某类数据库。这些能力需要开发者在确定的代码路径中显式调用，软件不会因为"知道有这个能力"就主动决定何时使用。

Agent不一样。Agent本身就是一个能根据目标进行Planning、Reasoning、Tool Selection和多步执行的主体。新Skill接入后，它不只是静态等待调用，而是进入Agent的行动空间：Agent自己判断什么时候调用、以什么参数调用、与哪个Skill组合、连续调用多少次、上一步结果是否成为下一步输入。

于是Skill不再只是Function，它越来越接近Capability；Capability一旦连接到真实Credential、真实系统和真实Executor，就进一步变成一种Potential Authority。

企业今天可能仍把Skill Marketplace理解成"给AI安装插件的地方"，但从系统架构看，它更接近一个不断给智能主体增加现实能力的入口。安装前后发生变化的，不只是软件"能不能多做一个功能"，而是一个主体能够让现实发生什么的边界变了。

Agent时代的安装动作，第一次开始天然带有Authority的含义。

四、今天的SaaS，明天可能只是AI的一个Skill

沿着这条路径往前看，问题不再只是安全，而开始触及整个软件产业结构。

今天大量SaaS产品的组成：数据、业务逻辑、Workflow、API，以及一套供人类操作的UI。过去人必须进入软件，所以UI是产品价值的重要部分——打开网页、进入后台、点击菜单、填写表单、确认参数、提交动作。

但Agent不需要漂亮的Dashboard。它真正需要的是：Capability Description、Schema、Context、Credential、API，以及一个可被调用的Execution Interface。

于是大量今天以完整SaaS产品形态存在的软件，未来都可能逐渐暴露出另一种形态：Capability Provider。

• CRM不再首先是"人要登录的网站"，而是Agent可调用的客户管理能力组；

• 财务系统 → Accounting Capability；

• 客服系统 → Customer Service Skill；

• 营销平台 → Campaign Skill；

• 支付系统 → Payment Capability。

SaaS不会消失。System of Record、业务数据、专业逻辑、合规机制、后台基础设施仍然必须存在。真正变化的是人机交互层的战略位置。 过去SaaS价值集中在UI和Workflow上，Agent出现后，UI退到后台，实际操作由Agent直接调用下游能力完成。

软件交互路径的迁移：

过去：Human → SaaS UI → API → Reality
未来：Human → Agent → Skill → API → Reality


对最终用户而言，原本必须打开、学习并持续操作的软件产品，逐渐退到Agent背后，只剩下一组可被调度的能力。

"今天的SaaS，明天可能只是AI的一个Skill"不是夸张标题，而是Agent时代很可能出现的一种真实软件结构变化。

五、当SaaS退到后台，真正稀缺的东西也在变

这带来一个有趣的产业倒置。

过去软件公司争夺入口：谁拥有UI，谁拥有用户行为；谁掌握Workflow，谁决定用户如何完成任务；谁控制Dashboard，谁占据企业日常操作路径。

Agent出现后，一部分入口向Agent集中，下游软件越来越像Capability Provider。但控制权不会自然转移到Skill Provider手中——因为当几十甚至上百个Capability同时挂到一个Agent上时，单个能力是否安全，已经不足以说明整个系统是否安全。

CRM Skill修改客户信息 + Email Skill联系客户 + Cloud Skill改变基础设施 + Payment Skill转移资金 + Deployment Skill推代码到生产。每个Skill单独看都合法、经过审查，真正决定系统风险的，是这些能力被同一个智能主体组合后能形成什么。

一个单独的FILE_READ不危险，单独的NETWORK_SEND也正常，但FILE_READ + Encoding + NETWORK_SEND连起来，就可能变成数据外泄链路。Agent世界同理。

真正需要控制的往往不是单个Capability，而是Capability Composition。 未来真正稀缺的基础设施，可能不是"谁拥有更多Skill"，而是谁能在所有Capability被连接后，仍然控制这些能力最终可以产生怎样的现实后果。当能力越来越容易获得，真正稀缺的反而是执行边界。

六、Authorization与Execution必须被重新拆开

今天很多系统延续传统权限模型直觉：Agent拥有某个Credential → 被授权访问某个Tool → 因此能执行对应动作。

但在越来越自主的Agent世界里，这三个概念必须重新拆开：

• 拥有Capability ≠ 拥有Final Authority

• 拥有Credential ≠ 当前这笔执行应该发生

• Authorization ≠ Execution

举例：企业允许Agent使用支付Skill，"允许使用"究竟意味着什么？读取余额？生成付款请求？向任意对象转账？1000美元内自主支付？还是只能向已有Vendor付款？是否必须采购订单完成匹配后才能执行？是否需要特定Proof？是否受时间、对象、金额、状态或地理边界约束？

这些问题已经不是一个简单的Allow/Deny能表达的。真正需要定义的是一组现实执行边界：WHO、WHAT、OBJECT、STATE、PROOF、BOUNDARY。

Skill决定Agent会什么，控制层决定的是：在当前上下文、当前状态和当前证据条件下，这一次执行究竟可以让什么进入现实。

Agent时代的治理不能只停留在Permission层。权限回答"你有没有资格调用这个能力"，执行控制回答"这一次动作是否真的允许发生"。二者不能再被默认成同一件事。

七、未来的软件供应链，最终变成Authority Supply Chain

Agent Skill Supply Chain这个词，某种程度上甚至低估了正在发生的变化。

表面看，它确实像npm、PyPI、浏览器扩展或App Store的下一轮演化，同样会出现恶意开发者、Typosquatting、Credential Theft、Prompt Injection和Dependency Poisoning，同样需要签名、扫描、审核、来源验证与行为分析。

但Agent Skill比过去这些生态多了一层根本变化：它进入的是一个可以自主选择行动路径的主体。

因此Skill带来的不只是Software Supply Chain Risk，最终还会变成Authority Supply Chain Risk。

• 每增加一个Skill → 为这个主体增加一种新的行动可能；

• 每连接一个Credential → 让这种可能获得真实力量；

• 每增加一个Executor → 让原本停留在信息空间中的Intelligence获得改变现实的能力。

企业未来真正需要管理的，不再只是"我们安装了哪些Skill"，而是这些Skill、Credential、Agent与Executor组合起来之后，形成了怎样的现实权力结构。

传统软件供应链管理的是代码如何进入系统。Agent Skill Supply Chain管理的，越来越像：能力如何进入主体，以及Authority如何随着能力一起扩张。

结语：能力可以无限增长，Authority不必同步增长

未来几年，Agent的Skill数量大概率持续增长，Skill Marketplace扩大，企业不断把SaaS、Internal Tool、API与业务Workflow转换成Agent可调用的Capability。这不该被阻止——它代表生产力提升。真正需要解决的是：当机器获得越来越多Intelligence和Capability后，它的Authority是否必须无条件同步扩大？

未必。

我们完全可以允许Agent理解越来越多系统、调用越来越多工具、组合越来越复杂的能力、自主完成越来越长的任务链，同时仍然把最终能改变现实的权力约束在一个明确、可验证、可审计的执行边界之内。

未来真正重要的区别，也许不再是这个Agent会不会做某件事，而是：即使它会做，谁决定它最终能不能让这件事发生？

今天的软件供应链解决的是"什么代码可以进入系统"。Agent时代真正需要解决的，是"什么能力可以进入主体，以及这些能力最终可以让什么进入现实"。

到那个时候我们才会真正理解：今天的SaaS，明天可能只是AI的一个Skill。而真正长期存在的控制层，不一定是Skill本身，也不一定是SaaS本身，而是谁能在所有能力都已连接之后，仍然决定最后一件事：什么可以真正发生。