运行时是怎么接起来的
从进入消息到持久化结果，HopClaw 关注的是可运营的控制点：排队、审批、artifact、审计，以及能力暴露。
四个核心部分
HopClaw 把入口、执行、安全和可选宿主能力拆开，这样每一层都能独立运维，而不是全堆进模型循环里。
Ingress
频道和 HTTP 负责产生工作、映射 session、入队 run，而不是把传输层规则硬塞进智能体循环。
Execution core
运行时负责准备上下文、选择模型、执行工具调用、存储 artifact，并发布事件。
Policy and approvals
高风险工具调用会变成审批单，只有运行时记录决策后，任务才会恢复继续执行。
Capability hosts
browser.* 和 desktop.* 只有在外部 daemon 正常配置、健康可用时才会暴露。
启动过程
有用的服务应该先声明“现在能做什么”，而不是假装所有路线图功能都已经落地。
- 注册内置工具和 Layer 2 工具组。
- 检测已配置的宿主和当前 runtime profile。
- 通过 HTTP 暴露工具与操作接口。
Run 生命周期
无论任务来自聊天、HTTP，还是未来的自动化入口，run 的执行形状都应该一致。
创建 run
入站请求先绑定 session key 并持久化，再开始执行，保证状态先于副作用落盘。
准备上下文
运行时会压缩历史、应用 token 预算，并准备面向模型的消息窗口。
调用工具
智能体循环可以在运行时策略下调用内置工具、宿主工具和本地技能。
拦截副作用
高风险操作会被审批机制暂停，而不是把信任边界交给模型自己决定。
持久化输出
大结果会写成 artifact，同时向操作员或下游系统发布事件。
恢复或结束
审批通过后 run 会继续，否则返回一个可经由 HTTP 查询的最终状态。
Runtime profiles
已发布的 profile 是真正改变默认安全行为的配置，不是一个模糊的“生产模式”标签。
默认的本地优先 profile。适合开发和日常使用，同时保留对写类操作的审批门。
在可信个人机器上降低摩擦，但依旧不会绕过破坏性操作的保护。
要求认证、持久状态、更严格的 exec 默认值，并在启动前启用审计。
发布边界
仓库已经明确区分“当前已实现”和“路线图草案”。官网也应该把这件事讲清楚。
- 智能体循环、run 与 session 生命周期、审批、artifact、审计和事件总线。
- HTTP runtime API 与轻量本地 operator console。
- 内置工具与 Layer 2 工具执行。
- 浏览器宿主 daemon、桌面宿主 daemon 以及对应的 runtime tool 暴露。
- 覆盖团队聊天、消息渠道与 webhook 的内置 channel adapter。
- gRPC plugin host 与对应协议实现。
- 自动生成 SDK。
- 更完整的浏览器流程，例如下载与多标签 orchestration。
- email inbox、email read、email search 工具。