Startup MVP runbook：9 个常驻 agent 加两组按需

2026-08-09

agency-agents 这个仓库里有 255 个带 frontmatter 的 agent，分布在 17 个 division。第一次翻它的人几乎都会卡在同一个问题上：知道东西多，但不知道该装哪些。全装是最省事的选择，也是最容易后悔的选择——255 份提示词一次性铺进全局配置目录，命名冲突、上下文占用、以后想删都不知道从哪删起。

仓库自己给了一个更克制的答案：strategy/runbooks.json。它不是文档，是一份机器可读的团队名单，四个场景各一份。本文只讲其中的 startup-mvp，把它从一份 JSON 变成一条你能直接跑的安装命令。

这份名单里到底有谁

runbooks.json 里 startup-mvp 的标题是 Startup MVP Build，mode 字段是 NEXUS-Sprint，duration 字段写的是 4-6 weeks，doc 指向 strategy/runbooks/scenario-startup-mvp.md。周期数字是文档给出的建议区间——NEXUS 的模式表里 NEXUS-Sprint 本身标的是 15–25 个 agent、2–6 周——它既不是实测数据也不是承诺，别拿去写进项目排期。

roster 分三组，18 个 slug：

分组	`activation`	slug
Core Team	`always`	`agents-orchestrator`、`project-manager-senior`、`product-sprint-prioritizer`、`design-ux-architect`、`engineering-frontend-developer`、`engineering-backend-architect`、`engineering-devops-automator`、`testing-evidence-collector`、`testing-reality-checker`
Growth Team	`week 3+`	`marketing-growth-hacker`、`marketing-content-creator`、`marketing-social-media-strategist`
Support Team	`as needed`	`design-brand-guardian`、`support-analytics-reporter`、`engineering-rapid-prototyper`、`engineering-ai-engineer`、`testing-performance-benchmarker`、`support-infrastructure-maintainer`

九人常驻这一组的构成值得多看两眼：一个编排者、一个项目经理、一个优先级排序者、一个 UX 架构、前后端加 DevOps 各一，然后两个测试位。花名册里 testing-evidence-collector 的自述是「要视觉证据才肯放行」，testing-reality-checker 的自述是「默认结论 NEEDS WORK」。一支只有九人的 MVP 常驻团队肯掏出两个名额给「不许糊弄过去」，这个配比本身就是这份 runbook 想传达的态度。

另外注意 agents[] 里放的是 slug，也就是 agent .md 文件的文件名主干，不是显示名。runbooks.json 的 _note 把理由写得很直白：文件名主干并不总带 division 前缀，而显示名带前缀、会漂移，所以一律引用 slug —— slug 抗改名、可测试，仓库还配了 scripts/check-runbooks.sh 去守住「每个 slug 都能解析到真实 agent 文件」。这条经验可以直接搬到自己项目里：跨文件引用只引稳定 id，别引展示名。

第一步：把名单落成一个 agents-file

install.sh 的选择器里有 --agents-file <path>，从文件读 agent 列表，每行一个 slug 或名字，支持 # 注释。这正好对应 runbook 的分组结构。在你的项目目录下建一个 nexus-startup-mvp.txt：

# startup-mvp / Core Team (activation: always)
agents-orchestrator
project-manager-senior
product-sprint-prioritizer
design-ux-architect
engineering-frontend-developer
engineering-backend-architect
engineering-devops-automator
testing-evidence-collector
testing-reality-checker

# Growth Team (activation: week 3+) —— 先注释掉，第三周再放开
# marketing-growth-hacker
# marketing-content-creator
# marketing-social-media-strategist

# Support Team (activation: as needed)
# design-brand-guardian
# support-analytics-reporter
# engineering-rapid-prototyper
# engineering-ai-engineer
# testing-performance-benchmarker
# support-infrastructure-maintainer

为什么要靠注释分批：install.sh 的选择器只有 --tool / --division / --agent / --agents-file 四个维度，没有一个是认 activation 的。week 3+ 和 as needed 是写给人和给 app 看的标注，脚本不认识它。所以分批的责任在你——要么像上面这样用 # 控制放开节奏，要么干脆维护三份文件分次执行。

第二步：先 dry-run，再落盘

# 1) 先看仓库认得哪些 agent，确认 slug 拼写没错
./scripts/install.sh --list agents

# 2) 只打印计划，不写任何东西
./scripts/install.sh --tool claude-code --agents-file ./nexus-startup-mvp.txt --dry-run

# 3) 计划没问题再真装
./scripts/install.sh --tool claude-code --agents-file ./nexus-startup-mvp.txt

逐个说这几个选项为什么在这：

--list agents 列出后直接退出，用来在动手前核对 slug。名单里写错一个字符，后面所有步骤都是白跑。
--tool claude-code 把目标收窄到一个工具。裸调用 install.sh 等于把所有 team 装到所有检测到的工具，第一次用别这么干。
--agents-file 而不是 --agent a,b,c：18 个 slug 塞进一行命令既难读也难改，落成文件还能进版本库，团队里谁改了名单有 diff 可查。
--dry-run 是这个仓库对新手最有价值的开关。它把安装计划打出来但不落盘，在往 ~/.claude/agents/ 这种共享目录写文件之前先看一眼，成本几乎为零。

另外几个按需的开关：--link 用符号链接代替拷贝，仓库更新会自动传播，适合你打算跟着上游走；--path <dir> 覆盖安装目录，只对单一目标生效；--no-convert 关掉「集成文件缺失时自动跑 convert.sh」的行为；--parallel 配 --jobs N 控制并行安装多个工具时的并发数，默认取 nproc 或 4。

以上为按官方参数语义组合的示例，未逐项实测，以官方文档与 ./scripts/install.sh --help 的实际输出为准。

Windows 侧：install.sh 的脚本注释里写明支持 Linux、macOS（需要 bash 3.2+）和 Windows 的 Git Bash / WSL。也就是说不要在 PowerShell 或 cmd 里直接调它，开 Git Bash 或进 WSL 再执行。

产出物会落在哪

这部分只讲我们有依据的：路径模板与安装机制来自 tools.json 与 install.sh 的注释。

Claude Code 的 installKind 是 per-agent，路径模板是 .claude/agents/{slug}.md，用户级落点写在 install.sh 注释里是 ~/.claude/agents/。按上面那份只放开 Core Team 的名单，对应的就是 9 个 .md 文件，文件名主干与你写进 agents-file 的 slug 一致。想换个位置，install.sh 会在硬编码默认值之前先读环境变量 CLAUDE_CONFIG_DIR。

如果你把 --tool 换成别的，有两处特别容易踩：

Cursor 的转换产物写死了 alwaysApply: false 和 globs: ""。也就是说 .cursor/rules/{slug}.mdc 装进去以后默认不会自动生效，得在 Cursor 里按需引用。装完觉得「像没装」，先去看这一行。
Aider 和 Windsurf 的 installKind 是 roster，所有 agent 合并成一个文件（CONVENTIONS.md / .windsurfrules），产物形态就不是一 agent 一文件。在这两个工具上「只装九个人」这件事的表现形式跟 Claude Code 完全不同。

还有个 scope 的坑：install.sh 注释里 opencode、Cursor、Aider、Windsurf 写的是当前目录，其余多为家目录。执行前先确认自己站在哪个目录，别把项目级的东西装进账户级。

怎么验收

装完人工检查这四处：

文件数量与文件名：去目标目录列一遍，文件名主干应当与 agents-file 里放开的那几行一一对应。多了说明你没收窄工具或没收窄名单，少了多半是 slug 拼错——回到 --list agents 重新核。
有没有装进错的 scope：家目录和项目目录各看一眼，尤其是你同时用了 Cursor 或 opencode 的时候。
integrations/ 是不是新鲜的：install.sh 从 integrations/ 读已转换的文件，缺失或过期时默认会先调 convert.sh。如果你为了省事加了 --no-convert，就得自己确认产物是最新的。
上游改名有没有让 slug 失效：runbooks.json 的名单和仓库里的 agent 文件是两处，靠 scripts/check-runbooks.sh 这类校验来保证每个 slug 都能解析到真实文件。你自己维护的 agents-file 不在仓库校验范围内，上游拉新之后值得再跑一遍 --list agents 对一遍。

最容易出错的一步是第一步就跳过 --dry-run 直接装全量，然后在一个混着两百多个文件的目录里找不到自己刚才装了什么。

什么情况别照这份名单装

你不是在做 MVP。 这份 roster 是按「从零到上线」的形态配的，前后端、DevOps、UX 架构各一个。如果你手上是往成熟产品里加一个功能，或者在处理线上故障，runbooks.json 里另有 enterprise-feature 和 incident-response 两份名单，后者用的是 NEXUS-Micro 模式，别拿 MVP 的名单硬套。
你是一个人写代码。 九个常驻角色意味着九份长提示词同时躺在配置目录里，命名和上下文都要占地方。个人项目更适合先只装两三个真正会用到的，用 --agent 直接点名。
你以为装完就有流程了。 必须说清楚：NEXUS 是一套写在 markdown 里的方法论，不是可执行的调度器。阶段顺序、质量门、交接模板全靠提示词让模型自己按部就班，仓库里没有任何代码在强制执行它们。装完这 18 个文件，你得到的是 18 份提示词，不是一条流水线；谁在什么时候被激活、上一步的产出有没有真的交到下一步，仍然要人来盯。
你需要的是评估而不是安装。 README 自己列的第三种用法就是「当参考资料用」——不装，直接读这些提示词是怎么写的。想学 agent 提示词的组织方式，这条路径比装一堆文件划算。

最后提醒一句关于 agent 自述的事：花名册里那些「Senior backend architect」「Screenshot-obsessed QA」是写给模型的人设文本，用来给输出定调，不是对任何真实履历的陈述，也不构成对产出质量的保证。装进去之后该验的还得验。

延伸阅读

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