1. 项目概述1.1 从一只“会动手的章鱼”说起我最早接触 OpenClaw是因为被朋友的演示视频种草他用一条自然语言说出“帮我把某个群里的表格整理出来再按优先级发到飞书”随后 OpenClaw 就像个老练的运营助理一样自己调用模型、检索上下文、组织消息最后真的把整理好的表格发到了飞书群里。整个过程没有写一行代码只在配置文件里改了几段 YAML。这个项目本质上是一个通用 Agent 执行框架——你可以把它理解成“给大语言模型装上了手和脚”。它内置了消息收发、文件读写、会话管理、多轮工具调用等能力对接不同的模型服务DeepSeek、MiniMax、千问等以及 IM/办公平台飞书、微信、Discord 等让模型不再只停留在“能聊天”而是能真正执行任务、操作文件、回复消息。很多人问我和 WorkBuddy 哪个好我的看法是WorkBuddy 更像一个开箱即用的成品工作室OpenClaw 则更像一套可自由组合的积木。如果你希望深入控制 Agent 的行为、切换多个模型、对接私有服务OpenClaw 更合适如果你只想要一个现成的本地助手那 WorkBuddy 可能更省心。本文会围绕 OpenClaw 的完整安装、MiniMax/DeepSeek 模型接入、飞书机器人接入这三条主线展开适合刚接触 Agent 框架的开发者也适合想在本地把 AI 真正用起来的人参考。1.2 这次要解决的核心问题我在实际部署前其实踩了不少坑。最初的诉求很简单本地跑一个 Agent能通过飞书接收指令用 DeepSeek/MiniMax 生成内容并发送表格。但真做下来发现配置链路比想象中长OpenClaw 本身需要先跑起来模型服务要能连通飞书那边要建应用、配事件订阅、处理回调还要处理消息截断、会话锁冲突等问题。所以这篇文档不只是把安装步骤罗列一遍我会把每一步背后的取舍逻辑和踩坑记录也写出来。比如为什么我最终选择本地部署 OpenClaw而不是直接依赖云端 IDE 或第三方托管MiniMax H3 和 DeepSeek 的 API 接入方式有什么区别飞书机器人发送表格时为什么经常被截断要怎么通过 message 分段和富文本解决本地模型接入后“反应慢”到底慢在哪一环如何定位瓶颈。如果你是带着“我也要搭一套”的目的打开这篇文章建议按顺序从环境准备开始走如果你已经搭到一半可以直接跳到 4、5 两节看问题排查和避坑清单。2. 环境准备与安装方式2.1 安装 OpenClaw 前的系统要求先聊环境。OpenClaw 对系统的要求不算苛刻但也不像普通 npm 包那样装完就跑。它在运行时会拉起多个子进程还需要访问本机文件系统、网络端口以及外部 API。所以我建议至少满足以下条件操作系统LinuxUbuntu 22.04 或 Debian 12 最佳、macOS、Windows通过 WSL2。我实测 Windows 原生跑容易出权限和路径问题建议统一走 WSL2。CPU/内存纯 API 模式使用云端 DeepSeek/MiniMax下2C4G 的云主机也能跑但如果你要接入本地大模型建议内存 16G 以上否则很容易 OOM。Node.jsOpenClaw 依赖较新的 Node.js 运行时建议版本 ≥ 18。用 nvm 安装会省很多事。网络需要能访问 OpenAI/DeepSeek/MiniMax 等模型 API。国内直连部分服务稳定性较差建议准备稳定的网络出口或反代并做好超时设置。为什么要提 Node.js 版本因为 OpenClaw 的依赖列表里有不少 native 模块比如 sharp、sqlite3如果 Node 版本过老或过新编译阶段就会直接报错。我的建议是直接用 nvm 锁定一个 LTS 版本避免后面折腾。2.2 安装包选择npm 全局安装 vs 源码编译OpenClaw 提供两种主要安装方式npm 全局安装命令很简单npm install -g openclaw装完直接openclaw --version验证。这种方式适合绝大多数用户安装快、更新方便。源码编译安装从 GitHub 拉取源码后自行构建git clone https://github.com/your-repo/openclaw.git cd openclaw npm install npm run build npm link这种方式适合需要改源码、调试核心逻辑的开发者。我建议普通用户直接选第一种因为源码编译会多出很多构建时间和潜在的依赖冲突问题除非你有二次开发需求否则没必要。实际安装时有一个常见坑npm 全局安装后在 WSL2 里运行openclaw可能提示“command not found”。这通常是因为 npm 全局目录没有加入 PATH需要把 npm prefix 配到.bashrc里echo export PATH$(npm prefix -g)/bin:$PATH ~/.bashrc source ~/.bashrc装好之后我习惯先跑一遍openclaw doctor看环境是否健康。它会自动检测 Node 版本、网络连通性、配置文件格式等比直接开跑更容易发现问题。2.3 初始化配置目录安装完成后需要初始化配置目录。第一次运行openclaw init这个命令会生成~/.openclaw/目录里面至少包含config.yaml主配置文件模型、通道、密钥都在这里修改agents/存放 Agent 定义文件不同角色的 prompt、工具集、模型绑定sessions/会话记录与上下文存储目录logs/运行日志。我第一次初始化时只改了 config.yaml结果发现 Agent 的默认行为完全不是我想要的。后来才意识到 OpenClaw 是一个“多 Agent 架构”——你可以在 agents 目录下定义多个角色每个角色可以绑定不同的模型、使用不同的工具。这个设计非常灵活但也意味着你要理解它的配置层级否则会像我一样以为“改一处就能全局生效”。2.4 Linux 下的启动与守护在 Linux 服务器上跑 OpenClaw建议用 systemd 做成服务避免关闭终端后进程退出。下面是一个最小 unit 文件放在/etc/systemd/system/openclaw.service[Unit] DescriptionOpenClaw Agent Service Afternetwork.target [Service] Useryourname WorkingDirectory/home/yourname/.openclaw ExecStart/usr/bin/openclaw start Restartalways RestartSec5 [Install] WantedBymulti-user.target启用命令sudo systemctl daemon-reload sudo systemctl enable openclaw sudo systemctl start openclaw用 systemd 管理的好处不只是“开机自启”更重要的是日志集中到 journald出问题时可以用journalctl -u openclaw -f实时跟踪排查效率高很多。3. 模型接入MiniMax 与 DeepSeek3.1 模型接入的整体思路OpenClaw 本身不做模型推理它只是把任务拆解成工具调用再交给模型去决策。因此接入模型的核心就是给 OpenClaw 配置模型 Provider、API Key和模型名称。一个重要的概念是OpenClaw 里的“模型”通常以 Chat Completion 接口为主所以只要目标模型厂商提供 OpenAI 兼容接口就可以直接配置。这也是为什么 DeepSeek、MiniMax、千问这些国内模型都能顺利接入——它们基本都做了 OpenAI 兼容层。如果你只接一个模型配置很简单但如果你想在多个 Agent 间切换模型比如简单摘要用 DeepSeek复杂多媒体任务用 MiniMax就需要理解 OpenClaw 的agents配置结构给不同角色绑定不同的模型。3.2 接入 DeepSeek 的完整配置DeepSeek 的 API 兼容 OpenAI 格式openclaw.yaml 里的配置大致如下model: provider: deepseek api_key: sk-xxxxxxxx model_name: deepseek-chat base_url: https://api.deepseek.com/v1需要注意几个细节base_url必须带上/v1如果只写到https://api.deepseek.com部分接口会 404。deepseek-chat是通用对话模型适合大多数文本任务如果要更强的推理能力可以换成deepseek-reasoner但响应会更慢。如果你开了fetch_timeout或类似参数建议调到 120 秒以上否则模型推理时间稍长就会被 OpenClaw 判定为超时直接报agent failed。DeepSeek 的接口并发限制相对较低。如果 OpenClaw 配置了多个 Agent 并行跑建议在请求层做限流——OpenClaw 的max_concurrent_requests参数可以控制并发数默认值可能偏大。DeepSeek API 调用时工具调用tool call场景下有一个很容易踩的坑OpenClaw 要求消息中 tool call 必须立即被工具执行并回传结果不能延迟到下一轮。如果你在日志里看到deepseek messages tool calls need immediate results说明你用的模型或代理把工具调用结果延迟了比如在中间加了缓存或人工审核。解决方式就是确保工具调用结果在同一个响应上下文里回传。3.3 接入 MiniMax含 H3 本地部署思路MiniMax 的接口整体也是 OpenAI 兼容的配置示例model: provider: minimax api_key: sk-xxxxxxxx model_name: MiniMax-Text-01 base_url: https://api.minimax.io/v1如果你是在国内访问可能需要把 base_url 换成国际站或你所在区的对应地址并且确认 API Key 和模型的区域匹配否则会一直报鉴权失败。MiniMax 除了云端 API还有 H3 系列模型。H3 在视频生成、图像理解、多模态任务上表现不错很多人会考虑本地部署。本地部署 H3 并不是一个轻量任务官方推荐配置里通常需要高性能 GPU显存越大越好对 CPU、内存也有要求。如果你真的要在本地跑 MiniMax H3我的建议是先用 ComfyUI 或类似工作流验证模型权重能否正常加载和推理确认推理框架如 vLLM、TensorRT-LLM是否支持 H3 的算子和量化方式不要一开始就接 OpenClaw先把模型单独跑通一个 HTTP 接口再用 OpenClaw 去请求这个接口。MiniMax H3 本地部署对显存的要求很真实普通单卡 3090/4090 跑小尺寸可能勉强但想跑中大型尺寸会非常吃力。而且“能加载”不代表“适合生产使用”推理速度、并发能力都是瓶颈。我自己的体验是如果只是给 OpenClaw 接一个多模态/视频模型优先用云端 API别急着本地部署。3.4 接入本地模型与 WorkBuddy 的对比OpenClaw 还支持通过 OpenAI 兼容的本地推理服务接入模型比如 vLLM、Ollama、LM Studio 等。配置一般如下model: provider: openai api_key: local-dummy-key model_name: my-model base_url: http://127.0.0.1:8000/v1接入本地模型后反应慢是非常常见的现象。我在实际对比过 WorkBuddy 和 OpenClaw 后发现慢不一定全在模型本身有时候是 OpenClaw 的会话锁定、上下文轮询、工具调用拆解带来的额外延迟。如果你的日志里出现agent failed before reply: session file locked (timeout 60000ms)那大概率不是模型慢而是会话文件被其他进程占用了。这时需要检查是否启动了多个 OpenClaw 实例或者关闭一些未正常退出的子进程。本地模型的响应慢还有一个原因是上下文长度。OpenClaw 会把历史消息一起传给模型如果历史消息太长本地模型的 prefill 时间会指数级上升。解决办法是在配置里限制max_context_tokens或者开启会话摘要功能让历史消息先被压缩再传给模型。3.5 模型选择建议DeepSeek 还是 MiniMax如果你要我给一个明确建议我会这样分场景说场景推荐模型理由通用文本对话、代码生成DeepSeek-chat / DeepSeek-reasoner成本低逻辑强API 稳定多模态理解、视频/图像类任务MiniMax 云端 API多模态能力强H3 在做视频理解时优势明显完全本地化、离线需求本地部署小模型数据不出内网但需要较强硬件和调优高并发、工具调用为主DeepSeek工具调用支持更稳延迟波动较小MiniMax 云端 API 在视频生成和多模态场景中真的很强但它的文本工具调用稳定性我在实际测试中感觉不如 DeepSeek 原生适配好。如果是长链路 Agent 任务建议核心文本决策用 DeepSeek多模态内容生成再单独调 MiniMax。4. 飞书机器人接入与消息处理4.1 创建飞书应用并获取凭证飞书机器人接入的基础是“创建一个飞书应用”。步骤并不复杂但每一步出错都可能让你在回调时一头雾水。1. 创建应用打开飞书开放平台点击“创建企业自建应用”填一个名称比如“Claw Assistant”然后进入应用详情。注意这里必须用真实企业账号创建个人开发者账号部分权限受限。2. 开启机器人能力在应用详情页找到“添加应用能力”选择“机器人”点击启用。启用后你会得到一个App ID和App Secret这两个值都会在 OpenClaw 配置里用到。3. 配置事件订阅飞书机器人要接收用户消息需要配置“事件订阅”。在事件订阅页面请求地址 URL 填 OpenClaw 暴露的公网地址比如https://yourdomain.com/openclaw/feishu添加事件im.message.receive_v1接收消息事件如果你要接收与消息相关的操作还需要添加im.message.reaction_v1等事件。这里需要特别强调飞书要求事件订阅地址必须能通过公网访问且响应要在 3 秒内完成。你可以先跑一个最简单的 HTTP 服务验证连通性否则后续回调失败很难排查。OpenClaw 内置了飞书适配器只要在配置里指定了正确的webhook_url和event_type它自己就能处理回调验证逻辑。4. 权限配置在“权限管理”里至少要开启im:message发送消息im:message:send_as_bot以机器人身份发消息im:resource如果需要接收图片、文件im:chat读取群组信息如果不开启权限你会在日志里看到类似“权限不足”的报错。这个报错很容易被误判为 token 问题其实只是 scope 没勾选。5. 发布版本完成上述配置后需要创建版本并发布。只有发布后的应用才有效。如果你在测试阶段也可以使用“测试企业与人员”的方式避免影响正常的生产应用。4.2 OpenClaw 与飞书连接的最小配置OpenClaw 里与飞书相关的配置大致长这样channels: feishu: app_id: cli_xxxx app_secret: xxxx event_type: im.message.receive_v1 webhook_url: https://yourdomain.com/openclaw/feishu send_method: message_api这里最关键的是send_method。如果你用message_apiOpenClaw 会调用飞书消息 API 发送文本或富文本如果你改成webhook就会用自定义机器人 Webhook 发送但接收消息的能力会受限。实际使用中我推荐用message_api方式配合飞书的/im/v1/messages接口可以发送更丰富的消息类型包括表格、卡片、富文本。用 webhook 的话虽然配置简单但没法精确控制消息结构而且容易触发频率限制。4.3 飞书机器人发送表格的实现很多人遇到“飞书机器人发送表格”的需求但 OpenClaw 默认发送消息时可能只是把表格内容当作纯文本贴在消息里结果列一变宽整条消息被飞书截断。这个问题在飞书里非常典型因为普通文本消息长度上限有限。我的解决方案是在 OpenClaw 的工具调用中先把表格内容渲染成 markdown 表格然后转换为飞书富文本 post 消息用post类型发送。飞书富文本对表格的支持有限但可以用“文本块缩进”的方式模拟表格或者直接把表格转成图片再发送。如果你只是需要快速把表格数据发给用户最简单的方式是让 OpenClaw 生成 CSV 或 Excel 文件然后用飞书文件消息接口发送。OpenClaw 的文件发送工具可以读取本地文件并调用飞书上传接口这样对方拿到的是一个真正的文件不会被截断排版也不会乱。我强烈建议不要试图用纯文本消息承载结构化表格。飞书对消息长度有限制而且中英文混排时换行经常出问题。用文件或图片方式发送表格体验会好非常多。4.4 飞书消息被截断的排查与对策“OpenClaw 在飞书输出容易被截断”是群里被问得最多的问题之一。我总结了几种常见原因和处理方法现象原因对策长文本被截断超过了飞书单条消息上限分段发送或转成文件表格排版错乱纯文本发送表格改用富文本 post 或发送文件消息内容缺失消息被飞书风控截断检查是否触发了频率限制降低发送频率始终只收到前几句OpenClaw 响应超时或 session locked加大超时时间检查进程并发在 OpenClaw 配置里还有一个开关可以控制消息分段发送channels: feishu: max_message_length: 4096 split_message: true开启split_message后OpenClaw 会把超长消息自动拆成多段避免因消息过长而被服务端拒绝。但要注意拆段之后消息顺序可能被打乱所以如果内容有严格顺序要求最好在 prompt 里就要求模型输出精简的分点内容。4.5 微信公众号与飞书的选择在这个项目里可能会有人问能不能直接接微信公众号答案是也能接但微信公众号的被动回复有 5 秒超时限制且消息类型和权限都不如飞书灵活。飞书在“机器人能力、事件订阅、富文本消息、文件上传”这些方面要完善很多所以如果你只选一个 IM 平台做 Agent 出口我推荐飞书。从实际体验看飞书机器人适合的工作流包括定时推送日报、群内问答机器人、审批提醒、表格文件自动发送等。对比企业微信/钉钉飞书的开放接口最接近“开发者友好”这几个字。5. 常见问题与排查技巧实录5.1 高频报错速查表在部署和实施中我整理了如下高频报错速查表。这张表的值在于当你遇到“agent failed”或“session file locked”时能快速定位方向而不是盲目重启。错误信息原因解决方案session file locked (timeout 60000ms)多个 OpenClaw 实例抢占同一个会话文件检查进程列表只保留一个实例删除sessions/下对应锁文件agent failed before reply模型 API 超时、配置错误或工具调用失败看日志从最底部的caused by往前追deepseek messages tool calls need immediate results工具调用结果传递延迟确认工具执行和结果回传是否在同一个响应上下文permission denied飞书应用权限未配置完整去开放平台权限管理里勾选对应 scopeInvalid base_urlbase_url 缺少/v1或写错按官方文档检查 base_urlECONNREFUSED本地模型服务未启动或端口错误确认推理服务已启动并测试curl http://127.0.0.1:8000/v15.2 会话锁问题从“盲目重启”到“正确定位”我在最初部署时就遇到过agent failed before reply: session file locked (timeout 60000ms)。当时第一反应是重启服务但重启后还是报同样的错。后来排查发现原来是我在调试的时候开了好几个 OpenClaw 进程一个在 systemd 里一个在终端手动启动还有一个是 IDE 的终端残留。多个进程同时尝试写同一个 session 文件就发生了锁竞争。解决办法很简单ps aux | grep openclaw kill 多余进程ID rm ~/.openclaw/sessions/*.lock然后只保留一个运行实例。这里要提醒一点session 锁不只是给会话文件加锁还会影响整个 Agent 的响应流。如果你在飞书里发消息后长时间无响应优先检查的就是锁文件是不是过期了。真的是模型慢还是锁冲突从日志里就能看出来。5.3 微信消息“发不出去/收不到”的原因有很多同学想让 OpenClaw 直接接入微信我也试过。一个典型的问题是OpenClaw 能发消息到微信但从微信发消息给 OpenClaw 却收不到回复。原因是微信个人号的接入方式大多依赖非官方协议这类 hook 方案在接收消息时经常出现登录态失效或者回调地址无法被公网访问的问题。OpenClaw 对微信的支持往往需要额外适配器而适配器的稳定性取决于第三方库是否还在维护。如果你一定要用微信我的建议是优先用企业微信或飞书而不是个人微信。因为个人微信的协议不稳定很容易被风控消息收发都可能中断。飞书在这个场景下稳定太多涉及的关键流程也更透明。5.4 本地模型反应慢模型本身还是链路问题另一个高频问题就是“接入本地模型后反应非常慢”。以我的排查经验看慢在你自己的链路里经常是“多因一果”。我做过一次实验同样的模型直接用 curl 调用本地推理服务的接口首 token 延迟在 500ms 左右但通过 OpenClaw 在飞书里发消息首 token 延迟可能涨到 5 秒以上。这说明慢的不仅是模型还有会话上下文准备、工具调用解析、消息通道回传等环节。要定位瓶颈建议分三段测模型层直接用curl调用模型的 HTTP API看单次完整响应时间OpenClaw 层去掉飞书和微信通道用 OpenClaw 自带的 CLI 测试消息看响应时间通道层通过飞书发送消息观察端到端时间。如果模型层快、OpenClaw 慢重点查上下文长度和会话锁如果 OpenClaw 快、飞书慢重点查飞书事件订阅回调和网络链路。另外一个容易忽略的点是OpenClaw 的fetch_timeout如果设置得太短飞书回调在 3 秒内没有响应飞书会重试。重试机制本身没问题但如果 OpenClaw 还没有处理完上一个请求就会触发锁冲突。所以给飞书配置时建议把event_callback_timeout和 OpenClaw 侧的request_timeout都放大一些。5.5 关于“不能选择 channel”的问题热词里有一条是“openclaw agent怎么选择channel”。这个问题其实是 OpenClaw 的多通道设计导致的。一个 Agent 可以同时关联多个 channel比如同时挂飞书、微信、Discord。但如果你没有在 Agent 配置里显式指定 channelOpenClaw 可能只会绑定默认 channel。在agents/目录下找到对应的 Agent 配置文件例如agents/claw.yaml里面会有类似channels: - feishu - wechat - discord如果你发现 Agent 没有监听预期的 channel先检查这个列表是否包含了你要的 channel以及配置文件里对应 channel 是否已经启用。改完之后记得重启 OpenClaw。另一个和 channel 选择相关的坑是不同 channel 的消息格式、事件类型可能不一样。比如飞书的消息事件是im.message.receive_v1而微信可能是另一种格式。如果 Agent 在飞书里能正常回复到微信里没反应多半是事件类型适配没对上。6. 实测过程与优化建议6.1 一次完整的实测飞书问答 表格文件发送我以一次完整实测为例说明从请求到返回的链路。场景是在飞书群里 机器人发一句“把这几条销售数据整理成 CSV 发给我”。飞书把消息事件推送到 OpenClaw 的 webhook 地址OpenClaw 鉴权后把消息内容转成 Agent 的输入Agent 调用 DeepSeek 模型识别出意图是“生成 CSV 文件”Agent 调用内置文件工具生成一个 CSV 文件OpenClaw 调用飞书文件上传接口把 CSV 上传后发送到聊天中。整个过程大概 6~15 秒取决于模型响应速度和文件生成复杂度。如果消息比较长或者模型输出量大时间会显著增加。这里我特别推荐一个优化点为 Agent 设置专门的系统 prompt。我通常会在 prompt 里写明“如果用户要求发送文件请生成 CSV 而不是在文本里贴表格如果内容过多请分点输出 3 条以内的摘要”。这样模型就不会自作主张输出一大段 markdown 表格导致飞书里被截断。6.2 tools 调用失败的常见原因OpenClaw 的底层依赖是大模型的工具调用能力如果模型不支持工具调用或者模型输出格式不规范工具调用就会失败。速查项我自己反复遇到的消息里包含多个 tool call部分模型一次只能处理一个工具调用建议在配置里限制max_tool_calls: 1。工具结果太长工具返回结果超长会撑爆上下文部分 Agent 会直接失败。建议在工具实现里对返回内容做截断或摘要。工具调用顺序错误OpenClaw 在某些版本里对工具调用顺序敏感比如先发送消息再调用工具会直接报错。这时需要看日志里的堆栈确认哪个工具调用环节出的问题。关于max_tool_calls我在模型接入本地时特别体会过。本地模型对多工具并行调用的支持不如 DeepSeek 稳定经常只执行第一个工具就停下来导致任务卡住。后来把max_tool_calls限制为 1反而更稳定。6.3 性能优化并发、缓存与上下文控制如果你打算把 OpenClaw 用于团队或长期运行以下几个参数的优化很关键参数默认值参考建议max_concurrent_requests5~10根据模型 API 限流调整避免 429max_context_tokens无限制根据模型上下文窗口设置避免超长fetch_timeout60s调大到 120s应对模型推理慢session_cleanup_interval1h定期清理过期会话避免锁累积另外我建议开启请求级缓存如果 OpenClaw 支持cache_response。飞书群里的重复问题很多如果相同问题能命中缓存能省不少 API 费用。但要注意缓存开关会导致逻辑类问题结果不更新所以只对“固定知识类”问题开启比较好。6.4 从“能跑”到“好用”的配置心得OpenClaw 这套系统搭起来是门槛真正花时间的是调优。以下几点是我从多次实验中沉淀出来的心得比较主观但是真话别把 Agent 当搜索引擎它更适合有明确任务结构的自动化流程而不是每次都要模型自由发挥。系统 prompt 越具体越好你越清楚告诉它什么能做什么不能做它就越少胡说八道。飞书的事件订阅地址一定要先测通这个环节最容易出问题而且报错信息不直观。用日志定位问题别靠猜OpenClaw 的日志比报错信息有效得多先看日志再做操作。如果你和我一样想把 DeepSeek MiniMax 飞书整套跑通其实并不复杂真正拉开体验差距的是这些细节。我现在的用法是日常文本任务走 DeepSeek图像/多模态任务临时切到 MiniMax 云端 API飞书作为统一入口大大提升了团队协作里的自动化效率。7. 最后再分享一点个人体会这套 OpenClaw 部署方案我在本地 Linux 服务器上已经稳定跑了将近一个月。踩过的最大坑其实不是配置本身而是“看着文档装完之后不知道下一步怎么调”。所以我特别建议你安装完第一件事不是急着接飞书而是先用 CLI 跑通一个最简单的文本对话确认模型链路没问题再逐步加 channel、加工具。第二次建议是所有外部服务的密钥、回调地址一定要集中管理不要散落在多个配置文件里。我之前因为密钥散落排查权限问题时浪费了不少时间。OpenClaw 的配置层级不复杂但一旦多 Agent、多模型、多通道叠加配置的“可溯源”就很重要。最后我自己觉得 OpenClaw 最值得玩的地方是它的扩展性和组合性。你可以把 DeepSeek 当“大脑”MiniMax 当“眼睛和耳朵”飞书当“手脚”再通过工具调用把它们真正组织起来。这个过程有点像搭乐高初看复杂但搭顺手之后会上瘾。希望这篇文档能帮你少走一些弯路。
