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

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 同步订单的套餐。

这篇文章要回答的问题很具体：你的店铺用 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），6 月 9 日提交了交易完成的 8-K（SEC 8-K，2026-06-09），换主人以后的客服和退货体验正是评论区最集中的话题。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）。同一份新闻稿写明，Airbyte Cloud 和 Enterprise Flex 用户还能通过 MCP 用上新的 context layer：在 Snowflake 和 BigQuery 目标库上直接查询由 50 多个来源 connector 同步进来的数据，例子是「哪些客户账户还有没关的工单」。Airbyte 官方博客同日发文，标题把 MCP 和 context layer 放在一起，页面显示 11 月 4 日更新过一次（Airbyte 博客，2026-10-27）。同一天 Airbyte 在 YouTube 发了一支 1 分 21 秒的演示视频，按顺序演示把 MCP 加进 agent、建来源（视频里说可选 600 多个 connector）、建目标库、建连接并同步、让 agent 读日志排查失败的同步，最后对数据提问；到 11 月 10 日这支视频播放约 3.7 万次（Airbyte 官方演示视频，2026-10-27）。视频里没有出现任何读取公开网页或社媒评论的步骤，这和下文本机数工具的结果一致。

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

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

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

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

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

文档列了工具，但文档会变，所以我们让本机直接回答。Airbyte 给自管 Core 的接法是在 MCP 客户端里用 uvx --from=airbyte@latest airbyte-mcp 启动本地服务（在 Airbyte Core 上用 Airbyte MCP）。我们在 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）；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）；它的 47 个工具里 36 个名字带 cloud，例如 list_deployed_cloud_connections、run_cloud_sync。而官方工具页在 11 月 6 日已经把名字改成不带前缀的 list_connections、run_connection_sync（PR #91190）。同一个包的 1.0 候选版在 11 月 6 日已经出到 rc42，PyAirbyte 仓库 11 月 2 日到 6 日之间合并了一串 MCP 相关的改动，包括为了通过 OpenAI 的审核放宽「破坏性」的定义（PyAirbyte PR #1441）、增加 ?insiders=true 参数（PyAirbyte PR #1456）。如果你在提示词、审批白名单或审计脚本里写死了工具名，托管版和本机版要分开写，升级后再核一次。

两个 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 高级配置）；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）；而按 RFC 9728，资源地址带路径时，元数据地址是把 /.well-known/oauth-protected-resource 插在主机名和路径之间（RFC 9728），所以根路径 404 是对的。自己写客户端或代理层的团队，别去根路径找。

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

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

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

{
  "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）；但一个只想回答「差评和退货」的 agent 根本不需要碰管道，开只读最省事，也让工具定义少一半。要让 agent 能读仓库，还需要组织管理员在 Airbyte 里打开 agent access，并且目标库得是 BigQuery 或 Snowflake，只允许 SELECT 和 SHOW TABLES（Agent access 文档）。

第二个要调的是工具输出的上限。Claude Code 在单次 MCP 工具输出超过 10,000 token 时提示，默认上限 25,000 token，可以用 MAX_MCP_OUTPUT_TOKENS 调高（Claude Code 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 评价接口）。amazon/reviews 必填商品链接，最多 100 条，同价（Amazon 评价接口）。下表是当晚每一次调用，时间都是新加坡时间，扣费取响应里的 charged_usd。

这张表本身就说明了三件和扣费有关的事。第一，失败不扣费：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 次，这类请求同样不计费。

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

{"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 搜索接口）。也就是说，同一款鞋的不同颜色、尺码各有一个 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：社媒差评和退货怎么进一张表》那篇在 11 月 6 日也遇到过 amazon/reviews 503 和空结果，所以本文的结论只用 Trustpilot 的数据；Amazon 评价建议先拿一两个 ASIN 试通，再排进定时任务。

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

Trustpilot 是「给公司打分」，关联键天然粗。为了看清关联键到底取决于什么，我们同一晚换了一个按商品打分的平台做对照：00:42（新加坡时间）用 jd/search 搜「安克 充电宝」，再拿第一个结果的 item_id 调 jd/reviews（京东搜索接口、京东评价接口）。两次都是 200，搜索 5 行扣 $0.002472，评价 10 行扣 $0.001389。选 Anker 是因为它也是我们在 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 是商家通过集成或链接发出的邀请。

结果如上图。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 帮助中心：上传客户数据发邀请），自动邀请也是由订单触发。参考号留在商家自己的 Trustpilot 后台，公开页面和接口返回里都没有。所以如果你是这家店，能做逐单关联的只有那 4.8%，而且要去自己的 Trustpilot Business 后台导出，不是靠公开评论。剩下 95% 的差评，用户写评价时只需要填一个「体验日期」，帮助文档要求这个日期在过去 12 个月以内（Trustpilot 帮助中心：写评价）。

还有三个会让关联更难的细节。一是商品：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 的国家，合表前要先按国家把两边对齐，不然美国店的退货会和英国用户的差评落在同一行。几件事加起来，意思是「这条差评对应哪个商品、哪个市场」本身就要先判断，而且大多数判断不出来。

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

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

两个美国、中国出海品牌的差评里，「客服没回应」都排第一，七成以上；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 文档；字段定义见 Shopify Refund 资源）。评价这边有两个日期：posted_at 是发出评价的时间，experience_at 是用户自己填的体验日期，只到天。合表应该用体验日期，因为它更接近购买和退货发生的时间。问题是两者差多远，决定了窗口要开多宽。

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 更新日志，PR #89704）。退款表的数如果和 Shopify 后台对不上，先刷新再合表。

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

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

-- 配置示例：经 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）。我们写了一个最小的 manifest，用本机 PyAirbyte 跑了四次，过程本身就是这一节最有用的部分。

# 本机 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 文档），一个品牌一个季度几十条评价，基本可以忽略。

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

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

我们按一个中等规模的 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 的价格页和目录是同一套数（价格）。

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

做不了的、要注意的

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

和前几篇的区别

同一类数据的另几种接法：Snowflake Cortex Agents 那篇先把评论经外部访问集成写进 Snowflake，Google Data Agent Kit 那篇把三个平台的数据装进 BigQuery 一张宽表，品牌舆情本身可以看 Gemini Enterprise 那篇的品牌情绪 agent；这一篇不要求先搬进仓库，重点是公开评论到底能不能和订单对上。

如果你还没有 EveryInfra 的 Key，五分钟上手见快速开始；MCP 的接法和各客户端的配置在 MCP 服务器页；本文用到的平台页是 Trustpilot、Amazon 和 Reddit，Reddit 的提及搜索见 reddit/search。

常见问题

airbyte mcp 是免费的吗？

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

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

是。Airbyte Core 按 Elastic License 2.0 免费自管（Airbyte 定价页）；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 文档）。问题来自联想词「airbyte shopify connector」。

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

公开的差评基本对不上。我们拉的 63 条 1–2 星评价里，只有 3 条（4.8%）来自商家邀请，参考号留在商家自己的 Trustpilot 后台；正文里带订单号的是 0 条。能做的是按商品和周合表；要逐单，就从自己的 Trustpilot Business 后台导出邀请评价，那里有你上传邀请名单时填的参考号（Trustpilot 帮助中心：上传客户数据发邀请）。问题来自联想词「trustpilot bad reviews」。

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

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

参考资料

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
2. Introducing the Airbyte MCP Server and Context Layer，Airbyte 博客，2026-10-27（11-04 更新），https://airbyte.com/blog/airbyte-mcp
3. Airbyte MCP，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/airbyte-mcp
4. Install the Airbyte MCP，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/airbyte-mcp/install
5. Airbyte MCP tools，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/airbyte-mcp/tools
6. Advanced Airbyte MCP configuration，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/airbyte-mcp/advanced-configuration
7. Use the Airbyte MCP with Airbyte Core，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/airbyte-mcp/self-managed
8. Context layer，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/context-layer
9. Agent access，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/context-layer/agent-access
10. Search your data，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/context-layer/search
11. Manage billing and credits，Airbyte 文档，2026-11 读取，https://docs.airbyte.com/platform/cloud/managing-airbyte-cloud/manage-credits
12. Shopify source connector（含更新日志 4.3.4、4.3.5），Airbyte 文档，2026-11-03，https://docs.airbyte.com/integrations/sources/shopify
13. Airbyte Pricing，Airbyte，2026-11-10 读取，https://airbyte.com/pricing
14. docs: add Airbyte MCP and Context layer docs (private beta)，GitHub PR #87633，2026-10-02，https://github.com/airbytehq/airbyte/pull/87633
15. docs: move Airbyte MCP and context layer to open beta，GitHub PR #88922，2026-10-14，https://github.com/airbytehq/airbyte/pull/88922
16. docs: remove beta references from Airbyte MCP and context layer docs，GitHub PR #89777，2026-10-27，https://github.com/airbytehq/airbyte/pull/89777
17. docs(mcp): document ?read-only=true URL，GitHub PR #90250，2026-10-30，https://github.com/airbytehq/airbyte/pull/90250
18. docs: retire Airbyte Agents documentation，GitHub PR #89805，2026-10-30，https://github.com/airbytehq/airbyte/pull/89805
19. docs: add context layer search documentation，GitHub PR #90239，2026-11-03，https://github.com/airbytehq/airbyte/pull/90239
20. docs(airbyte-mcp): update tool names after cloud prefix removal，GitHub PR #91190，2026-11-06，https://github.com/airbytehq/airbyte/pull/91190
21. docs(mcp): document insiders tools，GitHub PR #91203，2026-11-09，https://github.com/airbytehq/airbyte/pull/91203
22. Shopify：emit transactions of orders updated since the saved state，GitHub PR #89704，2026-11-03，https://github.com/airbytehq/airbyte/pull/89704
23. fix(mcp): apply broad destructiveHint definition for OpenAI review，PyAirbyte PR #1441，2026-11-02，https://github.com/airbytehq/PyAirbyte/pull/1441
24. feat(mcp): add ?insiders=true URL param，PyAirbyte PR #1456，2026-11-06，https://github.com/airbytehq/PyAirbyte/pull/1456
25. airbyte（PyAirbyte）包页面，PyPI，0.71.3 发布于 2026-10-26，https://pypi.org/project/airbyte/
26. airbyte-agents-benchmarks，GitHub，https://github.com/airbytehq/airbyte-agents-benchmarks
27. Show HN: Airbyte Agents，Hacker News，2026 年 5 月，https://news.ycombinator.com/item?id=48023496
28. Tools，Model Context Protocol 规范 2025-06-18，https://modelcontextprotocol.io/specification/2025-06-18/server/tools
29. Authorization，Model Context Protocol 规范 2025-06-18，https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
30. RFC 9728：OAuth 2.0 Protected Resource Metadata，IETF，2025，https://www.rfc-editor.org/rfc/rfc9728
31. Connect Claude Code to tools via MCP，Anthropic 文档，2026-11 读取，https://code.claude.com/docs/en/mcp
32. 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
33. Write a review，Trustpilot 帮助中心，2026-11 读取，https://help.trustpilot.com/s/article/Write-a-review?language=en_US
34. 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
35. Refund 资源，Shopify 开发者文档，2026-11 读取，https://shopify.dev/docs/api/admin-rest/latest/resources/refund
36. Allbirds, Inc. Form 8-K（资产出售协议），SEC，2026-03-29，https://www.sec.gov/Archives/edgar/data/1653909/000162828026022181/bird-20260329.htm
37. Allbirds, Inc. Form 8-K（资产出售完成），SEC，2026-06-09，https://www.sec.gov/Archives/edgar/data/1653909/000162828026043145/bird-20260609.htm
38. EveryInfra 社媒数据目录，EveryInfra，2026-11-10 00:14 读取，https://api.everyinfra.com/api/v1/social/catalog
39. 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/
40. Airbyte Pricing 2026: Plans, Credits and Real Costs，Skyvia 博客，2026-10-20，https://skyvia.com/blog/airbyte-pricing/
41. 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
42. Known issue：links include /api/public/v1，PyAirbyte issue #563，https://github.com/airbytehq/PyAirbyte/issues/563
43. Airbyte MCP: Build Pipelines, Troubleshoot Syncs & Chat With Your Data，Airbyte YouTube 频道，2026-10-27，https://www.youtube.com/watch?v=C4-eGrBePUQ