规模化AI智能体：从9个真实案例中学到的经验

我们的全新报告探讨了软件开发领导者要推动智能体投入实际工作，究竟需要具备哪些条件。

一家组织的 AI 采用率达到了 95%，但开发者速度并未提升。另一家组织的拉取请求吞吐量提升至三倍，同时将缺陷积压减少了 54%。

差异的原因是什么？

为了弄清是什么让 AI 智能体在单个开发者之外也能发挥效用，我与来自 Fin、Semrush、Skiller Whale 及其他组织的工程领导者和从业者进行了交流。

这些发现现已收录在我们的新报告顶尖团队如何规模化部署 AI 智能体中，报告包含九个真实案例研究和从业者叙述，也包括来自 JetBrains 自身工程团队的洞见。

该报告不止关注采用率和个人生产力提升，还探讨当团队开始依赖 AI 智能体时，实际会发生哪些变化——他们如何组织工作、维护代码质量、共享知识、管理成本以及衡量结果。
下载免费报告

以下是我认为尤其突出的三条经验。

#1. 更多智能体无法修复有问题的开发工作流

在 Fin，最初目标是在不牺牲代码质量、安全性或性能的前提下，将拉取请求吞吐量翻倍。

Fin 没有简单地部署更多编程智能体，而是成立了专门团队 Team 2x，负责管理围绕智能体的基础设施，包括共享技能、插件、MCP 服务器和评估机制。

该团队用真实示例测试智能体技能，用历史 PR 对代码审查技能进行回测，并分析智能体会话，以识别反复出现的错误和缺失的上下文。

但产出增加也带来了新问题。CI 开始承压，代码质量变得不稳定。Fin 的应对方式是投入 Lint 检查和标准化。

在 16 个月里，Fin 报告称：

尤其值得注意的是，Fin 为了让工程系统的其余部分跟上，投入了大量工作。

即使能力很强的智能体，在无法可靠构建项目、运行测试或找到所需上下文时也会举步维艰。

在大型复杂代码库中，这尤其具有挑战性；开发者往往依赖多年积累的关于构建配置、依赖项和项目约定的知识。

在 JetBrains，我们一直在自己的大型 monorepo 中应对这个问题。我们的经验指出了几项实际要求：标准化的构建工具、快速的测试、可访问的 API，以及智能体能够自行搭建的环境。

教训很直接：在投入更多智能体之前，先看看是什么阻碍了你已有的智能体可靠完成任务。

在 Angie Jones 谈到的一家组织中，AI 采用率达到了 95%，但开发者速度仍未改变。

该团队将重点从鼓励使用 AI 转向帮助开发者委派有意义的工作。那些构建了更丰富的仓库级上下文的倡导者，最终提交拉取请求的速度达到了此前的三到四倍。

Skiller Whale 遇到了同一问题的另一种表现。在一次客户合作中，一个接受过监督 AI 智能体培训的团队将 PR 吞吐量大约翻了一番，而组织其他部分的吞吐量却下降了。

这些例子凸显了 AI 采用计划中容易被忽视的一点：开发者需要学习如何组织任务、提供上下文、评估结果，并与同事分享有效实践。否则，组织最终可能只得到少数高效的 AI 高级用户，而不是整体生产力更高的工程团队。

在这些交流中，一个模式不断浮现：那些取得实质性成果的组织，都在持续改变其周围的系统和实践。

这意味着让开发环境为智能体做好准备、建立共享标准、改进审查流程、投入团队学习，并衡量采用率之外的成果。

没有一套适用于所有工程组织的单一剧本，但有一些具体方法值得借鉴，包括那些第一次并未奏效的方法。

与这些团队交流让我思考了很多，我也相信还有更多值得分享的故事。我很想在评论区听听你们使用 AI 智能体的经历、学到的经验，或者仍在摸索的挑战。
获取免费报告