Full、Sprint、Micro：三种模式各自适合什么活

2026-08-09

打开 agency-agents 的 strategy/QUICKSTART.md，NEXUS 三种模式的表格几行就看完了：Full 用全部 agent，Sprint 用 15–25 个，Micro 用 5–10 个。看完你大概率还是不知道自己手头这个活该选哪个——因为表格里那一列「适用场景」写的是「企业级产品发布」「功能开发、MVP 构建」「Bug 修复、内容战役、单一交付物」，这些词太大，落不到具体的活上。

这篇就干一件事：把选模式这个决定拆成几条能自己判断的依据。

先把「模式」是什么讲清楚，不然会选错

NEXUS 全称是 Network of EXperts, Unified in Strategy（QUICKSTART.md 里的原文展开）。它在仓库里的位置是 strategy/ 目录，而 divisions.json 的 _note 明确写了一句：strategy/ holds orchestration doctrine, not installable agents——这个目录里没有一个可安装的 agent，它是方法论文档加上机器可读的团队配置。

所以「切换模式」这个动作，不是在某个控制台上拨一个开关，而是你在激活提示词里写下的一个词。QUICKSTART.md 给的 NEXUS-Full 激活提示词第一行就是：

Activate Agents Orchestrator in NEXUS-Full mode.

后面跟着项目名、规格说明，以及 Phase 0 到 Phase 6 每个阶段点名参与的 agent 清单，最后两句是全篇的设计意图：Quality gates between every phase. 和 Evidence required for all assessments.

这个事实决定了你该怎么看待这三种模式：没有任何代码在强制执行阶段顺序，也没有任何代码在拦住不合格的产出。 阶段推进、质量门、交接契约，全靠这套提示词让模型自己按部就班。它不是一个编排引擎，也不是自动化框架，是一份写在 markdown 里、需要你和模型共同遵守的工作方法。

想明白这一点，选模式的性质就变了：你不是在选一档算力，而是在选你愿意为这次协作维持多大的流程开销。开销全部由你和模型的上下文承担。

三种模式的原始参数

模式	参与 agent 数	文档给的适用场景	文档建议周期
NEXUS-Full	All（全部）	企业级产品发布、完整生命周期	12–24 周
NEXUS-Sprint	15–25	功能开发、MVP 构建	2–6 周
NEXUS-Micro	5–10	Bug 修复、内容战役、单一交付物	1–5 天

这张表要这么读：右边那一列是文档建议的时间尺度，不是承诺，也不是任何人跑出来的数据。 别把「NEXUS-Sprint，2–6 周」理解成「用 Sprint 模式两到六周能做出 MVP」——文档表达的是「这个模式的流程重量，是按两到六周的活来设计的」。周期在这里是流程规格的单位，不是交付预期。

中间那一列同理。15–25 不是一个你要凑齐的数字，是这套阶段划分在实际展开时大致会牵扯到的规模。

判断依据一：先看交付物是一个还是一串

三种模式最干净的分界线在交付物形态，而不在难度。

只有一个交付物——修一个 bug、写一篇内容、出一份报告、加一个孤立的接口——落 Micro。这类活的特征是：做完就结束了，不需要下一阶段接着往前推。

一串交付物，但共享同一套约束——一个功能从设计到上线，或者一个 MVP——落 Sprint。特征是有明确的前后依赖：得先有架构决定，才谈得上写代码；得先有代码，才谈得上测试。这正是阶段划分开始产生价值的地方。

多条产品线并行、要覆盖完整生命周期，包括上线之后的运营——才轮到 Full。注意 Phase 6 叫 Operate & Evolve，它是持续的，不是一个能勾掉的框。你如果没打算真的走到运营阶段，选 Full 只是给自己在前面几个阶段加了一堆用不上的仪式。

一个反过来的检查：如果你说不出这个活的第二个交付物是什么，就不该往 Sprint 以上走。

判断依据二：官方自己的四个 runbook，一个 Full 都没有

这条是我认为最有说服力的依据，而它藏在 runbooks.json 里，不在那张模式表上。

仓库给了四个可直接照搬的场景 runbook：

runbook slug	场景	模式
`startup-mvp`	Startup MVP Build	NEXUS-Sprint
`enterprise-feature`	Enterprise Feature Development	NEXUS-Sprint
`marketing-campaign`	Multi-Channel Marketing Campaign	NEXUS-Sprint
`incident-response`	Incident Response	NEXUS-Micro

三个 Sprint，一个 Micro，没有一个 runbook 用 NEXUS-Full。连名字里带 Enterprise 的那个「企业级功能开发」都是 Sprint。

这意味着什么？项目作者在把方法论固化成可复用配置的时候，实际落笔的都是中小档。Full 更像是这套体系的完整形态描述——它把七个阶段、17 个 division、255 个 agent 的关系交代完整，是一张全景图；但当要给出「照着做」的具体方案时，落地口径是 Sprint 和 Micro。

所以你的默认档位应该是 Sprint，Micro 是常态，Full 需要额外理由。如果你正犹豫要不要上 Full，先问一句：官方连企业级功能开发都没用它，我这个活凭什么？

判断依据三：roster 的分组，说明规模是可以分批放的

四个 runbook 的 roster 都带 activation 字段，保留了阶段结构。以 startup-mvp 为例，它的 agent 分成三组：always（9 个）、week 3+（3 个）、as needed（6 个）。always 组里有 agents-orchestrator、project-manager-senior、product-sprint-prioritizer、design-ux-architect 这些。

这个结构给了一条很实用的操作依据：参与 agent 数不是一次性投进去的。 一个 Sprint 档的 runbook，起手真正常驻的可能只有九个，另外那些要么等到第三周，要么等到确实需要才拉进来。

于是选模式的焦虑就小了很多。你不必在开工前精确判断这个活是 18 个 agent 还是 23 个 agent 的量级——你需要判断的是起手常驻组该有谁。剩下的按需追加。这也解释了为什么模式表给的是区间而不是定值。

反过来，这也是 Full 的真实代价所在：always 组一旦铺开，每一轮对话都要携带这些角色的上下文。同时激活十几二十个 agent 会带来实实在在的上下文与成本压力，这一点文档没有量化，我也不打算给你一个编出来的数字，但方向是确定的：规模的代价是每一轮都在付，不是开工时付一次。

判断依据四：Micro 不等于「省掉后面的步骤」

很多人把 Micro 理解成「简化版」——只做修复，跳过验证。incident-response 这个 runbook 恰好给了反例。

它的 always 组是 6 个，包含 support-infrastructure-maintainer、engineering-devops-automator、engineering-backend-architect、engineering-frontend-developer 等；而在这之后还单独挂了一个 post-fix 组，4 个：testing-evidence-collector、testing-api-tester、testing-workflow-optimizer、product-sprint-prioritizer。

翻译成人话：取证、回测接口、优化流程、重排优先级——这四件事被明确安排在修复完成之后，而且是一个独立分组。 修完不算完。

testing-evidence-collector 的存在还呼应了激活提示词里那句 Evidence required for all assessments.：这套方法论不接受「我觉得修好了」，要求评估必须有证据。所以 incident-response 这十个 slug（always 6 个加 post-fix 4 个）里，有四个并不是用来干活的，是用来确认活干完了的。

如果你选了 Micro 却把 post-fix 这一组砍掉，那你选的其实不是 NEXUS-Micro，是「让一个 agent 帮忙改个 bug」——那没问题，只是别管它叫 NEXUS。

一条可以直接照着走的判断路径

把上面几条串起来：

数交付物。 只有一个 → Micro；一串且有前后依赖 → Sprint；多条线并行且要管到运营 → 才考虑 Full。
找有没有对得上的 runbook。 四个场景里对上任何一个，直接用它的模式和 roster，别自己重新设计分组。
对不上时默认 Sprint。 官方的落地口径就在这一档。
定起手 always 组，而不是定总数。 剩下的按 week 3+ / as needed 的思路追加。
确认收尾环节还在。 尤其是 Micro，post-fix 那一组是这个模式的一部分，不是可选项。
想上 Full 时，先说服自己。 理由必须是「我确实要走到 Phase 6 并持续运营」，而不是「这个项目挺重要的」。

几句必须说清楚的限制

模式与阶段划分是建议，不是约束。整套 NEXUS 靠提示词生效，你写 NEXUS-Sprint 也好 NEXUS-Micro 也好，没有任何机制会检查你是否真的按那个规模、那个周期在做事。质量门同理——它写在提示词里，能不能拦住东西取决于模型和你自己。

runbooks.json 的 _note 里提到它的用途是给 app 把一个 runbook 变成「一键部署一个团队」：读 roster、把每个 slug 映射到目录里的 agent、整组安装。也就是说，「切模式」在工具层面的实际动作，是往 ~/.claude/agents/ 这类目录里装进一组不同的 markdown，仅此而已。装了哪些人，和这些人能不能配合好，是两件事。

最后，本文引用的每一个 agent slug 都是从 runbooks.json 与花名册导出里核对过的文件名主干（比如 specialized/agents-orchestrator.md 对应 agents-orchestrator）。scripts/check-runbooks.sh 就是用来守住「每个 slug 都能解析到真实 agent 文件」这条线的。你自己拼 roster 时也照这个来——引用 slug，不要引用显示名，显示名会漂移。

延伸阅读

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