Agentic Hiring

字节跳动现有的招聘流程没办法很好地满足字节的招聘诉求，主要是两个问题。

一是效率不够高，体现在并发和流转上。二是质量不够高，主要体现为招聘质量强依赖 TA（招聘专员）个人的业务能力。

为什么会这样，要看招聘这个业务本身。招聘本质上就是判断一个候选人和一个岗位匹不匹配。要把这个判断做好有两个前提：候选人侧，得有足够多、信息足够新的候选人，这是供给问题；岗位侧，需要真正理解这个岗位要什么样的人，这是需求理解问题。

现在这两件事都是 TA 在负责。供给主要靠 TA 从人才库里捞候选人，手上又同时并行很多岗位，这是效率的瓶颈。需求理解靠 TA 自己对业务的把握，所以质量因人而异。

对应地，我们做两件事：

1. 打造 TA 工作台，把供给这类 TA 日常要用的能力做成平台基建。
2. 做推荐效果优化，让 Agent 把岗位需求理解准、推得准。

所以产品形态上，它是一个招聘工作台，主要用户是 TA 和 sourcer，次要用户是用人经理。里面分两块，对应刚才的两件事。

基建能力：把 TA 日常工作里要用的东西做进工作台。

• 供给。 开源：从官网主投、内推、活水、外部这些渠道，把人才库里没有的人加进来。激活：更新库里已有候选人的信息，比如意向度、新的项目和工作经历。
• 日常工作的其他环节。 自己负责岗位的招聘漏斗数据分析、和用人经理把招聘诉求聊清楚、评估通过之后的约面。

Agentic Hiring：TA 或 sourcer 给出岗位需求后，Agent 先澄清需求，再走召回、精评、精排三步，把候选人推给用人经理评估。

我主要做了两件事。

效果优化。 从线上回收的数据里找 badcase，做归因，再针对性优化。我们对 badcase 的定义是：Agent 推了、但用人经理评估没过的候选人。归因下来，需求理解的问题分三类：

1. 需求清晰，但 AI 理解有偏差。 比如 AI 产品岗推出来算法背景的人，属于“做的事不一样”。我建了一套岗位分类，一级是序列，二级是具体做什么，用它给线上岗位和候选人打标用于召回，同时写入精排环节的 system prompt。这个优化灰度 AB 下来，通过率从 21% 到 25%，提升 4 个百分点。
2. 用户没说清楚。 条件描述模糊的，让 Agent 自检后反馈给用户；条件不全的，让 Agent 对照一版完整的条件清单去反问。
3. 用户的标准本身不清楚。 这一类靠长期偏好记忆，从历史行为里把标准抽出来。

体验迭代。 基于用户反馈改产品。比如用户不知道怎么跟 Agent 把需求描述清楚，我们就做了预制 prompt，让他从一个现成的起点开始改，而不是从空白开始写。

怎么判断这些优化有没有用？看两个指标。

• 准不准：用人经理的简历评估通过率。分子是评估通过的人数，分母是 Agent 推出的总人数。对标人类 TA，目标是趋近最优秀的 TA。
• 全不全：同一个岗位，有没有 TA 推过、评估也通过了，但 Agent 没推出来的人。