原文作者：Pengyu，Co-founder of Particle Network

Intent-Centric（以意图为中心）是最近引发很多讨论的主题，热度之上也有很多质疑。

质疑主要集中在两个角度：

过于抽象与叙事导向，很难工程落地，不像是技术驱动的行业升级，更像是一种产品设计哲学。

可能只是 Account Abstraction（账户抽象）赛道换了一个新的说法。因为直观上大家会觉得 Intent-Centric（以意图为中心）与 Account Abstraction（账户抽象）有一定关系，貌似都是与降低用户门槛，提高用户体验有关。

这篇文章将会分析 Intent-Centric（以意图为中心）与 Account Abstraction （账户抽象）的伴生，演进与竞争关系。

Account Abstraction（账户抽象）的由来

整体而言，Web3 行业发展的趋势是从加密朋克友好的工程师行业转向大众友好的消费级行业。

对于以太坊的 Account Abstraction（账户抽象），社区在 2016 年和 2017 年之间便已经开始了讨论。早期的讨论和设计目标更多是从开发者角度考虑的，主要是简化合约的创建和交互，并为复杂的交易结构提供更多的自由度。此外，也希望通过账户抽象解决一些智能合约和 dApp 开发中的复杂性问题。这个阶段的账户抽象本质上是对账户模型的泛化。

在账户抽象的发展中，最核心的是 ERC-4337 的提出与成熟。随着讨论的深入，社区发现普通终端用户在应用层业务场景的的一些常见诉求是不可能从账户结构、链的原生结构得到直接满足的。例如恢复私钥，0gas 获得特定服务以及批量授权等。

作为对之前账户抽象探索的补充，ERC-4337 被 Vitalik 和 Ansgar Dietrichs 等提出，希望从账户结构本身升级的角度去提供一些场景功能。它引入了“用户操作”（User Operation）的概念，允许用户更加灵活地进行交易，而不需要担心Nonce或复杂的交易费用问题。

关于 Account Abstraction（账户抽象）领域的不同协议提出的时间表请见下图：

账户抽象行业的现状：核心价值与桎梏

Account Abstraction（账户抽象）行业已经接近成熟，便于理解，我们可以将现在的 Account Abstraction（账户抽象）行业按照靠近用户的顺序大致可以分为：

公链层

私钥管理层

AA Stack 层（主要包含 Paymaster 和 Bundler）

功能层

应用层

私钥管理层有多种成熟方案，像基于 AWS 的 KMS 服务的托管型方案的 Magic.link, 以及我们（Particle Network) 用的 MPC-TSS。AA Stack 层目前有超过百家的提供方，包括创业公司 StackUp，ZeroDev，Pimlico，基础设施 Alchemy 以及钱包头部公司 Safe 等都已经提供了可用的方案。在应用层上我们已经看到 CyberConnect 以及 dYdX 等头部项目已经在应用 Account Abstraction（账户抽象）到自己的特定业务场景。

账户抽象毫无疑问推动了终端用户体验，给 Web3 大规模应用扫平了更多的障碍，但是现阶段的实际效果与我们对账户抽象能带来行业体验的范式提升的预期是明显不匹配的。

因为 Account Abstraction（账户抽象）的本质在于从供给侧解决用户的 UX 问题，更像是面向开发者提供了更多的账户结构层面的开发选择。同时账户抽象与私钥管理层结合带来的社交登录+账户功能的扩展一定程度上降低了新用户进入 Web3 产品服务的门槛。

但是我们从账户抽象的普及加速度以及终端用户的 Aha 时刻的反馈来看，貌似并没有完全释放用户潜力。

当然一方面是因为应用层内容的数量和质量还在快速迭代，但另一方面我们认为是因为：

账户抽象优化了用户进入到表达的体验

但是没有解决表达到结果的问题

而表达到结果的优化就是 Intent-Centric 的核心价值。

为什么会有 Intent-Centric（以意图为中心）的提出，主要是两个原因：

加密行业的基石之一在于从链的底层设计上还用户自主权，包括资产自主，数据自主和信息自主等。但是自主权带来的问题就是完成一个目标背后的每一个细微的链上操作都需要暴露给用户做授权。

在行业早期，业务场景相对单一，执行逻辑相对简单，链与链涉及到的互操作性很少，这个时候需要用户的授权不会很多，用户需要做出主动判断的地方很少，体验是可以接受的。但是当更多的 L2 出现，更多的业务之间互相加盖，组合在一起，就会出现用户的需求是单一的，但是需要授权的频率是很高的，并且在过程中涉及到较多的主观判断，例如 Gas，滑点的设置等。

Intent-Centric（以意图为中心）推出的核心逻辑其实是在不损失用户自主权的基础上屏蔽过程，包括过程的监控和过程的管理，用户只需要明确自己的需求的起点及终点。而这带来的好处就是能够让用户从 Transaction（交易）视角转化为需求视角。

我们用一个简单的对话问题可以检验一下这个问题：

请问最常见的链上操作之一：我有 10 个 ETH，我希望在 Compound 上面按照 2% 的年化收益借贷出去。

请问这个表达真的是你的需求吗？

其实这个表达不是你的需求，你的需求是：我有 10 个 ETH，在一个安全的协议里面帮我找到最高的收益。

而“在 Compound 上面按照 2% 的年化收益借贷出去”是一个 Transaction（交易）。

那为什么你下意识的会认为这个 Transaction（交易）是你的需求，本质上是因为目前加密行业离散成了一个又一个的交易和状态，所有的需求都需要自己拆解成交易，并且监控状态才能得到实现，带来的问题就是我刚才提到的用户不是从需求视角出发，而是从交易视角出发，这显而易见的限制了很多用户需求的表达和实现，因为用户的心理其实有个思考方式上的桎梏。

因此 Intent-Centric（以意图为中心）解决的就是表达到结果的最优通路问题。

这个事情是有价值的，因为只有解决表达到结果的通路问题，才真正的释放了终端用户的广大需求。

那要达成这样的目标，Intent-Centric（以意图为中心）需要从哪些角度去推进产品和研究。

我们基于刚才的思路，把整个 Intent-Centric（以意图为中心）行业分成了四层：

用户表达的入口层

表达到意图的翻译层

垂直需求的整合层

复合需求的协调层

各自完成的计算目的是很清晰的：

用户表达的入口层是用来收集用户真实需求。核心指标：完成率；

表达到意图的翻译层是将用户真实需求翻译为机器与机器间，开发者与机器间以及开发者与开发者间可以统一沟通的语言，核心指标：响应时间和准确率；

垂直需求的整合层是整合垂直品类需求，并且撮合合适的求解者（Solvers）去响应这个需求。核心指标：匹配效率；

符合需求的协调层是拆解复合需求成为垂直品类需求，同时协调不同垂直品类的 Solvers（求解者）按照一个目标或者逻辑去响应这个复合需求。核心指标：拆解效率以及需求覆盖率。

当四个角度都有一定成熟度的时候，就能带来这样的用户路径：

用户在任何表达的入口层完成需求的表达，表达被翻译层翻译为一个机器间协调的通用语言描述的意图，意图被协调层做拆解，垂直需求的整合层的 Solvers（求解者）竞争以高效+安全的方式执行这些意图，最后垂类意图的执行结果再被协调层整合成一个复合意图的结果。

我们用一个实际例子来看一下：

一个 Coinbase 的股票持有者，看到 Base Chain 的发布，想要去体验下 Base Chain 上的一款游戏应用。他知道自己需要的是要 Mint 这个游戏的 NFT 开始进程。

我们跳过钱包注册流程（已经非常复杂），并且假设他在 Polygon 生态玩过其余 Web3 游戏，已经持有 Polygon 的 Matic 代币，他为了参与 Base Chain 的项目需要自己完成如下拆解：

找到一个三方跨链桥，将 Matic 代币跨链到以太坊的 ETH 代币

从 Base Chain 将 ETH 代币跨到 ETH-Base；

Mint NFT；

开始游戏。

这个是现在的过程，即使是配合账户抽象的 Batch Transaction（打包交易）或者 Gasless Transaction（无 Gas 交易），门槛依然很高。我们知道用户的意图（在 Base Chain 上 Mint 一个 NFT 以开始这个游戏）其实是清晰的，他知道自己要做啥，只是过程过于繁琐。

Intent-Centric 领域如果成熟，它可以完成用户意图的结构化、拆解、和执行。从终端用户体验上，用户交互的是适配了 Intent-Centric 协议的钱包或者应用或者在ChatGPT类似的 LLM UI 中表达自己的意图，开发者集成的 Intent-Centric 开发框架会自动结构化 Intent，然后 Intent Bidder 和 Solver 就会完成最终的拆解和执行，用户的感知只是点了个按钮或者发了一句话。

我们现在可以尝试回答这个问题：Intent-Centric 是 AA（账户抽象）的新瓶装旧酒还是进化的最优选择？

Intent-Centric 除了在用户路径上更往前一步-从进入到表达变成了从表达到结果-以外，还在哪些角度与账户抽象显著不同？

通过以上内容维度的对比，我们很清晰的可以回答：Intent-Centric（以意图为中心）不是 Account Abstraction （账户抽象）的新瓶装旧酒，而是用户路径体验优化的另一种选项。

但是 Account Abstraction（账户抽象）赛道是否会随着 Intent-Centric（以意图为中心）领域的更加成熟，变为 Intent-Centric（以意图为中心）领域实现特定操作的一个基础设施，我们需要更多这个领域的协议或产品更加成熟才能判断。

Particle Network在Intent-Centric领域的独特视角

首先回顾一下我们 V1 的核心产品：基于 MPC-TSS 和 Account Abstraction（账户抽象）的 Wallet-as-a-Service（钱包即服务），在 Account Abstraction（账户抽象）领域的价值位置可以用如图所示。

如图所示，可以很明确的知道我们的核心工作是基于 MPC-TSS 的 Key Management（私钥管理）层和提供社交登录套件的功能层。

其实本质上我们的 V1 只做了两件事情：

通过社交登录简化以及抽象用户进入 Web3 产品的行为和需求；

计算多链签名，在接入我们钱包即服务的各类型产品内直接完成签名，提高交易效率。

我们推出 Intent-Centric 相关产品的核心原因是两点：

Intent-Centric 的核心工作和我们 v1 产品的本质是完全统一的：抽象用户需求，提高交易效率。

我们在B2B2C这个方式下，在过去 10 个月内与合作伙伴共同引入了相当规模的用户，我们的关注点也顺势从用户进入更多的转向了用户表达和结果。

那我们对 Intent-Centric 领域的基础判断，以及我们在 Intent-Centric 的独特优势，和基于这个优势我们的产品策略是什么？

我们认为在我们上文提到的 Intent-Centric 领域的分层逻辑中，是有明确的价值优先级顺序的：

我们认为表达到意图的 Translation Layer（翻译层）是最核心的，因为这个是唯一一个有通过制定标准带动飞轮效应的层次，其次是复合需求的 Cordination 协调层，之后是垂直需求的整合层，再之后才是用户入口的表达层。

我们在 Intent-Centric 的独特优势是什么：

在抽象用户需求的积累以及在多链多行为签名计算的积累；

覆盖基本所有赛道的已经完成产品接入的合作伙伴；

所以我们 V2 在 Intent-Centric 领域的产品叫做 Intent Fusion Protocol，本质上包含：

一个表达到意图的翻译层的统一语言和框架（服务于我们觉得最重要的翻译层）

复合需求的协调层的开发套件

以及 Particle Network 自己用来做全链账号抽象管理和计算的 zkEVM

我们期待通过 V2 的 Intent Fusion Protocol 能够让用户在 zkWaaS 产品赋能的任意应用层产品通过隐私登录（在享受社交登录的便利性的同时，不暴露任何 Web2 的身份隐私），能够一键让自己持有的 ETH 参与到任意 L1/L2 上最佳的链上收益产品，并且在收益达到特定金额的时候进行自动赎回，再质押到 Lido 获取无风险收益。

Particle Network V2 的 Intent Fusion Protocol 将会更加从用户的需求和预期出发，而不是提供一堆复杂的功能和设置，以最小的理解成本和操作成本直接完成用户的真正意图。

我们觉得这个方式能够靠拢我们的目标：

通过打造一个以意图为中心，模块化的 Web3 访问层，加速 Web3 从工程师友好的金融行业转向大众友好的消费级行业。