Agents 一月一换，Skills 每周更新，但人和组织真正在乎的目标、数据、知识结构是缓慢的。Agent 是多个的、在任何端口都会发起的，本地永远是它的障碍。所以我们把 Claude Code 本地文件的工作方式，搬到了云端——一个面向 Agent 的云端文本系统，今天进入内测。
Agents change monthly. Skills iterate weekly. But the goals, data, and knowledge structures that humans and teams actually care about move slowly. Agents are plural and launch from anywhere — “local” is always going to be a barrier. So we took Claude Code’s local file workflow and moved it to the cloud. Today huozi enters beta.
从今天起，活字（huozi.app）进入内测。这是给前面几篇文章里那些主张落地的一刻——为什么我们坚持文件系统而不是文档 API、为什么把 HTML 当一等公民、为什么把 Excel 拆成三层——所有这些设计的最终形态，是一台 面向 Agent 的云端文本机。
这篇文章想把项目的定位说清楚：我们到底在哪一层做事，以及为什么。
任何想给 Agent 时代造工具的人，最先要回答的是：这个东西放在哪一层时间尺度上？
过去一年我们看到的现实是：
把这三层画出来很快就清楚了：Agent 这一层注定不停换；Skills 这一层注定不停迭；只有数据和工作目标这一层，是用户真正想稳定下来的。
大多数 Agent 工具的尴尬，是把自己造在了上面两层。换一个 Agent，工具就废了；换一套 Skills，记忆就丢了。我们想做的事相反——活字活在最慢的那一层，让它比任何一个具体的 Agent、任何一套 Skills 都活得更久。
第二个观察更具体：现在没有人只用一个 Agent。
桌面上是 Claude Code 和 Cursor，手机上是 Claude App 和 ChatGPT，团队的 Slack 里挂着一个值班 Agent，CI 里跑着定时的研究 Agent，浏览器里是 Codex Web，还有同事自己用 SDK 写的小脚本。Agent 从一开始就是分布式的。
这件事意味着：把数据放在“某一台本地”立刻就成了一个障碍——你的笔记本不能一直开着，你也不可能让手机上的 Agent 通过 SSH 摸进笔记本去读你昨天写的草稿。团队层面更明显：协作的前提是有一个共同的桌面，本地文件给不了。
团队也是同一件事的另一面——再聪明的 Agent，也要有一张大家都能看到的桌子，才有协作可言。活字也是这张共享的 Playground：成员、Agent、定时任务，都对着同一棵文件树工作；每一次写入都进同一个提交图，谁改了什么、什么时候改的，都查得到。
第三个判断更具体——也是我们前几篇文章一直在铺垫的：
在 Agent 的世界里，Word、Excel、PowerPoint 都注定要被替换。不是被某家公司的"AI Word 2.0"替换，而是被 token-friendly 的纯文本格式替换：
这背后的判断是：三层应该被拆开——值（数据）归数据，计算（公式）归代码，呈现（DOM）归 HTML。Agent 不需要“假装是纸”的二进制格式，它需要三样直白的东西。前面那篇 Office for Agent 把这件事讲得更细。
但有一个老问题——人类访问、打开、随手编辑这些"裸格式"，仍然不容易。把一份 CSV 发给非技术同事，他打开就皱眉；让他改一段 HTML，他先要找编辑器。所以活字这边在做的另一半工作，是把这层“打开和编辑”的体验做得跟双击一个文档一样轻——
/p/<slug>。huozi_image_render 接受 SVG / Mermaid 源码，服务端渲成 PNG，落到内容寻址的 /__assets__/。Agent 写一段 <svg> 就有图。回到具体怎么做。我们最直接的设计决定，是不要再发明一套新的 Agent 文档 API。
Claude Code 已经定义了一套非常好的本地文件工作流——Read / Edit / Write / Glob / Grep，这些是 Agent 工程师方言里最稳定的几个动词。我们做的事，就是把这套语义原样搬到云端：
# Claude Code 本地：
Read(file_path: "notes/w17.md")
Edit(file_path: "data.csv", old_string: "...", new_string: "...")
Grep(pattern: "TODO")
# 活字云端，bit-exact 同款方言：
huozi_read({ file_path: "notes/w17.md" })
huozi_edit({ file_path: "data.csv", old_string: "...", new_string: "..." })
huozi_grep({ pattern: "TODO" })同样的 schema、同样的错误码、同样的行号分页、同样的 old_string → new_string 唯一性契约。任何会讲 Claude Code 方言的 Agent 挂上活字立刻能用，不需要一行 prompt 调整。MCP 设计原则那一篇把这件事的推理写得更细。
这套方言搬到云端的回报，是三个“任何”同时成立：
这就是我们说的 OpenClaw Gateways 思路：把 MCP 当一个统一的网关入口，把所有客户端、所有设备形态、所有时点的写入，汇到同一棵文件树上。
活字从一开始就有两个版本，对应两类完全不同的诉求。
两边的 MCP 协议、工具方言、文件语义是完全一样的——你今天在 Cloud 上写的东西，明天可以原样导到 Edge；反过来也成立。我们把方言（dialect）当合约，把部署当实现细节。
这就是这次内测要交付的东西：
如果你已经在用 Claude Code、Cursor、Claude Desktop——挂上活字，不用再换一套思路。如果你在团队里需要一张所有 Agent 共享的桌子——欢迎来内测。
文具盒一直在变，桌子未曾离开。
As of today, huozi.app is in beta. This is the moment the arguments from our last few posts — why a real file system instead of a document API, why HTML deserves first-class status, why Excel needs to come apart in three — finally land in a shipping product. The shape they all converge on is a single thing: a cloud-side text machine for Agents.
This post is the positioning. What layer we’re building on, and why.
Anyone trying to build for the Agent era has to answer one question first: what time scale does this thing live at?
The reality of the last twelve months:
Once you draw those three layers next to each other, the picture becomes obvious: the Agent layer will keep churning. The Skills layer will keep churning. Only the data and goals layer is the one users actually want to hold still.
The mistake most Agent tools make is to build themselves on the top two layers. Switch the Agent and the tool dies; swap the Skill set and the memory is gone. We chose the opposite. Huozi lives at the slowest layer, so it outlives any particular Agent and any particular skill stack.
Second, more concrete observation: nobody runs just one Agent any more.
It’s Claude Code and Cursor on the laptop, the Claude app and ChatGPT on the phone, an on-call Agent sitting in the team’s Slack, a research Agent on a cron in CI, Codex Web in a browser tab, and a small SDK script a colleague wrote last week. Agents are distributed from day one.
Which means: pinning data to “some particular local machine” is instantly a problem. Your laptop isn’t always on. The Agent on your phone can’t SSH back into your laptop to read last night’s draft. And teams have it worse — collaboration assumes a shared desk, which is exactly what local files don’t give you.
Teams need the same thing for a different reason: even the cleverest Agent needs a desk everybody can see, or there’s nothing to collaborate on. Huozi is also that shared playground — members, Agents, scheduled jobs, all working against the same file tree, every write landing in the same commit graph. Who changed what, when, and why is queryable.
The third claim — and the one our last few posts have been building toward:
In the Agent world, Word, Excel, and PowerPoint are all going to be replaced. Not by some company’s “AI Word 2.0,” but by token-friendly plain-text formats. Word becomes Markdown. Excel becomes CSV. PowerPoint becomes HTML. The reasoning is in Office for Agent — three layers (values, computation, presentation) that Excel welds together for humans, but that should come apart for Agents.
There’s an old problem with that, though: humans still find these “naked” formats hard to open and edit. Send a non-technical colleague a CSV and watch their face. Ask them to tweak an HTML page and they’ll go look for an editor first. So the other half of the work happening in huozi is making the “open it and just edit” experience as light as double-clicking a doc:
/p/<slug>.huozi_image_render takes raw SVG / Mermaid source and turns it into a content-addressed PNG under /__assets__/. The Agent writes a <svg> block, you get an image asset.Enough observations — what did we actually build? The most direct decision we made: do not invent a new “Agent document API.”
Claude Code already defined a very good local file workflow — Read / Edit / Write / Glob / Grep. These are the most stable verbs in the Agent-as-engineer dialect. What we did was port the semantics, bit-for-bit, into the cloud:
# Claude Code, locally:
Read(file_path: "notes/w17.md")
Edit(file_path: "data.csv", old_string: "...", new_string: "...")
Grep(pattern: "TODO")
# Huozi cloud, bit-exact equivalent:
huozi_read({ file_path: "notes/w17.md" })
huozi_edit({ file_path: "data.csv", old_string: "...", new_string: "..." })
huozi_grep({ pattern: "TODO" })Same schemas, same error codes, same line-offset pagination, same old_string → new_string uniqueness contract. Any Agent that already speaks Claude Code’s dialect plugs into huozi without a single prompt tweak. The full reasoning is in MCP Design Principles.
The payoff of moving that dialect to the cloud is that three “any”s become true at once:
This is what we mean by the OpenClaw Gateways idea: MCP as a single gateway, every client / device / moment funneling writes into the same versioned tree.
Huozi ships in two editions, for two genuinely different audiences:
Both editions speak the same MCP dialect, with the same tool names and the same file semantics. What you write in Cloud today can move to Edge tomorrow, and vice versa. The dialect is the contract; deployment is an implementation detail.
What this beta puts in your hands:
If you’re already on Claude Code, Cursor, or Claude Desktop — mount huozi and keep your existing muscle memory. If your team needs a desk every Agent can share — come join the beta.
The pencil case changes. The desk stays.