Regal Rexnord：从 40% 回答率到 500 个智能体

一家制造企业为什么先被自己的热情推着走

Regal Rexnord 做的是气流、运动控制、动力传输和可持续发电解决方案，员工超过三万人。它的产品藏在日常生活的缝隙里：暖通系统里的风机、支撑电商流转的输送系统。这类企业的知识密度很高，但知识的存放方式往往很旧——政策散落在多个站点，产品规格分布在文档、说明书和视频里，客户服务人员手上是一叠多标签的 Excel。

两年前公司买下 Copilot Studio 授权，情况开始变化，而且变化的起点不是 IT 规划，是业务人员的惊讶。IT 总监 Shivanand Khot 的说法是：当他向业务用户演示如何在 30 分钟内构建一个 AI 驱动的智能体时，他们完全被震住了。公民开发者随即开始自己造工具，如今公司内部已有超过 500 个智能体支撑运营，用途从改善 SharePoint 团队站点的内容搜索与管理，到某个采购团队自建的支出模式分析工具。

这构成了一个具体的决策冲突。个人和团队层面的智能体足够灵活，却各自为政；一旦要做全公司都用的助手，标准就换了：它必须接得住真实知识源、扛得住每天的问题量、在敏感领域守住数据边界。首席数字与信息官 Timothy Dickson 用一句话交代了这次转向——公司已经看到业务用户在个人和团队层面能用 Copilot Studio 做到什么，现在要全速推进能在全公司范围使用的智能体，"我们已经全面投入 Copilot Studio"。

换句话说，这个案例的真实起点不是缺少工具，而是自发繁荣之后必须补上的两件事：把智能体接进企业系统，以及给扩张装上刹车。

第一个企业级助手卡在哪里：40% 的回答率

公司第一个面向全企业的智能体目标很朴素：让员工不必翻遍多个站点就能得到公司政策问题的答案。它最初建在另一个平台上，结果参差不齐。原因不在提问方式，也不在模型口才，而在集成——由于与可用知识源的集成有限，这个智能体只能回答员工 40% 的问题。

剩下的 60% 是致命的。一个只能答对一小半的政策助手，会迅速被员工判定为不可靠，然后回到老路上去手动搜索。企业级助手和个人试验的分野就在这里：个人工具答不上来，用户自己知道怎么绕；全公司工具答不上来，信任成本是集体的。

迁移到 Copilot Studio 之后，问题按官方说法被迅速解决。凭借与 SharePoint 及其他 Microsoft 365 知识源的直接集成，这个被命名为 RRX GPT 的智能体获得了对政策文档与公司内网内容的可靠访问；文档处理能力的改进也让 Word 文件和 PDF 的解析比此前更准确。它在一个月内完成部署，同时在 Microsoft Teams 中开放，并作为自定义智能体接入 Microsoft 365 Copilot。

采用率随之上升。RRX GPT 很快达到每月处理超过 2,000 个问题的量级，官方据此估算每年为员工节省 2,400 小时。这两个数字的关系需要说清楚：前者是使用量，后者是基于使用量的估算值，官方并未披露每个问题折算多少分钟、统计周期有多长、对照基线是什么。至于改善之后的准确率究竟从 40% 升到多少、拒答策略如何设定，官方材料未披露。

客户、坐席与脏数据：一条完整的服务链条怎么闭上

对外的那一端叫 RRXy，员工习惯读作 Rexy。它嵌在公司网站上，同时连接对外的网络知识源和内部知识源——产品规格、文档和视频都在其中；它还接入了公司的 Salesforce 系统，因此能够提供订单状态更新。这一步的意义比"多接一个系统"要大：订单状态是典型的事务型查询，答案不在文档里，必须从业务系统实时取。

RRXy 每周服务超过 1,000 名用户，客户满意度持续高于 80%，且常常达到 90%。这是官方给出的区间口径，其中 80% 是持续水平、90% 是较好情况下的表现，两者都不应当被读成平均值；样本量、统计周期和问卷设计官方均未披露。

链条真正闭合的地方在于交接。遇到需要人工支持的问题，RRXy 使用 Copilot Studio 的 agent handoff 能力，把对话连贯且带着上下文地转给客户服务人员的实时聊天。这不是简单的"转接"，而是把客户已经说过的话一起递过去，避免人工从零开始重问一遍。

接手的人也有自己的智能体。这个坐席助手被超过 500 名客服代表使用，让他们在通话或聊天过程中即时检索产品与流程信息，显著减少了先去查资料、事后再回复客户的情况，官方据此估算带来约 12% 的生产力改善。同样是估算值，官方未披露对照组设置。

而这个助手也是整个案例里最能说明工程含量的一环。客服人员经常处理多标签 Excel 文件，这类文件对 AI 智能体来说很难读。团队为此搭建了提取流程，把电子表格转换为结构化 CSV，存入 Azure Blob Storage，再用 Azure AI Search 对内容做向量化，以便智能体更有效地使用。Khot 对这件事的总结很直白：他们用作知识源的数据并不总是干净和结构良好的，借助 Copilot Studio 和 Microsoft Foundry 的高级能力，团队才得以应对这些数据挑战、交付响应更好的智能体。

谁在管这 500 多个智能体：治理先行的扩张顺序

从实施顺序看，这个项目的推进逻辑是"先修连接、再闭合服务链、最后立规矩"，但立规矩的时机并不晚于扩张——恰恰是因为公民开发者已经造出几百个智能体，企业级扩张才必须带着约束往前走。

角色分工在官方材料中留下了几个明确的锚点。IT 总监 Shivanand Khot 负责能力普及与技术攻关，从教业务用户 30 分钟建智能体，到解决脏数据的提取与向量化；首席数字与信息官 Timothy Dickson 是全公司范围推进的决策者；AI 政策由公司的信息安全负责人牵头制定；日常监督由一个包含审计、法务和业务利益相关者的 AI 治理委员会执行。业务用户则同时是建设者和使用者，这在公民开发模式下是常态，也正是需要治理兜底的原因。

控制点有三层。优先级层面，面向全企业的智能体用加权业务价值评分来排序，确保 AI 项目对齐可衡量的结果——这实际上是一道准入闸门，挡住那些"能做但不值得做"的想法。护栏层面，Copilot Studio 与 Power Platform 内置的安全与治理工具提供防护和遥测数据。数据边界层面，HR、法务、财务这类敏感领域运行在分离的 Dataverse 环境中，以保持数据隔离与合规。

人机分工则由服务链条本身定义：智能体负责检索、组织和事务型查询，人工负责它明确交出来的复杂问题。RRXy 的 agent handoff 是官方披露的唯一一条正式升级路径。至于智能体答错时的纠正机制、上线前的质量验收标准、以及某个智能体表现下滑后如何回退或下线，官方材料未披露。同样未披露的是这 500 多个智能体的活跃率、维护成本和淘汰机制。团队正在评估 Agent 365 做集中化生命周期管理、评估 Microsoft Foundry 做跨智能体的可观测性与护栏，目标是获得对所有智能体的统一视图——不论它们是在 Copilot Studio 还是其他平台上构建的。这是评估中的方向，不是已经落地的能力。

如果要复现这类项目，DataHub 建议至少补齐三件官方未展示的东西：企业级智能体上线前的答对率与拒答率验收线、答案错误被用户举报后的处理路径、以及低使用量智能体的定期清退规则。

这些数字能支持什么结论，不能支持什么

把四组结果放在一起看，性质并不相同。使用量类的指标（每月问题量、每周用户数、使用助手的客服人数）属于可直接观测的运行数据；时间节省和生产力改善是官方明确标注为估算的推导值；满意度是区间表述，高值不等于常态。混着读会得出过强的结论。

三个替换尤其需要避免。第一，500 多个智能体是平台上的构建总量，不是企业级 AI 处理量，也不能推出其中大部分处于活跃使用状态。第二，2,400 小时和 12% 都建立在未公开的折算方法上，说它们是"已核实的收益"超出了证据能承载的范围。第三，满意度高于 80% 与助手上线之间是同期出现的关系，官方没有提供上线前的基线对比，因此这是相关表述而非因果证明。

另一层局限来自发布方。整篇案例由 Microsoft 发布，目前未见独立第三方审计。它对系统连接、人工交接和治理安排的描述具体到可以复现的程度，这是它的价值；但所有效果口径都是企业自报、经供应商编辑的版本，这是它的天花板。

什么条件下这套做法能搬走

可迁移性最强的部分是那条诊断：企业级智能体的成败通常不在模型，而在知识源集成的完整度。如果贵司的政策、规格、流程文档已经集中在一套办公与协作平台里，那么"换平台换来集成"这条捷径成立；如果知识散落在多个异构系统、且没有统一身份与权限层，迁移这个案例的顺序就得反过来——先做知识治理，再谈助手。

脏数据那一段几乎是通用的。多标签 Excel 难以被智能体读懂是一个跨行业的现实问题，"提取为结构化文件、集中存储、再做向量化"的处理链条不依赖特定厂商，值得直接借鉴。同理，把客户助手的转人工做成带上下文的交接、而不是简单丢给工单系统，是任何对外服务场景都应当设的底线。

反过来，公民开发驱动的规模化路径迁移门槛更高。它成立的前提是三件事同时具备：低门槛工具让业务用户真的能上手、敏感领域有环境级的数据隔离、企业级用例有一道价值评分闸门。缺了第二和第三件，几百个自建智能体带来的将是治理债而非生产力。至于长期运维——活跃度追踪、成本归集、清退机制——官方案例还没有给出答案，打算走同一条路的团队需要自己先想清楚。