一篇关于麦肯锡《Reimagining tech infrastructure for (and with) agentic AI》的深度解读：从试点与规模化的落差，谈到执行架构、成本账本和落地顺序。
一个 AI 智能体能回答“服务器为什么报警”，不代表它能安全地处理一次生产事故。
回答问题时，它只需读懂日志并生成一段话；处理事故时，它还要确认报警是否真实、关联哪次变更、能调用什么工具、是否有权重启服务、谁批准回滚，以及操作之后怎样证明故障确实消失。
这中间隔着的，正是企业的技术基础设施。
麦肯锡在 2026 年 4 月发表的文章《Reimagining tech infrastructure for (and with) agentic AI》提出了一个双向命题：企业要改造基础设施，才能让智能体可靠工作；同时也可以用智能体改造基础设施的运营方式。读完这篇文章，我认为真正值得讨论的不是“未来有多少个智能体”，而是企业能否把原本依赖人来理解和操作的系统，改造成机器可以辨认、授权、执行和核验的环境。
一、智能体已经进入企业，为什么还没有大规模“上岗”？
麦肯锡援引其 2025 年 AI 调查称，62% 的受访者表示其组织至少已开始试验 AI 智能体：其中39%刚开始试验，23%已在至少一个业务职能扩大部署；但在任何单一业务职能中，表示其组织已经规模化使用智能体的受访者比例均不超过 10%。后两组数字的统计口径不同，却共同指出一个问题：部署虽然在推进，跨场景复用和深度应用仍有很长的路要走。[1][2]
**时间也要看清。**这篇基础设施文章发表于 2026 年 4 月，引用的是 2025 年调查。麦肯锡在2026 年 8 月发布的新调查则称，约两成受访者表示其组织已在全企业层面规模化使用 AI 智能体；在“至少一个职能规模化”的口径下，大型组织为40%，规模较小的组织为22%。[4]这说明部署正在推进，但它与上文“任何单一职能不超过 10%”不是同一个指标，不能简单相减得出增长率。
设想一个常见试点：让模型读取一条告警，查找知识库，再给工程师建议。它很容易在演示中显得聪明；但只要把任务改成“请直接处理故障”，问题就接踵而来：
- 日志、配置数据库和工单记录互相矛盾时，它应该相信谁？
- 它能查询生产环境，却是否有权修改生产环境？
- 同一时间两个智能体提出相互冲突的操作，谁来决定顺序？
- 执行失败后，谁来回滚，谁来承担责任？
- 每增加一个智能体，推理、存储和调用成本如何追踪？
这些不是模型多背一些运维知识就能解决的问题。**试点通常验证智能体能否给出建议；规模化则要求它能在明确边界内完成工作，并留下可以审计的结果。**这是我对报告中“规模化落差”的核心解读。
二、报告最容易被误读的几组数字
讨论“智能体会降低多少成本”之前，先把数据的分母、时间和性质分开。
| 报告中的数字 | 准确含义 | 不应解读为 |
|---|---|---|
| 62% | 2025 年调查中，受访者表示组织至少已开始试验智能体的比例，含 23% 在至少一个职能扩大部署 | 62% 的企业已经把智能体接入核心生产系统 |
| 单一职能不超过 10% | 2025 年调查中，在任一业务职能里报告规模化使用智能体的受访者比例 | 所有企业的 AI 项目只有 10% 成功 |
| 到 2030 年基础设施成本可能增至 2—3 倍 | 基于行业报告与 Gartner 数据的预测，报告同时假设预算整体大致持平 | 已经发生的全球成本涨幅，或每家企业都必然翻倍 |
| 常规基础设施工作长期可自动化 60%—80% | 麦肯锡基于实践经验给出的潜力判断 | 60%—80% 的岗位会消失 |
| 初始部署的持续运营成本可能下降 20%—40% | 特定基础设施运营改造的潜在持续成本降幅 | 所有企业 IT 总支出都会下降 20%—40% |
数据来源及口径见原文第 2、4、6 页；其中“2—3 倍”的出处在原文脚注中被标为麦肯锡依据行业报告和 Gartner 数据所作的预测。[1]
这组数据放在一起，反而能看出企业面临的真实张力：智能体扩大了计算与存储需求，而企业又希望靠智能体减少重复运维工作。**算力需求增长与运维效率提高可以同时发生。**只展示“省下的人时”，不记录新增的推理调用、治理、验证和事故成本，就算不出真实收益。
三、基础设施要改的，不只是 GPU 和服务器
谈到 AI 基础设施，很多人首先想到更强的显卡、更大的内存和更多机器。这些很重要，但报告重点讨论的“基础设施”，还包含企业如何把智能体接入既有系统，并允许它安全地执行操作。
可以把一个能在生产环境工作的智能体系统理解为四个相互依赖的部分：
| 部分 | 需要回答的问题 | 企业里的典型材料 |
|---|---|---|
| 可执行动作 | 智能体究竟能调用什么？ | API、自动化脚本、基础设施即代码、标准化工单动作 |
| 可信上下文 | 智能体凭什么判断当前状态？ | 资产与配置记录、依赖关系、日志、指标、变更历史 |
| 治理边界 | 谁允许它做什么？ | 数字身份、最小权限、审批阈值、审计日志、人工叫停 |
| 生命周期管理 | 智能体上线后由谁持续负责？ | 注册清单、负责人、适用范围、性能评估、成本监控与退役机制 |
这四部分对应报告提出的基础能力。[1]其中最关键的变化，是把过去人类工程师脑海里的隐性知识逐步变成机器可用的显性约束。例如，一句“出现该报警时先检查上游数据库，发布窗口内禁止自动重启”不能只躺在群聊记录里；它需要变成可查询的依赖关系、可执行的检查步骤和可强制执行的策略。
**智能体“知道怎么做”与系统“允许它怎样做”，必须是两套机制。**前者由模型与上下文提供判断，后者由身份、权限、规则和审批控制执行。把两者混在一个提示词里，无法代替生产系统中的权限管理。
麦肯锡因此主张一种更像“网状结构”的架构：不同职能的智能体、工具和企业系统经由共享的编排能力协作；执行层与数据层相对解耦，同时保留不同模型和部署环境的选择权。其示意图甚至将安全执行层单独画出，放在工具连接器与真实系统操作之间。[1]
这里有一个容易被忽略的商业含义：未来基础设施的价值，可能越来越多地体现在能否让多个智能体复用同一套身份、上下文、工具和审计机制，而不是某一个单独智能体演示得多惊艳。这是基于报告架构所作的推论，并非报告提供的市场规模预测。
四、看一次生产事故，就明白为什么要“编排”和“安全执行”
报告用一场一级严重事故（SEV1）说明多智能体如何参与运维。[1]将其改写成一个便于理解的工作流程，大致是：
- **触发与分派：**监控系统发出报警，事故管理智能体建立事件，读取服务归属和严重程度。
- **并行取证：**网络、应用、基础设施和变更记录等领域的智能体，分别检索自己的数据来源。
- **汇总假设：**编排智能体比较各方证据，形成可能的根因和处置步骤，并说明证据不足之处。
- **分级授权：**低风险、可逆的标准动作可以按预设规则执行；影响生产回滚、客户通信等重要动作交由人批准。
- **执行与验证：**通过安全执行层调用工具；之后检查指标是否恢复，若无效则停止或回滚，并保留完整记录。
这一流程的关键并非“多找几个模型一起思考”，而是把检索、判断、批准、执行、验证分成可追踪的步骤。如果一个系统只会生成“建议重启服务”的文字，却没有资源归属、审批阈值和结果验证，它仍然只是辅助分析工具。
现实案例也给出了参考。报告写到，一家跨国企业的 IT 服务台每年处理约45 万张工单；改造后，其至多 80% 的请求实现自动化，50% 的服务人员处理能力转向更高价值工作，客户满意度达到4.8/5。这里的 80% 是该案例的“至多”结果，50% 指工作能力转移，不能直接换算成裁员比例，更不能套用到其他组织。[1]
五、哪些场景值得先做？五个区间要分开看
报告第 6 页的图表列出五个价值领域。以下数字保留原图口径，并将“占比”与“潜在节省空间”并列，方便判断从哪里起步：[1]
| 场景 | 对应的基础设施支出占比 | 该场景的潜在节省空间 | 更适合先处理的问题 |
|---|---|---|---|
| IT 服务台 | 基础设施人力支出的 20%—30% | 25%—45% | 密码重置、账号解锁、标准权限申请、工单分流 |
| 可观测性与 IT 服务管理 | 基础设施人力支出的 20%—30% | 20%—40% | 告警关联、故障定位、事件分派、标准处置 |
| 网络运营 | 基础设施人力支出的 10%—20% | 20%—40% | 网络异常诊断、受策略约束的例行变更 |
| 托管与云资源运营 | 基础设施人力支出的 15%—25% | 20%—40% | 环境配置、容量管理、补丁和资源规格调整 |
| 成本与合同管理 | 非人力相关支出约占基础设施支出的 40%—60% | 5%—15% | 闲置许可回收、资源优化、合同和账单核验 |
**请不要把右列五个百分比相加。**原图脚注明确说，这些节省区间不可加总，因为各场景的基数不同，部分范围还可能重叠；并且图中展示的是潜在收益，实际收益取决于组织的成熟度。[1]劳动成本和非劳动成本同列时尤其需要看清分母。
我会优先选择服务台或故障分诊作为第一批场景：业务频率高、历史记录多、常见动作容易标准化，也容易界定何时转交人工。对于网络配置变更、生产回滚等高影响操作，应先证明系统能正确识别风险，再逐步开放执行权限。
另一个容易被忽视的案例来自德国电信。麦肯锡提到了其 RAN Guardian Agent；德国电信的官方公告称，它已经用于监测移动网络表现并协助排障与优化。这个案例说明智能体确实可以进入复杂网络运营，但公告同时将其描述为迈向自主修复网络的第一步，不宜理解为网络运维已全面无人化。[1][3]
六、企业怎样算清楚一笔“智能体运维账”？
企业常把“自动处理了多少工单”作为成绩单，但自动化率本身不足以证明业务价值。至少还要同时看三类指标：
- **效果：**端到端解决率、平均修复时间（MTTR）、重复故障率、服务满意度。
- **安全：**误操作率、越权尝试、人工接管次数、回滚成功率、审计记录完整性。
- **经济性：**每件成功处理事件的推理与工具成本、人工复核成本、平台维护成本、事故损失，以及实际节约的人时或外部支出。
一个更实用的核算式是：
净收益 = 避免的人工与外部支出 − 推理及算力成本 − 集成与维护成本 − 人工复核成本 − 新增风险成本
这是为落地评估提出的简化框架，不是麦肯锡报告给出的公式。它提醒我们：若自动化处理了很多请求，但后续需要大量人工返工，或模型调用成本持续上升，表面的自动化率就不能代表净收益。
部署位置也是同一笔账的一部分。报告允许企业结合云平台服务、模型提供方或企业自托管模型，按成本和数据敏感性选择架构。[1]据此可推论：涉及敏感数据、明确的低延迟要求或既有本地系统时，本地或边缘部署值得评估；需求波动大、跨区域弹性要求高时，云端资源也可能更合适。“全部放云端”或“全部放本地”都不应先于业务约束成为结论。
七、如果只有 90 天，我会按这个顺序试
麦肯锡建议 CTO 在最初 90 天聚焦流程改造、运营数据、治理和智能体管理。[1]把这些原则转成一个可执行的试验节奏，我会这样安排；以下时间划分是我的实施建议：
**第 1—30 天：选定一个边界清楚的任务。**挑选高频、可回滚、历史数据充足的流程，例如标准工单处理。记录当前解决率、处理时间、人工工时、误操作与单件成本，明确系统的事实来源和责任人。
**第 31—60 天：先让智能体“看”和“建议”。**接入只读日志、工单、配置与知识库；梳理冲突数据；建立工具权限、审批规则和审计记录。用历史事件与模拟异常评估其判断质量，再开放极少数低风险动作。
**第 61—90 天：小范围执行，按净收益复盘。**观察端到端成功率、误操作、回滚、人工接管和每件处理成本。只有当效果和安全指标一起达标，才扩大到更复杂的环境，并把运行中的智能体纳入统一注册与生命周期管理。
这个顺序看似保守，却有助于避免一种常见浪费：购买了更昂贵的模型和更多机器，最后发现企业连“这台机器属于哪个服务、故障由谁批准处理”都无法一致回答。
结语：智能体时代的基础设施，是一套可被授权的行动系统
这篇报告的意义，不在于宣布某个惊人的自动化百分比，而在于改变我们理解“AI 基础设施”的方式：计算资源当然重要，但企业还需要让资产与依赖可识别，让工具动作可调用，让权限可约束，让每一步结果可验证。
可以把判断标准压缩成一个问题：当智能体准备对真实系统执行一个动作时，企业是否清楚它依据什么事实、获得谁的授权、会造成什么影响，以及做错了如何停止？
如果这四件事答不清楚，再聪明的模型也只能停留在演示台上。真正决定智能体能否规模化的，往往是演示台背后那些没有那么炫目、却可以反复使用的基础设施能力。
资料来源与口径说明
[1] Arnaud Tournesac 等，麦肯锡，《Reimagining tech infrastructure for (and with) agentic AI》，2026 年 4 月 23 日。本文依据用户提供的 11 页 PDF 核对了正文及第 6、8 页图表；应用建议与推论已在文中单独标明。
[2] 麦肯锡，《The state of AI in 2025: Agents, innovation, and transformation》，2025 年 11 月 5 日；为 [1] 所援引的调查来源（PDF）。
[3] 德国电信，《AI agents for mobile network》，2025 年 11 月 11 日。
[4] 麦肯锡，《The state of AI in 2026: On the road to ROI》，2026 年 8 月 25 日；本文仅用来补充报告发表后的行业进展，其规模化指标与 [2] 所引口径不同。
