---
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、密码、短信验证码等任何登录凭证，也不在回答中输出这些内容。
- 员工事务仅本人、只读；招聘数据按当前账号角色可见范围使用，不扩散无关候选人、面试官或招聘团队信息。
- 不用缓存结果冒充实时数据；一个能力的凭证问题，不能用另一个能力的结果冒充。