Show notes
📝 本期播客简介
本期我们克隆了:leerob · Stanford CS146S: How always-on agents work
原内容更新时间:2026-10-11
合上电脑之后,AI 还能继续工作吗?Lee 想搭建的常驻 Agent,不只在云端持续运行,还能记住你的工作方式、处理 Slack 消息和邮件,并判断什么时候该来找你。
这场分享从常驻 Agent 的产品形态讲到背后的工程设计:云端电脑如何休眠和恢复,主 Agent 怎样把任务交给子 Agent,工作流如何在故障后接着执行,以及团队如何用上下文压缩和 prompt 缓存控制成本。最后还谈到长期运行带来的安全、评估和打扰频率问题。
👤 本期嘉宾
Lee(leerob)在 Stanford CS146S 分享如何搭建始终在线、能主动做事的 Agent。他谈到的工程实践来自 Grok Bot 的产品、基础设施与运行框架设计;他也提及自己在 Cursor 和 SpaceX 的经历,并说明部分内容仍在 SpaceX 开发中。
⏱️ 时间戳
00:02 常驻 Agent 的兴起
09:45 云端架构与持久工作流
18:55 运行框架与上下文工程
32:16 训练飞轮与未来挑战
🌟 精彩内容
💡 AI 同事不该每有进展就打扰你
常驻 Agent 可以在后台做事,遇到 Slack 消息、邮件或定时任务时醒来处理;它还要判断进展是否重要到值得通知你。
"如果每次有点进展,他都跑来打扰你,说,嘿,快看,我这件事又有进展了,那会挺烦的。"
💡 子 Agent 让长任务不挤满主对话
主 Agent 可以把大量命令和工具调用交给子 Agent,等它们完成后只接收结果。每个助手有独立的持久工作流,故障重启也能接着进度继续做。
"它只把结果传回来。这样做出的产品,就会让人感觉它有无限的上下文。"
💡 工作流崩溃后能从上一步接着做
普通任务队列遇到故障,可能要从头重跑;持久工作流会保存执行进度,失败后可以从已经完成的步骤继续。Lee 说他们使用开源工具 Temporal,避免从零实现复杂机制。
"这样你就可以安全地重试,失败以后再重试,会直接从第 3 步接着做。"
💡 每条命令都让人批准,未必更安全
模型可以先审查 Agent 要执行的命令。Lee 认为,相比人疲惫地盯着并逐条批准大量命令,自动审核有时反而做得更好;但发邮件等不可撤销的操作仍应先询问用户。
"这其实比让你疲惫地盯着几百条 shell 命令、逐条批准更安全。"
💡 上下文压缩,难在别丢掉重要信息
对话变长后,Agent 得把内容压缩成摘要,同时保留之后还用得上的细节。Lee 提到,上下文窗口达到二十万 token 也终究会用满,而压缩必然会损失信息。
"所以你得找到最好的压缩算法,避免丢掉重要细节。"
💡 Prompt 缓存失效会推高长期运行成本
工具定义和系统 prompt 尽量保持不变,能让缓存继续有效;对话很长时,还可以趁缓存仍热着先压缩上下文。Lee 把 prompt 顺序调整导致缓存失效称为一个系统里的 bug。
"所以,缓存没命中,其实就有点像系统里的一个 bug。"
🌐 播客信息补充
本播客采用原有人声声线进行播客音频制作,也可能会有一些地方听起来怪怪的
使用 AI 进行翻译,因此可能会有一些地方不通顺
在小宇宙查看该单集文稿