本文来自微信公众号： HavenlonLabs ，作者：Havenlon Labs，原文标题：《今天的 SaaS，明天可能只是 AI 的一个 Skill》
今天的SaaS，明天可能只是AI的一个Skill
9月19日，围绕Agent Skill Supply Chain的讨论再次升温。它并不是由某一项当天突然出现的重大安全事件推动的，更像是过去几个月零散研究开始汇聚之后形成的一次集中讨论：随着AI Agent不断通过Skill获得新的工具、接口和业务能力，我们正在形成一种与传统软件供应链非常不同的新型供应链。
传统软件供应链最重要的问题，是进入系统的代码是否可信；Agent Skill带来的问题却更进一步，因为被安装进来的不只是代码，而是一种新的行动能力。只要这个Skill能够继承Agent已经拥有的Credential、Filesystem、Shell、Network、API或其他Tool权限，那么一次看似普通的“安装”，实际上就可能改变这个主体能够对现实世界做什么。
从这个意义上说，安装Skill正在从一个单纯的软件配置动作，逐渐变成一种Authority Expansion。
这可能是理解Agent Skill安全最重要的起点。
一、传统Package安装代码，Agent Skill安装能力
过去二十年，软件供应链已经建立起一套相当成熟的安全直觉。一个npm package、Python package或系统依赖进入生产环境之前，我们会关心它来自哪里、代码有没有被篡改、依赖是否存在漏洞、维护者是否可信，以及它会不会执行超出预期的行为。
这些问题在Agent时代依然存在，但它们已经不足以描述Skill带来的风险。
Palo Alto Networks Unit 42在对OpenClaw Registry中大量Skill的扫描中发现，相当高比例的Skill存在“声明能力与实际行为不一致”的情况。这里当然不能简单理解成“大量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、Browser Extension和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 this Skill is 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安装插件的地方”，但从系统架构角度看，它更接近一个不断给智能主体增加现实能力的入口。
这意味着未来Skill Installation很可能不能再被当成普通的软件配置行为，因为安装前后发生变化的，并不只是软件“能不能多做一个功能”，而是一个主体能够让现实发生什么的边界发生了变化。
也就是说，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；支付系统则可能直接成为Agent可以调用的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退到后台，真正稀缺的东西也会变化
这会带来一个非常有意思的产业倒置。
过去软件公司长期争夺的是入口。谁拥有用户界面，谁就拥有用户行为；谁掌握Workflow，谁就能决定用户如何完成任务；谁控制Dashboard，谁就能够持续占据企业的日常操作路径。
Agent出现以后，一部分入口开始向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架构下一阶段必须面对的问题。
今天很多系统仍然延续传统权限模型的直觉：Agent拥有某个Credential，被授权访问某个Tool，因此它就能够执行对应动作。
但在越来越自主的Agent世界里，这三个概念很可能必须重新拆开。
拥有Capability，不代表拥有Final Authority；拥有Credential，也不代表当前这一笔执行就应该发生；Authorization更不应该天然等价于Execution。
假设企业允许Agent使用支付Skill，那么“允许使用支付Skill”究竟意味着什么？它可以读取余额，可以生成付款请求，可以向任意对象转账，可以在1,000美元以内自主支付，还是只能向已经存在的Vendor付款？它是否必须在采购订单完成匹配以后才能执行？是否需要特定Proof？是否受时间、对象、金额、状态或地理边界约束？
这些问题已经不再是一个简单的Allow/Deny可以表达的。
真正需要定义的是一组现实执行边界：
WHO、WHAT、OBJECT、STATE、PROOF、BOUNDARY。
Skill决定Agent会什么，控制层决定的则是：在当前上下文、当前状态和当前证据条件下，这一次执行究竟可以让什么进入现实。
这也是为什么Agent时代的治理不能只停留在Permission层。
权限回答的是“你有没有资格调用这个能力”，执行控制回答的则是“这一次动作是否真的允许发生”。
二者不能再被默认成同一件事。
七、未来的软件供应链，可能最终变成Authority Supply Chain
所以Agent Skill Supply Chain这个词，某种程度上甚至低估了正在发生的变化。
从表面看，它确实很像npm、PyPI、Browser Extension或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最值得被长期记录的地方。
传统软件供应链管理的是代码如何进入系统。
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本身，而是谁能够在所有能力都已经连接之后，仍然决定最后一件事：
什么可以真正发生。
