导读：GitHub Copilot 的创始工程师尼尔·桑达雷桑（ Neel Sundaresan ）目前正在开发 IBM Bob，这是一款已被 80,000 名 IBM 开发人员使用的智能编码工具。

在最近与媒体的谈话里，尼尔·桑达雷桑拒绝回答了三个问题。他带着几分戏谑说，其中一个问题是：为什么IBM的Bob叫Bob？

这种回避方式颇具一些深意。桑达雷桑——这位IBM软件自动化与人工智能总经理、微软GitHub Copilot的创始工程师，此前曾在IBM担任研究员——并非一名营销人员。他是一位从研究员转型为开发者，最终成为高管，而贯穿这三个角色的主线是同一个执念：如何才能提高软件开发人员的效率？又有哪些因素阻碍了他们？

他从2000年就开始研究这些问题，那时Transformer模型还未出现，大语言模型也尚未问世，甚至在当时的小众研究圈之外，没有人会认为人工智能和开发者工具可以放在一起讨论。从那时到本周发布的IBM Bob（目前已在IBM内部拥有8万用户），其发展历程远比稿中所描述的要长。

早在任何人观看之前就开始了

Sundaresan 为提高开发者效率而构建的第一个系统，与我们今天所理解的 AI 编码工具截然不同。它是一个 API 调用推荐系统。

“30%的开发者代码都是API调用，”他在接受媒体专访时说道。“如果你使用类调用某个函数，你会得到一长串待调用的函数列表，然后你必须从中选择。这本身就是一个痛点。”

其目标不是生成代码，而是在合适的时机显示正确的函数调用——本质上，这是一个应用于开发者自动完成体验的搜索排名问题。

这个模型并不是变形金刚，甚至也不是现代意义上的深度学习模型。但开发者们却非常喜欢它，他说道。而这一早期信号——即在开发流程中某个特定的小环节减少摩擦就能带来巨大的满足感——至今仍然影响着桑达雷桑对这个问题的思考方式。

“编程是一项分析性工作，这与网上购物不同，”他说。“如果系统给出错误的推荐，或者给出的推荐会干扰我的思考过程——这很重要。”

他认为，用户体验与人工智能底层的运行机制无关。即使模型本身更好，如果表面设计出错，最终得到的产品也可能更糟糕。

他见证了大模型领域的发展历程：长短期记忆模型、早期编码器-解码器架构、谷歌Transformer论文，以及第一个GPT模型。在每个阶段，他的团队都已经看到了他们试图解决的问题。只是当时的模型还不够强大。“如果你回顾一下我们发表的论文，你会发现我们在所有这些领域都有涉猎，”桑达雷桑说道，“每篇论文都会指出，这是解决此问题的模型，这是解决彼问题的模型。”

“就连我们的客户都不愿意把数据发送到我们的云端。他们希望数据保留在客户端。所以，我们实际上会让模型在笔记本电脑上运行——为了确保它能在笔记本电脑上运行，我们做了大量的工程工作。”

他表示，当尖端模型最终具备足够的能力，能够让更大胆的尝试获得回报时，Copilot 应运而生了。但在此之前，Sundaresan 也花了数年时间观察模型的误差——以及围绕这些模型的产品设计存在的缺陷。训练阈值导致了错误的自信信息。人们倾向于为每项任务都选择最强大（也最昂贵）的模型，而不管是否真的需要。在企业实际运营的受限环境中运行高性能模型也并非易事。

“即使是我们的客户不愿意把数据发送到我们自己的云端，”他回忆起微软早期的岁月时说道。“他们希望数据保留在客户端。所以，我们实际上会让模型在笔记本电脑上运行——为了确保它能在笔记本电脑上运行，我们做了大量的工程工作。”

为什么选择 IBM？

当桑达雷桑讲述这段经历时，人们自然会问：他为什么选择加入IBM而不是去其他更耀眼的公司？他的回答很坦率：在微软工作十年后，他想换个环境，而IBM的条件给的非常诱人。

但不太明显的答案是，就他遇到的具体问题而言，IBM 的负债实际上是资产。

“在软件部门，我们有近两万名员工。我们有基础设施，我们有咨询服务。IBM内部用户数量庞大，”他说道。“如果我能创造出对他们有益的产品，那本身就是一个巨型产品。”这种内部部署——IBM称之为“零号客户”——为他带来了外部产品发布无法企及的东西：一个庞大、多元化且忠诚的用户群体，他们愿意承受早期的摩擦，以换取真正的生产力提升。

另一项优势在于工作负载的多样性。IBM 的内部开发人员会编写Python和Rust 代码，但他们也会编写PL/I、COBOL、大型机 JCL以及 Sundaresan 所说的“自定义语言，例如俚语”。如果 Bob 能够处理如此广泛的工作负载，那么它就能应对企业客户提出的任何需求。

“在我们敲开客户家门之前，我们就已经有一个故事要讲了，”他说。

他也直言不讳地指出他所构建的体系针对的是什么。它不是一个适用于任何开发人员执行任何任务的通用工具，而是一个专门针对企业环境优化的系统，而大多数人工智能编码工具都将企业环境视为边缘情况：遗留代码库、严格的合规性要求、混合环境，以及人工智能生成的代码看起来可以用于生产环境但实际上却不具备生产环境的实际成本。

没人谈论的成本问题

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

“这就像开着法拉利去买牛奶一样，完全没必要。”

“人们会选择最新的[Claude Opus 4.7]或其他什么版本。他们可能只是在做一个简单的推广活动，但一百万个代币Token就要花费40美元，”他说。“这就像开着法拉利去买牛奶一样，完全没必要。”

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

Sundaresan认为，真正的架构设计在于路由智能。“这并非简单地将模型套用到系统中，”他说道，“而是要引入模型、引入体验，以及构建能够提供卓越体验的架构。这三者必须完美融合。模型只是等式的一部分。”

他描述了在IBM内部用户群中开展A/B测试的过程——对比测试前沿模型的不同变体，监控使用模式，并找出哪些任务使用了成本高昂的模型，而成本更低的模型却能同样出色地完成。这种内部部署使得早期产品无法承受如此大规模的实验成为可能。

AI Agent 市场将走向何方？

如果你问 Sundaresan 关于智能体人工智能的炒作周期，他会给你研究人员的答案，而不是总经理的答案。

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

他认为，基于代理的开发是真实存在的，但并非新生事物。基于服务的开发、基于API的开发、基于代理的开发——所有这些都早已存在。改变的是，如今的接口是概率性的、对话式的，而非确定性的、程序化的。这种转变创造了真正的新能力，但也带来了真正的新风险。

“我们可以因为害怕而什么都不做，也可以勇敢而有条不紊地向前迈进。”

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

他关注的方向，也是他认为应该得到更多重视的方向，是能够与其他智能体交流的智能体，最终会使用人类无法直接阅读的机器原生语言。“如果这些衍生语言中出现错误，后果可能不堪设想，”他说。“未来还有很多事情要做。我们可以畏首畏尾，什么都不做，也可以勇敢而有条不紊地向前迈进。”

作者：场长