中国社交电商数据：Agent 的机会窗口

先说结论 — 中国社交电商跑在抖音、小红书、微博等平台上，内容、互动和购买发生在同一个 App 里。AI Agent 能帮品牌、创作者和代理商在其中做事，但前提是能以机器速度读取这些平台的结构化公开数据。数据就在那里，瓶颈是访问架构。

市场

中国社交电商数据之所以重要，是因为发现、内容和购买常常在同一个平台内完成。市场规模估算因来源和口径差异很大，本文不依赖某个 GMV 数字，论证建立在平台的运作方式上。

核心平台：

平台	主要电商模式
抖音	直播电商 + 短视频带货
小红书	内容驱动的发现式消费
快手	直播电商
微博	明星/品牌代言
微信	小程序、私域流量

这些不是加了「购买」按钮的社交平台。它们是整合的商业生态：

内容即是店铺
互动指标即是购买信号
创作者影响力即是分发渠道
算法推荐即是商品陈列

为什么 Agent 需要这些数据

传统的中国社交电商分析工具假定人类会查看仪表盘、解读趋势、做出决策，这形成了一个随团队规模线性增长的瓶颈。

AI Agent 能松开这个限制。一个 Agent 可以：

追踪小红书上的公开商品笔记和评价，标记评价情绪和价格提及的变化
批量筛选 KOL 候选，依据公开内容、互动计数和达人市场列表判断合作匹配度
在产品爆发前检测趋势，交叉比对小红书提及量、抖音视频互动和微博讨论
规划直播排期，参考公开直播间信息和竞品开播情况

每一项都需要结构化、程序化地访问平台公开数据。不是截图，不是 CSV 导出，不是周报，是 Agent 速度的 JSON。

数据格局：有什么可用

以下全部内容的范围：公开、只读数据，用一个 SandBase API Key 调用。SandBase 不是这些平台的官方合作方，这些端点不提供私密账号、私信、仅账号所有者可见的分析数据（比如店铺自己的转化、加购数据）、发布或账号操作。需要你自己计算的项目标为派生。端点名来自 2026-10-01 的目录。只有本文实际调用过的三个端点（douyin/app-v3/user-post-videos、douyin/app-v3/multi-video-statistics、douyin/app-v3/user-profile）写出了字段名；其余只描述能力，具体返回什么请看各端点参考页。

抖音电商数据

创作者/达人数据：

公开主页和粉丝数（douyin/app-v3/user-profile；2026-10-01 实测观察到 user.follower_count）
公开账号视频列表里每条视频的点赞、评论、分享、收藏计数（douyin/app-v3/user-post-videos，见下文实测示例）
按视频 ID 批量查统计（douyin/app-v3/multi-video-statistics）：2026-10-01 实测返回点赞、播放、分享计数，两条视频中有一条另有下载计数；没有评论和收藏计数（示例见下文）
互动率和增长趋势（由上面的计数长期存储后派生）
星图达人市场列表：标价，以及市场为达人展示的汇总受众画像（douyin/xingtu/kol-service-price-v1、douyin/xingtu/kol-audience-portrait-v1）
公开直播间信息（douyin/web/user-live-info-by-uid）

商品/店铺数据： 截至 2026-10-01，SandBase 抖音目录里没有专门的抖音小店端点。商品信号只能间接获取：公开视频和评论（douyin/app-v3/video-comments），以及星图的达人-商品视图（douyin/xingtu-v2/author-convert-videos-or-products）。

趋势/发现数据：

多品类排行榜（douyin/billboard/*，例如 hot-total-list）
热搜和关联关键词（douyin/app-v3/hot-search-list、douyin/search/search-suggest）
视频和用户关键词搜索（douyin/search/*）

截至 2026-10-01，SandBase 抖音目录显示 262 个抖音端点，覆盖 index、web、app-v3、billboard、星图、creator、DOU+ 和 search 频道。

这个数字就印在目录页上，每张端点卡片也标了状态和价格。

截图：SandBase 抖音目录页，端点数显示「262 SHOWN」；选中的 multi-video-statistics 卡片标着 Available · Free（2026-10-02 截取）。

小红书电商数据

小红书是中国社交电商的「发现引擎」，用户在这里研究商品，然后去任何地方购买：

内容数据：

笔记搜索、笔记详情和笔记评论（xiaohongshu/app-v2/search-notes、xiaohongshu/app-v2/image-note-detail、xiaohongshu/app-v2/note-comments）
商品搜索、详情和公开评价（xiaohongshu/app-v2/search-products、xiaohongshu/app-v2/product-detail、xiaohongshu/app-v2/product-reviews）
话题信息流，用于观察季节性（xiaohongshu/app-v2/topic-feed）

创作者数据：

公开用户信息和已发布笔记（xiaohongshu/app-v2/user-info、xiaohongshu/app-v2/user-posted-notes）
蒲公英达人市场的达人详情和粉丝画像端点（xiaohongshu/pgy/blogger-detail、xiaohongshu/pgy/blogger-fans-profile）
内容品类分布（由达人笔记派生）

商业信号（全部由公开笔记和评论派生）：

商品提及频率和增长曲线
评论中的价格敏感度和购买意向语言

截至 2026-10-01，SandBase 小红书目录显示 34 个端点。

微博电商数据

微博是情绪层，公众舆论形成和品牌危机爆发的地方：

讨论数据：

实时搜索和热搜（weibo/web-v2/realtime-search、weibo/web-v2/hot-search）
公开微博的转发、评论和点赞（weibo/app/status-reposts、weibo/app/status-comments、weibo/app/status-likes）
情绪极性和声量突增（用你自己的模型对搜索结果派生）

明星/品牌数据：

品牌和明星账号的公开时间线（weibo/app/user-timeline）
相对竞品的声量份额（由搜索量派生）

截至 2026-10-01，SandBase 微博目录显示 52 个端点。

瓶颈：数据访问架构

核心问题：数据在平台上是公开的，但第三方 Agent 没有通用的程序化访问途径。

不可行的方案

人工导出： 分析师从平台页面复制数据。随团队规模 O(n) 增长，引入小时/天级延迟，Agent 用不了。

浏览器自动化： 无头浏览器爬取平台 UI。脆弱（UI 一改就坏）、慢、难以跨平台更新维护，而且视采集内容不同，可能涉及平台条款和法律问题。如果处理个人信息，请结合你的具体用途核对《个人信息保护法》下的义务。

官方 API（限于已授权账号）： 抖音开放平台服务经过授权、绑定账号的场景，巨量引擎给广告主自己的投放数据。当你代表授权给你的账号操作时，它们是正确工具，但不适合市场级公开研究。

需求	官方平台 API	公开数据 API（如 SandBase）
数据范围	授权给你应用的账号	公开、只读数据
鉴权	平台开发者应用 + 用户 OAuth	一个 SandBase API Key
发布 / 账号操作	对已授权账号支持	不支持
仅所有者可见的分析数据	对已授权账号支持	不支持
适合	管理自己或客户的账号	市场研究、监控、Agent 工具

可行的方案

结构化公开数据 API：通过文档化 REST 端点提供平台公开数据的服务。这是实现 Agent 速度数据访问的路径。

示例调用 douyin/app-v3/user-post-videos（端点参考）。你需要一个 SandBase API Key。

import os
import httpx

SANDBASE_API_KEY = os.environ["SANDBASE_API_KEY"]


async def latest_videos(sec_user_id: str, max_cursor: int = 0) -> dict:
    """拉取某个公开账号的一页视频（最多 20 条）。"""
    async with httpx.AsyncClient(timeout=60) as client:
        resp = await client.post(
            "https://api.sandbase.ai/v1/api/douyin/app-v3/user-post-videos",
            headers={"Authorization": f"Bearer {SANDBASE_API_KEY}"},
            json={"sec_user_id": sec_user_id, "count": 20, "max_cursor": max_cursor},
        )
        resp.raise_for_status()
        body = resp.json()
    outputs = body.get("outputs") or []
    if body.get("status") != "completed" or not outputs:
        raise RuntimeError(
            f"SandBase call did not complete: {body.get('status')} {body.get('error')}"
        )
    data = outputs[0].get("data") or {}
    return {
        "videos": data.get("aweme_list") or [],
        "has_more": bool(data.get("has_more")),
        "next_cursor": data.get("max_cursor"),
    }
# 解析、推理、决策：在一个 agent 循环迭代内完成

这里用的是 Model API 路由（POST /v1/api/douyin/app-v3/user-post-videos，Bearer 鉴权，JSON body 只放该端点的参数）。参考文档记录的完成态负载在 outputs[0].data；调用未完成时函数会直接抛错。

端点参考页上是同一条路由，函数发送的三个 body 字段也都在列。

截图：douyin/app-v3/user-post-videos 端点参考页，路由为 POST /v1/api/douyin/app-v3/user-post-videos，字段有 count（不超过 20）、用于翻页的 max_cursor 和必填的 sec_user_id（2026-10-02 截取）。

实测于 2026-10-01（UTC），测试对象是人民日报的公开官方账号。请求 body：

{"sec_user_id": "MS4wLjABAAAA8U_l6rBzmy7bcy6xOJel4v0RzoR_wfAubGPeJimN__4", "count": 20, "max_cursor": 0}

截短后的返回（20 条视频只展示 1 条，删掉了大部分字段）：

{
  "id": "ae988129-adb7-4393-a10d-46484cfbb5ed",
  "status": "completed",
  "model": "douyin/app-v3/user-post-videos",
  "outputs": [{
    "data": {
      "has_more": 1,
      "max_cursor": 1790762105000,
      "aweme_list": [{
        "aweme_id": "7691636135411420452",
        "desc": "国庆前夕，人民日报记者来到集市拍下这组照片……",
        "create_time": 1790848603,
        "statistics": {"digg_count": 14620, "comment_count": 82, "share_count": 254, "collect_count": 360}
      }]
    }
  }]
}

aweme_list、has_more、max_cursor 和 statistics 里的计数来自这次调用，属于实测观察，不是文档保证。翻页时，has_more 为真就把返回的 max_cursor 作为下一页请求的 max_cursor。

实测于 2026-10-01（UTC）： douyin/app-v3/multi-video-statistics，传入两个公开视频 ID（上面那条人民日报视频和另一条公开视频）。请求 body 为 {"aweme_ids": "7691636135411420452,7687107502068026650"}；截短后的响应（run id af0f2b72-968d-4475-b7ee-d77a5dde545a）：

{"statistics_list": [
  {"aweme_id": "7691636135411420452", "digg_count": 54636, "download_count": 30, "play_count": 2191932, "share_count": 57},
  {"aweme_id": "7687107502068026650", "digg_count": 195, "play_count": 24922, "share_count": 4}
]}

这些字段都是实测观察。第二条视频没有 download_count，所以每个字段都要用 .get() 读取；评论和收藏计数请用 user-post-videos 列表，上面的实测里它返回了 comment_count 和 collect_count。

截至 2026-10-01，与本文最相关的四个目录合计显示 493 个端点：抖音 262、TikTok 145、微博 52、小红书 34，同一个 Key、同一种调用方式。更全面的对比见2026 社媒数据 API 选型。

五大 Agent 机会

机会一：商品趋势检测 Agent

问题： 品牌常在趋势产品达峰后才发现。等人类分析师看到抖音趋势时，市场可能已经饱和。

Agent 架构：

每 15 分钟：
  1. 扫描抖音排行榜的上升条目
  2. 交叉验证小红书提及加速度
  3. 检查微博讨论中的早期负面信号
  4. 评分趋势强度（量 × 加速度 × 情绪）
  5. 如果分数超阈值且市场未饱和 → 告警

数据需求：

抖音排行榜端点（douyin/billboard/*）
小红书笔记搜索（xiaohongshu/app-v2/search-notes）
微博实时搜索（weibo/web-v2/realtime-search）
你自己存储的历史基线，用于评分

机会二：KOL 筛选和审核 Agent

问题： 品牌凭表面指标人工评估达人，看不出受众匹配度和带货潜力。假粉虚增感知价值。

Agent 架构：

输入：品牌 brief（产品、目标受众、预算）
对每个候选 KOL：
  1. 拉取星图市场列表和受众画像
  2. 从公开视频分析内容与带货的匹配度
  3. 标记可疑互动（基于公开计数的比率启发式）
  4. 用标价和公开播放量估算单次播放成本
  5. 对比 brief 需求评分排序

数据需求：

星图端点（douyin/xingtu/*、douyin/xingtu-v2/*）
公开视频互动（douyin/app-v3/user-post-videos）
跨平台达人可用小红书蒲公英列表（xiaohongshu/pgy/*）

第 3、4 步是你的 Agent 自己的估算，不是平台给出的指标。实现模式参见小红书 KOL 筛选 Agent 教程。

机会三：直播电商优化 Agent

问题： 直播排期和商品排序常常靠直觉。

Agent 架构：

开播前：
  1. 查看同类创作者的公开直播历史
  2. 识别同时段竞品直播
  3. 推荐开播时间和时长
  4. 按预测互动排序商品列表

直播中（准实时）：
  5. 观察竞品直播间的公开信号
  6. 你的团队看到互动下降时，建议切换商品

数据需求：

公开直播间信息和直播视频（douyin/web/user-live-info-by-uid、douyin/web/user-live-videos）
同类创作者的公开视频历史
你自己直播间的销售数据在你自己的商家工具里，不在公开数据 API 中

机会四：跨平台价格情报 Agent

问题： 同一商品在抖音、小红书、天猫、京东以不同价格出现。品牌缺乏跨平台价格监控。

Agent 架构：

对每个监控 SKU：
  1. 在小红书商品列表和笔记中搜索价格信息
  2. 扫描抖音公开视频和评论里的价格提及
  3. 标记可能的未授权经销商
  4. 价格被压低时告警
  5. 给出调价建议

数据需求：

小红书商品搜索和详情（xiaohongshu/app-v2/search-products、xiaohongshu/app-v2/product-detail）
抖音视频搜索和评论（douyin/search/*、douyin/app-v3/video-comments）
跨平台商品匹配（按名称或图片）；天猫/京东数据不在这些目录中

机会五：社交舆情预警 Agent

问题： 中国社媒上的品牌危机可能在数小时内升级。人工监控跟不上节奏。

Agent 架构：

持续监控：
  1. 跨微博、抖音、小红书追踪品牌/商品提及
  2. 对新提及做情绪分析
  3. 声量异常检测（突增 = 潜在危机）
  4. 升级评分（KOL 放大 + 负面情绪 + 声量）
  5. 升级分数过阈值立即告警

数据需求：

微博实时搜索和热搜（weibo/web-v2/realtime-search、weibo/web-v2/hot-search）
抖音评论和视频搜索
小红书笔记搜索
跨平台声量聚合（你自己实现）

Agent 驱动社交电商的经济账

竞品情报 Agent 运行成本

以下是一个示例工作负载的估算。数据端点：截至 2026-10-01，目录把这里用到的四个端点都标为 Free（douyin/app-v3/user-profile、douyin/app-v3/multi-video-statistics、xiaohongshu/app-v2/search-notes、weibo/web-v2/realtime-search）。价格可能调整，做预算前请看各自的模型卡片，也不要假设文档之外的配额。有一处不一致需要知道：multi-video-statistics 参考文档的描述里仍留着一行上游文字「Price: 0.025$ each time」，而截至 2026-10-01，目录和模型页（「Base price Free」）都标为 Free。

在 SandBase 统一这两处之前，这个工作负载的数据 API 成本应视为未核实，而不是零。下面的负载每月调用 multi-video-statistics 144,000 次；如果按参考文档里的上游价格计算，仅这一项就是 144,000 × $0.025 = $3,600/月。其余三个端点在 2026-10-01 查看时没有这种冲突。下面的 LLM 估算是唯一价格已核实的部分。

截图：douyin/app-v3/multi-video-statistics 模型页，显示 Base price Free、sync 执行和 1 个输入字段（aweme_ids，最多 50 个 ID）（2026-10-02 截取）。

每小时监控周期：
  - 50 次抖音主页查询         （douyin/app-v3/user-profile）
  - 200 次视频统计调用        （douyin/app-v3/multi-video-statistics）
  - 30 次小红书搜索           （xiaohongshu/app-v2/search-notes）
  - 20 次微博搜索             （weibo/web-v2/realtime-search）
  每周期小计：300 次数据调用

日（24 周期）：7,200 次数据调用
月（30 天）：216,000 次数据调用（数据 API 成本：未核实，见上文）

LLM 推理（假设：每天 100 次调用，每次 3,000 输入 + 500 输出 token，
30 天合计 900 万输入 + 150 万输出 token），按 2026-10-01 的 SandBase 价格：
  - openai/gpt-4.1-mini（输入 $0.40/M，输出 $1.60/M）：9 × 0.40 + 1.5 × 1.60 = $6.00/月
  - openai/gpt-4o（输入 $2.50/M，输出 $10/M）：9 × 2.50 + 1.5 × 10 = $37.50/月

和人类分析师做同样的检查相比，Agent 每小时全天候覆盖 50 个账号。它不替代「看到信号后该怎么办」的判断，而是把收集和初筛这部分工作拿掉。

解锁机会需要什么

1. 更广的电商覆盖

店铺分析、直播电商指标和商品目录数据在公开数据 API 里仍然不足；比如抖音目录目前就没有专门的店铺端点。

2. 更好的跨平台身份关联

Agent 需要跨平台关联创作者和商品。抖音大 V 可能也在小红书，商品以不同名称出现。身份关联能解锁跨平台分析。

3. 历史数据访问

多数 API 返回当前状态。做战略决策的 Agent 需要 30/60/90 天的互动、粉丝增长、内容产出轨迹，目前通常要靠自己存快照。

4. 事件驱动数据推送

超越轮询，Agent 受益于推送数据：监控指标过阈值时收到通知，减少不必要的调用。

5. 合规基础设施

Agent 需要清晰的数据溯源、用途日志；涉及个人信息时，还需要合法的处理依据。这是基础设施，不是功能。

想动手试试：创建 SandBase API Key、浏览抖音目录，或打开 user-post-videos 端点参考。

结论

中国社交电商是 AI Agent 尚未规模进入的大型商业机会。公开信号已经存在：内容互动、达人列表、排行榜，以及围绕每个商品和创作者的讨论。瓶颈不是智能（LLM 已足够能干），也不是需求，而是以 Agent 速度访问结构化数据。

解决访问层的平台，即在中国社交平台上提供可靠、有文档、标准化的公开数据 API，将使下一代商业 Agent 成为可能。机会窗口就是现在：

Agent 框架在 2025–2026 年进入生产使用
结构化公开数据端点已用一个 Key 覆盖主要中国社交平台
越早开始积累历史数据的团队，数据优势越会复利

对开发者和创业者来说，中国社交电商中的 Agent 机会是架构性的，不是算法性的。难题不是「造更聪明的模型」，而是「让抖音、小红书和微博的结构化数据进入 Agent 的决策循环」。解决这个，这些商业活动的很大一部分就变得可编程。

市场

为什么 Agent 需要这些数据

数据格局：有什么可用

抖音电商数据

小红书电商数据

微博电商数据

瓶颈：数据访问架构

不可行的方案

可行的方案

五大 Agent 机会

机会一：商品趋势检测 Agent

机会二：KOL 筛选和审核 Agent

机会三：直播电商优化 Agent

机会四：跨平台价格情报 Agent

机会五：社交舆情预警 Agent

Agent 驱动社交电商的经济账

竞品情报 Agent 运行成本

解锁机会需要什么

1. 更广的电商覆盖

2. 更好的跨平台身份关联

3. 历史数据访问

4. 事件驱动数据推送

5. 合规基础设施

结论

延伸阅读