ARTICLE · 1057801
Meta的AI助手火了,但每个人配一台服务器并不是好生意
资本市场看到Muse给每个人配一台云端虚拟机，就开始炒CPU。但Agent基础设施真正的机会，恰恰是让这些虚拟机大多数时候不用运行。
本文约2200字，预计阅读6分钟。
最近Meta推出的个人AI Agent Muse登上了美国App Store免费榜榜首，随后Meta股价单日上涨超过11%，服务器CPU相关公司也集体大涨。
资本市场开始炒作一个新故事：
如果未来每个人都有一个长期在线的个人Agent，服务器CPU需求可能大幅增长。
这个推演现在听起来还有些夸张。
Meta拥有数十亿用户和强大的分发渠道。单日下载量26.4万、日活44.8万，可以证明产品发布获得了关注，却不能证明用户会长期留存，也不能证明Muse已经形成稳定的变现模式。
但Muse确实暴露了一个比应用下载量更重要的问题，
过去AI基础设施负责训练模型、生成Token。未来还要负责长期运行数以百万计的Agent。
Agent消耗的不只是模型算力
传统的大模型服务主要处理一次请求。
用户提出问题，平台分配算力资源，模型生成答案，请求结束。
因此，过去AI推理Infra层面主要优化的是首Token延迟、单Token延迟、KV Cache和GPU吞吐量等指标。
但无论是Coding Agent还是个人Agent，处理的是一条可能持续数小时甚至数月的任务轨迹。
例如，用户让Agent比较保险方案，它可能需要：
1. 调用模型制定计划； 2. 打开浏览器访问多个网站； 3. 读取已有保单； 4. 填写表格； 5. 等待网站返回结果； 6. 再次调用模型比较方案； 7. 等待用户批准； 8. 最后执行购买或者取消操作。
模型推理虽然主要消耗GPU，但浏览器、代码执行、文件处理、虚拟机管理、网络请求和权限检查，会产生大量CPU、内存、存储和网络需求。
Meta公布的Muse架构中，每个用户都有一个独立的Secure VM，里面包含浏览器、文件系统、CPU、内存和长期任务状态。
这就是资本市场开始重新评估CPU需求的原因。
这个变化并不是Muse出现后才有的，只不过Muse的出现，让这把火烧的更旺了。
CPU的地位仍然不会取代GPU，但AI系统正在从单纯的模型推理，变成CPU、GPU、内存和存储共同参与的长期任务执行。
真正的问题不是每人常开一台VM
如果简单地给每名用户永久运行一台虚拟机，成本一定会失控。
更合理的个人Agent应该根据任务类型选择不同路径：
简单查询
→ 直接读取Memory和API
一次性复杂任务
→ 临时启动Sandbox，任务结束后冻结或销毁
长期后台任务
→ 使用持久环境，持续运行或按事件唤醒例如，用户只是问我今天下午有什么会议，系统没有必要唤醒一台完整虚拟机，只需要读取日历接口，再调用一次模型就够了。
只有当Agent需要浏览网页、运行代码、处理文件或者执行后台任务时，才应该恢复Sandbox。
所以，下一代Agent基础设施真正需要解决的问题，其实是，
怎样让用户感觉自己的Agent永远在线，同时让底层计算资源尽可能休眠？
可以概括为八个字：
逻辑常驻，物理休眠。
传统云计算不适合这种负载
普通云服务器假设应用持续运行，Serverless则主要面向短暂、无状态的函数。
个人Agent刚好处于两者之间：
• 用户身份和任务状态需要长期存在 • 计算环境大部分时间处于空闲 • 外部事件到来后，又需要迅速恢复 • 恢复以后，还要保留原来的文件、浏览器和任务进度。
Agent Sandbox因此呈现出明显的长时间空闲、短时间突发特征。
这需要一种新的有状态Serverless：
• 状态长期存在 • 计算资源可以缩减到零 • 外部事件到来后快速恢复 • 任务执行完成后再次释放资源
这套基础设施不仅可以用于Muse这样的个人Agent，也可能贯穿Agent的训练、评测和生产。
训练阶段需要批量创建环境、执行Rollout和探索不同策略，评测阶段需要复现固定环境和失败轨迹，生产阶段则需要为真实用户保存长期状态并恢复任务。
底层都依赖环境隔离、快照、暂停、恢复、调度和审计。
但在线Agent比训练环境更难
训练环境被Agent破坏后，可以直接重置。
在线Agent面对的却是真实世界。
VM可以回滚，现实世界不能回滚。
Agent在Sandbox里删除文件，可以从快照恢复。
但如果它已经发送了一封邮件、取消了一张机票或者完成了一笔支付，恢复虚拟机并不能撤销这些操作！
所以，个人Agent Runtime除了环境调度，还必须处理：
• 敏感操作审批 • 密码和Token隔离 • 网络出口控制 • 操作审计 • 幂等执行 • 失败后的补偿事务
Muse专门设置了一个独立于主Agent的Sentinel，决定哪些网络和连接器操作可以真正执行。这说明在线Agent的难点从来不仅仅是可不可以快速拉起一台云端虚拟机。
Agent基础设施的评价标准也要变化
过去评价LLM Serving，主要看每秒生成多少Token、GPU利用率和推理延迟。
但在Agent Runtime里，生成大量Token不等于完成了用户任务。
真正值得观察的指标应该变成：
• 每小时成功完成多少任务 • 完成一个任务的平均计算成本 • Sandbox真正执行工作的时间占比 • 空闲资源回收率 • 环境恢复延迟 • 人工接管比例 • 外部操作失败率
最终需要优化的从每秒生成多少Token，变成：
每一元基础设施成本，能够可靠完成多少个真实任务。
这可能是Muse带来的更重要启示。
Muse现在的下载量还不能证明个人Agent已经成功。但它让一个过去主要隐藏在Agent训练系统内部的问题浮出了水面：
当每个人都有一个长期在线的Agent时，谁来以足够低的成本、安全地运行这些Agent？
过去AI基础设施以模型为中心：训练平台管理Step，推理平台管理Token。
Agent时代的基础设施可能会以任务轨迹为中心：同时管理模型推理、长期状态、执行环境、权限、外部操作和失败恢复。
这可能比Muse本身更值得研究。
我在AI研学社的完整文章中，进一步拆解了以下问题：
• Agent训练环境为什么正在向在线Runtime延伸； • Kimi AgentENV的快照和Fork能力意味着什么； • Memory与Sandbox之间应该如何进行状态分层； • 在线Agent怎样进行分叉搜索； • Sandbox生命周期调度有哪些具体研究空间； • 没有大规模GPU资源的团队，还能从哪些Agent基础设施方向切入。
感兴趣的朋友，可以加入AI研学社查看完整版本。
