17 个 division 与那四个「不是 division」的目录

2026-08-09

第一次 clone 完 agency-agents，最容易犯的错是把仓库根目录下的文件夹数一遍，然后当成「它有多少个分类」。数出来的数字一定不对。这个仓库的顶层目录里，有一部分是真正的 agent 分类（仓库自己叫 division），有一部分是脚本产物、方法论文档和示例，它们长得跟 division 一模一样，但里面一个可安装的 agent 都没有。

分不清这件事的代价很具体：你会把 integrations/ 里的东西当成源 agent 去改，改完下次跑转换脚本就被覆盖；你会以为 strategy/ 里有一批可以直接激活的编排 agent，结果拷进配置目录之后什么都没多出来。

先看这张表：17 个 division 和它们的规模

以 2026-08-09 核对的仓库内容为准，带 frontmatter 的 agent markdown 共 255 个，分布在 17 个 division 里：

目录	divisions.json 里的展示名	agent 数
`engineering`	Engineering	58
`specialized`	Specialized	57
`marketing`	Marketing	36
`gis`	GIS	13
`security`	Security	12
`design`	Design	10
`sales`	Sales	9
`testing`	Testing	9
`paid-media`	Paid Media	7
`project-management`	Project Management	7
`academic`	Academic	6
`game-development`	Game Development	6
`spatial-computing`	Spatial Computing	6
`support`	Support	6
`finance`	Finance	5
`product`	Product	5
`healthcare`	Healthcare	3

这张表最该读出来的不是「有哪些方向」，而是它极度不均匀。前三个 division 加起来 151 个，占了 255 的一多半；而从 sales 往下数，有十一个 division 的 agent 数是个位数。这个分布直接决定了后面所有操作策略：对 healthcare（3 个）这种目录，你完全可以把三个文件都打开读一遍再决定；对 engineering（58 个）和 specialized（57 个），任何「整个目录先装上再说」的动作都是把一大坨提示词一次性倒进你的工具配置里。

顺带纠正一个很容易传错的数字：仓库里的 markdown 文件总数大约 316，但那不是 agent 数。差额是 README、CONTRIBUTING、strategy/ 下的编排文档、examples/ 里的示例这些没有 agent frontmatter 的文件。看到「316 个 agent」的说法就是把文件树统计当成花名册了，真实数字是 255。

division 的认定标准是机械的，不是编辑决定的

divisions.json 里有一个 _note 字段，明确写了：并非每个顶层目录都是 division。仓库把这条规则落到了脚本里——scripts/check-divisions.sh 用一个 NON_DIVISION_DIRS 列表做排除，被排除的四个目录是：

integrations/ —— scripts/convert.sh 写出的每工具转换产物。这里面的文件是从各 division 的源 agent 转换来的，不是源 agent 本身。
strategy/ —— 放 playbook 与 runbook，没有 agent frontmatter。它是编排方法论，不是可安装的 agent。
examples/ —— 示例。
scripts/ —— 脚本本身。

排除之外，判定规则只有一条：一个目录要成为 division，必须至少包含一个带 frontmatter 的 agent 文件。

这条规则很朴素，但它是你后面所有判断的依据。当你不确定某个目录该怎么对待时，判断动作是固定的：打开里面任意一个 .md，看开头有没有 YAML frontmatter。有，它就是 agent 源文件，能被安装脚本处理；没有，它就是人读的文档，拷到 ~/.claude/agents/ 里也不会变成一个可激活的角色。

这也解释了为什么 strategy/ 特别容易被误会。它的名字听起来像「战略部门」，内容也确实在讲多个 agent 怎么配合，但它是写给你看的方法论，不是写给模型加载的人格文件。想按它说的做，你得自己去把对应的 agent 找出来激活，strategy/ 目录本身安装不了。

同理，integrations/ 是下游不是上游。你在里面看到的每一份文件都有一个 division 里的源头。要改提示词，改源目录里的那份；改 integrations/ 里的副本，等于在改一个随时会被重新生成覆盖掉的中间产物。

目录名不等于题材：三个容易踩的坑

看完结构，真正影响你日常怎么找 agent 的是下面这几件事。它们在目录树上看不出来，得翻花名册才知道。

第一，specialized 是个兜底桶，不是一个方向。 别的 division 里 slug 大多带目录前缀，比如 engineering-backend-architect、security-appsec-engineer、gis-web-gis-developer，一眼就能看出属于谁。specialized 这 57 个里前缀完全不统一：既有 specialized-mcp-builder、specialized-codebase-archaeologist 这种带前缀的，也有 zk-steward、study-abroad-advisor、supply-chain-strategist、grant-writer 这种直接裸命名的。这意味着你没法靠 slug 前缀反推它在哪个 division，反过来也没法靠目录名预判里面有什么。

第二，题材会跨目录。 healthcare 这个 division 只有 3 个 agent（healthcare-clinical-evidence-agent、healthcare-innovation-strategist、healthcare-sovereign-health-systems-agent），但 specialized 里还躺着另外三个 slug 同样以 healthcare- 开头的：healthcare-customer-service、healthcare-marketing-compliance、healthcare-aging-parent-care-companion。也就是说，光看 slug 前缀就能认出是医疗题材的一共六个，只有一半在 healthcare 目录里。如果你的判断动作是「我要找医疗相关的，去 healthcare 目录」，另一半你根本不会遇见。

第三，前缀缺失不止 specialized 一处。 game-development 里是 game-designer、level-designer、narrative-designer、economy-designer、technical-artist 这类无前缀命名；spatial-computing 里是 visionos-spatial-engineer、xr-immersive-developer、terminal-integration-specialist。所以「slug 前缀 = division」这个规律在多数 division 成立，但它不是仓库强制的约定，别拿它当检索依据。

结论是：目录结构适合用来判断规模和安装粒度，不适合用来做题材检索。 要按题材找 agent，正确的动作是回完整花名册按 name / description 搜关键词，而不是照着 17 个目录名猜。凭印象编一个 agent 名字然后去 cp 它，大概率什么都拷不到。

那么装的时候按什么粒度来

README 的 Quick Start 给了三种用法，落到 division 结构上，判断路径大致是这样：

想要全量、并且不介意工具里多出几百个角色，走官方 app 或者安装脚本。README 把 app 标为 Recommended：那是一个 macOS / Linux / Windows 的原生程序（仓库 msitarzewski/agency-agents-app，站点 agencyagents.app），按 README 的说法能浏览整个花名册并一键装进 Claude Code、Cursor、Codex、Gemini、Osaurus 等工具，还会自动更新，macOS 侧给的是 brew install --cask msitarzewski/agency-agents/agency-agents。我们没有下载或运行过这个 app，这里只转述 README 的说法，界面长什么样、装完是什么体验，本文不做描述。

不装 app 就用脚本：

./scripts/install.sh --tool claude-code

装完之后怎么用，README 给的激活示例原文是 "Hey Claude, activate Frontend Developer mode and help me build a React component"——也就是用自然语言点名，而不是执行某条命令。这也从侧面说明了为什么前面那条「有没有 frontmatter」的判断这么关键：能被点名激活的前提，是这份 markdown 被当作 agent 处理过。

只想要某一个方向，README 给的是按 division 整目录拷：

cp engineering/*.md ~/.claude/agents/

这条命令本身没问题，但把它和上面那张分布表放一起看就知道要挑对象：拷 healthcare（3 个）、finance（5 个）、product（5 个）这种小 division，代价可以忽略；拷 engineering 是一次性灌 58 个，拷 specialized 是 57 个，而后者内部题材还是散的。在大 division 上，「整目录拷」是个钝器——你想要的可能只有三五个，剩下的五十多个会一直躺在你的配置目录里。这种情况下按单个文件拷、或者先在花名册里选定 slug 再拷，反而更省事。

第三种用法是根本不安装，把这批 markdown 当提示词写法的参考资料读。对 strategy/ 这种没有 frontmatter 的目录来说，这其实是唯一的用法。

以上命令原样取自仓库 README 的 Quick Start，我们没有安装或运行过其中任何 agent，实际选项以 ./scripts/install.sh --help 的输出为准。

几个别搞混的点

divisions.json 里除了展示名，还给每个 division 配了 Lucide 图标名和品牌色（比如 engineering 是 Code 加 #3B82F6，gis 是 Map 加 #14B8A6）。这套元数据是给展示界面用的，跟安装行为无关——它不影响哪些文件会被拷贝，也不影响 agent 能不能被激活。要用到具体某个 division 的图标或色值，回 divisions.json 现查，别照别人文章里抄。

另外，agent markdown 正文里那种「你曾经在大规模生产环境里部署过 ML 系统」式的句子，是写给模型看的人设设定，用第二人称对模型说话，让它进入某个角色。它不是任何真实的人的履历，也不是对这个 agent 产出质量的承诺。读到这类句子时别当成能力背书，把它当提示词读：它告诉你的是作者希望模型摆出什么姿态，而不是模型实际能做到什么。

最后一个数字：这个仓库在 2026-08-09 的快照里有 140729 star、22985 fork、110 个 open issue，仓库标注为 MIT。star 数说明关注度，不说明它适配你的项目、也不说明其中任意一个 agent 的输出质量——这两件事只能靠你自己读那份提示词、自己试。许可条款以官方 LICENSE 原文为准。

延伸阅读

本文依据 agency-agents 官方仓库（github.com/msitarzewski/agency-agents）的 README、 tools.json、divisions.json、scripts/ 下的安装与校验脚本整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装或运行过其中任何 agent。目录、脚本与安装路径随上游更新而变动，请以仓库最新内容与 ./scripts/install.sh --help 的实际输出为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。