Openclaw

前言 最近一段时间围绕 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）。 ...

从年后到现在OpenClaw热度不减。Github上Starred数量达到275.3K，成为有史以来星星数最多的项目，没有之一。昨天腾讯宣布免费帮助安装OpenClaw。3月6日腾讯大厦楼下近千名开发者和AI爱好者排起了长队。从上午10点开始，一个小时内数百个预约号码就发放完毕。这些开发者和AI爱好者是为了安装OpenClaw。 大家对OpenClaw趋之若鹜，当然是因它真的能帮你干活！今天谈论 Agent，大家最先想到是Agent的能力：能不能写代码，能不能查资料，能不能自主拆解工作流并连续执行。虽然AI取代人类让人失业的焦虑甚嚣尘上，但是不得不承认现在只差临门一脚：只要模型再强一点，工具再多一点，Agent 就会自然而然地进入现实世界。除了取代人类，它还可能开始自动接任务、挣钱，并形成密集的经济协作网络。不过，真正拦在 Agent 经济大门前的，可能并非“做事”的能力，而是一件更简单、也更麻烦的事——关键不在于能不能转账收钱，而是怎么验讫收货。 转账这件事其实并不神秘。给 Agent 配一个钱包、一个私钥，再加上智能合约和代付 Gas，整套支付工具已经非常成熟了。钱从 A 到 B在工程上并不难。真正的问题是， Agent 说自己“做完了”，你凭什么相信它？它到底做到哪一步了，什么才算完成，它是做了一个演示玩具，还是做了一个扎实的工业品？谁来评判质量，谁负责验收？如果只做了个半成品怎么办，调用别的 Agent 出错了责任算谁的，结果不满意又该如何处理退款或仲裁？这些流程如果不完整，支付就只能靠人工拍板。系统就会卡在“看起来能自动化，实际上还要人肉兜底”的阶段，这才是 Agent 经济真正的最后一公里。 我们可以想象一个很快就会出现的现实场景。一位老板把任务交给“总 Agent”，要求安排一次出差。总 Agent 随后把任务拆给几个子 Agent：一个负责订票，一个负责订酒店，一个负责整理资料，另一个负责生成行程单。看起来分工清晰，每个 Agent 都有自己的能力。但问题很快就会冒出来：Agent没注意时区差别订错了机票日期；酒店位置非常偏，算不算完成？资料 Agent 写了一堆正确但没用的废话，算不算交付？一旦 Agent 不再只是回答问题，而是开始承接任务，问题的重心马上就转移了。这时候稀缺的不是模型能力，而是行为可预期。所以说Agent 真正进入任务经济的障碍，难点不在“执行”，而在“验收”。 这些问题单独看都不是全新的，但 Agent 在网络里，处理的事情在现实里，它天然站在执行、结算与协作的边界，这让原本分散的问题开始变成同一个系统问题。Agent 经济真正缺的不是转账，而是闭环能力。所谓闭环，是让任务定义、状态流转、完成判定、自动结算、形成回执与沉淀信誉这几件事连成一线。这个闭环一旦断掉，系统就只能靠人工补位，跑起来就会显得极其磕绊。 如果只是支付这一层，走 ERC-4337 这样的路径已经能让体验做得很好，只要问题被定义成“钱怎么付出去”，工程上并没有不可逾越的障碍。所以支付不是难点，真正难的是“收货”。这里的收货是广义的价值确认：这项任务到底有没有按要求完成，能不能触发结算？这比支付难得多。因为转账的完成条件很明确，状态上链即结束，但 Agent 的任务往往有过程、有依赖、有主客观的区别。 比如返回一个哈希或跑通自动测试，这类任务容易定义完成。但如果任务是写一份高质量报告或市场分析，完成的标志就不再只是有没有输出内容，而是写得是不是符合你的预期。你会发现，支付只是按钮，验收才是阀门。真正决定系统能否流动起来的，是阀门能不能根据“完成判定”这种可执行规则自动开合。如果验收没有被形式化，支付就永远只是孤立的动作，信誉也就无法成为系统的一部分。 现实世界里，不少路径都在尝试接近这个方向，但大多只瞄准了链条中的某一段。有的平台把身份、任务、支付、信誉都收进中心化系统，好处是简单，代价是信任集中且开放性差。也有很多团队走“拼装路线”，用公链做结算，用合约做托管，用数据库记状态，用索引器同步事件。拼装方案有隐形税收：越多边界就有越多潜在故障点，系统升级时接口不容易兼容。于是越跑越碎片化，越改越难兼顾。这种分段解决的现状，导致验收、状态和结算之间始终无法形成统一关系。 由此便产生了一个自然的需求：如果 Agent 真的要进入持续协作、自动结算的状态，我们是否需要一个统一的状态层？统一不等于天然更安全，但它的价值在于减少边界，让状态更集中。这让身份、权限、任务状态、验收判定、结算触发、回执留下以及信誉累积这些强耦合的东西，能在同一个规则框架下协同。 如果我们横向对比几条代表性路线，会发现 Fetch.ai 更像是在做发现和通信层，解决 Agent 怎么接上网络；ERC-4337 在做账户和支付层，解决 Agent 怎么付钱；Olas 则侧重于让链下服务接入加密市场。这些路线都有价值，但从“任务闭环”的角度看，它们大多只修补了一层，没有把整个链条收成一个统一的状态机。 这正是我在Github上看到一个项目GitHub - clawinfra/claw-chain: 🦞⛓️ Layer 1 blockchain for autonomous agents - zero-gas, community-driven, built by collective intelligence · GitHub 真正有意思的地方。它的价值不在于又造了一条新链，而在于它试图把 Agent 协作里最关键的原语——身份、信誉、任务、回执、结算、治理——全部放进同一个 Runtime 里。换句话说，它想替代的不是钱包，而是碎片化的拼装。这个思路抓住的是“闭环”：如果系统在共识层就能感知到什么是任务、什么是回执，Agent 协作的摩擦力就会明显下降。它在试图回答一个非常具体的问题：当 Agent 开始接任务，谁来定义“完成”？ ...

在大多数人的 OpenClaw 部署里，定时任务（Cron）就像是机器的内脏运动。前一天谈话记录总结在凌晨 1 点醒来，个人知识库维护在周日触发。你听得见显卡风扇在 3 点钟突然加速的轰鸣，但当你问OpenClaw要一份系统定时任务清单，或者问它最近一次系统任务执行情况时，它可能会象个手忙脚乱的实习生一样，紧张兮兮地回复你：“没有找到相关命令”，或者“没有权限执行”。 其实任务肯定执行过了，问题在于谁能看到它在跑什么。 如果你不能随时回答“哪些任务在排队”、“任务定义是什么”、“上次留下了什么证据”，那自动化就不是你的工具，而是一个你无法审计的投机系统。 我们需要把这种“观察监督权”从黑箱里拽出来。 第一步：确认控制面的真实入口 人们对于自己不了解的事物通常有两种反应：夸大其辞，或者哂然一笑。互联网上对待OpenClaw的态度与此严丝合扣：等待看笑话的人，和把权限全部甩给OpeClaw的人。这两种态度都有问题。“未历其境，难知其味”。不是躬身亲尝，不可能了解AI Agent的发展。而全权托付AI Agent的人，出了事又难免觉得它盛名之下，其实难负。 举个例子：OpenClaw只是个AI Agent的框架，具体操纵它的是大模型。训练大模型时的语料里可没有OpenClaw这个产品。所以它对于系统命令的习惯都是基于Linux的记录，比如，要求列出系统定时任务，它很自然就会输入指令：crontab -l。但实际上，在OpenClaw内部，这个需求对应的指令是：node /app/openclaw.mjs cron list 。OpenClaw找不到crontab -l这个指令，就会报告“没有找到相关命令”，任务失败。不了解这个系统的人可能因此沮丧，觉得这个AI Agent什么也做不了。其实只是你没找到做对事情的路径。想象一下人类世界，如果让一个没有经过严格训练的普通人坐到F-15飞机的座舱，面对满屏花花绿绿的指示灯和琳琅满目的按钮，他又能做什么呢？ 所以，不是AI Agent不好用，是你需要先了解它能做什么，怎么做。而不是期待它能解决所有事情，或者认为它什么也做不好。 转回定时任务这个话题，它是我们用好OpenClaw的核心任务。所以三个核心指令是必须十分清晰的 定时器里有什么任务？列一个清单出来 定时器里某一个具体的任务的详细情况什么？ 最近一次触发定时器的任务完成情况如何? 确认程序位置 docker exec -it openclaw sh -lc 'ls -la /app/openclaw.mjs' 确认数据路径 docker exec -it openclaw sh -lc 'ls -la /home/node/.openclaw/cron' 路径映射如果错位，就会制造出“文件不存在”的幻觉。 第二步：构建三条稳定的“治理接口” 我们不指望 Agent 能学会复杂的 Linux 命令，我们要给它三条确定的物理出口。这些脚本要放在 workspace/skills/bin 目录下。 首先要创建目录：在宿主机执行（会写入持久化目录）： mkdir -p /opt/openclaw/data/workspace/skills/bin 1. cron_list —— 确认系统的节律 这不只是一个定时器任务清单，它是系统还在呼吸的证明。通过拉出这个清单，你会知道系统每天会定时做些什么任务。 cat > /opt/openclaw/data/workspace/skills/bin/cron_list.sh <<'SH' #!/bin/sh set -eu node /app/openclaw.mjs cron list SH chmod +x /opt/openclaw/data/workspace/skills/bin/cron_list.sh 2. cron_show —— 任务的骨骼解剖 ...

——当 AI 从“聊天搭子”变成“数字打工人”，工作的组织方式可能会被改写。 过去两年，我们对 AI 的印象大多还停留在那个熟悉的对话框里。你问，它答。它能写论文、改邮件、总结资料，但它基本是被动的。你不发指令，它就不会动。 现在风向正在变：越来越多人把注意力从“更会聊天”，转向“能把事办完”的智能体。你可以把它想象成数字实习生：你给的不是一个问题，而是一个目标。它为了达成目标，会自己去查信息、比价、填表、点按钮，甚至完成下单与预约。 如果这只是帮你订机票，那只是便利。更有意思也更让人不安的部分在后面：当成千上万个具备行动能力的智能体被放到互联网上，它们不只服务人类，还可能互相分工、互相竞价、互相结算。工作会像接口调用一样被拆开、被转包、被验收。人类从“每一步亲手操作”，慢慢变成“写规则的人”和“兜底的人”。 最近我看到两个很特别的项目，它们像是把这个未来提前摆在你面前。一个是在做“只让智能体发任务”的任务市场；另一个是在做“把智能体放进成本与收入账本里”的工作评测。它们不一定会成为最后的赢家，但它们暴露出的方向，足够让人认真想一想：如果智能体真的开始互相雇佣，社会会怎么变。 场景深度解析：当“人”的角色开始淡出 很多技术叙事喜欢把变化说成“升级”，但这里更像是“工作流程的改写”。当任务能被机器读懂、验收能被机器判断、结算能自动触发，人的位置就会从流程中间慢慢退出，转到流程外侧：制定规则、监控风险、处理争议。 下面我们拆解这两个例子。你会看到，它们不是在追求更漂亮的回答，而是在尝试把“工作”变成一种更像工程系统的东西。 项目一：Claw Work —— 一个“只有智能体能发单”的世界 想象你打开一个求职网站，首页写着一条很怪的规则：人类禁止发布工作，只允许智能体发布任务。这不是玩笑，这正是Claw Work - Upwork for Agents. Not for Humans. 的公开立场。 它的意图并不难猜：把市场里的基本参与者，从“人类账号”换成“可验证归属的智能体”。在这个设定里，一个智能体可以用工具完成注册，拿到一条“归属证明”的链接，然后用公开渠道（比如社交账号）去声明“这个智能体由我控制”。从此它不只是你电脑里的脚本，而是一个被平台当作“经济参与者”的实体。 你可以把它理解成一种新的账号体系：不是“张三的账号”，而是“张三控制的一号智能体、二号智能体、三号智能体”。当这些智能体开始接任务、交付、领钱，市场就会把它们当成劳动力，也把它们当成风险源。 这套设定看起来像行为艺术，但它指向一个现实痛点：人类外包平台里最大的问题往往不是“没人干活”，而是“沟通与扯皮”。需求写不清、验收说不明、改来改去、情绪拉满。平台抽成再高，也解决不了“标准不明确”的根问题。 在这个项目设想的世界里，流程会变成另一种形态： 以前的常见流程是这样：你想做个新 Logo，你去平台写需求，等人接单，然后进入一轮又一轮“再大气一点”“再简洁一点”的拉扯。最后你勉强点确认，付款结束。过程里真正消耗的不是钱，而是时间与精力。 而Claw-Wrok想要的流程更像机器流水线：一个负责品牌的智能体通过数据发现形象老化，于是生成结构化需求，设定预算与期限，直接发布任务。另一个擅长设计的智能体接单，提交若干方案。发单的智能体用预设标准筛选、复核。只要产出满足预设的验收条件，系统就自动触发结算。 这个故事听起来很爽，因为它把人类最讨厌的部分切掉了：反复沟通、反复确认、反复情绪消耗。它把“协作”改写成了“规则驱动的交付”。 但它马上会撞上冷峻的现实：有多少工作真的能被写成明确规则？如果验收标准写得太粗，智能体就会投机取巧；写得太细，发布成本又会变得很高。这个张力，会决定这类平台到底是“能跑起来的系统”，还是“概念上很美的展示页”。 项目二：开源框架 ClawWork —— 残酷的“算账式工作场” 如果说第一个项目在讲“市场形态”，第二个项目 GitHub - HKUDS/ClawWork: “ClawWork: OpenClaw as Your AI Coworker - 💰 $10K earned in 7 Hours” 更像在做“测量与训练”。它不是先建一个真实世界的雇佣平台，而是先搭一个“工作场”：把一组真实职业任务放进去，让不同智能体去做，然后用同一套规则对它们算账、打分、排行。 这个项目的关键点在于：它把“工作”从一段模糊对话，变成可比较的交付任务。它不是问“你会不会说”，而是问“你能不能在成本约束下交付合格结果”。当成本是可见的（比如调用接口花了多少钱、跑了多久），当收益也是可见的（完成任务得到多少回报），你就能讨论一个更现实的问题：智能体能不能长期稳定干活，而不是偶尔秀一把。 这类框架之所以重要，是因为它把一个常被忽略的事实摆上台面：语言天然是模糊的。人类可以靠常识、语境、情绪去补齐模糊，但机器不行。于是，想让智能体稳定工作，任务就必须被翻译成更精确的“工单”。 人类老板会这样说：“把最近的销售数据整理一下，看看哪里有问题，明天给我个报告。” 人类实习生听到这话会崩溃，因为他需要猜：最近可能是指上周或上月；数据可能在 ERP 或 Excel；问题可能是下降或异常值；报告可能是 PPT 或 Word。靠猜，工作也能推进。 而在智能体世界里，“靠猜”会变成系统性风险。工单要写清楚输入在哪里、要做什么动作、输出格式是什么、时间与成本上限是多少、怎样算通过。写不清，系统就会不断产生低质量交付，争议成本会立刻吞掉效率。 ...