高风险工作先停在显式审批门后
当智能体要执行高影响命令或安装缺失能力时,操作员可以先检查、再决定是否继续执行。
更适合 chat ops适合第一次使用。脚本会安装最新 release,走本地 web-first 启动路径,然后把后续配置交给 dashboard。
curl -fsSL https://hopclaw.com/install.sh | HOPCLAW_INSTALL_RUN_ONBOARD=1 shmodels、channels 等都可以放到 web 控制台里完成,不必卡在安装命令里。
hopclaw dashboard --open确认 runtime 已启动,接口和 token 都可用。
hopclaw health后台常驻服务不是首次安装的阻塞项,确认跑通后再决定是否安装。
hopclaw daemon install二进制优先阶段要站得住,不能只靠一个 GitHub 仓库地址。release 包、结构化 issue 入口和未来贡献者池都应该从首页直接可见。
第一天就先走发布包,让 Linux、macOS、Windows 用户可以真实安装,而不是要求他们先从源码构建。
打开最新 releaseBug先跑 `hopclaw doctor` 和 `hopclaw bug-report`,再把版本号、复现步骤和 bundle 细节通过结构化模板交上来。
打开 bug 模板Onboarding下载、安装、setup、auth、health 检查、dashboard 入口里哪一步让人卡住,都应该能单独反馈出来,不必硬塞进 bug。
打开 onboarding 模板Workflow把 release ops、审批流、channel、browser workflow 或集成缺口说清楚,帮助筛出真正值得做的 first-party 方向。
打开需求模板Contribute如果你能帮忙做 docs、复现、onboarding review、集成设计,或者后面愿意参与代码贡献,现在就可以先留下真实场景。
自我介绍当智能体要执行高影响命令或安装缺失能力时,操作员可以先检查、再决定是否继续执行。
更适合 chat opshealth、tools、runs、approvals、artifacts 都能通过 dashboard 或 HTTP 直接查看,而不是从对话里猜。
更少猜测SKILL.md、`~/.openclaw` 和常见安装结果仍可继续工作,团队可以逐步迁到更严格的 runtime surface。
保留已有资产真正的 operator 体验,起点不是“模型说自己准备好了”,而是用户能直接看到运行时状态。
本地 daemon 启动后,可以直接检查 readiness、token 和当前 profile。
直接看 `/runtime/tools`,而不是从对话里猜当前机器暴露了哪些能力。
审批、artifact 和 audit 都是查询得到的 runtime 记录,不会消失在长上下文里。
兼容重要,是因为迁移成本重要。在 HopClaw 里,兼容是通往 approval、audit、artifact 和 operator visibility 的桥,而不是全部产品身份。