核心发现
方法论
作者筛选并评估115篇将LLM智能体用于软件工程的论文，抽象出统一框架：感知接收文本、代码、图像或音频；记忆分为语义、情景和程序记忆；行动包括推理、检索、学习及环境交互，并进一步讨论多智能体协作。
关键结果
- 论文的核心结果不是新模型的准确率，而是系统分类：115篇研究被映射到感知、记忆和行动三大模块。代码相关工作主要使用token输入、API/文档检索、CoT推理和数字环境交互。
- 代表性机制包括DocPrompting、RepoCoder、De-Hallucinator、CodeAgent、SCoT、CodeCoT和TOOLGEN，覆盖代码生成、补全、调试、漏洞检测、仓库级开发等任务。
- 作者发现明显研究空白：软件工程智能体几乎未系统利用视觉、听觉及混合结构输入；尚无权威代码知识库；多智能体协作存在显著计算与通信开销。
研究意义
该研究为分散的“LLM+软件工程”工作提供共同语言。它说明智能体并不只是会调用工具的聊天模型，而是能感知环境、调用记忆、执行行动并根据反馈修正的闭环系统。对学术界而言，框架有助于比较不同方法；对工业界而言，它连接了代码模型、检索系统、解释器、测试平台和开发者协作流程。
技术贡献
技术贡献是提出面向软件工程的三模块智能体分类法，并细化代码特有的输入与行动形式。感知区分token、AST/控制流图和混合输入；记忆区分外部知识、历史案例及模型参数或代理代码中的程序知识；行动区分内部推理、检索、学习和外部交互。该框架还把单智能体与多智能体协作纳入同一视角。
新颖性
论文声称首次系统调查LLM智能体与软件工程的结合。其根本新意不在提出一个新算法，而在于把过去以不同术语出现的提示、检索、工具调用、自校验和代理协作统一解释为感知—记忆—行动闭环，并据此提出可操作的研究议程。
局限性
- 论文是综述与愿景研究，不提供统一数据集、统一指标或新的端到端实验，因此不能据此断言某一智能体架构在准确率或成本上优于其他方法。
- 纳入工作高度依赖代码生成和文本输入；视觉、音频、结构化代码表示及多智能体效率证据不足，分类边界也可能随“智能体”定义变化而变化。
未来方向
未来应建立权威代码知识库，发展视觉、音频、AST/图结构和多模态感知，研究角色自适应的多能力智能体，并以测试通过率、修复正确率、成本、延迟和安全性进行统一评估。同时应降低幻觉、通信开销，并将程序分析、测试生成和形式化验证等SE技术反哺智能体研究。
AI 总览摘要
大型语言模型已进入代码生成、摘要、翻译、漏洞修复和调试，但单次提示往往无法处理真实软件工程中的长上下文、依赖关系、运行反馈与持续修改。许多研究实际上已经使用了智能体思想，却缺少统一定义和发展脉络。Wang等人通过筛选获得115篇相关论文，试图回答：软件工程中的LLM智能体究竟由什么组成，又如何完成复杂任务？
论文提出三模块框架。感知模块把文本、代码、UML、执行结果甚至音频转换为模型可处理的信息；记忆模块包含语义记忆、情景记忆和程序记忆，分别对应文档/API、历史交互与示例、模型参数或代理代码中的知识；行动模块包含推理、检索、学习等内部行动，以及与人、其他代理和数字环境的外部交互。DocPrompting和RepoCoder展示了检索如何补充上下文，CodeCoT和SCoT展示了代码专用推理，CodeAgent则把仓库导航和测试工具纳入闭环。
研究最重要的结论是“地图”而非单一性能数字：现有工作集中在token文本、外部文档/API和CoT推理，视觉、听觉、结构化或混合输入仍被忽视；领域内也缺少权威代码知识库。未来的关键不只是让模型更会生成代码，而是让它能观察、记忆、行动、验证并从反馈中学习。作者还强调，多智能体协作虽有分工潜力，却带来计算和通信成本；反过来，程序分析、测试和代码工具也能推动通用智能体发展。
深度分析
研究背景
LLM已广泛用于代码摘要、生成、翻译、漏洞检测与修复。代表性工作包括DocPrompting、RepoCoder、AceCoder、De-Hallucinator和CodeAgent；推理方面出现CoT、SCoT、CodeCoT与Brainstorm。问题在于这些研究常以不同术语描述代理能力，缺乏统一框架。
核心问题
真实软件任务需要理解仓库结构、调用API、运行代码、处理错误并持续修改。单轮生成难以获得可靠反馈，模型还会产生幻觉、遗忘历史、受限于上下文窗口。多智能体虽能分工，却增加推理次数、同步和通信成本。
核心创新
- ��首次系统调查该交叉领域并筛选115篇论文。
- ��提出感知—记忆—行动框架，覆盖单智能体与多智能体。
- ��将记忆细分为语义、情景、程序三类，将行动细分为推理、检索、学习和外部交互。
- ��明确指出视觉、听觉、混合代码表示及权威知识库等空白。
方法详解
- ��感知：token直接编码代码；AST、控制流图等结构表示代码语法；视觉输入可包含UI草图或UML；音频支持语音交互。
- ��记忆：DocPrompting检索文档，KPC利用API异常知识，AceCoder检索相似程序，RepoCoder迭代检索—生成。
- ��推理：CodeChain进行自修订，CodeCoT结合测试与自检查，SCoT使用结构化提示。
- ��行动：CodeAgent调用符号导航和测试工具；TOOLGEN学习何时触发补全工具；学习行动更新模型知识、外部记忆或代理代码。
- ��协作：多个角色代理分担任务并共享状态。
实验设计
论文主要进行文献收集、过滤和质量评估，最终保留115篇，而非设计统一基准实验。案例覆盖代码库、API文档、执行环境和数字软件环境；文中引用CODEAGENTBENCH作为仓库级代码生成基准，但没有报告跨论文统一的准确率、通过率或消融数字。
结果分析
分类显示，token文本输入、文档/API检索、CoT推理和代码执行交互最成熟。视觉与听觉仍缺少LLM软件工程代理研究；AST/图结构虽在传统SE中存在，却尚未被系统纳入代理感知。幻觉缓解、知识库建设和多代理效率成为最明确的共同瓶颈。
应用场景
该框架可指导代码补全、需求到代码、仓库级生成、自动调试、漏洞修复、测试生成和开发者问答。实践部署需要可靠的代码检索、沙箱执行、权限控制、测试反馈和人工确认，不能仅依赖模型文本输出。
局限与展望
综述没有统一实验协议，无法进行严格的算法排名；论文集合也可能受检索范围和“智能体”定义影响。未来需要跨任务基准、真实仓库和成本指标，比较单代理、多代理、检索增强及工具使用。还应研究安全权限、隐私、错误恢复和可验证执行。
通俗解读 非专业人士也能看懂
把软件工程智能体想成一位会修理复杂机器的工程师。感知就是他的眼睛和耳朵：他读取需求、代码、图纸和运行结果。记忆像工具箱和工作日志：工具箱里放着API说明与通用知识，日志记录以前修过的类似故障，熟练技巧则已经练进了大脑。行动就是实际工作：先分析问题，再查资料，修改零件，开机测试；如果机器报错，就根据反馈继续调整。
论文做的事情像整理一座大型维修厂的档案。作者查看115篇研究，发现有些系统只会根据文字写代码，有些会查文档，有些能浏览整个代码仓库、运行测试或和人交流。DocPrompting像先查说明书，RepoCoder像翻找同一仓库的旧零件，CodeCoT像边列维修步骤边检查结果。
但这座维修厂仍有缺口：多数系统只会“看文字”，不太会看界面图或听语音；没有统一、可信的零件目录；多个工程师一起工作时还要不断开会。因此，未来的智能体应能看得更多、记得更准、行动后自我验证，并用更少的资源完成协作。
简单解释 像给14岁少年讲一样
想象你在游戏里带着一个超级队友修复一座坏掉的城市。它不是只回答“该写什么代码”，而是先看任务说明和地图，再查背包里的道具，走进城市测试机关，发现失败后重新计划。这就是论文所说的软件工程智能体。
作者研究了115篇论文，把超级队友拆成三部分：感知、记忆和行动。感知像眼睛，能看文字、代码、图纸和运行结果；记忆像游戏存档，保存说明书、以前遇到的关卡和已经学会的技巧；行动像手，可以思考、搜索、改代码、运行测试，还能和人或其他队友聊天。
例如RepoCoder会在整个代码仓库里寻找相似内容，DocPrompting会先查文档，CodeCoT会把写代码和检查代码连起来。这样做比“猜一个答案”可靠得多，因为程序真的可以运行并告诉它哪里错了。
不过它还不是无敌角色！大多数系统主要看文字，不太会理解界面图片或声音；它有时会编造不存在的API；多个代理合作时还会消耗很多计算资源。未来如果它能看懂更多信息、使用可靠知识库，并在每次行动后自动验收，就可能成为程序员的强力搭档。
术语表
LLM-based Agent（基于大语言模型的智能体）
以LLM作为认知核心，能够感知环境、推理并采取行动的系统。它通常通过工具、记忆和反馈完成多步任务。
论文研究其在代码生成、调试、检索和软件开发环境中的应用。
Perception（感知）
把外部文本、代码、图像或音频转换成模型可处理信息的模块。它决定智能体能观察哪些软件工程状态。
论文区分token、树/图、混合、视觉和听觉输入。
Semantic/Episodic/Procedural Memory（语义/情景/程序记忆）
语义记忆保存文档和API等事实；情景记忆保存历史案例、消息和示例；程序记忆保存模型参数或代理代码中的操作知识。
三类记忆构成论文框架的记忆模块。
Chain-of-Thought, CoT（思维链）
要求模型显式分解问题并逐步推理的方法。代码任务中可扩展为结构化推理、自修订和测试检查。
论文讨论SCoT、CodeCoT、Tree CoT和Brainstorm。
Retrieval-Augmented Generation（检索增强生成）
先从文档、API或代码库检索相关信息，再将其加入提示以生成答案。它能减少模型脱离项目上下文的猜测。
DocPrompting、RepoCoder和De-Hallucinator是代表例子。
开放问题 这项研究留下的未解疑问
- 1 如何统一评估智能体仍未解决：不同论文使用不同任务、数据集和指标，未来需要同时衡量正确性、测试通过率、成本、延迟和安全性。
- 2 代码的结构、视觉和音频信息如何与token有效融合尚不清楚；需要多模态数据、结构感知模型以及真实开发场景验证。
- 3 多智能体如何在减少通信和计算的同时保持协作质量，仍缺乏可复现的机制与理论分析。
应用场景
近期应用
仓库级代码助手
开发团队可结合RepoCoder式迭代检索、CodeAgent工具调用和项目API文档，为补全、代码导航与测试提供上下文。部署前应配置私有代码索引、沙箱和人工审核，预期减少无关生成与API幻觉。
自动调试与漏洞修复
利用CodeCoT的测试—自检查流程和De-Hallucinator的API grounding，代理可从缺陷报告定位代码、尝试修复并运行测试。适合低风险、可回滚仓库，关键修改仍需开发者确认。
远期愿景
多角色软件工程团队
未来可由需求分析、编码、测试、安全审查等代理分工协作，共享语义、情景和程序记忆，并通过统一数字环境验证提交。主要障碍是成本、权限、安全和跨代理状态同步。
原文摘要
In recent years, Large Language Models (LLMs) have achieved remarkable success and have been widely used in various downstream tasks, especially in the tasks of the software engineering (SE) field. We find that many studies combining LLMs with SE have employed the concept of agents either explicitly or implicitly. However, there is a lack of an in-depth survey to sort out the development context of existing works, analyze how existing works combine the LLM-based agent technologies to optimize various tasks, and clarify the framework of LLM-based agents in SE. In this paper, we conduct the first survey of the studies on combining LLM-based agents with SE and present a framework of LLM-based agents in SE which includes three key modules: perception, memory, and action. We also summarize the current challenges in combining the two fields and propose future opportunities in response to existing challenges. We maintain a GitHub repository of the related papers at: https://github.com/DeepSoftwareAnalytics/Awesome-Agent4SE.