VS Code Copilot cloud automations：每天给应用商店差评分类

一个移动应用团队最常见的早会问题是：昨天商店里新来的差评，说的是崩溃、扣费还是登不上？GitHub 在 2026 年 10 月 28 日给 VS Code 加上了 Copilot cloud automations：在编辑器里写好一段说明、选好时间，Copilot 云端 agent 就每天在 GitHub 上开一个会话照着做，电脑关着也照跑。本文把这件活拆开做了一遍：EveryInfra 的 app_store/reviews 和 google_play/reviews 两项能力我们在 2026 年 11 月 11 日真调了 10 次，覆盖 Duolingo 和 Strava 两款公开应用、两家商店，11 月 12 日又为墨西哥和西班牙两个 App Store 店面加调了 2 次；Copilot 一侧的设置全部来自 GitHub 和 VS Code 的文档原文，我们没有在自己的仓库里跑这个自动化，所以那部分一律写成「配置示例」。

结论先放在这里。按每天一次、两款应用四个商店入口算，接口费是 4 次调用、每天 $0.0056，30 天 $0.17。真正决定这件活成不成的是另外两个数：Duolingo 的英文 Google Play 评论，一次调用最多回 200 条，只盖住 4.25 小时，每天跑一次会漏掉一天里的大部分新评论；VS Code 里能选的云端定时又只有每天和每周，每小时一次只在本机跑。所以评论量大的应用要把「勤拉」和「每天分析一次」拆开，评论量小的应用一天一次绰绰有余。

这件活是什么：每天早上一份差评分类

先把任务讲具体，后面所有的数都按这个任务算。一个团队维护一款移动应用，iOS 和安卓各一版。每天早上 9 点（新加坡时间）之前，仓库里要多出一份当天的差评报告：昨天以来新出现的 1–3 星评论有多少条，各自属于崩溃和故障、付费和订阅、登录和账号、同步和设备、广告、改版这几类里的哪一类，哪一类比前几天明显多了，每类挑两三条原文当例子。如果某一类突然涨起来，比如「更新以后一直闪退」三天内冒出十几条，就直接在仓库里开一个 issue，把例子和版本号贴进去，指给负责的人。

这件活有三个特点，正好对上 Copilot cloud automations 的用途。第一，它是定时的，而且最好在人上班之前跑完，不该依赖某个人记得打开电脑点一下。第二，它要写进仓库：报告是 Markdown 文件，异常是 issue，这两样都是 Copilot 云端 agent 本来就会用的 GitHub 工具。第三，数据在仓库外面：两家商店的评论要从外部取，所以要给 agent 接一个 MCP 服务器，或者让它跑一段取数脚本。前两点 GitHub 已经做好了，第三点就是本文要接的 EveryInfra 数据接口。

为了让数字能代表两种典型情况，我们挑了一大一小两款应用。Duolingo（App Store 编号 570060128，安卓包名 com.duolingo）是评论量很大的语言学习应用；Strava（App Store 编号 426826309，安卓包名 com.strava）是评论量中等的运动记录应用。两款都是公开上架的应用，我们只读公开评论，不登录、不碰任何账号数据。美区的调用都在 2026 年 11 月 11 日 00:22 到 00:42（新加坡时间）之间完成，墨西哥和西班牙店面的两次在 11 月 12 日，见实测七。

Copilot cloud automations 是什么：10 月 28 日的发布逐条核对

GitHub 的更新日志在 2026 年 10 月 28 日发了一条「在 Visual Studio Code 里创建和管理 Copilot Automations」。按原文，这个功能需要 VS Code 1.144 或更新的版本，并且要在设置里打开 chat.automations.cloud.enabled；Copilot Pro、Pro+、Max、Business 和 Enterprise 用户都能用，入口在 VS Code 的 Agents 窗口里的 Automations 标签页。同一天的 VS Code 1.144 发布说明也写了这一项；VS Code 官网的下载页当天给的版本号是 1.144.1。VS Code 自动化文档在 2026 年 11 月 11 日的版本里换了说法：自动化和云端自动化的设置默认就是打开的，创建表单里看不到 Run in the Cloud 时，再去核对 chat.automations.enabled 和 chat.automations.cloud.enabled 这两个设置。

同一天 GitHub 还发了花费控制和团队共享自动化两条更新日志，下文算账时的 credits 上限和「做不了的地方」里的组织策略出自这两条。

把这些原文对在一起，一个 Copilot cloud automation 由三样东西组成：一段写给 agent 的说明（做什么、读哪些文件、交什么结果），一个触发条件（定时、手动，或者在 GitHub 上由 issue、PR 等事件触发），以及运行时能用的工具（GitHub 自带的工具，加上仓库 MCP 设置里配的 MCP 工具）。每次触发，GitHub 就开一个 Copilot 云端 agent 会话，在一个临时的云端环境里把说明照做一遍，会话记录留在 GitHub 上可以回看。VS Code 只是创建和管理它的一个入口，真正跑的地方是 GitHub。

表里有一条容易被忽略：VS Code 文档明确写着，云端自动化不接受本机模式和审批设置、自定义 agent，也不读本机的 MCP 配置，它继承的是仓库里的自定义说明、skills、防火墙规则和 secrets。换句话说，你在自己 VS Code 里配好的 EveryInfra MCP 服务器，云端自动化是看不到的；要让云端自动化能调，得在 GitHub 仓库的设置里再配一次。这一点后面单独讲。

定时能定多密：云端只有每天和每周

对一个评论分类任务来说，最要紧的产品事实是「最密能多久跑一次」。VS Code 的自动化文档里有一张「设一个循环时间」的表，下面一句话写得很直接：云端自动化支持手动、每天和每周三种；每小时和 Cron 表达式只适用于在本机跑的自动化。分钟只能选 00、15、30、45 四个刻度，时间按 UTC 存。我们把这一段截了下来。

这里有两份原文说法不完全一样，需要说清楚。GitHub 自己的自动化文档列的定时选项里有每小时、每天、每周，还有 issue、PR 等事件触发和一个 API 触发；VS Code 仓库里 10 月 11 日的一条测试 issue（编号 340970）写的待测项里有 Hourly 和 Weekdays。我们的理解是：在 GitHub 网页上建的自动化可以按小时跑，而在 VS Code 里建云端自动化时，界面只给每天和每周。VS Code 文档是 10 月 28 日之后的最新版本，比那条测试 issue 新，所以本文以文档为准。如果你的团队需要每小时跑，就到 GitHub 网页上建，或者用后面讲的「Actions 勤拉、自动化每天读」的拆法。

时间按 UTC 存，对新加坡团队很方便：选每天 01:00 UTC，就是新加坡时间早上 9 点。对美国西岸团队，01:00 UTC 是前一天下午 5 点或 6 点（看夏令时）。

整体流程：六步一圈

上面这张图是本文推荐的做法，一次运行分六步。第一步由 GitHub 按时触发；第二步开一个 Copilot 云端 agent 会话，agent 先读仓库里的说明文件；第三步取两家商店的新评论，走 MCP 或者走一段脚本都可以；第四步按评论 id 去掉以前看过的，只留下 1–3 星；第五步让模型读这些差评原文，按固定的几类归类，并对照前几天的数字找出涨得快的那一类；第六步把报告写进仓库，必要时开 issue。

第三步和第四步之间的分工是本文最想讲清楚的一点。如果让 agent 直接通过 MCP 调接口，接口返回的每一条评论（含作者、头像链接、版本号、点赞数等字段）都会原样进入模型的上下文；如果让一段脚本先取数、去重、只留差评，再把一个小文件交给模型，模型读的东西会少一个数量级。两种做法都能跑，后面「脚本先筛，模型后读」一节给出两种做法每天各要多少 token 的实测。

Copilot 云端 agent 怎么接 MCP：仓库设置里的那段 JSON

Copilot 云端 agent 的 MCP 服务器配在仓库设置里：仓库 Settings，左侧 Copilot 下的 MCP servers，填一段 JSON。GitHub 的 MCP 配置文档写明，配置的顶层是 mcpServers，每个服务器写 type（可以是 local、stdio、http 或 sse）、远程服务器的 url 和 headers，以及一个 tools 白名单；只支持 MCP 的工具，不支持资源和提示词；需要走 OAuth 的远程服务器目前不支持。EveryInfra 的远程 MCP 用 API Key 鉴权，不走 OAuth，所以可以直接配。下面是配置示例，我们没有在 GitHub 仓库里实际保存过这段配置。

{
  "mcpServers": {
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": {
        "Authorization": "Bearer $COPILOT_MCP_EVERYINFRA_KEY"
      },
      "tools": ["everyinfra_list_capabilities", "everyinfra_call_api", "everyinfra_get_job"]
    }
  }
}

Key 不要写进这段 JSON。GitHub 的 secrets 文档写得很细：在仓库 Settings 的 Secrets and variables 下有一个专门的 Agents 类型，名字以 COPILOT_MCP_ 开头的 secret 只会交给 MCP 服务器，不会出现在 agent 的环境变量里；其他名字的 secret 会作为环境变量交给 agent 跑的命令和脚本。会话日志里 secret 的值会被打码。所以走 MCP 的做法，Key 存成 COPILOT_MCP_EVERYINFRA_KEY；走脚本的做法，Key 存成 EVERYINFRA_API_KEY 之类不带前缀的名字。两条路要的是两个不同的 secret。

tools 白名单建议只写三个工具。我们在 00:22（新加坡时间）调了一次 EveryInfra MCP 的 tools/list，一共返回 12 个工具，评论分类只用得到列能力、调接口和查异步任务三个。白名单还有一层作用：MCP 规范给每个工具定义了 annotations，其中 readOnlyHint 表示这个工具不改任何东西。我们的返回里，everyinfra_list_capabilities 和 everyinfra_get_job 标的是只读，everyinfra_call_api 因为会扣费，标的不是只读。GitHub 文档写明 Copilot 代码审查只会用 readOnlyHint 为真的工具，所以同一套配置在代码审查里调不了接口，在云端 agent 和自动化里可以。

配好以后怎么验证，GitHub 文档给的办法是：给 Copilot 派一个 issue，打开会话日志，看「Start MCP Servers」这一步有没有把服务器和工具列出来。这里要提醒一个社区里正在讨论的问题：GitHub 社区讨论 211107（2026 年 10 月 27 日发帖）里，有人报告自定义 MCP 工具在自动化会话里能启动、也被选上了，却调不到，而同样的设置在手动开的云端会话里正常。截至我们读的时候，那个帖子里还没有 GitHub 员工给出结论。所以第一次上线时，先手动触发一次自动化，确认日志里真的有 everyinfra_call_api 的调用和返回，再交给定时去跑。

还有一个和防火墙有关的差别。GitHub 的防火墙文档写明，云端 agent 的防火墙只管 agent 通过 Bash 工具起的进程，不管 MCP 服务器的进程。走 MCP 的做法不用改防火墙；走脚本的做法，脚本里的 curl 或 Python 请求是从 Bash 起的，要在仓库的 Copilot 设置里把 api.everyinfra.com 加进自定义放行名单，否则请求会被拦。GitHub 的放行名单参考页列了默认放行的域名，我们的域名不在其中。

两项能力：`app_store/reviews` 和 `google_play/reviews`

EveryInfra 的免费目录（GET https://api.everyinfra.com/api/v1/social/catalog，不扣费）在我们读的时候列了 573 项能力。评论分类用到两项，另外两项可以在第一次配置时用来查应用编号和基本信息：app_store/search 按关键词找 App Store 应用和它的数字编号，google_play/profile 读一款安卓应用的商店页信息。四项的入口在 App Store 数据接口和 Google Play 数据接口两个平台页，能力页分别是 App Store 评论、Google Play 评论、App Store 搜索和 Google Play 应用详情。

价格按调用次数算，和返回多少条无关：App Store 一次要 500 条和要 30 条都是 $0.001389，所以每次都把 limit 开到上限最划算。Google Play 的翻页要注意一个上限：我们在 00:23（新加坡时间）对 Strava 先要了 100 条，返回带下一页的 token；用 token 拿第二页又是 100 条，返回的 stop_reason 是 depth_limit，表示到了 200 条的深度上限。也就是说，不管一次要 200 条还是分两页各要 100 条，最新的 200 条就是这项能力能拿到的全部；分页只会多扣一次钱。

两家商店字段名不一样，脚本要先对齐：星级一个叫 rating、一个叫 score；App Store 有标题、Google Play 没有；Google Play 带开发者回复 reply_text，App Store 没有。时间字段都叫 posted_at，但 App Store 带的是太平洋时区的偏移（例如 -07:00），Google Play 是 UTC。按天统计前要统一成同一个时区，否则「昨天」的边界会差 7 到 8 小时。

一次真实往返：agent 发出什么，接口回了什么

在 Copilot 云端 agent 里，模型调 MCP 工具时发出的是一个标准的 MCP tools/call 请求。我们在 00:26:38（新加坡时间）照这个格式直接给 EveryInfra MCP 发了一次，参数是 Strava 的 App Store 评论、美国商店、按最新排序、20 条。返回是一个 JSON 文本块，共 10,725 个字符，count 是 20，billing 里 charged_usd 是 0.001389。模型在会话里看到的就是这一整块文本，没有任何压缩。

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"everyinfra_call_api",
  "arguments":{"platform":"app_store","action":"reviews",
   "params":{"app_id":"426826309","country":"us","sort":"newest","limit":20}}}}

截图下半段是一次被限速的请求。我们用的测试 Key 被单独限到每分钟 10 次，并且同时有别的任务在用，00:22:43（新加坡时间）拉 Duolingo 的 Google Play 评论时收到了 429。返回里写清了原因（这把 Key 自己的每分钟上限）、retry_after 是 16 秒、retryable 为真，并且明说没有扣费。我们等了 21 秒重发，00:23:04 拿到 200 条。00:23:44 拉 Strava 的 App Store 评论又遇到一次 429，00:24:11 重发成功。两次 429 都没有扣费。

对每天跑一次的自动化来说，429 的处理很简单：在说明里写「遇到 429 就等 retry_after 秒再试，最多三次」。模型读得懂这段返回，因为错误原因、要等多久、扣没扣钱都写在里面。真正要防的是另一种情况：模型在等待时决定换一个参数重调，结果同一批评论拿了两次、扣了两次。所以说明里还要写一句「同一个应用、同一家商店，一次运行只调一次」，把调用次数钉死。

实测一：一次调用能盖住多长时间

每天跑一次是否够，先要看一次调用拿回来的评论覆盖了多长时间。我们用每条评论的 posted_at 算出最新和最旧一条的时间差。四组数据差得非常远：Duolingo 的 Google Play 英文评论 200 条只覆盖 4.25 小时，App Store 美区 500 条覆盖 37.9 小时；Strava 的 Google Play 英文评论 200 条覆盖 7.6 天，App Store 美区 450 条覆盖 123.9 天。最短和最长之间差了 700 倍。

有两点值得单独说。第一，Strava 的 App Store 这组 450 条覆盖了 2026 年 7 月 7 日到 2026 年 11 月 8 日的四个月，评论量小的应用一次调用就能看到一个季度。第二，差评占比和评论量是反着走的：评论量大的 Duolingo 差评只占 13.5% 到 21%，评论量小的 Strava 差评占一半以上。这和应用本身好坏没有直接关系，更可能是大应用有大量「顺手打五星」的评论把比例冲淡了。做分类报告时，所以要看差评的绝对条数和变化，而不是只看占比。

实测二：每天跑一次够不够

把「每天新评论数」和「一次调用的上限」放在一起，就能算出每天跑一次能接住当天多少条新评论：App Store 上限 500 条，Google Play 上限 200 条，接住比例等于上限除以每天新评论数，最多 100%。四组里有三组是 100%：Duolingo 的 App Store 每天约 317 条、Strava 两家商店每天几条到几十条，都在上限以内。只有 Duolingo 的英文 Google Play 每天约 1,131 条，一次 200 条只接住 17.7%。

接不住的部分不会自己补回来。Google Play 这项能力按最新排序只给最新的 200 条，翻页也到 200 条为止；第二天再跑，拿到的是第二天最新的 200 条，中间那 20 多个小时的评论就漏掉了。对 Duolingo 这样的应用，每天跑一次的报告看到的只是当天某 4 个小时的切片。切片里的分类比例未必有偏差，但「某一类涨了」这种判断会很不稳：你不知道那 4 个小时是不是碰巧落在一次推送通知之后。

要全接住，需要每天跑 6 次（每 4 小时一次）。在 VS Code 里建的云端自动化最密只能每天一次，所以有两条路。第一条是到 GitHub 网页上建自动化，用每小时的定时，每次都开一个 agent 会话，这样每次都花一份 AI credits 和 Actions 分钟。第二条是把取数和分析拆开：用一个普通的 GitHub Actions 定时工作流每 4 小时跑一次取数脚本（不用模型），把去重后的差评追加进仓库里的一个文件；云端自动化每天早上跑一次，只读这个文件写报告。第二条路的接口费是每天 9 次调用（Duolingo 安卓 6 次，其余三个入口各 1 次），30 天约 $0.375；模型每天只开一次会话。

对评论量中等和偏小的应用，这些都不用操心：一天一次的接住比例是 100%，而且有很大余量。一个简单的判断办法是第一次配置时手动调一次，看最新和最旧一条评论的时间差：大于 24 小时，每天一次就够；小于 24 小时，就按「24 除以时间差」向上取整，算出每天要拉几次。这个判断应该写进自动化的说明里，让 agent 每次运行都检查一遍，因为一次大版本更新或一次促销就可能让评论量翻几倍。

实测三：最新一条也是一天前的

第二个影响「每天跑一次」的事实是时差。我们用调用时刻减去返回里最新一条评论的发布时刻：Duolingo 的 App Store 是 36.9 小时，Google Play 是 24.3 小时；Strava 的 App Store 是 44.3 小时，Google Play 是 24.4 小时。两款应用的 Google Play 都恰好晚 24 小时出头，这和 Google Play 管理中心帮助页的说法对得上：新的评分和评论在公开显示前大约有 24 小时的延迟。App Store 的延迟更长，36 到 44 小时，苹果的开发者文档没有给出具体数字。

我们做了两次重复调用来确认这不是一次性的。00:29:13（新加坡时间）再拉一次 Duolingo 的 Google Play 评论，和 6 分钟前那次比，200 条里 177 条相同、23 条是新的，最新一条的时间往后挪了一点，说明 Google Play 这边一直在滚动放出新评论，只是整体晚一天。00:40:33 再拉一次 Duolingo 的 App Store 评论，和 18 分钟前那次比，500 条一条不差，没有一条新的，说明 App Store 这边是成批更新的。

对自动化的设计，这个时差有三个直接影响。第一，报告里要写清「这份报告覆盖的是哪一段发布时间」，不要写成「今天的差评」，它其实是前天到昨天的差评。第二，「新」评论要按 id 判断，不能按发布时间判断：一条 40 小时前发布的评论，可能今天才第一次被拉到。第三，定时不必追求整点准时，早半小时晚半小时，拿到的数据几乎一样。

实测四：差评分成几类

分类规则先用一张关键词表写死在脚本里，这样结果可以复算，也方便和后面模型的判断对比。规则按优先级从高到低：崩溃和故障（crash、freeze、bug、not working、stuck 等）、登录和账号（log in、sign in、password、account 等）、付费和订阅（subscription、charge、refund、premium、trial 等）、同步和设备（sync、GPS、Garmin、watch、upload 等）、广告、改版和更新（update、redesign、changed 等）。一条评论命中多条规则时，按第一条命中的定类；一条都没命中的算「其他」。

两款应用的差评结构完全不同。Duolingo 的差评以「其他」和付费为主，崩溃和登录问题很少，「其他」里大多是对课程设计、体力值、学习方式的抱怨，关键词规则抓不住。Strava 的差评里付费仍是第一大类，但崩溃、同步和登录加起来比付费还多，这和它要连手表、要记录 GPS 轨迹的产品性质一致。对一个只看占比的报告来说，Duolingo 每天 27 条英文安卓差评里 19 条是「其他」，这份报告几乎没有信息量；所以分类这一步不能只靠关键词。

实测五：关键词规则准不准

为了知道关键词规则能不能单独用，我们从四组差评里用固定的随机种子抽了 40 条，逐条读标题和正文，自己判一个类别，再和规则的结果比。结果是规则归对 23 条，归错 13 条，漏掉 4 条（规则判成其他、人判成某一类）。样本只有 40 条，这个比例只说明数量级：关键词规则大约对一半多一点。

错的 13 条很有规律。最多的是「account」这个词：用户说「我付了全年会员却一直用不了」，正文里有 account，规则按优先级先判成登录，实际是付费问题；用户投诉客服、或者说缺少某种训练类型，也因为提到 account 被判成登录。第二种是「super」：Duolingo 的付费档叫 Super，规则把它当付费词，结果「super annoying」也被判成付费。第三种是 Strava 安卓的流量问题：「更新以后几个小时吃掉 4GB 移动流量」里有 GB 和数字，被付费规则里的金额模式误抓，实际上是一个故障。漏掉的 4 条则是没有关键词的描述，比如「心率不显示」「iPad mini 不能全屏」「自动暂停太糟」。

这些错误正好说明了模型该放在哪一步。关键词规则适合做第一道筛子：便宜、可复算、能先把明显的付费和崩溃抓出来；但最终的类别要让模型读原文判。几篇公开论文的测量可以对照：一篇 2025 年 5 月的论文用 ChatGPT 零样本把 1,880 条人工标注的应用评论分成功能需求、非功能需求等四类，F1 是 0.842；一篇 2025 年 10 月的论文测了五个轻量开源模型，用户反馈分类的 F1 在 0.47 到 0.68 之间；一篇 2025 年 7 月的论文把简单的反馈交给微调过的小模型、拿不准的交给大模型，准确率保住了纯大模型零样本做法的 98.4% 到 100.4%（超过 100% 表示比纯大模型略好），请求数和 token 成本分别降了 67.8% 和 66.3%。这几篇的分类体系和我们的不同，数字不能直接搬过来，但方向一致：便宜的一层先分，难的交给大模型。我们用关键词表顶替那篇论文里的小模型，思路相同。

实测六：Strava 安卓的流量问题，每天跑能早几天看到

分类报告真正的价值是看到「某一类突然多了」。我们在 Strava 的 Google Play 评论里看到了一个现成的例子：200 条里有 23 条在说应用吃掉大量移动流量（例如两次徒步用掉 3GB、6 小时不到用掉近 4GB），其中 21 条是 1 星。同一时期 Strava 的 App Store 450 条评论里，提到流量的一条都没有。问题只出现在安卓端。

按发布日看，2026 年 11 月 2 日一天就有 10 条，之后每天 0 到 3 条，逐日下降。按版本看，23 条里 17 条来自 487.11 版、4 条来自 488.11 版；487.11 版本身有 86 条评论，提到流量的占约 20%，488.11 版有 68 条评论，提到流量的约 6%。有一条评论写着问题从 2026 年 10 月 22 日开始、两周没修；Reddit 的 Strava 版块也有一个讨论帖，用户说安卓端某天起流量暴涨，有人转述客服建议先关掉移动数据。我们没有找到 Strava 对这个问题的公开说明，所以只描述评论里看到的事实，不判断原因。

假设一个团队从 10 月下旬开始就跑着每天的差评分类，这个问题在报告里会是什么样子：前一两天它会混在「付费」或「其他」里（关键词规则会误判，正如上一节所说），模型读原文以后会把它归进「故障」，并且因为同一个描述在一天里出现了 10 次而被标成异常，开出 issue。每周看一次的周报，最快也要在问题出现几天后才看到。这就是每天跑和每周跑的差别，也是本文和 Codex Cloud 评论周报那篇最不一样的地方。

实测七：换到西语市场，定时和关键词表都要重算

不少团队的应用同时上架美国、墨西哥和西班牙。2026 年 11 月 12 日我们又调了两次 App Store 评论：00:15:21（新加坡时间）取 Duolingo 的墨西哥店面，00:15:33（新加坡时间）取西班牙店面，country 分别是 mx 和 es，各 500 条，两次共扣费 $0.002778。分类用了两套关键词表：一套是实测四的英文表，一套是看结果之前写死的西语表，里面是 se cierra、no funciona、iniciar sesión、contraseña、suscripción、cobro、reembolso、sincronizar、anuncio、actualización 这类词。

第一个结论是量。同一款 Duolingo，美区 App Store 500 条只盖 37.9 小时，墨西哥店面盖 15.4 天（发布时间从 2026 年 10 月 25 日到 2026 年 11 月 10 日），西班牙店面盖 40.3 天（从 2026 年 9 月 30 日到 2026 年 11 月 9 日）。美区英文 Google Play 每天要拉 6 次才接得住，这两个西语店面每天一次绰绰有余。所以在多个国家上架的应用，不要把一个市场的定时照搬到另一个市场：每个店面先手动调一次，按「24 除以时间差」各算各的。两个西语店面最新一条评论分别晚 37.0 和 41.5 小时，和美区 App Store 的 36 到 44 小时一致。

第二个结论是语言。英文关键词表在墨西哥的 72 条差评里只归进了 8 条，在西班牙的 157 条里只归进了 25 条，其余全落进「其他」；换成西语表，两边都升到 54% 到 55%。但仍有近一半没归上：墨西哥有 8 条在说连续打卡（racha）断了，11 条在说体力值（vidas、corazones、energía），两套表里都没有这些词；西班牙有 24 条提到广告（anuncio、publicidad），规则按优先级只把其中 10 条归进广告。评论有好几种语言时，关键词表要按语言各写一份，模型读原文这一步更省不掉。

脚本先筛，模型后读：为什么不让 agent 直接吃 MCP 返回

先算 token。四组原始返回里，每条评论平均 437 到 569 字节，按 OpenAI 帮助文档「英文约 4 个字符 1 个 token」的经验比例，约 109 到 142 个 token；00:26:38 那次 MCP 往返，20 条评论的文本块是 10,725 个字符，每条约 536 个字符，和这个估算一致。如果每天四个入口各调一次、让模型直接读 MCP 原样返回（Duolingo App Store 按每天新增约 317 条、其余按当天实际条数），每天约 65,062 个 token 进上下文。如果先用脚本按 id 去掉看过的、只留 1–3 星、只留标题和正文，每天约 4,999 个 token。两者相差约 13 倍。

按 GitHub 公开的模型价格（每百万输入 token：Claude Sonnet 5.5 $2，Claude Haiku 5.5 和 GPT-6 Luna 都是 $0.10，Claude Opus 5.5 $4），只算数据这一部分，Sonnet 5.5 原样读是每天 $0.1301，筛过再读是每天 $0.0100；Haiku 5.5 原样读每天 $0.0065，筛过再读每天 $0.0005。这里只算了数据进上下文的输入费用，agent 读说明、读仓库文件、写报告、开 issue 的开销都没算，我们没有跑真实会话，没法给这部分的实测数。数据部分已经能说明方向：筛过再读，用好模型也很便宜；不筛就读，同样的钱只能用小模型。

脚本先筛还有两个好处。一是去重靠代码，不靠模型的记性：实测三说过一条评论可能今天才第一次被拉到，按 id 记下看过哪些、只增不减，这种逻辑写在脚本里才可靠。二是作者名、头像链接这些字段在进上下文之前就被丢掉了，报告和 issue 里不会意外出现普通用户的名字。下面是一个最小的取数脚本，放在仓库里，自动化每次运行时让 agent 用 Bash 跑它。这段脚本我们在 00:41:50（新加坡时间）用测试 Key 实际跑过一次，两家商店各调 1 次，扣费 $0.002778，第一次运行把 600 条全部记为看过，其中 311 条 1–3 星写进了当天的文件。

"""取 App Store / Google Play 新评论，去掉看过的，只留 1-3 星给模型读。"""
import json, os, pathlib, urllib.request, datetime

API = "https://api.everyinfra.com/api/v1/social"
KEY = os.environ["EVERYINFRA_API_KEY"]          # Agents secret，不带 COPILOT_MCP_ 前缀
APPS = [
    ("app_store", "426826309", {"country": "us", "sort": "newest", "limit": 500}),
    ("google_play", "com.strava", {"country": "us", "language": "en", "sort": "newest", "limit": 200}),
]
STATE = pathlib.Path(".triage/seen.json")

def call(platform, app_id, params):
    body = {"platform": platform, "action": "reviews", "params": {"app_id": app_id, **params}}
    req = urllib.request.Request(API, data=json.dumps(body).encode(), method="POST", headers={
        "Authorization": f"Bearer {KEY}", "Content-Type": "application/json", "User-Agent": "review-triage/1.0"})
    with urllib.request.urlopen(req, timeout=120) as r:
        return json.load(r)

seen = set(json.loads(STATE.read_text())) if STATE.exists() else set()
out, spent = [], 0.0
for platform, app_id, params in APPS:
    data = call(platform, app_id, params)
    spent += data.get("billing", {}).get("charged_usd", 0)
    for r in data.get("results", []):
        key = f"{platform}:{r['id']}"
        stars = r.get("rating", r.get("score"))
        if key in seen:
            continue
        seen.add(key)                              # 记为看过
        if stars is not None and stars <= 3:
            out.append({"key": key, "stars": stars, "version": r.get("app_version"),
                        "posted_at": r["posted_at"],
                        "text": ((r.get("title") or "") + " | " + (r.get("text") or ""))[:600]})
day = datetime.date.today().isoformat()
pathlib.Path("reports").mkdir(exist_ok=True)
pathlib.Path(f"reports/{day}.new-low-star.json").write_text(json.dumps(out, ensure_ascii=False, indent=1))
STATE.parent.mkdir(exist_ok=True)
STATE.write_text(json.dumps(sorted(seen)))
print(json.dumps({"new_low_star": len(out), "seen_total": len(seen), "charged_usd": round(spent, 6)}))

脚本最后一行打印的是本次新增差评条数、累计看过的条数和本次接口费，agent 会在会话里看到这三个数，可以直接写进报告的开头。.triage/seen.json 要提交回仓库，否则第二天的云端环境是全新的，脚本会把所有评论都当成新的。第一次运行会把历史评论全部算作「新」，所以第一份报告应该只当基线，不做异常判断。

给自动化的说明怎么写

自动化的说明就是一段写给 agent 的文字，在 VS Code 的 Automations 标签页里建的时候填进去。说明里写得越具体，每天的结果越稳定，也越省 credits：模型不用每次重新想「我该做什么」。下面是一个配置示例，我们没有在 GitHub 上保存过这个自动化；分类规则和报告格式我们建议放在仓库的 .github/skills/review-triage/ 里做成一个 skill，GitHub 的 agent skills 文档写明云端 agent 会从 .github/skills、.claude/skills 或 .agents/skills 读项目级 skill，自动化也会继承仓库里的 skills。

每天的应用商店差评分类（配置示例）

1. 运行 `python3 scripts/triage.py`。它会取 App Store 和 Google Play 的新评论，
   写出 reports/<日期>.new-low-star.json，并打印 new_low_star、seen_total、charged_usd。
   每个商店入口一次运行只调一次；遇到 429 等 retry_after 秒再跑，最多 3 次。
2. 读这个 JSON，按 .github/skills/review-triage/SKILL.md 的类别给每条差评归类：
   崩溃和故障、付费和订阅、登录和账号、同步和设备、广告、改版和更新、其他。
   只读原文判断，不要按单个关键词判断。
3. 写 reports/<日期>.md：覆盖的发布时间范围、各类条数、与过去 7 份报告的平均值对比、
   每类最多 3 条原文（去掉人名），以及本次接口费。
4. 如果某一类的条数超过过去 7 天平均值的 3 倍且不少于 5 条，开一个 issue，
   标题写「[差评异常] 类别 + 版本号」，正文贴例子。同一类别已有未关闭的同名 issue 时只追加评论。
5. 把 reports/ 和 .triage/seen.json 提交到 triage-reports 分支并开 PR，不要直接推 main。

第 4 条的阈值（3 倍、不少于 5 条）只是一个起点，每个团队应该按自己应用的评论量改。第 5 条是安全考虑：GitHub 关于云端 agent 风险和缓解的文档写明，agent 默认在 copilot/ 开头的分支上工作、通过 PR 交付，不直接推受保护的分支；评论正文来自外部用户，可能夹带「忽略以上说明」之类的文字，把结果放进 PR，等于在 agent 和主分支之间留一道人看的门。

报告和 issue 长什么样

报告的第一屏应该让人 10 秒内看完。下面是用 00:22 到 00:24（新加坡时间）那几次真调的 Strava 数据，按上面的说明手工排出来的报告样例；类别条数来自关键词规则，没有经过模型复核，所以只用来示范格式。

# 差评日报 2026-11-11（Strava）

覆盖：Google Play 英文 2026-11-02 ～ 11-09（UTC），App Store 美区 2026-07-07 ～ 11-08
新增 1–3 星：Google Play 102 条，App Store 236 条（首次运行，只作基线）
本次接口费：$0.002778（2 次调用）

| 类别 | Google Play | App Store |
|---|---|---|
| 崩溃和故障 | 19 | 44 |
| 付费和订阅 | 14 | 63 |
| 登录和账号 | 12 | 25 |
| 同步和设备 | 11 | 28 |

待看：Google Play 有 23 条说「更新后吃掉大量移动流量」，集中在 487.11，App Store 0 条。

issue 只在「明显涨了」时开，内容比报告短：类别、版本号、条数和过去的平均值、三条原文、一条到报告文件的链接。GitHub 的 issues REST 接口和 Copilot 云端 agent 自带的 GitHub 工具都能开 issue，自动化里直接让 agent 用自带工具即可，不需要再给它另外一个 GitHub Token。

算一笔账：接口费、AI credits 和 Actions 分钟

Copilot 一侧按 2026 年 11 月 11 日读到的 GitHub 计费文档和套餐页算。现在 Copilot 的用量按 AI credits 计，1 个 credit 是 $0.01；个人套餐每月含的 credits：Pro（$10/月）1,500，Pro+（$39/月）7,000，Max（$100/月）20,000；Business（$19/用户/月）每用户 1,900，Enterprise（$39/用户/月）每用户 3,900。云端 agent 和自动选模型有 10% 的折扣。每次自动化运行开一个云端 agent 会话，消耗按模型 token 计的 credits，另外按 GitHub Actions 的规则消耗分钟；Linux 2 核的单价是每分钟 $0.006。GitHub 的自动化文档还允许给每次运行、每天、每周和每月分别设 credits 上限（单次运行最低只能设到 30 credits），每天的计数在 00:00 UTC 重置。

从这张表能看出几件事。接口费在整件事里是最小的一项，就算为了接住全部评论每天拉 9 次，一个月也不到 $0.40。模型读数据的费用取决于「让不让脚本先筛」，差 13 倍。Actions 分钟取决于每次会话跑多久，10 分钟是我们的假设，不是实测；仓库所属账户每月含的 Actions 分钟用完之前，这部分不另外收钱，具体额度看 GitHub Actions 计费文档。真正没法从公开资料算出来的是会话本身的开销，所以我们建议第一次上线时把单次运行的上限设低一点，跑一周看 GitHub 的用量页，再按实际数调整。

为什么不用商店自己的接口

两家商店都有给开发者的官方接口，但都只能读自己的应用。苹果的 App Store Connect API 有「列出某个应用的全部顾客评论」的接口，要用开发者账号的 API 密钥，只能读你自己团队名下的应用。Google Play Developer API 的 reviews.list 只返回最近一周的评论，只包括正式版应用、只包括带文字的评论，读取的配额是每小时 200 次；回复评论限 350 个字符。对一个只看自家应用的团队来说，这两个接口是第一选择：免费，而且是商店自己给的数据。

它们做不到的是三件事：看竞品，看一周以前，把两家商店放进同一个格式。很多团队的差评日报除了自家应用，还会放一两个直接竞品，看同一个问题（比如某次系统更新以后的崩溃）是不是全行业都有。EveryInfra 的两项评论能力对任何公开应用都一样调，字段统一成 JSON，一次调用 $0.001389。我们的建议是：自家应用的回复、精确统计用商店官方接口；竞品和跨商店的对比用数据接口；两者在同一个自动化里可以并存，报告里分开写。

做不了或要注意的地方

第一，VS Code 里建的云端自动化只能用在私有库和内部库，公开仓库不行；共享给团队的自动化还要求组织打开「允许使用按组织计费的 Copilot 云端 agent」这条策略。第二，云端自动化读不到你本机 VS Code 里的 MCP 配置，必须在 GitHub 仓库设置里再配一次；社区讨论 211107 报告的「自动化会话里自定义 MCP 工具调不到」问题，在我们读的时候还没有结论，第一次上线要手动触发一次确认。第三，在 VS Code 里最密只能每天一次，评论量大的应用要到 GitHub 网页上建每小时的自动化，或者用 Actions 勤拉。

第四，数据接口：Google Play 这项能力最多给最新的 200 条，country 不改变返回哪些评论，要按语言分开调；App Store 最多 500 条、不翻页，要看哪个国家的店面就把 country 设成哪个国家，墨西哥和西班牙店面的评论量和美区差得很远（见实测七）。第五，两家商店的新评论都要晚 24 到 44 小时才拿得到，所以这份日报看的是「前天到昨天」，不能代替崩溃监控工具的实时告警。第六，评论正文是外部用户写的，可能含有试图影响 agent 的文字；结果走 PR、不给 agent 推主分支的权限、报告里去掉用户名，这三件事都应该做。

第七，本文所有 Copilot 一侧的步骤都是配置示例：我们没有在 GitHub 仓库里建过这个自动化，也没有跑过真实会话，所以没有会话时长、会话总 token、credits 实际消耗这三个数。文中所有 EveryInfra 一侧的数字都来自 2026 年 11 月 11 日和 12 日的真调，接口费按目录里的价格和返回里的 charged_usd 核对过。本文不代表 GitHub 或微软的立场，EveryInfra 与这两家公司没有合作关系。

常见问题

vs code copilot cloud automations not working，自动化没跑起来怎么查？

先按 VS Code 文档核三件事：VS Code 版本是不是 1.144 或更新、设置 chat.automations.cloud.enabled 有没有打开、仓库是不是私有库或内部库。然后在 GitHub 上打开那次运行的会话日志，看是触发没发生、会话起不来，还是工具调不到。如果是自定义 MCP 工具在自动化里调不到、在手动会话里正常，和 GitHub 社区讨论 211107 描述的情况一样，可以先改用脚本取数的做法绕开。

copilot cloud agent pricing：每天跑一次大概多少钱？

每次运行开一个云端 agent 会话，按模型 token 消耗 AI credits（1 credit 是 $0.01），另外按 Actions 规则消耗分钟。本文只能给出能实测的部分：两款应用每天的接口费 $0.0056；用 Sonnet 5.5 读筛过的差评，数据部分每天约 $0.01；会话其余开销我们没有实测。建议先设单次运行的 credits 上限，跑一周看用量页。

google play store reviews api 为什么只拿得到一周？

Google Play Developer API 的回复评论文档写明 reviews.list 只返回最近一周的评论，而且只包括正式版应用、只包括带文字的评论。超过一周的历史，要靠自己每天存，或者用其他数据接口按最新排序每天拉。

上手

第一步，到 EveryInfra 快速开始拿一把 API Key，先用免费目录查 app_store/reviews 和 google_play/reviews 的参数。第二步，用 app_store/search 或商店网址找到你和竞品的应用编号，手动调一次评论接口，看最新和最旧一条的时间差，算出每天要拉几次。第三步，按本文的配置示例在 GitHub 仓库里配 MCP 或者放好取数脚本和 secret，在 VS Code 的 Automations 标签页里建一个每天的云端自动化，先手动触发一次，确认会话日志里有接口调用和报告提交。远程 MCP 的完整说明在 EveryInfra MCP 服务器，价格在价格页。

站内相关的几篇：GitHub Copilot MCP 竞品社媒周报让模型只写一个每周跑的 Actions 脚本；Codex Cloud 评论周报用同样两家商店的数据，每周出一份；想把评论数据做成对外产品，看评论数据产品化；担心 agent 重试时重复扣费，看用幂等键防止 AI agent 重试重复扣费。

参考资料

1. Create and manage Copilot Automations in Visual Studio Code，GitHub 更新日志，2026-10-28，https://github.blog/changelog/2026-10-28-create-and-manage-copilot-automations-in-visual-studio-code/
2. Automations，VS Code 文档，2026-11-11 读取，https://code.visualstudio.com/docs/agents/run/automations
3. VS Code 1.144 发布说明，2026-10-28，https://code.visualstudio.com/updates/v1_144
4. About automations，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/copilot/concepts/agent-capabilities/agent-powered-workflows-and-operations/about-automations
5. Creating automations，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/create-automations
6. New tools, triggers, and cost controls for Copilot automations，GitHub 更新日志，2026-10-28，https://github.blog/changelog/2026-10-28-new-tools-triggers-and-cost-controls-for-copilot-automations/
7. Build shared workflows for your team with Copilot automations，GitHub 更新日志，2026-10-28，https://github.blog/changelog/2026-10-28-build-shared-workflows-for-your-team-with-copilot-automations/
8. Copilot automations now learn from outcomes and self-improve，GitHub 更新日志，2026-10-28，https://github.blog/changelog/2026-10-28-copilot-automations-now-learn-from-outcomes-and-self-improve/
9. GitHub Agentic Workflows generally available，GitHub 更新日志，2026-10-28，https://github.blog/changelog/2026-10-28-github-agentic-workflows-generally-available/
10. GitHub Universe 2026: evolving every layer of the stack，GitHub 博客，2026-10-28，https://github.blog/news-insights/company-news/github-universe-2026-evolving-every-layer-of-the-stack/
11. REST API endpoints for agent automations（API 版本 2026-03-10），GitHub 文档，2026-11-11 读取，https://docs.github.com/rest/agent-automations/agent-automations?apiVersion=2026-03-10
12. Test automations（issue 340970），microsoft/vscode，2026-10-11，https://github.com/microsoft/vscode/issues/340970
13. Configure MCP servers for your repository，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers
14. About MCP，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/copilot/concepts/customizations/mcp
15. Configure secrets and variables for Copilot cloud agent，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/configure-secrets-and-variables
16. Customizing or disabling the firewall for Copilot cloud agent，GitHub 文档，2026-11-11 读取，https://docs.github.com/copilot/how-tos/agents/copilot-coding-agent/customizing-or-disabling-the-firewall-for-copilot-coding-agent
17. Copilot allowlist reference，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/copilot/reference/copilot-allowlist-reference
18. About Copilot cloud agent，GitHub 文档，2026-11-11 读取，https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
19. Risks and mitigations for Copilot cloud agent，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations
20. About agent skills，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/copilot/concepts/agents/about-agent-skills
21. Usage-based billing for individuals，GitHub 文档，2026-11-11 读取，https://docs.github.com/copilot/concepts/billing/usage-based-billing-for-individuals
22. Plans for GitHub Copilot，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/copilot/get-started/plans
23. Models and pricing，GitHub 文档，2026-11-11 读取，https://docs.github.com/copilot/reference/copilot-billing/models-and-pricing
24. About billing for GitHub Actions，GitHub 文档，2026-11-11 读取，https://docs.github.com/billing/managing-billing-for-github-actions/about-billing-for-github-actions
25. Actions runner pricing，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/billing/reference/actions-runner-pricing
26. REST API endpoints for issues，GitHub 文档，2026-11-11 读取，https://docs.github.com/en/rest/issues/issues
27. Custom MCP tools unavailable in automation sessions（讨论 211107），GitHub 社区，2026-10-27，https://github.com/orgs/community/discussions/211107
28. Copilot automations 讨论 211008，GitHub 社区，2026-11-11 读取，https://github.com/orgs/community/discussions/211008
29. Cloud sandbox sessions，VS Code 文档，2026-11-11 读取，https://code.visualstudio.com/docs/agents/run/cloud-sandbox-sessions
30. Add MCP servers in VS Code，VS Code 文档，2026-11-11 读取，https://code.visualstudio.com/docs/copilot/customization/mcp-servers
31. Introducing Agent Skills in VS Code，VS Code YouTube 频道，2026-11-11 读取字幕，https://www.youtube.com/watch?v=JepVi1tBNEE
32. Tools，Model Context Protocol 规范 2025-06-18，https://modelcontextprotocol.io/specification/2025-06-18/server/tools
33. Reply to reviews，Google Play Developer API 文档，2026-11-11 读取，https://developers.google.com/android-publisher/reply-to-reviews
34. androidpublisher v3 reviews（Python 参考），Google 开发者文档，2026-11-11 读取，https://developers.google.com/resources/api-libraries/documentation/androidpublisher/v3/python/latest/androidpublisher_v3.reviews.html
35. View and analyze your app's ratings and reviews，Play 管理中心帮助，2026-11-11 读取，https://support.google.com/googleplay/android-developer/answer/138230
36. List all customer reviews for an app，App Store Connect API 文档，2026-11-11 读取，https://developer.apple.com/documentation/appstoreconnectapi/get-v1-apps-_id_-customerreviews
37. Ratings, reviews, and responses，Apple Developer，2026-11-11 读取，https://developer.apple.com/app-store/ratings-and-reviews/
38. What are tokens and how to count them，OpenAI 帮助中心，2026-11-11 读取，https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them
39. Hybrid routing for app review classification（arXiv 2507.08250），2025，https://arxiv.org/html/2507.08250v2
40. Zero-shot app review classification with ChatGPT（arXiv 2505.04759），2025，https://arxiv.org/html/2505.04759v1
41. Lightweight LLMs for app review analysis（arXiv 2510.23055），2025，https://arxiv.org/pdf/2510.23055
42. Mobile data usage shot up today（Android），Reddit r/Strava，2026-11-11 读取，https://www.reddit.com/r/Strava/comments/1xcqvgv/mobile_data_usage_shot_up_today_android/
43. EveryInfra 数据能力目录（免费），2026-11-11 00:21 读取，2026-11-12 复核单价未变，https://api.everyinfra.com/api/v1/social/catalog