# Airbyte MCP 接社媒数据：差评和退货合表

> Airbyte MCP 查得了仓库里的订单退货，查不了公开评论；我们接上 EveryInfra 实测 63 条差评只有 3 条能追到订单，附合表做法和月费。

- Canonical page: https://everyinfra.com/blog/airbyte-mcp-social-data-agent
- Published: 2026-11-10T01:31:00+08:00 · Fact-checked: 2026-11-10T01:30:00+08:00

Airbyte 在 2026 年 10 月 27 日发布的 Airbyte MCP 能让 Claude、ChatGPT 直接查 Airbyte 同步进 BigQuery 或 Snowflake 的订单和退货，但它的工具里没有一个能读公开网页上的评论；我们在 2026 年 11 月 10 日 00:15 到 00:30（新加坡时间）本机启动了它的开源版，47 个工具逐个核过，确认这一点。把 EveryInfra 的远程 MCP 挂进同一个 agent，拉回三个品牌 71 条 Trustpilot 评价，其中 1–2 星 63 条，只有 3 条是经商家邀请来的、商家后台能用参考号追到订单，另外 60 条是用户自发写的，正文里出现订单号的是 0 条。所以「哪条差评对应哪张退单」逐条做不出来，能做的是按「商品 × 周」把退货数和差评数并排放：71 条里有 47 条在体验日期之后 7 天内发出，用 7 天窗口能对上三分之二。社媒这一侧，当晚已跑通的 Trustpilot 和 Reddit 一个店铺一个月约 $0.09；再加 20 个商品的 Amazon 评价约 $0.93，但 Amazon 评价当晚没拿到数据。账单的大头是 Airbyte 同步订单的套餐。

> **本文要点**
>
> - Airbyte MCP 于 2026-10-27 发布，托管地址 `https://mcp.airbyte.com/mcp`，用 OAuth 登录；context layer 的直接读取和检索每个组织每月 10 万次以内免费，只在 Airbyte Cloud 上有，查仓库只认 BigQuery、Snowflake 的只读 `SELECT`。
> - 本机 `uvx --from=airbyte@latest airbyte-mcp` 解析到 airbyte 0.71.3，`tools/list` 返回 47 个工具、97,251 字节定义，没有一个读公开评论；它的工具名还带 `cloud`，和 11-06 改过名的官方文档对不上。
> - 三个品牌 63 条 1–2 星 Trustpilot 评价：商家邀请来的 3 条，自发的 60 条，正文里带订单号的 0 条。逐单对不上，只能按商品和时间窗合表。
> - 体验日期到发评价的间隔中位 1.81 天，71 条里 47 条在 7 天内、64 条在 30 天内；退货表用 `processed_at`、评价用 `experience_at`，按周对齐。
> - 当晚真调 `trustpilot/reviews` 5 次计费，每次 $0.001389，最多 200 行；`amazon/reviews` 3 次没拿到数据，两次 503、一次空结果，全部没扣费。

![示意插图：一个圆脸小机器人坐在桌前，左手的青绿色线缆插在一摞数据库圆柱上，圆柱旁边是一个贴着回转箭头的纸箱；右手的灰色线缆插进一团由空白对话气泡和星形徽章组成的云；桌上放着一张两栏的表，中间一行是青绿色。](https://everyinfra.com/articles/airbyte-mcp-social-data-agent/img-explain.webp)

一只手接仓库里的订单和退货，一只手接公开评论，两边在同一张表的同一行里见面。

这篇文章要回答的问题很具体：你的店铺用 Shopify 卖货，订单和退款已经由 Airbyte 同步进了 BigQuery 或 Snowflake，客服在问「最近退货多的那几款，网上的差评都在说什么」。Airbyte MCP 能把仓库里的那一半交给 agent，公开评论那一半它拿不到。本文先用 Airbyte 的官方文档和本机实测把它能做什么、不能做什么讲清，再用 EveryInfra 的 `trustpilot/reviews`、`amazon/reviews`、`amazon/search`、`reddit/search` 真调拿回评论，量出两边能靠什么字段对上，最后给出两个 MCP 一起挂的配置、合表的 SQL 和一个月的账。Airbyte Cloud 一侧我们没有账号，凡是没跑过的步骤都写成「配置示例」；EveryInfra 一侧每个数字都来自当晚的真实返回。

我们选的三个品牌各有理由。Allbirds 是美国的直营鞋履品牌，2026 年 3 月 29 日签了资产出售协议（[SEC 8-K，2026-03-29](https://www.sec.gov/Archives/edgar/data/1653909/000162828026022181/bird-20260329.htm)），6 月 9 日提交了交易完成的 8-K（[SEC 8-K，2026-06-09](https://www.sec.gov/Archives/edgar/data/1653909/000162828026043145/bird-20260609.htm)），换主人以后的客服和退货体验正是评论区最集中的话题。Anker 是中国出海的消费电子品牌，产品型号多、评论里常写型号，适合看「评论能不能落到具体商品」。Ecoalf 是西班牙的环保服装品牌，评论几乎全是西语，用来检验同一套做法换个语言还成不成立。三家都在 Trustpilot 上有公开主页，评价是公开内容；本文只引用标题和统计，不写任何评论人的名字。

## airbyte mcp 是什么：10 月 27 日发布的托管 MCP 和 context layer

Airbyte 在 2026 年 10 月 27 日的新闻稿里说，新的 MCP 服务器让用户用 Claude、Cursor、ChatGPT 这类助手直接和数据对话、监控同步任务、排查和修复故障，CEO Michel Tricot 称 MCP 是公司五年多来被要求最多的功能（[Business Wire 新闻稿，2026-10-27](https://www.businesswire.com/news/home/20261027843580/en/New-Airbyte-MCP-Server-Lets-Users-Chat-with-Their-Data-Simplifies-Pipeline-Management-and-Improves-User-Experience)）。同一份新闻稿写明，Airbyte Cloud 和 Enterprise Flex 用户还能通过 MCP 用上新的 context layer：在 Snowflake 和 BigQuery 目标库上直接查询由 50 多个来源 connector 同步进来的数据，例子是「哪些客户账户还有没关的工单」。Airbyte 官方博客同日发文，标题把 MCP 和 context layer 放在一起，页面显示 11 月 4 日更新过一次（[Airbyte 博客，2026-10-27](https://airbyte.com/blog/airbyte-mcp)）。同一天 Airbyte 在 YouTube 发了一支 1 分 21 秒的演示视频，按顺序演示把 MCP 加进 agent、建来源（视频里说可选 600 多个 connector）、建目标库、建连接并同步、让 agent 读日志排查失败的同步，最后对数据提问；到 11 月 10 日这支视频播放约 3.7 万次（[Airbyte 官方演示视频，2026-10-27](https://www.youtube.com/watch?v=C4-eGrBePUQ)）。视频里没有出现任何读取公开网页或社媒评论的步骤，这和下文本机数工具的结果一致。

产品文档把它能做的事分成六类：建管道、排查管道、从来源和目标库直接读数据、通过 connector skill 了解每个 connector 的参数、在 Airbyte Cloud 里检索已同步的数据、回答关于 Airbyte 本身的问题（[Airbyte MCP 文档](https://docs.airbyte.com/platform/airbyte-mcp)）。用量限制写在同一页：每个组织每月直接读取和检索合计 10 万次以内不收费，管理连接、读日志这类工具不计入；直接读取还会消耗来源 API 的限速额度，查目标库会产生目标库的计算费。文档的限制一节写得很直白：托管版只给 Airbyte Cloud 和 Flex 用，自管的 Airbyte Core 要在本机跑，而且有已知问题；直接读取和检索都是只读的。

读文档时有一件事值得先弄清：这次发布的到底是哪一个产品。我们翻了 Airbyte 主仓里 `docs/platform/airbyte-mcp` 目录的提交历史，时间线比新闻稿长，而且中间撤掉过一个产品名。下表每一行都能在 GitHub 上打开原始提交。

| 日期（UTC） | 事件 | 对读者意味着什么 | 出处 |
| --- | --- | --- | --- |
| 2026-10-02 | 文档首次加入 Airbyte MCP 和 context layer，标注私测 | 10 月初的教程基于私测版，界面和工具名可能已变 | [PR #87633](https://github.com/airbytehq/airbyte/pull/87633) |
| 2026-10-14 | 转为公开测试 | 不再需要邀请，Cloud 账户都能连 | [PR #88922](https://github.com/airbytehq/airbyte/pull/88922) |
| 2026-10-27 | 删掉 beta 字样，与新闻稿同日 | 这一天之后才算正式提供 | [PR #89777](https://github.com/airbytehq/airbyte/pull/89777) |
| 2026-10-30 | 托管版支持 `?read-only=true`；同日撤下 Airbyte Agents 文档 | 不能发自定义请求头的客户端也能只读；旧的 Agents 教程别再照做 | [PR #90250](https://github.com/airbytehq/airbyte/pull/90250)、[PR #89805](https://github.com/airbytehq/airbyte/pull/89805) |
| 2026-11-03 | 补上 context layer 检索的文档 | 关键词、语义、混合三种检索可以用了 | [PR #90239](https://github.com/airbytehq/airbyte/pull/90239) |
| 2026-11-06 | 工具名去掉 `cloud` 前缀 | 写死在提示词或白名单里的旧工具名会失效 | [PR #91190](https://github.com/airbytehq/airbyte/pull/91190) |
| 2026-11-09 | 文档写入 insiders 工具和 `?insiders=true` | 新工具先在 insiders 里出现，默认隐藏 | [PR #91203](https://github.com/airbytehq/airbyte/pull/91203) |

表里 10 月 30 日撤下的 Airbyte Agents，是 Airbyte 半年前在 Hacker News 上发布的「给 agent 的统一数据层」，当时 CEO 在帖子里说，一个本该回答「这个季度哪些客户可能流失」的 agent 跑了 47 步，大多是 API 调用，最后答案听起来对、其实是错的（[Show HN: Airbyte Agents](https://news.ycombinator.com/item?id=48023496)）。那次发布配了一个公开的基准测试仓库，比较经 Airbyte 调用和直接调各家厂商 MCP 的 token 消耗（[airbyte-agents-benchmarks](https://github.com/airbytehq/airbyte-agents-benchmarks)）。现在这套思路并进了 Airbyte MCP 和 context layer：同步进来的数据建索引给 agent 检索，实时的记录由 connector 直接读。对本文的读者来说，搜到 2026 年 5 月前后讲「Airbyte Agents」的教程时要留意，它们的安装方式和现在的托管 MCP 不是一回事。

![截图：Airbyte 文档「Airbyte MCP tools」页的 Direct reads 表格，用青绿框标出三行：get_external_access_skill_docs 读 connector 的 skill 文档；execute_external_api_query 从来源 API 读实时记录，支持 list、get、search；execute_external_sql_query 在 Snowflake 或 BigQuery 目标库上跑只读 SQL，只支持 SELECT、WITH 和 SHOW TABLES、SHOW DATABASES、DESCRIBE TABLE。](https://everyinfra.com/articles/airbyte-mcp-social-data-agent/img-shot-airbyte-direct-reads.webp)

Airbyte MCP 的三个直接读取工具：读的都是你自己配好的来源和目标库。 [Airbyte 文档截图](https://docs.airbyte.com/platform/airbyte-mcp/tools)

三个工具读的都是你在 Airbyte 里已经配置好凭据的来源和目标库：`execute_external_api_query` 读 Zendesk、HubSpot 这类来源的实时记录，`execute_external_sql_query` 在 BigQuery 或 Snowflake 上跑只读 SQL（[Airbyte MCP tools](https://docs.airbyte.com/platform/airbyte-mcp/tools)）。context layer 的说明页把三种取数方式并排比较：复制进仓库的数据新鲜度等于最近一次同步，适合历史分析和关联；直接读取的新鲜度等于这次请求，不需要建连接；检索的新鲜度等于最近一次建索引（[Context layer 文档](https://docs.airbyte.com/platform/context-layer)）。

## airbyte mcp server 能不能读公开评论：我们本机跑了一遍

文档列了工具，但文档会变，所以我们让本机直接回答。Airbyte 给自管 Core 的接法是在 MCP 客户端里用 `uvx --from=airbyte@latest airbyte-mcp` 启动本地服务（[在 Airbyte Core 上用 Airbyte MCP](https://docs.airbyte.com/platform/airbyte-mcp/self-managed)）。我们在 2026 年 11 月 10 日 00:15（新加坡时间）照这条命令起了服务，环境变量填了占位值，只发 `initialize` 和 `tools/list` 两个请求，不连任何 Airbyte 部署。首次启动连下载依赖用了 32.0 秒，服务自报名字 `airbyte-mcp`，所用 MCP 框架版本 3.4.11，协议版本 2025-06-18。

`tools/list` 返回 47 个工具。按 MCP 规范，工具可以带只读、破坏性等行为标注，客户端据此决定要不要先问用户（[MCP 规范：Tools](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)）；47 个里标了只读的 25 个，标了破坏性的 12 个。逐个看名字和说明，它们全部围绕 Airbyte 自己的对象：工作区、组织、来源、目标库、连接、同步任务、自定义 connector 和 connector 注册表。没有一个工具接受网址、关键词或店铺名去取外部网页，更没有读 Trustpilot、Amazon、Reddit 评论的工具。本机版也没有截图里的三个直接读取工具，这和自管文档的说法一致：context layer、直接读取、检索和 connector skill 都只在 Airbyte Cloud 上有。

本机跑出来还有一个文档里看不到的细节。`airbyte@latest` 在当时解析到的是 PyPI 上的稳定版 0.71.3，发布于 2026 年 10 月 26 日（[PyPI：airbyte](https://pypi.org/project/airbyte/)）；它的 47 个工具里 36 个名字带 `cloud`，例如 `list_deployed_cloud_connections`、`run_cloud_sync`。而官方工具页在 11 月 6 日已经把名字改成不带前缀的 `list_connections`、`run_connection_sync`（[PR #91190](https://github.com/airbytehq/airbyte/pull/91190)）。同一个包的 1.0 候选版在 11 月 6 日已经出到 rc42，PyAirbyte 仓库 11 月 2 日到 6 日之间合并了一串 MCP 相关的改动，包括为了通过 OpenAI 的审核放宽「破坏性」的定义（[PyAirbyte PR #1441](https://github.com/airbytehq/PyAirbyte/pull/1441)）、增加 `?insiders=true` 参数（[PyAirbyte PR #1456](https://github.com/airbytehq/PyAirbyte/pull/1456)）。如果你在提示词、审批白名单或审计脚本里写死了工具名，托管版和本机版要分开写，升级后再核一次。

![横向条形图，单位字节：Airbyte MCP 本机版 47 个工具的定义 97,251 字节；只留 25 个只读工具 51,596 字节；EveryInfra MCP 12 个工具 16,261 字节；只留 3 个取数工具 3,250 字节，这一根是青绿色。标题说两个 MCP 一起挂，工具定义约 11.4 万字节，Airbyte 占 86%。](https://everyinfra.com/articles/airbyte-mcp-social-data-agent/fig-03-tool-defs-bar.zh.light.svg)

两个 MCP 一起挂，工具定义本身就要占上下文。上图按紧凑 JSON 量了字节：Airbyte 本机版 47 个工具 97,251 字节，其中说明文字 43,196 字节，47 个工具全都带输出结构定义；EveryInfra 远程 MCP 12 个工具 16,261 字节，两边合计约 11.4 万字节，按常用的 4 字节约 1 个 token 粗算是两万八千多个 token。Claude Code 默认开着工具搜索，工具定义按需加载，影响小一些；不支持按需加载的客户端，每一轮都要背着这些定义。两边都有收窄的办法：Airbyte 托管版用 `?read-only=true` 只给只读工具，或用 `X-MCP-Include-Modules` 只开某几个模块（[Airbyte MCP 高级配置](https://docs.airbyte.com/platform/airbyte-mcp/advanced-configuration)）；EveryInfra 这边真正取数只用得到 `everyinfra_list_capabilities`、`everyinfra_call_api`、`everyinfra_get_job` 三个工具，合计 3,250 字节。

## 未登录时托管地址回什么：OAuth 发现，和「Claude 发不了请求头」

托管版的认证我们也直接问了服务器。00:14（新加坡时间）向 `https://mcp.airbyte.com/mcp` 发一个不带凭据的 `initialize`，返回 401，响应头里的 `www-authenticate` 写着 `resource_metadata="https://mcp.airbyte.com/.well-known/oauth-protected-resource/mcp"`；去这个地址取，返回 200，内容是资源地址、授权服务器 `https://mcp.airbyte.com/`、三个 scope（openid、email、profile）和「令牌放在请求头里」。根路径的 `/.well-known/oauth-protected-resource` 则是 404。这正是 MCP 授权规范要求的做法：服务器必须实现 OAuth 2.0 受保护资源元数据，客户端用它找授权服务器（[MCP 规范：Authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)）；而按 RFC 9728，资源地址带路径时，元数据地址是把 `/.well-known/oauth-protected-resource` 插在主机名和路径之间（[RFC 9728](https://www.rfc-editor.org/rfc/rfc9728)），所以根路径 404 是对的。自己写客户端或代理层的团队，别去根路径找。

Airbyte 文档给了两种登录：有人在场的用浏览器 OAuth，客户端自动注册，不用填任何客户端 ID；无人值守的 agent、脚本和 CI 用 Airbyte 应用的 `Client-Id`、`Client-Secret` 两个请求头，服务器每次请求自己换令牌（[安装 Airbyte MCP](https://docs.airbyte.com/platform/airbyte-mcp/install)）。文档还提醒，应用以创建它的那个用户的权限行事，所以最好用服务账号；14 天不用要重新登录。高级配置页特别说了一句，Claude 这类客户端不能发自定义请求头，部分设置只能用网址参数代替，只读模式就是 `?read-only=true`（[Airbyte MCP 高级配置](https://docs.airbyte.com/platform/airbyte-mcp/advanced-configuration)）。这对本文的场景有直接影响：在 claude.ai 或 Claude Desktop 里加自定义连接器，连接是从 Anthropic 的云端发起的，服务器必须能从公网访问（[Claude 帮助中心：自定义连接器](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp)），而像「隐藏破坏性工具」「只开 cloud 模块」这些只有请求头才能设的开关，在 Claude 网页版里用不上，只读网址参数是唯一的收窄手段。

## 两个 MCP 放进一个 agent：配置示例

![流程动画：顶部是 Claude、ChatGPT 或 Cursor 里的同一个 agent；左边一列从上到下是 Airbyte MCP（mcp.airbyte.com，OAuth）、BigQuery 或 Snowflake 的 execute_external_sql_query（只读）、由 Airbyte 同步的 Shopify 表 orders 和 order_refunds；右边一列是 EveryInfra MCP（api.everyinfra.com，API Key）、everyinfra_call_api 调 trustpilot/reviews 和 amazon/reviews、公开评论和提及；两列的结果汇到底部「合表：商品 × 周」，左边是退货数和退货原因，右边是差评数和差评类别。灰色和青绿色的小圆点分别沿左右两条路走下来，汇入底部的表。](https://everyinfra.com/articles/airbyte-mcp-social-data-agent/fig-02-two-mcp-flow.zh.light.svg)

下面是 Claude Code 的项目级配置示例，放在仓库根目录的 `.mcp.json`。Airbyte 用只读网址，第一次连接时 Claude Code 会打开浏览器让你登录 Airbyte Cloud；EveryInfra 用 API Key，放在 `Authorization: Bearer` 请求头里，用环境变量展开，不写进文件；不能发请求头的客户端，看 [MCP 服务器页](/mcp-server) 的接法。两边认证方式不同，放在同一个 agent 里互不影响。Claude Code 支持在 `url` 和 `headers` 里用 `${VAR}` 引用环境变量，变量没设时会在 `/mcp` 里报警告（[Claude Code MCP 文档](https://code.claude.com/docs/en/mcp)）。这一段我们没有在连着 Airbyte Cloud 的环境里跑过，属于配置示例；EveryInfra 一半的地址和请求头和我们当晚真调用的一致。

```text
{
  "mcpServers": {
    "airbyte": {
      "type": "http",
      "url": "https://mcp.airbyte.com/mcp?read-only=true"
    },
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" }
    }
  }
}
```

只读网址是这个场景的正确默认值。Airbyte 的安全一节写明，删除工具只对名字里带 `delete-me` 或 `deleteme` 的资源生效，并且每个工具都会告诉客户端它是只读还是破坏性的（[Airbyte MCP tools：Safety](https://docs.airbyte.com/platform/airbyte-mcp/tools)）；但一个只想回答「差评和退货」的 agent 根本不需要碰管道，开只读最省事，也让工具定义少一半。要让 agent 能读仓库，还需要组织管理员在 Airbyte 里打开 agent access，并且目标库得是 BigQuery 或 Snowflake，只允许 `SELECT` 和 `SHOW TABLES`（[Agent access 文档](https://docs.airbyte.com/platform/context-layer/agent-access)）。

第二个要调的是工具输出的上限。Claude Code 在单次 MCP 工具输出超过 10,000 token 时提示，默认上限 25,000 token，可以用 `MAX_MCP_OUTPUT_TOKENS` 调高（[Claude Code MCP 文档](https://code.claude.com/docs/en/mcp)）。我们当晚经 MCP 调 `trustpilot/reviews` 返回 20 条评价，工具结果的文本是 24,265 个字符，按 4 字节约 1 token 估算约六千 token，离提示线还远；但把 `limit` 开到 200、或者一次拉几十个商品的评论，就会撞上。评价正文本身不短：当晚三组样本的正文长度中位数，Allbirds 396 个字符，Anker 572 个，Ecoalf 430 个左右，Anker 的差评往往把买了什么、坏在哪、客服怎么回一路写下来，越长的正文越吃上限。我们的建议是让 agent 在仓库那一侧先聚合，评论这一侧按商品分批拉，每批只把计数和几条代表性标题放回对话。

## 公开评论这一侧：当晚的真调

EveryInfra 的能力名、参数和价格先从免费目录读：`GET /api/v1/social/catalog`，00:14（新加坡时间）读取，当时目录里一共是 106 个平台的 573 项能力。`trustpilot/reviews` 必填 `company`（公司官网域名），可选 `stars`、`date`、`sort`、`lang`、`verified_only`，默认返回 20 条、最多 200 条，一次调用按一次计费，$0.001389（[Trustpilot 评价接口](/trustpilot-api/reviews)）。`amazon/reviews` 必填商品链接，最多 100 条，同价（[Amazon 评价接口](/amazon-api/reviews)）。下表是当晚每一次调用，时间都是新加坡时间，扣费取响应里的 `charged_usd`。

| 时间（新加坡时间） | 能力 | 参数要点 | 结果 | 扣费 |
| --- | --- | --- | --- | --- |
| 00:15 | `trustpilot/reviews` | allbirds.com，1–2 星，近 3 个月 | 20 行 | $0.001389 |
| 00:16 | `trustpilot/reviews` | allbirds.com，全部星级，近 30 天 | 503，`retry_after` 20 秒 | $0 |
| 00:16、00:18 | `amazon/search` | allbirds tree runner | 各 10 行（重复跑了一次） | 各 $0.002236 |
| 00:19 | `reddit/search` | allbirds return，按最新 | 0 行，空结果 | $0 |
| 00:21 | `trustpilot/reviews` | anker.com，1–2 星，近 3 个月 | 20 行 | $0.001389 |
| 00:22 | `trustpilot/reviews` | ecoalf.com，西语，近 12 个月 | 20 行 | $0.001389 |
| 00:22 | `trustpilot/reviews` | date 写成 last14days | 422，给出可选值和最接近的两个 | $0 |
| 00:22 | `trustpilot/reviews` | allbirds.com，全部星级，近 3 个月，limit 200 | 31 行 | $0.001389 |
| 00:23、00:25 | `amazon/reviews` | 两个 Tree Runner 的 ASIN，limit 100 | 都是 503 | $0 |
| 00:26 | MCP `everyinfra_call_api` | 同第一行参数 | 20 行，和 REST 同 id 同顺序 | $0.001389 |
| 00:28 | `amazon/reviews` | async 模式重试 | 00:30 完成，0 行，预扣已退 | $0 |
| 00:42 | `jd/search` | 安克 充电宝 | 5 行 | $0.002472 |
| 00:42 | `jd/reviews` | 搜索结果第一个 item_id | 10 行 | $0.001389 |

这张表本身就说明了三件和扣费有关的事。第一，失败不扣费：503 的响应体写着「Not charged」并给出 `retry_after`，422 的响应体列出 `allowed` 和 `did_you_mean`，原文是「Change only `date` to a value in `allowed`, then resend. Nothing was charged.」。第二，空结果不扣费：`reddit/search` 回 0 行，扣费是 0；`amazon/reviews` 走 async 时先预扣，任务完成但 0 行，`refund_state` 变成 `refunded`。第三，`trustpilot/reviews` 的 `limit` 开到 200 和默认 20 条是同一个价，Allbirds 近 3 个月一共只有 31 条评价，一次就拉全了，摊到每条约 $0.0000448。中间还有 6 次请求被 429 挡回，因为测试 Key 每分钟限 10 次，这类请求同样不计费。

![截图：两段真实的接口返回。上面一段是 HTTP 422，date 写成 last14days 时返回的 error 对象，青绿框标出 did_you_mean 给的 last7days 和 last30days，以及 next_steps 里的「Nothing was charged.」；下面一段是 HTTP 200，Allbirds 近 3 个月全部评价，青绿框标出 count 31 和 charged_usd 0.001389。标题栏写着 2026-11-10 00:22 SGT。](https://everyinfra.com/articles/airbyte-mcp-social-data-agent/img-shot-ei-response.webp)

同一分钟里的两次调用：参数写错时先告诉你能填什么、不扣费；改对以后 31 条一次拉全，扣一次的钱。 [EveryInfra 接口真实返回截图](https://api.everyinfra.com/api/v1/social/catalog)

MCP 往返和 REST 是同一个结果。00:26 经 MCP 的 `tools/call` 调 `everyinfra_call_api`，参数和 00:15 那次 REST 完全一样，返回的 20 条评价 id 与 REST 20/20 相同、顺序也相同，扣费同为 $0.001389。下面是这次往返里模型发出的调用，以及返回体里和合表有关的那几个字段（截取第一条，评论人名字已删去）。

```text
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"everyinfra_call_api",
 "arguments":{"platform":"trustpilot","action":"reviews",
  "params":{"company":"allbirds.com","stars":["1","2"],"date":"last3months"}}}}

{"id":"6aef3ce784d3a1aee4e3841a","rating":1,"title":"Customer Service not Customer Satisfaction",
 "language":"en","is_verified":false,"verification_level":"not-verified","source":"Organic",
 "country":"US","experience_at":"2026-11-05T00:00:00+00:00","posted_at":"2026-11-07T16:59:51+00:00",
 "company_domain":"allbirds.com","rating_scale":5}
```

Amazon 一侧当晚没拿到评论，但 `amazon/search` 给了一个合表必须知道的事实。搜「allbirds tree runner」返回的 10 条结果是 10 个不同的 ASIN：8 条是 Tree Runner，男款几条共享 779 个评分、女款几条共享 746 个评分；另 2 条是 Tree Runner Go，评分数分别是 236 和 292（[Amazon 搜索接口](/amazon-api/search)）。也就是说，同一款鞋的不同颜色、尺码各有一个 ASIN，评价挂在父商品上共享，10 个 ASIN 背后只有 4 个父商品。标价大多在 $50 到 $100 之间，有一条是 $1,642.72，明显是异常标价，算均价前要先剔掉。你的 Shopify 订单行里是 `product_id` 和 `variant_id`，Amazon 评价里是 `product_asin` 和 `variant`，两边要先建一张「父商品 ↔ 子 ASIN ↔ Shopify 变体」的对照表，否则按 ASIN 直接关联会把同一款鞋拆成十份。《[Snowflake Cortex Agents MCP：社媒差评和退货怎么进一张表](/blog/snowflake-cortex-agents-mcp-social-reviews)》那篇在 11 月 6 日也遇到过 `amazon/reviews` 503 和空结果，所以本文的结论只用 Trustpilot 的数据；Amazon 评价建议先拿一两个 ASIN 试通，再排进定时任务。

## 换一个平台看关联键：京东评价带着规格

Trustpilot 是「给公司打分」，关联键天然粗。为了看清关联键到底取决于什么，我们同一晚换了一个按商品打分的平台做对照：00:42（新加坡时间）用 `jd/search` 搜「安克 充电宝」，再拿第一个结果的 `item_id` 调 `jd/reviews`（[京东搜索接口](/jd-api/search)、[京东评价接口](/jd-api/reviews)）。两次都是 200，搜索 5 行扣 $0.002472，评价 10 行扣 $0.001389。选 Anker 是因为它也是我们在 Trustpilot 上拉过差评的三家之一，同一个品牌在两种评价平台上的字段可以直接比。下表只列和关联有关的字段，数值都来自当晚的两份原始返回。

| 字段 | 京东 `jd/reviews`（Anker 一款充电宝，10 条） | Trustpilot `trustpilot/reviews`（anker.com，20 条 1 星） | 对关联的意义 |
| --- | --- | --- | --- |
| 商品 | `item_id` 10/10 都有，就是你调用时传的那个 | 没有商品字段，评价对象是公司 | 京东可以直接对到商品，Trustpilot 要从正文里猜 |
| 规格 | `color` 和 `size` 10/10 非空，10 条都是同一个颜色容量和同一个功率版本 | 没有 | 京东能对到 Shopify 里 `variant_id` 那一层 |
| 时间 | `posted_at` 精确到秒，11-07 12:26 到 11-09 16:28，不带时区 | `posted_at` 带时区，另有只到日的 `experience_at` | Trustpilot 多一个「体验日期」，京东只有发评时间 |
| 购买量 | `buy_count`：7 条是 1，另外 3 条是 2、5、30 | 没有 | 京东能看出是不是批量采购的买家 |
| 来源 | 没有邀请或验证字段 | `source`、`verification_level` | Trustpilot 能分出经商家邀请的那一小部分 |
| 订单号 | 没有 | 没有 | 两边都不能逐单对 |

这张表的结论是：关联键的粗细取决于评价平台「评的是什么」，而不是取决于用哪个 MCP 去拉。京东的评价挂在具体商品上，并且记着买家下单时选的规格，所以能直接按「商品 × 规格 × 周」和仓库里的订单行合表，比 Trustpilot 的「品牌 × 周」细两层，也就是从「这个牌子这周口碑怎样」细到「这一款这个颜色这周口碑怎样」；但它同样没有订单号，逐单关联照样做不了。这和上一节 Amazon 那件事是一回事：一个父商品下面挂着很多规格，评价共享在父商品上，京东则在每条评价里把规格写出来了，所以反而更好对。

京东评价每条都带 `item_id`、`color`、`size`，能细到「商品 × 规格 × 周」，但同样没有订单号，逐单关联照样做不了。`jd/reviews` 也没有按星级筛选的参数，当晚最新的 10 条全是 5 星、其中 3 条没写正文，找差评要往后翻页或者在仓库里过滤；空评价算不算进「差评率」的分母，要在合表之前定下来。

## 逐单对不上：63 条差评里只有 3 条来自商家邀请

「哪条差评对应哪张退单」要逐条做，评价里得有能指回订单的东西：订单号、或者至少一个商家能查到的参考号。我们逐条看了三家共 71 条 Trustpilot 评价的字段。`trustpilot/reviews` 每条都带 `id`、`rating`、`posted_at`、`experience_at`、`country`、`source`、`verification_level`，71 条全部非空（当晚没有走备用数据源；目录的字段说明写着，备用源返回时 `experience_at`、`source` 等字段可能缺失）。真正决定能不能追到订单的是 `source`：`Organic` 是用户自己找上门写的；`Shopify`、`InvitationApi`、`BasicLink` 是商家通过集成或链接发出的邀请。

![堆叠条形图：三个品牌的 1–2 星评价按来源拆开。Allbirds 26 条，自发 25 条、经商家邀请 1 条；Anker 20 条，自发 18 条、经商家邀请 2 条；Ecoalf 17 条，全部自发、经商家邀请 0 条。经商家邀请的部分用青绿色。标题：63 条 1–2 星评价里，只有 3 条来自商家的邀请或订单系统。](https://everyinfra.com/articles/airbyte-mcp-social-data-agent/fig-04-review-source-bar.zh.light.svg)

结果如上图。Allbirds 近 3 个月 31 条评价里，5 条来自 Shopify 集成、标为已验证，其中 4 条是 5 星、1 条是 1 星；26 条自发评价里 25 条是 1–2 星。换句话说，能追到订单的那 5 条几乎都是好评，差评几乎都在追不到的那一边。再看这 31 条不筛星级的评价，分布是两头大、中间空：1 星 21 条、2 星 5 条、5 星 5 条，3 星和 4 星一条都没有。按来源拆：26 条自发评价里 25 条是 1–2 星、只有 1 条 5 星；5 条 Shopify 邀请来的评价里 4 条是 5 星、1 条是 1 星。也就是说，主动来 Trustpilot 写评价的人几乎都是来投诉的，经邀请写评价的人大多给好评，两种来源的星级分布完全不是一回事。合表时如果把两种来源混在一起算平均分，平均分的涨跌只反映这周商家发了多少邀请，不反映商品变好还是变坏，所以 `source` 要作为单独一列留着。Anker 近 3 个月的 20 条 1 星评价里，1 条经 InvitationApi 来、标为已验证，1 条经 BasicLink 来、标为「invited」，其余 18 条自发。Ecoalf 的 20 条西语评价全部是自发。三家合计 63 条 1–2 星，经商家邀请的 3 条，占 4.8%；71 条正文里出现订单号的 0 条（我们用「order #」「order number」「pedido」后跟 4 位以上数字的规则扫，0 命中）。

为什么经邀请的评价能追到订单？Trustpilot 的帮助文档写明，商家手动上传邀请名单时，文件就是三列：客户邮箱、客户名字、参考号（[Trustpilot 帮助中心：上传客户数据发邀请](https://help.trustpilot.com/s/article/Send-service-review-invitations-by-uploading-a-file-with-customer-data?language=en_US)），自动邀请也是由订单触发。参考号留在商家自己的 Trustpilot 后台，公开页面和接口返回里都没有。所以如果你是这家店，能做逐单关联的只有那 4.8%，而且要去自己的 Trustpilot Business 后台导出，不是靠公开评论。剩下 95% 的差评，用户写评价时只需要填一个「体验日期」，帮助文档要求这个日期在过去 12 个月以内（[Trustpilot 帮助中心：写评价](https://help.trustpilot.com/s/article/Write-a-review?language=en_US)）。

还有三个会让关联更难的细节。一是商品：Trustpilot 的服务评价写的是「这家公司」，不是某个 SKU。我们用型号词去扫 63 条差评，Allbirds 26 条里写出具体型号（Tree Runner、Wool Runner、Dasher、Trail Runner 这类）的只有 4 条，Anker 20 条里 9 条（Soundcore、eufy、AeroClip 这类产品线名），Ecoalf 17 条里 1 条，合计 14 条，约 22%。二是渠道：Allbirds 的差评里有一条标题直接写着东京丸之内门店的服务，这种线下门店的体验和 Shopify 线上订单根本不在一张表里。三是市场：Allbirds 31 条评价的 `country` 里，英国 18 条、美国 8 条，其余来自加拿大、新西兰、日本和斯洛伐克；Anker 20 条里英美各 7 条，另有 6 个国家各 1 到 2 条；Ecoalf 20 条里西班牙 18 条。如果你的 Shopify 按市场分了几家店，或者订单表里有 `shipping_address` 的国家，合表前要先按国家把两边对齐，不然美国店的退货会和英国用户的差评落在同一行。几件事加起来，意思是「这条差评对应哪个商品、哪个市场」本身就要先判断，而且大多数判断不出来。

## 差评在说什么：客服和退货多于产品本身

逐单做不了，按类别统计还是有用的：如果差评里讲退货的占一半，而你仓库里同期退款单又在涨，两件事放在一起就值得客服和运营看一眼。我们没有让模型判读，而是写了五组关键词规则，大小写不敏感，同时扫标题和正文，一条评价可以命中多类。规则先写好再跑，结果如下图。

![分组条形图：五类关键词在三个品牌 1–2 星评价里的命中占比。客服没回应：Allbirds 77%、Anker 70%、Ecoalf 53%；退货退款保修：Allbirds 50%、Anker 60%、Ecoalf 35%；质量做工坏了：Allbirds 46%、Anker 50%、Ecoalf 71%；物流没收到：Allbirds 35%、Anker 45%、Ecoalf 41%；尺码合脚：Allbirds 23%、Anker 0%、Ecoalf 12%。Allbirds 用青绿色。](https://everyinfra.com/articles/airbyte-mcp-social-data-agent/fig-05-complaint-share-bar.zh.light.svg)

| 类别 | 英文关键词（Allbirds、Anker） | 西语关键词（Ecoalf） | Allbirds 26 条 | Anker 20 条 | Ecoalf 17 条 |
| --- | --- | --- | --- | --- | --- |
| 客服没回应 | customer service、no response、email、phone、contact、support、ignored | atención al cliente、correo、teléfono、respuesta、contacto | 20 | 14 | 9 |
| 退货、退款、保修 | return、refund、exchange、final sale、warranty、replacement | devolución、reembolso、cambio、abono、dinero | 13 | 12 | 6 |
| 质量、做工、坏了 | quality、defect、fell apart、hole、faded、broke、bricked、stopped working | calidad、defecto、tara、roto、descosido、tinte、desgaste | 12 | 10 | 12 |
| 物流、没收到 | deliver、shipping、arrived、never received、wrong size、tracking | entrega、envío、transporte、paquete、pedido、recibido | 9 | 9 | 7 |
| 尺码、合脚 | size、sizing、fit、tight、narrow、wide | talla、ajuste、pequeño、estrecho、ancho | 6 | 0 | 2 |

两个美国、中国出海品牌的差评里，「客服没回应」都排第一，七成以上；Ecoalf 第一是质量，71%。要注意取样窗口不同：Ecoalf 这一组是近 12 个月的西语评价（发评时间从 2 月 24 日到 11 月 2 日），Allbirds 和 Anker 是近 3 个月，所以三家的占比适合各看各的结构，不宜直接排名。这和三家的回复习惯对得上：Allbirds 31 条评价商家回复 0 条，Anker 20 条回复 0 条，Ecoalf 20 条回复了 19 条。对合表最有用的是第二行：Allbirds 一半的差评提到退货、换货或「final sale」（清仓款不退），Anker 六成提到退款或保修。这些就是要和仓库里 `order_refunds` 并排看的那部分。关键词规则有明显的误报和漏报，比如「email」可能只是说「我发了邮件」，「fit」可能出现在「fits perfectly」里；它适合看趋势，不适合给单条评价下结论。要逐条打标签，可以把这一步交给模型，但标签要和规则结果抽样对一遍。

商家回复本身也是一列可以合进表里的数。`trustpilot/reviews` 返回的 `reply_at` 是商家公开回复的时间，我们把 Ecoalf 19 条回复的 `reply_at` 减去 `posted_at`：最快 3.1 小时，中位 22.5 小时，最慢 177.2 小时（约 7.4 天）；24 小时内回了 10 条，72 小时内回了 16 条。如果你的仓库里同时有 Airbyte 同步来的客服工单（比如工单系统的 tickets 表），就可以把「公开评价的回复时长」和「同一周工单的首次回复时长」放在同一行比：两个数一起变慢，多半是客服人手的问题；只有公开回复慢，就是没人盯评价平台。Allbirds 和 Anker 当晚回复数都是 0，这一列对它们就只剩一个结论：差评没人回。

## 时间窗怎么定：体验日期到发评价，中位 1.81 天

按「商品 × 时间」合表，时间轴两边要用同一个意思的日期。仓库这边，Airbyte 的 Shopify connector 同步 `order_refunds` 流，退款的 `processed_at` 是退款处理时间（[Airbyte Shopify connector 文档](https://docs.airbyte.com/integrations/sources/shopify)；字段定义见 [Shopify Refund 资源](https://shopify.dev/docs/api/admin-rest/latest/resources/refund)）。评价这边有两个日期：`posted_at` 是发出评价的时间，`experience_at` 是用户自己填的体验日期，只到天。合表应该用体验日期，因为它更接近购买和退货发生的时间。问题是两者差多远，决定了窗口要开多宽。

![柱状图，71 条 Trustpilot 评价从体验日期到发评价的天数分布：早于体验日 2 条，0–1 天 25 条，1–3 天 15 条，3–7 天 5 条，7–14 天 12 条，14–30 天 5 条，30–90 天 4 条，90 天以上 3 条；0 到 7 天的三根是青绿色。标题：47/71 条在 7 天内，64/71 条在 30 天内。](https://everyinfra.com/articles/airbyte-mcp-social-data-agent/fig-06-lag-dist-bar.zh.light.svg)

71 条评价的间隔中位数是 1.81 天：47 条（66%）在 7 天内，59 条（83%）在 14 天内，64 条（90%）在 30 天内，最长的一条 248 天。有 2 条的发帖时间早于体验日期几个小时，原因是体验日期按 UTC 零点存，而发帖时间带时分秒，用户所在时区一偏就会出现负数，合表时把负数当 0 处理即可。按品牌看，Ecoalf 中位 0.91 天，Anker 1.57 天，Allbirds 3.52 天；三家的第 90 百分位分别是 22.0 天、29.8 天和 27.9 天，都落在 30 天以内，这也是后面建议窗口最宽开到 30 天的依据；Allbirds 的长尾里有几条是「两个月前下的单还没到」，体验日期填的是下单那天。

所以我们的建议是：退款按 `processed_at` 所在的周，评价按 `experience_at` 所在的周，各自聚合，再用「同一周加前后各一周」去看重叠。7 天窗口能覆盖三分之二的评价，30 天能覆盖九成，但窗口越宽，同一周里别的原因造成的退货也越多。还有一个提醒来自 Airbyte 自己的更新日志：Shopify connector 4.3.4（2026-11-03）修了交易表增量同步漏掉退款状态变化的问题，但同一版文档写明 `order_refunds` 流的状态变化还不能增量捕获，要刷新这个流才能纠正旧行（[Airbyte Shopify connector 更新日志](https://docs.airbyte.com/integrations/sources/shopify)，[PR #89704](https://github.com/airbytehq/airbyte/pull/89704)）。退款表的数如果和 Shopify 后台对不上，先刷新再合表。

## 合表：仓库那一半交给 Airbyte，评论那一半交给 EveryInfra

两边数据凑齐以后，最省事的分工是：让仓库自己算退款，让 agent 只拿两份按周聚合的小表回来。Airbyte 的 `execute_external_sql_query` 只接受 `SELECT`、`WITH` 和几条 `SHOW`、`DESCRIBE` 命令（[Airbyte MCP tools](https://docs.airbyte.com/platform/airbyte-mcp/tools)），正好够跑下面这段。它是 BigQuery 方言的配置示例，表名按 Airbyte Shopify connector 的默认流名写，`refund_line_items` 是退款里的商品行；我们没有 Shopify 店铺和 Airbyte Cloud 账户，这段没有在真实仓库里跑过。

```text
-- 配置示例：经 Airbyte MCP 的 execute_external_sql_query 发出（只读）
WITH refunds AS (
  SELECT
    DATE_TRUNC(DATE(r.processed_at), WEEK(MONDAY)) AS week,
    CAST(JSON_VALUE(li, '$.line_item.product_id') AS INT64) AS product_id,
    SUM(CAST(JSON_VALUE(li, '$.quantity') AS INT64)) AS units_refunded,
    COUNT(DISTINCT r.order_id) AS refund_orders
  FROM shopify.order_refunds AS r,
       UNNEST(JSON_QUERY_ARRAY(r.refund_line_items)) AS li
  WHERE r.processed_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 92 DAY)
  GROUP BY week, product_id
)
SELECT week, product_id, units_refunded, refund_orders
FROM refunds
ORDER BY week, units_refunded DESC;
```

评论那一半我们真跑了。把 00:22 拉回的 Allbirds 31 条评价装进本机 DuckDB，按体验日期所在的周聚合 1–2 星评价和三类关键词，SQL 和上面同一个思路。结果是 15 个有数据的周，26 条差评，最多的一周（9 月 21 日那周）4 条，其中 3 条提到退货、3 条提到尺码，而且这一周正好有 3 条经 Shopify 邀请来的评价，其中一条 1 星写的是「收到的尺码不对」；最近一周（11 月 2 日那周）2 条差评都提到退货和尺码。这张小表说明了一个更实际的问题：像 Allbirds 这样的品牌，按周拆到品牌一级，差评只有 0 到 4 条，再按商品拆基本是 0 或 1。所以单个店铺做这件事，周粒度只适合看「有没有异常」，比较退货和差评的趋势要用 4 周滚动窗口，或者把同类商品合成一组。

4 周滚动窗口具体是什么样，用同一份 DuckDB 结果按日历周补齐空周（没有评价的周记 0），再每 4 周加一次。从 7 月 20 日那周到 11 月 2 日那周正好 16 周，切成 4 段，1–2 星评价依次是 7、6、7、6 条；提到退货的依次是 4、1、3、4 条；提到尺码的依次是 0、1、3、2 条。按单周看，9 月 21 日那周 4 条差评像一个尖峰；按 4 周看，那一段 7 条，和其余三段 6 到 7 条没有差别，尖峰只是几条评价恰好落在同一周。真正有一点变化的是尺码：前 8 周只有 1 条差评提到尺码，后 8 周有 5 条。5 条仍然太少，不足以下结论，但已经值得让 agent 去仓库里查同一时间段的退货原因里「尺码不合」占多少，这正是两边合表要回答的那种问题。

agent 拿到两张小表以后，合表本身不需要 SQL：按周对齐，退款件数和差评数放在相邻两列，差评类别作为第三列。我们会在提示词里写明四条规则，每条都来自上面量出来的数字：一，只用周聚合结果，不把单条评价和单张退单配对；二，评论里没写型号的归到「品牌整体」一行；三，任何一周差评少于 3 条不下结论；四，先说明窗口从哪天到哪天、最早一段是否完整，再给数字。第四条是因为 `date=last3months` 筛的是发评时间，统计按的却是体验日期，最早几周只收到「体验在 7 月、8 月以后才写」的那部分评价，天然偏少；按上一节 64/71 条在 30 天内发出，把最早 4 周当作不完整、只看后 12 周更稳。

## 想让评论也进仓库：用 Airbyte 声明式 connector 拉 EveryInfra

如果你更想在仓库里留一份评论的历史，而不是每次让 agent 现拉，可以反过来：把 EveryInfra 写成 Airbyte 的一个自定义来源，让 Airbyte 按计划同步进 BigQuery 或 Snowflake，再交给 context layer 建索引。Airbyte 的自定义 connector 用 YAML 声明式写法，Airbyte MCP 里也有 `publish_custom_source_definition` 这个工具可以发布 YAML（[Airbyte MCP tools](https://docs.airbyte.com/platform/airbyte-mcp/tools)）。我们写了一个最小的 manifest，用本机 PyAirbyte 跑了四次，过程本身就是这一节最有用的部分。

```text
# 本机 PyAirbyte 跑通的版本（第四次），Key 从 config 注入，不写进文件
version: 6.44.0
type: DeclarativeSource
streams:
  - type: DeclarativeStream
    name: trustpilot_reviews
    primary_key: [id]
    retriever:
      type: SimpleRetriever
      requester:
        type: HttpRequester
        url_base: https://api.everyinfra.com
        path: /api/v1/social
        http_method: POST
        authenticator:
          type: BearerAuthenticator
          api_token: "{{ config['api_key'] }}"
        error_handler:
          type: DefaultErrorHandler
          max_retries: 8
          backoff_strategies:
            - type: WaitTimeFromHeader
              header: Retry-After
            - type: ConstantBackoffStrategy
              backoff_time_in_seconds: 30
        request_body_json:
          platform: trustpilot
          action: reviews
          params:
            company: "{{ config['company'] }}"
            limit: 200
            date: last3months
      record_selector:
        type: RecordSelector
        extractor: { type: DpathExtractor, field_path: [results] }
    schema_loader:
      type: InlineSchemaLoader
      schema:
        type: object
        additionalProperties: true
        properties:
          id: { type: string }
          rating: { type: [integer, "null"] }
          experience_at: { type: [string, "null"], format: date-time }
          posted_at: { type: [string, "null"], format: date-time }
          source: { type: [string, "null"] }
          verification_level: { type: [string, "null"] }
```

前三次失败的原因各不相同，每一个都值得记下来。第一次（00:26，新加坡时间）请求体里写着 `stars: ["1", "2"]`，连续失败 11 次后放弃，其中 5 次是限速的 429。CDK 默认的退避是 1、2、4、8、16 秒，而失败响应里给的 `retry_after` 是 20 秒，退避根本没等够。第二次加了 25 秒的固定退避，又因为测试 Key 每分钟只有 10 次，429 把重试次数耗光。第三次把重试放到 8 次、每次 30 秒，仍然全部失败。我们起了一个本机的回显服务器，把 manifest 的地址指过去再跑一次，看 CDK 实际发出了什么：`"stars": [1, 2]`，字符串被模板引擎转成了数字，User-Agent 是 `python-requests/2.34.2`。00:38 我们用同样的 User-Agent 手工各发一次：数字版失败，字符串版回 200、20 行。所以要记住一条：`trustpilot/reviews` 的 `stars` 请按字符串传（`["1", "2"]`），传整数会回 503，这类失败不扣费。Airbyte 的声明式模板会把 `"1"` 解析成整数，所以 manifest 里不要传 `stars`，把星级过滤放到仓库的 SQL 里做。

第四次（00:39）去掉 `stars`、改成 `limit: 200`，14.3 秒同步完，31 行进了本机 DuckDB，和 00:22 那次 REST 拉回的条数一致。表里除了我们声明的字段，Airbyte 自动加了 `_airbyte_raw_id`、`_airbyte_extracted_at`、`_airbyte_meta` 三列，增量去重和排查都靠它们。还有一个坑是我们自己踩的：第四次跑的时候 schema 里只声明了 `id`、`rating`、日期这些字段，没有声明 `source` 和 `verification_level`，结果本机缓存表里就没有这两列，虽然 `additionalProperties` 是 true。前面讲过，`source` 是唯一能判断「这条评价能不能追到订单」的字段，所以上面贴出来的 manifest 已经把它们补进 schema。照 Airbyte 的计费，自定义来源和 API 来源一样按行数算，每百万行 6 个 credit（[Airbyte credits 文档](https://docs.airbyte.com/platform/cloud/managing-airbyte-cloud/manage-credits)），一个品牌一个季度几十条评价，基本可以忽略。

两条路怎么选？现拉（agent 每次经 EveryInfra MCP 调）适合问答和临时排查，数据是当下的，不占仓库；同步进仓库适合要留历史、要和退款表做 SQL 关联、要交给 context layer 检索的团队。context layer 的检索只索引「来源和目标库都是 agent connector」的连接（[Context layer 检索文档](https://docs.airbyte.com/platform/context-layer/search)），自定义来源能不能进索引，文档没写，我们也没有 Cloud 账户去试，这一点要以 Airbyte 的实际行为为准。

## 一个月多少钱：已跑通部分约 $0.09，含 Amazon 约 $0.93

![横向条形图，一个店铺一个月的账：Airbyte Cloud Standard 起步价 $20.00，含 5 个 credit；EveryInfra Amazon 评价 600 次 $0.83，当晚未拿到数据；EveryInfra Trustpilot 加 Reddit 120 次 $0.09，已实测，这一根是青绿色；Airbyte MCP 与 context layer 在每月 10 万次以内 $0.00。标题：已实测的社媒部分约 $0.09，加上 Amazon 评价约 $0.93。](https://everyinfra.com/articles/airbyte-mcp-social-data-agent/fig-07-cost-month-bar.zh.light.svg)

我们按一个中等规模的 Shopify 店铺算：每天 1 次 `trustpilot/reviews`（近 7 天、最多 200 条），3 个关键词各跑一次 `reddit/search`，20 个主力商品各拉一次 `amazon/reviews`。按 00:14 读的目录价分两档看。当晚已经跑通的 Trustpilot 和 Reddit，每月 120 次，约 $0.09。加上 Amazon 评价的 600 次，合计 720 次、约 $0.93，其中 Amazon 占九成，而这项能力当晚 3 次都没拿到数据，这一档请先小量试通再算进预算。Amazon 这 600 次还有压缩空间：上一节的搜索结果里，10 个 ASIN 只对应 4 个父商品，评价挂在父商品上共享，按父商品各拉一次就够。假设你的 20 个主力商品归到 5 个父商品，每月就是 150 次、约 $0.21，整月合计约 $0.30。失败和空结果不扣费，所以实际账单只会更低。还要看清计费单位：这些能力按次计费，不按条数。`trustpilot/reviews` 一次拉满 200 条时，每千条约 $0.0069；但 Allbirds 近 3 个月只有 31 条，同一次调用摊到每千条约 $0.0448。评价少的品牌，账单由调用次数决定，和 `limit` 开多大无关，所以省钱的办法是少调几次，比如 Trustpilot 每天一次足够，不必每小时轮询。EveryInfra 的价格页和目录是同一套数（[价格](/pricing)）。

| 项目 | 单价（读取日期） | 一个月用量 | 一个月费用 | 出处 |
| --- | --- | --- | --- | --- |
| EveryInfra `trustpilot/reviews` | $0.001389／次，最多 200 条（11-10） | 30 次 | $0.0417 | 目录 `price_usd` |
| EveryInfra `amazon/reviews`（当晚未拿到数据） | $0.001389／次，最多 100 条（11-10） | 600 次 | $0.8334 | 目录 `price_usd` |
| EveryInfra `reddit/search` | $0.000556／次（11-10） | 90 次 | $0.0500 | 目录 `price_usd` |
| Airbyte MCP 本身 | 免费（11-10） | 不限 | $0 | [Airbyte MCP 文档](https://docs.airbyte.com/platform/airbyte-mcp) |
| context layer 直接读取和检索 | 每组织每月 10 万次内免费（11-10） | 远低于 10 万次 | $0 | [Context layer 文档](https://docs.airbyte.com/platform/context-layer) |
| Airbyte Cloud Standard | $20／月起，含 5 个 credit，约 1 GB 同步（11-10） | 每月 3 万行订单和退款约 0.18 credit | $20 | [Airbyte 定价页](https://airbyte.com/pricing) |
| 仓库查询 | 按目标库计费 | 每天几次周聚合 | 视仓库而定 | [Agent access 文档](https://docs.airbyte.com/platform/context-layer/agent-access) |

表里 Airbyte 那一行要多说一句。Standard 的 $20 起步价里含 5 个 credit，API 来源每百万行 6 个 credit，3 万行订单和退款只用 0.18 个，所以小店铺一般不会超额；超出 5 个以后按额外 credit 收，官网定价页没有直接写出单价，第三方的价格汇总写的是每个 $5（[Skyvia 的 Airbyte 定价汇总，2026-10-20](https://skyvia.com/blog/airbyte-pricing/)），以你账户里的报价为准。月用量到 40 个 credit 以上，官方建议看 Plus 套餐，40 个 credit $189／月起（[Airbyte 定价页](https://airbyte.com/pricing)）。新账户有 14 天、400 credit 的试用，以先到者为准（[Airbyte credits 文档](https://docs.airbyte.com/platform/cloud/managing-airbyte-cloud/manage-credits)）。真正要留意的是仓库：`execute_external_sql_query` 的每一次查询都用目标库的算力，agent 如果每轮对话都全表扫一遍退款表，BigQuery 或 Snowflake 的账单会比上面所有数加起来都多。让 agent 只查按周聚合好的视图，是最直接的省钱办法。

## 做不了的、要注意的

| 事情 | 现状 | 怎么处理 |
| --- | --- | --- |
| 逐条把差评对到订单 | 63 条差评里 3 条经商家邀请，参考号只在商家自己的 Trustpilot 后台 | 只按商品 × 周合表；要逐单就导出自己后台的邀请评价 |
| 判断评价说的是哪个商品 | 型号写出来的约 22% | 没写型号的归到「品牌整体」，不硬猜 |
| Amazon 评价 | 当晚 `amazon/reviews` 两次 503、一次空结果，都没扣费 | 先拿一两个 ASIN 试通；用 `amazon/search` 先建父商品和子 ASIN 的对照表 |
| context layer | 只在 Airbyte Cloud 上有，自管 Core 和客户自管数据面的 Flex 都不行 | 自管用户只能用管道管理类工具，仓库查询走自己的 SQL 客户端 |
| Claude 网页版收窄 Airbyte 工具 | 自定义请求头发不出去 | 用 `?read-only=true`；Claude Code、Cursor 可以发请求头 |
| 工具名 | 本机 0.71.3 带 `cloud` 前缀，托管版 11-06 已改名 | 白名单和提示词别写死工具名，升级后重核 |
| 个人信息 | 评价里有评论人名字和头像链接 | 入库前丢掉 `author_*` 字段，只留统计需要的列 |

Trustpilot 返回里带 `author_name`、`author_id`、`author_image`，Amazon 评价也有评论人昵称。这些对「差评和退货」的统计没有用，进了仓库还会让同一份表落到更多人眼前。Airbyte 的文档自己也提醒过，直接读取用的是 connector 里存的凭据，可能让某个 Airbyte 用户看到他平时在源系统里看不到的记录（[Airbyte MCP 文档：认证说明](https://docs.airbyte.com/platform/airbyte-mcp)）。我们的做法是在 manifest 的 schema 里只声明要用的列，作者相关字段一律不进仓库。本文的统计、截图和代码里也都没有出现任何评论人的名字。

## 和前几篇的区别

同一类数据的另几种接法：[Snowflake Cortex Agents 那篇](/blog/snowflake-cortex-agents-mcp-social-reviews)先把评论经外部访问集成写进 Snowflake，[Google Data Agent Kit 那篇](/blog/google-data-agent-kit-bigquery-social-data)把三个平台的数据装进 BigQuery 一张宽表，品牌舆情本身可以看 [Gemini Enterprise 那篇的品牌情绪 agent](/blog/gemini-enterprise-agent-platform-mcp-brand-sentiment)；这一篇不要求先搬进仓库，重点是公开评论到底能不能和订单对上。

如果你还没有 EveryInfra 的 Key，五分钟上手见[快速开始](/docs#quickstart)；MCP 的接法和各客户端的配置在 [MCP 服务器页](/mcp-server)；本文用到的平台页是 [Trustpilot](/trustpilot-api)、[Amazon](/amazon-api) 和 [Reddit](/reddit-api)，Reddit 的提及搜索见 [`reddit/search`](/reddit-api/search)。

## 常见问题

**airbyte mcp 是免费的吗？**

Airbyte MCP 本身对所有套餐免费，包括自管的 Core。context layer 的直接读取和检索每个组织每月 10 万次以内免费，管理连接、读日志这类工具不计次数（[Airbyte MCP 文档](https://docs.airbyte.com/platform/airbyte-mcp)）。要花钱的是 Airbyte Cloud 的同步套餐和仓库的查询算力。这个问题来自 Google 联想词「is airbyte free」。

**is airbyte open source，MCP 也是开源的吗？**

是。Airbyte Core 按 Elastic License 2.0 免费自管（[Airbyte 定价页](https://airbyte.com/pricing)）；MCP 服务器的代码在 PyAirbyte 仓库里，本机用 `uvx --from=airbyte@latest airbyte-mcp` 就能起，我们 11 月 10 日起的是 0.71.3。开源版没有 context layer。问题来自联想词「is airbyte open source」。

**airbyte mcp server 能直接连 Shopify 吗？**

不能直接读 Shopify 的实时数据，除非 Shopify 在你的 Airbyte Cloud 组织里是支持 agent access 的 connector 并且管理员打开了它。常见做法是用 Airbyte 的 Shopify connector 把 `orders`、`order_refunds` 同步进仓库，再经 `execute_external_sql_query` 查（[Airbyte Shopify connector 文档](https://docs.airbyte.com/integrations/sources/shopify)）。问题来自联想词「airbyte shopify connector」。

**Trustpilot 差评能和自己的订单对上吗？**

公开的差评基本对不上。我们拉的 63 条 1–2 星评价里，只有 3 条（4.8%）来自商家邀请，参考号留在商家自己的 Trustpilot 后台；正文里带订单号的是 0 条。能做的是按商品和周合表；要逐单，就从自己的 Trustpilot Business 后台导出邀请评价，那里有你上传邀请名单时填的参考号（[Trustpilot 帮助中心：上传客户数据发邀请](https://help.trustpilot.com/s/article/Send-service-review-invitations-by-uploading-a-file-with-customer-data?language=en_US)）。问题来自联想词「trustpilot bad reviews」。

**MCP 和直接复制进仓库，哪个更适合做报表？**

Reddit 上有人问 Odoo 的数据该接 MCP 还是复制进仓库，几条高赞回答的意见一致：聊天里的临时问题用 MCP，看板和固定报表用复制进仓库的表，而且两边对同一个数的定义要统一（[r/Odoo 讨论](https://www.reddit.com/r/Odoo/comments/1x3wmhj/using_claude_dashboards_with_odoo_19_connect_via/)）。本文的结论是同一个方向：退款这类要稳定统计的数放仓库，评论这类变化快、量又小的数可以现拉，最后按周聚合再合表。

## 参考资料

1. New Airbyte MCP Server Lets Users Chat with Their Data，Business Wire，2026-10-27，https://www.businesswire.com/news/home/20261027843580/en/New-Airbyte-MCP-Server-Lets-Users-Chat-with-Their-Data-Simplifies-Pipeline-Management-and-Improves-User-Experience
1. Introducing the Airbyte MCP Server and Context Layer，Airbyte 博客，2026-10-27（11-04 更新），https://airbyte.com/blog/airbyte-mcp
1. Airbyte MCP，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/airbyte-mcp
1. Install the Airbyte MCP，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/airbyte-mcp/install
1. Airbyte MCP tools，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/airbyte-mcp/tools
1. Advanced Airbyte MCP configuration，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/airbyte-mcp/advanced-configuration
1. Use the Airbyte MCP with Airbyte Core，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/airbyte-mcp/self-managed
1. Context layer，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/context-layer
1. Agent access，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/context-layer/agent-access
1. Search your data，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/context-layer/search
1. Manage billing and credits，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/cloud/managing-airbyte-cloud/manage-credits
1. Shopify source connector（含更新日志 4.3.4、4.3.5），Airbyte 文档，2026-11-03，https://docs.airbyte.com/integrations/sources/shopify
1. Airbyte Pricing，Airbyte，2026-11-10 读取，https://airbyte.com/pricing
1. docs: add Airbyte MCP and Context layer docs (private beta)，GitHub PR #87633，2026-10-02，https://github.com/airbytehq/airbyte/pull/87633
1. docs: move Airbyte MCP and context layer to open beta，GitHub PR #88922，2026-10-14，https://github.com/airbytehq/airbyte/pull/88922
1. docs: remove beta references from Airbyte MCP and context layer docs，GitHub PR #89777，2026-10-27，https://github.com/airbytehq/airbyte/pull/89777
1. docs(mcp): document ?read-only=true URL，GitHub PR #90250，2026-10-30，https://github.com/airbytehq/airbyte/pull/90250
1. docs: retire Airbyte Agents documentation，GitHub PR #89805，2026-10-30，https://github.com/airbytehq/airbyte/pull/89805
1. docs: add context layer search documentation，GitHub PR #90239，2026-11-03，https://github.com/airbytehq/airbyte/pull/90239
1. docs(airbyte-mcp): update tool names after cloud prefix removal，GitHub PR #91190，2026-11-06，https://github.com/airbytehq/airbyte/pull/91190
1. docs(mcp): document insiders tools，GitHub PR #91203，2026-11-09，https://github.com/airbytehq/airbyte/pull/91203
1. Shopify：emit transactions of orders updated since the saved state，GitHub PR #89704，2026-11-03，https://github.com/airbytehq/airbyte/pull/89704
1. fix(mcp): apply broad destructiveHint definition for OpenAI review，PyAirbyte PR #1441，2026-11-02，https://github.com/airbytehq/PyAirbyte/pull/1441
1. feat(mcp): add ?insiders=true URL param，PyAirbyte PR #1456，2026-11-06，https://github.com/airbytehq/PyAirbyte/pull/1456
1. airbyte（PyAirbyte）包页面，PyPI，0.71.3 发布于 2026-10-26，https://pypi.org/project/airbyte/
1. airbyte-agents-benchmarks，GitHub，https://github.com/airbytehq/airbyte-agents-benchmarks
1. Show HN: Airbyte Agents，Hacker News，2026 年 5 月，https://news.ycombinator.com/item?id=48023496
1. Tools，Model Context Protocol 规范 2025-06-18，https://modelcontextprotocol.io/specification/2025-06-18/server/tools
1. Authorization，Model Context Protocol 规范 2025-06-18，https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
1. RFC 9728：OAuth 2.0 Protected Resource Metadata，IETF，2025，https://www.rfc-editor.org/rfc/rfc9728
1. Connect Claude Code to tools via MCP，Anthropic 文档，2026-11 读取，https://code.claude.com/docs/en/mcp
1. Get started with custom connectors using remote MCP，Claude 帮助中心，2026-11 读取，https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp
1. Write a review，Trustpilot 帮助中心，2026-11 读取，https://help.trustpilot.com/s/article/Write-a-review?language=en_US
1. Send service review invitations by importing a customer data file，Trustpilot 帮助中心，2026-11 读取，https://help.trustpilot.com/s/article/Send-service-review-invitations-by-uploading-a-file-with-customer-data?language=en_US
1. Refund 资源，Shopify 开发者文档，2026-11 读取，https://shopify.dev/docs/api/admin-rest/latest/resources/refund
1. Allbirds, Inc. Form 8-K（资产出售协议），SEC，2026-03-29，https://www.sec.gov/Archives/edgar/data/1653909/000162828026022181/bird-20260329.htm
1. Allbirds, Inc. Form 8-K（资产出售完成），SEC，2026-06-09，https://www.sec.gov/Archives/edgar/data/1653909/000162828026043145/bird-20260609.htm
1. EveryInfra 社媒数据目录，EveryInfra，2026-11-10 00:14 读取，https://api.everyinfra.com/api/v1/social/catalog
1. Using Claude Dashboards with Odoo 19：connect via MCP or replicate to a data warehouse?，Reddit r/Odoo，2026-11，https://www.reddit.com/r/Odoo/comments/1x3wmhj/using_claude_dashboards_with_odoo_19_connect_via/
1. Airbyte Pricing 2026: Plans, Credits and Real Costs，Skyvia 博客，2026-10-20，https://skyvia.com/blog/airbyte-pricing/
1. Connect Codex to Self-Managed Airbyte Core with the Airbyte MCP，Airbyte 博客，2026-11-07，https://airbyte.com/blog/connect-codex-to-airbyte-core-with-airbyte-mcp
1. Known issue：links include /api/public/v1，PyAirbyte issue #563，https://github.com/airbytehq/PyAirbyte/issues/563
1. Airbyte MCP: Build Pipelines, Troubleshoot Syncs & Chat With Your Data，Airbyte YouTube 频道，2026-10-27，https://www.youtube.com/watch?v=C4-eGrBePUQ