Web 数据收集 Agent 模式

Web 数据收集 Agent 模式

概述

Web 数据收集 Agent 是一种面向数据采集任务的自主 Agent 模式。与交互式编程 Agent（如 Claude Code、Codex）不同，Web 数据收集 Agent 接收用户的自然语言描述（“找到 Notion 的定价方案”），自主完成搜索、导航、内容提取和数据整理的完整流程，最终返回结构化结果。

与 Session/Turn 模型的差异

传统的交互式 Agent（如 Agent 核心循环设计）采用 Session/Turn 两层模型：

维度	交互式 Agent	Web 数据收集 Agent
触发方式	用户每轮输入触发一次 Turn	单次 prompt 触发完整自主流程
循环模式	用户输入 → 推理 → 执行 → 等待下一轮	接收任务 → 规划 → 执行 → 收集 → 整理 → 返回
状态保持	Session 持久化，多轮对话	任务级状态，完成后释放
结果形式	增量响应（流式）	一次性完整结果
典型延迟	秒级（单次 Turn）	10-60 秒（完整任务）

核心架构

关键设计决策

1. 双模型策略

模型	成本	适用场景
Mini 模型（默认）	60% 更低	单网站数据提取、简单查询
Pro 模型	标准成本	跨网站对比、复杂导航、需要高准确率的场景

选择依据：任务的搜索空间大小和结构复杂度。单网站简单提取用 Mini 即可；跨多个网站对比或需要深入导航时用 Pro。

2. Zero Data Retention (ZDR) 兼容性

Web 数据收集 Agent 不支持 Zero Data Retention 模式。原因：

• Agent 需要在中间步骤暂存抓取结果和浏览器状态
• 多步骤任务需要上下文传递
• 这与 ZDR 的”不保留任何中间数据”原则冲突

3. 信用额度管理

Agent 任务的信用消耗不可预测，因此采用预扣除 + 退款的策略：

1. 收到请求 → 预扣 maxCredits 额度（默认 20）
2. 执行任务 → 按实际消耗计费
3. 任务完成 → 退还多余额度

对于高消耗任务（maxCredits > 2500），直接走付费通道，不检查免费额度。

潜在陷阱

1. 无限搜索循环

Agent 可能不断搜索新页面而永远不返回结果。

对策：

• 设置最大步骤数限制
• 设置总超时时间
• 检测重复搜索模式并中止

2. Schema 与网页内容不匹配

用户提供的 Schema 可能要求网页中不存在的数据。

对策：

• 使用 LLM 验证 Schema 的可满足性
• 返回 null 而非编造数据
• 在结果中标注哪些字段未找到

3. 跨网站数据不一致

从多个网站提取数据时，同一概念可能有不同表示（如定价单位不同）。

对策：

• 在系统提示中要求 Agent 标准化数据格式
• 使用 Pro 模型处理多网站对比场景
• 在结果中保留原始来源 URL

设计优势

优势	说明
零 URL 要求	不需要事先知道目标 URL，Agent 自行发现
语义理解	比关键词匹配更精准，理解用户真实意图
自适应	网站结构变化时 Agent 自动调整策略
结构化输出	直接返回 JSON，无需二次处理

替代方案对比

方案	优点	缺点
手动爬虫 + 提取规则	精确可控、成本低	需要知道 URL、编写规则、维护成本高
Crawl + Extract 组合	需要先知道 URL、两步调用	用户需要自己编排流程
Web 数据收集 Agent	单调用、零 URL 要求、自适应	延迟较高、成本不可精确预估
自定义 Agent 编排	最大灵活性	开发成本高、需要编排知识