IBM 在 2026 年 9 月 24 日正式推出了 AI 编程智能体 IBM Bob 的自托管与物理隔离版本 Bob 2.0.0，配套发布 Bob IDE 2.2.0 与 Bob Shell 2.0.5。对于金融、军工以及守着大型机系统的机构来说，这是一剂盼望已久的定心丸：软件生命周期的自主智能体终于可以在完全切断外网的环境下运转，源代码半步都不必离开内网。
然而，隔绝外部网络并不等于零成本获取云端能力。筑起这道物理高墙的代价，是把庞大的计算开销、复杂的平台工程和模型运维的全部重担，完整移交到了客户自己的机房内。
物理隔离下的重载基建
主流公有云编程助手依赖云端多租户集群调度，根本无法进入保密要求严苛的涉密内网。IBM 这次给出的解法极其彻底：利用收购红帽后沉淀的 OpenShift 体系，把智能体工具链、网关、身份认证和审计组件整体打包成私有集群部署方案。
但这套内网软件栈的分量并不轻。官方给出的基线环境要求基于红帽 OpenShift 4.20、4.21 或 4.22 版本，且仅支持 amd64/x86-64 架构。一个能支撑生产环境的最小参考集群，就需要划拨 3 个控制节点、3 个基础设施节点与 3 个工作节点。
这一套管控面集群合计需要占用约 84 vCPU、168 GiB 内存 以及 600 GiB 的工作节点存储。
最值得厘清的事实是，这 84 核算力仅仅用来维持平台自身的调度、审计与状态存储，并没有包含任何用于大模型推理的 GPU 资源。为了把代码跑起来，企业必须在 OpenShift 之外自行搭建和维护基于 vLLM 或 TGI 的推理网关，再通过专用 CLI 工具 bobctl 将镜像导入内网私有仓库。
- 风险.若企业此前没有成型的 OpenShift 运维能力与本地 GPU 集群管理经验，为这套系统投入的基础设施和平台工程开销，将迅速超过软件授权本身的开销。
降本承诺与单模型现实
兵马未动，粮草先行。在基础设施账本之外，离线部署对智能体核心体验的折损同样明显。
在云端版本中，IBM 主打通过多模型动态路由来平衡任务开销，宣称这种智能分流能削减约 40% 的计算支出。但在物理隔离和自托管技术文档里，赫然写着一项底层限制：当前每次仅支持配置 1 个核心推理模型，系统完全不支持并发多模型动态路由。
这意味着企业在断网环境下面临两难。如果选一个轻量中等尺寸模型，它难以稳定胜任长程多文件的代码规划；如果直接挂载高规格模型，哪怕处理最琐碎的语法补全，GPU 也要承受最高级别的推理负载，宣称的 40% 降本机制在内网里根本无法生效。
官方文档列出的断网推荐模型包括 Mistral 3.5、NVIDIA Nemotron 3（博客提及 Nemotron 3 Ultra）以及 Poolside Laguna S2.1，并建议企业额外引入 openai/gpt-oss-20b 作为本地护栏模型。
在定价策略上，IBM Bob 的断网自托管版没有公开标价，完全走针对大客户的销售谈判流程。其公有云按代币消耗的参考阶梯为 Pro（$20/月，含 50 Bobcoins）、Pro+（$60/月，180 Coins）以及 Ultra（$200/月，1000 Coins），额外补充的企业代币包售价为 1000 Bobcoins / $500。
IBM 还设立了专门的遗留系统加价包：Java 现代化套件起价 $20、IBM i 起价 $40，涉及核心大型机的 IBM Z 套件则需单独逐级谈判。
遗留系统重构的实操断层
IBM 敢于开出高昂的加价订阅包，关键底气在于其掌握的大型机存量客户——全球大量银行与公共机构的关键业务仍运行在 COBOL、RPG 和 IBM i 系统之上。这些机构既离不开旧系统，又迫切需要借助自主智能体完成代码逆向与重构。
但目前公开的技术证据与社区实测数据，却显现出明显的落差。IBM 至今未公布 Bob 在 SWE-bench 等独立透明基准测试上的成绩，Gartner Peer Insights 上也仅收录了 12 条可见评价，平均分为 4.1 分。
在开源社区的实际调用报告中，Bob 在面对 IBM i、PASE 环境和 RPG 语法时暴露出较多的命令语法混淆，比如频繁颠倒 system 与 cl 指令。甚至有实测记录显示，一个长程自主任务在持续运行 8 小时、消耗了 73 个代币之后，生成的代码依然无法通过基础的 SQL 验证。对于需要精确交付的业务系统来说，这种错误往往需要耗费大量资深工程师的时间去人工排错。
物理隔离只能挡住外网的窥探，却挡不住内网智能体失控带来的执行损耗。
安全风险也是企业必须面对的变量。虽然网络处于断开状态，但 Bob 在工作节点上拥有深度的代码读写与终端 Shell 执行权限。早在 2025 年的 Beta 测试中，安全研究人员就演示过借助间接提示词注入（Indirect Prompt Injection）诱导智能体执行未授权脚本的路径。内网研发人员如果在配置权限时为了图省事而勾选始终允许，反而可能在物理隔离区内部给横向指令穿透留下通道。
平台暗战与选型推演
在企业代码安全这个高端防御性赛道上，各家方案的路线分野越来越明确。
| 解决方案 | 离线支持方式 | 基础设施依赖 | 模型路由能力 | 核心目标客群 |
|---|---|---|---|---|
| IBM Bob 2.0.0 | 完整物理隔离部署 | 红帽 OpenShift (≥84核) + 自建 GPU | 仅限单核心模型 | IBM Z/i 遗留大型机与强监管国企 |
| GitLab Duo | 自托管版本 | 既有 GitLab 私有实例底座 | 支持分级本地模型 | 追求 DevSecOps 闭环的私有云企业 |
| Tabnine Enterprise | 纯私有容器集群 | 独立 Kubernetes / 物理节点 | 专用微调小模型 | 算力受限、追求轻量部署的研发团队 |
| GitHub Copilot | 仅实验性预览 (CLI) | 依赖云端托管（内网方案未成型） | 云端闭源混合调度 | 以云端多租户协作开发为主的企业 |
横向审视整个断网开发市场，具备完整平台级物理隔离能力的只有 IBM Bob、GitLab Duo Self-Hosted 与 Tabnine Enterprise。GitHub Copilot Enterprise 虽然在开发者中呼声极高，但其本质架构仍旧扎根在微软托管云上；在 GitHub Enterprise Server 上的断网实践，目前仍停留在使用 Copilot CLI 配合本地 BYOK 自带模型接口的实验性预览阶段。
IBM 依靠红帽 OpenShift 构筑的竞争壁垒非常牢固。对于本就重度依赖红帽和 IBM 主机的大型机构而言，Bob 是一套现成、合规且能应付审计的整体方案。
- 建议.评估此类断网方案的决策者，不应仅以官方宣称的理论降本比例为准，必须将 9 节点管控集群硬件、自备 GPU 推理成本，以及模型在冷门专有语法下的低通过率综合折算进真实拥有成本。
物理隔离解决了代码合规的生存问题，但它换来的是基础设施层面的重装上阵。代码虽未移出内网一步，企业为这项能力付出的真实代价才刚刚开始结算。