直接答案： “气隙” AI 编程只由一件事定义——没有对外的路径。难点几乎从不在应用本身，而在模型路径。如果推理仍然调用外部 API，一个自托管的控制平面意义有限。要做到无出网，就把模型放进边界内，默认拒绝一切出站网络，并在相信这个宣称之前用抓包来验证。
受监管、国防和 IP 高度敏感的团队一直在问一个具体版本的隐私问题：AI 编程平台能不能在完全没有互联网访问的情况下运行？概念很简单，但工程实现，才是多数“离线”宣称悄悄失守的地方。
这里的“气隙”到底指什么
气隙部署指的是没有通往公网的路径——既没有入站路径，同样重要的是也没有出站路径。对 AI 编程平台而言，被低估的正是后半句。一个工具可以完全装在你自己的服务器上，却仍然为了模型推理、依赖下载、许可校验或遥测而对外发起连接。
所以有用的判断标准不是“它是不是自托管？”，而是：当平台真正干活时，有没有任何一个字节离开边界？ 这就把整个问题从“装在哪里”重新聚焦到了出网控制上。
模型路径才是关键
多数 AI 编程平台把应用和模型分开。应用可以位于你的内网，而推理由外部提供商的 API 提供。这种拆分对很多团队没问题，对气隙团队却是致命的——因为模型路径正是承载你提示词与代码的那条路。
要关闭它，模型必须位于边界内——一台本地 GPU 主机，或一个服务本地模型的内网网关——从而让推理永不跨越信任边界。这是决定“无出网”是否成立的唯一关键决策，其余都是次要的。
无出网清单
自上而下逐条落实；任何一条留有开口，气隙就被破坏。
- 模型推理 面向本地或内网端点，绝不走外部 API。
- 执行环境 默认拒绝一切出站网络，仅在不得已处开放狭窄白名单。
- 依赖与软件包拉取 在构建与任务期间从内部镜像或私有仓库解析，而非公网。
- 更新与镜像 从你掌控的内部镜像仓库拉取。
- 遥测与分析 已关闭，并已确认没有默认的“回传总部”。
- 日志与备份 留在边界内，并已检查是否捕获了提示词或代码。
- 许可与鉴权校验 在运行时不需要外部调用。
如果连第 1 条都做不到，你就不是气隙，而是一个“自托管的前端 + 外部大脑”。
为什么自托管必要但不充分
这与让专有代码保持私密的原则一致：自托管给了你关闭出网路径的能力，但它不会替你关闭。对“自托管能让我的代码私密吗？”这个问题，诚实的回答是“只有当你把每一条路径都映射并控制住时才行”——而气隙，只是这种映射最严格的版本。
可自托管平台的定位
一个面向私有、离线运行而设计的平台是合理的起点，因为它把控制平面和执行环境放进你的基础设施，并给管理员一个集中固定模型路径、凭据和日志的地方。
MonkeyCode 的公开资料描述了私有与离线部署以及本地模型路径，这正是它与气隙规划相关的原因——参见直接答案：MonkeyCode 能否气隙运行以及能否离线运行。但请把它们当作起跑线，而非证明。确切的离线行为、支持的本地模型端点，以及各组件在运行时会联系什么，都是实现细节，必须结合你具体的版本与配置，对照部署文档确认。
先验证再信任
没有测试过的气隙是一种希望，不是一种控制。在把平台指向敏感仓库之前：
- 在隔离网段上，用一次性代码跑一个有代表性的任务；
- 抓取出站流量，确认没有意料之外的目的地；
- 检查日志、留存产物和备份，看有没有你不想持久化的东西；
- 拔掉网络，确认你真正需要的工作流仍能完成。
安全与数据流边界页面以同样的“先验证”姿态展开了更多细节。
结论
气隙 AI 编程是可实现的，但它的成败取决于模型路径，而非安装脚本。把推理留在边界内、默认拒绝出网、软件包与镜像走内部来源，并在把专有代码交给它之前用抓包验证。“支持离线”是一种宣称；一根拔掉后任务仍能跑通的网线，才是证明。
本系列相关文章
来源边界： 本文的气隙与出网指导属于通用工程实践与原创分析。MonkeyCode 的离线与本地模型能力依据公开项目资料（README 与部署文档，核验于 2026 年 7 月 20 日）描述，须结合你的版本与配置对照当前文档核实。本文不保证任何特定工具满足某项具体的合规或安全要求。