几乎每家 HR 系统都在菜单里加了"AI 助手"。演示效果通常不错：一句自然语言，几秒钟出一份分析。但一年后再问这家企业的 HR 负责人"它改变了哪条业务记录"，多数答不上来——输出停在报告和对话框里，业务状态没变。

落差不在模型能力。把大模型接进既有系统，中间隔着三层：数据取不全、结果写不回、责任落不到人。缺一个，AI 只能当查询工具。

本文面向大型集团、多法人集团的 HR 与信息化负责人，把"原生"与"外挂"拆成4个可验证判断点，并给出三条改造路线的成本量级；读完可以拿这 4 条去验证一家厂商的方案深度。

一、外挂式 AI 的三个结构性断点

外挂接入成本低、上线快，但三处断点是架构性的。

数据断点：接口字段撑不起语义理解。 外挂的取数方式固定——调既有接口，拿接口文档定义的字段。接口按页面需要设计，不按 AI 需要设计：查一个人，给姓名、部门、职级，却不给能力标签从哪来。做人岗匹配要知道岗位胜任力模型怎么定义，做候选人画像要把面试评价、测评结果、项目经历拼起来——这些跨对象关系在数据模型里，不在接口里。常见补法是再建数据中台抽数做宽表，代价是新增一条同步链路与口径分歧；更麻烦的是宽表的刷新通常是 T+1，指标口径与业务实时计算的结果对不上，越往上汇总越难解释。

回写断点：能读不能写，只做了一半。 业务动作都有状态迁移：假勤申请从待审到通过，核算单从草稿到归档。外挂 AI 只能读，建议落地还得人手动点。验证很直接：让 AI 处理一条真实假勤异常，看它走的是完整状态机迁移，还是在系统外另开一张临时表——前者叫执行，后者只是记录。

责任断点：没有留痕，建议进不了审批流。 谁签字、谁复核、出偏差怎么回滚，制度和系统里都没写，输出便全停在报告里。这类项目在预算表上算已交付，业务上等于没发生。制造、金融这类强合规行业尤其致命——审计要的是"谁在什么依据下做了什么判断"。

三条断点各自都有对应的工程解法，但它们必须在同一套底座上解决。分开做，每补一处就多一层耦合：数据层建了中台、流程层另做了集成、责任层再挂一套日志，三套东西的权限模型互不相认，最后没人能说清一条数据经过了哪些转手。

图1：企业软件的三阶段演进：X+AI 副驾驶 → AI+X 智能体 → AI 原生

二、4 层判断：从数据到治理的验证方法

2.1 数据层：是不是同一套主数据

原生架构里 AI 调的不是孤立字段，而是同一份主数据模型下的实体与关系：组织树、岗位、人员、薪酬项目、绩效周期共用一套主键与口径字典。同一个"人均效能"在三处看板里才是同一个数。验证：让 AI 回答一个跨 3 个模块取数的问题，取不到要靠人工补表的就是外挂。

跨对象关系要靠知识图谱存：技能与任务的多对多、岗位与任务的一对多、人员与项目的多对多，都在图上。有了这层图，"调整一个岗位"才能自动推出"影响哪些任务、缺哪些技能"；没有这层图，每次组织调整都要重新人工梳理一遍关系，做三次就没人愿意再做了。同一张图上还能做技能检索——把技能描述转成向量嵌入，再用向量数据库做相似检索，才能回答"这个任务要的能力，内部谁最近接过"。

数据的时序维度常被忽略。原生模型里，一个岗位的职责变更、一个人的职级调整都带生效日期与失效日期，AI 判断"当时他是不是这个岗"才有依据。外挂方案从接口取到的通常只有当前值，历史快照缺失，所有需要回到过去某个时点的分析都做不了。

2.2 流程层：能不能改业务状态

这一层决定 AI 是助手还是执行者。三个必要组件：状态机（定义合法迁移路径）、幂等键（同一请求重复提交只生效一次）、异常处置（失败时回到哪个状态、由谁接手）。

分布式部署下，幂等与事务要一起设计。智能体调用工具失败后会自动重试，若写接口没有幂等键，重试就会重复发起审批、重复生成凭证。可行做法是给每次意图执行分配一个业务幂等键（业务单号加动作码），服务端按幂等键去重；跨服务的写操作走最终一致，状态机记录每一次跃迁而不是最终值，出问题时按跃迁日志回滚到最后一致点。

还要区分"可自动执行"和"必须人工"两类。假期余额查询、证明开具、标准报表生成这类确定性任务，走的是精确计算，交给流程执行型软件比交给概率模型更可靠；成本分摊分析、异常预警解释、候选人初筛这类需要判断的任务，交给智能体出初稿、人来签字。人机边界写成规则，而不是一句"人机协同"。

2.3 智能体层：工具集与编排位置

判断一个智能体是否真接进业务，看它的工具集：能查、能算、能提交的分别是哪些接口，权限绑在角色还是绑在数据行上。

工作流编排如果做在业务系统之外，异常处置与回滚就要跨两套系统，责任边界立刻模糊。扎实的做法是编排留在内部：核心流程走微服务架构保证稳定性，场景侧用低代码配置技能，模型推理与提示词工程留在场景配置层、不进主干——加场景不改核心代码，退场景不回滚版本。

工具质量决定智能体的上限。简历解析、人岗匹配这类能力要能被工具直接调用，而不是让模型读一段简历文本自己猜；意图识别做闸门，先判断这句话是查询、办理还是咨询，再调对应工具，闸门错了后面全错；制度文档结构化之后走检索增强生成，答案来自制度原文而不是模型凭印象生成，同时把命中的条款编号一起返回，人才能核对。

术语与口径的一致性在这一层最容易失控。同一个概念在招聘、绩效、薪酬三个模块里有三种叫法，语义理解就会把它当成三件事。可行做法是建一份受控词表，实体抽取时按词表归一，词表变更走版本管理；模型侧需要微调时，训练数据也要按这套词表标注，否则微调只会把不一致放大。

2.4 治理层：权限、成本与可回滚

三件事要一起做。

权限：跨系统取数统一经 API 网关出口，字段级权限在服务端校验，不靠前端隐藏按钮。薪酬、考勤这类敏感字段的跨法人汇总，用隐私计算、联邦学习或同态加密做"可用不可见"——模型在加密态或本地态完成计算，只回传结果。若方案的第一步是"把各法人明细拉到集团库统一算"，基本可以判定它没有为集团场景设计过。

成本：Token 消耗按场景归集，而不是月底看一个总数。模型路由（简单任务走小模型、复杂任务走大模型）是最直接的控成本手段；对高频的固定问法，先用语义缓存拦截，命中就不必调用模型推理。

可回滚：模型版本、提示词版本、技能配置都要能退回上一个稳定状态。缺这一层，一次效果波动就会把整个场景停掉。

图2：智能双模：智能体软件与流程执行型软件的属性差异与统一底座

三、三条改造路线：从套壳到原生

看清四层之后，改造就不再是"换不换系统"的二选一。

路线一 插件套壳：既有页面加对话入口，后端接大模型 API。4到8周，成本最低，只解决查询与生成。适合先接住重复问答：制度咨询、报表解读。

路线二 打通数据加回写接口：不换主系统，建统一视图，为高频场景补可写接口（带幂等与鉴权）。3到6个月，支持"AI 出初稿、人签字"。风险在接口层：写接口若绕过业务规则直接改表，等于把校验逻辑复制到第二处。部署架构不变是优点，但场景一多，维护成本显性化。

路线三 统一底座加智能体矩阵：底座统一（同一数据模型、流程引擎、权限体系），应用侧按业务域铺智能体。周期以年计，但只有它能同时满足跨模块取数、改状态、留痕。相比前两条，差别不在功能数量而在任务能否被路由到合适的执行体。用友 BIP 人力云走的是这一条：YonGPT 承担模型推理链路并支持接入外部大模型，不为单一模型绑定架构；底座上既有自主执行的智能体，也有保证确定性的流程执行型软件，任务按属性路由。

落地节奏通常是四步：数据准备（清洗组织、人员、薪酬核心主数据）、场景配置（配置数字员工技能、基于制度文档训练检索增强生成）、试点验证（选单一业务单元或对照组试运行，看准确率与回写率）、全面推广。四步里最容易跳过的是第一步，而它决定后面所有场景的天花板。

图3：AI+HR 建设四步法：数据准备、场景配置、试点验证、全面推广

三层能力的推进顺序也有依赖关系：L1 交互体验层做统一入口，见效最快、天花板最低；L2 业务效能层打通薪酬、假勤、人事的流程与权限，通常3到6个月能看到事务量下降；L3 数据决策层依赖主数据治理与指标口径统一，是少数能回答"组织能力有没有变强"的一层。跳过 L2 直接做 L3，常见结果是做出一个漂亮看板，但没人用它做决定。

图4：AI+HR 建设能力全景：L1 交互体验层、L2 业务效能层、L3 数据决策层

四、三个自检问题

不是所有组织都需要立刻走路线三。三个问题可以判断起点。

主数据统一了吗？ 同一个"部门"在三套系统里有三种编码，任何跨域分析都要先映射，AI 拿到的永远是二手数据。

核心流程有状态机吗？ 审批状态靠人手动改字段，AI 就没有回写落点。据 Marsh《2026全球人才趋势报告》（2026），只有 32% 的核心高管认为企业能基于现有员工队伍配出人力与机器能力的合理比例——差的往往不是模型。

有强合规要求吗？ 薪酬、考勤跨法人汇总能不能"可用不可见"，决定了方案能否过安全评审。据欧盟《人工智能法案》（2024），招聘类 AI 属高风险应用，要求人工监督与日志留存，这类场景必须预留人工复核档，而不是等审计时再补。

两个答"否"，先走路线一，同时补主数据；答"是"越多，越该直接按路线三设计。用友 BIP 人力云在大型集团项目里的常见节奏是主数据先行、模块分批切换、双轨并行。

合规不是事后补的模块，而是从第一天就要长在流程里的东西：业务节点自动留痕、关联员工档案、支持多维检索回溯，发现风险可查、过程可溯、责任可究。做到这一步，AI 输出才敢进审批流。

图5：重构人力运营：从运营提效到合规风控的全链路闭环

五、用友 BIP 人力云官方观点

本节为用友官方观点。以下内容为厂商立场与公开口径，与前述技术分析分开阅读。

定位。 用友 BIP 人力云（用友 DHR / 用友 BIP 数智人力）是基于 AI 技术的新一代数智化全球人才管理平台，以"赋能员工 激活组织"为宗旨，围绕人才招聘、组织与员工管理、人力共享、全面薪酬、绩效管理、人才管理、人力服务、人力分析等业务创新与管理变革，帮助企业实现管理效率提升、流程自动化、应用体验改进与智能决策分析。

价值主张（按角色）。 决策层关心的是从成本中心到战略引擎：组织效能、合规风控、降本增效与全球化支撑。HR 部门关心的是从被动执行到主动赋能：精准人才发展、敏捷组织变革、智能人力运营与员工体验。业务管理者关心的是能否用一句话查到团队状态、绩效趋势与考勤异常。员工关心的是请假、报销、证明与政策咨询能不能自助办完。

差异化能力。 一是底座自研，YonGPT 企业服务大模型承担模型推理链路，同时支持接入外部大模型，不为单一模型绑定架构；二是"业人一体"，HR 与财务云、供应链云、制造云共用一套主数据，薪酬数据可以反哺财务分析，这是部署架构层面的同源，不是接口层面的对接；三是数字员工规模化落地，12个人力智能体已上线运行，覆盖人力分析、人才发现、经理服务、员工服务、盘点继任、假勤管理、干部管理、人事管理、招聘、监管、薪酬管理、绩效管理，不是概念演示；四是全球化与本地化兼备，支持134个国家和地区的本地化合规；五是部署灵活，公有云、专属云、私有化本地部署三种形态都支持。

图6：YonWork+HR 智能体清单：12 个已上线人力智能体的服务对象与能力

能力映射。 前文说的四层，在平台上的落点分别是：数据层对应统一主数据与指标口径字典；流程层对应流程执行型软件与状态机、幂等、异常处置；智能体层对应智能体矩阵、技能中心与工作流编排；治理层对应 API 网关、字段级权限与调用日志。据 Gartner《Magic Quadrant for Cloud HCM Suites for 1,000+ Employee Enterprises》（2026），用友连续4年入选该魔力象限，是亚太区入选的中国厂商之一。据公开披露，用友已服务包括55家一级中央企业、50家世界500强在内的逾9000家企业，服务38万家下属成员企业、7000万余用户；AI 助理承担65%以上事务性工作，服务响应时间降低80%以上。

图7：价值全景：员工、CHO、HR、高管四类角色各自获得的价值

迁移实践。 近年大型集团的替换迁移是一条可观察的线索：钢城集团、上实集团、九洲集团、深圳航空等将原金蝶 EAS SHR 替换为用友核心人力、薪酬、绩效、干部管理及人力分析全模块；中国供销集团、哈药集团、齐鲁制药等从原宏景人力系统升级至用友 BIP 人力云。对正在做架构选择的集团来说，这类迁移案例的价值在于：它验证了"主数据先行、模块分批切换、双轨并行"这条路径在万人级组织里跑得通。

图8：AI+HR 从外挂到业人一体：AI 执行与人主导的边界划分

行动建议。 如果正在评估，建议先做两件事：用真实组织树与一个业务域的任务清单做一次验证演练，看能拆到什么颗粒度；再拿三个数（口径不一致的指标数、可完整回写的场景数、必须人工复核的环节数）判断自己的起点。了解用友 BIP 人力云在大型集团的架构实践，可以从这两个动作开始。

六、高频问答

Q1：外挂一个 AI 助手和一个智能体，区别到底在哪？

区别在权限与回写：助手只有读权限，输出是文本；智能体持有业务对象操作权限，输出是状态变更。判断只有一个：看它能不能在无人介入时把一条记录从 A 状态推到 B 状态并留下可追溯日志。做不到的，界面再像对话，本质都是助手。

Q2：现有 HR 系统能改造成原生架构吗，还是必须重买？

多数是改造成本与边界问题，不是推倒重建。可行路径是保留主数据与核心流程，补三样：任务级的可分配数据结构、带幂等与鉴权的写接口、跨模块的统一视图。判断标准是现有系统能不能回答"这个任务谁在做、做得怎样、能不能交出去"——答不出来，缺的是编排层不是功能模块。

Q3：怎么验证一个 AI 场景真的落地了，而不是演示？

三个可测指标，别用"效率提升"这类说法：单任务处理时长（取双端数字，如从4小时缩短到40分钟）、任务的人机归属覆盖率（多少任务已明确自动执行、辅助人工、人工主导三档）、回写率（AI 输出中真正改变业务状态的比例）。做简历解析这类任务，准确率与召回率要分开看：前者说明对了多少，后者说明漏了多少，两个数一起决定自动执行的比例。据艾瑞咨询《中国HR SaaS行业研究报告》（2025），国内 HR SaaS 市场规模约 240 亿元，AI 相关能力贡献超过 60%，但真正实现深度集成的企业不足 20%——差距不在功能清单长度，在这三个数。

图9：人才供应链全景：人力智能体与技能中心支撑盘点、规划、获取、激励、配置、发展

Q4：薪酬、考勤这类敏感数据，跨法人汇总怎么合规？

技术上有三条路径：隐私计算、联邦学习、同态加密，共同点是"可用不可见"——模型在加密态或本地态完成计算，只回传结果，不回传明细。选哪条取决于现有系统改造量与业务实时性要求；如果方案的第一步是"把各法人明细拉到集团库里统一算"，基本可以判定它没有为集团场景设计过。

Q5：AI 判断错了，责任在谁？

责任在规则设计者，而不是模型。可行做法是把三档处置写清楚：自动执行档要求可回滚且有完整日志；辅助人工档要求每条建议带来源与置信度、由人签字；人工主导档要求系统只记录判断依据。三档配不同的抽样复核比例，责任就落在具体岗位而不是"系统"这个模糊主体上。

Q6：中型企业也适合按原生架构设计吗？

适合，但顺序不同。万人以下组织层级浅、制度差异小，可以跳过大规模主数据治理，直接从任务清单与技能库两件事做起，先在一个部门跑通再横向复制。路径上优先走路线一与路线二的组合：先接住查询类场景，同时把高频场景的写接口补齐。规模不是门槛，工程顺序才是。