请假与补班智能体
我们设计、构建并部署一个 AI 智能体，在员工本来就在的地方接收请假与病假单（MC）申请——WhatsApp、聊天或你的 HR 应用——对照政策、额度与余额逐一核查、验证病假单、转交正确的审批人，并标出谁有资格且有空来补这个班次，让主管在几秒内完成审批，而不是去翻表格。
一览
请假事务不再吞掉 HR 的一周，而且——最花钱的部分——获批的缺勤不再让某个班次悄悄缺人：智能体在缺口酿成服务事故之前就给出合格的顶班人选。
多渠道接收、病假单文档核查（视觉）、政策/额度引擎，以及跨 HRIS 与排班系统、按技能、可用性与劳动规则做的补班匹配——但仍由人审批，从而把自主性控制住。
见效后会有什么改变
每份申请耗时
人工处理一份申请
约 10–20 分钟（含找顶班）
使用智能体
约 30–60 秒审批
节省的时间
每份申请约省 10–18 分钟——在高病假/请假量下每月数百小时——而更大的收益是覆盖：智能体帮助及时补上的每一个班次，都是一次避免的服务事故或加班救火。
为估算；实际时间与覆盖取决于申请量、你的排班数据结构化程度，以及有多少岗位需要持证或有技能的顶班。
阶段 1 · 界定
业务问题
在轮班制的业务里，员工通过任何顺手的渠道报病假或请假——给主管发条 WhatsApp、一张表单、一张诊所病假单的照片。HR 随后把每一份录入系统、读病假单，并人工核查额度、余额、通知期与封锁日期。接着是更难的部分：主管得弄清谁真能补这个班——谁受过收银或病房的培训、谁有空、谁还没超工时——通常是在表格或 WhatsApp 群里。在大型零售商或医院，那是每天数百份申请。它缓慢、执行不一致，而当一张当天病假单到来时，顶班往往来不及找到，于是这个班次就只能缺人运转。
阶段 2 · 梳理
当前的人工流程
- 01员工通过他们使用的任意渠道提交请假或病假单
- 02HR 把它录入 HR 系统并读取病假单
- 03人工核查额度、余额、通知期与封锁日期
- 04转交给正确的主管审批
- 05主管弄清谁能顶班——技能、可用性、加班
- 06更新排班并向各方确认
问题所在: 两个缓慢环节相撞——政策与余额核查，以及寻找合格顶班的侦探活——而当当天病假单到来时，顶班往往来不及找到，于是班次缺人运转。
阶段 3 · 设计
智能体化流程
我们以 routing（路由）方式构建：每份申请先按请假类型分类——年假、病假、紧急、无薪——因为各自有不同的政策路径、审批人与紧急程度。随后走一条简短链路：对照额度与余额核查、验证病假单、给出合格且有空的顶班建议、并组装审批摘要——在审批处以及任何规则确实无法满足时停下交由人处理。
当首轮无法满足某条规则时，复核余额与政策、并以扩大的人选池重跑顶班搜索，而不是批准一份违反额度或让班次缺人的申请。
看一个案件在智能体中逐步流转——它负责读取与比对；最终决定仍由人来做。
实际效果
员工消息
智能体准备了什么
- 识别：1 天病假，今天，员工 Aina（12 号店，2–10 点班次）
- 病假单已验证：从照片读出诊所名称、日期与 1 天时长；符合政策
- 余额无碍：今年 14 天病假已用 3 天，病假免通知
- 找到顶班：Faiz 与 Mei-Ling 均受过收银培训且今天有空；Faiz 已在 12 号店
主管一键审批 · 审批时更新排班与薪酬 · 每份申请 AI 成本约 RM 0.10–0.25。
逐步流程
- 1
在员工所在之处接收申请
智能体在你员工真正使用的渠道上接收申请——一条 WhatsApp 消息、你的 HR 应用或聊天——读取它（包括马来语/英语/中文混合与语音转写），并回确认它所理解的：谁、哪种请假、哪些日期、哪个班次。
- 2
对请假类型与紧急程度分类
它按类型路由申请——年假、病假、当天紧急，或无薪——因为各自有不同的政策路径、审批人与紧急程度。一次当天病假会直接跳到顶班搜索；一次计划中的年假则走通知期与封锁日期核查。
- 3
核查政策、余额与病假单
对照员工的实时额度，它核查余额、通知期与封锁日期，对病假则以视觉读取证明——诊所、日期、时长——对照政策验证，并标记任何对不上的地方（倒填日期、篡改、不一致）。
- 4
给出合格且有空的顶班建议
对受影响的班次，它在实时排班中搜索为该岗位受训/持证、有空、且在工时与加班上限内的员工——给出一小组合规的顶班选项，按契合度排序（同门店、轮换公平），或在无人合格时如实说明。
- 5
组装审批摘要
它交给主管一份可直接操作的摘要：申请、政策结果、已验证的病假单字段与顶班选项——于是批准请假并指派顶班只需一键，而非一场表格作业。
- 6
交给人处理
主管审批或驳回并确认顶班。正是这次审批写入请假记录与排班变更——没有任何内容被自动预订，任何违反政策或缺少顶班之处都会被呈现，绝不静默放行。
阶段 4 · 构建
我们如何用 Claude 构建
它读取病假单与申请，但始终只是提议——是主管的审批把请假写入 HR 系统并指派顶班。它基于你的实时排班与额度数据工作，因此顶班建议是此刻真正合格且已排到空档的人，而不是陈旧名单上的名字，并且它每次都执行同样的政策——同样的封锁日期、通知规则与余额核查。病假单被视为敏感：只使用政策所需的字段（有效性、日期、时长），而非诊断，且它呈现的每个决定都能追溯到其来源的规则与排班记录。
集成对接
- HRIS / 请假系统（额度、余额、请假记录）
- 排班 / 劳动力管理（班次、技能、可用性）
- 员工使用的渠道——WhatsApp、聊天或你的 HR 应用
底层实现
- 模式：基于 Claude Agent SDK 的路由前端按请假类型与紧急程度对每份申请分类，随后简短的分类型链路执行核查 → 验证病假单 → 给出顶班 → 摘要；每个工具通过进程内 MCP 服务器提供。
- 上下文：员工的实时额度与余额、该请假类型的政策规则，以及实时排班（谁有技能且已排空档）按申请载入，因此核查与顶班建议反映当前状态，而非隔夜导出。
- 工具：只读的额度/余额、政策与排班查询；面向病假单的视觉提取器；顶班匹配求解器（技能 + 可用性 + 劳动规则约束）；以及一个仅起草请假记录与拟议排班变更、供主管确认的写入工具——没有任何工具能自行预订请假或修改排班。
- 防护机制与门槛：没有任何内容被自主批准——智能体提议，而主管的审批是写入请假与指派顶班的门槛；任何违反规则的（余额不足、通知期、无合格顶班）都作为标记呈现，绝不静默放行。
- 病假单与敏感数据处理（PDPA/PDPC）：病假单被视为敏感——只提取并保留政策所需字段（有效性、日期、时长），诊断与自由文本不予存储，访问采用最小权限并留痕。
- 不可信输入：申请文本与病假单图片被视为不可信（伪造的引用或精心构造的消息无法推动审批通过），真伪标记——诊所不符、日期被改——转交人处理。
- 顶班匹配约束：求解器尊重技能与资质、可用性、最高工时与加班规则以及轮换公平，因此建议是合规且合理的，而非随便一个有空的人。
- 可观测性与审计：每次分类、政策核查、所用病假单字段与顶班建议都会留痕并可追溯到规则与排班记录——一条用于 HR 及劳动法/PDPA 审视的审计轨迹。
- 评估框架：一组真实历史申请的黄金集——干净、边缘（倒填病假单、零余额、封锁日期、无顶班可用）与对抗（伪造病假单）——配合确定性政策检查，并对模糊判断采用 LLM 作为评审，每次改动在上线前都做回归测试。
阶段 5 · 架构
单一模型还是多智能体？
一份申请共享同一上下文——员工的额度、政策与排班——因此由一个完善配置的单一模型来做判断，用更便宜的 Haiku 处理大量简单检查，把 Opus 仅留给顶班稀缺或政策冲突的情形。可靠、每份成本更低、也更易审计。
我们把多智能体设计（约 15 倍 token）留给真正并行、广度优先的工作——而非一份请假申请及其顶班搜索。
哪个模型做什么
跨渠道与语言理解申请
可靠读取马来语/英语/中文混合的 WhatsApp 消息，抽取请假类型、日期与意图。
读取并验证病假单（视觉）
对拍照的诊所证明具备可靠视觉——诊所、日期、时长——即便是不佳的手机照片。
高频分类与余额检查
对大量简单的请假类型与额度是/否检查最便宜、最快。
处理顶班稀缺或政策冲突
仅在顶班稀缺或政策冲突时调用——占申请的一小部分。
成本估算
AI 用量——每份申请
消息 + 病假单视觉 + 政策核查 + 顶班搜索 + 摘要，按 Claude Sonnet/Haiku 的 token 费率
约 RM 0.10–0.25
AI 用量——每月 3,000 份申请
对计划中（非当天）的请假用 Batch API 在非高峰处理可更低
约 RM 300–750 / 月
构建（一次性）
接入你的 HRIS、排班系统与员工渠道约需数周；简短的需求梳理后我们给出固定报价
按集成范围报价
持续运营
相比一个缺人的班次或一次加班救火，成本很小
监控 + 支持
仅为估算，按约 1 美元兑 4.70 令吉以令吉显示；每 token 费率以 Anthropic 公布的定价为准（请核对最新数字）。实际 AI 用量取决于申请量、有多少是病假（需要视觉），以及顶班有多难找。你可以用我们的 Claude 成本计算器把同样的数字换算成 SGD 或你的货币。
阶段 6 · 评估
我们如何衡量成效
- 先做确定性检查——额度、余额、通知期、封锁日期、病假单有效性
- 自我验证——智能体在交接前复核政策并以更大人选池重跑顶班，宁可标记也不强行批准
- 业务 KPI——每份申请的 HR 耗时、及时补上的班次比例、审批周转、政策例外率
我们采用 Agent GPA 框架——Goal、Plan、Action，当前衡量智能体可靠性的标准——并结合人工基线来评估。 (reference)
设定基线
我们先在样本上测量你当前的流程——每份申请耗时、两名 HR 员工执行同一政策的一致程度，以及目前有多大比例的缺勤能及时补上。这个人工基线是衡量每个智能体指标的基准，因此提升是可证明的，而非假设。
我们测试什么——Goal · Plan · Action
建议（对比资深 HR / 值班经理）
在留出的历史申请上，其请假决定与顶班建议与专家一致
必需检查全部执行
每一项政策检查都执行——额度、余额、通知、封锁、病假单——不遗漏
不提议违反政策的批准
它绝不建议批准一份违反额度、通知或劳动规则的申请
病假单字段提取准确率
是否正确读取证明的诊所、日期与时长？
顶班建议有效性
所建议员工确实合格、有空且在工时/加班规则之内
覆盖率
它为缺勤找到有效顶班的比例，对照人工基线衡量
无敏感数据泄露
只保留政策所需的病假单字段；诊断与自由文本从不存储
上线关卡
智能体不会自行写入请假或排班变更——由主管审批。它仅在历史申请黄金集（含伪造病假单、零余额与无顶班案例）上超过人工基线并达到这些 GPA 目标后，才按门店逐一上线，且先以影子模式运行。每次改动在上线前都要针对同一数据集做回归测试。
阶段 7 · 交付
我们如何交付
我们先在你真实的历史请假与病假单申请上做概念验证——包括杂乱的 WhatsApp 申请与边缘案例——以影子模式运行，让你在任何内容被预订前先看到它的决定与顶班建议。聚焦单一门店的落地只需数周。
常见问题
- 智能体会自行批准请假或修改排班吗？
- 不会。它负责读取、核查与提议——由主管审批，而这次审批才写入请假记录并指派顶班。它没有能力自行预订请假或修改排班；人在环路中是设计本身，而非事后补丁。
- 它如何处理病假单与隐私？
- 它把病假单视为敏感：只提取政策所需字段——有效性、日期、时长——不存储诊断或自由文本，符合 PDPA/PDPC 且采用最小权限。看起来可疑的证明（诊所不符、日期被改）会被标记给人，而非自动接受。请将此视为你 HR 与合规团队的起点，而非法律意见。
- 它如何寻找顶班？
- 它按技能与资质、可用性、最高工时与加班规则以及轮换公平，把缺口与你的实时排班匹配——给出几个按契合度排序的合规选项。若无人合格，它会如实说明，而不是建议一个不合适的人。
- 它能配合 WhatsApp 与混合语言吗？
- 可以。它在员工本来就在的地方接收申请，理解马来语、英语与中文混合（以及语音消息），并在采取任何行动前始终确认它所理解的——谁、什么、哪些日期与班次。
- 它能跨马来西亚和新加坡使用吗？
- 可以。它按各实体的请假政策与劳动规则配置——马来西亚与新加坡不同——并执行各门店的规则集。同一个智能体只要配上正确的政策集，就能同时服务两地。
- 部署需要多长时间？
- 针对单一门店或业务单元的概念验证通常只需数周，先以影子模式运行；全面落地需要更长时间，主要是 HRIS 与排班集成以及让主管适应，而不是 AI 本身。
案例基于真实的匿名合作，细节已作概括处理。Anchor Sprint 是 Anthropic Claude 合作伙伴网络成员——部署与落地伙伴，而非分销商。以上为一般信息，非法律或合规意见。