github-repo-intelligence-mcp

可维护性结论，而不是又一个仪表板。

GitHub Repo Health Check 是一个 MCP 服务，用来回答依赖列表无法回答的那个问题：这个仓库还在维护吗，还是我正在沙地上盖房子？ 最近提交日期会骗人，Star 数量也会骗人。单一信号不足以得出结论。因此，它会综合四个维度（活跃度、Issue、PR、贡献者），给出四种结论之一——维护活跃、活跃度放缓、存在风险 或 可能已弃用，并附上透明且可检查的阈值，说明结论是如何得出的。只需指定任意 owner/name（或 GitHub URL），Agent 就能获得可据以采取行动的结论，以及原始数据，准确了解原因。相同的仓库状态和配置，每次都会得出相同的结论。

它作为 Standby Actor 运行在 Apify 平台上，始终保持热启动，可通过 /mcp 路径使用 Streamable HTTP transport 访问，并包含 API 访问、定时调度和监控功能。

查看实际效果

两个仓库，两个截然不同的结论——接着深入查看背后的指标，全程通过 MCP 完成：

适用对象

• Agent 开发者：Agent 需要判断是否采用、推荐或监控某个开源库或工具
• 依赖尽职调查：在决定使用某个软件包之前，评估其上游项目是否仍在维护
• OSS 供应商评估：在基于某个项目构建之前，检查项目的健康状况
• 大规模仓库分诊：在人工审核之前，按健康状况对候选仓库列表排序
• 自动化监控：安排定期检查，并在依赖项目开始放缓时发出提醒

如果你曾问过“这个仓库是不是弃用了？”，或手动检查过 GitHub 仓库的健康状况，这个服务就能以编程方式按任意规模完成这项工作。

为什么使用 GitHub Repo Health Check？

大多数 GitHub 工具会向 Agent 提供原始 API 访问权限，把判断工作留给模型，导致每次调用都依赖不一致、临时编写的启发式规则。这个服务会替你完成综合分析。

它的差异化优势在于判断能力，而不是原始访问权限：每项结论都会附带生成该结论时使用的固定阈值和原始指标，方便 Agent（以及你）审查推理过程。相同的仓库状态和配置，始终会得出相同的结论。

每个仓库只会获取一次 GitHub 数据，并由全部五个工具共享缓存。要从总体结论深入查看某个具体维度，无需额外调用上游 API。

如何使用 GitHub Repo Health Check

1. 部署 Actor — 在 Apify 上以 Standby 模式运行。启动时无需输入任何内容。
2. 连接 MCP 客户端，通过 Streamable HTTP transport 连接到 Standby 端点（https://<your-standby-url>/mcp）。
3. 调用 get_repo_health 并传入 repo 参数（"owner/name" 或任意 https://github.com/owner/name URL），获取总体结论。
4. 添加 GitHub token — 实际上这是必需的。Actor 的主要数据源（GitHub 的 GraphQL API）会拒绝未经身份验证的请求，而 Apify 共享的出口 IP 几乎会立即耗尽 GitHub 的匿名配额。如果没有 token，Actor 返回的是速率限制错误，而不是结论。请参阅输入了解设置方法。
5. 深入查看各个维度 — 需要了解总体结论以外的详细信息时，可调用 get_activity_metrics、get_issue_health、get_pr_health 或 get_contributor_insights。五个工具都会读取同一份缓存数据。

五个工具

所有工具都只接受一个 repo 参数——可以是 "owner/name"，也可以是任意 https://github.com/owner/name[/...] URL（不区分大小写）。

get_repo_health — 总体结论

返回总体结论、各维度的详细分析，以及解释最差维度的理由说明。

{
  "repo": "honojs/hono",
  "overallVerdict": "Actively maintained",
  "dimensions": {
    "activity":     { "verdict": "Healthy", "lastCommitDaysAgo": 1, "commits90d": 412 },
    "issues":       { "verdict": "Healthy", "medianFirstResponseDays": 2.4, "staleOpenRatio": 0.12 },
    "pullRequests": { "verdict": "Healthy", "mergeRate": 0.88, "oldestOpenPrDaysAgo": 14 },
    "contributors": { "verdict": "Healthy", "totalContributors": 312, "busFactorFlag": false }
  },
  "rationale": "Overall: activity is Healthy; weakest dimension is issues (Healthy).",
  "stars": 21000,
  "forks": 640,
  "fetchedAt": "2026-06-01T00:00:00.000Z",
  "authenticated": true
}

get_activity_metrics — 提交频率与活跃势头

过去一段时间内的提交量、发布频率和势头趋势。

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "lastCommitDaysAgo": 1,
  "commits30d": 140,
  "commits90d": 412,
  "commits365d": 1680,
  "releaseCount365d": 48,
  "lastReleaseDaysAgo": 3,
  "momentumTrend": "steady",
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

momentumTrend 为 accelerating / steady / declining，根据 30 天提交速率与 90 天提交速率得出。通过打标签而非创建 GitHub Releases 的仓库会显示 releaseCount365d: 0 和 lastReleaseDaysAgo: null——这本身不会降低评估结果。

get_issue_health — 响应速度与待处理问题管理

维护者响应问题的速度，以及待处理问题中有多少已经过时。

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "openIssues": 32,
  "closedIssues": 1840,
  "openClosedRatio": 0.017,
  "medianFirstResponseDays": 2.4,
  "medianTimeToCloseDays": 5.1,
  "staleOpenIssues": 4,
  "staleOpenRatio": 0.12,
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

如果问题超过 90 天未有更新，则视为过时。分析时间范围内没有符合条件的事件时，中位数为 null——无数据不等于零。

get_pr_health — PR 处理效率与队列时长

项目合并或关闭贡献的效率，以及最早的未关闭 PR 已存在多久。

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "openPrs": 6,
  "mergedPrs": 220,
  "closedUnmergedPrs": 30,
  "mergeRate": 0.88,
  "medianTimeToMergeDays": 1.2,
  "oldestOpenPrDaysAgo": 14,
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

mergeRate 的分母不包括仍处于开放状态的 PR。分析时间范围内没有已作出决定的 PR 时，该值为 null。

get_contributor_insights — 贡献者集中度与单点故障风险

项目有多少贡献者，以及提交活动是否危险地集中在少数人身上。

{
  "repo": "honojs/hono",
  "verdict": "Healthy",
  "totalContributors": 312,
  "topContributorShare": 0.28,
  "topTwoContributorShare": 0.41,
  "busFactorFlag": false,
  "fetchedAt": "2026-06-01T00:00:00.000Z"
}

当排名第一的贡献者拥有超过 50% 的提交，或前两名合计拥有超过 80% 的提交时，busFactorFlag 为 true。totalContributors 是仓库的全部历史贡献者数量（数据来自 GitHub 稳定的 /contributors 列表端点）——不是近 90 天活跃贡献者数量。

评估阈值

评估结果基于固定且透明的阈值——同一仓库状态和相同配置始终会得出相同结果。

维度	Healthy	Moderate	At-Risk	备注
活跃度	最近一次提交 ≤ 30 天	30–180 天	180–365 天	超过 365 天则为 Likely abandoned
问题	首次响应中位数 ≤ 7 天 且 staleOpenRatio ≤ 0.40	≤ 30 天 且 ≤ 0.60	其他情况	中位数为 null 时，仅根据 staleOpenRatio 判断
拉取请求	mergeRate ≥ 0.60 且最早的未关闭 PR ≤ 30 天	mergeRate ≥ 0.30 或最早的未关闭 PR ≤ 90 天	其他情况	mergeRate 为 null 时，仅根据最早的未关闭 PR 判断
贡献者	totalContributors ≥ 3 且不存在单点故障风险	1–2 名贡献者，或 ≥ 3 名但存在单点故障风险	0 名贡献者	只有一名活跃维护者 → 最高为 Moderate

总体评估结果以活跃度为主导，自上而下评估（命中首项即停止）：

1. 很可能已弃用 — 活跃度为 Likely abandoned（超过 365 天没有提交）。
2. 有风险 — 活跃度为 At-Risk，或问题、PR、贡献者三项中任意两项为 At-Risk。
3. 积极维护中 — 活跃度为 Healthy，且没有任何维度为 At-Risk。
4. 活跃度放缓 — 其他所有情况（例如活跃度为 Moderate，或活跃度为 Healthy 但有一个维度为 At-Risk）。

输入

服务启动时无需任何输入（这是 Standby 的限制——架构中的所有字段都是可选的，因此容器不会在启动时陷入反复崩溃重启）。实际上，你必须提供 GitHub 令牌，才能让 Actor 返回判定结果，而不是返回速率限制错误。

字段	类型	默认值	描述
githubToken	string（密钥）	—	实际上必填。 GitHub 的 GraphQL API（此 Actor 的主要数据源）会拒绝未经身份验证的请求；而在 Apify 的共享 IP 上，匿名 REST 配额（每个 IP 约 60 次请求/小时）通常已被其他流量耗尽。令牌可提供 5,000 次请求/小时的额度，并支持分析私有仓库。
cacheTtlMinutes	integer	20	重新获取前，复用仓库已获取数据的时长。数值越低，数据越新；数值越高，GitHub API 调用越少。
analysisWindowDays	integer	90	用于衡量 issue 和 PR 活动的回溯窗口（30–365 天）。

GitHub 令牌设置。 对于公开仓库，无需任何权限范围的 classic 令牌即可满足要求。用于分析私有仓库时，可使用限定到特定仓库的 fine-grained 令牌。对于 Standby 部署，建议在 Actor 上设置 GITHUB_TOKEN 环境变量（以密钥形式存储），而不是将令牌粘贴到输入字段中——这样令牌会在重启后保留。两种方式都可用；令牌都会作为密钥存储，且绝不会出现在日志中。

输出

每个工具都会返回一个结构化 JSON 对象（如各工具对应章节所示）。响应具有确定性——相同的仓库状态和配置始终会产生相同的判定结果。每个响应都包含一个 fetchedAt 时间戳，表示底层 GitHub 数据的获取时间。在该 TTL 时段内读取缓存时，返回的时间戳与原始获取时间相同。

数据字段参考

字段	含义
overallVerdict	总体结论：维护活跃／维护放缓／存在风险／可能已被弃用
lastCommitDaysAgo	距最近一次提交的天数；如果未找到提交，则为 null
commits30d / commits90d / commits365d	过去 30、90 和 365 天内的提交次数
momentumTrend	提交速率是在加快、保持稳定还是下降（比较 30 天与 90 天的速率）
medianFirstResponseDays	维护者首次响应新 issue 的中位时间（天）
staleOpenRatio	开放 issue 中超过 90 天没有活动的占比
mergeRate	已合并 PR ÷（已合并 PR + 已关闭但未合并的 PR）——不包含仍处于开放状态的 PR
oldestOpenPrDaysAgo	仍处于开放状态的最早 PR 的存在天数
totalContributors	全部时间的贡献者数量（不是过去 90 天内活跃的贡献者数量——参见常见问题）
busFactorFlag	当提交活动危险地集中在 1–2 人身上时为 true

定价

此 Actor 在 Standby 模式下运行，按预热并处理请求期间使用的计算资源计费。健康状况查询开销很小——每个仓库的 GitHub 数据只获取一次并缓存（默认 20 分钟），供所有五个工具共享。针对同一仓库查询多个维度只需获取一次上游数据。

实际上需要 GitHub 令牌（参见输入），且不会产生额外的 Apify 费用。

提示

• 从 get_repo_health 开始，查看总体判定结果；只有在需要详细信息时才调用维度工具——它们都会共享同一份缓存数据。
• 批量筛查一长串仓库时，提高 cacheTtlMinutes，以尽量减少 GitHub API 调用。需要获取最新数据时，则降低该值。
• 在 Actor 上将 GITHUB_TOKEN 设为环境变量，而不是填写在输入字段中——这样令牌会在 Standby 重启后保留，无需重新提供输入。
• 调整 analysisWindowDays（30–365），以匹配你对 issue 和 PR 信号时效性的需求。较短的窗口能反映近期趋势；较长的窗口则会基于更稳定的基准进行平均。

工作原理

1. MCP 客户端发送一个工具调用（例如 get_repo_health），并附带 repo 参数。
2. 服务检查内存中的 LRU 缓存。若未命中，则向 GitHub API 发送一个 GraphQL 查询（另加一次用于获取贡献者数据的 REST 调用），并缓存原始负载。
3. 纯指标计算函数根据负载计算计数、中位数和比率，不会再进行网络调用。
4. 判定函数将每项指标与 config.ts 中固定的阈值进行比较，并返回一个维度判定。
5. 总体判定根据上述活动优先规则，由四个维度判定组合而成。
6. 完整结果——判定、各维度明细、原始指标和 fetchedAt——将返回给 MCP 客户端。

所有五种工具共享步骤 2 中缓存的负载。判定逻辑具有确定性，并注入时钟（无需网络即可测试）。

配合使用效果良好

这是面向 Agent 的一小组 Apify Actors 的一部分：

• SERP Topic Gap Monitor — 查找搜索结果覆盖中的主题空白，并生成带评分的空白报告。
• Changelog Triage Agent — 监控各项服务的产品更新日志，将每条新内容分类为 BREAKING / WARNING / INFO，并提供去重后的分诊报告，帮助团队在弃用造成影响之前及时发现。
• Docs MCP Server — 一个 MCP 服务，让 AI 助手可以查询框架文档（Next.js、React、Tailwind、TypeScript、Prisma）。

常见问题与支持

它能用于私有代码仓库吗？ 可以——提供一个具有代码仓库读取权限的 githubToken。

判定是否主观或可配置？ 不是。每项判定都基于上述固定阈值。同一代码仓库状态始终会得出相同判定。同时还会返回原始指标，方便你审查每次调用。

为什么 totalContributors 不是过去 90 天内活跃的贡献者数量？ GitHub 按周期统计贡献者的端点（/stats/contributors）在缓存未命中时并不可靠——它会返回 202，而且很少能在一次请求周期内完成缓存预热。因此，贡献者数据取自稳定的全时段 /contributors 列表。该字段反映的是代码仓库整个生命周期的贡献者广度，而非近期活动。

rationale 字段包含什么？ 该字段会说明活动判定和非活动维度中最弱的一项，例如 "Overall: activity is Healthy; weakest dimension is issues (Moderate)."。它适用于 Agent 日志和人工审计记录，而非面向用户的文案。

Actor 返回了速率限制错误——我该怎么办？ 添加 GitHub 令牌。请参阅输入。无需任何作用域的经典令牌可免费获取，在 github.com/settings/tokens 创建只需不到一分钟。

发现错误或想要新功能？ 在 Actor 的 Issues 选项卡中提交 issue。也可按需提供定制版本。

许可证

版权所有 © 2026 Joe Slade。

根据 GNU Affero 通用公共许可证 v3.0（AGPL-3.0）授权。你可以自由使用、研究、修改和自托管此软件；如果你将修改后的版本作为网络服务运行，AGPL 要求你以相同许可证向用户提供修改后的源代码。如需不受 AGPL 网络著佐权条款约束的商业许可证，请联系作者。