5.1 实战：电商比价与信息聚合

5.1 实战：电商比价与信息聚合

本节摘要：第一役打多页多品提取：对三个店铺页的同款商品比价，产出一张可入库的比价表。完整走一遍背景、操作、结果、解读、变式五道工序——本节的价值不在代码本身，而在工序模板，换任何聚合类需求都能照抄。

背景：需求长什么样

运营同学的原始需求一句话："每周把三个店铺的同款机械键盘价格拉出来比一比，涨跌超过一成告诉我。"先做需求翻译（命令台指挥官的第一道工序）：哪些店铺、哪个商品页、比什么字段、产出什么形态、什么算异常。翻译成任务规格——三个店铺的商品列表页地址已知，字段取名称、到手价、库存状态，产出一张按价格升序的对比表，涨跌幅超一成的行做标记。为什么派智能体而不是写脚本：三个店铺页面结构互不相同且隔三差五改版，维护三套选择器的成本高于模型调用费——1.3 口诀的"页面活"分支。

操作：代码分四步

第一步立字段合同，三个店铺共用一份：

from pydantic import BaseModel

class 店铺报价(BaseModel):
    店铺名: str                    # 来源店铺，人工填写进任务单
    商品名: str                    # 页面显示的商品全名
    到手价: float                  # 页面标示售价，不含券
    有货: bool = True              # 页面出现缺货字样则为假

class 比价表(BaseModel):
    行: list[店铺报价]             # 每店铺一行，三行合一张表
​

第二步按 3.3 的粒度拆解，一店一仗：

from browser_use import Agent, Browser
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0.1)
browser = Browser()

店铺任务 = [
    ("素盾官方店", "https://shop-a.example.com/k87"),
    ("铁臂数码",   "https://shop-b.example.com/list?kw=K87"),
    ("键盘之家",   "https://shop-c.example.com/p/9527"),
]

def 打一仗(店名, 地址):
    agent = Agent(
        task=(
            f"打开 {店名} 的商品页（{地址}），"
            "找到名为素盾K87的机械键盘，"
            "记录它的页面标示售价与是否有货；"
            "找不到该商品就明确回答'未找到'"
        ),
        llm=llm,
        browser=browser,
        structured_output=店铺报价,
    )
    return agent.run(max_steps=8)
​

第三步汇总与涨跌标记，纯 Python 的活，不必麻烦模型：

rows = []
for 店名, 地址 in 店铺任务:
    r = 打一仗(店名, 地址)
    rows.append(r)                     # 每仗独立交割，失败单独重打
prices = sorted(rows, key=lambda x: x.到手价)
base = prices[len(prices) // 2].到手价  # 以中位价为基准算涨跌
for row in rows:
    标记 = "异常" if abs(row.到手价 - base) / base > 0.1 else "正常"
    print(f"{row.店铺名}\t{row.到手价}\t{标记}")
​

结果：预期输出

素盾官方店	99.0	正常
铁臂数码	101.0	正常
键盘之家	129.0	异常
​

解读：输出里能读出什么

三行输出背后是三场独立战役，各自八步预算、互不牵连——键盘之家那站若翻车，重打成本是八步而不是全单二十四步。价格出现明显离群（129 对 99）通常有三种解释：页面标的是不同配置（注意任务单锁了型号名）、含套装赠品、或者真的调价了。智能体的价值边界也在这里：它忠实搬运页面标示值，判断"该不该信这个价"仍然是指挥官的事。另外注意任务单里那句"找不到就明确回答未找到"——给复核拍一个明确的失败出口，避免模型硬凑答案，这是聚合类任务的通用保命句。

变式：往你自己的场景迁移

变式一，加维度：字段合同里加"评分、月销量"，同一套代码不动逻辑只改模型。变式二，多商品：商品列表循环套店铺循环，注意每仗任务单里商品名与店铺名都要锁死。变式三，加监控：把本役的汇总结果存档，下次跑时对比上期——这正是第三役要展开的巡检形态，可以先想想你会怎么记"上期价格"。变式四，跨站核对详情：用标签页类动作开新页核套餐内容，记得 4.1 的叮嘱——切回原页要写进任务单。

战役复盘五问

每打完一役，按固定五问复盘，十分钟换一份可复用的经验：一问产出对不对——数据有没有错漏，错在提取环节还是环节之前；二问步数超没超——实际步数与预算的差值暴露任务单质量；三问卡在哪拍——按第 3 章的拍位定位最耗时的一拍；四问钱花在哪——成功调用与失败调用的比例，失败率高说明侦察不足；五问下次改一句什么——只允许改一句，强迫你找到最大杠杆。比价役按五问复盘的典型结论是"店铺任务单里型号名要锁死"，一句话值三成成功率。

一个聚合类需求的常见追问

**问：三个店铺要同时开三个会话并行跑吗？**可以但要排队见识：并行省时间，代价是三份并发日志混在一起，排错时得按任务号分拣。日任务量小的阶段，串行足够——先跑通、后提速，别在第一役就上并发把变量搞多。等第 5.3 的巡检体系稳定了，再把并行当优化项提上日程，那是锦上添花的活，不是雪中送炭的活。

交割之后：让数据接上下游

比价表的归宿通常是表格或数据库，交割格式多想一步能省很多 downstream 的力气：字段名与下游表结构对齐（别到导入时再改名）；价格统一数值型并注明币种；多店铺数据带采集时间戳——下次跑批对比涨跌全靠它。这些看起来是数据工程常识，但在智能体提取场景里格外重要：模型的产出天然是"这一刻的快照"，快照不带时间戳，比价就成了玄学。本役的汇总代码里那行 f"{row.店铺名}\t{row.到手价}"，真实生产里应该扩成带日期的完整行——读者动手时不妨直接按这个标准改进它，正好当本役的作业。

第二役换主攻：流程类任务的动作编排与禁区写法——那类"步骤多一步都不能错"的活。