「LLM 时代下，李想对理想同学的定义」
李想这次最锋利的一刀，是砍向整个行业心照不宣的”记忆”执念。当下几乎所有 C 端 Agent 都在干同一件事：把一份越来越长的 Markdown 历史文件塞进上下文，越用越膨胀、越膨胀越拖累——他把它定性为”熵增”，而不是记忆。这个判断和本站反复聊的”用锤子看什么都像钉子”是同一句话：大多数产品把所有 query 都丢给一套统一的 Agent 框架，用数万 Token、几分钟去回答一秒就能查到的天气。李想的解法是把需求拆成五类、各配最合适的工具。
更值得玩味的是他的”克制”：不堆更复杂的 Agent、不追更长的上下文，而是做需求分层和工具匹配。L9 Livis 还顺手把模型层做成可插拔（千问、豆包、Kimi、自研任选），底座是 Linux 与 Android 双系统。这不是保守，是工程上的清醒——在正确的场景用正确的工具。下面是这套框架的拆解。
车载agent怎么用
2026 年 5 月 14 日，罗永浩的”十字路口”迎来了李想的第二次到访，距上一次整整 200 天。这一次，他带来了理想 L9 Livis——搭载自研麒麟 M100 芯片，算力达 2560 TOPS，号称目前量产智能电动车中算力最高的产品。但在这场对话里，最值得反复咀嚼的，不是芯片参数，而是一个关于”开车一小时怎么不被浪费”的具体问题。
罗永浩说自己单程通勤一小时，这段时间对他来说是”报废状态”。他希望在驾驶时通过 HUD 和语音，与车载 AI 进行深度问答；到了办公室打开手机，对话记录无缝接续，把这一小时变成有价值的工作时间。但当前理想同学只能处理车辆操控层面的指令，涉及深度问答就直接说”这个我回答不了”。这是一个非常典型的超级用户诉求，李想的回应不是一句”我们会做”，而是一套完整的需求分析框架——以及为什么当前几乎所有车载 AI（乃至大多数 agent to C 产品）都做错了方向的判断。
| 维度 | 核心结论 |
|---|---|
| 核心反直觉 | 主流 Agent 的”记忆”机制本质是熵增，不是记忆，越用越拖累系统。 |
| 需求拆解 | C 端车载 AI 真实需求分五类，各配最合适的技术方案。 |
| 架构原则 | 分层、任务驱动的系统：正确的场景用正确的工具，而非统一 Agent。 |
| 硬件底座 | L9 Livis 麒麟 M100，2560 TOPS；模型层可插拔（千问/豆包/Kimi/自研）。 |
| 落地节奏 | 系统架构随 L9 Livis 于 2026-05-15 正式交付上线。 |
打碎一个幻觉：记忆不是答案，而是熵增
理解李想框架的起点，是他对当前主流 Agent”记忆”机制的否定。他谈到自己使用 OpenClaw 的实际体验：”我是先用 OpenClaw，用了段时间以后我基本被它记忆给快搞疯掉了。就我越用，其实我收益越差。”这背后的技术逻辑并不复杂。当前主流 Agent 框架对”记忆“的实现，是在每次对话开始时，把一份积累的 Markdown 文件读进上下文——你和 AI 的历史交互、你的偏好、你的背景，全都塞进来。但这不是真正的记忆，而是一种熵增。你用得越久，这份文件越膨胀；文件越膨胀，每次对话消耗在处理冗余信息上的成本越高；成本越高，实际可用的上下文空间越少，响应效率越差。所谓”记忆”，反而成了拖累系统运行的负担。
李想的结论是：C 端用户不应该用”记忆”来定义需求，而应该直接看需求本身。这是整个框架的逻辑起点。
五大需求场景：从记忆到需求
抛开”记忆”之后，C 端用户在车载 AI 场景下的真实需求是什么？李想将其拆解为五类，每一类对应一种最合适的技术方案，而不是用一套统一的框架硬扛：
| 需求场景 | 真实需求 | 最合适技术方案 | 关键特征 |
|---|---|---|---|
| ① 泛化任务 | 复杂、多步骤任务（深度调研、整合、跨平台操作） | Agent 框架（如 Claude Code 擅长的能力） | 代价是时间与 Token，只在真正需要时调用 |
| ② 泛化信息获取 | 快速拿信息（查新闻、问问题、聊话题） | Chatbot 能力 | 够快、低延迟，不能让用户等五分钟查天气 |
| ③ 精确指令控制 | 调空调、开 App、导航（频次最高） | 知识图谱 | 结构清晰、响应确定、本地算力即可，Token 近乎为零 |
| ④ 必要信息记录 | 提取要点、存日历、标记重要信息 | RAG（检索增强生成） | 可索引、按需取回，不污染上下文 |
| ⑤ 个性化 | 沟通偏好、性格特征、重要背景 | 参数化配置（类似 soul.md） | 只存关键参数，不做越来越臃肿的人物档案 |
表 1：李想拆解的 C 端车载 AI 五大需求场景与对应技术方案（据访谈整理）。
这里有两个区分至关重要。其一是”泛化任务”与”泛化信息获取”的边界：前者适合调用 Agent 框架，但代价是时间和 Token，只应在真正复杂时调用；后者只需要足够快的 Chatbot 响应。当前很多产品把所有 query 都丢给 Agent 框架处理，结果是消耗数万 Token、花费数分钟，去回答一个本来一秒就能解决的问题——这是典型的”大炮打蚊子”。
其二是”记录”与”记忆”的区别。李想对第④类的用词是”记录”而非”记忆”：记录是具体的、可索引的，在需要时通过 RAG 按需取回，不会把所有东西塞进上下文。它是对当前 Agent”记忆问题”的直接解法。第⑤类的个性化则强调”不需要写一堆东西”，只需要关键的参数化信息，而不是一份越来越臃肿的人物档案——这是个性化，不是另一种形式的熵增记忆。
分层架构：用正确的工具做正确的事
五大需求场景，对应五种不同的技术方案。这才是李想这套框架真正要指向的架构设计原则。他在访谈里有一句话直接点明了问题所在：”今天的很多 agent 架构可能都得这么去改，因为你所有东西都用一个 agent 架构，其实效率太低了。”这听起来显而易见，但当前大多数车载 AI（乃至大多数 agent to C 产品）的实现，恰恰走的是相反的路——用一套统一的 Agent 框架承接所有用户请求，导致简单需求变慢、复杂需求变差、整体体验崩坏。李想提出的架构逻辑是一个分层的、任务驱动的系统：
泛化任务 → Agent 框架 · 完成复杂多步骤任务
泛化信息获取 → Chatbot（可接第三方模型） · 速度快、低延迟
精确指令控制 → 知识图谱 · 稳定、确定、本地算力
必要信息记录 → RAG 索引 · 按需检索、不污染上下文
个性化 → 参数化配置 · 轻量、无冗余
值得注意的是，在模型层面，Livis 采用了开放接入的设计——用户可以在千问、豆包、Kimi 或理想自研模型中自由选择，前两个场景（Agent 和 Chatbot）均可接入第三方模型。这意味着，李想构建的不是一个封闭的 AI 能力，而是一个开放的、可插拔的系统级架构，底座是 Linux 与 Android 双系统协同。
为什么这套框架值得认真对待
这套框架的意义，不止于 L9 Livis 的产品设计。它本质上是在回答一个更普遍的问题：当 AI Agent 走向 C 端，用户的真实需求结构是什么，架构应该怎么设计才能与之匹配？
当前 AI 行业的主流叙事，是把”更强的记忆”、”更长的上下文”、”更复杂的 Agent”视为必然的进化方向。李想从一个车主的具体通勤痛点出发——倒推需求结构，再从需求结构推出架构原则——得出了一个方向几乎相反的结论：大多数 C 端场景，需要的不是更复杂的 Agent，而是更清晰的需求分层和更合适的工具匹配。这不是技术上的保守，而是工程上的克制——在正确的场景用正确的工具，而不是用锤子看什么都像钉子。
根据李想在访谈中透露，这套系统架构将随 L9 Livis 在 2026 年 5 月 15 日正式交付上线。结语李想这次给行业泼的冷水很具体：当所有人都在比谁的上下文更长、谁的 Agent 更重，他反过来把”记忆”定性为熵增，把需求拆成五类各配其器。这套框架未必是终局，但它至少戳破了一个幻觉——更复杂的系统不等于更好的体验。对做产品的人而言，”用正确的工具做正确的事”这句老话，在 Agent 时代反而更像一句还没被普遍执行的预言。
原文链接：查看微信原文《LLM 时代下，李想对理想同学的定义》。
内容源自：罗永浩的十字路口 第 27 期（2026-05-14 访谈）· YouTube 视频。
- 李想在罗永浩的十字路口第 27 期里，把主流 Agent 的记忆机制定性为熵增：越用越膨胀的 Markdown 历史文件不是记忆，而是拖累系统的负担，C 端用户不该用记忆定义需求。
- 李想将 C 端车载 AI 的真实需求拆成五类，并各配最合适的技术方案：泛化任务用 Agent、信息获取用 Chatbot、精确指令用知识图谱、记录用 RAG、个性化用参数化配置。
- 李想以自己用 OpenClaw 的体验说明，当前主流 Agent 把历史交互塞进上下文的做法本质是熵增，文件越膨胀响应越差，所谓记忆反而成了系统负担。
- 李想反对用一套统一的 Agent 框架承接所有请求，认为今天的很多 agent 架构都得改，正确的做法是分层、任务驱动，在正确的场景用正确的工具。
- 李想指出当前很多产品把本可一秒查到的天气问题丢给 Agent 框架，消耗数万 Token、耗时数分钟，是典型的用大炮打蚊子，应改由低延迟 Chatbot 处理。
- 理想 L9 Livis 搭载自研麒麟 M100 芯片达 2560 TOPS，采用分层任务驱动架构，模型层可插拔接入千问、豆包、Kimi 或自研模型，底座为 Linux 与 Android 双系统。
- 李想把第④类需求称为记录而非记忆，通过 RAG 把要点可索引地按需取回，不把所有内容塞进上下文，正是对当前 Agent 记忆问题的直接解法。
- 李想认为调空调、导航等高频精确指令最适合用知识图谱而非大模型，结构清晰、响应确定、本地算力即可胜任，Token 消耗几乎可以忽略。
- 李想从车主通勤痛点倒推需求结构再推出架构原则，得出与行业相反的结论：大多数 C 端场景需要的不是更复杂的 Agent，而是更清晰的需求分层和更合适的工具匹配。
- 在 2026 年 5 月的访谈中，李想展示了一套以需求分层为核心的车载 AI 框架，并透露该系统将随理想 L9 Livis 于 5 月 15 日正式交付上线。
写在最后
在 2026 年 5 月的访谈中，李想展示了一套以需求分层为核心的车载 AI 框架，并透露该系统将随理想 L9 Livis 于 5 月 15 日正式交付上线。（源自 AI催晨箭）关于这个话题，我们持续关注，欢迎在评论区交流你的看法。
