ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

跟我一起学 OpenClaw(01):OpenClaw 是什么?为什么我建议你把它当成「长期在线的 AI 同事」来用(入门指南)

跟我一起学 OpenClaw(01):OpenClaw 是什么?为什么我建议你把它当成「长期在线的 AI 同事」来用(入门指南) 1. 为什么我建议把 OpenClaw 当成「长期在线的 AI 同事」而不是问答工具很多人第一次接触 OpenClaw会下意识把它归类成「又一个 AI 聊天框」。我一开始也这么想直到我把同一套流程跑了三遍在网页里问模型、把答案复制到本地文档、再手动去执行发消息、跑命令、查日志。三次之后我意识到真正拖慢我的不是模型不够聪明而是它离我的工作流太远——它不知道我的项目结构不记得我昨天让它改过哪个文件也没法在我离开电脑后继续把活干完。OpenClaw 想解决的正是这个断层。它本质上是一个能长期运行的 AI Agent 网关把大模型能力接到飞书、Telegram、Slack 这类消息入口接到你的文件、终端、浏览器、日历等工具并且自带会话与记忆。你可以把它理解成「把 AI 从会聊天的工具升级成能干活的同事」的那层可编程底座。它不是一个页面而是一个常驻服务。所以这篇入门指南不打算只讲概念。我会从 Gateway、Sessions、Tools 三个核心概念切入交付一份可复制的 Gateway 接入配置、Sessions 初始化步骤以及 Tools 调用连通性的验证动作让你在本地完成第一轮可观测的 Agent 运行。适合谁适合已经用过一两次大模型 API、想把它接进真实工作流、但还没找到稳定落地方式的开发者。读完你应该能自己判断OpenClaw 到底是不是你要的那块拼图。先给一个整体心智模型。传统问答是「请求—响应」的一次性交易你问完就结束上下文留在浏览器里。OpenClaw 是「常驻网关 会话状态 工具执行」的持续系统消息从渠道进来网关路由到对应会话会话带着上下文决定调用哪些工具工具执行完把结果回传到原渠道。这条链路里任何一环断了你都会觉得「它不好用」而问题往往不在模型。我实测下来新手最容易卡住的不是安装而是没搞清楚这三个概念各自的职责边界。Gateway 负责「在线」和「路由」Sessions 负责「记得住」和「隔离」Tools 负责「能动手」。下面逐个拆开并且每一步都给可复制的配置和验证动作而不是停留在解释层面。2. TaoToken 前置准备给 OpenClaw 配一个稳定的模型入口在动 OpenClaw 之前得先解决模型从哪来的问题。OpenClaw 本身是网关和调度层它需要一个兼容 OpenAI 协议的上游来提供推理能力。我建议用 TaoToken 作为模型入口原因是它提供标准的 OpenAI 兼容接口Base URL 和 Key 的接入方式和绝大多数 Agent 框架一致省去你为不同框架改适配层的麻烦。你需要准备三样东西这三样在后面所有配置里都会反复出现我把它叫「三件套」Base URL、API Key、Model ID。缺任何一个Agent 都跑不起来。Base URL 用https://taotoken.net/api注意这个地址不带任何查询参数直接填在配置的 base_url 字段里。API Key 需要你去控制台创建创建入口在 API Keys 页面生成后只显示一次记得立刻复制保存。Model ID 就是你要调用的具体模型名比如你常用的对话模型或代码模型填在配置的 model 字段。创建 Key 的路径是进入控制台找到 API Keys 菜单点新建给它起个能认出来的名字比如 openclaw-local然后复制那串以 sk- 开头的字符串。这一步别偷懒用临时 Key后面排障时你会感谢自己用了命名清晰的 Key。如果你还没决定用哪个模型可以先到模型对话页面手动试几句确认这个模型在你的场景下回答质量够用再把它写进 OpenClaw 配置。模型对话入口在这里可以先用它验证 Key 是否有效、模型是否可用再去接 OpenClaw这样能把「Key 问题」和「OpenClaw 配置问题」分开排查。这里有个我踩过的坑很多人把 Key 直接写死在代码或配置文件里然后提交到 Git结果泄露。正确做法是用环境变量注入配置文件里只写变量名。下面第三节的配置片段我会用环境变量占位你照着填就行。另外提醒一句TaoToken 是合规的模型 API 服务入口你只需要按标准 OpenAI 协议调用即可不需要任何额外的网络层配置。如果你的环境本身访问不了外网那是另一回事不在本文讨论范围。准备好三件套之后先别急着装 OpenClaw。用一条 curl 命令验证 Key 和模型是否通这一步能帮你排除掉一半后续问题export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api curl -s $TAOTOKEN_BASE_URL/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: 你的模型ID, messages: [{role: user, content: 只回复两个字通了}] }如果返回的 JSON 里 choices 数组有内容说明三件套没问题可以进入 OpenClaw 配置。如果返回 401说明 Key 错了或没带上如果返回模型不存在说明 Model ID 写错了。把这两类错误在这一步解决掉后面会顺很多。3. 可复制的 Gateway 接入配置与 Sessions 初始化步骤这一节是全文最核心的部分我会给出可直接复制的配置片段。OpenClaw 的配置通常放在项目根目录或用户配置目录下常见形式是 JSON 或 TOML。下面用 JSON 举例路径按你实际安装位置调整字段名以你所用版本为准但结构基本一致。先看 Gateway 的接入配置。核心是把模型入口三件套和渠道入口配好{ gateway: { host: 127.0.0.1, port: 8787, logLevel: info }, model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, modelId: 你的模型ID, timeoutMs: 60000 }, channels: { feishu: { enabled: true, appId: cli_你的appId, appSecretEnv: FEISHU_APP_SECRET, eventMode: websocket } }, security: { dmPolicy: pairing, allowlist: [你的用户ID] } }几个关键点解释一下。baseUrl填https://taotoken.net/api不要多加/v1因为 OpenClaw 内部会按 OpenAI 协议拼接路径如果你填了/v1导致重复会出现 404。apiKeyEnv写的是环境变量名不是 Key 本身这样配置文件可以安全提交。eventMode用 websocket 是飞书推荐的订阅方式比 webhook 少一层公网暴露。dmPolicy设成 pairing 意味着陌生人私聊需要配对allowlist是白名单这两个是安全底线第一天就要配。配好之后启动 Gateway。命令顺序建议是安装、启动、查状态、跑诊断openclaw gateway install openclaw gateway start openclaw gateway status openclaw doctor --fixdoctor --fix这一步别跳过。它会检查缺的权限、错的配置、没启动的依赖并尝试自动修复。我实测下来飞书接入失败十有八九是权限没开全或事件订阅没配对doctor 会直接指出来。接下来是 Sessions 初始化。Sessions 决定了两件事上下文连续性和隔离性。同一个 Agent 面对不同联系人、不同群聊应该是不同的 session否则 A 的对话会污染 B 的上下文既不安全也不专业。初始化 session 的关键是定义 scope{ sessions: { scope: per-channel-per-user, persist: true, storePath: ./data/sessions, maxTurns: 50, memory: { enabled: true, backend: file, path: ./data/memory } } }scope设成per-channel-per-user表示每个渠道的每个用户独立会话这是最稳妥的默认值。persist为 true 让会话落盘重启 Gateway 后上下文还在这是「长期在线」的关键。maxTurns控制上下文窗口太大费 token太小记不住事50 是个不错的起点。memory开启后Agent 能把重要信息落到文件配合检索实现「记得住」。初始化完成后你可以用一条命令查看当前 session 列表确认隔离生效openclaw sessions list你应该能看到按渠道和用户分组的会话条目。如果所有消息都挤在一个 session 里说明 scope 没生效回去检查配置是否被正确加载。4. 验证请求与成功结果让 Tools 真正动起来配置写完不代表能用必须做一次端到端的可观测验证。这一节我给出 Tools 调用连通性的验证动作目标是让你亲眼看到「消息进来—会话处理—工具执行—结果回传」这条链路跑通。先定义一个最小工具。Tools 让 Agent 不只是会说还能做事比如读写文件、执行命令、控制浏览器。新手建议从最安全的只读工具开始比如读一个固定目录下的文件{ tools: { readFile: { enabled: true, type: filesystem, allowPaths: [./workspace], readOnly: true } } }allowPaths限定工具只能访问./workspace目录readOnly禁止写入。这是安全边界别一上来就给全盘读写权限。配好后重启 Gateway然后在你的消息渠道里发一条指令比如「读一下 workspace 里的 hello.txt 并告诉我内容」。如果一切正常你会看到 Agent 回复文件内容同时 Gateway 日志里出现工具调用的记录。日志是验证的关键建议开 info 级别并实时查看openclaw gateway logs --follow成功的结果长这样日志先出现收到消息、路由到 session、模型决定调用 readFile、工具返回内容、模型组织回复、回传到渠道。这一串事件都出现说明链路完整。任何一环缺失都能从日志定位。再验证一次会话连续性。发第二条消息「刚才那个文件的第一行是什么」如果 Agent 能基于上一轮上下文回答说明 session 持久化和上下文都正常。这一步很多人会失败原因通常是 persist 没开或 storePath 不可写。最后验证隔离性。用另一个账号或另一个群发消息确认它看不到第一个会话的上下文。如果能看到说明 scope 配错了这在多人场景下是严重问题。把这三个验证都跑通你就完成了第一轮可观测的 Agent 运行。这时候再回头看「长期在线的 AI 同事」这个说法你应该有体感了它记得住、能动手、还分得清谁是谁。5. 本篇常见错误排查401、local proxy failed、reading choices、OAuth新手在这一步最容易撞上几类报错我按真实遇到的频率排一下并给出定位方法。第一类是 401 Unauthorized。这几乎总是 Key 的问题要么环境变量没导出要么导出的是旧 Key要么配置文件里写的是变量名但进程没读到。排查顺序是先确认echo $TAOTOKEN_API_KEY有值再用第 2 节的 curl 单独验证 Key最后确认 OpenClaw 进程的启动环境里确实有这个变量。注意如果你用 systemd 或容器启动环境变量不会自动继承 shell 的需要在服务定义里显式声明。第二类是 local proxy failed。这个报错通常出现在 Gateway 尝试连接上游模型时含义是本地到上游的连接建立失败。常见原因是 baseUrl 写错比如多写了/v1或少了协议头、端口被占用、或者本机网络策略拦截。先检查 baseUrl 是否为https://taotoken.net/api再用 curl 从同一台机器验证连通性。如果 curl 通但 OpenClaw 不通多半是配置没热加载重启 Gateway。第三类是 reading choices 相关报错比如cannot read property choices of undefined。这说明上游返回的 JSON 结构不符合预期Agent 拿不到 choices 字段。原因可能是模型 ID 写错导致返回了错误对象也可能是上游返回了非标准结构。解决办法是先看原始响应在日志里找到那次请求的响应体确认它到底返回了什么。多数情况下是 Model ID 拼错或该模型未开通。第四类是 OAuth 相关报错出现在渠道接入环节比如飞书授权失败。这类问题通常是 appId/appSecret 不匹配、权限未开通、或事件订阅模式选错。飞书接入建议用 websocket 模式并在开放平台把所需权限一次性勾全。改完配置后一定要重新跑openclaw doctor --fix它会重新校验授权状态。这里再强调一次三件套的完整性。无论你用的是 CC Switch、Cline MCP 还是 Codex 的 auth.json只要涉及模型接入就必须同时配齐 Base URL、Key、Model ID 三个字段。少一个就会出现上面某类报错。我见过太多人只填了 Key 就以为完事结果卡在 reading choices 上找半天。排查的通用心法是把「模型入口问题」和「OpenClaw 配置问题」分开验证。先用 curl 确认模型入口通再确认 OpenClaw 配置加载正确最后看渠道。分层排查比盯着一个报错猜要快得多。6. 把 AI 推进到工作流下一步怎么走跑通第一轮之后你手里其实已经有了一个能长期在线、能记住上下文、能调用工具的 Agent 底座。接下来最有价值的动作是把你重复做过三次以上的操作固化成 skill。比如「整理一段文字成博客并发布」「检查 gateway 日志给结论」「把某个固定流程一键执行」这些一旦固化就从一次性操作变成了可复用能力。如果你打算长期用它做编码或跑 Agent 任务可以了解 Coding Plan它更适合持续性的开发场景。日常验证模型效果、试新 prompt用模型对话就够了。需要创建和管理更多 Key 时去 API Keys 页面。接入过程中遇到配置细节接入文档里有更完整的字段说明。我的建议是别一上来就追求大而全。先把一个渠道、一个工具、一个 skill 跑稳再逐步加。OpenClaw 的价值不在于功能多而在于它让 AI 真正进入了你的工作流成为系统的一部分而不是浏览器里的一次性对话。
返回列表