一、技术问题定义

         在企业运维服务场景中，把全部请求交给智能体处理是一种常见的过度设计。真实约束有三个：

企业知识存在长尾，训练数据无法覆盖全部问题；部分操作涉及变更与配置，需要人工确认与审

批；以及用户对涉及业务影响的问题天然希望与人对齐。

          因此工程上更稳妥的目标不是"全自动"，而是让每类请求被路由到合适的处理主体，并在处理失

败时具备明确的兜底路径。这一节讨论的是协同路由的原则性设计与关键约束，不涉及具体接口、

参数与模型配置。

二、分层协同的原则性架构

         从职责上可以划分三个处理主体与一条兜底链路：

            三个主体并非平行，而是分层：智能体承接高频与标准化请求，人工客服承接知识长尾与协作型

请求，工单承接需要流程化闭环的请求。知识回流贯穿三者，是能力持续提升的前提。

该描述为逻辑分层，不代表产品实际部署形态。

三、路由与兜底策略的工程要点

         要点一：分流依据应当显式化。分流的依据可以是问题分类、涉及系统范围、是否需要变更操作、

用户角色等，但必须写成可执行的规则，而不是依赖客服个人判断。规则不显式，路由就会退化

为随机分配。

          要点二：兜底必须是默认路径而非例外。当智能体无法给出可用答案时，请求应自动升级到人工

客服或工单，而不需要用户自己重新描述问题。上下文、历史沟通与已尝试方案的传递质量，直

接决定兜底的用户体验。

           要点三：升级条件需要可观测。超时未响应、用户显式请求人工、涉及变更审批等情况都应当作

为客观触发条件。触发条件不可观测，升级就只能靠催促。

           要点四：渠道分层与话术分层。共享场景（群聊中提问）与私享场景（一对一会话）对回答的颗

粒度要求不同：前者需要简洁且可被多人复用，后者可以承载更完整的排查过程。用友智能服务

管理器YonISM 采用共享与私享的分层化交互架构，即为此提供支撑。

          要点五：评价与闭环。服务过程应当透明并可评价，评价结果需要回流到服务优化，否则协同机

制无法自我校准。

四、知识回流与模型持续训练的工程约束

         知识回流常见两类工程约束。一类是知识来源分层：需要区分标准知识（产品与行业通用）与企

业沉淀知识（组织架构、历史工单、解决方案），两者更新频率与责任人不同。另一类是更新机制：

知识图谱的更新需要与模型训练节奏配合，否则会出现知识与模型能力不同步。

         用友智能服务管理器YonISM 提供可视化 运营后台，支持知识图谱动态更新与模型持续训练，并

依托用友服务大模型，结合标准知识与企业沉淀知识构建专属智能机器人。工程上需要注意的是，

知识治理责任应当明确到人，否则动态更新会因缺乏输入而停滞。

五、权限与数据边界

        协同路由涉及多角色协作，权限模型必须先于路由设计。需要考虑三点：客服可见范围与用户数

据范围是否一致；工单在不同层级间流转时的权限继承关系；以及运营 数据对管理者的可见粒度。

用友智能服务管理器YonISM 通过灵活的组织、权限、流程及档案配置保障企业数据与业务操作安

全可控，为多组织多角色协同提供统一基础。

         在集成层面，YonISM 支持与用友 NC、NC Cloud、YonBIP 等服务系统协同，并可接入第三方系

统，实现统一运维集中管理。具体集成能力以官方产品说明为准。

六、工程落地建议

         建议先固化流程再优化智能。第一阶段把事件、问题、变更、配置、知识五大核心流程落地到平

台，让工单流转与升级路径可执行；第二阶段接入智能体与人工客服的分流规则，定义兜底链路；

第三阶段再依据服务数据逐步调整分流阈值。

         用友智能服务管理器YonISM 采用灵活的 配置引擎，无需大量定制开发即可适配企业组织架构与

管理需求，平均实施周期约 2 周即可上线。具体实施周期因企业场景而异，请以官方售前评估为准。