麦肯锡2026技术趋势01_智能体式软件开发_研究解读

当 AI 开始承担开发任务：麦肯锡 2026 年"智能体式软件开发"研究解读

麦肯锡《Technology Trends Outlook 2026》技术趋势解读系列 · 第 1 篇

摘要

麦肯锡将"智能体式软件开发"（Agentic software development）列为 2026 年新增技术趋势。它意味着 AI 开始在授权范围内承担规划、编码、测试、调试和部署等开发任务，软件工程师则更多参与任务定义、系统设计、结果验证与异常处理。报告揭示了一个值得重视的现象：开发活动迅速增长，企业层面的收益却明显分化。本文从技术边界、实证证据、交付瓶颈、工程环境、人才结构与成本机制六个方面展开解读，提出一个核心判断：智能体式软件开发的收益，取决于生成能力与需求定义、企业知识、验证机制及交付流程之间的匹配程度。未来竞争将更集中于可验证的交付能力，以及企业持续组织人机协作的能力。

关键词： 智能体式软件开发；AI 编程；产品开发生命周期；软件交付；企业上下文；人机协同

一、为什么这一趋势值得单独讨论

设想这样一个开发场景：工程师在下班前提交一项任务，说明要修复什么问题、哪些模块可以修改、怎样判断任务完成。智能体随后阅读代码仓库，定位问题，提出修改，运行测试，并留下待审查的变更。第二天，工程师面对的是一组需要判断和验收的成果。

这只是说明工作方式的一个例子，却体现了麦肯锡所讨论的变化：AI 正在进入软件开发的执行过程，人与 AI 之间的协作开始围绕任务委派、过程监督和结果验收展开。

在这份 2026 年 9 月发布的报告中，麦肯锡首次将"智能体式软件开发"单列为技术趋势，并把它放在"AI 革命"类别的首位。1，正文第 10---18 页 这个位置不构成技术重要性的严格排名，但单独设立一个章节，说明报告关注的对象已经扩展到软件生产方式本身。

过去，我们通常用"生成了多少代码""补全是否准确"来讨论 AI 编程。现在，更值得追问的是：当 AI 能连续执行开发任务，企业如何定义工作、分配权限、组织审查，并把执行成果转化为稳定运行的产品？

围绕这个问题，智能体式软件开发具有两层意义。技术上，它扩大了 AI 可以承担的工作范围；管理上，它改变了开发活动的分工、交接和责任结构。这两层变化能否彼此配合，决定了企业最终能够获得多少收益。

二、技术边界：从代码建议走向任务执行

麦肯锡将智能体式软件开发定义为：利用大语言模型驱动的系统，自主执行软件工程任务，包括规划、编写代码、运行测试、修复缺陷和部署变更。1，第 10 页

理解这一概念，需要抓住"任务执行"这个核心。智能体可以依据目标选择下一步操作，读取环境反馈，再调整行动。例如，测试失败之后，它可以读取错误信息、修改实现，再次测试。这个过程使 AI 的作用延伸到多步工程活动。

为了便于理解，可以把相关工作方式区分为三类。下面的划分描述的是交互模式，同一款工具可能支持其中多种模式。

工作方式	AI 承担的工作	人的主要参与方式
自动补全	根据当前上下文建议代码片段	持续编写代码，并逐项接受或修改建议
同步协作	按即时指令解释、生成和修改代码	在执行过程中频繁提供指令与反馈
异步委派	接收有边界的任务，持续调用工具、修改代码并验证结果	定义目标和约束，在关键节点审查、验收或处理异常

报告特别强调了从同步协作向异步执行的发展。1，第 11---12 页 这种变化使部分工作可以在人没有持续参与的情况下推进，也让工程师有机会同时管理多项任务。

不过，"自主"始终需要明确边界。智能体能够修改文件，不代表它自然拥有生产数据库的操作权限；能够运行测试，也不代表它可以自行决定一次高风险发布。自主程度应当随任务风险、验证能力和可恢复性调整。

还需要区分两个概念：本章讨论的是用智能体开发软件，下一项趋势"Agentic AI"覆盖的是更广泛的智能体应用。由智能体编写出来的软件，可以是一套普通的库存系统，也可以是一个智能体产品；开发方式与最终产品类型是两个不同维度。

三、报告中的证据：工具扩散与收益分化同时发生

这一章提供了多组看似不同方向的数据。把它们放在一起，才能看清技术所处的阶段。

指标	报告给出的结果	解读时需要保留的口径
企业采纳评级	3：试点阶段	依据专家访谈形成的五级评价，不能换算为"成熟度 60%"
2025 年股权投资	49 亿美元	报告定义的资本交易口径，包含相关并购等活动；不是行业收入
相关岗位公告变化	2024---2025 年增长 221%	特定趋势关键词与数据来源下的招聘活动；不代表全部软件岗位变化
达到显著加速标准的企业	约 25%	相关高管受访者报告：超过四分之一的团队实现至少两倍生产率提升
出现生产率下降的企业	约 30%	调查中的自报结果；不能据此认定下降由 AI 单独造成
开发者收益分化	约 80% 的工程师平均提升约 3%；表现最好的 20% 平均提升约 55%	属于调查结果，反映个体间差异，不能直接当作全行业平均收益
开发活动与最终产出	代码提交活动约增加 180%，发布量约增加 30%	来自报告引用的外部研究，前者不是代码行数，两者也不是同一种产出
对 AI 准确性的信任	46% 不信任，33% 信任，约 3% 高度信任	来自 Stack Overflow 2025 年调查，不能标成"2026 年全体开发者"数据

资料来源：报告正文第 10---11、16 页及研究方法第 3 页；关键生产率调查与提交活动研究见参考资料 2、3，信任调查见 4。

这些数据支持一个相对稳健的判断：技术扩散速度已经相当快，但收益实现仍然具有较强的条件性。

麦肯锡的相关调查开展于 2026 年 5 月，涵盖 334 名产品与工程领域受访者。其中，关于 25% 和 30% 的判断采用了 173 名总监及以上受访者的分析口径。2 这类调查有助于识别企业实践中的差异，但它没有把企业随机分配到不同技术或组织模式，因此不能单独证明某一种改造方式的因果效果。

同样需要审慎理解"近万亿美元的价值"。报告将它表述为潜在机会。配套研究以全球工程师规模、人力综合成本，以及生产率向领先群体靠拢等假设估算潜在新价值。1，第 10 页；2 这与 AI 编程工具的市场收入、企业已经获得的利润、能够立即削减的工资支出，具有不同含义。

资本数据也需要区分构成。报告列出的 2026 年上半年超过 610 亿美元的统计，按其原文主要由一笔 600 亿美元的收购交易贡献。1，第 11 页 这样的结构能够显示大型资本交易对领域关注度的影响，却不适合直接与 2025 年数据相除，推算普通融资活动或客户需求的增长速度。

因此，阅读这一章时，应把三种证据分开：资本与招聘说明资源正在流入，企业调查说明采用效果存在分化，实际开发行为数据则帮助判断提速最终停留在哪个环节。

四、为什么代码增加很多，交付只增加一部分

报告引用的一项研究，是理解这一趋势的关键。Demirer、Musolff 和 Yang 分析了超过 10 万名 GitHub 开发者的活动，并结合 AI 工具使用信息，研究不同代际工具采用前后的变化。3

这里的 180% 指自动补全、同步智能体和异步智能体等多代工具叠加使用后的累计提交活动增幅。它不能表述为"仅使用异步智能体就提效 180%"。相应的发布量增长约为 30%。研究采用匹配事件研究设计，虽然进行了多项识别检验，仍与随机试验具有不同的证据性质。3

这组结果说明，软件生产中的收益会沿着交付流程发生衰减。代码需要被审查、集成、测试和发布，产品还需要被用户采用。每一个阶段都有自身的能力上限。

可以用一个纯粹的假设例子说明。某项需求从确定到发布原本需要 10 天，其中编码占 3 天。即使编码被加速到只需 1 天，而其余环节保持原状，总周期也仍然需要 8 天。编码时间减少了约三分之二，交付周期只缩短了 20%。这个例子用于解释机制，并非报告中的实测案例。

实际工作中还可能出现更复杂的情况：AI 提交的变更增长，人工审查能力没有同步增长，于是等待审查的任务越来越多。工程师局部完成得更快，需求最终上线的时间却未必缩短。

据此，本文认为企业需要关注三类瓶颈。

第一，需求歧义会在执行过程中被放大。 一条模糊需求进入智能体流程后，可以迅速产生方案、实现和测试。若最初的理解偏差没有被发现，后续活动可能围绕同一个错误假设持续展开。更快的执行也就增加了返工的规模。

第二，系统集成需要跨模块判断。 某个修改能够独立通过测试，并不意味着它与支付、权限、数据结构及既有接口兼容。随着变更数量增加，跨模块依赖和兼容性问题可能成为新的工作重心。

第三，发布量与用户价值之间仍有距离。 一次发布可以修复重要故障，也可以增加一个无人使用的功能。提交数和发布数都有测量价值，但企业还需要判断可靠性、使用效果以及客户问题是否得到解决。

这也解释了为什么不能用"30% 除以 180%"计算所谓价值转化率。提交与发布属于不同层级的指标，不能作这样的直接换算。

麦肯锡主张把 AI 嵌入完整的产品开发生命周期（PDLC）。1，第 10---13 页 这个概念比编码更宽，包含需求发现、产品定义、实现、验证，以及产品交付后的反馈。它指向的管理问题是：当一个环节突然变快，怎样让其他互补环节承担相应的工作量，并保持结果质量？

五、企业需要建立怎样的工程环境

模型具备规划和代码生成能力，只是任务能够执行的一个条件。报告列出的底层技术还包括企业上下文系统、智能体评估、执行控制、编排框架、CI/CD 集成与用量管理等。1，第 17 页 这些技术共同决定智能体能否持续完成工程工作。

1. 企业上下文：让智能体理解代码背后的业务约束

企业代码仓库包含大量历史选择。有些规则记录在文档里，有些体现在测试和接口中，还有一些只存在于工程师的经验里。

例如，一个退款功能需要符合代码结构，也需要理解部分退款、促销优惠分摊、财务对账和权限规则。只看到函数实现的智能体，可能写出语法正确、局部测试通过，但业务含义不完整的修改。

报告据此区分了新项目开发、既有系统开发和遗留系统现代化。后两类工作需要处理更多架构约束、依赖关系与既有业务行为。1，第 13 页

企业上下文建设应当让规则可以被检索、理解和验证。知识图谱是报告提到的一种方式；结构化文档、代码索引、接口契约和测试案例，同样可以承担部分作用。选择哪种方式，应取决于系统复杂度与具体的信息缺口。

这带来一个组织层面的变化：过去主要通过口头交接传递的知识，需要逐步进入可维护的工程资料。知识整理因此成为开发能力建设的一部分。

2. Harness：支持持续执行、交接与恢复

Harness 可以理解为支撑智能体工作的执行框架。它组织任务状态、工具调用、权限、记录和恢复机制，使执行过程能够被持续管理。

报告引用了 Anthropic 关于长时间运行智能体的工程研究。该研究尝试通过初始化环境、结构化功能清单、进度记录、版本历史、增量开发和端到端验证，改善跨多个上下文窗口的工作连续性。5 这是一种工程实现经验，不能视为所有软件任务的统一最优方案。

它揭示的问题却具有普遍的分析价值：如果智能体无法可靠判断上一次完成了什么、哪些功能经过验证、当前系统是否处于可工作状态，继续执行就会产生额外的不确定性。

因此，企业应把状态记录和交接材料视为开发产物。一次任务结束时，除了代码，还应留下修改范围、验证结果、未解决问题及继续执行所需的信息。这样的安排能够降低人工与智能体之间、不同执行会话之间的交接成本。

3. 验证机制：明确"通过测试"究竟证明了什么

智能体能够生成测试，有助于扩大检查覆盖面，但测试本身也可能存在错误或遗漏。

尤其当实现和测试都来自同一个需求理解时，两者可能共享同一种偏差。例如，代码错误地假设所有用户都拥有某项权限，生成的测试也沿用这个假设，于是测试通过，却没有检验真正重要的权限边界。

这是本文基于验证逻辑提出的判断：验证需要保留相对独立的判定依据。 对业务逻辑，依据可以来自经确认的规则和案例；对系统兼容性，可以来自接口契约和回归测试；对安全敏感修改，则需要相应的安全检查与责任人审查。

智能体的完成声明应当对应可检查的证据。不同类型的证据证明不同范围的正确性，企业需要避免把某一层测试通过，直接等同于整个变更适合发布。

4. 多智能体编排：处理好任务之间的依赖

报告介绍了由不同智能体分别承担需求、架构、编码、测试和发布工作的"智能体工厂"模式。1，第 12 页

这种方式提供了并行执行的可能，也增加了协作管理问题。多个智能体若同时修改共享接口，局部成果可能互相冲突；各自通过的测试，也未必能保证合并后的系统正常。

因此，多智能体系统应当明确任务边界、依赖顺序、共享接口、变更冲突处理和异常升级规则。任务数量还应与审查和集成能力匹配。

从管理角度看，这是一种新的工作分配方式。其有效性需要通过整体交付效果评估，单纯增加智能体数量无法说明系统能力已经提高。

六、人才结构：定义、验证与交付能力的重要性上升

报告的人才数据提供了一个有启发性的观察：在相关岗位公告中，87% 要求云计算技能，84% 要求 CI/CD 技能。按报告的人才识别与需求口径，CI/CD 的人才供给需求比约为 0.1，而 JavaScript 约为 5.9，Python 约为 1.8。1，第 16 页

CI/CD 指持续集成与持续交付，涉及把代码变更接入自动构建、测试和发布流程。它的作用是让修改能够反复、可靠地进入系统。

这些比例不能直接换算为某个国家有多少岗位缺口。报告的招聘数据主要来自英语国家，技能识别也受到数据源和关键词定义影响。1，第 3 页 但在报告的观察范围内，交付相关技能呈现出的紧张程度，确实高于若干常见编程技能。

结合前文的瓶颈分析，可以推导出一个人才判断：当基础实现更容易生成，团队会更需要能够定义任务、理解系统依赖、判断质量并承担交付责任的人。

角色	工作重点可能发生的变化	应当关注的成果
产品与需求负责人	把用户问题转化为目标、业务规则和验收条件	需求的可执行性，以及上线后的问题解决效果
软件工程师	设计任务边界，处理系统依赖，审查关键变更	系统正确性、可维护性与合并质量
测试与运维人员	建立验证依据、发布流程、监测和恢复机制	缺陷发现能力、发布稳定性与恢复效率
技术管理者	配置人机分工、权限、预算和异常处理责任	团队交付能力、单位成本与长期工程质量

上表是本文基于报告提出的角色分析，不是麦肯锡对岗位数量的预测。

岗位公告增长与部分团队规模缩小，也可以同时发生。一方面，已有团队可能用智能体扩大产出；另一方面，更多组织开始建设相关平台、开发新产品或改造旧系统，产生新的需求。报告尚不足以确定这两种作用对整体就业的净影响。

另一个值得研究的问题，是初级工程师如何积累经验。若基础实现任务大量被委派，他们原本通过编码、调试和修复错误形成系统理解的学习路径，也可能随之改变。企业可以在采用智能体的同时，保留代码解释、故障分析和有监督的独立任务，以检验学习是否仍在发生。这是人才培养方面的管理推论，仍需要长期证据验证。

七、经济账：以合格交付为单位计算成本

报告指出，随着智能体执行复杂任务，token 消耗、推理成本和运行基础设施开始成为需要管理的预算项目。1，第 13---14、17 页

这使软件开发成本具有更强的可变性。同一项任务可能一次完成，也可能经历多次检索、修改、验证与重试。较低的单次调用价格，未必对应较低的最终完成成本。

为了分析这类工作，本文建议采用以下核算思路：

单位合格交付成本 =（人力投入 + 模型与执行环境成本 + 审查返工成本 + 故障处置成本 + 组织改造摊销）÷ 合格交付量。

这是一项分析框架，不是报告中的统计公式。企业需要按照任务类型定义"合格交付"：修复缺陷、实现功能、完成系统迁移，具有不同的工作量与价值，不能简单混合计数。

这一框架有三个实际含义。

首先，模型选择应当与任务匹配。简单、明确且容易验证的工作，可以优先评估成本较低的方案；复杂依赖或高风险工作，则需要把推理能力、验证投入和失误代价一起考虑。

其次，节省工时需要经过资源配置才能体现为经济收益。企业可能把释放出来的时间用于处理积压需求、改善可靠性或开展新产品验证。它们都可能创造价值，但需要通过相应结果衡量，不能直接计为工资支出减少。

最后，应观察上线后的表现。开发阶段少花了时间，如果后续带来更多缺陷修复、系统复杂度和维护工作，收益就可能被逐步抵消。

因而，采用效果至少需要同时观察交付周期、上线缺陷、人工审查与返工投入、单位任务总成本，以及用户或业务结果。AI 使用频率能够说明工具被采用的程度，交付表现才能进一步说明采用效果。

八、如何评价麦肯锡的判断

这份报告具有价值的地方，在于把技术进展与组织运行联系起来。它既描述了异步执行、多智能体协作和 AI 原生工作流，也保留了生产率下降、信任不足、成本上升与遗留系统约束等问题。这使其判断具有较清晰的条件边界。

DORA 的 2025 年研究也提出，AI 会放大组织既有的优势与薄弱环节。6 这一观点与本章的管理主线相呼应：基础工程能力、知识组织和交付流程，会影响 AI 能力进入企业之后的结果。

不过，报告中的不同证据应当获得不同权重。趋势分数由关键词活动和相对归一化形成，主要用于描述研究范围内的变化；采纳评级来自专家判断；企业生产率调查依赖受访者报告；个别领先实践则通常具有较强的情境条件。1，第 3、10---18 页 它们能够共同形成趋势判断，但不能合并成一个适用于所有企业的固定回报率。

开发者生产率研究中的变化，也提醒我们保留时间与场景边界。METR 对 2025 年初工具进行的一项随机试验，发现参与者完成任务的时间增加约 19%；这一结果来自熟悉成熟开源项目的开发者。7 在 2026 年 2 月的后续说明中，METR 认为较新工具可能带来了更多加速，同时明确指出，参与者和任务选择等问题，使新实验无法可靠估计加速幅度。8

两项结果应当共同阅读。前一项显示特定场景中确实可能发生减速，后一项说明技术变化与测量偏差会限制旧结果的外推。企业自己的试点，需要记录模型与工具版本、任务类型、系统条件及质量标准，才能解释效果为何发生变化。

因此，本文对麦肯锡判断的评价是：其方向性判断具有较强解释力，尤其是对开发流程、角色与验证能力的强调；涉及收益规模和推广速度的判断，则应作为条件性预期，通过企业层面的连续测量进一步检验。

九、未来一至两年的四个可检验判断

以下判断来自本文对报告与补充证据的综合分析，不属于麦肯锡已经证实的结论。

判断一：验证与交付能力将成为更重要的竞争条件

随着代码生成能力进一步普及，企业选择工具和改造流程时，可能更加重视成果是否能够审查、集成、发布和维护。这会扩大对评估、测试、安全检查、运行监测及证据管理能力的需求。

可以观察的信号是：人工审查与返工占比是否下降，单位合格交付成本是否改善，以及发布后的质量是否保持稳定。如果只有生成活动增长，系统收益仍然有限。

判断二：自主程度将主要按任务类型扩展

需求明确、影响范围有限、验证充分、易于恢复的任务，具备更好的委派条件。跨系统架构调整、敏感权限变更和关键业务发布，则需要更强的验证与责任安排。

可以观察的信号是：企业能够稳定委派的任务种类是否扩大，人工介入集中在哪些异常，以及自主执行的扩大是否伴随更好的质量证据。

判断三：企业知识积累将更直接地影响开发效率

如果智能体需要理解架构、规则、接口和产品历史，那么这些知识的完整性与可维护性就会影响执行效果。持续整理的文档、测试案例和历史决策记录，可能成为企业开发能力的重要组成。

可以观察的信号是：增加有效上下文之后，需求理解错误和重复返工是否减少；更换模型或工具时，已有知识资产能否继续发挥作用。

判断四：定制开发会更活跃，长期运维能力仍将影响软件采购

智能体式开发可能降低小型工具、业务扩展和特定功能的实现门槛，使企业更愿意尝试组织专用的软件能力。与此同时，持续升级、可靠运行、合规支持和长期维护仍需要投入。

可以观察的信号是：定制能力能否从原型进入稳定使用，以及企业是否根据完整生命周期成本，调整自建、采购和平台扩展之间的组合。

结语

智能体式软件开发正在改变人如何参与软件生产：部分执行工作被委派，人需要更清楚地定义意图、组织知识、检查证据，并对系统结果承担责任。

麦肯锡这一章揭示的核心问题，是技术能力与组织能力之间的匹配。代码提交迅速增加、最终交付增长较少的现象说明，软件生产由多个互补环节构成，每个环节都可能限制收益实现。

因此，企业可以把这一趋势理解为一次持续的工程与组织改造：先识别适合委派的任务，建立可验证的完成标准，再根据交付、质量和成本证据逐步扩大应用。随着生成能力更普遍，能够稳定完成这项改造的组织，有机会形成更持久的开发优势。

参考资料与口径说明

本文以用户提供的麦肯锡 2026 年 9 月版报告为主，解读范围为第 1 项技术趋势，正文第 10---18 页，并结合第 3 页研究方法。上述页码均指报告印刷页码，对应 PDF 文件页序第 12---20 页和第 5 页。补充资料用于核对关键数据及解释技术机制，核对日期为 2026 年 10 月 3 日。文中的假设示例、成本框架、角色分析及未来判断属于作者分析。

1. McKinsey & Company. Technology Trends Outlook 2026. September 2026, sixth edition. "Agentic software development", pp. 10--18; research methodology, p. 3. 本文主要依据用户提供的 PDF。

2. McKinsey & Company. Beyond the copilot: Scaling the agentic product development life cycle. August 21, 2026. 用于核对企业调查、开发者收益分化与潜在价值估算口径。

3. Demirer, M., Musolff, L., & Yang, L. Writing code versus shipping code: Productivity effects across generations of AI coding tools. CEPR / VoxEU, June 21, 2026. 研究作者对其研究的说明，用于核对提交活动、发布量、工具代际叠加与研究设计。

4. Stack Overflow. 2025 Developer Survey: AI. 用于核对开发者对 AI 准确性的信任数据。

5. Young, J. / Anthropic. Effective harnesses for long-running agents. November 26, 2025. 用于理解长时间执行、状态交接、增量开发与验证机制。

6. DORA. State of AI-assisted Software Development 2025. 用于补充 AI 与组织既有能力之间关系的研究判断。

7. Becker, J., Rush, N., Barnes, E., & Rein, D. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. 2025. 用于说明特定开发场景中的生产率异质性。

8. METR. We are Changing our Developer Productivity Experiment Design. February 24, 2026. 用于补充后续测量中的选择效应及旧结果的外推边界。