供应商监控 Agent

本页说明供应商监控 Agent 如何用 Track 对供应商价格页、SLA 与条款页和状态页建立长期监控：首次运行建立基线，之后按 schedule 反复比对，命中变化时带 diff 与来源通知负责人。读完本页，你能理解为什么这个场景的主轴是长期 monitor 而不是记忆、基线和逐轮 diff 应该存在哪里，以及公开页监控为什么只需要静默签发的运行时凭证。

适用场景

采购、法务或安全团队需要持续关注供应商价格、服务条款、安全公告和产品变化。供应商很少主动通知这些更新：价格页悄悄调整、SLA 条款在改版中变更、状态页记录了未邮件通报的事故。人工定期巡检既占时间，又难以证明"上次检查时条款是什么样"。

典型触发时机：

合同续签前，需要确认供应商 SLA 和服务条款相对签约时有哪些变化。
供应商状态页出现事故记录，需要评估对自身业务的影响。
年度采购评审需要各供应商价格页的变化时间线作为谈判依据。

工程挑战

变化检测的信噪比：供应商页面经常改版，视觉与结构变化远多于实质变化。把"页面改版"误报成"条款变化"，几轮之后负责人就不再看告警。
基线管理：判断"变没变"的前提是"上次是什么样"。基线需要带版本、可回放、可在改版后人工确认重建——散落在脚本本地的快照支撑不了续约谈判时的取证。
告警可信度：一条"SLA 从 99.9% 降到 99.5%"的告警必须能指回具体页面、具体段落 diff 和抓取时间；无来源的变化结论没有处置价值。

模块组合

模块	角色	说明
GenAuth	核心	运行时以静默委托签发短时效凭证（所有产品调用必需）；本场景默认无需交互式确认，接入登录态或写动作时才升级 interactive，见下方"何时需要交互式确认"。
Web Agent	核心	Track 维护长期 monitor：首次运行建立基线，按 schedule 反复取数比对，命中变化通过回调通知；一次性核查可回退到单轮巡检。
GUMem	不使用	页面基线和逐轮 diff 是业务状态，不是用户记忆——放在 Track 的 run 快照和你的监控基线存储里按版本管理，Memory 不参与本场景。

供应商监控 Agent 场景架构

何时需要交互式确认

所有产品调用都需要 GenAuth 委托令牌；公开只读场景用静默委托即可。本场景默认监控公开页面（价格页、公开条款页、状态页），不需要用户在 Console 交互确认：

公开读取：用 delegateToken 静默签发运行时凭证即可。凭证短时效、可随时撤销，撤销后 monitor 的下一次取数立即失败；每次签发与取数都进入审计链。
登录态或写动作：只有当监控目标是供应商登录后台（例如合同价页、账单页），或需要在站点上执行任何写动作时，才切换到 mode: 'interactive'，让负责人在 Qoni Console 确认授权。本页示例不包含这类目标。

注意：SDK 示例申请的是产品级授权。供应商域名清单、页面范围这类细粒度边界由 GenAuth 的 Agent Profile 或策略层配置强制执行，不由监控意图文本承担；本页示例未展示该配置。完整语义见 Delegate Token 与缩权。

工作流程

供应商监控 Agent 工作流程

团队选择需要监控的供应商页面、关注段落和检查频率。
应用静默签发运行时凭证，并从监控规则库读取当前版本的监控规则。
应用创建 Track monitor；首次运行抓取目标页并建立基线（baseline_extracted）。
之后每次按 schedule 运行，Track 抓取当前页面并与基线比对；变没变由规则判定，不由模型措辞决定。
检查点：页面整体改版导致比对失败时按失败处理——回放该次 run，人工确认后重建基线，不把改版误报为条款变化。
命中变化时，Track 通过回调把段落级 diff、来源 URL 和快照推给你的应用。
应用校验变化条目（无来源不告警），把新基线与 diff 写入监控基线存储，并通知负责人。
检查点：每条告警都应能回溯到具体段落 diff 与来源页面；风险定性和处置由负责人完成，Agent 不直接给高风险定论。

示例代码

下面的示例使用官方 Qoni SDK（@qoniai/qoni）建立长期监控：静默签发运行时凭证 → 从监控规则库读取带版本的监控规则 → 创建 Track monitor → 需要时暂停与恢复调度。

Draft interface

统一 SDK 的 Track 接口签名尚未定稿，下面的示例只表达集成意图；Track 的产品语义见 Track。

import { Qoni } from '@qoniai/qoni'

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

export async function createVendorMonitor(vendorPages: string[]) {
  // 1. 静默委托：公开页监控，不涉及站点登录；凭证可随时撤销
  const { data: grant } = await qoni.delegateToken({
    user: { id: process.env.QONI_USER_ID! },
    agent: 'vendor-monitor',
    products: ['track'], // Track 产品授权的最终写法以正式签名为准
  })

  // 2. 创建前：从你的监控规则库读取当前版本的监控规则（不是 Memory）
  const policy = await loadMonitorPolicy() // 例如 { version: '2026-08', watchedSections: [...], thresholds: ... }

  // 3. 创建长期 monitor：首次运行建立基线，之后按 schedule 反复比对
  const { data: monitor } = await qoni.track.create({
    token: grant.token,
    intent: `
      Watch these vendor pages for pricing, SLA/terms and status changes:
      ${vendorPages.join(', ')}.
      A visual redesign alone is not a change — report only when the
      monitored sections below actually change, with a section-level diff
      and the source URL for every change.

      Monitor policy (version ${policy.version}):
      ${JSON.stringify(policy)}
    `,
    schedule: { kind: 'interval', intervalSeconds: 3600 },
    notify: { kind: 'callback_url', url: 'https://app.example.com/hooks/vendor-track' },
  })

  // monitor 引用与规则版本一起入库，供回调处理与事后回放
  await saveMonitorRef(monitor.id, { policyVersion: policy.version })
  return monitor
}

// 谈判窗口或供应商维护期间暂停调度，结束后恢复
export async function pauseVendorMonitor(monitorId: string, token: string) {
  await qoni.track.pause(monitorId, { token })
}

export async function resumeVendorMonitor(monitorId: string, token: string) {
  await qoni.track.resume(monitorId, { token })
}

命中变化时 Track 会向 notify.url 回调。回调处理属于你的应用：解析变化条目，丢弃没有 diff 或来源 URL 的条目，把新基线与 diff 连同规则版本号写入监控基线存储，然后再通知负责人——告警可信度由这一层校验保证。

单轮巡检回退：如果暂时不需要长期 monitor（例如只在续约前核查一次），可以用已文档化的 doAnything.run() 做单轮只读巡检——静默委托 webagent.do_anything 产品权限后一次调用抓取目标页面，输出与你存储基线的 diff，比对与告警逻辑同样在应用侧执行。两种形态的基线都进监控基线存储，不进 Memory。

数据与记忆边界

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

版本化规则：监控段落清单、触发阈值、告警升级规则——放在监控规则库里按版本管理，每条告警引用规则版本号。
业务状态：页面基线、逐轮 diff、快照——由 Track 的 run 记录和你的监控基线存储承载，带版本、可回放。
审计记录：凭证签发与每次取数构成的行为链——由 GenAuth 维护。
用户 Memory：本场景不使用 GUMem。基线与 diff 是业务状态而不是用户偏好；写进 Memory 只会制造第二份无法对账的真相。

失败处理

情况	推荐处理
页面整体改版导致比对失败	按失败处理并回放该次 run；人工确认后重建基线，不把改版误报为条款变化。
monitor 连续失败（`consecutive_failures` 增长）	monitor 进入异常状态；检查目标页可达性与规则配置，修复后用 `run_now` 验证一次。
目标页面出现登录墙或验证码	Track 发出需要人介入的信号；由负责人处理（`intervene`），不静默绕过。
回调条目缺少 diff 或来源	应用侧校验直接丢弃该条目并记录丢弃数量；无来源不告警。

生产注意点

网页变化不等于真实风险：Track 判定"变了"，风险定性与处置始终由负责人完成。监控只读、只通知，不代替人执行合同或采购动作。schedule 间隔应结合页面更新频率设置下限，避免对供应商站点造成压力；monitor 长期存在，团队成员变动时应转移归属并复核 notify 渠道。

下一步

阅读 Track 了解 monitor 的完整生命周期与事件流。
阅读快速开始跑通 Agent 身份与委托的最短路径。
继续查看 Partner Portal Monitoring Agent 了解登录态下的相邻监控场景。

供应商监控 Agent ​

适用场景 ​

工程挑战 ​

模块组合 ​

何时需要交互式确认 ​

工作流程 ​

示例代码 ​

数据与记忆边界 ​

失败处理 ​

生产注意点 ​

下一步 ​