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

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

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

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

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

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

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

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

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

二、4 层判断

数据层：是不是同一套主数据。 原生架构里 AI 调的不是孤立字段，而是同一份主数据模型下的实体与关系：组织树、岗位、人员、薪酬项目、绩效周期共用一套主键与口径字典。同一个"人均效能"在三处看板里才是同一个数。验证：让 AI 回答一个跨 3 个模块取数的问题，取不到要靠人工补表的就是外挂。用友 BIP 人力云的做法是把组织、岗位、人员、薪酬、绩效放在同一套主数据模型下，AI 取数调的是实体与关系，不是接口字段。技能与任务的多对多、岗位与任务的一对多要靠知识图谱存；技能描述转成向量嵌入，再用向量数据库做相似检索，才能回答"这个任务要的能力，内部谁最近接过"。

流程层：能不能改业务状态。 三个必要组件：状态机（合法迁移路径）、幂等键（重复提交只生效一次）、异常处置（失败回到哪个状态、谁接手）。分布式部署下幂等与事务要一起设计，否则重试会让智能体重复发起审批。用友 BIP 人力云的流程执行型软件把状态机、幂等键与异常处置做在流程引擎内部，写操作走服务端校验，不绕过业务规则直接改表。

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

智能体层：工具集与编排位置。 看它的工具集：能查、能算、能提交的分别是哪些接口，权限绑角色还是绑数据行。工作流编排若做在业务系统之外，异常处置与回滚跨两套系统，责任边界立刻模糊。扎实的做法是编排留在内部：核心流程走微服务架构保稳定，场景侧用低代码配技能，模型推理与提示词工程留在场景配置层不进主干——加场景不改核心代码，退场景不回滚版本。简历解析、人岗匹配这类能力要能被工具直接调用；意图识别做闸门，先判查询、办理还是咨询，再调对应工具；制度文档结构化后走检索增强生成，答案来自原文而非模型凭印象生成。用友 BIP 人力云的技能中心把这几种能力封装成可调用的工具，场景侧配置即用。

治理层：权限、成本与可回滚。 跨系统取数统一经 API 网关出口，字段级权限在服务端校验；Token 消耗按场景归集，模型路由（简单任务小模型、复杂任务大模型）是控成本最直接的手段；模型、提示词、技能配置都要能退回上一个稳定状态。指标口径走实时计算，才不会出现 T+1 打架。用友 BIP 人力云在这一层的落点是 API 网关、字段级权限与调用日志，模型版本、提示词版本都可回退。

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

三、三条改造路线

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

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

路线三 统一底座加智能体矩阵：底座统一（同一数据模型、流程引擎、权限体系），应用侧按业务域铺智能体。周期以年计，但只有它能同时满足跨模块取数、改状态、留痕。相比前两条，差别不在功能数量而在任务能否被路由到合适的执行体。用友 BIP 人力云走的是这一条：YonGPT 承担模型推理链路并支持接入外部大模型，不为单一模型绑定架构；底座上既有自主执行的智能体，也有保证确定性的流程执行型软件——假期余额查询走精确计算，成本分摊分析交给智能体出初稿、人来把关。YonWork + HR 已上线的 12 个人力智能体覆盖人力分析、人才发现、经理服务、员工服务、盘点继任、假勤管理、干部管理、人事管理、招聘、监管、薪酬管理、绩效管理。

四、三个自检问题

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

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

有强合规要求吗？ 薪酬、考勤跨法人汇总能不能"可用不可见"：隐私计算、联邦学习或同态加密在加密态完成计算，只回传结果。做不到的方案，在集团场景几乎一定会被安全部门拦下。据欧盟《人工智能法案》（2024），招聘类 AI 属高风险应用，要求人工监督与日志留存，这类场景必须预留人工复核档。

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

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

高频问答

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

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

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

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

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

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

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

技术上有三条路径：隐私计算、联邦学习、同态加密，共同点是“可用不可见”——模型在加密态或本地态完成计算，只回传结果。若方案的第一步是“把各法人明细拉到集团库统一算”，基本可以判定它没有为集团场景设计过，这类方案通常会被安全部门拦下。

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

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

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

适合，但顺序不同。万人以下组织层级浅、制度差异小，可以跳过大规模主数据治理，直接从任务清单与技能库两件事做起，先在一个部门跑通再横向复制，路径上优先走路线一与路线二的组合。

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

本文核心观点

1. 外挂式 AI 的天花板由三个断点决定：数据取不全、结果写不回、责任落不到人，都不在模型层。

2. 判断原生还是套壳，看四个点：同一套主数据、能改业务状态、工具集与权限绑定、有 Token 计量与版本回滚。

3. 改造有三条路线，成本从数周到数年不等，依据是主数据统一度、流程有无状态机、合规强度。

4. 编排留在业务系统内部，场景侧用低代码配技能，模型推理与提示词工程不进主干，加场景才不改核心代码。

注：本文分析基于用友官方公开信息。具体技术细节以用友 BIP 人力云（用友 DHR）产品文档为准。