AI 智能体真正上岗前，企业为什么要先重修基础设施？

一篇关于麦肯锡《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] 所引口径不同。