这是传统的做法：你告诉程序每一步怎么做。

1. 打开 URL
2. 找到 class="product-card" 的元素
3. 在它里面找到 class="price" 的元素
4. 读取文本内容

优点是指令精确, 执行速度快, 结果确定。但缺点也很明显：你对页面的结构做了假设, 页面一改假设就失效。每次页面更新都是一次人工维护。

这是新做法：你告诉程序你想要什么, 它自己想办法。

目标：找到 RTX 50 系列的游戏本, 预算 1500 美元以内, 提取名称、价格和显卡型号

程序（一个 LLM 驱动的 Agent）自己打开网页, 自己识别哪些元素是产品卡片, 自己找到价格和规格信息。你不需要关心页面的 HTML 结构。

缺点是慢（每次执行都需要 LLM 推理）, 贵（每次调用都有 Token 成本）, 而且结果不保证一致。同一个任务跑两次可能拿到不同的数据。

这个表格说明一件事：两个范式没有绝对优劣。重点不在"哪个更好", 得先搞清楚"什么时候用哪个"。

Agent 拿到任务后进入一个循环：

1. 执行 (Action) ：从内置工具箱中选一个操作（导航、点击、提取、滚动）
2. 评估 (Eval) ：上一步操作成功了吗？如果失败就重试
3. 记忆 (Memory) ：记录已经完成的工作, 避免重复
4. 规划 (Next Goal) ：基于当前进度决定下一步做什么

这个循环的好处是能自我纠正。传统脚本碰到意外情况就直接崩溃, Agent 的 Eval 步骤能发现失败并调整策略。比如某个按钮没找到, 不会抛出异常退出, 而是尝试其他方式定位。

Worker 完成后, 第二个 LLM 作为 Judge 审查结果。

这个设计的思路是这样的：人做复杂任务时容易自我感觉良好, 看不到自己的盲区。LLM 也一样。Worker 看到的是完整的思考过程, 容易觉得自己"做得还不错"。Judge 只看到原始任务和最终结果, 能以新视角找出问题。

在该示例中, Judge 发现 Worker 把一篇关于加密技术的文章错误归类为 AI 相关文章。这个分类错误并不显眼, 但 Judge 抓住了。

Agent + Judge 架构不限于网页爬虫。它的本质是两个角色的分离：

• 一个能做决策的执行器 + 一个能发现问题的评审器
• 执行器负责灵活应对变化, 评审器负责把住质量底线
• 两者视角不同, 才能相互制衡

如果你在设计 AI 工作流, 可以试试这个分离模式。

精确指令范式快。定位一个元素是毫秒级的操作。但这个快建立在"页面结构稳定"的假设上。页面一改, 快就没意义了, 因为代码跑不了。

目标描述范式慢。每次操作都有 LLM 推理延迟, 一个简单的数据提取任务可能花 30 到 60 秒。但这个慢换来了适应性：页面结构变了, Agent 通常还能自己找路。

取舍逻辑：如果页面稳定、任务频繁执行, 精确指令更划算。如果任务是一次性的、或者目标站点经常改版, 目标描述的总体成本（开发时间加维护时间）反而更低。

精确指令范式每次执行结果完全相同。这在很多场景下是硬要求。比如金融数据的定时采集, 结果不一致比慢更可怕。

目标描述范式每次都可能走不同路径。同一个提取任务, 两次运行之间分类结果可能不一样。

取舍逻辑：需要审计级可靠性的场景选精确指令。能容忍"今天的结果和昨天有细微差异"的场景再考虑目标描述。

精确指令范式的成本是一次性的开发成本。写爬虫花时间, 但跑起来几乎不花钱。

目标描述范式正相反。每次执行都有 Token 成本。Hacker News 示例跑了 42,339 个 Token, 花费约 12 美分（用 GPT-4o）。看起来不多, 但请注意：后续步骤会携带完整对话历史, 步骤越长上下文越大, 成本会加速增长。

降低成本有三种方式：

• 换便宜模型。GPT-4o-mini 或 Haiku 能把成本降到两美分以下
• 用本地模型。Ollama 或 LM Studio 可以把单次运行成本降到零。注意需要 30B+ 参数级别的模型才能可靠输出结构化结果
• 缩短提示词。每少一步推理, 上下文就少几千 Token

精确指令适合规则匹配型任务。"提取 class=price 的文本内容"、"点击 class=next-page 的按钮"。这些任务不需要 LLM, 用了反而添乱。

目标描述适合判断综合型任务。"找出所有 AI 相关的故事"、"总结这些产品的共同点"、"挑出性价比最高的那一款"。这些任务需要某种程度的理解, 纯规则无法完成。