硅谷坐标 x PingCAP联创黄东旭谈Agent 时代基础设施的重构
- 黄东旭判断 OpenClaw 标志着 AI-native 应用形态已经出现,但它只是“及格线”——“做得比 OpenClaw 差的属于上一个时代,未来只会比它更好”。 他家里不懂计算机的父母和太太都开始“养龙虾”,自己手握多个 Claude Code + Codex 的 Pro Max 账号,峰值日耗 token 达十亿量级,平日几亿,因而“很兴奋,同时也很焦虑”,有一种“被 agent team 推着往前跑”的感觉。
- Harness engineering 是继 prompt、context 之后的更高维度:多 agent 协同、子 agent 压缩管理、外挂记忆,本质“更像在管一个真正的开发团队”,只是“这帮 agent 不睡觉而已”。 他不认为 harness 有边界——benchmark 只测单 agent、单任务、单环境,“模型本身很聪明了,只是我们的题设计得不好”,未来甚至可能出现“agent 的社会学”。
- 本期最硬的价值判断:LLM 无状态,各家头部模型都聪明,“很多的价值其实会在记忆这一层,而不是大语言模型这一层”。 “它有多了解你呢?还是得靠记忆。”他的 Mem9 插件正解决龙虾“聊着聊着就忘了”的 compaction 失忆和升级丢数据两大痛点,提供开源自部署与云上托管的永久龙虾记忆服务。
- 反直觉的数据量判断:agent 时代不是中心化大数据,而是“海量的小数据”——“你跟小龙虾往死里聊,能聊出一本莎士比亚吗?” 但加总规模可能比淘宝、美团级的中心化数据更大,提供商的策略是全存:“永远不删数据,只要价值能 cover 存储成本”;当下存储短缺在他看来只是“产能临时短缺,会回归”,长期需求持续增加可以预期。
- “一虾一库”是必然趋势,且他认为记忆一定会在云端。 实现是数据库虚拟化:共享对象存储底座上划出虚拟门户,agent“认为自己拥有整个数据库”;因为重度用户可能只有 1%,不必为轻度用户维护专属基础设施。OpenClaw 的 local-first 是极客理念但“牺牲了用户体验”——龙虾养死“跟家里亲人去世的感觉很像”,云端才能“马上再给你启动一只龙虾的身体,接到你的记忆上又复活了”。
- 商业化押注“记忆 marketplace”:黄东旭赌下一代 agent-native application 不会像今天这样由软件工程师编写代码,而有可能由无数领域专家从自己的记忆里提取高价值的东西。 厨师不会写代码,但可把与龙虾聊做饭的记忆抽成外挂记忆接到别人 agent 上收钱,成为“一个新的分发渠道”;基础记忆可能免费,云备份、导入导出可做订阅制增值服务。
- Agent 基础设施会被整体重写——沙箱化的 agent 云、agent 邮箱、支付、权限和 ID 都值得重新设计,现有数据库“给几十亿 agent 提供,成本扛不住”——但 SQL 和文件系统作为模型的心智模型会长期存在。 独立向量数据库“不需要单独出现”:向量检索只是检索手段之一,会收敛为所有数据平台的标准能力。
- 组织形态可能变成部落:他一两人团队“过去三个月干了传统软件公司一百个人年的事”,公司 90% 的代码由 AI agent 编写,他不掌握具体代码细节,“上一个时代软件工程已经终结”,全职 coder 可能会很危险。 但这是软件民主化——这并不是像纺织女工一样让软件变少;正如衣服如今反而穿得更多,软件也可能更多。个人护城河方面,他给出的方向是“保持手感”;年轻人该学 Unix philosophy 这类“永恒不变的东西”。
1. OpenClaw 是“及格线”,从业者被 agent team 推着往前跑
- 黄东旭开场的体感证据:家里父母、太太这些“计算机背景不强的人”都开始“养龙虾”了——这标志 AI-native application 的产品形态已经出现。但 OpenClaw 只是及格线:“做得比它差的属于上一个时代,未来只会比它更好。”
- 他的用量本身是行业信号:多个 Claude Code + Codex 的 Pro Max 账号,峰值日耗 token 十亿量级,平日几亿。反馈闭环极快——“今天我有个想法,马上让 agent 去做,一个小时之后这个东西就上线了。”
- 新的心理状态:agent 会等着你,于是不断 push 自己“下一个想法在哪里”,持续进入想法—反馈—新想法的循环。“很兴奋,同时也很焦虑”——前沿实践 harness engineering 的资深工程师多少都有这种“被 agent team 推着往前跑的感觉”。
2. 从 prompt 到 context 到 harness:层层递进,且看不到边界
- 三代概念的分层:prompt engineering 是 few-shot、无外部工具调用的短程问答(2022 年底、2023 年初直到 2024 年);context engineering 是长程任务、工具调用结果分析、有限上下文空间的高效利用;harness engineering 再升一维——多 agent 协同,要把每个子 agent 的 compaction 考虑进去,并在其上构建信息同步、子任务管理、外挂记忆, “更像在管一个真正的开发团队”。
- 曹卿云问 harness 的边界在哪,答案坦率:“我没有感觉到现在有边界。每一次觉得快到边界了,agent 又能给我惊喜。”更深一层:他们甚至没办法评估当前 SOTA 模型——“模型本身很聪明了,只是我们的题设计得不好”,benchmark 还只测单 agent、单任务、单环境;人类靠组织变成社会,agent 也一样,“也许未来我们会发现一些 agent 的社会学”。
- 终局:harness 本质仍是软件工程,“一个好的 harness 就是一个好的软件工程”,跟管真人团队“没有太大区别,只是这帮 agent 不睡觉而已”。第一阶段用人类几十年的组织架构、工具和方法论做 bootstrap;第二阶段可能出现埃隆所说的递归自进化, “就会超出人类能理解的范围”。他相信各家会有自己的 harness,但“不会脱离传统团队管理和软件开发的 ground truth 太远,还是会收敛的”。
3. 记忆是 harness 最难也最值钱的一层
- Mem9 针对两个痛点:龙虾“聊着聊着就忘了前面的事”——长程任务里上下文一压缩就可能灾难性失忆;以及私密对话可能在一次升级中丢失。方案是开源可自部署+云上托管的永久龙虾记忆服务,安装体验是 agent-native 的:给龙虾复制粘贴一句话,软件就自动安装上去了。
- 概念区分用的比喻值得记:黄东旭把 context window 比作短期记忆,把 memory 比作笔记本——“好记性不如烂笔头”,检索出相关记忆再放回窗口。曹卿云补充认为,只要模型仍基于 Transformer,上下文窗口就是定值;他以开发大型系统软件可能需要几十万个步骤为例,说明外挂记忆的必要性。黄东旭不认可 RAG 作为完整概念:“跟具体的技术绑定得太紧”,因为今天的记忆已经超出原来 RAG 所代表的技术。
- 价值归属的核心命题:ChatGPT 强迫每个任务开新对话,只是用产品形态把记忆问题“掩盖过去了”;大语言模型无状态,“每家可能 top 1 的 model 都很聪明,但它有多了解你呢?”——“很多的价值其实会在记忆这一层,而不是大语言模型这一层。”
4. 设计哲学:把模型本身当评估函数
- 怎么记、怎么提取的答案出人意料地简单:更相信模型自己的能力。团队本想设计精妙的遗忘曲线算法,最终方案是——把相关信息检索出来,每条数据后加一个“这个事实离当前时间有多少天”的标签,全部丢给大模型,再加一句“根据你自己的判断,哪条是最重要的”。“我把模型本身的能力当成一个评估函数。”归纳总结、知识图谱的关联判断,同理全丢给模型。
- 由此推到极端的类比:“也许未来对 agent 最好的安全软件可能就是一句话:‘你要注意安全。’”传统编程逻辑不能直接套用到 agent-native 开发;他甚至认为 coding agent “可能会变成未来的操作系统内核”。
5. 反直觉的数据判断:“海量的小数据”,而且全都要存
- 数据库出身的量级直觉:全世界只有一个淘宝,背后是数百甚至上千 PB 的中心化数据;个人 agent 则相反——“你跟小龙虾往死里聊,能聊出一本莎士比亚这么长的话吗?”只要以文本语言交互,单体数据量就不大,这是他敢于说可以提供“无限记忆”的底气。
- 但对存储供给的含义是看多:海量小数据加总“可能会比中心化淘宝、美团的数据量更大”,只是碎片化到无数龙虾服务商。策略上“无论用户跟他的龙虾聊过什么,我作为提供商一定得存下来,这是对未来最宝贵的资源”——他认同 Google 的 philosophy:“永远不删数据”,只要价值 cover 存储成本;热、温、冷数据,结构化、非结构化数据,以及“人跟机器产生的所有 footprint”,都应该被存储下来。
- 为什么个人数据现在才值钱:过去无法千人千面,只能把所有人的数据汇集起来,给消费者打十个标签(白领、三线城市青年、老人);agent 时代“你的 agent 非常了解你,推荐非常精准,价值就非常高”。至于当下存储产能短缺,他判断“不是什么航天科技,只是产能临时短缺,会回归”,长期需求则会持续增加。
6. 一虾一库,且一定在云端
- “一虾一库”是必然趋势:每个人的记忆结构不同,安全是硬性限制——每个人的数据都应单独加密,个人密钥可能各不相同,“你不会愿意把你的记忆跟陌生人全放一起”。实现是数据库虚拟化:底层用云对象存储做大型共享存储,上面划出一个个虚拟门户,门户里的 agent 会认为自己拥有整个数据库。经济账是,重度用户可能只有 1%,不能为一天聊两三句的用户维护专属基础设施;对 agent 的正确抽象是“与其教它在存储服务上注册账号,不如直接告诉它:你现在看到的就是一个完整的数据库,随便用”。
- 云端 vs 本地,他给的是产品结论而非安全结论:OpenClaw 是 geek 设计的,Peter 是“一个特别极客的人”,理念是 local first——安全、没有云端“邪恶公司”控制数据,但“牺牲掉用户体验”,用户可能经常把龙虾养死,“跟家里亲人去世的感觉很像,很吓人”。如果要成为 C 端产品,他认为“一定是云端”:“龙虾养死了,但我的数据还备份着,马上再给你启动一只龙虾的身体,接到你的记忆上又复活了。”
7. 商业化:从备份订阅到“记忆 marketplace”
- 他首先提到的付费场景是记忆的备份恢复:基础记忆可能免费,导入导出、云备份可以做订阅制增值服务——“但它肯定不是企业级产品的定价模式”。
- 更大的赌注是记忆成为通用基础设施:他在赌下一代 agent-native application 的形态——不会像今天这样由软件工程师编写代码,而有可能由无数领域专家从记忆里提取高价值的东西,甚至可能只是“一堆 Markdown 文档”。厨师完全不会写代码、只会做饭,天天跟龙虾聊做饭,把这份记忆抽取成外挂记忆接到别人的 agent 上,通过 marketplace 收钱——“你就变成了一个新的分发渠道”。
8. 基础设施整体重写,但 SQL 与文件系统的心智模型长存
- 面向 agent 的基础设施一定会出现:今天的云、数据库、网络本质上面向开发者;agent 的云不会是 AWS、GCP、阿里云的现有形态,而可能是一个个沙箱——Manus 的形态相当于给 agent 一台小电脑,里面什么都有,agent 可以在里面工作。数据库的账算不过来:现在最便宜的库一个月也要几美元, “给几十亿 agent 提供,成本扛不住”,必须重写底层实现。同样逻辑套到通信(“谁在给 agent 提供邮箱服务?没有”)、支付、权限和 ID——都是值得重新设计、 “非常朝阳、同时又非常重要的事情”。
- 接口层却要保守:模型从人类数据训练而来,SQL 和 file system 是它最熟悉的操作计算机的心智模型——所以 Mem9 的记忆通过数据库接口提供,OpenClaw 原生记忆本身就是一堆 Markdown 文件。 “在 agent 自我进化出更符合自身使用方式的接口和形式之前,这些经典心智模型会长期存在,只是下面的实现不一样。”
- 对向量数据库的判断,他自称“有点极端”:向量检索只是若干检索手段之一(还有全文匹配、原始信息过滤),单独拆出来对 agent 不友好——“不需要单独出现一个向量数据库”,它会成为所有数据平台的标准能力,接口收敛;而在个人数据语境下,“多高的性能、多大的数据量其实没有什么意义”。
9. 好体验的判据是 Unix 哲学;多 agent 里可能藏着新 scaling law
- 给 agent 做软件怎么算好用?他的猜想是:“对开发者友好的体验,一样也会对 agent 友好。”GUI 不可组合——“两个图形界面的东西不能融合出第三个图形界面”,命令行可以;Unix 哲学最近又火,核心正是“方法论原则就那么几个,但通过组合能变出一个更大、更复杂的世界”,用一套简洁、自洽的心智模型囊括尽可能多的灵活任务。
- 下一个突破边界的猜想,明确标注为 open question:“我隐约觉得组织多个 agent 干复杂任务的过程中,会 somehow 存在一种 scaling law——放一百个、一千个、一万个进去,能产生什么效果?”
- 人与 agent 的协同只发生在最上层:提需求、验证交付结果、通过 skill 或 spec 传递经验;agent 怎么开会、怎么管理,“你可以给它一些点拨,但不要参与进去——你一旦参与进去,就变成整个系统的瓶颈了”。
10. 组织可能变成部落,护城河在于手感
- 他的实证:Mem9、DB9 都是一两人团队、他一人主力,“过去三个月干了传统软件公司一百个人年的事”。软件生产在黑盒化:公司 90% 的代码由 AI agent 编写,他每天数万行代码 check in,却“完全不知道 AI 写了什么”,不看具体代码细节,只管架构、软件工程和“代码不要快速腐化”等更上层的事——编程语言“既重要又不重要”。
- 对码农的判断直白但带有个人判断:“上一个时代的软件工程已经终结了,确实不需要这么多软件工程师了”;如果是全职 coder,“可能会挺危险”。未来组织可能是“一个个小型的部落”:强 harness engineer 带 agent team,配一个了解现实问题但不会编程、也不会做软件的领域专家。但这被他视为软件民主化的好现象,并不是像纺织女工一样让软件变少——正如衣服如今反而穿得更多,软件也可能更多。
- 他自己那句“细思恐极”的话——所有认知一个月后可能严重过时——的自答:“一定要身处这个浪潮之中,保持手感”;看科技文章或听类似今天这样的对话都不是最高效的学法,“最高效就是亲自去用”。给焦虑的计算机专业学生:学“永恒不变的东西”——Unix philosophy、经典软件工程、思维模型;“如果学计算机只是为了找一份码农的工作,你就得想一想你真正喜欢什么”。彩蛋由黄东旭推荐《禅与摩托车维修艺术》;曹卿云说自己看过无数遍。黄东旭认为这是一本让人认真思考“造物这件事情的本质是什么”、为什么享受把东西做好、什么是好东西的书。
Full transcript
Agent application 绝对不会像今天这样由软件工程师编写代码,而是有可能由无数领域专家从自己的记忆里提取出一些高价值的东西,变成一个所谓的 app。这个 app 可能是一堆 Markdown 文档,或者是一堆从你的记忆里提取出来的内容。
你最好的策略就是,无论用户跟他的龙虾或者 agent 聊过什么东西,作为提供商,我一定得把它存下来。这是对未来来说最宝贵的资源。
你觉得未来 AI 能力的下一个突破边界在哪里?
东旭,欢迎你来到《硅谷坐标》。今年整个硅谷科技迭代的速度非常快,你在第一线,肯定感受最强烈。想问问你,今年 OpenClaw 出来之后,你现在最大的感受是什么?
1. OpenClaw 定义 AI 原生应用
我举个简单的小例子吧。在我家里,我的父母,包括我太太,可能都不是计算机背景很强的人,现在已经都开始养龙虾了。
所以我觉得,这标志着一种 AI-native application 的产品形态已经出现了。但我觉得 OpenClaw 是一条及格线,做得比 OpenClaw 差的,那就属于上一个时代;未来只会比它更好。
所以我现在每天都非常兴奋。手上有好几个 Claude Code 加 Codex 的 Pro Max 账号,可能峰值时每天消耗的 token 在 10 亿这个量级左右;普通的日子里,也大概是几亿的规模。
我认为现在的 agent,或者说 coding agent,达到了一个能力边界。你会发现,很多想法得到反馈的速度非常快。比如今天我有个想法,马上让 agent 去做,可能 1 个小时之后这个东西就上线了。
这时候他们会等着你。我其实非常想避免 agent 等着我的状态,于是就会 push 自己:“我下一个想法在哪里?”然后持续进入这样一个循环:有新想法,得到反馈,再产生下一个想法。
所以我很兴奋,同时也很焦虑。我觉得现在处在最前沿、实践 harness engineering 的资深工程师,多多少少都会有我现在这样的状态。我不能称之为焦虑,但会有一种被 agent team 推着往前跑的感觉。
很有意思。前两年大家还在讲 prompt engineering,后来转成讲 context engineering,而现在所有头部、前沿的人都开始讲 harness engineering。
你先给大家介绍一下,AI 时代的 harness engineering 大概是一个什么样的概念?它跟前两代有什么不一样?
2. Harness Engineering 进入多 Agent 时代
Prompt engineering 我觉得有 2 个关键点。第一个关键点是 few-shot:在一个比较短程的对话里,通过调整对话上下文,得到一个及时的、更好的结果。第二个是,它基本上没有涉及外部工具调用,基本还是在一个问答流程里。
我觉得早期可能是 2022 年底、2023 年初,包括一直到 2024 年,都是在 prompt engineering 这个框架里面。
Context engineering 更多像是在一系列长程任务里,让 agent 把结果交付出来。刚才提到的 2 个关键点,一个是任务的长度变长、对话轮次变多;第二个是,它可能会涉及外部工具的调用,以及对调用结果的分析。最后,你还要考虑如何高效利用有限的上下文空间。
所以,context engineering 比 prompt engineering 又高一层。
Harness engineering 今天仍然是一个非常前沿的话题,但用我自己的理解来说,它可能又升高了一个维度。刚才不管是 prompt 还是 context,都是在一个对话流、一个 agent 或者一个大语言模型的窗口里;但 harness 今天强调的是多 agent 的协同。
比如在 context engineering 里面,有一个非常普遍的问题:当任务太长时,上下文窗口已经装不下之前的对话历史。这时候会引入一个技术叫 compaction,也就是压缩。压缩经常会伴随着灾难性的失忆。
所以在一个更复杂的 harness 环境里,你需要把每个子 agent 的上下文压缩都考虑进去。你必须在此之上构建一层信息同步、子任务管理,以及外挂记忆等东西。
对我来说,harness engineering 更像是在管理一个真正的开发团队,让他们在复杂的大型项目里持续、不断地产出。它其实是一个层层递进的关系,而且每一层都依赖上一层的一些最佳实践,并在其上封装出来。
你觉得 harness 的边界到哪里?
3. Harness 能力没有边界
说句实话,我没有感觉到现在有边界。每一次我觉得自己快到边界了,但 agent 又能够给我一些惊喜。
因为当你提到“边界”这个词时,就暗示它的能力可以被人类感知,或者说可以有一个明确的上限。我甚至觉得,有时候我们没有办法评估现在 SOTA 模型的能力。因为模型本身已经很聪明了,只是我们设计的题目不好,没有办法测出它真正的能力。
而且大多数 benchmark 还只是在单一 agent、单一任务和单一环境里的评分。但你想想,人类通过无数个个体的组织变成了社会,我们能够协同完成超出任何一个人能力边界的事情。
我相信 agent 也一样可以。所以也许未来我们会发现一些关于 agent 社会学之类的事情。那这时候还有什么边界吗?我觉得没有边界。
既然 harness 是一个系统级的工程,你觉得它未来有没有可能像数据库或者云平台一样,变成一个比较通用的产品?还是说,未来各家公司都会做自己的 harness?你觉得终局会是什么样子?
今天大家千万不要被 harness 这个词吓到。Harness engineering 对我来说仍然是 software engineering,一个好的 harness 就是一个好的软件工程。
我自己的体感是,我会给 agent team 设置不同的 role,这其实跟我以前管理由真人组成的软件工程团队没有太大区别,只是这帮 agent 不睡觉而已。
我觉得这是第一阶段。因为 agent 会产生什么样的组织形态,或者什么样的形态才是 agent-native 的,我们现在还不知道。我们现在知道的是,人类几十年积累下来的复杂软件开发组织架构、工具和方法论。这些东西可以用来做 bootstrap,让 agent 先协同起来,完成一些单个 agent 做不了的事情。
第二阶段,可能就会出现包括埃隆所说的递归自进化的 agent 工具或形态。如果进入递归自我优化的阶段,就会超出人类能够理解的范围。所以我们现在能做的,就是先把人类的经验映射过来,让它先完成第一步。
回到你刚才的问题,会不会每家公司都有一套自己的 harness?我相信会。但是各家不同 harness 的思想,我觉得不会脱离传统团队管理和软件开发的 ground truth 太远,它还是会收敛的。
最近你发布了 Mem9 的一个龙虾记忆插件,也在龙虾社区里引起了非常大的反响。你可以给我们介绍一下这个插件吗?
4. Mem9 解决龙虾失忆
其实这个插件解决的问题很简单。大家用小龙虾的时候,经常会发现它聊着聊着就忘了前面的事情。你想象一下,如果它在做一件重要的事,结果到最后一步把前面的内容忘了,其实是挺糟心的。我经常就有这样的体验,这是第一个痛点。
第二个痛点是,我跟我的小龙虾聊了非常多重要、私密、个人的东西。如果哪一天更新把它升级挂了,那岂不是很难过?所以,云端备份也是我一个特别大的需求。
基于这 2 个需求,就做了 Mem9。首先,它是一个开源项目,你可以自己部署。其次,Mem9 这条产品线也会提供云上托管的、永久的龙虾记忆服务。
我当时在设计 Mem9 的时候,一直在思考一个问题:如何设计 agent-native 的软件使用体验。比如以前安装软件,可能要配置 A、B、C、D,要下载安装包,再安装各种东西。但在 Mem9 里,你其实只需要给龙虾复制、粘贴一句话,软件就自动安装上去了。
可以跟大家解释一下,长上下文窗口,也就是 context window,和记忆 memory 的区别吗?
5. Memory 超越 Context Window
Context window 可以认为就是一个很小的窗口。这个窗口之外的东西,大语言模型在短时间的对话里是不知道的,它相当于短期记忆。
Memory 是什么呢?我用一个更形象的比喻:它像一个笔记本。这个笔记本可能记了非常多相关的事实,相当于你的长期记忆,但这个长期记忆不在你的脑子里,而是在一个小本子里。
当下我们要做一些事情时,如果发现要看的东西不在上下文窗口里,就会发现“好记性不如烂笔头”。我就要拿出 memory 这个笔记本,找到相关信息,以及这条信息相关的上下文,也就是这条具体的记忆,然后再把它放到短期的 context window 里。这样,大语言模型才能更了解我们在讨论什么上下文。
其实在过去,我们把这个东西叫 RAG。但我觉得 RAG 不是一个好的技术概念,因为今天我们再聊记忆时,已经超过了原来 RAG 所代表的技术。RAG 可能跟具体技术绑定得太紧了,但记忆是一个更大的话题。
以后多 agent 或者多步骤任务会让你的短期记忆窗口很快被填满。哪怕短期记忆窗口越来越大,甚至再大,也还是要长期解决长期记忆的问题。
是的。不管怎么样,只要现在的模型还是基于 Transformer 的模型,上下文窗口一定是个定值。哪怕做得再大,它也是个定值。
所以必须得有一个外挂记忆系统。我觉得人也一样,有短期记忆和长期记忆,因为我们的世界太复杂了,很多任务其实几乎可以无限长。
我举个例子:我要开发一个大型系统软件,可能需要几十万个步骤。短期语言模型的 context window 再长,也不可能把现实世界的复杂性都塞进一个固定窗口里。至少从 Transformer 的架构来看,一个外挂记忆系统可能还是必须的。
记忆为什么现在成了整个 harness 里面最困难的一环?
刚才我也提到了,单体 agent 一个重要的痛点就是:在长程任务过程中,只要上下文一压缩,它刚才在聊的事情就全忘了。所以在做这种关键的 harness 时,必须用外挂记忆解决单体 agent compaction 带来的问题。这就是为什么 memory 如此重要。
第二方面,不管是 ChatGPT,还是早期基于聊天机器人的形态,它不停地让你为每个任务强行开启一个新的对话。它并没有解决记忆问题,只是通过产品形态把问题掩盖过去了。但这种产品形态又会带来不好的用户体验。
再从重要性来说,大语言模型其实是没有状态的。它没有办法自主地持续跟你聊天,最后持续变强。真正有差异性的,其实是你跟它聊的内容,以及它自己在这些内容里的反思。
简单来说就是记忆。最后我觉得,很多价值其实会在记忆这一层,而不是大语言模型这一层。因为每家可能 top 1 的 model 都很聪明,但它有多了解你呢?还是得靠记忆去了解你。
记忆要解决 2 个问题:一个是这东西怎么记、什么东西需要记、什么东西不需要记;另外一个是怎么样提取这些信息。你们是怎么解决这个难题的?
这里面提到一个非常哲学的问题。我一向更相信模型自己的能力。
什么意思呢?比如记忆分为远期记忆和近期记忆,它们的重要性是不一样的。我们的开发人员经常会想设计一个精妙的算法,做一个遗忘曲线,超过多长时间就自动剔除,可能还要做一个很复杂的模型。
但你知道我最近最后怎么解决这个问题的吗?方式非常简单:我把相关信息检索出来,然后在数据后面加一个标签,这个标签表示这个事实距离当前时间有多少天。我把所有信息直接丢给大模型,再加一句:“请根据你自己的判断,判断哪条信息最重要。”
就是把模型本身的能力当成一个评估函数。今天我觉得开发软件的思路变了,变成了应该如何更好地利用模型本身的能力去做事情,因为模型一定有自己的判断。
另外一个例子可能是安全。现在大家经常会想,龙虾的安全应该怎么做?当然我不是做安全的,也许未来最好的 agent 安全软件可能就是一句话:“你要注意安全。”
明白了。
所以,怎么记、怎么提取这 2 个步骤,基本上都是让大模型自己发挥判断。
所以更多是通过 prompt 提示它,而不是通过算法来解决。
对。所以这也是为什么我觉得今天的 coding agent 可能会变成未来的操作系统内核,在上面能做很多事情。但传统编程的逻辑,不能直接套用到今天这种 agent-native 的软件开发上。
听起来好像就是以时间为标注,根据这件事情发生的时间距离当下有多远,然后由大模型自己判断这件事情是否重要。
是的,这只是一个很小的例子。其实我设计这套东西时,大量采用的都是类似方法。
比如这段话讲了什么、怎么归纳总结,我一定会丢给大模型帮我总结。比如我要构建知识图谱,我不会自己写一个程序去分析它们之间的关联,而是直接丢给模型,让它判断它们之间的关联是什么。
你提到的这种多 agent 协作的状态,对于龙虾来说,它需要记住的东西非常多。你知道它的记忆量增长是一个什么量级吗?
6. 海量个人数据重塑存储
我本身是做数据库出身的。目前这些 agent 在完成个人任务,甚至企业任务时,产生的数据量不会太大。比起我在 Web 2.0 时代接触到的那些互联网公司产生的数据量,一个 agent 要处理的数据简直太少了。
其实这有点反直觉。比如我用淘宝、用美团,全世界只有一个淘宝。淘宝背后的数据系统、存储系统要面临的数据量,可能都是以 PB 为单位计算的。1 PB 是 1,024 TB,淘宝可能是数百甚至上千 PB 的级别。
但当每个人都有自己的 agent 时,它不再是一个集中的大数据,而是高度碎片化的无数个小数据。我举个例子:现在你跟小龙虾天天聊,往死里聊,你能聊出一本莎士比亚的这么这么长的话吗?哪怕算上个人电脑上所有的文档,或者所有看过的书,加起来其实对于过去数据库这类软件的存储极限来说,也还差得非常远,所以都不是大数据。
今天 agent 使用数据的方式是海量的小数据。这就是为什么我敢于说,可以提供无限的记忆。因为我假设,一个人跟他的小龙虾一起产生的有价值对话和数据,在今天这种以语言模型为主的产品形态里不会太多。
哪怕以后有非常多 agent,执行非常多步骤的复杂任务,只要它们是以文本语言交互,数据量就不会太大。
因为我们现在也很关心,整个存储供应链都很短缺。你觉得 multi-agent 的趋势其实不会产生特别大的影响?
我觉得会产生影响,但这个影响是刚才提到的“海量的小数据”。海量小数据加起来其实也很大,未来加起来的数据量可能会比刚才说的中心化淘宝、中心化美团的数据量更大,只是它不再是一个集中的形态,而是可能有无数家提供龙虾服务的厂商,顺便提供记忆服务。
比如我们就属于提供记忆和存储服务的厂商之一。
最好的策略就是,无论用户跟他的龙虾或者 agent 聊过什么东西,作为提供商,我一定得存下来。这是对未来来说最宝贵的资源。所以今天大家可能就要开始布局,采购各种存储。
第二个方面,我觉得大语言模型以及今天的多模态模型,已经具备了初步能力,可以把很多非结构化数据变成结构化数据。这意味着它能产生价值。
对于一个服务提供商来说,我觉得对全社会而言,存储肯定还是重要的。我能理解为什么存储价格在涨,因为 agent 确实创造了更多产生数据的机会和场景。
比如热数据、温数据、冷数据,你觉得是不是全部都需要?
全都需要。结构化数据、非结构化数据也都需要。人和机器产生的所有 footprint、所有脚印,都应该被存储下来,因为这些东西都有价值。
哪些需要永久保留,哪些可能用一段时间就删掉?我很认同 Google 的一个 philosophy:我永远不删除数据。只要这些数据产生的价值能够 cover 它的存储成本,那你就应该都存下来。
怎么去衡量它的价值?
你问了一个非常好的问题。以前人没有办法去衡量个人数据这种非常零散的数据的价值,因为没有办法利用这些个人数据,所以不划算。
但今天不一样了。以前因为没有办法做到千人千面,只能把所有人的数据汇集在一起,用大数据做分析,比如给所有消费者打 10 个标签:这个是白领,那个是三线城市的青年,另一个是老人。
但你想象一下,在 agent 时代,你的 agent 会非常了解你。它知道你经常吃什么、最近对什么感兴趣。这时候再给你推荐东西,就会非常精准。它的价值是不是就非常高了?
只是以前没有办法利用,现在有了 AI、有了 agent,它一定可以利用上。
现在存储产能这么缺,你觉得未来有什么好的办法去解决吗?
我觉得这可能是短期供应链的波动。存储本身也不是什么航天科技,没有什么秘密,只是产能临时短缺。所以我觉得它会回归。
第二,长期来看,需求肯定会持续增加,也是可以预期的。
未来 AI 时代,我们需要怎样的存储范式?
其实刚才说到,这是一种海量个人小数据、灵活数据的范式。它不再是一个集中的、固定形态的数据,而是像每个人真正的记忆一样。
我未来会更看好这样的数据形态:数据库和数据形态不是给人做的,而是给 agent 做的。什么样的数据库或者数据平台,能够适合高度灵活、千人千面以及非常个人化的场景?
你刚刚提到“一虾一库”的概念,同时又提出来可以让很多虾共享一个存储空间,这个是怎么做到的?
“一虾一库”是一个必然的趋势,因为每个人自己的记忆结构跟另外一个人都是不一样的。
比如安全就是一个硬性限制。每个人的数据都应该用个人密钥加密,每个人的密钥可能都不一样。你不会愿意把自己的记忆跟陌生人的全部放在一起,对吧?你还是希望有一个属于自己的空间,你的龙虾也是这样。
我觉得一个好的机器系统,必须提供这样的能力。
第二个问题是,为什么要做 consolidate,也就是怎么提供这样的平台,给每个龙虾提供免费或者低成本的服务。
这里面有一些技术细节,但核心原理大概是:我对外提供一层数据库虚拟化,底层则基于云存储,用对象存储作为大型共享存储。
在上面,我可以针对不同用户划出一个个虚拟门户。每个门户里的 agent 都会认为自己拥有整个数据库,但底下其实是一个大型共享存储。
核心目标是节省成本。因为大多数时候,大多数人不会跟自己的 agent 天天聊天,重度用户可能只有 1%。你不能为了那些一天只聊两三句话的用户,维护一套专属基础设施,那是很不划算的。所以还是需要共享的一套基础设施。
为什么要这么设计?我觉得也是为了给 agent 提供一个更加易用、更容易理解的数据模型。与其教 agent“你要去存储服务上注册一个账号”,不如直接告诉它:“你现在看到的就是一个完整的数据库,随便用。”这样其实对 agent 更友好。
从数据安全的角度来说,你觉得以后这些记忆是存在云端、存在本地,还是采用混合方式?
我觉得一定是云端。这个结论不是从安全性得出的。
比如微信支付、我的银行账号和银行数据,你可以认为它们也都是在云端的。其实我觉得小龙虾的一个问题是,它是 geek 设计的。Peter 是一个特别极客的人,他的理念是 local first。
Local 确实很安全,也不会有一个云端的“邪恶公司”控制着你的数据。但它牺牲了什么?牺牲了用户体验。
如果你没有本地 debug 的能力,或者不了解这个系统是怎么开发的,你会发现自己经常把龙虾养死。比如你跟你的龙虾聊了 10 年,突然有一天升级时它说:“不好意思,我挂了。”你可能会有一种家里亲人去世的感觉,很吓人。
所以我觉得,从产品形态和体验的角度来说,如果它要变成一个 C 端产品,被更广泛地使用,就一定是云端的。只有在云端,才能提供通用、易用的用户体验。
比如龙虾养死了,但我的数据还备份着,我马上再给你启动一只龙虾的身体,把它接到你的记忆上,一下子又能复活。你不需要了解 Linux,也不需要了解如何在本地安装开发工具,所以一定是云端。
你觉得未来记忆层的商业化前景怎么样?它以后会被吸收成一种基础设施吗?从你看到的情况来说,用户付费意愿最强的场景是什么?
我觉得有几个场景。
第一个是机器的备份和恢复。大家都知道机器的价值,尤其是重度使用、跟龙虾一起工作时,机器的价值非常重要。
这里面有几种商业模式。一种是围绕服务本身的备份恢复等周边服务做增值服务。基础记忆本身可能免费,但如果需要导入导出,或者需要云端备份,就可以在上面设计订阅制的商业模式。不过它肯定不是企业级产品的定价模式。
第二种是我个人理想中的模式:memory 会变成真正通用的基础设施。因为我其实在赌,下一代 agent-native application 的形态,绝对不会像今天这样由软件工程师编写代码,而是有可能由无数领域专家从自己的记忆里提取高价值的东西。
比如我是一个厨师,我每天都跟我的小龙虾聊做饭。最后我可以把这个厨师的小龙虾脑子里关于做饭的记忆提取出来,变成一个外挂记忆。这个外挂记忆接到其他人的 agent 上,然后我通过 marketplace 收钱。
你想象一下,这个厨师可能完全不会写代码,他只会做饭。他一直跟自己的龙虾讨论做饭的内容,而我现在可以帮他把这些知识变现成一个可以付费购买的东西。这时候,你就变成了一个新的分发渠道。
我觉得这是基于记忆变现的一条很有意思的路径。
我们现在拉回去看整个 AI 时代的基础设施。你又是这个领域做数据库的专家,数据库是一个重要的基础设施。你觉得 AI 时代,整个基础设施会怎么样被重写?
7. AI 基础设施重新设计
第一点,面向 AI 的基础设施一定会出现。今天我们看到的云、数据库、网络,本质上它们的用户还是开发者。我们的基础设施或者生态链,都是围绕人构建的。
但我觉得在 agent 时代,围绕 agent 会有一套属于 agent 应用的基础设施。这件事今天已经正在发生。比如它一定会有给 agent 用的云,但给 agent 用的云,形态会跟今天看到的 AWS、GCP、阿里云完全不一样。
包括用过 Manus 的同学都知道,Manus 相当于给 agent 一台小电脑,电脑里面什么都有,agent 可以在里面工作。我们把这个环境称为 sandbox,也就是沙箱。
现在对于 agent 来说,因为每个任务都是特别的,所以 agent 的云可能提供的不是一个底层云平台,而是一个个小型沙箱,让 agent 在里面干活。
如果我是做 agent 的 AWS,我一定会提供这样的服务。
“一虾一库”是我们在 Mem9 这个产品里提出的理念。但想想,对于基础设施提供商来说,从来没有一家数据库公司敢这样卖。为什么?因为当我们提到给 agent 设计数据库时,可能有几百万、几千万个 agent 同时使用数据库。
现在的云和基础设施里,每个数据库最便宜可能一个月也得几美元。但当你要给几十亿个 agent 提供数据库时,这个成本是扛不住的。所以必须重新设计数据库底层实现,才能适应 agent 的使用方式。
同样的逻辑也可以套用在很多其他产品上。比如通信,人和人之间用电子邮箱通信。但 agent 不需要界面,而且 agent 应该会更高频地跟其他 agent 通信。
现在谁在给 agent 提供邮箱服务?没有。另外,支付、权限,或者说 ID,也都值得针对 agent 的场景重新设计一遍。这是一件非常朝阳、同时又非常重要的事情。
你怎么看待 SQL 和 file system 这样的经典抽象在 agent 时代的前景?
现在的 coding agent 也好,模型也好,都是从人类的数据里训练出来的。人类发明了 SQL,也发明了 file system。所以在 agent 背后的大语言模型脑子里,这些就是它们最熟悉的操作计算机的心智模型。
不管今天提供什么样的 agent-native 新基础设施,给 agent 使用的接口一定还是这些经典接口。这就是为什么我们提供记忆时,会通过数据库接口来实现存储。
因为 agent 最擅长写 SQL。比如 OpenClaw 原生的记忆系统就是一堆 Markdown 文件,大语言模型和 coding agent 也非常擅长操作文件系统。
所以我的结论是,至少在 agent 自我进化出更符合自身使用方式的接口和形式之前,这些经典心智模型会长期存在。只是这些心智模型下面的实现会不一样。
我们知道,这几年向量数据库非常火,但同时也看到一些现有玩家把向量能力加入了自己的产品。你觉得未来这些独立的向量数据库,终局会怎么样?
我的观点可能有点极端。刚才我提到,记忆检索会用到向量数据库的一些检索能力,但向量检索只是我若干个检索手段中的一个。
我不仅要做向量检索,还要做全文匹配,也要做原始信息过滤。其实我非常不赞同把向量数据库单独划分成一个独立的类别。它应该只是所有数据平台都提供的一项标准能力。
如果把它单独拆成一个独立的东西,对 agent 来说是不友好的。有些数据在这里,有些数据在那里,这时候想交叉做一些事情就会非常费劲。还不如把所有东西放在一起,提供一个更加自然的接口。
所以我的结论非常简单:大家都会有这个能力,不需要单独出现一个向量数据库。
所以你觉得,分布在各个地方的这些能力,未来还是会收敛?
对,它会收敛。对于每个 agent 的接口层来说会收敛,但它面向的数据量不会太多。
我一直在强调一个点,就是海量的个人数据。当处在个人数据的语境下,数据量其实不会太大。这时候所谓多高的性能、多大的数据量,其实没有什么意义,但接口一定是统一的。
还想问你一个问题:给 agent 用的软件,怎么样做才能让它更好用?
8. Agent 软件改变人类工作
这是一个很好的问题,也是研究的前沿。我觉得可能会出现一个新兴领域。
过去我们叫人体工学。开发者经常会给自己造一些工具,有些工具好用,有些不好用。有很多技术一用就知道:“这个东西太爽了,太舒服了。”
我的猜想是,对 agent 来说,一个对开发者友好的体验,一样也会对 agent 友好。
我一直觉得图形界面不是真正的好用。它可能很适合普通人使用电脑,但并不是 agent 这种灵活场景最合适的抽象。比如两个图形界面的东西,你不能融合出第三个图形界面;但在命令行世界里,这是可以的。
这种体验就是程序员所说的“好体验”。在 agent 时代,我觉得反而会更好,因为 agent 面临的需求非常多。你能用一套简洁、自洽的心智模型,囊括尽可能多的灵活任务,这就是对 agent 来说的好体验。
所以 Unix 哲学最近突然又变得非常火,核心就在这里:这套方法论的原则就那么几个,但通过组合,能够变出一个更大、更复杂的世界。
你觉得未来 AI 能力的下一个突破边界在哪里?
我隐约觉得,在组织多个 agent 去完成复杂任务的过程中,会 somehow 存在一种 scaling law。
我们今天刚刚开始把多个 agent 协同起来,做一些事情。如果放进去 100 个、1,000 个、10,000 个 agent,它们能够产生什么样的效果,我觉得现在还是一个 open question,也让我挺兴奋的。
编程语言和开发者工具,你觉得在 agent 时代还重要吗?
我觉得这其实还挺重要,非常重要。刚才我反复提到心智模型。大家知道,模型是通过强化学习训练出来的,但它仍然是人发明了数学,也发明了编程语言。
不过这里面反过来又不太重要。包括在 harness engineering 里,你不用再去关心具体代码。以我自己的开发过程来说,我每天消耗这么多 token,产生这么多新代码,但一行具体的代码细节都不会看。
你要关注架构,关注软件工程,关注代码不要快速腐化,以及更上层的事情。所以对我来说,它既重要又不重要:重要的是必须贴合 agent 的心智模型;不重要的是,作为人,你不需要再去关注那些具体细节,而要关注更高层、更抽象的事情。
以后人与 agent 还需要协同吗?
这种协同可能不会针对具体某些事情的对齐,也不会是对细节的把控,而更多是提出需求,以及验证 agent 交付给你的结果。
还有,人会把自己的经验通过 skill 或者 spec 传递给 agent team。中间的软件生产过程,比如 agent 自己怎么开会、怎么管理,你可以给它一些点拨,但不要参与进去。
因为你一旦参与进去,就会变成整个系统的瓶颈。所以我觉得人和 agent 会有交互,但这个交互会发生在最上层。
你最近说过一句非常耐人寻味、又有点细思恐惧的话:你现在所有的认知,可能过 1 个月之后就会严重过时。
在这种快速变化的情况下,你到底怎么样建立自己的护城河?
我自己也在寻找这个问题的答案。我的方向是,一定要身处这个浪潮之中,天天去使用,保持自己对技术的判断,保持手感。
我觉得现在很多人学习 AI,或者学习 agent,靠的是看各种科技文章,或者看像我们今天这样的对话,但这都不是最高效的。最高效的方式就是亲自去用。
当你自己有了这种感受之后,今天的所有经验都会引导下一个月的自己,走向更前面的阶段。保持手感吧。
还想问问,你现在做的这些软件,是多大的一个团队做出来的?
现在大多数新产品,包括 Mem9、DB9,可能就是 1、2 个人的团队,其中可能我一个人是主力。
这跟传统的软件开发流程不太一样。可能我过去 3 个月干了传统软件公司 100 个人年做的事情,非常夸张。
你觉得未来公司的组织形态会发生什么样的变化?
这是个好问题。我最近其实也在经历这个过程:软件生产的过程会发生变化,人不再直接参与代码生产。
如果你是一个全职 coder,可能会挺危险。因为慢慢地,软件生产会变成黑盒化。比如现在我每天可能有数万行代码 check in 到软件里,但 AI 写了什么,我其实完全不知道。
包括我们公司现在 90% 的代码,都是 AI agent 在写。
所以人的组织形态可能会变成:由若干个非常强的 harness engineer,带领自己的 agent team,负责一个垂直业务,然后再配上一个领域专家。
领域专家相当于非常了解现实世界中的某个问题,但不会编程,也不会做软件。这两个人配合在一起,用 agent team 和 harness engineering 快速生产软件,去解决现实问题。
我觉得未来的组织形态可能就是这样一个个小型部落,不再是一个大公司或者大平台,而是高度碎片化的团队。
现在硅谷这么多大厂里有这么多软件工程师,你觉得裁员大概处在什么阶段?未来还需要这么多码农吗?
在我看来,上一个时代的软件工程已经终结了。以我的个人体验来说,确实不需要这么多软件工程师了。
其实这是一个好的现象,它意味着软件真正民主化了,任何人都可以实现自己想实现的软件。这是这一波浪潮带来的最大意义,而不是说像纺织女工一样。
其实我们现在穿的衣服反而更多了,而不是更少了。
今天最后一个问题,想帮年轻人问一下。现在有很多正在学计算机专业的同学都很焦虑,因为他们可能觉得,在学校里学的东西毕业以后就完全没有用了。你觉得他们现在应该学什么?
如果你真的喜欢计算机,就会发现有很多东西即使在今天 agent 的时代也不会变,甚至更有价值。
就像我刚才说的 Unix philosophy,以及一些经典的软件工程、思维模型,这些东西其实一直都不会变。你要找到这些永恒不变的东西,学习这些东西,然后投身到软件行业里。
如果你现在学计算机只是为了以后找一份码农的工作,那可能就得想一想,你真正喜欢什么。
我觉得不管怎么样,人最后还是要做自己热爱的事情,才能最幸福。正好现在有这样一个时机,老天让你去做真正喜欢的事情。
而且今天大语言模型这么强,你在学习任何感兴趣的东西时,门槛和学习成本都已经大幅下降了。所以我对年轻朋友的建议就是:做你想做的事情,做你热爱的事情,去做就好了。
非常感谢今天的分享。最后想问你一个彩蛋:如果给大家推荐一本书,你推荐什么?
我想想。我其实有一些 candidate。那还是《禅与摩托车维修艺术》吧。
对,那本书我也看过无数遍,非常喜欢。最打动你的是什么?
其实那本书讲的是一对父子骑着摩托车环游美国的 road trip。在这个过程中,他每天都会思考工匠精神,以及一件事物为什么好、好的地方在哪里。
所以我觉得,它是一本让人能够认真思考“造物”这件事情的本质是什么、你为什么会享受把东西做好、什么是好的东西的书。它讨论的就是这些内容。
读完那本书以后,如果你是一个工程师,或者说是一个广义上的工匠,你会更加明白自己为什么是这样的人。