先看证据
IBM交付的不是一个模型，而是一层控制面
IBM已经正式提供IBM Bob的自托管部署。Bob是一套面向软件开发全生命周期的智能体平台，覆盖代码理解、任务规划、变更执行和结果验证，并把IDE体验、BobShell、并行工具调用、agent harness、skills和modes放在同一个工作面中。企业可以把它部署在本地环境、私有云、主权云或隔离网络里，也可以使用可选的Java、IBM i和IBM Z现代化包。
这次发布值得技术负责人认真拆开看，因为Bob的交付边界与常见编码助手不同。IBM没有把模型随平台一起交付，客户必须从支持清单中自行获取、许可并托管模型。于是Bob更像一个承接开发任务的智能体控制层，模型则成为可以替换、分区和单独治理的推理层。
推理地点决定代码经过哪条路径
自托管架构的关键，不在于界面是否仍然是Bob，而在于代码、上下文和构建产物最终在哪里被处理。完全隔离的部署路径可以使用NVIDIA Nemotron或Poolside Laguna，由客户在自己的基础设施上完成推理。混合路径则允许通过批准的私有连接使用Claude Sonnet 5.0、Claude Opus 4.8、Gemini 3.7 Flash或OpenAI GPT 5.6 Sol等外部模型。
可以把IBM给出的部署选择理解成一个证据块：本地或隔离模型对应最高的边界控制，但客户承担模型托管；批准的外部服务对应更少的本地模型负担，但代码和上下文需要经过企业认可的连接；混合模式则按工作负载分配两条路径。开发者看到的是相对一致的Bob体验，平台和安全团队真正控制的是每类代码能否离开企业边界。
混合部署把合规从总开关变成工作负载规则
对银行、主机和长期运行的企业系统而言，代码主权很少是一个简单的“全部留内”或“全部上云”选择。核心银行应用、受监管的主机代码或尚未完成分类的遗留系统，可以使用本地推理。相对低敏的开发任务，则可能通过批准的外部模型获得更强的能力或更快的迭代。Bob试图把这两种需求放进同一套开发流程，而不是让团队维护两套完全不同的工具链。
这也是自托管Bob与只把智能体接入自身DevOps平台的产品之间的差异所在。GitLab和GitHub的比较重点更多是平台内的代理能力，Mistral则把代理与自身开放权重模型绑定。IBM的取舍是面向长期维护的Java、IBM i和IBM Z资产，在不能接触公共互联网的环境中保留一套统一的开发控制面。它解决的是部署边界和遗留系统适配问题，不是自动消除模型选择带来的工程差异。
统一体验不会统一模型能力
把模型从平台中拆出来，确实让架构更容易按场景调整，但也把复杂度显性化了。自托管并不等于模型选择自由。企业仍然受IBM支持清单、模型许可、本地算力和部署条件约束。IBM还没有公布自托管价格，客户需要通过演示申请进一步了解商业方案，这意味着总成本不能只按一个平台订阅费估算。
更容易被界面掩盖的是能力差异。即使Bob的工具调用、任务编排和验证流程保持一致，不同模型在代码理解、长任务稳定性、延迟和资源消耗上的表现仍可能不同。一个能把高敏代码留在隔离网络中的方案，并不自动等于一个在所有现代化任务上都同样有效的方案。
适合先做边界清晰的现代化试点
对技术负责人而言，Bob自托管版更适合作为架构试点，而不是直接替换整个开发平台。可以先选择一类边界清晰的资产，例如银行核心系统、IBM i应用或IBM Z代码，把本地模型路径、工具权限、构建环境和结果验证流程固定下来。与此同时，较低敏的工作负载可以单独评估是否允许走批准的外部模型路径。
判断标准应当包括四件事：代码和上下文是否按分类正确路由，模型许可和本地算力是否可持续，统一的Bob体验是否掩盖了关键能力差异，以及隔离部署带来的运营成本是否低于现有方案。IBM已经把多模型路由列为未来扩展方向，因此目前不应把它当成已经交付的自动调度能力。可执行的结论是，先把“什么代码可以去哪一个模型”定义成平台政策，再决定是否扩大Bob的覆盖范围。