招聘寻源 Agent

本页说明招聘寻源 Agent 如何按经审核的岗位能力要求检索候选人公开资料，生成每条匹配理由都带来源的寻源清单。读完本页，你能理解这个场景为什么以 Web Agent 为核心、岗位规则为什么放在 ATS 或规则库而不是 Memory，以及候选人评估中偏见风险的工程处理方式。

适用场景

招聘团队需要根据职位要求查找公开候选人资料并生成候选人摘要。公开资料分散在个人主页、技术社区和公开履历页上，人工逐个检索既慢又难保持标准一致；直接把招聘系统账号交给脚本，则候选人数据的访问和留存完全失控。Agent 只处理公开可见的信息，产出是待招聘人员复核的寻源清单。

典型触发时机：

• 新职位开放，需要在几天内产出首批候选人寻源清单。
• 职位要求调整后，需要按新标准重新筛选已有候选池。
• 稀缺岗位长期在招，需要定期补充新出现的公开候选人线索。

工程挑战

• 公开信息的采集边界：候选人资料散在个人主页、社区和作品集上，哪些真正公开、哪些要登录才可见，这条边界必须硬性执行——绕过登录墙采集候选人数据是合规事故，不是技术优化。
• 筛选口径漂移与偏见固化：寻源标准如果由脚本各自理解 JD，跨批次结果无法对齐；而用"历史上哪类人进了面试"来校准标准，会把过去的偏见固化成排序信号。口径必须来自经审核、版本化的岗位能力要求，不来自历史推进结果。
• 证据与可复核性：每条匹配理由必须对应具体公开来源和抓取时间，招聘人员才能复核；无来源的"感觉匹配"既不可审计也不可辩护。

模块组合

模块	角色	说明
GenAuth	核心	运行时以静默委托签发短时效凭证（所有产品调用必需）：短时效、可撤销、带审计记录；本场景默认无需交互式确认，需要登录 ATS 或招聘系统时才升级为交互式委托。
Web Agent	核心	通过 WebSearch 检索公开候选人资料，逐条保留来源 URL 与抓取时间；登录才可见的页面跳过并记录。
GUMem	不使用	岗位能力要求是经审核、版本化的招聘规则，放在 ATS 或规则库按版本注入；历史面试推进结果不得作为候选人排序信号，因此不存在需要跨会话沉淀的"筛选偏好记忆"。

何时需要交互式确认

所有产品调用都必须持有 GenAuth 签发的委托令牌——可选的不是委托本身，而是交互式确认。公开候选人资料检索不需要用户逐次确认授权：静默签发的运行时凭证已经提供这个场景需要的约束——凭证短时效、可随时撤销、每次检索都带 grantId 与 auditId 可归因到具体职位和任务。

需要升级为 mode: 'interactive' 交互式委托、让招聘人员在 Qoni Console 明确确认的情况：

• 登录态访问：任务需要进入 ATS、招聘系统或其他登录后才可见的候选人数据——本页示例不涉及。
• 写动作：私信候选人、修改候选池——本场景默认排除，建联始终由招聘人员确认草稿后由人执行。

注意：本页示例申请的是产品级委托（products: ['webSearch']）。可检索的站点清单这类细粒度边界由 GenAuth 的 Agent Profile 或策略层配置强制执行，不由任务 prompt 承担。完整语义见 Delegate Token 与缩权。

工作流程

1. 招聘人员选择职位并确认寻源范围。

2. 应用从 ATS 或规则库读取经审核的岗位能力要求（带版本号），并获取静默运行时凭证。

3. Web Agent 检索公开候选人资料，逐条抽取经历、技能和公开作品，保留来源 URL 和抓取时间。

   检查点：只采集公开可见信息；遇到需要登录才可见的候选人页面，跳过并记录，不尝试绕过。

4. Agent 按岗位能力要求生成候选人摘要和匹配理由，每条理由对应具体来源并引用规则版本号。

   检查点：摘要中不得出现敏感属性（年龄、婚育、族裔等）或与岗位能力无关的信号；发现即剔除并记录。历史面试推进结果不参与排序。

5. 招聘人员复核清单，标注推进或排除；复核结果记录到 ATS，用于岗位规则的下一次人工修订评审。

6. 需要建联时，Agent 生成私信草稿交招聘人员确认后由人发送，不自动触达候选人。

示例代码

下面的示例使用官方 Qoni SDK（@qoniai/qoni）把这个场景接到你的服务端：静默运行时凭证 → 从 ATS/规则库读取岗位能力要求 → 一次 webSearch.run() 完成公开资料检索与摘要 → 应用侧校验输出。

import { Qoni } from '@qoniai/qoni'

const qoni = new Qoni({
  accessKey: process.env.QONI_ACCESS_KEY!,
  secretKey: process.env.QONI_SECRET_KEY!,
})

export async function sourceCandidates(recruiterId: string, roleId: string) {
  // 1. 静默运行时凭证：只检索公开资料，不涉及站点登录
  const { data: grant } = await qoni.delegateToken({
    user: { id: recruiterId },
    agent: 'recruiting-sourcing',
    products: ['webSearch'],
  })

  // 2. 任务前：从 ATS / 规则库读取经审核的岗位能力要求（不是 Memory）
  const criteria = await loadApprovedRoleCriteria(roleId)
  // 例如 { version: '2026-08', mustHave: [...], niceToHave: [...] }

  // 3. 一次 WebSearch 完成公开资料检索与摘要
  const search = await qoni.webSearch.run({
    token: grant.token,
    prompt: `
      Source candidates for role ${roleId} from publicly visible
      profiles, portfolios and talks only.
      Match strictly against the approved role criteria below; tie every
      match reason to a source URL and capture time, and cite criteria
      version ${criteria.version}.
      Skip and record sign-in-only pages; never bypass them.
      Exclude sensitive attributes (age, family status, ethnicity, etc.)
      and any signal unrelated to the role criteria. Do not use past
      interview outcomes as a ranking signal. Do not contact anyone.

      Approved role criteria (version ${criteria.version}):
      ${JSON.stringify(criteria)}
    `,
    maxResultsPerQuery: 8,
  })
  const result = await search.wait()

  // 4. 应用侧校验输出契约：无来源或规则版本不符的条目丢弃
  const candidates = parseCandidates(result.output).filter(
    (c) => c.sourceUrl && c.criteriaVersion === criteria.version,
  )

  // 5. 敏感属性显式过滤，评分与清单只使用 screened
  const screened = dropSensitiveAttributes(candidates) // 剔除性别/年龄/民族等敏感与代理字段，并记录剔除计数

  return {
    sourcingList: screened,
    criteriaVersion: criteria.version,
    audit: { auditId: grant.auditId, permissionBoundary: grant.grantedScopes },
  }
}

寻源清单的输出结构由任务描述约定：这里约定逐人返回带 sourceUrl 与 criteriaVersion 的条目，应用侧 parseCandidates 负责解析与校验，缺少来源或规则版本的条目直接丢弃；dropSensitiveAttributes 再显式剔除敏感与代理字段并记录剔除计数，后续评分只使用过滤后的 screened。SDK 顶层只返回通用的 RunResult（runId、status、output、artifacts 等）。

数据与记忆边界

这个场景涉及四类数据，没有一类属于 GUMem：

• 招聘规则：岗位能力要求——仅使用经审核的版本，放在 ATS 或规则库按版本管理，每条匹配理由引用规则版本号。历史面试推进结果不得作为候选人排序信号，也不得反向写成"筛选偏好"。
• 业务状态：寻源清单、候选人摘要和复核标注——归档到 ATS，留存和使用符合当地招聘与个人数据法规。
• 审计记录：grantId 与 auditId 构成的委托与行为链——由 GenAuth 维护，检索行为可归因到具体职位和任务。
• 用户 Memory：本场景不使用。候选人评估不应依赖跨会话沉淀的个人化筛选记忆——那正是偏见固化的入口；口径变更只应通过规则库的人工修订评审完成。

失败处理

情况	推荐处理
候选人页面出现登录墙或验证码	跳过该来源并记录，升级给招聘人员决定是否人工查看。
公开资料不足以支撑匹配判断	如实标注证据不足，不硬猜候选人背景。
输出条目缺少来源或规则版本号	应用侧校验直接丢弃该条目，并在清单中标注丢弃数量。
摘要中出现敏感属性或无关信号	剔除该字段并记录事件，供偏差检测复盘。

生产注意点

候选人排序只使用经审核的岗位能力要求；历史面试推进结果不得作为候选人排序信号。敏感属性（年龄、婚育、族裔等）不进入任何自动评分，并需要定期检测代理变量（毕业院校、地域、姓名风格等可能间接代理受保护属性的信号）与群体层面的筛选偏差，检测结果纳入岗位规则的修订评审。候选人数据只用于本职位的寻源目的，留存和使用符合当地招聘与个人数据法规。Agent 不自动私信候选人，建联触达始终由招聘人员确认草稿后由人执行。

下一步

• 阅读 快速开始 跑通 Agent 身份与委托的最短路径。
• 阅读 WebSearch 了解公开资料检索的工作方式。
• 继续查看 销售线索 Agent 了解相邻场景。