加密AI智能体需要一种新型算力:Acurast为何至关重要

AI智能体正在超越对话。加密AI智能体可以持有钱包、调用智能合约、为服务付费并在链上执行任务,而无需人工批准每一个步骤。
借助x402等基础设施,智能体可以用稳定币为API付费。智能体钱包则让它们能够在所有者设定的额度内进行支出。
但自主性也带来了新的安全隐患。
聊天机器人泄露对话记录是一个隐私问题。而自主的加密智能体一旦泄露其凭证,或运行了被人暗中修改的代码,就可能演变成一起在链上造成真实后果的安全事件。
然而,许多智能体仍然运行在笔记本电脑、传统VPS实例或中心化云基础设施上。这些环境也许很方便,却引出了几个重要问题:谁能访问智能体的运行时?任何人如何验证正在运行的是什么代码?如果某个提供商宕机或决定将其关停,又会发生什么?
加密智能体需要的不只是算力。它们需要机密执行、可验证的基础设施,以及一种无需依赖单一提供商即可获取算力的方式。
Acurast提供了一种不同的方案:一个建立在智能手机硬件安全之上的分布式算力网络。
核心问题
加密智能体拥有钱包
它们该信任谁来运行自己?
加密原生算力的五项要求
自主智能体需要其运行时具备五项核心特性。
机密执行
凭证、API密钥和私密上下文必须受到保护,防止未经授权的访问。
可验证的执行
用户和交易对手需要证据,证明底层硬件和所部署的代码符合预期的安全要求。
持续可用
链上事件、定时任务和协议操作不会等笔记本电脑重新打开。
分布式基础设施
主要依赖单一提供商,会形成潜在的故障点和控制点。
加密原生的访问方式
智能体应当能够以编程方式请求算力并为其付费,使用的是钱包而非传统账户。
这些要求并非加密领域独有。但当软件能够控制钱包或触发链上操作时,一旦出错,后果就会严重得多。
为什么传统云基础设施存在缺口
中心化云平台提供熟悉的工具、可靠的基础设施和简单直接的部署。问题不在于它们本身不安全,而在于它们的信任模型未必符合自主的、具备钱包能力的软件的需求。
- 提供商仍然处于信任边界之内。如果没有额外的硬件级保护,拥有特权的基础设施运营方可能能够查看工作负载的内存、存储或配置。对智能体来说,这些位置可能包含敏感的上下文和凭证。
- 验证运行时可能很困难。当智能体运行在他人的基础设施上时,用户需要一种方式来确认它运行在什么环境中,以及所部署的工作负载是否与预期一致。仅凭一份部署说明,并不能独立证明执行情况。
- 基础设施可能成为单点故障。某个提供商的一次宕机、账户封禁或政策变更,都可能中断所有依赖它的智能体。
- 传统的资源开通流程默认由人来操作。云账户、计费安排和访问凭证都是围绕个人或组织设计的。一个已经拥有钱包的自主智能体,需要一种更加程序化的方式来请求算力。
整个行业正在朝着为智能体提供专用计算环境的方向发展。Meta的Muse和OpenAI的Dots就体现了这一趋势。
但对于加密原生智能体来说,问题不只是给每个智能体配一台属于自己的电脑。
智能体的运行时能否做到机密、可独立验证,并且无需让某一家基础设施提供商掌控就能访问?
Acurast:建立在智能手机硬件之上的算力
Acurast将智能手机变成一个分布式算力网络。它不依赖中心化数据中心,而是协调一个分布在全球各地的手机网络(即Processor)。
它的方案以不同方式满足了上述五项要求。
1. 硬件级机密性
Acurast在硬件支持的可信执行环境(TEEs)中运行部署。
TEE提供一个隔离的执行环境,旨在保护敏感数据和计算过程不受周围系统的影响。与仅依赖普通的软件权限相比,这形成了一道更强的机密性边界。
部署环境变量可以在运行时向工作负载提供密钥等机密信息,使其保留在预期的执行边界之内。
对加密智能体来说,这一点与API凭证、私密上下文和其他敏感配置尤其相关。目标是减少用户需要对手机持有人或基础设施运营方给予的信任。
与任何安全架构一样,实际的保护效果取决于硬件、具体实现和部署配置。
2. 硬件证明
机密性解决的是谁能访问工作负载的问题。证明(attestation)则有助于确认运行它的是什么样的硬件。
在分发工作负载之前,Acurast会使用硬件证明来验证符合条件的手机。这有助于将受支持的真实硬件与未通过网络检查的手机区分开来。
结合部署流程,证明为验证基础设施和执行前提提供了依据,而不必仅仅依赖运营方的承诺。
对于自主智能体来说,这一区别很重要:安全性声明应尽可能有可验证的证据支持。
3. 分布式基础设施
Acurast在由不同所有者运营的手机网络中协调各个Processor。
这让算力分布到单一传统基础设施提供商之外。它可以减少对某一家公司的机器和运营决策的依赖,不过任何具体部署的韧性仍取决于其配置以及网络的可用容量。
对于监控协议或执行周期性基础设施任务的智能体来说,减少对单一主机的依赖是一项有意义的架构优势。
4. 沿用现有工作负载,无需彻底重写
借助Cargo,开发者可以部署多种Linux工作负载,包括Python、Go、Rust、C++、Shell脚本和二进制程序。
开发者可以使用熟悉的工具,通过SSH查看日志,并改造现有的智能体框架,而不必围绕某个专有运行时重建整个应用。
Cargo支持在Android Processor Core手机上运行Linux工作负载,而iOS Processor则继续支持JavaScript工作负载。
因此,Acurast不仅适合正在构建新智能体的开发者,也适合希望把现有工作负载迁移到另一种算力架构上的团队。
5. 通过钱包获取算力
借助Acurast Deploy Agent,智能体可以通过HTTP接口请求算力,并使用x402在Base上以USDC付费。
根据请求的不同,它可以获得一个任务部署,或请求一台VPS。VPS请求可以返回一个运行在Processor上、可公开访问并支持SSH的Ubuntu环境。
VPS请求无需传统的Acurast账户、本地CLI或ACU代币。
这为智能体系统提供了一个实用的构建模块:软件可以请求所需的基础设施、执行任务,然后让部署到期结束,一切都受所配置的时长和支出限额约束。
由此形成的算力模式,能够自然地融入具备钱包能力的软件。
在Acurast上运行加密AI智能体的三种方式
网络的这些能力可以转化为三种实用的部署模式。
1. 在Processor上运行整个智能体
对于需要持续执行并访问敏感配置的工作负载,整个智能体可以在Acurast Processor的TEE内运行。
在Acurast示例应用代码库中,已有两个提供Cargo应用的示例:
Hermes:一个具备任务调度、记忆和工具调用能力的自主智能体。
OpenClaw:一个能够处理定时任务和多步骤任务的个人助理。
开发者可以在.env中配置环境,在acurast.json中指定部署时长,然后使用acurast deploy进行部署。生成的智能体URL会被发送到所配置的回调端点。
对于拥有自己智能体的团队,Cargo模板为将现有框架引入该环境提供了一个起点。
最适合:定时运行的智能体、协议监控、周期性维护,以及能从硬件级机密性中受益的工作负载。
2. 让智能体的推理保持私密
如果智能体把每一条提示词都发送给第三方模型API,那么即使保护好了运行时凭证,仍然可能暴露敏感的上下文。
根据工作负载的不同,Acurast提供两种在TEE内运行推理的方式。
直接在Processor上运行模型。Acurast LLM模块支持Hugging Face上的众多GGUF模型,适合分类、信息提取和摘要等轻量级推理任务。
运行AI网关。在一项有Pocket Network和NodeGhost参与的早期实验中,一个兼容OpenAI的网关以Cargo构建的形式运行,在一小时内交替处理推理请求和网页搜索请求,没有丢失任何请求。
这项网关实验属于探索性质,并不代表一定能达到生产规模的性能。尽管如此,它展示了在基于智能手机的算力上运行更完整推理工作流的潜力。
最适合:处理机密文档、内部研究、私密运营数据的智能体,或团队不希望例行发送给第三方推理服务商的提示词。
3. 让智能体自行开通算力
智能体不一定需要一台常驻服务器,也不一定需要有人来管理每一次部署。
借助Deploy Agent,智能体可以发出一个HTTP请求,其中包含在Base上以USDC进行的x402支付,以及一份任务规范或VPS请求。
例如,智能体可以请求一个算力环境来执行定时的基础设施任务,通过SSH连接到返回的Ubuntu机器,完成任务后让部署到期结束。
这一工作流无需传统的Acurast账户或本地CLI。
再配合智能体钱包和明确的支出限额,这就为以编程方式开通算力奠定了实用的基础。
最适合:临时工作负载、自动化维护、针对特定任务的环境,以及需要按需获取算力的智能体。
加密智能体的五个用例
最能发挥价值的应用,是那些持续运行、机密执行和可验证的基础设施能够带来实际价值的场景。
治理监控
功能:跟踪DAO提案,总结变更内容,并在投票截止前提醒成员。
为何选择Acurast:支持持续监控,并提供硬件级的执行保护。
金库监控
功能:监控多签钱包余额和待处理交易,并标记异常活动。
为何选择Acurast:有助于将敏感配置和告警逻辑保护在预期的执行边界之内。
协议自动化智能体
功能:运行定时维护任务和其他预先定义的协议操作。
为何选择Acurast:提供分布式算力,并支持有边界的、程序化的部署工作流。
数据馈送智能体
功能:获取链下数据,对其进行验证,并将结果交付给合约或应用。
为何选择Acurast:硬件证明有助于确认执行环境的完整性,但它本身并不能确保源数据是正确的。
研究智能体
功能:阅读文档、论坛和链上数据,然后生成结构化的简报。
为何选择Acurast:本地推理选项可以减少敏感研究上下文暴露给外部模型提供商的情况。
这些是基础设施层面的用例,并不意味着智能体的决策或输出总是正确的。应用逻辑、数据来源、权限和运营保障措施依然重要。
更重要的是,智能体可以被设计成更少地依赖对单一运营方的信任。开发者可以将硬件级保护、证明、分布式基础设施和明确的访问控制结合起来。
这正是自始至终塑造加密基础设施的那些原则的自然延伸。
加密基础设施的下一层
加密领域花了多年时间构建减少对中介依赖的系统。自主智能体带来了新的挑战:能够独立行动的软件,同样需要一个无需盲目信任运营方就能运行的基础设施。
Acurast将基于智能手机的算力、硬件级的机密执行、证明以及基于钱包的资源开通结合在一起,构成一个为应对这一挑战而设计的架构。
它为开发者提供了一种探索不同智能体运行模式的途径:运行时可以更加机密,基础设施可以更加分布,获取算力的方式也能更好地适配自主软件。
如果智能体要在链上行动,那么运行它们的基础设施,也应当得到与它们所交互的钱包和协议同等的重视。
如何开始
探索Acurast最快的方式,是先部署一个现成的智能体,再构建您自己的。
选择一个示例。浏览Acurast示例应用,从Hermes或OpenClaw开始。
按照部署教程操作。按照Hermes教程中的说明,配置环境和部署时长,然后部署应用。
构建您自己的工作负载。使用Acurast Quickstart和CLI文档来改造您现有的智能体。
探索自主开通算力。如果您的智能体需要以编程方式请求算力并为其付费,请阅读Deploy Agent文档。
无论您选择哪种基础设施,部署加密智能体时都应遵循三条基本规则:
- 使用专用的钱包或账户。只授予智能体所需的权限,并设定明确的支出限额。
- 不要让机密信息出现在提示词和日志中。通过相应的部署配置提供凭证,避免在智能体对话中暴露它们。
- 为部署到期做好规划。设置合适的时长,并将关键状态保存在持久化存储中,因为临时部署可能会停止,其本地数据也可能在到期时被删除。
无论智能体运行在哪里,这些保障措施都很重要。更好的算力基础设施是对稳健的钱包设计和严谨的应用层安全的补充,而不是替代。
正在基于Acurast进行构建?如果您正在手机上运行智能体、智能体后端或推理服务,Acurast Discord就是构建者们交流经验的地方。加入Discord。


