揭秘常驻AI智能体：持久化、主动性与长时任务架构

从终端脚本到数字同事

斯坦福 CS146S 课程中，来自 SpaceX 的工程师 Lee 系统拆解了一类正在崛起的新型 AI 产品——常驻型（always-on）、主动式、持久化智能体的工作原理。它与上周课程中学生们亲手搭建的"简易 harness"（模型在循环中调用工具）形成鲜明对比：传统 harness 一旦合上笔记本就停止运行，而常驻智能体跑在云端服务器上，可以在你关机、重启甚至崩溃之后继续工作。

讲者将这类智能体称为"bot"。它拥有自己的云端 Linux 机器（含桌面、文件、浏览器），能保存文件、积累对你工作方式的长期记忆，更像一位同事而非问答机器人——它知道何时该保持安静，只在有重要进展时才打扰你，并且可以由 Slack 消息、邮件或其他事件唤醒，而不只是靠你在终端里敲命令。目标是让它持续工作数周甚至数月。

AI 开发者的四个时代

Lee 把开发者与 AI 协作的演进划分为四个阶段：第一是从 ChatGPT 复制粘贴代码到编辑器；第二是模型获得编辑文件、运行 shell 命令的能力，形成简单的终端 harness；第三是编码智能体拥有专属应用、可并行运行多个实例，但人类仍是瓶颈，需要逐条审批每个命令；第四就是现在的常驻智能体时代——它们在后台 ambient 运行，拥有自己的计算机、记忆，边工作边学习新技能。

一个关键变化是交互方式。过去是"提示—等待—批准命令"的队列模式，现在则是"引导式"（steering）：你可以随时打断补充，比如"去看看这个线程，顺便周四再做那件事"。早期模型会被这种打断搞糊涂，如今的模型和 harness 已能像朋友聊天一样解析这些关联指令。

对于发邮件、发 Slack 等操作，业界引入了"auto review"——由另一个 AI 模型检查所有待执行命令。有趣的是，相比人类面对数百条 shell 命令时产生的审批疲劳，模型的检查反而更安全、往往做得更好。

支撑常驻智能体的六项模型能力

Lee 列举了近一两年促成这一转变的核心模型进步：

• 长程指令遵循：模型能连续运行数小时乃至数天而不混乱，配合压缩与压实（compaction）技术保持稳定。
• 子智能体（subagent）协作：主智能体可将耗费大量 token 或工具调用的任务交给拥有全新工作记忆的"助手"，助手只返回结果，从而逼近"无限上下文"的体验。
• 强大的工具调用：几年前模型还频繁幻觉、几乎无法可靠调用工具，如今幻觉几乎成为"已解决"的问题，模型甚至能像人一样操作完整 Linux 电脑。
• 计算机使用（computer use）：模型可点击屏幕，让任何没有 API 或 MCP 的 SaaS 和网站也能被无头化、自主地操作。

• 文件化记忆：所有信息存入文件，模型擅长用 shell 命令 grep、搜索来召回。用户画像（如"喜欢小写文本"）会进入每条提示，工作日志则按需检索。
• 技能与例程：把完成特定任务的 know-how 编码成 Markdown 技能文件，已形成由公司和开发者共建的技能生态；routine 则类似 cron job，按计划触发提示。GrokBot 还设有插件系统，任何工具都能通过技能或服务器安装。

计算机使用（computer use） 能力的实现路径值得深入说明。模型并非直接操控鼠标和键盘，而是通过截图或读取界面可访问性树（accessibility tree）来"观察"屏幕状态，然后输出点击坐标、键盘输入等操作指令，再由 harness 层执行并返回新的截图，形成感知-决策-执行的闭环。Anthropic 于 2024 年率先在 Claude 3.5 中开放了这一功能，称为"Computer Use"API。可访问性树是操作系统为辅助技术（如屏幕阅读器）暴露的 UI 结构化描述，包含按钮名称、文本框内容等语义信息，比截图更省 token，也更适合模型理解界面语义。MCP（Model Context Protocol） 则是 Anthropic 提出的开放协议，让模型能以标准化方式接入外部工具和数据源，类似 USB-C 之于硬件外设，本文中提到的"没有 API 或 MCP 的 SaaS"即指不支持此类结构化接入的服务，只能退而求其次用计算机使用来操控。

"永远在线"背后的系统架构

所谓"always-on"，并非真的 7×24 空转。讲者给出一条从左到右的状态流：服务器与智能体的专属计算机默认处于休眠，收到消息或触发器后才启动并加载状态；需要浏览器时再唤醒计算机；用完则可将二者休眠，状态（对话日志、记忆、例程）持久化到数据库。这样设计是因为全世界没有足够的计算机让每个人常驻运行，服务器开销也极大。

唤醒方式越来越丰富——除了直接提示，Slack 消息、电话、会议都能触发。SpaceX 内部已常见员工派 bot 去参会做笔记。一个 router 负责去重并判断"是否需要打扰用户"，就像好同事不会每取得一点进展就来汇报。

智能体的 Linux 机器运行在 Firecracker 虚拟机上，便于快照、关机与重启；可连入实时查看甚至手动接管；多个 bot 还能各自拥有虚拟桌面与独立浏览器。

架构上采用"瘦客户端 + 厚服务器"：命令进入队列，调用"agent loop"（模型在循环中调工具），关闭时存档到数据库。把 agent loop 放在服务器而非虚拟机上至关重要——这样做零日安全更新、重建 VM 时不会连带智能体服务一起宕机。底层还区分作业队列与持久化工作流：普通队列崩溃后需重放步骤一二三，而使用开源工具 Temporal 构建的 durable workflow 可在失败后从第三步直接续跑。

Firecracker 是由 AWS 开源的轻量级虚拟机监视器（VMM），基于 Linux 的 KVM 技术构建。它专为无服务器（serverless）和容器化工作负载设计，启动一个 microVM 通常只需不到 125 毫秒，内存开销也远低于传统虚拟机。与 Docker 容器相比，Firecracker 提供了更强的硬件级隔离（每个 VM 拥有独立的内核），同时保留了近似容器的启动速度。对常驻智能体而言，这意味着可以快速为每个用户创建一台"私有 Linux 机器"，在空闲时制作快照并休眠以节省算力，在收到触发信号后毫秒级恢复，兼顾安全隔离与成本效率。AWS Lambda 和 Fly.io 等云服务底层均使用 Firecracker。

Temporal 是一个开源的持久化工作流编排框架，最初由 Uber 工程团队开发。它的核心思想是"工作流即代码"：开发者用普通编程语言编写业务逻辑，Temporal 负责将每一步执行状态持久化到数据库，程序崩溃或服务重启后可从断点续跑，而无需重放全部步骤。对比普通消息队列，后者崩溃后必须从头重试，Temporal 则允许直接从失败点恢复，极大降低长时运行任务的风险。这对需要跨天、跨周执行的智能体任务至关重要。

Harness 的工程艺术与上下文优化

GrokBot harness 的最大特点是客户端与服务器之间只有一个工具 send-to-user 相互通信，架构极简：客户端只是"给服务器发短信"，繁重工具都放在服务器端。无论是移动端、桌面端、邮件还是 Slack，都用同一接口对话，再由客户端决定如何富交互地展示（登录表单、Stripe 支付、邮件草稿审批、甚至只回一个 emoji）。

上下文窗口是模型的工作记忆。若把 Google Drive、Gmail、YouTube 等所有工具 schema 全塞进去，就会挤占对话空间。解法是"动态上下文 / tool search tool"：每条消息只放工具名称，模型需要时再读取详情，节省 token 与成本。整体原则是"先试最便宜最可靠的办法"——先用已知的对话历史，再到插件/API，再到网页搜索，再到打开浏览器、动用整台桌面，实在不行才回头打扰用户。

浏览器信息检索也有三种由省到费的方式：读取可访问性树（accessibility tree）最省 token，其次是 HTML，最后才截图或直接点击像素。

主智能体像"编排者"，应尽量保持对话稀疏，把昂贵工作下放给各具技能的 subagent，每个助手都是独立的 durable workflow，崩溃可恢复。几条实战经验也很有价值：turn 内不要增删工具以免破坏缓存；若模型 90% 时间在跑同一类 shell 命令，不如做个专用工具；给智能体写清晰的错误信息，和给人写一样重要。

Prompt caching 是降本关键。大部分 token 其实是缓存命中——每次只在对话末尾追加新消息。保持系统提示、工具定义尽量静态、顺序固定（甚至对每段做哈希、A/B 测试时也不打乱顺序），就能最大化缓存。还有个巧招：用户开始打字时服务器就提前预热缓存，类似网页链接预取。讲者回顾今年初 OpenClaw^广告 流行时出现大量 cache miss，正是因为模型服务商此前没见过这种常驻用法。

压实（compaction） 不可避免——假设 200K 上下文窗口终将填满，就必须做有损压缩而不丢关键细节。一个技巧是趁缓存仍"温热"时就先行压实，用户回来时直接从摘要续谈，更便宜。记忆被分层组织：必带的用户核心事实、带日期的历史日志、临时的 scratch pad 笔记，其余一律通过文件查找——这颇似人脑对信息的垃圾回收。

Prompt caching 是主流大模型 API 提供商（包括 Anthropic、OpenAI）推出的降本机制。其原理是：模型在处理请求时，对已处理过的 token 序列生成 KV 缓存（Key-Value Cache），若后续请求的前缀与之完全一致，则直接复用缓存结果，跳过重新计算，费用通常降至正常价格的 10%–25%。这要求提示词的"静态部分"（系统提示、工具定义等）必须保持字节级完全一致，哪怕插入一个空格都会导致缓存失效（cache miss）。文中提到 OpenClaw 流行时出现大量 cache miss，正是因为常驻智能体的用法让系统提示持续变化，超出了模型服务商最初为短会话设计的缓存假设。用户开始打字时服务器提前预热缓存的技巧，本质上是在用户输入完成之前就发起一次"假请求"以触发缓存填充，类似浏览器的 DNS 预解析或链接预取（prefetch），属于典型的延迟隐藏（latency hiding）工程手法。

训练飞轮与未来走向

Lee 复习了 LLM 的训练三阶段：预训练学世界知识、监督微调学行为方式、强化学习学"玩游戏"。对常驻智能体而言，SFT 阶段让模型见识 harness 与可用工具，RL 阶段提升指令遵循、从数百技能中选对技能、在浏览器里点对位置。推理服务也可差异化：主智能体要低延迟快速回应，而后台助手跑 10 分钟还是 12 分钟差别不大。

整个产品靠"内外双环飞轮"迭代：内环是团队每天发现 bug、用 eval 衡量、修复 harness/提示/推理后发布；外环是每隔数月训练新模型，让其在 eval 上持续攀升并解锁新能力（如群聊中多 bot 协作——Mojibake、Hugging Face 事件都显示这里容易出岔子）。

讲者分享了在 Cursor 和 SpaceX 都奉行的原则——"删掉产品"（delete the product）：要假设今天的模型是未来最差的，六个月后可能需要彻底重建 UI，所以应为下一代模型构建尽量轻薄的界面。他对未来 6–12 个月的判断包括：智能体工作时长从数小时延伸到数周数月、记忆召回算法持续改进、接口可能走向语音对话、模型更擅长在岗学习并编码技能。

一个尖锐的开放问题是：当智能体要运行一个月、而模型每月更新时，该如何评估它？ 要么做出更好的 eval，要么放慢发模型的节奏。此外还有记忆算法、harness 安全（防提示注入、防被恶意接管）、以及"何时沉默何时打扰"的拿捏。

引用 Open Router 的 Alex 的观点：有人抱怨如今每个 app 都长一样（侧边栏+智能体+聊天框），但这就像 2005 年人人都在搭"服务器+数据库+CRUD 界面"——这正是新常态。durable workflow、沙箱、云端计算机、记忆技能、语音、支付、身份、评估、可观测性，每一个方框都对应数十亿乃至数万亿美元的 VC 资本和 20 家创业公司，它们是下一代产品的新原语。

给工程师的三条 takeaway：系统设计与架构比以往更重要，这些决策会复利放大；动手 fork 开源 GrokBot、配上沙箱和 VM 亲自搭一遍；别回避去理解 LLM 的运作原理——正如建 web app 要懂数据库，如今大量产品与 harness 层的决策都受模型本身影响，建立这种直觉会让你在任何岗位都更有优势。

文中提到的训练三阶段对理解模型能力的来源至关重要。预训练在海量互联网文本上进行无监督学习，赋予模型语言理解与世界知识，但此阶段的模型行为不可控，输出更像"续写"而非"对话"。监督微调（SFT） 使用人工标注的高质量对话示例训练模型"如何回答"，让其学会遵循指令、使用特定格式和工具；对常驻智能体而言，SFT 数据集会包含 harness 调用日志，让模型内化工具使用的规范。强化学习（RL） 阶段（以 RLHF、GRPO 等为代表）则通过奖励信号让模型在"玩游戏"中不断优化策略——例如在浏览器任务中点击正确目标获得奖励，错误操作受到惩罚。这一阶段对智能体能力的跃升尤为关键，文中所述"推理时差异化"策略（主智能体要低延迟、后台子智能体可慢跑）也与 RL 训练出的模型对延迟的不同敏感度有关。