IBM Bob 可以自托管了：代码、上下文、构建产物都不用出你的环境

9 月 30 日，IBM 把 Bob 的自托管能力正式推出来了，支持自托管、气隙和混合三种形式。公告里有一句话是这么写的：

“Security, data sovereignty and operational requirements may require source code, application context, and build artifacts to remain within approved environments.”

带着自托管模型配置时，官方原话是 “code, development context and build artifacts can remain within the customer-managed environment”。注意最后三个字，customer-managed，客户自管的环境。

也注意前面那串名词：源码、应用上下文、构建产物。IBM 特意把构建产物和源码并排写了出来。

为什么是这三样，而不是笼统的「代码」

企业买 AI 编程工具，过去一年里问的问题在变。

最早问的是它写得好不好，答案靠 benchmark 和内部试点。后来问的是它写的东西敢不敢用，问题开始落到流程上：代码走不走 review，有没有测试，责任人是谁。

现在的问题更靠前一步：东西在谁手里。

这不是洁癖。今年 4 月出过一次真事故。一个跑在 Railway 上的项目，Cursor 的 agent 带着 Claude Opus 4.6，通过一次 API 调用删掉了生产数据库和卷级备份，整个过程 9 秒。事后 agent 的说明是：“I guessed that deleting a staging volume via the API would be scoped to staging only. I didn’t verify.” 它猜这么删只影响 staging，它没验证。

根因不是模型判断失误，失误只是结果。根因是那个 API token 长期存续、权限过宽，被放在一个跟代码库无关的文件里；没有即时提权，没有人工确认门，备份和生产还挂在同一卷上。每一环都缺一道锁。

如果这场事故发生在一个要求产物不出客户环境的体系里，至少会多一道边界拦住它，因为那串 token 能不能从那个环境里被取到，本身就成了一个必须回答的问题。

所以 IBM 把 build artifacts 写进公告不是凑字数。代码在本地，但跑起来产生的中间物、构建输出的产物、日志和上下文，同样可能带着敏感信息。只锁源码不锁产物，锁住的是一半。

IBM 那篇公告里还有一句话被 SD Times 引了出来：“The platform brings AI to the data instead of moving the data to the AI.” 把 AI 带到数据这边，而不是把数据搬到 AI 那边。跟自托管讲的是同一件事，数据不动，工具动。

产物是工程里的资产，还是工具的会话记录

飞算 JavaAI 是 IntelliJ IDEA 的插件，在智能会话里跑一条按环节推进的指令链：需求分析、前后端设计、前端开发、后端开发。

它的产物直接落进你当前打开的这个项目。需求文档和业务设计文档落在 docs，前端工程落在项目自己的 frontend 目录，源码和 SQL 按项目原本的结构生成。这些文件就在你自己的工程目录里，你的版本控制管着它们，你的构建流程读得到它们，你的同事在 code review 里能看到它们。

它不替企业解决数据主权的问题，模型调用是另一回事，这一点后面边界里会说清。它解决的是另一个层面的事：交付物本身是不是留在工程里，而不是留在某个工具的云端会话里。

两者的差别在具体场景里才显出来。你今天关掉那个会话，明天换一台机器，后天来了个新人，产物还在不在？接口设计文档能不能直接打开对着改代码？需求当时为什么这么定，查得到吗？如果答案依赖「我还记得那个对话窗口在哪」，那它就不是工程资产，是一次性的工作记录。

IBM 公告里那三个词搁在这个场景里对得很清楚：源码在你自己的仓库里，上下文也就是需求文档、业务设计文档、接口设计文档，在你项目的 docs 里，构建产物由你自己的构建工具在你的机器上产出。它们都不依赖某个对话框的历史记录。

企业级 AI 编程的竞争，正在从谁写得好转向谁的东西放得明白。前者是模型能力的比拼，差距会慢慢抹平；后者是工程习惯的比拼，会一直拉得开。

同样一周，几家在做不同的事

这周里跟这件事并排的还有两条。

10 月 1 日 JetBrains 开了 Air 的 EAP，明确说不预装 agent，把自己做成通道，让 Codex、Copilot、Cursor 这些都能接进来。这是把选择权交回给用户的路线。Qodo 3.0 的思路不一样，它把治理规则塞到生成之前，让约束先于代码存在。

一家在解绑，一家在加锁，一家在提前设规则。做法不同，回答的却是同一个问题：agent 进了企业之后，它的产出到底归谁管。

这也解释了数据主权这个词为什么偏偏在这个时间点被反复提起。不是因为合规部门忽然变得敏感，而是因为 agent 产出的东西比过去任何工具都多、都散，也更接近系统本身，多到已经没法用「这是开发工具的使用数据」打发过去。

边界

先说清一件事，免得被误读：飞算 JavaAI 讲的是产物存放位置，不是工具的部署形态。它是 IDEA 插件，模型调用走云端，这一点不用绕开，也不该含糊。写成代码不出内网、本地推理是不准确的。

它真正解决的是交付物归属：你产出的文档、代码、工程，落在你自己的工程目录里，由你的版本控制管理。

自托管这个选项本身有它的代价。IBM Bob 支持自托管模型（NVIDIA Nemotron、Poolside Laguna）和混合或私有 SaaS 模型（Claude Sonnet 5.0、Opus 4.8、Gemini 3.7 Flash、GPT 5.6 Sol）两类，也支持 BYOL，但多一套环境就多一套运维，气隙部署对更新节奏和依赖管理的要求也更高。它适合有明确合规要求的团队，不是通用推荐。

有件事不用等到出事才想：下次有人问「这个接口当初为什么这么设计」，你团队能在几分钟内翻出来吗。