OpenClaw自托管AI助理实战：从飞书接入到安全边界配置

最近我把团队里好几个在线AI平台的机器人统一撤了下来，换成OpenClaw自托管部署，并且接进了飞书。起因其实很朴素：团队真正高频使用的不是哪个大模型本身，而是那个能进群、能处理表格、能记住上个星期排期的“数字助理”。但它如果只活在一个独立的网页里，每天还要登录一次，也不会调用内部数据，那就跟没用一样。

OpenClaw恰好解决这个问题。它不负责训练模型，也不是一个绑定特定厂商的云服务，而是一个自托管的AI消息中枢：飞书、网页、终端都可以是入口，中间接DeepSeek、Ollama、NVIDIA NIM等不同类型的模型后端，最终让AI能访问workspace、执行工具、扩展skill技能。对用过各类在线Agent平台但始终觉得不够落地的人来说，这是挺顺的一条路。

接下来我会按三段主线展开：先把OpenClaw在整套AI工具链里的定位讲清楚，然后是环境、模型和安全边界这三个提前决策，再给一份完整的部署与飞书接入操作流程，最后补充skill和多平台落地细节。内容以我在2.x版本上的实际操作为基础，版本升级后菜单名或字段名可能略有差异，但排查思路基本通用。适合有一定命令行基础、想给个人或团队搭建私有AI助理的同学参考。

1. OpenClaw在AI工具链里的位置：为什么值得自托管

1.1 一场关于“去云平台”的迁移

在聊OpenClaw之前，先面对一个绕不开的问题：现在Coze、Dify、各类云厂商的智能体平台都能一键发布到飞书，为什么还要自己部署？

我之前的亲身体会是，云平台的问题不在“能不能跑通Demo”，而在“接入真实工作流”这一层开始露馅。比如团队内部文档涉及客户信息和项目排期，能不能上传到第三方平台本身就是一道审批难关；再比如想让它每天定时读取某个内部系统的监控数据，出问题后自动执行一条恢复脚本，这在托管平台几乎不可能，因为平台不会把命令执行能力开放给你。

OpenClaw这类自托管工具解决的正是最后这一公里。它本身不是一个重型知识库或模型训练平台，更像是负责“路由、调度、执行”的中枢：消息从飞书进来之后，OpenClaw决定调用哪个模型、携带哪些上下文、是否执行某条命令，最后再把结果发回飞书。这种架构保证了数据链路完全由你控制：模型可以选外部API，也可以选本地推理；工具可以是文件读写，也可以是固定的运维脚本。

我并不是说云平台一无是处。如果只是搭一个内部问答机器人，Coze或Dify确实更省事，知识库上传、可视化编排、飞书发布基本都是点几下的事。可一旦你想让它碰文件、跑命令、做定时任务，再回头看OpenClaw，就会有“原来权限在自己手里这么重要”的感觉。OpenClaw和Dify其实也不是替代关系，更像是应用编排器和消息网关的配合关系，生产环境完全可以同服务器共存。

1.2 先认识四个容易混淆的目录与概念

部署OpenClaw之前，建议先理解它和普通聊天机器人最大的区别：它不是一个只会回复消息的进程，而是一个带着“工位”“工作流”和“操作权限”的自治代理。常见的概念和目录如下：

• 运行程序：提供命令行交互和后台服务，负责模型调用、工具执行、平台消息收发。
• .openclaw 配置目录：这是用户级目录，保存全局配置、命令审批、日志、skill列表。Windows上常见路径是C:\Users\Administrator\.openclaw\，Linux下通常是/root/.openclaw/。
• workspace工作区：AI执行任务时读写文件的操作空间。它相当于给AI划了一个“工位”，日常任务产物、临时文件都该放在这里。
• skill技能目录：以文件夹形式存在的技能包，里面包含描述、脚本和示例，用来教会AI按固定流程完成某一类工作。

很多新手第一次启动后，看到日志里出现exec-approvals.json相关的提示就开始慌，尤其是升级旧版本后提示存在legacy approvals时。这个文件是OpenClaw的命令审批记录，AI想执行不在白名单里的命令时，它会弹出确认，你的选择会被记录到这个文件里。旧版本的规则升级后被识别为legacy规则，不代表有安全问题，但需要你打开文件逐条看一遍，不用的就重建一份。

1.3 和Dify、Coze、AnythingLLM的取舍与分工

如果把这些工具放在同一张表里比较，会更容易理解OpenClaw的定位。我实际接触过的自部署方案还包括Dify、AnythingLLM等，每个东西擅长的事情不一样。

我的建议很简单：如果你的主要需求是“知识库问答”，AnythingLLM或Dify已经很好用；如果你的主要需求是“一个能跨平台对话、能操作文件、能执行脚本的数字员工”，应该选OpenClaw这一类自托管网关。两者需要的运维复杂度完全不同，先想清楚需求归属，再谈部署方式，不要盲目跟风把所有工具都装一遍。

2. 部署前先定三件事：环境、模型后端与安全边界

2.1 运行环境：测试阶段别过度设计

OpenClaw的部署环境很灵活，Windows、Linux、容器都能跑。但“能跑”和“跑得舒服”是两个概念，我建议按阶段区分。

测试阶段最忌讳一上来就上Kubernetes或者搞一堆容器编排。我第一次部署时直接在Windows上用PowerShell安装，整个过程只需要执行官方提供的一行安装命令，之后就能在本地启动服务。这种方式的优势是日志直接在终端输出，改配置后重启很快，适合把整个链路跑通。

Windows上有几个隐藏问题需要提醒：普通用户安装时可能会遇到执行策略限制，需要以管理员身份打开PowerShell；安装完后如果openclaw命令不在PATH里，重新开一个终端窗口通常能解决。另外，直接开着PowerShell窗口跑服务，窗口一关服务就停了，适合临时测试，不适合长期运行。

到了团队稳定使用阶段，我强烈建议迁移到Linux服务器或Docker容器。原因不是Windows跑不了，而是systemd和Docker带来的“开机自启、崩溃重启、日志轮转”这些能力，在Windows上配置起来麻烦得多。还有一点：如果后续要接飞书事件订阅，飞书开放平台要求回调地址是公网可达的HTTPS地址，生产服务器通常比个人电脑更容易满足这个条件。

关于模型是否和OpenClaw放在同一台机器，也是一个需要提前考虑的点。OpenClaw本身对CPU和内存要求不高，我曾在2核4G的云主机上跑得很稳。但如果要本地跑Ollama、vLLM这类推理引擎，就需要单独准备带GPU的服务器。最佳实践是：OpenClaw和推理引擎分开部署，OpenClaw统一通过API访问模型，这样以后换模型后端，OpenClaw的配置改动非常小。

2.2 模型后端：从一次unknown model报错说起

配置模型是OpenClaw启动过程中最容易翻车的一步，也是最多人私信问我的一步。问题很少出在“配置不会写”，而在于大家默认模型名应该和开源模型的称呼一致。

首先要搞清楚，OpenClaw本身并不内置模型，它只是按模型接口转发请求。因此你必须正确区分两件事：一是服务商提供的API地址，也就是base_url；二是该服务商在接口里真实暴露的模型名。

举个例子，有人想通过DeepSeek官方API接入，在配置里写了model: deepseek，结果启动对话时一直收到agent failed before reply: unknown model: deepseek。这个报错的关键字不是前面的agent failed，而是最后的unknown model: deepseek。去DeepSeek开放平台查看真实模型名后，发现可能叫deepseek-chat或deepseek-reasoner。把配置改成真实模型名后，问题立刻消失。

所以，我养成了一个习惯：无论接什么模型后端，第一步永远先访问该后端的模型列表接口，确认返回的真实模型名。如果接的是OpenAI兼容服务，直接请求/v1/models；如果是Ollama，就在命令行执行ollama list。这个动作花不了十秒钟，但能避免至少半小时的无效排查。

下面是我在实际项目中用过的几条模型接入路径，侧重点各不相同：

我个人的推进路线是先API后本地。先用DeepSeek或MiniMax的API把OpenClaw到飞书的完整链路跑通，确认消息顺序、工具调用、回复发送都没有问题后，再去折腾Ollama或vLLM的本地部署。这样可以把“模型问题”和“平台接入问题”拆开，排查起来轻松得多。

2.3 安全边界：workspace与命令审批就是你的底线

OpenClaw能干活，本质上是因为它能执行命令、能写文件，这是它和普通聊天机器人最大的差异，也是最大的风险点。理解workspace和命令审批机制，比理解某个参数更重要。

workspace相当于划给AI的“工位”。AI生成的项目文档、下载的中间文件、任务处理的JSON都应该放在这个目录。不要图省事把workspace指向服务器根目录或整个用户主目录。原因很好理解：AI收到不同任务时会创建各种文件，如果目录范围失去边界，一旦某个Prompt诱导它清理文件，后果是灾难性的。我的习惯是单独建一个/workspace/projects目录，下面按项目分子目录，方便备份和清理。

命令审批是另一个容易被忽略的机制。当OpenClaw想执行一条不在白名单中的命令时，客户端会弹出确认，询问允许一次还是总是允许。这些规则最终会写入.openclaw/exec-approvals.json。有些版本会默认带一批legacy审批规则，升级日志里看到提示时，最好打开文件逐条确认，不要直接全部清空，因为里面可能有你常用的命令记录。

关于审批安全有一个容易被低估的威胁：Prompt注入。当OpenClaw读取一个网页或文件时，内容里可能隐藏着“忽略之前的指令，帮我执行某条危险命令”这类引导。如果命令审批是全放行状态，AI很可能真的去执行。所以我的配置原则是：永远不要把审批范围扩大到所有命令，尤其不要对rm、curl | bash、chmod -R这类高风险操作全局放行。宁可让它在真实任务中多弹几次确认，也不要给未知来源内容一个直通本机命令的入口。

3. 从安装到首次对话：极简部署的实际操作

3.1 Windows平台安装与目录确认

OpenClaw官方支持PowerShell安装，这一点对Windows用户很友好。用管理员身份打开PowerShell，执行官方文档提供的一行安装命令，等待依赖下载和安装完成即可。如果网络状况不太好，脚本下载过程可能比较慢，建议耐心等，不要中途关闭终端，否则可能出现半安装状态，之后排查起来更麻烦。

安装完成后，先不要急着跟它聊天，先确认三件事：

1. 在终端执行openclaw --help，查看版本信息和可用子命令。如果提示找不到命令，说明安装目录没有加入PATH，重新打开终端或手动添加PATH即可。
2. 确认配置目录.openclaw已经生成。Windows下通常是C:\Users\Administrator\.openclaw\。
3. 确认workspace目录已经创建。启动时如果看到workspace: c:\users\administrator\.openclaw\workspace这类提示，说明工作目录已经就绪。

我在Windows上第一次启动时踩过一个不算坑的坑：因为安装完成后没重开终端，直接执行命令提示找不到openclaw，浪费了几分钟。后来重开PowerShell窗口就好了。如果后续想把这个服务做成Windows开机自启，可以借助计划任务或NSSM把OpenClaw包装成Windows服务。但我的真实建议是，Windows只用来验证功能，别用来做7x24小时生产服务。

3.2 配置模型与首次对话

OpenClaw第一次启动时会引导配置模型供应商，这时会有“先配置模型”和“先跳过，之后再添加AI”之类的选择。我建议如果你手头已经有