过去十八个月的大部分时间，我都在会议室里和各位CIO一起梳理他们的AI战略，这些对话总是从同一个地方开始——模型选型、供应商评估、智能体框架——但最终都会归结到同一个令人不安的问题。
"这东西到底要在哪儿跑?"
这个问题之所以让人尴尬，是因为它听起来像是几年前就该解决的事，大多数企业在2015到2020年间就选定了云服务商，他们在AWS、Azure或GCP之间做了标准化选择，签了多年合约，并据此构建了应用组合，云战略早已尘埃落定，那为什么它突然又被摆上了台面?
因为底层的工作负载变了，对无状态Web应用来说合理的云战略，对AI智能体来说并不适用，而那些最快想明白这一点的CIO，正在围绕一个大多数采购团队甚至还不知道存在的约束条件重构他们的架构。
旧的云计算逻辑已经失效
大约十年来，云战略的核心就是应用在哪里运行，你优化的是计算价格、开发速度和托管服务，数据是你搬到应用所在位置的东西，这之所以行得通，是因为数据与计算的比例很小。一个典型的应用请求只在应用和数据库之间移动几KB的结构化数据。
由此形成的架构模式简洁而优雅：应用在一个区域，数据在另一个区域，用户在完全不同的地方，中间的网络填补了缝隙。延迟预算是以用户可感知的方式来衡量的——200毫秒的页面加载可以接受，500毫秒就是问题，跨区域调用是你为了弹性或为了让计算靠近用户而付出的代价。
整个模型都假设应用是执行工作的主体，而数据是被操作的对象。
AI智能体颠倒了这个假设。
AI颠覆了这个比例
智能体不只是消费数据，它们就活在数据里。
记忆、上下文、检索、嵌入——数据不是工作负载的输入，它在很大程度上就是工作负载本身。一个智能体在推理客户情况时，每一轮都在拉取对话历史、组织策略、产品文档和结构化记录。一个写代码的智能体在拉取代码仓库、架构决策记录、测试套件和相关的运行时遥测数据。一个做财务分析的智能体在拉取市场数据、内部预测、监管文件和历史背景——然后产生中间结果，反馈到下一步推理中。
数据不是工作负载偶尔引用的东西，它是工作负载在其上进行计算的基底。
而这个基底有引力。
它有监管引力——主权指令、数据驻留要求、特定行业的合规制度，规定特定类型的数据不能离开特定的司法管辖区。欧盟AI法案、HIPAA、十几个国家的金融服务法规——这些不是偏好，而是约束条件，在你做出任何架构决策之前，就决定了你的部分数据允许存放在哪里。
它有经济引力——出口流量费、GPU时的定价差异、在云边界之间移动TB级语料库的粗暴经济学。训练数据和嵌入存储早就不是以GB为单位了。移动它们不是改个配置的事，而是一个项目，有时是长达一个季度的项目，还附带一张真实的账单。
它有既有格局引力——数据就在它所在的地方，移动PB级数据不在今年的路线图上。大多数企业的数据分散在从未设计为可移植的系统中。你的客户记录存在某个特定云上，不是因为有人在2026年做了什么战略决策，而是因为他们在2017年做了一个战略决策，数据从那以后就一直在那里积累。
它还有延迟引力——而这正是悄悄为所有人重写架构的那个因素。
实际耗时是驱动因素
这里有一个没人会放进PPT里的数学题。
一个普通的智能体循环(检索、推理、执行、观察)每个任务轻松就要做五到十次往返。智能体检索相关上下文，对其进行推理，调用一个工具，观察结果，对结果进行推理，检索更多上下文，再次执行。每一步都触及数据层、记忆存储、模型，再回来。
现在假设每次跨区域网络跳跃增加50毫秒延迟，这意味着每个智能体任务上，除了实际的模型推理和工具执行之外，还要额外增加250到500毫秒的纯网络开销。如果这个循环每小时运行一百次，同时有数千个智能体会话在运行，你面对的就不是轻微的性能下降了。你面对的是一个感觉"活着"的智能体和一个感觉像拨号上网的智能体之间的区别。
这就是为什么我在那些会议室里反复跟CIO说同样的话：你的数据、记忆存储、模型和智能体运行时必须在同一个物理数据中心，没有例外。
这个物理数据中心是你自己的还是超大规模云厂商的，才是真正值得讨论的问题，但它们必须同处一地。如果你为了追采购折扣而把这些东西分散到不同区域或不同供应商，你就是在AI战略上线之前就亲手毁掉它。
我想在评论区出现之前先堵上两个反对意见。
"那些确实需要跨区域的智能体呢?比如一个需要从区域数据存储中检索的全球客服智能体?"
那些其实不是一个智能体，它们是带有路由层的区域智能体联邦，而实际耗时的计算在每个区域内部适用，联邦才是架构。假装它是一个横跨各地理区域的智能体，就是你最终遇到拨号上网问题的原因。
"那超大规模云厂商的私有连接呢?Direct Connect、ExpressRoute，那些能把跨区域延迟降到个位数毫秒吧?"
个位数毫秒在智能体循环中仍然会累积，比在人工操作时累积得更多。五次跳跃，每次5毫秒，每个任务就是25毫秒的网络开销，在数百万次任务中会累加起来。
而且私有连接解决不了其他引力问题，它不会让数据驻留指令消失，它不会改变数据本身的出口流量经济，它只是让问题的一个维度稍微好一点。
约束是物理，不是采购，你没法跟光速谈判。
这就是为什么云市场碎裂了
一旦你接受智能体必须在物理上紧邻其数据、记忆和模型运行，AI云市场最近的碎裂就开始说得通了。
主权云不是靠爱国情怀赢的，它们赢在监管引力占主导、数据已经在特定边界的特定一侧的地方，新兴云不是靠氛围转变赢的，它们赢在经济引力占主导、GPU时定价让数学算得过来的地方，私有云不是因为本地部署又流行了才赢的，它们赢在既有格局引力占主导、数据已经在你的数据中心里哪儿也不会去的地方。超大规模云厂商仍然赢在开发引力和托管服务占主导的地方，以及数据已经在他们的对象存储里、来自十年云迁移积累的地方。
这些不是在旧维度上竞争，它们各自在不同引力成为绑定约束的场景中胜出。
正确的问题不是你该选哪朵云，而是对每个工作负载来说哪种引力占主导，因此整个技术栈(数据、记忆、模型、智能体运行时)需要在哪里同处一地，有些智能体会在三个地方运行，有些智能体需要在它们之间移动，这就是为什么部署灵活性比我们只跑无状态应用时比以往任何时候都更重要。
CIO这个季度实际应该做的事
别再选云了，开始把你的智能体组合映射到四种引力上，让架构从映射结果中自然浮现。
对你计划在未来十二个月内投入生产的每个AI工作负载，过一遍四个问题：
1. 数据在哪里，或者最终会在哪里?不是你希望它在哪里。是它实际在哪里，或者监管或业务现实迫使它在哪里，这是约束其他一切的答案。
2. 哪种引力占主导?如果监管指令不可协商，那就是你的绑定约束。如果GPU经济是问题所在，那就是你的绑定约束。如果你有10PB的历史数据存在某个特定云上，而移动它是一个多年项目，那就是你的绑定约束。
3. 智能体循环的实际耗时预算是多少?如果是批量工作负载，你有灵活性。如果是实时面向客户的智能体，你需要所有东西在同一个数据中心，而且你需要从第一天就为此设计。
4. 可移植性要求是什么?随着模型提供商竞争和定价变化，你能在不移动数据的情况下移动智能体运行时吗?你能在不重写智能体的情况下移动数据吗?锁定过去是用出口流量费来衡量的。现在是用Token定价、嵌入模型兼容性和智能体框架可移植性来衡量的。
那些搞错的CIO不会因为选错了云而失败，他们会因为选了一朵云而失败。单一的、整体的、在2019年选了一次的云，而正确答案本该是一个围绕每个工作负载的引力来架构的组合。
云战略在智能体成为工作负载的那天就不再是采购决策了，它变成了一个物理问题，而物理不在乎你跟哪个供应商签了约。
