凌晨两点，一个链上借贷协议监测到ETH价格在十分钟内下跌了8%。它的清算机器人立即启动——但问题来了：该优先清算哪个地址？哪些地址只是暂时亏损、很快就能恢复，哪些地址已经资不抵债、再晚一步就变成坏账？传统合约只能按预定的抵押率阈值机械化执行，但一个有AI辅助的合约可以调用风险模型，分析每个地址的链上行为历史，做出更精细的清算决策。这就是"合约+AI"要解决的问题。

摘要

智能合约自诞生以来一直受限于一个根本性的约束：它只能执行确定性的逻辑。如果输入相同，输出必然相同——这是区块链共识的基础，但也意味着合约无法处理模糊判断、模式识别或概率推理。而AI模型恰恰擅长这些事。如何让确定性的智能合约调用不确定性但强大的AI能力？这个问题催生了一整套技术栈：预言机（Oracle）作为可信数据桥梁，链外推理引擎在链下运行AI模型并通过零知识证明或TEE验证结果，智能合约则作为最终的执行层接收AI的输出并触发链上操作。本文从技术架构层面拆解这一"合约+AI"的融合路径，介绍Chainlink Functions、zkML等代表性方案的工作原理，分析它们在动态NFT、链上信用评分、自动参数优化等场景中的应用，并讨论当前的技术局限——延迟、成本、隐私与可验证性之间的权衡。这不是一篇面向投资者的概念科普，而是一份面向开发者和技术爱好者的系统技术解析。

一、引言：确定性合约的「盲区」

如果你用过智能合约，你一定熟悉它的核心承诺：确定性。给定相同的输入和状态，在任何节点、任何时间执行，结果都完全一致。这个特性是区块链共识的基石——如果不同节点执行同一笔交易得到不同结果，网络就无法达成一致。

但确定性也是一把双刃剑。它意味着智能合约无法"看"——无法识别一张图片里是不是猫，无法判断一段文本的情感倾向，无法对市场走势做出概率性的预测。它只能机械地执行预设的 if-then-else 分支。

换句话说，智能合约没有"理解"能力，只有"执行"能力。

而AI模型的核心价值恰好相反。大语言模型可以理解自然语言，计算机视觉模型可以识别图像，强化学习模型可以在复杂环境下做出决策。它们处理的是模糊、不确定、需要判断力的任务。

问题来了：如果链上协议需要AI的判断力呢？

设想一个场景：一个NFT拍卖合约，拍卖品是一幅AI生成的数字艺术品，起拍价由AI根据作品的视觉复杂度和市场趋势动态设定。合约需要AI的估值判断作为定价依据。

或者：一个链上信用评分协议，需要根据用户的链上行为数据——交互频率、资产多样性、清算历史——计算一个信用分数。合约需要一个机器学习模型来处理这些多维数据。

再或者：一个自动化做市协议，想要根据链上的流动性格局实时调整交易费率。合约需要AI的实时分析结果。

这些场景的共同点是：智能合约（执行层）需要AI（决策层）的输出作为输入。但问题在于，合约无法直接在链上运行AI模型——大模型的推理计算量太大，Gas成本不可承受，且多数AI框架的运算结果在GPU上并非完全确定性的。

那么，如何让合约"调用"AI？答案是一套分层架构：链外推理 + 链上验证 + 预言机桥接。

下面，我们将从最基础的技术组件——预言机——开始，逐层拆解这套架构。

二、预言机：AI进入区块链的「第一公里」

2.1 预言机的基本作用

预言机（Oracle）是链上合约与链下世界之间的数据桥梁。一个标准的预言机工作流程如下：

1. 智能合约发起一个数据请求（附带查询参数）
2. 预言机节点监听到链上事件，从指定的链下数据源获取信息
3. 预言机将获取的数据签名后提交回链上合约
4. 合约通过预言机的回调机制接收数据并继续执行

在AI调用的场景中，预言机的作用从"传递数据"升级为**"传递AI推理结果"**。

2.2 From 数据传递到推理传递

传统预言机传输的是静态数据——ETH/USD价格、天气温度、体育比分。这些数据是"已经存在的事实"，预言机只是搬运工。

AI场景下，预言机传输的是推理输出——输入模型的数据可能来自链上（用户的链上行为特征），也可能来自链下（市场情绪数据、图像内容）。预言机不仅需要获取这些输入，还需要将输入发送给AI模型，等待推理完成，再将结果返回链上。

这个过程中，关键的信任问题是：合约如何信任预言机返回的推理结果是正确的？

这个问题引出了分层解决方案：

• 基础层：由多个预言机节点独立执行相同的AI推理任务，通过共识机制（多节点多数决）来防止单个节点的作弊或出错。这是Chainlink等经典预言机的去中心化方案。
• 增强层：引入可验证计算——预言机节点在执行AI推理时，同时生成一个零知识证明，证明推理过程是按指定模型和输入正确执行的。合约可以验证这个证明，而无需重复执行整个推理过程。这就是zkML的核心理念。
• 最高层：使用可信执行环境（TEE），在硬件层面保证推理代码和数据在链下执行期间不被篡改。Intel SGX和AMD SEV是两种主流TEE方案。

下图展示了这一分层架构：

flowchart LR
    subgraph "链上（智能合约层）"
        A["智能合约\n（消费者合约）"]
        B["数据请求合约\n（Oracle Consumer）"]
    end

    subgraph "桥接层"
        C["预言机节点网络\n（去中心化Oracle）"]
    end

    subgraph "链下（AI推理层）"
        D["AI模型推理\n（LLM/CV/ML模型）"]
        E["可验证计算\n（zkML证明生成）"]
        F["可信执行环境\n（TEE）"]
    end

    A -->|"发起推理请求"| B
    B -->|"事件触发"| C
    C -->|"分发推理任务"| D
    D -->|"推理结果"| E
    E -->|"证明+结果"| F
    F -->|"签名提交"| C
    C -->|"共识验证"| B
    B -->|"回调执行"| A

    style A fill:#4a90d9,color:#fff
    style B fill:#5b9bd5,color:#fff
    style C fill:#f0ad4e,color:#000
    style D fill:#5cb85c,color:#fff
    style E fill:#5cb85c,color:#fff
    style F fill:#5cb85c,color:#fff

图1：智能合约调用AI模型的完整架构。合约通过预言机将推理任务分发至链下AI引擎，推理结果经由可验证计算层生成证明后返回链上。

每一层的选择都意味着不同的安全假设和成本代价。去中心化共识方案最简单但开销最大（多个节点并行推理）；zkML方案验证成本低但证明生成有显著的延迟和计算开销；TEE方案效率最高但引入了硬件信任根。实际部署时，开发者需要根据场景的安全需求做出权衡。

2.3 Chainlink Functions：一个具体的实现

Chainlink Functions是Chainlink预言机网络提供的"链下计算即服务"功能。它的工作方式可以理解为：开发者在智能合约中嵌入一段JavaScript代码（不超过100KB），这段代码在Chainlink的去中心化预言机节点网络中执行，可以调用任何HTTP API——当然也包括AI模型的API。

具体流程：

1. 智能合约调用 FunctionsConsumer 接口，提交JavaScript源代码和密封参数（使用DON（去中心化预言机网络）的公钥加密，仅DON节点可解密）
2. DON中的多个节点独立执行这段JS代码——代码通过fetch()调用AI服务API（如OpenAI、HuggingFace或自部署模型），获取推理结果
3. 节点对结果达成共识（阈值签名），将结果提交到链上
4. 智能合约接收结果并执行后续逻辑

sequenceDiagram
    participant SC as 智能合约
    participant DON as Functions DON节点
    participant AI as AI模型API
    participant Chain as 区块链

    SC->>SC: 编写JS推理代码 + 加密参数
    SC->>Chain: 提交请求（含代码哈希+加密参数）
    Chain->>DON: 事件触发
    DON->>DON: 解密参数
    DON->>AI: HTTP请求（携带输入数据）
    AI->>DON: 返回推理结果
    DON->>DON: 生成阈值签名
    DON->>Chain: 提交结果+签名
    Chain->>SC: 回调执行
    SC->>SC: 根据AI结果执行业务逻辑

图2：Chainlink Functions执行AI推理调用的序列流程。DON节点独立执行JS代码，调用AI模型API，通过阈值签名机制达成共识后提交结果。

这种设计的优势在于：开发者不需要自己运行预言机节点或管理密钥，只需在合约中嵌入推理逻辑代码即可。但代价是：每次AI调用都经过整个DON共识流程，端到端延迟通常在数十秒到数分钟级别，不适合对实时性要求较高的场景。

三、可验证推理：当AI输出需要「被证明」

预言机解决了"AI结果如何到达链上"的问题，但留下了一个更深的信任问题：合约怎么知道返回的结果确实是正确的AI推理，而不是预言机节点伪造的？

去中心化预言机的多节点共识可以在一定程度上缓解这个问题（你需要控制超过半数节点才能造假），但这不是密码学级别的保证。于是，可验证推理技术登场了。

3.1 zkML：零知识证明 × 机器学习

zkML的核心思路很简单：AI模型推理过程可以表示为一组数学运算，零知识证明系统可以将这组运算的"正确执行"编码为一个紧凑的证明。任何人拥有这个证明，就可以在不看到输入数据和不重复执行推理的情况下，确信推理结果是按指定模型正确计算的。

一个典型的zkML工作流程：

1. 模型编译：将训练好的机器学习模型（如神经网络）编译为算术电路或中间表示。这一步将模型的所有权重、激活函数、矩阵乘法等操作转化为证明系统可以处理的约束系统。
2. 推理执行：预言机节点或专门的证明者节点获取输入数据，运行模型推理，生成推理结果。
3. 证明生成：证明者同时运行一个证明生成算法，输出一个零知识证明，证明推理结果确实是按照编译后的模型权重和输入数据正确计算得出的。
4. 链上验证：智能合约调用验证器（一个轻量级的链上合约），验证这个证明的真伪。验证过程通常只需要毫秒级的时间和微量的Gas消耗。

flowchart TD
    subgraph "链下（证明者）"
        A["输入数据"] --> B["模型推理\n（前向传播）"]
        B --> C["推理结果"]
        B --> D["证明生成\n（zk-SNARKs/STARKs）"]
        D --> E["零知识证明\n（紧凑证明）"]
    end

    subgraph "链上（验证者）"
        F["验证合约\n（轻量级验证器）"]
        G["业务合约\n（消费者合约）"]
    end

    C -->|"结果"| F
    E -->|"证明"| F
    F -->|"验证通过/拒绝"| G

图3：zkML的"链下证明-链上验证"架构。推理过程和证明生成都在链下完成，链上只做轻量级的证明验证，Gas开销远低于直接执行推理。

目前主流的zkML实现方案包括：

• EZKL：一个开源zkML框架，支持将ONNX格式的模型编译为证明电路。它使用Halo2证明系统，支持多种神经网络架构（包括CNN、MLP、GNN）。在普通GPU上，对一个中等规模的MLP模型（约10万参数）进行推理证明，生成时间在数十秒到几分钟之间。
• Modulus Labs：专门针对链上AI需求构建的zkML基础设施，他们的"数字眼睛"（Digital Eyes）项目为NFT稀有度排序提供了可验证的AI推理。每个NFT排序结果的证明生成成本约为链上直接计算的1/100。
• Giza：专注于zkML在DeFi场景的应用，提供将训练好的ML模型转换为合约可调用的zk证明管道的工具链。

3.2 zkML的工程困境

尽管zkML在理论上是优雅的，它目前的工程实践中存在几个显著的局限：

证明生成时间仍然是瓶颈。 对于一个大语言模型（如7B参数的Llama系列），一次推理的zk证明生成时间在H100 GPU上仍需要数十分钟到数小时。这使zkML在实时应用中基本不可行。目前可以实际部署的zkML应用仅限于小模型——参数规模在百万级别、结构相对简单的神经网络。

证明生成成本高昂。 生成证明需要大量的GPU计算资源，产生的电力消耗和时间成本远超过推理本身。在很多场景下，这个成本是否值得是开发者需要认真权衡的。

模型更新困难。 一旦模型在链上被编译为证明电路，任何权重的更新都需要重新编译整个证明系统，这是一次全新的工程投入。这使zkML不适合需要频繁模型更新的场景。

3.3 TEE：一个务实的替代方案

如果zkML的延迟和成本不可接受，可信执行环境（TEE）提供了一个务实的替代选择。

TEE（如Intel SGX、AMD SEV）在CPU硬件层面创建了一个隔离的"飞地"（Enclave），其中的代码和数据对操作系统和外部进程完全不可见。AI推理运行在TEE内部，输入、模型权重、推理结果在处理过程中都不会暴露给外界。

TEE的优势在于效率——推理速度几乎无损耗，不需要zkML那样的秒到分钟级的证明生成。但代价是引入了额外的信任假设：你必须信任硬件制造商（Intel或AMD）的TEE实现没有后门或漏洞。历史上，SGX多次被发现侧信道攻击漏洞，这提醒我们TEE并非一个完美的信任根。

一个更加健壮的方案是将TEE与zkML结合使用：TEE负责高效执行推理，同时定期生成完整性证明（proof of integrity），由zkML机制验证TEE内部的计算未被篡改。这种混合方案在2026年已在某些实验性项目中得到应用，但尚未成为主流。

四、应用场景：合约+AI正在改变什么

技术架构的最终价值体现在它开启的应用可能性上。以下是几个已经出现或接近落地的典型场景。

4.1 动态NFT：内容随外部条件变化

传统的NFT元数据一旦铸造就永久锁定。但如果NFT的属性可以由AI根据外部条件动态更新呢？一个"天气NFT"可以根据实时天气数据——由预言机获取——调用AI模型生成不同风格的画面；下雨时画面阴郁，晴天后色彩明亮。

这种动态性的技术实现依赖于预言机+AI的联动：合约定期（或按需）触发AI推理，AI根据当前链上/链下数据生成新的元数据，合约将新的Token URI更新到NFT的存储地址。

4.2 链上信用评分

在DeFi借贷协议中，抵押率是决定借款上限的核心指标。但抵押率是一个粗粒度的指标——两个地址同样质押了10 ETH，但一个地址的链上行为历史（清算记录、交互协议的稳定性、持有资产的波动性）截然不同。

AI可以通过分析地址的完整链上行为轨迹，生成一个更细粒度的信用评分。合约调用AI推理引擎评估借款人的信用等级，动态调整其借贷参数——信用好的地址可以获得更高的借贷上限或更低的利率。

这个场景对延迟相对容忍（信用评分不需要实时更新），但对安全性和公平性的要求极高——信用模型的不透明可能导致歧视性结果。

4.3 链上安全监控

智能合约的实时安全监控是一个天然适合"AI+合约"的场景。一个链上安全合约可以定期调用AI异常检测模型，分析最近一批交易的链上行为模式。

如果AI模型检测到异常模式（例如，某地址的交易频率和Gas消耗模式突然变化，与已知攻击行为高度吻合），合约可以主动触发安全措施——暂停特定功能的执行、触发多签确认、或者向管理员发送链上警报。

flowchart LR
    A["链上交易\n实时数据流"] -->|"定期采样"| B["安全监控合约"]
    B -->|"调用AI推理"| C["异常检测模型\n（链下推理）"]
    C -->|"异常评分 ≥ 阈值"| D{"是否超过\n风险阈值？"}
    D -->|"是"| E["触发安全措施\n（暂停/警报/多签）"]
    D -->|"否"| F["继续监控"]
    E --> B

图4：AI驱动的链上安全监控流程。安全合约定时调用AI异常检测模型，根据返回的异常评分决定是否触发安全措施。

4.4 自动化治理参数优化

DAO治理中，协议参数（如借贷利率曲线、交易费率、区块Gas限制）的调整通常需要通过治理提案——一个缓慢、低效的过程。AI可以为参数调整提供建议：通过分析链上数据（资金利用率、交易量、用户增长率）和外部环境（宏观经济指标、竞争协议参数），AI模型推荐一组优化参数，合约执行这些推荐参数——在DAO的授权范围内，或在紧急情况下由多签机制确认后执行。

五、约束与权衡：没有免费的信任

让智能合约调用AI并不是一个纯粹的"加法"问题——每引入一层能力，都伴随着新的约束。

5.1 延迟

一次完整的"合约触发→预言机分发→AI推理→证明生成→链上验证"流程，端到端延迟从数秒（使用TEE方案）到数十分钟（使用zkML方案）不等。对于高频链上交互场景（如AMM的即时费率调整），这个延迟是不可接受的。但在信用评分、NFT元数据更新、治理参数建议等场景中，它是可以接受的。

5.2 成本

每一次AI推理调用都涉及链上Gas成本（触发和回调）、链下计算成本（推理+证明生成），以及预言机服务成本（如果使用节点网络）。对于大规模应用，这些成本可能快速累积。开发者需要在推理精度、安全等级和成本之间寻找平衡点。

5.3 隐私

在基础架构中，用户的输入数据和AI的推理结果在预言机节点和证明者节点上是明文可见的。如果应用涉及敏感数据（如医疗诊断、信用记录），全同态加密（FHE）与联邦学习的结合提供了一个可能的解决方案方向，但这方面的工程成熟度仍在早期。

5.4 选择矩阵

5.5 开发者决策指南：如何为你的合约选择AI调用方案

如果你是一个正在评估是否要给合约引入AI能力的开发者，下面这些判断标准可以帮助你缩小选择范围。

第一步：问自己是否需要AI。 不是所有协议问题都需要AI来解决。如果可以用简单的链上条件判断（如抵押率阈值、时间窗口、白名单机制）实现目标，就不要引入AI。AI调用增加了系统的复杂性、延迟和信任假设，只有当确定性逻辑确实不够用时才值得考虑。

第二步：评估你的延迟预算。 你的合约能接受从发起推理请求到收到结果的延迟是多少？如果是秒级（例如自动化做市协议的费率调整），TEE方案是唯一务实的选择。如果是分钟级（如信用评分更新），去中心化预言机或zkML的小模型方案都可以。如果是小时级甚至更慢（如DAO治理参数的定期优化建议），任何方案都可行。

第三步：评估安全等级需求。 如果推理结果错误会导致资金损失（如链上借贷的清算决策），你应该选择zkML或至少是去中心化预言机的多节点共识方案。如果只是影响体验而非资产安全（如NFT的元数据更新），单节点预言机加简单的链上验证可能已经足够。

第四步：考虑成本预算。 每次AI调用的总成本 = 链上Gas费（触发+回调） + 链下推理计算费 + 证明生成费（如果使用zkML） + 预言机服务费。对于高频调用场景，即使单次成本很低，累计也可能成为一个显著的运营支出。对于低频调用（每天几次），成本通常不是瓶颈。

第五步：规划迭代路径。 如果你的模型需要频繁更新（例如在运营初期通过数据反馈不断优化），zkML的证明电路重新编译成本可能过高。此时TEE或去中心化预言机方案更灵活——只需更新链下模型，不涉及链上合约变更。

这五个步骤不应该一次性完成。建议按照 MVP→迭代→投产 的节奏：先用最简单的方案（单节点预言机+HTTP调用开源模型API）跑通全流程，验证你的应用场景和用户需求，再逐步升级到更安全但更复杂的zkML或TEE方案。

六、结语：智能合约的认知升级

智能合约从单纯的"条件执行器"进化为"决策型合约"，这是一条正在被铺设的道路。预言机解决了数据到达的问题，zkML和TEE解决了信任验证的问题，而越来越多的协议开发者正在将这些技术栈组合成实际的应用。

但需要清醒认识到："合约+AI"不是万能药。 每当合约从链下获取信息或推理结果，它就在某种程度上放弃了确定性执行这个区块链在根本优势。信任从数学（合约代码的确定性执行）转移到了多种新的信任根——预言机节点的诚实、zk证明系统的安全性、TEE硬件的完整性。

对于开发者来说，理解这些权衡比理解任何具体技术方案都更重要。选择什么样的信任模型，决定了你的协议的设计空间和安全边界。而对于普通用户来说，理解"你的智能合约不是在链上做AI推理，而是通过可信的链下AI推理结果做决策"这个区别，是理解新一代链上应用的前提。

区块链给了合约执行的确定性，AI给了合约决策的智能性。两者的结合，正在让链上应用从"能做确定的事"走向"能做聪明的事"——这不是未来的愿景，而是正在发生的变化。

参考说明

• Chainlink Functions白皮书及开发者文档（chainlinklabs.com）
• EZKL开源项目文档及技术博客
• Modulus Labs "Digital Eyes" 技术报告
• Giza zkML技术栈文档
• Intel SGX可信执行环境技术资料