同一套智能体运行时在不同区域上线，差距不在模型在配套
一、“正式可用”核对的是配套矩阵，不是模型名称
一项智能体运行服务在由本地运营商运营的区域宣布正式可用，新闻里最容易被误读的一行是服务名称。名称相同只说明同一套控制面入口在两个区域都存在，不说明围绕它的那圈东西也一样。对企业侧的交付来说，“能不能用”的判断要落到六个具体的面上：运行时与工具调用框架、身份与密钥管理、网络出口与访问控制、可观测性、数据存留与备份策略、支持与工单链路。这六项里任何一项缺失或降配，智能体系统的可交付形态都会变。
我们做跨区域方案时的习惯是，先把“模型一致”这句话从讨论里删掉，只留“能力项一致”。前者是市场口径，后者是工程口径。模型一致但工具调用框架少一种鉴权方式，等于所有需要该鉴权的业务动作在这个区域跑不通；模型一致但指标存放位置不同，等于同一套告警规则要重写。
区域之间的能力差不是缺陷，是常态。把它当成异常去惊讶，不如把它当成一项固定核对工作去做。
二、六类配套能力：跨区域要打勾的那张表
核对表的价值在于每一项都能给出“可用、部分可用、不可用”三态，并且部分可用要写清楚缺哪一块。三态之外不许写“应该没问题”。
| 配套能力 | 要问的具体问题 | 缺配时业务侧的真实后果 |
|---|---|---|
| 运行时与工具调用框架 | 支持的调用形态、并发上限、单任务最长执行时长是否一致 | 同一段编排代码在另一区域超时或被限流，任务半途终止 |
| 身份与密钥管理 | 密钥是否可在本区域自主创建与轮转，是否支持既有身份提供方 | 跨区取密钥变成跨境调用，链路一断全停 |
| 网络出口与访问控制 | 出站是否需走专用代理，目标地址白名单谁来维护 | 工具无法访问外部接口，或被迫放开过大范围 |
| 可观测性 | 日志、追踪、指标三类数据存放位置与查询保留期 | 排障窗口缩短，事后无法重建一次异常执行 |
| 数据存留与备份策略 | 副本份数、跨区备份是否允许、保留期默认值 | 备份策略与合规承诺对不上，需自建备份链路 |
| 支持与工单链路 | 用哪个入口提单、以哪种语言、响应时限怎么算 | 同一故障在两个区域的处理时长差数倍 |
这张表要按区域各填一份，然后做差集。差集里每一条差异，都要在验收表里对应一个“我们侧要做的改动”和“改动由谁承担”。没有这两列的核对表只是知识，不是交付物。
三、同一个服务在不同区域会长得不一样，原因有四个层面
理解差异来源，比记住差异清单更耐用，因为清单每个季度都会变。
第一层是合规要求的差别。同一类数据在某个区域有额外的存留与处理约束时，依赖这些数据的配套能力就会先被裁剪或改造，表现通常是某类日志不可导出、某种备份默认关闭。第二层是代运营主体的差别。运营方拿到的是在同一套控制面上的运营与支持职责，两侧能承诺的服务项目、通知渠道和时限并不天然相同，需要以书面公布为准。第三层是基础设施规模差别，包括可用区数量与容量供给，它决定了能否在一个区域内做跨可用区的高可用。第四层是供给面差别，最容易被忽略也最容易致命：容器镜像、依赖包仓库、模型权重与第三方工具后端在这个区域内能否直接取到。
四个层面里，第三和第四层是纯工程问题，可以在方案里补；第一和第二层是合同与责任问题，只能靠写清边界来管理，不能靠技术手段绕开。
四、“由本地运营商运营”在合同与运维上的三处具体影响
这句话在交付文档里不能只写一遍，它要在三个地方分别落下来。
签署主体与支持入口。协议与谁签、发票与谁开、故障找谁提单、升级请求走哪条路，四件事可能指向不同的法律主体。运维侧必须有一份“问题分类到提单入口”的对照表，否则一线在跨主体问题上会把时间花在互相转手上。判断标准很简单：任何一条支持承诺，都要能在合同文本里找到对应条款和时限数字，找不到就当它不存在。
数据所在地的判定。数据在哪里这个问题，要按存储位置而不是按服务名称回答。同一套系统里，会话记录、向量索引、模型输入输出的临时缓存、备份副本、指标数据，可能落在不同位置，也可能有默认值差异。要逐类存储列出物理位置与可配置范围，形成数据位置表，这张表后面在客户审计时是第一份被索要的材料。
变更通知渠道与时限。功能的下线、接口字段的调整、配额策略的变化，通过哪个渠道通知、提前多久、有没有例外，两区域的公布口径可能不同。运维上要指定唯一的通知接收邮箱与订阅渠道，并规定内部转发时限，避免“通知发过了但没人看”这种最难界定的情况。
五、迁移动作之前，先盘依赖清单和数据面四类约束
智能体系统看起来只依赖一个模型服务，实际依赖面比这宽得多。盘查时按六条线走，每条线都要写出“在目标区域是否可用”和“不可用时的替代方案与改动量”。
- 模型与推理服务。除主模型外，还有嵌入模型、重排模型、分类小模型，这几类经常不同步上线，替代后要重跑召回与排序的回归。
- 工具后端。函数调用指向的内部接口、消息队列、邮件与短信通道、文档解析服务，逐一确认网络可达与鉴权方式。
- 检索与向量存储。向量库版本与索引参数不一致时，同一份语料的召回结果会变，必须重建索引后再比指标，不能直接沿用。
- 外部接口。第三方接口的可用区域、证书与域名解析差异，往往要在这一档才发现。
- 身份提供方。单点登录、服务账号、临时凭证的签发路径是否在本区域内闭环。
- 数据管道与调度。批量导入、定时任务、依赖编排工具的部署位置。
数据面有四类约束，每一类都要单独填，不能合并成“符合合规要求”一句话：采集范围（哪些字段必须留在原区域）、留存期（默认多久、可配置到什么区间）、跨区传输（是否允许、允许时的最小字段集）、被请求删除时的物理清除（备份与缓存里的副本多久能清、清除后能否出具证明）。这四类在两个区域的默认值不同是常见情况，所以判断要落在“我们侧要不要多存一份、少存一份、按谁的条件来”上，而不是落在“哪个更严”的口头结论上。
六、四档灰度、每档的回退路径，以及一张验收表
跨区域切换最稳妥的做法是把链路按副作用强弱分档，一档一档推，每档都留一条已经演练过的退路。
| 灰度档位 | 迁移对象 | 停留与观察内容 | 回退路径与耗时 |
|---|---|---|---|
| 一档 | 只读查询与离线评测链路 | 同一批输入在两侧跑，比召回、格式、延迟分位数 | 流量切回原区域，分钟级 |
| 二档 | 非关键生产（内部问答、报表生成） | 错误率、工单量、成本计量项是否符合预期 | 路由配置回切，需在半小时内完成 |
| 三档 | 带副作用的生产动作（发通知、写业务数据） | 确认点是否触发、留证是否完整、凭证是否越界 | 需停新会话并回收在跑任务，耗时以小时计 |
| 四档 | 主链路与全部流量 | 连续两周的错误率与延迟基线对照 | 只保留人工介入，不再自动回切 |
每一档都要有“未达到观察标准就不进下一档”的硬条件，条件写成指标而不是感觉。三档之前，回退演练必须真做一次：把开关拨回去，看要多久、丢不丢数据。只在文档里写“可回退”不作数。
验收表按六类配套能力逐项展开，每行五列：能力项、是否可用、差异说明、差异带来的改动项、改动由谁承担。最后一列只有三种填法：供应商侧已承诺、我方实施、双方共同。三种之外填不进表。这张表签完，跨区域交付才有可核对的边界。
在洹拓自己做智能体交付时，跨区域核对还多一条要求：所有能力差异要写进对客户的说明里，不允许用“以官方公布为准”来代替核对动作本身。公布的东西是别人负责的边界，核对表才是我们负责的交付。