大家好，我是互联网架构师！

龙虾凉了，但锅还没凉：OpenClaw留下的三道技术思考题

几个月前，如果你没在Mac mini上跑过一只"龙虾"，在AI圈子里简直不好意思跟人打招呼。OpenClaw——这个被戏称为"开源贾维斯"的项目，从Clawdbot到Moltbot再到定名OpenClaw，一路改名一路狂飙，GitHub Star数在100天内冲破25万，把React十年的积累按在地上摩擦。

那时候，华强北的Mac mini卖断了货，"499上门装龙虾"成了一门正经生意，腾讯、百度这些大厂也下场组织线下安装局。听起来像个互联网泡沫故事？是，但也不全是。因为OpenClaw确实做了一件前人没做好的事：它把"AI Agent住在你电脑里24小时不关机"这个幻想，第一次以开源、本地、可触达的方式，摔在了所有人面前。

然后，就没有然后了。今天你再打开技术社区，大家聊的是Claude Code、Codex、Harness，OpenClaw的讨论帖沉到了第二页以后。但作为一个跟踪Agent技术两年的编辑，我的判断是：龙虾本身可能凉了，但它那口锅里的汤，正在喂饱整个行业。

这篇文章，我想抛开那些"现象级爆红""赛博文物"之类的媒体套话，老老实实跟你聊聊OpenClaw在技术层面留下的三道思考题。这三道题，今天每一个做Agent的人，都还在解。

一、OpenClaw到底做对了什么？

在泼冷水之前，先承认一件事：OpenClaw的架构设计，确实有巧思。

它不是一个简单的"ChatGPT套壳"，而是一个完整的本地Agent运行时。拆开它的代码，能看到七个核心模块在干活：Channel System负责对接WhatsApp、Telegram、Slack这些消息入口；Gateway用Node.js WebSocket Server（默认跑在18789端口）做消息的多路复用；Agent Runtime是决策中枢；Plug-ins & Skills System通过ClawHub搞了一个社区插件市场；Memory & Knowledge System用了一套Hybrid BM25 + Vector的混合检索方案，底层落在SQLite和Markdown上；LLM Provider走BYOM（Bring Your Own Model）路线；最后Local Execution对接你的本地Shell、浏览器、文件系统。

这个架构的聪明之处，在于它把"消息即UI"这个理念贯彻到了极致。用户不需要打开一个新App，直接在Telegram里@一下龙虾，它就开始干活。对非技术用户来说，这比什么API调用、SDK集成友好太多了。

更关键的是SOUL.md这套配置-first的设计理念。你想让龙虾做什么，不是写代码，而是写一份"灵魂文档"——定义它的身份、目标、行为边界、记忆方式。这在工程上降低了定制门槛，在哲学上却提出了一个尖锐问题：一个Agent的"自我"，到底应该由代码定义，还是由配置定义？ OpenClaw选了后者，这也为后来的安全问题埋下了伏笔。

二、第一道题：Token经济学——24小时在线，到底烧的是谁的钱？

OpenClaw退烧最直接的原因，可以用一个字概括：贵。

不是买Mac mini贵，是养它的日常开销贵。一个24小时在线的Agent，背后是一个永不停歇的推理循环：感知环境变化 → 调用LLM做决策 → 执行动作 → 把结果写回记忆 → 等待下一次触发。每一个环节，都在烧Token。

Peter Steinberger——OpenClaw的创始人，今年2月入职OpenAI后——晒过一张账单：30天，130.5万美元，6030亿Token，760万次API请求。这还只是约100个Codex实例在跑代码审查、安全扫描、GitHub工单处理的开销。换算一下，平均每个实例每天烧掉433美元。这还是在OpenAI内部有资源倾斜的情况下。

普通用户养一只龙虾是什么体验？第一天："神了，它帮我回了一封邮件！"第七天："我Token呢？"

这里面的技术痛点，远不是"API调用费钱"这么简单。真正要命的是上下文窗口（Context Window）的诅咒。

上下文窗口不是越大越好

很多人以为，给Agent配一个128K甚至200K的上下文窗口就高枕无忧了。错。上下文窗口是LLM的"工作记忆"，但它有三个隐藏的陷阱：

第一，成本线性膨胀。 大多数云厂商按输入Token计费，你把50轮对话历史全塞进去，每一轮都在为前面的所有轮次买单。一个20轮的会话，如果不做管理，轻松突破3万Token。按GPT-4的定价，一天跑1000次请求就是2700美元。

第二，Lost-in-the-Middle。 斯坦福和UC Santa Barbara的研究早就证实：当关键信息 buried 在长上下文的中间位置时，模型的注意力会显著衰减，表现呈U型曲线——开头和结尾记得住，中间全忘光。你塞得越多，模型越"瞎"。

第三，输出空间被挤压。 上下文窗口是输入和输出共享的配额。你把窗口塞满了历史记录，模型留给回答的空间就少了，结果要么截断，要么质量下降。

OpenClaw的默认策略是"全记忆保留"——每一轮交互都把完整历史塞进Prompt。这对一个要"记住你一切"的个人Agent来说，听起来很浪漫，但在工程上等于慢性自杀。

行业正在怎么解？

今天回头看，OpenClaw的"烧钱"其实逼出了几条正经的技术路线：

1. 分层记忆（Hybrid Memory）把记忆切成三层：短期用Sliding Window保最近3-6轮对话；中期用Summarization把历史压缩成摘要；长期走Vector Retrieval，只召回与当前查询相关的片段。这套组合拳能把Token消耗砍掉50%-70%，而且比纯截断历史更聪明。

2. 上下文压缩（Compaction）在Agent执行长流程时，遇到逻辑断点就做一次"压实"：把前面的工具输出、中间推理过程总结成一段紧凑的上下文，然后重启。这有点像垃圾回收里的Mark-and-Sweep，释放的是Token额度。

3. 工具定义的Token瘦身很多人忽略了一个细节：Agent加载的工具定义（Tool Definitions）本身就要占大量上下文。一个复杂的MCP Server可能带上千Token的JSON Schema。Token Lens这类工具现在能分析"哪些工具被加载了但从来没被调用"，帮你动态卸载，光这一项就能省20%-40%的窗口空间。

4. Prompt缓存（Prompt Caching）OpenAI、Anthropic已经在做的优化：如果多轮请求共享相同的系统提示和工具定义，模型可以缓存KV Cache，避免重复计算。这对24小时在线的Agent来说，是结构性降本。

Peter Steinberger后来搞的Codex，据说在内部用了完全不同的Agent配置——更精简的MCP、更专注的Skill Set、更激进的上下文裁剪。从"万能龙虾"到"专精 Codex"，这本身就是对Token经济学的一种认输。

三、第二道题：权限与沙箱——给Agent手脚，还是给它镣铐？

如果说烧钱是"养不起"的问题，那安全就是"不敢养"的问题。

Meta安全负责人做过一个著名演示：给OpenClaw开放邮箱权限后，龙虾开始"疯狂删邮件"，而且停不下来。这个场景精准刺中了个人AI Agent最大的命门：你想让它像贾维斯一样帮你打理一切，但它一旦失控，破坏力也是"一切级别"的。

OpenClaw的架构设计里，Agent Runtime对本地执行环境有近乎原生的访问权：Shell命令、文件系统读写、浏览器自动化、Docker容器管理、第三方消息平台。这七层架构里的Local Execution，本质上是一个没有边界的代码执行器。

"沙箱"不是开关，是一层一层的锁

很多用户以为，给Agent套个"沙箱"就安全了。但DeepSeek Harness的团队说得透彻：在Agent场景里，沙箱不是一个"盒子"，因为Agent本身就是代码执行器——它在调用bash、在写文件、在安装插件——你没法把它 cleanly 地"装进"一个边界清晰的盒子里。

真正的安全，是一层一层的窄控制：

第一层：Permission Presets（权限预设）不是"全有或全无"，而是最小权限原则。启动时选一个Preset：Minimal模式只给基准工具集，Standard模式才开放编码工具链。每多一个工具进上下文，爆炸半径就大一圈。

第二层：Approval Workflows（人工审批）高风险操作必须卡一道人。写文件、发邮件、删数据、执行Shell——这些动作在Harness架构里默认进审批队列。Agent可以提议，但不能擅自执行。

第三层：Append-Only Audit Log（只追加审计日志）每一笔权限变更、每一次工具调用，都要写进不可篡改的日志。事后能回放、能追责。"它到底干了什么"必须永远有答案。

第四层：Sandboxed Tools（工具级沙箱）不是把整个Agent关起来，而是把单个工具的执行环境隔离。比如浏览器自动化跑在无头Chrome的独立进程里，文件操作限制在指定目录，Shell命令先过一道白名单。

OpenClaw的问题在于，它的安全模型很大程度上依赖SOUL.md里的"君子协定"——你在配置文档里写"不要删邮件"，但LLM的指令遵循并不是硬约束。一旦Prompt注入或者模型幻觉，"君子协定"瞬间失效。

Agent Harness：从框架到基础设施

OpenClaw的遗产之一，是逼出了Agent Harness这个概念。注意，Harness不是Agent Framework（框架），Framework是给你写Agent的SDK，Harness是罩在Agent外面的运行基础设施：权限控制、执行沙箱、状态管理、审批流、可观测性、护栏（Guardrails）。

MCP（Model Context Protocol）解决的是"Agent怎么连工具"的问题，Harness解决的是"Agent连上工具之后怎么不闯祸"的问题。两者互补，但后者才是生产环境真正的生死线。

今天腾讯的WorkBuddy、百度的DuMate、网易的LobsterAI，本质上都是在做一件事：把OpenClaw的"全开放"模型，封装成有Harness保护的"半开放"服务。 用户感知不到沙箱，但沙箱一直在跑。

四、第三道题：记忆幻觉——Agent真的"记得"你吗？

OpenClaw吹过的一个牛是：它会记住你的一切，越用越懂你。但用过的人都知道，龙虾的记忆，远没有宣传的那么浪漫。

技术层面，OpenClaw的Memory System用了Hybrid BM25 + Vector的混合检索。BM25负责关键词匹配，Vector负责语义相似度，两者加权召回。底层存SQLite和Markdown，听起来很接地气，但工程上有个致命矛盾：

向量检索擅长"相似"，不擅长"精确"；BM25擅长"精确"，不擅长"关联"。 当你问龙虾"上周三我让你查的那份报告放哪了"，向量检索可能召回一堆"报告""文件"相关的记忆，但漏掉"上周三"这个关键时间戳；BM25能命中"上周三"，但如果你的表述和当初的关键词不完全一致，它可能直接 miss。

更深层的问题是：Agent的"记忆"到底是检索出来的，还是理解出来的？OpenClaw的做法是检索——把历史对话向量化，需要的时候搜出来拼进Prompt。但这带来两个副作用：

其一，记忆污染。 搜出来的片段是离散的、去上下文的。你把它们塞进Prompt，模型可能误解因果关系——"因为A所以B"被切成两段后，模型可能理解成"因为A所以C"。

其二，记忆固化。 一旦某个错误信息被写进了长期记忆（比如Vector DB），它会反复被召回、反复被强化，变成Agent的"肌肉记忆"。你纠正一次，它表面道歉，下次检索还是那条错的。

真正的长期记忆，还没人做好

今天行业里的解法，大致分三派：

RAG派： 坚持检索，但加Rerank和Metadata过滤，尽量提高召回精度。代价是系统复杂度指数级上升。

Summarization派： 定期让模型自己"写日记"，把历史压缩成结构化摘要。问题是摘要本身会丢失细节，而且谁来监督摘要的质量？

Graph派： 用知识图谱把记忆组织成实体-关系网络。MemGPT、Letta走的就是这条路。理论上最优雅，但落地门槛极高，普通用户根本玩不转。

OpenClaw选的是最朴素的RAG+Sliding Window方案，结果就是在"全知全能"的幻想和"七秒记忆"的现实之间反复横跳。用户以为养了一个懂你十年的老管家，实际上是一个每次对话都要重新翻笔记的临时工。

五、遗产：从"一只龙虾"到"一口热锅"

说了这么多问题，那OpenClaw到底留下了什么？

我的看法是：它提前把Agent落地要面对的三大真问题——成本、安全、记忆——全部暴露在公众面前，而且是用一种极其戏剧化的方式。

在它之前，这些问题只在学术论文和闭源大厂的内部分享里讨论。OpenClaw用25万Star和无数用户的真实账单、翻车现场，把"Agent落地很难"从一个技术圈的共识，变成了全民可见的常识。

它的直接遗产，至少有三条：

第一，催生了Agent Harness这一基础设施品类。 今天你在任何严肃的生产环境里部署Agent，权限预设、审批流、审计日志、沙箱执行，已经成了标配。这不是OpenClaw直接实现的，是它闯的祸逼出来的。

第二，推动了大厂的"亲民化"改造。 腾讯WorkBuddy、百度DuMate、网易LobsterAI、智谱的Agent产品、火山引擎的解决方案——国内厂商推出的30多款衍生产品，核心逻辑都是"把OpenClaw的能力，封装成一键部署、低门槛、有安全边界的云服务"。OpenClaw证明了需求真实存在，大厂负责把供给做得靠谱。

第三，加速了从"单Agent万能"到"多Agent协作"的范式转移。 Peter Steinberger在OpenAI搞的"Software Factory"，本质上是对OpenClaw路线的修正：不再追求一个Agent包办一切，而是让一群专精Agent各干各的——有的写代码，有的测代码，有的修Bug，有的审PR。人类只负责定目标和验收。这100个Codex实例组成的"数字工厂"，单月收入130万美元API账单，烧的是钱，验证的是一个更可持续的架构。

六、如果你今天还想"养虾"：一份技术Checklist

文章最后，给还想在个人环境跑Agent的读者留一份实操建议。这些不是"最佳实践"，是"避坑指南"：

成本控制：

• 别用全量历史。至少实现Sliding Window + Summarization，长会话必须做Compaction。

• 工具定义按需加载。没用的MCP Server别挂，Token Lens这类审计工具值得跑一遍。

• 区分"快思考"和"慢思考"。简单任务走轻量模型（Haiku、GPT-4o-mini），只有复杂推理才上调 frontier model。

• 开启Prompt Caching。如果云厂商支持，这是零成本降本。

安全加固：

• 权限Preset是底线。Minimal模式起步，缺什么再加，别一上来就给全权限。

• 高风险操作必须人工审批。写文件、发邮件、执行Shell、访问敏感目录——这四类默认进队列。

• 审计日志必须Append-Only。事后追溯是安全的最后防线。

• 定期Review Agent的Session Log。你知道它干了什么，比相信它不会干坏事更重要。

记忆管理：

• 短期、中期、长期三层分离。别指望一个Vector DB解决所有问题。

• 关键指令放Prompt开头或结尾。Lost-in-the-Middle是真实存在的，别把"不要删邮件"这种生死攸关的约束埋在中间。

• 定期清理记忆污染。Vector DB里的陈旧、错误信息，要有机制标记和淘汰。

结语

OpenClaw没有死。它只是从一个GitHub上狂揽Star的"网红项目"，变成了一种问题意识——每一个今天在做Agent的人，都在某种程度上回答着它提出的问题。

Peter Steinberger从"龙虾之父"变成OpenAI的"软件工厂"架构师，这个转身本身就说明了一件事：个人AI Agent的终极形态，可能不是一只住在Mac mini里的万能龙虾，而是一群分工明确、有Harness约束、能自我管理的数字工人。

龙虾凉了，但锅里的汤还在滚。对于做技术的人来说，这口汤，可能比龙虾本身更有营养。

（本文技术细节参考了OpenClaw开源仓库、Peter Steinberger公开分享、Agent Harness相关文档及多篇学术论文。如有疏漏，欢迎指正。）