Claude Cowork 定时任务：每周竞品价格评论表

我们在 2026 年 11 月 3 日 00:15–00:29（新加坡时间）用 EveryInfra 接口真调了 Amazon 和 Walmart 上 3 款 4 夸脱空气炸锅竞品的价格和评论，约一小时后（01:12–01:16）又按同样参数复查了一轮。最容易把周报做错的不是价格本身，而是「谁在卖」和「用哪个关键词查」：Walmart 上同一个商品编号的 Ninja Crispi，用「ninja air fryer 4 quart」搜，显示 Patent Paid 卖 $135；用「ninja crispi glass air fryer」搜，显示 Mercshop 卖 $134.50。一小时后两次复查只隔 9 秒，结果还是各自那样。所以一张每周一自动生成的「竞品价格与评论变化表」，每个商品要固定用同一个关键词去查，每一行都要把价格和卖家一起存下来，否则表里的「降价 $0.50」其实只是换了关键词、看到了另一家卖家。按目录价，盯 3 个竞品、两家店，每周 10 次调用合计 $0.014737，一个月约 $0.064，只有 Claude Pro 月费 $20 的 0.32%；真正要花心思的是 Cowork 这一侧的三件事：连接器怎么加、工具审批怎么提前放行、上周的数据存在哪。

这篇文章回答一个具体的问题：一个在 Amazon 和 Walmart 卖小家电的团队，想每周一早上打开电脑就看到一张表，列出几个主要竞品这一周在两家店的价格、折扣、卖家、评分和新差评，和上周比变了什么。我们用 Claude Cowork 的定时任务（scheduled tasks）来跑，用自定义连接器接 EveryInfra 的远程 MCP 服务器 https://api.everyinfra.com/mcp。EveryInfra 一侧的每个数字都来自 15 次真调的原始返回；Cowork 一侧我们没有在 claude.ai 上建任务，所以那部分全部写成「配置示例」，每条事实都链到 Anthropic 的帮助中心、文档或更新日志原文，读取日期是 2026 年 11 月 3 日。

这件活是什么：每周一一张竞品价格与评论变化表

先把任务说死，后面所有的数都按它算。输入是一份竞品清单，每个竞品在两家店各对应一个商品：Amazon 用 ASIN，Walmart 用商品编号（item_id）。我们用 4 夸脱级空气炸锅做例子，挑了三组：Ninja 的基础款（Amazon 上是 AF101，Walmart 上是 Walmart 专供的 AF100WM），Ninja Crispi 4 合 1 玻璃款（Amazon 上是 FN101 的石色款，Walmart 上是 FN101PK1 樱花粉款），以及 Instant Pot 的 Vortex 4 夸脱迷你款。挑空气炸锅是因为它在两家店都是畅销品类，竞品多、价格动得勤，而且 11 月 12 日起 Walmart 有三轮节日促销（Walmart 新闻稿，2026-10-26），接下来几周正是最需要每周盯价的时候。

输出是一张表，每个竞品每家店一行，列包括：本周价格、划线价、折扣率、卖家、评分、评分数或评论数、和上周相比的价格变化、评论数增量、本周新出现的 1–2 星评论条数和它们主要在抱怨什么，最后一列是一句话的「要不要管」。这件活有三个特点，正好对上定时任务的用途：一是固定节奏，每周一次，不需要人临时起意；二是只读，不下单、不改价、不发消息，出错的代价是一张表不准，不是一笔钱没了；三是要和上一次比，所以必须有地方存上周的结果。第三点是 Cowork 定时任务和普通聊天最大的区别，后面单独一节讲。

为什么不直接在 Amazon 和 Walmart 的卖家后台看？因为后台只给你看自己的商品。Walmart 卖家中心的评论页明确写着只显示在 Walmart.com 上买了你这个报价的顾客的反馈，别的卖家报价下的评论不显示（Walmart Marketplace Learn：评论概览）。Walmart 的定价洞察看板能比你和购物车赢家的价格，但同样只针对你自己的商品（Walmart Buy Box 指南）。看竞品，只能从公开商品页上取数，这正是 Amazon 数据接口 和 Walmart 数据接口 做的事。

竞品清单怎么来，决定了这张表能不能长期用。我们的建议是由人在第一周手工定好，每个竞品一行，写清楚 Amazon 的 ASIN 和 Walmart 的商品编号：ASIN 是 Amazon 商品页地址里 /dp/ 后面那 10 位，Walmart 的商品编号是商品页地址里 /ip/ 后面最后那串数字，例如 Crispi 樱花粉款是 https://www.walmart.com/ip/20370717802。再配一个搜索关键词，用来在 walmart/search 的前 20 条里找到这个编号。之所以不让模型每周自己去搜「Ninja 4 夸脱空气炸锅」再挑同款，是因为搜索排序每周都在变，同一个关键词今天排第 6 的商品下周可能掉到第 25，模型挑到的「同款」就会悄悄换成另一个型号，表里的变化就没有意义了。

claude cowork scheduled tasks 现在是什么样

Cowork 定时任务是 2026 年 2 月 25 日上线的，当时的发布说明写的是可以在 Cowork 里创建循环任务和按需任务（Claude 帮助中心发布说明）。最早它跑在你自己的电脑上，桌面应用关了、电脑睡了就不跑，这也是社区里抱怨最多的一点：有人在 r/ClaudeAI 说，如果只在电脑开着时运行，定时这件事本身就没意义了（Reddit 讨论）。这个前提在 10 月变了。

帮助中心现在写的是：定时任务在所有付费套餐可用，包括 Pro、Max、Ultra、Team 和 Enterprise；它「远程运行」，所以电脑睡着或桌面应用关着时照常按计划跑；每次运行是一个独立的 Cowork 会话，可以用你在 Cowork 里设置好的连接器、技能和插件（Schedule recurring tasks in Claude Cowork）。另一篇帮助文章讲清了变化的日期：2026 年 10 月 6 日起，Pro、Max、Ultra 套餐新建的 Cowork 任务都在云端运行，设置里的「Only on your computer」选项被去掉，不能切回去；10 月 6 日前已经在本机跑的定时任务继续在本机跑，新建的定时任务在云端跑（Use Claude Cowork on web, desktop, and mobile）。

手动建任务时要填的字段，帮助中心列得很清楚：任务名、描述任务的提示词、审批模式、运行频率（每小时、每天、每周、工作日，或者只手动运行）、可选的模型、可选的工作文件夹。这里有一句容易被忽略的注：如果定时任务需要本机文件或应用，它只会在本机运行（同一篇帮助文章）。所以竞品周报这类活，最好设计成完全不碰本机文件：数据从连接器来，结果写到连接器里，这样才能真的在电脑睡着时跑。

还有一个界面上的变化会影响你找不找得到入口。2026 年 9 月 16 日起，Anthropic 开始把 Cowork 和聊天合成一个界面，逐步推给 Pro、Max、Ultra；如果你的输入框里已经没有「Chat」和「Cowork」两个选项，说明你在新界面里，直接在任何对话里说「每周一早上 9 点做某事」就能建定时任务，Claude 会把任务名、频率和指令列出来，你点「Schedule」确认（Claude Cowork and chat are one Claude；发布说明）。

Cowork 定时任务和 Claude Code 定时任务有什么不同

我们在 11 月 1 日写过一篇 Claude Code 定时任务每晚读 Reddit 痛点，那篇用的是 Claude Code 的云端定时任务（原名 routines）。两者名字一样，都在云端跑，都消耗订阅用量，但它们解决的是两类活。Claude Code 的云端定时任务是一个保存下来的 Claude Code 配置：提示词、一个或多个代码仓库、一组连接器，触发方式有定时、API 和 GitHub 事件三种，每次运行是一个完整的 Claude Code 云端会话，可以跑命令、改代码、开 PR（Automate work with scheduled tasks）。Cowork 定时任务不挂仓库，面向的是报告、简报、整理文件这类知识工作，产出是一个 Cowork 会话和里面的文件。

表里 Claude Code 那一列的「每小时 100 次」和「cron 最密每小时一次」来自同一页文档的用量与触发两节（Claude Code 云端定时任务文档）。Cowork 这一列我们查了帮助中心的定时任务、团队版、安全、架构四篇文章，都没有写每个账号能建多少个定时任务、每小时能跑多少次，Reddit 上也有人问过同一个问题，没有人给出官方数字（Reddit 讨论）。所以我们写「未找到公开数字」，不猜。

对竞品周报来说，判断很直接：它不需要仓库，不需要改代码，结果是一张给运营看的表，Cowork 定时任务更顺手。如果你的团队本来就把数据和脚本放在 Git 仓库里，想让上周的快照自然留在提交历史里，那就用 Claude Code 的云端定时任务，做法见《claude code scheduled tasks 每晚读 Reddit：一页 100 帖只盖 18.7 小时》；两篇调的是同一个远程 MCP 地址，连接器配置可以照搬。

把 EveryInfra 加成自定义连接器

Cowork 里调外部数据，靠的是自定义连接器。帮助中心写明，基于远程 MCP 的自定义连接器在 Claude、Cowork 和 Claude Desktop 上对 Free、Pro、Max、Ultra、Team、Enterprise 都开放，Free 只能加一个（Get started with custom connectors using remote MCP）。个人套餐的入口是 Customize > Connectors，点「+ Add」再选「Add custom connector」，填名字和远程 MCP 服务器地址。

鉴权是第一个容易卡住的地方。EveryInfra 的远程 MCP 用 API Key 鉴权，不走 OAuth：initialize 和 tools/list 不带 Key 也能读，调用工具时要在请求头里带 Authorization: Bearer 加 Key（EveryInfra MCP 接入页）。MCP 规范把鉴权写成可选项，规范里的 OAuth 流程只在服务器支持它时才适用（MCP 规范：Authorization）；Authorization: Bearer 这个请求头格式本身出自 OAuth 的 Bearer Token 标准（RFC 6750），客户端照常带上即可。我们在 2026 年 11 月 3 日 00:47（新加坡时间）用不带 Key 的请求试了一次 tools/call，服务器 0.09 秒就回了 unauthorized: no API key provided，并在下一段写明「Nothing was charged」，也就是没有扣费。对应到 Claude 的设置，Anthropic 文档里说：服务器用 API Key 鉴权时，在 Authentication 里选「No sign-in」，把 Key 加在 Request headers 里；Claude 会加密保存，保存后不再显示，每次请求都带上；而且 Claude 按你填的原样发送，不会自动加前缀，所以 Authorization 的值要写成 Bearer 加 Key，中间那个空格不能少（Add a connector that isn't in the directory）。

配置示例（Customize > Connectors > + Add > Add custom connector，按 Anthropic 文档字段填写，未在本机实测）
Name:            EveryInfra
MCP server URL:  https://api.everyinfra.com/mcp
Authentication:  No sign-in
Request headers: Authorization = Bearer <你的 EveryInfra API Key>
Advanced > Transport: 保持默认（地址不以 /sse 结尾，走 Streamable HTTP）

第二个容易卡住的是网络。帮助中心专门有一节「Network requirements」：加自定义连接器后，Claude 是从 Anthropic 的云端去连你的 MCP 服务器，不是从你的电脑，这对 claude.ai、Claude Desktop、Cowork 和手机应用都一样；所以服务器必须能从公网、从 Anthropic 的 IP 段访问到，放在公司内网、VPN 后面或被防火墙挡住的服务器连不上，哪怕你自己的电脑能连（帮助中心原文）。Anthropic 公布的出站地址是 160.79.104.0/21，并注明这是调用外部 MCP 工具时用的（IP addresses）。EveryInfra 的 MCP 地址本身在公网上，这一条对它不构成问题；但如果你把它包在公司自己的网关后面再给 Cowork 用，就要把这个地址段放行。

第三个是 Team 和 Enterprise 的共用凭据。团队版里只有 Owner 和 Primary Owner 能把自定义连接器加到组织里（Enterprise 还包括有「管理库」权限的自定义角色），加好之后成员各自去 Customize > Connectors 点「Connect」。帮助中心原话的意思是：这样设计是为了让 Claude 只能访问每个成员自己有权访问的东西，除非连接器用的是 API Key 这类共用凭据，那所有用它的人都拿到这把凭据的权限；在 Team 和 Enterprise 上，所有用这个连接器的人都用同一个凭据访问服务，所以要用一把权限只够成员需要的凭据（帮助中心原文）。对 EveryInfra 来说，这意味着团队里每个人的定时任务都扣同一个账户的钱。我们的建议是单独建一把只给 Cowork 用的 Key，调低它每分钟的上限，这样一个人写错提示词让任务循环调接口，也只会碰到这把 Key 的上限。另外要记住，Anthropic 文档写明加好以后不能改鉴权设置，换 Key 只能删掉连接器重新加，成员要重新连接（Add a connector that isn't in the directory）。

还有一个细节值得提前知道：Anthropic 会审核请求头的名字，没批准的头名保存时会报错（同一页文档）。EveryInfra 只用标准的 Authorization，不需要额外的头。EveryInfra 也接受把 Key 放在地址的 ?key= 参数里，但地址会出现在更多地方，我们不推荐在 Cowork 里这样配。

工具审批：为什么建好后要先手动跑一次

定时任务在没人看的时候跑，审批就成了最常见的「怎么没出结果」的原因。帮助中心的安全文章把审批模式分成三档：「Automatically approve」会在每个动作前做安全检查后自动放行，「Skip all approvals」什么都不检查，「Manually approve」每一步都问你（Use Claude Cowork safely）。同一篇文章对定时任务的建议是从低风险的汇总类任务开始、不要安排会发消息或下单的任务、每次运行后看一眼结果。竞品周报只读不写，正好是它说的那一类。

EveryInfra 的 12 个 MCP 工具都带了 MCP 规范里的工具注解（tool annotations）。我们在 11 月 3 日读了一次 tools/list：查目录的 everyinfra_list_capabilities、取异步结果的 everyinfra_get_job 标的是 readOnlyHint: true；真正调数据的 everyinfra_call_api 标的是 readOnlyHint: false、destructiveHint: true，因为它会扣钱。MCP 规范对这几个注解的定义是「提示」，客户端可以据此决定要不要先让人确认；没有注解的工具默认按「可能有破坏性」处理（MCP 规范：Tools；MCP 博客：工具注解能做什么、不能做什么）。

这在 Team 和 Enterprise 上影响最大。团队版帮助文章写明，组织设置里有一项「Allow "Always allow" for connector tools」，默认关闭；关闭时，成员在 Cowork 的审批框里选不了「Allow for all tasks」，以前存过的「总是允许」对写入类工具也不生效，只有连接器把工具标成只读的才免审批（Use Claude Cowork on Team and Enterprise plans）。按这条规则推，everyinfra_call_api 在默认设置下每个任务都要人点一次。我们没有 Team 组织可以实测这会让定时任务停住还是跳过这一步，所以只给做法：请 Owner 打开这项设置，或者把任务的审批模式设成「Automatically approve」，然后在任务建好后点「Run now」手动跑一次，看到审批框就选「Allow for all tasks」。

另外，10 月 22 日的桌面应用 v3.6556.1 把服务器标记为「需要人确认」的 MCP 工具改成只在应用内卡片上询问，定时任务遇到这类调用会跳过这一步、继续往下跑（Claude Desktop 更新日志）；EveryInfra 的工具没有这个标记，只有上面那四个注解。审批框在定时任务里实际怎么出现、会不会让任务停住，我们没有在 Cowork 里实测；建好任务后先点一次「Run now」，就是为了让你自己看清这一步。

一次真实往返：模型发出什么，我们回了什么

Cowork 一侧我们没有跑，但模型通过连接器发给 EveryInfra 的东西，就是一个标准的 MCP tools/call 请求。为了让你看到真实的样子，我们在 2026 年 11 月 3 日 00:25:46（新加坡时间）用 curl 直接向 https://api.everyinfra.com/mcp 发了同样格式的请求，带测试 Key，调 walmart/search 搜「ninja crispi glass air fryer」。服务器 43.6 秒后返回 200，返回体里是一段 13,115 个字符的 JSON 文本，20 条商品，扣费 $0.001389。

// 请求：模型通过连接器发出的 tools/call（2026-11-03 00:25:46 新加坡时间，真实请求，Key 在请求头里，此处不显示）
{"jsonrpc":"2.0","id":8,"method":"tools/call",
 "params":{"name":"everyinfra_call_api",
           "arguments":{"platform":"walmart","action":"search",
                        "params":{"keyword":"ninja crispi glass air fryer"}}}}

// 返回：result.content[0].text 里的 JSON（节选第 2 条，原样）
{"item_id": "20370717802",
 "name": "Ninja Crispi 4-in-1 Portable Glass Air Fryer Cooking System FN101PK1, ...",
 "price": 134.5, "was_price": 179.99, "currency": "USD",
 "rating": 4.5, "rating_scale": 5, "review_count": 1877,
 "in_stock": true, "seller_name": "Mercshop", ...}
// 同一返回的 billing：{"charged": true, "charged_usd": 0.001389, ...}

同一轮里还有一次失败的往返，我们也照实写。00:24:06 我们经 MCP 调 amazon/reviews 读 AF101（ASIN B07FDJMC9Q）的评论，88.8 秒后返回 isError: true，原因是这件商品的评论页要登录或受限，打不开，这次调用已退款，charged_usd 是 0，返回里还附了一句「马上重试大概率没用」。目录对 amazon/reviews 本来就写着各站点只能取到商品页展示的精选评论，每个商品通常十几条（EveryInfra 目录）。所以在这张周报里，Amazon 一侧我们不读评论正文，只用 amazon/search 返回的评分和评分数做「评论量」的信号；评论正文从 Walmart 读。

实测一：同一款锅，两家店差多少

第一轮快照在 00:15:54 到 00:26:55（新加坡时间）之间完成：amazon/search 搜「ninja air fryer 4 quart」一次，返回 20 条，用了 36.8 秒，扣 $0.002236；walmart/search 三次，分别搜 Ninja 4 夸脱、Ninja Crispi 和 Instant Vortex 迷你款，各扣 $0.001389。下表的每个数都直接取自这几次返回（Amazon 搜索接口、Walmart 搜索接口）。

这张表要先看第一行。$60.99 的价差看起来很大，但 AF101 和 AF100WM 不是同一个型号：后者是 Walmart 的专供款，名称里写着「3 Functions」，而 AF101 是「4-in-1」。零售商专供型号在家电品类很常见，按品牌加容量去配对，周报里就会出现一条永远存在、其实没有意义的「大价差」。所以竞品清单要按型号号码配对，型号对不上的就在表里标出来，不算价差。

折扣也要同样小心。同一次 Amazon 搜索的 20 条里，15 条带划线价，折扣从 8.0% 到 44.4% 不等。划线价是每个商品自己标的，A 商品打 6 折、B 商品打 8 折，说明不了谁更便宜。周报里看的是最终价，折扣只用来跟同一个商品自己的上周比。

Walmart 的搜索结果里本来有一个 upc 字段，目录说明它是跨平台比价时做同款匹配最准的依据，但同一段说明也写了，主数据源不可用时这个字段会缺；我们这三次 walmart/search 的返回里都没有 upc。所以周报的配对表要由人先定好，每周按定好的编号去取，而不是每周让模型重新猜哪个是同款。

第二个发现是 Amazon 的评分数会在变体之间共用。同一次搜索里，Instant Pot Vortex 的三个 ASIN（B08R6KMBQT、B0F9B4YCZF、B0F9B48Q1B）评分数都是 36,519；Ninja Crispi 的四个 ASIN（三种颜色的 FN101 加一个 FN103）都是 8,426。这些 ASIN 的颜色、型号后缀都不一样，评分数却一模一样，只能解释为它们挂在同一个变体家族下、共用一份评分数；Crispi 那四个里甚至有一个是 5 合 1 的 FN103，和 4 合 1 的 FN101 功能不同。这对周报的影响是：如果你把「Amazon 评分数这周涨了多少」当成某一个颜色的销量信号，就会把整个家族的评论都算到它头上。我们的做法是把评分数记成「家族评分数」，并在表里注明它和哪几个 ASIN 共用。

实测二：同一个商品，两个关键词，两个卖家

00:16:52 那次 walmart/search（关键词「ninja air fryer 4 quart」）里，Crispi FN101PK1（商品编号 20370717802）排在第 6 条，价格 $135，划线价 $179.99，卖家 Patent Paid。00:25:46 那次经 MCP 的 walmart/search（关键词「ninja crispi glass air fryer」）里，同一个商品编号排在第 2 条，价格 $134.50，划线价不变，卖家变成了 Mercshop。两次相隔约 9 分钟，我们起初以为是 9 分钟内换了卖家。约一小时后的复查推翻了这个解释：01:13:54 用第一个关键词搜，Crispi 仍是第 6 条、Patent Paid、$135；9 秒后 01:14:03 用第二个关键词搜，仍是第 2 条、Mercshop、$134.50。也就是说，差别跟着关键词走，不跟着时间走。

Walmart 的规则解释了为什么会这样。一个商品页上可以有多家卖家的报价，购物车按钮上方那一家叫 Buy Box 赢家；Walmart 会综合价格、运费、送达速度、卖家表现等因素，并按顾客所在地区决定谁赢（Walmart Buy Box 指南）。同一份指南还推荐卖家开 Walmart 自己的 Repricer 自动改价；定价规则页也写了，报价明显高于近期在 Walmart 或其他网站上的价格时，会被自动下架，或者去掉「加入购物车」按钮（Walmart 定价规则）。也就是说，第三方卖家多的商品，同一个编号背后本来就有好几家报价。但这些规则解释不了为什么同一时刻、两个关键词显示的是两家不同的卖家，我们也不知道原因，这里只记下现象。

这就是开头那句话的来源。如果周报按商品编号记价格、关键词又不固定，Crispi 这一行下周一可能显示「降价 $0.50」，而真实情况只是换了个关键词、看到另一家卖家。我们的做法有三条：每个商品在 config 表里配死一个关键词，每周都用它；主键用「商品编号 + 卖家名」，卖家换了就单独标「卖家变更」，不算价格变化；评论里的卖家名也一起看。Crispi 这 100 条评论里，有卖家名的 30 条分属 7 个卖家（Walmart.com 11 条、Shark Ninja Store 10 条、SDG Distribution 4 条，另有 4 家各 1–2 条），而 Ninja 基础款的 100 条里 98 条都是 Walmart.com 自营。卖家越分散，表里越容易把不同卖家的报价混在一起。

实测三：评论这一侧，差评有三成是配送问题

00:19:07 我们用 walmart/reviews 同步读了 Ninja 基础款 AF100WM 的 100 条评论，66.1 秒返回；00:22:20 用异步模式读了 Crispi FN101PK1 的 100 条，00:23:49 取回结果。两次各扣 $0.001389（Walmart 评论接口）。

这一节最有用的数，是差评里有多少其实和锅无关。我们用一条很粗的关键词规则（评论里出现 receive、deliver、ship、arrive、package、address、DHL、never got 这类词）去数，AF100WM 的 12 条差评里有 5 条、Crispi 的 20 条里有 6 条讲的是配送：「Never got it」「Delivered to wrong address」「Anything shipped via DHL I never receive」。Walmart 的评论规则写的是评论应聚焦商品本身和使用体验（Walmart 评论条款），但实际上这类评论照样会出现，并且会拉低星级。对做竞品分析的人，这意味着两件事：竞品的差评率高，不一定是产品不行，可能是它的第三方卖家配送差；反过来，如果你自己的差评集中在配送，改产品没用。周报里我们把差评拆成「产品问题」和「配送与卖家问题」两栏，就是为了这个。

第二个要注意的是这 100 条覆盖的时间。AF100WM 的 100 条从 2025 年 7 月跨到 2026 年 10 月，Crispi 的 100 条有 93 条落在 2026 年 8 到 10 月。而且返回的顺序不是严格按时间倒排的，前 30 条里就混着 6 月、9 月、10 月的评论。所以「这一周新增了几条评论」不能靠数这 100 条里日期落在本周的条数：AF100WM 落在 10 月 27 日到 11 月 2 日的有 5 条，落在前一周的有 4 条，这只是样本里的数，不是全量。商品总评论数也不能简单两周一减，原因见下一节；新差评按 review_id 去重，上周没见过的才算新的。

还有一个时间差要算进去。Walmart 帮助页写明，新评论要 5 到 7 个工作日才在网站上显示（Walmart 评论条款）；Walmart 给 Marketplace 买家发评论邀请的时间是送达或取货后 7 天，没打开的话 28 天后再发一次（Walmart Marketplace Learn）。所以周一早上看到的「上周新差评」，对应的大多是两三周前的订单。如果竞品上周刚降价冲量，它带来的评论变化要再过两三周才会出现在你的表里。周报的「要不要管」一列，我们按这个滞后来写：价格变化当周就提醒，评论变化至少看两周。

实测四：同一个数，一次返回里就有三个值

周报要和上周比，最怕的是数字本身就不稳。我们在同一轮里从三个能力读了 AF100WM 的评论数：00:16:52 的 walmart/search 是 12,571，00:21:10 提交、00:22:03 取回的 walmart/product_detail 也是 12,571；但 00:19:07 那次 walmart/reviews 返回的 100 条评论，每条都带一个商品总评论数 product_review_count，这个字段在同一次返回里就有三个值：12,562 出现 40 次，12,571 出现 40 次，12,573 出现 20 次。约一小时后的第二次读取，还是同样 100 个 review_id，分布变成 12,562 ×20、12,571 ×40、12,573 ×40。同一个响应内部最多差 11 条，所以这个字段不能只看第一条，也不能两周一减就当作新增评论数。我们在周报里的做法是三条：同一个指标每周从同一个能力读；评论接口里的总数取 100 条里的最大值（第一次返回里 12,562 和 12,571 各 40 次打平。我们用 Python 在两次原始返回上算过：statistics.multimode() 第一次给出两个值，statistics.mode() 遇到打平只取先出现的那个，第一次得 12,562、第二次得 12,571，周报就会凭空报出「新增 9 条」；两次的最大值都是 12,573（statistics 文档））；和上周相差不超过 15 条时记「无变化」。15 条这个阈值是按本文两次样本里看到的 11 条内部差定的，不是平台规则，跑上几周后要按你自己的数据调。

第二个意外是 walmart/product_detail 没有价格。两次详情返回的字段只有 id、url、name、text、brand、rating、rating_scale、review_count、image_url、platform，目录里列出的 price、original_price、in_stock、seller_name 都没出现（Walmart 商品详情接口）。我们照实写进周报的设计里：价格、划线价和卖家从 walmart/search 取，详情接口只用来在商品掉出搜索结果前 20 名时补评分和评论数，以及在型号描述里核对是不是同款。第一次同步调详情时，88.0 秒后返回 503 超时，没有扣费；改用 "mode":"async" 后 2.0 秒拿到任务编号，约 53 秒后结果就绪。

这些耗时对定时任务意味着什么？一次周报 10 次调用，按串行算要七八分钟，其中评论和详情最慢。我们建议在提示词里写明：详情和评论一律用异步模式提交，拿到任务编号后再用 everyinfra_get_job 去取，取结果不计费，也不占每分钟次数；同步调用超时的不要原样重发：那次 503 的返回里写着「没有扣费」、建议 20 秒后再试、最多重试 2 次，并直接建议改用异步模式。Reddit 上有用户总结过定时任务最大的坑是错误处理：遇到一次 429 或网络抖动，模型不是干净地重试，而是越绕越远，所以要在任务说明里写清「失败就停下并报告，不要自己想办法」（Reddit 讨论）。

本周和上周怎么比：数据存在哪

这是 Cowork 定时任务和普通聊天最不一样的地方。帮助中心的架构文章写明，云端会话里，Claude 的循环和代码执行跑在 Anthropic 托管的隔离临时沙盒里，每个会话一个沙盒，会话开始时创建、结束时销毁，沙盒之间不共享状态（Claude Cowork architecture overview）。也就是说，这周一跑完算出来的 CSV，下周一的新会话看不到。云端会话可以读写你电脑上连接过的文件夹，但只有桌面应用开着时才行（Use Claude Cowork on web, desktop, and mobile），这又回到了「电脑要开着」的老问题。

我们的推荐是 Google Sheets。帮助中心写明 Google Sheets 连接器可以创建新表格、在表格里编辑，Google Drive 连接器负责搜索、上传和分享；同一篇文章也提醒，如果只说「做一个表格」而不提 Google，Claude 会生成一个本地文件（Use Google Workspace connectors）。用 Microsoft 365 的团队，可以开它的写入工具，在 OneDrive 或 SharePoint 里创建和更新文件（Set up the Microsoft 365 connector；发布说明 2026-07-07）。表格里放两张工作表就够：snapshots 每周追加一批原始行，changes 每周追加一批对比结果。

对齐的键决定了比较准不准。行的主键是「店 + 商品编号 + 卖家」，评论用 review_id 去重；周次用 Python date.isocalendar() 给出的年-周编号，跨年、跨月都不会乱（datetime 文档），2026 年 11 月 2 日周一是 2026-W45，11 月 9 日是 2026-W46。

# 对比逻辑示例：在 Cowork 会话的代码执行里跑（我们在本机用两次真实快照跑通过）
def key(r):  # 店 + 商品编号 + 卖家
    return (r["store"], r["item_id"], r.get("seller_name") or "-")

def diff(last_week, this_week):
    prev = {key(r): r for r in last_week}
    prev_item = {(r["store"], r["item_id"]): r for r in last_week}
    out = []
    for r in this_week:
        p = prev.get(key(r))
        if p is None and (r["store"], r["item_id"]) in prev_item:
            out.append({**r, "flag": "卖家变更", "seller_before": prev_item[(r["store"], r["item_id"])].get("seller_name")})
        elif p is None:
            out.append({**r, "flag": "新出现"})
        else:
            out.append({**r, "price_change": round((r["price"] or 0) - (p["price"] or 0), 2),
                        "count_change": (r.get("review_count") or 0) - (p.get("review_count") or 0),
                        "flag": "价格变化" if r["price"] != p["price"] else ""})
    return out

用两次真实快照演示一次对比

为了让上面的对比代码不是纸上谈兵，我们在第一轮之后约一小时，于 2026 年 11 月 3 日 01:12:58 到 01:15:52（新加坡时间）按完全相同的参数又取了一轮：amazon/search 一次、walmart/search 三次、AF100WM 的 walmart/reviews 一次（异步），共 5 次调用，扣费 $0.007792。然后把两轮结果按「店 + 商品编号 + 卖家」喂给上面的 diff()。真实的周报是隔一周比一次，这里隔一小时，只为演示做法和看清哪些字段会自己动。

一小时里，我们盯的 6 行价格、卖家、评分数和评论数一个都没变。AF100WM 的第二次评论读取返回的也是同样 100 个 review_id，顺序都一样，按去重规则新增为 0；product_review_count 还是那三个值，只是比例从 40/40/20 变成了 20/40/40，取最大值两次都是 12,573，按上面的规则记「无变化」。变了的是 Amazon 的搜索名次：同一个关键词的前 20 名里，有 17 个 ASIN 两次都在，3 个换了；AF101 从第 2 掉到第 14，Crispi 从第 9 升到第 1，Vortex 从第 3 到第 4。这正是我们不让模型「挑前几名」、而是按配好的 ASIN 去取的原因：名次一小时就能大幅移动，价格却一分没动。如果按名次配对，表里会冒出一堆假的「变化」。

我们还用同一段代码演示了关键词不固定时会发生什么：把第二轮 Crispi 那一行换成用「ninja air fryer 4 quart」搜到的结果（Patent Paid、$135），diff() 给出的不是「涨价 $0.50」，而是「卖家变更，之前是 Mercshop」。这就是主键带卖家的作用。diff() 对这一行的原样输出是：

{"store": "walmart.com", "item_id": "20370717802", "seller_name": "Patent Paid", "price": 135, "review_count": 1877, "flag": "seller change", "seller_before": "Mercshop"}

第二轮三次 walmart/search 只用了 5.9 到 8.7 秒，比第一轮的 35.8 到 43.6 秒快得多，返回里没有字段说明是否读到缓存；所以判断「这周有没有变」，看两次快照的字段，不看调用花了多久。

提示词骨架和输出表结构

Cowork 的定时任务就是一段保存下来的提示词，每次运行照它做。帮助中心说，用「Create with Claude」时，Claude 会先问几个选择题，再把任务名、计划和它要做的事列出来给你确认（Schedule recurring tasks in Claude Cowork）。我们建议用「Set up manually」，把下面这段直接贴进去，因为每一步要调哪个工具、参数是什么、失败怎么办，写死比让它每周重新想要稳。频率选「每周」，时间选周一早上；模型可以选一个便宜的，帮助中心的手动设置里模型是可选字段，Reddit 上也有用户找到了在任务编辑页改模型的位置（Reddit 讨论）。

配置示例：定时任务提示词（Set up manually，频率：每周一 09:10，审批模式：Automatically approve）

你是竞品周报助手。只读，不下单、不改价、不发消息。工具只用 EveryInfra 连接器和 Google Sheets 连接器。
1. 打开 Google Sheets 文件「竞品周报」（没有就创建），读 snapshots 表里上一个周次（ISO 周，如 2026-W45）的全部行。
2. 读 config 表：每行一个竞品，列为 key、amazon_asin、walmart_item_id、walmart_keyword、model。
3. 调 everyinfra_call_api：platform=amazon, action=search, params={keyword: "ninja air fryer 4 quart", limit: 20}。
   只保留 config 里的 ASIN，记 price、list_price、rating、rating_count（rating_count 记为家族评分数）。
4. 对每个竞品：
   a. platform=walmart, action=search, params={keyword: walmart_keyword}，按 walmart_item_id 取 price、was_price、seller_name、rating、review_count。
   b. 如果第 a 步没找到这个编号：platform=walmart, action=product_detail, params={url: "https://www.walmart.com/ip/<编号>"}, mode=async，只取 rating、review_count。
   c. platform=walmart, action=reviews, params={url: 同上, limit: 100}, mode=async；用 everyinfra_get_job 取结果。
      按 review_id 和上周去重，只保留新的；1–2 星的新评论分成「产品问题」「配送与卖家问题」两类，各给一句摘要。
5. 每次调用失败：记下错误和 request_id，跳过这一项，不重试超过 1 次，不换别的办法。
6. 本周所有行追加到 snapshots（主键：周次 + 店 + 商品编号 + 卖家）。
7. 和上周按主键对比，结果追加到 changes：价格变化、卖家变更、评论数增量、新差评条数和摘要、要不要管。
8. 最后在会话里输出 changes 本周的行，按「要不要管」排序；写明本次一共调了几次接口、几次失败。

每周、每月接口费

按目录价算账：amazon/search 每次 $0.002236（每千次 $2.236），walmart/search、walmart/product_detail、walmart/reviews 每次 $0.001389（每千次 $1.389），都是 2026 年 11 月 3 日 00:15（新加坡时间）从免费目录读到的 price_usd。失败和空结果不扣费，异步任务的结果读取也不扣费。下表把三种做法算出来，每个数都由脚本从目录价现算（定价页）。

和订阅费比，接口费几乎可以忽略：3 个竞品每周一次，一个月 $0.0639，是 Claude Pro 月付 $20 的 0.32%（Claude 定价页）。真正的成本在 Claude 这一侧的用量。帮助中心写明，Cowork 接的是复杂的多步骤任务（Get started with Claude Cowork）；而 claude.ai、Claude Code、Claude Desktop 的用量都算进同一份上限，付费套餐有每 5 小时重置一次的会话上限和每周重置的周上限（How do usage and length limits work）。定时任务每跑一次，就从这份用量里扣一次。一次 Amazon 搜索返回 20 条就有 71,614 字节，评论 100 条约 6 万字节，全部原样塞给模型很费用量。所以提示词里要让它只保留配置表里的那几个编号，评论只看新出现的那几条。

做不了或要注意的地方

第一，Amazon 评论正文这次没拿到。amazon/reviews 对 AF101 返回「需要登录或受限，打不开」，已退款；即使能打开，目录也写明每个商品通常只有商品页展示的十几条精选评论。这张周报的 Amazon 一侧只有价格、划线价、评分和家族评分数。第二，walmart/product_detail 这次两个商品都没返回价格、库存和卖家，价格只能从 walmart/search 取；搜索结果每次一页 20 条，竞品掉出前 20 名时要换更精确的关键词。第三，Temu 也在很多卖家的竞品清单上，但目录里 temu/search 目前标的是暂停（available: false），调用会回 503 并且不扣费，这一版周报没有加。

第四，Cowork 这一侧我们没有实测。审批、连接器、Google Sheets 写入、模型选择，都是按 Anthropic 的帮助中心和文档写的配置示例。Team 组织里「Always allow」默认关闭时定时任务会停在审批还是跳过这一步，我们没法验证。第五，竞品周报只用于你自己的定价和产品决策。美国联邦贸易委员会 2024 年的规则禁止买卖假评论、按好评或差评给报酬、压制差评等做法（FTC 新闻稿，2024-08-14；16 CFR Part 465）；看到竞品差评多，正确的反应是改自己的产品和配送，不是去影响别人的评论。这里只讲数据方法，不构成法律意见。

最近的变化

• 2026 年 10 月 6 日：Pro、Max、Ultra 新建的 Cowork 任务和定时任务都在云端跑，「Only on your computer」选项去掉（帮助中心）。对读者意味着：周报不再需要电脑开着，但也不能再依赖本机文件夹存快照。
• 2026 年 10 月 22 日：桌面应用 v3.6556.1 让定时任务在遇到「需要人确认」的 MCP 工具时不做这一步、继续跑，并修复了定时任务找不到插件和技能的问题（更新日志）。对读者意味着：任务「跑完了但少了一块」时，先查是不是某个工具被跳过。
• 2026 年 10 月 26 日：Walmart 宣布 11 月 12 日到 12 月 2 日三轮节日促销，合计 14 天，比 2025 年的 10 天多（Walmart 新闻稿；Retail Dive 报道）。对读者意味着：接下来五周价格变动最密，每周一的表可以临时改成每天一次，3 个竞品一周也只要 $0.10。
• 2026 年 10 月 27 日：v4.29.0 规定定时任务里的网页抓取（在两种自动审批模式之外）只能访问任务说明里写明或搜索找到的地址（更新日志）。对读者意味着：靠 Cowork 自带网页抓取去读商品页会越来越受限，走连接器更稳。

常见问题

claude cowork scheduled tasks not working 怎么办？

问题来自搜索联想词「claude cowork scheduled tasks not working」和「claude cowork scheduled tasks connector not working」。先分清是哪一层坏了。Cowork 这一层：有用户在 macOS 上遇到新建定时任务报「Invalid file path: path traversal detected」、手动新建也失败（Reddit 讨论），相关的 GitHub 议题指出远程执行的会话拿不到管理本地定时任务的工具（GitHub #76968）；10 月 22 日的更新还修过定时任务找不到插件和技能的问题（更新日志），先把桌面应用升到最新。连接器这一层：确认请求头写的是 Bearer 加 Key、服务器公网可达、审批已经放行。EveryInfra 这一层：用 everyinfra_list_requests 按 request_id 查那次调用的状态和扣费，它不收费。

下表把我们在真调里遇到的、以及上面几个帖子里提到的症状放在一起，标出通常是哪一层的问题。

claude cowork scheduled tasks limit 是多少？

问题来自联想词「claude cowork scheduled tasks limit」，Reddit 上也有人问过能建多少个定时任务，没有人给出官方数字（Reddit 讨论）。我们查了帮助中心的四篇相关文章，没有找到 Cowork 定时任务的个数或次数上限；能确定的是它消耗订阅用量，受每 5 小时和每周上限约束（用量说明）。作为对照，Claude Code 的云端定时任务写明每个账号每小时 100 次（文档）。EveryInfra 一侧的限制是每把 Key 每分钟的请求次数，在控制台可以调低。

claude cowork scheduled tasks vs claude code routines 怎么选？

问题来自联想词「claude cowork scheduled tasks vs claude code routines」。看你的数据和结果放在哪：结果是给业务同事看的表格或文档，用 Cowork 定时任务，配 Google Sheets 或 Microsoft 365 连接器；数据和脚本本来在 Git 仓库里、想让历史留在提交记录里，用 Claude Code 的云端定时任务（原名 routines），它还能用 API 和 GitHub 事件触发（Claude Code 文档）。两种都能挂同一个 EveryInfra MCP 地址，具体做法见我们的 Claude Code 定时任务那篇。

claude cowork scheduled tasks cloud：电脑关机还会跑吗？

问题来自联想词「claude cowork scheduled tasks cloud」。会。帮助中心写明定时任务远程运行，电脑睡着或桌面应用关着都照常跑；10 月 6 日后新建的任务都在云端（帮助中心）。例外是需要本机文件或应用的任务，以及 10 月 6 日前就在本机跑的老任务。也有用户在 Reddit 上说没找到切到云端的选项（Reddit 讨论）；那个帖子里有人回复说云端选项是按套餐分批开放的，而帮助中心写明 10 月 6 日起 Pro、Max、Ultra 新建任务一律在云端跑。

定时任务能指定用哪个模型吗？

问题来自 Reddit 原帖「any way to set which model scheduled tasks run on?」（Reddit 讨论）。能。帮助中心的手动设置里，模型是一个可选字段（帮助中心），帖子里的回复也指出可以在任务的编辑页改。竞品周报主要是调工具、对表格，用便宜的模型就够；把省下的用量留给需要判断的任务。

为什么定时任务没有准点跑？

问题来自 Reddit 的一条回复：远程调度的时间不完全一致，有时会偏约 10 分钟（Reddit 讨论）。Cowork 的帮助中心没有写准点程度；Claude Code 云端定时任务的文档写明，排在整点的运行可能晚几分钟开始，建议选整点后几分钟，例如 9:07（文档）。周报对几分钟不敏感，我们示例里写 09:10，也是这个原因。

上手

1. 在 EveryInfra 控制台免费注册，建一把只给 Cowork 用的 API Key，按 快速上手 先用 curl 调一次 walmart/search 确认能通。
2. 在 Claude 的 Customize > Connectors 里加自定义连接器：地址 https://api.everyinfra.com/mcp，Authentication 选 No sign-in，Request headers 填 Authorization = Bearer <Key>；完整说明见 MCP 接入页。
3. 打开 Google Sheets 连接器，建一个「竞品周报」表格，config 表里填好竞品编号。
4. 在 Scheduled 里 Set up manually，贴上面的提示词，频率选每周，先点 Run now 跑一次，处理审批框。
5. 下周一看 changes 表。想看更多做法，可以读 价格监控做成订阅产品、Amazon 价格追踪：可比报价 和 用 Agent Skills 做竞品评论分析。

参考资料

1. Schedule recurring tasks in Claude Cowork，Claude 帮助中心，2026-11-03 读取。
2. Get started with custom connectors using remote MCP，Claude 帮助中心，2026-11-03 读取。
3. Add a connector that isn't in the directory，Anthropic 文档，2026-11-03 读取。
4. Claude Cowork and chat are one Claude，Claude 帮助中心，2026-11-03 读取。
5. Use Claude Cowork on web, desktop, and mobile，Claude 帮助中心，2026-11-03 读取。
6. Use Claude Cowork safely，Claude 帮助中心，2026-11-03 读取。
7. Use Claude Cowork on Team and Enterprise plans，Claude 帮助中心，2026-11-03 读取。
8. Get started with Claude Cowork，Claude 帮助中心，2026-11-03 读取。
9. How do usage and length limits work?，Claude 帮助中心，2026-11-03 读取。
10. Release notes，Claude 帮助中心，2026-02-25 至 2026-10-21 条目。
11. Claude Desktop changelog，Anthropic，v3.6556.1（2026-10-22）至 v4.4212.0（2026-10-29）。
12. Plans & pricing，Anthropic，2026-11-03 读取。
13. IP addresses，Anthropic 文档，2026-11-03 读取。
14. Claude Cowork architecture overview，Claude 帮助中心，2026-11-03 读取。
15. Automate work with scheduled tasks，Claude Code 文档，2026-11-03 读取。
16. Run prompts on a schedule，Claude Code 文档，2026-11-03 读取。
17. Use Google Workspace connectors，Claude 帮助中心，2026-11-03 读取。
18. Set up the Microsoft 365 connector，Claude 帮助中心，2026-11-03 读取。
19. Tools，Model Context Protocol 规范 2025-11-25。
20. Transports，Model Context Protocol 规范 2025-11-25。
21. Tool Annotations as Risk Vocabulary，MCP 博客，2026-03-16。
22. Issue #76968，GitHub anthropics/claude-code，2026-09-14 跟进。
23. Anyone else unable to create or edit scheduled tasks in Claude Cowork，Reddit r/ClaudeAI。
24. Scheduled tasks / Routines: what's actually holding up for you?，Reddit r/ClaudeAI。
25. Using claude.ai scheduled tasks to trigger the 5h window，Reddit r/ClaudeAI。
26. I can't create scheduled tasks on remote (cloud)，Reddit r/ClaudeCowork。
27. Cowork mode: any way to set which model scheduled tasks run on?，Reddit r/Anthropic。
28. EveryInfra 数据能力目录，EveryInfra，2026-11-03 00:15 新加坡时间读取。
29. Walmart Buy Box 指南，Walmart Marketplace Learn。
30. Pricing rules，Walmart Marketplace Learn，2025-12-12 更新。
31. Marketplace reviews overview，Walmart Marketplace Learn。
32. Ratings, Reviews, Question, & Answer Terms of Use，Walmart 帮助中心。
33. Walmart Unwraps Three Major Holiday Shopping Events，Walmart，2026-10-26。
34. Walmart debuts longer Black Friday, Cyber Monday sales events，Retail Dive，2026-10-26。
35. FTC Announces Final Rule Banning Fake Reviews and Testimonials，美国联邦贸易委员会，2024-08-14。
36. 16 CFR Part 465，eCFR。
37. datetime：Basic date and time types，Python 文档。
38. Authorization，Model Context Protocol 规范 2025-11-25。
39. RFC 6750：The OAuth 2.0 Authorization Framework: Bearer Token Usage，IETF，2012-10。
40. statistics：Mathematical statistics functions，Python 文档。