OpenClaw Studio RC1：本地闭环、外部被关卡挡住，以及我还在改的事

OpenClaw Studio 阶段复盘

一天之内把 OpenClaw Studio 从第一阶段推到第七阶段，交付 RC1（Release Candidate 1，首个候选发布版本）。听上去像在跑冲刺，其实更像在拆雷。

OpenClaw Studio 是我正在做的本地 AI 工作系统。能在本地完成晨检、任务流转、内容产出这三件事。外部那些大组件——DeerFlow（一套深度研究流程）、Mission Control Web（任务中控的网页端）、Gateway（外部网关）、LLM（大模型）接入、Search（搜索）——全部按 gate（关卡）管理，没解锁的就先不接。

RC1 不只是版本号。对我来说它是一道边界——边界之内能独立运转，边界之外老老实实写「未通过」。这次复盘要说的是：这道边界怎么一步一步划清楚的，以及现在还有哪些漏。

为什么要硬塞到一天里跑完

一开始我没打算把七个阶段全压在一天。越做越发现：阶段之间的依赖只在一天内是新鲜的。隔一夜，前一阶段的状态记忆变模糊，下一阶段被迫重新验证，本来一步能确认的事变成三步。

索性集中火力——把所有阶段排成链，前一个通过（PASS）才能开始下一个，中间任何关卡没过就直接停（STOP）。听起来像走钢丝，但实际跑下来比拖几天更稳。注意力没散，决策路径一直热着，遇到问题也能立刻回头改前一步。

单日推进的代价是密度——七个阶段、十几次审稿（review）、二十多次空跑（dry-run）。中途累了就容易放水，放水就出事。我给自己定了三条不能破的方法，这三条才是 RC1 真正的脊柱。

方法一：空跑（dry-run）在前，实跑在后

每一阶段开始之前，我都会先让系统空跑一遍——不写文件、不发消息、不动外部状态。只让它把流程从头到尾走一遍，告诉我「如果真做，会做什么」。

空跑刚出现的时候，我把它当成「确认环节」。后来发现远不止——它其实是「让 AI 暴露自己的理解」。一次空跑下来，AI 会列出它打算访问的路径、执行的命令、修改的文件、调用的外部接口。十次有八次，我都在这一步发现误解：把状态文件当成草稿，要去访问还没解锁的外部，要把「通过」结论写到一个还没被确认的位置。

这些误解空跑里抓不住，实跑时就是事故。规矩是——任何能改外部状态的事，空跑必须先过；过完才允许实跑。

方法二：关卡（gate）隔离，过不去就停

OpenClaw Studio 真正难的地方不是写代码，是控制边界。本地能跑的事情很多，但外部依赖一旦没解锁就不能动——不能假装能动，不能跳过去等以后再补，更不能因为「应该没问题」就先放出去。

我给每个外部依赖都装了一道关卡。关卡状态只有三种：未通过、已通过、待复核。未通过的依赖，整个系统就当它不存在；任何阶段任务里只要碰到这个依赖，立刻停下来等人确认。

Gate 矩阵（所有关卡的状态总表）是 RC1 文档里最重要的一份文档——比任何架构图都重要。它不是装饰，是运行时的真实约束。这一次跑七个阶段，DeerFlow、Mission Control Web、Gateway、LLM、Search 全部未通过，整个外部链路是黑的；但本地链路因为有关卡隔离，反而能完整跑通。

方法三：零越界写入

Agent（智能体）越积极，越容易出事。让它读一下，它顺手改了；让它分析一下，它开始重构；让它检查一下，它把检查结果写到了不该写的地方。

我给每个 agent 都签了一份「契约」——明确写清它能读哪里、能写哪里、绝对不能动哪里。RC1 一共有 7 份这样的契约：每个 agent 一份，三栏（Read 读 / Write 写 / Forbidden 禁），完全没有灰区。

契约本身不复杂，关键是签完以后真拿它做拦截。任何写入只要不在「写」列表里，工具层直接拒绝，不给 agent 留余地。这一招让 RC1 的安全感比之前几版高了一截——不再怕哪个 agent 心血来潮把资料目录改了。

七个阶段，分别在收什么口

七个阶段不是按功能分的，是按风险分的。每个阶段只解决一类风险，全部通过才进下一阶段。任何时候出问题，都能精确定位到上一道闸门，不必从头排查。

• 第一阶段：把环境冻结——确认本地工作目录、状态文件、工具版本，全部空跑过一遍。
• 第二阶段：把 agent 契约写清楚——读哪里、写哪里、什么时候必须停。
• 第三阶段：外部关卡全部摆好——没有外部依赖能在未确认状态下被触发。
• 第四阶段：把内容工厂跑通——五类内容模板、注册表（registry，相当于内容的总账）、审稿管线，本地全闭环。
• 第五阶段：把 Mission Control（任务中控）的 markdown 版本接上——能自动更新，能自动备份。
• 第六阶段：主集成（master 集成）——前五阶段的产物合起来跑一次完整任务，看耦合点。
• 第七阶段：交付 RC1——固化文档，标记首个候选发布版。

每个阶段的审计链路（包括所有重跑子版本、小任务节点、收口节点）都留在本地审计目录里，不必在文章里贴。重要的是分阶段思路——按风险切，不按功能切。

RC1 真正交付了什么

一天结束，RC1 上能用的东西不算多——但每一项都被验过：

• 本地工作系统能独立运转——能晨检、能流转任务、能产出内容，不依赖任何外部接口。
• 内容工厂跑通了——注册表 + 五类型模板 + 审稿管线，一篇内容能从草稿走到审稿通过，全程留下证据。
• 任务中控的 markdown 版接上——任务状态自动更新、自动备份，不用人手动同步。
• 7 份 Agent 契约就位——每个 agent 的读写边界都明确，无契约不工作。
• 关卡矩阵已文档化——任一外部依赖未通过都被自动拦下，没有偷偷放过去的可能。
• 角色调整也落地了——主控和写入责任人从「嬴政」迁到「赵子龙」，其余角色降级为主理人之一。这件事写进契约之后，所有写入都收口到赵子龙一个 agent，问题追溯快了很多。

RC1 没有交付什么

我想把这一节写清楚——RC1 的本质是「本地能跑的部分」，不是「整个系统已经成熟」。下面这些事还没解决：

• 外部系统全部被关卡挡住——DeerFlow、Mission Control Web、Gateway、LLM 接入、Search 都还在边界之外。任何需要外部能力的任务，RC1 都接不住。
• 4 个锚点（anchor，长期状态同步用的几份关键文件）的同步机制还不可见——本地状态变化时，这几个锚点是否真的被同步、什么时候被同步，没有自动校验。漂移风险一直挂着。
• 26 个待清理的密钥（secret）仍然阻塞着另一台机器的重装。本地工作系统 RC1 解决了，整台机器的卫生问题没解决。
• 多套控制平面共存——本地 RC1、Mission Control Web 和未来的外部网关在职责上有重叠，谁压谁还没定。
• 历史条目草稿（HISTORY_ENTRY_DRAFT，把当次工程产出归并进长期历史账本的草稿文件）还没闭合——这次七阶段的全过程虽然有审计，但还没归并进长期历史账本，过几个月会需要再回头收一次。

「没交付什么」比「交付了什么」更重要——防止我几个月后回头看 RC1，把它当成「已经完成」的状态。

关于 RC1 的真实状态：我还在做

RC1 在我这里不是终点，是一个能继续走的起点。

本地闭环能跑，我有一个不依赖外部就能维持的工作底座——但边界还很窄。外部关卡解锁是长路，不会一两周完成；锚点同步、密钥清理、控制平面收口，每一件都得单独排队。

我现在的节奏是：每周拣一个关卡试着推进一步——能解锁就解锁，不能解锁就把「为什么不能」写进审计。每解决一个锚点漂移就标「已验证」；每清理一批密钥就把对应位置标「已过期」，等下一轮复核。不追求 RC2、RC3 的版本号，但要让 RC1 这个版本的边界一直清楚——能跑什么、不能跑什么、为什么不能跑——三个问题永远有答案。

这篇是阶段复盘，不是发版庆功。RC1 在线下持续改，本文写完的同时，新一轮关卡测试已经在排队。下一篇关于 OpenClaw 的复盘，多半会从「某个关卡终于解锁」或者「某次以为能解锁结果又退回去」开始讲。