深夜刷到一条动态，OpenClaw又被顶上了热榜。这个被国内开发者昵称为“小龙虾”的开源Agent项目，最近在PanelAI的开发者社群里引发了一场异常激烈的深夜讨论。起因很简单，有开发者用同一个模型驱动不同Agent，一个接入了大量本地数据，另一个纯靠模型裸奔，跑出来的效果天差地别。于是争论的焦点集中在一个问题上：当大模型能力已经足够强的时候，AI Agent真正缺的那块拼图到底是什么——是更强的模型，还是更懂你的个人数据？
这场讨论从晚上十点持续到凌晨三点，参与的人有做RAG基础设施的、有做Agent框架的、有在企业里落地的，也有刚入门的学生。大家观点针锋相对，但也达成了不少共识。今天我把那晚的核心观点和碰撞过程整理出来，结合我自己实际调Agent的经验，聊聊我对这个问题的看法。
1. “小龙虾”为什么突然就火了
1.1 OpenClaw是什么，为什么被叫小龙虾
先说清楚这个项目本身。OpenClaw在GitHub上是一个开源的AI Agent执行框架，官方定位是“让模型能像人一样操作电脑和手机”。它能接管你的浏览器、命令行、文件系统，甚至能模拟键盘鼠标操作GUI应用。简单说，它把“模型说话”变成了“模型动手”。
至于“小龙虾”这个外号，纯粹是谐音梗——OpenClaw的发音听起来很像“小龙虾”的英文口音版，加上Claw本身有“钳子”的意思，跟小龙虾的钳子形象也对得上，国内开发者圈子里就这么叫开了。
真正让它火的不是谐音梗，而是它的几个特性：完全开源可自部署、支持多模型后端、内置了一套便捷的工具调用协议，还有非常活跃的社区。在当前的Agent生态里，像这样把“模型能力、工具编排、数据接入”都揉在一个工程框架里的项目，确实不多。
1.2 刷屏的导火索：同一个模型，天差地别的表现
引发那场讨论的具体事件是这样：某位开发者在社群里分享了他的对比实验。他用同一个大模型API，跑两个Agent实例，一个完全零配置，另一个接入了他的笔记库、浏览器历史、本地文件索引和日程数据。同样的任务——“帮我整理一下最近一周的项目进展，并生成周报”——两个Agent的表现几乎像两个不同水平的实习生。
裸奔的那个Agent能写出一份结构工整但空洞的周报，里面全是通用模板语言，完全没有他手头项目的具体信息。接了数据那个Agent不仅知道他最近在推进哪些模块，连他习惯用的术语、之前踩过哪些坑都记得，写出来的周报像是了解他工作状态的人写的。
这条对比动态一下就炸了。因为“用同一个模型”这个条件，把模型能力的变量给控制住了，剩下的差异只能来自数据。于是争论立刻分成了两派。
2. 模型能力派：Agent的天花板，写在模型的权重里
2.1 核心逻辑：没有聪明的模型，数据只是死资料
主张“模型能力才是终极拼图”的开发者，逻辑链条非常清晰：Agent本质上是一个决策系统，模型的推理能力、规划能力、工具调用能力决定了这个决策系统的上限。数据只是“原料”，如果你的“加工引擎”不够强，再好的原料也做不出好菜。
他们在讨论里举了不少反例。比如有开发者测试过一个很小的模型做Agent，即使把本地文档、知识库全接进去，它依然会在复杂任务上翻车——遇到多步骤任务时容易中途迷失方向，调用工具时经常传错参数，做完一步就忘了下一步。这跟数据多少没有关系，是模型本身的规划能力不够。认知科学里有个类比很贴切：短期记忆受损的人，你给他贴再多便利贴，他也无法完成需要临时规划的多步任务。
2.2 支撑论点的几个技术维度
模型能力派强调的主要是这几个维度：
- 长上下文与信息聚焦：Agent要理解用户的历史行为、偏好、项目背景，就需要在上下文中容纳足够多的信息。但上下文窗口变大之后，模型的“注意力”能不能精准聚焦在关键信息上，这本身就是一个模型能力问题。塞进去2万行日志，模型分不清哪些是核心矛盾，照样白搭。
- 规划与纠错能力：一个真实任务往往包含十几个子步骤，模型需要动态生成计划、执行、看结果、调整。这种“干一步看一步”的能力，在技术社区里常被叫作Agent的“执行力”。模型如果只会直来直去，数据接得再全也跑不出复杂的业务闭环。
- 工具调用的可靠度：Agent要操作浏览器、查数据库、发请求，每一步都是工具调用。小模型经常出现参数幻觉——对话里说的是对的，真发出去的函数参数却是错的。这种基础能力的缺陷，靠数据完全补不上。
2.3 他们反驳数据派的一句话
讨论中模型能力派说得最狠的一句话是：“数据解决的是‘做什么’的问题，模型解决的是‘怎么做到’的问题。你把菜谱背得滚瓜烂熟，但手不听使唤，照样做不出菜。”这个类比在现场赢得了一片认同。
不过我也注意到一个细节：持这个观点的人，多数是做模型评测、框架开发的技术背景，他们平时接触的Agent任务普遍偏复杂，对推理能力的要求极高。他们的立场，多少是被自己的工作场景塑造的。
3. 数据派的反击：没有记忆的Agent，只是个聪明的金鱼
3.1 核心逻辑：模型是公用的，数据才是私有的
数据派的论点同样扎实。他们的核心逻辑是：大模型能力再强，也是所有人都能调用的公共资源，你用GPT，别人也用GPT，模型本身不构成壁垒。真正拉开差距的是“谁拥有更完整、更干净、更结构化的个人数据”。
他们用了一个很好的比喻：同样请一个名校毕业生来家里做助理，你只给他一张白纸，他能做的是标准动作；你给他一本详细的家庭档案、生活偏好、历史账目，他才能做到“懂你”。模型是那个名校毕业生，而个人数据就是那本家庭档案。Agent竞争的终极战场，不是谁的毕业生更聪明，而是谁的档案更厚。
3.2 数据到底在Agent里扮演什么角色
从工程角度拆开看，数据在Agent系统里至少承担了三层角色：
- 长期记忆层：用户的偏好、习惯、历史决策，需要以结构化的方式持久化存储。Session一断就什么都记不得的Agent，交互体验会大打折扣。
- 情境感知层：当下的环境信息，比如正在看的网页、日历上的安排、当前的地理位置。没有这一层，Agent就像一个眼睛被蒙住的人，再聪明也使不上劲。
- 领域知识层：针对特定领域（法律、医疗、编程、投资）的专业知识库。模型训练时学到的通识知识是有限的，真正专业的信息要靠外部注入。
有做RAG方向的朋友在讨论里分享了一个数据：在同样的模型条件下，接了高质量知识库的Agent，在特定领域任务上的准确率能提升30%以上。这不是个例，是普遍现象。
3.3 隐私与数据权属，数据派手里的另一张牌
数据派还有一个很有力的论点：数据不仅仅是“效果问题”，还是“所有权问题”。你用公共大模型API跑的Agent，交互数据最终都会沉淀给模型服务商；而本地部署的Agent配合个人数据，数据主权牢牢握在自己手里。对于企业场景来说，数据安全合规往往是比效果更刚性的需求。
她说：“企业客户不在乎你的Agent用的是90分的模型还是85分的模型，但非常在乎他们的客户数据、财务数据、供应链数据会不会因为Agent调用而外泄。本地部署+私有数据，有时候是入场门票，效果反而是之后才讨论的事。”这段话引发了讨论里相当大范围的共鸣。
4. 实操视角：Agent要落地，真正的瓶颈其实在工程衔接
4.1 模型和数据不是二选一，而是上下层关系
争论到后半夜，双方的火气慢慢消了，开始有人做技术拆解。一位做Agent框架的资深开发者画了一个分层结构，我觉得非常清晰：
- 底层是模型能力：负责理解、推理、规划、生成。这个层面决定Agent智商的下限。
- 中间层是数据管线：负责把个人数据做清洗、切片、向量化、存储、检索。这个层面决定Agent能调用多少“私有知识”。
- 上层是工具层：负责把决策转化成真实动作，调浏览器、操作系统、外部API。
他问了一个关键问题：你们觉得现在Agent落地难，难在哪一层？答案是：每一层单独拿出来都有现成方案——模型可以选择、向量库有很多、自动化工具也不缺，真正难的是把这三层衔接成一个稳定、低延迟、可维护的系统。
这个观点一下子把争论带到了新的高度。原来双方争论“谁更重要”，但实际操作里，瓶颈既不在模型也不在数据，而是在“模型怎么优雅地使用手头的数据”，这需要一套优秀的工程框架来支撑。
4.2 让人沉默的实践真相：数据清洗比换模型更痛苦
现场有个做企业AI落地的开发者分享了自己的经历：他们团队做内部知识问答Agent，最初效果很差，团队第一反应是换更大的模型。结果换了三个模型，提升依然有限。后来他们花了两周时间做数据治理，把知识库里重复的文档去重、给缺失的字段补元数据、把PDF里的表格转成结构化的Markdown、修正了过时的流程文档，效果立刻上了一个台阶。
他语速不快，但每一句都砸在点上：“换模型是加钱，清洗数据是干活。大部分团队宁愿加钱，也不愿意干脏活。但真正让你家Agent和别家Agent拉开差距的，恰恰是那个没人愿意干的脏活。”
他个人的结论是：如果你的数据是干净的、结构化的、覆盖了关键场景的，那么模型能力的边际收益会递减；反之，如果你的数据一团乱麻，再大的模型也无从下手。这个结论在讨论中得到了最多的认同。
4.3 评测视角：为什么大家会吵架，因为评测标准本身就偏了
还有一个观点我觉得特别值得一提：这场争论之所以吵得不可开交，很可能是因为大家各自心里对“Agent到底该测什么”的标准不一样。模型能力派习惯用推理题、编程题、逻辑题来测Agent；数据派习惯在特定场景里看Agent能不能解决真实问题。
但真实世界的Agent评测，应该同时包含三个维度：通用智力、领域能力、个性化程度。一个只能答对逻辑题但完全不知道用户是谁的Agent，只能算“聪明却没用”；一个很懂用户但稍微复杂点的任务就卡壳的Agent，只能算“贴心但不顶事”。只有两个维度都过硬的Agent，才算真正意义上的可用产品。
5. 那场讨论之后，我自己的观察和踩过的坑
5.1 别迷信“最强模型”，也别迷信“无限数据”
作为一个实际调过Agent的人，两边极端的观点我都不太认同。我不认为存在一个“终极拼图”这样的单点答案，真实世界里做产品，模型和数据就像发动机和油箱，一辆车少了哪一个都跑不起来。
踩过的坑倒是可以说几个具体的。最开始我调Agent，花了很多功夫去优化prompt，希望让模型表现得更聪明，但很快发现靠prompt能榨出的提升是有限的。后来我开始接数据，又走入另一个极端——什么数据都往里塞，结果向量库臃肿不堪，检索时经常召回一堆无关内容，效果反而更差了。
这里要分享一个我比较得意的小操作：我在数据接入层加了一道“相关性过滤”，在把文档写入向量库之前，先用一个便宜的模型做一次预筛选——判断这篇文章跟用户的真实使用场景有没有关系，没有关系的直接不索引。这一步做完，召回准确率提升非常明显，代价只是一点点离线计算成本。
5.2 先想清楚场景，再谈模型和数据
另一个让我很受益的经验是：做Agent，第一件事不是选模型，也不是搭数据管道，而是想清楚“你这个Agent到底在什么场景里给谁用，那个场景最关键的任务长什么样”。如果你做的是客服Agent，那么知识库和话术沉淀可能比推理能力重要十倍；如果你做的是数据分析Agent，那么模型的代码生成能力和长上下文理解才是核心。
场景不同，“拼图”的组合方式就不同。有人需要大模型打底、数据锦上添花；有人需要数据做地基、模型在上面盖楼。谁也不是谁的终极答案，但“在正确的场景里用正确的方式组合它们”才是。
5.3 给正在做Agent的人几个建议
那天讨论到最后，大家互相交换了不少实操层面的建议，我自己也补充了几条：
- 先给Agent建立“记忆分层”：把短期session记忆、长期用户画像、领域知识库分成三层，不要混在一起存。这会大大降低后期的调试成本。
- 重视数据新鲜度：个人数据不是静态的，你的Agent如果一直用三个月前的用户画像，迟早会做出离谱决策。建议设置定期重算机制。
- 关注成本曲线：模型能力强的往往贵，数据接得多的往往存储和检索成本高。做产品的时候，要算清楚每增加一个能力的边际成本，别让一个Demo级Agent烧出生产环境的费用。
- 善用开源框架：像OpenClaw这样的开源项目，核心价值不在于它多聪明，而在于它把模型和数据之间的粘合层做好了，你不用从零开始造轮子。
那场深夜讨论其实没有分出胜负，最后大家默契地得出了一个更务实的结论：大模型能力是Agent的脑力，个人数据是Agent的记忆力和经验。缺了脑力，Agent无从思考；缺了记忆和经验，Agent无法真正为“你”服务。真正的高手，不会去争论哪个更重要，而是花时间把两者都打磨好，让它们在工程上完美地咬合在一起。
所以我个人现在看到“小龙虾”这类项目时，关注的既不是它的模型跑分，也不是它的数据接入数量，而是看它有没有把模型与数据之间的那个接缝处理得足够顺滑。模型在快速迭代，数据在你手中积累，而真正决定你Agent体验的，恰恰是这两者之间的那条窄窄的通道——这也是我接下来会重点研究的方向。
