DeepSeek Harness 实践：自动化读取淘宝/天猫等电商数据

每天凌晨自动获取淘宝 / 天猫店铺的商品、价格、销量与用户评价，沉淀成可对比、可追溯的结构化数据——这件事的难点不在"抓"，而在登录态能不能自动维持、数据可不可信、行为够不够克制。

这篇文章记录整个项目的实现过程。它本身也是一次 DeepSeek Harness 实践：从方案调研、接口验证、代码实现、数据采集到文档产出，全部由一个 AI Agent 在 DeepSeek Harness 上推进完成——4 路并行调研、关键结论独立复现、真实浏览器链路搭建、采集器实现与幂等校验、最后是图文文档的生成与渲染验证。

这篇文章是怎么做出来的

这个项目没有一行代码是手敲的——它是一次完整的 DeepSeek Harness 实践：

• 4 路并行调研：官方接口现状、浏览器自动化可行性、移动端方案、调度与法律风险四条线同时开，子代理各自查证，主代理只做汇总与决策。
• 关键结论独立复现：对「官方评论接口不存在」这个决定性判断，我没有采信二手教程，而是让主代理亲自向开放平台网关发请求，用错误码位级验证。
• 真实环境排障：Chrome 在沙箱里起不来、pnpm login 撞上 pnpm 内置命令、价格数字粘连、商家回复混进评价——这些坑全是跑出来的，不是想出来的。
• 文档也由 Agent 产出并自检：HTML 长文写完后先渲染截图、逐区块核对，抓出了「终端代码块换行丢失」「时序图节点断线」两个排版问题，改完才生成 PDF。

下面所有数据、截图与结论，都来自这次实践的产出。

一、先说结论：官方接口这条路过不去

动手前我做的第一件事不是写代码，而是证伪。

网上有大量「淘宝商品评论接口 taobao.item.reviews.get 接入教程」，看起来像官方文档。但它们经不起一次验证：直接向淘宝开放平台网关发请求，app_key 故意填无效值，用错误码就能区分「接口未注册」和「凭据无效」：

curl -s -G 'https://gw.api.taobao.com/router/rest' \
  --data-urlencode "method=taobao.item.reviews.get" \
  --data-urlencode 'app_key=00000000' \
  --data-urlencode 'v=2.0' --data-urlencode 'format=json' \
  --data-urlencode 'sign_method=md5' --data-urlencode 'timestamp=...' \
  --data-urlencode 'sign=00'

结果很干脆：

错误码 22 表示该 ApiName 在开放平台未注册，29 表示接口存在、只是测试凭据无效。结论：所谓"官方评论接口"是第三方数据商的 SEO 软文，真实存在的商品与评价接口权限边界是"自己的店"，拿不到竞品。

这也决定了技术路线：必须用真实用户身份访问公开页面。

二、整体架构：人工只出现一次

五个环节：真实 Chrome → CDP 接管 → 采集器 → 本地数据库 → 分析产物。人工只在最开始扫码登录一次，之后由定时任务自动完成。

为什么用真实 Chrome，而不是无头浏览器

直接用无头浏览器 + 反检测插件（puppeteer-extra-plugin-stealth / playwright-extra）这条路已经走不通：这两个库最后一次发布停在 2023 年 3 月，而且它们只做页面层的属性伪装，碰不到浏览器底层的 TLS、GPU、字体特征，反而容易被反过来识别。

所以方案改成：启动本机真实的 Chrome（独立数据目录，保留正常的浏览器指纹），再用浏览器官方的调试协议 CDP 接管它。浏览器是真的、指纹是真的、登录态是真的，程序只是替人"翻页和记录"。

技术栈选的是 Node 24 + playwright-core（不下载任何浏览器，直接驱动系统 Chrome）+ node:sqlite（零原生依赖，不用编译）。

三、每天凌晨 1 点发生什么

关键设计是探测失败时停下来报警，而不是反复重试——反复重试才是账号被风控的主因。

• 01:00 唤醒，随机后移 0–30 分钟（固定整点、固定节奏本身就是机器特征）
• 登录态探测：把「技术故障」和「需要人工登录」彻底分开
• 分步采集：店铺 → SKU → 价格 → 评价增量，单项失败不影响整体
• 幂等入库 + 心跳：判断「该跑没跑」

四、采什么

「商家回复率」是个容易被忽略但几乎零成本的字段，本次实测三家分别是 98% / 12% / 0%，差距比想象中大得多。

五、四道质量保障

自动化采集最容易出的问题不是"抓不到"，而是抓错了还看不出来。

① 归属校验。 每店按「会员 ID + 店铺 ID」双号核对。搜索结果里常混入卖同款的分销店——我实测遇到过标题写 A 品牌、实际属于 B 店铺的情况，只靠标题会采错数据。

② 按结构取值。 价格不能从整段文字里"抠数字"。页面上价格被拆成「整数 + 小数」两个节点，而且紧挨着「6000+人付款」；我第一版就踩了坑，抓出来的均价高达 ¥5794，因为 48.31 和 6000 被连成了 48.316000。修法是按 DOM 结构分别读取整数与小数节点，销量从独立元素取，再加一道「价格超过十万判为异常」的护栏。

③ 幂等去重。 每条评价用稳定主键 + 内容指纹双保险。同一批数据连续跑两遍，第二遍新增为 0——这是增量采集正确性的硬指标。

④ 隐私假名化。 评价者身份只保存不可逆哈希，原始昵称、头像、图片一律不落库，并用程序化校验确保没有一条漏网。

还有一个必须单独说的坑：评价页的商家回复块和评价正文共用同一个类名，我第一版把每条商家回复也当成了一条评价，污染了 47 行数据（占当时总行数的 22%），直接把客服回复率算虚高。修法是靠"内部是否含回复标签"区分，并加一道"正文含『商家回复』字样即丢弃"的防线。

六、真实数据长什么样

以下都是实际采集结果（2026-10-15 快照，3 家店铺 748 个 SKU）。

同一品类下三种完全不同的打法：

宝宝馋了是广度铺量，窝小芽是低价爆款驱动（用 ¥12–15 的糖果做流量入口，再引到 ¥56 的鳕鱼肠），而 SKU 最少的那个品牌客单价最高、却缺一个 ¥10–20 的入口款。

七、合规边界：这条线划得很清楚

这套流程采用「模拟人工浏览」的方式获取登录后本就可公开查看的页面内容。它仍然可能不符合平台用户协议，属于民事 / 违约层面的风险；而一旦越过「破解技术措施」这条线，性质就变成刑事风险。

做的： 自有账号登录、只看本就可看的页面、单账号串行、3–8 秒随机间隔、每次少量、时间随机化、评价者假名化、数据仅内部决策。

绝不做的： 不计算平台接口签名、不破解滑块验证码、不伪装设备指纹、不使用账号池、不采集个人信息、不做同质化产品替代原平台。

流程中任何一步遇到验证码或异常拦截，程序会立刻停下并告警，交由人工处理——不重试、不硬碰。

相关依据包括《反不正当竞争法》关于「不得以避开或破坏技术管理措施等不正当方式获取其他经营者数据」的规定、《个人信息保护法》对已公开个人信息的处理要求，以及平台自身的用户协议与法律声明。如果能通过品牌授权或官方数据产品（如生意参谋的市场洞察模块）获得同类数据，应优先采用官方通道。

八、局限（先把话说清楚）

• 销量是页面展示口径。「5万+人付款」是平台对外展示的区间值，不是精确销量，跨店只能比量级。
• 评价是抽样。 每个商品只取最新 1–2 屏，用于看口碑结构足够，不能当全量情感分析。
• 页面会改版。 前端样式更新会导致选择器失效，需要用诊断工具重新校准，这属于持续维护成本。
• 建议先对账。 用自有店铺的采集结果与后台真实数据比对几天，确认准确度后再把竞品数据用于决策。

这套流程的定位是辅助决策的持续观测，不是精确的行业数据库。它擅长回答「谁在放量、价格怎么动、口碑往哪走」，不擅长回答「精确销量是多少」。

附：完整工作流程文档

完整版（18 页）包含架构图、时序图、四道质量保障机制、真实数据图表、合规边界清单、交付说明，以及一份可直接用于客户沟通的对话引导（9 组客户问答 + 反向提问清单 + 开场白）。

📄 下载完整文档（PDF，18 页）