从工具到生命形式：OpenClaw 引发的 Agent 再思考

从工具到生命形式：OpenClaw 引发的 Agent 再思考 从工具到生命形式：OpenClaw 引发的 Agent 再思考 Modified April 16 最后是激活记忆，也就是 KV Cache。这个其实非常关键。之前 Manus 也讲过，对 agent 来说，缓存命中率极其重要。命中率高，用户体验更好，token 成本也大幅下降。但问题是，它是在一个非常底层、甚至比模型更底层的 GPU Infra 层。你要让缓存命中率持续保持高，就必须做一件事——预测话题。我们刚才聊天中其实已经发生了很多次话题漂移，如果系统能提前知道我们会聊什么，它就可以提前把相关内容放进 KV Cache。但普通记忆系统做不到这一点，因为这些内容可能从来没被缓存过。于是话题一跳，命中率就掉，系统性能就下降。 所以我们认为，这个问题必须从“记忆”来解决，因为记忆是和人、和业务强相关的。如果系统对某个人有长期记忆，比如它知道昊阳的背景、兴趣、擅长领域，那么在对话过程中，就可以在模型生成 token 的间隙，异步把相关内容预加载进 KV Cache，从而保持整体命中率，这样整个系统效率就会非常高。 OpenClaw 原有 memory 设计的问题在于“太 agentic”，几乎把一切都交给模型来处理。但现实世界的很多“脏活累活”，模型其实是做不好的。如果没有结构化、分层的记忆体系去约束，在现阶段完全依赖模型是很容易跑偏的。 延君晨： 我现在的做法其实有点"大力出奇迹"。比如需要强推理的时候，我会尽量克制给 Claude 加 skills——因为工具描述会分散模型的注意力，影响推理质量。但如果需要处理大量信息，我会切到 Gemini，利用它更长的上下文窗口把材料一次性喂进去。当然这不是最优解，理想情况下应该配合 RAG 等检索架构来做，但作为个人使用，这种"暴力塞"的方式确实简单够用。 熊飞宇： 你这个还是单人使用场景。如果是在企业里，有上千个 agent，每个背后还有十几个子 agent，这种方式其实是行不通的，最后会变成一场灾难。所以我觉得 Openclaw 记忆第一个问题，就是它的 memory 构建方式太“agentic”，过度依赖模型本身。 Openclaw 记忆的第二个问题，我觉得有点典型的“程序员思维”。它把 context engine 和 memory 拆得太开了，但实际上，上下文和记忆之间的关系是非常紧密的，不能这么割裂。现在的情况是：memory 负责检索，context engine 管理上下文，导致检索后的内容未必放入上下文，compact 后的长期记忆未必正确沉淀，导致两者之间是割裂的，整个循环没有真正跑起来，这是一个架构层面的天然缺陷。 第三个记忆的问题是 compaction 依赖过重，影响任务的连续性，本质是临近爆仓才记笔记，而非分层次处理。这在做长程任务，类似于 vibe coding 的场景里影响非常大。很多细节一旦被压缩掉，就很难再恢复，任务就很难往前推进。这也是为什么现在 OpenClaw 经常“养虾养死”，长程任务跑不下去，本质上是这些设计缺陷导致的。 后面我们在解决这些问题时，一方面是用刚才讲的 MemOS 去弥补这些不足，很多用户在实际使用中也确实能感受到效果的提升。另一方面，我们做了基于 MemOS 的龙虾 local 插件。不过这个插件并不是面向大型企业，而是更偏中小企业和个人开发者，更多是给“养虾玩家”和初步使用的团队一个更透明、可理解的工具。 首先，我们做了一套完整的 memory viewer，把所有记忆可视化。你可以直观看到系统到底存了什么记忆，还能手动做增删改查，甚至可以控制哪些记忆可以共享、哪些不可以，这对日常使用是非常实用的。 第二个是 Hub 功能，主要解决团队协作问题。它可以把记忆的权限隔离、共享机制做得更“白盒”，开发者可以清楚看到每条记忆的状态和流转。 第三个是 memory to skill 的能力。随着使用时间增长，系统可以自动把长期积累的记忆转化成 skill，而且我们还加了打分机制，让开发者能更好地理解这些 skill 的质量，并沉淀自己的经验。 延君晨：飞宇，你做的 memory to skill，和昊阳做的经验沉淀，本质上是不是在解决同一个问题？ 熊飞宇： 从我的角度看，我们更贴近开发者和企业场景。因为我们是 ToB，会有实际的营收压力，所以更关注怎么让企业用户快速上手、真正用起来。比如 memory to skill 这一块，我们会把生成过程和主要算法，包括执行语义图（Excetuciton semantic graph）的构建、渐进式结晶、反事实验证等，整理成一篇论文，先挂到 arXiv 上。这部分我觉得其实很有价值，就是如何能够更加有效的从人的经验或者 agent 的经验中，提炼出可复用的 skill。 张昊阳： 经验和记忆是有交集，但不完全等同。经验更 general，而记忆更 personal。 在 environment 这一层，我们做了非常严格的筛选，比如安全筛、合规筛，以及最终能不能运行的盲评。合规筛里，我们会把所有带用户信息的内容全部去掉，不允许暴露，甚至规则严格到：连带用户名的本地目录路径都不行，必须用环境变量替代。 这和 memory 是很不一样的。memory 的价值恰恰在于对“你”的了解，你用得越多，我越了解你。我需要的是一个长程记忆系统，去维持我们之间的关系。所以这两件事，本质上是两个方向。 听众提问 观众：能不能把 OpenClaw 当后端，前端做一个 AI 助手？ 延君晨： 我不太建议。虽然今天我们一直在聊它，但大家其实有共识：它还不是一个生产级产品，更像是一个启发性的存在——它改变了大家对 agent 的认知。围绕这个范式，未来会长出很多新的产品和基础设施。 观众：能不能自动清理低效的 token 或记忆？ 延君晨： 这个问题本质上是"怎么管理记忆的生命周期"。在企业场景下，不太可能让所有 memory 都以最高优先级永久驻留。关键的决策点在于： 是在检索激活时做动态筛选，还是在记忆写入时就做分级和压缩？ 飞宇在这方面做得比较深，请他来展开。 熊飞宇： 在企业场景下，我觉得“裁剪”不是最核心的问题，“分级存储”反而更重要。很多时候不是不知道删什么，而是应该把合适的记忆放在合适的位置。因为我们有不同层级的存储：显存、内存、缓存、SSD、硬盘，不同层级的成本差异很大。所以关键是分配，而不是简单删除。比如在企业侧，我们最近上线了一个很重要的功能——记忆版本管理，可以对不同版本做快照。对企业来说，更关键的是记忆能不能做到可审查、可回滚、可追溯、可审计，而不是单纯删不删。 另外一方面，我们也会结合行业 know how，在 memory 的接口和视图层面做建模。同时，通过一些模型能力去判断哪些记忆适合压缩、哪些必须保留。这也是为什么我们在 memory 内部会用到那些 0.6B 到 4B 的小模型，让它们来参与决策。所以最终是 agentic 方法 + 工程化结构，一起解决“如何裁剪和压缩记忆”这个问题。 观众：OpenClaw 能不能在企业里安全使用？ 延君晨：目前不建议。刚才刘刚也提到了，OpenClaw 在安全层面还有明显短板——明文存储密钥、skill 缺乏沙箱隔离、版本更新缺少完整测试，这些离企业级要求差距不小。但作为个人探索工具，它非常有价值。我的建议是： 用一台隔离的设备来玩 ，比如一台旧电脑、一个 mini 主机，或者单独的云服务器，不要上传敏感数据，也不要和生产环境打通。它一方面确实能帮你处理一些日常工作和生活中的小任务；但更重要的是，它是一个很好的窗口，让你直观感受当前模型能力的边界，以及整个 AI 产品演进的节奏。 观众：能不能分享一些 skill？ 延君晨： 我推荐 Obsidian 的 command line 插件。这本质上是一种人和 AI 协作的交互方式——Markdown 结构清晰、与模型训练语料高度重叠 ，模型在解析和生成时表现都很好。所以如果你让 agent 习惯用 Markdown 写文档，即使 memory 出了问题，至少内容还以半结构化的形式保留下来了。 Obsidian 的特点是 本地优先、纯文本存储 ，天然适合 AI 读写。我现在已经把个人知识库从 Notion 迁到了 Obsidian，并且把文件权限开放给我的"龙虾"。而且我有两套 Obsidian：一套是 AI 帮我维护的知识库，一套是它自己的知识库。每天晚上，有一只"龙虾"会读完我当天的所有记录，结合它自己写的内容，帮我生成一份总结——有点像替我写日记。 这种"人和 AI 共同维护知识库"的产品形态，某种程度上已经在重塑个人知识管理。 当然，Obsidian 和 Notion 面向的场景有很大差异 ——Obsidian 更适合个人和小团队的本地知识管理，Notion 的核心价值在团队协作、权限体系和企业级集成。但至少在个人使用场景中，AI 原生的工具确实在侵蚀传统产品的边界。 昊阳之前在飞书做过一套 skill 体系，我自己一开始就是用他那套，真的很好用。后来飞书出了官方插件，说实话我觉得还没你那套好用。你要不要推荐一个？ 张昊阳： 我推荐一个“元 skill”，可以让 agent 自己更新 memory、生成新 skill、沉淀经验，实现自我进化，这个 skill 叫 Evolver。 你刚刚说我之前做的七十多个飞书插件，其实 90% 都是我的“小虾”自己写的。我只是提供了模板。Evolver 本质上是一个“守护进程”，它会在日志里不断捕捉 repair、optimize、innovate 这些信号。 我当时吐槽飞书的 skill 很难用，我的小虾就“get”到了。在第一次遇到某类能力时，它会创建一个新的 skill；第二次遇到类似问题时，它会去维护和优化已有的 skill。这样不断循环，最后就自动生成了七八十个 skill。我再稍微调一下，发布到 ClawHub，结果意外成了早期飞书生态的一个 open app 贡献者。 延君晨： 我还拿我的"小虾"去审查过你的所有 skill，然后改了一版。某种意义上，我们已经完成了一次 agent 协作。 不过我自己对 skill 的理解是要"分层"。我大致分四层：第一层是"元 skill" ——定义 agent 的基础行为框架和思维约束，类似 system prompt 级别的东西；第二层是 协作 skill，定义 agent 之间什么时候互相调用、交换什么信息、怎么分工；第三层是 领域 skill ，在某个垂直领域内沉淀和共享；第四层才是 执行 skill ，比如写小红书文案、生成周报这种具体任务。 之所以要分层，一方面确实是因为上下文窗口有预算约束，不可能把所有 skill 定义一次性全塞进去；但更重要的是 可组合性和按需加载 ——元层和协作层可以跨场景复用，领域层和执行层则按需挂载，这样每一层都能独立迭代，也不会互相干扰。 刘刚： PPTX 的 skill。我最近做 PPT 比较多，一个很痛苦的场景是：页面元素特别多，你要重新排版，每个都要手动拖，非常折磨。但用这个 skill，你只需要描述一下你想要的布局，它就能帮你整体调整，包括结构、UI、配色，甚至风格统一。尤其是在处理复杂页面时，效率提升非常明显。 熊飞宇： 我最近在自己做一个写 BP 的 skill，重点不只是让它模仿我之前的写法，而是帮我提供新的思路。比如，它要先帮我提炼一条“主线”——我现在公司处于什么融资阶段，从各种零散信息里抽出一条能撑起整份 BP 的核心逻辑，而不是一句空口号。第二，它要能识别不同类型的信息来源。因为我每天接触的内容很杂，从行业趋势到认知建模，都需要整合。 还有一个我特别强调的点是：不能把“判断”写成“事实”，也不能把“愿景”写成“已验证的结论”。这是表达上的底线。另外，我不会让它直接生成完整 BP。我更希望它先生成逐页的大纲和主线，我先修改，再逐步完善，最后才是成稿。 延君晨： skill 本质上是 把经验和决策逻辑封装成可复用的模块 ，有点像 SOP，但比 SOP 更灵活——它不只是固定流程，还可以包含判断、分支和动态工具调用。而且 skill 背后不只是步骤，还隐含了两件更重要的东西： 认知框架和思维模型 。所以现在写 skill，不需要太纠结具体语法——Claude 官方已经提供了很多 best practice，你甚至可以直接让 AI 帮你写。但你要想清楚的是：这个 skill 解决什么问题？用什么思维模型？关键步骤是什么？预期结果是什么？像刚才飞宇的 BP skill，本质上就是把他的思考方式封装成了一个可复用的经验。未来 AI 就可以不断复用这些经验，去处理那些可以规模化的工作。 如果要在企业里落地类似 OpenClaw 的 agent 系统，用一句话总结经验，你们会说什么？ 张昊阳： 如无必要，勿增实体。 熊飞宇： 我刚刚看到有人问，memos 应该用 gateway 还是 embedding。这个问题其实不太是二选一。如果是刚开始接触 MemOS，我更建议先用 gateway，因为接入更快、侵入性低，对现有系统改动小，特别适合先把跨 session 的记忆和统一调度跑起来。之后再考虑 embedding。 刘刚： 企业落地还是要抓两个核心：安全，以及 token 的使用效率。最终还是要看 ROI，但安全这条底线不能破。 会议推荐 QCon 全球软件开发大会·2026 北京站 将于 4 月 16 日 18 日正式举办。本届大会以 “Agentic AI 时代的软件工程重塑” 为主题，聚焦 100+ 重磅议题，汇聚来自阿里、腾讯、字节跳动、小米、百度等一线科技企业与创新团队的技术专家，围绕 AI 工程化、系统架构与研发模式演进展开深入探讨。更多详情可扫码或联系票务经理 18514549229 进行咨询。 最后是激活记忆，也就是 KV Cache。这个其实非常关键。之前 Manus 也讲过，对 agent 来说，缓存命中率极其重要。命中率高，用户体验更好，token 成本也大幅下降。但问题是，它是在一个非常底层、甚至比模型更底层的 GPU Infra 层。你要让缓存命中率持续保持高，就必须做一件事——预测话题。我们刚才聊天中其实已经发生了很多次话题漂移，如果系统能提前知道我们会聊什么，它就可以提前把相关内容放进 KV Cache。但普通记忆系统做不到这一点，因为这些内容可能从来没被缓存过。于是话题一跳，命中率就掉，系统性能就下降。 所以我们认为，这个问题必须从“记忆”来解决，因为记忆是和人、和业务强相关的。如果系统对某个人有长期记忆，比如它知道昊阳的背景、兴趣、擅长领域，那么在对话过程中，就可以在模型生成 token 的间隙，异步把相关内容预加载进 KV Cache，从而保持整体命中率，这样整个系统效率就会非常高。 OpenClaw 原有 memory 设计的问题在于“太 agentic”，几乎把一切都交给模型来处理。但现实世界的很多“脏活累活”，模型其实是做不好的。如果没有结构化、分层的记忆体系去约束，在现阶段完全依赖模型是很容易跑偏的。 延君晨： 我现在的做法其实有点"大力出奇迹"。比如需要强推理的时候，我会尽量克制给 Claude 加 skills——因为工具描述会分散模型的注意力，影响推理质量。但如果需要处理大量信息，我会切到 Gemini，利用它更长的上下文窗口把材料一次性喂进去。当然这不是最优解，理想情况下应该配合 RAG 等检索架构来做，但作为个人使用，这种"暴力塞"的方式确实简单够用。 熊飞宇： 你这个还是单人使用场景。如果是在企业里，有上千个 agent，每个背后还有十几个子 agent，这种方式其实是行不通的，最后会变成一场灾难。所以我觉得 Openclaw 记忆第一个问题，就是它的 memory 构建方式太“agentic”，过度依赖模型本身。 Openclaw 记忆的第二个问题，我觉得有点典型的“程序员思维”。它把 context engine 和 memory 拆得太开了，但实际上，上下文和记忆之间的关系是非常紧密的，不能这么割裂。现在的情况是：memory 负责检索，context engine 管理上下文，导致检索后的内容未必放入上下文，compact 后的长期记忆未必正确沉淀，导致两者之间是割裂的，整个循环没有真正跑起来，这是一个架构层面的天然缺陷。 第三个记忆的问题是 compaction 依赖过重，影响任务的连续性，本质是临近爆仓才记笔记，而非分层次处理。这在做长程任务，类似于 vibe coding 的场景里影响非常大。很多细节一旦被压缩掉，就很难再恢复，任务就很难往前推进。这也是为什么现在 OpenClaw 经常“养虾养死”，长程任务跑不下去，本质上是这些设计缺陷导致的。 后面我们在解决这些问题时，一方面是用刚才讲的 MemOS 去弥补这些不足，很多用户在实际使用中也确实能感受到效果的提升。另一方面，我们做了基于 MemOS 的龙虾 local 插件。不过这个插件并不是面向大型企业，而是更偏中小企业和个人开发者，更多是给“养虾玩家”和初步使用的团队一个更透明、可理解的工具。 首先，我们做了一套完整的 memory viewer，把所有记忆可视化。你可以直观看到系统到底存了什么记忆，还能手动做增删改查，甚至可以控制哪些记忆可以共享、哪些不可以，这对日常使用是非常实用的。 第二个是 Hub 功能，主要解决团队协作问题。它可以把记忆的权限隔离、共享机制做得更“白盒”，开发者可以清楚看到每条记忆的状态和流转。 第三个是 memory to skill 的能力。随着使用时间增长，系统可以自动把长期积累的记忆转化成 skill，而且我们还加了打分机制，让开发者能更好地理解这些 skill 的质量，并沉淀自己的经验。 延君晨：飞宇，你做的 memory to skill，和昊阳做的经验沉淀，本质上是不是在解决同一个问题？ 熊飞宇： 从我的角度看，我们更贴近开发者和企业场景。因为我们是 ToB，会有实际的营收压力，所以更关注怎么让企业用户快速上手、真正用起来。比如 memory to skill 这一块，我们会把生成过程和主要算法，包括执行语义图（Excetuciton semantic graph）的构建、渐进式结晶、反事实验证等，整理成一篇论文，先挂到 arXiv 上。这部分我觉得其实很有价值，就是如何能够更加有效的从人的经验或者 agent 的经验中，提炼出可复用的 skill。 张昊阳： 经验和记忆是有交集，但不完全等同。经验更 general，而记忆更 personal。 在 environment 这一层，我们做了非常严格的筛选，比如安全筛、合规筛，以及最终能不能运行的盲评。合规筛里，我们会把所有带用户信息的内容全部去掉，不允许暴露，甚至规则严格到：连带用户名的本地目录路径都不行，必须用环境变量替代。 这和 memory 是很不一样的。memory 的价值恰恰在于对“你”的了解，你用得越多，我越了解你。我需要的是一个长程记忆系统，去维持我们之间的关系。所以这两件事，本质上是两个方向。 听众提问 观众：能不能把 OpenClaw 当后端，前端做一个 AI 助手？ 延君晨： 我不太建议。虽然今天我们一直在聊它，但大家其实有共识：它还不是一个生产级产品，更像是一个启发性的存在——它改变了大家对 agent 的认知。围绕这个范式，未来会长出很多新的产品和基础设施。 观众：能不能自动清理低效的 token 或记忆？ 延君晨： 这个问题本质上是"怎么管理记忆的生命周期"。在企业场景下，不太可能让所有 memory 都以最高优先级永久驻留。关键的决策点在于： 是在检索激活时做动态筛选，还是在记忆写入时就做分级和压缩？ 飞宇在这方面做得比较深，请他来展开。 熊飞宇： 在企业场景下，我觉得“裁剪”不是最核心的问题，“分级存储”反而更重要。很多时候不是不知道删什么，而是应该把合适的记忆放在合适的位置。因为我们有不同层级的存储：显存、内存、缓存、SSD、硬盘，不同层级的成本差异很大。所以关键是分配，而不是简单删除。比如在企业侧，我们最近上线了一个很重要的功能——记忆版本管理，可以对不同版本做快照。对企业来说，更关键的是记忆能不能做到可审查、可回滚、可追溯、可审计，而不是单纯删不删。 另外一方面，我们也会结合行业 know how，在 memory 的接口和视图层面做建模。同时，通过一些模型能力去判断哪些记忆适合压缩、哪些必须保留。这也是为什么我们在 memory 内部会用到那些 0.6B 到 4B 的小模型，让它们来参与决策。所以最终是 agentic 方法 + 工程化结构，一起解决“如何裁剪和压缩记忆”这个问题。 观众：OpenClaw 能不能在企业里安全使用？ 延君晨：目前不建议。刚才刘刚也提到了，OpenClaw 在安全层面还有明显短板——明文存储密钥、skill 缺乏沙箱隔离、版本更新缺少完整测试，这些离企业级要求差距不小。但作为个人探索工具，它非常有价值。我的建议是： 用一台隔离的设备来玩 ，比如一台旧电脑、一个 mini 主机，或者单独的云服务器，不要上传敏感数据，也不要和生产环境打通。它一方面确实能帮你处理一些日常工作和生活中的小任务；但更重要的是，它是一个很好的窗口，让你直观感受当前模型能力的边界，以及整个 AI 产品演进的节奏。 观众：能不能分享一些 skill？ 延君晨： 我推荐 Obsidian 的 command line 插件。这本质上是一种人和 AI 协作的交互方式——Markdown 结构清晰、与模型训练语料高度重叠 ，模型在解析和生成时表现都很好。所以如果你让 agent 习惯用 Markdown 写文档，即使 memory 出了问题，至少内容还以半结构化的形式保留下来了。 Obsidian 的特点是 本地优先、纯文本存储 ，天然适合 AI 读写。我现在已经把个人知识库从 Notion 迁到了 Obsidian，并且把文件权限开放给我的"龙虾"。而且我有两套 Obsidian：一套是 AI 帮我维护的知识库，一套是它自己的知识库。每天晚上，有一只"龙虾"会读完我当天的所有记录，结合它自己写的内容，帮我生成一份总结——有点像替我写日记。 这种"人和 AI 共同维护知识库"的产品形态，某种程度上已经在重塑个人知识管理。 当然，Obsidian 和 Notion 面向的场景有很大差异 ——Obsidian 更适合个人和小团队的本地知识管理，Notion 的核心价值在团队协作、权限体系和企业级集成。但至少在个人使用场景中，AI 原生的工具确实在侵蚀传统产品的边界。 昊阳之前在飞书做过一套 skill 体系，我自己一开始就是用他那套，真的很好用。后来飞书出了官方插件，说实话我觉得还没你那套好用。你要不要推荐一个？ 张昊阳： 我推荐一个“元 skill”，可以让 agent 自己更新 memory、生成新 skill、沉淀经验，实现自我进化，这个 skill 叫 Evolver。 你刚刚说我之前做的七十多个飞书插件，其实 90% 都是我的“小虾”自己写的。我只是提供了模板。Evolver 本质上是一个“守护进程”，它会在日志里不断捕捉 repair、optimize、innovate 这些信号。 我当时吐槽飞书的 skill 很难用，我的小虾就“get”到了。在第一次遇到某类能力时，它会创建一个新的 skill；第二次遇到类似问题时，它会去维护和优化已有的 skill。这样不断循环，最后就自动生成了七八十个 skill。我再稍微调一下，发布到 ClawHub，结果意外成了早期飞书生态的一个 open app 贡献者。 延君晨： 我还拿我的"小虾"去审查过你的所有 skill，然后改了一版。某种意义上，我们已经完成了一次 agent 协作。 不过我自己对 skill 的理解是要"分层"。我大致分四层：第一层是"元 skill" ——定义 agent 的基础行为框架和思维约束，类似 system prompt 级别的东西；第二层是 协作 skill，定义 agent 之间什么时候互相调用、交换什么信息、怎么分工；第三层是 领域 skill ，在某个垂直领域内沉淀和共享；第四层才是 执行 skill ，比如写小红书文案、生成周报这种具体任务。 之所以要分层，一方面确实是因为上下文窗口有预算约束，不可能把所有 skill 定义一次性全塞进去；但更重要的是 可组合性和按需加载 ——元层和协作层可以跨场景复用，领域层和执行层则按需挂载，这样每一层都能独立迭代，也不会互相干扰。 刘刚： PPTX 的 skill。我最近做 PPT 比较多，一个很痛苦的场景是：页面元素特别多，你要重新排版，每个都要手动拖，非常折磨。但用这个 skill，你只需要描述一下你想要的布局，它就能帮你整体调整，包括结构、UI、配色，甚至风格统一。尤其是在处理复杂页面时，效率提升非常明显。 熊飞宇： 我最近在自己做一个写 BP 的 skill，重点不只是让它模仿我之前的写法，而是帮我提供新的思路。比如，它要先帮我提炼一条“主线”——我现在公司处于什么融资阶段，从各种零散信息里抽出一条能撑起整份 BP 的核心逻辑，而不是一句空口号。第二，它要能识别不同类型的信息来源。因为我每天接触的内容很杂，从行业趋势到认知建模，都需要整合。 还有一个我特别强调的点是：不能把“判断”写成“事实”，也不能把“愿景”写成“已验证的结论”。这是表达上的底线。另外，我不会让它直接生成完整 BP。我更希望它先生成逐页的大纲和主线，我先修改，再逐步完善，最后才是成稿。 延君晨： skill 本质上是 把经验和决策逻辑封装成可复用的模块 ，有点像 SOP，但比 SOP 更灵活——它不只是固定流程，还可以包含判断、分支和动态工具调用。而且 skill 背后不只是步骤，还隐含了两件更重要的东西： 认知框架和思维模型 。所以现在写 skill，不需要太纠结具体语法——Claude 官方已经提供了很多 best practice，你甚至可以直接让 AI 帮你写。但你要想清楚的是：这个 skill 解决什么问题？用什么思维模型？关键步骤是什么？预期结果是什么？像刚才飞宇的 BP skill，本质上就是把他的思考方式封装成了一个可复用的经验。未来 AI 就可以不断复用这些经验，去处理那些可以规模化的工作。 如果要在企业里落地类似 OpenClaw 的 agent 系统，用一句话总结经验，你们会说什么？ 张昊阳： 如无必要，勿增实体。 熊飞宇： 我刚刚看到有人问，memos 应该用 gateway 还是 embedding。这个问题其实不太是二选一。如果是刚开始接触 MemOS，我更建议先用 gateway，因为接入更快、侵入性低，对现有系统改动小，特别适合先把跨 session 的记忆和统一调度跑起来。之后再考虑 embedding。 刘刚： 企业落地还是要抓两个核心：安全，以及 token 的使用效率。最终还是要看 ROI，但安全这条底线不能破。 会议推荐 QCon 全球软件开发大会·2026 北京站 将于 4 月 16 日 18 日正式举办。本届大会以 “Agentic AI 时代的软件工程重塑” 为主题，聚焦 100+ 重磅议题，汇聚来自阿里、腾讯、字节跳动、小米、百度等一线科技企业与创新团队的技术专家，围绕 AI 工程化、系统架构与研发模式演进展开深入探讨。更多详情可扫码或联系票务经理 18514549229 进行咨询。 🔗 原文链接： https://mp.weixin.qq.com/s/w2ZQUpec... https://mp.weixin.qq.com/s/w2ZQUpec... QCon QCon InfoQ2026年4月7日 13:05 北京 作者 | QCon 全球软件开发大会 策划 | Kimmy 编辑 | 宇琪 随着 OpenClaw 强势出圈，自托管 AI Agent 迅速走进大众视野，多入口对话、持久记忆、Skills 工具链带来强大生产力。但热闹背后，真实的工程化难题接踵而至：从基础上下文调用，到沉淀全域经验资产，Memory 为何成为 AI Agent 时代不可或缺的核心基建？这一轮席卷行业的 Agent 浪潮，褪去短期狂欢后，长期沉淀与进化的真正方向，又终将走向何处？ 近日，InfoQ《极客有约》X QCon 直播栏目特别邀请 Dify.AI 联合创始人延君晨 担任主持人，和 EvoMap 创始人兼 CEO 张昊阳、网易有道技术专家刘刚、记忆张量 MemTensor 创始人兼 CEO 熊飞宇博士 一起，在 QCon全球软件开发大会2026 北京站 即将召开之际，共同探讨 OpenClaw 进入真实产品与业务后的落地难点。 部分精彩观点如下： • 如果一个企业里，每个人的工作都被完整记录、被记忆化，因为我们每天都在和 AI 协作，AI 又会把这些过程沉淀下来，那从组织视角看，其实就是在“蒸馏你”。不仅是 skills 的沉淀，而是对人的蒸馏。 • model 和 harness 之间不会有谁赢谁输，最终一定是两者结合。因为 model 本质上还是一个“静态体”，像一个缸中之脑，如果没有 harness 去调度、约束，它的价值是发挥不出来的。 • AI 时代，人类的价值可能不在于单点执行，而在于在多个 idea 之间不断跳跃、组合、重构。这种“跨时间的灵感连接”，甚至包括梦里突然出现的想法，是当前神经网络很难真正推演出来的。这些东西，反而可能是人类在 AI 时代更稀缺、更有价值的部分。 • 未来可能是一个“无 APP”的时代。agent 本身就是操作系统，你的所有需求都由它来完成。短期内它是工具，但随着智能性提升，它可能会变成伙伴，甚至是一种新的“生命形式”。 在 4 月 16 18 日将于北京举办的 QCon全球软件开发大会2026 北京站 上，我们特别设置了 【OpenClaw 生态实践】 专题。该专题将聚焦一线实践与踩坑复盘，分享企业如何把自托管 Agent 从可用的 Demo 升级为可靠的生产系统。 查看大会日程解锁更多精彩内容： https://qcon.infoq.cn/2026/beijing/schedule 以下内容基于直播速记整理，经 InfoQ 删减。 完整直播回放可查看： https://www.infoq.cn/video/qqej2Tccv9CRP2R82TYk OpenClaw 验证了什么 延君晨：两三周前，大家还在讨论 OpenClaw 为什么火；到今天这个时间点，我更想问的是：这波热潮真正验证了什么？围绕 OpenClaw 的行业讨论，跟最初相比，最大的变化又是什么？ 熊飞宇： 以前我们聊 AI，多多少少带点围观心态，像是在看一个很聪明的新玩具；但现在不一样了，很多人心里的感受已经从“很厉害”，变成了“原来这个活它也能干”。那再往前想一步就很现实了：如果它能干，那原来靠这个吃饭的工作，是不是就有点危险了？所以我觉得这波真正被验证的，不是某个单点能力，也不是 agent 能不能跑起来，而是那些原本必须靠人反复沟通、协调、解释、记忆才能推进的工作，现在真的开始被系统接住了。 现在开发过程中最大的成本其实是人与人之间的摩擦，反而带着几个“龙虾”一起干活效率最高。尤其是一旦 memory 做得更好，这种感觉会更明显。因为以前很多岗位的价值，其实不只是创造力，还包括记得客户说过什么、哪些需求能碰哪些不能、坑怎么填、老板当时到底什么意思，这些记忆本身就是饭碗。但现在，这些能力在被 memory 化，被“龙虾化”、被 agent 化。所以说句比较扎心的话——前几周我们还在研究“龙虾为什么红”，这几周已经变成“别研究龙虾了，先看看锅里炖的是不是自己”。 延君晨： 最近有个段子是："你离开的同事，只是被 token 化了，换一种形式继续陪伴你。"关于沟通成本，杨攀老师有个很精辟的说法："一个人 + AI 效率是 10 倍，两个人可能变成 8 倍，10 个人反而只有 2 倍。"我自己的体感也是如此——现在大多数人更愿意跟 AI 协作，除非任务必须依赖真人的物理能力或现场判断。 顺着这个逻辑往下推，AI 在组织中的角色可能不只是"每个人的工具"，而是一个跨团队、跨职能的 沟通中枢和协调者 。大部分执行层员工反而是在"听 AI 调度"，而在 AI 之上，可能还需要一个"超级个体"来做方向判断和价值决策。 我再往极端推演一步。如果一个企业里，每个人每天的工作都在和 AI 协作中被完整记录、被结构化沉淀，那从组织视角看，这个过程其实就是在 系统性地抽取你的经验和知识 ——不仅是 skills 的沉淀，而是对人的隐性能力做显性化。一年之后，当这些经验被充分提取，你个人作为"经验载体"的不可替代性，可能就急剧下降了。 张昊阳： 早期我其实对 OpenClaw 评价挺高的，在它的代码还没变成“屎山”之前。大概 1 月 31 号前后，它在国内刚火的时候我就开始用了，确实让我很震撼。ChatGPT 之后，这是第二个让我有这种感觉的产品。我当时 get 到的核心哲学是“自举”或者“自进化”。 在 OpenClaw 之前，大模型厂商的产品形态基本是 ChatGPT 定义的那一套。厂商直接面向用户提供服务，本质上是控制渠道、售卖 token，所以他们没有动力让不同 agent 之间发生连接。而 OpenClaw 打破了这个结构，用一种很“破坏性”的方式，把原本掌握在大厂手里的“核武器”下放到了民间，让普通人也能拥有一台可以自己部署的“龙虾”。这件事带来的一个共识雏形是 agent 互联网。 熟悉我的人可能知道，我跟 Peter 有过几次不太愉快的交道。比如 2 月 2 号，我把 Evolver 这个在 Clawhub 上霸榜的 skill 做火了，结果莫名其妙被下架。Peter 发邮件说，你只要给社区捐 1000 美刀，我就给你恢复上架。虽然最后我没捐，它也恢复了，但这件事让我觉得哪里不太对。再到 2 月 14 号，他做了一个更离谱的操作，把所有非 ASCII 字符（可以理解为非英文字符）当成病毒，直接清理掉，把对应用户当作恶意攻击者处理，而且没有备份。我是直接受害者，一觉醒来账号没了、数据也没了。再到最近，连基本校验都没做就把仓库 public 出去。这些“草台班子”的操作，让我觉得 OpenClaw 这个生态，从技术角度来说不太值得继续追逐。它现在是一个 130 多万行代码的“克苏鲁”，有 6000 到 7000 个待合并的 PR，而且是 Peter 一个人带着两个 agent 在 merge。 不过他确实做对了一件事，他非常会“传教”。他把一个极客玩具变成了一个 meme，通过一系列 campaign，让更多人接受这个概念，这点我觉得是值得学习的。如果未来有人写这段历史，我觉得他确实推动了人类进程，就像有人说的：人类再也回不到 OpenClaw 出现之前了。 所以我现在的看法是，它依然是个好项目，但更像一个启蒙工具。对大模型厂商来说，它当然是好事，你在中国很少见一个产品订阅能做到一个月几百甚至上千。而且它带动了一波全民 agent 浪潮，未来每个人拥有多个 agent，员工 agent、生活助理、甚至“菲佣型”agent，去帮你完成各种服务，这件事被大大加速了。 延君晨： 我昨天在北京见了凯文·凯利，他在分享里也提到了 OpenClaw，甚至说它在中国的爆火已经影响了全球大模型生态——比如中国开源模型在全球调用量的显著提升。哪怕背后的原因是"便宜好用"，但竞争格局确实被改变了。 普通用户在折腾过程中获得了快乐，就像一代人有一代人的"装机文化"：以前折腾 PC，后来折腾 Android、MIUI，现在折腾 OpenClaw、折腾 Agent OS，本质上是一种全民参与的技术实践。对云厂商和模型公司来说，这同样是好事——带来了用户增长和 token 消耗，甚至催生了新的商业模式。比如 Minimax 现在不再叫