[实证研究] 开发者如何构造软件工程agent?

论文基本信息：Lyu, Y., Williams, D., Shi, J., Sun, Z., Peng, C., Yang, Z., ... & Lo, D. (2026). How Do Practitioners Build SE Agents? Insights from a Mixed-Methods Study. arXiv preprint arXiv:2607.10856.

论文链接：https://arxiv.org/pdf/2607.10856

作者单位：新加坡管理大学、UCL、腾讯、阿尔伯塔大学

软件工程智能体作为一种新形态软件，开发者究竟如何设计、评估、部署和维护这些智能体？这篇来自SMU David Lo团队等人的工作针对这一问题进行了首个大规模实证研究。

1. 研究背景

软件工程智能体是结合大语言模型、工具、记忆、规划机制与环境反馈，能够自主完成软件工程任务的系统。Agent的行为并不完全由开发者编写的代码决定，而是由基础模型、提示词、上下文、工具接口、执行权限和运行环境共同涌现。当agent出现错误时，很难像调试传统程序一样定位到某一条错误语句：失败可能来自模型推理、上下文选择、工具调用、harness逻辑，或者多个组件的交互。

已有研究多通过分析 GitHub 仓库、Issue 和提交记录理解智能体开发，或者关注智能体部署后的可观测性与运维问题。而针对机器学习软件和大模型应用的访谈研究，则大多早于当前的智能体浪潮。因此，作者提出两个研究问题：

RQ1：软件工程智能体在实践中如何被开发，传统软件工程过程正在发生哪些变化？
RQ2：智能体开发面临哪些关键挑战，实践者采用或提出了哪些应对方法？

2. 研究设计

如图1所示，论文采用探索式序列化混合研究设计：首先通过定性访谈识别出流程、挑战和实践，再通过定量问卷验证这些发现是否具有更广泛的代表性。

研究团队在2026年2月至5月间访谈了来自12家组织的20名实践者，参与者包括应用科学家、基础设施工程师和管理者，覆盖大型科技公司、中型企业、创业公司和非IT组织。他们构建的系统既包括通用代码智能体，也包括需求工程、性能优化、漏洞修复和智能运维等任务专用智能体。访谈围绕六类主题展开：参与者背景、组织环境、开发流程、开发挑战、所需技能以及开放性问题。

在数据分析阶段，研究团队先将访谈文本划分为具有独立意义的内容单元，再采用混合卡片分类法，将预先设定的访谈主题与数据中自然涌现的主题结合起来。最终识别出52项发现，包括12项流程发现、23项挑战、9项技能发现和8项其他发现。随后，作者发放在线问卷，共获得89份回答，问卷要求参与者评价各项流程变化和挑战的认同程度，并评价相应实践的有效性。

3. RQ1: 软件工程智能体的开发流程

研究识别出一个具有高度迭代性的七阶段流程，如图2所示。它并不是传统瀑布式流水线，而更接近由评估和反馈驱动的敏捷循环。

需求定义。团队需要明确智能体的目标行为、任务边界、输入输出形式和约束条件。与传统需求文档不同，这些需求不仅面向人类开发者，也越来越需要被智能体直接读取和执行，因此必须更加明确、结构化和机器可理解。
评估设计。团队需要提前确定如何判断智能体是否完成任务，包括离线基准、成功条件、置信度阈值和结果导向指标。论文特别区分了测试与评估：测试主要验证确定性组件是否正确，而评估用于衡量具有随机性的智能体行为及其任务能力。
数据准备。数据既服务于评估，也可能用于模型训练。评估数据包括基准任务、标准答案、真实运行轨迹以及从历史提交中提取的正确补丁；训练数据则可能包括人工标注样例和智能体运行轨迹。但如果团队主要采用提示词工程和现成模型，未必需要完整的训练数据流程，因此数据并非所有团队都必经的独立阶段。
系统构建，包括模型策略和脚手架策略。多数团队遵循“成本最低者优先”的原则：首先尝试调用现有闭源API或开源模型，通过提示词工程解决问题；只有效果不足时，才逐步采用LoRA、监督微调、偏好优化或持续预训练。与模型选择相比，开发者普遍更加重视模型之外的脚手架，即负责管理上下文、记忆、工具、技能、权限和工作流编排的系统层。即使更换模型，这一层通常仍然存在，因此成为智能体产品的重要工程基础。
测试、评估与部署。每次迭代都要同时检查传统软件组件的可靠性和智能体整体的任务表现。只有满足预先定义的发布门槛后，系统才会进入部署。
人类反馈循环。团队通过内部试用、人工审查、验证智能体、封闭测试和A/B测试收集运行反馈，并用这些信息更新评估用例、提示词、脚手架乃至训练数据。
自适应维护。基础模型更新速度很快，新模型可能增强某些能力，也可能引入新的失败模式。团队因此需要持续重新评估模型、需求、测试集和脚手架设计，而不能将智能体视为一次性交付的静态软件。

4. RQ2: 挑战与应对

作者总结出6项挑战：

评估缺乏可信信号：现有测试可能不完整或已经过时，却因为容易执行而被直接当作标准答案；相同模型和脚手架多次运行也可能产生不同结果；公开基准一旦成为优化目标，就可能被模型“刷分”；而构建真实仓库环境和运行大规模回归评估的成本又非常高。解决方案：从生产结果和业务影响中获取验证信号；在分配任务前先设计验证方式；分层评估最小可判断单元并持续更新私有任务集；通过代表性子集、分阶段执行和小模型控制评估成本。
“什么都没改，一切都变了”：传统机器学习中的CACE原则强调“改变任何组件都会影响一切”。智能体系统还存在相反现象：即使团队没有修改代码、提示词和工具，模型供应商的版本更新也可能彻底改变系统行为。为弥补旧模型缺陷而设计的规则和工作流，可能在模型能力提升后变成限制性能的“枷锁”。解决方案：团队需要区分长期有效的基础机制与针对当前模型弱点的临时补丁。上下文管理、压缩和快速验证通常更持久，而过度细化的表层流程可能很快失效。
安全性可能让位于性能：部分团队明知智能体存在风险，却担心安全限制降低任务完成率或执行效率。论文记录了智能体绕过工具限制，以及大量子智能体因上下文溢出而遗忘约束、删除用户目录等严重事件。解决方案：高风险约束不能只写在提示词中，而应在工具调用层实施，包括最小权限、沙箱隔离、调用拦截和明确的人类授权。
智能体只能检索“写下来的知识”：许多关键项目知识并不存在于代码和文档中，而是以设计动机、历史约束和团队惯例的形式留在开发者头脑中。另一方面，将全部仓库内容塞入上下文又可能造成信息过载。解决方案：将反复出现的经验编码为仓库级技能和规则；按照任务进展逐步提供最小充分上下文；当关键信息缺失时，让智能体暂停并请求人类，而不是自行猜测。
代码增长速度超过人类理解速度：论文提出“理解债务”概念：智能体生成代码的速度超过开发者理解和审查代码的速度，导致代码在团队尚未形成充分认知时就进入系统。生成代码不仅数量庞大，还可能通过不断叠加条件和工具函数扩展旧结构，留下重复、废弃或范围过大的实现。解决方案：部分团队选择继续让智能体诊断和修复这些代码，但这并没有偿还理解债务，只是将维护进一步交给AI。另一种更具前瞻性的设想是“可再生软件”：重点保存需求、测试、约束和生成基础设施，而不是永久维护某个具体实现；当依赖和模型变化后，系统可以重新生成并验证代码。
传统生产力指标失效：代码行数、提交次数等指标本来就难以准确衡量软件价值，智能体则进一步放大了这一问题。代码产量可能快速增长，却无法直接转换为业务价值；个体开发者看似效率提高，也可能给团队带来更多审查和维护负担。解决方案：论文建议将代码量视为诊断信号，而不是绩效目标。更有意义的指标可能包括交付提前程度、缺陷减少、人员流失降低和开发者可支配时间增加，但目前产业界仍缺少能够可靠连接智能体使用与组织价值的生产力度量。

5. 总结

本文作为软件agent领域的早期代表性访谈研究，最终识别出一套七阶段开发流程、六类关键挑战和十二项应对实践，反映了当前工业界关于软件工程智能体的实践经验，同时指出：未来软件工程的核心能力，可能不再是高效地产生代码，而是准确表达意图、构造可信验证信号，并持续控制能够自主行动的软件系统。