flowchart TB
subgraph L1["编排层：谁派活"]
A["headcount 公司制15部门"]
B["fable-orchestrator 多模型分工"]
C["astra-luna 编排加子代理"]
end
subgraph L2["执行层：谁干活"]
D["hermes-agent 通用底座"]
end
subgraph L3["状态层：记住什么"]
E["agent-memory Markdown为源"]
F["okf-agent-memory Git原生"]
end
subgraph L4["发布层：怎么上线"]
G["部署四件：Vercel、Cloudflare、Netlify、Render"]
H["CI两件：Actions与gh-fix-ci"]
I["sentry 线上监控"]
end
L1 --> L2
L2 --> L3
L3 --> L4
权重：功能完整度 25%、设计质量 25%、实战效果 20%、上手难度 15%（星越多越易用）、社区活跃度 15%。综合分为加权值。
| 排名 | Skill | 工位 | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 社区活跃度 | 综合 |
|---|---|---|---|---|---|---|---|---|
| 1 | 部署四件（本机装机合评） | 部署 | ★★★★★ | ★★★★☆ | ★★★★☆ | ★★★★☆ | ★★★★☆ | 4.25 |
| 2 | NousResearch/hermes-agent | 执行底座 | ★★★★☆ | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★★★ | 4.00 |
| 3 | tigerless-labs/agent-memory | 状态 | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★★☆ | 3.80 |
| 4 | CI监控三件（本机装机合评） | CI/监控 | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★★☆ | ★★★★☆ | 3.75 |
| 5 | cbrock84/headcount | 编排 | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ | ★★★★☆ | 3.65 |
| 6 | okf-memory/okf-agent-memory | 状态 | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ | 3.50 |
| 7 | codejunkie99/fable-orchestrator | 编排 | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ | ★★★★☆ | 3.40 |
| 7 | donvito/codex-astra-luna-orchestrator | 编排 | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | 3.40 |
规律一眼可见：编排件设计分普遍高（范式新），实战分普遍低（没沉淀）；发布件正好相反。新工位多，老工人稳。
它的聪明之处在于意识到：多 Agent 协作的瓶颈从来不是「能不能开子代理」，而是任务按什么规则路由。headcount 的答案是先给组织设计——部门即职责域，任务进场先按职能分工，再落到具体执行者。组织架构本身就是一份大型提示词工程，这是 Skill 竞争进入「组织设计」维度的标志。新星榜四小时级别的登榜速度（今日 ⭐1348）说明「公司制」隐喻对用户有真实号召力。
短板也来自隐喻本身：部门一多，路由判断和上下文交接的开销线性上涨，小项目用公司制属于高射炮打蚊子；另外从描述看，它的重心在「分活」而非「验收」，跨部门的成果质检机制描述里没有体现，需要使用者自己补。
npx skills add cbrock84/headcount
新上架，⭐594，描述只有一句却信息量极大：Fable 5.1 orchestrates. GPT-5.6 Luna and DeepSeek V4 Flash implement.——Fable 5.1 只做编排，GPT-5.6 Luna 和 DeepSeek V4 Flash 负责实现。
「贵模型想、便宜模型干」是社区流传已久的成本策略，这件作品的价值是把它显式化、固化成结构：编排与实现分离到了模型级，而且实现位混编了不同厂商的模型。这实际上是承认了一个事实——没有任何单一模型在「规划」和「执行」上同时最优。
最大风险同样写在脸上：型号强绑定。当下模型以月为单位迭代（本周 HN 首页还在热议 DeepSeek v4.1 Flash），编排件背后每换一代模型，分工描述、上下文传递格式都可能要重调。这类件的维护成本不在代码，在追模型。
npx skills add codejunkie99/fable-orchestrator
⭐869，描述：Use Astra as orchestrator and Luna for subagents in Codex——在 Codex 里用 Astra 做编排者、Luna 做子代理。
它与 fable-orchestrator 几乎同构：一个编排位、若干执行位。有意思的是两个信号。其一，「编排者/子代理」双角色结构在两个仓库、两个场景里独立出现，说明这已经是跨 harness 的通用模式，比 headcount 的全公司制轻，比单 Agent 干重活稳。其二，Astra 这个代号本周热度极高——HN 首页同时挂着《GPT-6 Astra, looped transformers, and hidden reasoning》（447 分），编排件选在话题峰值期上架，命名本身就是流量策略。
短板：同样绑死模型代号；且编排协议是自定义的，想迁移到别的 harness 成本不低。
npx skills add donvito/codex-astra-luna-orchestrator
# Codex 场景使用，具体接入方式以仓库 README 为准
⭐244054，本周热榜上排在 obra/superpowers（⭐284374）、affaan-m/ECC（⭐255537）之后，与 react、linux 同榜——这个量级说明「可持续成长的通用 Agent」已是共识级需求，而不再是某个 Skill 的小功能。
在本文的四层模型里，hermes-agent 是执行层的底座：编排层派下来的活，最终要有一个能长期运行、能自我修正的宿主去干。它的定位语 The agent that grows with you 强调的是随使用积累而进化，这恰好是纯 Skill 方案的短板——Skill 只给方法，底座才给记忆与习惯的容器。
短板：底座型项目的开箱即用性让位于可塑性，对只想自动化一条流水线的人偏重；上手分给到三星不冤。
# hermes-agent 是独立 Agent 底座而非单文件 Skill，按仓库 README 安装
git clone https://github.com/NousResearch/hermes-agent
新上架，⭐818，描述：Long-term memory runtime for AI agents — plain Markdown as the source of truth。纯 Markdown 作为事实源的长期记忆运行时。
选 Markdown 作事实源是个务实的决定：可 diff、可 review、可人肉修改，记忆第一次获得了和代码同等的待遇——能进版本控制、能走审查流程。「runtime」形态也值得注意，它意味着有统一的读写接口，而不是一堆散落文件靠约定维护。对工作流而言，这解决了「上一轮部署踩过的坑，这一轮还记得吗」的问题。
短板：与 Claude Code 原生 memory 目录、CLAUDE.md 的职责边界需要用户自己划清，装之前先想好谁是事实源。
npx skills add tigerless-labs/agent-memory
⭐535，描述：Git-native persistent memory for AI coding agents. Implements Google OKF v0.2 with sub-300µs in-memory…。Git 原生持久记忆，实现 Google 的 OKF v0.2 规范，亚 300 微秒的内存级读写。
两个罕见的点：一是「Git-native」，把 branch/merge/revert 语义直接套在记忆上——记忆可以分叉试验、可以合并、可以回滚，这是把工作流的状态管理彻底压回版本控制；二是它公开谈性能指标，记忆件此前几乎没人报延迟数字，sub-300µs 给这个品类定了第一个性能锚点。
短板：绑定 OKF v0.2 这个尚新的规范，规范演进时有迁移风险；社区活跃度（⭐535）也还处在早期。
npx skills add okf-memory/okf-agent-memory
本节视角不同：以下件均出现在本文写作环境的 Claude Code 装机目录中（按名称核对），是「已经在日常服役」的一批，各平台对应的 CLI 能力为公开稳定特性。合评分析。
四个平台各一件，分别封装 Vercel、Cloudflare（wrangler）、Netlify、Render 的部署链路。部署 Skill 的价值从来不是「会敲 deploy 命令」——命令谁都会敲——而是把判断固化下来：部署前的预检（环境变量齐不齐、构建产物对不对、区域选没选）、失败后的回滚路径、以及更关键的「什么时候不该部署」。这类件把平台最佳实践编码成可执行的检查单，是四个门类里功能完整度唯一给到五星的：部署是强边界任务，成败立判，容不得含糊，也因此最容易被做扎实。
短板在装配侧：一个团队通常只用其中一件，四件全装会稀释触发精度——部署词「发一下」「上 production」落在哪个件上，完全取决于各件描述的区分度。按需装一件，比全都要更明智。
# 用 skills CLI 先定位再安装，避免装全不必要平台
npx skills find deploy
npx skills find vercel # 按平台关键词缩小范围，选定后 add
这四件合起来正好是一条「红了之后」的完整链路。github-actions-skill 管工作流的编写与维护（YAML 生成、改触发规则）；gh-fix-ci 管 check 挂掉后的排障——拉日志、定位失败步骤、给出修复；sentry 把线上错误接进会话，让「部署成功但用户那边炸了」这件事可见；gh-address-comments 处理 PR 评论的逐条回复，补上人机协作的闭环。外加同目录的 long-running-agent（长时任务代理），构成无人值守的执行容器。
给四星不给五星的原因是设计层面的：CI 与监控的 Skill 化程度天然浅于部署——gh run view --log、Sentry 的错误流这些能力 MCP 和 CLI 都已覆盖，Skill 层的增量主要在「诊断顺序与止损判断」的方法论封装，护城河不如平台官方部署件深。
npx skills find ci # 定位 CI 类件
npx skills find sentry # 定位监控类件
flowchart LR
W["工作区改动"] --> CI["CI 检查"]
CI -->|红| F["gh-fix-ci 拉日志修复"]
CI -->|绿| D["平台部署件上线"]
F --> CI
D --> M["sentry 盯线上"]
M -->|异常| F
M -->|正常| MEM["记忆件沉淀复盘"]
单人小项目的最优装配是：部署四件选一件 + gh-fix-ci + sentry + 一件记忆件，五件以内。headcount 或 fable-orchestrator 这类编排件建议在有多条并行任务线时再引入——编排层的收益来自并行度，单线任务里它只是开销。
| 维度 | 第一名 | 说明 |
|---|---|---|
| 功能完整度 | 部署四件 | 强边界任务，成败立判，最容易被做扎实 |
| 设计质量 | headcount | 用组织图解决路由，范式级想法 |
| 实战效果 | 部署四件 + CI监控件 | 已在日常装机服役 |
| 上手难度（越易越好） | astra-luna-orchestrator | 双角色结构，比公司制轻得多 |
| 社区活跃度 | hermes-agent | ⭐244054，与 superpowers、ECC 同梯队 |
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。