GitHub Copilot 创始工程师 Neel Sundaresan 正在构建 IBM Bob——一款智能编码工具，目前已有 8 万名 IBM 开发者在使用。
Neel Sundaresan 回避了三个问题，其中一个是 “IBM Bob 为什么取名叫 Bob”。
这种回避本身就耐人寻味。Sundaresan 现任 IBM 软件部自动化与 AI 总经理，也是微软 GitHub Copilot 创始工程师，早年还曾担任 IBM 研究员，并不是一个擅长做产品营销的人。他是研究员出身，后来成为产品构建者，再后来成为高管，贯穿这三个角色的始终都是同一个执念：究竟是什么在阻碍软件开发者提高效率，又该如何消除这些障碍？
他从 2000 年就开始研究这个问题，远早于 Transformer 架构和大语言模型的问世，也远早于 AI 与开发者工具被主流技术圈关联在一起。从那时候起，到已在 IBM 内部为 8 万用户提供服务的 IBM Bob 正式发布，这条探索之路远比发布会新闻稿所呈现的要漫长得多。
在无人关注的时候开始
Sundaresan 为提升开发者效率所搭建的第一个系统和如今我们熟知的 AI 编码工具截然不同。那是一个 API 调用推荐系统。
“开发者有 30% 的代码都是 API 调用，”他在接受《The New Stack》深度访谈时表示。“当你在一个类名后面按下点号，就会弹出一长串可供调用的函数，你得从中挑选一个。这本身就是一个效率损耗点。”
目标并不是生成代码，而是在恰当的时机给出正确的函数调用，本质上是开发者代码自动补全场景的搜索排序问题。
当时的模型不是 Transformer，甚至从现在的定义来看，也不是深度学习模型。但他表示，开发者们很喜欢这个工具。这个早期的启示——在开发流程里某个细微的环节降低使用阻力就能收获超乎预期的用户满意度——直到如今，仍在影响着 Sundaresan 对这类问题的思考逻辑。
“编码是一项分析性工作，和网购不一样，”他说。“如果系统给出了错误的推荐，或是给出会干扰我思路的推荐，那就有问题了。”
他认为，用户体验和底层 AI 的实现逻辑是两个相互独立、互不干扰的问题。即便模型性能再好，如果表层产品体验设计出现偏差，整体产品体验也会大打折扣。
他见证了模型领域的演进：长短期记忆网络（LSTM）、早期的编码器解码器架构、谷歌的 Transformer 论文，以及初代 GPT。在每一个发展阶段，他的团队早已明确了所要解决的问题，只是当时的模型还不够强大。“如果你回看我们发表的论文，这些相关领域我们都有涉猎，” Sundaresan 说道，“每篇论文都会提到哪种模型适合解决这类问题、哪种模型适合解决那类问题。”
当前沿模型终于具备了足够的能力，足以支撑更大投入并获得回报时，Copilot 应运而生，他说道。但到那时，Sundaresan 也已经花了多年时间观察模型会在哪些场景出现问题——以及围绕模型的产品设计会在哪些环节出现疏漏。陈旧的训练数据会导致模型生成看似笃定却虚假的信息。无论任务是否需要，都倾向调用性能最强、成本也最高的模型。在企业受限的运行环境中部署高性能模型也存在不小难度。
“就连我们的客户也不放心把数据发送到我们的云端，”他谈及在微软的早年经历时说道，“他们希望数据留在客户端。所以我们让模型直接在个人笔记本上运行，还为此投入了大量工程优化工作，确保它能在笔记本有限的资源条件下顺畅运行。”
为什么是在 IBM？
当 Sundaresan 讲述这段历史时，一个显而易见的问题是：他为什么把多年积累的知识带到了 IBM，而不是某个更光鲜的地方。他直言不讳：在微软待了十年后，他想换个环境，而 IBM 给出了一个很有说服力的理由。
但还有一个不那么显而易见的答案：对于他所研究的问题，IBM 的所谓“劣势”实际上是“优势”。
“仅软件部门，我们就有近两万名员工。我们有完善的基础设施与咨询业务，IBM 内部本身就有大量用户，”他说道。“如果我能打造出让他们受益的产品，这本身就是一个体量巨大的产品。”这种内部部署模式——IBM 称之为“零号客户”——给了他任何外部产品发布都无法提供的东西：一个规模庞大、多元且愿意容忍早期产品缺陷、换取实际效率提升的固定用户群体。
另一个优势在于工作负载的多样性。IBM 内部的开发者不仅编写 Python 和 Rust 代码，还会使用 PL/I、COBOL、大型机 JCL，还有被 Sundaresan 形容为“如同行业俚语一般的自定义语言”。只要 Bob 能够适配这么广的技术范围，就能应对各类企业客户的任意开发场景。
“在敲开客户大门之前，我们就有故事可讲了，”他说道。
他也直言不讳地说明了自己的研发定位：不是面向开发者的通用工具，而是一个专门针对企业场景的系统，而大多数 AI 编码工具把这些场景条件当作边缘情况：遗留代码库、严格的合规要求、混合环境，以及 AI 生成的看似可以投产但实际上却不行的代码所带来的真实成本。
没人谈及的成本问题
与 Sundaresan 的对话中，有一段十分坦诚的表述，他道出了大多数开发者在不受约束的情况下如何使用 AI 编码工具。
“人们会选择最新的 Claude Opus 4.7 这类顶级模型。他们可能只是执行一条简单的提示词，但成本却高达每百万词元 40 美元，”他说。“这就好比开着法拉利去便利店买牛奶，完全没有必要。”
Bob 不会向用户暴露底层模型，它会根据实际任务需求自动调度路由，可选模型包括 Anthropic Claude、Mistral 开源模型、IBM Granite，以及多款专为 Bob 运行环境定制微调的专有模型。
这种智能路由能力正是 Sundaresan 认为的真正能体现架构设计价值的核心。“这并非简单地将各类模型接入系统，”他表示，“而是要把模型能力、产品体验，以及能够支撑优质体验的架构有机结合起来。模型只是整体方案的一部分。”
他介绍了在 IBM 内部用户群体中开展 A/B 实验的做法：测试各类前沿模型变体、监测用户使用模式，识别出高成本模型被滥用于普通模型即可胜任的场景。这种内部部署让这类大规模实验得以落地，其规模是任何早期初创产品都负担不起的。
智能体市场究竟将去往何方
被问及 Sundaresan 对智能体 AI 炒作周期的看法，他给出的会是研究者视角的答案，而不是管理者视角的表态。
“无风不起浪，”他接受《The New Stack》采访时表示，“如果炒作是烟，那背后一定有火。火势或许没有烟那么大，但火苗确实存在。”
他的判断是，基于智能体的开发模式确有实际价值，但并非新生事物。基于服务的开发、基于 API 的开发、基于智能体的开发，这些模式以往早已存在。真正的变化在于，如今的接口是概率性、对话式的，而非传统的确定性、程序化接口。这种转变催生了全新的能力，同时也带来了全新的风险。
“你也可以分散它的注意力，”他谈及智能体系统时说。“你可以问不该问的问题，或者透露不该透露的信息。”他所看到的 91% 失败的 AI 项目归根结底在于规范或者说纪律的缺失。企业以为和前沿模型提供商签个协议就够了，但事实并非如此。“在把它们集成到你的软件产品之前，你需要遵循已有的规范，”Sundaresan 说道。
他关注一个尚未得到足够重视的发展方向：智能体之间相互交互对话，最终会采用人类无法直接读懂的机器原生语言。“倘若这些衍生语言中出现漏洞差错，这类错误很可能会呈爆炸式扩散蔓延，”他说道。“未来还会有诸多变化发生。我们可以因为害怕而什么都不做，也可以勇敢但系统性地向前推进。”
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
