龙虾实际产品形态预测——龙虾生态创业者必读系列

龙虾实际产品形态预测——龙虾生态创业者必读系列 龙虾实际产品形态预测——龙虾生态创业者必读系列 Modified February 25 1、不是独立App，是嵌入在你常用的聊天软件（目前最优解是Telegram）里的对话窗口 2、不是一个万能agent，是多个专注不同领域的agent，各有自己的窗口 3、需要一个大总管agent负责调配和维护统一记忆 4、主动汇报比被动聊天重要——每天早上你打开Telegram，每个agent已经把简报发过来了，你扫一遍就行 5、记忆共享是当前最大的技术短板，Mnemo和Memory System 2.0是早期尝试 6、现阶段能真正用起来的是少数个人创业者，企业市场还需要合规层的成熟 OpenClaw的贡献是证明了"agent住在聊天软件里"这个方向是对的。接下来要解决的是怎么从"一个agent一个窗口"进化到"多个agent协同工作"，以及记忆怎么在它们之间流动。这两个问题谁先解决好，谁就拿下下一阶段。 附：支持和反对这个观点的案例 上面是我的判断。下面是从83条推文和132个用例里找到的支撑材料，也包括跟我观点矛盾的案例——放在一起看更完整。 支持"agent应该在聊天软件里，不是独立App" René Schulte让agent "Dave"通过WhatsApp从零建了一个完整网站——没用IDE、没push过git，全程聊天完成。他的原话是"no IDE, no git push, just chat"。这说明聊天界面不只是"方便"，它本身就能承载复杂的生产力工作。——by @rschu，2月16日 James Steinberg说"我就想用手机远程控制Codex和Claude Code"，最后用VNC方案解决。他真正的需求不是VNC，是"在我已经在用的工具里，随时随地控制agent"。——by @DareFailed，2月22日 Contabo的部署教程有个细节值得注意：他们建议agent跑在VPS而不是Mac Mini上，因为"Mac mini会离线，VPS不会"。但如果agent通过Telegram跟你通信，Telegram本身就是永远在线的——设备离不离线不影响你跟agent的对话。 Radek Sienkiewicz的描述很有画面感："它替我干活、关心我的睡眠、理解我的梗，早上准备好报告等我起床。"这种交互方式天然就是聊天，不是打开一个App。——by @velvet shark，1月25日 支持"多窗口多agent，不是一个万能agent" Ryan Seamons第一周就给家庭每个成员配了不同的bot——这是最原始的"每人一个窗口"实践。——by @ryanseamons，1月25日 Rahul Singh的Lead Agent "Supaclaw"抓取了Postiz的API文档，从零构建了一个专门管社媒的子agent。这就是"大总管派活给专业agent"的模式。——by @rahul singh07，2月14日 Casey Sapp的方法论把多agent分成明确的角色：Scout（数据采集）、Engine（推理）、Editor（润色）、Judge（质量把关），不同角色用不同模型。他特别强调"最后一个模型必须最擅长说'我不知道'"。——by @CaseySapp，2月22日 Greg Isenberg的商业框架——"OpenClaw是wrapper，Claude Code是工厂，sub agent/skill是劳动力，垂直bundle是产品"——本质上就是多agent分工。——by @gregisenberg，2月18日 第五周集中出现的ClawWork、Duet、Agify、TinkerClaw Recipes全都在解决multi agent管理的问题，说明"多agent怎么协同"已经成了社区最迫切的需求。 支持"统一记忆是关键短板" Suhail Balhatlani做的Mnemo试图解决跨工具记忆——把Cursor、Claude Code、Gemini CLI等10多个工具的聊天记录统一索引到本地SQLite。但这还只是"归档"层面的统一，不是"实时共享"。——by @sbalhatlani，2月22日 中国开发者社区自建的Memory System 2.0走得更远一步，做了持久记忆架构。这不是OpenClaw官方功能，是社区等不及自己造的——说明记忆是真刚需。 OpenClaw v2026.2.9专门修了一个bug：compaction之后agent会失忆。连单个agent的记忆持久化都还在修，多agent之间的记忆共享难度可想而知。 Machina（@EXM7777）说得很准确："真正的价值在于本地运行+持续记忆+主动推送"——他把记忆列为三大核心价值之一，和运行方式、交互方式并列。 不支持我的观点的案例——也值得看 "嵌入聊天"不代表好用。 Will Cheung对比了OpenClaw和Manus，结论是OpenClaw复杂很多："OpenClaw像自建房，Manus像精装房。"他还发现OpenClaw做简单查询要5 10分钟延迟，Manus几乎即时。"聊天窗口"形态的易用性天然受限于底层配置的复杂度。——by @willcheung，2月14日 大多数人根本用不了。 OpenClaw维护者Shadow自己在Discord上说过："if you can't understand how to run a command line, this is far too dangerous for you to use."（如果你连命令行都不会，这个项目对你来说太危险了。）这直接质疑了"聊天窗口降低门槛"这个假设——形态上是聊天窗口没错，但背后的搭建和维护门槛很高。 Agent可能超越屏幕。 Irvin的ROSClaw把agent接入了机器人操作系统，Vitto Rivabella给agent造了物理身体。这些案例指向一个方向：agent最终可能不住在任何屏幕上的"窗口"里，而是存在于物理空间中。当然这离主流还很远，但它提醒我们，"聊天窗口"可能只是agent形态的一个阶段，不是终局。 1、不是独立App，是嵌入在你常用的聊天软件（目前最优解是Telegram）里的对话窗口 2、不是一个万能agent，是多个专注不同领域的agent，各有自己的窗口 3、需要一个大总管agent负责调配和维护统一记忆 4、主动汇报比被动聊天重要——每天早上你打开Telegram，每个agent已经把简报发过来了，你扫一遍就行 5、记忆共享是当前最大的技术短板，Mnemo和Memory System 2.0是早期尝试 6、现阶段能真正用起来的是少数个人创业者，企业市场还需要合规层的成熟 OpenClaw的贡献是证明了"agent住在聊天软件里"这个方向是对的。接下来要解决的是怎么从"一个agent一个窗口"进化到"多个agent协同工作"，以及记忆怎么在它们之间流动。这两个问题谁先解决好，谁就拿下下一阶段。 附：支持和反对这个观点的案例 上面是我的判断。下面是从83条推文和132个用例里找到的支撑材料，也包括跟我观点矛盾的案例——放在一起看更完整。 支持"agent应该在聊天软件里，不是独立App" René Schulte让agent "Dave"通过WhatsApp从零建了一个完整网站——没用IDE、没push过git，全程聊天完成。他的原话是"no IDE, no git push, just chat"。这说明聊天界面不只是"方便"，它本身就能承载复杂的生产力工作。——by @rschu，2月16日 James Steinberg说"我就想用手机远程控制Codex和Claude Code"，最后用VNC方案解决。他真正的需求不是VNC，是"在我已经在用的工具里，随时随地控制agent"。——by @DareFailed，2月22日 Contabo的部署教程有个细节值得注意：他们建议agent跑在VPS而不是Mac Mini上，因为"Mac mini会离线，VPS不会"。但如果agent通过Telegram跟你通信，Telegram本身就是永远在线的——设备离不离线不影响你跟agent的对话。 Radek Sienkiewicz的描述很有画面感："它替我干活、关心我的睡眠、理解我的梗，早上准备好报告等我起床。"这种交互方式天然就是聊天，不是打开一个App。——by @velvet shark，1月25日 支持"多窗口多agent，不是一个万能agent" Ryan Seamons第一周就给家庭每个成员配了不同的bot——这是最原始的"每人一个窗口"实践。——by @ryanseamons，1月25日 Rahul Singh的Lead Agent "Supaclaw"抓取了Postiz的API文档，从零构建了一个专门管社媒的子agent。这就是"大总管派活给专业agent"的模式。——by @rahul singh07，2月14日 Casey Sapp的方法论把多agent分成明确的角色：Scout（数据采集）、Engine（推理）、Editor（润色）、Judge（质量把关），不同角色用不同模型。他特别强调"最后一个模型必须最擅长说'我不知道'"。——by @CaseySapp，2月22日 Greg Isenberg的商业框架——"OpenClaw是wrapper，Claude Code是工厂，sub agent/skill是劳动力，垂直bundle是产品"——本质上就是多agent分工。——by @gregisenberg，2月18日 第五周集中出现的ClawWork、Duet、Agify、TinkerClaw Recipes全都在解决multi agent管理的问题，说明"多agent怎么协同"已经成了社区最迫切的需求。 支持"统一记忆是关键短板" Suhail Balhatlani做的Mnemo试图解决跨工具记忆——把Cursor、Claude Code、Gemini CLI等10多个工具的聊天记录统一索引到本地SQLite。但这还只是"归档"层面的统一，不是"实时共享"。——by @sbalhatlani，2月22日 中国开发者社区自建的Memory System 2.0走得更远一步，做了持久记忆架构。这不是OpenClaw官方功能，是社区等不及自己造的——说明记忆是真刚需。 OpenClaw v2026.2.9专门修了一个bug：compaction之后agent会失忆。连单个agent的记忆持久化都还在修，多agent之间的记忆共享难度可想而知。 Machina（@EXM7777）说得很准确："真正的价值在于本地运行+持续记忆+主动推送"——他把记忆列为三大核心价值之一，和运行方式、交互方式并列。 不支持我的观点的案例——也值得看 "嵌入聊天"不代表好用。 Will Cheung对比了OpenClaw和Manus，结论是OpenClaw复杂很多："OpenClaw像自建房，Manus像精装房。"他还发现OpenClaw做简单查询要5 10分钟延迟，Manus几乎即时。"聊天窗口"形态的易用性天然受限于底层配置的复杂度。——by @willcheung，2月14日 大多数人根本用不了。 OpenClaw维护者Shadow自己在Discord上说过："if you can't understand how to run a command line, this is far too dangerous for you to use."（如果你连命令行都不会，这个项目对你来说太危险了。）这直接质疑了"聊天窗口降低门槛"这个假设——形态上是聊天窗口没错，但背后的搭建和维护门槛很高。 Agent可能超越屏幕。 Irvin的ROSClaw把agent接入了机器人操作系统，Vitto Rivabella给agent造了物理身体。这些案例指向一个方向：agent最终可能不住在任何屏幕上的"窗口"里，而是存在于物理空间中。当然这离主流还很远，但它提醒我们，"聊天窗口"可能只是agent形态的一个阶段，不是终局。 🔗 原文链接： https://mp.weixin.qq.com/s/qtgASw0o... https://mp.weixin.qq.com/s/qtgASw0o... 原创 郎瀚威 Will 郎瀚威 Will 郎瀚威 Will2026年2月25日 18:52 美国 过去几周我翻了83条推文、132个用例，跟踪了OpenClaw从一个周末项目变成GitHub第二大开源项目的全过程。关于用户拿它做什么、需求怎么变化，我在之前的文章里写过了。这篇聊一个不同的问题：OpenClaw现在这个形态，到底对不对？ 我的判断是：方向对了，但形态还没到位。 分为两步，第一步，第二步。我们今天讲第一步。 我自己接了各家API都简单测了下： agent不应该是一个App 先说一个观察：OpenClaw用户讨论最多的不是"我用它做了什么炫酷的事"，而是"我在哪里跟它说话"。 翻完这些案例你会发现，绝大多数活跃用户选择的界面是Telegram，其次是WhatsApp和Discord。几乎没有人在用OpenClaw自带的Web UI作为主要交互界面。 这不是偶然的。 Manus过去的路线是做一个独立App——你打开它，告诉它做事，它做完了你关掉。这个交互模式跟ChatGPT没有本质区别，还是"你去找AI"。（现在也有龙虾了） OpenClaw走了另一条路：agent住在你已经在用的聊天软件里。你不需要"打开"它，它就在你的Telegram对话列表里，跟你的朋友、家人、同事的对话窗口并列。你想跟它说话，点一下就行，跟给朋友发消息没区别。 这个设计选择看起来很小，但它决定了一件事：你跟agent交互的频率。 一个需要单独打开的App，你一天打开几次？可能三五次。一个在你聊天列表里的对话窗口，你一天点进去几次？可能二三十次。交互频率上去了，agent对你的了解就上去了，它能做的事也就多了。 所以我的第一个判断是：agent的正确形态不是一个独立App，而是嵌入在你已经常驻的通讯工具里。目前来看，对个人用户最合理的载体就是Telegram——开放的bot API、全平台覆盖、消息格式灵活、全球用户基础。 多个窗口，不是一个窗口 但光"在Telegram里"还不够。 现在大多数人的OpenClaw用法是：一个agent，一个对话窗口，什么都跟它说。邮件的事、日程的事、代码的事、买东西的事，全在一个窗口里。 这会出问题。 第一，上下文会乱。你跟它聊了半天代码bug，突然切到"帮我查一下明天的航班"，agent需要做一次心理切换。模型能处理，但效果不如专注在一个领域里好。 第二，记忆会炸。一个窗口承载所有领域的对话，记忆系统（不管是持久记忆还是context window）都会被稀释。真正重要的信息淹没在大量日常闲聊里。 第三，不符合人的思维习惯。你在公司里不会跟同一个人同时聊代码、聊行政、聊客户。你会找不同的人。 所以更合理的形态是：Telegram里有多个agent对话窗口，每个agent负责一个领域。一个管邮件，一个管开发，一个管日程，一个管内容。就像你的聊天列表里有不同的同事，各管一摊事。 这个方向其实已经有人在做了。Ryan Seamons在第一周就给家庭每个成员配了不同的bot。Kieran在跑三个agent swarm三班倒。Ziwen搭了10个agent组成的"AI公司"，每个agent有名字有分工。这些都是"多窗口"思路的早期实践。 但多窗口需要一个大总管 多个agent各管一摊，马上会遇到一个问题：它们之间怎么协调？ 你跟"邮件agent"说了一件事，"日程agent"不知道。你跟"开发agent"讨论了一个决策，"内容agent"写文章的时候用不上这个信息。 所以多agent架构里一定需要一个"大总管"——一个supervisor agent，负责两件事： 1、调配：你说一句话，大总管判断这事该分给谁，或者需要哪几个agent协作完成。Casey Sapp的方法论其实就是这个思路——Scout采集、Engine推理、Editor润色、Judge把关，每个角色对应不同的agent或模型。 2、统一记忆：所有agent共享一层底层记忆。 你告诉任何一个agent的信息，其他agent都能访问到。这样你不用重复跟每个agent说"我是做什么的、我的偏好是什么、上次讨论到哪了"。 记忆这块目前是最大的短板。 Mnemo在做跨工具的记忆统一（把Cursor、Claude Code、Gemini CLI的聊天记录索引到一个本地SQLite），中国社区自建了Memory System 2.0。但这些都还在很早期，离"多个agent无缝共享上下文"还有距离。 fomomofosol的案例很能说明问题：他的agent观察到他重度使用Notion，自己决定把dashboard迁过去。这个行为之所以惊艳，是因为agent做到了"跨上下文理解"——它不只是执行当前对话里的指令，而是综合了对用户习惯的长期观察。如果多个agent都能做到这一点，而且彼此共享这些观察，那才是真正的"AI团队"。 主动汇报比被动聊天更重要 前面说的"多窗口"还是一个"你去找agent"的逻辑——你点进邮件agent的窗口，问它今天有什么重要邮件。但更好的方式是反过来：每天早上你打开Telegram，每个agent已经主动给你发了一条消息。 邮件agent告诉你："昨晚收到3封需要回复的邮件，其中1封是客户催款，我已经起草了回复，你确认一下。" 开发agent告诉你："CI昨晚跑失败了，我查了日志是依赖版本问题，已经提了PR，等你review。" 内容agent告诉你："今天有两个选题跟你的领域相关，我准备了草稿大纲，下午发布来得及。" 你不需要挨个点进去问"有什么新情况"。你起床，Telegram里已经有一排未读消息，每条都是一个agent的简报。你扫一遍，该确认的确认，该忽略的忽略，5分钟搞定。 这比你打开一个App、输入指令、等回复的效率高一个量级。 Radek Sienkiewicz在第一周就体验到了这个："它替我干活、关心我的睡眠，早上准备好完整报告等我起床。"Jesse Leimgruber说得更直接："如果你还在给OpenClaw下指令，那你没搞懂重点。"J.B.的内容agent每天7点自动扫描热门话题、分析互动模式、起草内容选项——他只需要审批，不需要发起对话。 所以"多窗口"不只是让你有地方跟不同agent聊天，更重要的是让每个agent有一个固定的地方来给你汇报。窗口的意义不是"你去找它"，是"它来找你，而且你知道在哪里看"。 Manus那种界面不是没用，但它是后台面板，不是主界面 有人会问：那Manus、Claude Code这种独立界面就没有存在的价值了？ 有。但它的定位应该变一下。 你想想日常工作的逻辑：你跟同事聊天在微信/Slack里，但调整公司的CRM设置、改项目管理面板、配置服务器参数，你会去登录一个后台系统。这两种界面不是互斥的，而是不同场景。 同样的道理，agent的日常交互——对话、下指令、接收汇报——应该发生在聊天窗口里。但agent的配置和维护——调整记忆规则、修改技能模块、设置权限边界、查看运行日志——需要一个专门的操作面板。 Manus或者类似的独立界面完全可以承担这个角色：一个你偶尔登录一次的维护面板（panel），用来调整那些不需要每天碰的设置。比如： 这个agent的记忆范围是什么？哪些上下文可以跨agent共享？ 哪些操作需要我确认，哪些可以直接执行？ 各agent之间的调配规则怎么设？ 运行成本多少，哪里可以优化？ 你不会每天去调这些东西，就像你不会每天去改CRM的字段设置一样。但你需要一个地方能改。 所以结论不是"Manus没用"，而是Manus这种界面的定位应该从"主要交互入口"变成"后台维护面板"。用户的主战场在聊天窗口里，操作台在后面。 对创业者来说，没做完的地方就是机会 上面说了这么多"应该长什么样"，反过来看，现在还没做到的部分就是创业机会。对照一下： 1、Telegram原生的multi agent管理层。 现在要在Telegram里跑多个agent，你得自己部署多个OpenClaw实例，手动配置各自的SOUL.md和技能，手动处理它们之间的通信。没有一个产品把这件事做成"开箱即用"。谁先做出来"一键在Telegram里创建一组协同agent"的产品，谁就拿到第一波用户。 2、大总管调配层。 Casey Sapp的Scout/Engine/Editor/Judge方法论是对的，但现在全靠手动编排。需要一个中间层产品，能根据用户的消息自动判断该分给哪个agent，或者需要哪几个agent协作。Greg Isenberg说的"wrapper"就是这个东西，但目前还没有好用的实现。 3、跨agent统一记忆。 Mnemo在做跨工具记忆归档，但不是实时共享。Memory System 2.0方向对了但还在早期。这一层谁做好，谁就成为多agent架构的基础设施。记忆层的价值在于：用户只需要说一次"我是做XX的，我的偏好是XX"，所有agent都知道。 4、维护面板（Panel）。 前面说的那个"后台操作台"——配置记忆、调整权限、设定调配规则、监控成本。现在这些要么靠命令行，要么靠改配置文件。做成一个可视化面板，让不会写代码的人也能管理自己的agent团队，这是Manus类产品真正应该去的方向。 5、企业合规封装。 个人用户可以接受agent偶尔犯错，企业不行。把OpenClaw的能力封装成带权限管理、审计日志、SOC 2认证的企业产品，这条路Knolli和Lindy已经在走，但远没有跑通。 这五个方向有一个共同特点：都不是在做"一个更好的agent"，而是在做"让agent协同工作的基础设施"。单个agent的能力已经够用了，缺的是让多个agent像一个团队一样运转的管道、调配和治理层。 但先泼盆冷水 方向说完了，说说现实。以下是我的一些观察和判断 第一， 安全现阶段不是2C获客属性。 现在很多OpenClaw生态的创业项目主打"更安全的agent"——NanoClaw、ZeroClaw都是这个定位。但安全是门槛，不是钩子。用户不会因为"这个agent更安全"而买单，但会因为"不安全"而离开。对创业者来说，企业端的资金和安全这块，大概率还是大公司在主导。创业者要想的是怎么破局，怎么把流量和热度先搞明白，这比堆安全功能重要。除非你是做2b，那么可以参考yc几个公司怎么玩的。 第二， 这波创业者几乎都是有积累的人，不是从零开始的。 Daniel Foch能用agent跑房地产CRM是因为他本来就懂房地产流程，Greg Isenberg能提出"boring industry+agent"框架是因为他做过很多垂直SaaS。我目前没看到这一波里有从0到1特别牛的新人。都是之前融了一两轮、有行业认知的人在吃这波红利。如果你什么积累都没有就想进场，要想清楚自己的认知差在哪。 第三， 整个链路都是坑。 产品底层架构、安全性、收费支付、登录用户权限、大模型检查、宣发（联系大V）、老用户社群——所有能助力产品的环节，反过来看全是没做完的。这有点像出海，如果没踩过这些坑，即使有好想法，速度也不够快。有些钱不是创业者能快速赚的，没有那个资源，很多人看不明白，结果就永远跟不上套。 最后一句话：不管形态判断多正确、创业方向多清晰，到用户手上没有一个产品用不起来，一切都白玩。创业者应先把基本功夯实，把市场解读透彻，然后快速开发一个版本出来。 现阶段能用的人很少 说完理想形态，说说现实。 对个人用户来说，"Telegram里开几个agent窗口，各管一摊事"这个方案现在就能跑。不需要什么特殊架构，就是多部署几个OpenClaw实例，配不同的SOUL.md和技能，连到不同的Telegram bot上。成本是主要门槛——每个agent每月100 300美元的API费用，开三四个就是小一千美元/月。Daniel Foch算过账，对他的房地产业务来说替代人力还是划算的，但对普通个人用户来说这个数字不低。 对团队和企业来说，目前基本不现实。原因不是技术，是管理和合规： 谁来决定agent的权限边界？agent之间共享的记忆里如果包含敏感信息怎么办？agent做了错误决策谁负责？WIRED的安全警告和HuggingFace 58.9%的审计评分不是闹着玩的——agent在明确任务上表现可靠，但在理解意图上还是0%。 所以现阶段真正能把多agent跑起来的，是一小群技术能力强、风险承受力高、业务场景明确的个人创业者。像Daniel Foch（房地产CRM）、Ziwen（10 agent公司）、Presh Kumar（创业邮件自动化）这样的人。他们的共同特点是：自己就是老板，自己能承担风险，业务流程足够清晰到可以交给agent。 企业市场要等Knolli（结构化权限+SOC 2方向）、Lindy（零配置+HIPAA）这类产品把合规和管理层解决了，才会真正打开。 总结一下 我认为AI agent的正确形态是：