背景:为什么 IT 运维成了智能体最早的规模化场景
IT 运维具备三个让智能体容易落地的特征。第一,任务边界清晰:一个工单、一次告警、一台设备,起止明确,成败可判定。第二,历史数据密集:告警日志、知识库文章、变更记录往往已经积累多年,是现成的上下文来源。第三,失败代价可控且有回滚路径:多数运维动作作用在可恢复的对象上,出问题可以退回。
第三点尤其关键。近期多份企业落地复盘都指向同一条规律:先做可回滚、可复现、出问题代价低的场景,比先做价值最高的场景更容易跑通。本栏目此前复盘过的 Thrive 服务台改造与本案例在路径上高度一致——都是先把数据底盘换成统一的,再上智能体,最后接端点。
行业侧的渗透速度也支持这个判断。第三方调研显示,63% 的中国企业已部署 AI 助手或 AI 赋能的知识管理系统,而一年前该比例为 28%;Gartner 对 IT 负责人的调研显示,75% 的 IT 管理者正在试点、部署或已落地各类 AI 智能体。两项数据均被厂商引述,本文标注为厂商引用的第三方调研,未独立核验原始问卷。
事实基线:30 余款、五条产品线、不额外收费
时间线是这样的:2026 年 5 月,ManageEngine 卓豪在全球发布智能体 AI 能力,在各产品中引入 Zia 智雅智能体;时隔五个月进入中国市场,首批推出 30 余款;10 月 28 日深圳用户大会上正式亮相,计划到 2026 年底扩展至 100 余款。
覆盖范围是全栈 IT 管理产品体系,而非单一工具。已嵌入的五条核心产品线为:全栈可观测性(FSO)、统一服务管理(USM)、统一终端管理与安全(UEMS)、身份与访问管理(IAM)、以及安全信息与事件管理。据厂商全球副总裁 Mathivanan 的说法,到 2026 年底智能体将嵌入多达 60 余款产品,覆盖工单全流程监测、网络安全运维等核心场景,并能实现内部操作联动;而行业内多数厂商往往只提供一两种单点解决方案。
商业模式是这轮发布里最值得拆的一点:智能体不额外收费,企业无需调用外部大模型,也不需要自行部署大模型,直接使用厂商自研的 Zia 智雅大模型与智能体。厂商全球产品市场总监 Ananth 解释的商业逻辑是,智能体本身就是产品研发的一部分,也是数据中心提供服务的一部分;中国 COO 李飞补充,智能体主要是在现有 IT 管理产品中调用已有功能,完成分析、操作等任务,与生成代码、文章相比 Token 消耗相对有限。
两个具体案例可以说明智能体在做什么。根因分析智能体:当网络速度明显变慢时,运维人员通常需要逐一排查防火墙、终端、路由器等设备,有时需数百次检查才能定位;智能体根据现有 IT 设备数据分析故障原因,必要时主动从终端获取更多数据复查并给出方案,对已预先授权的操作(例如关闭交换机端口)还能直接执行。一线专家智能体:自动识别工单内容,按问题性质从知识库查找解决方法,简单问题直接把方案发给用户并批量处理重复工单,复杂问题转人工。
四笔账:各自的口径是什么
厂商公布的四组量化结果,需要各自标注口径才能使用:
| 场景 | 公布读数 | 口径提示 |
|---|---|---|
| 全栈可观测性 FSO | 设备故障修复时间缩短 40% 至 60% | 区间而非点估计;未说明样本量与统计口径;不同报道表述为「MTTR 缩短」或「修复效率提升」 |
| 统一服务管理 USM | 可自主处理 40% 至 60% 的 L1 工单 | 「自主处理」未定义是否含错误率与返工;剩下 40% 至 60% 仍走人工 |
| 统一终端管理 UEMS | 响应/处置时间由小时级缩短至分钟级 | 量级描述,无具体数值;「部分原本需要数小时的工作」这一限定语不能省略 |
| 身份与访问管理 IAM | 三年累计投资回报率预计 219% | 「预计」与「三年累计」两个限定词;未给出投入口径与折现方式 |
另有一笔成本侧的账:李飞测算,以 DeepSeek V4 版本为例,企业每年可能产生 20 万至 40 万元的大模型调用费用;在卓豪的方案里这部分支出被直接划掉。这条数据的价值不在于具体数字,而在于它给出了一个参照系——本地或公有大模型调用对企业而言是一笔可计量的年度支出,而免收 Token 费的商业模式把这笔支出从智能体的 ROI 分母里移走了。
把「零 Token」理解成范围限定词:智能体只调用已有产品功能时不产生额外费用,一旦需要调用第三方模型,账单照付。省下的 20 万至 40 万元是真实的,但它换来的是能力边界,不是无限能力。
本文推算一:缩短 60% 不等于快 60%
「修复时间缩短 40% 至 60%」这句话在传播时常常被读成「快了 40% 到 60%」。两者不是一回事。设原修复时长为 T,缩短 60% 后为 0.4T,那么同样的时间能处理 1 ÷ 0.4 = 2.5 倍的工作量;缩短 40% 后为 0.6T,对应 1 ÷ 0.6 ≈ 1.67 倍。因此这个区间对应的吞吐改善是 1.67 倍到 2.5 倍,而不是 1.4 倍到 1.6 倍。
这个换算对容量规划的意义很直接:如果一支运维团队原本每天能闭环 10 个故障,MTTR 改善处于区间上沿时,理论吞吐接近 25 个。但理论值不等于实际值,因为故障处理的时间构成里还包含等待备件、协调窗口、用户确认等不受智能体影响的环节。缩短的是其中可自动化的那一段,而这段占整体的比例决定了最终能吃到的收益比例。
同理,40% 至 60% 的 L1 工单自主处理率,意味着仍有 40% 至 60% 的工单走人工。若工单总量随自助能力提升而上升(用户发现提问成本降低后问得更多),人工侧的绝对量未必下降。这一效应在已披露材料中未被提及,属于需要在试点阶段自己埋点观测的指标。
三步走:每一级真正的前置条件
福田康明斯的三步走是这样设计的:第一步做单点场景智能体,例如市场数据分析——过去数据分析依赖专门团队,用 Excel 或 BI 工具整理输出固定报告,管理层临时提问或业务人员拜访客户途中提出的定制化查询往往难以即时回答,单点智能体补齐这类短板;第二步落地业务级、部门级智能体,覆盖采购、供应链、客户支持等业务群;第三步构建企业级智能体,整合分散的智能体与技能模块,沉淀福田康明斯独有的企业知识库。刘元福的表述是,这个企业级智能体对福田康明斯的认知深度将超过内部任何一名员工,因为通用大模型虽具备广泛知识,却缺乏企业专有知识。
本文认为,三步走里真正的难点不在任何一步的搭建,而在每一级的前置条件,而这些前置条件在公开表述里被省略了。
第一步的前置条件是问题可结构化。市场数据分析之所以能先做成功,是因为查询对象是已有口径的数据,答案可被验证,答错也不会直接造成损失。反过来,一个需要跨系统推断、答案无法立即验证的场景,不适合作为起点。
第二步的前置条件是权限与上下文模型统一。从单点跨到部门级,意味着智能体要同时触碰采购、供应链、客户支持三套系统的数据。如果这三套系统的身份、权限与字段口径不一致,智能体要么被卡住,要么绕过控制。这一步的实际工作量通常被低估。
第三步的前置条件是知识治理,而它恰恰是最容易被跳过的。企业级知识库的质量决定了这个智能体的上限,而厂商全球副总裁 Mathivanan 自己在给出落地建议时就明确指出:知识库录入错误信息可能引发错误决策,因此构建高质量知识库与安全防护机制同样重要。也就是说,第三步的瓶颈不是模型能力,而是「谁对知识库里的每一条内容负责」。一个没有责任人、没有复核机制、没有过期清理策略的知识库,会让第三步的智能体把错误放大到全公司范围。
还有一个容易被忽略的顺序问题。刘元福把运维放在最前面,理由是明确的:如果运维做不好,生产停线、系统中断、业务连续性得不到保障,做其他增值业务都没有意义。因此福田康明斯优先采用成熟通用的标准化产品来保障运维连续性,而不是自建。这个判断对制造业是成立的,也解释了为什么它的智能体落地从 IT 运维起步而非从业务起步。
零 Token 的边界:什么时候它不再是零
「零 Token」需要在三个地方打折。
第一处是调用范围。厂商中国总裁侯康宁明确表示,如果部分特殊场景需要调用 DeepSeek、WorkBuddy 等第三方模型,客户仍需支付相应的 Token 费用。也就是说,省钱的前提是智能体的任务落在已有产品功能之内。任务一旦越界,账单就回来了,而且越界的往往是价值更高的那部分任务。
第二处是不计入的隐性成本。免的是 Token 费,不免的是集成、培训、知识库整理、权限梳理与流程改造。对福田康明斯这样有约 1200 台办公电脑、外加大量随生产设备引入而难以统一配置的工控机的制造业企业,光是把资产台账理清楚就是一项独立工程。这类成本通常不被写进 ROI 分子,却是决定项目能否跑通的变量。
第三处是规模上限。厂商自述的逻辑是智能体主要在现有产品中调用已有功能,因此 Token 消耗相对有限。这句自述同时说明了它的能力边界:这类智能体擅长的是「在既有功能之间做编排与判断」,不擅长的是需要大量生成式输出的开放任务。把它当成一个开放的通用智能体来用,会迅速撞上边界,也会迅速撞上账单。
本文推算二:年底 100 余款意味着什么
首批 30 余款,2026 年底目标 100 余款。以 10 月 28 日为起点、12 月 31 日为终点,中间约两个月;按 30 与 100 两个端点计算,还需新增约 70 款,折合每月约 35 款、每个工作日约 1.6 款。
这个节奏透露了两件事。其一,它依赖模板化生成能力。厂商提供的 Zia 智雅智能体构建器支持用自然语言描述需求,通过低代码或无代码组件配置安全护栏、上下文与知识库来生成智能体,并通过 MCP Server 把能力开放给第三方工具——这正是支撑高频发布的产能来源。其二,数量增长速度提示了一个判断口径的问题:智能体款数与场景深度之间没有换算关系。对采购方而言,真正要问的不是「你们有多少款」,而是「我这三个具体场景各自对应哪一款、各自的准确率与回滚方式是什么」。
顺便说一句,60 余款产品、100 余款智能体的组合意味着平均每条产品线承载不到两个智能体。这个密度说明现阶段的智能体是「嵌入既有功能」而非「重构产品线」,与厂商自己的表述一致。
最大风险面:智能体同时是攻击面
这篇案例里最有价值的一句判断来自客户方而非厂商。刘元福坦言,随着智能体能力提升,数据安全和网络安全挑战越来越大——「大家用智能体既可以做业务的事情,也可以做网络攻击的事情」。他期待平台在出现问题时能自动响应,并具备基线管理和动态调整能力。
这句话把一个常被弱化的事实摆到了台面上:给智能体的每一个授权,同时也是一份可被滥用的权限。根因分析智能体能关闭交换机端口,是因为它被预先授权关闭交换机端口;反过来,一个被诱导的智能体也能关掉不该关的端口。这与近期智能体安全领域的主流判断一致——问题不出在工具本身,而出在「允许哪些工具、在什么范围、有没有审计与超时」这三件事是否被显式声明。
福田康明斯在终端侧的应对是具体的:用 BitLocker 对硬盘加密,使电脑丢失或硬盘被拆卸后没有解密密钥也无法读取;补丁与漏洞采用集中管理,由 IT 工程师先验证兼容性再通过统一平台推送,整个过程在用户无感知下完成。这些措施属于传统终端安全范畴,但它们构成一个前提——智能体运行的底座越干净,智能体本身的风险面越小。
厂商给出的落地顺序与这个判断一致:由易到难、由简到繁;优先把标准化、可复现、支持故障回滚的常规运维场景交给智能体;涉及全局核心设备、关键业务服务等高风险操作,坚持「AI 出方案、人来审核执行」——由智能体输出操作步骤,运维人员完成审核、落地执行并校验结果,验证稳定后再从小范围试点逐步放大。
六步可复现路径
第一步,先理资产台账再谈智能体。福田康明斯仅办公电脑就约 1200 台,外加随生产设备引入、难以统一标准配置的工控机;统一纳管是后续一切自动化的前提,这一步省不掉。第二步,选定可回滚的起点。优先选常见、可复现、出问题可回滚的常规运维场景,例如密码重置、补丁推送、重复工单批量处理。第三步,把知识库当成产品来建,明确每条内容的责任人与复核周期。第四步,为高风险操作设定人工审核环节,采用「智能体出方案、人审核执行」的模式,验证稳定后再放大范围。第五步,从单点跨到部门级时,先统一权限与字段口径,再谈智能体编排。第六步,只有在前五步都跑通之后,才考虑企业级知识库智能体——它的上限由第三步的质量决定,而不是由模型决定。
五条避坑
一,别把「零 Token」当成零成本。它是范围限定词,越界即收费;集成、培训与知识库整理的成本不会被免除。二,别从核心设备开始。先做可回滚场景,关键设备与服务坚持人工审核执行。三,别低估知识库的错误放大效应。厂商自己指出知识库录入错误信息可能引发错误决策,这一风险在第三步会被放大到全公司。四,别把智能体只当工具不当权限。每一个授权同时是一份可被滥用的权限,需要审计、超时与范围声明。五,别把 ERP 解耦当成反锁定的手段。刘元福明确表示,福田康明斯推进 ERP 解耦的目的不是避免被厂商绑定,而是提升业务运转效率与供应链联动准确性——动机错了,工程优先级也会跟着错。
尚未披露的部分
四笔账的样本量、统计区间与测算方法未公开,其中 IAM 的 219% 未给出投入口径与折现方式。福田康明斯数十个智能体的具体清单、各自的准确率与人工接管率未披露。三步走的时间表与阶段性验收标准未公布,目前无法判断第二步推进到了什么程度。零 Token 模式在调用第三方模型时的计费与配额规则未细化。信创适配方面虽已支持人大金仓数据库、麒麟与欧拉操作系统、ARM 架构及东方通中间件,但各组合下的实测性能数据未公开。关于智能体本身的安全机制(审计、超时、权限范围声明的具体实现),公开材料中只有方法论建议而无技术细节,目前官方及行业暂未披露更多细节,后续将持续跟进迭代动态。
冷静判断:这套打法能复制到什么程度
可复制的是顺序,不是厂商。「稳住运维底座—单点可回滚场景—部门级统一口径—企业级知识治理」这条顺序与具体产品无关,本栏目此前复盘的多家企业落地案例也呈现同一形态。对还没有任何智能体在运行的组织,照这条顺序走比照厂商清单买更可靠。
零 Token 是一种值得注意的商业模式,但要按范围而非按承诺来读。把大模型能力作为产品的一部分而非新的收费项,降低了试点门槛,也让 ROI 的分母变小。这一思路对 SaaS 厂商有参考价值;对采购方,需要把它换算成能力边界来评估。
四笔账是可参考的量级,不是可直接引用的 ROI。缩短 40% 至 60% 的区间、219% 的三年预计值,都来自厂商且未公开测算方法。把它们当作立项时的量级参照可以,写进董事会材料前需要自己复算。
真正决定成败的是那两件没人写进新闻稿的事。一是资产与权限的梳理,二是知识库的责任机制。前者决定智能体能触达什么,后者决定它说出来的话能不能信。福田康明斯把这两件事都放在了智能体之前,这才是这个案例里最值得学的一处。