OpenClaw on KnightLi的博客

OpenClaw 作者 Peter Steinberger 如何看 AI 软件开发？从 OpenClaw 到闭环编程

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger 的经历很适合用来观察 AI 软件开发正在发生什么变化。

他不是“突然被 AI 带火的新人”。在 OpenClaw 之前，他已经是 PSPDFKit 的创始人，长期做 PDF 渲染、文档处理和开发者工具。这类产品很难靠概念包装取胜，必须面对性能、兼容性、API 设计、企业客户和长期维护。

所以，当 Steinberger 后来用 AI 工具做出 OpenClaw，并围绕 AI Agent、个人自动化和 AI 编程发表观点时，重点不只是“一个人写了很多代码”。更值得看的，是他把多年软件工程经验和新一代 AI coding agent 结合后，对开发流程的重新理解。

AI 编程不是魔法按钮

很多人讨论 AI 编程时，会把它简化成两个极端。

一种说法是：AI 已经能写代码，程序员快没用了。

另一种说法是：AI 写的代码不可靠，真正工程还是得靠人手写。

Steinberger 的经验更接近第三种：AI 让软件开发的操作单位变了，但没有取消工程判断。

过去，开发者主要以“编辑代码”为中心工作。需求拆解、架构判断、写实现、跑测试、修 bug，都围绕人工修改代码展开。

AI coding agent 介入后，开发者越来越像在管理一个执行系统：

说明目标。
提供上下文。
约束边界。
让 agent 修改代码。
运行测试和检查。
根据结果继续迭代。

这不是简单把键盘交给模型，而是把人从“每一行都亲手敲”转到“定义方向、设计反馈、判断结果”。

为什么他不喜欢把这叫 vibe coding

围绕 Steinberger 的讨论里，一个高频词是 vibe coding。

这个词原本用来形容一种新开发方式：开发者用自然语言描述想法，让 AI 生成大量代码，再通过运行结果和反馈不断调整。

但 Steinberger 对这个词并不完全买账。公开报道中提到，他认为 vibe coding 容易变成一种贬义表达，暗示 AI 辅助开发只是“凭感觉乱生成”，忽视了背后的技能、判断和经验。

这个批评有道理。

真正有效的 AI 编程并不是随便输入一句话，然后相信模型输出。它需要：

能把模糊需求拆成可执行任务。
能识别模型是否误解了目标。
能设计测试和验收标准。
能判断代码结构是否会影响长期维护。
能知道什么时候应该停止生成、转向人工审查。

换句话说，AI 降低了写代码的摩擦，但没有降低理解系统的责任。

闭环才是关键

Steinberger 相关访谈和文章里，经常被总结出的一个核心思路是“闭环”。

只让 AI 生成代码，是开环。

让 AI 生成代码、运行代码、读取错误、修复问题、再运行测试，才更接近闭环。

这个差别非常重要。

开环生成很容易制造表面可用的软件。页面能打开，功能看起来有，代码也不少，但一旦进入真实场景，就会暴露状态管理、权限、异常处理、边界条件和部署问题。

闭环开发要求输出必须被反馈约束。最简单的闭环是：

写清楚目标。
让 AI 修改代码。
自动运行测试、类型检查、lint 或构建。
把错误反馈给 AI。
重复直到通过。
最后由人审查关键路径。

这也是 AI 软件开发真正能提高效率的地方。不是因为模型一次就写对，而是因为它可以快速参与“生成、验证、修复”的循环。

经验越多，越能用好 AI

AI 编程最容易产生的误解之一，是“经验不重要了”。

Steinberger 的案例反而说明，经验会变得更重要，只是作用方式变了。

一个有经验的工程师更容易判断：

哪些任务适合交给 agent。
哪些模块需要先写测试。
哪些改动风险太高，不该让 AI 大范围重构。
哪些生成代码只是看起来合理。
哪些问题应该通过架构调整解决，而不是继续补丁式修复。

AI 可以生成大量候选方案，但候选方案越多，越需要判断力。没有经验的人可能会被“能跑起来”迷惑，有经验的人更会追问：能不能维护？能不能扩展？会不会破坏安全边界？出了问题能不能定位？

这也是为什么 AI coding agent 并没有让软件工程变成纯聊天。它更像把一部分执行劳动外包出去，同时放大了规划、审查、验证和取舍的重要性。

OpenClaw 的意义不只是项目本身

OpenClaw 被关注，不只是因为它是一个开源 AI agent，也不只是因为它的增长速度快。

它更像一个信号：开发者开始希望 AI 不只回答问题，而是能接入真实工具，完成真实动作。

传统聊天机器人停留在对话框里。它可以解释代码、写草稿、给建议，但很多时候还需要人复制、粘贴、打开软件、执行命令。

Agent 的方向是把模型接到工具上：

文件系统。
浏览器。
终端。
邮件。
日历。
第三方服务。
项目仓库。

一旦模型能使用这些工具，软件开发的边界就会变化。AI 不再只是“代码补全”，而会参与项目阅读、任务拆解、文件修改、测试执行、PR 整理和工作流自动化。

这也是 Steinberger 加入 OpenAI 后被关注的原因。他代表的不是单个开发者故事，而是一种产品方向：个人 agent 会从演示玩具走向日常工作层。

这对普通开发者意味着什么

对普通开发者来说，Steinberger 的经验不一定能直接复制。

不是每个人都能同时管理多个 agent，不是每个项目都适合高强度 AI 生成，也不是每个团队都能接受“先生成再快速迭代”的节奏。

但有几件事值得学。

第一，先把任务写清楚。

AI 对含糊目标很敏感。你说“优化一下”，它可能改风格、改结构、加功能、删逻辑。你说“把登录失败时的错误提示从英文改成中文，不改变认证流程”，结果通常更可控。

第二，把验证命令固定下来。

如果一个项目没有测试、没有构建命令、没有 lint，AI 就很难形成闭环。哪怕只是最基础的 npm test、go test ./...、pytest、hugo，也比完全靠肉眼检查强。

第三，控制改动范围。

一次只让 AI 处理一个模块、一个 bug、一个页面，通常比让它“重构整个项目”更可靠。

第四，保留人工审查。

尤其是认证、支付、权限、数据删除、部署脚本、数据库迁移、安全配置这些地方，不要因为代码是 AI 生成的就降低审查标准。

第五，复盘 prompt 和失败模式。

如果 AI 经常误解某类任务，就把约束写进项目规则、agent instructions 或技能文件。AI 编程能力不是只来自模型，也来自你给它搭建的工作环境。

AI 软件开发会走向哪里

Steinberger 的故事说明，AI 软件开发正在从“辅助写代码”走向“组织软件生产流程”。

早期 AI 编程工具的价值主要是补全函数、解释报错、生成模板。现在的变化是，agent 可以跨文件工作，可以调用工具，可以运行检查，可以根据反馈继续修复。

这会带来几个趋势：

第一，个人开发者的产能上限会提高。

一个人可以同时推进更多原型、脚本、内部工具和小型产品。但产能提高不等于质量自动提高。越快生成，越需要验证。

第二，项目结构会更重要。

代码越清晰，测试越明确，文档越完整，AI 越容易正确修改。混乱项目对人难，对 AI 也难。

第三，软件工程师会更像工作流设计者。

未来重要的不只是会不会写某门语言，而是能否把需求、上下文、工具、测试、部署和权限组织成一个可控循环。

第四，安全边界会更敏感。

Agent 能做事，就可能做错事。它能读文件、执行命令、访问服务，也意味着权限、审计和回滚会成为 AI 开发环境的基础设施。

小结

Peter Steinberger 的 AI 软件开发观，最有价值的地方不是“AI 生成了多少代码”，而是他展示了一种新的开发姿势。

人不再只是在编辑器里逐行输入，而是在设计目标、管理 agent、构造反馈回路、审查结果和调整系统。代码仍然重要，但代码不再是唯一的劳动中心。

如果说传统软件开发强调“把代码写对”，AI 软件开发会更强调“让系统持续产出可验证的正确结果”。

这不是降低工程门槛那么简单。它是在改变工程能力的形态：从手工实现，转向任务分解、上下文管理、工具编排、自动验证和最终判断。

参考资料

Hermes Agent 是什么：简介、优点、快速上手与 OpenClaw 对比

Sun, 12 Apr 2026 14:07:58 +0800

如果你最近在关注开源 AI Agent，Hermes Agent 是一个很值得看一眼的新项目。它由 Nous Research 推出，核心卖点不是“再做一个聊天壳子”，而是把长期记忆、技能沉淀、上下文文件、MCP 扩展、消息网关和子代理并行这些能力，尽量收敛进一个统一的 agent 运行环境里。

从官方 README 的表述看，Hermes Agent 的目标很明确：它既可以像本地 CLI 助手一样在终端里工作，也可以像一个常驻云端的个人助理一样，通过 Telegram、Discord、Slack、WhatsApp、Signal 等渠道和你持续对话。对于希望把“代码助手”“自动化助手”“个人 AI 工作台”合并到一个系统里的用户来说，这个定位是很有吸引力的。

01 Hermes Agent 简介

Hermes Agent 是 Nous Research 开源的自改进型 AI Agent。它支持多种模型提供方，包括 Nous Portal、OpenRouter、OpenAI 以及自定义兼容 OpenAI 的端点；也支持在本地终端、Docker、SSH、Daytona、Modal 等不同执行后端上运行。

它和很多“会调用工具的聊天机器人”最大的区别在于，Hermes 不是只强调一次会话里的工具调用，而是强调跨会话的持续能力建设。官方文档里把这种思路拆成几块：

持久记忆：通过 MEMORY.md 和 USER.md 保存关于环境、项目、用户偏好的关键信息。
技能系统：把复杂任务里学到的流程沉淀成技能，后续按需加载。
上下文文件：自动读取 AGENTS.md、SOUL.md、.cursorrules 等文件，把项目约定直接注入会话。
MCP 集成：可以接入任何兼容 MCP 的工具服务器，扩展数据库、GitHub、文件系统、抓取等能力。
消息网关：除了 CLI，还能通过 Telegram、Discord、Slack、WhatsApp、Signal、Email 等入口使用。

如果只用一句话概括，Hermes Agent 更像是一个“带记忆、带技能、可扩展、可多端接入的通用 Agent 操作层”。

02 它的优点在哪里

1. 同时覆盖 CLI 工作流和消息工作流

很多 agent 项目要么偏“终端内开发助手”，要么偏“聊天平台机器人”。Hermes 想做的是把这两件事合并起来。你可以直接在终端里运行 hermes，也可以启动 gateway 后从 Telegram 或 Discord 上继续同一个助手。

这种设计的好处是，Hermes 不局限于“坐在电脑前时才有用”。如果你把它部署在云端或者 VPS 上，它可以变成一个持续在线的个人 AI 助理。

2. 对“长期使用”考虑得比较完整

Hermes 不只是会聊天和调工具，它还强调长期积累：

有边界的持久记忆，而不是无限堆上下文。
有技能系统，可以把成功流程保存下来复用。
能搜索过去会话，做跨会话召回。
能读取项目里的上下文文件，减少每次重复解释项目背景。

对于经常在固定代码库、固定工作流、固定团队规范里反复工作的用户，这一点很重要。它意味着 agent 不只是“这次帮你做点事”，而是会逐渐更懂你的环境。

3. MCP 支持让扩展性很强

Hermes 官方文档明确支持 MCP，并且说明了 stdio 和 HTTP 两类接入方式。也就是说，只要某个外部系统已经有 MCP server，Hermes 理论上就可以较低成本接进去。

这比每次为单个系统单独写插件更灵活。对于已经在 MCP 生态里积累了一批工具的人，Hermes 的接入成本会低很多。

4. 对 OpenClaw 用户很友好

这一点很有意思。Hermes README 里直接提供了 hermes claw migrate，并写明可以从 OpenClaw 导入配置、记忆、技能、API key、消息平台设置等内容。

这说明它并不是完全无视既有生态重新造轮子，而是明确把一部分 OpenClaw 用户视为潜在迁移对象。

03 怎么快速上手

Hermes Agent 官方推荐的安装方式非常直接：

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

官方说明支持 Linux、macOS、WSL2，以及 Android 的 Termux。需要注意的是，README 里明确写了原生 Windows 暂不支持，Windows 用户建议走 WSL2。

安装完成后，通常先刷新 shell：

`1`	`source ~/.bashrc`

然后就可以直接启动：

hermes

如果你想一步一步完成完整初始化，最省心的命令是：

`1`	`hermes setup`

根据官方文档和 README，首次上手可以按下面这个顺序来：

运行 hermes setup，完成基础配置。
用 hermes model 选择模型提供方和模型。
用 hermes tools 开关需要的工具集。
直接执行 hermes，进入交互式 CLI。
如果你想接 Telegram、Discord 之类的渠道，再继续配置 hermes gateway。

如果你本来就是 OpenClaw 用户，还可以先看一眼迁移命令：

`1`	`hermes claw migrate --dry-run`

它会先预览可迁移的内容，再决定要不要正式导入。

04 和 OpenClaw 怎么看

从官方文档和 README 来看，Hermes Agent 与 OpenClaw 并不是简单的“谁替代谁”，而是定位有明显重叠，但侧重点不同。

Hermes Agent 更像什么

Hermes 更像一个偏 agent 内核和工作流系统的产品。它强调的是：

CLI 体验
记忆与技能沉淀
项目上下文文件
MCP 扩展
子代理并行
在本地、容器、远端、serverless 环境之间切换执行后端

如果你的主要诉求是“让 agent 更懂项目、更能持续复用能力、更方便接 MCP 和开发工作流”，Hermes 的方向会更顺手。

OpenClaw 更像什么

OpenClaw 则更像一个以个人 AI 助手和消息网关为中心的平台。它强调：

非常丰富的消息渠道接入
常驻运行的 Gateway
浏览器里的 Control UI
设备配对、远程访问、状态管理
语音、移动端、Canvas 等更强的助手形态

如果你的核心需求是“把一个个人 AI 助手稳定地挂在各种聊天渠道和设备上”，并且希望用控制面板统一管理，OpenClaw 的产品感会更强。

一个更实用的选择建议

可以把两者简单理解成：

Hermes Agent：更偏“会成长的通用 agent 工作台”
OpenClaw：更偏“多渠道常驻型个人 AI 助手平台”

当然，这个区分不是绝对的，因为两边都在继续扩展能力，而且 Hermes 还提供了从 OpenClaw 迁移的路径。但至少从当前公开资料看，Hermes 在“记忆、技能、上下文、MCP、开发工作流”这条线上更突出；OpenClaw 在“网关、多渠道、控制 UI、设备接入”这条线上更成熟。

05 适合谁尝试

如果你属于下面几类人，Hermes Agent 值得优先试一下：

你已经在终端里大量使用 AI 工具，希望 agent 更懂代码库和项目规则。
你想把 AGENTS.md、技能、记忆、MCP 这些能力组合到一起。
你不想被单一模型厂商锁死，希望可以灵活切换 provider。
你原来就在用 OpenClaw，现在想试试一个更偏 agent 工作流的方向。

如果你更看重的是移动端触达、各种 IM 平台接入、浏览器控制台和“始终在线的个人助理感”，那 OpenClaw 仍然很有吸引力。

参考链接

Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
Hermes Agent 文档: https://hermes-agent.nousresearch.com/docs/
Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/
OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart
OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui

OpenClaw 类脑记忆算法 Dreaming：机器开始做梦，人类却在失眠

Sun, 12 Apr 2026 12:41:34 +0800

大模型的长期记忆一直是个老问题。上下文越积越多，信息越容易混乱。智能体看似什么都记得，实际上却越来越难判断什么重要、什么该忘。

4 月 5 日，OpenClaw 在新版本里上线了一项实验功能：Dreaming。它不是一个花哨名字，而是一套模仿人类睡眠过程的后台记忆整理机制，目标很直接，就是让智能体醒来后记得更准。

01 睡眠算法：把记忆整理拆成三个阶段

Dreaming 并不是简单做索引，而是把记忆整理拆成三个逻辑阶段，对应人类睡眠中的不同功能。

浅睡阶段（Light Sleep）：系统先扫描近期对话和召回记录，做去重和初步筛选，生成候选内容。这个阶段只做暂存，不会直接改动核心记忆文件 MEMORY.md。

深睡阶段（Deep Sleep）：系统开始按规则筛选高价值信息。只有同时达到最低评分、最低召回次数和最低独特查询次数的信息，才会进入下一步。写入前还会重新比对最新日志，剔除过时内容，最后把结果追加到 MEMORY.md，并在 DREAMS.md 中留下深睡摘要。

快速眼动阶段（REM）：在记忆固化之后，系统进一步分析短期行为痕迹，寻找不同信息之间的潜在联系，生成模式总结和反思内容。这部分会写入专门的 REM 区块，帮助智能体在处理复杂任务时更容易抓住全局。

除了给机器自己用的记忆整理机制，Dreaming 还会顺手生成一份更适合人类阅读的“梦境日记”。当素材积累到一定程度，后台子智能体会调用默认模型，在 DREAMS.md 中追加一段简洁说明。

02 评分机制：决定什么该留下，什么该被忘掉

Dreaming 的关键不只是“整理”，更是“筛选”。OpenClaw 没有继续沿用粗放式的全量保存，而是用一套加权评分机制判断哪些信息值得进入长期记忆。

这套机制主要看六个维度：

相关性权重（30%）：衡量信息在被检索时到底有没有用。
频率权重（24%）：统计某条信息被反复提及的次数。
查询多样性（15%）：看它是否在不同问题和场景中都出现过。
时效性权重（15%）：让新近信息拥有更高优先级。
整合度权重（10%）：看信息是否能跨多天稳定出现。
概念丰富度（6%）：判断它背后的关联概念是否足够丰富。

这意味着系统不是把所有内容一股脑塞进长期记忆，而是优先保留那些反复出现、能解决问题、又不过时的信息。

03 它为什么让人联想到 Claude 的“做梦”思路

有开发者认为，OpenClaw 这次 Dreaming 升级的思路，很像 Claude Code 泄露代码中出现过的 KAIROS 自动做梦机制。过去那种反复读写整个 MEMORY.md 的方式，到了后期很容易让记忆系统越来越臃肿；而 Dreaming 把过程拆成浅睡整合、深睡固化、REM 关联，逻辑明显更清晰，也更接近“先整理、再沉淀、再提炼”的思路。

也有人从神经科学角度肯定这套设计。因为 Dreaming、浅睡、深睡和 REM 这些概念并不是随便取的名字，而是明确借用了人类睡眠巩固记忆的模型。

OpenClaw 现有的 IDENTITY.md、USER.md 和 HEARTBEAT.md 已经给了智能体人设、用户上下文和运行连续性，而 DREAMS.md 补上的，正是“哪些记忆该留下”的能力。

04 最讽刺的一幕：机器学会做梦，人却睡不着

Dreaming 的真正价值，不是让 AI 什么都记住，而是让它学会复盘短期记忆、提取底层模式、过滤噪音。一个真正好用的智能体，不应该像移动硬盘一样死记硬背，而应该越来越懂用户的偏好、目标和背景。

从工程角度看，这套机制最值得注意的地方在于它并不神秘。它不是黑盒魔法，而是一套有阶段、有阈值、有反思、也有遗忘规则的后台流程。这种设计让 AI 的记忆机制第一次显得更像“可控的系统”，而不只是“无限堆上下文”。

但也正因为如此，整件事才显得有点讽刺：我们正在投入大量资源，教机器如何像人一样做梦；与此同时，许多人却因为担心被这些越来越聪明的系统取代而失眠。

OpenClaw 与 Agent Harness：为什么它看起来像 AGI

Fri, 10 Apr 2026 09:16:17 +0800

很多人第一次接触 OpenClaw，会觉得它“比聊天机器人更像一个会做事的同事”。

这种感觉并不神秘。关键在于：OpenClaw 不是单一模型能力的跃迁，而是一个完整的 Agent Harness。

先给结论

OpenClaw 的本质可以概括为：

模型负责理解与决策
Harness 负责记忆、工具、触发、执行与输出
两者通过循环协作，形成“持续行动”的体验

所以它“像 AGI”的核心原因，不是模型突然变成全能，而是系统工程把模型的可执行性放大了。

什么是 Harness

可以把 Harness 理解为“给模型穿上的外骨骼”。

单独的 LLM 通常只能在一次请求里给出回答，而 Harness 会补齐这些能力：

会话与状态管理：把多轮任务串起来
记忆机制：保存并按需召回上下文
工具系统：调用浏览器、终端、文件与外部 API
触发机制：由定时器或事件唤醒，不必每次都等人提问
输出通道：把结果写回系统，而不只是回一段文字

当这些能力被接入同一个循环时，模型就从“回答器”变成“执行器”。

OpenClaw 为什么显得不一样

传统聊天机器人是“问一次，答一次”。

OpenClaw 更像“观察 -> 调工具 -> 看结果 -> 再决策”的闭环。闭环一旦成立，就会表现出持续推进任务的能力。

这也是 OpenClaw 最值得学习的地方：

它证明了 Agent 体验主要来自架构设计
它把“自治”拆成了可工程化的模块

价值与边界

OpenClaw 的优势是通用、灵活，但代价也明显：

上下文与工具定义越多，成本越高
系统越通用，调试和治理越复杂

在生产场景里，很多团队会选择更小、更专的 Agent，而不是一个“全能智能体”。

Anthropic 封杀 OpenClaw 的完整时间线

Wed, 08 Apr 2026 19:48:42 +0800

事件背景

2026 年 4 月 4 日，Anthropic 宣布切断 Claude 订阅对 OpenClaw 等第三方工具的覆盖。

对用户层面的直接影响是：原先依赖订阅路径接入 Claude 的第三方流程，需要改为其他接入方式或切换到其他模型。

时间线（2026 年 1 月至 4 月）

2026 年 1 月

据公开报道，Anthropic 要求当时名为 Clawdbot 的项目调整名称，理由是发音与 Claude 接近。

同一阶段，社区开始出现关于第三方通过订阅凭证调用能力受限的反馈。

2026 年 2 月

相关限制被写入服务条款，订阅与第三方自动化调用之间的边界进一步明确。

同月，OpenClaw 发布 v4.0，底层架构改为可插拔模型后端。也就是说，模型不再是单一固定入口，而是可以在多个模型提供方之间切换。

2026 年 3 月

Anthropic 发布 Claude Dispatch 与 Computer Use，覆盖远程任务执行与桌面操作等能力。

OpenClaw 在后续更新中继续推进兼容层，统一不同模型在认证方式、工具调用格式和返回结构上的差异，降低切换模型时的迁移成本。

公开报道还提到，OpenClaw 团队与 Anthropic 在 3 月下旬有过沟通，但最终策略方向未发生改变。

2026 年 4 月 4 日

Anthropic 正式执行对第三方工具的订阅覆盖切断。

这标志着此前数月的策略调整进入执行阶段。

2026 年 4 月 5 日

OpenClaw 发布 v4.5，主要动作包括：

在引导流程中调整模型入口优先级
接入 GPT-5.4 等替代模型路径
继续针对任务流程与交互体验做适配

从发布时间看，OpenClaw 的切换能力并非完全临时构建，而是建立在 2 月以来的多模型架构改造基础上。

过程中的两个并行方向

按时间线看，双方在同一时期分别推进了不同方向：

Anthropic：收紧订阅边界，推动官方产品能力整合
OpenClaw：强化模型可替换性，提升跨模型兼容能力

这两条路线并不矛盾，但会在“入口归属”和“用户工作流沉淀位置”上产生竞争关系。

当前状态（截至 2026 年 4 月）

基于已公开的信息，可以确认以下事实：

订阅覆盖切断已执行
OpenClaw 已完成主要模型路径切换并保持版本迭代
用户是否感知明显变化，取决于其原有工作流对单一模型能力的依赖程度

后续观察点

接下来更值得关注的，不是单次事件本身，而是三件事：

订阅方案与 API 调用边界是否继续细化
多模型 Agent 在稳定性、成本和体验上的长期表现
用户工作流最终沉淀在模型层、工具层，还是两者之间的混合层

OpenClaw 对接本地 Gemma 4：完整配置指南

Wed, 08 Apr 2026 18:18:00 +0800

这篇文章演示如何把 OpenClaw 对接到本地 Gemma 4 模型（通过 Ollama 提供接口）。

如果你还没完成本地部署，可先参考：

如何在笔记本电脑上运行 Gemma 4：5 分钟本地部署指南

第 1 步：启动 Ollama API 服务

先启动 Ollama 服务：

`1`	`ollama serve`

你可以用下面的命令快速测试 API 是否正常：

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "你好"
}'

如果能返回模型输出，说明本地 API 已可用。

第 2 步：配置 OpenClaw 接入 Ollama

OpenClaw 配置文件路径通常为：

`1`	`~/.openclaw/config.yaml`

编辑 config.yaml，在 models 中新增一个本地模型条目：

models:
  # 你已有的模型配置...

  gemma4-local:
    provider: ollama
    base_url: http://localhost:11434
    model: gemma4:12b
    timeout: 120s

第 3 步：设置默认模型（可选）

如果你希望默认走 Gemma 4，可添加：

`1`	`default_model: gemma4-local`

第 4 步：重启并验证 OpenClaw

重启 OpenClaw：

`1`	`openclaw restart`

查看模型列表：

`1`	`openclaw models list`

发起一次对话测试：

`1`	`openclaw chat --model gemma4-local "你好"`

如果对话返回正常，说明 OpenClaw 已成功接入本地 Gemma 4。

常见排查

connection refused：先确认 ollama serve 是否在运行。
模型找不到：检查模型名是否与 ollama list 一致（例如 gemma4:12b）。
响应超时：可适当提高 timeout，并优先测试较小模型。