这个 GitHub 爆火的 Agent Sort 到底能干嘛？实测来了

1. 基于证据的分类，不靠猜#

Agent Sort 的核心哲学是「不要猜测，要看证据」。它不会凭感觉说「这个项目可能需要 Python」，而是去 grep 你的代码：

• 有 .py 文件吗？
• 有 pyproject.toml 吗？
• package.json 里声明了什么技术栈？
• CI 配置在跑什么？

每个分类决策都必须附带具体的仓库证据。

2. DAILY vs LIBRARY 二分模型#

整个分类体系极其简洁，只用两个桶：

不是「删掉」，而是「归档可查」——这个设计非常合理。

3. 六通道并行审查#

如果你的 Agent 支持并行子 Agent，Agent Sort 会把审查拆成六个通道同时跑：

1. Agents → 分类 agents/*
2. Skills → 分类 skills/*
3. Commands → 分类 commands/*
4. Rules → 分类 rules/*
5. Hooks & Scripts → 分类 hook 和脚本
6. Extras → 分类上下文、示例、MCP 配置等

没有子 Agent 也没关系，顺序执行同样的流程。

4. 完整的输出产物#

一次完整的 Agent Sort 运行会产出五件东西：

1
1. DAILY 清单 — 哪些要加载
2
2. LIBRARY 清单 — 哪些要归档
3
3. 安装计划 — 具体怎么操作
4
4. 验证报告 — 确认结果正确
5
5. skill-library 路由器（可选）— 可搜索的参考库入口

适用场景#

✅ 适合的情况：

• 项目只需要 ECC 的一部分，全量安装太臃肿
• 仓库技术栈清晰，但不想手动一个个筛选
• 团队需要基于证据（而非主观意见）的可重复安装决策
• 仓库的技术栈已漂移，混入了不该用的组件

不适用场景#

❌ 不适合的情况：

• 从零开始的新项目，还没确定技术栈
• 项目本身就是个 Skills 集合仓库（分类逻辑不适用）
• 你不在乎 token 消耗和上下文开销

实际操作步骤#

第一步：分析仓库技术栈

1
# 看看项目里都有什么文件
2
rg --files
3

4
# 搜索关键技术栈关键词
5
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
6

7
# 检查配置文件
8
cat package.json
9
cat pyproject.toml
10
cat Cargo.toml

第二步：构建证据表

对每个候选组件，按这个格式记录：

1
skills/frontend-patterns | skill | DAILY | 84 个 .tsx 文件，存在 next.config.ts | 核心前端技术栈
2
skills/django-patterns   | skill | LIBRARY | 无 .py 文件，无 pyproject.toml | 此仓库不活跃

第三步：决定分类

• 仓库明确使用对应技术栈 → DAILY
• 组件偏离当前技术栈 → LIBRARY

第四步：执行安装计划

• DAILY 组件 → 保留在 .claude/skills/
• LIBRARY 组件 → 通过搜索保持可访问

第五步：验证

确认每个 DAILY 文件在预期位置，过期组件已被移除。

优点#

• 🎯 证据驱动：不靠直觉，grep 说话
• 🧹 瘦身效果显著：一个纯前端项目可能省掉 60%+ 的无用加载
• 🔄 可重复：每次运行结果一致，适合团队
• 📊 输出标准化：格式清晰，便于审查和交接
• 🤖 并行友好：有子 Agent 时速度更快

缺点#

• 📝 对小型单文件项目收益有限（本来就没多少组件）
• 🔧 需要一定技术判断力来解读证据表
• 📚 学习成本：第一次用可能需要跑两遍才能完全理解流程

推荐指数：⭐⭐⭐⭐½（4.5/5）#

对于任何使用 AI 编程助手的中大型项目，Agent Sort 都是必备技能。它的证据驱动方法让配置优化从「凭感觉」变成了「看数据」，这正是 AI 辅助开发应该有的样子。