合上笔记本，AI 编程助手就停了。Lee Robinson 在斯坦福 CS146S 讲 Grok Bot 这类 always-on agent 怎么搭：服务器、沙箱、记忆与动态工具发现，把一切当成一台长期在线的电脑，只在真正需要判断时才来打扰你。

你有没有想过，我们现在用的 AI 编程助手，其实有一个很大的软肋：你一合上笔记本电脑，它就停了。它只会在你发消息的时候才动一下，你不说话，它就不存在。那如果有一种 agent（智能体），像一个同事一样一直在线，会自己在后台干活，只有真正重要的时候才来找你，它背后到底是怎么搭起来的？

这是 Lee Robinson 在斯坦福 CS146S 这门课上的一场分享，他之前在 Cursor，现在在 SpaceX，讲的是他们正在做的 Grok Bot 这一类“永远在线、会主动干活”的 agent。他从上一周大家写的最简单的 harness（驱动模型的那层运行框架）讲起，一路讲到服务器怎么设计、上下文怎么省、模型和产品怎么互相推着进步。我挑了其中几条我觉得最有价值的线，每一节先讲 Lee 是怎么说的，再写我自己的想法，分享给大家。

为什么要做一个永远在线的 agent

Lee 先回顾了第一周大家做的东西：一个模型，加上一堆工具，在一个循环里反复调用，这个想法本身已经非常强大。但他说它有个明显的缺点：你合上电脑，进程就停了。他想讲的，就是怎么把这个想法延伸成 always-on agent，也就是跑在云端服务器上的 agent。它可以重启，可以在崩溃之后恢复，而且有自己的一台电脑，一台云端的 Linux 机器，上面有桌面、文件、浏览器，还可以存东西，慢慢积累对你的工作方式的了解。

他最想强调的一点，是这种 agent 更像同事，而不是一个有问必答的聊天框。聊天框的特点是你每发一条消息它都立刻回，而同事知道什么时候该安静。有时候它只是在后台默默做事，等有重要进展才回来找你。它也不只被你的输入唤醒，一条 Slack 消息、一封邮件，或者别的什么事件，都可以叫醒它去干活。他的期望是，这类 agent 干活的时间能从几小时、几天，拉长到几周甚至几个月。

他把开发者和 AI 的关系分成四个阶段。第一阶段是从 ChatGPT 里复制代码粘贴到编辑器，感觉像是几十年前，其实只是几年前。第二阶段是模型能改文件、跑命令，直接在终端里工作。第三阶段是编程 agent 有了专门的应用，大家开始同时跑很多个，甚至放到云上，但人仍然是瓶颈，因为每一条命令你都要审。现在是第四阶段：agent 有自己的电脑、自己的记忆，能在工作中学新技能，你去睡觉了它还在干。

我觉得这里最关键的变化，是人在循环里的位置变了。以前是你提示一次，等一次，它要跑命令，你点批准或者拒绝。Lee 说现在你可以直接“引导”它：先说“去看看这个帖子”，紧接着又说“对了，这事周四再做”，以前的模型会被这种打断弄糊涂，现在它们能像朋友听你絮絮叨叨一样，听出这两句话是相关的。至于发邮件、发消息这类事，有一层 auto review（自动审查），本质上是另一个 AI 模型在检查每一条命令。Lee 觉得这反而比人更安全，因为人要面对几百条 shell 命令，会疲劳；他甚至说，做一个盲测，多数时候是模型审得更好。

他还解释了为什么这类产品会叫 bot，并且突然火起来：因为每个人都会发短信。他们把和 AI 合作的方式简化成像给朋友发短信，可是背后它真的可以替你完成一件需要交接给同事的长任务。我觉得这个解释很朴素，也很准确：技术越强，界面反而越简单，用户需要学的东西越少，门槛才降得下来。

模型有了哪些变化，才让这件事成为可能

Lee 讲了六个模型层面的变化。第一，模型在过去一两年里，越来越能在很长的时间里持续遵循指令而不糊涂，配合压缩（compaction），可以放心地跑几个小时甚至几天。第二，模型可以把任务交给帮手，这些帮手叫 sub-agent（子智能体）。因为模型自己的工作记忆，也就是 context window（上下文窗口）迟早会被填满，把花费大的活儿交给一个全新记忆的帮手，做完再回来汇报，就近似得到了无限的上下文。

第三，工具调用已经好太多。他说几年前模型基本不会调工具，还总是产生幻觉，现在大家几乎不再谈幻觉了，因为它基本上算是解决了。第四，可以像给新同事配装备一样给它很强的工具：shell 命令、文件，甚至一整台 Linux 电脑，让它像人一样点屏幕、录演示视频，这就是 computer use（电脑操作）。这意味着，任何没有开放 API 或者 MCP 服务器的网站和软件，也可以被它无头地使用。

第五，信息可以全部存在文件里，因为模型很擅长用 Linux 命令去搜索文件。他举的例子是：用户画像会放在每一次提示里，比如你喜欢全小写的短信风格；工作日志像同事每天记笔记一样存成文件，你问“我上周做了什么”，它就自己去翻。第六，你只要给它演示一遍怎么做，它就能把这件事变成可复用的 skill（技能）、记忆或者 routine（例行任务）。skill 就是把做某件事的具体流程写进一个 markdown 文件，routine 则像 cron job，按时间表跑某个提示。

他把这些概括成一句话，“一切皆电脑”。我觉得这句话很有意思，因为它指出了这套东西的底层思路：不要为每一个能力发明一套新机制，而是把一切都落到文件、命令和一台真正的电脑上，模型已经很擅长这些了。这和我们对 AI 的传统想象很不一样，传统想象里，AI 是一个特别的系统；而在这里，它更像一个会用电脑的人。

一个永远在线的 agent，怎么醒来、怎么睡去

Lee 把“永远在线”拆开来讲，其实它并不是一直开着。服务器和 agent 能用的那台电脑，平时都是睡着的。你发来一条消息，或者某个触发器叫醒它，系统才加载这个 agent 的所有状态，把它启动起来；它需要用浏览器或者点屏幕的时候，才把那台电脑也启动；用完了，两样都可以再睡回去。原因很现实：让每个人的电脑一直开着，既贵，世界上也没有那么多计算机。状态则保存在数据库里，包括对话记录、记忆、例行任务。

叫醒它的方式有很多。你直接给它发消息当然可以，但他觉得更有意思的是后台别的东西来叫它：有人在 Slack 里找你，有一个电话或会议，或者一个跑了几小时的后台任务要给你一个总结。他还提到，在 SpaceX 现在常见的情形是，员工本来能去开会，但选择让自己的 bot 去开会、做记录，回头再汇报给他，他自己也觉得挺好笑。

所有这些事件会先进入一个 router（路由），去重，再放进对话里，同时有一套启发式规则判断：这件事需不需要打扰用户？Lee 的比喻很直白：同事每有一点进展就来找你说“快看，我有进展了”，你肯定烦，大多数任务一天一次状态更新就够了。

那台电脑，他说跑的是 Firecracker 虚拟机，好处是很容易把整台机器的状态做成快照，关掉再起来。你可以连上去看它的实时画面，必要时亲自接管。它有文件、能跑命令、有 Chrome，而且可以有虚拟桌面，所以你同时跑五个、十个 bot，每个都能有自己的屏幕。我觉得这里的关键是，你不想把这些命令放在自己的笔记本上，而是放在一个被锁定、与你隔离的环境里。agent 在那里怎么折腾，都不会弄脏你的电脑。

为什么 agent 要跑在服务器上，用什么保证不掉链子

这套架构的核心是 thin client、thick server，也就是客户端很薄，服务端很厚。Lee 给了几个理由：要更新 agent 的代码，推一次服务器更新比推一次 App Store 更新快得多；转写、图片生成这类重计算在服务器上通常更快；服务器的扩容方式也有成熟的做法。但最关键的一点是，如果 agent 的循环就跑在虚拟机里，你就没法独立地关掉那台虚拟机。比如要给虚拟机打一个紧急的 Linux 零日补丁，你希望能直接重建虚拟机，而不会把整个 agent 循环一起清掉、让应用停机。所以所有东西都存在服务器上，随时可以重建那台机器。

他还讲了一个我觉得很值得记的基础设施概念：job queue（任务队列）和 durable workflow（可持久化的工作流）的区别。你让 agent 去做一个复杂任务，要走第一步、第二步、第三步，中间碰到了基础设施故障。普通队列崩溃之后重启，要把一二三步重放一遍，这会出很多问题；而 durable workflow 是可以安全重试的，失败之后会直接从第三步接着做。他们用的是一个开源工具 Temporal，没有自己从头造这套复杂的东西。

消息的优先级也有讲究。你对自己的 bot 说“其实把那个活动的日期改一下”，系统要让当前的 agent 循环立刻停下来，你的消息优先于其他一切；而群聊、Slack 线程或后台例行任务的消息，就排到队尾，如果短时间进来三四条，还可以合并成一轮处理。

我觉得这一节让我意识到，一个“看上去像聊天”的产品，底下的工程重点其实是“不丢状态”。用户感受到的是可靠，它背后是一整套让任务能被打断、能被恢复的设计。agent 要干几周甚至几个月，这种可靠性不是锦上添花，而是前提。

这套 harness 有什么不一样

这是我觉得整场分享里最有意思的设计。Lee 说，Grok Bot 的 harness 和市面上类似工具最大的区别在于：客户端和服务器之间只有一个工具，就是 send to user（发给用户）。重的工具，比如跑 shell 命令、读文件、调用云端 agent、录屏、做演示，全放在服务器上。好处是架构上非常简单，不管客户端是手机应用、桌面应用、邮件还是 Slack，都只用这一个工具来回沟通；而客户端收到之后，可以决定怎么展示得更丰富，比如弹出登录表单、对接密码管理器，需要付费时调用支付服务。遇到发邮件、发 Slack 这种不可撤销的事，就先让你编辑、批准一份草稿，有时候只用一个表情回应就够了，根本不用发消息。

第二个关键是 dynamic tool discovery（动态工具发现）。Lee 解释说，模型的上下文窗口就是它的工作记忆，有 token 上限。如果你把 Google Drive、Gmail、YouTube 这些连接器的所有工具定义，包括名字、参数结构，全塞进去，窗口早就被占掉一大半，模型留给真正干活的空间就少了。现在不少主流 harness 的做法是，每条消息里只放工具的名字，模型决定要用哪个，再去文件里读详细信息。这样既省上下文，也省成本。

第三个，是他总结的一条原则：先试最便宜、最可靠的办法，再一级一级往上爬。第一级是 bot 凭对话历史已经知道的东西；不知道就看有没有插件、MCP 服务器或 API 可以拉，比如从 Plaid 拉银行信息；不行就去网上搜，比如昨晚小熊队的比分；再不行就去那台电脑上开浏览器搜；最后才是动用整个桌面，在 Linux 机器上写脚本、造东西。所有办法都失败了，才去打扰用户，让你输入或批准。

在电脑上读取信息也有梯度。截图是最直接的，但更省的办法是读页面的 HTML，或者读 accessibility tree（无障碍树），它能大幅减少 token，帮你找到按钮和链接。实在不行才去点像素，比如网站弹出一个必须点的对话框。碰到两步验证码、CAPTCHA，就回头找用户。

我觉得这套“能力阶梯”的思想，其实比任何具体技术都值得学：每一步都问自己，有没有更便宜的办法。这也是一个好同事的素质，不是什么都交给上级，而是先自己排除可能。agent 要让人愿意长期用，就要让用户觉得“它很少烦我，而一旦来找我，就是真的需要我”。

怎么把上下文省下来

Lee 把 context engineering（上下文工程）和 harness engineering 看成几乎同一件事，目标都是尽量少用上下文，这样更高效、更省钱。主 agent 是你长期对话的那一个，要保持稀疏，所以重活儿都交给子智能体。让子智能体去跑一堆 shell 命令、做很多昂贵的工具调用，这些过程都不会撑大主 agent 的对话，只带回一个结果。这就是产品看起来有“无限上下文”的原因，他说无限上下文当然不存在，每个模型都有上限，但靠这些技巧，再加上专门训练模型，用户不会感觉到撞上了上限，也不会感觉到越往后质量越差。

每个子智能体本身也是一个 durable workflow，崩溃了、内存用爆了，重启后接着干，不丢进度。主 agent 就像一个同事在管一份待办清单，你可以去查进度、发消息、停掉某个帮手。他说这很大程度上是照着“怎样扩大一个工程师团队去解决复杂问题”的理想方式来设计的。

接着他讲了 prompt caching（提示缓存）。使用 agent 时，每次其实都是把整段对话重新发一遍，只多了一条新消息，所以绝大多数 token 理想情况下都是被缓存的，模型提供商对缓存的 token 有很大折扣。因此要尽量让工具定义、系统提示在不同调用之间保持不变，不要破坏缓存。他的说法很重：“缓存没命中，其实就是系统里的一个 bug。”他还回忆说，今年一月 OpenClaw 很火的时候，大家在订阅套餐里用它，这是模型提供商没见过的新用法，harness 也还没为这种一直在跑的工作流优化过，缓存没命中很多，后来补了很多修复。

他分享了几个小技巧：给提示里的每一段做哈希、固定顺序，这样做 A/B 测试加一段新提示，也不会打乱其他人的提示顺序；用户在输入框里刚开始打字时，服务器就可以提前准备提示、预热缓存，就像鼠标悬停在链接上时提前预取下一页。还有一个我很喜欢的：当缓存还热的时候，趁机把长对话压缩好。因为对话已经超过十万 token，用户半小时后回来，就是从一个便宜得多的摘要接着聊了。

压缩本身，他说，所有的压缩都会丢信息，怎么压得好，可能值好几篇博士论文。他的记忆分了几层：每次都必须带上的核心事实，比如用户要求全小写；按日期记录的过往对话日志；还有只活半小时一小时的草稿式笔记；其余的都放在文件里，让模型需要时自己去查。他还说这其实有点像人脑：现在相关的事就留在脑子里，比如你此刻不会去想一场足球赛。

我觉得这一节最大的启发是，大模型的“智能”很大程度上是靠管理注意力来实现的。不是让模型记得更多，而是让它在每一刻只看到该看的东西，其余的放在需要时能找到的地方。这个思路对做产品的人很有用：别想着把所有信息都塞给模型，而是想怎么让它找得到。

模型和产品怎么互相推着进步

Lee 讲了一个他称为 flywheel（飞轮）的循环。训练一个大语言模型分几步：pre-training（预训练）让模型从大量文本里获得对世界的通用理解；supervised fine-tuning（监督微调）教它以某种方式行事，比如做聊天助手或 agent；最后是 reinforcement learning（强化学习），像教它玩游戏、越玩越好。对 always-on agent 来说，在微调阶段让模型见过 harness 的样子、知道自己有哪些工具，很有帮助；在强化学习阶段则要训练它更好地遵循指令，比如在几百个技能里选对该调用哪一个，在浏览器里点对位置。

推理（inference）也能分开优化。你正在聊天的主 agent，希望延迟尽量低、回得快；而交给帮手去做的长任务，花十分钟还是十二分钟差别不大。产品团队每天都在做的“内循环”是：agent 出错了，就把它变成一条评测（eval），修 harness、修提示或者查推理问题，在评测里确认修好，再发布。每隔几个月则有一个“外循环”：训练新模型，让它从这些失败里学习，在评测上爬升，再放进产品，新模型往往带来新的能力跳跃。

他提到他们在 Cursor、现在在 SpaceX 的一条原则，是“delete the product”（把产品删掉）。意思是你得认定，今天的模型是它们这辈子最差的时候，六个月之后你可能要把界面整个重做。他说今天这场分享，和六个月前甚至一年前相比，已经是很大的更新，因为他们学到了很多新的 harness 和 context engineering 的实践。所以策略是为下一代模型来建：尽量少建，让界面足够简单，让模型自己去想、去做。

我觉得“把产品删掉”是整场里最反直觉也最诚实的一句话。传统软件的价值积累在代码和功能上，越多越好；而在模型飞速变强的时候，你今天精心搭的脚手架，很可能明天就成了拖累。能保留的，是你对问题的理解和评测体系，其余的随时准备推倒。这对每一个想做 AI 产品的人都是一个提醒：别爱上自己的实现。

未来半年到一年，会有哪些变化和难题

Lee 对接下来六到十二个月做了几个他觉得算安全的押注。agent 现在能干几个小时或一天，他认为很可能很快就是几周甚至几个月，这会带来新的问题。模型对过往对话的回忆会越来越好，底层的表示可能是图、可能是文件，研究里有很多种路线。理想情况是，你把给一个新员工的所有工具，都给你的数字同事，不过他说组织还在适应这个想法。界面可能更简单，有的人会愿意直接对着 bot 说话。模型和产品也会越来越会在工作中学会技能，写进文件和指令里，公司也会更善于把各种定制化的流程写下来，让 agent 看得懂。

他还抛出几个可以拿去研究的问题。第一个很有意思：如果一个 agent 要跑一个月，可模型每个月都发新版，你怎么评测它？你没法完整评估它的行为是否符合预期，要么做出更好的评测，要么放慢发模型的节奏，他觉得这是行业未来六个月必须解决的问题。第二是记忆算法。第三是安全，怎么做出一个安全的 harness，怎么让围绕 agent 的基础设施不被坏人接管。他在讲安全时说，一封收件箱里的邮件可能是钓鱼邮件，一个 webhook 也可能来路不明，不能把它们当成用户指令送给模型，这方面行业要做的工作还很多，防提示注入（prompt injection）只是其中之一。

第四个，是 agent 什么时候该沉默、什么时候该打扰你的那套启发式，他坦率地说，还没做到完美。比如它看到你昨天没去上课，有录音、做了笔记，主动告诉你，这可能很有帮助，也可能很烦，怎么在主动和打扰之间走钢丝，是个没解决的问题。

他引用了 OpenRouter 的 Alex 在 X 上的一个说法：现在每个应用看起来都一样，侧边栏、agent、对话框，但这就像 2005 年，大家都在做一个服务器、一个数据库、一个增删改查的界面。每个新产品都要有 agent 的一面，要么集成它，要么变成一份给别的 agent 使用的“无头数据”。Lee 还列了一串新的基础件，从沙箱、云端电脑、记忆，到支付、身份、评测，每一块都有大量创业公司在做。

我觉得这段话有一层很实在的意思：agent 不是一个单独的功能，而是新一代软件的基础设施层。就像当年的服务器加数据库成了所有应用的标配，以后每一个产品都要想清楚，自己在 agent 的世界里是什么位置：是做 agent 的积木，还是成为被 agent 调用的数据。

我自己的一点思考

听完这场分享，我最大的感受是，always-on agent 真正新的地方，并不是它更聪明，而是它的“存在方式”变了。以前的 AI 是一个只在你开口时才出现的工具，现在的 AI 是一个有自己的电脑、自己的记忆、有自己的工作节奏的同事。Lee 讲的几乎所有设计，睡眠和唤醒、不打扰用户的启发式、先试便宜办法再爬梯子，都是围绕“一个靠谱的同事该是什么样”来的。

第二点是，整套架构有一种很克制的美。客户端和服务器之间只有一个工具，一切皆文件、一切皆电脑，主 agent 保持稀疏、重活交给帮手。他们没有为每个新能力造一套新机制，而是反复用同样几个简单的积木。这和他说的“为下一代模型而建，建得越少越好”是一致的：模型越强，脚手架越应该退后。

第三点是关于信任。Lee 在安全部分说得很平实：要让人把长时间的工作交给 bot，前提是信得过它。所以有独立的机器，有每条命令都过一遍的自动审查，不可撤销的事先问用户，密码这类东西放在模型对话之外。也许一个 agent 能不能真的被用起来，最终不取决于它能做多少事，而取决于你敢不敢睡觉前把事交给它。

它能干几周的活，前提是你敢放手，而你敢放手，靠的是它知道什么时候该来问你。