## 永远在线的 Agent 是怎么搭出来的 我们常用的 AI 编程助手有个明显软肋：合上笔记本它就停了。Lee Robinson 在斯坦福 CS146S … · @shuizhuyu · TwKit

@shuizhuyu

## 永远在线的 Agent 是怎么搭出来的 我们常用的 AI 编程助手有个明显软肋：合上笔记本它就停了。Lee Robinson 在斯坦福 CS146S 课上以 Grok Bot 为例，讲了 always-on agent（常驻智能体）怎么搭：把 agent 放上云端服务器，给它一台自己的 Linux 电脑，让它像同事而非聊天框那样在后台长期干活。 核心思路可以概括成一句“一切皆电脑”。不为每种能力造新机制，而是把工作都落到文件、shell 命令和一台真实机器上。agent 平时是睡着的，消息、Slack、邮件或定时任务通过 router 叫醒它，需要时再启动那台跑在 Firecracker 虚拟机里的电脑，用完双双休眠，状态存在数据库里。这样做的关键收益是隔离：agent 怎么折腾都在独立环境，不会污染你的本地机器。 支撑这套架构的模型层面变化主要有几点。子智能体（sub-agent）把昂贵操作放到全新上下文中执行，只带回结果，近似实现“无限上下文”；工具调用基本可用了；computer use 让没有 API 的网站也能操作；用户画像、工作日志都存成文件，需要时用 Linux 命令搜；演示一遍就能沉淀为 skill 或 routine。 Harness 上最值得看的是三点。一是客户端与服务器之间只保留 send to user 一个工具，重工具全在服务端，客户端只决定怎么展示；二是动态工具发现，提示里只放工具名，用时再去读定义，省下大量 token；三是一套“能力阶梯”：先查对话历史，再看插件或 API，然后搜索、开浏览器，最后才动桌面，全都失败才打扰用户。 可靠性靠 durable workflow（文中用的是 Temporal）：任务崩溃后从断点续跑，而不是重放前几步。官方还强调 prompt caching 很重要，缓存没命中等同于 bug，并会趁缓存热时压缩长对话。 这套设计的影响在于：agent 正从“你问它答”的工具变成有记忆、有节奏的常驻协作者，产品界面会更薄，工程重心转向状态管理和不打扰用户的启发式。真正值得关注的不是它能干多少活，而是你敢不敢睡前把任务交给它——这取决于它是否知道什么时候该来问你。 #AIAgent #LLM #上下文工程

曝光 6 · 评论 0 · 点赞 0 · 书签 0