跳到主要内容

OpenClaw：架构与实战场景

目录​

心智模型：Gateway 是什么​

把 OpenClaw 想成三层，会显著降低你读官方文档时的「概念漂移」：

  1. 渠道层：Telegram/Slack/Webhook/长连接等，负责消息如何进入与离开系统。渠道越多，你越需要统一的路由与风控策略。
  2. Gateway 控制面：会话、事件、工具调用、权限与安全策略的枢纽（见 Gateway）。
  3. 执行与扩展层：浏览器、Canvas、Cron、Sessions、Skills 等「让助手真能办事」的模块（见 Tools）。

官方 README 强调：Gateway 只是控制面，产品体验在助手本身。这意味着评估时不要用「Gateway 进程是否存活」代替「端到端任务是否可靠」——你应关注会话是否串台、工具是否越权、是否可复现。

为什么“控制面”这么重要​

没有控制面，你的系统会退化成「一堆散落的集成」：渠道各自解析、工具各自调用、日志各自打印。控制面的价值是把状态机（会话）、策略（谁能做什么）与观测（日志/追踪）统一起来，让问题能定位、能回滚、能审计。

从请求到响应：两条图一起看​

图 A：粗粒度数据流（教学抽象）​

图 B：与工作区沉淀的闭环​

更细的概念与协议请参考官方：Architecture、Agent、Session model、Gateway protocol。

工作区、会话与 Agent：如何分工​

官方 README 给出的默认工作区路径为 ~/.openclaw/workspace（可通过 agents.defaults.workspace 配置），并提到会注入 AGENTS.md、SOUL.md、TOOLS.md 等提示文件；Skills 位于 ~/.openclaw/workspace/skills/<skill>/SKILL.md。

会话负责短期交互状态；工作区负责长期可维护规则与沉淀；Agent（在路由层面）决定这条入口使用哪套工作区与策略。三者若混用，会出现典型问题：

  • 会话里临时口令被写进长期文件；
  • 工作区文件过大导致模型抓错重点；
  • 多入口共用工作区导致隐私串味。

提示文件：AGENTS、SOUL、TOOLS 的协作方式​

建议用以下方式理解三者关系（具体文件名以官方为准）：

  • SOUL：偏稳定的人设与价值观边界，变化频率低。
  • AGENTS：偏职责与任务边界（“你是谁、负责什么、不能做什么”）。
  • TOOLS：偏工具策略（哪些默认可用、哪些必须审批、哪些永远拒绝）。

把高频变更写进 TOOLS.md，把低频变更写进 SOUL.md，能显著减少“调工具策略却意外改变人设”的事故。

工具、Skills 与自动化​

  • 工具：浏览器、Canvas、Nodes、Cron、Sessions 等能力是否开启，直接改变风险面与成本；README 的 Security model 里对 main 会话与沙箱的默认行为有重要说明。
  • Skills：适合封装「重复任务的标准操作程序（SOP）」，见 Skills。
  • Cron / Webhooks / Gmail Pub/Sub 等：把助手从「被动回答」推进到「按节律办事」；上线前务必做权限与数据最小化审计（见 Automation 文档索引）。

工具启用的一条经验法则​

每新增一个工具，就问三个问题：最坏情况下它能造成什么损失？谁能触发？能否回滚？ 回答不清楚就不要默认开启。

典型实战场景（含落地要点）​

场景价值落地前检查
个人超级入口手机 IM 丢任务，桌面继续跟进会话是否一致、是否误串台
小团队值班群聊里统一响应，减少人肉切换DM 是否关闭或强制配对、群权限是否明确
可视化协作Live Canvas / A2UI 类任务权限与屏幕内容是否敏感（见平台文档）
节律任务日报/巡检摘要Cron 频率、通知对象、失败重试

每个场景都要写清「失败时用户体验」：例如 Cron 失败是静默、还是通知、还是写入日志告警。

多 Agent 路由在工程里意味着什么​

「多 Agent routing」通常对应：

  • 数据隔离：不同工作区、不同会话状态，减少串台与提示污染。
  • 权限隔离：对不同入口使用不同工具白名单（尤其在引入沙箱时）。

更系统的方法见本站 多 Agent 方案。

性能与体验：不要只盯首 token​

真实体验往往由以下因素共同决定：

  • 工具延迟：浏览器、网络请求、外部 API。
  • 重试与失败：工具失败后的恢复策略是否清晰。
  • 消息送达：渠道侧限流、重试、消息格式。

因此评估时，不要只关注「模型回复快不快」，而要关注「任务完成率是否稳定」。

延伸阅读​

原文链接​