控制面,不是对话面
ManClaw 关心的是服务是否在线、当前 Profile 接到了什么配置、哪个 Agent 在用什么模型、某个 channel 绑定到了哪里,而不是复刻一套对话体验。
ManClaw 是面向 OpenClaw 的管理控制面。它不重复造一个聊天壳,而是把运行诊断、配置治理、模型与渠道关系、插件与技能管理,以及高频运维动作重新收进一个清晰可操作的入口。
拉取最新脚本并启动 ManClaw 控制台:
curl -fsSL https://github.com/icocoding/manclaw/releases/download/scripts/install-latest-release.sh | bashGit 仓库:https://github.com/icocoding/manclaw.git
装好控制面后,再连接你的 OpenClaw 实例,即可开始做运行观察、配置治理、插件与技能管理,以及最佳实践执行。
当 OpenClaw 进入多 Agent、多技能、多渠道和持续值守场景后,最缺的往往不是一个新的聊天窗口,而是一个能把运行态、配置关系和高频治理动作收回来的控制台。
ManClaw 关心的是服务是否在线、当前 Profile 接到了什么配置、哪个 Agent 在用什么模型、某个 channel 绑定到了哪里,而不是复刻一套对话体验。
workspace、bindings、skills、plugins、channels、models 这些关系一旦增长,单靠 JSON 和命令行很快会失控。控制面的任务就是把这些关系重新组织清楚。
配置写回、服务重启、Session 清理、模型迁移和技能操作都需要明确边界、错误回传和可追溯反馈,而不是散落在一堆手工步骤里。
当前首页与架构文档保持同一口径:ManClaw 围绕六类真实能力组织,而不是用一堆抽象卖点拼页面。
openclaw.json 做结构化编辑ManClaw 是 OpenClaw 的 operator console,用来把原本散落在配置文件、工作区、技能目录和命令行里的运行复杂度,重新收成一个稳定、清晰、可操作的治理入口。
首页不再把重点放在抽象口号,而是明确 ManClaw 怎么和 OpenClaw 分工、以及页面里的能力为什么可信。
ManClaw 当前直接围绕真实 `openclaw.json`、真实 workspace 和真实 service/profile 工作。页面里展示的状态、绑定和配置不是独立影子模型,而是当前实例的真实信息。
前端只是入口。真正的配置读写、进程探测、日志采集、OpenClaw CLI 调用和治理动作,都下沉到服务端和核心层处理,再由页面组织成可见界面。
当前 `manclaw` 本体已经具备真实运行控制、配置治理、模型与 Agent 编辑、插件与技能管理、Profiles 管理、Best Practices 和 Release CLI 闭环。
“最佳实践”不是另一个文案栏目,而是把常见治理动作直接做成能执行、能回刷、能继续编辑的功能入口。
Prompt 页面展示的是 ManClaw 对控制目标、角色边界和运行约束的表达方式,用来说明这套控制面如何进一步沉淀成可复用的方法结构,而不是产品主功能页。
当前静态站不再只罗列“应该怎么做”,而是把产品里已经存在的治理动作浓缩成一个更适合对外理解的入口页。
用更直接的入口收紧当前 profile 的 Feishu tools 和相关系统技能,减少无关能力继续进入模型上下文。
当模型、workspace、skills、bindings 或 tools 策略变化后,直接清理旧 Session,让后续验证回到干净上下文。
当上游模型版本号变化时,批量把旧 Model ID 迁移到新值,并同步更新默认模型与 Agent 引用。
ManClaw 面向的是已经进入真实运行阶段的 OpenClaw 系统。它不是开发脚手架,也不是教程页,而是给日常治理、值守和协作使用的控制面。
当服务已经上线,最重要的是持续知道哪些 gateway、agent、channel 和配置动作正在影响当前系统,而不是再开一个聊天窗口。
适合需要频繁调整模型、绑定规则、技能、插件和 session 策略的团队,把变更从零散命令重新收回到同一个控制台。
当同一套 OpenClaw 需要被运营、开发或维护者共同接触时,ManClaw 提供的是更清晰的治理界面,而不是让每个人直接碰底层配置。