agents-radar 评测：一个用 GitHub Actions 自动生成中英双语 AI 日报的流水线
该项目围绕「Daily AI ecosystem digest from 10 sources (GitHub, ArXiv, HN, HuggingFace, Product Hunt, Dev.to, Lobste.rs). Bilingual ZH/EN reports via GitHub Actions.」构建，适用于实际场景的开源实践，提供可复用的工具链与集成方式。
秒懂
- 它是什么？
- agents-radar 是一个基于 GitHub Actions 的自动化项目，每天从 10 个数据源聚合 AI 生态信号，生成中英双语日报并发布为 Issue、Markdown 文件、RSS 和 MCP 工具。本文拆解它的工作机制、部署方式与适用边界。
- 适合谁用？
- agents-radar 适合两类人：一是想省去手动浏览 10 个信息源、需要一个每日 AI 摘要的工程师或研究者；二是想在自己的项目里复用这套 GitHub Actions 采集流程的开发者。不适合的是那些需要深度分析或定制排序规则的人，因为报告是固定模板，且 Hugging Face 数据每周才更新一次。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是信息过载，不是信息缺失
AI 领域每天产生的信号分散在 GitHub、ArXiv、Hacker News、Product Hunt 等至少 10 个平台。一个工程师如果手动跟踪这些源，每天要花掉一两个小时，而且很容易漏掉某个仓库的 release 或某篇论文。agents-radar 把这件事自动化了：每天早上 07:00 CST，一个 GitHub Actions 工作流会跑一遍，抓取数据，生成中英双语的日报，然后发布成 GitHub Issue 和 Markdown 文件。它的目标用户很明确：需要每日 AI 生态概览，但不想自己写爬虫的人。注意，它不是一个实时监控工具，而是一个每日摘要器，时效性以天为单位，不是分钟级。
数据流：十个源，四种抓取方式
agents-radar 的采集逻辑不是统一的。GitHub 部分走 API，拉取 18 个 AI 工具仓库的 Issue、PR 和 release；Claude Code Skills 走 anthropics/skills 仓库，按评论数排序，不设日期过滤，这意味着它反映的是讨论热度而非新近度。Hacker News 用 Algolia API 发 6 个并行查询，取最近 24 小时的前 30 条 AI 故事。Product Hunt 用 GraphQL API 拿昨天的投票最高产品。ArXiv 用官方 API 拉 cs.AI、cs.CL、cs.LG 三个分类最近 48 小时的论文。Hugging Face 比较特殊，它每周一才更新一次，取 30 个按周点赞数排序的模型。Anthropic 和 OpenAI 的新闻则通过 sitemap 的 lastmod 字段做差异检测。这种混合设计意味着不同源的数据新鲜度不一致，日报里 ArXiv 的论文可能是两天前的，而 GitHub 的 release 是当天的。
输出形态：Issue、Markdown、RSS 和 MCP
生成的报告有四种消费方式。第一，GitHub Issue，适合在 GitHub 上直接浏览。第二，仓库内的 Markdown 文件，这些文件被 GitHub Pages 渲染成网页，地址是 https://duanyytop.github.io/agents-radar，深色主题，无需登录。第三，RSS feed，地址是 https://duanyytop.github.io/agents-radar/feed.xml，包含最近 30 条报告，每天随 manifest.json 更新。第四，一个托管的 MCP 服务器，地址是 https://agents-radar-mcp.duanyytop.workers.dev，暴露了四个工具：list_reports、get_latest、get_report、search。MCP 是 Model Context Protocol 的缩写，任何兼容的客户端，比如 Claude Desktop 或 OpenClaw，都可以通过 JSON 配置直接调用。这个设计把日报从静态内容变成了可查询的数据源，是它区别于其他 RSS 聚合器的地方。
部署与配置：从 fork 到自托管
如果你不想依赖作者托管的 MCP 服务器，可以自己部署。README 给出了 MCP 服务器的部署方式：进入 mcp/ 目录，运行 pnpm install，然后 wrangler deploy。这是一个 Cloudflare Worker，部署后你就有了自己的 MCP 端点。但注意，README 没有说明如何配置数据源列表，只提到 config.yml 中标记了 discussions: true 的仓库（如 Codex 和 Pi）会额外拉取 GitHub Discussions。如果你想修改追踪的仓库列表，需要自己查看 config.yml 的结构。对于 Claude Desktop，配置方法是编辑 ~/Library/Application Support/Claude/claude_desktop_config.json，加入 mcpServers 字段。对于 OpenClaw，可以用命令行 openclaw mcp add --transport http agents-radar <url>。整个过程不涉及复杂的服务器运维，但要求你熟悉 Cloudflare Workers 的部署流程。
局限一：数据源的硬编码与更新频率
agents-radar 的追踪列表是固定的。18 个 AI 工具仓库、5 个 agent 生态项目、5 个基础设施项目，这些都在 README 里列出来了。如果你想追踪某个不在列表里的仓库，必须修改代码或配置。另外，Hugging Face 的模型趋势每周只更新一次，这意味着周中的日报里这一部分数据是重复的。ArXiv 的论文窗口是 48 小时，但 GitHub 的 release 是当天的，所以日报里不同部分的时效性差异明显。如果你需要分钟级或小时级的监控，这个工具不合适。它适合的是每天看一次摘要的场景。
局限二：第三方托管服务的可靠性
MCP 服务器托管在 Cloudflare Workers 上，域名是 agents-radar-mcp.duanyytop.workers.dev。这是一个个人项目，没有 SLA 承诺。如果作者停止维护，或者 Workers 免费额度耗尽，这个端点可能会失效。对于依赖 MCP 的 Claude Desktop 用户来说，这意味着你的工作流会突然断掉。解决办法是自托管，但自托管需要你维护一个 Cloudflare 账户和 wrangler 部署流程。另外，RSS feed 和 GitHub Pages 都依赖 GitHub 仓库的更新，如果 GitHub Actions 因为 API 限流或网络问题失败，当天的报告就不会生成。README 没有提到失败重试机制，所以这是一个潜在的单点故障。
替代方案：自己写脚本 vs. 现成 RSS 聚合器
agents-radar 的替代方案有两类。第一类是通用 RSS 聚合器，比如 Feedly 或 NewsBlur。这些工具可以订阅 GitHub releases、ArXiv 和 Hacker News 的 RSS 源，但它们的输出是原始链接列表，没有中英双语，也没有跨源的数据整合。第二类是自建脚本，用 Python 或 Node.js 分别调用各个 API，然后自己生成 Markdown。这种方式灵活，但你需要处理 API 认证、限流、数据去重和翻译，工作量远大于 fork 这个项目。agents-radar 的价值在于它把采集、翻译、发布和查询封装成了一个完整的包，你只需要改配置。但如果你需要深度定制，比如调整排序算法或增加新的数据源，自建脚本可能更合适。
维护成本与许可证
agents-radar 使用 MIT 许可证，这意味着你可以自由使用、修改和分发，包括商用。但注意，MIT 许可证不包含对数据源的授权，你仍然需要遵守 GitHub、ArXiv、Hacker News 等平台的 API 使用条款。维护成本方面，这个项目依赖 GitHub Actions 的免费额度，以及 Cloudflare Workers 的免费额度。对于个人使用，这些额度通常足够，但如果你的仓库 fork 很多，或者 API 调用频繁，可能会超出限额。另外，数据源 API 的变动（比如 GitHub 的 rate limit 策略调整）会直接影响工作流的稳定性，你需要关注上游变化。README 没有提供升级路径或版本管理，所以你需要自行跟踪 master 分支的更新。
编辑结论
agents-radar 适合两类人：一是想省去手动浏览 10 个信息源、需要一个每日 AI 摘要的工程师或研究者；二是想在自己的项目里复用这套 GitHub Actions 采集流程的开发者。不适合的是那些需要深度分析或定制排序规则的人，因为报告是固定模板，且 Hugging Face 数据每周才更新一次。在采用前，建议先确认三件事：第一，检查 config.yml 中 18 个仓库的列表是否符合你的关注范围，因为它是硬编码的；第二，验证 MCP 服务器（https://agents-radar-mcp.duanyytop.workers.dev）的可用性和响应速度，因为它是第三方托管的，不保证 SLA；第三，如果打算自托管，确认 wrangler deploy 部署的 Worker 是否在你的 Cloudflare 账户配额内。这个项目最大的价值在于它把采集、翻译、发布和查询封装成了一条完整的流水线，但它的输出质量取决于上游 API 的稳定性，而这是你无法控制的。
社区笔记