先看一个完整过程
源码 → 编译 → Wasm → 运行时 → 宿主能力。下面的动画用同一个照片例子把它们串起来。
Deep Research Topic
WebAssembly · Component Model · WASI
2026-10-07 · 入门导读与动画更新
WebAssembly：先看懂 Wasm，再理解 Agent 时代的程序执行底座
先用一段照片处理逻辑，理解 WebAssembly（Wasm）是什么、怎样运行、与 JavaScript 有什么关系；再进入组件化、标准进展和 Agent 时代的深度研究。
表示该章节含 SVG 动画，目录和正文使用同一标识。
七张动态图速览 · 展开选择
按“入门 → 架构装配 → Agent 洞察”阅读，也可直接定位单张图。图号表示阅读顺序，不表示技术成熟度。
入门 · 1 张图
手机默认纵向阅读；需要完整桌面构图时使用播放器的“查看细节”。图旁提供本图链接、前后图和返回目录入口。链接只定位图，不设定播放时间。
先看懂：Wasm 究竟是什么？
零基础入口。先理解程序如何被运行，再看版本号、组件模型和 Agent。
一句话：Wasm 是一种面向虚拟机的二进制指令格式，也是编译目标。通常用 Rust、C/C++ 等语言写逻辑，再借助相应工具链生成
.wasm，由支持它的运行时执行；不是让 CPU 直接识别一种新的程序文件。[B1] [B7]再分清六个术语
Module、Runtime、Host、WIT、Component、WASI 各有职责。进入术语速查。
最后看 Agent 的新问题
生成代码之后，怎样验证、限权、版本化并重复调用？跳到 Agent 深度章节。该部分保留研究假设标记。
图 1 · Wasm 怎样运行？
机制示意
读图结论：源码先编译为 Wasm，再由运行时执行；照片例子用 JS 与 Wasm 的分工说明这一过程。
展开文字读图与边界说明
阅读顺序：先看源码与编译，再看运行时和宿主；最后对照照片例子中传入像素、执行计算、显示结果的分工。
读图：五张卡依次高亮；照片例子展示 JS 与 Wasm 的分工。动画为说明性演示，本页没有真实执行图中的 Wasm 代码。可暂停、重播；手机默认纵向阅读，也能切换完整桌面图。
本图不证明：照片流程只是说明性演示，本页没有执行对应的 Wasm 代码，也没有给出性能测试。
依据与验证：WebAssembly 定义 · JS 协作与 FAQ
术语速查：不要把这六件事混为一谈
先分清谁负责计算、谁负责执行、谁提供外部能力。接口与组件定义见一手文档。[B4]
Core Module · 核心模块
包含函数、内存与导入/导出等定义的程序单元。可以先把它理解为“一份能被装载的计算模块”，而不是完整操作系统。
Runtime · 运行时
负责校验、实例化与执行 Wasm 的引擎。浏览器可以内置引擎，应用也可以嵌入独立引擎。
Host · 宿主
承载运行时的环境或应用，并通过接口提供文件、网络、页面或领域服务。支持一个接口，不代表自动授予所有资源权限。
WIT · 接口描述语言
描述组件需要什么、提供什么，以及参数和结果的类型。它是接口合同，不是业务逻辑语言，也不是用户权限表。
Component · 组件
在核心模块之上组织更丰富的接口与组合关系。一个组件可以包含模块或其他组件；普通核心模块不自动等于组件。
WASI · 系统接口家族
为文件、时钟、HTTP 等能力定义标准接口。它不是操作系统，也不等于宿主必须提供全部能力。
学习顺序：先用 Core Module + Runtime + Host 理解“能运行”；再用 WIT + Component + WASI 理解“怎样跨语言组合、接入系统能力”。这些概念有层次，不是六个同义词。
与 JavaScript、原生程序、容器的关系
从“流程怎么走”到“系统怎么搭”：组件的架构组合
2026-10-07 增补。实线框表示包含，接口接头表示依赖绑定，外层边界区分制品与宿主。动画解释结构，不代表已运行编译器。
先建立一个直觉：组件不是把几个方框用箭头串起来。它可以包含 Core 模块或子组件，并用一个组件的 export 满足另一个组件的 import；组合后的组件继续暴露自己的外部合同。[A1] [A2] [A3]
图 2 · 组件怎样装配成一个系统？
架构示例
读图结论：组合可以在内部满足一部分接口依赖，剩余依赖仍需要宿主提供。
展开文字读图与边界说明
阅读顺序：先看包含关系，再对准 Reporter 与 Formatter 的接口接头；最后找组合边界之外的 store 导入。
看图方法：Core 模块轻微入位，接口接头靠拢，组合边界与宿主框分阶段强调。所有内容始终保留，暂停在任何时间都能读完整架构。Reporter 使用 Formatter 的 format 导出；组合后 format 变成内部依赖，store 仍须外部提供。图中 @1 是版本标识的简写，并非完整 WIT 包名。[A3]
本图不证明：模块入位和接头靠拢只是解释结构，不证明已运行编译器、实现零拷贝或完成运行中热替换。
决定哪些组件组合成制品
例如 WAC 把 Reporter 的 format 导入接到 Formatter 的导出，生成组合组件。没有被内部满足的依赖仍是外部导入；“拼成一个文件”不等于依赖或权限消失。[A3]
决定剩余接口由谁实现
宿主注册接口实现，连接组件所需的 imports，然后实例化。以 Wasmtime 的常规 Linker 路径为例，缺少导入或类型不匹配会报错；资源权限仍需宿主配置。[A4]
决定何时调用哪个版本
LRI 推演：Agent 可以选择已经验证的组合制品，也可以提出新的组合方案；但部署、授权和验证仍由应用机制落实。一次工具调用不是一次二进制组件组合。
WIT 描述外部合同，不替你实现业务
world 描述需要与提供的接口；Canonical ABI 规定类型值在二进制边界的表示与传递。它们帮助跨语言互操作，但不是共享同一套语言内部对象，也不能据此承诺零拷贝。[A2] [A6]
类型能接上，不等于换实现就没有风险
工程判断：替换存储或排版实现后，还要检查错误语义、状态、性能、权限与回退。构建时重组、新实例装配和运行中热替换是三个不同问题；图中的装配动画不证明后者。
图 3 · 同一能力怎样进入不同宿主？
架构示例
读图结论：浏览器、服务端与 Agent 应用分别需要匹配的运行时和宿主接口。
对 Agent 时代的新洞察：可复用资产不仅是代码，也可以是“哪个组件版本、连接哪个接口实现、剩余能力交给哪个宿主”的组合方案。这是 LRI 的架构判断，不是标准已经提供完整 Agent 平台的声明。程序记忆因此还应关联组合关系与验证证据，而不能只保存一段源码或一个文件名。
把架构判断变成可验收实验：同一报告能力，替换存储实现
固定 Reporter、Formatter、输入与 report 接口；分别接入内存存储和持久化存储。检查组合产物的外部 WIT、剩余导入、输出一致性、错误语义、权限范围与资源预算；缺失接口或版本不匹配应明确失败。随后验证新实例的状态接续与回退。当前是新增实验设计，尚未实施真实 WAC 编译或跨宿主部署。
常见误解：六个不能直接画等号的地方
理解能力边界，比记住术语更重要。
Wasm = 一门新的应用开发语言？
不等同。它通常是编译目标；也有可手写的文本形式 WAT，但这不改变它与 Rust、JavaScript 等源语言的分工。[B1]
Wasm = 总比 JavaScript 快？
不是性能保证。要对实际计算、编译装载、数据传递和宿主调用一起测量。能够互补不等于需要把全部逻辑迁移。[B2]
Wasm 沙箱 = 程序没有漏洞？
一个 .wasm = 任何环境都能直接跑？
Wasm = 容器或操作系统替代品？
使用 Wasm = Agent 生成代码自动安全？
不是。Wasm 是候选执行底座；Agent 仍需要验证、授权、版本管理与故障恢复。后文对此作研究推演，不把方向判断写成已验证结果。进入 Agent 章节。
一、核心判断：Wasm 已从“便携 ISA”进入“组件系统”阶段
事实、趋势判断和待验证假设分开。
已有技术综述：原版本进展口径截至 2026-09-29
2025 年 Wasm 3.0 把 core language 的大块长期缺口一次性补齐：memory64、多 memory、GC、typed references、tail calls、原生异常、relaxed SIMD 和 deterministic profile。2026 年生态重心明显上移：WASI 0.3 把 async/future/stream 下沉为 Component Model 原语，0.3.1 开始形成固定 release train；与此同时 Component Model 1.0 的路线已经从“功能够不够”转向“ABI 是否足够轻、浏览器能否原生、线程/资源/包管理/调试能否形成生产闭环”。未来 Wasm 的竞争力更可能来自组件边界，而不是单个模块跑分。
本次新增基础导读与可视化，不把旧时间线重新标记为全量最新核验。
Wasm 3.0 已成为 live standard
2025-09-17 发布的 Wasm 3.0 将 memory64、多 memory、GC、typed references、tail calls、exception handling、relaxed SIMD、deterministic profile 等并入正式标准，明显增强高层语言、超大内存、函数式/动态语言和可重放执行能力。
WASI 0.3 把 async 从“库协议”变成组件 ABI 原语
2026-06-11 发布 WASI 0.3.0：future、stream、async function 进入 Component Model/canonical ABI，解决 P2 中 pollable 无法自然穿过组件链的问题，让异步调用真正可组合。
WASI 0.3.1 开始固定节奏演进
2026-08-11 的 0.3.1 是 0.3.x 首个 point release，并宣布约每两个月一个版本、计划延续到 2027；新增 WIT 的 map<K,V> 以及 implements/external-id annotations，表明 Component Model 正从“大版本实验”走向连续演进。
Wasmtime 47/49 把新 core 能力推向默认生产路径
Wasmtime 47 默认启用 Wasm GC 和 exceptions；截至 2026-09-24 最新维护版 49.0.1 已进入修正 fuel accounting、HTTP body memory exhaustion、WASI filesystem 边界等生产细节的阶段，说明核心能力正在从“实现”走向“硬化”。
未来 2–3 年真正的主战场是 Component Boundary
Core Wasm 已足够成熟，差异化会转到 typed interface、组件组合、async、线程、零拷贝 ABI、包发布、record/replay、跨语言 bindings 与 host capability。价值单位从“一个 .wasm 模块”转向“一个可组合组件”。
Agent 时代，Wasm 的新机会是“动态程序的可信执行层”
Agent 不缺生成代码的能力，缺的是可限制权限、可复现、可版本化、可移植、可快速装载的运行边界。Wasm + WIT + capability host 很可能比“直接 shell / Python / native plugin”更适合作为模型生成程序的执行单元，但这一方向仍需系统级实测。
一句话：第一阶段 Wasm 解决“同一份计算跑到哪里都能执行”，第二阶段正在解决“不同语言、不同组件、不同权限的程序如何像系统组件一样组合”。
二、2025–2026 关键时间线：变化速度已经从年级别进入月级别
只列对架构判断有实质影响的里程碑。
| 时间 | 事件 | 技术含义 |
|---|---|---|
| 2025-09-17 | Wasm 3.0 completed | Core 标准一次性吸收 memory64、multi-memory、GC、typed refs、tail calls、EH、relaxed SIMD、deterministic profile；高层语言和大型非 Web workload 的基础明显加强。 |
| 2026-06-08 | 公开 Component Model 1.0 路线 | 工作焦点明确转向 lazy ABI、zero-copy forwarding、sync-call overhead、browser native、C ABI lowering、record/replay、WIT expressivity。 |
| 2026-06-11 | WASI 0.3.0 ratified | async/future/stream 成为 Component Model 原语；组件链异步语义正式进入标准路径。 |
| 2026-07-20 | Wasmtime 47 默认启用 GC + Exceptions | Core 3.0 的高层语言能力进入主流 standalone runtime 默认配置，而不是长期 feature gate。 |
| 2026-07-21 | WAMR 离开 Bytecode Alliance 独立发展 | 生态出现更明确分工：Bytecode Alliance 继续押注 Wasmtime/Component Model，嵌入式 runtime 可能形成更独立路线。 |
| 2026-08-11 | WASI 0.3.1 | 引入 map 与 implements annotations；正式建立 0.3.x 双月 release train。 |
| 2026-09-21/24 | Wasmtime 49.0.0 / 49.0.1 | 持续推进 EH/GC/CLI 与安全修复，runtime 正在进入快速迭代 + LTS/安全工程并行阶段。 |
三、Wasm 3.0：Core 的意义不是“多几个指令”，而是高层语言终于不用大量自带 runtime workaround
Core Wasm 的能力边界已明显从 C/Rust 风格扩展到 GC 语言、函数式语言和大型内存应用。
Memory64
4 GiB → 64-bit address
内存/表可使用 i64 地址。理论地址空间到 16 EiB；Web 仍有限制，但 standalone runtime 可承载更大数据与 server workload。
Multi-memory
单模块多个 address space
安全隔离、public/private buffer、instrumentation、static linking 都更自然；也为后续“component smashing / lower-components”提供底层基础。
GC + Typed Refs
高层语言不必把 GC 全塞进线性内存
runtime 提供低层 struct/array/ref/GC primitives；Java/Kotlin/Scala/Dart/OCaml 等语言的 Wasm 路线因此更实际。
EH + Tail Call
控制流语义补齐
异常不再需要逃逸到 JS/host 模拟；tail calls 支持函数式语言、CPS、FSM 和 tracing/JIT 风格技术。
Deterministic Profile 很容易被低估
Relaxed SIMD 允许部分平台差异，同时标准又定义 deterministic profile，为区块链、可重放系统和需要跨平台一致性的执行环境提供明确选择。对 Agent 生成程序、审计回放、调试复现，这一点可能比“峰值 SIMD 性能”更重要。
Core Wasm 正越来越像成熟虚拟 ISA，而不是“浏览器里的 C target”
64-bit memory、多个 address space、GC heap、typed function ref、EH、tail call 的组合，意味着源语言不必再强行折叠到“单线性内存 + 整数/浮点 + 手写 runtime”模型。
四、WASI 0.3：2026 年最重要的变化，是 async 终于变成可组合语义
P2 的异步主要通过 wasi:io/pollable 建模，P3 把它下沉到 Component Model 自身。
异步成为接口级属性
bindings generator 可以直接生成语言原生 async API，不需要每个组件各自解释 pollable 协议。
单值异步结果
跨组件边界表达延迟完成的结果，不再依赖 component-local pollable 中转。
真正的跨组件流
适合 HTTP body、文件流、网络、生成式数据通道和长链 pipeline，重点是 wake-up/flow control 可以跨组件组合。
为什么重要：当 A → B → Host 时，P2 的 pollable 属于某个组件实例，B 很难透明传递 readiness；P3 把 task/async 语义放进 Component Model，使“组件组合”与“异步执行”第一次真正站在同一抽象层。
五、重新理解 Wasm 技术栈：Core / Component Model / WASI 是三层，不应混为一个 runtime feature
未来架构判断必须明确每个能力属于哪一层。
Core WebAssembly
模块、指令、内存、表、GC、异常、线程等“计算机本体”。它不定义文件、网络、HTTP、GPU，也不定义高层语言之间如何传 string/record/resource。
Component Model + WIT
定义组件如何 bundle/link/compose，以及 typed values、resources、interfaces、canonical ABI 如何跨隔离边界传递。它更像“Wasm 的微内核与 ABI”。
WASI
文件、socket、clock、HTTP、random 等 capability-secure OS/service interfaces。WASI 依赖 Component Model，但 Component Model 不依赖某一套 WASI service。
架构含义：未来一个 runtime 可以只实现 Core，也可以通过“lower-components”之类方案较低成本承载 Component；一个 Host 可以按能力只提供部分 WASI interface。这比 POSIX 式“给进程一个巨大系统调用世界”更适合细粒度沙箱。
六、未来五大趋势：从功能补齐转向性能、并发、浏览器、供应链与可观测性
以下趋势以 Component Model 1.0 路线和当前 active proposals 为依据。
组件边界从“能传复杂值”转向“低开销传复杂值”
当前 canonical ABI 依赖 cabi_realloc，复杂返回值可能产生多次 host↔guest allocation/copy。1.0 路线提出 lazy value handles：callee 返回 opaque handle，caller 再把值直接 materialize 到目标位置，可支持未使用即 drop、零拷贝 forward，并减少 host round trip。
异步基础设施不能拖慢同步 fast path
公开测量显示当前 async task machinery 曾给纯同步跨组件调用带来约 3.5× overhead。后续目标是把同步 adapter task 压到 stack 上，让 Cranelift 等优化器基本消掉额外成本。
组件并发将从 async 扩展到 thread semantics
cooperative threads 位于 Component Model 层；wasi-libc pthreads 大部完成、LLVM patch 已进入发布链、Wasmtime 有 feature-flag 实现。它被视为迈向 shared-everything threads 的关键桥梁。
组件模型最终必须回到浏览器
Component Model 1.0 的公开条件之一是至少两个浏览器 engine 原生实现。当前 jco 可以 transpile 到 Core Wasm + JS glue，并用 “use components” telemetry 为原生实现积累真实使用证据；Mozilla/V8 都在关注，但尚不能写成已承诺。
组件会越来越像可发布的软件包，而不是裸二进制
wkg/OCI、wac composition、wit-bindgen、guest/host C ABI、“component smashing”、包版本与 interface compatibility 会成为生产工程重点。WASI 0.3 已要求 phase-2 proposal 有 OCI-published artifact，说明 registry/包分发正在进入标准流程。
WIT 边界天然适合全链路可重放
公开 1.0 路线展示了用 instrumentation component 包裹 imports/exports，把 WIT-level calls 记录为 WAVE，再脱离原 host 重放。共享无状态/显式接口让这种调试能力比传统进程更自然。
七、并发路线：不要把 core threads、stack switching、Component cooperative threads 混在一起
2026 年同时存在多条并发路线，成熟度不同。
| 能力 | 当前状态（2026-09） | 作用 | 判断 |
|---|---|---|---|
| Core Threads | Phase 4 | shared memory + atomics 的核心线程基础 | 标准化程度高，但 standalone “如何 spawn” 仍需要上层系统接口 |
| Stack Switching | Phase 3 | continuation / coroutine / language runtime control | 重要但不再是 WASI 0.3 async 的前置条件；P3 async 已走 Component Model 路线 |
| Cooperative Threads | Component Model 后续 P3 minor，实现进行中 | 让 std::thread::spawn 等语言线程模型跨组件工作 | 短期最值得关注的组件并发能力 |
| Shared-Everything Threads | Phase 1 | 多个组件/模块更深层共享 heap/runtime state | 长期方向，可能显著提高共享语言 runtime 的效率，但复杂度/隔离成本更高 |
| Wide Arithmetic / Custom Page Size | Phase 3 | 扩大数值/内存表达与 runtime 调优空间 | 属于 Core 持续演进，不是 Component Model 主线但会改善专业 workload |
八、浏览器与 Server Wasm 正在重新汇合，而不是永久分叉
过去几年 WASI/Component Model 主要在 server/edge 先走，1.0 路线开始明确要求浏览器原生回归。
现在：jco 作为 polyfill/telemetry bridge
任何 component 可以 transpile 为 Core Wasm + JS glue 在浏览器运行。它解决“现在能不能跑”，同时通过实际 usage telemetry 帮助浏览器厂商判断 native implementation 的价值。
未来：Component Model 可能成为 Web 与 Server 的共同组件 ABI
如果浏览器原生支持 WIT/component，并结合 WebIDL imports，Rust/Go/Python/Java 等组件可以用同一种 interface/packaging 逻辑跨 Web、server、edge 分发。这个愿景仍受浏览器实现投入和 ABI 简化进度约束。
九、Agent 时代的新变量：Wasm 可能从“应用部署格式”转向“动态能力执行单元”
这是基于标准特性的 LRI 推论，不是 WebAssembly 官方 roadmap。
先看结构，再看流程：前面的架构装配双图解释“哪些组件构成能力、哪些依赖还要宿主满足”；下面的四张动画再解释生成、验证、调用与证据回流。组合关系与执行过程是两张不同的图，不能互相替代。
图 4 · Agent 生成的程序怎样进入执行路径？
LRI 架构推演
读图结论：生成只是候选起点，验证、权限与版本管理之后才讨论可复用执行路径。
展开文字读图与边界说明
阅读顺序：按六幕看实际形变：接口与逻辑拼合；接头不匹配先回弹、修正后嵌合；检查完成后闸门才开启；程序入位；Host 区分允许读与拒绝写；异常携带记录返回 Agent。
读图重点：Agent 负责高自由度 reasoning；WIT/Component 把程序契约、类型与 capability surface 显式化；通过验证的 Wasm artifact 才进入可复用 Fast Path。Record/replay 与版本证据用于判断是否值得长期沉淀，而不是把“生成出来”直接等同于“可以上线”。
本图不证明：这条链是 LRI 系统推演，不是标准自带的完整 Agent 平台，也不是已经通过的上线验收。
与 MHS 专题的连接：MHS 更关注 Agent → Program/Policy → Fast Controller → Physical World；这里关注 Agent → Typed Program → Wasm Component → Capability Host → Digital/Device Resources。两者共同指向“把反复成功的 reasoning 固化成可执行 Program Memory”，但 Wasm 是候选软件执行底座，不是 MHS 的实现要求，也不直接解决机器人运动控制。
图 5 · 每次推理，还是验证后重复调用？
待验证比较
读图结论：程序记忆要回答的是验证后的重复调用何时值得，而不是保证总比逐次推理便宜。
展开文字读图与边界说明
阅读顺序：按六幕比较：重新推理的步骤轮转；候选装配；版本指示器在验证通过后切换；多个请求复用原位的 vN；新情况被退回 Agent；最后把前期投入与后续调用、维护放在一起计算。
Program Memory 不是 prompt cache：它把通过验证的 reasoning 结果变成具备 contract、version、evidence 与 rollback 的执行资产。真正应实验的是 break-even：调用频率、reasoning 成本、任务变更率、验证成本与回放/治理收益在什么条件下使“生成一次、调用多次”明显优于每次重新 reasoning。
本图不证明：本图没有实测盈亏平衡点；调用频率、环境变化和验证成本需要在同一任务下比较。
依据与验证：E5 等验证计划
1. Generated Code Sandbox
Agent 生成代码后，不必默认落到 shell/native/python 全权限环境。Wasm 可以用 import surface 精确描述能力，让生成程序只能调用被注入的 Host resources。
2. Typed Tool Program
WIT interface 比“函数名 + JSON schema”更接近可编译 ABI：资源、stream、future、result、record 都是强类型。Agent 可生成组件，再由 host 在装载时完成类型/能力检查。
3. Program Memory / Fast Path
Agent 经常把反复成功的动作固化成程序。Wasm 的小体积、AOT/JIT、版本化二进制和 deterministic profile 适合承载这种“动作记忆”，尤其是高频、重复、无需每次 reasoning 的路径。
4. Multi-language Skill Ecosystem
Component Model 的目标不是所有 Skill 都用同一种语言，而是让 Rust/C/Go/Python/JS/GC language 在统一 typed boundary 下组合。未来 Skill/Plugin 市场更可能按 WIT contract 而不是源码语言组织。
5. Interposition & Policy
组件 imports/exports 是天然切点，可以插入 tracing、quota、auth、policy、record/replay 组件，而不必修改业务二进制；这对 Agent 动态加载不可信第三方能力尤其重要。
6. 不是万能安全层
Wasm 只能限制“通过 Host imports 暴露的能力”；Host API 设计错误、资源泄漏、side-channel、DoS、runtime 漏洞仍存在。Wasmtime 49.0.1 的多项安全/资源修复正说明生产沙箱需要持续 hardening。
LRI 判断：未来 Agent Runtime 的关键分层可能是：LLM/Planner → typed component contract → Wasm fast path → capability Host API → OS/设备/服务。Wasm 的优势不在于替代所有容器，而在于承载数量巨大、生命周期短、权限窄、由 Agent 动态生成/组合的程序单元。
图 6 · Wasm 在 Agent 运行时中处于哪一层？
LRI 架构推演
读图结论：Wasm 被放在程序执行边界，不替代规划、长期记忆、宿主授权或设备安全。
展开文字读图与边界说明
阅读顺序：自上向下区分语义智能、程序记忆、Wasm 执行边界、Host 能力和真实副作用层。
边界判断：Wasm 最可能承担的是 Program Execution Boundary，而不是 Planner、长期记忆、全部 capability authority 或真实设备安全本身。系统安全来自 Agent policy、Program Memory、Wasm runtime、Host API、OS/设备五层共同设计。
本图不证明：五层划分是本专题的分析框架，不是官方唯一架构；沙箱不能独自提供整栈安全。
图 7 · 不同执行方式的权限边界怎样比较？
待验证比较
读图结论：比较重点是权限如何授予、执行如何约束，不是按语言名称判定哪种方式天然安全。
展开文字读图与边界说明
阅读顺序：先对比环境可触达能力与显式导入，再查看启动、内存、回放和可观测性等实验维度。
这不是“Wasm 一定更快”的宣传图，而是 E5 实验的治理假设：真正要对比 Shell、Python、Native、Core Wasm、Wasm Component 的 permission surface、启动、RSS、deterministic replay、artifact size、throughput 与 observability。
本图不证明：这是比较框架，不是性能排名；没有证明 Wasm 在所有任务中更快或绝对安全。
十、现实阻力：Component Model 仍不是“已经完成的下一代 POSIX”
当前最值得警惕的不是标准功能缺失，而是实现复杂度、性能和生态一致性。
ABI 仍在重构
1.0 路线明确要从 cabi_realloc eager ABI 迁到 lazy ABI，说明当前 Component Model 并非最终形态；长期兼容靠 adapter 维持，而不是“二进制格式已经永久冻结”。
语言支持节奏不一致
spec → wasm-tools → runtime → wit-bindgen → LLVM/Rust/CPython/Go 等有多个 release cadence。标准已发布不等于所有语言马上得到稳定支持。
浏览器原生尚未落地
jco 可以运行 component，但 native browser Component Model 仍在评估/推动阶段。真正统一 Web + Server 仍有工程与治理门槛。
异步/线程提高了实现复杂度
从 shared-nothing module 到 async task/stream/thread，runtime 的 scheduling、resource lifecycle、cancellation、fuel、debug 复杂度快速上升。
生态会分叉
Wasmtime/Component Model、WAMR/embedded、browser engines、WasmEdge 等可能选择不同 feature floor。可移植性必须由明确 profile/feature contract 管理，而不是假设“Wasm 都一样”。
能力安全不等于自动安全
组件边界能缩小权限，但 host capability 设计、供应链签名、OCI artifact provenance、资源限制和 runtime advisories 同样必须进入生产治理。
十一、LRI 验证计划：下一步应测“组件系统收益”，而不是再做 Core microbenchmark
重点验证 2026 新能力对真实系统是否产生可量化收益。
| 实验 | 问题 | 指标 | 价值 |
|---|---|---|---|
| E1 · Core vs Component Sync | Component boundary 的同步开销到底多少？ | ns/call、P50/P99、alloc/copy count、CPU | 验证 1.0 “zero-overhead sync” 是否是关键瓶颈 |
| E2 · P2 vs P3 Async Chain | A→B→Host 的 stream/future 是否显著简化并改善 async composition？ | 代码量、wakeups、latency、throughput、RSS | 量化 WASI 0.3 的系统价值 |
| E3 · Lazy ABI / Splicing | 复杂值和大 stream 能否真正减少 copy？ | bytes copied、host round trips、bandwidth、CPU | 验证 Component Model 1.0 性能主线 |
| E4 · GC Language | Java/Kotlin/Scala/Dart/OCaml 等 Wasm GC 路线相比自带 GC runtime 如何？ | binary size、startup、RSS、GC pause、throughput | 判断 Wasm 是否真正扩大语言边界 |
| E5 · Agent-generated Component | Agent 生成 Wasm component 与 Python/shell fast path 谁更可治理？ | 权限 surface、启动、RSS、审计、可重放、故障隔离 | 验证 Agent Runtime 新机会 |
| E6 · Record/Replay | WIT-level trace 能否稳定复现跨组件故障？ | trace size、replay fidelity、debug time | 验证 Component Model 独特可观测性 |
| E7 · Runtime Matrix | Wasmtime/WAMR/WasmEdge/browser 的 feature floor 实际差多少？ | proposal compatibility、startup、AOT、memory、component support | 防止“标准已完成=所有 runtime 一致”的误判 |
十二、未来 3 年判断：哪些方向最可能形成长期价值？
不是预测发布日期，而是按技术因果关系给出演进优先级。
高确定性
Component ABI 降开销
lazy ABI、stream splicing、sync fast path 直接回应当前生产痛点，且已进入明确 1.0 路线。
高确定性
WASI 0.3 连续发布
0.3.1 已建立双月 release train，未来 0.3.x 将持续吸收成熟 Component features。
中高确定性
Cooperative Threads
toolchain/runtimes 已有较深实现基础，短期落地概率明显高于 shared-everything threads。
中等确定性
Browser Native Component
是 1.0 必要条件且浏览器团队已在评估，但投入规模和时间仍不确定。
中等确定性
OCI Component Supply Chain
标准流程开始要求发布 artifact，wkg/wac 等工具已形成方向；能否形成统一“Wasm package ecosystem”取决于 discovery/signing/metadata。
探索性
Agent-program Runtime
技术属性高度匹配，但尚缺行业统一范式。应通过真实 Agent-generated code workloads 验证，而不是从沙箱特性直接外推。
长期
Shared-Everything Components
可能提升共享 runtime/heap 的语言互操作效率，但会削弱 shared-nothing 的简单隔离模型，需要更复杂安全和生命周期语义。
长期
Runtime Instantiation
组件在运行时创建组件，将打开 lazy loading、子任务、动态插件与 per-component lifetime；同时也把动态系统复杂度带进 Component Model。
十三、主要证据来源
优先使用 WebAssembly/WASI 官方仓库、Bytecode Alliance 与 Wasmtime release；趋势部分明确区分已发布与 roadmap。
Primary · WebAssembly
Wasm 3.0 Completed
Core 3.0 正式能力：memory64、multi-memory、GC、typed refs、tail calls、EH、relaxed SIMD、deterministic profile。
Primary · WASIWASI 0.3.0 / 0.3.1 Releases
2026-06 native async；2026-08 map、implements annotations 与双月 release train。
Primary · Bytecode AllianceWASI 0.3 Launched
future/stream/async 与 Component Model native async 的动机和架构变化。
Primary · RoadmapThe Road to Component Model 1.0
lazy ABI、zero-copy、浏览器、C ABI、record/replay、cooperative threads、WIT expressivity。
Primary · RuntimeGC and Exceptions in Wasmtime 47
Wasm 3.0 高层语言能力在主流 standalone runtime 默认启用。
Primary · ReleaseWasmtime 49.0.1
2026-09-24 最新维护版及 fuel、HTTP body memory exhaustion、WASI filesystem 等生产修复。
Primary · StandardsActive WebAssembly Proposals
Threads、Stack Switching、Wide Arithmetic、Custom Page Sizes、Shared-Everything Threads 等当前 phase。
Primary · Component ModelComponent Model Specification
0.2/0.3/0.3.1 feature baseline，以及后续 cooperative threads 等 gated feature。
证据边界：Core 3.0、WASI 0.3/0.3.1、Wasmtime 47/49 属已发布事实；lazy ABI、cooperative threads、native browser Component Model、runtime instantiation 等属于明确 roadmap/进行中工作；“Agent-program Runtime”是 LRI 基于能力组合给出的研究假设。