适用场景

当智能体真的碰到现实约束时，再用它

HopClaw 最有价值的时候，是 prompt 已经不够，周边运行时语义必须稳定而明确的时候。

Chat ops

把团队智能体放在审批门后面运行

当助手需要通过 Slack、Discord 或 Telegram 做部署、查日志、改基础设施时，频道适配器和策略门控会比花哨的 agent 叙事更重要。

  • 多个聊天产品共享同一套 runtime surface。
  • 高风险工具在人工批准后恢复执行。
  • 真正能追查“改了什么”，而不是只看聊天记录。
scenario 01
[slack] /deploy api to production
> git.status()
> exec.run("kubectl set image ...")
[approval] waiting for operator
[resume] rollout continues
Local operator

自动化真实桌面，而不是把 UI 流程写死在核心运行时里

只有在机器真的需要这类能力时才挂接 browser 和 desktop daemon，让核心二进制在其他环境依旧保持可移植。

  • 当 Web 应用没有 API 时，使用 browser.*。
  • 当任务需要 App 聚焦、热键、截图和剪贴板时，使用 desktop.*。
  • 宿主相关自动化与主二进制清晰解耦。
scenario 02
[desktop] open Browser and Notes
> browser.navigate("https://calendar.google.com")
> desktop.screenshot()
> desktop.clipboard_write(summary)
[done] morning brief prepared
HTTP service

从你自己的系统里驱动 runs

如果你已经有调度器、Webhook 源或者内部平台，HopClaw 可以稳稳地挂在 HTTP 后面，而不假设聊天一定是唯一入口。

  • 异步创建 run，之后再轮询结果。
  • 通过 HTTP 查看 approvals 与 artifacts。
  • UI 保持轻，因为 API 才是真正的边界。
scenario 03
POST /runtime/runs
{"session_key":"daily-report","content":"summarize new issues"}
202 Accepted
GET /runtime/runs/7d1a
[status] completed, artifact_ref=artifact://local/9b4
Skill packs

不 fork 运行时，也能加上团队自己的能力

使用本地 SKILL.md 把自定义行为叠加到运行时之上，并且按你希望的策略控制安装过程。

  • 启动时从磁盘发现技能。
  • 运行中通过 skill.ensure 恢复缺失能力。
  • 把团队知识放进可版本化的技能包里。
scenario 04
[run] missing capability: github.issue.search
> skill.ensure("github-issues")
[policy] install_policy=ask
[approval] skill install requested
[resume] skill available, continue

常见部署形态

只要控制表面足够干净，同一套运行时可以先跑在笔记本上，再放到面向团队的网关后面。

Laptop operator

desktop profile、本地控制台、可选 browser 或 desktop host、以及来自工作区的 SKILL.md 技能包。

Team runtime

频道适配器、审批队列、持久状态、production profile，以及 HTTP 状态与 artifact 检查。

Internal service

HTTP 驱动的 run 创建、健康检查、外部可观测性，以及从磁盘加载的仓库专属技能。