快速结论
AAS Core / Agentic Awesome Skills 适合同时使用 Claude Code、Codex、Cursor、Gemini CLI、OpenCode 等编码 Agent，并希望从大型技能目录中形成可复现技能栈的开发者。项目已经从旧名 Antigravity Awesome Skills 迁移到 agentic-awesome-skills：截至 2026 年 7 月，npm 版本为 15.1.0，目录标称 1,969+ 项技能，新增 AAS Core 本地 MCP、aas CLI、栈清单、验证、不可变计划预览和浏览器内 Workbench。
它不是替你挑选“最佳技能”的推荐模型。Agent 先检查项目并选择精确技能 ID，Core 只验证目录身份和结构；语义适配、安全性、兼容性仍由使用者判断。当前受支持路径以只读搜索、检查、组合、验证和计划为主，apply 与 recovery 明确属于实验能力。先用计划和人工审核，不要把完整目录直接交给高权限 Agent 自动落地。
核心功能
- 完整本地目录：搜索、读取并比较 1,969+ 技能，不需要把代码仓库上传给 AAS 服务。
- 只读 AAS MCP：
search_skills、get_skill、compose_stack、inspect_stack、diff_stack等工具负责发现与结构验证。 - 可复现清单：把 Agent 选择保存为
aas-stack.json，可另存选择证据，便于评审和版本控制。 - 计划先行：CLI 验证清单并生成不可变计划；受支持预览不会直接修改目标技能目录。
- 多种分发面：保留直接安装、专业插件、bundles、workflows 和完整目录，适配不同宿主。
- Workbench 审阅：托管页面在浏览器内导入栈与计划；官方说明它不访问本地文件系统，也不是托管控制平面。
- 模型与宿主无关但效果不同：Claude、Codex 等模型负责项目理解和选择，Core 不保证不同模型得到同样的技能栈。
适合人群
- 多 Agent 开发者：想在多个宿主之间复用
SKILL.md工作方法。 - 技术负责人：需要记录谁选了哪些技能、为什么选、准备改动什么。
- 安全敏感团队：愿意先搜索、验证和预览，再批准写操作。
- 技能作者：需要大目录、元数据、插件与工作流作为兼容性参考。
- 不适合的人群：只需要一两个明确技能、无法审阅第三方指令，或期待工具自动认证“语义正确与绝对安全”的用户。
使用场景
- 项目技能栈设计：让 Agent 分析架构、测试、安全、部署等能力面，再搜索多个候选并生成可评审清单。
- 跨宿主迁移：为 Claude Code、Codex、Cursor、Gemini CLI 或 OpenCode 选择对应安装路径。
- 团队变更审批：提交栈清单、选择证据和计划，而不是口头说明“装了一批技能”。
- 领域插件起步：从 Web、Security、Data、QA、DevOps 等小型专业插件开始，避免完整目录压垮上下文。
- 目录研究：读取技能元数据和正文，比较重复项、来源与风险标签，再决定是否引入。
价格与版本
项目与 npm 包免费。代码和工具采用 MIT 许可证；项目自有文档等非代码内容采用 CC BY 4.0，而第三方技能仍保留各自上游许可与例外，复用前必须查看来源记录。15.x 才包含 AAS Core，旧的 antigravity-awesome-skills 包停留在 13.x 兼容线，不应继续作为 canonical 安装入口。
AAS 本身不收模型费，但每次让编码 Agent 分析项目、比较技能和执行工作流都会消耗宿主订阅或 API 配额。GitHub 与 npm 也有网络下载和速率限制；大型包体、完整目录和频繁更新会增加磁盘、上下文和供应链审查成本。固定 npm 版本、使用 release-pinned 安装、先 dry-run 或 plan，通常比追随 main 更稳。
国内访问与使用体验
核心目录、MCP 与 CLI 在本地运行；安装和更新时需要访问 npm 与 GitHub。needsVPN: false 只表示项目本身没有必须登录的海外 SaaS 控制面，不保证每个地区、每个宿主模型或第三方链接始终可达。AAS Core 本地 stdio 默认不需要 AAS 账号和 API Key，也不提供多用户身份系统；真正的认证、模型授权和计费由 Claude、Codex 等宿主负责。
不要把本地 MCP 当成安全认证层。第三方 SKILL.md 本质上是会影响 Agent 行为的指令，应视为不可信供应链输入：检查来源、脚本、外链、Shell 操作和数据上传要求。Workbench 声称只在浏览器内审阅导入文件，但敏感项目仍应优先使用本地 diff。模型可能误选技能，描述触发也可能漏判或误判。
优点
- 从“复制技能文件”升级为可记录、可验证、可预览的技能栈管理流程。
- 本地搜索和检查不要求上传代码库，数据边界相对清楚。
- 多宿主、插件、bundle、workflow 与直接安装路径覆盖面广。
- 完整目录与专业小包并存，可按上下文预算选择。
- 清楚区分结构有效、语义适配与执行安全，没有把验证器包装成安全认证。
不足
- 近两千项技能会带来筛选、重复、上下文和供应链审核负担。
- Core 仍处于 agent-first preview；apply 和 recovery 不在稳定安全承诺内。
- 本地 MCP 无独立用户鉴权，团队远程化需要自行增加边界。
- 不同模型和宿主对技能格式、触发、命令权限的支持并不完全一致。
- MIT/CC BY 只覆盖项目自有部分，第三方技能许可必须逐项核查。
替代品对比
| 工具 | 更适合谁 | 优势 | 局限 |
|---|---|---|---|
| Superpowers | 重度 Claude Code 流程用户 | 头脑风暴、TDD、调试流程集中 | 目录广度和跨宿主分发较少 |
| Spec Kit | 需要规格驱动开发的团队 | 从 specification 到 plan/tasks 很清晰 | 不是通用技能目录 |
| Skill Seekers | 想从资料生成技能的人 | 偏技能创建与提取 | 不负责大型栈管理 |
| agents | 需要多宿主插件与子 Agent 的用户 | 插件、Agent、命令一体 | 组织方式与 AAS Core 不同 |
| Claude Code | 想直接执行终端开发任务的人 | 宿主能力成熟 | 是运行环境，不是技能目录控制面 |
常见问题 FAQ
AAS Core 免费吗？
是，代码与工具免费；使用 Claude、Codex 等模型产生的订阅或 API 费用另算。
旧的 Antigravity Awesome Skills 还能用吗？
旧包可能仍可安装，但 canonical 项目和 15.x Core 已迁移到 agentic-awesome-skills，新部署应使用新名称。
AAS 会上传我的代码吗？
官方 Core 流程由本地 Agent 检查项目，本地 MCP 搜索目录。Workbench 是浏览器内审阅面；仍应检查宿主模型自身的数据政策。
需要 AAS 账号或 API Key 吗？
本地 stdio MCP 与 CLI 不要求 AAS 账号。模型宿主、GitHub 或 npm 可能有各自认证和限额。
验证通过是否表示技能安全？
不是。验证确认 ID 和结构，不认证语义适配、命令安全、许可证或第三方脚本可信度。
应该安装完整目录吗？
只有确实需要广度时才安装。多数项目从专业插件或小型精确栈开始，更省上下文也更容易审计。
总结
AAS Core 的真正价值不是“技能数量最多”，而是把 Agent 自主选择变成可保存、可验证、可 diff、可预览的状态。它适合愿意做工程治理的多 Agent 用户。最稳妥的采用路径是锁定 15.x release，用本地只读 MCP 搜索，保存选择证据，审阅计划，限制高风险技能，并暂不依赖实验性自动 apply。目录内容、模型判断和外部脚本都不能因为进入 AAS 就自动变可信。