播客：Grok Bot 的常驻 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 进行翻译，因此可能会有一些地方不通顺