「Why MoonBit」 是 MoonBit 推出的应用案例栏目，聚焦真实开发者、团队和项目在实际场景中使用 MoonBit 的经验与实践。

在这里，我们希望记录的不只是“MoonBit 能做什么”，更是开发者为什么选择 MoonBit：他们遇到了怎样的工程问题，为什么需要更轻量、更高效、更可靠的技术方案，以及 MoonBit 如何在真实项目中发挥价值。

从 AI Agent、WebAssembly、开发工具，到高性能计算、编译器、基础软件与应用开发，我们将持续分享 MoonBit 在不同场景中的落地案例，呈现新一代编程语言如何走向真实产品与开发者生态。

OceanBase 是一款原生分布式关系型数据库，最早由蚂蚁集团自主研发，主要面向金融、电商、政务、互联网等对高并发、高可用和数据一致性要求较高的场景。它采用分布式架构，支持 ACID 事务、弹性扩展、自动容灾和多云部署。

近年来，OceanBase 也在向统一数据基础设施演进，官方将其定位为面向 AI 时代的统一分布式数据库，覆盖事务处理、实时分析和 AI Native Search 等工作负载。

过去一段时间，我们在 seekdb 和 PowerMem 里持续关注一个问题：AI Agent 如何拥有真正可用的长期记忆。

一个 Agent 如果每次对话都从零开始，就很难长期工作。它需要记住用户偏好、项目背景、历史决策、工具使用经验，也需要知道过去哪些方案成功过，哪些方案失败过。

早期的 Agent Memory 往往比较简单：本地文件、Markdown 日志、workspace 目录，或者直接依赖当前上下文窗口。

这种方式适合实验，但只要 Agent 被持续使用，问题很快就会出现：换设备后 Memory 怎么同步？换 workspace 后历史经验怎么带走？多个 Agent 协作时，团队经验怎么共享？用户私有 Memory、项目 Memory、团队 Memory 又该怎么隔离？

更重要的是，Memory 不是把所有历史都存下来就够了。

如果 Agent 只是把对话、日志、任务记录不断堆起来，它并不会自动变聪明。很多时候，问题反而会变成：记忆很多，但真正需要的时候找不到关键内容。

所以，Agent Memory 的难点不只是“存下来”，而是要能被持续整理、精准检索和安全复用。

这也是 seekdb 和 PowerMem 关注的方向。

seekdb 更偏向 Memory 背后的数据与检索底座。它希望让结构化数据、全文检索、向量检索等能力协同起来，让 Agent 根据当前任务召回真正相关的内容，而不是把大量历史信息重新塞回上下文。

PowerMem 则更像是面向 Agent 的 Memory Management Layer。它关注的不只是存储，而是 Memory 的完整生命周期：哪些信息应该被抽取出来，哪些应该长期保留，哪些已经过时，哪些需要合并，哪些值得在未来任务里继续复用。

比如用户偏好、项目决策、Bug 排查经验、团队工作流、工具使用方式，这些都不应该只停留在一次对话里。它们应该从临时上下文中沉淀出来，变成 Agent 之后还能继续使用的长期 Memory。

在更大规模、更高可靠性的生产环境中，OceanBase 也可以为长期 Memory 提供更强的数据承载能力。

简单说，seekdb、PowerMem 和 OceanBase 解决的是 Agent Memory 的数据底座、检索能力和生命周期管理问题。

但当 Memory 真的进入 Agent Runtime 之后，新的问题也会出现。

Memory 服务化之后，Skill 成了新的边界

在 OpenClaw 这样的 Agent Runtime 里，Agent 不只是和用户对话，它还会加载 Skills、调用工具、执行任务。

这时，Memory 不再只是 Agent 自己内部使用的一份历史记录。越来越多第三方 Skill 也可能想要访问 Memory。

有的 Skill 需要读取项目历史，有的 Skill 需要总结用户偏好，有的 Skill 需要把任务中的新经验写回 Memory，还有的 Skill 会结合 Memory 调用外部工具。

这就带来了一个很现实的问题：

第三方 Skill 到底能不能读用户级 Memory？能不能写 workspace Memory？能不能访问团队共享 Memory？能不能直接拿到数据库地址、API key 或 Memory 服务的连接信息？

如果这些问题没有清晰答案，Memory 服务化之后，反而会把新的风险暴露出来。

因为长期 Memory 里可能包含用户偏好、项目历史、团队决策、业务上下文，也可能包含代码片段、配置、错误日志和执行经验。这些信息一旦沉淀为长期资产，就不能被任何 Skill 随意读取和修改。

所以，从 Agent 基础设施的角度看，问题不只是：

Memory 如何存储和检索？

还包括：

访问 Memory 的第三方 Skill，应该如何被安全分发、安全执行和安全授权？

问题不在于谁能调用 API

从技术上说，调用 Memory API 并不难。

JavaScript 可以，Python 可以，Go 可以，Rust 可以，MoonBit 也可以。

真正的问题不是哪门语言能发 HTTP 请求，而是：当第三方 Skill 都可以访问 Memory 时，Runtime 如何管理它们的权限边界。

如果一个 Skill 直接拿到 PowerMem 的 API key，直接连接 Memory 服务，它的能力边界就会很难控制。

它可能查询不该查询的 Memory，可能写入不该写入的内容，可能把 Memory 结果发到外部网络，也可能绕过 Runtime 的审计，在用户不清楚的情况下访问更大的范围。

更合理的方式，是不让 Skill 直接连接 Memory 服务，而是让 Skill 通过 Runtime 请求受控能力。

比如，memory.search 用于检索授权范围内的 Memory，memory.add 用于写入新的 Memory，memory.update 用于更新已有 Memory，tool.call 用于调用白名单里的外部工具，log.emit 用于输出受控日志。

在这个模型里，Skill 不直接知道 PowerMem、seekdb 或 OceanBase 的连接信息，也不直接持有 API key。它只知道自己被授予了哪些能力。

真正的访问动作，由 Runtime 代理完成。

Runtime 负责检查当前用户、Agent、workspace、scope 和 Skill 权限，判断这次调用是否允许。必要时，Runtime 还可以对返回结果做裁剪、脱敏或拒绝，并记录审计日志。

这样，Memory 就不再是第三方 Skill 可以任意读写的全局资源，而是 Runtime 明确授予的一组受控能力。

这就是从 Memory API 到 Memory Capability 的变化。

API 更像是一个接口。

Capability 更像是一种被明确授予、可以限制范围、可以审计、也可以撤销的能力。

为什么我们开始关注 MoonBit + Wasm

这里先简单介绍一下 MoonBit。

MoonBit 是一门面向现代软件开发的新一代编程语言，强调静态类型、工程化体验和多后端编译能力。它可以编译到 WebAssembly，也适合把一段能力逻辑封装成轻量、清晰、可分发的模块。

对 Agent Skill 来说，我们关注 MoonBit 的重点，不是“又多了一门能写代码的语言”，而是它能不能帮助 Skill 变得更容易管理。

一个第三方 Skill 不应该只是随手写出来的一段脚本。它以后可能会被分发、安装、审核，也可能申请访问 Memory、工具、文件系统或外部服务。这样的 Skill 需要说清楚：自己接收什么输入，返回什么结果，可能产生什么错误，需要哪些权限，访问的是哪一类 Memory。

这些边界如果只靠动态 JSON、prompt 约定或者开发者自觉来维护，短期能跑，长期会很难治理。MoonBit 的静态类型和编译能力，可以让这些边界在开发阶段就更清楚。

而当 MoonBit 编译到 Wasm 后，Skill 就可以以更轻量、更容易沙箱化的方式交给 Runtime 执行。Skill 本身不直接拿 API key，也不直接连接 PowerMem、seekdb 或 OceanBase。它需要访问 Memory 时，仍然要通过 Runtime 暴露的 Capability。

也就是说，MoonBit 负责让 Skill 更清楚、更工程化；Wasm 提供更适合沙箱执行的模块形态；Runtime 负责真正的授权、审计和能力边界。

现在很多 Agent Skill 会用 JavaScript 或 Python 编写。它们生态成熟，开发效率高，也很适合快速验证想法。

但如果要构建一个更开放的第三方 Skill 生态，脚本语言会带来一些治理成本：运行环境要安装，版本可能不一致，依赖链可能很长，供应链风险也更难评估。

另一类选择是 Native Binary。Go、Rust、Zig、C/C++ 都可以编译出本机可执行文件。它们部署清爽，很适合构建高信任的基础设施组件，比如 Runtime、CLI、daemon、插件管理器或 API gateway。

但如果第三方 Skill 也都以 Native Binary 的形式分发，它默认更接近普通本机程序，可能访问文件系统、网络、环境变量、子进程，也可能直接连接数据库或外部服务。

这会带来更高的审计和信任成本。

所以我们需要一种介于脚本语言和 Native Binary 之间的方式：

分发要足够轻，运行边界要足够清楚，默认权限要足够小，外部能力要能由 Runtime 显式授予。

这也是 MoonBit + Wasm 进入我们视野的原因。

Wasm，也就是 WebAssembly，最早常被理解为浏览器里的高性能执行格式。但今天，Wasm 已经越来越多地被用于服务端、边缘计算和插件系统。

它真正适合 Agent Skill 的地方，不是“运行在 Web 里”，而是可以把代码放进一个更清晰的沙箱执行环境中。

在没有 Host 显式授予能力的情况下，Wasm module 不能天然访问宿主文件系统、网络、环境变量或子进程。它能做什么，取决于 Runtime 暴露了哪些接口。

这正好适合第三方 Skill。

平台不需要直接运行一个拥有完整本机权限的程序，而是加载一个沙箱中的 module。Skill 接收输入，执行计算，返回结果。如果它需要访问 Memory、工具或外部服务，就必须通过 Runtime 显式开放的 Capability。

当然，MoonBit + Wasm 并不是单独解决所有安全问题。

真正的权限检查、审计、脱敏、撤销，仍然要由 Runtime 完成。Wasm 提供的是更适合沙箱执行的模块形态，MoonBit 提供的是更清晰的工程表达和类型边界。

两者结合起来，才让第三方 Skill 更容易被纳入 Runtime 的 Capability 管理。

从 Memory 到 Skill，问题自然走到了这里

回到最初的问题：Agent Memory 如何真正长期可用？

第一步，是让 Memory 不再困在当前上下文或本地文件里，而是可以持久化、检索、迁移和复用。

这对应 seekdb、PowerMem 和 OceanBase 正在解决的问题。

但当 Memory 进入 OpenClaw 这样的 Agent Runtime，并开始被第三方 Skill 使用时，问题就进入了下一层：

• 谁可以访问 Memory？

• 访问什么范围？

• 能不能写入？

• 能不能把结果带出去？

• 出了问题能不能审计？

这时，Memory 就不能只是一个可以随便调用的 API，而应该变成 Runtime 明确授权的 Capability。

在这个模型中，seekdb 负责底层检索能力，PowerMem 负责 Memory 的抽取、管理、更新和复用，OceanBase 可以提供生产级的数据承载，而 MoonBit + Wasm 则让访问 Memory 的第三方 Skill 更容易被封装成边界清晰、可分发、可沙箱执行的能力单元。

这不是把 seekdb 和 MoonBit 硬放在一起。

而是当 Agent Memory 真正进入 Runtime 场景之后，Skill 的安全执行自然会成为下一层问题。

MoonBit + Wasm 正是在这个问题上的一条重要技术路径。