本文来源于阿里云社区电子书《AIGC+软件开发新范式》
《AIGC+软件开发新范式》--01.当「软件研发」遇上 AI 大模型（2）：https://developer.aliyun.com/article/1537722
唯我专属
我觉得企业要想让代码大模型真的能实现一个非常好的效果，都逃不过这一关。比如如何实现企业数据的个性化场景，比如在项目管理阶段，如何能够让大模型按照需求 / 任务 /缺陷内容的一些固有的格式和规范去生成，帮我们实现一些需求的自动拆解、自动续写、自动总结等等。
开发阶段可能是大家最关注的，经常有企业会讲要有符合企业自己的代码规范，引用企业自己的二方库，调用 API 生成 SQL，包括使用企业自研的一些前端框架、组件库等等，这些都属于开发场景。测试场景也要生成符合企业规范的，甚至是理解业务的测试用例。在运维场景，要时刻查找企业的运维知识，然后去回答，去获取企业的一些运维的 API 快速生成代码。这些都是我们认为要做的企业数据化个性化场景。具体的做法是要通过检索增强或者微调训练的方式来实现。
在这里我列了一些简单的场景和需要注意的事项，包括代码应该怎么处理，文档应该怎么处理，代码过来要进行过滤、清洗、结构化，然后才能够可用。
在我们训练的过程中，要去考虑开放域数据和私域数据的混入。比如我们要去做一些不同的参数调整，在检索增强上，我们要考虑不同的检索增强策略，我们其实也是在不断的进行探索，包括如何在代码生成场景里面命中我们所需要的上下文信息，以及我们在问答场景里面如何去命中我们需要的回答的上下文信息，这属于检索增强。
我们要做的就是企业级的检索增强方案，企业级的检索增强方案目前的架构图大概是这样。中间是知识库的管理服务，包括数据解析的调度、问题的理解、整理回答、结构化的解析、数据分块等等，核心的能力在中间这块，向下是我们比较常用的 Embedding 的服务，包括大模型的服务、向量的存储和检索。
向上是我们管理的一些后台，在这个场景下支持了我们关于文档的检索增强以及代码生成的检索增强。代码生成也就是补全这个场景的检索增强它所需要的处理方式和技术跟文档其实还是略有不同。
过去我们跟复旦大学也做过几年的学术研究，非常感谢他们的付出，我们也有一些论文在发表，当时我们测试集的结果也是用一个一点几 B 的模型，再配合检索增强，它实际上的准确率和效果就可以达到一个大概 7B 以上模型的同等效果。
三 . 未来的软件研发 Agent 产品演进
我们认为未来软件研发一定会进入到 Agent 时代，也就是说它具备一些自主性，并且它可以
非常容易使用我们的工具，然后理解人类的意图，完成工作，最终会形成一个如图所示的多智能体的协同模式。
就在今年三月份，Devin 的诞生其实让我们感觉到这个事情真真实实的被加速了，我们从来没有设想到这个事情能够完成一个真实的业务项目，我们过去都没有想象到，甚至我们都觉得这个事情可能还要一年以后，但是它的出现让我们觉得，今天真的可以通过大模型拆解数百上千个步骤，并且一步一步执行，出现问题它还可以自我反思，自我迭代，有这么强的拆解能力和推理能力让我们非常意外。
随着 Devin 的诞生，各个专家学者就开始投入，包括我们通义实验室，马上发起的一个项目叫 OpenDevin。这个项目在短短的几周内 star 数就超过了 2 万，可以看到大家对这个领域非常的热情。然后马上开源了 SWE 的 Agent 项目，把 SWE- bench 的解决率又推升到了 10% 以上，过去的大模型都在百分之几，推升到 10% 已经接近了 Devin 的表现，所以我们判断在这个领域的学术研究会非常快，我们大胆猜测一下，很有可能在 2024 年年中左右的 6 到 9 月份，很有可能 SWE- bench 的解决率会超过 30%。
我们大胆猜测一下，如果能够达到百分之五六十解决率的话，它的测试集实际上是一些真实的 Github issue，让 AI 完成 Github 上面的 issue，可以去修复 bug，去解决需求的这样一个测试集。如果这个测试集能够让 AI 的自主完成率达到百分之五六十，我们认为真的是可以在生产级中落地了。至少一些简单的缺陷可以交给它来修复，这是我们看到的目前业界的一些最新的进展。
但是这张图也不是马上就能实现的，现在从技术路线上来讲，我们会沿着这四步逐步实现。第一步我们现在还在做单库的问答 Agent，这个领域是非常前沿的，我们现在在做单库的问答 Agent，近期会上线。
下一步我们希望推出能独立完成编码任务的 Agent，它的作用主要是具备一定的自主规划能力，可以使用一些工具去了解背景知识，能够自主的完成单库范围内的编码任务，还不是跨库，可以想象一个需求有多个代码库，然后前端也改、后端也改，最终形成一个需求，我们觉得还很远。
所以我们先实现单库的编码 Agent，下一步我们会去做测试 Agent，测试 Agent 可以基于代码 Agent 的生成结果，自动完成一些测试任务，包括理解任务的需求、阅读代码、生成测试用例，并且自主运行。
如果这两步的成功率做的比较高的话，我们就会进入到第三步。让多 Agent 基于 AI 调度共同完成任务，从而实现从需求到代码到测试的全流程自主化。
从工程的角度来讲，我们会一步一步这么来走，确保每一步都达到一个比较好的生产级落地，最终去做产品。但是从学术来讲，他们研究的速度会比我们更快，现在我们是从学术、工程讨论的，我们还有第三个分支就是模型演进。这三条路就是我们现在阿里云和通义实验室一起联合在做的一些研究。
最终，我们会形成一个 Multi-Agent 概念架构，用户可以跟大模型进行对话，大模型可以进行任务的拆解，然后有一个多 Agent 协同系统。这个 Agent 可以外挂一些工具，它有自己的运行环境，然后多 Agent 之间可以互相协同，它们还会共享一些上下文机制。
这个产品图会分为三层。最下面是基础层，对于企业来讲，可以先把基础层做好。比如现在可以引入一个代码大模型，我们虽然没有马上实现 AI Bot，但是现在已经具备了 IDE 代码生成插件的这些能力，已经可以做一些工作了，就是 Copilot 的模式。
Copilot 模式在基建层上面，进化了 Agent 这一层，实际上基建是可以复用的。该做的检索增强、微调训练和知识库，现在就可以做起来了。这些知识的梳理，资产的积累，是来自于原来 DevOps 平台的积累。现在就可以通过一些提示词工程的方式，将现在基础的能力层跟整个 DevOps 工具链进行结合。
我们做了一些实验，在需求阶段要想让这个大模型来实现一个需求的自动拆解，我们可能只需要将过去的一些拆解数据，还有现在的需求拼成一个 prompt 给大模型，大模型就可以比较好的去完成拆解并且完成人员的分配。在实验中发现，结果的准确率还是蛮高的。
其实现在整个 DevOps 工具链，并不需要所有东西都要用 Agent 或者都要用 Copilot。我们现在用一些提示词工程，就有很多场景可以马上去赋能，包括我们在 CICD 过程中的自动排错，在知识库领域的智能问答等都可以实现。
在实现多 Agent 以后，这个 Agent 可以在 IDE 里面透出，也可以在开发者的门户，即 DevOps 平台透出，甚至在我们的 IM 工具里面透出。它实际上是一个拟人的智能体。本身这个智能体它会有自己的工作区，在这个工作区里我们的开发者或者说管理者可以去监控它到底是如何帮我们完成代码编写的，如何帮我们完成测试的，它到底在互联网上获取了什么样的知识去完成工作，会有一个它自己的工作空间，最终实现整个任务的完整流程。
