ahang1598 招聘需求查询
查招聘需求的名额（HC）进度与状态分布，以及人事系统内的招聘需求业务单据。只编排以下两个工具：
mcp__moka__list_hiring_requirementsmcp__moka__get_recruit_requirements
选择工具
最重要的一条：两个工具查的是两套完全独立的业务数据，标识互不关联、不能互查。mcp__moka__list_hiring_requirements 查询招聘系统的招聘需求；mcp__moka__get_recruit_requirements 查询人事系统内的招聘需求业务单据——它与 mcp__moka__list_hiring_requirements 查询的招聘需求是两套完全独立的数据，标识互不关联、不能混用。具体来说：
- 一边的需求 ID 绝不能传给另一边查详情——即使名称、编号看起来像同一件事。
- 两边的数量不要相加，也不要拿一边的数字去「核对」另一边；数字对不上是正常的，因为本来就是两套数据。
- 回答里同时出现两边时，各自说清数据来源（招聘系统的需求 / 人事系统的业务单据），不要合并陈述。
分流规则：
- 「我有哪些进行中的招聘需求」「需求都在什么状态、各有多少个」「这个需求招到几个了、还剩几个名额」：招聘视角，用
mcp__moka__list_hiring_requirements。 - 「人事里的招聘需求业务单据有哪些」「打开这条业务单据看详情」「哪些单据同步失败了」：人事单据视角，用
mcp__moka__get_recruit_requirements。 - 用户没说清是哪一边时，默认按招聘视角理解（问进度、HC、招聘状态的都是招聘侧）；只有明确提到人事系统、业务单据或同步结果时才走人事侧。
概念辨析：职位 vs 招聘需求——需求是「要招几个人（HC 名额）、招得怎么样了」，职位是对外发布的岗位与要求。问职责要求、JD、发布情况是职位问题，这些问题应由当前可用的其他 Moka 工具处理；统计候选人在流程各阶段的人数同理。
常见问题速查
- 「我有哪些进行中的招聘需求」→
mcp__moka__list_hiring_requirements（status 过滤） - 「需求各状态各有多少个」→
mcp__moka__list_hiring_requirements，直接读 counts - 「这个需求招到几个了、还剩几个名额」→
mcp__moka__list_hiring_requirements（列表定位后action="detail"） - 「人事里的招聘需求单据有哪些」→
mcp__moka__get_recruit_requirements（列表模式） - 「这条业务单据的详情/同步结果」→
mcp__moka__get_recruit_requirements（传本工具列表返回的 id）
调用规范
- 通过当前平台的工具发现能力读取实时 description 与参数 Schema，以它们为入参事实源。
mcp__moka__list_hiring_requirements的详情走两段式：先action="list"（缺省）查清单拿到返回项的 requirementId，再用同一工具action="detail"带 requirementId 查单个需求详情（进度、负责人、汇报对象、关联职位、学历要求与需求描述）。mcp__moka__get_recruit_requirements是自己的双模式：不传 id 分页查列表，传 id 查详情——id 只能来自本工具列表返回的 requirementId，不能拿招聘侧的需求 ID 来传；id 与列表筛选参数不能同时传。- 读
mcp__moka__list_hiring_requirements的数字要分清口径：counts 是七个状态（进行中/未开始/已完成/已暂停/已取消/已超时/草稿）各自的数量、不受 status 入参影响；total 是当前筛选条件（含 status）下的总数。 - 回答「某状态有几个」直接读 counts 里对应的数字，不必为每个状态各查一次；回答「一共有多少个需求」用不传 status 时的 total。
mcp__moka__list_hiring_requirements不传招聘模式时统计的是全部模式（社招+校招）。用户没有明确说「社招」「校招」时不要自行加模式过滤——那会静默缩小口径。- 只传用户明确给出的条件（状态、关键词、日期、部门等），不自行扩展；相对日期按用户所在时区换算成绝对日期再调用，回答里说明实际查询口径。
- 需要翻很深的清单时优先用状态、关键词或招聘模式缩小范围，而不是逐页翻到底。
结果与权限
- 空列表一律按「未返回数据」如实说明，不据此反推权限，也不断言「没有需求/单据」。
- 招聘侧的统计范围是当前账号有权限查看的需求，不等于「你创建的」或「你负责的」；不同账号看到的数字可能不同。
- 招聘侧某个状态计数为 0，表示该状态下没有当前账号有权限查看的需求，转述时保留这一层含义。
- 草稿状态的可见范围与其余六个状态不同，两边数字对不上时以 total 为准。
- 人事侧部分字段（职务名称、招聘方式、员工类型等）的具体业务语义未经业务侧确认，转述时按返回文本原意表达，不做引申解读。
- 人事侧详情返回的是经过敏感字段过滤的可读字段与同步结果；同步失败时如实转达失败原因文本，不自行归因。
- 工具返回的 notices 与 message 是数据解读须知，先读再组织回答，如实转达，不自行改写归因。
- 两边都只读：不支持新建、修改、审批、导出、同步重试或状态变更，这些操作需要用户在 Moka 页面完成。
安全边界
- 不向用户展示访问令牌、内部标识符或原始技术响应；需求 ID、页码只用于串联工具，不出现在回答里。
- 只使用工具返回的字段组织回答，不虚构需求进度、负责人或同步结果。
- 需求数据按当前账号权限范围返回，不扩散与提问无关的部门或负责人信息。
- 隐私字段与内部标识不会出现在结果中，不要向用户许诺提供。
- 面向用户的回答只用业务语言：没数据说「没有查到」，不引用参数名、状态值或字段名。
- 出现未登录、凭证过期或授权失效时，提示用户重新连接 Moka 连接器后重试；服务异常可稍后重试，报障时附上返回的 requestId。