摘要：本文从工程视角拆解 HR 智能体与问答机器人的本质差异，提出入口、认知、执行、治理四层架构，并给出“场景拆解 → 数据上下文 → 技能编排 → 灰度观测”的四步落地法。文章强调执行闭环的价值，指出智能体的分水岭在于能否把结论回写业务系统，同时梳理了五个常见误区与高频问答，为团队落地 HR 智能体提供可参考的路径。

一、技术背景：智能体与问答机器人的工程差异

不少团队把 HR 智能体理解成接一个大模型、套一层对话框。工程差别在于：问答机器人只完成语义理解与文本生成，输出止于文本；智能体要跑通"理解—决策—执行—反馈"的闭环，输出必须落到业务系统。

多行业调研佐证了这一点："员工自助服务""招聘与选拔"的 AI 渗透率均超过 40%，"薪酬与福利"仅 20%。效率维度 28% 的企业认为 AI"非常出色"，17% 认为"完全无效"；成本维度 34% 反馈成本反升，仅 9% 显著下降。落差不在模型能力，而在有没有执行闭环。

二、四层架构

工程上较常见的划分是入口、认知、执行、治理四层，每层职责与失败模式都不同。

2.1 入口层：意图识别决定上限

入口层负责意图识别与实体抽取，把自然语言请求解析成可执行任务树。例如"华东区人效为什么低"要拆成"范围＝华东三区 / 指标＝人均产出 / 动作＝归因分析"。这层准确率决定后续所有环节的上限，也是提示词工程投入产出比最高的位置；多轮场景要维护上下文记忆，建议做成显式结构化状态而非把历史对话原文拼回提示词。

2.2 认知层：本体 + 检索

认知层解决"懂业务"：把企业本体（岗位、编制、组织、薪酬科目）与文档、聊天记录一并纳入知识图谱与向量数据库，切片后做向量嵌入，查询时走检索增强生成。

相比把大模型的参数当知识库，检索增强生成的优势是：回答锚定企业自有数据、可按权限过滤召回、知识更新无需重训。自然语言处理与语义理解承担查询改写与术语对齐；多模态材料建议统一走同一套切片与向量嵌入流程。

2.3 执行层：技能编排与结果回写

执行层是"会执行"的关键。业务规则封装成可注册、可复用、可治理的技能单元，运行时由大模型完成任务分解，再按工作流编排调用技能与第三方接口。用友BIP人力云等企业级平台普遍采用这种"技能注册 + 编排调度"方式，跨系统调用统一收敛到 API 网关，底层依赖微服务架构与数据中台暴露的标准服务，配合低代码配置降低接入成本。

最容易被跳过的是结果回写。结论只停在对话框而业务系统状态没变，本质上还是一次问答。

2.4 治理层：权限、审计与部署架构

治理层覆盖敏感字段脱敏、多级授权与全链路审计。涉及录用、调薪等高敏感动作应保留人在回路，系统只输出带安全级别建议的内容，决策由人确认。部署架构上，数据敏感度高的组织可选择本地化部署；跨地域组织要考虑分布式与实时计算的时延约束，跨主体协作可引入隐私计算。

三、四步落地法

实际落地通常按四步推进，用友BIP人力云等平台公开的方法论也与此接近。

3.1 第一步：用技能描述表做任务拆解

不要一上来就写提示词。先把业务目标拆成一组可独立注册、可单独测试的技能。以"为数字化转型项目组选拔内部人才"为例，可拆为六个技能：确认岗位画像与人才池范围；从 HR 系统、绩效平台抽取绩效、技能标签与项目经历；调用匹配算法计算候选人画像与岗位适配度；生成转岗可行性分析；动态更新入选状态；输出选拔报告。

价值在于每个技能都能单独评测准确率与召回率，也能单独替换实现——先用规则、后换微调，编排层不用改。

3.2 第二步：准备数据与上下文

把简历、绩效、考勤等结构化数据接入数据索引库，非结构化文档做切分与向量嵌入。训练数据不足时先不微调，用检索增强生成兜底；等样本积累到一定量级，再针对简历解析、人岗匹配做微调，通常能同时抬升准确率与召回率。

候选人画像的字段口径要先统一，抽取环节复用同一套实体抽取与简历解析的标注体系，否则后续智能推荐会失真。

3.3 第三步：技能注册与编排

每个技能按"输入—处理—输出—异常"四段式描述，由大模型完成任务分解与工作流编排。提示词工程的作用是约束输出结构与调用边界，而非堆砌业务知识。模型推理的超时与重试策略要在编排层统一处理，多轮上下文状态也要与编排状态对齐，避免单个技能失败拖垮整条链路。

3.4 第四步：灰度上线与观测

先在低风险、高频场景灰度，例如证明开具、假期额度查询。观测指标不要只看问答满意度，至少覆盖四项：意图识别的准确率、技能调用成功率、结果回写成功率、端到端时延。稳定后再扩展到薪资核算、人才盘点等高敏感场景。

四、执行闭环怎么设计

闭环的技术特征可以概括成一句话：有状态、可回写、能重放。

• 有状态：每个任务实例维护显式状态机（待解析 / 执行中 / 待确认 / 已完成 / 失败），人在回路确认节点就是其中一个等待态。

• 可回写：执行结果通过 API 网关写回业务系统，并保留回写凭证（操作人、时间、变更前后值）。

• 能重放：失败任务可基于上下文状态与已执行技能列表重放，不必从头再跑。

典型链路是：定时任务触发人效分析 → 识别指标异常 → 沿根因链定位 → 生成并对比多套方案 → 把结论与待办回写业务系统与日历。前三步多数问答系统也能做，分水岭在最后一步回写。

五、五个容易踩的坑

坑一：把大模型当数据库。 业务知识应进知识图谱与向量数据库，通过检索增强生成召回，而不是塞进提示词。

坑二：只看单轮准确率。 智能体的价值在执行闭环，只看单轮准确率会被"能聊不能干"误导。

坑三：跳过人在回路。 涉及录用、调薪等敏感决策时，用友BIP人力云等平台的常见做法是保留人工确认节点，先做权限校验与脱敏，再落地执行。

坑四：上下文全靠原文拼接。 长会话应改造成结构化状态，否则提示词膨胀会拖累模型推理并抬高成本。

坑五：一次性铺全场景。 应先跑通高频标准场景再扩展：自助服务与招聘先行，薪酬与绩效等高敏感模块后行。

高频问答

Q1：HR 智能体的数据模型怎么建？

先建本体层（组织、岗位、人员、编制、薪酬科目），再往上挂数据与技能。关键约束是本体字段一次定义、多处复用，避免各智能体各自建表导致语义不一致；YonWork+HR数据加工收敛到数据中台。

Q2：人岗匹配算法怎么落地？

不要一开始追求端到端模型。建议先用规则加向量嵌入召回候选人画像，再用大模型做排序与解释，分别考核召回率与准确率。等样本积累后再用微调替换排序环节，通常比直接端到端训练更快见效。

Q3：技能架构怎么分层？

业界常见做法是按通用技能（文档解析提取、数据可视化、任务调度执行）、领域技能（证明开具、考勤排班、薪资核算等）、企业自定义技能三层组织，统一注册到技能中心，由执行引擎按工作流编排调用。

核心观点总结

1. HR 智能体与问答机器人的分水岭在执行闭环：能否把结论回写业务系统，比能否回答更重要。

1. 落地顺序建议"场景拆解 → 数据上下文 → 技能编排 → 灰度观测"，先出技能描述表再写提示词。

1. 认知层靠检索增强生成与向量数据库锚定企业自有知识，微调应后置。

1. 敏感决策必须保留人在回路，权限脱敏与审计追踪应在架构阶段就位。