OpenClaw Team Ops Console：一个严格只读的 Multi-Agent 运维治理台（Alpha）# Standalone · Read-only · Mock-first · Governance Preview当 Agent 开始变多，真正稀缺的往往不是“再来一个能力”，而是“我到底还能不能看清整个系统”。于是我做了一个 OpenClaw 的外挂控制台：不改内核，只做只读治理观察。很多人第一次接触 OpenClaw，最先感受到的是它把 Agent 跑起来的能力：有 workspace，有 session，有 bindings，有多 Agent 路由，也有越来越完整的运行配置。但当你真的开始长期使用，尤其是进入多 Agent、多 workspace、多渠道绑定的状态之后，一个问题会越来越明显：运行时对象越来越多，而统一的外部观察视角并不天然存在。OpenClaw 官方文档已经把 workspace、state、profile、多 agent 路由这些基础模型讲得很清楚，但“如何以只读方式把这些对象整体看清楚”，仍然有很大的外挂层空间。(OpenClaw)所以我做了一个独立项目：OpenClaw Team Ops Consolehttps://github.com/tiejiang8/openclaw-team-ops-console
它不是对 OpenClaw 内核的修改，不 import OpenClaw 私有源码模块，不 patch、不 fork，也不提供写回、控制、终止、编辑、创建等能力。它只做一件事：从 OpenClaw 外部，以严格只读的方式，把多 Agent 的运行状态、workspace、session、binding、auth profile 和拓扑关系统一观察出来。这也是它最核心的设计边界。从形态上看，它不是把自己伪装成第二个 Gateway，而是一个外挂式控制台。当前仓库保持的是三层结构：sidecar + overlay-api + overlay-web。其中，sidecar 负责只读采集，overlay-api 负责只读聚合，overlay-web 负责只读可视化。这种拆法的好处很直接：控制台本身可以独立演进，但又不需要侵入 OpenClaw 本体。我刻意把它做成了mock-first。原因很简单：一个“治理观察台”最先要证明的，不是控制能力，而是观察视图本身是否成立。当前 sidecar 支持两种 adapter 模式：默认的 mock，以及面向本地状态目录的 filesystem。前者适合演示和联调，后者适合对接真实 OpenClaw 运行环境。换句话说，你可以先把界面跑起来，先看清楚这套只读治理视角值不值得，再决定要不要接真实数据。这件事在 OpenClaw 语境下其实很自然。官方文档已经把 agent workspace 的结构拆得很细：AGENTS.md、SOUL.md、USER.md、IDENTITY.md、TOOLS.md、HEARTBEAT.md、BOOT.md、BOOTSTRAP.md、MEMORY.md、以及 memory/YYYY-MM-DD.md 各自承担不同职责；多 agent 模式下，workspace、state、profile、bindings 也都有默认约定和覆盖规则。也就是说，OpenClaw 的核心对象已经存在，缺的是一个不碰内核、只做观察与治理表达的外层。在当前这个 Alpha 版本里，控制台已经不只是传统意义上的 inventory 面板。前端导航里除了 Overview / Agents / Workspaces / Sessions / Bindings / Auth Profiles / Topology，还已经扩展到了 Targets / Risks / Findings / Evidence。这意味着它正在从“我能看见什么”逐步走向“我应该关注什么”。前者是可视化，后者才是治理。它到底读什么
当前 sidecar 的 filesystem 能力，核心是只读扫描 OpenClaw 的外部状态。按仓库 README 的公开口径，它会读取配置文件，解析 agents.defaults.workspace、agents.list[].workspace、agents.list[].id、agents.list[].name、agents.list[].agentDir 和 bindings；同时读取运行目录中的 auth-profiles.json 与 sessions.json，并扫描 workspace 里的常见文件与目录。缺失文件时，它不会补写，只会降级成 warning 或 partial/unavailable。这和 OpenClaw 官方模型是对得上的。官方文档已经明确，单 agent 模式下 workspace 默认在 ~/.openclaw/workspace，设置 OPENCLAW_PROFILE 时会变成 ~/.openclaw/workspace-；state 默认在 ~/.openclaw/agents/main/agent。官方也公开了 OPENCLAW_CONFIG_PATH、OPENCLAW_STATE_DIR 这类外部契约，用于多实例或不同状态目录隔离。也正因为如此，我在这个项目里一直坚持一件事：代码透明。读了什么，尽量写清楚；没读什么，也尽量写清楚；能做什么、不做什么，更要写清楚。一个外挂治理台最怕的，不是功能少，而是边界模糊。只要边界模糊，读者就会自然怀疑：你到底是不是在偷偷“控制” OpenClaw。最简单的使用方法
第一次体验，我建议直接走最短路径：先跑 mock-first，本地把界面看起来。环境要求
当前仓库 package.json 里已经写明了本地开发要求：Node.js >=22，包管理器固定为 pnpm@10.6.4。同时，开发脚本基于 Corepack + pnpm 组织。(GitHub)如果要走 Docker 路线，再准备好 docker compose 命令环境(GitHub)最快跑起来（推荐）
git clone https://github.com/tiejiang8/openclaw-team-ops-console.gitcd openclaw-team-ops-consolecorepack pnpm installcp .env.example .envcorepack pnpm dev
Overlay Web：http://localhost:9527
Overlay API：http://127.0.0.1:4300
Sidecar：http://127.0.0.1:4310
这条路径下，sidecar 默认仍是 mock-first，所以不需要你先准备真实 OpenClaw 状态目录。你可以先把页面结构跑起来，看它如何展示 Targets / Risks / Findings / Evidence / Agents / Sessions / Topology 这些视图。为什么我觉得这条路有价值
我越来越相信，OpenClaw 未来真正需要的，不只是“更多 agent”，也不只是“更强模型”，而是更清晰的运维和治理层。因为一旦 agent 数量、workspace 数量、绑定关系、session 历史开始增长，问题就不再是“这套东西能不能跑”，而是“现在到底是什么状态”“哪里不一致”“哪个对象过期了”“哪些关系是悬空的”“哪些结论有证据支撑”。这就是 Targets / Risks / Findings / Evidence 这组菜单真正想表达的事。而且这件事必须克制。只读，是一种能力边界，也是一种产品伦理。一个外挂控制台如果上来就做写回、重配、自动修复、远程控制，当然会更“炫”，但也更容易把系统边界搞乱。相反，先把“看清楚”做好，先把透明度做好，再决定要不要进入控制面，才是更稳的一步。你从当前仓库的边界定义里也能看到这种克制：不改内核、不引私有模块、不做 chat UX、不提供控制动作。当前阶段，我为什么只把它叫 Alpha
因为它确实还是 Alpha。仓库首页虽然还残留着旧的 v0.1 alpha 表述，但项目包版本已经是 0.2.0-alpha.0，而且当前最有价值的增量不是“又多了几个页面”，而是它正在从单纯的可视化清单，走向只读治理预览。这个阶段最重要的不是夸大能力，而是把边界、路径和价值讲清楚。所以，如果你把它理解成一个“OpenClaw 的外挂控制台”，我觉得是准确的；如果你把它理解成一个“正式可替代官方控制面的产品”，那还太早。它今天更像一个被刻意做轻、做稳、做透明的外层：先把观察层跑顺，再谈治理层；先证明 read-only 的价值，再决定要不要往 control plane 走。最后
如果你也在折腾 OpenClaw，多半会有类似感受：真正难的不是把一个 agent 跑起来，而是当系统开始有多个 agent、多个 workspace、多个 bindings 之后，如何不迷路。OpenClaw Team Ops Console 想解决的，就是这个“别迷路”的问题。不改 OpenClaw 内核，不引入侵入式控制，不把外挂做成分叉，只做一层严格只读、可解释、可观察的治理视图。对我来说，这已经足够值得做。但我相信，一套系统真正成熟的标志，不只是它能跑得更远，也包括我们终于有能力把它看得更清楚。欢迎你来看看这个项目，也欢迎一起讨论：OpenClaw 的外挂式治理层，究竟应该长成什么样。
夜雨聆风
