openEuler Agent Infra企业级编码方案：基于AI原生软件工程范式，实现企业级软件交付可靠、可控、可演进

2025年，METR 做了一项随机对照实验。找来一批资深开源开发者，让他们在有无AI辅助的条件下完成同样的任务。

结果让所有人愣住：开发者自认为用AI后提效了 24%，实测却下降了约 20%。

问题出在哪？不是AI不够快。它太快了。快到你还没意识到问题，已经跟着错误方向跑出去很远。幻觉编造出不存在的API，代码语法无懈可击但语义完全跑偏。等你察觉，返工成本已经高企。这不仅仅是工具问题，而是工程范式在发生变化。

先看几组数据：

可见，编码Agent已跨越“生产级”门槛，从辅助工具演变为工程执行主体。

图1：编码Agent正从辅助工具演变为工程执行主体

AI编程工具正加速演进为Agentic AI的核心应用场景，Claude Code、Codex、Copilot、Cursor等工具正成为开发者的首选。AI编码产品的形态沿着"人在回路中的位置"这条轴一路后撤，走出了清晰的三个阶段：从AI IDE阶段（Copilot式深度集成，开发者仍处于实现回路之中），演进至自主编程Agent阶段（开发者负责设计架构、任务拆解与监督实现），最终迈向意图编程阶段（开发者只需关注任务目标，无需关注实现细节）。

AI已迈过"能否写代码"的门槛。 真正的问题变成了：当它从助手变成主体，能不能像一个工程团队那样，做到可靠、可控、可演进地交付软件？

模型在评测集上的高分并不等同于完整的工程能力。有研究者把SWE-Bench上标记为"已解决"的补丁重新跑了完整测试集。29.6%的修复实际改变了程序行为，其中28.6%被明确判定为错误。看起来对的代码，离真的对，还有距离。

AI让软件工程变简单了吗？它的确帮我们拔高了能力上线，但在传统挑战之上，又叠了一层新的复杂度。

图2：软件工程的三重挑战

➣规模挑战：从“代码太多、人读不过来”，变成“Agent 太多、协调不过来”

传统的规模瓶颈——代码量超出人的阅读带宽——已被AI基本解决：它能并行处理大量文件、自动导航大型代码库、跨模块理解上下文。但“看得到”不等于“理解全局”。

单Agent层面，问题是有视野没地图。上下文窗口大到能装下整个代码库，但AI缺的是架构的全局理解。GitClear对2.11亿行代码的研究显示，AI编码工具普及后，代码复用率从2020年的24.1%降至2024年的9.5%，而复制粘贴的重复代码块增长4倍，首次超过重构代码。Agent宁愿另写相似代码，也不复用已有抽象——它能“读到”全局，却未“理解”全局。

多Agent层面更棘手。谁调用谁、状态怎么传、失败如何回溯，这些在人类团队里靠默契和代码审查解决的事，在Agent之间必须变成显式设计的工程机制。一个Agent中间跑偏，误差沿链路级联传播，到最终产出才暴露。Agent数量越过某个阈值后，协调成本反超并行收益。更多Agent，不意味着更快交付。

➣效率挑战：速度被方向跑偏的隐性成本悄悄吃掉

传统的效率瓶颈，是流程长、中间环节多。AI把它压缩了——意图可以直接驱动执行，一个任务闭环在 Agent 内部完成，人只在关键节点介入。但速度优势会被隐性成本悄悄抵消。METR 2025 年一项针对资深开源开发者的随机对照实验得出了一个反直觉的结果：开发者自认为用AI后提效 24%，实测却下降了约 20%，问题来自两方面：模型幻觉——AI 会编造出不存在的依赖、API，代码语法正确但语义不适用，发现时已浪费大量时间；方向跑偏——AI 缺乏“我是不是跑偏了”的元认知，能沿错误方向跑很长，回退的代价常常大于重来。

➣质量挑战：从“缺陷多、测试不足”，变成“产出的不确定性”

传统质量瓶颈在于缺陷多、测试覆盖不足，AI虽能生成测试用例、自动审查问题、发现边界条件，但其产出也带来了新的质量问题。新的质量问题表现为三个特征：不可信——代码“看起来对”与“真的对”难以区分，仍需人工判断；不可解释——代码为什么选方案A而不是B，决策推理过程是黑箱；不可复现——生成结果具有概率性，相同输入可能产生不同输出，动摇了传统测试方法与工具的基本假设。

三重挑战指向同一个根因 —— 软件工程的整套方法体系：需求表达、设计沟通、代码审查、质量保证、经验传承，都是围绕人类的认知特性设计的，但人和Agent在五个维度上存在结构性差异：上下文理解方式不同，推理路径不同，失败模式不同，经验积累机制不同，协作方式不同，当执行主体从人换成Agent，这套方法就出现了系统性错位。

图3：人和 Agent 的五维度差异

把为人设计的工程实践直接“喂”给Agent，但它与Agent的处理方式并不匹配。由此，我们需要构建AI原生的软件工程方法体系，用新的工程方法去应对AI带来的新问题。

为了应对上述问题，openEuler 构建了一套企业级编码解决方案，通过开源项目AET（Agentic Engineering Team） 开放。

AET 围绕AI Agent的认知特性，重新设计的软件工程方法体系与实践，它由五大原生能力构成：

图4：AI 原生软件工程五大原生能力

五大能力之间协同配合，形成闭环：架构上下文给需求和设计提供语义地图，设计驱动可靠执行，执行轨迹被评测系统审视，失败被沉淀为约束，约束反哺回架构理解。让Agent在下次"踩坑之前"，就已经绕开了已知的坑。

AET当前已包含8个专家智能体组成的多智能体团队，分管设计、测试、实现、Bug修复、文档生成、版本发布等领域。另有 40+ 个专业化Skill，覆盖需求分析、功能设计、代码开发与验证、PR提交、漏洞分析、技术文档编写等全生命周期环节。

核心功能特性包括：

回头再看那个反直觉的数字。AI让我们自认为提效了 24%，实测下降了 20%。差距不在工具，在工程方法体系。

AI原生软件工程要解决的核心问题，不是让AI写得更快。是让AI写得更对、更稳、更好迭代。它承认一个基本事实：执行主体变了，方法论必须跟着变。

AET是这个方向上的第一次系统性尝试，它搭起了一套可演进的框架：架构上下文可以越来越精准，失败约束可以越积越厚，决策评测可以越来越聪明。可靠、可控、可演进，这三个目标不靠一次性优化达成，靠一个能自我进化的工程体系持续逼近。

欢迎加入 sig-intelligence 交流社区，分享使用心得、反馈问题或贡献代码，与生态伙伴共同探索 openEuler 与 AI 的更多创新可能！

🔹代码仓： 

https://atomgit.com/openeuler/agentic-engineering-team

🔹开发小组：

 sig-intelligence

🔹交流社区： 

https://www.openeuler.openatom.cn/zh/sig/sig-intelligence

供稿 | 王磊、张桐、杜开田

编辑 | 丘云

校审 | 朱艳婷、郑振宇、刘彦飞