夜雨聆风再不蹭点热度，可能 OpenClaw 的关注度就会慢慢降下来了。不过这也是好事，与其让所有人都关注，不如只让需要它的人安安静静地去使用它。
OpenClaw 是什么我想已经不用再多做赘述了，也不会具体的讲如何安装和部署它，网上有足够多的文章来向大家介绍这个过程，我今天在这里是想向大家分享一下，我是如何将它成功运用在生活与生产环境，以及采取了什么样的措施来规避安全风险及尝试实现高可用的。
与很多工具不同，OpenClaw 更适合单实例模式部署，它在自己的安装指引中也多次强调了工具的"个人化""私人"的设计目标。而且市面上绝大多数人，尤其是非互联网行业的技术人员，几乎都是这么做的。尽管这种部署方式非常简单，但如果真的采用了这种方式，那么就会产生一个非常显著的缺点 —— 要么用户能够做到随时带着这台设备，要么就得保持 24 小时开机，否则基本就难以实现全天候的随时随地 AI 辅助的目标。
大家可能会很容易想到，把它给部署在云上不就行了吗？很多互联网大厂也给出了类似的解决方案 —— 甚至提供了一键式的云端部署能力，但此时却又会带来另一个问题 —— 很多用户压根就不具备安全防护能力，一个裸露在公网上的服务器，本身就是被攻击的绝佳目标，更别说很多人还会把宝贵的 APIKEY 以明文形式写在配置文件里。对于具有一定专业能力的用户，如果需要他花时间去解决公有云带来的安全隐患，那还不如直接买一台裸机从零开始部署，设置各种安全组、转发策略，达到企业级安全，但 OpenClaw 自身极低的资源占用往往又会让这个部署方式显得非常鸡肋，浪费成本。
既然它是为个人场景设计的，那就应该部署在自己家里。
对很多极客来说，拥有一个公网 IP 可能并不是什么难事，即便没有的话，也能通过各种内网穿透的手段（如 FRP）得以解决。因此，家里的群晖、树莓派、甚至路由器，都是部署 OpenClaw 的理想设备。尤其是群晖，自带的"反向代理服务器"的功能（其实就是 Nginx）甚至可以通过 UI 界面轻松配置访问白名单，并且通过它配置的 DDNS 域名自带 https 证书，简直就是 HTTP 协议下，家庭网络安全屏障的天花板。群晖自带的 Docker 也可以方便快捷的实现一键部署的能力，对追求懒省事的人来说，除了低配高价让人觉得不爽之外，群晖几乎可以做到不带脑子的使用。
对我来说可能更安逸一些，虽然我也有群晖，但也只是图它的证书而已。毕竟我真正的算力还是来源于家里的三台 DELL 服务器，通过 PVE 虚拟出一台 Ubuntu 完成 OpenClaw 主节点的安装之后，通过 rsync 很容易就能够实现 OpenClaw 配置文件的冷备与同步，除了自动备份机制之外，借助 HAProxy + KeepAlived 也能可靠的实现服务的高可用。最终，再通过群晖暴露公网下访问的节点，转发到内网的 OpenClaw 主节点上，便能既轻松，又安全的实现私有化 OpenClaw 的对外暴露。
要求大家在自己家里也部署一个机柜可能有点强人所难，但对大部分朋友来说，部署在群晖活其他NAS平台的 Docker 中，其实已经能够实现几乎相同的能力与效果，所以也不用纠结。而成功部署并安全对外开放能力，也只是迈出了第一步，如何才能安全的隔离算力，防止它过度索权以及误操作呢？
这就是后面想要向大家分享的——分布式部署的一环了。
我的整体物理部署架构如下图所示：
架构说明：
- 入口层：群晖 NAS 作为公网入口，负责 HTTPS 接入服务和访问控制
- 高可用层：HAProxy + KeepAlived 实现 Gateway 节点的负载均衡和故障转移
- 计算层：PVE 虚拟化的 Ubuntu 运行 OpenClaw Gateway，主备节点通过 rsync 同步配置
- 执行层：公司设备（Mac Mini/MacBook Air）以 Node 身份加入，家庭设备通过 SSH 或 Node 模式管理
- 隔离层：公司内网资源（Cursor、代码库）仅通过公司设备访问，数据不出公司
作为面向单实例设计的程序，尽管它并不擅长于分布式协作，但它仍然有着比较完备的 Gateway/Node 的"身份"设计。Gateway 作为它的主节点，在大部分的部署环境中，都是承担着绝对主力的任务，但为了能安全隔离操作，我的架构却是反其道而行之。
首先，安装 OpenClaw 的 Gateway 节点时，我们应当为它分配一个专用的账号，并严格约束它的权限范围，这样的话，即使是使用命令行，也可以减小它误操作带来的风险。即便 OpenClaw 所部署的机器上，甚至仅运行着它自己，但隔离这件事对安全运维的目标来说，仍然是十分必要的。这样的话，对 OpenClaw 来说，Gateway 的这台设备就是它的边界。可是，限制那么多，还怎么让它做事？
和很多人想象的不太一样，由于我极大的限制了它的操作范围，所以我在这时反而可以放心的给 OpenClaw 赋予 Full 权限，甚至不太需要我干涉、审计，因为我在底层就给它牢牢地限制住了，我不想让它做的事，它压根就做不了。
其次，需要做事情时，我通过在 AGENTS 的定义，令其总是尽可能的通过其他节点来具体实施（其他节点是指：以 Node 身份安装的其他节点，或通过 SSH 方式登录的远程机器），采取这样的策略，既能避免 OpenClaw "杀死"自己的 Gateway，也能通过在不同机器设置不同的权限粒度的方式，约束它的操作边界。
四层权限模型说明：
以我的实际环境为例，我在公司用来办公的设备（一台 Mac Mini），安装了 OpenClaw 的 Node，通过 WSS 的方式与 Gateway 节点建立连接，这个节点通过 AllowList 的白名单方式为 OpenClaw 赋予了调用 Cursor CLI、QWen Code 等工具的权限，以及能够对特定的几个目录具备读写权限，规避了误操作的风险；而我平时用来开会的笔记本（一台 Macbook Air），家庭、公司两边来回带的情况下，也是和 Mac Mini 类似，以节点形式加入到集群；但我在家里的很多希望由 OpenClaw 进行管理的设备，会让它以 SSH 的形式直接管理，为了避免对外暴露密码，只需要在想让它操作的机器上，提前配置好能够用来远程登录的公钥即可，免密登录在大模型场景下实际上是更安全的方案。
当我需要让它帮我分析公司的项目代码时，它只能读取到我允许它读取的那些资源。当我需要让它完成需求开发时，它通过公司采购的 Cursor 或 Token 都能合规的执行编码动作。而当他实现家里的需求时，也可以和公司里的资源做到完全隔离、互不认识、互不干扰，尽可能的满足了最小权限原则。尤其是公司内的数字资产，完全不需要离开公司，通常也不需要完全让大模型来解析，有足够多的不出公司的 AI 能力可以支撑这个过程安全的进行。
想必当我说到这里时，大部分的读者都已经能够完全理解我的物理部署架构了，那么如何来保证公司的数字资产不外泄呢？
数据隔离原则：
- 公司数据不出公司：代码库、内部文档等仅通过公司 Node 访问
- 家庭设备内网隔离：智能家居等设备不直接暴露给 Gateway
- 外部 AI 脱敏处理：必须使用外部大模型时，先脱敏再发送
主要还是要满足一点要求 —— 公司内的事务，尽可能仅使用公司内的工具来完成，减少 AI 的直接干涉。
坦率的说，想要做到绝对的数据安全，需要全程都使用公司的 Token 来完成大模型相关的任务，但这个成本对很多公司来说又太高了，可能根本不愿意承担。很多时候员工自己为了提效而去购买各种订阅服务，考虑到供应商截留数据的可能性（甚至会明确写在用户协议中），需要主动留意数据泄露的风险。
对程序员来说，自己采购 Coding Plan 完成大模型能力层面上的接入，再通过 AGENTS、SOUL、TOOL 等约束 OpenClaw 仅使用公司合规工具来操作和分析代码，将会是最现实、最稳妥也很容易实现的安全方案，我想很多公司还是会走正规流程采购 Cursor 一类的产品的，一定程度上可以规避代码层面上的安全风险。而对许多需要处理数据的同事（如产品经理），则需要避免让外部的大模型直接接触到我们的数据文件，尤其是包含营收、转化率之类商业敏感信息的内容。
那么还能用 OpenClaw 去分析数据吗？我的建议是，不要直接让未经审计的、不合规的大模型直接接触到商业数据。如果是对 HIVE、MySQL 之类的数据源进行分析，不要直接把原始数据暴露在对话中，取而代之的是可以告知其数据表的 Schema，让它来协作完成分析 SQL，基于 AI 给出的 SQL 自行到数据平台完成数据分析。如果是对 Excel 之类的完成分析，可以给 AI 一个空表格，让他去完成统计脚本的填充，再自行将数据贴入完成计算任务。
其实这些问题并不该仅在 OpenClaw 出现后才开始考虑，反而是要问问所有人，有没有在日常工作中，用到了 豆包、DeepSeek 等大模型产品来完成工作（包括通过网页、APP 等分析 Excel、或者做 PPT 等非常常见的工作场景）。毕竟前者还可以通过规则来约束，而后者往往会出现在一些人完全无意识的动作中，因此，安全风险从来都不是新出现的工具所独有的。
效率与安全从来都不可能做到完美共存，做好充分的权限拦截，保证安全的底线，在此基础上完成提效，无论对公司还是对个人，都是十分必要的。
题外话
有人让我评价一些高校把 OpenClaw 视为木马病毒，我只能说真的难以想象这些公告会出自 985、211 的高等学府之手，甚至让我觉得有些魔幻。
对于政府单位、机构出于公共安全原因不允许接入公有大模型，甚至要求卸载，站在数据安全的立场上，我都可以十分理解以及认同。但如果一个计算机专业的大学生连 OpenClaw 的原理都搞不清楚的话，那只能说计算机教育真的是任重而道远。
OpenClaw 本质上是一个本地化工具链管理器，它的所有操作都在用户的控制之下。将它与木马病毒混为一谈，反映出的不仅是对技术原理的无知，更是对"安全"概念的误解。真正的安全不是通过禁用工具来实现的，而是通过正确的架构设计和权限管理来保障的 —— 这也是本文想要传达的核心理念。
我的实际使用场景
至于我本人有没有用 OpenClaw 解决我的实际工作？是的。在尝试让它接管我的智能家居和家庭数字化系统并取得了不错的结果之后，我现在已经在大量使用它解决工作中的实际问题，包括：
凌晨自动化代码优化：自动检测项目代码问题、制定优化迭代计划及实现细节，并在完成修复后（包括全部单元测试）将代码和文档推送到指定分支。我每天上班后确认这部分内容，决定是否合并至主分支。
BAD CASE 自动修复：每天通过对话告知它调查、解决我所负责的语义消歧服务（代码量巨大、业务复杂的算法服务，非传统 CRUD 项目）的 BAD CASE。它会先确认问题存在（自动调用接口验证），然后拉取最新的 main 分支在本地执行测试。如确认问题在最新分支仍然存在，则会创建解决问题的分支开始执行原因调查及修复。它会调用我所依赖的上游接口确认数据源，再通过本地运行日志分析消歧失败原因并给出修复计划，甚至直接完成修复和测试。在完成全部自动化测试之后，它会将代码推送到仓库。随着领域知识的不断丰富（通过 SOUL.md 和记忆文件积累），它的分析成功率、正确率逐渐提升，自动化程度越来越高，人工干预的次数及粒度也在不断降低。
日常事务管理：待办事项、会议纪要、OKR 完成情况等，都可以基于对话式指令准确完成。
其他场景：能想到的任务都可以交给他。
效率对比
它的工作效率如何？它没有我本人的工作效率高，但它能在我开会、睡觉的时候继续帮我完成任务，包括一些复杂耗时的分析型任务。我在他的协作下可以交付更多成果（以 BAD CASE 解决量计算，约 1.5 倍）。考虑到我工作内容和所负责项目的复杂度，只靠他或者只靠我很难实现这一目标。
与 Cursor 相比？Cursor 提升了我 5 倍的开发效率（以有效代码行数计。曾经靠 Cursor 在一个月内从零开始完成了一个系统的开发，有效代码量约为 10 万行左右。相比我曾经在类似项目一个月手写 2 万行的记录有着巨大的提升）。但我的工作内容并不局限在使用 Cursor 写代码，而 OpenClaw 是一个全能型的助手，可以全面提升我所有方面的工作效率。
多 Agent 实践
我本人会创建多个 Agents 完成工作吗？是的。我创建了十几个不同的 Agent，在不同环境中执行不同方向的任务。我倾向创建每个方向的专家型 Agent，在主 Agent 的指挥下进行工作 —— 绝对不要尝试建立一个"大而全"的全能型选手，因为大模型有幻觉、上下文长度也有限，事情做得越杂越容易遗忘及出错。
我的每一个 Agent 的名字均取自游戏《明日方舟》，她们在工作时会和游戏设定一样称呼自己为"干员"，称呼我为"博士"。凯尔希作为主 Agent，每天指挥迷迭香（搜索消歧服务专家）、塞雷娅（研发工程师，负责代码 review）、但书（负责记录日常工作事项、任务提醒）、可露希尔（完成除搜索领域外的其他领域的开发任务）等十余位干员，帮我完成工作和家庭中的各项任务。
Skills 使用建议
Skills 要不要用？考虑到供应链投毒的风险，建议慎重使用别人公开的 Skills。参考 npm 曾经的事故，今天安全的东西保不齐哪天作者推送恶意更新，可能用了好几年的东西更新完一下子真的变成木马了，那就讽刺了。
如果拿不准是否安全但实在想用，也可以考虑让自己的 Agent"抄"一个。或者减少更新频次，并在每次更新前让自己的 OpenClaw 仔细研究一下相关代码。
不推荐使用本地模型
要不要自己部署本地模型？我的建议是没必要。如果工作有密级要求，可以直接使用公司统一提供的审计安全的接口。本地部署的模型参数量不可能太大，即便是主流顶配的机器跑个 72B 已经是极限了，但和各种满血版模型动辄 300B+、500B+、800B+ 的参数量一比，几乎就是小学生和研究生的区别，本身是为了提效的，没必要给自己添堵。专业领域的专用小规格模型可以尝试，但也仅限于特定任务再去使用。默认情况下，Agent 应当使用最好的模型，有条件的话 All in Claude Opus 4.6 / GPT-5.4 也不是不可以，反正你的 Token（经费）将会熊熊燃烧。
非技术人员是否需要
普通人到底要不要用它？我的建议是：应用尽用。但他对每个人效率的提升程度因人而异，还是取决于自己本身——了不了解它、有没有足够的配置能力（包括虽然不会写代码，但能够以对话形式让 OpenClaw 自己更改配置的能力）。
最次，哪怕干不了活，他也能给大家当成个电子宠物提供情绪价值。
随着对 AI 的理解的不断深入，我想越来越多的人也会发现，在 AI 应用越来越普及的情况下，增加人力反而会成为实现真正意义上降本增效目标的重要一环。因为 Token 的价格和我一直以来预测的趋势一样，真的是变得越来越贵。
