AI Agent 与区块链交互的四层架构

问十个人“AI+区块链”是什么意思，你会得到十个关于代币的答案。但这并非工程所在。真正的交叉点要具体得多，也有用得多：它是一个自主代理实际接触链上系统以读取、获得许可、支付和结算的点集。

如果你在构建，代币叙事只是噪音。你需要的是堆栈地图：哪一层负责什么，哪个标准在哪一层，哪一部分可以智能，哪一部分必须笨拙且确定。搞错了，你就会发布一个能被诱导清空钱包的代理。做对了，你发布的东西就能经得起真实资金的考验。

这就是那张地图。四层，从上到下：读取与推理、授权、支付、结算。我们将逐一介绍每一层，包括拥有它的协议和一个简短的代码草图，然后看看各层之间实际出问题的接缝处。

AI“接触链”到底意味着什么？

意味着代理通过四个不同的点与链上系统交互：它读取链状态并在此基础上推理，它获得一个范围受限的授权来执行操作，它用稳定币支付资源费用，它触发一笔最终在链上结算的交易。代币价格的故事是营销。真正的AI和区块链堆栈就是这一组接触点，每个点由各自的标准管理，工程在于安全地将它们连接在一起。

剥离投机，画面就清晰了。代理是一个有目标的软件。要在链上做任何事情，它必须依次完成四件事。

它必须感知，即读取余额、价格和合约状态。它必须被许可，即持有授权说明它可以做什么。它必须支付，因为大多数有用的服务和操作都需要成本。它必须执行，即产生一个链会接受并最终确定的交易。

每一层对应一个方面。每一层都有一个行业正在趋同的标准。作为构建者，你的工作是将它们连接起来，同时不让顶层的自由度渗入底层的最终确定性。

组织整个堆栈的一个原则是什么？

顶层是概率性的，底层是确定性的。推理层可以发挥创造力，因为模型是在猜测中制定计划。越接近资金，模型的主控权就越少。授权、支付和结算必须受规则约束且可验证，而非推断。模型提出方案；确定性代码负责执行。每一个安全的代理架构都强制底层不会简单地信任顶层。

这一个想法就能让你免于大多数代理灾难。

语言模型是一个概率引擎。它在将目标转化为计划方面表现出色，但在决定是否转移资金方面则非常糟糕。因此设计规则是：让它在上层自由推理，然后通过下层的确定性门控强制执行每一个关键操作。

模型可以决定它想买某样东西。但它不能决定支付是否在限额内、收款方是否被允许、或签名是否有效。这些是检查，而非判断，而检查属于每次都做相同事情的代码。

在逐层讲解时请牢记这个原则。这就是为什么每个下层都有一个硬性的、可验证的合约，而不是一种感觉。

第一层：AI如何读取并推理链上状态？

顶层是模型加上它与世界的连接。模型处理推理和规划。模型上下文协议（Model Context Protocol，MCP）赋予它调用工具和读取数据的标准方式，包括链上状态，如余额、价格和合约读取。代理间协议让它能与其他代理协调。这一层是智能所在，也是任何不可逆操作都不应自行发生的地方。

实践中，这一层是一个连接工具的代理循环。模型感知、规划、调用工具、查看结果并决定下一步。

这里重要的连接标准是 MCP，它给代理一个统一的方式来访问外部工具和数据，而不是为每个服务做定制集成。对于区块链，这意味着一个 MCP 工具，它读取链上状态并以清晰的形式返回给模型。

以下是代理可以调用的读取工具的样子：

// 代理可以调用的MCP工具，用于读取链上状态。设计为只读。
server.tool(
  "get_onchain_balance",
  { address: z.string(), token: z.string() },
  async ({ address, token }) => {
    const balance = await publicClient.readContract({
      address: token,
      abi: erc20Abi,
      functionName: "balanceOf",
      args: [address],
    });
    return { content: [{ type: "text", text: `Balance: ${balance}` }] };
  }
);

注意“只读”这个词。这一层的工具负责获取和报告。一旦一个工具可以移动价值，它就不再属于这里，而必须放在授权层之后。将读取和写入分开在这条线的两侧，是区分玩具和系统的第一件事。

这一层有一个跨领域警告：它读取的数据必须是可信的。如果你的代理基于被操纵的价格馈送进行推理，下面每一层干净的代码都会忠实地执行一个糟糕的决策。预言机和馈送完整性是这一层威胁模型的一部分，而不是一个单独的问题。

第二层：代理如何被授权操作？

授权是思维与行动之间的确定性门控。在代理行动之前，它必须出示一份签名的授权令，明确说明它被允许做什么：哪些操作、哪些资产、什么限额、有效期限。像代理支付协议这样的标准将操作与这些加密签名的授权绑定。你的代码验证授权令并对照它检查提议的操作。如果操作超出授权范围，则被拒绝。这是使整个堆栈安全的关键控制点。

这是最重要的一层，也是团队们经常跳过的。

授权令是委托人提前授予的签名许可。它编码了范围和限制，并在运行时根据代理实际尝试执行的操作进行检查。模型永远不能覆盖它。

一个最小的门控看起来像这样。它故意显得乏味，因为乏味正是你想要的介于代理和资金之间的东西。

function authorize(signedMandate, action) {
  const m = verifySignature(signedMandate);        // 伪造或篡改的授权将被拒绝
  if (Date.now() > Date.parse(m.expiresAt)) throw new Error("授权已过期");
  if (!m.allowedActions.includes(action.type)) throw new Error("操作不被允许");
  if (action.amountUsd > m.maxPerActionUsd) throw new Error("超过每次操作限额");
  if (!m.allowedPayees.has(action.payTo)) throw new Error("收款方不在白名单中");
  return true; // 只有到这时操作才能进入支付和结算阶段
}

这个门控之下的一切信任该操作已被授权。门控之上的一切只是一个提议。这种分离是一个可防御代理的主干。

第三层：代理如何实际支付？

一旦被授权，代理就进行支付。主要模式是 x402，它使用 HTTP 402 状态码在普通 web 请求内结算稳定币支付。代理请求一个付费资源，收到带有条款的 402 响应，签署一笔稳定币转账，然后重试。它无需账户，几秒内结算，成本不到一美分，这是唯一适用于软件为许多微小服务付费的模式。

这一层是代理遇到价格的地方。它故意设计得很薄。

在代码中它几乎不可见，因为支付客户端包装了你的普通 HTTP 调用并自动处理支付-重试循环：

import { wrapFetchWithPayment } from "@x402/fetch";
const fetchWithPay = wrapFetchWithPayment(fetch, agentAccount);
// 现在，在第二层批准后，402 会被自动支付并重试
const data = await (await fetchWithPay(url)).json();

要记住的是顺序。支付在授权之后，而不是替代授权。支付客户端应该只接收已经被门控清除的操作。反过来连接的话，你就构建了一个先付钱再请求许可的代理。

第四层：链如何执行并结算？

结算是交易最终确定的地方，而账户抽象使其对代理安全。在 ERC-4337 下，代理使用智能合约钱包而非原始密钥。账户本身在执行前强制规则：支出限额、允许的操作、以及通过 ERC-7715 等标准授予的限时会话密钥。泄露的会话密钥造成的损失是有限的，而非全盘皆输。智能账户是链最终确定前的最后一个确定性检查点。

这是堆栈底部发挥作用的地方。

原始密钥（外部拥有账户）拥有无限权限。如果代理持有它并泄露，资金就没了。智能账户则翻转了这一点。钱包是一个合约，它在执行前根据自身规则验证每个操作，因此控制不仅存在于你的应用代码中，也存在于链上。

对于代理来说，关键特性是会话密钥：委托人授予代理的一个范围受限、有时间限制的许可。代理只能在这个范围内签名，不能做其他事。较新的许可标准使其成为一个清晰的请求-授予流程，而来自 Pimlico、ZeroDev 和 Safe 等团队的生产级 SDK 现在已提供此功能。

概念上，授权看起来像这样：

// 委托人授予代理一个受限的会话密钥，在链上赎回
const sessionKey = await smartAccount.grantPermissions({
  signer: agentSigner,
  permissions: [
    { type: "erc20-spend", token: USDC, maxAmount: parseUnits("100", 6) },
    { type: "contract-call", target: ALLOWED_VENUE },
  ],
  expiry: nowPlusHours(24),
});
// 代理使用此密钥签署用户操作。智能账户强制执行限制。

由于限制由账户本身强制执行，这是堆栈中最强的检查点。即使上面每一层都被攻破，智能账户仍会拒绝任何超出授权的操作。这就是确定性底层在履行其职责。

各层之间的安全接缝在哪里？

危险从来不是单独的某一层。而是接缝。提示注入攻击推理层以产生恶意计划。过于宽泛的授权令让授权层放过太多东西。被操纵的价格馈送毒害了顶层推理的数据。泄露的密钥或超出范围的会话密钥破坏了结算。防御方法是假设每一层都可能出错，并让下一层验证而非信任。此堆栈中的安全性是边界纪律。

将威胁映射到各层，工作就显而易见了。

在推理层，不受信任的输入是敌人。如果代理读取了攻击者控制的内容同时拥有权限，一条精心设计的指令就能引导其计划。让不受信任的输入远离决策时刻，绝不让模型的输出绕过下面的门控。

在数据边缘，预言机和馈送完整性决定了代理是否在基于现实推理。一个干净的堆栈执行被投毒的输入仍然会导致损失。

在授权层，故障模式是过于慷慨。过于宽泛、有效期过长或过于模糊的授权令等同于没有授权。范围收紧、快速过期、收款方列入白名单。

在结算层，范围同样是一切。会话密钥应持有最小的资金余额和最窄的权限，只要能让任务运行，并且应该轮换。密钥应放入保管库，绝不放在仓库中，因为泄露的配置秘密仍然是代理资金消失的最常见原因之一。

四层的模式都是一样的。不要信任上一层。要验证。

你应该如何基于这张地图实际构建？

自上而下构建智能，自下而上构建信任。让模型通过MCP推理和连接，但让每一个关键操作都经过签名的授权令、通过序列化的支付步骤支付、并通过一个在链上强制执行限制的智能账户结算。保持读取和写入分离，严格限定每个授权的范围，记录每一个操作及其授权依据，并在阈值之上引入人工决策。地图的强度取决于各层之间的门控。

发布前的一个简短检查清单：

• 你的读取工具是否严格只读，任何移动价值的操作都位于授权门控之后？
• 每个关键操作是否需要一份在运行时验证（而非假定）的签名授权令？
• 支付是否在授权之后顺序执行，使得支付客户端只看到已批准的操作？
• 代理是否通过一个强制执行支出限额、使用短生命周期且范围狭窄的会话密钥的智能账户进行结算？
• 你是否将价格和数据馈送视为攻击面的一部分？
• 每一个操作是否都根据其依赖的确切授权进行记录，以便你能追溯发生了什么？
• 任何超过设定值的操作是否会升级到人工处理而不是自动执行？

如果以上所有问题的答案都是“是”，那么你就按照应有的方式构建了堆栈：在可以灵活的地方保持智能，在不能灵活的地方保持确定。

交叉点是架构，而非叙事

思考AI与区块链的有用方式不是将其作为一个可交易的主题。而是作为一个可构建的堆栈。代理在顶层推理，在底层获得许可、支付和结算，每一步都有标准和任务。

在此胜出的团队不是那些拥有最佳代币故事的团队。而是那些懂得智能属于堆栈顶部、权威属于堆栈底部，并在两者之间构建验证门控以防止它们相互混淆的团队。

这就是AI真正接触链的地方。诚实绘制地图，尊重概率性与确定性之间的界限，你就能构建出执行真正链上工作而不成为下一个警示故事的代理。

设计这些层之间的门控——授权、控制和结算账户——是决定链上代理是资产还是负债的验证工作。这就是我们做的事。

• 原文链接： medium.com/@ancilartech/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～