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