IBM Bob 走进防火墙之内，而这正是关键所在

IBM 已开始以自托管形式提供其智能体软件开发平台 IBM Bob。本地部署、私有云、主权云以及物理隔离环境都在可选之列。客户可以自行选择模型配置，把源代码和应用上下文留在自己的网络内，并保有对数据驻留和安全策略的控制权。

这听起来像是部署方式上的一则脚注。但它更像是一个关于「究竟谁能使用编码智能体」的命题。

自托管所填补的那道鸿沟

编码智能体的进展很快。它们能读取代码仓库、提出修改建议、运行测试并提交拉取请求。对一家初创公司来说，把智能体接入云服务不过是某个周二下午的事。但对国防承包商、银行或医院系统而言，同样的动作会在第一轮法务审查就卡住。源代码不能离开大楼。内部上下文——那些让代码库变得可理解的、杂乱的组织知识——同样不能外流。而物理隔离环境从设计上就没有通往云的路径。

这让经济中相当大的一部分只能隔着玻璃观望智能体时代。IBM 正是冲着这一块市场去的，而且它并非第一家。这个品类目前规模还小，主要是因为自托管智能体需要模型权重、硬件，以及一层通常由云厂商提供的编排能力。谁能把这条工程管线解决掉，谁就能获得那些「API 优先」的实验室触及不到的客户群。

为什么这件事比看上去更难

把智能体理解为一个循环，比把它理解为一个单一事物要容易：规划、行动、观察、调整。在云端，它调用的工具都是服务，各种故障模式都是别人的问题。而在防火墙后面，智能体必须访问同样的代码仓库、同样的工单系统、同样的构建系统——只不过现在网络是分段的，凭证按计划轮换，而其中一半的服务上次更新时，「智能体」这个词还没什么含义。

IBM 的说辞依托于一个事实：它本来就在向这类环境销售产品。它的客户运行着别人都不愿碰的大型机和遗留系统。让智能体在那里跑起来既不光鲜，也很缓慢，而这恰恰是能筑起护城河的那类工作。

还有一个治理层面的角度，而且这一点被反复提及。自托管智能体生成的日志归你所有。在受监管的审计中，你可以准确展示是哪个模型在运行、它读了什么、改了什么。而在云端方案里，这些证据散落在厂商的控制台和一份服务协议里。一旦出事，「我们有日志」和「我们已申请调取日志」之间的差别，就是一个已经了结的事件和整整一个季度的取证调查之间的差别。

底层绕不开的模型问题

自托管一个智能体，就意味着自托管一个模型，或者至少选一个你能放进自家算力上跑的模型。IBM 允许客户选择受支持的配置，实践中也就是开源权重模型与 IBM 自有模型的组合。开源权重选项在这里很重要。一个运行在私有集群上的 70B 级别模型，比最好的托管模型更慢、能力也更弱。但当网络中断时、当厂商涨价时，或者当厂商认定你的用例违反了你从未读过的某项政策时，它依然可用。

企业已经在数据库领域做了十年的这种取舍，结果如出一辙：它们接受一定的能力差距来换取控制权，然后随着硬件进步逐步缩小这个差距。

防火墙之内的经济账不一样

云端编码智能体按 token 计费，这意味着成本会随着智能体读写代码的量而增长。对初创公司来说，这是一笔可预测的支出。但对大型企业而言，单个代码仓库可能承载着数十年的历史，智能体在能帮上忙之前必须先消化多得多的上下文，于是计量表转得飞快。

自托管则把这个模式颠倒过来。成本变成了硬件和运维，也就是组织本来就已经承担的资本支出。一家拥有数据中心的银行，不会因为智能体多读了一百万行代码就多付钱。新增一次智能体任务的边际成本趋近于电费和 GPU 时间，而这些都是沉没成本。正是这种不对称，使得即便云产品客观上更好，自托管的说辞依然站得住脚。

不过，营销材料会略过一项合规成本。自托管把打补丁、监控和模型更新的负担转移给了客户。云厂商推一个修复，事情就结束了。而本地部署必须安排升级窗口、针对内部系统做测试，还要过变更控制委员会的审批。工具更可控，工作量也更大——而这正是企业软件的全部故事。

让这件事可行的相邻市场

只有当墙内确实有值得运行的东西时，自托管智能体才成立，而这种供给已经成长起来了。能够胜任真实编码工作的开源权重模型如今已很常见，由多个大洲的实验室以宽松许可证发布。缺的从来不是模型，而是那套「马具」——把模型变成开发者可以在受控网络内放心委派任务的对象。

这正是 IBM 在卖的那一层。训练出最好的模型不是目标；成为让现有模型在无法调用云服务的场所可用的那套集成才是目标。这套策略与「API 优先」的实验室正好相反：它们把能力向外推，让任何人接入；IBM 把能力向内收，让它能在边界之内存活。

对于被困在这道边界内的买家来说，过去两年的选择一直不太好受：要么远远地看着智能体浪潮，要么打破一条安全规则去加入它。自托管选项不会让浪潮变小，只是让它变得够得着——而对一个受监管的组织而言，够得着就等于它是真实的。

值得关注什么

演示并不是关于自托管智能体编码的关键问题。真正的问题是：面对一个有着十五年技术债、由早已离职的人写成的代码库，结果是否依然站得住脚。云端智能体在这件事上也很吃力。区别在于，自托管智能体无法由厂商一夜之间改进，除非客户自己动手。每一点提升，都必须由客户自己的团队挣来。

这让采用过程更慢，也更黏，而这正合 IBM 的心意。它为那些以年、而非以冲刺来衡量成功的买家而建，这些买家宁愿拥有一件稍差但自己能检视的工具，也不愿租用一件更好却无法审视的工具。对于一个花两年时间追逐基准测试的编码智能体市场来说，这是一个保守的押注。但它押的也是市场上至今尚未被服务的那一部分。

也存在一种糟糕的走向。自托管工具素有「发布一次便从此荒废」的名声，因为厂商没有持续改进它的动力，客户也没有讨价还价的筹码去要求。如果 IBM Bob 停留在一个稳定却再无实质进步的产品上，它吸引来的买家就会恰好得到他们所要的，却少于他们所期望的。另一种可能，是自托管智能体按照客户掌控的节奏持续改进——这条路更难走，但价值大得多。IBM 最终交付的是哪一种，正是未来一年值得关注的事。