原作者：Lee（leerob），Stanford CS146S 讲座 · 原文链接：https://youtu.be/L1OBRtfPS34

学习笔记：Stanford CS146S —— How always-on agents work

主讲人：Lee（leerob；讲座中提到曾在 Cursor，现在 SpaceX）
链接：https://www.youtube.com/watch?v=L1OBRtfPS34
时长：45:17
来源：本笔记仅根据视频英文自动字幕整理

总览

上一讲（week one）里，学生搭了一个最简单的 harness：模型在循环里调用工具。它的缺点是合上电脑进程就停了。这一讲讲的是怎样把这个核心思路扩展成"常驻型"智能体（always-on agent，讲者称之为 bot）：它跑在云端服务器上，有自己的电脑和记忆，能被各种事件唤醒，可以连续工作很久。内容依次是：发展脉络和模型能力的进步、系统架构、harness 设计、上下文工程、训练飞轮与未来展望，最后给学生几条建议。

1. 什么是常驻型智能体 [0:00–2:37]

从终端到云端：不再只跑在你的终端里，而是跑在服务器或云上。你合上电脑它照样运行，能重启，也能从崩溃中恢复。
有自己的电脑：一台云端 Linux 机器，带桌面、文件、浏览器，可以把文件存在上面。
会积累记忆：随着时间了解你的工作进展和工作方式。
像同事，而不是问答机器：不会对每条消息都立刻回复，"knows when to be quiet"（知道什么时候该安静），可以先在后台干活，有重要进展再来找你。
多种触发方式：除了你打字，还可以被 Slack 消息、邮件或其他事件唤醒。
目标是长时间运行：不只是几小时、几天，甚至几周、几个月。这需要不同的架构。

2. 开发者与 AI 协作的四个阶段 [2:37–5:44]

从 ChatGPT 复制代码，粘到编辑器里。
终端里的简单 harness：能改文件、跑 shell 命令。
给编码智能体做专门的应用，多个智能体并行跑，也有跑在云端的。但人仍然是瓶颈，要逐条审核命令。
现在：常驻智能体在后台运行，有自己的电脑和记忆，在工作中学会新技能，你睡觉以后它还在干活。

交互方式的变化

以前是"发提示、等待"反复循环，碰到 shell 命令要你批准或拒绝。
现在可以插话引导（steer）：比如先说"去看看这个帖子"，紧接着补一句"其实周四再做"。老一代模型被这样打断会糊涂，现在的模型和 harness 能理解这两句是相关的。
Auto-review（自动审核）：由另一个 AI 模型检查所有要执行的命令。讲者认为，这比人看几百条命令看到疲劳反而更安全；盲测里多数时候模型审得更好。
一个看似矛盾的现象：模型越强，界面反而越简单。

"this type of always on agent we're calling a bot" 这种常驻型智能体，我们称之为 bot。

为什么这类产品火起来：人人都会发短信。和 AI 协作被简化成"像给朋友发消息"，但它能真的去干活，可以像交给同事一样交给它较长的任务，而不只是一问一答。

3. 让这一切成为可能的模型进步 [6:13–10:03]

讲者列了六点（他说实际上还有更多）：

长时间稳定地遵循指令：配合压缩（compression / compaction），可以放心地连续跑几小时甚至几天。
能把任务交给子智能体（subagents）：主智能体的工作记忆（上下文）终究会被填满。交给有一份全新上下文的帮手去做那些耗 token、耗工具调用的活，做完只回报结果，效果上相当于上下文"无限"。
工具调用更可靠：几年前模型很难调好工具，总会出现幻觉。

"you don't really hear people talk about hallucinations anymore because it's kind of a solved problem mostly" 现在已经不太听到有人谈幻觉了，因为这在很大程度上算是解决了。
可以给它很强的工具：就像给新同事开通权限一样，给一整台 Linux 电脑，让它录演示视频。Computer use（像人一样在屏幕上点击）让那些没有 API 或 MCP 服务的 SaaS 和网站也能被自主操作。
信息存进文件：模型很擅长检索和回忆文件里的内容。
示范一遍就能学会：把示范转成可以复用的技能、记忆或定时任务（routines）。

文件的例子

用户画像：每次提示都会带上。比如用户喜欢全小写的消息风格，那每条消息都得遵守。
工作日志：像同事每天记笔记一样。你问"我上周做了什么"，它直接去查。模型很会用 grep 之类的 Linux 命令搜文件。
技能（skills）：把怎么做好某件事的具体流程写成 Markdown 文件。已经有一个生态，很多公司和开发者在写技能，比如怎么写好一封邮件、怎么设计好的 API。
Grok Bot 有插件系统：插件用到技能或服务；routines 类似 cron，按计划执行某个提示。
讲者总结："everything is computer"（一切皆电脑）。

4. 架构：常驻是怎么实现的 [10:03–18:08]

4.1 生命周期：休眠与唤醒

初始状态下，服务器上的智能体和它的电脑都在休眠。
收到消息或触发事件时，加载并启动智能体的状态。如果它需要用电脑（比如浏览器），再把电脑也启动。
用完以后两者都可以重新休眠。原因是一直开着太贵，世界上也没有那么多电脑能给每个人一直开着。
对话记录、记忆、定时任务等状态都持久化到数据库。

4.2 触发源与路由

触发源：直接发消息、Slack 上有人找你、电话或会议（讲者说在 SpaceX，员工没空参会时让 bot 去记笔记的情况越来越常见）、跑了几小时或几天的后台任务完成后的汇报。
路由器负责去重，决定怎么把事件放进对话。
一个启发式判断：这件事值得打扰用户吗？不是每件事都重要。如果同事每推进一点就来找你，会很烦。视任务而定，可能一天一次进度更新就够了。

4.3 智能体的电脑

运行在 Firecracker 虚拟机上，好处是能方便地给机器状态打快照、关机和重启。
可以连进去看实时画面，自己也能操控。命令在一个隔离、锁定的环境里跑，而不是在你的个人电脑上。
有 Chrome，还支持虚拟桌面：同时跑 5 个、10 个 bot 时，每个都有自己的屏幕。底层是共享的基础设施。

4.4 服务端

左边是触发源，中间是服务器，右边是电脑。
消息进入队列，交给 agent loop（模型循环调用工具，也就是上一讲的内容），结束时把状态存进数据库或存储。
一个小小的核心循环，在上面叠加各种抽象、工具和服务连接，就成了一个强大的产品。

为什么 agent 循环放在服务端（瘦客户端、胖服务端）

更新智能体代码不需要发 App Store 版本，推送服务端更新就行。
转写、生图这类重计算，在服务器上通常更快。
怎么扩容服务器、应对流量波动，已经有成熟做法。
最关键的一点：如果循环跑在虚拟机里，虚拟机就没法独立于智能体单独关掉。所有东西都存在服务端，虚拟机就可以随时重建，比如要紧急打 Linux 零日漏洞补丁时，不会把整个 agent 循环搞掉、造成停机。

4.5 一次发送的流程（讲者说这部分较细，只是带过）

客户端立刻确认收到。涉及强一致性和最终一致性。
轮次中模型循环调用工具，结果存进数据库。
客户端订阅服务端的变化，收到信号后拉取最新数据。重试时要去重，避免显示重复消息。

4.6 关键基础设施：持久化工作流 vs 任务队列

普通任务队列：任务做到第 3 步时基础设施出问题崩溃，重启后要把第 1、2、3 步重放一遍，可能出问题。
持久化工作流（durable workflow）：可以安全重试，失败后从第 3 步接着做。
他们用开源的 Temporal，省得从零造轮子，但基础设施仍然要自己运维。

4.7 消息优先级 [17:25]

用户本人发给自己 bot 的消息优先级最高。比如"把这个活动的日期改一下"，会让正在跑的循环停下来。
群聊、Slack 线程、后台任务等其他来源的消息排到队尾。
短时间内连着来的三四条消息可以合并成一轮处理，启发式规则可以自己定。

5. Harness 设计 [18:08–27:26]

5.1 只有一个跨端工具：send user

客户端和服务端之间只通过一个工具通信：send user。架构很简单，客户端就像在给服务端发短信。
重的工具都在服务端：跑 shell、读文件、调用云端智能体、录屏、做演示等。
不管新加的是手机、服务端、桌面、邮件还是 Slack 客户端，都只用这一个工具。
客户端可以把内容渲染成丰富的交互界面：登录表单（接 1Password 之类）、支付（Stripe Link、X Money 等）、不可撤销的操作（发邮件、发 Slack）先给出草稿让你编辑和批准；有时只用一个表情回应就够了。

5.2 动态工具发现（dynamic tool discovery）

上下文窗口是模型的"工作记忆"，有 token 上限。
每个工具都要占名字、schema 等描述。装了 Google Drive、Gmail、YouTube 等一堆 MCP 连接器以后，上下文一大块已经被占满，留给真正对话的空间就少了。
做法（也叫 "tool search tool"）：每次只放工具名，模型决定要用时再去读完整定义（"文件和文件系统一路到底"）。
好处是省上下文、省成本、省用量。

5.3 能力阶梯：先试最便宜、最可靠的

对话历史里已经有的信息
插件、MCP 服务或 API（比如通过 Plaid 拿银行信息）
网页搜索（比如"昨晚小熊队的比分"）
在电脑上打开浏览器去搜
用整台桌面跑脚本、跑命令、做东西
以上都不行，才去找用户要输入或批准

这样用起来更像和同事合作：他们会先自己把这些办法都试一遍。

5.4 从电脑获取信息的方式 [22:37]

截屏；看页面 HTML；看无障碍树（accessibility tree），能大幅减少 token，便于找到按钮和链接。
都不行就按像素坐标点击，比如处理弹窗。
最坏情况是回来找用户，比如碰到双因素验证码或 CAPTCHA。

5.5 主智能体 + 帮手（子智能体）[23:30]

主智能体是编排者（orchestrator），对话要尽量保持精简。
交给帮手做的大量 shell 命令和昂贵工具调用，都不会撑大主智能体的上下文，回来的只有结果。这就是"感觉上下文无限"的由来，虽然每个模型都有上限。如果专门训练模型擅长这一点，越往后也不会感到质量下降。
每个帮手各有技能，各自是一个持久化工作流：比如视频帮手内存爆了崩溃，可以重启继续，进度不丢。
主智能体像同事一样管一份待办清单，可以查看帮手进度、给它发消息、叫停它。整体参照的是怎样扩展一支工程师团队去攻克复杂问题。

5.6 团队实践中的经验 [25:14]

为了提示缓存，轮次中间不要增删工具。
工具描述和 schema 太长会占很多上下文，对价格和用量都不好，要尽量精简。
"只给一个 shell 工具"确实能覆盖很多场景。但如果模型 90% 的时间都在用 shell 做同一件事，给它做一个专门的工具会更高效，人审查时也更清楚。
给人看的错误信息要写清楚"哪里失败了、下一步怎么做"，结果这对智能体同样有用。为智能体设计好的错误信息，本身也是一种开发者体验（DX）。

5.7 安全 [26:30]

即使智能体在独立的机器上跑、不污染你的电脑，也最好有模型在每条 shell 命令执行前审核（auto review）。
邮件（可能是钓鱼邮件）、webhook 这类不可信输入，不能当成用户指令交给模型。防提示注入，整个行业还有很多工作要做。
发邮件这类不可撤销的操作要先问用户。
在产品流程上把密码等敏感信息挡在模型对话之外。

6. 上下文工程（也叫 harness 工程）[27:26–34:27]

6.1 提示缓存（prompt caching）

每次请求都会把整段对话重新发一遍，只是在末尾加了一条新消息。所以理想情况下，大部分 token 都应该命中缓存，而缓存 token 价格有很大折扣。
做法：工具定义、系统提示等尽量保持静态，只为最新这条消息付未缓存的费用。
主智能体是你那条"非常非常长"的对话，会在你察觉不到的情况下被压缩很多次，所以上下文一定要保持小。
保持上下文小的办法：长输出写进文件（模型很会读文件，就像读技能、读记忆一样）；截图等昂贵的工作交给帮手；随时"修剪"掉不需要的内容，既为了成本，也为了回忆效果和模型表现。

"if there's a cash cache miss, it's kind of like a bug in the system really"（字幕原文如此，"cash" 为识别错误）缓存没命中，其实就相当于系统里的一个 bug。

背景：今年 1 月 OpenClaw 很火，大家在模型厂商的订阅套餐里用它。厂商没见过这种用法，harness 也没针对它优化，缓存未命中很多。智能体一直在跑，这个问题就很严重，后来做了大量修复。
技巧一：提示各段落的顺序固定，可以对每一段做哈希。比如做 A/B 测试新增一段提示时，不能打乱其他所有人的提示顺序，否则缓存就失效了。
技巧二：你一打开聊天开始打字，服务端就提前准备提示、预热缓存，类似网页在鼠标悬停时预取下一页。
这些小优化叠加起来，决定了模型在长时间使用中能走多远、有多聪明。

6.2 压缩（compaction / summarization）[31:33]

比如上下文窗口是 20 万 token，跑着跑着总会到需要总结的时候。

"all compression is lossy" 所有压缩都是有损的。

难点在于找到一种压缩算法，不丢重要细节。讲者说这大概能单独做几篇博士论文。
技巧：趁缓存还热时提前压缩。 厂商的缓存窗口可能是 10 分钟或 60 分钟。对话已经超过 10 万 token、用户暂时离开时，就趁现在做压缩，因为这时最便宜。用户 30 分钟后回来，就从摘要接着聊，后续每条消息都更省。

6.3 分层记忆 [32:52]

核心事实：每次都必须带上，比如"用户总要全小写"。要有某种"垃圾回收"机制决定保留哪些事实，类似人脑只把和当下相关的东西放在脑子里。
按日期的日志：过去的对话历史。
草稿笔记（scratchpad）：设计成临时的，可能只在接下来 30 分钟到 1 小时有用。
其余一切都靠文件检索：模型很会用命令去查。

7. 未来：训练飞轮 [34:27–38:33]

7.1 训练阶段回顾

预训练：从大量互联网文本和其他数据中学到对世界的一般理解。
监督微调（SFT）：教模型按某种方式行事，比如做聊天助手或智能体。对常驻智能体来说，可以让它见到 harness 的示例，熟悉可用的工具。
强化学习（RL）：像教模型玩游戏，提升指令遵循能力；在几百个技能里选对那个；在浏览器里点对位置。

7.2 推理部署也可以调

和你直接对话的主智能体要低延迟、快速回复。
交给帮手的长任务里，10 分钟和 12 分钟差别不大，可以按不同目标去优化。

7.3 两个循环

内环（每天）：智能体出错 → 写成 eval → 修 harness、提示或推理问题 → 在 eval 上确认修好 → 上线。
外环（每隔一段时间）：训练新模型，让它从这些 bug 和失败中学习、在 eval 上提分，然后换进产品。新模型会带来能力跃升，解锁新的用法。
例子：bot 在群聊里的训练数据还很少，这是一个正在摸索的新场景。讲者提到 multbook、Hugging Face 事件这类出过问题的案例，所以要教会模型在多智能体系统（bot 之间互相对话）里表现得体。

7.4 原则："delete the product"

"the models today are the worst they'll ever be" 今天的模型是它们有史以来最差的。

意思是要默认 6 个月后可能得把 UI 整个重做。这次讲的大部分内容，和 6 个月前、更别说一年前讲的版本相比，变化都很大。
策略：为下一代模型而构建，自己尽量少造东西，做一个非常简单的界面，让模型替你思考和行动。

8. 未来 6–12 个月的预判与开放问题 [38:33–43:23]

预判（讲者认为比较稳妥的判断）

智能体的工作时长从几小时、一天，变成几周、几个月。
模型回忆历史信息的能力会更好，底层数据可能是图、文件或别的形式。
像入职真人一样，把你有的所有工具都给"数字同事"，组织还在慢慢接受这个想法。
界面更简单，有人会更喜欢语音对话，讲者还提到 Jony Ive 的设备。
模型和产品更擅长在工作中学技能、写进文件。个人和公司也会更擅长把定制流程写下来，让智能体看得懂。

开放问题（可以作为研究方向）

一个要跑一个月的智能体，模型却每个月都在更新，怎么评估？要么做出更好的 eval，要么放慢发布节奏。讲者认为这是行业未来 6 个月要解决的问题。
记忆算法。
安全：harness 和基础设施怎样防止被坏人接管。
什么时候沉默、什么时候打扰用户的启发式规则还不完美。比如"你昨天缺课了，我录了音、做了笔记"，可能有用，也可能有点烦，平衡还在摸索。
一年后 token 用量会大幅增加，优化推理、模型和 harness 来压低 token 消耗会非常重要。

新的基础构件：讲者提到 OpenRouter 的 Alex 在 X 上的观点。有人说现在每个应用都长一个样：侧边栏、智能体、聊天框。这就像 2005 年说"大家都有服务器、数据库和增删改查界面"一样，这就是新常态。每个新产品都会有智能体的一面，要么集成智能体，要么成为别的智能体使用的无界面数据源。持久化工作流、沙箱、云电脑、记忆、技能、服务连接、语音、支付、身份、eval、可观测性，每一块都是巨额投资和大量创业公司在做的新基础构件。

9. 给学生的建议 [43:23–45:17]

重视系统设计和架构，这些决定会产生复利。讲者自己仍然坚持看代码，认为这有助于理解所交付的架构。
自己动手搭一个 harness，把今天讲的思路用进去。讲者说 GitHub 上大概有人做了 "open grokbot"，可以配沙箱、虚拟机等来练手。
学一点 LLM 的工作原理，不必深入 ML 研究。就像写 Web 应用要懂数据库一样，harness 和产品层面的很多决定都受模型本身影响。

Stanford CS146S：How always-on agents work（leerob）