夜雨聆风我们做 ManClaw，并不是因为一开始就想做一个“新的聊天产品”。
真正的起点，来自一个很具体的问题：
为什么一次看起来普通的 OpenClaw 请求，会轻易跑到 40k Token？
一开始我们也以为，问题只是 prompt 太长，或者模型本身太贵。但越往下排查，越发现真正拖高成本的，往往不是某一句提示词，而是整个运行环境。
最常见的情况包括：
默认只用一个 mainAgent，结果所有能力都往它身上堆暴露给模型的 tools 太多 不该继续注入的系统技能还在带上下文 Agent、workspace、bindings、channel 的关系不够清楚 很多并非当前场景需要的能力，仍然默认参与每次请求
更麻烦的是，问题还不只出在“能力暴露太多”。
我们最开始做的，其实是最直观的几步：
禁用插件 禁用 Tools 禁用技能
但这些动作做完以后，Token 消耗依然没有明显降下来。继续往下查才发现，旧 session 还在持续污染上下文。配置虽然收紧了，运行时却仍然带着之前那套记忆继续跑。
也就是在这个过程中，我们越来越清楚地意识到：
当 OpenClaw 从“本地试一下”走到“真的跑起来”，复杂度会迅速从 prompt 本身，转移到运行环境上。
你会开始关心：
现在到底是哪个 profile 在跑 当前 workspace 是哪一个 默认模型是什么，哪些 Agent 显式覆盖了模型 某个 channel 最终绑定到了哪个 Agent 哪些 plugins、skills 正在暴露能力 为什么配置改了，行为还像旧上下文 遇到问题时，日志、doctor、restart、session cleanup 应该从哪里下手
这时候最缺的，已经不是再来一个聊天窗口，而是一个真正的控制面。
ManClaw 就是在这个阶段开始成形的。
它要解决的，不是“怎么让模型多说一句话”，而是“怎么把 OpenClaw 的真实运行环境重新组织成一个可见、可控、可治理的 operator console”。
ManClaw 不是聊天壳，而是控制台
我们从一开始就没有把 ManClaw 当成另一个聊天前端。
它更像一层管理外壳，负责把原本散落在：
openclaw.jsonworkspace skills / plugins bindings / channels 命令行和诊断工具
里的运行复杂度，收回到一个统一入口。
在当前阶段，ManClaw 已经围绕真实运行环境落下了一批核心能力：
查看 OpenClaw 当前服务状态、PID、运行时长和日志 启动、停止、重启服务，并执行 doctor --fix直接读写真实 openclaw.json独立管理 Models、Agents、Channels 管理 Plugins、Skills，并支持筛选 维护 Profiles 和工作区 清理 Session、迁移 Model ID、收紧 Feishu 能力暴露 使用全局 manclawCLI 安装、启动、更新和卸载
这些能力的重点，不在“功能堆得多不多”，而在“高频治理动作能不能回到同一个地方完成”。
在我们一次真实治理里，当配置关系、能力暴露和运行时上下文被逐步精简以后，首次对话的 Token 消耗从原来轻易冲到 40k，压到了 2k 以内。
这也是我们真正看到控制面价值的时刻：
问题并不只是“模型贵”，而是系统在没有被整理之前，运行态本身就会不断放大成本。
为什么 OpenClaw 需要这样一层控制面
OpenClaw 本身已经有很强的运行能力，但一旦进入真实场景，问题往往不再只是“模型怎么回答”，而会变成：
这套系统现在到底在怎么跑？
尤其当你开始面对下面这些情况时：
多 Agent 多 workspace 多 channels / 多账号 多套 skills / plugins 多个 profiles
如果这些动作还主要依赖手工改 JSON、手工执行命令，成本会越来越高，错误也会越来越隐蔽。
ManClaw 的价值，就是把这些状态和动作重新组织成一套可操作结构。
例如现在的 Best Practices 页面，已经不是简单列几条建议，而是把一批高频治理动作做成了真正可执行的入口：
一键收紧 Feishu 能力暴露 快速新增 Feishu Channel 一键新增预设 Agent Session Cleanup 一键更换 Model ID
这意味着，很多原本要手工改配置、再去验证的动作，已经可以直接在控制台里闭环。
更重要的是，它帮助我们逐步形成了一个很明确的原则：
Tools 和技能不应该默认全部挂到同一个 Agent 身上，更不应该默认一次性全部开放。更合理的做法，是围绕不同 Agent 的职责，逐步开放它真正需要的能力。
我们在意的不是功能数量，而是治理闭环
ManClaw 不是靠堆模块来增长的。
我们更看重的是：每次新增一项能力，是否真的围绕真实运行环境形成闭环。
例如：
配置改了，能不能直接保存到真实 openclaw.json模型和 Agent 改了，页面能不能看到默认值和实际绑定 当前工作区到底是哪一个，文案会不会把用户带偏 更新 CLI 后，全局命令还能不能继续工作 高风险动作执行后，能不能明确告诉用户影响范围和下一步建议
这些问题，比“页面上再多一个按钮”重要得多。
ManClaw 现在处在什么阶段
它已经不是一个静态壳子了，但我们也不想把还在推进中的能力说成“已经成熟完备”。
目前更准确的说法是：
ManClaw 已经具备真实可用的最小控制面闭环，并且还在持续收紧几个方向：
更准确地围绕 OpenClaw 语义组织页面和文案 更明确地区分 runtime、workspace、profile、service 这些概念 把更多高频人工治理动作沉淀成 Best Practices让官网、宣传图、Prompt 页面和发布材料形成统一对外表达
换句话说，ManClaw 正在从“能用的管理台”，继续收敛成“一套面向 OpenClaw 的操作表面”。
最后
如果说 OpenClaw 更像引擎，那 ManClaw 想做的，就是仪表台、控制杆和维修面板。
它不是替代引擎，而是让这台机器在真实运行里，更容易被看清、被控制、被治理，也更容易被维护。
这也是我们继续做它的原因。
主页地址：
https://cocoding.org/manclaw
