在那篇《2024 年 AI 辅助研发趋势》里，我们谈及了未来的趋势是：从辅助开发人员发展到涵盖软件开发的 整个生命周期。而软件研发本身也是一个复杂的流程，涉及到需求分析、设计、开发、测试、部署等等。 在开源的《AI 辅助软件工程：实践与案例解析》中，我们研究了国内公司的辅助研发工具，如 Google、GitHub、GitLab 等，以及对应的 Jira、Cursor、IBM Assistant Builder 等工具。

进而发现，现阶段我们需要解决一个问题：如何去打通工具之间的壁垒，让 AI 辅助研发工具更好地协同，以提高研发效率？

AI 辅助研发策略应该如何演进？

下图是当前 AI 增强的研发工具、平台的主要构建思路：

当前阶段，我们主要通过在已有的 DevOps 工具平台上，通过 AI 增强，来为端到端工作流、多角色协同场景提供场景化 Agents，提升协同效率。而从未来来看， 当前的 AI 辅助研发工具还存在一些问题。

问题 1：速赢和高杠杆领域已经被摘取

去年 5 月，我们在 QCon 上分享《探索软件开发新工序：LLM 赋能研发效能提升》里，其中我们建议企业应该关注：“速赢和高杠杆领域”，以得到更高的的投入产出比。

而在今年这些领域已经被摘取，如在辅助结构化需求、辅助代码生成、辅助代码审查等领域。大量的企业已经有一系列的“自研”工具，虽然可能缺少一些 最佳实践，但是或多或少已经在试点中，有一些还取得不错的效果。对于现有的开发流程而言，我们很难一一增强，我们还要面临工作使用者缺乏相关的 AI 技能，提不出好的问题和需求。

尽管，我们可以更多地关注长尾领域，如辅助部署、辅助运维等领域。这些领域的 AI 辅助研发工具还处于初级阶段，但是性价比不一定更高。

问题 2：AI 平台与工具的碎片化加深

相似的，如先前的图所示，企业已经购买了或者自建算力、模型平台、模型编排等平台的底层能力，以及大量的知识库， 再到辅助研发的需求助手、架构助手、测试助手、代码助手等等。就当前而言，企业普遍缺乏优秀的 AI 工程师，因此主流的方式是外购或者基于开源软件构建。

• 购买方式。对不同的平台、工具进行大量的前期试点或者评估，再选择最适合自己的工具。如基于 GitHub Copilot、通义灵码、CodeGeeX 等等。
• 自建方式。如基于开源 AI 应用开发平台 Dify、开源的 IDE 插件 AutoDev、Continue、开源的各类辅助研发 ChatBot 等等。

在这种情况下，未贴合企业实际需求的碎片化工具大量存在各个团队中，并且难以协同。碎片化的工具不仅会存在大量重复劳动，还会使得 AI 平台或者工具束之高阁，无法发挥最大的价值。那么，我们应该如何去打通这些壁垒呢？

什么是云端与 IDE 智能体协同？

在过去的一年里，我们看到了一些 IDE 智能体的案例：

• Bloop。可以使用自然语言提问，搜索代码，并基于现有代码库生成补丁。
• Tabnine - Jira to code。开发团队可以从 Jira 任务中自动生成功能完备的应用程序。
• GitHub Copilot Workspace。结合 GitHub 平台的需求功能（issue）、代码托管、构建、部署平台，实现从需求到代码的自动生成与部署。
• ……

这些智能体的共同点是：通过结合工具链来获取 IDE 的上下文信息，再结合云端的知识库等，来处理对应的的任务需求。

IDE 智能：如何最大化代码的价值？

在 IDE 侧，与智能体相关的能力通常有两类：

• 本地智能体。直接从本地获取所需上下文，直接与模型进行交互，如常用的 @workspace 功能，用于直接与代码库进行问答。
• 云端智能体集成/智能体市场。即与云端的智能体进行交互，通过多轮信息通信，提供其所需要的上下文，诸如 AutoDev 自定义的智能体、GitHub Copilot Extension 等。

对于本地智能体来说，其主要的优势是：速度快，可以直接快速获取本地的上下文信息，不需要网络传输。但是，其缺点是：无法获取云端的知识库 ，无法获取更多的领域知识。所以，对于一些需要大量领域知识的任务，如需求生成代码、代码审查等，我们需要通过云端智能体来获取更多的知识。

因此，对于 IDE 侧来说，我们需要能动态地提供云端所需要的上下文信息，并提供对应的智能体接口，以支持云端智能体的调用。

云端智能体：内部资产与研发知识的集成

如图 1 所示，我们在过去已经构建了一系列的智能体，它们都基于各自领域的特点，提供了所需要的知识与最佳实践。诸如，我们会在需求助手中，添加所属领域的 知识库，需求编写的最佳实践等等。而事实上，对于这一类需求助手只有这一些是不够的，代码的现有实现逻辑，会影响新功能的设计。

进而我们会发现：软件研发的各类智能体是你中有我，我中有你的。只是单独的一个智能体是无法完成整个研发流程的，我们需要将这些智能体进行整合，以支持 整个研发流程。

云端与 IDE 智能体协同的实现

在云端，大量企业已经构建了类似于 Dify 的 AI 应用平台，在这些应用平台上，已经可以支持对智能体的编排，因此实现上起来并不困难。但是，对于 IDE 侧来说，我们还需要构建一个类似的智能体编排系统，以支持 IDE 侧智能体的调用。

IDE 智能体编排系统

在 IDE 侧，我们需要构建一个智能体编排能力，以支持 IDE 侧智能体的调用。它需要支持：

• 快速获取 IDE 上下文信息。如当前的代码库、当前的代码、当前的需求等等。
• 轻量级的上下文处理。诸如对于代码库的搜索、静态代码分析等等。
• 与云端智能体的交互。通过 API 调用，获取云端智能体的结果。
• 与三方工具的集成。如与 Sonarqube、GitHub、Git 等工具的集成，以支持对应的需求、代码库的获取。
• 数据的安全性。对于代码库、需求等敏感信息，需要进行加密处理。

让用户能够为他们自己的 IDE 创建定制的 AI 智能体，从而构建个性化的 AI 驱动开发环境。

云端与 IDE 智能体协同实现：Shire 示例

Shire 提供了一种简便 AI 编码智能体语言，能够让大型语言模型（LLM）与控制集成开发环境（IDE）之间自由对话，以实现自动化编程。在 Shire 中，你可以 通过编程语言的方式，来定义与 IDE 的交互信息处理，以及与远程智能体的交互。

如下是一个简单的 Shire 结合数据库信息，与远程智能体生成 SQL 的示例：

---
name: "设计数据库"
variables:
  "requirement": /any/ { thread(".shire/shell/dify-epic-story.curl.sh") | jsonpath("$.answer", true) }
afterStreaming: {
  case condition {
    default { execute("gen-sql.shire", $requirement, $output) }
  }
}
---
[相关的数据库设计库提示词]

— User use database: $databaseInfo
- User tables: $tables

Here are the User requirements:

$requirement

在这个示例中，我们通过 thread 函数，调用了一个部署于 Dify 上的远程智能体，获取了相关业务的需求。在 AI 分析完需求后，再通过 execute 函数， 再调用了一个本地的智能体（即 gen-sql.shire），生成了 SQL。在 gen-sql.shire 中，我们定义了基本的 SQL 规范，以让 AI 生成的 SQL 更符合 企业规范。

你可以在我们的 GitHub 上找到更多的示例：Shire 示例 （ https://github.com/shire-lang/shire-spring-java-demo ） 。

小结

去年，我们在设计开源 IDE 插件 AutoDev 时，构建了一个 AutoCRUD 的智能体。这个智能体可以获取 GitHub、GitLab 上的 issue 作为需求，再结合本地的代码库，自动对代码进行修改。

我们相信，未来的 AI 辅助研发工具应该是：云端与 IDE 智能体协同。即通过 IDE 侧的智能体编排系统，与云端智能体进行协同，以支持整个研发流程的 自动化。