PART 01
Agent应用规模落地元年，AI已成为工程执行主体
2026 年是Agent应用规模化落地的元年。过去两三年，AI从"生成式（会创造）"跨越到"自主式Agentic（自主执行）"，Token调用量随之增长，中国日均调用量从 2024 年初的约 1000 亿涨到 2025 年底的约 100 万亿、2026 年 3 月的约 140 万亿，较 2024 年初增长约 1400 倍。
编码Agent也跨过"生产级"门槛，不再只是编码辅助，而是正在成为工程执行主体：据调查，84% 的开发者正在使用或计划使用AI编码工具，AI可自主完成的任务时长拉长到 2~8 小时，MCP、A2A等协议落地，让Agent互联有了标准。
从模型、工具、工程实践三个层面，都能看到"AI成为工程执行主体"正在发生：
模型层面
头部厂商不约而同把编码与软件工程能力当作核心卖点，SWE-Bench分数已冲到 80% 上下（Claude Fable5 达 80.3%）。但分数高不等于工程能力强。有研究在被标记为"已解决"的补丁上重跑完整开发者测试集，发现看似合理的修复中 29.6% 实际改变了程序行为、其中 28.6% 被明确判定为错误（多因修改不完全或过于宽泛、屏蔽了关键检查逻辑）；另一项研究手工复核 251 个通过SWE-Bench的补丁后发现，31% 仅仅因为测试太弱而蒙混过关，过滤后真实解决率从 12.47% 跌到 3.97%。要全面评估一个代码生成Agent，必须考察它在行为等价性、架构一致性、风格统一性上的表现，而不只是盯着一个分数。
工具层面
AI编程工具正快速成为Agentic AI的核心应用，产品形态沿"人在回路中的位置"持续后撤：AI IDE阶段（Copilot式深度集成，开发者仍在实现回路里）→ 自主编程Agent阶段（开发者退到设计架构、拆解任务、监督实现）→ 意图编程阶段（开发者不再关注实现细节）。各大厂转向自主编程Agent，Claude Code、Codex、Copilot、Cursor成为开发者首选，能独立承担复杂工程任务的"数字队友"正在成为主流。
工程实践层面
"零人工编写代码的生产级软件"已经逐步变成事实。Anthropic用 16 个Claude实例并行协作，从零用Rust写出一个约 10 万行的C编译器，它能编译Linux 6.9 内核以及QEMU、Redis等大型开源项目，开发速度约为手工的 10 倍、人类手写代码 0 行；OpenAI则用Codex、以约 3 人团队花 5 个月上线了一个百万行代码、零人工手写的内部产品，数百名员工日常在用。支撑这类实践的是同一套工程方法论：
这些实践共同说明：零人工代码在生产级开发中已经可行，但要靠系统化的软件工程保障：明确意图、设计约束、构建 AI 执行环境、持续反馈闭环。
三个层面指向同一个事实：AI 已经跨过了"能不能写代码"这道门槛。真正的问题随之而来，当AI从"编码助手"变成"工程执行主体"，它能不能像一个工程团队那样，规模化、可靠、可演进地交付软件？模型层的那些反例已经给出预警：背后的软件工程：理解全局、对齐意图、保证可靠、沉淀经验，才是真正的难关。瓶颈不在模型能力，而在方法体系。
PART 02
软件工程的三重挑战：旧瓶颈已破，新问题浮现
AI没有让软件工程变得更为简单，传统软件工程中的规模、效率、质量问题，在AI时代又遇到了新的挑战：AI帮我们拔高了能力上限的同时，又在每个维度上带来新的问题。
规模挑战：从代码过载到多 Agent 协作复杂度
传统的规模瓶颈，是代码量超过了人的阅读带宽。这一条AI基本解决了，它能并行处理大量文件、自动导航大型代码库、跨模块理解上下文。
但"看得到"不等于"理解全局"。
单个Agent层面，问题是有"视野"无"地图"：上下文窗口再大，也不等于掌握了架构结构。GitClear 一份基于 2.11 亿行代码变更的研究发现，AI编码工具普及后，代码复用率从 2020 年的 24.1% 跌到 2024 年的 9.5%，而复制粘贴的重复代码块增长 4 倍、首次超过重构代码，Agent宁愿另写一份相似代码，也不去复用已有抽象。它能"读到"全局，却没在"理解"全局。
多个Agent层面，问题升级为协作本身的复杂度：谁调用谁、状态怎么传递、失败如何回溯，都成了需要显式设计的工程产物。5 个Agent就有上百种调用顺序；一个Agent在中间环节悄悄跑偏，误差会沿链路传播到最终产出才暴露；而且Agent数量过了某个阈值，协调成本会反超并行收益，更多Agent不再等于更快交付。
规模瓶颈换了形态：从"代码太多、人读不过来"，变成"Agent 太多、交互太复杂"。
效率挑战：从流程冗长到方向偏差的隐性成本
传统的效率瓶颈，是流程长、中间环节多。AI把它压缩了——意图可以直接驱动执行，一个任务闭环在Agent内部完成，人只在关键节点介入。GitHub的数据显示，AI已在编写开发者约 46% 的代码，使用Copilot的开发者编码速度提升过半。
但速度优势会被隐性成本悄悄抵消。METR 2025年一项针对资深开源开发者的随机对照实验得出了一个反直觉的结果：开发者自认为用AI后提效 24%，实测却下降了约 20%。差距来自三类被低估的成本：
效率瓶颈换了形态：从"流程太长、中间环节多"，变成"方向跑偏的隐性成本"。
质量挑战：从功能缺陷到输出不确定性
传统的质量瓶颈，是缺陷多、测试覆盖不够。AI 也在缓解它：能生成测试、自动审查、发现边界条件。
但AI产出的质量问题换了形态。DORA 2025年的报告指出，AI在软件工程中能否成功，更取决于组织系统的强度，而非工具本身的复杂度 —— 也就是说，没有配套机制，再强的工具产出也不可靠。新的质量问题有三个特征：
质量瓶颈换了形态：从"缺陷多、测试不够"，变成"产出的不确定性"。
三重挑战的相互加剧
它们不是孤立的：多Agent协调失败 → 产出质量下降、返工增多（规模→效率）；返工挤占协调精力（效率→质量）；质量问题难回溯，多Agent冲突更难定位（质量→规模）。在没有显式防护机制时，三者会循环放大。
|
|
|
|
|
|---|---|---|---|
| 规模 |
|
|
|
| 效率 |
|
|
|
| 质量 |
|
|
|
根因：方法体系与执行主体的错位
三重挑战指向同一个根因：软件工程的整套方法体系：需求表达、设计沟通、代码审查、质量保证、经验传承，都是围绕人类的认知特性设计的。当执行主体从人换成Agent，这套方法就出现了系统性错位。人和Agent在五个维度上存在结构性差异：
把为人设计的工程实践直接"喂"给Agent，内容没错，但它是按人的认知习惯来编码和消费的，与Agent的处理方式并不匹配。由此，我们需要构建AI原生的软件工程方法体系，既要使用AI的能力去缓解旧的规模、效率、质量瓶颈，也要用新的工程方法去应对AI自己带来的新问题。
PART 03
范式重建：AI 原生软件工程与 AET
面对这些挑战，给Agent不断补充skills、specs、rules这类人类知识，在小规模下确实管用，但终究是在面向人设计的软件工程实践外围打补丁；真正的出路，是换一层地基。
软件开发范式正在沿"人在回路中的位置"经历代际跃迁。开篇已从产品形态看到这条后撤线；换成能力成熟度的视角，它呈现为三代范式：
短期最优解正落在 Human-on-the-loop：人类在环上把关，让编码 Agent 作为 10x 开发者，撑起一支小团队。而当执行主体进一步走向范式三那样自治协作的Agent团队，为人设计的那套工程方法体系，就必须随之重建。
这场跃迁由三股力量共同驱动，也划定了新方法体系要重建的三个面：
我们把这套重建后的方法体系称为 AI原生软件工程（AI-Native Software Engineering）：围绕AI Agent的认知特性，重新设计的软件工程方法体系与实践。
落到工程上，它由五大原生能力构成：
|
|
|
|
|---|---|---|
|
|
自动构建架构上下文 |
|
|
|
全量需求分析与设计 |
|
|
|
可靠执行与故障恢复 |
|
|
|
决策轨迹评测与自动归因 |
|
|
|
失败模式自动捕获与经验沉淀 |
|
① 自动构建架构上下文：架构约束大多隐式存在，Agent容易陷入局部盲区、越界改动破坏依赖。解法不是更强的检索（grep/RAG只给碎片），而是把代码资产做成一张可导航的语义地图——模块职责、依赖拓扑、边界契约，再按任务生成"修改围栏"，实时告诉Agent改这里会坏哪里、哪条边界不能碰。
② 全量需求分析与设计：AI 直接出的设计常对架构、DFx考虑不全，返工率偏高（约 60%）。解法不是把spec写得更细（那仍是"人写、AI读"的静态契约），而是让"需求→设计"成为Agent扎根架构、主动收敛的过程：补上架构上下文、把设计方法论做成可复用Skill，在跑偏前校准。
③ 可靠执行与故障恢复：概率化输出让同一任务多跑几遍结果就不一致，长链路执行还脆弱，局部错误会沿"生成 — 编译 — 测试"级联放大。解法不是在生成后多设几道关卡，而是把"可靠"做进执行期本身——生成时按语法、语义分层约束，出错时容错、断点续行、语义回滚，让长链稳定、不必从头返工。
④ 决策轨迹评测与自动归因：传统QA评的是"产物"，默认背后是个可追问的人类作者；但Agent的推理是黑盒、还会系统性重复犯错，只看代码就会"知行不一"、同类错误反复犯。解法是把"决策过程"本身变成评测对象，轨迹 + 代码双轨、四维查约束是否对齐，再单/多链路归因挖出根因和盲区。
⑤ 失败模式自动捕获与经验沉淀：经验靠文档和口头相传、Agent没法直接执行，同样的错反复重演，约束过时也无人清理。通用记忆只让Agent"记住发生了什么"，这里要的是把工程教训变成下次生成时就拦得住的约束：失败根因自动提成可执行约束，带版本与置信度、过时降权，按架构相似度跨项目继承。
五大能力之间的关系
架构上下文为需求与设计提供语义地图，设计驱动可靠执行，执行的决策轨迹被评测系统审视，评测发现的失败被自动沉淀为结构化约束，再反哺回架构理解与执行，让 Agent 在下一轮"踩坑前"就避开已知的坑。
再往前看，当执行主体彻底变成Agent群体，要重建的会从这五项能力扩展成五根支柱：
它们串成一套AI原生软件工程的参考架构：资产与结构提供目标和认知地图，汇入群体执行与编排，经实时验证门禁把关后交付产物，产出的经验再回流成闭环、反哺前端。其中治理（多 Agent的编排与MCP/IAM身份权限）是单Agent时代尚不突出、群体时代才凸显的新命题。
而这套方法与能力，需要一个工程载体才能真正落地。我们把它做成一个开源项目 —— AET（Agentic Engineering Team），围绕以上五大能力构建的AI原生软件工程平台，代码已开源：https://atomgit.com/openeuler/agentic-engineering-team。后续每篇拆解一项能力时，也会结合[1] AET 的设计谈具体落地。
PART 04
小结
本篇只勾勒了轮廓：三重挑战是什么、AET主张怎么破。从第 2 篇起，我们将逐一拆解五大能力——它们各自要解决什么问题、关键技术是什么、工程上如何落地：
欢迎大家共同交流与讨论。
AET项目已开源到openEuler社区，欢迎试用与共建：https://atomgit.com/openeuler/agentic-engineering-team。
PS：
最后，做个小小的推荐，目前正在进行的两个项目：
Agent Insight：openEuler孵化的项目，旨在让每一个Agent 都可被观测、可被评估、可自我进化。
Skill Radar：给Agent Skills技术画一张”活地图”，追踪Skills技术，让Agent能力进化有迹可循。
如果你对Agent Insight感兴趣，欢迎参与进来，一起把它变得更好~~
🔗 仓库地址：https://atomgit.com/openeuler/agent-insight
更多Agentic AI技术前沿分享，欢迎添加群助手ID：qstarsky，邀请您进群交流