真实 AI Agent 的商业化路径：后台监控优于对话交互

我看到的消费级 AI 演示，似乎总是围绕“对话”展开。

聊天搭子。生活教练。一个配着可爱 UI 的第二大脑。

我认为，这个方向基本搞反了。

普通人真正会照着搭建的第一个 AI Agent，要无聊得多：

一个 watcher agent，按计划检查那些烦人的网站，只有发生了真正重要的变化时才通知你。

更像是：“每 30 分钟检查一次这个难用的许可证门户，等我的状态发生变化时告诉我。”

这种模式已经存在于 OpenClaw、Distill.io 和 changedetection.io 等工具中。说实话，它比当下许多备受关注、华而不实的消费级 Agent 更实用。

让我豁然开朗的那篇帖子

在研究求职自动化和浏览器 Agent 工作流时，我在 r/openclaw 发现了一个帖子，标题是：

“OpenClaw 找到了我走失的猫！”

没读内容之前，这听起来很像标题党。

其中的核心细节很简单：用户把情况告诉 OpenClaw，随后 Agent 持续检查动物保护协会的认领信息和相关论坛，直到情况出现变化。

整个模式就是这么简单。

真正有用的部分并不是模型。

不是 glm 5.1，不是 GPT-5，也不是 Claude Opus 4.6。

真正有用的是把“坚持不懈”委托了出去。

人类不必再每隔 20 分钟，手动重新检查一遍相同的信息源。

这是一个比人们意识到的更庞大的品类。

大多数令人痛苦的个人事务并不难，只是不断重复。

现实世界中的许多任务，并不需要那种戏剧化意义上的智能。

• 底层的浏览器操作
• 记得稍后再检查一次
• 检查不同公司招聘页面上的职位
• 检查许可证和资质审批门户
• 检查那些从不发送有效通知的学校门户
• 检查补货和降价信息
• 检查二手设备分类信息
• 在收容所和社区公告板上搜索走失宠物

这其实不是一个 chatbot 问题。

而是一个 watcher 问题。

网站监控早已证明了这种需求

多年来，人们一直愿意为“盯着这个页面，有变化就告诉我”付费。

这一点很重要，因为它意味着这种行为模式已经得到验证。AI 只是让这个模式变得更聪明。

现有产品已经证明了以下几点：

有意思的是，changedetection.io 已经开始向 Agent 行为演进。

它支持的功能包括：

• OpenAI-compatible AI endpoints

到了这一步，你做的就不只是比较 HTML 差异了。

你正在构建一个决策层。

Monitor 与 Agent：真正重要的分界线

这是我反复想到的一个区别。

网站 monitor 负责检测变化。

watcher agent 则负责判断，这个变化是否值得打扰你。

听起来只是一个很小的差别，却会彻底改变整个 UX。

monitor 会说：有东西发生了变化。

• 你知道具体是哪个页面
• 你知道具体是哪个 selector
• 你知道自己关心的具体文本

Distill.io 很擅长做这件事。

Agent 会说：这个变化可能很重要，原因如下。

Agent 不必转发每一处差异，而是可以：

• 忽略外观上的变化
• 比较多个信息条目
• 总结发生了什么变化
• 区分有效信号与噪声
• 只在置信度较高时升级通知
• 继续搜索相邻的信息源

这就是 OpenClaw 的故事如此打动人的原因。

重点不是“哇，AI 居然可以浏览网页”。

而是“哇，我终于不用守着这些标签页了”。

我真正会采用的架构

如果今天让我来构建这个系统，我会把它拆成三层。

首先使用最简单但足够可靠的方案。

• Distill.io：快速、托管式的监控
• changedetection.io：开源方案的灵活性
• Playwright：适合动态、不稳定或高度依赖登录的网站

使用 Docker 运行 changedetection.io：

docker run -d \
  --name changedetection \
  -p 5000:5000 \
  -v $PWD/datastore:/datastore \
  ghcr.io/dgtlmoon/changedetection.io

这样很快就能得到一个可靠的基础 watcher。

什么时候 Playwright 更合适

如果目标网站存在以下情况：

• 奇怪的多步骤表单
• 客户端渲染的内容

npm init -y
npm install playwright
npx playwright install

下面是一个监控许可证门户的示例脚本：

const { chromium } = require('playwright');
const fs = require('fs');

(async () => {
  const browser = await chromium.launch({ headless: true });
  const page = await browser.newPage();

  await page.goto('https://example.gov/permit-status');
  await page.click('text=Accept Cookies');
  await page.fill('#permit-id', process.env.PERMIT_ID);
  await page.click('button[type="submit"]');
  await page.waitForSelector('.status-value');

  const status = await page.locator('.status-value').innerText();
  const previous = fs.existsSync('last-status.txt')
    ? fs.readFileSync('last-status.txt', 'utf8')
    : '';

  if (status !== previous) {
    console.log(`Status changed: ${previous} -> ${status}`);
    fs.writeFileSync('last-status.txt', status);
    // send webhook / Slack / Discord here
  } else {
    console.log('No meaningful change');
  }

  await browser.close();
})();

仅仅做到这些，就已经很有用了。

但真正有意思的部分，是从加入判断能力开始的。

这才是 LLM 真正体现价值的地方。

You are reviewing website changes for a user.

Return JSON with:
- meaningful_change: boolean
- summary: string
- urgency: low | medium | high
- reason: string

Ignore:
- timestamps
- layout changes
- ad rotations
- navigation changes
- cosmetic text edits

Flag only changes that affect:
- availability
- price
- status
- deadlines
- application state
- newly posted matching items

如果你使用 changedetection.io 或自己的工作流引擎，可以把这一层放在 OpenAI-compatible endpoint 后面。

这一点很重要，因为这样你就可以更换模型提供商，而不必重写应用。

例如，将 OpenAI SDK 指向 Standard Compute：

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: process.env.STANDARD_COMPUTE_API_KEY,
  baseURL: 'https://api.standardcompute.com/v1'
});

const response = await client.chat.completions.create({
  model: 'gpt-5.4',
  messages: [
    {
      role: 'system',
      content: 'Classify whether a website change is meaningful and summarize it.'
    },
    {
      role: 'user',
      content: `Old content:\n${oldContent}\n\nNew content:\n${newContent}`
    }
  ],
  response_format: { type: 'json_object' }
});

console.log(response.choices[0].message.content);

在按 token 计费的模式下，这类工作负载很容易让人头疼。

watcher agent 的设计初衷就是重复运行。

它们全天候运行，检查大量充满噪声的页面，而且往往需要检查多个信息源。绝大多数检查都不会产生任何有用的结果。

这意味着成本模型非常重要。

如果每一次后台检查都可能带来一笔意外账单，人们就会过度限制系统的运行频率，甚至彻底停止使用。

固定费率的计算资源更适合这种模式。

Standard Compute 在这里值得关注，因为它提供 OpenAI-compatible API，并采用可预测的月度定价，不必时刻焦虑 token 费用。对于页面监控、过滤、总结和路由提醒这类周期性 Agent 工作负载，这种定价模式比为后台的每一个微小决策单独付费合理得多。

不要把提醒发送到另一个 dashboard。

把它们发到用户原本就在使用的地方：

• 通过 webhook 接入 n8n、Make 或 Zapier

Discord webhook 示例：

await fetch(process.env.DISCORD_WEBHOOK_URL, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    content: `Permit update: ${summary}`
  })
});

n8n webhook 调用示例：

await fetch('https://your-n8n-instance/webhook/permit-alert', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    source: 'permit-portal',
    meaningful_change: true,
    summary,
    raw_status: status
  })
});

这才是正确的形态。

平时悄无声息，只在真正重要时出现。

一个实用的工作流示例

下面是一个用于职位信息的最简 watcher pipeline。

• Playwright 打开 5 家公司的招聘页面
• 提取职位名称和链接
• 与上一次运行结果进行比较
• 把新职位发送给 LLM 进行筛选
• 只有职位符合你的条件时才发出提醒

const listings = await scrapeCompanyPages();
const newListings = diffAgainstPrevious(listings);

for (const listing of newListings) {
  const decision = await classifyListingWithLLM(listing, {
    targetTitles: ['Platform Engineer', 'Developer Productivity', 'AI Automation Engineer'],
    locations: ['Remote', 'NYC'],
    seniority: ['Senior', 'Staff']
  });

  if (decision.meaningful_change) {
    await sendSlackAlert(decision.summary, listing.url);
  }
}

这些系统在现实中会在哪里出问题

watcher agent 很有用，但它们并不神奇。

常见的故障模式完全可以预料：

• 登录悄无声息地失败
• Agent 过于频繁地把垃圾信息升级成提醒

还有第二个问题：自主权不断膨胀。

你给 Agent 的自由度越高，它做出蠢事的可能性就越大。

我为这类系统制定的规则很简单：

• 自动总结
• 自动升级通知
• 只有获得批准后才执行操作

这样既能获得大部分价值，又不至于制造出恐怖故事。

为什么这对 Agent 开发者很重要

如果你正在为真实用户构建 AI 工作流，那么这个品类值得重点关注。

因为“监控并通知”模式具备人们真正需要的全部特征：

• 在后台运行
• 可以自然地接入现有自动化工具

它也与开发者已经在使用的工具完美契合：

• OpenAI-compatible APIs

同时，它还带来了一种非常具体的基础设施需求：

你需要廉价、可靠、朴实无华的 inference，来处理周期性的后台任务。

不是只运行一次的英雄式 prompt。

而是成千上万个微小决策。

这恰恰是大多数 AI 定价模式开始变得别扭的地方。

无聊的 Agent 最终会击败那些令人印象深刻的 Agent。

不是因为它们更聪明。

而是因为它们消除了反复出现的烦恼。

大多数人真正喜欢上的第一个个人 Agent，很可能既不是陪伴者，也不是通用助理。

而是那个在人们睡觉时，仍然不断检查难用网站的东西。

等现实终于发生变化时，它还知道这次更新是否值得把人叫醒。

如果你正在构建这样的系统，我建议从下面这套技术栈开始：

• 使用 changedetection.io 或 Playwright 检测变化
• 使用 OpenAI-compatible model endpoint 进行判断
• 使用 Slack、Discord、Telegram 或 webhook 升级通知
• 如果 Agent 需要持续运行，则使用固定成本的 inference layer

最后一点比人们想象中更重要。

只有当你敢于让 watcher agent 自由运行时，它的体验才会真正出色。

如果你一直惦记着 token 开销，最终就只能构建出一个降低监控频率的 watcher。

那就失去了它存在的意义。

对于后续操作，你可以考虑屏蔽此人和／或举报滥用行为。