摘要（Abstract）

随着大模型与区块链的融合，“链上 AI 代理（on-chain AI agents）”成为 Web3 世界的新叙事。但在目前主流实践中，所谓“链上 AI”在技术架构和控制权分配上仍高度依赖中心化团队：模型托管在云端，API 密钥由项目方掌握，链上只负责资产结算与访问控制。这种“去中心化包装 + 中心化智能”的结构，被部分研究者称为“去中心化 AI 的幻象”。 0G Labs 提出的 ERC-7857 标准以及“智能 NFT（Intelligent NFTs, iNFTs）”概念，尝试为 AI 代理提供一种新的链上表示方式：通过加密元数据、安全转移与可验证所有权，将 AI 代理本身视作可转移的链上资产，从而在所有权与控制权层面推进去中心化。

1. 当前 Web3 圈所谓“链上 AI 代理”是如何被中心化团队控制和获利的？

2. 这种架构在所有权、隐私与治理上存在哪些结构性问题？

3. ERC-7857 / iNFT 提供了怎样的技术路径来缓解这些问题？

4. 对于未来的 DID + Agent / A2A（Agent-to-Agent）生态，这一范式变化意味着什么？

1 引言：Web3 语境下的 “链上 AI 代理”

1.1 概念与背景

• AI 代理（AI Agent）：具备感知环境、规划行动、调用工具并持续迭代的智能体，通常由大模型 + 工具链 + 记忆系统构成。

• 链上 AI 代理（on-chain AI agents）：可以与区块链交互（读写链上数据、发起交易、调用合约）的 AI 代理，常被宣传为“能自己在链上执行策略的智能体”。

• QuickNode 的 Eliza 教程展示了如何使用 Eliza 框架构建一个能发送 ETH、交互合约的 AI Agent；Agent 在本地/服务器运行，通过 Ethers.js 与链交互。

• Cyphertux 的 Polkadot 教程展示了如何用 OpenAI Agents SDK + MCP 协议构建一个自动分析治理提案的 Polkadot AI Agent，本质上是一个运行在后端的 LLM 代理，按需读取链上治理数据。

1.2 问题意识：谁真正控制这些 Agent？

谁真正控制这些 AI 代理？

• 模型与推理服务部署在谁的服务器上？

• 谁持有模型的权重、Prompt 配置与 API 密钥？

• 用户是否可以在团队消失后，依然独立运行、迁移或出售自己的 Agent？

2 现状：链上 AI 代理的实际中心化架构

2.1 Web3-Enabled Eliza Agents：链上只是“遥控器”

• 运行位置：
• Agent 程序运行在开发者控制的服务器或本地环境中。

• 智能来源：
• 教程要求配置 OPENAI_API_KEY 等环境变量，Agent 通过 OpenAI 等 LLM 提供推理能力。

• 链上交互：
• 使用 EVM 插件/Ethers.js，Agent 可以触发转账、调用智能合约等链上操作。

• 模型选择、版本更新、Prompt 策略：由开发者/项目方决定；

• API Key：由团队或单个开发者掌握；

• 用户：只能通过前端界面对 Agent 发出请求，无法审计或替换背后的智能逻辑。

2.2 治理辅助 Agent：Polkadot AI Agent 的例子

• 自动抓取 Polkadot OpenGov 的提案数据；

• 用 LLM 分析提案内容，生成摘要与建议；

• 潜在地为 DAO 治理提供“AI 顾问”。

• 智能部分完全依赖 OpenAI Agents SDK 提供的云端推理；

• 后端由教程作者/运行者掌控；

• 链上只是“数据输入 + 决策结果可能落在链上”。

1. OpenAI 提供的模型与安全性；

2. 运行这个 Agent 的服务器不会被篡改或关闭。

2.3 AI Token 项目：去中心化 AI 的“幻象”

• 文中指出，许多 AI 代币号称支持“去中心化 AI”，但：
• 推理与训练主要在链下节点或运营方服务器上完成；
• 链上只记录任务、奖励与质押；
• 普通用户无法验证模型是否按声明运行，也无法独立迁移模型或 Agent。

• 论文用对比表格展示了“中心化 AI 服务 vs 去中心化 AI Token 项目”的相似性：
• 二者都依赖少数算力节点；
• 去中心化程度常常只是从“单一公司”变成“少数节点寡头”。

3 问题分析：所有权、隐私与治理的错位

3.1 所有权 vs 控制权错位

• 用户往往只拥有：
• 某个 NFT/SBT
• 某个访问权限（例如订阅、API 次数）

• 但并不拥有：
• 模型权重
• 参数、Prompt、长期记忆
• 以及上述资源的迁移权与处置权

链上看起来“拥有”一个 Agent，实际上只是“租用了团队提供的智能服务”。

3.2 元数据隐私与可迁移性不足

• 已训练好的神经网络权重；

• 任务特化后的 Prompt 与策略；

• 与用户长期交互形成的记忆与偏好。

• 元数据通常是静态的、公开的 URI；

• 不适合存放敏感的、需要加密的 AI 模型数据；

• 更没有“在转移 NFT 时一并安全转移加密智能数据”的机制。

• 要么元数据放在团队私有存储中，用户无法验证；

• 要么把信息“降级”为简单图片/描述，失去真实智能含义。

3.3 治理与安全风险

• DeFi 策略执行；

• DAO 治理建议与自动投票；

• 高价值 NFT/资产管理；

1. 单点故障：团队关停、API 封禁、服务器被攻击都会导致 Agent 失效。

2. 策略篡改：团队可在用户不知情的情况下更改策略逻辑，甚至植入恶意行为。

3. 合规与责任界定困难：当 Agent 做出了有争议的决策，责任在用户、团队、还是底层 AI 服务商，边界并不清晰。

4 ERC-7857 与 iNFT：为 AI 代理重新定义链上所有权

4.1 标准概览

• 在延续 ERC-721 兼容性的前提下，引入：
• 加密元数据（Encrypted Metadata）
• 隐私保护的元数据验证与转移
• 动态元数据更新

• 使一个 AI Agent = 一个 iNFT，即：
• 智能体的“身份 + 能力 + 记忆”可以被打包为 NFT
• NFT 持有者即为该 Agent 的实际控制者

4.2 核心机制：从加密元数据到安全转移

步骤 1：元数据加密与哈希承诺

• 将 Agent 的关键元数据（模型权重、记忆、角色配置等）以加密形式存储；

• 生成对应的哈希值（commitment），记录在链上，作为“这份智能数据”的唯一承诺；

• 当前持有者拥有访问这些加密元数据的密钥。

步骤 2：交易触发与预言机重新加密

• 一个受信任的预言机或 TEE 环境接收旧的加密元数据；

• 在安全环境中解密后，用 新密钥 对元数据重新加密；

• 将新的加密元数据与新哈希上传到去中心化存储（如 0G Storage）。

步骤 3：接收者专属密钥

• 新的加密密钥再用接收者（买家）的公钥加密；

• 这一“加密后的密钥”包含在链上交易参数或事件中；

• 只有持有对应私钥的接收者才能解密并恢复访问 Agent 的智能数据。

步骤 4：链上验证与转移完成

1. 发送方是否仍有访问旧加密元数据的能力；

2. 预言机提供的证明是否表明“新元数据由原元数据正确派生”；

3. 接收方对元数据哈希签名，确认自己可访问。

• iNFT 的所有权在链上完成转移；

• 接收方获得解密密钥，从而完整掌握该 AI 代理的智能能力。

这一设计的关键是：

转移的不仅是 TokenID，而是 TokenID 对应的“智能体全部能力与状态”。

4.3 结合去中心化存储与动态元数据

• 加密后的元数据与更新版本存储在去中心化存储网络中；

• 通过哈希与加密验证确保不可篡改性；

• 支持 Agent 在运行过程中不断更新状态（学习新数据、调整策略等），同时保持从链上可验证的一致性。

5 对比：中心化团队控制型 Agent vs iNFT 模型

1. 明确把“智能元数据”视作 NFT 的一部分；

2. 用加密学手段定义了“谁真正拥有这个 Agent”；

3. 为未来的多方运行、跨平台迁移提供了统一接口。

6 对 DID + A2A 生态的启示与未来研究方向

6.1 与 DID / 可验证凭证（VC）结合

• Agent 本体的“所有权层”：
• 谁持有 iNFT，谁在链上对 Agent 具有控制权；

• 而 DID + VC 提供：
• Agent 与人/机构的身份绑定；
• Agent 被授权访问哪些个人数据、调用哪些外部 API。

1. 用户通过 DID 对某个 Agent 进行授权（数据访问、签名权限等）；

2. Agent 自身则通过 iNFT 进行买卖、出租或抵押；

3. 不同 Agent 之间（A2A）可以通过彼此的 iNFT 与 DID 建立信任关系。

6.2 研究与落地方向（可直接变成 PPT 的“展望”页）

1. 可验证推理（Verifiable Inference, 如 zkML）与 ERC-7857 结合
• 目前 ERC-7857 主要解决“所有权与元数据转移”；
• 未来可以进一步在“Agent 真的按约定执行了吗？”上引入零知识证明。

2. 预言机与 TEE 信任模型的去中心化
• 如何避免单一预言机成为新的中心化单点？
• 是否可以通过多预言机共识、MPC 或可信硬件多方验证来降低信任假设？

3. Agent 市场与激励机制设计
• 在 iNFT 框架下，如何设计“训练–部署–转售–分润”的完整经济闭环？
• 如何合理分配：模型作者 / Agent 运营者 / 终端用户之间的收益？

4. 监管与合规
• 当 Agent 具备执行链上资产操作能力时，谁对其行为负责？
• 如何在不破坏隐私的前提下，为监管提供必要的审计线索？

7 结论

• 多数项目的架构仍然是：
• 链上负责资产与权限；
• 链下团队/节点负责智能与执行；

• 在所有权、隐私与治理三方面，用户都无法真正掌控自己的 AI 代理。

• “AI 代理作为一种可转移的链上资产”

• “用户真正拥有并控制其个人/企业 AI 代理”

我们正在从“完全中心化团队控制的链上 AI 代理”，

逐步走向“以 iNFT 为核心、控制权部分去中心化的 AI 资产生态”。

0G Introducing ERC-7857 | 0G

0G Introducing ERC-7857 | 0G

The First Decentralized AI Operating System

Introducing AIverse: The Marketplace for iNFTs | 0G

Introducing AIverse: The Marketplace for iNFTs | 0G

The First Decentralized AI Operating System