AI编程工具的“大材小用”：IBM Bob的智能之道

导读：GitHub Copilot 的早期工程师尼尔·桑达雷桑（Neel Sundaresan）目前正致力于开发 IBM Bob，这是一个已被 IBM 内部 80,000 名开发者采用的智能编码辅助工具。

在近期与媒体的交流中，尼尔·桑达雷桑巧妙地回避了三个问题，其中一个便是关于 IBM 的 Bob 工具为何得名 Bob。他带着几分戏谑的语气。

这种略显神秘的回避方式，实则蕴含深意。桑达雷桑，这位 IBM 软件自动化与人工智能部门的总经理，同时也是微软 GitHub Copilot 的创始工程师，此前曾在 IBM 担任研究员。他并非传统的市场营销人员。他的职业生涯轨迹——从研究员到开发者，再到高管——始终围绕着一个核心关切：如何才能最大化地提升软件开发人员的效率？又是什么因素在阻碍他们的前进？

他对这些问题的探索始于 2000 年，彼时 Transformer 模型尚未问世，大语言模型也只是小众研究领域的概念，人工智能与开发者工具的结合更是鲜为人知。从那时起，到本周发布的 IBM Bob（目前已有 8 万内部用户），其发展历程远比在此赘述的要漫长得多。

“30% 的开发者代码都涉及 API 调用，”他在接受媒体专访时指出。“当你通过类调用某个函数时，会弹出一长串待选的函数列表，你必须从中仔细挑选。这本身就是一个令人头疼的问题。”

其核心目标并非是生成代码，而是在恰当的时机，精准地呈现出正确的函数调用——本质上，这可以被看作是一个应用于开发者自动补全体验的搜索排名问题。

这个模型并非基于 Transformer，甚至也不是现代意义上的深度学习模型。然而，开发者们对其表现出了极大的喜爱，他提到。而这一早期信号——即在开发流程的某个细微环节中减少阻力，便能带来显著的满足感——至今仍在深刻影响着桑达雷桑对该问题的思考方式。

“编程是一项需要深度分析的工作，这与你在网上购物是截然不同的，”他说道。“如果系统给出了错误的推荐，或者其推荐干扰了我的思考流程——这一点至关重要。”

他坚信，用户体验的优劣与人工智能底层运行机制的先进与否并无必然联系。即使模型本身非常强大，如果其前端设计存在缺陷，最终呈现给用户的产品体验也可能大打折扣。

他亲历了深度学习模型领域的发展变迁：从长短期记忆模型、早期的编码器-解码器架构，到谷歌的 Transformer 论文，再到首个 GPT 模型。在每一个阶段，他的团队都曾致力于解决他们所关注的问题，只是当时的模型性能尚不足以支撑。“如果你回顾我们过去发表的论文，你会发现我们在所有这些领域都有所涉猎，”桑达雷桑表示，“每篇论文都清晰地指出了，这是用于解决此问题的模型，那是用于解决彼问题的模型。”

“即便我们的客户也不愿将数据传输到我们的云端。他们要求数据必须保留在本地设备上。因此，我们实际上让模型在笔记本电脑上运行——为了实现这一点，我们付出了巨大的工程努力。”

他解释说，当最前沿的模型终于发展到足够强大，能够支持更大胆的尝试并带来显著回报时，GitHub Copilot 应运而生。但在那之前，桑达雷桑花费了数年时间去观察模型产生的误差，以及围绕这些模型存在的缺陷产品设计。训练阈值导致了错误自信信息的生成。人们倾向于为每项任务都选择最强大（也最昂贵）的模型，而忽略了实际需求。在企业实际运行的受限环境中部署高性能模型也绝非易事。

“即使是我们的客户，他们也极不愿意将数据发送到我们自己的云服务器上，”他回忆起微软早期的经历。“他们更希望数据能够保留在本地设备。所以，我们实际上让模型在笔记本电脑上运行——为了确保它能在笔记本电脑上稳定运行，我们付出了大量的工程心血。”

当桑达雷桑讲述这段经历时，人们自然会产生疑问：他为何选择加入 IBM，而非其他更具吸引力的公司？他的回答直截了当：在微软工作了十年之后，他渴望尝试新的环境，而 IBM 提供的条件极具吸引力。

然而，一个不那么显而易见的答案是，就他所要解决的具体问题而言，IBM 的“包袱”实际上成为了它的“资产”。

“在我们的软件部门，拥有近两万名员工。我们具备完善的基础设施，我们提供专业的咨询服务。IBM 内部拥有庞大的用户基础，”他说道。“如果我能够创造出对他们有价值的产品，那本身就是一个意义重大的项目。”这种内部应用——IBM 称之为“零号客户”——为他提供了一个外部产品发布所无法比拟的优势：一个规模庞大、用户群体多样且高度忠诚的群体，他们愿意忍受早期产品的不完美，以换取实实在在的生产力提升。

另一项显著优势在于工作负载的多样性。IBM 的内部开发者不仅编写 Python 和 Rust 代码，还会处理 PL/I、COBOL、大型机 JCL，以及桑达雷桑所说的“自定义语言，例如俚语”。如果 Bob 能够胜任如此广泛的工作负载，那么它将能够满足企业客户提出的任何需求。

“在我们正式接触外部客户之前，我们就已经拥有了一个引人入胜的故事可以讲述了，”他说。

他也毫不避讳地指出了他所构建的体系所针对的特定领域。它并非一个适用于任何开发人员、执行任何任务的通用工具，而是一个为企业环境量身定制的优化系统。而目前市面上大多数人工智能编码工具，都将企业环境视为一种特殊情况来处理：包括遗留代码库、严格的合规性要求、混合式环境，以及那些看起来能用于生产环境、但实际成本高昂且不具备生产能力的人工智能生成代码。

在与桑达雷桑的对话中，一个最坦诚的时刻是他描述了大多数开发者如何随意使用 AI 编码工具的现象。

“这就像是开着一辆法拉利去商店买牛奶，完全没有必要。”

“人们会选择最新的模型，比如 [Claude Opus 4.7] 或者其他版本。他们可能只是在执行一个简单的推广活动，但却要花费 40 美元来处理一百万个 Token，”他举例说。“这就像是开着一辆法拉利去商店买牛奶，完全没有必要。”

Bob 并不会向用户公开其底层所使用的模型。它会根据任务的实际需求，自动将请求路由到 Anthropic Claude、Mistral 的开源模型、IBM Granite，或者几个专门为 Bob 环境构建的专有、经过精细调整的模型之一。

桑达雷桑认为，真正的架构设计在于智能路由。“这并非简单地将模型集成到系统中，”他强调，“而是要整合模型、整合用户体验，并构建一个能够提供卓越体验的架构。这三个要素必须完美契合。模型仅仅是整个等式中的一部分。”

他详细描述了在 IBM 内部用户群体中进行 A/B 测试的过程——对比测试前沿模型的不同版本，密切监控使用模式，并识别哪些任务使用了成本高昂的模型，而实际上成本更低的模型也能同样出色地完成。这种内部部署使得早期产品难以承受的大规模实验成为可能。

如果你问桑达雷桑关于智能体人工智能（Agent AI）的炒作周期，他会以研究人员的视角而非总经理的视角来回答。

“无风不起浪，”他这样说道。“如果炒作是烟雾，那么火一定就在某个地方燃烧。它可能没有烟雾那么显眼，但火确实存在。”

他认为，基于代理（Agent-based）的开发模式是真实存在的，但并非全新的概念。基于服务的开发、基于 API 的开发、基于代理的开发——所有这些模式早已存在。不同之处在于，如今的接口是概率性的、对话式的，而非确定性的、程序化的。这种转变催生了真正的新能力，但也带来了真正的新风险。

“我们可以因为恐惧而裹足不前，也可以选择勇敢且有条不紊地前进。”

“你也可以分散它的注意力，”他谈到智能体系统时说道。“你可以提出一些不该问的问题，或者泄露一些它不该透露的信息。”他认为，他所观察到的 91% 的人工智能项目失败率，归根结底在于纪律性——或者说是缺乏纪律性。企业常常误以为与前沿模型提供商签订合作协议就万事大吉了。事实并非如此。“在将它们集成到你的软件产品之前，你需要确保自己遵循了相应的纪律，”桑达雷桑强调。

他关注的方向，也是他认为应该获得更多重视的方向，是那些能够与其他智能体进行交互的智能体，并最终使用人类无法直接理解的机器原生语言。“如果这些衍生出的语言中出现了错误，其潜在后果可能是灾难性的，”他说。“未来还有很多工作要做。我们可以因为恐惧而停滞不前，也可以选择勇敢且有条不紊地向前迈进。”

作者：场长

IBM 的人工智能编码伙伴“Bob”发布

微软与OpenAI重新签署“开放式”的合作关系

Anthropic推出Claude Managed Agents