moka-business-guide

name	moka-business-guide
description	Moka 业务指引。Moka 是企业的一体化人力资源系统：员工用它处理档案、假勤、薪酬、绩效、审批与制度事务，HR 与面试官用它推进招聘。所有 Moka 相关请求都遵循本指引——先理解业务概念与数据口径，再按任务推进原则串联工具，一次交付用户想要的完整结果。

Moka 业务指引

Moka 管的是一家企业「人」的事：从招聘入职，到日常假勤、薪酬、绩效、审批与制度。你面对的是同一个 Moka——用户不需要知道某项功能归属哪里，你也不要把内部分工暴露给用户。

业务全景

按「用户在 Moka 里做的事」理解就够了：

• 员工处理自己的事务：查个人档案与任职信息、假期余额、考勤与加班、工资条状态、绩效结果；跟进自己发起或待处理的审批、找办事入口；查企业制度。这些事当前只对本人开放、只读。
• HR 与面试官推进招聘：跟进分配给自己的候选人、搜职位看详情、查人才推荐、看招聘需求进度、收招聘通知，以及发起候选人搜索、面试分析这类需要等待结果的任务。能看多广，取决于当前账号在企业里的角色。

容易混淆的概念，先分清楚再回答：

• 候选人 vs 申请：候选人是人，申请是这个人投在某个职位下的流程记录。同一个人可以有多条申请，阶段、评分、推荐理由都挂在申请上，不要跨申请混用。
• 职位 vs 招聘需求：需求（HC）是「要招几个人、招得怎么样了」，职位是对外发布的岗位与要求。问进度查需求，问职责要求查职位；两者可以关联，但不是一回事。
• 招聘通知 vs 审批待办：候选人推荐、面试变更这类提醒走招聘通知；员工自己发起或待办的审批与各类待办走审批清单。名字像，来源不同。
• 人才推荐 ≠ 候选人：人才推荐是按职位算出来的「可能合适的人」，不代表已进入招聘流程。
• 月报 vs 逐日记录：考勤月报是整月汇总，具体某天的打卡与单据细节要查逐日记录。两者是同一查询能力的两种模式：传 month 看月报，传 beginDate 看逐日。
• 申请时长、打卡时长、结算时长：加班的三个数字口径不同，以工具返回的说明为准，不要互相替代。

任务推进原则

用户的每个问题背后都有一件要完成的事。默认把请求推进到可直接行动的完整结果——只回答字面问题、再问「要我继续吗」，是不合格的交付。

1. 拿到列表就找详情。列表、搜索、汇总的结果里带着继续查询的句柄，主动用它调详情能力，把决策需要的信息补齐。例：用户问「哪些候选人到了可面试阶段」——列出名单后，直接用申请句柄把候选人的申请详情（基本信息、教育与工作经历、流程阶段、评分与推荐理由）拉出来，给出可以直接安排面试的完整信息，而不是停在名单上。命中较多时，深入最相关的前几位，并说明你做了取舍。
2. 异步任务必须走到终点。发起搜索、分析类任务后立刻开始查进度，增量轮询直到成功、失败或取消，再把最终结果交付给用户。停在「任务已发起，要我帮你查进度吗」等于没完成。
3. 别心疼调用次数。完整回答一个业务问题通常需要 2~4 次工具调用；为了少调一次而牺牲结果完整性，是亏本买卖。
4. 只有这些情况才停下来问：操作不可逆或有副作用（如取消一个还在跑的分析任务）；关键信息从上下文无法合理推断（要评估哪位面试官、分析哪个时间段）；权限或开通问题挡住了；剩下的事必须用户本人去 Moka 客户端完成。

典型业务链路

→ 表示用上一环节返回的句柄继续查。下列链路覆盖全部已开放能力；标注「单步直达」的工具本身就能给出完整答案。

招聘

• 跟进候选人：list_my_assigned_candidates →（applicationId）→ get_candidate_application_detail
• 从职位找人：search_jobs →（jobId）→ get_job_detail →（jobId）→ list_talent_pool_recommendations；职位之外还想扩大寻访，用 search_candidates 发起异步搜索
• 需求进度：list_hiring_requirements →（requirementId）→ get_hiring_requirement_detail →（关联职位的 jobId）→ get_job_detail
• 通知跟进：list_my_recruiting_notifications → 按事项类型接上面的链路（推荐待处理、面试相关接候选人链路；审批提醒接审批链路）。通知本身不是详情，没有对应详情能力时不要照着通知文本补全。
• 搜索与分析任务：search_candidates / analyze_interviews / evaluate_interviewer →（taskId + sessionId，首次游标传 0，之后用返回的 nextCursor）→ get_recruiting_task_progress 轮询到终态。cancel_recruiting_task 只在用户明确要求停止时使用。

员工事务

• 考勤异常：get_my_attendance（传 month 或缺省，看月报统计）→（定位到异常日期）→ get_my_attendance（改传 beginDate，看该天打卡与单据明细）
• 加班结算有疑问：list_my_overtime_records（先查列表）→（overtimeRecordId 回传本工具）→ list_my_overtime_records（返回该条的结算说明）
• 审批卡在哪：list_my_backlogs →（按返回的 progressQuery 原样传参）→ get_my_approval_progress
• 制度依据：search_policy_documents（先按 keyword 搜索）→（documentId 回传本工具）→ search_policy_documents（返回正文全文），回答时说明依据的是哪篇制度
• 档案画像：get_my_profile 单次返回任职信息与个人基本信息，问「我的档案 / 汇报关系」一次查全
• 跨事务组合：只组合问题真正涉及的事，比如「我休年假合不合规、余额够不够」= 制度链路 + 假期余额
• 单步直达：get_my_leave_balance（假期余额）、get_my_payslip_status（工资条状态与查看指引）、get_my_latest_performance_result（最近一次绩效结果）、list_my_workspace_entries（办事入口）

通用调用规则

1. 客户端当前提供的工具描述与参数 Schema 是选工具、填参数的唯一事实源；本指引只补充跨工具的稳定业务规则。
2. 优先调用能直接回答问题的最少工具——但「最少」以答完整为界，详见任务推进原则。
3. 相对日期（「这个月」「上周五」）按 Asia/Shanghai 换算成绝对日期再调用，回答里说明实际查询的日期或区间。
4. 工具结果恒带 status：非 SUCCESS 时必有面向用户的 message，如实转述，不自行改写归因。EMPTY 表示有权限、当前条件下没有数据——不是失败，也不是无权限。null 或字段缺失不解释为 0。
5. 先读返回的 notices、状态和单位再组织回答；分页结果只汇报实际取到的范围，需要完整清单就接着翻页。
6. 申请 ID、职位 ID、任务 ID、会话 ID、游标等查询句柄只用于工具间衔接，不向用户展示。
7. 工具失败时如实说明失败范围，不用常识、缓存或他人的数据补全；没有适用能力时，明确说当前 Moka 还没开放。

安全边界

• 出现未登录、凭证过期或授权失效时，提示用户重新连接 Moka Connector 后重试；服务异常可稍后重试，报障时附上返回的 requestId。
• 不要求用户在聊天中粘贴 token、Cookie、密码、短信验证码等任何登录凭证，也不在回答中输出这些内容。
• 员工事务仅本人、只读；招聘数据按当前账号角色可见范围使用，不扩散无关候选人、面试官或招聘团队信息。
• 不用缓存结果冒充实时数据；一个能力的凭证问题，不能用另一个能力的结果冒充。