气隙环境中的智能体部署。
人人都会问的那个气隙问题是「模型跑在哪」,而这恰好是唯一有厂商答案的问题。真正代价高昂的意外,是你的智能体在没人拍板的情况下就已经依赖上的那半打互联网依赖:它用来读版本号的软件包索引、它用来发现服务器的工具注册表、你的评测套件要调用的那个托管评判模型、会无声丢弃数据的错误上报、永远解析不出来的证书吊销列表。搬之前先把这些清点出来,因为在气隙之内,它们每一个都不是以连接错误、而是以「无法解释的质量回归」的形式失败——而且要把「模型档位会不一样」算进计划,这使得这整件事是一次披着基础设施迁移外衣的评测迁移。
把三种主张分开命名,因为它们的代价完全不同。
「气隙」这个词被用来指三种工程后果各异的姿态,而团队常常买下其中一种、却承诺了另一种。在架构评审之前就把它们写开,因为满足一条数据驻留条款的控制,并不满足一项隔离要求。
# Three postures, in increasing order of what breaks SOVEREIGN CLOUD provider infrastructure, contractual region + jurisdiction internet present; dependencies all still work buys: residency, legal venue breaks: nothing technical SELF-HOSTED your infrastructure, egress allowed through a policy buys: custody of weights + data breaks: provider features AIR-GAPPED no route to the internet at all, by design buys: isolation you can demonstrate breaks: every implicit network dependency, all at once # The sentence worth writing down before you commit "we need X" where X is one of the three, not the word air-gapped
本页讲的只是第三种姿态。前两种分别由数据驻留与主权和智能体的自托管推理处理;而如果你真正拥有的其实是一条数据驻留要求,那么停在第一种姿态是一个正当、且便宜得多的答案。
里面可用的模型档位,才是那条起约束作用的设计约束。
这是改变产品而不是改变管路的那一部分,而厂商的矩阵把它明摆出来,并没有藏。IBM 的自托管版 Bob 于 2026 年 10 月 1 日正式可用,面向本地、私有云、主权云与气隙环境,外壳完整保留——shell、并行工具调用、技能、操作模式——而在正式可用时,受支持运行在客户自管基础设施上的模型是 NVIDIA Nemotron 与 Poolside Laguna。Claude Sonnet 5.0 与 Opus 4.8、Gemini 3.7 Flash 以及 GPT 5.6 Sol 出现在托管与混合配置里。外壳越过了气隙;模型没有。
由此引出三个运维后果,而这三个都是排期事项。
- 你的提示词与技能都是未经测试的资产。一切照着托管的前沿模型校准过的东西,都得在你能在里面运行的那个模型上重新挣一遍——这正是提示词可移植性里的那个问题,只不过它这次是以一次部署决策、而不是以一次选模型的形式登场。
- 要重新界定任务集,而不只是提示词。如果本地模型完成同一任务需要更多步数,那么你的步数上限、超时与上下文预算全都是照着另一个模型定的尺寸。同一上限下更长的循环,读起来就是「被截断的运行莫名增多」。
- 容量规划现在归你了。没有突发、没有弹性配额、没有厂商替你吸收峰值。要么按 p99 并发做容量并接受 GPU 空转,要么实现准入控制并接受排队——参见承载智能体流量。
请在迁移之前做这个对比,而不是之后。把候选的本地模型在你平常的环境里立起来,把你现有的任务集指向它,在你还同时握着两边的时候把差距读出来。等气隙闭合之后才发现质量差的团队,是分不清「模型回归」和「依赖断掉」的,因为在气隙之内这两者都表现为「它变差了」。
把隐式依赖一一列举出来;其中大多数并不是模型。
智能体是一个「会去查东西」的程序。切断网络之后,那些查询并不会抛异常——模型改为凭记忆作答,而这是可选失败模式里最糟的一种,因为它与「正常工作」无从区分。请拿这张清单对着你自己的智能体走一遍,并在每一行标上「用什么来替代它」。
# Implicit network dependencies, and how each one fails inside the gap
package index / registry version lookups -> model guesses a version
MCP / tool registry server discovery -> stale local catalog only
docs + web retrieval grounding -> confident answers from weights
hosted LLM judge eval scores -> suite silently skips or errors
telemetry + error reporting drops -> you lose the one thing you need most
model + container updates no pull -> a release process, see Step 5
CRL / OCSP / NTP TLS + token validation fails, intermittently
license activation phones home -> expiry outage on a quiet Sunday
有两行值得强调。接地那一行产出的是「错的活」而不是「失败的活」:此前能读到最新文档的智能体,现在是从一个知识截止里作答,而且无从示意这个差别;所以请有意地把检索内化——镜像一份文档语料、一个内部软件包索引、一份你按计划刷新的工具目录——并让智能体的检索工具在语料比申报的新鲜度上限更旧时大声失败。而时间那一行产出的是凌晨三点的事故:证书校验与令牌过期都依赖时钟与吊销数据,而一个隔离的网络必须自己供给这两样。
请用硬办法检验这份清单。在一个其他方面完全相同的预发环境里封掉对外访问,然后跑你完整的任务集——和对智能体做故障注入是同一招。每一个你本来不知道的依赖都会在一个下午里现形,这比在一次主权审计中发现它要便宜得多。
评测与可观测性必须一起搬进去,而不是被跳过。
气隙可预见的牺牲品是评测套件,因为它是整条栈里依赖项大多托管在外的那一块:厂商那边的评判模型、托管的追踪后端、放在别处对象存储里的数据集。要避开的是那个常见模式——套件为了这套气隙部署被「临时」关掉,于是可观测性最差的那个环境,变成了彻底没有质量闸门在跑的那一个。
- 把评判模型托管在里面。一个在本地运行的、更小的开放权重评判模型,并在你已有的标注集上重新校准,让你在信它之前就知道一致率。校准这一步不是可选的;换一个评判模型就是换一个指标。参见用 LLM 评判智能体。
- 凡是能用规则评分的地方就优先用规则。在气隙之内,每一条你能表达成精确检查而不是模型判断的断言,都同时消掉了一项依赖与一场关于校准的争论。
- 追踪数据留在原地,因而会不断堆积。没有任何东西把它们运往站外,所以保留期既是一个磁盘容量决策,也在同一口气里是一个披露决策——请显式设定它,正如追踪采样与保留所述。
- 决定结论怎么出来。总会有人需要在气隙之外依据某个汇总指标行动。请把那次导出定义成一件经评审的产物——一份签名摘要、不含原始追踪、按指定节奏——而不是留给「谁手上有个 U 盘」。
而且请在气隙之内、在真实部署上跑评测套件,而不只是在那个有对外访问的预发环境里跑。这两者之间的配置差异,恰恰就是气隙特有失败的藏身之处。
更新变成一套有人参与的发布流程。
在气隙之外,打补丁是一项后台活动。在里面,每一个模型版本、容器镜像、工具服务器、依赖项与 CVE 源都要经由一次刻意的、经认证的导入抵达——而一套没人排期的刻意流程,其默认结局就是十一个月没更新过任何东西。
- 给导入定一个节奏,写下来,并指定负责人。镜像与依赖项按月是个合理的默认;模型版本可以更慢,但「等有人提」不是一个节奏。
- 入口处按摘要与签名逐一验证。传输介质现在就是供应链,而导入这一步是强制固定与验证价值最高的那一个位置。一个靠笔记本电脑越过气隙的未签名镜像,等于让后勤替它做完了信任决策。
- 也要把漏洞情报源镜像进来。隔离并不会修补任何东西;它只是拿掉了你的通知通道。一套看不到安全公告的气隙智能体平台,是在带着已知有洞的组件运行而无从得知——这是智能体平台的漏洞管理里属于「清点」的那一半。
- 把一次模型更新当作一次发布,配上第 4 步那道评测闸。这是气隙唯一的好处:没有东西会在你脚下悄悄变。不会有无声的端点升级,也不会有未固定的厂商默认值在某个周二自己挪位。版本归你——这同时也意味着不会有别人替你注意到那次回归。
在你需要之前就把例外通路写下来,因为你一定会需要。当一次生产事故需要厂商帮忙、而厂商什么都看不到时,现场临时想出来的答案就是有人拿手机把日志拍下来。请预先决定什么可以出去、以何种方式脱敏、由谁批准——并请注意,同样的推理也适用于智能体自己的追踪数据,而在人们会选择气隙的那些环境里,那些数据里装着源代码与客户资料。
验收闸,以及那个告诉你它到底行不行的数字。
气隙部署是凭证据验收的,而不是凭一张功能清单,因为功能清单恰恰是那个干净迁移过去的东西。五项检查,每一项都是「是」或「否」。
- 任务集在气隙之内通过,通过率达到你事先写下的「在本地模型上可接受」的水平——而不是与托管部署持平,那个你拿不到,也不该承诺。
- 对外访问默认拒绝,且拒绝被记录在案,这样一次尝试性查询就是一个可见事件,而不是一个缺失事件。这是智能体的出口管控由内向外的版本:策略本身很简单,日志才是成果。
- 每一份检索语料都申报自己的新鲜度,并且在超过上限变旧时,智能体会拒答或打上标记。
- 评测套件与评判模型都在里面运行,并记录与你此前那份标注集之间的一致率。
- 导入已经端到端真做过一次——完整走一轮模型、镜像与情报源更新,计时,并实际演练签名校验。一条从未跑过的导入通路只是一份计划。
然后在生产里盯住一个数字:有多少比例的运行是在「没有任何工具调用返回语料过旧或依赖不可用信号」的情况下完成的。它最先动、也动得很早,远在质量指标明显劣化之前,因为一个绕开了缺失查询的智能体照样会产出一个答案。如果采用这套姿态是出于治理原因,同一批证据也可以喂给智能体清册的条目,以及随后那份影响评估。
在决定上气隙之前,先做那个便宜的实验:在一个与生产完全一致的预发环境里封掉所有对外访问,把你完整的任务集跑一整天。数两件事——有多少次工具调用失败了,以及有多少次运行给出了一个自信的错误答案而不是直接失败。第二个数才是气隙的真实代价,它几乎总比团队预期的更大,而它也是唯一能告诉你「在气隙成为一个可安全运营、而不仅仅是合规的地方之前,你必须把多少检索内化」的数字。