GitHub 趋势 · 第 53 期
Agent 外围层横评：25 万 star 的那个仓库，README 写着只有一个人维护
#Agent外围层#技术选型#横向对比
这一期把榜单上「围绕 agent 的那一层工具」捡出来横着比了一遍 —— 8 个仓库，合计 773,434 star。比完之后最大的感觉是两件事：这一层里 star 最高的不是大厂，是个人；而 star 的多少，几乎不能说明「现在有没有人在回你的 issue」。
你可能已经装了三个 MCP server、两个 skill 包、一个终端里的编码 agent。它们分别写进你不同的配置文件，各自都宣称支持十几个客户端。真出问题的时候，你分不清是客户端没读到，还是这层工具根本没接上 —— 因为这一类的安装方式，从来没有统一过。
一、先说这一层到底是什么
上一期写的是「教 agent 怎么想」的那一层（skill 包）。这一期换一层：「让 agent 能动手」的那一层。同一个目的，在榜单上有三种完全不同的交付形态，而它们是被放在同一张榜上比 star 的。
取代方 你 → Agent（它自己就是入口） 寄生方 你 → 你原来的 Agent → 规则 / hook / skill 写进它的目录 被调用方 你 → 你原来的 Agent → 子进程（MCP server）→ 外部工具
| 交付形态 | 它要占什么 | 本期入选 | 合计 star | 占比 |
|---|---|---|---|---|
| 取代方（CLI agent 本体） | 占掉你的终端 | anomalyco/opencode、github/spec-kit、apache/maka | 347,547 | 44.9% |
| 寄生方（harness / 插件集） | 写进你现有 agent 的目录，做加法 | affaan-m/ECC、ruvnet/ruflo | 328,518 | 42.5% |
| 被调用方（MCP server） | 给你的 agent 起一个子进程 | ChromeDevTools/chrome-devtools-mcp、mksglu/context-mode、pascalorg/editor | 97,369 | 12.6% |
三行合计 773,434，和上面的总数对得上。值得注意的是最后一行：只给 agent 递工具的那一类，拿到的 star 只有前两类的七分之一。而它恰恰是你每天真正会被调用的那一类。
二、错位一：star 最高的那一批，不是大厂
先把这 8 个仓库按维护者体量分三类。身份取自 GitHub API 的 owner.type：User 是个人账号，Organization 是组织。
| 维护者类型 | 仓库 | 合计 star | 占比 |
|---|---|---|---|
| 个人（3 个） | affaan-m/ECC、ruvnet/ruflo、mksglu/context-mode | 350,690 | 45.3% |
| 其他组织（2 个） | anomalyco/opencode、pascalorg/editor | 230,119 | 29.8% |
| 大厂 / 基金会（3 个） | ChromeDevTools/chrome-devtools-mcp、github/spec-kit、apache/maka | 192,625 | 24.9% |
三个个人账号下的仓库拿了 350,690 star，占到 45.3%；而出自 Google、GitHub、Apache 基金会的三个仓库合计 192,625 star，只有 24.9%。
最直白的对比是这两个：affaan-m/ECC 的 256,407 star，是 ChromeDevTools/chrome-devtools-mcp 51,667 star 的 4.96 倍。而 ECC 的 README 里写着这么一句 a single maintainer ships weekly across 7 harnesses（大意：只有一个维护者，每周给 7 个 harness 发版）。同样是个人账号的 ruvnet/ruflo 有 72,111 star，比 Google 官方那个高 39.6%。
而代码体量反过来。GitHub API 的 size 字段（单位 KB）里，两个官方仓库恰好是最小的：chrome-devtools-mcp 10,910 KB、spec-kit 17,552 KB；最大的两个反而都是社区的：ruflo 549,314 KB、opencode 509,806 KB，与最小的那个相差 50.4 倍。
这一层的 star 记录的是「多少人想自己攒一套」，不是「多少人认可官方做法」。ECC 一个仓库里装着 68 个 agent、291 个 skill、94 条命令；而 chrome-devtools-mcp 只做浏览器控制这一件事，仓库也只有 10,910 KB。两者被放在同一张榜上比大小，本身就说明了问题。
三、错位二：未关闭 issue 与 star 的比例，相差 128 倍
上面那个结论只能说明 star 不等于认可度。那什么指标能说明「这个仓库现在有没有人在管」？把 open_issues_count 除以 star 试了一下，结果比 star 本身有意思得多。
| 仓库 | Star | 未关闭 issue | 每 100 star 的 issue 数 |
|---|---|---|---|
| affaan-m/ECC | 256,407 | 188 | 0.07 |
| anomalyco/opencode | 206,589 | 5,740 | 2.78 |
| github/spec-kit | 135,718 | 306 | 0.23 |
| ruvnet/ruflo | 72,111 | 980 | 1.36 |
| ChromeDevTools/chrome-devtools-mcp | 51,667 | 102 | 0.20 |
| pascalorg/editor | 23,530 | 58 | 0.25 |
| mksglu/context-mode | 22,172 | 233 | 1.05 |
| apache/maka | 5,240 | 492 | 9.39 |
最高的 maka 是 9.39，最低的 ECC 是 0.07 —— 相差 128 倍。两个极端对着看更清楚：
- ▪apache/maka：5,240 star，对应 492 个未关闭 issue。同一时间里 star 只有 ECC 的 1/49，积压的 issue 却是它的 2.6 倍。
- ▪anomalyco/opencode：206,589 star、5,740 个未关闭 issue。它是这 8 个里名义上最忙的一个，发现问题的第一反应也就是去它那里开一条。
star 是历史累计的收藏，issue 是「现在有没有人在回你」。一个仓库可以靠一次榜单曝光拿到上万 star，但 issue 积压只能靠人力消化。选工具时先看这个比值，比看 star 实在。
四、错位三：star 的分布，跟着「占不占你的入口」走
回到第一张表。被调用方（MCP server）嘴上说是最适合自动化的一类，但 star 只有 97,369，占 12.6%；取代方与寄生方合起来拿了 87.4%。
一个合理的解释是：取代方占掉你的终端，你得先比较才敢装，于是会先收藏；寄生方不要求你换工具，只是往你现有的 agent 里加东西，门槛最低；而被调用方只是给 agent 递个工具，它的价值要你真用上才体现出来。
但 star 少不代表工作量小。以 mksglu/context-mode 为例，它要同时适配十几个客户端，README 里的说法是 This is a mandatory paradigm across all 17 supported clients，而同一份 README 的兼容性表里实际列了 18 个平台列。它自己的数字就没对上。
五、八个仓库的硬字段对照
下面这张表里的 star、许可、语言、体量全部取自 GitHub REST API 实测，对应的安装命令逐字取自各仓库 README 原文。
| 仓库 | Star | 许可 | 语言 | 主安装通道 | 体量 KB |
|---|---|---|---|---|---|
| affaan-m/ECC | 256,407 | MIT | JavaScript | npx ecc-universal@2.2.1 setup | 50,373 |
| anomalyco/opencode | 206,589 | MIT | TypeScript | curl -fsSL https://opencode.ai/install | 509,806 |
| github/spec-kit | 135,718 | MIT | Python | uv tool install specify-cli | 17,552 |
| ruvnet/ruflo | 72,111 | MIT | TypeScript | npx ruflo@latest init wizard | 549,314 |
| ChromeDevTools/chrome-devtools-mcp | 51,667 | Apache-2.0 | TypeScript | npx -y chrome-devtools-mcp@latest | 10,910 |
| pascalorg/editor | 23,530 | MIT | TypeScript | npx @pascal-app/cli editor | 145,961 |
| mksglu/context-mode | 22,172 | Elastic License 2.0 | TypeScript | npm install -g context-mode | 31,898 |
| apache/maka | 5,240 | Apache-2.0 | TypeScript | git clone + npm ci + npm run dev | 118,332 |
八个里七个是 MIT 或 Apache-2.0，唯一的例外是 context-mode 的 Elastic License 2.0。语言也很集中：TypeScript 6 个、JavaScript 与 Python 各 1 个，合计正好 8 个。
六、上手：三类各一条入口
被调用方（MCP server）写进客户端配置，以 chrome-devtools-mcp 为例，README 原文：
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"]
}
}
}
同一类里另一个的 Claude Code 路径，README 原文（context-mode）：
/plugin marketplace add mksglu/context-mode /plugin install context-mode@context-mode
取代方（CLI agent 本体），三个仓库的 README 原文：
# opencode curl -fsSL https://opencode.ai/install | bash npm i -g opencode-ai@latest # spec-kit uv tool install specify-cli specify init my-project --integration copilot # maka git clone https://github.com/apache/maka.git cd maka npm ci npm run dev
寄生方（harness），两个仓库的 README 原文：
# ECC npx ecc-universal@2.2.1 setup # ruflo npx ruflo@latest init wizard
七、我的判断
- ▪想少写重复 prompt、又不想换工具：选寄生方。但要接受它会往你的 agent 目录写一堆文件，而且一旦装错了路径、事后很难分辨哪些是它写的。
- ▪想让 agent 真的能开浏览器、翻自己的上下文：选被调用方。这一类不劫持你的客户端，也就不会把你锁在某个生态里。
- ▪想连终端一起换掉：选取代方。但记得这类工具本身不含模型，token 费用自付。
不适合谁：只想要一个能用的工具、不愿意读安装文档的人。这一层没有统一的装法，装错通道的典型症状是「装上了但 agent 看不见」。
坑一：官方仓库的默认值不是「安全默认」。chrome-devtools-mcp 的 README 原文写着 Data collection is enabled by default，要显式加 --no-usage-statistics 才能关；性能工具还会把 trace URL 发给 Google 的 CrUX API，要加 --no-performance-crux。
坑二：八个里有一个不是 OSI 开源。context-mode 的 LICENSE 是 Elastic License 2.0（source-available）。README 解释得很直白，原文原因是 We chose ELv2 over MIT because MIT permits repackaging the code as a competing closed-source SaaS —— 你能用、能改、能再分发，但不能拿它做托管服务、不能删许可声明。
坑三：开源 + 付费扩展。ECC 的 README 写着 This repo is MIT-licensed forever，同时挂着一个托管版：ECC Pro（私有仓库从 $19/seat/mo 起）。开放的部分不会回收，但你要知道哪些能力在付费那一边。
坑四：不要叠加安装。ECC README 原文 Do not stack install methods；同一个 harness 装两次会出现重复的 skill、hook 和配置。ruflo 也提醒自己有 two different install paths with very different surface areas。
坑五：MCP 不是越多越好。ECC README 原文 Keep under 10 MCPs enabled per project 与 under 80 tools active —— 每个 MCP 工具描述都要吃 token。
坑六：maka 的官方构建还不是正式发布。README 原文 Maka has not made an Apache release yet；Windows 与 Linux 桌面是未签名预览版，且不打算用于生产。
数据来源：GitHub REST API（repos / contents / README 原文）与 GitHub Trending 三榜（daily / weekly / monthly），抓取时间 2026-09-12 凌晨（北京时间）。
许可：affaan-m/ECC、anomalyco/opencode、github/spec-kit、ruvnet/ruflo、pascalorg/editor 为 MIT；ChromeDevTools/chrome-devtools-mcp、apache/maka 为 Apache-2.0；mksglu/context-mode 为 Elastic License 2.0（source-available，非 OSI 开源）。
八个仓库均未归档、未禁用，README 中均未出现禁止引用声明。star 以 REST API 实测为准，Trending 页快照略有差异：ECC 256,439（周榜快照）/ spec-kit 135,730 / ruflo 72,119 / chrome-devtools-mcp 51,670 / editor 23,543 / context-mode 22,177 / maka 5,238。
本期三榜在榜情况：ECC 周榜 +9,257，context-mode 周榜 +1,619，ruflo 周榜 +1,694，chrome-devtools-mcp 周榜 +791，spec-kit 日榜 +985，editor 日榜 +83，maka 月榜 +3,941。
地址：github.com/affaan-m/ECC · github.com/anomalyco/opencode · github.com/github/spec-kit · github.com/ruvnet/ruflo · github.com/ChromeDevTools/chrome-devtools-mcp · github.com/pascalorg/editor · github.com/mksglu/context-mode · github.com/apache/maka
本文所有安装命令均逐字取自对应仓库 README 原文，未作改写；能力与限制描述亦取自 README 原文。
这 8 个里你装过几个？如果碰过「装了但 agent 看不见」，欢迎在评论区写一下你的排查顺序 —— 这类问题一般不是配置写错，而是两边的目录约定本来就不一致。
下一期会先抓三榜。如果继续零候选，就写 jakubkrehel/skills（6,233 star，本周 +1,103，一个设计师写的界面类 skill 集）；备选是日榜上的 melgarafael/DeskcommCRM（+126）与 jordan-gibbs/hyperresearch（+118）。
#Agent外围层#技术选型#GitHub趋势