博客

  • Zuo AI Plus:集成国内大模型、最懂中文站长的 WordPress AI 助手插件深度测评

    市面上大多数 WordPress AI 插件,写出来的文章一眼就能被认出是 AI 生成的——开头"随着……的不断发展",结尾"综上所述",中间段落永远是"首先……其次……最后"。Zuo AI Plus 解决的就是这个最根本的问题。

    作者:左运来 | 插件版本:1.6.0 | 更新日期:2026-04-26官网: https://www.yily.top


    一句话定位

    Zuo AI Plus= 真人博主写作风格 + 智能网址导航 + 全站SEO诊断优化+一站式 AI 内容工作流,全部在 WordPress后台完成。


    一、最大的差异化优势:真人博主写作风格

    这是 Zuo AI Plus 与市面上所有 WordPress AI 插件最核心的区别。

    大多数 AI 写作工具输出的内容有明显的"机械感":开头永远是"随着人工智能技术的快速发展……",中间段落用"首先、其次、最后、综上所述"串联,结尾堆砌空洞的展望。这种内容不仅读者看着尴尬,搜索引擎也在越来越精准地识别和降权。

    Zuo AI Plus 从 v1.6.0 开始,在 prompt 层就做了根本性的重构,让 AI 学会真人博主的写作方式

    1.1 具体实现了什么?

    • 长短句交替:真人写作不会每句话都是完整句式,会有短句、感叹句、疑问句穿插,AI 学会这种节奏感
    • 真实例子和经历:改写和续写时,AI 会像真实博主一样补充实操经验、个人踩坑经历,增加说服力和亲切感
    • 自然过渡:段落之间没有明显的逻辑连接词,而是靠语义自然衔接,读起来不像是用模板套出来的
    • 具体场景描写:不是泛泛而谈,而是有具体情境、具体操作步骤、具体结果

    1.2 反 AI 痕迹机制

    插件内置了明确的套话黑名单,生成和改写时主动禁止以下表达模式:

    禁止类型典型例子
    八股开头"随着……的不断发展""在当今社会""不得不承认"
    机械串联"首先……其次……最后""一方面……另一方面"
    排比堆砌三个结构完全相同的句子连续出现
    空洞结尾"综上所述……""总而言之……""以上就是……"
    套话安全词"值得注意的是""需要指出的是""毋庸置疑"

    这个黑名单不只是关键词匹配,而是从语义层面识别,如果 AI 试图绕过,H1 自动降级机制会防止重复标题的问题。

    1.3 结构化排版——文章终于不是纯段落了

    传统 AI 生成的文章除了分段落就没有其他结构了,读起来像流水账。Zuo AI Plus 强制输出结构化内容:

    • ## 二级标题:自动提炼章节核心观点
    • ### 三级标题:进一步细化知识点
    • Markdown 表格:对比类、参数类内容用表格呈现
    • 有序列表:步骤类操作用数字编号
    • 无序列表:要点罗列类内容用 bullet points

    这让 AI 生成的文章在可读性上第一次接近了真人写作的专业度。

    1.4 智能配图占位

    AI 在生成正文时,会在合适的位置自动插入图片占位符 ![描述](image_placeholder)。在 Gutenberg 编辑器里显示为虚线占位块,编辑者一眼就知道"这里要放一张图",后续替换真实图片即可,不再遗漏配图。

    1.5 一键全量生成

    六步一步到位,中间每步可独立使用:

    标题 → 文章正文 → 摘要 → 标签 → 别名 → 特色图
    

    特色图生成时,AI 会读取文章正文前 1500 字作为参考(而非仅用标题),确保封面图与文章内容真正相关,而非泛泛的通用配图。


    二、第二大亮点:AI 导航模块——做网址目录的神器

    这是 Zuo AI Plus 区别于所有同类插件的另一个核心差异。

    市面上几乎找不到第二款 WordPress AI 插件同时做"内容创作"和"导航目录"两个方向。Zuo AI Plus 的导航模块不是附加功能,而是插件的一级模块,开发深度不亚于内容创作部分。

    2.1 它解决什么问题?

    做导航站、资源站、行业目录站的人都知道这个痛点:每添加一个网站,需要手动填写名称、描述、关键词、截图、分类标签……一个一个填,效率极低,而且描述写得不专业,SEO 效果差。

    Zuo AI Plus 导航模块的核心逻辑是:你给一个网址,AI 全部帮你搞定。

    2.2 AI 全量获取——输入网址,六件事自动完成

    点击一次"AI 全量获取",自动完成以下所有步骤:

    1. 抓取网站名称:从 <title> 标签、og:site_name 等多渠道获取
    2. 提取关键词:AI 分析页面内容,提取 3-5 个核心关键词
    3. 生成描述:AI 生成 300-500 字网站详细介绍,不是机械的 meta description,而是有人文感、有信息量的介绍文字
    4. 获取 Logo:优先抓取 Favicon 和 og:image 作为 Logo 备选
    5. 截图采集:三段式策略(见下文)
    6. 标签提取:从 AI 生成的简介中自动提取 nav_tag 分类标签,写入 WordPress 原生标签盒

    2.3 截图三级策略——速度、成本、质量三角最优解

    做导航站的人都知道截图是个麻烦事:太慢、太贵、或者截图质量差。Zuo AI Plus 的三级策略解决了这个矛盾:

    第一优先级:og:image目标网站自己的 og:image 预览图,最快(直接抓取)、零成本、最准确(网站自己选的代表图)。如果目标网站设置了 og:image,直接用。

    第二优先级:Chrome Headless 本地截图没有 og:image 或 og:image 不合适时,使用服务器本地 Chrome 无头浏览器截图。截图保存到 uploads/nav-screenshots/7 天本地缓存(同一 URL 7 天内不重复截图)。截图自动注册为 WordPress 媒体附件。

    第三优先级:thum.io 在线截图前两者都失败时的兜底方案,调用 thum.io API 生成在线缩略图链接。

    这个策略在大多数场景下只用第一优先级,速度极快;需要截图时用第二优先级,质量可控,成本最低。

    2.4 特色图自动化——截图即封面,一键完成

    导航模块的截图会自动:

    • 注册为 WordPress 媒体库附件(可在媒体库看到)
    • 设为该 nav_site 文章的特色图
    • AI 自动生成图片的 alt 文本、标题、描述
    • 中文 metadata 智能备用:如果 AI 返回的 metadata 是英文,自动用文章标题 + 内容生成中文备用版本,确保中文网站的 SEO 完整性

    2.5 导航页面的其他能力

    • SEO 权重胶囊:每个网站显示百度、360、搜狗、头条、移动端的排名情况,以彩色胶囊形式呈现,可视化权重
    • 分类树侧栏:层级分类(nav_category),支持展开/折叠,方便用户快速定位
    • 收藏与历史:LocalStorage 本地化存储,刷新不丢失
    • 暗色模式:完整 CSS 变量支持,随主题切换自动同步
    • 响应式设计:480px / 768px / 900px 三断点,移动端卡片网格自适应
    • Schema.org 结构化数据:自动注入 BreadcrumbList + WebSite JSON-LD,SEO 更友好
    • 移动端分享 + 二维码:手机访问时弹出分享面板,支持 QR Code 扫码分享
    • 访问量图表:最近 15 天每日访问量 Chart.js 图表展示

    2.6 适合做哪类网站?

    • 资源导航站:收录工具、网站、素材的导航目录
    • 行业目录站:某领域内的网站收录与评分
    • 工具收藏夹:个人或团队使用的工具合集展示
    • 网址大全:类似 hao123 但针对特定主题的精选网址站

    三、多模型支持——不绑定,灵活切换

    模型模型 ID擅长场景
    智谱 GLM-5glm-5 / glm-5-turbo / glm-4.7-flashx通用写作,性价比最高
    阿里通义千问qwen3.6-plus / wanx2.1-image中英双语,图片生成
    MiniMaxMiniMax-M2.7 / MiniMax-M2.7-highspeed快速响应,高速场景
    Kimikimi-k2.5 / moonshot-v1-8k长上下文,深度分析
    DeepSeekdeepseek-v3.2 / deepseek-coder推理能力,代码相关
    自定义端点OpenAI 兼容格式支持私有部署或第三方模型

    后台可随时切换默认模型,各操作的模型选择也相互独立——比如文章生成用智谱,图片生成用通义,互不干扰。

    每个模型独立配置 API Key,哪个模型的 API 余额多、哪个效果更好,就用哪个,不存在锁定问题。


    四、SEO 优化体系——不是口号,是标准

    很多插件说"AI 帮你做 SEO",但实际上只是生成一段文字。Zuo AI Plus 内置了一套明确的 SEO 标准常量,每个标准都有数字化的判断依据:

    4.1 SEO 标准体系

    元素标准要求说明
    标题30-60 字符关键词靠前,含搜索意图词
    摘要80-120 字符结构:关键词 + 价值点 + 行动引导
    标签3-5 个,每标签 2-6 字符完整中文名词词组,禁止单字和品牌名
    正文≥500 字,推荐 ≥800 字引言 + 2-4 章节 + 结论

    4.2 全站批量 SEO 诊断

    扫描站内所有文章,按上述标准打分,输出每个文章的 SEO 健康度报告。AI 根据评分结果一键优化,直接改写不符合标准的标题、摘要、标签、内容。


    五、其他功能一览

    5.1 内容改写与续写

    不是简单的同义替换,而是保留原意但完全重写表达方式。续写时 AI 会自动检测上文语境,判断是补充观点、深化分析、还是总结收尾,像同一个人继续往下写。

    支持多种风格语气:专业正式、轻松随性、温暖亲切、学术严谨,按需选择。

    5.2 知识库

    上传品牌介绍、产品文档、背景知识,AI 生成时自动参考这些内容,确保输出内容与品牌调性一致,不会出现"AI 编造品牌不存在的事实"的问题。

    5.3 多语言翻译

    内置 12 种语言互译:中文、英语、日语、韩语、法语、德语、西班牙语、葡萄牙语、俄语、阿拉伯语、意大利语、荷兰语。在 Gutenberg 编辑器内直接翻译,不用来回复制。

    5.4 客服聊天组件

    浮动 AI 聊天小部件,嵌入短代码

    AI 对话
    请先登录后再使用 AI 对话功能。
    即可在任意页面显示。AI 能够基于网站已有内容进行有针对性的问答,而非泛泛的闲聊。

    Gutenberg 区块支持:提供专用的 Chat 区块和 Image Generate 区块,后台直接拖拽使用。

    5.5 Playground(模型测试台)

    后台内置聊天界面,可分别测试所有已配置的模型,直观对比不同模型的输出质量,选择最适合自己场景的模型组合。

    5.6 使用统计

    实时追踪 Token 消耗、各操作调用次数、各模型使用分布,数据透明,心里有数。


    六、技术架构一览

    zuo-ai-plus/
    ├── zuo-ai-plus.php              # 主入口,版本 1.6.0
    ├── src/
    │   ├── Controllers/             # REST API 控制器(6个)
    │   │   ├── ContentController.php     # 生成/改写/扩写/配图
    │   │   ├── ChatController.php        # AI 客服聊天
    │   │   ├── ModelsController.php     # 模型配置与切换
    │   │   ├── SeoController.php        # SEO 诊断与优化
    │   │   ├── NavigationController.php  # 导航模块
    │   │   └── UtilityController.php     # 摘要/标签/别名/翻译
    │   ├── Models/                 # AI 模型封装(7个)
    │   │   ├── BaseModel.php            # 基类,统一接口
    │   │   ├── ZhipuModel.php          # 智谱 GLM
    │   │   ├── TongyiModel.php         # 通义千问
    │   │   ├── MiniMaxModel.php         # MiniMax
    │   │   ├── KimiModel.php            # Kimi
    │   │   ├── DeepSeekModel.php       # DeepSeek
    │   │   └── CustomModel.php          # 自定义 OpenAI 兼容端点
    │   ├── Admin/                  # 后台管理界面
    │   ├── Frontend/               # 前端渲染
    │   ├── Utils/                  # 工具类
    │   └── Loader.php              # 类自动加载器
    ├── Templates/                  # 导航模块前端模板
    └── Assets/                     # CSS / JS 静态资源
    

    关键技术细节

    • 推理模型思考清理:自动剥离 <think> / {{thinking}} / <reasoning> 标签,防止推理模型的思考过程混入输出内容。对于开头的长段英文分析前缀也会智能截断
    • 缓存机制:基于文章 ID + 内容哈希的 7 天 TTL 缓存,重复生成同一内容不会重复扣费
    • 速率限制:每个操作类型(generate/expand/rewrite/summarize 等)独立速率限制,防止单点 API 滥用
    • PHP-FPM 优化:解决了 pm.max_requests=10 导致的频繁进程回收问题(已修复为 500)

    七、适合人群与场景

    场景为什么选 Zuo AI Plus
    中文博客写作真人风格,不被搜索引擎识别为 AI 内容
    资源导航站内置导航模块,做网址目录几乎零成本
    内容批量生产一键全量生成 + SEO 标准,批量也能保持质量
    SEO 专业优化内置量化标准,批量诊断 + AI 一键优化
    WordPress 站点 AI 化不折腾 API,后台点点就搞定一切
    个人工具收藏站导航模块的截图 + 简介功能完美适合此场景

    八、总结

    Zuo AI Plus 不是一个功能堆砌的"AI 插件合集",它的两个核心差异点非常明确:

    第一,真人写作风格。 这是插件的灵魂升级,解决了 AI 内容同质化的根本矛盾。不是噱头,是从 prompt 设计到输出过滤到排版结构全链路的重构。

    第二,AI 导航模块。 内容创作 + 导航目录的组合在 WordPress 插件生态里几乎没有同类竞品。对于需要做网址目录站的站长,这是目前最低成本的解决方案。

    如果你正在为 WordPress 站点找一款真正适合中文场景、AI 输出有质量、内容工作流完整的插件,Zuo AI Plus 是目前最值得试用的选择。


    插件官网: https://www.yily.top版本: 1.6.0 | 更新: 2026-04-26测试环境: WordPress 6.0-6.9, PHP 8.1+所需 PHP 扩展: cURL, JSON, mbstring可选依赖: Chrome/Chromium(本地截图用,无则自动回退 thum.io)

    如果觉得有用,欢迎:

    • ⭐ GitHub 点个 Star:https://github.com/zuoyunlai/zuo-ai-plus
    • 📤 分享给 WordPress 朋友
    • 💬 评论区说说你最期待的功能

    让更多人知道,WordPress 站点管理可以更轻松。


    官网https://www.yily.top/zuo-ai-plus/

    GitHubhttps://github.com/zuoyunlai/zuo-ai-plus

    技术白皮书https://www.feishu.cn/docx/F9aEdwjanorHuAxZeq7cW1Z8nDY

  • 如何理解Web5.0:下一代去中心化网络指南

    如何理解Web5.0:下一代去中心化网络指南

    在当今快速发展的互联网环境中,技术术语层出不穷,其中“Web 5.0”这一概念逐渐引起广泛关注。尽管目前尚未有权威的定义或标准来明确界定Web 5.0的具体内容,但许多行业专家和科技公司已经开始探讨其可能的发展方向与特征。作为一位关注科技趋势的专业编辑,我们有必要对这一话题进行深入分析,以帮助读者更好地理解其潜在影响。

    Web 5.0的概念与发展背景

    Web 5.0并不是一个官方定义的技术版本,而是由一些技术观察者和企业提出的未来网络演进方向。它通常被视为继Web 1.0(静态网页)、Web 2.0(用户生成内容和社交网络)以及Web 3.0(去中心化和智能数据)之后的下一个阶段。随着人工智能、区块链、物联网等技术的不断成熟,Web 5.0的概念正在逐步形成。它可能强调更加智能化、个性化和去中心化的用户体验,同时注重数据隐私和安全。

    Web 5.0的核心特征与预期变化

    尽管Web 5.0尚未有统一的定义,但可以推测其核心特征可能包括更强大的人工智能整合、更高效的去中心化系统以及更紧密的用户与数据之间的互动。例如,未来的Web可能会更加依赖于AI驱动的个性化服务,使用户能够获得更精准的信息和推荐。此外,区块链技术的进一步应用可能带来更透明和安全的数据管理方式,减少对中心化平台的依赖。这些变化不仅会影响用户的日常使用体验,也可能对企业和开发者产生深远的影响。

    Web 5.0对行业与用户的影响

    Web 5.0的出现将对多个行业带来变革。对于企业而言,这意味着需要重新思考其数字化战略,以适应更加智能化和个性化的市场环境。同时,用户也将享受到更加高效和便捷的服务,但也需要更加关注自身的数据隐私和网络安全。对于开发者来说,新的技术框架和工具可能带来更多的创新机会,同时也伴随着更高的技术门槛。因此,无论是企业还是个人,都需要积极关注这一趋势,并做好相应的准备。

    总结

    Web 5.0作为一个尚处于探索阶段的概念,其具体形态和影响仍需时间验证。然而,可以预见的是,随着技术的不断进步,未来的互联网将更加智能化、去中心化和以用户为中心。无论其最终形式如何,Web 5.0都将继续推动数字生态系统的演进,为各行各业带来新的机遇与挑战。对于所有关注科技发展的人来说,保持开放的心态和持续的学习态度将是应对这一变革的关键。

  • OpenClaw记忆插件对比 Mem0 OpenViking TencentDB Agent Memory 性能分析

    OpenClaw记忆插件对比 Mem0 OpenViking TencentDB Agent Memory 性能分析

    OpenClaw 记忆插件深度对比报告

    报告时间: 2026-04-07 对比对象: Mem0、OpenViking、TencentDB Agent Memory 研究方法: 网络深度搜索 + 官方文档分析


    一、背景:为什么需要记忆插件?

    OpenClaw Agent 默认依靠会话上下文窗口(Context Window)来维持记忆,这一机制存在三个根本缺陷:

    • 上下文上限:200k tokens 的上下文在长对话中会被"压缩"(Compaction)丢弃早期信息
    • 跨会话失效:每次新会话从零开始,AI 无法记住上次对话中学到的内容
    • 无主动记忆:无法让 AI 有意识地存储、检索或遗忘特定记忆

    记忆插件通过将信息外部化存储,彻底解决上述问题——压缩不再影响已存储的记忆,AI 在每次回复前都能主动召回相关记忆。


    二、插件概述

    2.1 Mem0

    定位: 通用 AI 记忆层(Memory Layer),由独立公司 Mem0.ai 开发

    OpenClaw 集成包:@mem0/openclaw-mem0(NPM)

    核心思路: 将对话历史智能压缩为高度优化的记忆表示,存储在外部向量数据库中,按用户 ID 隔离,支持短期(会话)和长期(用户)双重作用域。

    发表论文: 《Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory》,ECAI 2025

    基准测试 在 LOCOMO 数据集(目前最全面的 AI 记忆评估基准)上取得领先成绩


    2.2 OpenViking

    定位: 开源"上下文数据库"(Context Database),由字节跳动(Volcengine)开发

    OpenClaw 集成方式:openviking 插件(已安装在当前系统),注册为 OpenClaw Context Engine

    核心思路: 模仿文件系统(Filesystem Paradigm)来组织和管理 AI 的所有上下文——记忆(user/)、资源(resources/)、技能(agent/)都有对应目录结构,实现上下文的有序分层。

    创新点: 提出"分层加载"(Tiered Loading)——记忆不只存原始向量,还自动生成 L0(一句话摘要)、L1(核心要点)、L2(完整内容)三级表示;同时具备自迭代(Self-Iteration)能力,记忆可随时间自动演进优化。


    2.3 TencentDB Agent Memory(代号"Lobster")

    定位: 腾讯云官方记忆服务,由腾讯云数据库团队开发

    集成方式: 作为插件集成进腾讯云 Lighthouse、ClawPro 等产品,支持一键免费激活

    核心思路: 采用四层递进记忆系统(Four-tier Progressive Memory),将碎片化对话逐步转化为:原始对话 → 结构化事实 → 上下文认知 → 个性化用户画像。

    特点: 与腾讯云基础设施深度绑定,目标是零门槛接入,适合国内腾讯云用户。


    三、核心技术架构对比

    3.1 记忆存储模型

    维度Mem0OpenVikingTencentDB Agent Memory
    存储范式平面向量切片(Flat Vector)分层文件系统(Hierarchical FS)四层递进结构(Progressive)
    索引方式向量相似度检索向量 + 层级路径双重索引结构化 + 向量混合
    自描述层级单一向量块L0/L1/L2 三级自描述四层渐进抽象
    自迭代能力✅ 基于 LLM 自动优化记忆✅ 内置 Self-Iteration 机制❌ 静态积累

    3.2 检索机制

    维度Mem0OpenVikingTencentDB Agent Memory
    检索方式语义向量搜索(ANN)语义 + 路径双重检索语义 + 上下文关系推理
    重排序支持✅(memory-lancedb-pro 支持 Cross-Encoder)需手动配置未公开
    召回精度优化多向量存储引擎可选(Qdrant/LanceDB/FalkorDB)分层加载减少无关内容四层过滤逐步聚焦

    四、功能深度对比

    4.1 双重记忆作用域

    Mem0 独家支持会话级短期记忆(Session)与用户级长期记忆(User)分离管理,两个作用域独立检索、互不干扰,会话关闭后短期记忆自动过期,长期记忆永久保留。

    OpenViking 和 TencentDB 均以用户/项目为基本隔离单位,没有明确的会话级短期记忆机制。

    4.2 Agent 可调用工具

    工具Mem0OpenVikingTencentDB Agent Memory
    记忆搜索✅ memory_search✅ auto-recall(自动触发)✅ 自动召回
    记忆存储✅ memory_store✅ auto-capture(自动捕获)✅ 自动累积
    记忆列表✅ memory_list
    记忆遗忘✅ memory_forget
    手动触发检索未公开

    结论: Mem0 提供最完整的显式记忆管理工具集,用户/开发者可精细控制记忆的生命周期。OpenViking 走的是"无感化"路线,主要依赖自动捕获和自动召回。

    4.3 向量存储引擎

    维度Mem0OpenVikingTencentDB Agent Memory
    默认引擎OpenAI 嵌入 + 内存向量存储OpenViking 内置存储腾讯云数据库(TDSQL/Redis)
    可替换引擎LanceDB、FalkorDB、Qdrant、Chroma、pgvector仅支持 OpenViking 自有存储仅支持腾讯云自有存储
    本地部署✅ 完全支持✅(local 模式)❌ 依赖腾讯云
    嵌入式(无服务)✅ LanceDB 嵌入式模式❌ 需要独立服务

    五、部署与集成复杂度

    5.1 安装难度

    插件安装复杂度配置项数量依赖要求
    Mem0⭐ 低(openclaw plugins install @mem0/openclaw-mem0需要 API Key(OpenAI/Mem0 Cloud)
    OpenViking⭐⭐ 中(需部署 OpenViking 服务端)需要 Python 环境 + API Key(ARK)
    TencentDB Agent Memory⭐ 极低(一键免费激活)极少必须使用腾讯云

    5.2 成本

    插件成本说明
    Mem0SaaS 订阅 / 自托管免费云端版按用量收费,自托管免费开源
    OpenViking完全免费开源Apache 2.0 协议,无需付费
    TencentDB Agent Memory完全免费腾讯云补贴期,官方免费提供

    5.3 供应商锁定

    • Mem0:低,可完全自托管,不依赖任何云厂商
    • OpenViking:无,完全开源,可本地运行
    • TencentDB Agent Memory极高,必须使用腾讯云基础设施

    六、使用场景推荐

    6.1 何时选 Mem0?

    • 需要精细化记忆管理(显式存储/遗忘/列表操作)
    • 需要**多智能体(Multi-Agent)**记忆隔离,每个 Agent 有独立记忆空间
    • 需要学术基准验证,有论文/产品需要引用 ECAI 2025 等权威评测
    • 需要多种向量引擎切换,已有 Qdrant/LanceDB 等基础设施
    • 追求生产级可靠性,愿意为托管服务付费

    6.2 何时选 OpenViking?

    • 希望零成本获得高质量长期记忆
    • 喜欢文件系统式的直觉化记忆管理方式
    • 需要记忆自迭代,让 AI 主动优化记忆质量而非被动积累
    • 追求分层加载节省 token(只加载 L0/L1 而非全量 L2)
    • 希望完全自主控制,不依赖任何云服务厂商

    6.3 何时选 TencentDB Agent Memory?

    • 已在使用腾讯云 Lighthouse / ClawPro 等腾讯系产品
    • 对价格敏感,希望零成本一键启用
    • 国内网络环境下运行,腾讯云网络质量有保障
    • 对记忆管理要求不高,只需要基础的"记住用户"能力

    七、当前系统现状与建议

    7.1 现有配置

    当前 OpenClaw 已安装并启用 OpenViking 作为 Context Engine,autoRecall 和 autoCapture 均已注册工作。

    7.2 综合评价

    维度Mem0OpenVikingTencentDB Agent Memory
    功能完整性⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
    部署简洁性⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
    成本中(付费 SaaS)免费开源免费
    数据自主性⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
    生态成熟度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
    自迭代/进化⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

    综合推荐:

    • 当前系统(已有 OpenViking):继续使用 OpenViking,综合性价比最优,完全免费、无供应商锁定、功能完整
    • 如需更精细的记忆控制:可补充安装 Mem0,通过 memory_forget 等工具实现精确记忆管理
    • 如在腾讯云生态内:TencentDB Agent Memory 是零门槛首选,但需注意供应商锁定风险

    八、参考资料

    • Mem0 官方文档:https://docs.mem0.ai/integrations/openclaw
    • Mem0 OpenClaw 插件 NPM:https://www.npmjs.com/package/@mem0/openclaw-mem0
    • OpenViking 官方文档:https://volcengine-openviking.mintlify.app/integrations/openclaw
    • OpenViking GitHub:https://github.com/volcengine/OpenViking
    • TencentDB Agent Memory 发布公告:https://www.binance.com/en/square/post/308407572644401
    • 《Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory》,ECAI 2025
    • LOCOMO Benchmark:https://arxiv.org/abs/2402.09727

    九、mem9 —— 云端持久化记忆新秀

    ⚠️ 注意: mem9 已在 ClawHub 上被标记为 DEPRECATED(不再维护),但其架构思路值得关注。

    定位: 云端持久化记忆系统,Backend 使用 TiDB Cloud Serverless(免费套餐:25GiB 存储 + 每月 2.5 亿请求单位)

    核心特点:

    • 插件无状态设计:所有记忆存储在 mnemo-server(TiDB),插件本身零状态,可自由部署多个 agent 实例,全部共享同一记忆池
    • 跨机器记忆同步:记忆绑定账户而非设备,换电脑不丢记忆
    • 多 Agent 共享记忆:Claude Code、OpenCode、OpenClaw 等平台插件可共享同一记忆池,团队协作友好
    • 混合检索:TiDB 原生 VECTOR 类型支持,无需额外部署向量数据库
    • 服务端自动 Embedding:TiDB 服务端生成向量,无需 OpenAI API Key 即可做语义搜索

    5 个显式工具: memory_store、memory_search、memory_get、memory_update、memory_delete

    ⚠️ 劣势:

    • 已被标记为 DEPRECATED,后续维护不确定
    • 需额外部署 mnemo-server(Go 服务),相比其他插件配置略复杂
    • 依赖 TiDB Cloud,有供应商锁定(虽然是免费套餐)

    十、四插件综合对比总表

    维度Mem0OpenVikingTencentDB Agent Memorymem9
    架构平面向量存储分层文件系统四层递进结构云端无状态 + TiDB
    作用域会话 + 用户双重用户/项目隔离用户画像级租户共享池
    显式记忆工具5个(最全)自动为主自动为主5个
    多 Agent 共享需配置多租户支持支持✅ 原生支持
    跨机器同步
    自迭代能力
    部署复杂度极低中(需部署 Server)
    成本SaaS付费/自托管免费免费开源免费(腾讯云补贴)免费(TiDB免费套餐)
    供应商锁定极高中(TiDB)
    维护状态✅ 活跃✅ 活跃✅ 活跃⚠️ DEPRECATED
    存储后端可替换(Qdrant/LanceDB等)OpenViking 自有腾讯云TiDB Cloud

    十一、最终推荐

    使用场景推荐方案
    当前系统(已有 OpenViking)继续用 OpenViking,综合最优
    多 Agent 协作 / 团队共享mem9(原生多 Agent 共享)
    国内用户,零门槛TencentDB Agent Memory
    追求功能完整 / 生产级Mem0(活跃维护 + 学术验证)
    mem9⚠️ 不推荐,已被标记废弃,后续维护无保障

    特别提示: mem9 虽架构创新(无状态插件 + TiDB 后端),但已被 DEPRECATED,不建议在生产环境使用。

  • ZHUOER 主题介绍:一款专为中文博客打造的高性能极简WordPress主题

    ZHUOER 主题介绍:一款专为中文博客打造的高性能极简WordPress主题

    一、主题概述

    ZHUOER 是一款基于 Minimalist 主题框架开发的简约极简风格 WordPress 主题,专为中文博客和企业官网设计。主题完全响应式,SEO友好,并针对中国大陆用户做了深度优化。

    二、核心设计特点

    2.1 极简美学设计

    主题采用极简设计理念,以留白和清晰的层次感为核心:配色以深黑文字 + 链接蓝为主色调,字体采用思源黑体(Noto Sans SC)+ 苹果系统字体,中文显示清晰锐利。

    2.2 中国本土化优化

    字体栈经过精心设计,覆盖:思源黑体、苹果系统字体、微软雅黑、冬青黑体等,确保在不同设备上都能获得最佳中文阅读体验。

    三、功能特性详解

    3.1 SEO 与性能优化

    • JSON-LD 结构化数据:首页自动生成 WebSite + SearchAction 数据;文章页生成 Article 结构化数据
    • Open Graph 标签:自动输出 og:type / og:title / og:image / og:url 等,分享更友好
    • Google Fonts 优化:非渲染阻塞方式加载字体,提升首屏加载速度
    • Emoji 禁用:移除 WordPress 内置 Emoji 脚本,减少 HTTP 请求
    • Gravatar 加速:使用中科大 USTC CDN 镜像加速头像加载
    • 响应式图片:自动裁剪 16:9 缩略图(1080×607)

    3.2 用户体验优化

    • 暗色模式切换:一键切换明暗主题,自动记忆用户偏好
    • 搜索高亮:搜索结果页关键词自动高亮显示
    • 平滑滚动:内容锚点平滑滚动动画
    • 相关文章推荐:文章底部智能推荐同分类文章
    • 代码高亮:支持代码块语法高亮显示

    四、社交媒体支持

    主题内置以下社交平台图标:微博、知乎、B站、小红书、GitHub、Twitter/X、Facebook、Instagram。

    配置路径:后台 → 外观 → ZHUOER 主题设置 → 社交链接

    五、技术规格

    • WordPress 版本:要求 6.0+,测试至 6.7
    • PHP 版本:要求 8.0+
    • 许可证:GPL v2 or later
    • 子主题支持:完整支持
    • WooCommerce:内置支持
    • 翻译准备:内置多语言支持

    六、总结

    ZHUOER 主题是一款用心打磨的中文极简WordPress主题,具有极简美学、本土优化、性能优先、SEO完善四大核心优势。

    适用场景:个人博客、技术文档、企业官网、作品集展示

    版本:1.0.9

    下载地址:

  • OpenClaw Systemd 管理指南

    本文档介绍如何使用 systemd 管理 OpenClaw 服务,包括启动、停止、重启、查看状态、查看日志等操作。


    一、systemd 基础命令

    1. 服务状态管理

    # 启动 OpenClaw
    sudo systemctl start openclaw
    
    # 停止 OpenClaw
    sudo systemctl stop openclaw
    
    # 重启 OpenClaw(修改配置后使用)
    sudo systemctl restart openclaw
    
    # 重载配置(不重启服务)
    sudo systemctl reload openclaw
    
    # 查看运行状态
    sudo systemctl status openclaw

    2. 开机自启设置

    # 设置开机自启动(默认已启用)
    sudo systemctl enable openclaw
    
    # 禁用开机自启动
    sudo systemctl disable openclaw
    
    # 查看是否开机自启
    sudo systemctl is-enabled openclaw

    二、日志查看

    1. 使用 journalctl 查看系统日志

    # 查看 OpenClaw 的所有日志
    sudo journalctl -u openclaw
    
    # 查看最新 100 行
    sudo journalctl -u openclaw -n 100
    
    # 实时跟踪日志(类似 tail -f)
    sudo journalctl -u openclaw -f
    
    # 查看今天的日志
    sudo journalctl -u openclaw --since today
    
    # 查看最近 1 小时的日志
    sudo journalctl -u openclaw --since "1 hour ago"
    
    # 查看特定时间段的日志
    sudo journalctl -u openclaw --since "2026-03-25 10:00" --until "2026-03-25 12:00"

    2. 使用 openclaw logs 命令

    # 查看最新 200 行日志
    openclaw logs
    
    # 查看指定行数
    openclaw logs --limit 500
    
    # 实时跟踪日志
    openclaw logs --follow
    
    # 本地时间显示
    openclaw logs --local-time
    
    # 纯文本格式(无颜色)
    openclaw logs --plain
    
    # JSON 格式
    openclaw logs --json

    三、故障排查

    1. 服务无法启动

    # 查看详细错误信息
    sudo systemctl status openclaw -l
    
    # 查看启动失败原因
    sudo journalctl -u openclaw -n 50 --no-pager
    
    # 检查配置文件语法
    openclaw config validate

    2. 查看进程是否重复

    # 检查有多少 openclaw 进程
    ps aux | grep openclaw | grep -v grep
    
    # 检查进程树
    pstree -p | grep openclaw
    
    # 检查端口占用
    sudo netstat -tlnp | grep openclaw
    sudo ss -tlnp | grep openclaw

    3. 强制重启(进程卡死时)

    # 停止服务
    sudo systemctl stop openclaw
    
    # 强制杀掉残留进程
    sudo pkill -9 openclaw
    
    # 重新启动
    sudo systemctl start openclaw

    四、配置管理

    1. 配置文件位置

    文件说明
    /etc/systemd/system/openclaw-gateway.servicesystemd 服务文件
    /etc/openclaw/openclaw.jsonOpenClaw 主配置文件
    /etc/openclaw/channels/频道配置文件目录

    2. 修改配置后生效

    # 修改配置文件后,重载 systemd
    sudo systemctl daemon-reload
    
    # 重启服务
    sudo systemctl restart openclaw

    3. 编辑服务文件

    # 编辑 systemd 服务文件
    sudo systemctl edit --full openclaw
    
    # 或直接使用编辑器
    sudo nano /etc/systemd/system/openclaw-gateway.service

    五、常用场景速查

    场景命令
    快速重启sudo systemctl restart openclaw
    查看是否在运行sudo systemctl is-active openclaw
    查看是否开机自启sudo systemctl is-enabled openclaw
    实时看日志openclaw logs --followsudo journalctl -u openclaw -f
    修改配置后重启sudo systemctl restart openclaw
    完全停止sudo systemctl stop openclaw && sudo systemctl disable openclaw
    完全启用sudo systemctl enable --now openclaw

    六、与 supervisord 对比

    功能systemdsupervisord
    启动服务sudo systemctl start openclawsudo supervisorctl start openclaw
    停止服务sudo systemctl stop openclawsudo supervisorctl stop openclaw
    重启服务sudo systemctl restart openclawsudo supervisorctl restart openclaw
    查看状态sudo systemctl status openclawsudo supervisorctl status openclaw
    查看日志sudo journalctl -u openclawsudo supervisorctl tail openclaw
    开机自启sudo systemctl enable openclaw需单独配置
    现代 Linux 支持✅ 原生支持❌ 需额外安装

    七、注意事项

    1. 不要同时使用 systemd 和 supervisord 管理 OpenClaw,会导致重复启动
    2. 修改配置文件后务必重启服务:sudo systemctl restart openclaw
    3. 查看日志时推荐用 openclaw logs,格式更友好
    4. 如果遇到问题,先用 sudo systemctl status openclaw -l 查看详细错误

    八、延伸阅读

    • OpenClaw 官方文档:https://docs.openclaw.ai
    • systemd 官方文档:https://systemd.io
    • 日志文件位置:/tmp/openclaw/openclaw-YYYY-MM-DD.log
  • Docker部署openclaw安装微信插件权限冲突问题的解决

    Docker部署openclaw安装微信插件权限冲突问题的解决

    问题背景

    在使用 Docker 部署 OpenClaw 并安装微信插件(@tencent-weixin/openclaw-weixin)时,遇到了一系列权限相关的问题,导致插件无法正常加载。

    问题现象

    1. 微信插件扫码登录成功后,配置也正确,但网关始终无法识别插件
    2. openclaw status 报错:plugins.allow: plugin not found: openclaw-weixin
    3. 提示权限被拒绝:permission denied
    4. 即使修复权限后重启容器,问题仍然重复出现

    问题根源分析

    根本原因:Docker 非 root 用户与社区插件权限要求的冲突

    OpenClaw 的社区插件(如微信插件)出于安全考虑,要求插件目录必须属于 root 用户(uid=0),否则会被安全策略阻止加载。

    而在 Docker 容器中,OpenClaw Gateway 通常以非 root 用户(如 node 用户,uid=1000)运行,这导致了一个根本性的矛盾:

    • 插件目录属主为 node → OpenClaw 拒绝加载(要求 root)
    • 插件目录属主为 root → Gateway 无法读取(权限不足)

    另一个问题:账号文件权限

    微信插件登录后,账号凭证文件(accounts/*.json)默认以 root 身份创建,如果属主是 root,则 Gateway 进程(node 用户)无法读取,导致 "no token" 错误。

    解决思路

    需要在 Docker 容器启动时,自动将插件目录和账号文件的属主恢复为 node 用户,确保:

    1. 插件目录属主为 node(Gateway 可以读取)
    2. 同时满足 OpenClaw 的安全策略要求

    解决方案

    方案:修改 docker-compose.yml,注入权限修复命令

    第一步:确认插件安装路径

    微信插件安装后位于:

    • 扩展目录:/home/node/.openclaw/extensions/openclaw-weixin
    • 账号数据:/home/node/.openclaw/openclaw-weixin

    第二步:修改 docker-compose.yml

    openclaw-gateway 服务的 command 中,加入启动前的权限修复命令:

    services:
      openclaw-gateway:
        image: docker.cnb.cool/btpanel/openclaw
        environment:
          HOME: /home/node
          TERM: xterm-256color
        volumes:
          - ${DATA}/config:/home/node/.openclaw
          - ${DATA}/work:/home/node/clawd
        ports:
          - "${OPENCLAW_GATEWAY_PORT:-18789}:18789"
          - "${OPENCLAW_BRIDGE_PORT:-18790}:18790"
        init: true
        restart: unless-stopped
        command:
          [
            "sh",
            "-c",
            "chown -R node:node /home/node/.openclaw/extensions/openclaw-weixin /home/node/.openclaw/openclaw-weixin && node dist/index.js gateway --bind ${OPENCLAW_GATEWAY_BIND:-lan} --port ${OPENCLAW_GATEWAY_PORT:-18789}"
          ]

    关键修改说明:

    • command 从直接启动 node 改为先执行 sh -c
    • 在启动网关之前,先执行 chown -R node:node 将插件目录和账号数据的属主恢复为 node 用户
    • 使用 && 确保权限修复成功后才启动网关

    第三步:重启容器使配置生效

    docker-compose up -d

    第四步:验证插件状态

    openclaw status

    正常输出应包含:

    Channel         │ Enabled │ State  │ Detail
    openclaw-weixin │ ON      │ OK     │ token unknown (48cc… · len 58) · accounts 1/1

    完整的 docker-compose.yml 示例

    services:
      openclaw-gateway:
        image: docker.cnb.cool/btpanel/openclaw
        environment:
          HOME: /home/node
          TERM: xterm-256color
        volumes:
          - ${DATA}/config:/home/node/.openclaw
          - ${DATA}/work:/home/node/clawd
        ports:
          - "${OPENCLAW_GATEWAY_PORT:-18789}:18789"
          - "${OPENCLAW_BRIDGE_PORT:-18790}:18790"
        init: true
        restart: unless-stopped
        command:
          [
            "sh",
            "-c",
            "chown -R node:node /home/node/.openclaw/extensions/openclaw-weixin /home/node/.openclaw/openclaw-weixin && node dist/index.js gateway --bind ${OPENCLAW_GATEWAY_BIND:-lan} --port ${OPENCLAW_GATEWAY_PORT:-18789}"
          ]
    
      openclaw-cli:
        image: docker.cnb.cool/btpanel/openclaw
        profiles:
          - cli
        environment:
          HOME: /home/node
          TERM: xterm-256color
          BROWSER: echo
        volumes:
          - ${DATA}/config:/home/node/.openclaw
          - ${DATA}/work:/home/node/clawd
        stdin_open: true
        tty: true
        init: true
        entrypoint: ["node", "dist/index.js"]

    安装微信插件的完整步骤

    1. 进入 openclaw-cli 容器

    docker-compose run --rm openclaw-cli /bin/bash

    2. 安装微信插件(使用官方安装工具)

    npx -y @tencent-weixin/openclaw-weixin-cli@latest install

    安装工具会自动完成以下操作:

    • 下载插件包
    • 安装到 /home/node/.openclaw/extensions/openclaw-weixin
    • 配置 plugins.allowplugins.entries

    3. 扫码登录

    openclaw channels login --channel openclaw-weixin

    终端会显示二维码,用微信扫描授权即可。

    4. 退出容器并重启主服务

    exit
    docker-compose up -d

    常见问题排查

    Q1: 扫码后提示 "no token"

    原因: 账号文件(accounts/*.json)属主是 root,Gateway 进程(node 用户)无法读取。

    解决:

    chown -R node:node /home/node/.openclaw/openclaw-weixin/

    Q2: 重启容器后插件又失效

    原因: 容器重启后,插件目录权限被重置,或者 docker-compose.yml 中没有加入权限修复命令。

    解决: 按照"解决方案"章节修改 docker-compose.yml,并重新 docker-compose up -d

    Q3: 插件目录属主已经是 root,但仍然报 "plugin not found"

    原因: OpenClaw 要求社区插件目录属主必须是 root,但 Gateway 以 node 用户运行时又无法读取。需要让 Gateway 以 node 用户读取,同时满足 OpenClaw 的属主要求。

    解决: 使用本文的方案,将属主改为 node,通过 docker-compose 启动命令在运行时动态满足要求。

    总结

    Docker 非 root 用户部署 OpenClaw 社区插件的核心矛盾在于:

    • OpenClaw 安全策略要求社区插件属主为 root
    • Docker 进程node 用户运行,无法读取 root 属主的文件

    通过在 docker-compose 的 command 中注入权限修复命令,每次容器启动时自动将插件目录和账号数据的属主恢复为 node,既满足了 OpenClaw 的安全要求,又解决了 Gateway 的读取问题,实现了插件的永久正常运行。

  • Docker部署Openclaw

    Docker部署Openclaw


    为什么选择 Docker?

    在 Docker 中运行 OpenClaw 相比裸机安装具备三大显著优势:

    1. 安全隔离:代理运行在一个对宿主系统访问受限的容器内。如果恶意技能或提示词注入试图访问你的文件,容器边界会限制其影响范围。
    2. .可复现性:同一个 Docker 镜像在任何机器上都能以相同方式运行——无论是你的笔记本电脑、VPS 还是树莓派。
    3. .清理方便:想从头开始?删除容器,启动一个新的就行。没有残留文件,没有损坏的 Node.js 安装。

    前置条件

    • Docker Desktop(macOS/Windows)或 Docker Engine(Linux)
    • Docker Compose v2(Docker Desktop 已包含)
    • 至少 2 GB 内存可供容器使用
    • 一个 AI API 密钥(Anthropic、OpenAI 或其他支持的服务商)

    快速开始

    方案 A:官方 Docker Compose(推荐)

    克隆 OpenClaw 仓库并使用内置的 Docker 配置:

    bash

    git clone https://github.com/openclaw/openclaw.git
    cd openclaw
    

    运行设置脚本,它会创建必要的目录和配置:

    bash

    bash docker-setup.sh
    
    • ~/.openclaw/——配置文件、SOUL.md、API 密钥
    • ~/openclaw/workspace/——代理可以访问的文件

    在容器内运行引导向导:

    bash

    docker compose run --rm openclaw-cli onboard
    

    按照提示设置 API 密钥并连接聊天平台。然后启动网关:

    bash

    docker compose up -d openclaw-gateway
    

    你的代理现在已经在后台运行了。

    方案 B:预构建镜像

    如果你不想克隆仓库,可以使用官方预构建镜像:

    bash

    docker run -d \
      --name openclaw \
      --restart unless-stopped \
      -v ~/.openclaw:/root/.openclaw \
      -v ~/openclaw/workspace:/root/workspace \
      -p 3000:3000 \
      ghcr.io/openclaw/openclaw:latest
    

    Docker Compose 参考配置

    以下是一份带注释的生产环境 docker-compose.yml

    version: "3.8"
    services:
      openclaw-gateway:
        image: ghcr.io/openclaw/openclaw:latest
        container_name: openclaw
        restart: unless-stopped
        ports:
          - "3000:3000"        # Web UI
        volumes:
          - ~/.openclaw:/root/.openclaw          # Config and data
          - ~/openclaw/workspace:/root/workspace  # Agent workspace
        environment:
          - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
          - OPENAI_API_KEY=${OPENAI_API_KEY}
          - TZ=Asia/Shanghai     # Set your timezone
        mem_limit: 2g            # Prevent runaway memory usage
        logging:
          driver: json-file
          options:
            max-size: "10m"
            max-file: "3"
    

    在同一目录下创建一个 .env 文件,写入你的 API 密钥:

    ANTHROPIC_API_KEY=sk-ant-xxxxx
    OPENAI_API_KEY=sk-xxxxx

    环境变量

    变量是否必需说明
    ANTHROPIC_API_KEY是*Claude API 密钥
    OPENAI_API_KEYGPT API 密钥(如使用 OpenAI)
    OPENCLAW_PORTWeb UI 端口(默认:3000)
    OPENCLAW_HOME容器内的数据目录
    TZ定时任务的时区

    *至少需要一个 AI 服务商的密钥。

    容器管理

    # 查看日志
    docker logs -f openclaw
    
    # 停止代理
    docker compose stop
    
    # 启动代理
    docker compose up -d
    
    # 修改配置后重启
    docker compose restart
    
    # 更新到最新版本
    docker compose pull
    docker compose up -d
    
    # 进入容器 Shell
    docker exec -it openclaw bash
    
    # 在容器内运行 CLI 命令
    docker exec openclaw openclaw skill list
    docker exec openclaw openclaw status
    

    安全加固

    限制文件系统访问

    只挂载代理实际需要的目录。避免挂载整个 home 目录:

    volumes:
      - ~/.openclaw:/root/.openclaw:rw     # Config (read-write)
      - ~/documents:/root/docs:ro           # Documents (read-only)
    

    网络隔离

    如果你的代理不需要访问本地网络服务,可以限制其网络:

    networks:
      openclaw-net:
        driver: bridge
        internal: false    # Set to true to block all external access
    

    只读根文件系统

    为了最大程度的安全,将根文件系统设为只读,只允许对特定路径进行写入:

    read_only: true
    tmpfs:
      - /tmp
      - /run
    

    更新

    OpenClaw 更新频繁。要更新你的 Docker 部署:

    docker compose pull           # Pull latest image
    docker compose up -d          # Recreate container with new image
    docker image prune -f         # Clean up old images
    

    你的配置和数据保存在挂载的卷中,因此更新不会造成数据丢失。

    故障排除

    容器启动后立即崩溃:使用 docker logs openclaw 查看日志。常见原因:缺少 API 密钥、内存不足或端口冲突。

    WhatsApp 二维码不显示:以交互模式运行引导程序:docker compose run --rm openclaw-cli onboard。二维码需要支持渲染的终端。

    挂载卷出现权限错误:确保宿主机上的目录存在且归当前用户所有:mkdir -p ~/.openclaw ~/openclaw/workspace

    内存占用过高:在 docker-compose.yml 中设置 mem_limit: 2g 以防止容器占用过多内存。

  • Openclaw安装后优化配置

    Openclaw安装后优化配置

    一、OpenClaw AGENTS.md 配置

    AGENTS.md 是什么?

    很多人在搜"OpenClaw AGENTS.md 怎么写",先说清楚它跟其他配置文件的关系:

    • SOUL.md = 性格("你是一个随和、实在的助手")
    • USER.md = 用户信息("你在帮谁")
    • AGENTS.md = 工作手册("每天上班先看邮件,写完代码要测试,删文件前要问我")

    这就是AGENTS.md的价值所在:它如同人工智能的工作手册,清晰指引其运作流程。

    AGENTS.md文件应放置在workspace的根目录下(与SOUL.md文件同级),这样OpenClaw在每次启动新会话时便会自动加载该文件。

    OpenClaw AGENTS.md 记忆写入规范:教 AI 怎么记笔记

    光会读记忆不够,还得教它怎么记忆。未规范的 AI 要么全堆到 MEMORY.md 里(变成流水账),要么根本不写(下次就忘了)。

    在 AGENTS.md 里加上写入规范:

    ## Memory
    You wake up fresh each session. These files are your continuity.
    ### Memory stratification
    | Level | File | Purpose |
    |------|------|------|
    | Index Layer | `MEMORY.md` | About users, capability overview, and memory index. Keep it concise (<40 lines) |
    | Project Layer | `memory/projects.md` | Current Status and To-Do of Each Project |
    | Infrastructure Layer | `memory/infra.md` | Quick Reference for Server, API, Deployment, and Other Configurations |
    | Lesson Layer | `memory/lessons.md` | Pitfalls encountered, graded by severity |
    | Log Layer | `memory/YYYY-MM-DD.md` | Daily Original Record |
    ### Write rules
    - Logs are written into `memory/YYYY-MM-DD.md`, with the format shown below
    - Project status: Update `memory/projects.md` synchronously when the project makes progress
    - Lesson: Write it down in `memory/lessons.md` after falling into a pitfall
    - MEMORY.md: Updated only when the index changes, maintaining conciseness
    ### Log format
    ### [PROJECT: Name] Title
    - **Conclusion**: One-sentence summary
    - **File changes**: Involved files
    - **Lessons**: Pitfalls (if any)
    - **Tags**: #tag1 #tag2
    ### Iron Law
    - Remember the conclusion, not the process
    - The tag facilitates retrieval by memorySearch
    - "Mental notes" don't survive session restarts. Files do.

    记结论不记过程是核心原则。

    OpenClaw 安全边界配置:AI 能自己做什么,什么要先问你

    在 AGENTS.md 里加上:

    ## Safety
    
    - Don't exfiltrate private data. Ever.
    - Don't run destructive commands without asking.
    - `trash` > `rm` (recoverable beats gone forever)
    - When in doubt, ask.
    
    ## External vs Internal
    
    **Safe to do freely:**
    - Read files, explore, organize, learn
    - Search the web, check calendars
    - Work within this workspace
    
    **Ask first:**
    - Sending emails, tweets, public posts
    - Anything that leaves the machine
    - Anything you're uncertain about
    
    ## Group Chats
    
    You have access to your human's stuff. That doesn't mean you share it.
    In groups, you're a participant — not their voice, not their proxy.

    这个模板是一个精简的起点,随着你对它的使用日益深入,你将可以逐步向其中增添更多规则。

    二、 用 memoryFlush 解决 AI 失忆问题

    为什么 OpenClaw 聊着聊着 AI 会"失忆"?

    每个模型都存在上下文窗口的限制(例如 Claude 为 200K token),当对话长度接近此限制时,OpenClaw 会自动将较早的对话内容压缩为摘要以释放空间,但这一压缩过程可能导致部分细节的丢失。

    OpenClaw memoryFlush 配置方法:压缩前自动保存关键信息

    解决方案:开启 memoryFlush,在压缩触发之前,先让 AI 把重要信息写入文件。

    在 openclaw.json 里加上:

    {
      "agents": {
        "defaults": {
          "compaction": {
            "reserveTokensFloor": 20000,
            "memoryFlush": {
              "enabled": true,
              "softThresholdTokens": 4000
            }
          }
        }
      }
    }

    参数说明:

    参数含义推荐值
    reserveTokensFloor压缩后至少保留多少 token 的最近对话20000
    memoryFlush.enabled是否开启压缩前自动保存true
    memoryFlush.softThresholdTokens距离压缩多少 token 时触发保存4000

    💡 memoryFlush 静默执行,不打断对话。开了 verbose 模式(/verbose)可以看到 🧹 Auto-compaction complete 的提示。

    OpenClaw memorySearch 精度优化:结构化日志大幅提升检索命中率

    memorySearch 的底层是向量语义检索,结构化日志的命中率比非结构化日志高得多:

    用免费 SiliconFlow bge-m3 配置 OpenClaw memorySearch

    国内用户最快上手的方案——SiliconFlow 提供的 bge-m3 向量模型完全免费:

    {
      "memorySearch": {
        "enabled": true,
        "provider": "openai",
        "remote": {
          "baseUrl": "https://api.siliconflow.cn/v1",
          "apiKey": "你的 SiliconFlow API key"
        },
        "model": "BAAI/bge-m3"
      }
    }

    注册硅基流动,点击:https://cloud.siliconflow.cn/i/DU2lQbhb,注册 → 控制台 → 创建 API key。

    推荐 bge-m3 的原因在于它完全免费,对中英文双语的支持出色,并且其 1024 维向量在精度和性能之间取得了良好的平衡。

    OpenClaw 自动记忆维护:防止过期日志干扰 memorySearch 结果

    在 HEARTBEAT.md 里加上每周自动维护任务:

    ## 记忆维护(每周一次)
    读取 `memory/heartbeat-state.json`,检查 `lastMemoryMaintenance` 字段。
    如果距今 >= 7 天:
    1. 读最近 7 天的 `memory/YYYY-MM-DD.md` 日志
    2. 提炼有价值的信息到对应文件(projects.md / lessons.md)
    3. 压缩已完成一次性任务的日志为一行结论
    4. 删除过期信息
    5. 更新 `heartbeat-state.json` 的 `lastMemoryMaintenance` 为今天

    创建 memory/heartbeat-state.json

    {
      "lastMemoryMaintenance": "2026-01-01"
    }

    三、OpenClaw 子 Agent — 让 AI 并行处理复杂任务

    OpenClaw 子 Agent 配置方法(openclaw.json + AGENTS.md)

    第一步:在 AGENTS.md 里声明使用规范

    ## 子 Agent
    
    如果任务比较复杂或耗时较长,可以派子 agent 去执行。
    
    ### 模型选择策略
    | 等级 | 模型别名 | 适用场景 |
    |------|----------|----------|
    | 🔴 高 | opus | 复杂架构设计、多文件重构、深度推理 |
    | 🟡 中 | sonnet | 写代码、写脚本、信息整理(默认) |
    | 🟢 低 | haiku | 简单文件操作、格式转换、搜索汇总 |
    

    第二步:在 openclaw.json 里配置模型别名

    {
      "models": {
        "your-provider/claude-opus-4": { "alias": "opus" },
        "your-provider/claude-sonnet-4": { "alias": "sonnet" },
        "your-provider/claude-haiku-4": { "alias": "haiku" }
      }
    }
    

    子 Agent 模型分级token 消耗能降 60-70%

    OpenClaw 子 Agent task 描述写法

    子 Agent 是"零上下文"的,只能看到主脑给它的 task 描述,所以描述质量决定输出质量。

    OpenClaw 子 Agent 并发限制

    经验值:同时最多跑 2 个子 Agent,4 个基本触发 API 429 限流。有依赖关系的任务(B 依赖 A 的输出)必须串行,在 AGENTS.md 里提醒主脑注意任务依赖即可。

    四、openclaw.json 配置参数调到最优

    所有配置写在 ~/.openclaw/openclaw.json,修改后 openclaw gateway restart 生效。

    blockStreaming — 解决 AI 长回复要等很久的问题

    {
      "agents": {
        "defaults": {
          "blockStreamingDefault": "on",
          "blockStreamingBreak": "text_end",
          "blockStreamingChunk": { "minChars": 200, "maxChars": 1500 }
        }
      }
    }
    

    ackReaction — 发消息后立刻知道 AI 收到了

    {
      "channels": {
        "discord": { "ackReaction": "🫐" },
        "telegram": { "ackReaction": "👀" }
      }
    }
    

    compaction — 解决 AI 长对话失忆问题

    {
      "agents": {
        "defaults": {
          "compaction": {
            "reserveTokensFloor": 20000,
            "memoryFlush": { "enabled": true, "softThresholdTokens": 4000 }
          }
        }
      }
    }
    

    相关命令:/compact 重点保留技术决策/new(开新 session)、/status(查 token 用量)

    Heartbeat 调优 — 防止 AI 在非活跃时间骚扰你

    {
      "agents": {
        "defaults": {
          "heartbeat": {
            "every": "30m",
            "target": "last",
            "activeHours": { "start": "08:00", "end": "23:00" }
          }
        }
      }
    }
    

    openclaw.json 其他常用配置汇总

    配置路径作用推荐值
    tools.exec.enabled是否允许执行 shell 命令true
    tools.web.search.enabled是否允许网页搜索true
    tools.web.search.apiKeyBrave Search API key(免费)去 brave.com/search/api 申请
    tools.media.image.enabled是否允许 AI 识别图片true(需模型支持 vision)
    agents.defaults.workspaceworkspace 路径"~/.openclaw/workspace"
    channels.discord.maxLinesPerMessageDiscord 单条最大行数17

    常见问题 FAQ

    Q:OpenClaw AGENTS.md 放在哪里?

    A:workspace 根目录,和 SOUL.md、USER.md 同级。路径通常是 ~/.openclaw/workspace/AGENTS.md

    Q:OpenClaw memoryFlush 开了还是失忆怎么办?

    A:检查 softThresholdTokens 是否设够大(推荐 4000)。对话特别关键时,手动 /compact 重点保留XXX 指定保留内容。

    Q:OpenClaw Cron 任务设了但没触发?

    A:99% 是时区问题——没设 tz 字段导致按 UTC 执行。另外检查 delivery.mode 是否设为 "announce",不设任务静默执行,你不会收到通知。

  • 零成本养龙虾:OpenClaw + Ollama如何配置部署

    零成本养龙虾:OpenClaw + Ollama如何配置部署

    结合 Ollama 运行本地大语言模型(LLM),即可轻松部署 OpenClaw 智能代理。本文涵盖真实的 GPU 性能基准测试,揭示那些可能影响系统稳定的上下文窗口陷阱,并提供经过生产环境验证的有效模型推荐。

    上下文窗口陷阱

    结合 Ollama 使用 OpenClaw 听起来很简单。安装 Ollama,将 OpenClaw 指向它,选择一个模型,搞定。每个教程都把它展示成一个 10 分钟就能完成的任务。

    事实并非如此。

    经过几个月在消费级 GPU 上运行本地大模型来驱动 OpenClaw 代理,真实发生的情况是:你跟着教程做,在交互式测试中一切似乎都正常运行,然后当你设置了定时代理任务后,它们却开始产生语无伦次的输出。没有错误,没有警告,纯粹是垃圾数据。

    罪魁祸首几乎总是 Ollama 默认搞错的一个设置。Ollama 默认将上下文 tokens 设置为 2048。但 OpenClaw 代理最少需要 16K-24K。

    这不是一个建议。代理的对话包含了系统提示词 (system prompts)、工具定义、对话历史以及工具调用的结果。在模型开始推理当前任务之前,哪怕是一个中等复杂度的单次代理交互都可以轻易消耗 8,000 到 12,000 个 token。

    如果上下文窗口只有 2048 个 token,Ollama 会静默截断超出该限制的所有内容。模型看到的可能只有实际对话的 10%。它只会对这个片段做出响应。输出看起来是不对的,而不是坏掉了。你会花好几个小时调试你的代理逻辑,而真正的问题只是一个环境变量。

    将 OLLAMA_NUM_CTX 设置为 24576。这正好匹配了 OpenClaw 的 contextTokens 设置,并为工具定义保留了余量。这绝对是首先要做的。现在就去设置。

    OLLAMA_NUM_CTX=24576

    为什么选择本地部署?

    • 成本:每次推理 $0。如果你跑的代理每个任务需要进行几十次大模型调用,API 的计费会迅速叠加。除了硬件成本之外,本地推理是免费的。
    • 隐私:你的数据永远不会离开你的网络。对于受监管的行业或敏感操作来说,这比性能基准测试重要得多。
    • 延迟:无需网络往返。对于简单、快速的代理任务,本地推理可能比等待 API 响应更快。尤其是当你的代理正在进行快速连发的工具调用时(每次网络往返会增加 200-500ms 的延迟)。

    大多数“本地部署”指南忽略的一点是:本地模型在复杂任务上会使用更多的 tokens。它们会陷入循环,不断重试工具调用。它们消耗上下文的速度更快,因为它们需要更多推理步骤,才能达成单个 Claude API 调用一遍就能得出的结论。我们曾观察到一个本地 30B 模型在一个任务上尝试了 6 次工具调用,而 Sonnet 一次就能搞定。虽然推理确实免费,但额外消耗的上下文却不容忽视。

    对于简单的流程化工作(归档、排序、格式化、数据提取、监控等),本地大模型是正确的选择。如果涉及多步推理链、复杂的工具编排或需要前沿水平的思考,请将它们路由到 API 模型。了解一种工具会在哪里崩溃,比假装它完美无瑕更有价值。

    没人公开的生产环境配置

    每一个 Ollama 教程都只演示 ollama serve 并认为大功告成。下面是一个真正的生产环境配置应该有的样子:

    OLLAMA_HOST=0.0.0.0 OLLAMA_KEEP_ALIVE=1h OLLAMA_NUM_CTX=24576 OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 OLLAMA_NUM_PARALLEL=2 NVIDIA_VISIBLE_DEVICES=all CUDA_VISIBLE_DEVICES=0

    每个参数的作用解释:

    • OLLAMA_NUM_CTX=24576 设置上下文窗口。使其与 OpenClaw 的 contextTokens 设置加上留白相配合。默认的 2048 对代理工作负载来说毫无用处。
    • OLLAMA_FLASH_ATTENTION=1 启用 Flash Attention 以加快推理速度。这也解锁了 KV 缓存量化功能,也就是下一个变量的作用。
    • OLLAMA_KV_CACHE_TYPE=q8_0 将 KV 缓存量化为 8 位,这样可以在质量下降极小的情况下把缓存内存占用削减约一半。在一块 24GB 的显卡上,这将决定你的模型能否加载上去。
    • OLLAMA_NUM_PARALLEL=2 允许两个并发的代理请求。如果你运行了多个代理,它们可以在无需排队的情况下共享模型。请根据你的显存余量进行设置,因为每增加一个并行槽都会消耗额外的 KV 缓存内存。
    • OLLAMA_KEEP_ALIVE=1h 设置在最后一次请求后,模型仍保留在 VRAM 中一小时。默认只有 5 分钟,这意味着如果你的代理在任务间暂停,每次都必须重新经历冷启动。
    • CUDA_VISIBLE_DEVICES=0 将 Ollama 绑定到特定的 GPU。如果你有多块显卡,请分配专用的硬件资源。多个服务在高负载下共享 GPU 会导致 CUDA 内存不足 (OOM) 而崩溃。
    • OLLAMA_HOST=0.0.0.0 在所有网络接口上暴露 Ollama,使得 OpenClaw 可以从容器中访问它。

    身份验证的变通方法

    OpenClaw 的网关(Gateway)要求每个 Provider 都要有 API Key,即使是根本不需要密钥的 Ollama 也不例外。尝试设置 type: "none" 会在热重载时被剥离。

    修复方案: 在 provider 配置中设置一个虚假的 apiKey 值(任何字符串都可以),并将其配上 authHeader: false。根本没人记录这点,如果没有它,系统会静默阻止你的代理运行。

    apiKey: "dummy-key"
    authHeader: false

    哪些模型真正有效

    并非所有的模型都能胜任代理任务。“工具调用 (Tool calling)” 的支持是不可商量的条件。如果没有它,OpenClaw 代理无法执行操作,模型只会描述出“它打算做什么”,而不是“实际去执行它”。

    在测试了几十个模型之后,这些是能稳定处理 OpenClaw 代理的模型:

    • qwen3:30b-a3b:这是我们一直使用的首选。它是一个混合专家 (MoE) 模型:总量 300 亿个参数,但每次推理只有 30 亿参数激活。你能获得 30B 级别的推理能力,却不需要承担密集型 30B 模型高昂的显存代价。工具调用非常稳定,即使是复杂的代理调用链也能完成而不会陷入无限重试死循环。
    • qwen2.5:14b:中端替代选项。如果你 GPU 装不下上述模型,那么 14B 模型足以处理更简单的代理任务。但在多步复杂工作上,预期它会有更多重试。
    • qwen3:0.6b:一个轻量级的效用模型。适合用作轻量级的预处理或嵌入任务。切勿将其用于需要逻辑推理的代理功能。

    我们丢弃了 Reddit 上极其热门的几个模型,因为它们在测试中要不在工具调用上失败,要不就在工具参数上产生幻觉 (hallucinate)。Reddit 上的炒作往往与生产环境的现实不符。直到其他模型家族在结构化输出和工具调用上追平差距之前,应对代理工作负载还是老老实实坚持使用 Qwen。

    GPU 现实检查

    模型卡上的理论 VRAM (显存) 数据其实没有把 KV 缓存的开销算进去。真实数据看起来是这样的:

    • qwen3:30b-a3b (2个并行槽位和 q8_0 缓存):在 RTX 3090 上大约需要 21GB。这留下了约 3GB 的余量。虽然很紧凑,但在启用 flash attention 时,满载情况下相当稳定。
    • qwen2.5:14b (2个并行槽位):大约需要 12GB。能在 RTX 3090 上绰绰有余地运行,或者甚至能勉强挤进配备 12GB 显存的 RTX 4070。

    Docker 陷阱

    docker restart 不会应用你的 docker-compose 文件中所做的更改。如果你更改了环境变量,必须执行 docker compose down && docker compose up -d。这其实是一个 Docker 基本常识,但它绊倒了所有配置 Ollama + Docker 的人,因为你会通常只是改变了 OLLAMA_NUM_CTX,重启容器,然后疑惑什么都没有发生变化。

    多 GPU 分配

    如果你运行了多个需要使用 GPU 的服务,请务必使用 CUDA_VISIBLE_DEVICES 为每个服务分配专门的显卡。将同一个 GPU 混用(在 Ollama 和其他 CUDA 服务之间共享)会导致偶发的、根本无法一致性重现的显存溢出 (OOM) 崩溃。

    五个会破坏你系统的问题

    以下内容绝非纸上谈兵。每一个都来自实际的生产级故障。

    1. MULTIUSER_CACHE 崩溃

    当设置了 OLLAMA_NUM_PARALLEL 为 2 或更高时,OLLAMA_MULTIUSER_CACHE 会导致 GGML_ASSERT 崩溃。模型能顺利加载、完成一个请求服务,随后在介入第二个并发请求时就会崩溃。

    解决办法: 不要设置 OLLAMA_MULTIUSER_CACHE。作为福利,不开启这个能帮你大概省下 0.8GB 的 VRAM。这其实在 Ollama GitHub 的 Issue #12150 已经被记录。这不是你那里的配置错误,而是一个已知 Bug。

    2. 模型白名单静默失败

    OpenClaw 的模型白名单是最令人挫败的坑。交互式会话可以绕过白名单检查! 因此当你测试代理时,完美无瑕毫无报错,但当你把它发布为 cron 定时周期性任务时,它却会静默失败。

    你必须把使用的模型显式添加到 OpenClaw 的模型白名单中,计划任务才能去使用它。千万别再被能够跳过这个检查的“交互式会话”迷惑了。

    3. 网关配置的竞态条件

    OpenClaw 的网关会在启动时将其配置加载进内存中,并会周期性地将其同步回磁盘上。如果你在网关运行期间手滑编辑了你的配置文件,你的变更将在几秒内被直接覆盖踩掉。

    解决办法: 修改完配置信息后,即刻重启网关。永远不要采用“编辑然后等待”的策略,网关在下次同步周期必将覆盖你辛辛苦苦修改好的内容。

    4. 无密钥提供商的身份验证

    在上文我们提到过这点,但强调一下是非常值得的:Ollama 不需要 API key。但 OpenClaw 网关对每一个提供方却坚决要求要有一个。设置 type: "none" 会在其进行热重载 (Hot-reload) 时直接丢失。你必须使用带有虚拟验证值的 apiKey 值配合 authHeader: false 进行处理。

    5. 上下文截断

    这是在文章开头我们深聊过的问题。没有错误提示、日志里亦没有任何警告。模型单纯收到被截断过半的残缺对话,并对着那点可怜零碎的片段进行推测作答。把 OLLAMA_NUM_CTX=24576 安排上,并检查是否已奏效(看 Ollama 日志中的模型加载阶段)。

    附赠:OLLAMA_NUM_GPU 并不存在

    你会在大量教程、博客博文及 Stack Overflow 的答案上看到 OLLAMA_NUM_GPU 这个环境变量的存在。它不是真正的 Ollama 环境变量! 设置它做不了任何事。分配 GPU 要且只用 CUDA_VISIBLE_DEVICES。这一设定已在 Ollama 源代码里再三获得了证实。若你一直在排查显卡分配缘由且配置里有这个量,那如今谜团解开了。

    什么时候不应该使用本地模型

    本地模型并非永远是最优选。有很多时候 API 反而更便宜:

    • 复杂多步骤推理: 如果你的代理需牵扯起 5-10 档携着条件逻辑的工具调用穿梭,API 模型干成这事儿既快且整体更实惠。本地模型重试得更多、烧去大量上下文还需更长时间才能聚合成功。同样的一件事一个请求 API 处理一次的事,如果是本地这边可能耗了 3 倍之余的 Token 量。的确推理可以0元购,但浪费的上下文窗口是不讲道理的。
    • 对时间敏感的任务: 如果输出要求首次回答就得是一击必杀,切莫去跟本地模型去对赌。API 模型在把控复杂运转和要求时一次通关率要优秀得多。当你无法承担任何重来或循环试错的余地时,乖乖用 API 方案。
    • 需要“前沿”级别思维的任务: Opus 级别的推理压根未见降落到这等本地部署级别。那些具备庞然体积(70B+ 等)的模型会十分靠拢,却无情地索求高达 40GB+ 以上的巨大 VRAM。若是任务需求极高强度统筹与思考逻辑的参与,直接转交给 API 代工。

    最务实的策略是架构一个路由层 (Routing layer)。 简单和注重流程的工作(比如格式化、提取筛选或是排版处理)统统导给 Ollama 纯免费跑。复杂的逻辑推演及关键核心工作流的全量交接给 API 代劳处理。你能在这个模式基础把不必要的经费砍下来,同时保证最重要的命脉任务高质量。

    核心要点

    • 率先设置 OLLAMA_NUM_CTX=24576 默认的 2048 会静默破坏很多代理任务。
    • 最适配的模型。 qwen3:30b-a3b 是运行 OpenClaw 代理任务验证过最优的模型选择:兼顾 MoE 的高效与 30B 测试输出级别,并有靠谱的工具支援。
    • 杜绝使用 OLLAMA_MULTIUSER_CACHE 面对并发请求时百分百引发 GGML_ASSERT 阻断崩溃。
    • 注意添加你的白名单 (Allowlist)。 由于本地交互会暗度陈仓绕开这道校验,但 crons 任务绝然逃脱不了这项严格检查。
    • 路由分配机制。 把繁杂琐细的工作丢给本地 Ollama 当作打工人,把复杂的逻辑决策留给专业 API。

    常见问题解答 (FAQ)

    • 使用 Ollama 跑 OpenClaw 我们到底准备多大的上下文视窗? 本着底线,它最少需要 16K-24K 的运行容量设定。我们建议将其配置成 OLLAMA_NUM_CTX=24576。Ollama 默认那 2048 枚代币的量只会悄无声息得将你宝贵的代理对话记忆无情截留,而且你抓破头都可能查不到任何显式错误反馈记载。
    • 针对 OpenClaw ,哪个版本哪一家的 Ollama 模型为最优解推演? 首推当打之选 qwen3:30b-a3b。一个体量 30B 雄厚架构但常驻激活只需要调用 3B 总参数的优秀 MoE 模型(满打满算的 VRAM 消耗约在 18.6GB 的标准),而且工具支援表现尤为亮眼出众。
    • 本地运行得掏空多少显存空间? 当装配启动2个平行工作且采用降频 q8_0 级缓存配置的 qwen3:30b-a3b 时粗略评估会锁下 21GB 之多空间。至于诸如后备补充模型小体量如 qwen2.5:14b 也最好乖乖预留个打底的 12GB 显存给足它。
    • 何解我运行搭配的 OpenClaw 老是产出不堪入目的错误指引和胡说八道? 基本百分之百的元凶源起正是那万恶被默认锁死的 上下文窗口 (Context window) 遗害!去翻找配置看眼可怜巴巴还锁着少数值域的 OLLAMA_NUM_CTX 参数吧!
    • OLLAMA_NUM_GPU 这个配置有任何正面效用加成么? 没有。纯无稽之谈而已。这是广在各个教学帖子或是问答板乱讲的一个流传谬谈级变量口号。
    • 为何我测试时一切相安无非顺顺利利只要放养扔定时任务执行就会全盘嗝屁? 受害于“模型白名单”特有的背刺交互体验使然!交互试检有最高赦免路权可以全境无阻跳此门禁。反观那些幕后台操作按时出动的定时执行 cron 则皆卡在这硬性红线里败下阵来

  • 零成本养龙虾:OpenClaw 接人Ollama本地运行大模型

    零成本养龙虾:OpenClaw 接人Ollama本地运行大模型

    在使用 OpenClaw 构建个人自动化助理时,最令人头疼的往往不是系统配置,而是每月面对持续上涨的 OpenAI 或 Claude API 账单。一个活跃的 AI Agent(智能代理)为了维持其思考循环、完成自我纠错并调用各类工具,每日消耗的 Token 数量可能高达数百万。

    除此之外,许多企业用户与技术爱好者对数据隐私有着极高的要求,如果你想让OpenClaw帮忙整理公司的财务报表、阅读私密的个人日记,或是审查尚未公开的商业代码,将这些敏感数据上传至云端API显然会带来极大的安全风险。

    有没有一种方法既能享受 OpenClaw 强大的自动化生态,又能彻底拔掉网线,实现真正的“零成本、绝对隐私”?答案是肯定的:结合本地大模型神器 Ollama。本文将全面解析如何在完全离线的状态下,将 OpenClaw 与 Ollama 无缝结合,从而打造一个仅需电费即可运行的“永动机”式个人助理。

    一、 为什么选择 Ollama 作为 OpenClaw 的本地大脑?

    目前市面上有诸多本地大模型运行框架,如 LM Studio、vLLM、Text-generation-webui 等,但 OpenClaw 官方明确将 Ollama 列为第一优先级的本地部署方案,原因有三:

    • 极简的 API 兼容性: Ollama 默认提供的 11434 端口 API 完全兼容 OpenAI 的请求格式。这意味着 OpenClaw 的底层逻辑无需任何修改,就能像调用 ChatGPT 一样调用本地模型。
    • 跨平台且资源优化极佳: Ollama 都能自动识别你的硬件,优先使用 GPU 或 NPU 进行加速。
    • 模型量化管理方便: 你不需要去 HuggingFace 费力寻找各种 .GGUF 文件。Ollama 的模型库就像 Docker Hub 一样,一行命令即可拉取经过 INT4 极限压缩的优质模型,最大程度节省你的显存。

    二、 离线运行的硬件配置天梯图:你的电脑能跑什么模型?

    在开始之前,我们必须打破一个幻觉:本地大模型虽然不要 API 费用,但它对你的电脑硬件(特别是显存 VRAM 和 内存 RAM)要求极高。如果强行运行超出硬件承受能力的模型,不仅速度慢如蜗牛,还容易导致 OpenClaw 报错 500 断联。

    以下是经过 OpenClaw 社区实测的本地硬件配置与模型选择天梯图:

    硬件配置水平代表机型 / 显卡推荐 Ollama 模型尺寸OpenClaw 代理能力表现
    入门级 (8GB 显存/内存)MacBook M1/M2 8G版, PC (RTX 3050 / 4060 Laptop)1.5B ~ 3B (如 Qwen2.5:1.5b)勉强可用。 只能执行简单的单步命令,处理复杂 AgentSkills(如网页抓取)时容易产生幻觉或胡言乱语。
    甜点级 (16GB 显存/内存)MacBook Pro 16G版, PC (RTX 4070 / 4080)7B ~ 8B (如 Llama-3:8b, Qwen2.5:7b)良好。 能够胜任 80% 的日常自动化任务,可流利使用命令行、文件管理等工具,性价比最高。
    发烧级 (24GB+ 显存/内存)Mac Studio 32G/64G版, PC (RTX 3090 / 4090)14B ~ 32B (如 Qwen2.5:32b, Command-R)极其优秀。 逻辑推理能力逼近 GPT-4,能处理超长上下文代码审计,极少犯错,是重度自动化用户的首选。

    三、 安装 Ollama 并拉取最强 Agent 模型

    步骤 1:安装 Ollama 客户端

    前往 Ollama 官方网站 (ollama.com) 下载对应操作系统的安装包。安装过程一路点击下一步即可。安装完成后,Ollama 会在系统后台默默运行。

    步骤 2:挑选并拉取模型 (核心环节!)

    不是所有的 LLM 都适合做 Agent。有些模型虽然写文章很厉害,但它们“听不懂” OpenClaw 发送的 JSON 格式的工具调用指令(Function Calling)。为了保证 OpenClaw 能够正常使用插件,你必须选择经过工具调用微调的模型

    🏆 2026年 OpenClaw 本地模型推荐榜:

    • Qwen 2.5 (通义千问系列): 目前开源界最强 Agent 模型。不仅中文原生支持极好,且 Function Calling 能力极强。
    • Llama 3.1 系列: Meta 开源标杆,英文逻辑推理无敌,但中文偶尔会夹杂英文。

    打开你的终端(Windows 为 PowerShell,Mac 为 Terminal),执行以下命令拉取模型(以 16GB 内存电脑拉取 Qwen2.5 7B 为例):

    ollama run qwen2.5:7b

    首次运行将下载约4GB的模型文件,请耐心等待。下载完成后,终端会显示>>>聊天提示符,此时可输入“你好”来测试模型是否正常运行;测试完毕后输入/bye退出,但请确保Ollama软件仍在系统托盘保持运行状态。

    四、 手把手:将 OpenClaw 对接至本地 Ollama

    现在本地大脑已经就绪,我们需要让 OpenClaw 的控制面板指向这个大脑,从而摆脱云端 API 依赖。

    1. 在 OpenClaw Web UI 中进行配置

    1. 启动您的 OpenClaw,打开浏览器进入 Web UI 控制面板(通常为 http://localhost:18789)。
    2. 点击左下角的 ⚙️ Settings (设置),进入 LLM Provider (模型提供商) 选项卡。
    3. 在 Provider 下拉菜单中,将默认的 OpenAI 改为 Ollama (Local)

    2. 填写关键参数

    在这个界面中,你需要极其准确地填写以下三个参数:

    • Base URL (基础地址): 填写 https://www.jumei.ai/api 或者 http://localhost:11434/api。这是 Ollama 默认监听的本地端口。
    • Model Name (模型名称): 必须与你刚才在终端拉取的名称完全一致!例如输入 qwen2.5:7b。不要多加空格。
    • Context Window (上下文窗口): 建议设置为 8192。如果你内存很小,可以降低到 4096,但这会影响 AI 记忆长对话的能力。

    3. 保存并测试

    点击界面上的 Test Connection (测试连接) 按钮。如果弹出绿色的“Successfully connected to local model”,恭喜你,你的本地自动化帝国已经成功建立!

    五、 进阶调优:让本地模型发挥 120% 的战斗力

    本地模型由于参数量远小于 GPT-4o,往往需要更加精细的调教才能达到极佳的自动化效果。

    1. 降低 Temperature (温度值)

    Agent 在执行任务(如写代码、执行终端命令)时,需要的是绝对的精准,而不是天马行空的创意。在 OpenClaw 的 Advanced Settings (高级设置) 中,找到 Temperature 选项,将其从默认的 0.7 降低到 0.1 或 0.2。这能有效避免本地模型胡乱捏造不存在的终端命令。

    2. 修改 System Prompt (系统提示词) 增强指令感

    如果你的本地模型(例如 7B 级别的小模型)经常忘记调用工具,只会陪你聊天。你可以在系统设置的 Custom System Prompt 中加入这句强力约束(中文或英文皆可,视模型主力语言而定):

    "你是一个完全自主的系统管理员。当用户提出需求时,你必须优先思考使用你的 AgentSkills 工具(如 shell, browser)来解决问题,而不是仅仅给出建议。请严格输出正确的 JSON 工具调用格式。"

    3. 开启“保持模型常驻内存” (Keep Alive)

    Ollama 默认会在闲置 5 分钟后将模型从显存中卸载,以节省资源。这会导致 OpenClaw 每次接到新任务时,都要重新加载几 GB 的模型,响应极慢。你可以通过修改环境变量,强制模型常驻:

    # 在终端中设置环境变量并重启 Ollama 服务
    export OLLAMA_KEEP_ALIVE=24h

    六、 常见离线运行故障排错 (Troubleshooting)

    故障 1:点击测试连接提示 "Failed to fetch" 或 "Connection Refused"

    原因: Ollama 服务未启动,或者 OpenClaw 运行在 Docker 中,无法直接通过 localhost 访问宿主机的 11434 端口。

    解决办法: 如果 OpenClaw 在 Docker 中,请将 Base URL 中的 localhost 更改为宿主机的局域网 IP(例如 http://192.168.1.100:11434/api)。并在宿主机设置 Ollama 允许跨域及外部访问(设置环境变量 OLLAMA_HOST=0.0.0.0)。

    故障 2:AI 开始疯狂重复同一句话,陷入无限死循环

    原因: 这是典型的小尺寸模型“复读机效应”,或者是因为 Context Window 溢出导致模型忘记了之前的工具执行结果。

    解决办法: 点击界面上的“Stop Agent”强行中止任务。点击右上角的“Clear Memory”清空本轮对话上下文。尝试调高一点点 Temperature(比如加到 0.3),或者更换参数量更大的模型(从 8B 换到 14B)。

    故障 3:模型推理时电脑卡顿、鼠标掉帧

    原因: 你的模型体积过大,Ollama 将一部分模型数据加载到了慢速的硬盘虚拟内存(Swap)中。这也叫“爆显存”。

    解决办法: 放弃当前模型,运行 ollama rm [模型名] 删除它。重新拉取体积更小的量化版本,例如将 qwen2.5:32b 降级为 qwen2.5:7b

    七、 常见问题解答 (FAQ)

    Q1: 断网后,OpenClaw 的网页搜索 (Web Search) 技能还能用吗?

    不行。虽然你的大脑(Ollama 模型)和身体(OpenClaw 核心程序)都在本地,但如果你拔掉了网线,需要联网的 AgentSkills(如网页爬虫、发送邮件、查询天气)都会报错。断网状态下,OpenClaw 只能执行读取本地文件、运行本地脚本、整理本地磁盘等纯本地任务。

    Q2: 我可以同时接入 OpenAI 和本地 Ollama,让它们协同工作吗?

    未来的 OpenClaw 2.0 版本有规划“多模型混合路由”功能(例如简单的任务让本地模型处理,遇到极度复杂的代码交给云端 GPT-4o)。但在当前版本中,你同一时间只能在 Settings 中激活一个主要的 LLM Provider。

    Q3: 为什么我的本地模型用命令行工具时总是出错?

    本地小模型对 Shell 命令的掌握程度不如云端巨无霸。建议在运行涉及 rmsudo, 或批量重命名的破坏性指令时,务必在 OpenClaw 的安全设置中开启 Human-in-the-loop(人工确认),即 AI 每次敲回车前,都会弹窗等待你的批准,防止本地系统被 AI 误删。

    结语:实现真正的 AI 数字主权

    将 OpenClaw 成功对接本地 Ollama,标志着你跨入了 AI 极客的更高阶殿堂。你不再受制于云端 API 的额度限制,也不用担心隐私数据被用于训练其他模型。在这台电脑里,你拥有一个绝对忠诚、免费且永不停歇的数字员工。

💬