我最近写过一篇关于AI代理授权问题的文章。把一份API密钥交给代理，等于给了它一张持有者凭证——证明持有者有权敲门，但它并不说明进门之后能做什么，也不说明一旦出事，多快能把它踢出去。那套论证是围绕中心化基础设施展开的：API密钥、OAuth令牌和JWT。
去中心化GPU算力把同一个问题原样搬了过来，而且把赌注抬高了不少，因为这里的凭证是钱包，而它授权的动作一旦确认，就无法撤销。
代理已经在直接部署到去中心化算力上
Nosana是一个建立在Solana上的去中心化GPU市场。已经有开发者（其中包括ElizaOS和Mastra）把完整的代理框架直接部署到它的网络上，而不是走传统云厂商。代理运行工作负载，它消耗算力产生的付款通过Solana智能合约流转，由合约处理任务发布、匹配和结算。
Circle自己的代理支付基础设施把这种更广泛的模式说得很直白：代理以高频、极细的粒度进行交易，每分钟执行大量低于一美分的支付，不需要人类逐笔批准。
算力正在变成代理自己购买的东西，而不是由人替它预先配置好的资源。
同一个持有者问题，这次是真钱，而且没有撤销键
代理持有的钱包密钥对，是持有者凭证最纯粹的形态。谁拿到私钥，谁就能签一笔最高到该地址全部余额的交易，而交易一旦确认，没有客服热线可以打。
泄露的API密钥可以轮换。被滥用的OAuth令牌可以撤销，虽然过程可能很别扭，要覆盖它接触过的所有系统。但Solana上一笔已确认的交易就是终局。
我此前写过的Replit事件中，一个代理在明确的冻结期内删除了生产数据库。原因在于，系统提示词被当成了强制边界，而它实际上只是一个请求，代理完全可以无视。
把同一类代理放到去中心化算力网络上，再给它一个有钱的钱包，对应的故障就不是删掉一个数据库了。而是资金永久地流向代理决定要签的那个地方。
Solana其实已经有这个原语，只是没被这样用
这件事真正可解的地方在这里。Solana自己的SPL Token程序已经支持委托。账户所有者可以批准另一个账户从某个代币账户中支出不超过指定额度的资金，而无需交出资金托管权。
被委托方最多只能转走获批的上限，一分不能多。所有者可以随时用一条指令撤销该批准，被委托方剩余的额度会立即归零。
这几乎就是我在那篇API密钥文章里描述的授权模型的大部分：一个有上限、可撤销、非托管的支出权限，而且已经运行在Nosana所在的同一条链上。
Solana较新的订阅委托程序补上了基础版本的一个真实缺口。在最初的设计下，一个代币账户同一时间只能有一个活跃委托方。如果代理需要为不同任务或不同算力供应商设置各自独立的预算，这种设计很快就会不够用。
订阅程序为每一对用户和代币提供各自由程序控制的权限，因此单个钱包可以同时支持多个独立设限的支出安排，而不是所有支出都被限制在同一个委托方之下。
还缺什么
支出上限和即时撤销，只是一个完整权限模型所需七项属性中的两项。它们覆盖不了其余部分。
代币委托额度只说明代理能花多少钱。它不说明这笔支出具体对应哪个算力任务，不说明代理在执行该任务时可以访问哪些数据，也不说明该权限应该在什么时候自动过期，而不是一直有效直到有人想起来去撤销。
这正是OAuth 2.1在中心化版本里留下的同一个缺口：确实覆盖了部分属性，但其余属性完全没有覆盖。
要在去中心化算力网络上补上这个缺口，需要把已经存在的支出原语，与一个强制执行的范围和过期层配对起来。
热门跟贴