Personal Agent 拆解：模型越强，产品越要做减法
从 Lee Robinson 讲 Grok Bot 的一堂课说起，聊聊 personal agent 为什么把 Agent 从工具变成了同事，以及为什么值得每个人去用一用。后半篇讲「删掉产品」：UI 的复杂往往是在弥补模型的不足，补偿模型的部分该删，承载业务的部分要加厚。
前几天看了 Lee Robinson 在 Stanford CS146S 的一堂课（讲座发布帖 ↗），主题是常驻、主动的 Agent 是怎么工作的。Lee 之前在 Vercel 负责开发者体验，后来去 Cursor 做 Agent 产品，现在在 SpaceX 做 Grok Bot。这堂课讲的就是 Grok Bot 这类产品是怎么搭起来的。
这堂课我看得很有感触，因为它讲的正是这一年里我用 Agent 的方式变化最大的地方。我现在的主力 Agent 跑在家里的 Mac mini 上，我在 Telegram 里随时可以找它。它已经不太像一个工具，更像一个同事。
讲座快结束时，Lee 提了一条原则，前后只讲了不到一分钟：delete the product，删掉产品。我回头再看前面讲的架构，发现几乎每一个设计都能用这条原则解释。
所以这篇文章分成两半。前一半借这堂课聊聊这类 Agent 产品：它和我们平时用的 coding agent 有什么不同，为什么我建议每个人都去用一用，Grok Bot 是怎么搭的，以及这些活为什么不直接交给 Codex 或 Claude Code；后一半聊「删掉产品」：删的是什么，为什么删了反而更好，哪些东西不能删。上一篇讲 Harness 的文章聊的是哪些东西会被模型学走；这一篇从一个具体的产品形态出发，看「删」这个动作本身该怎么做。
一、从「发一条等一条」到同事#
Lee 先回顾了我们是怎么走到今天的，他分了四个阶段。最早是复制粘贴：从 ChatGPT 里复制代码，再粘回编辑器。后来有了跑在终端里的 Harness，模型可以自己改文件、跑命令。再后来有了专门的 App，可以在云端同时跑很多个 Agent，但人成了瓶颈，每一条命令都要等你审批。现在是第四个阶段：常驻 Agent。
我在 Talks 第二期里也讲过类似的演进，当时引用的是 Karpathy 的三层：第一层是网页版的 LLM，你打开网页提问，它是一台回答问题的机器；第二层是本地或 IDE 里的 Agent，比如 Claude Code、Cursor、Codex，它能直接操作你的文件；第三层是常驻的 Agent，有记忆，异步工作，可以多人接力。换句话说，LLM 从 response interface 变成了 delegation interface：你不再是问它，而是把工作委托给它。
我自己划分 Agent 产品，也是按这三种形态：网页端的 Agent；装在电脑上的 coding agent；以及跑在云端、在聊天软件里就能找到的 bot，我暂时把它们统称为 personal agent。Grok Bot 属于第三种。
第三种真正改变了我们使用 Agent 的方式。最早用 Agent，是我发一条，等它做完，才能发下一条。现在更像和同事一起工作：你可以随时插话，先说「去看一下这个帖子」，紧接着补一句「其实周四再做也行」，它能理解这两句话说的是同一件事；它在后台把事情做完，有重要的进展才回来找你。Lee 的原话是 “It knows when to be quiet.”
它不再像一个听你吩咐的小弟，而是一个真的可以长时间共事的伙伴。和 coding agent 比，差别主要在这几点：
- 它一直在线。 你合上电脑、它自己重启、中途崩溃，都不影响它继续干活。
- 它有自己的电脑。 一台云端的机器，有桌面、文件和浏览器。
- 唤醒它的不只是你。 Slack 里有人 @ 你、收到一封邮件、到了某个定时任务的时间，都可以把它叫起来。
- 它要连续工作很久。 不是几个小时，而是几天、几周，甚至几个月。
这类产品大多做成 bot 的形态，Lee 的解释很简单：大家都会发短信。他还顺口说了一句，后面会反复用到：模型越强，界面反而越简单。
先去用一用#
OpenClaw 刚火起来的时候，很多人的第一反应是：这些事情，交给 Codex 或者 Claude Code 不也能做吗？
这个问题我会在第四节回答。但在那之前，我特别建议大家花一点时间，一周也好，几天也好，去真正用一用这类产品。我相信这是最能改变你想法的一件事。可以从这几款开始：
- Today：分国内版和国外版，国内版可以直接使用。条件允许的话，我更建议用国外版，功能更多，模型也更好。
- Cue（Manus）
- Muse（Meta）：使用门槛更高一些。
- Dots（OpenAI）：目前只有 Pro 账户可以使用。
- Grok Bot：也放在这里，不过它现在已经更偏向工作场景，也在做团队版、企业版这些功能。
这几款里，除了 Muse 我都用过。我自己的主力是一个基于 pi（一个开源的极简 Agent 运行框架）二次开发的个人 Agent，我叫它 Jojo；粉丝群里给大家答疑的「副校长」bot，也是基于 pi 二次开发的。这些我都统称为 bot。
二、Grok Bot 是怎么搭起来的#
下面讲的是 Grok Bot 的架构。它的内核依然是那个最小的 Agent：模型在循环里调用工具，变化都在外面那一圈。Lee 把它分成三段：左边是各种触发器，中间是服务器，右边是 Agent 自己的电脑。
① 触发器
② 服务器（厚）
队列 / 路由器
去重 · 定优先级 · 合并连发 · 要不要打扰用户
优先级最高 正在跑的 Agent loop 会停下来，先处理你这句话，其他来源的消息排到后面。
Agent loop
模型在循环里调用工具；每个任务是一个持久化工作流（Temporal），崩溃后从断点继续
数据库
对话日志 · 记忆 · 定时任务 · 状态，每一轮都写进来
③ Agent 的电脑
Firecracker 虚拟机
- 文件：记忆、技能、日志、长输出
- 在隔离、锁定的环境里跑命令
- Chrome，多个虚拟桌面（每个 bot 一块屏）
- 可以实时查看，必要时亲手接管
- 启动
- 使用
- 快照
- 休眠
一直开着太贵，需要时才从快照唤醒。Agent loop 不在这里，所以虚拟机可以随时重建、打补丁。
消息从不同的来源进来，先经过一个路由器：去重，按来源决定优先级，连续收到的几条合并成一轮处理，再判断这件事要不要去打扰用户。这一点和真实的同事很像：一个同事每有一点进展就来找你汇报，你会觉得很烦，大多数任务一天更新一次状态就够了。优先级里最重要的一条是，你直接发给它的消息高于其他一切：你一开口，它就先放下手上的事。
右边是 Agent 自己的电脑，一台按需启动的云端虚拟机：用的时候启动，用完做快照然后休眠。一直开着太贵，世界上也没有那么多电脑能给每个人常开一台。你可以随时连进去看它在做什么，必要时自己接管。
有一个设计我觉得很值得一提：Agent 的循环不放在这台电脑里，而是放在服务器上，状态也都存在服务器。这样电脑可以随时重建，比如出现一个紧急的安全漏洞，直接重建所有虚拟机打补丁，Agent 不会因此停下来。长任务也被拆成一步步持久化的工作流，中途崩溃了就从断点继续，不用从头再来。
三、客户端和服务器之间只有一个工具#
Grok Bot 还有一个设计很能说明问题：客户端和服务器之间只有一个工具，叫 SendToUser。
薄客户端
手机 · 桌面 · 邮件 · Slack
收到消息后，按内容渲染成合适的交互：
- 登录表单
- 付款
- 不可逆操作先确认草稿
- 不需要回话时，回一个表情
厚服务器
所有「重」工具都在这里
- shell 命令，读写文件
- 调用云端 Agent
- 录屏、做演示
- 连接器、MCP、插件
不管用的是手机 App、桌面 App、邮件还是 Slack，客户端和服务器之间都只靠这一个工具来回传消息，客户端只是在给服务器「发短信」。客户端收到消息后，再决定用什么形式呈现：需要登录就弹出登录表单，发邮件这类不可逆的操作先给你一份草稿确认，不需要回话的时候，回一个表情就够了。加一个新渠道，不需要改 Agent 的任何东西，只是多了一个会收发消息的客户端。
工具都在服务器上，用起来也尽量省：每次发给模型的只有工具名，模型决定要用某个工具时，再去读它的详细说明。遇到一个任务，它按一个升级阶梯来尝试：先试最便宜、最可靠的办法，不行再一级一级往上爬，实在不行才来问你。下面每个例子都可以点一下，看它会停在哪一级。
- 1 已知上下文 Known context 对话历史里已经知道的东西
- 2 连接器 / API Connector · MCP · API 例如通过 Plaid 拉取银行信息
- 3 网页搜索 Web search 公开、实时的信息
- 4 浏览器 Browser 在电脑上打开浏览器搜索、操作
- 5 整个桌面 Full desktop 在 Linux 电脑上跑脚本、跑命令、构建东西
- 6 询问用户 Ask the user 以上都不行，才来打扰你：输入、审批、2FA 验证码
停在第 1 级：已知上下文
一个靠谱的同事也是这么做事的：先自己把能试的都试一遍，实在不行再来问你。
上下文也是同样省着用的。Agent 每加一条消息，基本上都是把整段对话重新发一遍给模型；前面的部分和上一次完全一样，就能命中缓存，价格便宜很多。所以 Lee 说，出现缓存未命中，基本上就是系统里的一个 bug。 对一个一直在跑的常驻 Agent 来说，缓存命中率直接决定了它养不养得起。
安全也是同样的思路：每条命令执行前，先让另一个模型审查一遍；收件箱里的邮件是不可信的输入，不能当成你的指令。这一块我在权限隔离那篇里写得比较细，这里不展开。
四、为什么不直接交给 Codex 或 Claude Code#
回到前面那个问题：这些活，为什么不直接交给 Codex 或者 Claude Code？
Lee 在讲座里讲了主 Agent 的设计。你和主 Agent 的对话会很长，而且要求回复快，所以主 Agent 要保持「稀疏」：它管理待办清单，查看进度，给帮手发消息；真正耗时间、耗 token 的工作，交给子 Agent 带着全新的上下文去做，最后只把结果带回来。
这件事我很早就开始讲了，它也正好是我对那个问题的回答。如果你同时只有一个任务，直接交给 Codex 或 Claude Code 完全可以。 你的上下文和注意力都放在这一个任务上，盯着它做完就好。
但当这个数字变成 5 个、10 个呢？这并不夸张：可以是一个项目里的几个并行子任务，也可以是几个不同的项目同时在推进。这时候瓶颈变成了你自己：每切换一次任务，你都要重新回忆它做到哪一步、上下文是什么、下一步该说什么。并行的任务越多，上下文和注意力的切换成本就越高。
所以才需要一个主 Agent，或者说一个编排层，来替你承担这一部分。我自己的 Jojo 做的就是这件事：我把任务交给它，它在 herdr 里为每个任务开一个独立的工作区，拉起 Claude Code 或 Codex 去干活，自己负责盯进度、做验收。默认情况下，我只会听到两类消息：「做完了」，以及需要我拍板的事。这套做法我整理成了一个 skill，放在 joyehuang/skills 里的 herdr-workflow ↗。
另一个好处是上手的成本低了很多。后台可以有很多个 Agent，但你不需要直接面对它们，你面对的只有一个。心理上的负担和使用上的负担，都会因此小很多。
不过这有一个前提：最强的那一批模型要真的擅长多 Agent 协作。据我观察，这个能力是在今年下半年才有了一次很大的提升。今年上半年 Claude 推出了 agent teams，社区里也有不少类似的产品，但效果都不太好；娱乐一点的，也有人让不同公司的模型一起玩狼人杀，效果也都一般。
五、删掉产品#
讲座后半段，Lee 讲了 Grok Bot 团队怎么让产品和模型一起变好：产品里的每一个错误都变成一条评测，先去修 Harness；再定期用这些失败去训练新模型。后一步只有训练模型的团队能做。对大多数做 Agent 产品的人来说，模型的换代是一个外部变量，这一点后面会很重要。
紧接着，Lee 讲到了这条原则。他说这是他们在 Cursor、现在在 SpaceX 都遵守的一条原则：delete the product。意思是你要真正接受一个假设：今天的模型，是它们有史以来最差的（“the models today are the worst they’ll ever be”）。所以半年之后，你可能要把整个 UI 重做一遍。比较好的策略是为下一代模型而建：尽可能少建，只做一个非常简单的界面，让模型替你去思考和行动。
我第一次读到这里，其实没看懂前后两句的关系：为什么「今天的模型是最差的」，就意味着半年后要把 UI 重做一遍？拿 AI 写代码工具这几年的界面变化来看，就清楚了。
从 Tab 补全，回到一个对话框#
最早的 AI 代码工具是代码补全：光标停在某个地方，按一下 Tab，它补全这一行，还补不了一整段。
接下来，你在代码文件里选中一行，上面会弹出一个很小的对话框，你只能让它改这一行，或者上下几行。
再后来，VS Code 的右边多了一个侧边栏，里面有 Ask、Plan、Agent 各种模式，用之前先要选一个。去年那段时间，Cursor 大概每周都要更新两次界面上的细节，加新模式、调交互，一直在打补丁。
到了今年，以 Codex 为例，点进去就是一个对话框。原来的各种模式基本都没了，输入框旁边只剩下权限设置，而大部分人其实都开着最高权限。很多 AI 产品，不管是 WorkBuddy 还是 GLM 的 Z Code，界面都在向 Codex 靠拢，因为它的界面形态确实做得好。
-
01
Tab 补全
按一下 Tab，补全这一行
- 界面复杂度
- 模型能力
-
02
选中几行，弹出小对话框
只能改选中的这几行
- 界面复杂度
- 模型能力
-
03
侧边栏 + 各种模式
先选 Ask、Plan 还是 Agent
- 界面复杂度
- 模型能力
-
04
一个对话框
点进去直接说要做什么
- 界面复杂度
- 模型能力
示意图。复杂度和能力是相对的比较，不是测量值。
那段时间为什么需要那么多额外的界面？因为模型的能力还不够。只补一行，是因为补多了容易错；只让改选中的几行，是因为放开了它可能会改乱；要先选模式，是因为模型自己还判断不好这件事该先问、先规划，还是直接动手。UI 的复杂程度，往往是在弥补模型不够聪明的地方。 模型够强了，这些界面就可以拿掉。
表面上看，产品又回到了 ChatGPT 刚出来时的那个对话框。但这次回归，并不是因为模型只会聊天，而是因为模型已经足够强，我们不应该再用多余的 UI 去限制它。
而且今天的对话框也不只是一个对话框。Opus 4.6 之后的模型已经能稳定地输出复杂的 JSON，产品只要准备好一套组件，模型输出 JSON，就能直接渲染出表单、卡片和图表，这就是生成式 UI。前面 Grok Bot 的客户端按内容渲染登录表单、付款和草稿确认，也是同样的思路：界面不再是事先写死的一层层菜单，而是在模型需要的时候才出现。
回头看前面的架构，几乎每一个设计都是这条原则的结果：界面就是发短信；客户端和服务器之间只有一个工具；工具只给名字；重活交给子 Agent，主 Agent 保持稀疏。Lee 在 X 上介绍 Grok Bot 时还提到，它没有模型选择器，也不流式显示回复。他的总结是 “The best UI is none at all”，Grok Bot 能做成现在这样，“primarily because of everything we didn’t have to build”（帖子 ↗）。
今天的模型是最差的#
这条原则里，我觉得最难的是真正把「今天的模型是最差的」内化下来。
第四节说过，今年上半年的多 Agent 还很差，会忘事；到了下半年，一下子就不一样了。让我惊讶的是，大家好像觉得这是自然而然、理所当然的事情，对模型的快速进步已经有点麻木了。可如果真的接受这个假设，就意味着你要随时准备推翻自己刚刚习惯的东西。产品形态的保质期大概只有半年，Lee 自己也说，这场讲座如果放在半年前或一年前讲，内容会很不一样。
对做 Agent 的人来说，这更应该是一个明确的认知：你现在为了弥补模型短板而做的那部分 Harness，三个月、半年之后就是会被淘汰的。 这不是谁做得不够好，而是这一行的底层逻辑：模型每隔几个月就换一代，今天替模型补上的东西，迟早会被模型自己学会。认清这一点，才不会把一块注定要拆的脚手架当成护城河，拆它的时候也不会舍不得。
这件事说起来容易，做起来很难。我最近经常和我爸聊 AI。他年纪比较大，做的也不是和代码相关的事，用的 token 很少，但我能很明显地感觉到，他在这个时代里有了提升。大家常说，年纪大的人用惯了十几年、二十几年的做法，就不愿意改变；但我在他身上看到的不是这样。反过来想，我能这么快接受 AI，部分原因是我没有十几年的旧习惯要放下。等我完全适应了 AI 之后，如果再出现一个全新的东西，我也不确定自己有没有勇气去接受。
所以删掉产品，首先要删掉的，是自己已经习惯的那一套做法。
补偿层和承载层#
不过「删掉产品」很容易被误读成：产品做得越少越好。我不这么理解。
我会把一个 Agent 产品拆成两层。一层是补偿层：因为模型还不够好，才替它做的那些事，包括替它做判断的流程和按钮、意图路由、一长串规则、手写的检索、为某一类任务专门做的小工具。另一层是承载层：不管模型多强都需要的东西，包括数据、权限、集成、评测、分发和成本。
打个比方：同样一件活，交给实习生，你得写清楚第一步、第二步、第三步；交给一个资深的工程师，你只要告诉他目标就够了。补偿层就是写给实习生的那份步骤说明。模型已经越来越像那位资深工程师，还给它一份详细的步骤说明，反而是在限制它。
「删掉产品」删的是补偿层。补偿层要尽量薄，随时可以扔掉；承载层不但不能删，还要持续加厚。
补偿层的价值会随着模型变强先升后降：
概念示意图，不是实测数据。思路来自 Sutton 的 The Bitter Lesson、Hyung Won Chung 关于「结构多和结构少」的曲线，以及 Aaron Levie 说的「建脚手架、模型追上来、拆掉脚手架」。
模型弱的时候，补偿层让产品能用；模型追上来之后，它就没用了；再往后，它会变成负担：限制模型、和模型的判断冲突、占用上下文，还要人一直维护。难的是交叉点在哪里，事先很难知道。
六、为什么补偿层留着反而有害#
如果补偿层只是变得没用，留着也无所谓。问题在于它会主动拖累一个更强的模型。原因主要有四个。
第一，它写死的是一个已经过期的假设。 每一个专用工具、每一条预过滤、每一段手写的检索，背后都有一个「模型做不到 X」的假设。Vercel 在回顾他们的数据 Agent d0 时写道：“We were doing the model’s thinking for it.” 他们原来有 17 个专用工具，负责查 schema、校验、错误恢复、规划，后来删到只剩两个：一个沙箱里的 bash，一个执行 SQL 的工具。结果是这样的：
- 平均耗时
- 平均 token
- 平均步数
数据来自 Vercel 博客。样本只有 5 条代表性查询，应当看作很强的信号，而不是统计结论。
这个结果有一个前提，Vercel 自己也写得很清楚：他们的语义层本来就是一份很好的文档。数据层如果一团乱，把文件系统交给模型也救不了，只会更快地得到错误的查询。
第二，多余的约束会伤害强模型。 Anthropic 的 Thariq 介绍他们删掉 Claude Code 八成以上系统提示时（帖子 ↗），列了几种典型的伤害：系统提示、skills 和用户请求里同时出现互相打架的指令，模型得先花力气去调和；给的示例反而把模型限制在一个固定的范围里；为了防止最坏情况写的强规则，换到另一类任务上就是错的。Every 的 Dan Shipper 在 Opus 5 发布当天也遇到了同样的事：为旧模型攒下的 skills 和新模型配合得很差，他们把 skills 全删了从头开始，Opus 5 的表现明显变好（帖子 ↗）。
第三，每次换模型都要重新校准。 Vercel 的原话是 “every model update meant re-calibrating our constraints”，他们花在维护脚手架上的时间，比改进 Agent 本身还多。Box 的 Aaron Levie 也说过，做 Agent 意味着接受未来几年要写大量会被扔掉的代码（帖子 ↗）。补偿层有维护成本，而且这个成本跟着模型的发布节奏走。
第四，界面会把用户留在旧的用法里。 Amp 的 Thorsten Ball 说得很直接：“If a feature teaches you to start using agents the old way, we need to remove it.”（帖子 ↗）Lee 发布 Cursor 3 时也承认，Cursor 2 里频繁挪动 UI 让用户很烦，但 Agent 接手的工作越来越多，已经装不进 IDE 的界面了。
这四点之外，还有一个人性上的原因。前 OpenAI 研究员 Hyung Won Chung 在 Stanford CS25 讲过，结构是因为算力不够才加的，之后要删掉；但大家擅长加结构，却不擅长删（CS25 视频 ↗）。
所以在我看来，删掉产品不是一种审美偏好，而是一笔期望值的计算：模型能力增长的速度，远远快过手写补丁能带来的提升。任何把人的判断硬编码进去的东西，都是在和这个速度对赌。
「删掉产品」也不是 Lee 一个人的发明。往前可以追到 Rich Sutton 2019 年的 The Bitter Lesson ↗：长期来看，能利用算力的通用方法最终胜出，人加进去的知识短期有帮助，长期会变成阻碍。落到 Agent 产品上，过去两年各家陆续说过同样的话：Anthropic 的 Building effective agents ↗ 建议从最简单的方案开始，只在能证明有效时才增加复杂度；Manus 一年里把框架重写了四次，说要做随潮水上升的船，而不是插在海底的柱子（博客 ↗）；Boris Cherny 在 YC 的节目里说，Anthropic 是为六个月之后的模型而建（帖子 ↗）。
落到具体的产品上，要问的其实是一个问题：你的产品，能不能在模型变强的时候免费变好？ 最能直接拿来检验的，是 Manus 的 Peak Ji 给的一个指标（帖子 ↗）：在同一个模型家族里，把弱模型换成强模型，你的架构能多拿到多少提升？差值越大，说明架构越能跟着模型一起变好；差值很小，说明补偿层在拖后腿。另外，换成不同家族的模型，表现的差距要尽量小，这说明你没有过度适配某一个模型。
七、哪些东西不能删，反而要加厚#
如果只读到这里，很容易得出「什么都别做，等下一代模型」的结论，这也是这条原则最容易被误用的地方。Lee 自己在发布 Cursor 3 时就补了一句：删掉产品，不等于把所有好的想法都扔掉，让老用户能顺利适应同样很重要（帖子 ↗）。
把前面说的补偿层、承载层，再加上中间很薄的一层接口，画在一起是这样的。不能删的东西，都在最底下的承载层里：
补偿层：可以删
因为模型还不够好，才替它做的事
- 堆砌的 few-shot 示例
- 冗长、互相打架的规则
- 关键词意图路由
- 手写检索、RAG 分块
- 为单一任务做的专用小工具
- 向导、模式切换、模型选择器
承载层：要加厚
不管模型多强都需要的东西
- 数据与记忆：用户画像、日志、可读的知识
- 评测与 trace：每个 bug 变成一条 eval
- 集成与权限：账号、支付、不可逆操作的审批
- 分发与用户关系：用户、社群、渠道
- 运行时：持久化、沙箱、缓存、成本上限
示意图，比例不是测量值。接口层指一个对话入口、少量基础工具和按需加载的 skills。哪一项先被删掉因产品而异，判断依据是评测。
逐个说一下承载层里的东西。
评测。 评测是唯一能告诉你「这块可以删了」的东西。Claude Code 敢删掉八成的系统提示，是因为有编码评测证明「没有可测量的损失」。没有评测，删就是在赌。讲座里 Grok Bot 团队的做法也是这个道理：每个错误先变成一条评测，修完先在评测里验证。
可靠性。 模型会做，不等于每次都做对。Cognition 曾经想让 Sonnet 4.5 自己写笔记，替代他们自建的记忆系统，结果效果下降了，因为模型不知道自己不知道什么（博客 ↗）。Lee 在讲座里也提到：很多事都能用 shell 完成，但如果模型 90% 的时间都在用 shell 做同一件事，就值得把它做成一个专用工具，执行更高效，人也更容易审查。这类结构是为了稳定和可审查，不是为了补偿模型。
权限和不可逆操作。 发邮件之前先确认草稿，每条命令先过一遍审查，不可信的输入不能当指令。这些不是在补偿模型，而是在划清责任的边界，模型再强也要有。
成本和缓存。 Manus 把 KV-cache 命中率看作生产环境里 Agent 最重要的单一指标，缓存和不缓存的价格能差十倍左右。第三节提到的缓存，不会因为模型变强而过时，反而会随着用量增加变得更重要。
让人能快速核对的界面。 Karpathy 讲过，diff 视图的价值在于借用人的视觉系统，缩短核对的时间（帖子 ↗）。Lee 说 Cursor 删到最后，编辑器还剩 2% 删不掉，那一部分就是留给人核对和微调的。Hamel Husain 夸 Devin 现在会给出视频作为工作的证明（帖子 ↗），也是同一类东西。
可读的数据。 前面 Vercel 的例子已经说明了：删工具之所以有效，是因为投入转移到了文档、命名和数据结构上。
讲座最后，Lee 列了一串新的基础构件：持久化工作流、沙箱、云端电脑、记忆、技能、连接器、语音、支付、身份、评测、可观测性。他说每一块背后都有大量的风投，各有二十来家创业公司在做。把这张清单和上面对照一下会发现，它们几乎全落在承载层里。
还有一个反对的声音值得认真对待：Anthropic 可以为六个月之后的模型而建，是因为他们看得到模型的路线图，大多数创业团队看不到（帖子 ↗）。我同意这一点，上一篇里我也写过：模型厂商可以选择「这个先不做，等下一代模型」，我们不行，用户今天就有事情要完成。所以补丁今天该打还是要打。「删掉产品」的意思不是事前不建，而是事后不留恋。Aaron Levie 说得更坦白：你得接受自己做了一些会被扔掉的工作（帖子 ↗）。
最后也说说我觉得要打折扣看的地方。
Lee 讲的很多做法，背后是一个有自己的模型、有完整基础设施的大团队。用户一开始打字就预热缓存，把每一轮都做成持久化工作流，按需唤醒一整台虚拟机，这些对大厂来说很合理，但个人或小团队照搬，成本和维护都扛不住。记忆也是一样：讲座里那套分层记忆和压缩策略，对个人来说门槛太高，很多时候直接交给 Claude Code 这类工具自带的机制就够了。「The best UI is none at all」我也觉得说得太理想，不是所有产品都能只剩一个对话框，人需要核对和微调的地方，界面还是要做。
所以读这类分享，我会先分清楚哪些是原则，哪些是规模带来的做法。「删掉补偿层、加厚承载层」是原则，谁都适用；具体加厚到什么程度，要看自己的规模。
八、我自己的做法#
前面提到的副校长 bot，在一个大约 800 人的 QQ 粉丝群里给大家答疑。讲座里有一句话我印象很深：bot 在群聊里应该怎么表现，几乎没有训练数据，这是一个新出现的问题。而一个好的常驻 Agent “knows when to be quiet”。这正是群聊 bot 最难的地方。
按「补偿层要薄、承载层要厚」的思路回头看这个 bot，我会这样分：
- 入口统一成消息。 @ 它、回复它、私聊、定时任务、群事件，都转成同一种消息，进同一个 Agent loop。不再为每种入口写一套逻辑，也不用关键词和指令菜单去做意图路由。
- 要不要说话交给模型判断，但外面加确定性的上限。 它可以选择不回，或者只回一个表情；但每分钟最多发几条、对同一个人的冷却时间、深夜静默，这些由程序来管。
- 人设写短。 一段简短的人设描述，加上少量典型的例子；群里的梗和常用说法放进文件，需要的时候再查，而不是在提示词里堆几十条规则和示例。
- 记忆文件化、分层。 群规和核心事实常驻；成员的情况和按日期的记录按需去查；临时笔记自动过期。
- 治理要加厚。 管理操作走白名单和二次确认，群消息全部当作不可信输入，所有操作都留记录。这部分在权限隔离那篇里已经展开过。
放到更一般的 Agent 产品上，我会坚持这几条：
- 从最强的模型、最短的提示、最少的工具开始。 先跑通，再按真实的失败往上加东西。
- 每块补偿层都写清楚过期条件。 它在补偿模型的哪一项短板，哪一条 eval 能证明它不再需要。这和我在上一篇里说的「加补丁的时候，同时留下一个可以重跑的失败案例」是同一件事。
- 新模型发布时，裸跑一遍。 同一套 eval，一遍用完整的配置，一遍只留人设和最基础的工具。裸跑不输的那些规则和 skills，直接删掉。顺便用 Peak Ji 的指标看一下，强模型带来的提升有多大。
- 工具少而基础。 发消息、搜索、读写文件、shell；某一类调用占了大头，再把它做成专用工具。
- 把力气花在承载层。 对我的 bot 来说，就是群里积累下来的知识和成员记忆、对 QQ 生态的接入和治理，以及一套从真实群聊里整理出来的评测集。这些都是下一代模型冲不掉的。
最后#
回头看，Grok Bot 的每一个设计，SendToUser、升级阶梯、主 Agent 编排、守住缓存，做的都是同一件事：让模型以外的部分尽量薄、尽量稳，这样模型变强的时候，整个产品会自动跟着变好。
「删掉产品」提醒的是另一半：分清楚哪些东西是在补偿今天的模型，哪些是下一代模型也冲不掉的。前者随时准备删，后者每天都在加厚。
Lee 最后给工程师的建议里有一条是自己动手搭一个，我很认同。不过在动手之前，我更建议先做一件更简单的事：花几天时间，真正用一用 personal agent，把一件你平时要自己盯着做的事交给它。用过之后再回来看这篇文章，很多地方会更好理解。
如果你也在用或者在做 personal agent，或者删掉过什么、让产品反而变好的东西，欢迎来 QQ 粉丝群聊聊：
参考#
- Lee Robinson，Stanford CS146S 讲座 How do always-on, proactive agents work?：发布帖 ↗
- Lee Robinson 关于 Grok Bot 架构的帖子：链接 ↗；关于 Cursor 3 和「删掉产品」：链接 ↗
- Vercel：We removed 80% of our agent’s tools ↗
- Thariq（Anthropic）：删掉 Claude Code 八成系统提示的长文 ↗
- Manus：Context Engineering for AI Agents: Lessons from Building Manus ↗
- Cognition：Rebuilding Devin for Claude Sonnet 4.5 ↗
- Amp：The Coding Agent Is Dead ↗
- Anthropic：Building effective agents ↗、Effective context engineering for AI agents ↗
- Rich Sutton：The Bitter Lesson ↗
- Hyung Won Chung，Stanford CS25：视频 ↗
- Hamel Husain：Your AI Product Needs Evals ↗
文中对讲座内容的引用均为按原意概括，英文引文是讲座转录稿或原文的简短摘录。