#772. Grok Bot 的 Personal Agent 实践

📝 本期播客简介

本期我们克隆了：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 进行翻译，因此可能会有一些地方不通顺