旅程始于一个 Imagine If。

Follow the notes upon the journey. At first sight marks one’s destiny. Return lies within the hasty keys.

几个月前，我穿梭在若干家客户现场，讲我们新的 New Agent Design in Workflow。

每到现场，总有人问：为什么不试试 OpenClaw？这和 Hermes Agent 有什么区别？

这并不是我第一次感觉到 get lost。

后来我意识到，困惑并不来自某一个工具本身，而是来自我们还没有说清楚一条边界：什么时候 Agent Work 只是一次交付，什么时候它应该成为生产系统的一部分。

对于许多消费级场景，提前构建“组件库”的门槛太高了。

一个一次性需求，一个三个月后未必会再次出现的问题，直接用 Claude Code 或 Codex 做掉就好。没有必要先抽象，也没有必要先搭一个应用，再去解决本来可以直接交付的结果。

有时我甚至会劝客户把问题放轻一点。

“这个问题不需要弄这么复杂。Claude Code 可以解决。如果它反复出现，再写一个 skill，可能就是最小投入。”

这仍然是我相信的判断。

但另一件事也慢慢变得明显：无数 Personal PC 上，开始长出很多碎片化的 Agent 解决方案。

它们像实验，也像作品。它们依赖本地环境、Session History、上下文、文件副本、MCP 工具和 skill。

我可以在我的 computer 上完成这个 task。只要你拥有相同环境，你就可以复现我的“实验”。

可是，如果软件或者 Agent 的交付物只能这样被转移，那它到底是什么？是快消品吗？是一段偶然成立的现场表演吗？

这就是这段心路里真正重要的拐点。

我们并不是想把所有 Agent Work 都平台化。恰恰相反，我们想承认那条阈值线。

在图像里，灰度值描述一个像素的明暗程度。通常 0 是纯黑，255 是纯白。

在 Agent App 里，也存在类似的阈值。

阈值以下，是一次性应用，是 skill，是一次本地交付，是“别把它弄复杂”的地方。

阈值以上，是构建、评估、部署、A/B 测试，是从生产环境生成评估结果，是需要覆盖完整生命周期的地方。

走到这里以后，工具突然变得分散。

开发者必须把多个点解决方案拼在一起：Sandbox、Eval Harness、部署脚本、日志、权限、上下文、UI，以及一堆由 Prompt 字符串组成的函数。

此时，你并不是在用 Codex 或 Claude Code 解决自己的问题。

你是在用它们为客户构建一个生产方案。

你会浸泡在各种 harness 和依赖里，不断循环。你会打开多个终端、多个 worktree，或者一个新的 ADE，试着让工作往前走。

这时我开始反复问自己：为什么这里不能有一个框架无关的 “Supabase”？

不是为了替代开发者，而是为了把重复的 Agent Runtime 托管、部署、隔离和评估从每一个项目里释放出来。

云计算时代之前，做软件像“自己买地、盖房、养物业”。

你要买物理服务器、交换机、存储，把它们放进机房或 IDC，然后才能谈应用。

Agent App 开发也会经历类似的旅程。

过去，我们把 Token 封装成 LLM API Call，把它当成最小的计算资源。

现在，我们正在把 Token 重新封装成对一个 Cloud Agent 的一次请求。

长期来看，本地 Hermes 或 OpenClaw 代表的消费级需求，会继续存在；但更复杂的生产需求，会走向 Cloud Agent in a Sandbox。

它需要更高并发，更长运行时间，更强隔离性，也需要后台任务能够被创建、暂停、恢复、评估和部署。

我们正在把云里的“机器资源”，重新抽象成开发者可以直接调用的 Cloud Agent Session Lifecycle API。

这就是我们在做的事情。

不是又一个 Agent Demo。

不是又一个 Prompt Wrapper。

而是一种判断：当 Agent Work 真的跨过那条阈值，它应该像云资源一样被托管，被隔离，被观测，被复用。

We call it mosoo.

第一件已经发生的事，是我们把 mosoo Agent Driver 开源了。

它是 mosoo 的第一块开源工作：一个 driver 层，用来把 OpenClaw、Hermes Agent、Claude Code 和 Codex 统一到兼容的 Agent Session API 之下。