这一份是谁写的、数据是什么性质：由 HEYI 撰写，介绍我们交付的一个客户项目，客户未获具名授权前按其要求匿名。文中数据为生产环境真实运营数据（截至 2026 年 9 月 8 日）。覆盖人数与实际使用人数一并给出，办理成功率的计算口径写在文末。
这一份里有什么
- 三类高频诉求，只有一类是真的在办事
- 五件挡在前面的事，关键词机器人办不成事
- 能听懂、查得到、办得成
- 上线 112 天的真实运营数据
- 数据口径：哪两个数字必须一起给
01 场景
员工在一个对话框里办完常见 HR 事务，HR 不再被重复咨询淹没。
客户是一家 B2B SaaS 企业。这套 HR 数字助理嵌在企业协同办公平台里，面向全员，覆盖三类高频诉求。同时以 MCP 工具的形式把 HR 能力开放给企业内其他智能体，成为企业 AI 生态里的 HR 能力底座。
| 三类高频诉求 | 具体是什么 |
|---|---|
| 政策咨询 | 考勤制度、假期规定、报销流程、福利政策等公司制度问答 |
| 个人数据查询 | 个人信息、假期余额、当月考勤异常等即时自助查询 |
| 流程办理 | 补卡申请、请假申请（覆盖 19 种假期类型）、在职与收入证明开具，全程对话式完成 |
三类里只有第三类是真的在办事——前两类答完就结束，第三类要提交到业务系统并生效。这也是它最难的地方。
02 挑战
关键词式问答机器人听不懂「下周三想休个年假」，更代替不了员工完成提交。
01 HR 团队被重复咨询淹没
假期政策、考勤规则、办理流程等问题高频重复，人工答疑响应慢、占用大量精力，员工体验也不好。
02 员工自助门槛高
查假期余额、查考勤异常要登录 EHR 系统层层点击；请假、补卡要在多个页面间跳转填表，一次缺卡补办动辄十几分钟。
03 知识分散、口径不一
制度文档散落在各处，员工问同一个问题可能得到不同答案，缺乏统一、权威、即时的出口。
04 传统机器人能力有限
关键词式问答机器人无法理解口语化表达（比如「下周三想休个年假」），更无法真正代替员工完成业务提交。
05 AI 能力孤岛
即便建成 HR 助理，能力也只服务于单一入口，无法被企业其他智能体复用。
03 方案
「能听懂、查得到、办得成」——语义理解为核心，规则降级兜底。
01 语义理解为核心，规则降级兜底
意图识别覆盖 15 类场景，大模型识别加关键词匹配双层降级保障可用性。请假信息提取支持口语化表达与双时间模式（按天 / 按时段），正则加大模型两层解析。
02 企业数据与业务系统直连
直连企业 EHR 数据库（只读、参数化查询），员工信息、假期余额、考勤异常实时可查；对接 EHR 业务接口，补卡、请假在对话内直接提交生效，支持附件凭证。企业统一身份认证加四级应用权限体系，数据安全边界清晰。
03 知识检索加大模型整理的政策问答
检索企业制度原文后由大模型整理成自然语言答案，附带原文出处，并设三层降级。
04 多轮对话状态机
请假、补卡这类复杂流程支持「解析 → 补全追问 → 校验 → 确认 → 提交」多轮交互，上下文感知，用户中途变更诉求可识别并切换。
05 MCP 开放能力
7 个 HR 工具（员工查询、假期余额、考勤、政策问答、HR 链接、多轮对话、附件上传）以 MCP 协议开放，支持按用户授权，企业内任意智能体可安全调用。
06 可观测与洞察
全链路调用来源追踪加工单生命周期落库，业务数据每晚同步进企业图谱洞察平台，负责人可用自然语言分析使用情况。
04 成果
上线 112 天，704 人开放范围内有 127 人实际用过，办了 157 笔工单。
下面都是生产环境的真实运营数据（截至 2026 年 9 月 8 日）。覆盖人数和实际使用人数一起给——只说前者会让人默认 704 人都在用。
- **704 人**：应用开放范围内的员工数
- **127 人**：实际发起过对话，占开放范围约 18%
- **157 笔**：累计自助办理的 HR 工单（请假 98 / 补卡 59）
条宽按人数比例。18% 是从零开始的增量，不是渗透率目标——这套东西上线 112 天，还在推广期。第三条的条宽只作示意，工单数与人数不是同一量纲。
01 稳定运行
2026 年 5 月 20 日上线，至今稳定运行近 4 个月（112 天），历经 7 个版本持续迭代，无重大故障。
02 员工可以自助办完常见 HR 事务
累计自助办理 HR 工单 157 笔（请假 98、补卡 59），成功提交 94 笔，剔除用户主动取消的 40 笔后，办理成功率约 80%（按总量算是 94÷157，约 60%——两个口径都在文末写明了）。全程无需 HR 人工介入。补卡、请假、考勤、假期余额、个人信息五类个人事务交互合计占比约 71%——员工把过去跨系统多页面的操作变成了「一句话加一次确认」。
03 制度类咨询有了统一出口
累计 80 次制度类咨询由知识检索加大模型整理后应答，附制度原文出处，答案口径统一。这是四个月的累计量，绝对量不大——所以我们说的是「口径统一了、有了权威出口」，不说「显著降低 HR 答疑负担」。
04 多渠道复用已成事实
会话来源中 Web 端 426 个、知识社区 69 个、企业工作台 6 个——HR 能力经 MCP 协议被企业其他智能体真实调用，一次建设、多端复用。这是「能力底座」这个说法唯一的证据。
一次缺卡补办，从跨系统翻十几分钟，变成一句话加一次确认。
157 笔工单、80 次制度咨询，都是四个月的累计量。绝对量不大，我们不称它「显著」。
口径与说明
- 客户身份：客户为一家 B2B SaaS 企业。未获书面授权前不具名，也不写所处细分行业。
- 数据性质：以上均为生产环境真实运营数据，统计截至 2026 年 9 月 8 日；运行时长按产线最早会话 2026-05-20 至最新会话 2026-09-08 计。
- 覆盖人数必须和使用人数一起看：应用开放范围 704 人，其中 127 人实际发起过对话，约 18%。只给 704 会让人默认全员在用，那是误导——这套东西上线 112 天，仍在推广期。
- 办理成功率的两个口径：约 80% = 成功 94 ÷（成功 94 + 失败 23），用户主动取消的 40 笔不计入分母；若按工单总量算则为 94 ÷ 157 ≈ 60%。引用 80% 时必须一并说明剔除了主动取消。
- 我们不展示月度趋势：会话量按月不是持续上升的曲线，而我们没有归因数据。要谈趋势，得先和客户一起把原因搞清楚——拿一段不会解释的曲线出去，只会引出答不上来的追问。
- 不说「显著提升」：80 次制度咨询、157 笔工单是四个月的累计量，绝对量撑不住「显著」二字。可说的是「有了统一权威出口」「员工可以自助办完」。
- 不说「办完所有 HR 事务」：覆盖的是政策咨询、个人数据查询、补卡请假与证明开具这几类高频事务，不是全部。
- 三层降级不是可用性承诺：它是设计手段。我们不承诺「永不中断」。
- 不披露的信息：客户企业名称、内部系统代号、EHR 与身份认证的厂商名、数据库与图谱的节点字段名。
- 关于界面截图：对话内含真实员工姓名、考勤与假期数据，本文未使用截图。需要看界面时，我们用演示数据现场演示。
关于这个案例的常见问题
这个HR数字助理能处理哪些具体事务？
该系统覆盖三类高频诉求：政策咨询（考勤制度、假期规定等）、个人数据查询（个人信息、假期余额等）、流程办理（补卡申请、请假申请等）。其中只有流程办理是真正提交到业务系统并生效的。系统以MCP工具形式开放7个HR能力，可被企业内其他智能体调用。
系统如何理解员工的口语化表达？
系统采用语义理解为核心，规则降级兜底的设计。意图识别覆盖15类场景，使用大模型识别加关键词匹配双层降级保障可用性。请假信息提取支持口语化表达与双时间模式，通过正则加大模型两层解析实现。
系统如何确保查询到的个人数据准确安全？
系统直连企业EHR数据库进行只读、参数化查询，确保数据实时准确。采用企业统一身份认证加四级应用权限体系，数据安全边界清晰。所有数据查询和处理都在授权范围内进行。
系统实际使用效果如何？这些数据可信吗？
系统上线112天，在704人开放范围内有127人实际使用（约18%），累计自助办理HR工单157笔。这些是生产环境真实运营数据（截至2026年9月8日）。办理成功率有两个口径：约80%（剔除用户主动取消）或约60%（按工单总量计算）。
这个系统有哪些做不到的事情？
系统不覆盖所有HR事务，仅处理政策咨询、个人数据查询、补卡请假与证明开具等高频事务。不说'永不中断'，三层降级是设计手段而非可用性承诺。系统不展示月度趋势数据，因为没有归因数据支撑。