销售线索 Agent

本页说明销售线索 Agent 如何用 WebSearch 收集目标公司的公开信号（新闻、融资、招聘、技术栈），在应用侧按带版本的 ICP 标准做确定性评分，并把带来源的线索摘要以 draft 记录写回 CRM。读完本页，你能理解公开信号收集为什么只需要静默运行时凭证、评分为什么放在应用侧而不是模型侧，以及 ICP 画像与历史互动为什么以 CRM 为 canonical source。

适用场景

销售团队需要快速了解目标公司、联系人、近期新闻、技术栈和可能的切入点。这些信号分散在官网、新闻稿和招聘页上，人工逐家研究跟不上线索列表的增长。Agent 的产出是带评分依据的线索摘要和 CRM 草稿记录，触达动作始终由销售人员执行。

典型触发时机：

市场活动带来一批新线索，需要在跟进前完成富集和优先级评分。
目标客户出现购买信号（融资、扩张、相关岗位招聘），需要及时更新切入点。
季度开始时需要按最新 ICP 标准重新为存量线索排序。

工程挑战

信号质量：新闻稿、转述和过期页面噪音大，"该公司在招 DevOps"可能是一年前的旧岗位。进入评分的每条信号都要带来源 URL 和抓取时间，否则评分只是编故事。
评分一致性：ICP 标准会随成交经验演进；不带版本的标准让各批次线索评分不可比，"上季度 80 分"和"本季度 80 分"说的不是一回事。
CRM 数据主权：ICP 画像和历史互动的唯一真相在 CRM。把它们复制进第二套存储会立刻漂移——富集结果只能以 draft 记录写回，正式数据变更由销售确认。

模块组合

模块	角色	说明
GenAuth	核心	运行时以静默委托签发短时效凭证（所有产品调用必需）；本场景默认无需交互式确认，接入登录态或写动作时才升级 interactive，见下方"何时需要交互式确认"。
Web Agent	核心	WebSearch 搜索官网、新闻、招聘页和公开资料，逐条信号保留来源 URL 与抓取时间。
GUMem	不使用	ICP 画像与历史互动以 CRM 为 canonical source，由你的应用直接读取并按版本注入评分；不在 Memory 建第二份真相。

销售线索 Agent 场景架构

何时需要交互式确认

所有产品调用都需要 GenAuth 委托令牌；公开只读场景用静默委托即可。本场景只读取公开可见页面，不需要销售在 Console 交互确认：

公开读取：用 delegateToken 静默签发运行时凭证即可（products: ['webSearch']）。凭证短时效、可随时撤销；每次签发与检索都进入审计链。
登录态或写动作：CRM 的读取与草稿写入由你的应用用自己的 CRM API 凭证直接完成，不经 Qoni 委托。只有当富集需要 Web Agent 登录第三方数据源（例如付费数据库）时，才切换到 mode: 'interactive'，让销售在 Qoni Console 确认授权。本页示例不包含这类目标。

注意：SDK 示例申请的是产品级授权。目标域名清单、抓取频率这类细粒度边界由 GenAuth 的 Agent Profile 或策略层配置强制执行，不由任务 prompt 承担；本页示例未展示该配置。完整语义见 Delegate Token 与缩权。

工作流程

销售线索 Agent 工作流程

销售人员输入目标公司或提交待富集的线索列表。
应用静默签发运行时凭证，并从 CRM 读取当前版本的 ICP 标准和该客户的历史互动。
Web Agent 通过 WebSearch 收集官网、新闻和招聘页上的公开信号，每条保留来源 URL 和抓取时间。
检查点：目标页面出现登录墙或验证码时跳过该来源并记录，升级给销售决定是否人工查看，不尝试绕过。
应用侧解析信号并校验：缺来源 URL 或抓取时间的信号直接丢弃，不参与评分。
应用侧按 ICP 标准做确定性评分，逐条保留评分依据与来源。
检查点：进入评分的每条信号都必须有来源；无来源的推测不参与评分。
应用把评分摘要、切入点和来源清单以 draft 记录写回 CRM，等待销售确认后才成为正式数据。
检查点：CRM 正式记录的变更必须由销售人员确认；Agent 不覆盖人工维护的字段。
销售人员基于摘要决定跟进顺序；如需邮件触达，草稿由销售确认后发送。

示例代码

下面的示例使用官方 Qoni SDK（@qoniai/qoni）接入这个场景：静默委托（仅 webSearch）→ 从 CRM 读取带版本的 ICP 标准 → webSearch.run() 收集公开信号 → 应用侧来源校验与确定性评分 → 以 draft 记录写回 CRM。

import { Qoni } from '@qoniai/qoni'

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

export async function enrichLeads(sellerId: string, targetCompanies: string[]) {
  // 1. 静默委托：只收集公开信号，不涉及站点登录；仅申请 webSearch 产品
  const { data: grant } = await qoni.delegateToken({
    user: { id: sellerId },
    agent: 'sales-lead',
    products: ['webSearch'],
  })

  // 2. 评分前：从 CRM 读取当前版本的 ICP 标准与历史互动（CRM 是 canonical source，不是 Memory）
  const icp = await crm.loadIcpCriteria() // 例如 { version: '2026-Q3', industries: [...], signals: [...] }
  const history = await crm.loadInteractionHistory(targetCompanies)

  // 3. WebSearch 收集官网、新闻和招聘页上的公开信号
  const search = await qoni.webSearch.run({
    token: grant.token,
    prompt: `
      Recent news, funding, hiring and tech signals for these companies:
      ${targetCompanies.join(', ')}.
      Return signals as a JSON array of
      { company, signal, sourceUrl, capturedAt } objects.
      Public pages only — skip anything behind a login wall.
    `,
    maxResultsPerQuery: 5,
  })
  const result = await search.wait()

  // 4. 应用侧校验：缺来源 URL 或抓取时间的信号不参与评分
  const signals = parseSignals(result.output).filter((s) => s.sourceUrl && s.capturedAt)

  // 5. 应用侧确定性评分：对照带版本的 ICP，逐条保留评分依据
  const scored = scoreLeads(signals, icp, history) // 你的评分逻辑，不由模型打分

  // 6. 富集结果以 draft 记录写回 CRM（你的应用直接调用 CRM API），
  //    正式数据变更由销售确认，人工维护的字段不覆盖
  await crm.createDraftRecords(sellerId, scored, { icpVersion: icp.version })

  return {
    scored,
    icpVersion: icp.version,
    audit: { auditId: grant.auditId, permissionBoundary: grant.grantedScopes },
  }
}

输出结构由任务描述约定：这里约定返回 { company, signal, sourceUrl, capturedAt } 数组，应用侧 parseSignals 负责解析与校验，缺少来源或抓取时间的信号被直接丢弃；评分由应用侧的 scoreLeads 对照 ICP 版本完成，不由模型给分。SDK 顶层只返回通用的 RunResult（runId、status、output、artifacts 等）。

数据与记忆边界

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

版本化规则：ICP 标准、行业偏好、评分权重——在 CRM 或配置库中按版本管理，每批评分引用 ICP 版本号，标准调整即版本升级。
业务状态：公开信号、评分结果、切入点和草稿记录——以 draft 记录写回 CRM；ICP 画像与历史互动以 CRM 为 canonical source，不建第二份真相。
审计记录：凭证签发与每次检索构成的行为链——由 GenAuth 维护。
用户 Memory：本场景不使用 GUMem。画像、互动和评分标准都是需要团队共享和版本对账的 CRM 数据，不是某个用户的会话偏好。

失败处理

情况	推荐处理
目标页面出现登录墙或验证码	跳过该来源并记录，升级给销售人员决定是否人工查看，不尝试绕过。
公开信号不足以支撑评分	如实标注证据不足并降低置信度，不硬编评分理由。
信号缺少来源 URL 或抓取时间	应用侧校验直接丢弃该信号，并在摘要中标注丢弃数量。
CRM 草稿与人工维护的字段冲突	草稿保持 draft 状态并标注冲突，由销售人员裁决，Agent 不覆盖人工字段。

生产注意点

不要让 Agent 自动发送外部联系邮件；触达时机与措辞的最终责任在确认草稿的销售人员。CRM 写入始终限定为 draft 记录，正式客户数据的变更必须经销售确认。对目标站点的抓取频率应设置上限；需要长期盯守某个目标客户的官网或招聘页时，参见供应商监控 Agent 的 Track 形态。

下一步

阅读快速开始跑通 Agent 身份与委托的最短路径。
阅读授权与浏览器沙盒了解受控会话的安全边界。
继续查看招聘寻源 Agent 了解相邻场景。

销售线索 Agent ​

适用场景 ​

工程挑战 ​

模块组合 ​

何时需要交互式确认 ​

工作流程 ​

示例代码 ​

数据与记忆边界 ​

失败处理 ​

生产注意点 ​

下一步 ​