OpenClaw 是什么？自托管助手、Gateway 与聊天渠道如何配合
解释 OpenClaw 的自托管助手和常驻 Gateway，说明会话、模型与聊天渠道的分工，以及共享使用时的信任范围，避免把它当成模型或 IDE。
先了解这个工具
OpenClaw 是可运行在自有基础设施上的 AI 助手与协调系统。它通过常驻 Gateway 连接聊天渠道、会话和工具，让用户从已有通信界面发起任务。Gateway 是控制与连接部分，模型负责处理任务信息；OpenClaw 不是某个固定大模型，也不能仅因自托管就认为所有推理和数据都不离开机器。
Gateway 把聊天渠道与任务会话连接起来
例如从Telegram或WebChat询问自己的项目资料，请求先由渠道送至Gateway，再交给相应助手处理。渠道是用户交互的位置，Gateway维护连接与会话。助手能完成什么，仍由已配置工具决定；仅把聊天账号接入，不会自动生成文件读取或业务系统权限。
这与把模型API封装成聊天框有所不同：OpenClaw还组织持续会话、工具调用和消息返回。它适合需要从多个入口访问同一助手的情形。若只是直接在代码库中修改程序，独立编程工具可能更贴近工作，不必额外引入消息渠道层。
会话和记忆让跨设备工作保留状态
会话状态和记忆为后续任务提供持续资料，但当前会话、保存的信息与项目源文件并非同一对象。旧状态可能已经过时，重要结论需要核对对应资料。用户换设备仍能接近同一助手，不代表每台设备上的本地文件已经自动同步。
官方将Gateway定位为常驻控制平面，部署时需考虑进程、存储与更新恢复。自托管助手不等于部署了模型权重，外部推理仍需请求模型服务。应分别梳理助手状态保存处和模型调用目的地。
模型配置与工具部署仍需分别准备
模型提供方承担推理，工具或插件负责具体外部动作。替换模型不会自动安装缺失工具，也不能解决下游接口没有授权的问题。选择模型时还应核对工具调用和上下文要求，而不是只要接口能返回一句话，就假定整个助手功能都可用。
OpenClaw侧重助手协调，不是要替代所有IDE。与Codex或Claude Code连接时，也应区分消息路由与真实编程会话，不能把一条已发送请求当作代码已修改完成。需要持续项目工作时，明确使用哪份仓库和哪个执行环境。
一个共享 Gateway 有明确的信任范围
共享Gateway可以服务相互信任的团队，但官方安全模型不把同一Gateway当作敌对用户间的强隔离。不同信任范围应考虑分开Gateway与凭证，必要时隔离系统用户或主机。多用户功能存在，不代表可以安全托管任意互不信任的人。
聊天发件身份、工具权限和跨渠道消息范围需要对应实际配置。未知发件人能否使用助手，不应仅凭群成员身份随意推断。安装或接通渠道后，先核对允许的用户与动作；连接状态正常只证明部分环节可用，业务结果仍要由相应资源确认。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。