继昨天 Claude Code 源码泄露之后，全网已经狂欢了一整天。 除了学习它的 agent 架构、prompt 组织方式，对很多又爱又恨 Claude Code 的中国用户来说，还可以研究下怎么"道高一尺、魔高一丈！" 我们来对比泄露的代码和 @anthropic-ai/claude-code 当前 npm 包里的 cli.js，研究下 Claude Code 是如何精准定位用户的！ 一、Claude Code 到底在送什么 1. system prompt 里就带着环境信息 很多人会本能地觉得，“追踪"无非就是打点埋点，把那一路关了就行。 ...
最近将 Token 翻译成词元之后，又有个词突然变热且暂时没有合适的翻译：Harness Engineering。 不是新模型，不是新框架，甚至不是新工具——就是这么一个词，突然开始出现在各种技术讨论里。 它从哪来的？它在说什么？为什么现在火起来？ 我们来拆解三篇相关的重要文章，最后讲讲实践中如何落地。 先说这个词本身 Harness，字面意思是"缰绳"或"挽具"。 放进 AI 工程的语境：Harness 是把 agent 纳入工程系统的那套控制结构——让 agent 的工作变得可约束、可验证、可回放，而不是每次运气好就成功、运气不好就不知道哪里出了问题。 它不是某一个工具，也不是某一个 prompt 技巧。它是一套工程思路：当代码主要由 agent 生成，工程师的工作重心从"写代码"转向"设计让 agent 能够有效工作的环境"。 听起来很虚？下面看具体的。 第一篇：OpenAI，2 月 11 日 这个词真正开始传播，是因为 OpenAI 在 2 月 11 日发了一篇工程博客，标题叫《Harness Engineering: Leveraging Codex in an Agent-First World》。 文章里有一组数字，很多人看完沉默了： 5 个月。3 名工程师。约 100 万行代码。约 1,500 个 PR，平均每人每天 3.5 个。 更关键的是：从第一个 commit 开始，仓库里没有一行代码是人手写的。 连最初的 AGENTS.md——用来告诉 agent 怎么在这个项目里工作的文件——都是 agent 自己写的。 但这不是 vibe coding。 OpenAI 团队在文章里说了一句很关键的话： 早期进展比预期慢——不是因为 Codex 没有能力，而是因为环境没有定义好。 ...
今天微信发布了官方龙虾插件 微信ClawBot，支持 OpenClaw 接入个人微信。 第一时间尝试之后，深入源代码，分析其协议实现。废话不多说，直接开始。 一张图先看全局 整套协议的结构其实非常规整：控制面走 Bot 网关，��据面走 CDN，插件本地负责把两者接起来。 控制面接口主要有 5 个： getupdates sendmessage getuploadurl getconfig sendtyping 数据面则只有一件事：媒体文件通过 CDN 上传/下载，本地做 AES-128-ECB 加解密。 这就是理解整套协议的入口。 1. 登录链路：二维码授权 -> bot_token 先看登录。 插件登录阶段只依赖两个接口： GET /ilink/bot/get_bot_qrcode?bot_type=3 GET /ilink/bot/get_qrcode_status?qrcode=... 第一步拿二维码，第二步轮询二维码状态。它的状态机大致如下： 确认授权后，服务端会返回： { "status": "confirmed", "bot_token": "<bot_token>", "ilink_bot_id": "xxxxxxxx@im.bot", "ilink_user_id": "xxxxxxxx@im.wechat", "baseurl": "https://ilinkai.weixin.qq.com" } 这里真正关键的是 4 个字段： bot_token：后续所有业务请求的 Bearer 凭证 ilink_bot_id：Bot 身份 ilink_user_id：绑定的微信用户 baseurl：服务端下发的 API 基址 插件会把这些值保存到本地账号文件，后续 gateway 启动时直接复用。 一句话概括登录阶段：二维码只是授权入口，真正建立会话能力的是 bot_token。 2. 统一请求头：协议外壳非常稳定 除了扫码登录用 GET 之外，后续业务接口基本都是 JSON POST。统一请求头如下： Content-Type: application/json AuthorizationType: ilink_bot_token Authorization: Bearer <bot_token> X-WECHAT-UIN: <base64(random uint32 decimal string)> SKRouteTag: <optional> 这里可以顺手记住 3 个实现细节。 ...
很多人辛辛苦苦养的小龙虾，都会在某个时刻让主人产生一种挫败感： 昨天刚说过的偏好，今天新开一个会话又得重讲； 明明说了"记住这个"，过几天再问，它像没听过； 会话越长，助手越像"注意力涣散"，前面已经确认过的事，后面又绕回来。 这类问题看起来像"小龙虾变笨了"，怀疑给虾使用的大模型不够智能？其实大多数时候都不是模型能力问题，而是记忆机制没有被正确使用。 （本文所说的小龙虾，通过 OpenClaw 部署。研究对象也是 OpenClaw。接下来将统一口径，使用 OpenClaw 来称呼。） OpenClaw 的记忆系统并不神秘。恰恰相反，它非常工程化：记忆不是藏在黑盒里的，而是落在工作区里的 Markdown 文件、会话历史和检索索引里。 你理解了这套机制，很多"为什么它会忘"的问题都会立刻变清楚。 这篇文章在深入研究 OpenClaw 官方文档、拆解源代码之后，讲清楚三件事： OpenClaw 到底靠什么"记住"你； 为什么它会忘； 怎样把它调到一个长期稳定、可维护的状态。 一、先把一个认知纠正过来：模型本身不会跨会话记忆 大语言模型并不会像人一样，把昨天的对话自然带到今天。 它每次能看到的，只有本轮请求被送进上下文窗口的内容。如果某条信息没有进入当前上下文，模型就等于没看见；如果某条信息从来没有被写到磁盘，下次重启后也就无从谈起。 这也是 OpenClaw 记忆设计最核心的一条原则： 文件才是记忆的唯一可信来源。 按照 OpenClaw 当前官方文档，记忆是工作区中的纯 Markdown 文件：模型只会"记住"那些被写入磁盘、并在合适时机重新加载或检索出来的内容。 这件事听上去朴素，但它带来一个非常重要的推论： “我已经在对话里说过了”，不等于"它下次还会记得"； “它刚才答应会记住”，不等于"它已经落盘"； “它知道我是什么意思”，不等于"这条信息已经进入长期记忆层"。 如果你把 OpenClaw 当作一个有天然长期记忆的大脑，就很容易失望；如果你把它当作一个带文件系统、检索和压缩机制的 Agent 运行时，它的行为反而会变得非常可预测。 二、从使用体验看，OpenClaw 实际上有三层"记忆" 官方文档在"记忆文件"这一层主要讲两种载体：MEMORY.md 和 memory/YYYY-MM-DD.md。但从实际使用体验看，OpenClaw 的"记得住"与"记不住"，是三层机制共同作用的结果： 层级 载体 作用 典型内容 工作记忆 当前会话历史 维持本轮任务的连续性 刚才的问答、工具调用结果、当前任务状态 短期记忆 memory/ 保留近期上下文和运行日志 会话摘要、日常运行记录、短期上下文 长期记忆 MEMORY.md 保留跨会话稳定信息 偏好、长期事实、重要决策、环境约定 这三层各自解决的是不同问题。 1. 工作记忆：负责"眼前这件事" 当前会话历史就是工作记忆。它保证 OpenClaw 在同一段对话里还能接着前文往下走。 ...