Openclaw

我的博客封面上写着一句话：In scripts we trust; the rest is up to God。中文大概可以译成：让代码的归代码，其余的归上帝。 这句话不是装腔作势，而是在提醒自己：确定性的事情交给确定性的系统去做；模糊性的事情，才交给模型去发挥。知识库是我们长期积累资料、调用资料、依赖资料的对象。我们今天往里放东西，最好希望三个月后、半年后、一年后，它依然能稳定地把东西找回来，而不是每次都像抽奖。 LLM Wiki很火，但我劝你三思 最近，Andrej Karpathy 介绍他的 LLM Wiki 方法，在网上很火。这个思路确实很吸引人：原始资料是一层，LLM 生成和维护的 wiki 是一层，最上面再来一层 schema 去约束组织方式、命名规则、吸收新内容的流程，以及回答方式。听上去很高级，也很符合现在很多人对 AI 的期待：资料本身不需要太操心，结构会自己长出来，LLM 会替你把中间层收拾好。 我当然很尊敬Andrej Karpathy，也常常听他的播客访谈。但我看完以后，第一反应是：这件事太像“把大象放进冰箱一共三步”了。开门，把大象放进去，关门。说法当然没有错，问题是你真有一头大象时，就会发现根本不是这么回事。冰箱够不够大，门能不能关上，大象会不会挣扎，放进去以后还能不能长期维持，这些真正麻烦的事，全都被“三步”给抹平了。LLM Wiki 也是一样。最迷人也最危险的，恰恰是中间这层由 LLM 持续生成和维护的 wiki。它听上去像智能，实际上意味着漂移、失控和高成本。 今天你加十篇资料，它可能重写三页。明天你换一个模型，摘要口径可能又变。后天上下文再长一点，概念边界和命名体系也跟着漂。这个流程天然很难做到幂等：同一批资料，你跑一次和跑两次，结果未必一样。做 demo、做概念验证、做一次性的专题整理，这当然很酷；但如果你想把它当成自己的长期知识系统，问题就很大。LLM Wiki当然很酷。但是它把最关键的中间表达，交给了最不稳定的LLM输出。你无法完全信任它，将它当成一套长年积累的知识系统。更何况，如果让一个带上下文记忆而且循环的AI Agent处理中间层，每一次从资料内容到Wiki的转换都需要带着数万的上下文和同样数量级的文章发起请求。你原本就不富裕的coding plan一下子就被吸干了。值得吗？ 我做 clawsqlite-knowledge，走的是另一条路。不是先让 LLM 给我生成一层很漂亮的 wiki，再希望以后慢慢把它固定住；而是先把底层结构钉牢，让知识库本身是可重复、可扩展、可调参的，再让模型在局部环节帮忙。为了做到这一点，这几天我对 clawsqlite-knowledge 和它底层的clawsqlite · PyPI CLI 做了一轮比较大的算法升级。现在两者都已经到了 v1.0.0。这个 v1，在我看来并不是“功能多了一点”，而是底层思路开始真正成型了。 知识库与幂等性 幂等性这个词听上去有点技术，但意思其实很简单：同一个操作，执行一次和执行很多次，结果应当一样。第一次就把该做的事情做完，后面重复执行，不应当无缘无故改变结果。对数据库、索引、搜索系统来说，这个性质很重要；对知识库来说，更重要。因为知识库不是一次性的输出，而是一个要长期依赖的底座。 LLM Wiki 最大的问题，就在这里。你让 LLM 去处理原始资料，生成中间层 wiki，这一次生成的内容和下一次天然会有差异。这不是它“偶尔失手”，而是它的推理方式决定的。它很擅长生成、概括、改写、重组，但并不天然擅长维持严格一致的中间表达。那在这种前提下，我们怎么把它当成一个长期稳定的知识来源？ clawsqlite-knowledge 这次升级，核心其实就是围绕这个问题展开的。我不是想让它“更像一个会说话的 AI”，而是先让它更像一台能重复运行的机器。资料进来以后，先被转换成一组结构化对象：摘要、标签、全文索引、向量索引、兴趣向量、兴趣簇，以及相关的 meta 信息。它们先落库，先固定，后面的搜索、召回、聚类、报告，全部是在复用这套已经落地的结构，而不是每次重新让模型自由发挥。 换句话说，这次不是在给知识库“加更多智能”，而是给它夯实地基。 重构查询入口 这次升级里，最直观的一层改动，是查询入口被彻底重构了。 人类提出问题时，天然是口语的、跳跃的、带噪音的。比如你会说：“我记得之前存过一些跟卫星图、新闻查询、情报收集有关的内容，你帮我找找。”这句话对人类来说很好懂，因为人会自动忽略“我记得”“之前”“帮我找找”这种语气成分，只抓住真正有信息量的部分。对数据库来说就不一样了。数据库不会自动替你做这种收束。它只会拿到一整句原话，然后尽量去匹配。 ...

我们并不缺文章和笔记收藏工具。浏览器收藏夹、微信收藏、稍后读、Notion、Obsidian，这类工具已经足够多了。可笔记存得越多，你反而越容易觉得那只是文本的堆积，并没有真正沉淀成可用的信息，更不要说进一步转化成知识。明明收藏了很多东西，你却说不清自己最近到底在关注什么；你也许还记得某个模糊的主题，但真到要找的时候，又想不起具体标题和关键词，怎么都翻不出来。面对积累已久的笔记，你甚至很难回答一个简单却重要的问题：自己的时间，到底花在了哪里？ 最近我为OpenClaw开发了一个知识库skill，clawsqlite-knowledge。我的本意是想让这个知识库借助向量能力，更好地解决搜索和回忆的问题。可用了一段时间以后，我慢慢发现，除了“怎样搜索得更好”，还有一件更有意思的事：能不能让知识库自己长出一点结构？ 于是，我开始尝试在 1024 维 embedding 空间里做两阶段的兴趣聚类，再基于这些兴趣簇生成周期报告。这样一来，知识库就不再只是一个存放文章的地方，它还会反过来告诉你：你最近到底在看什么，你的关注正在朝哪些方向升温，哪些兴趣点又在慢慢冷却。 clawsqlite-knowledge 是什么 如果没有用过 clawsqlite-knowledge，可以先把它理解成一个围绕 SQLite 搭起来的本地知识库 CLI。推荐你先读一下这篇介绍：把收藏夹从“数字坟墓”变成可搜索知识库：我的 clawsqlite-knowledge 实战。 它主要处理的场景是这样的：你看到一篇微信公众号文章、一条长微博、一串 X 上的推文，或者一个 GitHub 项目，觉得有趣或者有用，就可以把网络链接推给 OpenClaw，让它录入 clawsqlite 数据库。clawsqlite-knowledge 这个 skill 会启动网页抓取脚本抓取全文，清洗成 Markdown。接着，文章标题、摘要、标签、路径等结构化信息会被写入数据库。 在这套流程里，文章前 1200 字加最后一段会被用来生成长摘要，再从长摘要中进一步提取标签。长摘要和标签一方面会被用来建立关键词索引，另一方面也会被向量化，建立向量索引。这样做的结果很实用：Markdown 文件本身可以直接打开阅读；SQLite 则负责把这些分散的文件组织成一套可检索、可统计、可关联的知识仓库。clawsqlite-knowledge 做的，就是把文件系统、数据库、全文索引和向量索引拼成一套完整的本地知识基础设施。 为什么这里要同时建立两套索引，也就是关键词索引和向量索引？因为关键词搜索本质上需要一对一匹配：你得先知道自己要搜什么词，系统才有机会把它找出来。大多数笔记软件的搜索能力，基本也就停在这里。可人的记忆和兴趣，本来就不是按关键词组织的。很多时候，你记得的只是一个模糊印象。比如，“有一篇讲大模型工具链数据流的问题写得很好”。这种记忆并不对应一组准确的关键词，你拿它去做普通搜索，往往徒劳。还有些时候，你想找的并不是某一篇具体文章，而是某个主题相关的一批内容。可这些内容虽然在语义上很接近，标题、标签和摘要里的字面表达却可能完全不同，这时候关键词搜索也很难发挥作用。这就是我给 clawsqlite-knowledge加上关键词和向量混合检索的原因。 向量索引的本质，是把语义相近的文本映射到向量空间里彼此靠近的位置。这样一来，即使它们在字面表达上很不一样，系统仍然有机会把它们联系起来。包括不同语言中含义相近的词，也可能在空间中相互接近。因此，向量检索天然适合同义表达、多语种内容以及模糊主题的混合搜索。实际打分时，向量相似度、全文匹配、标签语义、标签词面、优先级和时效性会一起进入综合评分。这样一来，即使你的表达不够精确，系统也更有可能把真正相关的内容找出来。 做到这一步以后，知识库的“查找能力”已经明显上了一个台阶。但这还不是终点。 我到底在关心什么 当知识库开始稳定以后，你的关注点会慢慢发生变化。一开始，你想做的只是把重要的东西收进来，尽量让它们可搜索、可回看。可当库里的内容越来越多，另一个问题就会浮出来：这些内容之间，是否存在某种比标签更自然的结构？它们能不能自动分成若干个方向？如果可以，这些方向是不是就能反过来帮助我理解自己？比如，我收集了这么多东西，它们大致可以分成哪些兴趣方向？哪些方向是长期稳定的？哪些方向是最近突然冒出来的？哪些方向曾经很热，现在却基本不更新了？ 这些问题，单靠标签很难回答。因为标签本质上还是人工命名，而人工命名往往是随意的。时间一长，标签的颗粒度、口径和边界都会混在一起。无数个夜晚，我都在为笔记到底该按目录存储，还是按内容打标签而反复折腾。可文章一多，标签几乎立刻就开始失效。 后来我开始意识到，既然向量本身就是文章在语义空间里的坐标，那么完全可以直接利用这个空间结构来做聚类。只要语义空间不是完全混乱的，主题相近的文章就应该自然靠近，进而形成一些“簇”。这些簇不一定和人工标签一一对应，但它们更接近内容本身在讲什么，也更接近你真实在关注什么。这其实是一种自动长出来的兴趣结构。你不需要再手工给文章补更多标签，知识库自己就会慢慢显出一些轮廓。 兴趣簇是怎么长出来的 我的目标，是尽量利用向量语义，获得一组相对稳定、又尽可能可解释的兴趣簇。在这套设计里，聚类直接在原始的 1024 维向量空间里完成。整个过程分两阶段。 第一阶段，会先用一个偏大的 $k$ 跑一轮 k-means。这里的 $k$ 不是越精确越好，而是故意设得偏大一些，好把原本可能混成一团的大主题先打散。跑完以后，再检查哪些簇太小。如果某个簇里只有极少数文章，小到不足以说明它是一个可靠主题，就把这些点重新分配到最近的大簇里。 第二阶段，则会基于第一阶段得到的候选簇心继续做合并。具体来说，就是检查这些簇心之间的余弦距离。如果两个兴趣簇的中心非常接近，就可以认为它们在语义上足够近，适合合并成一个更大的兴趣组。 这套两阶段方案，比较符合真实语义结构常见的样子。很多主题之间的关系并不是严格分开的，而是“接近，但又不完全相同”。如果只做一次聚类，你很难同时兼顾细粒度和整体性。先拆后并，通常更容易得到既有辨识度、又有一定隔离度的结果。 参数决定细节 聚类是一种无监督方法，本来就没有唯一正确答案。所以，参数并不是一个无关紧要的细节，它直接决定了你最后看到的到底是一张有层次的兴趣地图，还是另一团更复杂的混合物。这里有几个参数值得单独解释。 min_size 控制的是“一个簇小到什么程度，就不值得单独存在了”。如果一个簇只有极少数文章，它往往不稳定，也很可能只是初始聚类时偶然分出来的碎片，所以需要并回更大的邻近簇。原文默认值是 5。 max_clusters 控制的是第一阶段初始拆分的上限。它决定了你一开始把知识库拆得有多细。值越大，初始碎片越多；值越小，初始结果越粗。默认是 16。 CLAWSQLITE_INTEREST_MERGE_DISTANCE 则是第二阶段里最关键的阈值。它决定了簇心之间要近到什么程度，才允许合并。这个值越小，系统越保守，最后保留下来的兴趣簇越细；值越大，合并越积极，最后的簇就越粗。原文给的内部 fallback 是 0.06。 另外还有一个 CLAWSQLITE_INTEREST_MERGE_ALPHA，它会根据真实簇结构自动推一个建议阈值。这个值不一定直接拿来当最终参数，但可以帮助判断当前知识库在什么尺度下更适合合并。 所以，clawsqlite 的兴趣簇并不是“跑一次算法就完了”。第二轮还会继续观察第一轮结果的簇内平均半径、最大半径、簇心间距离分布，以及二维投影图里这些簇到底是彼此分开，还是又重新糊成一团。参数调得好，你看到的是一张可读的兴趣地图。下图就是我测试用数据库中 150 篇文章，根据向量投影聚类得到的 7 个兴趣簇。 ...

我的案头摆着一枚铭牌：“工具是开发者方法论的固化”。 本篇介绍的clawsqlite-knowledge是一款为OpenClaw环境量身开发的个人知识库skill，也是我在文章收纳与搜索召回领域探索之后的一次方法论固化。 我一直有一种好奇心焦虑：好玩、有趣的东西太多了，于是不停地剪藏网页，保存长文，转存观点，收藏链接。Evernote、Notion、OneNote、Joplin、Obsidian，装了一个又一个，库越攒越大，心里也似乎越来越踏实。可真正需要它们的时候，问题就来了：明明记得自己看过那篇文章，也大概记得它讲了什么，但就是搜不出来。 我想找“爬虫抓取”，那篇文章标题却叫“网页数据采集”；我想找“模型量化”，收藏时用的词却是“模型压缩”；我记得它讲过 RWA，但文章真正写的"资产代币化"。传统搜索靠的是字面匹配，只认词，不认意思。结果就是存的时候很轻松，用的时候大海捞针。久而久之，收藏夹就不再像知识库，而更像一座“数字坟墓”。东西全都在，真正能被重新调出来的却很少。 这正是我做 clawsqlite-knowledge 这个 OpenClaw skill 的原因。我想解决一个实际问题：已经存下来的东西，怎样才能在需要的时候重新被找回来。 为什么你的笔记总是“搜不到”？ 很多笔记软件最大的问题在缺乏有效维护时，无法完成真正有意义的召回。原因很简单：第一，大多数人没有耐心在保存时认真整理。我们以为以后会补标签、补分类、补摘要，但现实往往是：存完就结束了。第二，人类回忆信息时，想起来的常常不是原词，而是一个模糊概念。你脑子里浮现的是“那个讲社交预测市场的文章”，但原文标题可能完全不是这个说法。传统全文检索这时就很吃力，因为它只会问一句：你输入的字，和原文里的字，到底有没有重合。 可见“收纳”和“召回”根本不是同一个问题。前者追求顺手，后者需要理解。那么有没有什么方法可以只管一键收藏。过后只需要模糊地表达意向，总是能找回当初收纳的文章，提供灵感和参考呢？我开发clawsqlite-knowledge 就是尽量让这两件事无缝衔接起来。 Embedding与向量匹配 传传统关键词搜索的逻辑，本质上更像“查字典”。它只能处理“你刚好说对了原词”这类情况。这种基于字面匹配的搜索，无法感知文字背后的语义。比如你搜索“网页抓取”，而文章里写的是“网页采集”；你搜索“量化模型”，而文章里讨论的是“压缩推理成本”；你搜索“社交预测”，而文章真正写的是某个具体的机制。只要字面偏一点，普通搜索就会漏掉。但人类回忆信息，本来就不是按精确标题回忆的。我们记住的常常是主题、场景、印象和关联。一个真正有用的知识库，不能只有全文检索，还需要有更接近语义层面的召回能力。 向量匹配则重构了这种搜索方式。它不再只关注字符本身，而是通过一种被称为“嵌入（Embedding）”的方式，将每一段笔记、每一个词汇投影到一个高维空间里。在我们的 clawsqlite 实现中，这个空间的维度是 1024。你可以把它想象成一座深邃的宇宙，每一条笔记都是一颗悬浮的星球。在这个宇宙中，星球的位置不是由名字决定的，而是由它的含义决定的。当模型处理“量化交易”这个词时，它会分析这个词携带的金融属性、算法属性、自动化属性，并在 1024 个维度上给出一组空间坐标。换句话说，向量匹配不只看字面是否重合，而是试图把“意思相近”的内容放得更近。这样一来，即便查询和原文的措辞不一样，系统也还有机会把你真正需要的那篇文章拉回来。 无论你说的是“番茄”“西红柿”还是 tomato，尽管它们的拼写几乎没有重叠，但因为它们所代表的核心含义高度一致，模型就会把它们放在距离很近的位置上。这就是向量匹配能够实现“模糊搜索”的底层逻辑。它识别的是概念的接近程度，而不是拼写表面的相似程度。哪怕你的查询词写得支离破碎，或者使用了完全不同的语言，只要它们在语义层面足够接近，系统就有机会在海量数据中捕捉到那条关联信号。这种从“字符对比”到“空间定位”的转变，让笔记搜索拥有了更接近人类直觉的联想能力。 BM25的精确制导 不过，如果只用向量检索，另一个问题又会出现：它容易找出一堆“差不多”的文章，却不一定“够准确”地发现你真正想要的那个精确匹配结果。尤其是在技术场景里，很多关键信息并不是一个模糊主题，而是一个具体名词、一个协议名、一个型号、一个缩写。像 STM32F103、nRF24L01、RWA、BM25、LoRA 这种东西，字面本身就很重要。你不能只靠“语义大概相近”来判断它是不是正确结果。 这时，关键词搜索里的 BM25 算法恰好可以弥补这一点。它的一个关键技术叫作 IDF，也就是“逆文档频率”。你可以把 IDF 想象成一种“物以稀为贵”的打分标准。在搜索时，不是每个词的地位都一样。 如果你在知识库里搜索“量化交易的原理”，系统会扫视一眼你的所有笔记。“的”这种词几乎到处都会出现，对系统来说，它就像空气一样普通，几乎不能帮助定位任何具体笔记，所以分数会非常低，甚至被直接忽略。但“量化交易”这种专业词就不一样了。它可能只在你 146 篇笔记中的 5 篇里出现过。正因为它稀缺，所以它的辨识度很强。系统会认为：既然你提到了这么少见的词，那你找的大概率就是那几篇文章之一。因此，这个词的得分会明显更高。 这就是“逆文档频率”的基本逻辑：一个词在库里出现得越频繁，它在搜索时的价值就越低；反过来，一个词越罕见、越独特，它越可能代表文章的核心，得分也就越高。它就像一个自动过滤器，帮你过滤掉那些没什么区分度的虚词，把搜索的聚光灯集中到真正有含金量的关键词上。这样，即便你搜的是一句比较长的话，系统也能很快抓出其中最值钱的部分，帮你定位结果。 在 clawsqlite-knowledge 里，BM25 是向量搜索最好的搭档。向量搜索负责解决“大概是什么”，而 BM25 负责守住“到底写了什么”。前者给你联想能力，后者给你精确锚点。 混合搜索：组合的升华 既然 BM25 见树不见林，而向量搜索恰恰相反，那么最自然的思路，就是把它们组合起来，以同时获得两边的优点。当然，这种组合不是简单的线性拼接。 当我们收录一篇文章以后，会先对全文做一次“取头留尾”。具体来说，就是取文章前 1200 字和最后一段，生成一个“长摘要”。这个长摘要会生成一个 1024 维向量，同时也会建立一个 BM25 的 FTS 索引。接着，这个长摘要还会交给 LLM 模型生成一个关键词列表。 如果没有配置 LLM，则降级为使用 jieba 分词结合 TextRank 来生成关键词列表。jieba 不仅是目前非常稳健的中文分词工具，更重要的是，它还能通过 TextRank 这样的算法，从一堆文字里尽量抓出更有代表性的关键词。你可以把这个过程理解成一种降级但可用的替代方案：它当然不如 LLM 那样灵活，但在没有模型可用的时候，仍然能提供不错的标签抽取效果。这个关键词列表随后也会再生成一个 1024 维向量。 ...

前言 最近一段时间围绕 AI Agent 的讨论越来越热闹。一边是各种“AI 很快就会替代人类”的夸张想象，另一边则是把注意力放在一些并不重要的争论上，故意设计一些绕口的陷阱题，比如“走着去洗车，还是开车去”，来证明模型“并不聪明”。但只要你真的开始把 AI 用进日常工作，就会发现一个更现实的问题：它们在很多最基础的事情上，其实还远远没有做到足够好。 最常见的一件事：你读到一篇不错的微信公众号文章，把链接发给 AI，让它帮你总结、分析，或者和你讨论。听起来这几乎是最自然不过的使用场景了，但实际体验往往并不理想。我尝试了一下最新的Chatgpt 5.4 和 Gemini 3.5，结果如下： 网页之困 很多人以为，只要底层模型足够强，丢给它一个 URL，它就能像人类一样读懂背后的逻辑。但现实是Agent 经常根本拿不到真正有用的正文。有时它收到的是一个冷冰冰的 403 Forbidden。有时虽然抓到了内容，但里面混着导航栏、广告位、脚本碎片，最后变成一堆几乎无法使用的“电子垃圾”。对用户来说，这种体验很糟糕：不是抓不到，就是抓不准，或者抓回来一大堆噪音。 当大家的注意力焦点都在AI做研究员，AI写项目代码，AI生成PPT 这些大事的时候，网页抓取这件事看起来很小，实际上却是 AI Agent 落地过程中一个非常基础、也非常关键的问题。如果一个知识系统连我们真正关心的内容都无法稳定摄取，或者摄取进来的东西质量很差，那么后续无论是总结、检索，还是 RAG，都会建立在不干净的输入之上。输入一旦被污染，后面的结果自然也很难可靠。 因此我开始认真思考：OpenClaw 需要的，究竟是什么样的网页抓取工具？ 为什么我没有直接满足于现有方案 其实现在并不缺网页抓取工具，面向 AI Agent 的方案也已经不少。问题不在于有没有工具，而在于它们是否真的适合日常知识采集，尤其是否适合部署在资源有限的环境里。 以 OpenClaw 自带的 webfetch 为例，它本质上更接近 curl 加规则提取。在一些结构简单、静态内容为主的页面上，它可以工作；但一旦遇到微信公众号、现代博客，或者强依赖 JavaScript 渲染的站点，就很容易失效。 另一类工具则走向了另一个极端：它们确实具备更强的抓取能力，但代价是要启动一个完整浏览器，甚至带图形界面。这样的方案在本地高配机器上未必不能接受，但如果你的 OpenClaw 部署在一台只有 2 核 CPU、4GB 内存的 VPS 上，这种做法往往太重了。冷启动慢，常驻占资源，还可能因为依赖不齐、浏览器环境异常、内存不足等问题，让整条任务链中断。换句话说，问题不是“抓不到网页”，而是现有方案常常只能在“能力不够”与“资源过重”之间二选一。 而我真正想要的，是一个更适合 Agent 使用习惯的工具：它要足够轻，足够稳，而且要知道面对不同站点时，该走哪条更合理的路径。这就是 clawfetch 的出发点。 工殊途不同归 clawfetch 并不是完全排斥浏览器方案。它会使用无头浏览器+轻量级的Playwright-core操控方式来处理需要渲染的页面。但它的关键不在于‘用了浏览器’，而在于它不会默认对所有网页都走最重的路径，而是先判断有没有更轻、更直接的入口。换句话说，clawfetch 不是一上来就强行模拟人类打开网页、执行脚本、等待渲染，而是先判断：这个站点有没有更适合机器读取的原生接口？有没有更直接的文本入口？有没有一种路径，能绕开登录墙、广告层和复杂前端，直接拿到高质量正文？如果有，就优先走那条路。 这个思路听起来朴素，但在实际使用中非常重要。因为对 Agent 来说，目标不是“像人一样浏览”，而是“尽快拿到可靠文本”。在开发 clawfetch 的过程中，我给一些高频站点做了针对性的提取路径。 比如 Reddit。与其让工具在复杂页面结构里挣扎，不如直接利用它现成的 RSS 入口。只要在原始链接后面追加 .rss，Reddit 就会返回结构更清晰的 XML 内容。这样一来，既可以绕开那些不必要的页面元素，也更容易稳定拿到主帖正文。在这个基础上，clawfetch 还可以通过 --max-comments 这样的参数，把评论区中真正有价值的内容一起提取出来。对很多技术讨论、经验贴、故障排查串来说，评论往往比正文更有信息量。把这部分一起打捞上来，才更符合真实使用场景。 ...

我们每天都在产生大量和自己有关的数据。步数、心率、睡眠、HRV、压力、训练状态，这些数据几乎时时刻刻都在被手表、手机和各种设备记录下来。问题是，大多数时候，它们只停留在厂商的 App 里。你可以看图表，可以翻历史记录，但很难真正把它们接入自己的知识系统、日程系统，或者个人 AI 助手。这是我一直觉得可惜的地方。 我一直很喜欢Mathematica 以及 Wolfram|Alpha 的发明者 Stephen Wolfram 那种用数据理解人生的方式。很多年前，他就展示过如何通过长期积累的数据来观察自己的生活模式：Stephen Wolfram：以数据诠释人生。那种感觉很震撼：原来一个人的作息、节奏、投入和变化，真的可以在数据中留下轨迹。可惜的是，今天大多数人的健康数据虽然更多了，却依然被困在封闭的系统里，难以成为真正可用的个人上下文。 于是我做了一个开源项目：Clawhealth。它的目标不是单纯把 Garmin 运动手表数据“读出来”，而是把这些原本散落的个人健康信号，真正接入 OpenClaw 生态，让它们可以被本地 Agent 理解、调用、分析，并进一步参与到日常决策之中。比如，Agent 不再只是回答你“今天睡得怎么样”，而是可以根据连续的睡眠、HRV 和训练状态，判断你今天更适合高强度工作、轻量安排，还是应该主动多休息一点。 Clawhealth 到底做了什么 Clawhealth 是一个以 OpenClaw 为第一目标的个人健康数据工具。目前它已经接入 Garmin 生态，可以同步你的 Garmin 手表数据，并把这些数据保存到本地 SQLite 数据库中，供 OpenClaw 以结构化方式调用。它的能力包括：Garmin 账号登录、MFA 验证、每日健康汇总同步、睡眠分期、HRV、训练指标、活动详情，以及适合 Agent 使用的 JSON 输出。 这件事看起来像是“把手表数据存一下”，但我真正关心的并不是存储本身，而是它背后的意义。过去，健康数据更多只是“展示型数据”。你看见它，知道自己昨天睡了几个小时、走了多少步、压力值怎么样，然后就结束了。它很少真正进入你的长期系统，也很少能和你的工作节奏、学习计划、恢复状态形成联动。而一旦这些数据被同步到本地、变成稳定可访问的结构化数据，意义就不一样了。它可以成为个人 AI 的长期上下文。它可以和你的待办事项、日程安排、工作日志、笔记系统结合起来。它甚至可以参与一个更完整的反馈回路：身体状态影响建议，建议影响安排，安排又反过来影响第二天的状态。 我想做的，不是“再看一个图表”，而是让健康数据真正有用。 为什么我坚持本地运行 我觉得这个项目最坚持的一点，其实不是 Garmin，也不是 OpenClaw，而是：健康数据不应该被轻易交给额外的第三方服务。 身体数据和普通应用数据不一样。它们非常私人，而且往往带有长期连续性。心率、睡眠、HRV、压力、训练状态，这些东西一旦被系统化地积累下来，几乎就是一个人的生理画像。 所以 Clawhealth 的设计重点之一，就是尽量把事情放在本地做。这个技能完全运行在用户自己的本地 OpenClaw 环境中。Garmin 的账号凭据和会话数据不会离开设备，也不会发送给技能作者或额外的第三方服务。同步后的数据落到本地 SQLite 中，后续 Agent 读取的是本地结构化结果，而不是去外部系统来回取数。 这意味着，你得到的不只是“能同步”，而是一种更安心的工作方式：你的数据在本地。你的凭据在本地。你的后续分析能力，也在本地。这一点对所有人来说都非常重要。 为什么要接到 OpenClaw Garmin App 本身当然已经很好了。它能展示很多统计结果，也能给出一些基础判断。但它的问题也很明显：它是一个封闭系统。它知道你的身体状态，却并不知道你今天的工作安排、学习计划、项目压力、写作节奏、会议密度。它很难真正理解“你这个人”。 而 OpenClaw 的价值恰恰在于，它不是一个单独的健康 App，而是一个带记忆、可扩展、可接入多种上下文的个人 AI 助手环境。把 Garmin 数据接进去，意义就在于：健康数据终于不再是孤岛。从这个角度看，Clawhealth 不是一个“运动手表工具”，而更像是个人健康数据进入 AI 工作流的一道入口。 ...

前言 很多人在体验 OpenClaw 几天之后，直呼Agent好用，但是token太贵。如果你打开输入命令行开关/usage full，每次输出末尾附带的数万 token 消耗记录，常常会让人倒吸一口冷气。有人说，招呼一句 “Hello” 就消耗了几美元的 token，虽然有些夸张，但也不算完全离谱。 这种花钱如流水的现象，背后有两层原因。第一层原因确实来自 Agent 系统本身。像 OpenClaw 这样的系统，在每一轮对话中都要注入大量上下文，例如用户习惯、系统约束、工具列表等。这是 Agent 与普通聊天模型最大的区别之一。这种上下文注入并不是缺点，而是 Agent 能持续工作的必要条件。第二层原因往往才是真正的 token 消耗大户：**当前主流的 Agent 执行模式——Function Calling。**在这种模式下，Agent 常常在错误中不断尝试调用工具，形成一种类似“鬼打墙”的循环，每一次尝试都在燃烧新的 token。 被困在“盒子”里的 AI Agent 在传统软件工程中，为了可维护和可追溯，系统接口通常必须是强类型、可验证的。无论是 REST API 还是 GraphQL，本质逻辑都很类似： 你必须提供一个精确的结构化输入，否则请求将被拒绝。 这种思维方式已经在软件工程中存在了几十年。2022 年底 ChatGPT 出现之后，早期开发者很快遇到一个问题：LLM 的输出是概率性的文本，而传统程序接口要求严格结构化数据。 于是最早的工程实践通常是这样的： 在 System Prompt 中要求模型： 请务必只输出 JSON，格式如下…… 但 LLM 并不总是严格遵守格式，它可能输出： 好的，这是你要的 JSON： { ... } 或者把 JSON 包在 Markdown 代码块中。结果是后端解析程序经常崩溃。 为了解决这个问题，OpenAI 在 2023 年推出了 Function Calling。模型在判断需要调用工具时，会输出一个特殊的 tool call token，并生成符合 schema 的 JSON 参数。 ...

前言 前几天发布了我在OpenClaw官方Docker镜像基础上的增强补丁版：OpenClaw Docker 补丁镜像 2.0：给你的 AI Agent 装上六种“新感官” 。有朋友问能不能把一些编辑音乐文件的标签的工具加上去。包括改 flac wav dsd 文件的标签让音乐软件识别，比如 tagutil 、tageditor 、metadsf，另外还有 Python 的库 mutagen。百人千味，每个人需求不一样，确实很难用一个补丁包满足所有人的想法。但一个很实际的问题是，如果所有人都根据自己需求，想让我往补丁包里塞各种工具，原来已经稳定的镜像结构会继续变重，后面只要再加第二类、第三类工具，很快就会变成一个越来越难维护的大文件。尤其是像我的补丁镜像，本身已经有一套比较完整的运行环境了，很多时候我们只是想额外加一小块能力，并不想去动它原来的主结构。 我的建议是：可以尝试在我已经编译好的基础镜像 ernestyu/openclaw-patched 之上，再写一个新 Dockerfile，只把这次需要的功能叠上去。这样做的好处是，原来的补丁镜像继续保持原样，每个人的新需求单独放在一层里。边界很清楚。要删，要改，要换方向，都不会影响已经验证过的基础版本。 给镜像补丁打补丁 以这个音乐爱好者朋友的需求为例，他要加进去的东西，一共分三类。第一类是系统包安装的命令行工具，比如 flac 和 kid3-cli。第二类是需要单独编译的 metadsf，它主要用来处理 DSF 文件的标签。第三类是 Python 侧的 mutagen，它适合做脚本化处理，也和我现有镜像里 /opt/venv 这套 Python 环境保持一致。 这里有一个细节，我的补丁镜像是让系统级命令进入系统路径，Python 包还是放进原来就存在的 /opt/venv，而不是乱装到别的地方。新镜像也建议这样做，编译以后，上手方式和原镜像几乎一样。用户进入容器，就可以直接用这些命令，不用再记一堆奇怪路径。 下面就是这次使用的完整 Dockerfile。 FROM ernestyu/openclaw-patched:latest AS metadsf_builder USER root SHELL ["/bin/bash", "-lc"] RUN set -eux; \ apt-get update; \ DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \ ca-certificates \ git \ build-essential \ pkg-config \ libtag1-dev \ automake \ autoconf \ libtool \ m4 \ perl; \ update-ca-certificates; \ ln -sf "$(command -v aclocal)" /usr/local/bin/aclocal-1.14; \ ln -sf "$(command -v automake)" /usr/local/bin/automake-1.14; \ rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/* RUN set -eux; \ git clone --depth 1 https://github.com/pekingduck/metadsf.git /tmp/metadsf; \ cd /tmp/metadsf; \ ./configure --prefix=/usr/local; \ make -j"$(nproc)"; \ make install; \ mkdir -p /out/usr/local/bin; \ cp -av /usr/local/bin/metadsf /out/usr/local/bin/; \ rm -rf /tmp/metadsf FROM ernestyu/openclaw-patched:latest USER root SHELL ["/bin/bash", "-lc"] ENV VENV_PATH=/opt/venv ENV PATH="${VENV_PATH}/bin:${PATH}" RUN set -eux; \ apt-get update; \ DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \ ca-certificates \ flac \ kid3-cli; \ update-ca-certificates; \ apt-get clean; \ rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/* COPY --from=metadsf_builder /out/usr/local/bin/metadsf /usr/local/bin/metadsf RUN set -eux; \ chmod a+rx /usr/local/bin/metadsf; \ command -v metaflac; \ command -v kid3-cli; \ command -v metadsf RUN set -eux; \ test -x "${VENV_PATH}/bin/pip"; \ "${VENV_PATH}/bin/pip" install --no-cache-dir mutagen; \ "${VENV_PATH}/bin/python" - <<'PY' import mutagen from mutagen.flac import FLAC from mutagen.wave import WAVE from mutagen.dsf import DSF print("mutagen ok") print("FLAC ok:", FLAC is not None) print("WAVE ok:", WAVE is not None) print("DSF ok:", DSF is not None) PY USER node 这个文件虽然简单，里面有几个点很关键。第一个是两阶段构建。metadsf 不是一个直接 apt install 就能拿到的现成工具，所以需要编译。既然要编译，就会用到 git、build-essential、pkg-config、libtag1-dev 这一类东西。它们只在构建阶段有用，不应该留在最终镜像里。分阶段以后，最终镜像里只留下编好的结果，不留下那一整套编译环境，体积和干净程度都会好很多。 ...

前言 最近发布的OpenClaw Docker 补丁镜像 2.0：给你的 AI Agent 装上六种“新感官” ，一些使用者很好奇其中增强工具细节。所以专门再写一篇文章详细解释。有动手能力的人根据工具列表可以写出自己的Dockerfile。普通使用者可以进一步了解这个增强版的具体功能。 如果把 OpenClaw 看成一个会思考、会规划、也会调用工具的 AI Agent 平台，那么官方镜像更像是一个比较干净的基础版本。它把核心部分准备好了，但并没有把所有常见的外围能力都一起带上。我做的这个补丁镜像，本质上是在这个基础上再补一层，让它更接近一个真正能直接投入工作流的运行环境。 给官方镜像打补丁，怕的不是工具少，而是思路混乱。如果一股脑往里塞很多工具包，最后什么都有一点，但是缺乏重点。这样做出来的镜像看上去很全，却很难解释清楚：到底增强了什么，为什么要增强，以及这些增强之间有没有一条统一的界线。我的思路并不是“把能想到的工具都装进去”，而是围绕一个基础问题来做判断：一个真正长期使用的 OpenClaw 环境，到底最常缺什么？ 我给出的答案不是某个单独的软件，而是几类特别常见的工作能力。它们单独看都不惊人，但组合在一起，就会决定 OpenClaw 是停留在“能聊天、能跑任务”的阶段，还是能进一步进入“真能帮你处理文件、管理资料、连接外部资源、做自动化小工作流”的阶段。 连接外部世界：网络访问与数据获取能力 最基础的一层就是和外部世界打交道的能力。很多人提及AI Agent直接就拿推理、提示词、任务分解这些能力去衡量。但是一旦开始使用，你会发现一个 Agent 的价值并不只在于它想得多好，还在于它能不能连接真实世界，能不能把外部信息带回来，能不能和别的服务说上话。现实里的任务很少是完全封闭的。你会需要请求一个 API，拉取某个接口的数据，下载一个文件，看一眼某个网页的返回内容，或者只是简单检查某个远程地址是不是还活着。没有这些能力，Agent 再会规划，也只能在自己的上下文里绕圈。 所以补丁镜像里补进去的第一层能力，就是更完整的网络访问和外部资源获取能力。它让容器里的 OpenClaw 不只是“会说”，而且更容易“去拿”。当一个任务需要访问接口、下载文件、处理 JSON 响应或者和外部系统交换数据时，环境本身已经具备了比较顺手的工具链，而不是临时再装点东西。这件事看起来很普通，但它对实际体验的影响很大。当外部访问能力不完整时，OpenClaw 就会很容易退化成一个“分析器”，只能告诉你下一步该做什么，但不能真的把那些步骤接起来。补上这一层工具后，它就更像一个真正能接触外部世界的执行节点。 处理真实资料：文档与表格处理能力 接下来是文档处理能力。这一层可能比网络工具更常用，因为很多人的实际资料根本不在 API 里，而是在文件里。知识库也好，工作文档也好，论文也好，表格也好，日常收到的东西很少会整整齐齐地躺在一个数据库里等你调用。它们更常见的状态，是散落在 PDF、Markdown、HTML、Word、Excel 这些格式里。对人来说，这些格式只是“打开方式不同”；但对一个 Agent 环境来说，这意味着完全不同的处理链路。 如果环境里只有最基础的文本能力，那么 OpenClaw 确实可以读纯文本，但只要文件格式稍微复杂一点，处理起来未必就那么丝滑了。PDF 不是普通文本，Excel 也不是。你想让它整理内容、提取数据、做后续分析，前面总得先有一个“把东西拆开、转成可处理形式”的过程。所以补丁镜像里，我把文档和表格相关的常用处理能力也补上了。这样做的意义，不只是“多支持几个格式”，而是把 OpenClaw 从一个主要面对字符串的系统，往前推成一个更能面对实际文件资料的系统。 举个很直接的例子。如果你平时会整理知识库，那么你很可能会遇到这样的链路：别人给你一份 PDF，你先提取文本，再把里面的结构整理成 Markdown，之后也许还要把某些表格内容单独转出来做后续处理。又或者你手头有一些 Excel 数据，想做轻量分析或导入别的系统，那第一步几乎总是先把它转成 CSV。对人来说，这些只是日常小动作；对一个没有配套工具的容器来说，这些事情每一步都可能变成障碍。 把这一层补齐之后，OpenClaw 的角色就会发生变化。它不再只是“读取你贴进去的内容”，而是更有机会直接参与到文档清洗、资料转换、结构整理这些前置工作里。这样一来，它对知识管理、内容整理和资料再加工的帮助就会更实在。 面对多模态文件：媒体与图像处理能力 再往下，就是媒体处理能力。很多人一开始觉得媒体处理好像不是 OpenClaw 这种 Agent 平台最核心的东西。但只要你真的开始把它用到更广一点的场景里，你会发现，音频、视频和图片处理可能比想象中更频繁。你想做语音相关的处理，先得拿到音频。你想从视频里提取一段内容，先得能拆解视频。你想整理一些截图或者图片材料，往往也需要做基础的转换、缩放或者预处理。再进一步，有些任务甚至不是“分析媒体内容”本身，而是把媒体当作中间材料：比如把视频抽音轨，再转文字；比如把图片预处理后送进别的流程；比如先下载素材，再做归档和整理。如果这些能力都不在镜像里，那么每次涉及媒体，你都得把工作拆到容器外面去做。结果就是 Agent 只负责中间一小段，而完整流程还是要靠人工搬运。 所以我把常见的音视频和图像处理能力也一并补进来了。它的意义不是把 OpenClaw 变成一个专门做媒体生产的软件，而是让它在面对多模态材料时，不至于在最基础的步骤上就断掉。你可以把这一层理解成“让它不怕文件类型变复杂”。这样无论是下载、转换、抽取还是简单预处理，都可以更自然地接进同一条工作链里。 在本地资料库里行动：文件检索能力 除了面对外部资源和文件格式，另一个特别现实的问题，是本地检索。很多真正长期使用 OpenClaw 的人，往往不会只让它看一次性输入，而是会慢慢把它和自己的资料体系绑在一起。这个资料体系可能是笔记目录，可能是代码仓库，可能是论文文件夹，也可能是一整个长期积累下来的知识库。到这个阶段，问题就不再是“模型懂不懂这段文字”，而是“它能不能在我的本地东西里快速找到我需要的那一部分”。这时候文件系统本身就变成了工作对象。 ...

前言： OpenClaw 最近很火，但很多人部署它时只关注一件事：能不能跑起来。 对于一个可以自动调用工具的 AI Agent 来说，真正重要的其实是 权限边界和系统能力。 这篇文章介绍我做的 OpenClaw Docker 补丁镜像 2.0 —— 让 Agent 在安全容器中，一启动就拥有完整工具链。 OpenClaw 越火，风险越大 最近，一个名为 OpenClaw Exposure Watchboard 的安全观察页面持续扫描互联网，已经统计到接近 28 万个公开可达的活跃 OpenClaw 实例。这个数字一方面说明 OpenClaw 确实很火，部署量正在快速上升；但另一方面也说明，很多人只关注“能不能在我的电脑上跑龙虾”，却没有认真处理认证、访问控制和公网暴露面这些更基础的问题。对一个具备工具调用和自动执行能力的 Agent 来说，能跑起来只是第一步，更重要的问题是：这个 Agent 能接触什么文件、能执行哪些命令、能访问哪些网络资源。如果这些边界没有控制好，那么一个看似方便的自动化助手，很可能反而变成系统的安全隐患。因此，在我自己的部署实践中，我一直更倾向于优先使用 Docker 来运行 OpenClaw，而不是直接在主机系统里进行原生安装。 优先用 Docker 部署 Docker 并不天然等于安全，但它提供了一种非常重要的能力：可以明确划定运行边界。这对一个能够自动调用工具的 Agent 来说尤其关键。在实际使用中，我选择 Docker 部署 OpenClaw，主要有三个原因。 第一，权限边界更清楚。 当 OpenClaw 运行在容器中时，它能访问的文件、目录和系统工具都可以被严格限定。换句话说，你可以先划定一个安全范围，然后再逐步增加它的能力，而不是让它直接运行在整个主机环境里。 第二，资源利用率更高。 对很多家庭服务器、NAS、小型 Linux 主机，甚至 Mac mini 来说，让 OpenClaw 独占一台机器并不现实。容器化之后，可以在同一台机器上运行多个实例，不同用途的 Agent 之间也可以互相隔离。 第三，上下文更容易隔离。 在实际使用中，一个 OpenClaw 实例如果长期同时承担多种任务，很容易出现提示词风格、工具调用习惯以及工作目录互相干扰的问题。相比之下，我更倾向于在同一台机器上部署多个 Docker 化的 OpenClaw，让每个实例专注一种任务类型。 Docker 方案现实问题 Docker 带来了清晰的边界，但同时也带来了另一个现实问题：官方镜像通常会非常“干净”。这种设计对于维护者来说是合理的。镜像越精简，维护成本越低，也更容易保证稳定性。但对普通用户来说，这意味着 OpenClaw 虽然可以顺利启动，却未必具备足够的工具能力。 ...

如果你将OpenClaw视为日常聊天伙伴，那你一定遇到过这样的场景：花了一个小时跟它交代事情背景、定好规矩，聊得正起劲，它突然回了一句：“对不起，我不记得你刚才说的规则了。” 这时候人很容易抓狂：我不是刚刚才说过吗？为什么 AI 的记忆力这么短？ 其实，不是OpenClaw没有记忆。问题出在它的“大脑空间”——也就是所谓的上下文窗口（Context Window）——本来是有限的。对话一长，它不可能把前面所有内容不分轻重地一直塞进上下文里，那样 Token 开销会很快失控。为了继续聊下去，它就必须想办法把旧内容压缩、整理，或者替换掉。所以它不能记得每一处细节。 OpenClaw在 3 月 7 日做了一次非常重要的系统更新，尝试把这件事做成一套可以被开发者接手改写的开放插件机制。 OpenClaw的记忆系统 如果用通俗一点的话来说，OpenClaw 现在可以大致看成两层。一层是 memory search，负责跨会话、跨文档、跨项目去做内容检索。另一层是 context engine，负责当前这场对话里，哪些内容要放进模型眼前，哪些内容要被压缩，哪些内容要暂时放到后面。 你和 OpenClaw 当前正在进行的这一轮对话，会属于一个 session，分配了一个session ID。只要这个 session 还在，它就能依靠当前会话上下文继续“接着聊”。当你使用 /new、/reset，或者你自己配置过其他 reset trigger 之后，它就会进入一个新的会话。你们之前的问答内容会随 session 一起持久化保存；理论上由Memory Search负责搜索。至于后续能否被 memory 检索到，还要看 memory 配置是否启用了相应路径。 简单来说，当前对话不断不掉线，主要靠的是 context engine。换了会话以后，还能不能从旧内容里翻出东西，更多靠的是 memory search。这篇文章想重点讲的，不是长期知识库memory search，而是当前对话为什么会“断片”，以及这次更新为什么重要。 顺便说一句，中文用户对 memory search 这块往往会更敏感。因为在公开讨论里，和中日韩语言相关的分词、检索效果，直到现在也仍然能看到一些争议和问题。所以，对中文用户来说，当前会话的上下文管理，很多时候反而更值得关心。 Context Engine“拆东墙补西墙” 在这次更新之前，OpenClaw 处理长对话的方式，核心方式比较传统：当你们进行多轮对话，上下文快满了，它会对较早的对话做压缩。这里要注意，它并不是简单地把旧内容直接扔掉，而是会把更早的内容压缩成一段摘要，再把较新的对话保留下来。也就是说，旧机制并非完全“失忆”，而是把原始细节换成了总结版。 问题在于，这种方式虽然比硬删除好，但仍然很容易带来两个麻烦。第一个麻烦，是你最早设下的规则、反复强调的偏好、对任务的关键约束，可能在多轮压缩之后只剩下一层模糊总结。AI 未必真的“忘了”，但它看到的已经不是原话，而是一个被处理过的版本。细节一旦被压平，执行质量就容易下降。上周 Meta 超级智能实验室的安全总监Summer Yue 也公开提到，自己部署的 OpenClaw 在处理邮箱时，因为上下文压缩后丢失了‘先确认再执行’这类约束，开始未经授权地大量删除或归档邮件。这件事也让更多人意识到：上下文管理不是小问题，而是 AI Agent 的安全问题。 第二个麻烦是子智能体。如果主智能体要把某个任务派给子智能体，它得先决定：到底该把哪些背景信息一并交过去？以前这个过程缺少足够灵活的控制，很容易出现两种情况：要么塞太多，子智能体被无关信息淹没；要么塞太少，关键约束没有传过去。结果就是，复杂任务越长，越容易出现上下文错位。 所以，以前真正的问题不是“OpenClaw 完全没有记忆”，而是它的记忆管理方式太像一个固定流程，开发者很难插手改造。 第二部分：给 AI 装上“生命周期钩子” 为了解决这个问题，OpenClaw 在最近的 v2026.3.7 版本中，引入了 ContextEngine Slot，并给出了 7 个生命周期钩子（Lifecycle Hooks）。 ...