篷汎山去年年底我接触了一个叫 OpenClaw 的开源项目，最初只是抱着“装个智能体玩玩”的心态，结果花了两天时间把文档啃完、环境跑通、再接入豆包之后，我突然意识到这类工具才是未来几年个人和团队真正会用上的东西。它不是一个聊天机器人，而是一个能直接操作电脑、读写文件、执行命令、调用工具完成任务的 AI 代理框架。这篇文章就围绕 OpenClaw 的本地部署、豆包接入这两个核心点，把整个实操过程、配置细节、踩坑记录完整梳理一遍，适合对 AI Agent 感兴趣的开发者、运维人员和所有想用大模型做点实事的人参考。文中提到的所有命令和配置文件都是我在 Windows 和 Linux 两种环境下实测过的，你可以直接照着做。
1. 核心思路：为什么要“本地部署”一个智能体，还要接豆包
1.1 OpenClaw 到底是什么
OpenClaw 这个名字可能很多同学还不熟悉，它是我目前见过的在“把大模型变成能动手干活的 Agent”这条路上做得最彻底的开源项目之一。它的前身是 Clawdbot，后来改名为 Moltbot，再后来改名为 OpenClaw，底层核心能力是把大语言模型接入到操作系统中，让模型可以执行 shell 命令、读写工作区文件、调用各种预置技能（skills）、访问网络甚至控制浏览器。简单说，你抛给它一个任务，它能自己去拆解、调用工具、逐步执行，最后把结果返回给你，而不是只停留在“对话”层面。
它的工作流程大致是：用户输入任务 -> 大模型理解任务并生成行动计划 -> OpenClaw 的 tools 层执行具体操作（命令、文件、HTTP 请求等）-> 执行结果反馈给大模型 -> 大模型决定下一步动作 -> 最终完成任务并向用户汇报。这套“Plan-Tool-Observation”的循环是几乎所有 Agent 框架的基础，但 OpenClaw 的特别之处在于它对本地环境的高度整合和相对完善的权限控制机制。
1.2 为什么选择豆包作为模型后端，而不是 OpenAI 或本地开源模型
部署 OpenClaw 本身只是第一步，真正决定智能体“聪明不聪明”的，是给它接上哪个大模型。官方文档里默认配置指向 OpenAI 或 Anthropic 的 API，但实际操作中你会发现两个痛点：一是网络和服务可用性不稳定，二是成本不低。我在测试阶段把当前主流的几类方案都过了一遍，最后还是把豆包作为主力后端保留了下来。
豆包的 API 接入地址是 https://ark.cn-beijing.volces.com/api/v3，它兼容 OpenAI 的接口协议，这意味着我在 OpenClaw 里不需要写任何自定义适配代码，只要把 API 地址、密钥、模型名填对就能直接跑通。另外它在中文理解和指令跟随上的表现非常稳，响应速度快，而且开通即用，不用自己折腾 GPU，这点对大多数个人用户来说极其重要。反而不少人热衷的“纯本地大模型”（通过 Ollama 跑 Qwen、DeepSeek 蒸馏版等）在实际使用中受限明显：硬件门槛高、推理速度慢、工具调用能力弱，稍微复杂一点的任务就容易失败。我把这类对比整理成了一张表，方便你根据自身情况做选型：
| 方案 | 优点 | 缺点 | 适合人群 |
|---|---|---|---|
| 豆包 API | 中文好、响应快、接入简单、价格低 | 数据要过云端、依赖网络 | 绝大多数用户 |
| OpenAI API | 生态成熟、工具调用能力强 | 国内访问不便、成本偏高 | 有稳定访问条件的开发者 |
| 本地大模型（Ollama） | 数据不出本机、完全可控 | 吃配置、速度慢、Agent 能力弱 | 有显卡的极客和隐私敏感场景 |
| 其他国产 API（DeepSeek、MiniMax） | 各有特色、价格实惠 | 兼容性参差、部分需额外适配 | 愿意花时间调参的技术用户 |
1.3 一次部署，理清“Agent 框架”和“大模型”的边界
我在做这次部署之前，其实对 Agent 和大模型的关系一直有点模糊。这次完整跑下来之后，我觉得可以打个比方：大模型是“大脑”，负责理解和决策；OpenClaw 是“手脚和神经网络”，负责把大脑的想法翻译成对操作系统的具体动作；豆包 API 则是一个“外包大脑”，你通过网络调用它来获得这个大脑的能力。三者之间通过标准 HTTP 接口通信，OpenClaw 不需要关心大脑有多大的参数量，只需要关心 API 是否兼容、返回质量是否够好。
这种分工带来的最大好处是“可替换性”。今天有更好的大模型出来了，你只需改一下 API 配置就能升级智能体；今天你想换个工具链，从 OpenClaw 换到其他 Agent 框架，只要原来的模型 API 不变，认知能力不会浪费。这也是我在这篇文章里特别想把“部署框架”和“接入模型”分开讲的原因。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与安装详解：从零到 OpenClaw 跑起来
2.1 安装前的硬件和系统要求
先泼一盆冷水：OpenClaw 并不是一个“浏览器里点两下就完事”的工具，它需要在真实的操作环境里安装运行。官方推荐的平台是 Linux 和 macOS，Windows 用户则需要通过 WSL（Windows Subsystem for Linux）来运行，这点我在 Windows 11 上实测过，走 WSL 2 的 Ubuntu 22.04 完全没有问题。如果你和我一样平时主力机就是 Windows，不要试图在 PowerShell 或 CMD 里直接跑 OpenClaw 的 bash 脚本，环境差异导致的坑会让你怀疑人生。
硬件方面其实没有太多要求，因为真正的计算发生在云端 API 里，本地 OpenClaw 只是一个控制层，2 核 4G 的小主机也能跑得很欢。系统里需要装好 Node.js 20+ 和 Git，因为安装脚本本质上是从 GitHub 拉代码然后执行。这里有个经验：如果你所在的网络环境访问 GitHub 不稳定，建议先设置好代理或者用镜像源，否则安装脚本很容易跑到一半断开，前功尽弃。
2.2 Windows 下的一键部署实操记录
Windows 环境下的“一键部署”其实是两步走：先装好 WSL，再在 WSL 里执行 OpenClaw 的安装脚本。如果你还没有装 WSL，在管理员 PowerShell 里敲一句：
powershell复制wsl --install -d Ubuntu-22.04
装完后重启，进入 Ubuntu 终端，更新一下系统包：
bash复制sudo apt update && sudo apt upgrade -y
然后是正式安装 OpenClaw，官方脚本是：
bash复制curl -fsSL https://openclaw.ai/install.sh | bash
这一步强烈建议全程开着代理（如果你有的话），因为脚本会从 GitHub Release 下载预编译的二进制包，国内直连速度时快时慢，我遇到过下载卡住 20 分钟不动的情况。脚本跑完后，它会自动在 ~/.openclaw 目录下生成初始配置和 workspace。如果你看到终端输出类似 install completed successfully，说明基础环境已经就绪。我安装时是 OpenClaw 0.2.x 版本，后来升级到了 0.3，配置格式有微小变化，但总体向下兼容。
2.3 Linux 服务器部署：比你想的更简单
如果你有一台云服务器，部署起来其实更直接，因为不需要 WSL 这层转换。我用一台 Ubuntu 22.04 的 2C4G 轻量服务器做过验证，同样的命令：
bash复制curl -fsSL https://openclaw.ai/install.sh | bash
这个脚本默认会以当前用户身份安装到用户目录下，但我建议你用一个专门的账号来跑，不要拿 root 直接跑，毕竟它要执行命令、读写文件，权限隔离总归是好的。装完之后可以通过 claw --version 验证安装是否成功，能输出版本号就说明二进制没问题。这里要注意一点：OpenClaw 的安装脚本会往 ~/.bashrc 里写入环境变量，如果你换了终端或者通过 SSH 非交互式登录，可能找不到 claw 命令，需要手动执行 source ~/.bashrc 或重新登录。
2.4 安装完成后的目录结构和第一印象
安装完成后，你会在用户主目录下看到一个 .openclaw 文件夹，这是 OpenClaw 的核心目录，里面默认包含：
openclaw.json：主配置文件，模型连接、工具开关、权限设置都在这里；workspace/：这个目录相当于 AI 的“工位”，它干活时读写文件、创建项目都在这个目录里，不会乱跑到系统其他地方；exec-approvals.json：命令执行授权记录，AI 执行敏感命令前会先查这个文件；logs/：运行日志，排查问题基本靠它。
我第一次看到 workspace 这个设计的时候觉得挺奇妙——给 AI 划了一块固定地盘，它只能在里面折腾，这其实是相当安全的设计。后面配置豆包的时候，我只需要改 openclaw.json 这一个文件，其他目录都不用动。所以这里建议先 cat ~/.openclaw/openclaw.json 看一眼默认配置，了解有哪些字段，再动手改。
3. 接入豆包：配置文件的每一处细节都在这里
3.1 拿到豆包的 API Key 和模型 ID
要接入豆包，第一步是注册一个火山引擎方舟账号，然后在“开通管理”里找到豆包大模型服务并开通。开通后创建一个 API Key，这个 Key 在调用时作为 Authorization: Bearer 请求头传入。另一个关键是“模型 ID”，很多新手在这里翻车：豆包不是通过“模型名称”来调用的，而是通过一串以 doubao- 开头的模型 ID，比如 doubao-seed-1-6-250615，不同的形态和应用场景对应不同的 ID。
我的建议是直接在方舟控制台的“在线推理”里创建推理接入点，创建时会让你选择模型版本，完成后系统会生成一个 ep- 开头的接入点 ID。虽然用模型 ID 也能直接调，但接入点的好处是：将来豆包升级版本时，你只要在控制台切换接入点指向的模型版本，OpenClaw 端的配置完全不用动。实操中我用的是 ep-202501xxxxx 这种接入点 ID，实测在 OpenClaw 里和模型 ID 一样可以正常识别。
3.2 修改 openclaw.json：核心配置逐行解读
找到 openclaw.json 后，用编辑器打开，核心的模型配置块大概是这样的结构：
json复制{
"model": {
"provider": "custom",
"name": "ep-202501xxxxx",
"baseUrl": "https://ark.cn-beijing.volces.com/api/v3",
"apiKey": "你的豆包API Key",
"options": {
"temperature": 0.7
}
},
"tools": {
"exec": {
"enabled": true
},
"web": {
"enabled": true
}
}
}
这里的几个字段要解释一下。provider 可以填 openai 或 custom，实测填 custom 更稳妥，因为 OpenClaw 对豆包的接口兼容性判断会更宽松一些，不会要求额外的参数。baseUrl 就是豆包 API 的根地址，不需要带 /chat/completions，框架会自己拼接。name 字段放模型 ID 或接入点 ID，注意不要带引号里面多余的空格。
一切就绪后，在 WSL 里输入 claw 进入交互界面，看到提示符后直接问一句“你好，请介绍一下你自己”，如果它用中文回答，说明豆包接入成功了。我第一次在这里卡了很久，后来发现是 baseUrl 末尾有多余的空格，导致请求 404，清理掉空格就好了。这个细节一般人真不会注意，写出来帮你避坑。
3.3 扩展配置：工具开关和额外的豆包参数
除了最基本的 model 配置，OpenClaw 对工具（tools）的开关控制也很有讲究。默认情况下，command execution（执行命令）、web search（联网搜索）、memory（记忆）等工具并不是全部开启的，你需要按需在配置里打开。我当时为了让它能帮我处理本地文件，重点开了 exec 和 file 相关的能力，因为 Agent 最核心的“动手能力”几乎全靠这两个工具支撑。如果你要测试它连网抓取信息，就把 web 打开，但要注意这个功能会消耗额外的 token，因为网页内容需要先转成文本喂给模型。
豆包 API 也有一些调节参数值得玩味。比如 temperature，在写代码的辅助场景里，我建议设为 0.3 左右，这样输出更稳定、更少“自由发挥”；如果是闲聊或头脑风暴，则可以调到 0.8。还有 max_tokens 参数，豆包默认单次输出长度有限，较大的任务很容易截断，我在配置里把它调到了 4000 以上，基本能覆盖大多数需求。这些参数在 OpenClaw 的 model.options 里都可以配置，具体字段名是 maxTokens 驼峰形式，这是个容易踩坑的细节。
3.4 配置 exec approvals：给 AI 加上“安全锁”
OpenClaw 有一个人性化的设计，叫 “exec approvals”。因为 AI 要执行系统命令，这本质上是有一定风险的，所以框架允许你配置哪些命令属于敏感命令，AI 在执行前必须获得你的确认。配置文件里就是 ~/.openclaw/exec-approvals.json。当你启动 OpenClaw 时，如果这个文件不存在，系统会提示你说 legacy exec approvals 存在于某个路径，并问你如何处理，通常回车确认即可。
我强烈建议你把 rm、mkfs、shutdown、reboot 这类高危命令放进审批列表，也就是说 AI 执行它们时必须弹窗问你。不要偷懒把所有命令都放行，否则某天你让 AI 整理目录时它手滑把文件删了，那才叫真的头疼。这个“安全锁”是 Agent 工具和普通聊天机器人最大的区别之一，千万不要嫌麻烦。
4. 实操过程：从创建 workspace 到让豆包驱动的 AI 自动干活
4.1 给 AI 一块专属工作区：clone 或新建 workspace
OpenClaw 的安装默认会创建一个 workspace 目录，但我的建议是给不同项目建不同的工作区，比如 workspace/project-a 和 workspace/project-b，这样 AI 在项目 A 中产生的所有文件不会污染项目 B。进入 OpenClaw 交互界面后，通过命令可以查看当前所在 workspace，默认也支持 cd 切换目录，体验上更像在一个终端里干活。
如果你是想让 AI 在已有项目基础上工作，直接把代码仓库 git clone 到 workspace 里即可。我用这个方法让 AI 帮我看一个老旧项目的日志文件，它先定位到路径、再执行 tail 命令、分析异常原因，最后生成一份简要报告，整条链路非常顺畅。对 AI 来说，明确的执行环境就是最大的效率保障。
4.2 一个完整的实战：让 AI 用豆包能力写一个 Python 脚本
这里分享一个我实际跑通的任务。我让 OpenClaw 在 workspace 下写一个 Python 脚本，功能是扫描指定目录下超过 1GB 的大文件，并按大小排序输出。整个过程我只说了一句话：“请在 workspace 下写一个 Python 脚本，扫描当前目录下所有超过 1GB 的文件，并按大小降序输出。”
接下来它做的事情是这样的：先通过 ls 和 du 命令了解当前目录情况，然后用 cat 写了一个 Python 文件，再执行 python3 运行它。中间它还主动检查了 Python 环境是否存在，确认无误后才继续。这就是大模型和工具链配合的威力，跟纯写文本的 AI 完全不是一个层级。不过我也注意到它有些习惯并不完美，比如生成脚本时没有考虑隐藏文件，这些就需要后续用人话补充需求来纠正。
4.3 调试技巧：看日志、看 token 消耗、逐步验证
在实际操作中，如果 AI 某一步卡住了或者执行结果不符合预期，最有效的办法是看 OpenClaw 的日志。日志默认在 ~/.openclaw/logs 下，包含模型请求的输入输出、工具调用的参数和返回结果。很多时候你以为模型“答错了”，翻日志才发现其实是工具返回了异常数据，导致模型感知出现偏差。
另外 token 消耗也是一个需要关注的指标。豆包 API 有控制台可以实时查看调用量和费用，OpenClaw 在执行多步任务时，每一步都会把中间结果送回模型，这个过程消耗的 token 远比一次对话多。建议你在配置里设定一个合理的 max_tokens 上限，避免复杂任务把预算烧穿。我自己跑一个复杂的多步骤任务，消耗量大约在 1-2 万 token 左右，豆包的价格下这个量级通常几厘钱，完全在可接受范围内。
4.4 豆包 API 的参数调优：针对不同任务的推荐值
基于我多次实测，针对不同任务我给豆包 API 总结了几个推荐参数组合。日常对话和答疑场景，temperature 设 0.7，max_tokens 设 2000 左右，兼顾稳定性和多样性；代码编写和文件处理场景，temperature 降到 0.2，max_tokens 调到 4000+，减少模型自由发挥，保证输出内容完整；长文档分析场景，建议把上下文窗口相关的配置调到大模型支持的最大值，因为 OpenClaw 会把整份文档内容拼接进上下文，如果你的窗口太小，模型就会截断导致分析不完整。值得注意的是，OpenClaw 对超长上下文的处理是分段式的，实际测试下来，豆包对中文长文的聚焦能力相当不错。
5. 常见问题与避坑实录
5.1 启动时报 "legacy exec approvals exist" 怎么处理
很多用户第一次启动 OpenClaw 时会看到类似这样的提示：
text复制legacy exec approvals exist at /root/.openclaw/exec-approvals.json. Run `openclaw approvals migrate` to migrate them.
这其实是框架升级后引入了新的权限管理机制，旧版本生成的 exec-approvals.json 格式不被新版本直接识别，需要迁移。处理方式很简单：照着提示执行迁移命令即可，或者如果旧文件里没有任何重要的授权记录，直接把它备份后删除，让 OpenClaw 自动生成新的默认文件。如果版本比较新（0.3+），还有一个更简单的办法是直接运行 claw 命令，它会以交互方式询问你如何处理，回车选择默认迁移即可。
5.2 接入豆包后 AI 不回复或回复报错
如果豆包接入后 AI 完全无响应，或者回复一大段 JSON 错误信息，90% 的情况出在配置上。最常见的是 baseUrl 写错，比如末尾忘记加 /api/v3 或者多了空格；其次是 API Key 没有权限，需要在火山引擎控制台确认 Key 对应的账号已经开通了豆包服务；还有一种情况是 name 字段填了不存在的模型 ID，或者接入点 ID 被误删了。这里面有个快速排查法：先用 curl 直接请求豆包 API，确认自己的 Key 和模型 ID 本身没问题，再回过来查 OpenClaw 的配置。
我自己当时就犯过一个愚蠢的错误：把 API Key 复制到了 name 字段，导致模型名变成了乱码，AI 压根不知道自己在用哪个模型，回复牛头不对马嘴。所以配置完第一件事就是打开日志看一眼请求的 body，确认模型名、key、url 都正确。
5.3 内存占用过高和进程卡死的解决经验
本地跑 OpenClaw 的时候我发现它虽然只是一个控制层，但长时间运行后内存占用会缓慢上升，特别是在跑完复杂任务后。这是因为 OpenClaw 会在内存里缓存对话历史和工作状态，任务越复杂缓存越大。目前没有太完美的自动清理机制，我的做法是定时重启服务，或者在长时间不用时主动退出交互式会话，释放内存。
另外一个卡死场景是在执行某些长时间运行的命令时，OpenClaw 会一直等待命令返回，看起来就像卡住了。这时候不要急，等它自己超时就好。如果实在等不了，可以在配置里调整命令执行的超时时间，把默认的 30 秒改成 60 秒或更长，但要小心这会让某些挂死的命令拖更久。
5.4 豆包输出被截断和 JSON 解析失败的应对
在使用 OpenClaw 时你会发现，它的工具调用本质上是让模型输出一个结构化 JSON，如果这个 JSON 不完整或者格式错误，整个链路就会中断。豆包作为大模型，偶尔也会犯这个毛病，尤其是当 max_tokens 设置过小，模型话没说完就被强制截断时。解决的思路有两个：其一，把 max_tokens 调大，给模型足够的输出空间；其二，如果发现某种固定模式总是触发截断，可以在提示词里加一句“请确保输出完整的 JSON 结构，不要省略任何字段”，效果立竿见影。
还有一个野路子是：给 temperature 调低一点。temp 过高会让模型更发散，输出更容易跑偏，形成不规范的 JSON。我踩过几次坑之后，在代码生成类的任务里一律使用 temp = 0.1，不能说 100% 不出错，但概率大大降低。
5.5 合规与安全提示
本地部署 AI Agent 本身就意味着你要把一部分系统操作权限交给 AI，所以我有几条个人总结的安全边界：第一，绝对不要用 root 或其他管理员账号运行长时间无人值守的 OpenClaw 服务，尽量用低权限用户；第二，不要把高敏感信息写在 workspace 里，因为所有文件内容都可能作为上下文发送给云端模型；第三，执行高危命令前一定要确认当前环境没有其他人会被影响，尤其在自己不熟悉的服务器上。豆包作为云端 API，它对内容也有相应的过滤机制，日常使用没有任何问题，但涉及敏感生产环境的操作最好还是人工把关。
6. 实测体验与后续扩展玩法
豆包接入 OpenClaw 之后，我用它做了一些日常工作，比如写自动化脚本、整理日志、批量处理文件名、生成周报初稿。总体感觉是：它的中文理解能力比很多海外模型更适合处理中文命名和中文语境，而且响应速度很快，基本感觉不到延迟。在“工具调用”这个关键点上，豆包对 OpenClaw 发出的 JSON 指令理解准确率也很高，至少在我测试的十几个任务里没有一次因为模型原因导致工具调用失败。
后续我还打算试试 OpenClaw 的 skills 机制，给它配置一些自定义技能，比如自动部署、自动测试，这样它就不只是“会聊天”，而是真正成为团队里一个个人的“动手专家”。同时也计划试一下 OpenClaw 连接飞书或钉钉，这样在移动端也能随时给它派活。这套东西的价值，不在于模型本身多聪明，而在于模型的能力终于可以落成系统里的真实操作，这比多问它几个问题有意义多了。