--- id: 6 title: 去中心化 AI 堆栈：为什么执行层决定 Web3 与 AI 能否协同 slug: aibitrootweb3ai date: 2026/07/28 summary: Web3 与 AI 的融合不只是叙事叠加。本文从 AI Agent 的链上行为、算力调度与结果可验证三条线索，说明执行层为什么成为去中心化 AI 堆栈的瓶颈，以及 Bitroot 相关能力如何各司其职。 keywords: 去中心化AI堆栈,Web3,AI Agent,执行层,Bitroot heroImage: /cms-media/file/1The%20Future%20of%20Decentralized%20AI%20Stack.jpg --- 把 Web3 和 AI 写进同一张幻灯片很容易，真正难的是让两者在同一条链上协同工作。AI 需要吞吐、低延迟和可编排的计算资源；Web3 需要可验证、抗操纵与明确的权责边界。两边的目标并不天然兼容。本文不讨论口号，而是把「去中心化 AI 堆栈」拆成几层，说明执行层为什么往往是最先卡住的那一层。 ## AI 侧缺的不是模型，是可信的执行环境 主流大模型训练与推理仍高度集中在少数云厂商。问题不只是供应商锁定，更在于：调用方很难独立核验「用了哪个模型版本、吃了哪些输入、产出是否被篡改」。对普通聊天应用，这或许可以接受；对要自动调仓、结算、触发合约的 AI Agent，黑箱就是系统性风险。 Web3 本应补上可验证性，但多数公链的执行层仍按「人类用户偶尔点一次交易」设计。Agent 可能在短时间内发出大量相互依赖的交易：询价、拆单、跨协议调用、事后对账。若链上确认慢、冲突处理粗暴、费用波动大，Agent 要么退化成链下编排加偶尔上链，要么在拥堵时失效。关于单线程 EVM 为何撑不住这类负载，可参见 [《EVM 单线程瓶颈》](/zh/blog/evm-single-thread-bottleneck)。 ## 堆栈视角：五层各管一件事 用堆栈而不是「全栈叙事」来看，去中心化 AI 大致需要五层能力，且层与层之间应解耦： 1. **结算与合约执行层**：决定状态谁先谁后、冲突如何收敛。没有足够快且可预期的最终性，上层的 Agent 编排没有意义。 2. **算力调度层**：把训练/推理任务分发给异构 GPU 或边缘节点，记录任务元数据与完成证明，而不是假装「链上直接训练千亿参数模型」。 3. **可验证计算层**：用零知识证明、TEE 或 MPC 等手段，让「算过什么」可被第三方抽查，细节见 [《可信计算框架》](/zh/blog/trusted-computing-framework)。 4. **数据与模型确权层**：贡献者、模型版本、收益分成需要可执行的规则，而不是白皮书承诺，见 [《AI 资产确权》](/zh/blog/ai-data-ownership)。 5. **应用与 Agent 层**：策略、风控、人机协同逻辑；应尽量把重计算放在链下或专用算力网络，把结算与关键状态变更留在链上。 Bitroot 的叙事落点，主要在第 1 层（乐观并行 EVM）以及与第 2、3 层的衔接：链负责排序与结算，算力网络负责重负载，可信计算负责抽查与隐私边界。产品定位的完整说明见 [《Bitroot 定位》](/zh/blog/bitroot-positioning)。算力接口边界见 [《分布式 GPU 与边缘算力》](/zh/blog/gpuai)；「AI 原生」能力清单见 [《AI 原生区块链》](/zh/blog/ai-native-blockchain)。 ## 为什么「执行层」特别关键 很多人把 AI × 链的瓶颈归咎于「Gas 太贵」或「没有原生 AI opcode」。更常见的失败模式其实是：共识已经给出交易顺序，执行却跟不上，或者一遇到热点合约就退化成近似串行。对 Agent 而言，这意味着： - **延迟不可预期**：同一策略在不同拥堵程度下行为漂移，难以做风控。 - **可组合性打折**：多协议原子操作更容易触发冲突与重执行，吞吐被热点拖垮，参见 [《并行 EVM 工作负载热点》](/zh/blog/parallel-evm-workload-hotspots)。 - **验证成本上升**：节点若无法高效重放并行结果，去中心化验证会变成纸面承诺。 因此，并行执行、共识与执行解耦、以及明确的冲突检测，不是「为了刷 TPS」，而是给自动化实体一个可规划的结算基板。机制地图见 [《并行 EVM 架构概览》](/zh/blog/bitrootevm)、[《Pipeline BFT 与执行解耦》](/zh/blog/bitroot-pipeline-bft)、[《乐观并行化机制》](/zh/blog/bitrootevm-)。 Bitroot 在测试网口径下披露过单分片数千至数万 TPS 量级、确认延迟约秒级乃至亚秒级的工程目标与测试结果；具体数字依赖硬件、负载与冲突率，不代表主网稳定表现，也不构成任何收益承诺。读指标方式见 [《性能指标术语表》](/zh/blog/performance-metrics-glossary)。 ## 该警惕的叙事陷阱 - **链上训练神话**：完整预训练几乎必然发生在链下或专用网络；链更适合记录任务、支付与验证摘要。 - **把算力挖矿写成理财**：分布式 GPU 网络可以降低闲置率，但不等于稳定收益。 - **用兼容性口号代替工程**：真正的 EVM 兼容要落到字节码与工具链，见 [《EVM 兼容意味着什么》](/zh/blog/evm-compatibility-explained)。 - **用「融合」掩盖信任缺口**：缺口清单见 [《Web3 与 AI 融合》](/zh/blog/web3-ai-convergence)。 ## 落地时先建哪一层 若资源有限，建议顺序是：先让结算延迟在自动化负载下可预期，再挂任务/支付与最薄验收，然后按威胁模型引入 TEE 或 ZK，最后做复杂确权与市集。反过来先做模型商城而结算仍抖动，只会放大争议。去中心化与性能的张力见 [《去中心化与性能的权衡》](/zh/blog/decentralization-performance-tradeoff)；读者入口见 [《谁该读并行 EVM》](/zh/blog/who-should-read-parallel-evm)。 ## 层与层之间的失败如何传染 堆栈的价值在于解耦，失败却会沿接口传染。算力层验收含糊时，结算层只会忠实地执行错误分账；确权层缺失时，Agent 应用层只能把平台条款当最终真相；执行层冲突失控时，上层再完美的策略编排也会在费用与延迟上崩溃。因此「先画五层」不是为了多写几个模块名，而是为了给每个接口规定：输入是什么、验收是什么、失败时状态停在哪。 对开发者而言，优先集成顺序建议是：先在并行 EVM 上把任务/支付状态机跑稳，再接算力调度与证明，最后才做面向终端的 Agent 体验。反过来从聊天机器人倒推上链，几乎总会在确认延迟与不可验证输出上返工。兼容与工具链约束见 [《EVM 兼容意味着什么》](/zh/blog/evm-compatibility-explained)。 ## 评估清单：读项目材料时看什么 遇到「去中心化 AI」项目时，建议至少核对：结算层是否给出冲突率与重放成本，而不只是峰值 TPS；算力层是否描述验收与挑战，而不只是 GPU 数量；确权层是否有撤销与分账状态机，而不只是铸造图片；可信计算是否写明对手模型，而不只是名词堆叠。 Bitroot 相关材料应放在同一清单下阅读：并行 EVM 与 Pipeline BFT 负责结算基板，算力与可信计算负责链下重负载与抽查，确权负责规则执行。任何把四者合并成一句「AI 公链已就绪」的表述，都值得拆回清单逐项打勾。定位见 [《Bitroot 定位》](/zh/blog/bitroot-positioning)。 堆栈地图的用处是减少范畴错误：不要用结算层解决训练问题，不要用算力层解决最终性问题，不要用确权 NFT 解决验收问题。分清范畴之后，Web3 与 AI 的协同才有可讨论的接口。 ## 与系列机制文的阅读顺序 若目标是理解结算基板，建议顺序为：单线程瓶颈与扩容地图 → 三条并行路线与 OCC 入门 → 本文堆栈地图 → 并行 EVM 架构概览与定位。若目标是 AI 产品，则在堆栈地图之后读信任缺口、可信计算、算力网络与确权。两条路径都指向同一事实：没有可预期的执行层，上层叙事无法稳定交付。 ## 小结 去中心化 AI 堆栈能否成立，取决于能否把「智能」放在可验证的边界内，同时把「结算」做得够快、够确定。执行层是这条链路上最先被 Agent 压测的部分。后续文章分别展开并行架构、可信计算与确权；本文只建立分层地图，避免把所有问题塞进一句「Web3 + AI」。 ## 延伸阅读 - [《Web3 与 AI 融合：信任缺口在哪里》](/zh/blog/web3-ai-convergence) - [《Bitroot 并行 EVM 架构概览》](/zh/blog/bitrootevm) - [《AI 原生区块链需要哪些能力》](/zh/blog/ai-native-blockchain)