我做了一个 Agent 赛事观测站：把散落的比赛结果，变成可搜索、可追溯的数据

木匠刘师傅
0 阅读9分钟

我做了一个 Agent 赛事观测站：把散落的比赛结果，变成可搜索、可追溯的数据

如果你认真找过 Agent、Skill 或 MCP 比赛的获奖名单，大概率遇到过这些问题：

  • 赛事很多，但结果分散在主办方官网、博客、活动页和 GitHub；
  • 有的比赛按总排名，有的按地区、赛道或专项奖，口径并不统一；
  • 项目 README 常写“获奖”或“入围”，却没有可以证明名次的官方来源；
  • 结果页会迁移、补发甚至下线，不记录核验时间，很难判断信息是否仍然有效；
  • 自动抓取容易把页面顺序、搜索摘要或参赛者自述误判成正式名次。

更麻烦的是，这些问题不能靠“再做一张 Top 10”解决。数据源本身不统一，强行排名只会让信息看起来更整齐，却离事实更远。

于是，我做了 Agent 赛事观测站（Podium Signal） 。

它不制造新的综合排行榜，而是把散落在官方页面里的赛果整理成一组可搜索、可筛选、可追溯、可以复查的数据坐标。

项目地址：

Agent 赛事观测站首页 image.png

先看当前的数据快照

截至 2026 年 9 月 4 日，页面展示的数据快照如下：

指标当前数量
已收录赛事11 场
获奖记录54 条
主办组织10 个
最近核验2026-09-04

收录范围包括中国大陆和全球赛事，涉及 Agent 应用、Agent Skill、MCP、多智能体、实时智能体和 Agent 原生 Web 等方向。

其中既有已经公布结果的赛事，也有仍在进行或等待开奖的比赛。后者不会生成一份“预测名单”，而是明确标记为待开奖。

这不是榜单，而是一层“证据索引”

项目有一个很重要的原则：

先锁定来源，再谈名次。

不同赛事的奖项结构并不等价。

例如，“第一名”可以安全地记录为数字名次；但“最佳实践奖”“地区优胜奖”或“荣誉提名”并不能被擅自塞进第一、第二、第三名。即使官方页面按某个顺序展示项目，只要没有明确说明排序含义，数据里就不会把页面顺序解释成名次。

观测站采用四级来源口径：

等级能否证明名次典型来源
A可以主办方官网或官方博客直接公布奖项与获奖者
B可以能确认主办方身份的官方竞赛结果页
C有条件主办方维护的 GitHub 或官方社交公告
D不可以参赛者 README、个人主页、二手盘点、搜索摘要、点赞或 Star

项目链接可以帮助读者了解作品，但它不能单独承担名次证明。奖金额度、项目热度、页面位置和 Finalist 身份也不会被用来推断排名。

这看起来有些“保守”，但对赛事数据来说，克制比完整更重要。

三个核心模块：Archive、Radar 和 Method

1. Archive：已经确认的赛果坐标

Archive 是正式赛果目录。

用户可以按关键词搜索赛事、项目、团队、用途和标签，也可以按照主办方、年份、比赛类型、赛果状态进行筛选，并按年份、获奖记录数或主办方排序。

每条记录会尽可能展示：

  • 官方奖项原文与明确的数字名次；
  • 获奖项目和团队；
  • 项目链接与官方结果来源；
  • 最近核验日期；
  • 当前是完整奖单、主要奖项精选，还是等待开奖；
  • 暂缺的项目链接、规模数据或结果信息。

image.png 这里还有一个容易忽略的细节：未知信息不会被藏起来。没有项目链接就显示待补充，官方还没公布赛果就显示待开奖，而不是用一个看似完整的卡片掩盖数据缺口。

2. Radar：只负责发现，不负责盖章

赛事信息一直在变化，完全依赖人工搜索很容易漏掉新项目，所以项目加入了 Discovery Radar。

GitHub Actions 每天 **09:17（北京时间）**调用 GitHub Search API，使用 Agent、Skill、MCP、多智能体以及“黑客松 / 大赛 / 挑战赛”等中英文关键词组合，更新候选池。

但这里刻意保留了一条边界：

自动发现不等于正式收录。

候选仓库可能属于主办方，也可能只是参赛项目，甚至只是提到过某场比赛。因此，所有自动发现的结果都会先标记为“待核验”。只有找到主办方身份、官方奖项和获奖者证据后，才会进入正式目录。

image.png 网页端还提供了交互式搜索台，可以组合主题、行业、主办方、地区和年份标签，跳转到主办方官方域名、GitHub、Devpost、Kaggle、Hugging Face 等入口继续检索。

3. Method：把数据口径公开出来

很多榜单的问题不只在于数据错，而在于读者根本不知道它是怎么得出的。

因此，观测站把核验方法直接放在页面上：

  1. 来源门槛：主办方官网、官方博客、官方竞赛页或主办方维护的 GitHub，才可作为名次依据；
  2. 排名原貌：只有主办方明确排序时才展示数字名次，类别奖和同档奖保留官方原文；
  3. 核验时间：每场赛事展示最近核验日期；
  4. 未知可见：资料缺失、结果待公布或链接不完整时，明确标记待补充。 image.png

把“发现”和“确认”拆开

整个项目的工作流可以概括为五步：

  1. GitHub Actions 生成候选线索；
  2. 人工或 agent-competition-scout Skill 核验官方证据；
  3. 将确认后的结果写入 data/competitions.json；
  4. 生成离线数据 Bundle，并运行结构与行为测试；
  5. 通过 GitHub Pages 展示统一的可搜索界面。

这里有两个不同的数据层：

  • data/discovery.json：自动发现的候选池，默认不可信；
  • data/competitions.json：已经经过核验的正式赛果，是唯一维护源。

将两者分开，可以让自动化负责扩大搜索范围，同时让需要判断力的环节保留人工和证据门槛。

这也是我认为整个项目最关键的设计：自动化可以提高发现效率，但不能替代事实判断。

仓库本身还是一个可安装的 Skill

项目根目录同时提供了 agent-competition-scout Skill，用来协助维护赛事数据。

它可以完成这些工作：

  • 从标签或用户问题生成多组联网查询；
  • 优先检索主办方官网、官方博客、官方赛事页和官方 GitHub；
  • 将来源划分为 A—D 级，二手信息只作为线索；
  • 区分数字名次、大奖、地区奖、类别奖和荣誉提名；
  • 按主办方、赛事、届次和官方链接去重；
  • 对无法确认的字段保留 null 或“待补充”；
  • 更新 JSON 后生成数据 Bundle，并运行结构与行为测试；
  • 输出新增、跳过、待确认项以及证据等级组成的核验回执。

安装到项目中：

git clone https://github.com/carpentry-liu/agent-skill-podium.git \
  .codex/skills/agent-competition-scout

然后可以用自然语言触发：

使用 $agent-competition-scout 搜索 2026 年 Agent 安全和 MCP 比赛，
先做只读报告，不修改数据。

或者：

使用 $agent-competition-scout 核验最近公布的官方前三名，
更新领奖台数据并给出验证回执。

image.png

为什么选择纯静态实现

这个项目没有使用前端框架，也没有生产构建依赖，核心就是原生 HTML、CSS 和 JavaScript。

这样做有几个直接好处：

  • 仓库可以原样部署到 GitHub Pages；
  • 本地双击 index.html 就能浏览；
  • 不需要维护 Node.js 依赖和复杂构建链；
  • 数据、页面和维护 Skill 可以放在同一个仓库中版本化；
  • 更适合长期维护一个更新频率不高、但要求可追溯的公共数据项目。

为了兼容直接打开文件的场景，浏览器读取生成的 data/competitions.js，而 JSON 仍然是唯一维护源。

校验器只使用 Python 标准库，负责检查 Schema、URL、日期、重复 ID、奖项状态和 Bundle 同步。动态内容通过 DOM 文本节点写入，避免直接把数据拼成 HTML；页面还处理了响应式布局、键盘焦点、ARIA live 和 reduced-motion。

这套技术栈并不炫，但与项目目标非常匹配：部署简单、依赖少、数据清晰、几年后依然容易打开和维护。

一条命令完成维护和校验

仓库把同步、校验和测试统一放进了 scripts/maintain.py：

# 提交前完整检查，不写文件
python scripts/maintain.py check

# 编辑正式赛果后，同步 Bundle 并完成检查
python scripts/maintain.py refresh

# 只预览新的候选线索
python scripts/maintain.py discover --dry-run

# 更新每日候选池
python scripts/maintain.py discover --write-leads

如果需要留下维护记录，可以生成 Markdown 报告：

python scripts/maintain.py refresh \
  --report reports/maintenance.md

报告路径被限制在仓库专用的 reports/ 目录中，而且不会覆盖已有报告。自动发现也只查询公开的 GitHub Search，不需要把密钥放进仓库，更不会把候选自动写进正式赛果。

这个项目适合谁

我认为它主要适合四类人：

  1. Agent 开发者：寻找比赛、获奖项目和可以复用的产品方向；
  2. 技术内容创作者：快速定位原始结果页，减少转述错误；
  3. 企业或社区运营者：观察不同主办方的赛道设置和获奖口径；
  4. 开源数据维护者：参考“候选发现—证据核验—结构化收录”的维护流程。

它现在还不是一份全量数据库，项目也没有假装自己已经覆盖所有赛事。相反，每条记录都会说明当前覆盖的是完整奖单、精选主要奖项，还是仍在等待结果。

写在最后

AI Agent 生态变化很快，新赛事、新工具和新项目每天都在出现。但越是变化快，越需要把“我看到过”与“官方确认过”区分开。

Agent 赛事观测站想做的事情很简单：

不追求制造一张更热闹的榜单，而是让每一条赛果，都能回到它的原始来源。

如果你知道尚未收录的 Agent、Skill、MCP 或多智能体赛事，欢迎提交官方来源；如果发现链接迁移、结果补发或奖项口径有误，也欢迎在仓库中参与修正。

如果这个项目对你有帮助，欢迎收藏、Star，或者把它分享给正在寻找 Agent 比赛的朋友。

avatar
文章
阅读
粉丝