养殖龙虾（OpenClaw），你必须配置这些虾粮和工具

附配置清单

OpenClaw 不是单纯的聊天工具，也不是一组零散的 agent 工具。它更准确的身份是：一个自托管的 Gateway 驱动型 AI 操作系统。你在自己的电脑或服务器上运行一个 Gateway 进程，这个 Gateway 负责统一管理会话、路由、渠道连接和控制界面；然后 Telegram、WhatsApp、飞书、钉钉、企业微信、Web UI、CLI，甚至移动端节点，都会围绕这个 Gateway 工作。官方甚至直接把 Gateway 描述成 sessions、routing 和 channel connections 的单一事实来源。

所以，讨论“一个优秀的 OpenClaw 应该具备什么”，不能从“装什么模型”开始，而要从它的系统本质开始：它首先是一个控制界面，其次才是一个会说话、会用工具、会跑流程的助手。这也是为什么 OpenClaw 的配置中心是 ~/.openclaw/openclaw.json，为什么官方主路径是 openclaw onboard 和 openclaw gateway，以及为什么一旦配置不符合 schema，Gateway 会直接拒绝启动。

如果把 OpenClaw 说得最自然，它其实可以被理解成三层结构。

能力层回答的是：这个系统最终能做成什么。

框架层回答的是：它靠什么运行机制把这些事稳定做成。

组件层回答的是：这些机制最后具体落成了哪些可部署、可配置、可审计的实体。

这三层不是并列摆放的目录，而是从上往下收束的关系。能力层是“目的”，框架层是“组织方式”，组件层是“落地载体”。

一个成熟的 OpenClaw，能力上不应该被理解成“会聊天 + 会调工具”，而应该被理解成一个完整闭环：能接入，能理解，能编排，能执行，能记住，能复用，能约束自己，也能被审计。官方首页强调它是 self-hosted、multi-channel、agent-native；工具能力是它的原生核心能力；安全文档强调它不是 hostile multi-tenant 平台。这三件事合在一起，才是它完整的能力边界。

首先，它要有接入能力。这不是“把 bot token 配进去”那么简单，而是要能在多个渠道下稳定收发消息、识别发送者、维护会话边界，并把不同入口统一收束到 Gateway。官方明确支持多渠道和多智能体路由，甚至把“按 agent、workspace 或 sender 隔离 session”列为关键能力之一。换句话说，优秀 OpenClaw 的第一能力不是回答问题，而是把消息正确地接到对的 agent 上。

其次，它要有推理能力，但这里的推理不是“选个更强模型”这么简单。OpenClaw 的推理能力本质上是“主模型 + 回退模型 + 认证轮换 + 会话粘性”的组合能力。官方模型与配置文档都表明，OpenClaw 支持模型 allowlist、fallback、auth profiles，以及在失败时的轮换与降级。真正优秀的配置，追求的不是单次回答最聪明，而是系统长期在线时依然稳定、连续、成本可控。

再者，OpenClaw 还必须有上下文和记忆能力。这里的关键不是“上下文窗口有多大”，而是工作区是否被当成 agent 的长期家园。官方把 workspace 直接定义为 agent 的 home，并明确区分它和 ~/.openclaw/ 下的配置、凭证、会话数据；同时还给出一整套工作区文件地图，例如 AGENTS.md、SOUL.md、USER.md、TOOLS.md、MEMORY.md 等。也就是说，一个优秀 OpenClaw 的稳定性，来自结构化上下文，而不是临时 prompt 的堆积。

然后再到执行能力。OpenClaw 的工具系统已经不是旧式的 shell 拼接，而是一组类型化的工具：browser、canvas、nodes、cron、exec、web_search、web_fetch、message、sessions_* 等都在同一个工具体系里；同时又能通过 tools.allow / tools.deny 做边界控制。于是，“执行能力”在 OpenClaw 里真正意味着：系统不仅能做事，而且能在明确权限范围里做事。

而在这些能力中间，真正把系统从“会用工具的助手”抬升为“可长期运行的系统”的，是工作流能力。这个能力是目前很多基础模型最难的地方，其实它在逻辑上非常居中：接入和理解告诉系统“要做什么”，工具和浏览器告诉系统“能做什么”，而工作流决定的是“这些事如何按步骤、有顺序、可暂停、可恢复地完成”。Lobster openclaw 被官方定义为 typed workflow runtime，能够把多步工具序列收束为一次确定性操作，并带审批检查点；OpenProse 则是 markdown-first workflow format，能生成多个子智能体并显式控制流程；cron 和 webhook 又负责把这些流程接到时间和事件上。换句话说，工作流不是附属功能，而是 OpenClaw 的“中段肌肉”。没有它，系统只有动作；有了它，系统才有过程。

最后，一个优秀 OpenClaw 还必须有安全与运维能力。官方安全文档写得很明确：它假定的是单一信任边界下的个人助手模型，而不是多个不互信用户共享同一 gateway 的敌对环境；官方配置文档也明确要求严格 schema 验证，配置错了就不启动；runbook 则提供 status、logs、doctor 之类的运维路径。也就是说，真正成熟的 OpenClaw，不是“能跑起来”，而是知道自己能做什么、不能做什么，出问题时还能自行检查和修复。

如果说能力层回答“它会什么”，那框架层回答的就是“它为什么会这些”。

最外层是控制平面框架。Gateway 是整个系统的中枢，不只是一个监听端口的进程。它统一承载 sessions、routing、channel connections、Control UI 和运行状态，因此它不是普通组件，而是整个系统的主框架。先有 Gateway，才有后面的多渠道、多 agent、多会话、多工具。

在控制平面之内，第二层是接入与会话框架。消息从不同渠道进来后，系统要决定由谁处理、进入哪个会话、用哪个 agent、落到哪个 workspace。这也是为什么 OpenClaw 文档不断强调 sender/session/agent/workspace 的关系。没有这一层，渠道再多也只是更多入口，不会形成稳定系统。

第三层是模型路由框架。优秀 OpenClaw 从来不是“绑定一个模型”，而是“为不同失败模式、不同授权方式和不同任务复杂度准备一套路由机制”。这套框架让模型层从脆弱的外部依赖，变成可管理的系统资源。

第四层是上下文管理框架。工作区之所以重要，不是因为它是一个目录，而是因为它把规则、人格、用户、记忆、工具说明这些原本容易混杂在 prompt 里的内容，拆解成长期可维护的结构。这样 agent 的“持续性”才来自文件体系，而不是来自一次性对话偶然性。

第五层是工具与 Skills 框架。OpenClaw 现在同时保留了两类东西：一类是