Notion MCP 多 agent 同写竞品表：键、时间、计数怎么对齐

Notion 在 2026 年 11 月 4 日把 Notion MCP 推成「所有 agent 共用的一个大脑」，但这份共享记忆是每个人私有的 Memories 数据库，不是团队的竞品表。要让 Claude Code 和 Codex（用 ChatGPT 账号登录）往同一张 Notion 表里写竞品社媒数据，有三件事 Notion 不替你做：用哪个字段当去重键、哪个时间算更新时间、两份来源的计数谁覆盖谁。

我们用 EveryInfra 接口实测，7 次核心调用拿回 130 行，能原样当成「本品牌新帖」写进表的只有 68 行（52.3%）。其余 62 行里，3 条是置顶的旧视频；19 条是别的账号发的，包括 Instagram 上 2 条合作帖和 TikTok 搜索结果里 17 条非品牌主账号的视频；40 行是 YouTube 频道列表里只有「10d ago」这种相对日期的视频。这些数据来自 2026 年 11 月 8 日 00:17–00:48（新加坡时间）的 12 次真调（其中 1 次故意不带 Key，没有扣费），对象是 CeraVe 和 The Ordinary 两个护肤品牌在 TikTok、Instagram、YouTube 上的帖子。按目录价，3 个品牌、两个 agent 每天各跑一次，一周接口费 $0.048372，一个月约 $0.21。

这篇文章要解决的问题很具体：一个品牌团队已经在用 Claude Code 写脚本、用 Codex（ChatGPT 账号登录）做调研，两边都能连 Notion MCP，也都能连 EveryInfra 的远程 MCP。现在想让两个 agent 各拉一部分竞品的社媒数据，写进同一个 Notion 数据库，周一早上大家打开同一张表看。下面先讲 Notion 这次发布了什么、它解决和没解决什么，再讲表怎么设计、真调数据暴露了哪些坑、两边的配置怎么写、一周要花多少钱。Notion 一侧我们没有在 Notion 工作区里跑过，所以那部分一律写成「配置示例」，依据是 Notion、Anthropic、OpenAI 的官方文档原文；EveryInfra 一侧的每个数字都来自接口的真实返回。

11 月 4 日 Notion 发布了什么：一个「共享大脑」和它的边界

2026 年 11 月 4 日，Notion 官方账号发帖说，现在 ChatGPT、Claude、Muse 和 Bot 可以把学到的东西存进 Notion 里的同一份记忆，并使用同样的技能（Notion 官方 X 帖子）。同一串帖子给了两个现成的设置提示词入口，分别给 ChatGPT 和 Claude，其他 agent 则粘贴一句话，让它按开发者文档里的设置指南把 Notion 设成自己的「上下文系统」。帮助中心把这件事写成三点：每个接上的 agent 都能接着上一个 agent 的进度干活；agent 把你的偏好、决定和项目细节存进一个只有你能看、能改的 Memories 数据库；设置提示词会照你工作区现有的结构来，新建或改动任何东西之前先问你（Notion 帮助中心：Notion MCP）。

记忆能力其实 10 月已经上线：Notion 10 月 19 日的发布说明写明记忆同步当天上线（Notion 10 月 19 日发布说明）。11 月 4 日主要是给它配了一套设置提示词。

开发者文档讲清了这份「记忆」到底是什么：它是一个个人的 Memories 数据库，加一页总结它的 About page，在你第一次存记忆时自动创建；记忆只属于你，不会让一个客户端拿到你本来看不到的内容；经 MCP 的记忆功能在所有套餐上都能用，但只能走「以用户身份连接」的方式，走工作区拥有的连接时用不了（Notion 开发者文档：个人记忆）。写记忆的方法也很具体：调用 notion-create-pages 时把 parent 设成 "memory"（页面工具参考）。这里有一处两份官方文档说法不一致：帮助中心的 Memories 页写「Memories 在开启了 Notion AI 的工作区可用，Notion AI 属于 Business 和 Enterprise 套餐」（查看你的 Notion Agent Memories），开发者文档写的是「所有套餐」。我们没法在各个套餐上逐个验证，建议以你自己工作区里能不能存第一条记忆为准。

把这些原文放在一起，结论是：Notion 提供的共享记忆，适合存「这个人喜欢周报先写风险」「这个项目的品牌名单是哪几家」这类偏好和决定；它不适合存每天几百行、要多人一起看的竞品帖子数据。后者应该放进一个普通的团队数据库，由你来设计字段和查重规则。下面的表把两者并排放：

为什么竞品数据不放进 Memories，而放进普通数据库

第一个理由是可见范围。Memories 是私有的，你同事的 agent 读不到你的 Memories；竞品表天生是给一组人看的。第二个理由是数据形状。Memories 是一条条短文本，用来在下一次对话开头补上下文；竞品帖子是有固定列的记录，要排序、筛选、按周汇总，这正是 Notion 数据库和视图擅长的。第三个理由是可追溯。Notion 10 月 29 日上线的 notion-get-version-changes 能列出一段时间里页面或数据库改了什么、谁改的，包括 Notion AI、自定义 agent 和 MCP 客户端做的编辑；11 月 3 日又加了 notion-restore-version，能把页面或数据库恢复到过去某个时刻（Notion 开发者更新日志、改动历史工具参考）。两个 agent 写同一张表时，出了错能查到是哪一边写的、能退回去，这比把数据塞进私有记忆可靠得多。

还有一个容易忽视的点：Notion 的数据库没有「唯一键」这种约束。你可以用 ID 属性给每行编号，但那是 Notion 自动生成、不能手改的流水号（Notion 帮助中心：数据库属性），从 1 开始给每一页编号（Notion 帮助中心：Unique ID 属性），不能拿来防止外部数据重复写入。两个 agent 如果都把同一条 TikTok 视频当成新帖写一次，表里就会有两行。所以查重这件事必须提前设计好，而且要让每次查重的查询足够小。

竞品表的 11 个字段：每个字段从哪项能力的哪个字段来

我们为这张表定了 11 个字段。定字段的原则是：只放每周汇总真正要用的；每个字段都能从 EveryInfra 目录 response_fields 里找到出处；跨平台同名同义。目录是免费的，GET https://api.everyinfra.com/api/v1/social/catalog 就能读到每项能力的参数、返回字段和 price_usd（EveryInfra 能力目录）。下面这张表是字段和来源的对照：

这张表里有三处是看了真调数据之后才定下来的，目录描述本身看不出来。第一，Key 列不能直接用数字类型存 TikTok 的 id，原因在下一节。第二，Instagram 返回两个 ID：post_id 是 11 位短码，例如 DfU4LSwCopm；id 是「数字_数字」的形式，例如 4023087433800911462_260452448，下划线后面那段是发帖账号。我们选 post_id，因为它和帖子网址里的短码一致，人一眼能对上。第三，YouTube 的发布时间要从 youtube/video 取，不能从频道列表取，原因在「更新时间」一节。最后一个细节来自 Notion 自己：如果你的数据库里有一列叫「URL」，Notion MCP 会把它存在 userDefined:URL 这个键下面，10 月 16 日起会在返回的 warnings 里告诉你它修了这个键（更新日志 10 月 16 日条目）。agent 之后更新这一行时要用返回里的键名，不能自己猜。除了这 11 个数据字段，后文还会根据真调结果加两列标记：Count precision（计数是精确值还是约数）和 Owned（发帖账号是不是品牌自己）。它们由 agent 按规则算出来，不来自接口返回，所以单独说明。

真调：7 次核心调用、130 行，能原样入表的不到六成

我们在 2026 年 11 月 8 日 00:18 到 00:27（新加坡时间）分两批真调。模拟的分工是：Claude Code 负责 TikTok，Codex（用 ChatGPT 账号登录）负责 Instagram 和 YouTube。品牌选了 CeraVe 和 The Ordinary，因为它们三个平台都有官方账号、发帖频率高，而且一个偏大众药妆、一个偏成分党，评论区风格差别大。每次调用的结果、扣费和用途如下，所有调用都用同一把测试 Key：

每一项都是按次计费，limit 20 和 10 价格一样，每次 $0.000556。instagram/user_posts 在目录里是异步能力，请求立刻返回 202 和 poll_url，我们按它轮询，00:21:47 拿到 20 行。表里 7 次「核心调用」指的是除去 youtube/video 那次单条查询之外的 7 次列表调用，合计 130 行。我们按「能不能直接当作本品牌的一条新帖写进表」把这 130 行分成四类，规则写死在脚本里：发帖账号等于品牌账号、is_pinned 不为真、posted_at 是 ISO 8601 格式的绝对时间，三条都满足才算能原样入表。按这三条，130 行里有 68 行能原样入表，占 52.3%；其中 TikTok 30 行、Instagram 38 行，YouTube 一行都没有。

图里最显眼的是三类「看起来是数据，其实不能直接写」的行。第一类是置顶视频。CeraVe 的 TikTok 主页前 3 条是置顶的，发布日期分别是 2026 年 2 月 10 日、2 月 24 日和 8 月 31 日，其中 8 月那条播放 7,140 万次。它们排在「最新视频」最前面，如果 agent 按返回顺序取前几条当本周新帖，就会把 8 月的广告当成本周发的，还会把 7,140 万播放算进本周互动。返回里有 is_pinned 字段，过滤掉就行，但前提是 agent 知道要看它。The Ordinary 那次 10 行里没有置顶，所以这类问题不是每个账号都有，抽查一个账号发现不了。

第二类是别的账号发的帖子。CeraVe 的 Instagram 20 行里有 2 行发帖账号不是 cerave：一条是一家咖啡店 11 月 6 日发的联名活动，一条是一位名人 10 月 22 日发的合作视频。它们出现在品牌主页里，是因为 Instagram 的合作帖会同时挂在两个账号下。这类帖子要不要算进品牌声量，是业务判断，但无论算不算，表里都应该有一列标出「发帖账号不是品牌自己」，否则周报会把别人的点赞算成品牌的。tiktok/search 更极端：搜 cerave 返回的 20 条里，品牌主账号只有 3 条，泰国区的品牌分账号 1 条，其余 16 条是普通创作者的视频，它适合做「别人怎么谈论这个品牌」，不适合当品牌发帖清单。

第三类是 YouTube 的相对日期。两个品牌的 youtube/user_posts 各返回 20 条，posted_at 全部是「10d ago」「2w ago」「1mo ago」「1y ago」这样的相对说法，没有一条是具体日期。这不是接口出错，频道视频列表页本身就是这样显示的；但对一张要按周汇总的表来说，「1mo ago」可能是 30 天前，也可能是 59 天前，没法判断它属不属于某一周。下一节讲怎么补。

去重：键用哪个 ID，为什么 TikTok 的 ID 不能存成数字

两个 agent 写同一张表，最常见的重复来自同一条内容被两个能力同时拿到。我们在 CeraVe 的两次 TikTok 调用里就碰到了：tiktok/user_videos 和 tiktok/search 两份结果里有 3 个视频 ID 是重合的。如果 Claude Code 先用主页列表写了一遍，后来又用搜索结果写一遍，没有查重的话表里就会多出 3 行。去重的办法是给每行一个跨能力不变的键：平台名加平台自己的帖子 ID，例如 tiktok:7704741979216694541。写之前先按键查，查到就更新，查不到才新建。

键的类型比键的内容更容易出错。TikTok 的视频 ID 是 19 位数字，CeraVe 两次 TikTok 调用拿到的 40 个 ID 全部是 19 位，EveryInfra 返回时把它们放在 JSON 字符串里。问题出在下一步：如果 agent 觉得「这是个数字」，把它写进 Notion 的数字属性，或者在 JavaScript 里当数字处理，就会出错。JavaScript 的数字是 IEEE 754 双精度浮点数，能精确表示的最大整数是 2^53 − 1，也就是 9,007,199,254,740,991（MDN：Number.MAX_SAFE_INTEGER），而 TikTok 的 19 位 ID 大约是它的 850 倍。我们用脚本把 40 个 ID 都转成双精度浮点数再转回整数，结果是 0 个能还原成原来的样子，末尾几位全部变了。这 40 个 ID 里有 3 个是两次调用都拿到的同一条视频，去重后是 37 条，下一段会讲到它们。所以 Key 必须是文本，放在标题列最合适：标题列在 Notion 里不能被列权限限制（Notion 帮助中心：数据库属性权限），也是 Notion 建议 agent 依赖的「描述性标题」（Notion MCP 使用建议）。

重合的那 3 条还暴露了第二个问题：同一条视频，两个能力给的计数精度不同。下面是三条重合视频在两次调用里的计数，两次调用只隔 20 秒：

小数字两边完全一样，大数字主页列表给的是约数（71,400,000、22,900），搜索给的是更精确的数（71,440,950、22,850）。这意味着「谁后写谁赢」是个坏规则：如果 Codex 一侧后来用主页列表更新了这一行，精确的 71,440,950 会被改成 71,400,000。我们的建议是加一列 Count precision，取值 exact 或 rounded，按两步判断。第一步，同一条视频同时有两个读数时（比如主页列表和搜索都拿到了），以末尾零更少的那个为准，标成 exact，另一个标成 rounded。第二步，只有一个读数时，才按数的形状判断：大于等于 10,000、而且正好能写成「一位小数加 K（千）或 M（百万）」的数，例如 22,900（22.9K）、115,700（115.7K）、71,400,000（71.4M），标成 rounded。形状判断有已知的误判：正好是整千整百的精确值也会被标成约数。CeraVe 有一条 2026 年 10 月 17 日（UTC）发布的视频，两次读到的播放数都是 10,000，单看这个数分不清是真的 10,000 还是约数。

更新时，rounded 不能覆盖 exact，除非新值比旧值大出 1% 以上，说明真的涨了。这些规则是本文根据 3 条重合视频定的经验值，其中只有 1 条是大数，样本很小，用之前请拿你自己品牌的数据再验一次。

更新时间：Observed at、Posted at 和 YouTube 的「10d ago」

一张会被反复更新的表需要两个时间：帖子是什么时候发的（Posted at），这一行的数字是什么时候读到的（Observed at）。只存一个会出问题。我们在 00:18:08 和 00:48:17 两次读取 CeraVe 的 TikTok 主页，相隔 30 分钟。17 条非置顶视频里，6 条播放数涨了，最新那条（11 月 6 日发布）涨了 0.99%；3 条没变，其中 115,700 那条本来就是约数，涨了也看不出来；另外 8 条反而少了 0.01% 到 0.07%。播放数会变少，说明平台会回头修正计数，所以「两次里取较大的那个」也是坏规则，应该以最新一次读到的精确值为准。如果表里没有 Observed at，下周一看到两行播放数不同的数据，你分不清是视频又涨了，还是两个 agent 在不同时刻读的。

这张表还说明了一件事：只看一次读取，你根本分不出哪条视频还在涨、哪条已经停了。要判断一条帖子本周的势头，至少要有两个不同 Observed at 的读数。

Posted at 的问题出在 YouTube。前面说过，youtube/user_posts 只给相对日期。我们在 00:25:49 用 youtube/video 查了其中一条 CeraVe 视频，频道列表里写的是「10d ago」，单条查询返回的 posted_at 是 2026-10-28T04:00:20+00:00，换算成新加坡时间是 10 月 28 日中午 12 点，距离调用时刻 10 天 20 小时，「10d ago」是往下取整的结果。两项能力在同一条视频上的差别如下：

播放数从 664 变成 670，是因为两次读取隔了 7 分钟；时长格式不同，写表前要统一换算成秒。YouTube 官方 API 的 snippet.publishedAt 字段同样是 ISO 8601 格式的时间（YouTube Data API：Videos），所以存进表的时间应该一律用 ISO 8601 / RFC 3339 的 UTC 写法（RFC 3339），不要存「10d ago」这种会随时间变的字符串。

补日期的成本很低：Codex 一侧每周只需要对频道列表里新出现的视频 ID 各调一次 youtube/video。从真调数据看，CeraVe 最近三周发了 3 条常规视频（10d、2w、3w ago），The Ordinary 发了 1 条（3w ago），平均每个品牌每周约 0.7 条，3 个品牌每周约 2 条。我们留出余量按每周 3 条算，一个月约 13 次补日期调用，每次 $0.000556。

notion mcp claude code：Claude Code 一侧的配置示例

Claude Code 要同时接两个远程 MCP：Notion 和 EveryInfra。Notion 的官方写法是一条命令，接上后在 Claude Code 里运行 /mcp 走 OAuth 登录；--scope project 会把配置写进项目根目录的 .mcp.json，方便团队共用（Notion 开发者文档：连接 Claude Code）。EveryInfra 用请求头里的 Bearer Key 鉴权，Claude Code 的远程 HTTP 服务器支持 --header 参数，.mcp.json 里的 ${VAR} 会在加载时从环境变量展开（Claude Code MCP 文档）。下面是配置示例，我们没有在 Claude Code 里跑这个项目：

# Notion：OAuth，接上后在 Claude Code 里运行 /mcp 完成登录
claude mcp add --transport http notion https://mcp.notion.com/mcp --scope project

# EveryInfra：Bearer Key 从环境变量读，不写进仓库
export EVERYINFRA_API_KEY=...   # 放在 shell 配置或密钥管理里
claude mcp add --transport http everyinfra https://api.everyinfra.com/mcp \
  --header "Authorization: Bearer ${EVERYINFRA_API_KEY}" --scope project

{
  "mcpServers": {
    "notion": { "type": "http", "url": "https://mcp.notion.com/mcp" },
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" }
    }
  }
}

Claude Code 文档特别提醒：JSON 里有 url 但没写 type 的条目会被当成本地 stdio 服务器，然后被跳过并报错，所以 "type": "http" 一定要写（Claude Code MCP 文档）。另一个要注意的是工具数量。EveryInfra 的 MCP 有 12 个工具，Notion MCP 的完整工具表有五十多个（Notion MCP 工具清单），两边一起挂上会占不少上下文；Notion 文档建议用 /context 看每个 MCP 服务器占了多少 token。本文这件活在 EveryInfra 一侧只需要 everyinfra_call_api 和 everyinfra_get_job 两个工具。

定时运行有两种选择，各有代价。Claude Code 桌面版的本地定时任务直接读你本机的配置文件，所以上面带请求头的 .mcp.json 能用；代价是只有在应用开着、电脑没睡眠时才会跑，电脑睡着时这一次会被跳过（桌面版定时任务文档）。云端定时任务（以前叫 routines）在 Anthropic 的云上跑，电脑关了也能跑，Pro、Max、Ultra、Team 和 Enterprise 套餐可用，最短间隔一小时（云端定时任务文档）；它用的是你在 claude.ai 账号里接好的连接器，带请求头的私有服务器要怎么带进去，取决于你的云端环境变量和仓库配置，本文没有验证，上线前要自己试一次。

notion mcp connector：ChatGPT 网页版为什么填不了请求头，要改用 Codex

ChatGPT 一侧比 Claude 一侧多一个坑。在 ChatGPT 网页版里加自定义 MCP 服务器，现在的入口叫「插件」：打开 ChatGPT Plugins，点加号，选 Add custom MCP server，填名称和服务器地址，再选鉴权方式。OpenAI 文档列出的鉴权方式只有三种：OAuth、不鉴权、OAuth 或不鉴权混用（OpenAI 文档：Add custom MCP server）。没有「填一个固定请求头」这一项。OpenAI 社区在开发者模式刚出的时候就有人问过同一个问题（OpenAI 社区讨论）。EveryInfra 的远程 MCP 用 Bearer Key 鉴权，我们查了 /.well-known/oauth-protected-resource 和 /.well-known/oauth-authorization-server，都返回 404，也就是目前不支持 OAuth。

那 ChatGPT 网页版能不能接？我们在 00:17:36 不带 Key 调了一次 tools/call，服务器返回 unauthorized，错误信息写明 Key 可以放在 Authorization: Bearer 请求头里，也可以放在 ?key= 查询参数里，并注明「没有扣费」。所以理论上可以在 ChatGPT 里选「不鉴权」，把带 ?key= 的地址填进去。我们不推荐这样做：Key 会出现在 ChatGPT 的插件设置页、浏览器历史和各种日志里，工作区里能看到这个插件配置的人也能看到 Key。这条路我们没有在 ChatGPT 里实测。

更稳的做法是让 ChatGPT 账号一侧的 agent 用 Codex。OpenAI 的帮助中心写明，用 ChatGPT 账号登录 Codex 时用的是你 ChatGPT 套餐的额度；从 12 月起，Plus、Pro 和 Business 套餐的额度在 ChatGPT 和 Codex 之间共用（ChatGPT Work 和 Codex、ChatGPT 和 Codex 用量说明）。Codex 的 MCP 配置支持 bearer_token_env_var，填一个环境变量名，它就会把这个变量的值放进 Authorization 请求头（Codex MCP 文档）。Notion 一侧，Notion 文档给的写法是在 ~/.codex/config.toml 里加 [mcp_servers.notion]，再运行 codex mcp login notion 走 OAuth（Notion 开发者文档：连接 Codex）。配置示例如下：

# ~/.codex/config.toml（配置示例，未实测）
[mcp_servers.notion]
url = "https://mcp.notion.com/mcp"

[mcp_servers.everyinfra]
url = "https://api.everyinfra.com/mcp"
bearer_token_env_var = "EVERYINFRA_API_KEY"
enabled_tools = ["everyinfra_call_api", "everyinfra_get_job"]
tool_timeout_sec = 120
default_tools_approval_mode = "writes"

这几行里有两个数是按真调结果定的。tool_timeout_sec 的默认值是 60 秒，而 EveryInfra 同步调用最长会等 85 秒，我们这次 REST 同步调用耗时 3.8 到 32.5 秒，最慢的是 youtube/video 那次；慢的平台会超过 60 秒，所以调到 120。default_tools_approval_mode 设成 writes，表示只对没标成只读的工具弹确认。EveryInfra 的 everyinfra_call_api 标的是 readOnlyHint: false、destructiveHint: true，因为它会扣钱，所以每次调用都会问你；everyinfra_get_job 标的是只读，轮询结果不用确认。ChatGPT 网页版也是同样的逻辑：没有 readOnlyHint 的工具一律当写操作，默认要确认，确认时可以选「本次对话记住」（OpenAI 文档）。工具注解的定义见 MCP 规范的工具一节。

三种接法放在一起比较：

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

上面的配置接好以后，agent 拉 The Ordinary 的 TikTok 主页时，MCP 层面发生的就是下面这一次往返。我们在 2026 年 11 月 8 日 00:21:58（新加坡时间）直接向 https://api.everyinfra.com/mcp 发了 JSON-RPC 的 tools/call，工具名 everyinfra_call_api，参数是平台 tiktok、能力 user_videos、用户名 theordinary、条数 10。服务器返回 HTTP 200，result.content[0].text 是一段 JSON 字符串，解析后有 10 条视频和一个 billing 对象，charged_usd 是 0.000556。

这一次往返有两个对写表很重要的细节。第一，返回的 id 是字符串 "7705177610602532114"，带引号，说明接口这一侧没有把它当数字；出问题只会发生在 agent 写表的那一步。第二，10 条视频的完整返回有 26,253 字节，平均每条 2.6 KB，里面有封面地址、音乐信息、作者简介等几十个字段。agent 如果把整段返回原样塞进 Notion 页面正文，每行会很重，下一次查重读表也更慢。这正是要提前定好 11 个字段的原因。

多大一行：为什么只写 11 个字段

我们把同一批数据按 11 个字段的白名单重新序列化，每行平均 419 字节；原始返回每行 0.7 KB 到 2.6 KB 不等。差距主要来自三个地方：带签名的图片和视频地址（会过期，存了也没用）、作者主页的整套资料（每行重复一遍）、音乐和话题标签的嵌套对象。

行小有三个实际好处。一是 Notion 的写入限制：notion-create-pages 一次调用里所有页面共用同一个解析上限，内容太大或格式太复杂会整个调用失败，一页都不建（页面工具参考）。二是 agent 的上下文：查重时要把最近两周的行读回来，行越小，同样的上下文能装下越多行。三是可读性：周一打开表的人只需要看这 11 列。原始返回如果确实要留档，放在 agent 本地的文件里，表里只放链接。

写入 Notion 的那一步：先查键、再新增或更新

Notion 一侧的写入要用到三个工具：notion-query-data-sources 查已有的行，notion-create-pages 新建行，notion-update-page 更新行（数据库工具参考、页面工具参考）。查询这一步有三个限制，决定了表要怎么设计。

第一，行模式一次最多返回 100 行，而且不返回游标，读不到第 101 行。第二，在 Free 和 Plus 套餐上，SQL 查询和行模式共用一份有限的额度，只有「查保存好的视图」这种模式在所有套餐上都不占额度；SQL 不限次只在开启了 Notion AI 的 Business 和 Enterprise 上成立（Notion 开发者文档：套餐差异）。Reddit 上有 Plus 用户反映，同一个查询以前能跑，后来返回需要 Business 或 Enterprise 套餐的提示（Reddit：Did Notion just significantly change the MCP capabilities on the free plan?）；另一位用户抱怨 agent 只能看到数据库前 25 条（Reddit：The reason why Notion MCP is a big fail）。第三，请求频率：Business 和 Enterprise 每个连接每分钟 600 次，其他套餐每分钟 180 次，查询数据源另有每秒约 3 次的单独限制（Notion 请求限制）；Notion MCP 碰到等待不超过 2 秒的限流会自己重试一次，更长的直接把 rate_limited 错误交给 agent（Notion MCP 限流说明）。

把这三条和真调的发帖量放在一起，就能算出表该怎么切。两个品牌 11 月 1 日到 7 日（新加坡时间）在 TikTok 和 Instagram 上一共发了 22 条：CeraVe TikTok 5 条、Instagram 3 条，The Ordinary TikTok 5 条、Instagram 9 条。按这个速度，3 个品牌两周大约 66 条，加上 YouTube，留出余量也在 100 条以内。所以我们的做法是：在 Notion 里建一个保存好的视图「最近 14 天」，按 Posted at 过滤、按 Key 排序；两个 agent 写之前都用视图模式读这个视图，在本地按 Key 比对，新键建页、旧键更新。这样查询不占 Free 和 Plus 的额度，也不会碰到 100 行的上限。品牌多到两周超过 100 条时，按品牌或平台各建一个视图。

写入时让 agent 遵守一份写在 Notion 页面里的规则，两个 agent 读同一份。Notion 的设置提示词本来就会让 agent 先读一页 Agent Operating Guide（Notion 设置指南），我们把竞品表的规则也放进这页。下面是一次新建调用的参数示例，字段名和本文的 11 个字段一致：

{
  "parent": "<竞品表的数据源，写法以 notion-create-pages 工具说明为准>",
  "pages": [{
    "properties": {
      "Key": "tiktok:7705177610602532114",
      "Platform": "tiktok",
      "Brand": "The Ordinary",
      "URL": "https://www.tiktok.com/@theordinary/video/7705177610602532114",
      "date:Posted at:start": "2026-11-06T21:44:30Z",
      "Views": 50600, "Likes": 2908,
      "date:Observed at:start": "2026-11-07T16:21:58Z",
      "Agent": "claude-code", "Count precision": "rounded"
    }
  }]
}

这段是配置示例，参数形状按 Notion 页面工具参考写，parent 怎么指向数据库以你客户端里 notion-create-pages 的工具说明为准；日期属性在返回里会出现在 date:<名字>:start 这样的键下（页面工具参考），没有在 Notion 里实际创建过。写完以后读返回里的 properties 和 warnings：Notion 会告诉你某个键被改存到了哪里，之后更新要用它给的键名。

写给两个 agent 的规则页：一页纸讲清谁写什么

两个 agent 能不能长期不打架，关键在于它们读的是不是同一份规则。Notion 的设置指南会让 agent 在工作区里找到或新建一页 Agent Operating Guide，每次开工先读它（Notion 设置指南）。我们建议在这页里专门留一节「竞品表规则」，把前面几节定下的做法压成六条 agent 能逐条执行的句子，不超过一屏：

这六条每条都对应前文的一个实测发现：第 2 条来自 40 个 ID 转成浮点数后 0 个能还原，第 3 条来自 YouTube 频道列表的「10d ago」，第 4 条来自 71,400,000 和 71,440,950 的差别，第 5 条来自置顶视频和合作帖。最容易被忽略的是第 4 条：半小时内 8 条视频的播放数变少了，所以「两次里取较大的」是错的，两个精确值之间只能按读到的先后来定。第 6 条也不能省：agent 碰到错误时倾向于换一条路绕过去，在一张共享的表上，悄悄绕过比停下来更糟，因为另一个 agent 和看周报的人都不知道这一批数据是怎么来的。

把规则写在 Notion 里而不是写在各自的提示词里，好处是改一次两边都生效。Notion 3.8 起页面的版本历史会标出是谁改的，包括 agent 的改动（Notion 3.8 发布说明），所以规则页本身被谁改过也查得到。规则页最好对 agent 只读：Notion 10 月 13 日起支持数据库的列权限，agent 也可以拿到自己的列权限（Notion 帮助中心：数据库属性权限），但列权限只在 Business 和 Enterprise 上有；在 Plus 上，比较实际的办法是把规则页放在 agent 连接没有编辑权限的位置，并每周看一次它的版本历史。

每周成本：接口费、订阅费和 Notion 的调用额度

钱分三块：EveryInfra 的接口费、两个 AI 产品的订阅、Notion 的套餐。接口费按目录 price_usd 算。我们的方案是 3 个品牌，Claude Code 每天对每个品牌调一次 tiktok/user_videos 和一次 tiktok/search，Codex 每天对每个品牌调一次 instagram/user_posts 和一次 youtube/user_posts，每天 12 次；另外每周为新出现的约 3 条 YouTube 视频各调一次 youtube/video 补日期。这 5 项能力的目录价都是每次 $0.000556（EveryInfra 定价）。

订阅一侧按各家定价页 2026 年 11 月 8 日读到的价格：Notion Plus 月付每人 $12、年付折合每月 $10，Business 月付每人 $24、年付折合 $20（Notion 定价）；Claude Pro 月付 $20、年付折合 $17（Claude 定价）；ChatGPT Plus 每月 $20（OpenAI 帮助中心：What is ChatGPT Plus）。和这些订阅比，每月约 $0.21 的接口费可以忽略，这套方案的成本几乎全在订阅上；真正要盯的是 Notion 的查询额度和两个 AI 产品的用量额度，它们决定了你能不能每天跑。

还有两笔不在账单上的成本。一是 Notion 套餐决定的查询方式：如果团队在 Free 或 Plus 上，就必须用视图模式查重，不能依赖 SQL；在 Business 上加了 Notion AI，才能放心让 agent 用 SQL 跨表比对。二是无人值守运行的鉴权：Notion 的 MCP 令牌（不用浏览器登录、直接用 Bearer 令牌连）只有 Business 和 Enterprise 能建，而且只有工作区所有者能建（Notion 开发者文档 FAQ）；Free 和 Plus 上只能走 OAuth，这意味着定时任务要跑在一个能保存 OAuth 登录的客户端里。

小红书对照：同一个品牌换个平台，字段长什么样

中文读者的竞品表多半还要加小红书。我们在 00:34:00 用 xiaohongshu/search 搜了 CeraVe 的中文名「适乐肤」，20 条结果，扣费 $0.005556，单价是 TikTok 那几项的 10 倍。这 20 条和海外三个平台比，有四点不同，都会影响表的设计。第一，ID 是 24 位的十六进制字符串，例如 6adc93fe0000000033031fd6，不会有超出 2^53 的问题，但同样要存成文本。第二，posted_at 是完整的 ISO 8601 时间，20 条从 2026 年 5 月 23 日到 11 月 5 日，其中 15 条在最近 30 天内，只有 1 条在最近 7 天内；返回里有 updated_at 字段，但这 20 条全部是空的，不能拿它当更新时间。第三，有 2 条标了 is_cooperation_note: true，也就是平台标注的合作笔记，这一列在小红书上可以直接映射成表里的「是否合作」。第四，20 条全部来自普通用户，author_is_verified 一条都不是真，搜索结果里没有品牌官方号的帖子。

小红书的数据适合放进同一张表，但 Brand 列的映射规则要改：海外三个平台的帖子大多来自品牌主页，按发帖账号映射品牌；小红书的搜索结果几乎都是用户笔记，品牌要按搜索词映射，并加一列标出「这是用户谈论品牌，不是品牌自己发的」。成本上，如果 3 个品牌每天各搜一次小红书，每周多 21 次、$0.116676，会让接口费翻好几倍，但依然远低于任何一个订阅。

做不了或要注意的地方

第一，Notion 一侧我们没有实测。本文所有 Notion 工具名、参数和限制都来自 2026 年 11 月 8 日读到的 Notion 开发者文档，Notion 在 10 月 13 日到 11 月 5 日之间几乎每两三天更新一次 MCP 工具（Notion 开发者更新日志），参数随时可能变，动手前请重读文档。Notion 早年开源的本地 MCP 服务器包已经不再积极维护，Notion 自己的文档建议改用远程服务器 https://mcp.notion.com/mcp（GitHub：makenotion/notion-mcp-server）。

第二，ChatGPT 网页版接 EveryInfra 目前没有好办法。OAuth 我们不支持，?key= 会让 Key 出现在设置页和日志里。ChatGPT 账号一侧请用 Codex。Reddit 上也有用户反映 Notion 在 ChatGPT 里接上后不能用、连不上（Reddit：Notion MCP not working in ChatGPT），这类问题我们无法替 Notion 或 OpenAI 排查。

第三，平台数据本身的边界。tiktok/search 返回的是和关键词相关的视频，不是全量；youtube/user_posts 只给相对日期；instagram/user_posts 会把合作帖一起返回；计数会随时间变化，大数字在某些能力里是约数。这些都要在表里用字段标出来，而不是假装数据是干净的。EveryInfra 一侧，参数错误、调用失败或空结果不扣费，每次扣费都写在返回的 billing.charged_usd 里（EveryInfra MCP 说明）。

第四，两个 agent 同时写同一行。本文的方案是分平台分工，Claude Code 只写 TikTok 行，Codex 只写 Instagram 和 YouTube 行，同一行只会被一个 agent 写，从设计上避开冲突。如果你让两个 agent 都拉同一个平台，就要加一条「同一个 Key 在 10 分钟内只允许一个 agent 写」的规则，并用 notion-get-version-changes 定期查是谁改的。

第五，时区。表里存的是 UTC，但 Notion 的日期属性显示时会按查看者的时区换算，新加坡的同事看到的是 UTC 加 8 小时。按周汇总时一定要先定好「一周」按哪个时区切：本文统计 11 月 1 日到 7 日的发帖数，用的是新加坡时间 11 月 1 日 0 点到 8 日 0 点，换成 UTC 就是 10 月 31 日 16 点到 11 月 7 日 16 点。如果两个 agent 一个按 UTC 切、一个按本地时间切，周报里同一周的数字会对不上，而且很难看出来是哪里错了。最稳的做法是在规则页里写死时区，周报的视图也用同一个时区过滤。

第六，普通用户的数据。tiktok/search 和 xiaohongshu/search 返回的大多是普通创作者的帖子，返回里有他们的昵称、简介和头像地址。竞品表只需要帖子链接、发布时间和计数，个人资料不必存，存了也会随时间过期。周报里引用创作者的内容时，用帖子链接代替昵称；需要按创作者汇总时，用平台给的作者 ID 做分组键，不把昵称当成主要信息展示。

行业动向（2026 年 10–11 月）

2026 年 11 月 4 日，Notion 把 MCP 宣传成「所有 agent 共享的大脑」，并给 ChatGPT 和 Claude 各配了一份设置提示词（Notion 官方 X 帖子）。对读者的意义是：Notion 正在把「多个 agent 读写同一个工作区」当主线做，相关工具还会快速变化。

2026 年 11 月 3 日，Notion MCP 上线 notion-restore-version，10 月 29 日上线 notion-get-version-changes，10 月 27 日上线建议修改和 notion-view-version（更新日志）。对读者的意义是：agent 写错了能查、能看、能退，多 agent 共写一张表的风险比一个月前低了很多。

2026 年 11 月 3 日前后，OpenAI 帮助中心宣布从 12 月起，Plus、Pro 和 Business 的用量在 ChatGPT 和 Codex 之间共用，按 token 计量（ChatGPT 和 Codex 用量说明）。对读者的意义是：用 Codex 跑每天的拉数任务，会和你在 ChatGPT 里聊天抢同一份额度，长返回要尽早裁剪。

常见问题

notion mcp server url 是哪个？

远程服务器地址是 https://mcp.notion.com/mcp，用 Streamable HTTP；客户端不支持时可以退回 SSE 地址 https://mcp.notion.com/sse（Notion 开发者文档）。EveryInfra 的远程 MCP 地址是 https://api.everyinfra.com/mcp。（问题来源：Google 联想词「notion mcp server url」「notion mcp url」）

claude code notion mcp authentication 怎么做？

运行 claude mcp add --transport http notion https://mcp.notion.com/mcp，然后在 Claude Code 里输入 /mcp，按提示走 OAuth 登录（Notion 开发者文档）。如果需要不经过浏览器登录，Business 和 Enterprise 的工作区所有者可以在开发者门户建一个 MCP 令牌，客户端把它当 Bearer 令牌发送。（问题来源：联想词「claude code notion mcp authentication」「setup notion mcp claude code」）

notion mcp chatgpt not working 怎么办？

先确认是在 ChatGPT 网页版里用的，OpenAI 文档写明自定义 MCP 插件要在网页版添加，工作区权限和 Lockdown 等安全设置也会限制它（OpenAI 文档）。Notion 10 月 20 日的更新日志还提到，ChatGPT 里的新工具要等 OpenAI 审核过更新后的 Notion 应用才会出现（更新日志）。Reddit 上同类求助帖的回复大多是「等修复」或「改用 Claude」（Reddit 讨论）。（问题来源：联想词「notion mcp chatgpt not working」）

notion mcp codex 能一起用吗？

能。Notion 文档给了 Codex 的写法：在 ~/.codex/config.toml 加 [mcp_servers.notion] 和地址，再运行 codex mcp login notion；团队共用可以把同样的配置放进项目根目录的 .codex/config.toml（Notion 开发者文档）。用 ChatGPT 账号登录 Codex 时，用的是 ChatGPT 套餐的额度。（问题来源：联想词「notion mcp codex」）

Notion 免费版能用 Notion MCP 吗？

能连，但有几项受限：SQL 查询在 Free 和 Plus 上只有有限的单数据源额度，行模式也算在里面，只有查保存好的视图不占额度；MCP 令牌只有 Business 和 Enterprise 能建；部分搜索筛选只在 Business 和 Enterprise 上生效（Notion 开发者文档 FAQ）。（问题来源：Reddit 帖子《Did Notion just significantly change the MCP capabilities on the free plan?》）

chatgpt notion mcp write 能写数据库吗？

能。OpenAI 文档写明 ChatGPT 支持 MCP 服务器的读写工具，写操作默认要你确认（OpenAI 文档）；Notion 的 notion-create-pages 和 notion-update-page 就是写工具。删除类工具如 notion-delete-pages 还要求参数里带 user_confirmed: true。（问题来源：联想词「chatgpt notion mcp write」）

上手步骤

1. 在 EveryInfra 快速上手 注册并建一把 API Key，放进环境变量 EVERYINFRA_API_KEY。
2. 在 Notion 里建竞品表，按本文 11 个字段设属性，Key 用标题列，再建一个「最近 14 天」视图。
3. Claude Code 一侧照本文配置示例加两个 MCP 服务器；Codex 一侧在 config.toml 里加两段。
4. 先各手动跑一次：让 Claude Code 拉一个品牌的 tiktok/user_videos，让 Codex 拉同一个品牌的 instagram/user_posts，看表里是否各多出一组行、Key 有没有重复。
5. 确认无误后再加定时任务，并每周用 notion-get-version-changes 抽查一次是谁写的。

想先看看各平台能拿到哪些字段，可以直接看 TikTok 爬虫 API、Instagram 爬虫 API、YouTube 爬虫 API、小红书爬虫 API 这几个平台页，以及 TikTok 主页视频、TikTok 关键词搜索、Instagram 主页帖子、YouTube 频道视频、YouTube 单条视频、小红书搜索 这几项能力的说明。

相关阅读

• GitHub Copilot MCP：竞品社媒周报的配置示例与 26 次接口实测：同样是竞品社媒周报，那篇把数据写成脚本交给 GitHub Actions，本篇把数据写进 Notion 让多个 agent 共用。
• ChatGPT Spaces 做竞品社媒追踪页：只用 ChatGPT 一边的做法，可以和本篇的 Codex 接法对照。
• Claude Code subagents：Haiku 子代理并行拉 TikTok 品牌号：账号多时怎么在 Claude Code 里并行拉取、控制上下文。
• Claude Artifacts 接 MCP 做实时竞品看板：不想用 Notion 时，另一种展示竞品数据的办法。
• EveryInfra 远程 MCP 服务器：各客户端的接入配置。

参考资料

1. Notion 官方 X 帖子「Give all your agents one shared brain in Notion」，Notion，2026-11-04，https://x.com/NotionHQ/status/2118059335930744999
2. Connect AI tools with Notion MCP，Notion 帮助中心，读取于 2026-11-08，https://www.notion.com/help/notion-mcp
3. Set up Notion for your agent（设置指南），Notion 开发者文档，读取于 2026-11-08，https://developers.notion.com/prompts/setup
4. Use shared Skills and delegate to Notion Custom Agents（个人记忆），Notion 开发者文档，读取于 2026-11-08，https://developers.notion.com/guides/mcp/tools-skills-agents
5. Connect Notion to your AI assistant with MCP，Notion 开发者文档，最后修改 2026-10-28，https://developers.notion.com/guides/mcp/get-started-with-mcp
6. Notion MCP tools for projects, tasks, and teamwork，Notion 开发者文档，读取于 2026-11-08，https://developers.notion.com/guides/mcp/mcp-supported-tools
7. Notion MCP FAQs and complete tool list，Notion 开发者文档，读取于 2026-11-08，https://developers.notion.com/guides/mcp/tools-faqs
8. Database and view tools in Notion MCP，Notion 开发者文档，读取于 2026-11-08，https://developers.notion.com/guides/mcp/tools-databases-reference
9. Page creation and editing tools in Notion MCP，Notion 开发者文档，读取于 2026-11-08，https://developers.notion.com/guides/mcp/tools-pages-reference
10. Comments and change history tools in Notion MCP，Notion 开发者文档，读取于 2026-11-08，https://developers.notion.com/guides/mcp/tools-comments-reference
11. Notion MCP rate limits，Notion 开发者文档，读取于 2026-11-08，https://developers.notion.com/guides/mcp/rate-limits
12. Request limits，Notion API 参考，读取于 2026-11-08，https://developers.notion.com/reference/request-limits
13. Changelog，Notion 开发者文档，2026-10-13 至 2026-11-05 条目，https://developers.notion.com/page/changelog
14. Connect AI assistants to Notion with MCP（概览），Notion 开发者文档，读取于 2026-11-08，https://developers.notion.com/docs/mcp
15. Agents, rebuilt to do more for less，Notion 发布说明，2026-10-19，https://www.notion.com/releases/2026-10-19
16. Notion 3.8: Context for your agents，Notion 发布说明，2026-10-13，https://www.notion.com/releases/2026-10-13
17. View your Notion Agent Memories，Notion 帮助中心，读取于 2026-11-08，https://www.notion.com/help/view-your-notion-agent-memories
18. Manage database property access，Notion 帮助中心，读取于 2026-11-08，https://www.notion.com/help/database-property-access
19. Notion 定价页，Notion，读取于 2026-11-08，https://www.notion.com/pricing
20. makenotion/notion-mcp-server，GitHub，读取于 2026-11-08，https://github.com/makenotion/notion-mcp-server
21. Connect Claude Code to tools via MCP，Anthropic Claude Code 文档，读取于 2026-11-08，https://code.claude.com/docs/en/mcp
22. Schedule recurring tasks in Claude Code Desktop，Anthropic Claude Code 文档，读取于 2026-11-08，https://code.claude.com/docs/en/desktop-scheduled-tasks
23. Automate work with scheduled tasks，Anthropic Claude Code 文档，读取于 2026-11-08，https://code.claude.com/docs/en/routines
24. Claude 定价页，Anthropic，读取于 2026-11-08，https://claude.com/pricing
25. Add custom MCP server，OpenAI 文档，读取于 2026-11-08，https://developers.openai.com/api/docs/guides/custom-mcp-server
26. Model Context Protocol（Codex），OpenAI 文档，读取于 2026-11-08，https://developers.openai.com/codex/mcp
27. ChatGPT Work and Codex，OpenAI 帮助中心，读取于 2026-11-08，https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex
28. Understanding ChatGPT and Codex usage limits，OpenAI 帮助中心，读取于 2026-11-08，https://help.openai.com/en/articles/20001625-understanding-chatgpt-and-codex-usage-limits
29. What is ChatGPT Plus?，OpenAI 帮助中心，读取于 2026-11-08，https://help.openai.com/en/articles/6950777-what-is-chatgpt-plus
30. MCP server tools now in ChatGPT developer mode，OpenAI 社区，2025-09-10，https://community.openai.com/t/mcp-server-tools-now-in-chatgpt-developer-mode/1357233
31. Tools（工具注解），Model Context Protocol 规范 2025-06-18，https://modelcontextprotocol.io/specification/2025-06-18/server/tools
32. Number.MAX_SAFE_INTEGER，MDN，读取于 2026-11-08，https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER
33. RFC 3339: Date and Time on the Internet: Timestamps，IETF，2002-07，https://www.rfc-editor.org/rfc/rfc3339
34. Videos（snippet.publishedAt），YouTube Data API，读取于 2026-11-08，https://developers.google.com/youtube/v3/docs/videos
35. Did Notion just significantly change the MCP capabilities on the free plan?，Reddit r/Notion，读取于 2026-11-08，https://www.reddit.com/r/Notion/comments/1uc5cje/did_notion_just_significantly_change_the_mcp/
36. The reason why Notion MCP is a big fail，Reddit r/Notion，读取于 2026-11-08，https://www.reddit.com/r/Notion/comments/1t7kpxp/the_reason_why_notion_mcp_is_a_big_fail/
37. Notion MCP not working in ChatGPT，Reddit r/Notion，读取于 2026-11-08，https://www.reddit.com/r/Notion/comments/1ps8y93/notion_mcp_not_working_in_chatgpt_is_anyone_else/
38. Database properties，Notion 帮助中心，读取于 2026-11-08，https://www.notion.com/help/database-properties
39. Unique ID property，Notion 帮助中心，读取于 2026-11-08，https://www.notion.com/help/unique-id
40. EveryInfra 能力目录（catalog），EveryInfra，读取于 2026-11-08，https://api.everyinfra.com/api/v1/social/catalog
41. EveryInfra 远程 MCP 端点，EveryInfra，2026-11-08 实测，https://api.everyinfra.com/mcp