按你的角色选 division：agency-agents 不用一次全装
第一次翻开 agency-agents 这个仓库，很容易产生一种”全都要”的冲动：README 把它描述成一整间随身携带的 AI 事务所，./scripts/install.sh --tool claude-code 一条命令就能把整柜子人格搬进你的工具里。截至 2026-08-09 的 GitHub 快照，这个仓库有 140729 star、22985 fork、110 个 open issue——关注度确实高。但 star 数说明的是有多少人点了收藏，它不能推导出这批 agent 的质量、稳定性，更不能推导出它适配你手上这个项目。
所以这篇不打算按 division 逐个夸一遍，而是倒着来：从你的处境推到你该装哪几个。裸调用 install.sh 的语义是”把所有 team 装到所有检测到的工具”，而带 frontmatter 的 agent markdown 一共 255 个，分布在 17 个 division。往 ~/.claude/agents/ 这种共享目录一次性写进两百多个文件，是有代价的——上下文占用、工具启动时的加载、命名冲突都跑不掉。具体代价有多大我们没测过，不给数字；但”能不能少装点”这个问题，是值得在敲回车之前想三十秒的。
顺带先纠一个常见误读：仓库里 markdown 文件总数约 316，比 255 多出来的那部分是 README、CONTRIBUTING、strategy/ 下的编排文档、examples/ 之类的非 agent 文件。能装的是 255 个，不是 316 个。
第一个岔路：你的工具属于哪种 installKind
在讨论”挑哪个 division”之前，得先确认一件事——你的工具允不允许你挑。
tools.json 里收录了 16 种工具，每个工具都带一个 installKind 字段，它的 _note 把这个字段定义为安装机制，并且说明它是”上游真相，对每个消费方都成立”。一共三种：
| installKind | 产物形态 | 属于这一类的工具 |
|---|---|---|
per-agent | 每个 agent 渲染出一个文件或一个目录 | Claude Code、Codex、Gemini CLI、GitHub Copilot、Qwen Code、Cursor、opencode、Osaurus、Antigravity、Kimi、OpenClaw、Mistral Vibe、ZCode |
roster | 所有 agent 合并成一个文件 | Aider（CONVENTIONS.md）、Windsurf（.windsurfrules） |
plugin | 一个构建出来的产物，不能按 agent 渲染成字符串 | Hermes（唯一一个） |
这张表就是第一道分流。如果你在 Aider 里琢磨”怎么只装 Code Reviewer 一个”，答案不在参数里，在产物形态里：roster 的输出本来就不是一 agent 一文件，它把花名册压成一份 CONVENTIONS.md。Windsurf 的 .windsurfrules 同理。Hermes 的 plugin 更极端——它是一个构建产物，只能走命令行，官方 app 也装不了。
所以：只有 per-agent 的工具，“按 division 收窄”这件事才谈得上。 用 roster 类工具的人，该想的是另一个问题——这份合并文件里塞多少人格是你愿意让它每次都参与的，而不是怎么筛。
另外提一句 format 字段的契约：tools.json 的 _note 说同一个 format 名保证渲染出字节级相同的输出。这就是 claude-code 和 copilot 都用 identity、osaurus 和 antigravity 都用 skill-md 的原因。_note 最后一句也要如实带出：渲染器覆盖面是消费方自己的事，目录本身不携带任何 app 发布状态。
第二个岔路：装进家目录，还是装进这个项目
第二个决定比”挑哪个 division”更影响你的日常。
install.sh 的注释里列出了各工具的落点，其中有一个很容易被扫过去的差别：opencode、cursor、aider、windsurf 这四个写的是”当前目录”，而 claude-code（~/.claude/agents/）、codex（~/.codex/agents/）、gemini-cli（~/.gemini/agents/）、osaurus（~/.osaurus/skills/）、openclaw（~/.openclaw/agency-agents/）等多为家目录。qwen、zcode 则同时给了用户级与项目级两种写法。
这个差别决定了两件事：
- 你在哪个目录敲命令很重要。 落点是”当前目录”的工具，你在哪个项目根下执行，文件就写在哪个项目里；跑错目录会把规则文件撒进不相干的仓库。
- 收窄的必要性不一样。 装进当前项目的，天然被项目边界圈住了，多装几个 division 影响范围可控；装进家目录的，是给整个账户装，之后每个项目都带着——这种才是真正需要克制的。
顺便说一个坑：tools.json 里 opencode 的用户级路径是 .config/opencode/agents/{slug}.md，而 install.sh 注释写的是当前目录的 .opencode/agents/。这两处分别对应不同 scope，不是矛盾。要断言某个具体路径，回源文件核对当前是哪个 scope，别混着说。
如果你想强行指定目标，--path <dir> 可以覆盖安装目录，但它只接受单一目标。另外 install.sh 还会在硬编码默认值之前检查一批环境变量：CLAUDE_CONFIG_DIR、COPILOT_AGENT_DIR、CURSOR_RULES_DIR、GEMINI_AGENTS_DIR、OPENCODE_AGENTS_DIR、OPENCLAW_DIR、QWEN_AGENTS_DIR、CODEX_AGENTS_DIR、OSAURUS_SKILLS_DIR、HERMES_HOME、HERMES_PLUGIN_DIR、VIBE_HOME。习惯用非默认配置目录的人，先设变量比事后搬文件省事。
第三个岔路：按角色对 division
到这一步才轮到”选哪几个”。先把规模摆出来，因为 division 之间的体量差得很远：
| division | 展示名 | agent 数 |
|---|---|---|
engineering | Engineering | 58 |
specialized | Specialized | 57 |
marketing | Marketing | 36 |
gis | GIS | 13 |
security | Security | 12 |
design | Design | 10 |
sales / testing | Sales / Testing | 各 9 |
paid-media / project-management | Paid Media / Project Management | 各 7 |
academic / game-development / spatial-computing / support | Academic / Game Development / Spatial Computing / Support | 各 6 |
finance / product | Finance / Product | 各 5 |
healthcare | Healthcare | 3 |
读这张表的要点是：engineering 加 specialized 两个就占了 115 个，接近总量的一半。也就是说，“我是个写代码的，那就装 engineering 吧”这个看似保守的选择，实际上一口气装了 58 个。
怎么对到角色上？这里只能按 divisions.json 给出的 label 语义做对应，不能承诺效果——我们一个 agent 都没有运行过，所有”适不适合你”的判断只能你自己在提示词正文里读出来。可用的起手组合大致是这样：
- 只写业务代码的独立开发者：
engineering起手就够了。想再收一层，直接跳到下一节用--agent点名。 - 要交付前端界面的：
engineering+design。design只有 10 个，代价小。 - 对交付质量负责的（自测、回归、上线前把关）：
testing9 个，体量很轻，值得单独加。 - 要过安全审查或合规的：
security12 个。 - 一人多岗、还要写文案和落地页的：
marketing36 个是个不小的增量，建议先用--agent点名而不是整个 division 拖进来。 - 做需求与排期的：
product（5）+project-management（7），加起来 12 个，是全表里性价比最直观的一组。 - 领域强相关的：
gis、healthcare、game-development、spatial-computing、finance、academic这几个，不在你的领域里就别装——它们不会因为多装而”备用”，只会占位置。
specialized 这个名字最有迷惑性：57 个，仅次于 engineering，但”专门化”具体专门在哪，只能逐个看 agent 的 description 才知道。不建议闭着眼睛整包装。
收窄的三个粒度，以及先跑 --dry-run
install.sh 的调用形式是 ./scripts/install.sh [selection] [mode] [behavior]，选择器可以自由组合，全空就是全装：
| 参数 | 含义 |
|---|---|
--tool <a,b> | 只装这些工具 |
--division <a,b> | 只装这些 division |
--agent <slug,slug> | 只装指定 agent |
--agents-file <path> | 从文件读 agent 列表，每行一个 slug 或名字，支持 # 注释 |
三个粒度从粗到细：工具 → division → 单个 agent。团队里想统一一份清单，用 --agents-file 最合适，因为它能进版本库，而且支持 # 注释——你可以在每行后面写清楚为什么留着这一个。
在真正落盘之前，先加 --dry-run。它只打印计划、不写任何东西，是这个仓库对新手最有价值的一个开关。往共享目录写两百多个文件这种事，看一眼计划再决定，成本几乎为零：
# 先列一遍可选项，确认名字没写错
./scripts/install.sh --list tools
./scripts/install.sh --list agents
# 只给 Claude Code 装工程与测试两个 division，先看计划不落盘
./scripts/install.sh --tool claude-code --division engineering,testing --dry-run
# 计划没问题了，去掉 --dry-run 真装
./scripts/install.sh --tool claude-code --division engineering,testing
# 或者按点名清单装，清单文件放进你自己的项目里
./scripts/install.sh --tool claude-code --agents-file <你的项目目录>/agents.txt
以上为按官方参数语义组合的示例，未逐项实测，以官方文档与 ./scripts/install.sh --help 的实际输出为准。
还有几个行为开关值得知道：--no-convert 关掉”集成文件缺失时自动跑 convert.sh”；--parallel 并行装各工具、输出按工具缓冲，--jobs N 控制最大并行数（默认 nproc 或 4）；--interactive / --no-interactive 控制交互向导，终端里默认是开的。--link 用符号链接代替拷贝，改动会自动传播——这一条是双刃：跟着上游走确实省事，但你本地改过的内容和仓库更新之间的关系也变复杂了，装在共享目录时尤其要想清楚。
Windows 用户注意：脚本注释里写的支持平台是 Linux、macOS（需要 bash 3.2+）、Windows 的 Git Bash / WSL。别在 PowerShell 里直接敲。
两个”装完像没装”的坑
第一个：Cursor 的转换产物 alwaysApply 是写死的 false。convert.sh 渲染 .mdc 时，frontmatter 固定是 description + globs: "" + alwaysApply: false。也就是说转出来的规则默认不会自动生效，得在 Cursor 里按需引用。装完感觉”一点反应都没有”，先查这一条，别急着怀疑 division 选错了。
第二个：integrations/ 是产物目录，不是源目录。install.sh 从 integrations/ 读取已转换的文件再拷到各工具配置目录，divisions.json 的 _note 也明确把 integrations/、strategy/、examples/、scripts/ 排除在 division 之外。想改提示词要改源 agent markdown 然后重新 convert，直接编辑 integrations/ 下的文件会在下次转换时被盖掉。另外 strategy/ 里放的是 playbook 和 runbook，没有 agent frontmatter，是编排方法论不是可安装 agent——按 division 挑的时候不用惦记它。
哪些维度我们不比
选型文章最该说清楚的，是自己的边界：
- 效果、产出质量、“用了提效多少”——不比。 我们只读了仓库文件，没有安装或运行过其中任何一个 agent，没有任何依据。
- agent 提示词里的自述（比如”You’ve built and deployed ML systems at scale”这类句子）是写给模型的人设文本，不是任何人的真实履历，更不构成能力背书。挑 agent 时它只能当风格参考。
- star 数不参与选型。 140729 这个数字是 2026-08-09 的快照，只说明关注度。
- 各 division 之间谁”更成熟”——官方没给这个维度的数据，我们不比。 表里的 agent 数只反映数量，不反映成色。
- 正文词数（花名册导出里每个 agent 后面那个”~N 词”）也只是长度，长不等于好用。
最后给一条兜底建议：如果你实在拿不准，就从”当前项目目录”这一侧起步——用落点在项目里的工具试，或者用 --path 指到一个临时目录，观察一段时间再决定要不要往家目录铺。装进 ~/ 的东西，清理成本永远比装进项目里的高。
延伸阅读
本文依据 agency-agents 官方仓库（github.com/msitarzewski/agency-agents）的 README、tools.json、divisions.json、scripts/ 下的安装与校验脚本整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装或运行过其中任何 agent。目录、脚本与安装路径随上游更新而变动，请以仓库最新内容与 ./scripts/install.sh --help 的实际输出为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。