在刚刚过去的周五直播里，WAO（Wizard AO）的故事，第一次被系统地摊开在中文社区面前。镜头前，一边是 WeaveDB 与 WAO 的作者 Tomoya Nagasawa，一个写了 30 年代码、在链上折腾数据库多年、最后选择站在 Arweave 一侧的工程师；另一边，是刚刚完成 WAO 资产收购的 Arweave Oasis 创始人 Gerry，希望把这套原本为「自用」而生的工具，变成整个 AO 生态的默认开发入口。
这篇文章，试图在直播之外，用文字把这套故事讲完整：Tomo 为什么从以太坊、ICP 一路走到 Arweave？WAO 想解决的到底是什么问题？HTTP 签名和 HBSign 库在 HyperBEAM 里有多关键？以及，为什么是 Arweave Oasis 来接手这套工具，未来一年我们又准备怎么一起把它推到台前。
从以太坊到 Arweave：一个工程师被「逼」出来的选择
如果只看履历，Tomo 身上有几个关键标签：写代码近 30 年、WeaveDB 创始人、2022 年起深度参与 Arweave 生态建设。直播里，他重新讲了一遍自己「换公链」的过程，这不是一段简单的「叛逃史」，更像是一个工程师被现实一步步逼着做技术选择的过程。
最开始，他在以太坊生态尝试做去中心化数据库。那是一段典型的「理想很丰满，Gas 很骨感」的时期：在 Solidity 上堆任何类似数据库的系统，都会直接撞上成本和扩展性的天花板。为了寻找更适合的环境，他转向 ICP，一个对外宣称「为 Web 而生、极易扩展」的链上计算平台。然而，很快又遇到了 canister 4GB 内存限制的问题：对一个真正意义上的大规模数据库来说，这个上限依旧远远不够。
直到他看到 Arweave 的永久存储共识化 —— 把永久存储直接作为安全共识基础，再在它之上叠加 AO / HyperBEAM 这类计算层。数据永存、计算横向扩展、链上证明与链下扩展之间可以通过零知识证明打通，这套组合在他看来，是第一次让「做一个真正的去中心化数据库」变得合理而且可行。一端是 Arweave 提供的永久存储和安全共识，另一端是 AO 提供的分布式计算和可组合的 Device / Process 模型，中间再用 ZK 让以太坊、Solana 等其他公链也能可信地读取这些数据——在 Tomo 的视角里，这是一条完全不同的技术路线。
他说自己不是一个「喜欢讲故事的人」，很多选择都是被工程现实逼出来的。当一个做数据库的人，走遍几条主流公链之后发现「永久存储 + 计算层」才是合理的架构，他自然会把时间和精力押在这里。这也是他最终决定在 Arweave / AO 这条路上扎根的原因。
WAO：把「很酷的终端」变成「真正能做产品的地基」
AO 刚上线时，官方给开发者的第一个入口，是一块非常酷的终端体验：打开 Cookbook，连上 testnet 或 mainnet，通过终端直接 spawn AO 进程、发送消息、观察状态变化。对初次接触的人来说，这无疑是一种很好的「体验式 onboarding」方式——你能非常直观地感受到 AO 的并发、消息驱动和调度机制。
但对于真正要做复杂产品的团队来说，仅仅有终端体验远远不够。当你需要写大量集成测试、构建复杂系统、验证边界条件时，开发方式必须从直接连 testnet/mainnet 切换到有完善本地环境的工程化开发。Tomo 在直播中点破了一个很多人都有过的隐性痛点：AO 长期缺乏一个可用、可靠、标准化的本地开发环境。
在 WeaveDB 的开发过程中，他亲身踩过坑：团队曾经把集成测试指向远程 AO 网络，每跑一次测试要三分钟，一天跑一百次就是 300 分钟。甚至网络状态、节点负载等外部因素也会带来不可控的不稳定性。很长一段时间，对于想认真在 AO 上做产品的人来说，「测试」这件事本身就成了一种成本极高的折磨。
WAO 就是在这种背景下诞生的。起初，它只是 WeaveDB 的一个自用工具，目标非常简单：把 AO 的 compute / messenger / scheduler 单元完整地在内存中仿真出来，构建一个不依赖远端网络、本地可控的测试环境。所有进程、消息、状态都在内存里完成，不写磁盘、不发网络请求，从根到枝为测试「减重」。
效果是立竿见影的。同样一套集成测试，从三分钟缩到了大约一秒，测试提速约一千倍。对 WeaveDB 这种测试量级极大的系统来说，这不仅意味着节省了大量开发时间，更重要的是让团队敢于增加测试覆盖率、频繁重构和迭代。随着项目推进，WAO 的功能边界也在逐渐清晰：它不再只是 WeaveDB 的「私人物品」，而是天然具备了做 AO 版 Hardhat / Foundry 的潜质。
在以太坊世界，Hardhat 和 Foundry 已经成为事实标准，几乎每一个严肃项目都会选择其中之一作为测试和开发框架。Tomo 的设想很直接：在 AO 生态中，WAO 要承担同样的角色，它是一个包含内存仿真、签名处理、工具链集成的完整开发基础设施，未来应该成为大多数 AO 项目默认采用的地基。
今天的 WAO，在 AOS 进程的测试与模拟上，已经经过 WeaveDB 以及数个核心团队的长期实战打磨，成熟度很高。相对粗糙的部分，反而是 HyperBEAM 的最新集成：当前版本仍然停留在 6 月份，对 10 月发布的 Milestone 3 中新增的几十个 Device 和大量更新，还需要一个系统升级周期。这也是接下来 WAO 技术路线中的优先工作之一。
浏览器里的 AO 操作系统：零安装的 Playground 与联机实验室
如果说本地内存仿真解决的是工程效率问题，那么 Tomo 在直播中分享的另一个方向，则更像是一份面向新开发者的邀请函，把 AO 单元塞进浏览器，做一个真正意义上的在线 AO 操作系统。
在这条线上，他做了几件极具想象力的事情：首先，把 AO 的单元实现编译为 WebAssembly，让它们可以直接在浏览器中运行。由于浏览器环境对资源使用有严格限制，他又做了多层压缩与内存布局优化，使得浏览器可以在合理资源占用下同时跑上百个进程。其次，在浏览器端内置了一个简化版 IDE：一侧是 AOS 终端，开发者可以直接在其中 spawn 进程、发送消息、观察状态；另一侧是代码编辑区与 Explorer，可以跟踪消息流转、查看进程状态变化。
更进一步，Tomo还实现了本地 VS Code 与浏览器 IDE 的双向同步：开发者依然可以在自己最熟悉的 VS Code 里写代码，而浏览器端则作为实时的调试和可视化界面，两者通过同步机制保持一致。这种「本地编辑 + 浏览器跑 AO + 实时可视化」的组合，大大降低了上手门槛，也降低了团队协作成本。
最具突破性的一点，是他选择用 WebRTC 来构建浏览器之间的通信网络。与传统的 WebSocket 不同，WebRTC 支持浏览器与浏览器之间的点对点连接，不需要依赖中心化的中转服务器。Tomo 利用这点，把每一个打开 WAO 浏览器 IDE 的用户，都视作一个轻量级 AO 单元节点：每个人的浏览器里都有一套 AO 单元，可以直接和其他人的浏览器通信，从而自然地拼成一个小型的 P2P Mesh Network。
这带来的直接结果，是联机调试变得异常简单：团队成员只需各自打开浏览器，就可以在一个去中心化的小网络里共同测试一个复杂的 AO 系统，而不必搭建专门的远程测试环境。对想要一边学习、一边协作探索的新开发者来说，这几乎就是一个现成的AO 新手村 + 高级副本大门。
Tomo 也坦承，这一整套浏览器端功能目前仍处于「实验性阶段」，并且基于旧版 AOS，未来需要与 HyperBEAM 的演进一同重构。但从方向上看，它已经非常清晰地给 WAO 定义了一个重要角色：既是新手的 Playground，也是高级开发者的联机实验室。
HBSig 与 HTTP 签名：打通外部世界与 HyperBEAM 的那一层「翻译官」
在 HyperBEAM 这条线，Tomo 花了很多时间讲一块不那么酷炫、却极为关键的基础能力：HTTP 消息签名与 HBSig 库。HyperBEAM 的设计理念之一，是尽可能与现有 Web 标准兼容，比如采用「HTTP Message Signatures」作为请求的签名方式，这意味着理论上任何符合标准的库，都可以直接与 HyperBEAM 对话。
然而，工程实现远没有概念那么简单。HTTP 头部本身有天然限制：只能存放字符串，不支持嵌套对象，复杂的结构化数据必须先经过编码、拆解与平铺；而 HyperBEAM 需要签名和验证的，却往往是包含业务数据、元信息、上下文的复杂对象。如何在严格受限的 HTTP 头部与复杂的内部数据结构之间搭建一个稳定可依赖的桥梁，是整个系统能否被外部世界优雅接入的关键。
为了解决这个问题，Tomo 花了大约 300 个小时，在大语言模型的辅助下，设计并实现了一套完整的签名方案和工具库 —— HBSig。它通过三层不同的编码方式，分别处理结构化信息、顺序与规范化，以及字符串化问题，然后再将这些编码结果组合进 HTTP 消息头进行签名。最终，任何外部系统只要使用 HBC，就可以：
- 将任意复杂对象以一致的方式编码；
- 在 HTTP 消息中附带正确的签名；
- 让 HyperBEAM 端稳定地验证并处理这些请求。
换句话说，HBSig 是外部世界与 HyperBEAM 之间的安全翻译官。没有这样的抽象层，DePIN 设备、传统后端服务、企业内部系统等，很难以一种既安全又可维护的方式接入 AO 网络；有了它，HyperBEAM 才真正具备了作为网络操作系统去驱动外部资源的能力。
更重要的是，这套签名能力目前是伴随 WAO 一起提供的，它不仅是测试与本地仿真的一部分，也是未来构建复杂分布式系统时的基础组件之一。在 Tomo 看来，这正是 WAO 能为整个 AO 生态填补的高级缺失：它不只是一个写 Lua 脚本的地方，更是一个可以帮助开发者把 AO 和现实世界真正连在一起的平台。
为什么是 Arweave Oasis：当工具遇上一个想做开发者社区的团队
在这次资产收购背后，还有一个不太技术、但很关键的问题：为什么是 Arweave Oasis 来接手 WAO？Tomo 在直播里说得很直接：他可以把 WAO 打磨得很扎实，但他不是那个负责「做大一个地区开发者生态」的人。要把 WAO 变成一块真正的生态基建，不仅要写代码，还要：
- 用开发者听得懂的方式，系统化输出文档、教程和 Cookbook；
- 长期组织线上 / 线下活动，维护一个有温度的开发者社区；
- 在不同语言和文化环境下，持续做本地化沟通与支持。
这些工作，需要的是另一个方向的能力与耐心。对于熟悉 Arweave 生态的人来说，Tomo 眼中的 Arweave Oasis，大概有这样几个角色：一方面是内容与信息的中枢，每天把 Arweave / AO 生态最新的项目进展、技术更新、社区活动，用中文整理给更大范围的开发者和用户；另一方面，是在过去两年里持续推动线上训练营、HyperBuilders Hackhouse、技术直播和各种活动的组织者，在东亚尤其是中文世界，搭起 Arweave / AO 这条技术路线和本地开发者之间的桥梁。
从我们的角度看，过去两年最痛苦的一件事，就是长期缺少一条从 0 到 1 的清晰路径。很多人对 AO / HyperBEAM 感兴趣，也愿意花时间学习，但进来之后很快会遇到几个问题：文档碎片化、本地环境不清晰、缺乏可复用的最佳实践，一旦踩坑过多，就很容易看了一圈，最后还是离开。我们一直在寻找一套工具，能够把这条路径铺出来，而 WAO 正好填上了这块缺失的拼图。
从本地 WAO 测试框架，到浏览器端 Playground，再到 HBSig 等高级工具，WAO 提供的其实是一套横跨新手体验与高级集成的能力组合。把这套能力交给一个愿意长期做开发者社区和本地支持的团队，本身就是一种很自然的分工：Tomo 继续用工程师的方式把工具打磨到极致，我们则用社区和内容的方式，把这些工具放在正确的位置，让更多人真正用起来。
未来一年：把 WAO 做成 AO 生态的「默认选项」
在直播的最后，Gerry 和 Tomo 分别给未来一年划了两条简单却清晰的路线。从技术侧看，Tomo 希望：
- 让 WAO 成为 AO 生态里的「标配测试与开发框架」，就像 Hardhat / Foundry 之于以太坊；
- 在 HyperBEAM 的高级玩法上，产出系统化教程：如何构建自定义 Device、如何利用 HBC 与外部系统交互、如何用 AO 做真正复杂的分布式系统；
- 把目前还主要依赖口碑的 WAO，打磨成一个被更大范围开发者自发采用的工具。
从社区与生态侧看，我们的目标也很明确：
- 把 WAO 打造成 AO 开发者的第一站：新人可以从浏览器 Playground 和入门文档开始，进阶开发者则通过本地 WAO 和 HBSig 工具链，走向更复杂的架构；
- 用中文、英文，未来甚至加入日文，把东亚范围内有潜力的工程师尽可能拉进 AO / HyperBEAM 这条技术路线里；
- 通过线上直播、线下活动、黑客松和长期内容输出，让 WAO 不只是「一个工具仓库」，而是一块承载开发者文化和最佳实践的公共基础设施。
彩蛋
Tomo 在直播的最后，还给自己加了一道看上去挺硬核的任务：他说会用一年的时间把中文学到可工作交流的程度，下次再来 Arweave Oasis Show，希望不再需要依赖 AI 翻译，能直接用中文和社区聊 WAO 和 AO。
这件事本身，某种程度上也象征着一个很现实的变化：从以太坊、ICP 到 Arweave，再到今天和一个中文主导的社区团队深度绑定，这条路线越来越像是一场跨文化、跨生态的长期合作，而不是一次短期的技术试验。