深度拆解 agency-agents 及其对 Skill 评测方法论的启示

2026 年，GitHub 上涌现出一批 Agent 工程仓库。它们既不提供新模型，也不开发新框架，而是把资深工程师和专家的判断力写成 Markdown 文件，加载到 Claude Code、Cursor、Codex 等编程智能体中。agency-agents、addyosmani/agent-skills、obra/superpowers 这三个项目半年内合计拿到数十万 Star，有人调侃说这是"人们用十万级 Star 投的票"。

agency-agents（全称 "The Agency"）是其中声量最大的一个，官网定位是 "A complete AI agency at your fingertips"——一个触手可及的完整 AI 代理机构。目前 Star 数超过 14 万。这个项目想表达的观点很明确：真正稀缺的不是模型调用权限，而是打包好的工作判断力。

但大多数介绍文章都绕开了一个问题：当仓库里有 200 多个"专家人格"、24 个"工程技能"、14 个"方法论技能"时，怎么判断某个 skill 到底好不好、适不适合、有没有用？Skill 测评可能才是这场运动的下一站。本文从 agency-agents 的工程实践切入，尝试给出一套可操作的评测思路。

2.1 起源与定位

这个项目始于一个 Reddit 讨论帖，经过几个月的社区迭代，逐渐长成一个不断扩充的 AI 代理人格集合。官方的一句话介绍是：

（从前端巫师到 Reddit 社区忍者，从奇思妙想注入者到现实检查员，每个代理都是有个性、有流程、有可验证交付物的专业专家。）

这里的三个关键词值得留意：personality（个性）、processes（流程）、proven deliverables（可验证的交付物）。这也是它和普通"提示词库"的根本区别。

2.2 规模与组织：部门制（Division）

项目按部门（division）组织顶层目录，每个部门下放具体的代理 Markdown 文件。部门和代理的数量增长很快，大致轨迹如下：

• 2025-10 初始提交：51 个专家代理，覆盖 9 个类别；
• 2026 年初：147 个代理，12 个部门；
• 2026 年中：200+ 代理，16 个部门（工程、设计、付费媒体、销售、营销、产品、项目管理、测试、安全、支持、空间计算、学术、医疗、GIS、游戏开发、战略等）。

部门定义的唯一真相源（single source of truth）是根目录下的 divisions.json，由 CI 脚本 scripts/check-divisions.sh 校验，确保目录结构、JSON 配置和脚本中的 AGENT_DIRS 三者一致。这种去硬编码的设计让代理名单在持续增长时也不会过期。

2.3 多工具集成：一次编写，处处运行

agency-agents 的工程价值之一在于多工具适配。它通过一套 Bash 脚本（scripts/convert.sh、scripts/install.sh）把同一份 Markdown 人格转换成 16 种以上工具的集成格式，包括 Claude Code、Cursor、Codex、Gemini CLI、OpenCode、OpenClaw、GitHub Copilot、Aider、Windsurf、Kimi Code、Osaurus、Antigravity、Hermes、Mistral Vibe、Qwen、ZCode 等。

转换逻辑本身也值得一看。convert.sh 通过匹配标题关键字，把人格相关章节（Identity、Communication、Critical Rules）路由到 SOUL.md，把运作相关章节路由到 AGENTS.md（OpenClaw 格式）。Qwen 只需要 name 和 description 两个字段，Codex 也只取这两项生成 TOML。这层格式抽象让同一份人格定义可以在不同运行环境间移植，而这正是 Anthropic 在 2025 年 12 月发布的 Agent Skills 开放标准试图解决的分发问题。

作者还提供了原生桌面应用（支持 macOS/Linux/Windows，可通过 Homebrew 安装），可以浏览全部代理名单并一键安装到各大工具，支持自动更新。

理解 agency-agents 最好的方式是直接看一个真实代理文件的结构。以 engineering/engineering-frontend-developer.md（Frontend Developer）为例，文件分为两部分：

3.1 YAML Frontmatter（元数据）

name、description 是必填字段；color、emoji、vibe（一句话人格描述）用来增强可读性；services 是可选字段，只有代理需要调用外部服务时才填。description 在这里扮演双重角色：既要让人看懂这个代理是做什么的，也要作为"何时激活该代理"的语义信号。这和 superpowers 的 "Description Trap" 设计思路相通，后文会展开。

3.2 正文：九段式结构

正文采用规范的九段结构，可以归为 Persona（身份）和 Operations（运作）两组：

最后两项的交付设计尤其值得关注：

Technical Deliverables 不是空泛的描述，而是直接给出基于 memo 和 useVirtualizer 的虚拟列表 React 组件，以及一份结构化的前端实现交付模板，包含 Framework、State Management、性能、无障碍等具体字段。代理的产出是可以直接用的，而不是只给一段思路。

Success Metrics 给出了可测量的阈值："页面在 3G 网络下加载 < 3 秒；Lighthouse 性能与无障碍评分稳定 > 90；组件复用率 > 80%；生产环境零 console error。"这把"完成"从主观感受变成了客观指标。

人格、流程、交付物、成功指标，这四样东西构成了 agency-agents 最值得借鉴的内核。

不少评测文章把 agency-agents 归为"提示词合集"，这其实低估了它。它的真正贡献是把社区贡献做成了一套可以自动校验的生产系统。

4.1 质量门禁（Guards）

新代理要合并进主分支，必须通过一系列 CI 检查：

• 结构与 Lint：scripts/lint-agents.sh 校验九段结构，要求零警告；
• 原创性校验：scripts/check-agent-originality.sh 把新代理与全量名单比对，近重复率必须在 0.0–0.1% 之间。只是"换个国家名或平台名"的换皮（re-skin）会被自动标红；
• 工具链一致性：scripts/check-tools.sh 交叉校验 tools.json、install.sh、convert.sh 三者是否匹配；
• 生成物隔离：转换输出（integrations/<tool>/*）禁止提交，必须在 .gitignore 中加规则，否则 CI 或审核会要求移除。

4.2 成功指标是"强制项"

CONTRIBUTING 模板明确要求每个代理必须包含 🎯 Your Success Metrics，设计原则是 "Specific, measurable"，比如 "Page load times under 3 seconds on 3G"。PR 模板里甚至有一个勾选项：- [ ] Defines success metrics。也就是说，不定义成功标准的代理在流程上就不会被接收。

4.3 评审与合并流程

• 社区评审（Community Review）→ 迭代（Iteration）→ 批准（Approval）→ 合并（Merge）；
• 会被直接关闭的 PR 类型包括：提交构建输出、未经 Discussion 就批量修改现有代理、近重复的"换皮"代理；
• 新增部门需要创建目录、在 divisions.json 中加条目、更新脚本中的 AGENT_DIRS，并且至少包含一个代理文件，否则 CI 会失败。

这套机制的价值在于用工程纪律代替了"凭感觉判断一个人格好不好"，这也是本文后半部分方法论的起点。

4.4 深度使用：把"代理机构"装进你的 IDE

只看结构不够，最好实际跑一遍。上手有两条比较轻量的路径：

路径 A：原生桌面应用（零脚本）

安装后打开 App，可以浏览 200 多个代理，一键安装到 Claude Code、Cursor、Codex 或 Gemini CLI，支持自动更新。适合不想碰脚本的团队。

路径 B：脚本化安装（可控、可审计）

为了避开 OpenCode 大约 119 个代理的上限，官方建议用 --division 参数做子集安装。一个实用的做法是不要全量灌入，而是按项目缺口"组队"。比如做 MVP 时只激活 Frontend Developer、Backend Architect、Growth Hacker 和 Reality Checker，让四个角色分别关注交互性能、API 扩展性、获客路径和上线风险。

下面是一个多代理协作的工作流示例：

1. 用 Product Manager 产出需求文档（含非功能需求）；
2. 切换到 Backend Architect 设计 REST API（端点、状态码、鉴权、分页缓存）；
3. 切换到 Frontend Developer 实现组件，自带 Core Web Vitals 优化；
4. 用 Security Architect 做威胁建模与漏洞审查；
5. 最后用 Reality Checker（现实检查员）验证需求可行性，专门负责"泼冷水"。这是项目里很有意思的一个角色：它不写代码，只负责戳破不切实际的假设。

组队、分工、交叉审查、现实校验，这个回路正是人格库比散装提示词更有价值的地方。

不过也需要看到问题的另一面。agency-agents 本质上是结构化的 system prompt 包装，它的优点和局限都来自这里。

5.1 它真正解决的痛点

• 降低幻觉和平庸产出：把通用 LLM 的上下文收窄到特定领域，强制遵循 OWASP、Core Web Vitals 等最佳实践，产出更符合角色预期；
• 输出稳定可复用：明确了"何时用谁"和"产出什么格式"，解决了散装提示词库"不知道用哪个、用了也不稳定"的问题；
• SOP 化协作：多代理交接时有结构化的上下文传递，比如安全工程师审查后交给前端实现，再由现实检查员验收，减少信息丢失；
• 组织心智模型：部门制让团队一眼就能看出"我缺的是哪个角色"。

5.2 它没解决、甚至掩盖的问题

• 能力上限由底层模型决定：一个戴上"安全架构师"帽子的模型，真实的安全审计能力不会超过模型本身的安全知识。人格是约束和引导，不是增能；
• 换皮和质量参差：尽管有 originality 脚本，但概念查重仍部分依赖人工，200 多个代理中必然存在能力重叠和质量差异；
• 缺少真实效果测评：项目衡量代理质量的唯一客观信号是"是否通过 lint 和原创性门禁"，没有任何运行期指标，比如代理被激活的频率、产出被采纳的比例、任务成功率。它做到的是结构合规，而不是效果优良。一个人格写得再规范，也可能在实际任务中产出平庸的结果，这也是本文提出测评方法论的直接动因；
• 专家幻觉的组织成本：把 200 多个人格当成"一支公司"来用，隐含了一个假设：用户清楚自己缺哪个角色，并且能正确编排协作顺序。但在真实工程中，选错角色、漏掉"现实检查员"这样的守门人、或者让两个重叠人格互相冲突，都是常见的失败模式。人格库降低了单点产出的门槛，却没有降低编排判断力的门槛，而后者才是更稀缺的能力；
• Star 数叙事的失真：不同来源给出的 Star 数（22k、40k、81k、111k、127k、146k）差异很大，多数来自不同统计时点或二手转述，不能当作项目真实影响力的硬证据。引用时应该标注时点并交叉验证。

这些问题指向同一个结论：结构合规不等于效果优良，只会用 skill 远远不够，还需要建立测评 skill 的方法论。

把视野放宽，agency-agents 并不是孤例。2026 年 Agent 工程有三条主线正在合流：

这三者的内核其实是一致的：把资深工程师和专家的判断力编码成机器可读、不可跳过的规则。Addy Osmani 说过一句话："AI coding agents are extremely capable junior engineers with no instinct for the parts of the job that don't show up in the diff. The job is to encode that discipline as something the agent cannot talk itself out of."

从这里可以反推出一套 Skill 测评方法论：不只是评它写得规不规范，更要评它能不能真的把活干好，而且不糊弄。

基于对这三个项目的拆解，我整理了一个六维测评框架。每个维度都可以转化为可执行的检查项，而不是主观感受。

维度一：结构完整性（Structure Completeness）

这个 skill 是否定义了人格、流程、交付物和成功指标？

检查项：是否包含身份、使命、关键规则、技术交付物、工作流、成功指标这六类必备章节；

参考：agency-agents 的九段模板和 CONTRIBUTING 的强制结构。缺少"成功指标"章节直接一票否决。

维度二：可测量性（Measurability）

它是否定义了"怎样算做完了"的量化标准？

检查项：Success Metrics 是否包含具体数值阈值，比如"Lighthouse > 90""加载 < 3s"，而不是"高质量""用户满意"这类空泛的词；

参考：agency-agents 把"完成"客观化的设计。无法量化的 skill 就无法被测评。

维度三：可验证性（Verifiability / Evidence over Claims）

它是否提供验证门和退出标准，要求 AI 先证明再声明完成？

检查项：是否包含 verification gate 和 exit criteria；是否把"测试通过""构建成功"作为完成的前提；

参考：agent-skills 的 verification gates（"Tests are proof"）、superpowers 的 "Evidence over claims"（对用户说"完成"之前先验证）。测评一个 skill 好不好，就看它有没有堵住"应该可以了""大概没问题"这类逃逸词。

维度四：原创性与不可替代性（Originality & Non-redundancy）

它是真的新专家，还是现有角色的换皮？

检查项：与现有人格和技能的概念重复率；是否只是"换平台名或换国家名"的重皮肤；

参考：agency-agents 的 check-agent-originality.sh（0.0–0.1% 阈值）加上人工概念查重。重复的 skill 会稀释整体效能，测评必须设定去重红线。

维度五：可移植性与渐进式披露（Portability & Progressive Disclosure）

它能否做到一次编写、多处运行，并且不污染上下文？

检查项：是否用 frontmatter 加纯 Markdown 表达，不绑定某个平台的专有格式；是否支持渐进式披露，核心部分保持精简，按需加载深层参考；

参考：agency-agents 的格式抽象层和 superpowers 的 SessionStart Hook 书签机制，后者可以避免一次性灌满上下文。测评一个 skill 的工程成熟度，就看它跨运行环境零改动和按需加载的能力。

维度六：反理性化（Anti-rationalization）

当 AI 想偷懒绕过规则时，这个 skill 有没有预设的封堵手段？

检查项：是否包含 red flags 和铁律（Iron Law）清单，列举 AI 可能用来跳过规则的借口并给出封堵方式；

参考：superpowers 的 anti-rationalization 表，比如"我先实现回头补测试"对应"删掉，先写测试"。这是测评 skill 硬度的最高标准：好的 skill 让 AI 无法通过自我合理化来违规。

把上面六个维度整理成一张可勾选的评测表，研究团队在引入或自建 skill 时可以直接用：

评分规则建议：第 1–4 项和第 8 项是硬门禁，任何一项不通过就整体不推荐；第 5–7 项和第 9 项是质量分；第 10 项是长期迭代信号，用来 A/B 比较不同 skill 版本的真实效果。

agency-agents 真正的启示不在于那 200 多个人格，而在于它无意中验证了三件事：

• 打包好的工作判断力，比裸模型更稀缺也更值钱；
• 结构合规可以用 CI 门禁保证，但效果优良必须靠测评，而当前整个生态恰恰缺后者；
• Skill 的终极形态不是提示词，而是不可跳过的工程纪律，包括 verification gate、anti-rationalization 和 evidence over claims。

对 AI 研究员来说，下一阶段最有价值的工作可能不是再写第 201 个专家人格，而是建立一套能把 skill 当实验对象、用运行期数据说话的测评体系。当 Star 数不再能代表能力，谁能把"这个 skill 到底好不好用"变成可测量、可比较、可迭代的指标，谁就握住了 Agent 工程化的真正护城河。

参考文献

1. https://github.com/msitarzewski/agency-agents
2. https://raw.githubusercontent.com/msitarzewski/agency-agents/main/engineering/engineering-frontend-developer.md
3. https://raw.githubusercontent.com/msitarzewski/agency-agents/main/CONTRIBUTING.md
4. https://addyosmani.com/blog/agent-skills/
5. https://github.com/addyosmani/agent-skills
6. https://agentmarketcap.ai/blog/2026/04/17/superpowers-121k-stars-workflow-layer-coding-agent
7. https://agentconn.com/blog/obra-superpowers-agentic-skills-framework-guide/
8. https://evermx.com/open-source/obra-superpowers-agentic-skills-framework-for-coding-agents
9. https://openllm.wavise.com/blog/agency-agents-complete
10. https://yuv.ai/blog/agency-agents
11. https://blog.mushroom.cv/blog/agency-agents-opensource-multi-model/
12. https://clauday.com/article/2efb8ca5-0848-4f71-b263-a08e020dd043