本地与云：Agent运行时的混合架构

你的笔记本现在已经能跑Agent了。不是噱头，也不是未来预言——本地推理和云计算之间的那道墙正在被敲碎。

这篇文章从底层架构入手，讲清楚本地模型和云端推理怎么协作。你会看到：一个守护进程如何根据模型标记（tag）决定请求是走本地GPU还是远端数据中心；一条命令就能让开源模型接入Copilot CLI、Claude Code这类编码助手；以及为什么统一内存成了决定Agent能不能跑完长任务的关键瓶颈。

文章还提到了伯克利国家实验室、NASA格伦研究中心、布鲁克海文国家实验室的真实部署案例，并对比了Ollama和Foundry Local的差异，帮你选到最合适的运行时。

读完这篇文章，你将理解整个技术栈的每个层次：运行时、中间层、容器隔离、底层硬件。

参考视频：微软内部演讲（英文）

守护进程：比你想象的更重要

Ollama在用户看来就是一条命令，和模型聊天。底层其实是一个本地推理守护进程，监听在 localhost:11434，使用三种不同的“方言”：

• 原生API
• OpenAI兼容接口
• 自定义扩展

这个守护进程让一切变得灵活。当你输入 ollama run codellama:7b，它立刻解析模型标记，检查本地是否已有缓存。如果有，直接走GPU推理；如果没有，从远端仓库拉取。而一旦你想用更强的云端模型，比如Claude或GPT-4，只需改一个字符：把模型名字从 codellama:7b 改成 claude:3-opus，守护进程就会自动把请求路由到对应的云服务。

本地VS云端：一个字符的决策

这个“一个字符”的切换不是魔法，而是一个统一的模型注册表。Ollama 的本地模型库和云模型都在同一个命名空间下。比如：

• codellama:7b → 本地GPU
• claude:3-opus → 云端（API Key 来自环境变量）
• deepseek:coder → 本地，或通过中转层到云端

这背后是路由表 + 健康检查 + 动态负载均衡。国产工具比如 ModelScope 的本地推理方案也类似，但还缺少Ollama那种无缝切换的体验。

长任务的隐形杀手：统一内存

Agent跑一个复杂任务时，需要记住上下文。如果上下文太长，模型就“失忆”了。这不是模型容量问题，是硬件内存墙。

统一内存（Unified Memory）技术允许CPU和GPU共享同一块内存，不需要来回拷贝数据。但问题是，它只在苹果M系列芯片、英伟达Grace-Hopper等产品上才高效。普通PC用DDR + 显存分离，Agent跑几分钟后就可能因为内存换页而卡死。

伯克利实验室和NASA格伦研究中心的部署经验表明：要想让Agent连续工作超过10分钟，必须用统一内存架构，或者把部分推理切到云上。

真实部署：三个案例

• 伯克利国家实验室：用Ollama + 本地推理跑分子模拟Agent，遇到长任务就切到云端。
• NASA格伦：在一个离线环境里部署全本地栈，不依赖云，但限制了任务复杂度。
• 布鲁克海文：用Foundry Local做实验管理，通过统一内存让Agent能跑满GPU显存。

这些案例有一个共同规律：都采用了“本地兜底 + 云端兜不住”的路由模式——任务简单时本地搞定，复杂时自动兜售到云。

如何选：Ollama vs Foundry Local

特性	Ollama	Foundry Local
上手	一条命令	需要配Docker
路由	自动，基于模型tag	手动配置profiles
统一内存	自动优化（苹果芯片）	需要手动设置
团队管理	无	角色权限、审计日志

如果你是个人开发者，Ollama 足够；如果你要在团队里管理多个模型、分层权限，Foundry Local 更合适。国内类似的方案还有 Xinference（用Python起推理服务）和 FastChat，但都缺少统一的云路由能力。

总结

从一个大模型用户的角度，本地-云混合就是一个“零切换体验”。你不需要关心模型到底在哪里跑，只要告诉Agent“去干活”。背后的守护进程、路由表、内存墙这些细节，决定了这个体验到底顺滑还是卡顿。

未来，Agent运行时可能会像浏览器一样成为操作系统的标配——你的笔记本既是终端，也是服务器。