题目重点：把招聘业务目标分解为权限受控的工具、可追溯检索、候选排序和邮件草稿审批流程。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版助手可检索有权限的职位和候选资料、生成草稿，但发送邮件或改招聘状态前必须经 recruiter 明确确认。
- 工具调用权限按用户、租户和业务动作范围检查；RAG 文档视为不可信数据，不能让检索文本替代系统指令或调用权限。
解题路线
- 先定义任务和指标：找合适候选人、回答职位/候选人问题、辅助写沟通稿；分别测证据正确率、任务完成、招聘人员节省时间和候选人负反馈。
- Tool registry 为每个工具声明输入 schema、权限、成本、超时和副作用等级。planner 只能从当前用户获准的工具集合选择；调用前校验参数，调用后做结构化错误处理和审计。
- RAG 以权限过滤后的职位/候选资料召回证据，返回文档 ID、版本与片段；ranker 结合职位硬条件与候选偏好，生成解释时仅引用检索证据。缺证据要回答未知，不编造履历。
- 邮件草稿单独作为可编辑 artifact，页面显示引用、待核事实、发送对象与频控状态；human approval 应绑定草稿版本和最终收件人，审批后若内容改变需重新确认。
- 是否微调 ranker/LLM 取决于足够且合法的训练数据；先以规则/检索 baseline 对照，离线标注、shadow 测试后再逐步放量。观测工具失败、错误检索、幻觉、越权尝试和人类修改率。
手动走一遍
招聘人员问‘找熟悉流式指标平台且愿意在纽约工作的工程师’，助手调用职位读取与候选检索工具，按授权范围取证、排序并给出每人的证据；草拟首封邮件时引用真实职位和候选公开经历。招聘人员修改、确认收件人与文本后，受控发送工具才执行。
规模与取舍
一次请求成本由 T 次工具调用、R 个检索候选和 M 个重排候选组成；串行延迟累加，独立只读调用可并行但最终结果要按版本合并。存储随索引文档、审计事件与草稿版本增长；题目无具体 QPS/模型 token 预算，不填固定实例数。
易错点与追问
容易失分的边界
- 把 RAG 检索结果当可执行指令。
- 工具注册只写名字，不做参数 schema/权限和副作用声明。
- LLM 生成邮件后直接发送，human-in-loop 流于形式。
- 基于模型自己生成的解释评估 ranker，没有人工标注或业务结果。
- 声称 fine-tuning 必需，未先和简单检索/规则 baseline 比。
继续深挖
- 搜索结果含恶意 prompt 注入文本怎么办？
- 审批后职位内容变化，草稿是否仍能发送？
- 工具调用超时或返回部分候选时如何告知用户？
- 如何区分模型改写邮件带来的效果与候选排序改动？
