GitHub Copilot MCP：竞品社媒周报的配置示例与 26 次接口实测

我们在 2026 年 11 月 6 日 00:17–00:38（新加坡时间）用 EveryInfra 接口真调了 26 次，替 Notion、ClickUp、Asana 三家先跑了一遍「竞品社媒周报」：10 月 30 日到 11 月 5 日这一周，ClickUp 在 YouTube、TikTok、Instagram 上一共发了 14 条，Asana 3 条，Notion 只有 2 条，Notion 和 Asana 的 TikTok 分别停在 5 月 26 日和 6 月 4 日。这件事的做法是：让 GitHub Copilot 的 coding agent（GitHub 文档里现在叫 Copilot cloud agent）经 MCP 读几次真数据、看清字段，然后写出一个普通的 Python 脚本和一个定时 workflow，以后每周由 GitHub Actions 跑，不再调用模型；按目录价，3 个品牌、4 个平台每周接口费 $0.011961，一个月约 $0.0518。26 次里只有 13 次扣费，合计 $0.007228；另外 13 次是 5 次空结果（4 次是我们猜错了账号名，1 次是换对频道后 Asana 本周确实没发 YouTube）、7 次 503（LinkedIn 公司动态 6 次、一次超过 85 秒的同步超时）和一次参数错误，全部没有扣钱，这些失败正是脚本里最该提前写好的地方。先交代边界：我们本机没有 Copilot 订阅，GitHub 一侧的配置、issue 和 workflow 都是照 GitHub 官方文档写的配置示例，没有在 Copilot 里跑过；文中所有实测数字都来自 EveryInfra 接口的真实返回。

这篇文章要回答的问题很具体：你在一家做协作软件的公司负责市场，想每周一早上在仓库里看到一份 Markdown 周报，列出三家竞品上周在四个平台发了什么、哪条最火、发帖频率有没有变化。你想让 GitHub Copilot 来写这份周报的代码，而不是每周让 AI 现查一遍。GitHub 一侧的每条功能事实都来自 GitHub Changelog 和 docs.github.com 的原文，读取日期是 2026 年 11 月 6 日；EveryInfra 一侧的每个数字都来自真调的原始返回。

先说结论：github copilot mcp 这件活分两半做

这份周报最容易做错的地方，是把「写代码」和「每周取数」混成一件事。GitHub 在 2026 年 10 月 28 日同一天发了两样东西，正好对应这两半：一样是连接器和仓库 MCP 配置，让 Copilot 在干活时能调外部工具；另一样是 Copilot Automations 的新工具、新触发器和费用上限，让 Copilot 能按计划自己跑（新工具、触发器与费用上限的更新日志）。如果每周都让 Copilot 自己去调 MCP、自己写周报，每次运行都会开一个 cloud agent 会话，GitHub 的文档写明每次运行都消耗 AI credits 和 Actions 分钟（Copilot automations 文档的计费一节）。

我们推荐的做法是：AI 只上场一次。你开一个 issue，把要求、验收例子、账号清单写清楚，指派给 Copilot；agent 在写代码前用 EveryInfra 的 MCP 工具读目录、试调三四次，看到真实字段长什么样，再写出 weekly_report.py 和 .github/workflows/weekly-report.yml，开一个 PR 给你审。合并以后，每周一由 GitHub Actions 的定时任务直接 POST /api/v1/social，生成 Markdown，提交到仓库或者开一个 issue。之后每周的成本只剩我们的接口费和几分钟 Actions 时间，周报的格式也不会因为模型这周心情不同而变。

两种做法放在一起比，差别主要在三处：每周要不要花 AI credits、对仓库有什么要求、出问题时谁来看。下表的事实都来自 GitHub 文档原文，「本文推荐」一列是我们的判断。

上表里「单次上限最低 30 credits」来自创建 automations 的文档：你可以给每次运行设上限，最小值是 30 AI credits（创建 automations 文档），而 1 个 AI credit 等于 $0.01（个人版用量计费文档）。文档没有给出一次运行一般花多少 credits，所以我们不替它估；能确定的只是：Actions 脚本这条路每周的 AI credits 是 0。两条路也可以组合：脚本每周出数，你再偶尔让 Copilot 读几周的 Markdown 写一段分析。

如果你确实想让 Copilot 每周自己跑，automations 也能用仓库 MCP 设置里配好的工具，本文的那段 JSON 同样有效；具体触发方式和费用归属见 Copilot automations 文档，开之前先给单次和每周设好 AI credits 上限。它解决的是「每周要判断」的问题，周报只是每周取数、排版，用不上这份判断力。

10 月 28 日这条 changelog 到底改了什么

很多人搜「github copilot mcp」是因为看到了 2026 年 10 月 28 日的更新日志《Connect your tools to Copilot without all the setup》。它说的是 GitHub-verified MCP 服务器，也叫连接器（connectors），以公开预览的形式推出：选一个服务、登录、批准访问，之后在 Copilot 应用、Copilot CLI、VS Code、云端的 Copilot 和 GitHub Mobile 里都能用，不用自己找服务器、装东西或管凭据；上线时有 26 个服务，包括 Slack、Figma、Notion、Sentry、Linear、Atlassian Rovo、Cloudflare、Vercel 和 Work IQ（更新日志原文）。原文还写了套餐：所有 Copilot 套餐都在逐步开放；Copilot Business 和 Enterprise 要管理员先打开「Editor preview features」策略，企业用了 MCP 白名单的还要把这些服务加进去。

这条更新和本文的关系要说清楚。第一，EveryInfra 不在这 26 个连接器里，我们也不是 GitHub 验证过的服务，接我们的数据要走「仓库 MCP 配置」或「个人 MCP 配置」，都是你自己填一段 JSON。第二，连接器文档写明：连接器能用在本地和云端沙箱里的会话，但还不支持在 GitHub Actions 上跑的会话，比如把 issue 指派给 Copilot 时开出来的那种会话（Copilot connectors 文档）。仓库 MCP 配置的文档在开头用同一句话再提醒了一遍（仓库 MCP 配置文档）。所以本文的路线是仓库 MCP 配置，它在 Actions 会话和云端沙箱会话里都有效。

第三个容易让人困惑的地方是名字。派活时大家还在说「Copilot coding agent」，但 docs.github.com 里对应的页面现在叫「Copilot cloud agent」，旧的 coding agent 文档地址会跳到新的「Configure MCP servers for your repository」页面（关于 cloud agent 的文档）。本文两个名字指的是同一个功能。

copilot coding agent mcp 配置：仓库设置里那段 JSON

仓库 MCP 配置填在仓库的 Settings → Copilot → MCP servers 页面，格式是一个 mcpServers 对象，键是服务器名字，值里必须有 type 和 tools 两个键；远程服务器写 url，需要认证的写 headers，请求头的值可以引用以 COPILOT_MCP_ 开头的密钥，写法是 $COPILOT_MCP_API_KEY 或 ${COPILOT_MCP_API_KEY}（仓库 MCP 配置文档）。文档强烈建议在 tools 里只列具体的只读工具，因为 agent 会自主调用，不会先问你。EveryInfra 的远程 MCP 地址是 https://api.everyinfra.com/mcp，用 Bearer 密钥认证，不走 OAuth，所以正好落在文档支持的范围里。下面是本文的配置示例：

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

为什么只放三个工具？我们在 00:16（新加坡时间）不带密钥读了一次 tools/list，又在 00:26 带密钥读了一次，两次都返回 12 个工具，整个返回 16,247 字节。周报只需要三样：查目录（选能力、看参数）、调接口、读异步任务的结果。其余九个里有查余额、开充值链接、开工单、解验证码这类，和周报无关，放进白名单只会让 agent 多一种走错的可能。

12 个工具各自带了 MCP 规范里的 annotations。这里有一个只有读了真实返回才会发现的细节：everyinfra_call_api 的 readOnlyHint 是 false、destructiveHint 是 true，因为它会扣钱；而 GitHub 文档写明，Copilot code review 只使用 tools/list 里 annotations.readOnlyHint 为 true 的工具，没有这个标注或标成 false 的会被排除（仓库 MCP 配置文档的 Note）。结果是：同一份仓库配置，cloud agent 能调我们的取数工具，Copilot 在审 PR 时调不到。对周报这件事这正合适，审代码时不该花钱取数；如果你不想让 code review 碰任何 MCP 工具，文档也给了关掉的开关。MCP 规范本身对这些标注的说明见 MCP 规范的 Tools 一节。

还有两条限制直接影响写法。文档说 cloud agent 和 code review 只支持 MCP 的工具，不支持服务器带的 resources 和 prompts；我们的周报只用工具，没有影响。另一条是验证方法：把一个 issue 指派给 Copilot，打开会话日志里的「Start MCP Servers」一步，日志底部会列出启动成功的工具。Reddit 上有用户在 coding agent 里配 Atlassian 的 MCP 服务器，日志显示连接成功却「retrieved 0 tools」（r/GithubCopilot 讨论帖），遇到这种情况，先确认 tools 白名单里的名字和 tools/list 返回的名字一字不差。

secrets 怎么放：两把钥匙，两个抽屉

这一节是整件事里最容易出错的地方。GitHub 现在给 cloud agent 单独设了一类密钥，叫 Agents secrets，和 Actions、Codespaces、Dependabot 三类并列；文档写明，cloud agent 拿不到 Actions、Codespaces、Dependabot 的密钥和变量，只拿得到 Agents 这一类；而 Agents 密钥里名字以 COPILOT_MCP_ 开头的，只交给 MCP 服务器，不会作为环境变量暴露给 agent 运行的命令（cloud agent 密钥与变量文档）。反过来，你的定时 workflow 用的是 Actions secrets，读不到 Agents secrets。所以一份周报要放两把钥匙：

起名字和放位置还有三条细则，都写在同一份文档里。密钥名不能以 GITHUB_ 开头；Agents 这一类既有密钥也有变量，但 agent 跑在云端沙箱时只拿得到密钥、拿不到变量，变量只有跑在 GitHub Actions 上时才可用；不带 COPILOT_MCP_ 前缀的 Agents 密钥会作为环境变量交给 agent 运行的命令和工具，所以除非你确实要让 agent 在会话里联网跑脚本，否则别放不带前缀的 EveryInfra Key。组织级的 Agents 密钥可以让多个仓库共用一把，适合一个团队在好几个仓库里都要读竞品数据的情况。

为什么不用同一个名字、同一把钥匙图省事？原因有三个。第一，上面说的隔离是 GitHub 定的，两个抽屉本来就互相读不到。第二，我们建议在 EveryInfra 控制台建两把 Key，分别命名，这样哪把泄露、哪把在乱花钱，在调用记录里一眼能分开。第三，GitHub 的推送保护默认只拦它认识格式的密钥，EveryInfra 的 Key 不在其中，agent 如果把 Key 写进测试文件，不一定会被拦下来（推送保护更新日志），所以 issue 里要写明「Key 只从环境变量读」。

还有一个和防火墙有关的坑。cloud agent 的网络默认被防火墙限制，但文档写明，防火墙只管 agent 通过 Bash 工具启动的进程，不直接管 MCP 服务器进程（防火墙文档的 Limitations 一节）。这意味着：agent 经 MCP 调我们没问题；但如果它想在会话里直接跑一遍刚写好的 weekly_report.py，请求会发往 api.everyinfra.com，会被防火墙拦下，PR 正文里会出现一条拦截警告。两种处理办法：在仓库的 Internet access 设置里把 api.everyinfra.com 加进自定义白名单，再另放一把不带 COPILOT_MCP_ 前缀的 Agents secret 给 agent 的命令用；或者更稳妥地，让 agent 用 MCP 拿到的真实返回存一份样例 JSON，脚本的测试读这份样例，不在会话里联网。我们推荐后者，因为第一种做法会让 Key 出现在 agent 的命令环境里，文档虽然说日志会把密钥值打码，但你没必要多开这个口子。

给 agent 的 issue 怎么写

GitHub 的最佳实践文档说，指派给 Copilot 的任务要写清楚问题、验收标准和要改哪些文件，范围小、定义清楚的任务效果最好（给 Copilot 分派任务的最佳实践）。对周报来说，最重要的是把「账号清单」和「验收例子」写死，不让 agent 去猜。我们在实测里猜错了 3 个账号名（下一节细说），每一次都只返回一个空列表，不报错、不扣费，脚本照样能跑完，周报上就静悄悄地少了一行。下面是 issue 的写法示例：

## 任务
写 weekly_report.py 和 .github/workflows/weekly-report.yml：每周一 09:00（Asia/Singapore）
取 config/competitors.yml 里每个品牌上周（周一 00:00 到周日 23:59，UTC）的新内容，
生成 reports/<ISO 年>-W<周>.md 并提交到 main。

## 数据（先用 MCP 工具 everyinfra_list_capabilities 核对参数，再各试调 1 次）
- YouTube：youtube/user_posts，参数 url（频道链接），since=上周一，mode=async
- TikTok：tiktok/user_videos，参数 username，limit=30
- Instagram：instagram/user_posts，参数 username，limit=30，mode=async
- LinkedIn：linkedin/company_posts，参数 company（/company/ 后面那段），limit=20

## 账号清单（不要改，不要猜；LinkedIn 公司名待核对）
notion:  youtube https://www.youtube.com/@Notion | tiktok notionhq | instagram notionhq | linkedin notionhq
clickup: youtube https://www.youtube.com/@ClickUpProductivity | tiktok clickup | instagram clickup | linkedin clickup-app
asana:   youtube https://www.youtube.com/channel/UC2BoogM0AqwOJyoSp1S4ClQ | tiktok asana | instagram asana | linkedin asana

## 必须处理
1. TikTok 先去掉 is_pinned=true 的视频，再按 posted_at 过滤；不要读到第一条旧视频就停。
2. YouTube 的 posted_at 可能是 "1d ago" 这种相对时间，按取数时刻换算成日期。
3. HTTP 503 或 status=failed：按 retry_after 等待后重试 1 次，仍失败就在周报里写「本周未取到」，不要中断。
4. 返回 0 条时写「本周 0 条」，同时在周报末尾列出这个账号，提醒人工核对账号名。
5. Key 只从环境变量 EVERYINFRA_API_KEY 读，不写进任何文件、日志和测试。
6. 测试用 tests/fixtures/ 下的样例 JSON（用 MCP 试调的真实返回存），测试里不联网。

## 验收例子
用 fixtures 跑，ClickUp 的 TikTok 本周条数 = 4（不是 0，也不是 7），本周播放合计 = 60463。

这份 issue 里最后那条验收例子很关键。它的期望值来自我们在 00:19（新加坡时间）真调 tiktok/user_videos 拿到的 ClickUp 返回：10 条里前 3 条是 2024 年的置顶视频，播放量分别是 2,010 万、750 万和 320 万。返回按时间倒序排，但置顶视频永远排在最前；如果脚本用「第一行就是最新一条」，周报会说 ClickUp 最近一条 TikTok 发在 2024 年；如果脚本按时间倒序读、读到第一条早于窗口的就停，ClickUp 本周会被算成 0 条，而实际是 4 条。只去掉置顶、不按日期过滤，又会算成 7 条。把这个数写进 issue，agent 写出来的代码对不对，跑一次测试就知道，不需要你逐行读。

一次真实往返：Copilot 会发什么，我们回什么

Copilot 一侧我们没有跑过，但 MCP 是一个公开协议，agent 调工具时发出去的是一条标准的 JSON-RPC tools/call 请求，走的是 MCP 规范里的 Streamable HTTP 传输：每条消息是一次 HTTP POST，客户端要在 Accept 里同时声明 application/json 和 text/event-stream（MCP 规范的传输一节）。所以我们可以用 curl 发一条和 agent 完全一样的请求，看我们的服务器回什么。我们在 2026 年 11 月 6 日 00:26:28（新加坡时间）发了下面这条：

curl -s https://api.everyinfra.com/mcp \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
       "params":{"name":"everyinfra_call_api",
                 "arguments":{"platform":"tiktok","action":"user_videos",
                              "params":{"username":"notionhq","limit":5}}}}'

服务器在 31.1 秒后回了 HTTP 200。result.content[0].text 里是一段 13,272 个字符的 JSON：5 条 Notion 的 TikTok 视频，每条有 posted_at、view_count、like_count、is_pinned 等字段，最新一条发于 2026-05-26，播放 22,800；末尾的 billing 里 charged 为 true、charged_usd 为 0.000556。这也是 agent 在写代码前会看到的东西：它能直接从真实返回里知道字段名、知道时间是 ISO 格式、知道这个账号最近 5 个多月没发 TikTok。

13,272 个字符只是 5 条视频。按每 4 个字符约 1 个 token 粗算，约 3,300 token；一份 3 个品牌、4 个平台、每个平台 30 条的原始数据，进到 agent 的上下文里会有几十万字符。这正是我们不建议每周让 agent 自己取数的另一个原因：取数和格式化交给脚本，agent 只在写代码时看几条样例就够了。

用 26 次真调把这份周报先跑一遍

在让 agent 写脚本之前，我们自己先把这份周报跑了一遍，目的是知道「正确答案」长什么样，后面才能判断脚本对不对。时间是 2026 年 11 月 6 日 00:17 到 00:38（新加坡时间），统计窗口按 UTC 日期定为 10 月 30 日到 11 月 5 日共 7 天。四个平台用的能力和参数都以免费目录 GET /api/v1/social/catalog 为准：youtube/user_posts（必填 url，可选 since、sort）、tiktok/user_videos（必填 username，可选 sort、until、min_likes）、instagram/user_posts（必填 username，目录标为异步）、linkedin/company_posts（必填 company）。能力页分别在 YouTube 用户内容、TikTok 用户视频、Instagram 用户内容 和 LinkedIn 公司动态。

这张表本身就是一份周报的主体，从里面能读出三件事。第一，三家的社媒节奏差得很远：ClickUp 一周在三个平台发了 14 条，Instagram 上 10 条里有 7 条落在本周，TikTok 4 条，YouTube 3 条，而且 YouTube 那 3 条都和 AI 有关，其中两条直接在讲它自己的 AI 助手 ClickUp Brain。第二，Notion 和 Asana 已经基本不在 TikTok 上发了，两家最近 10 条视频里最新的一条分别是 2026-05-26 和 2026-06-04，Asana 最近 10 条里有 7 条集中在 2026-06-04 同一天，另外 3 条是 2025 年和 2023 年的。周报里「本周 0 条」本身是个有用的信号，但前提是你确认了账号名是对的，否则 0 条也可能是猜错了账号。第三，Instagram 是三家这周唯一都发了内容的平台，如果你只能盯一个平台，从这张表看应该是它。

这些结论都有边界。窗口只有一周，样本是三个品牌；TikTok 每次只取了 10 条，Instagram 也是 10 条，对 ClickUp 来说 10 条刚好盖住 9 天。我们另外为中国读者常关心的出海品牌试了一次 DJI 的 Instagram（djiglobal）：10 条全部发在 11 月 1 日到 11 月 5 日，也就是说 10 条只盖住 5 天，一周的周报至少要取 20 条。这条观察直接决定 issue 里 limit 写多少：发帖勤的账号要多取，取多了也不多花钱，因为这几项能力按次计费，一次调用返回多少条都是同一个价。

这一周的周报样例：脚本最后应该写出什么

光有条数还不够，周报要让市场同事一眼看到「哪条最火、在讲什么」。下面这张表是我们按真调返回手工排出来的本周样例，也是你可以直接贴进 issue、让 agent 照着生成的格式。表里只列每家每个平台互动最高的一条，TikTok 已经去掉置顶，Instagram 按点赞排序，YouTube 按播放排序；YouTube 的日期是用取数时刻减去「1d ago」「5d ago」换算的，所以只精确到天。

从这张样例里能看到两件只看条数看不出来的事。第一，ClickUp 的 TikTok 走的是职场段子路线，本周 4 条（2026-11-05、2026-11-04、2026-11-02、2026-10-30）合计播放 60,463、点赞 3,392，单条最高 27,400；它窗口外前一天（2026-10-29）还有一条 145,200 播放的，说明这个账号的爆款间隔大概是一周一次，周报的窗口如果按「运行时刻往前 7 天」滑动，这种爆款会时进时出。第二，三家这周的内容都在往 AI 上靠：Notion 唯一一条 YouTube 讲的是怎么把 ChatGPT 或 Claude 接进 Notion，ClickUp 的 YouTube 三条都和 AI 有关，ClickUp 在 Instagram 上 2026-10-30 的每周回顾里还专门提了它新做的 Salesforce MCP，Asana 的 Instagram 在窗口前两天（2026-10-28）还在宣传它的 AI 助手 Dash。如果你做的也是协作软件，这一列「本周在讲什么」比发帖条数更值得每周看。

点赞数要放在一起比，必须先知道各家的基数。ClickUp 的 Instagram 本周 7 条合计 273 个赞，单条 1 到 73 个不等；Asana 本周 3 条合计 82 个；Notion 只有 1 条，143 个赞，比 ClickUp 任何一条都高。只看条数会觉得 ClickUp 在 Instagram 上远远领先，按单条互动看却是 Notion 更高。所以我们建议周报里同时放「条数」「合计互动」「单条中位数」三列，再加一列「本周最高的一条」，由脚本从返回里算，不要让人每周手算。这三列都只用到返回里已有的字段，不需要额外调用，也就不多花钱。

两个出海品牌的样例也值得放进来，因为它们说明同一份脚本换一组账号就能用。DJI 的 Instagram（djiglobal）10 条全部发在 2026-11-01 到 2026-11-05，合计 111,392 个赞，其中 2026-11-04 一条运动相机特写拍了 49,372 个赞，一家公司一周的 Instagram 互动就是上面三家协作软件合计的两百多倍。Mercado Libre 墨西哥站的 Instagram（mercadolibre.mex）本周 5 条，合计 1,132 个赞，其中 3 条属于同一个「Unidos por la velocidad」赛车主题（2026-10-30 一条、2026-11-01 两条，点赞最高的 470 是为车手第 300 场比赛发的祝贺），另外 2 条是 2026-11-03 的抽奖活动。这两组数据说明两件事：一是 limit 必须按账号的发帖频率设，DJI 这种一天两三条的账号取 10 条只能盖住 5 天；二是不同行业的互动量差两到三个数量级，周报里跨品牌比较要用环比（这周比上周）而不是绝对值。

实测里踩到的 6 个坑，脚本要提前写进去

26 次真调里有一半没有扣费。我们把它们按结果分了组：13 次正常扣费，5 次空结果自动退款，7 次 503（6 次是 LinkedIn 公司动态，1 次是 YouTube 同步请求超时），1 次是我们故意写错参数的 422。没有一次失败扣了钱，扣费合计 $0.007228，正好是 13 × $0.000556。

每一组失败都对应脚本里的一段处理。我们把它们列成一张表，issue 里的「必须处理」就是从这张表来的：

第二个坑值得多说两句。我们把 8 次拿到数据或超时的同步请求，从发出到收到第一个响应的时间画了出来（LinkedIn 公司动态那 6 次 503 都在 2.2–2.4 秒内返回，参数错误的 422 只用了 0.2 秒，没有画进去）：TikTok 三次分别是 22.2、68.9 和 21.6 秒，经 MCP 的那次是 31.1 秒；YouTube 正确账号的一次是 11.5 秒，猜错账号的一次等了 40.3 秒才回空结果，另一次 89.8 秒后回了 503。同步请求最多等 85 秒，这是错误信息里写明的；ClickUp 的 TikTok 用了 68.9 秒，离上限只差 16 秒。脚本跑在 Actions 上，偶尔多等几十秒无所谓，但一旦超时就要重发，所以凡是目录里允许的，我们都建议直接用异步模式：提交时立刻拿到 job_id，之后每隔几秒读一次 GET /api/v1/jobs/{job_id}，读任务结果本身不收费。

第五个坑是 LinkedIn。当晚 00:18 到 00:38，linkedin/company_posts 对 Notion、ClickUp、Asana 和错误信息建议的示例公司 google 一共 6 次都回 503，错误码是 unavailable，每次的 billing.charged_usd 都是 0；第 3 次失败时，返回的 next_steps 写着「10 分钟内 3 次失败，都没有扣费」，并建议先试一次示例请求，示例也失败就说明是我们这边的问题，要先问用户再开工单。同一时间 linkedin/company_profile 是好的，00:34 读到 Notion 的公司主页，扣 $0.000556，返回里有关注人数 1,137,647 和员工数 7,211，6.2 秒就回来了。周报里 LinkedIn 一列在动态取不到的那一周，至少还能放关注人数的周变化。目录里这项能力当时仍标着可用，所以脚本不能只靠目录判断，要能接住 503。周报里「LinkedIn 本周未取到」比一份悄悄少了一列的周报有用得多，读的人至少知道这一列不是零，而是这周没取到，下周会补上对比。失败不扣费的规则和退款怎么核对，见我们的失败退款对账。

脚本长什么样：agent 应该交回的 workflow

agent 交回的 PR 里至少应该有两个文件。下面是 workflow 的配置示例，几个关键点都来自 GitHub Actions 的文档：schedule 默认按 UTC，现在可以用 timezone 写 IANA 时区；最短间隔 5 分钟；整点前后负载高时定时任务可能延迟，负载特别高时排队的任务可能被丢掉，所以文档建议别卡在整点；定时任务只在默认分支上跑；公开仓库 60 天没有活动会被自动停用（触发 workflow 的事件文档，schedule 一节）。cron 的五个字段遵循 POSIX crontab 规范。

name: weekly-competitor-social-report
on:
  schedule:
    - cron: "17 9 * * 1"          # 周一 09:17，避开整点
      timezone: "Asia/Singapore"
  workflow_dispatch: {}
permissions:
  contents: write
concurrency: weekly-report
jobs:
  report:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Build report
        env:
          EVERYINFRA_API_KEY: ${{ secrets.EVERYINFRA_API_KEY }}
        run: python weekly_report.py --config config/competitors.yml --out reports/
      - name: Commit report
        run: |
          git config user.name "weekly-report-bot"
          git config user.email "weekly-report-bot@users.noreply.github.com"
          git add reports/
          git commit -m "weekly social report" || echo "nothing to commit"
          git push

脚本的核心只有一个函数：提交一个请求，遇到 status: running 就按 job_id 轮询，遇到 503 按 retry_after 等一次再试，最后返回结果列表或一个「未取到」的标记。下面是我们按本文实测写的骨架，变量名和字段名都和目录 response_fields 对得上，可以直接放进 issue 当参考：

import os, time, json, urllib.request, urllib.error

API = "https://api.everyinfra.com"
KEY = os.environ["EVERYINFRA_API_KEY"]          # 只从环境变量读

def call(platform, action, params, mode="sync"):
    body = {"platform": platform, "action": action, "params": params}
    if mode == "async":
        body["mode"] = "async"
    for attempt in (1, 2):
        req = urllib.request.Request(API + "/api/v1/social", json.dumps(body).encode(),
              {"Authorization": "Bearer " + KEY, "Content-Type": "application/json",
               "User-Agent": "weekly-report/1.0"})
        try:
            data = json.load(urllib.request.urlopen(req, timeout=100))
        except urllib.error.HTTPError as e:
            err = json.load(e).get("error", {})
            if e.code == 503 and attempt == 1:
                time.sleep(err.get("retry_after", 60)); continue
            return {"unavailable": True, "code": e.code, "reason": err.get("code")}
        while data.get("status") in ("submitting", "running", "finalizing"):
            time.sleep(8)
            job = urllib.request.Request(f"{API}/api/v1/jobs/{data['job_id']}",
                  headers={"Authorization": "Bearer " + KEY, "User-Agent": "weekly-report/1.0"})
            data = json.load(urllib.request.urlopen(job, timeout=60))
        if data.get("status", "succeeded") != "succeeded":   # 任务失败：明确标记，不当成 0 条
            return {"unavailable": True, "status": data.get("status"), "reason": data.get("error")}
        if "results" not in data:                              # 成功却没有 results：直接报错
            raise RuntimeError(f"no results field: {platform}/{action}")
        return {"rows": data["results"], "count": len(data["results"])}

注意请求头里那行 User-Agent。Python 标准库默认的 UA 会被一部分站点的防护规则拦下，显式写一个，省得在 Actions 日志里排查一个莫名其妙的 403。另外 timeout=100 比服务器的 85 秒同步上限略长，这样超时时你收到的是服务器的 503 和它的 retry_after，而不是客户端自己断开。最后两个判断最要紧：异步任务的 status 只要不是 succeeded，函数就返回 unavailable 标记，周报写「本周未取到」；任务成功了却没有 results 字段，就直接抛错让 Actions 这一步变红。只有真正成功且 results 为空时，周报才会写「本周 0 条」。少了这两步，服务失败会被写成「竞品本周停更」，正好是周报最不该出的错。

审 PR 时看这五处，不用逐行读

agent 交回 PR 以后，你不需要逐行读 Python。我们建议只看五处，每一处都能在几分钟内确认。第一，workflow 里 secrets.EVERYINFRA_API_KEY 只出现在取数那一步的 env 里，没有被 echo 出来，也没有写进任何文件；GitHub 会把密钥值在日志里打码，但写进提交的文件不会被打码（在 Actions 中使用密钥的文档）。第二，tests/fixtures/ 里的样例 JSON 是 agent 用 MCP 真调存下来的，打开看一眼，字段名应该和本文的字段表一致；如果样例是 agent 自己编的，测试就只是在复述它自己的代码。

第三，验收例子是否真的写成了测试：ClickUp 的 TikTok 本周条数等于 4、播放合计等于 60463，这两个数来自真调返回，agent 改不了它们，只能让代码去对上。第四，失败分支是否齐全：503 等一次再试、status: failed 记「未取到」、0 条记「待核账号」、422 不重试，四条缺一条就打回去。第五，PR 上的 workflow 默认要你点「Approve and run workflows」才会跑，先用 workflow_dispatch 手动跑一次，看 Actions 日志里每次调用的耗时和扣费，再合并。我们这边每次调用的扣费也能在控制台的调用记录里逐条对上，失败的那几次应该显示为未扣费。

每周、每月接口费：按目录价算

钱分两部分：EveryInfra 的接口费和 GitHub 一侧的费用。我们的接口费按目录里每项能力的 price_usd 算，这几项都是按次计费，一次调用返回 1 条还是 30 条价格一样，失败和空结果不扣。价格在 EveryInfra 定价页也能查到。

3 个品牌每周 $0.011961，一个月按 52 ÷ 12 周算约 $0.0518。规模放大以后也不大：10 个品牌每月约 $0.1728，30 个品牌约 $0.5183，100 个品牌约 $1.7277。本周按正确账号实跑的花费更低：YouTube 有 2 次有数据（Asana 的一次是空结果退款），TikTok 和 Instagram 各 3 次，LinkedIn 3 次都 503 没扣，合计 8 次、$0.004448。

GitHub 一侧有三笔，前两笔是确定的，第三笔我们只能给范围。第一笔是 Actions 分钟：公开仓库用标准 GitHub 托管运行器不收费；私有仓库从你套餐里每月包含的计算额度里扣，GitHub Free 每月包含 $12、GitHub Pro 和 Team 是 $18，标准 Linux 运行器每分钟 $0.006（GitHub Actions 计费文档）。按本次实测耗时，3 个品牌 12 次调用顺序执行约 5 分钟，私有仓库每周约 $0.03；改成先一起提交异步任务再统一轮询，能压到一两分钟。第二笔是 Copilot 订阅本身，例如 Copilot Pro 每月 $10、含 1,500 个 AI credits，Pro+ 每月 $39、含 7,000 个（Copilot 套餐文档）。第三笔是 agent 写脚本那一次消耗的 AI credits，取决于模型和会话长短，文档没有给典型值，我们也没有在 Copilot 里跑过，所以不编数字；你可以在 Copilot 的用量页面看到实际值。

字段：四个平台回来的东西不一样

周报要横着比四个平台，最麻烦的是字段不齐。目录里每项能力都列了 response_fields，我们把真实返回逐条对了一遍，发现三处差异会直接影响周报的列。第一，Instagram 的 user_posts 当晚 5 个账号共 50 条结果里都没有 view_count；目录的 field_note 也说明，Instagram 的部分请求不返回 view_count、is_comments_disabled、author_follower_count 和 top_comments，这类请求最多回 48 条。所以 Instagram 一列只能比点赞和评论，不能比播放。第二，YouTube 的 user_posts 在目录里列了 25 个字段，但按频道取列表时实测只回 14 个：有 view_count、title、duration，没有 like_count、comment_count 和 is_paid_partnership，posted_at 是相对时间。第三，TikTok 的 user_videos 有 35 个字段，信息最全，也最占地方。

这张表也是 issue 的一部分。与其让 agent 自己去猜每个平台有没有播放量，不如直接告诉它：Instagram 和 LinkedIn 的「播放」列写「—」，周报里按「互动 = 点赞 + 评论」比。agent 读真实返回时会自己发现大部分差异，但把结论写进 issue，等于给了它一份不用推理的对照表。

和 Claude Code、ChatGPT 定时任务那两篇有什么不同

站内已经有几篇相近的文章，这里说清楚区别，免得你读了两遍一样的东西。Claude Code 子代理并行拉 TikTok 品牌号讲的是一次性拉几十个账号、用子代理把原始数据挡在主会话外面，重点是上下文和并发；ChatGPT 定时任务做每周需求雷达讲的是每周让 ChatGPT 自己调 MCP、自己写报告，重点是取数要先点确认、每周花多少；Codex Cloud 评论周报讲的是一次调用能盖多长时间、取数频率怎么定；ChatGPT Spaces 竞品社媒追踪讲的是追踪页不会自己更新。

本文和它们最大的不同是：AI 只在写代码时用一次，之后每周跑的是一段普通代码。这样做的好处是周报格式稳定、每周没有模型费、出错时看 Actions 日志就能定位；代价是你要审一次 PR，并且在品牌或平台变化时改配置文件。如果你的周报需要每周写判断性的分析，比如「这条视频为什么火」，那更适合 ChatGPT 那篇的做法，或者在脚本出数以后再让 Copilot 读几周的 Markdown 写分析。

为什么不直接用各平台的官方接口

一个合理的问题是：四个平台都有自己的开发者接口，为什么还要经过 EveryInfra？答案在于「看别人家的公开内容」这件事，在各平台官方接口里门槛都不低。下表的每一条都来自平台自己的开发者文档。

YouTube 的官方接口其实很适合做周报的一部分，如果你只看 YouTube，直接用它就行。四个平台合在一起，就要维护四套认证、四种额度和四种返回格式，agent 写出来的脚本也会长出四个分支。EveryInfra 的作用是把四种返回统一成同一种请求格式、同一种计费和同一套错误码，脚本里只有一个 call() 函数。四个平台各自还能取什么，见 YouTube 数据接口、TikTok 数据接口、Instagram 数据接口和 LinkedIn 数据接口；LinkedIn 公司动态暂时不可用时，可以先用 LinkedIn 公司主页拿关注人数做替代列。

做不了或要注意的地方

第一是提示注入。周报读的是竞品发的帖子正文，这些文字会经 MCP 进到 agent 的上下文里。OWASP 把「模型从网页、文件这类外部来源读到的内容改变了它的行为」列为间接提示注入（OWASP LLM01 提示注入）。GitHub 的风险文档说它会过滤 issue 和评论里的隐藏字符，比如 HTML 注释不会传给 agent（cloud agent 风险与缓解），但 MCP 工具返回的帖子正文不在这个过滤范围的描述里。本文的做法本身就降低了风险：agent 只在写代码时读几条样例，每周的周报由脚本生成，脚本不会把帖子正文当指令执行。白名单只放三个工具，也让被注入的 agent 能做的事很有限。

第二是 agent 的权限边界。文档写明，cloud agent 只能推到它自己的 copilot/ 分支，开的 PR 必须由人审核合并，它不能把 PR 标成可审核、不能批准或合并；PR 上的 workflow 默认要有写权限的人点「Approve and run workflows」才会跑（cloud agent 风险与缓解）。这意味着 agent 写的 workflow 在你审完之前不会真的去扣你的接口费。

第三是 Actions 的定时任务不是准点闹钟。文档写明整点前后可能延迟，负载特别高时可能被丢掉；所以周报的取数窗口要按「上周一到上周日」算，不要按「运行时刻往前 7 天」算，否则延迟一小时就会少一小时的数据。公开仓库 60 天没有活动会停用定时任务，周报每周往仓库里提交一次 Markdown，正好算活动。

第四是我们这边的边界。我们只取公开内容：品牌公开账号的帖子、视频、互动数。私密账号、广告投放数据、粉丝画像都取不到。当晚 LinkedIn 公司动态不可用，就是一个真实的例子：脚本要能接住，周报要写明。最后，GitHub 和 EveryInfra 之间没有任何合作关系，本文只是用 GitHub 公开的 MCP 配置方式接入我们的公开接口。

最近的变化

2026-10-28：GitHub 推出 GitHub-verified MCP 服务器（连接器），首批 26 个服务，公开预览，所有 Copilot 套餐逐步开放（更新日志，社区讨论）。对读者的意思：Slack、Notion 这类服务有了一键连接，但第三方数据服务仍要自己配仓库 MCP，而且连接器暂时不能用在 Actions 会话里。

2026-10-28：Copilot Automations 支持接自定义 MCP 服务器的工具，新增 24 个 GitHub 事件触发器、20 个 GitHub 工具和按次、按天、按周、按月的 AI credits 上限（更新日志）；同日共享 automations 开始推出，费用记在仓库所有者名下（共享 automations 更新日志），VS Code 也能管理云端 automations（VS Code automations 更新日志）。对读者的意思：「每周让 Copilot 自己跑」这条路现在可行了，但每次运行都花 credits，先设好上限。

2026-10-28：Copilot 改为一个连在一起的云端体验，会话默认跑在云端沙箱，Actions 的包含额度改成按美元计的共享池，同时覆盖运行器和云端沙箱（更新日志）。对读者的意思：周报脚本的 Actions 分钟和 agent 的沙箱时间从同一个池子里扣，私有仓库要留意总量。

2026-10-28：GitHub Agentic Workflows 正式发布，用 Markdown 写任务、编译成 Actions YAML，可选 Copilot 或其他编码 agent（更新日志，项目主页）；同日 Actions workflow 锁文件正式发布，可以把 actions/checkout 这类依赖锁到具体提交（锁文件更新日志）。对读者的意思：周报 workflow 里引用的 action 可以锁版本，防止依赖被悄悄换掉。

2026-10-22：Copilot 用量指标接口开始按名字列出组织自定义的 MCP 服务器、技能和自定义 agent，每类最多 25 条（更新日志）。对读者的意思：组织管理员能看到 everyinfra 这个 MCP 服务器到底有没有人在用。

2026-10-13：secret scanning 把 Anthropic 的两种密钥加进推送保护的默认拦截（更新日志）。对读者的意思：已知格式的密钥会被拦，但 EveryInfra 的 Key 不在名单里，仍然要靠 Agents secret 和 Actions secret 两个抽屉管住。

常见问题

github copilot mcp configuration 写在哪？和 mcp.json 是一回事吗？

不是一回事。给 cloud agent 和 code review 用的配置写在 GitHub 网页上，仓库的 Settings → Copilot → MCP servers，是一个 mcpServers 对象，每个服务器必须有 type 和 tools。VS Code 本地用的是仓库里的 .vscode/mcp.json 或个人设置，GitHub 文档专门写了从 VS Code 配置改过来要做的四处修改，比如补上 tools、把 inputs 换成 env。（问题来源：Google 联想词「github copilot mcp configuration」「github copilot mcp.json」；依据：仓库 MCP 配置文档、VS Code MCP 文档）

copilot coding agent mcp server 能用远程 HTTP 服务器吗？

能。type 可以是 local、stdio、http 或 sse，远程服务器写 url 和 headers。限制是：仓库配置里的远程服务器如果用 OAuth 认证，cloud agent 和 code review 目前不支持；用请求头里的密钥认证没问题。EveryInfra 用的是 Bearer 密钥。（问题来源：联想词「copilot coding agent mcp server」「github copilot coding agent mcp configuration」；依据：仓库 MCP 配置文档）

coding agent 里 MCP 的 token 应该放哪？

放在仓库或组织的 Agents secrets 里，名字以 COPILOT_MCP_ 开头，再在配置里用 $COPILOT_MCP_名字 引用。这类密钥只交给 MCP 服务器。Reddit 上有用户问在 coding agent 里配 Atlassian 时 token 放哪，回答也是把 COPILOT_MCP_ 前缀的密钥设成仓库密钥，而不是直接写进配置字符串。（问题来源：r/GithubCopilot 讨论帖；依据：cloud agent 密钥与变量文档）

日志里显示 MCP 连上了，但 retrieved 0 tools，怎么办？

先看 tools 白名单里的名字是否和服务器 tools/list 返回的完全一致；再看服务器是否只有 resources 或 prompts，cloud agent 只用工具。对 EveryInfra，可以不带密钥 POST 一次 tools/list 看到全部 12 个工具名。（问题来源：r/GithubCopilot 讨论帖；依据：仓库 MCP 配置文档的验证一节、本文 00:16 的实测）

github copilot mcp allowlist 会挡住自己配的 MCP 服务器吗？

可能会。连接器文档列了几条会影响 MCP 的策略：组织或企业关掉「MCP servers in Copilot」时所有 MCP 都不能用；「Restrict MCP access to registry servers」设成只允许注册表时，执行这条策略的客户端会挡住连接器；企业定义了 allowedMcpServers 白名单时，要把对应地址加进去。自配的服务器在你的组织里能不能用，先问管理员这几条怎么设。（问题来源：联想词「github copilot mcp allowlist」「github copilot mcp registry」；依据：Copilot connectors 文档）

每周让 Copilot automations 直接跑，和 Actions 脚本比哪个划算？

只看钱，Actions 脚本每周的 AI credits 是 0，接口费 3 个品牌每周 $0.011961；automations 每次运行都要花 AI credits，单次上限最低能设 30 credits，也就是 $0.30，而且只能用在私有或 internal 仓库。需要每周写分析时 automations 更方便，只要出数时脚本更省。（问题来源：本文实测与联想词「copilot coding agent mcp」；依据：automations 文档、创建 automations 文档）

上手

1. 在 EveryInfra 控制台建两把 Key，分别叫「copilot-mcp」和「weekly-actions」，步骤见快速上手。
2. 仓库 Settings → Secrets and variables → Agents 加 COPILOT_MCP_EVERYINFRA_API_KEY；Actions 下加 EVERYINFRA_API_KEY。
3. Settings → Copilot → MCP servers 粘贴本文的 JSON，只放三个工具；MCP 的其他接法见 EveryInfra MCP 说明。
4. 按本文的模板开 issue，指派给 Copilot，审 PR 时先跑一次 workflow_dispatch。

参考资料

1. Connect your tools to Copilot without all the setup，GitHub Changelog，2026-10-28，https://github.blog/changelog/2026-10-28-connect-your-tools-to-copilot-without-all-the-setup
2. Copilot connectors，GitHub Docs，2026-11-06 读取，https://docs.github.com/copilot/concepts/customizations/copilot-connectors
3. Configure MCP servers for your repository，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers
4. Configure secrets and variables for Copilot cloud agent，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/configure-secrets-and-variables
5. Copilot automations，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/concepts/agent-capabilities/agent-powered-workflows-and-operations/about-automations
6. Creating automations with Copilot cloud agent，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/create-automations
7. GitHub Copilot on GitHub.com and GitHub Mobile（cloud agent 概览），GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent
8. Risks and mitigations for GitHub Copilot cloud agent，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/concepts/security-governance-and-network-settings/risks-and-mitigations
9. Customizing or disabling the firewall for GitHub Copilot，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-the-firewall
10. Best practices for using GitHub Copilot to work on tasks，GitHub Docs，2026-11-06 读取，https://docs.github.com/copilot/how-tos/agents/copilot-coding-agent/best-practices-for-using-copilot-to-work-on-tasks
11. Plans for GitHub Copilot，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/get-started/plans
12. Usage-based billing for individuals，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/concepts/billing-and-usage/individuals/billing
13. Events that trigger workflows（schedule），GitHub Docs，2026-11-06 读取，https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
14. GitHub Actions billing，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/billing/concepts/product-billing/github-actions
15. New tools, triggers, and cost controls for Copilot Automations，GitHub Changelog，2026-10-28，https://github.blog/changelog/2026-10-28-new-tools-triggers-and-cost-controls-for-copilot-automations
16. Build shared workflows for your team with Copilot Automations，GitHub Changelog，2026-10-28，https://github.blog/changelog/2026-10-28-build-shared-workflows-for-your-team-with-copilot-automations
17. Create and manage Copilot Automations in Visual Studio Code，GitHub Changelog，2026-10-28，https://github.blog/changelog/2026-10-28-create-and-manage-copilot-automations-in-visual-studio-code
18. Work from anywhere with a new, connected Copilot cloud experience，GitHub Changelog，2026-10-28，https://github.blog/changelog/2026-10-28-work-from-anywhere-with-a-new-connected-copilot-cloud-experience
19. GitHub Agentic Workflows generally available，GitHub Changelog，2026-10-28，https://github.blog/changelog/2026-10-28-github-agentic-workflows-generally-available
20. GitHub Actions workflow lockfiles are generally available，GitHub Changelog，2026-10-28，https://github.blog/changelog/2026-10-28-github-actions-workflow-lockfiles-are-generally-available
21. Push protection beyond predefined secret patterns，GitHub Changelog，2026-10-28，https://github.blog/changelog/2026-10-28-push-protection-beyond-predefined-secret-patterns
22. Custom skills, agents, and MCP servers in usage metrics API，GitHub Changelog，2026-10-22，https://github.blog/changelog/2026-10-22-custom-skills-agents-and-mcp-servers-in-usage-metrics-api
23. Secret scanning blocks Anthropic keys by default, adds Salesforce，GitHub Changelog，2026-10-13，https://github.blog/changelog/2026-10-13-secret-scanning-blocks-anthropic-keys-by-default-adds-salesforce
24. Connect your tools to Copilot without all the setup（社区讨论 #211002），GitHub Community，2026-10-28，https://github.com/orgs/community/discussions/211002
25. GitHub Agentic Workflows，GitHub Next，2026-11-06 读取，https://github.github.com/gh-aw/
26. Tools，Model Context Protocol 规范 2025-11-25，2026-11-06 读取，https://modelcontextprotocol.io/specification/2025-11-25/server/tools
27. Transports，Model Context Protocol 规范 2025-11-25，2026-11-06 读取，https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
28. crontab，The Open Group Base Specifications Issue 7，2018，https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html
29. LLM01:2025 Prompt Injection，OWASP GenAI Security Project，2026-11-06 读取，https://genai.owasp.org/llmrisk/llm01-prompt-injection/
30. Quota Calculator，YouTube Data API，Google for Developers，2026-11-06 读取，https://developers.google.com/youtube/data/determine_quota_cost
31. IG User Business Discovery，Meta for Developers，2026-11-06 读取，https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-user/business_discovery
32. TikTok Research Tools: Access and Eligibility，TikTok for Developers，2026-11-06 读取，https://developers.tiktok.com/products/research-api/
33. Community Management Overview，LinkedIn（Microsoft Learn），2026-11-06 读取，https://learn.microsoft.com/en-us/linkedin/marketing/community-management/community-management-overview
34. Add MCP servers in VS Code，Visual Studio Code 文档，2026-11-06 读取，https://code.visualstudio.com/docs/copilot/customization/mcp-servers
35. GitHub Copilot Code Agent: Retrieved 0 tools from MCP server，Reddit r/GithubCopilot，读取于 2026-11-06，https://www.reddit.com/r/GithubCopilot/comments/1lb0sjd/github_copilot_code_agent_retrieved_0_tools_from/
36. How to use MCP atlassian on Github coding agent，Reddit r/GithubCopilot，读取于 2026-11-06，https://www.reddit.com/r/GithubCopilot/comments/1ne73m1/how_to_use_mcp_atlassian_on_github_coding_agent/
37. EveryInfra 数据能力目录，EveryInfra，2026-11-06 00:16 读取，https://api.everyinfra.com/api/v1/social/catalog
38. GitHub Copilot supports server-to-server authentication，GitHub Changelog，2026-10-27，https://github.blog/changelog/2026-10-27-github-copilot-supports-server-to-server-authentication
39. Using secrets in GitHub Actions，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets
40. Configure the development environment for agents on GitHub Actions，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/customize-the-agent-environment
41. Copilot allowlist reference，GitHub Docs，2026-11-06 读取，https://docs.github.com/en/copilot/reference/copilot-allowlist-reference
42. github/github-mcp-server，GitHub，2026-11-06 读取，https://github.com/github/github-mcp-server