汪晟杰——腾讯云 AI 代码助手技术产品专家，腾讯资深产品专家，20 年工作经验，负责腾讯云开发者 AI 代码助手产品规划设计与运营，十多年协作 SaaS 和 SAP 云平台、SuccessFactors HCM、Sybase 数据库、PowerDesigner 等产品的开发经理，在软件架构设计、产品管理和项目工程管理、团队敏捷、AI 研发提效等方面拥有丰富的行业经验。

本文整理自汪晟杰在 AiDD 研发数字峰会深圳站的演讲内容。AiDD 峰会是具有专业性、专注性、全面性与前瞻性的顶级 AI 数字峰会，旨在协助企业利用 AI 技术深化计算机对现实世界的理解，推动研发进入智能化和数字化的新时代。下面，作者将从以下七个方面进行内容阐述：

一、SWE Agent 的起源与目前发展概述

先来聊聊 SWE Agent。从宏观角度作为软件工程师的智能体，应该像讲议左图一样，具备工程师的「专业」，除了具备代码专业知识的 Skills 外，还需要过往开发项目的经验（Career Path）、自主学习的分析能力（Education，具备联网检索学习能力），更需要有专业领域的解决工程问题的能力。于是最近比较火的 SWE Benchmark 就以这样的目标诞生，如右图，通过一系列 Issues 的自动思考修复的解决率，从而评判 SWE Agent 所拥有的「智能体」的阶段。

我认为目前以人的思考过程去自动修复一个专业问题，是很难真实解决的。 SWE Benchmark 初衷是考验模型在软件工程上的各方面能力，比如定位 bug 文件、定位 bug 函数、定位 bug 行、修复 bug 、合并修复后的代码等等，这里面有 n 个步骤需要用到模型，然而目前 benchmark 还是处在刷榜的可能，对于真实结果存疑。

相反，最近 GitHub Copilot Workspace 也发布了预览版本，他通过 Issue 辅助生成自我提问的 Brainstorm，到生成对应的一堆 Proposal，再从 Proposal 到对应的一堆任务 Task ，最后再生成代码修复方案。过程中的每一步都由人来做确认，从而降低了难度提升准度，这无疑不是一种更稳妥的做法，也是人机交互的创新点。

对于工程智能体场景，我们深度分析各种 SWE Agent 所需要涉及的各个领域，如测试用例生成 Agent 、评审 Agent 、代码生成 Agent 、修复 Agent 等等。结合企业专属知识库，扩展 Agent 在行业领域的认知，通过平台工程，接入 Agent API ，结合既有业务流程的某些环节，如提交代码后 Hook  安全扫描的 Agent ，结合质量红线，验收代码中存在的依赖漏洞等等。

2024 年信通院发布了软件工程各个阶段中 AI 技术应用比例，我们可以看到编码和测试场景是最有诉求和痛点。从 2023 年至今，软件工程的各个阶段均有非常多的产品孵化落地。

二、智能体

到底什么是智能体？

智能体被企业提及，智能体目前是解决 AI 场景下完成软件工程的必要载体。

智能体，也称之 Agent ，我认为是一种架构层面的载体，它应该具备至少三要素：

- Perception 感知，各种输入的非结构化数据，如图片、不精准描述的提问、上下文工程代码等等，这些都属于输入的感知。

- Brain 记忆体，针对历史对话，还有企业知识库，以及对于这些内容的总结、回放、 Planning 、反思等过程。这里可以值得提一下，这个词也是我最近想到的，就像人的大脑，很大一部分是存储，并对于感知下的知识检索，决策，再检索，再决策的一个循环过程。

- Action（行动），集成企业内部系统。

从单智能体到多智能体的演进

取决于场景的复杂程度，我们又逐步引入从单智能体到多智能体的解决方案。如下图所示。

- 单智能体，执行单一任务，并逐步深挖拆解，反思，试错，最后得出一个更好的结果。

- 多智能体，类似去中心化的思路，通过多个智能体的协作，强调自主性，配合或者对抗，根据最终结果选举出最后的对抗结果。这类多智能体往往去解决复杂的工程问题，但这类复杂问题多依赖于模型，并需要在上层对抗中有策略去丢弃破解循环对抗可能性，从而停止协作并给出结论，防止无限陷入思考对抗。

我认为，智能体更类比人，眼睛是感知体，大脑是记忆体，手脚是行动体。接下来我根据这大部分，分享一下我对这块的深度理解，而多智能体就像是「斯坦福小镇」游戏，获得一个可长期运行的「仿社会体」的形态。

三、感知体

上下文感知

与场景结合，当模型能力上可以接受更多上下文的时候，可否更好的结构化提示词，从而减少理解错误的修正成本，是在设计感知体与上下文信息结构的重要环节。

比如，在补全场景下， FIM +知识库，可否设计出大模型可以理解的额外上下文，从而完成补全填空的时候，更准确更贴近业务的生成行和块。

四、记忆体

面向代码的知识库建设

腾讯云 AI 代码助手在推进更关心代码层面上可否采用 RAG 的检索增强技术。腾讯云 AI 代码助手通过如下的流程，对于代码型文档和代码做了特别的区分，并增强了在索引过程中额外的上下文信息，并提供了召回的相关配资，从而在既有的检索到召回的流程下得到更好的效果。

构建自主混合多源知识库 Autonomy Hybrid Multiple Knowledge Base 

现在很多做知识库的产品，都会限制文档格式和内容，但企业内部都很难按此优化文档，从而对于知识库的建设带来了门槛。

另外一个是多种用途的知识库可以混合使用，比如企业核心代码库、企业研发规范等知识库建设后，都有可能被叠加使用，甚至一个知识库可以像网盘那样随心丢入文件，在召回的时候更智能的归类和特征提取。

第三个，通过简单对话自主发现我该选取哪个知识库，生成对话的效果，设置过滤条件和阈值，改写并反思下一轮提问增强的改写建议

上面三点正是构建自主混合多源知识库的方案的探索的核心方向（AHM-KB）。

代码场景下知识图谱

我参与建设 PowerDesigner（一款数据库建模工具）内核，在那个过程中，我们就提出了类似代码下的知识图谱，因为建模本质是对需求的结构化和可视化。在大模型时代，这些建模信息会是知识图谱构建的核心数据之一。如下图所示，譬如我去问 「实现一个跨地域的世界时钟的程序」，那么它可以通过什么地域的知识点，分析到需要对时间和当前 locale 转换，从而关联并发现 TimeUtils 类下的某个函数，并找到其关联的一些系统时间函数。

五、行动体

单智能体与多智能体的不同的扩展

1.    提示词调优扩展：在 IDE 里的编码阶段，比如代码补全、解释和生成注释等场景，流程比较固化，企业的定制需求绝大部分是在是否可以修正提示词，或者增加一个自定义指令与其背后的提示词而已。

2.    结合企业业务服务，用在对话的扩展上。这里一般有两种方法，第一个是无代码可视化的配置，如腾讯元宝、 GPT Store 等。通过 Schema 的可视化，定义对话的人机交互，如在扩展对话按钮、交互按钮行为、下轮推荐等等，从而快速可以实现一个免发版即部署的在线扩展智能体管理方案。另一个是高代码的扩展，就如 GitHub Copilot Extension 一样，本质上提供了插件方式的扩展和接入，让对接业务系统用代码方式来写并定义好申明，通过插件发布机制上线。

3.    智能感知业务。用于多智能体场景下，前序的行动决策（如 Function call 等技术）作为后续智能体的感知，而行动的决策又给予下一个智能体的感知。

六、实践：AI 助手的标品建设和扩展架构

腾讯云 AI 代码助手从一开始就定位是一款标品产品，具有高度的可扩展性，在云上、私有化、 SaaS 层面都可以标准交付和联合创新定制。通过绿色的开放生态，接入不同模型、搭建企业内知识库、企业自主扩展智能体方案、企业管理和度量方案，从而让产品也成为企业研发效率提升的管理工具。

七、总结与展望

AI 能力在企业落地不是一个独立的事情，它需要融入到企业现有的管理和工程场景中，为现有的系统注入新的能力。这个过程不单单是部署一套大模型应用，而是需要标准化产品逐步演进。同时产品层面也要能具备提供标准运营方法和度量的方法，给管理者投入产出比建议，积极与企业各个环节结合，才能良性带动整个企业 AI 化建设进程。

再来最后聊一下 AI 对人机交互的变革的影响。Claude、Open AI Canvas、Cursor、Vercel V0、Bolt.new 等产品纷纷获得大众的视野热度不减，特别是 Cursor Composor 和最近 GitHub Copilot Edit 等新创新能力，都在往下一代人机交互的编辑器探索和发力，给面向自然语言写代码，在化繁为简的编码方向卷出了一条新的思考方向。

人工智能的浪潮不断向前，越来越多的 AI 产品帮助我们提高日常生活与工作的效率，例如腾讯云 AI 代码助手这款集成了深度学习和自然语言处理技术的智能编程辅助工具。它能够理解代码上下文，提供智能代码补全、单元测试和技术对话等功能，显著提升开发效率，满足开发者日益增长的需求，推动软件开发领域的创新和进步，扫描二维码可以了解更多详情，也欢迎点击链接免费体验腾讯云 AI 代码助手。

链接：https://copilot.tencent.com/