Phase 0 到 Phase 6：七个阶段的分工与产出
如果你只把 agency-agents 当成一个 agent 花名册来用，那你大概率会漏掉 strategy/ 这个目录。它不是 division，里面一个可安装的 agent 都没有 —— divisions.json 的 _note 字段写得很直白：strategy 目录放的是编排方法论（orchestration doctrine），不是可安装的 agent。这个目录装的是一套叫 NEXUS 的东西，全称按 QUICKSTART.md 的展开是 Network of EXperts, Unified in Strategy。
先把最容易误解的一点说在前面：**NEXUS 是一套写在 markdown 里的方法论，不是一个可执行的调度器。**它靠提示词让模型自己按阶段往下推进，仓库里没有任何代码在强制执行阶段顺序，也没有代码在卡住质量门。看完这篇你要能自己判断：这七个阶段里哪几个对你当前的项目有意义，哪几个可以直接跳过。
七个阶段和它们各自的 playbook
nexus-strategy.md 的章节结构与 strategy/playbooks/ 下的七个文件一一对应：
| Phase | 名称 | playbook 文件 | 行数 |
|---|---|---|---|
| 0 | Intelligence & Discovery | phase-0-discovery.md | 178 |
| 1 | Strategy & Architecture | phase-1-strategy.md | 238 |
| 2 | Foundation & Scaffolding | phase-2-foundation.md | 278 |
| 3 | Build & Iterate | phase-3-build.md | 286 |
| 4 | Quality & Hardening | phase-4-hardening.md | 332 |
| 5 | Launch & Growth | phase-5-launch.md | 277 |
| 6 | Operate & Evolve | phase-6-operate.md | 318 |
这张表最有信息量的其实是最后一列。七篇 playbook 的篇幅并不平均：Phase 4（质量与加固）是最长的一篇，Phase 6（运营与演进）紧随其后，而 Phase 0（发现）是最短的。行数只是个粗略信号，但它至少说明作者的笔墨押在哪儿 —— 前期发现阶段给的是框架性的引导，越往后、越靠近”东西已经写出来了怎么办”，文档写得越细。
所以第一个判断依据就出来了：**如果你要挑一两篇 playbook 先读，别从 Phase 0 开始，从 Phase 4 开始。**发现和调研阶段你自己多半已有一套做法，而”写完了怎么验、怎么加固、上线后怎么运营”往往才是个人开发者和小团队真正缺的那一段。
每个阶段谁进场
QUICKSTART.md 给了一段 NEXUS-Full 模式的激活提示词，这段文本本身就是阶段分工的最简明表述，可以整段抄下来：
Activate Agents Orchestrator in NEXUS-Full mode.
Project: [YOUR PROJECT NAME]
Specification: [DESCRIBE YOUR PROJECT OR LINK TO SPEC]
Execute the complete NEXUS pipeline:
- Phase 0: Discovery (Trend Researcher, Feedback Synthesizer, UX Researcher, Analytics Reporter, Legal Compliance Checker, Tool Evaluator)
- Phase 1: Strategy (Studio Producer, Senior Project Manager, Sprint Prioritizer, UX Architect, Brand Guardian, Backend Architect, Finance Tracker)
- Phase 2: Foundation (DevOps Automator, Frontend Developer, Backend Architect, UX Architect, Infrastructure Maintainer)
- Phase 3: Build (Dev↔QA loops — all engineering + Evidence Collector)
- Phase 4: Harden (Reality Checker, Performance Benchmarker, API Tester, Legal Compliance Checker)
- Phase 5: Launch (Growth Hacker, Content Creator, all marketing agents, DevOps Automator)
- Phase 6: Operate (Analytics Reporter, Infrastructure Maintainer, Support Responder, ongoing)
Quality gates between every phase. Evidence required for all assessments.
读这段提示词的时候注意三处结构性的安排：
**Phase 0 是”往里收信息”，Phase 1 才开始”往外定方案”。**发现阶段进场的是趋势调研、反馈综合、用户研究、数据分析、合规检查、工具评估这一类角色，没有一个是写代码的；到策略阶段才有 UX 架构与后端架构进来。这个切分的意义在于：如果你发现自己在 Phase 0 就开始讨论技术选型，说明你跳阶段了。
**Phase 2 和 Phase 3 的参与者是错开的。**基础与脚手架阶段由 DevOps、前端、后端架构、UX 架构、基础设施维护这几方一起搭底子；到构建阶段，提示词写的是 “Dev↔QA loops — all engineering + Evidence Collector”，也就是全体工程角色进入开发与质检的循环。这里的判断依据很清楚：**脚手架没搭完就冲进 Phase 3，后面每一轮 Dev↔QA 循环都可能要额外背一次环境返工。**这一条是文档的阶段划分本身在暗示的先后关系，不是官方给出的结论。
同一个角色会在不同阶段以不同身份出现。Legal Compliance Checker 在 Phase 0 出现过一次，在 Phase 4 又出现一次；Analytics Reporter 在 Phase 0 和 Phase 6 各出现一次；DevOps Automator 横跨 Phase 2 与 Phase 5。这不是重复，而是同一专业视角在项目的不同时刻要回答不同的问题 —— 发现阶段的合规检查是”这事能不能做”，加固阶段的合规检查是”做出来的这个东西合不合规”。
两句被写进提示词末尾的设计意图
提示词最后那两行短句才是 NEXUS 的骨架：
Quality gates between every phase. Evidence required for all assessments.
第一句是每个阶段之间都有质量门。注意这是文档层面的约定，不是代码层面的拦截 —— 没有任何程序会在你没过关时阻止你进入下一阶段，能不能守住这条线取决于你自己是否认真对待。
第二句是所有评估都要有证据。这一句在花名册里有对应的实体：Testing division 下有一个专门的 testing-evidence-collector（显示名 Evidence Collector）。在 Phase 3 的描述里它是被单独点名的 —— 全体工程角色进入 Dev↔QA 循环时，取证是一条独立的线，而不是顺手做的事。
这两句合起来是这套方法论里最值得迁移到自己流程里的部分：**阶段之间设检查点，检查点上要的是证据不是结论。**哪怕你完全不用 agency-agents，这条也成立。
七阶段不是必须全走：三种激活模式
nexus-strategy.md 和 QUICKSTART.md 里的模式表是一致的：
| 模式 | 参与 agent 数 | 适用场景 | 周期 |
|---|---|---|---|
| NEXUS-Full | All（全部） | 企业级产品发布、完整生命周期 | 12–24 周 |
| NEXUS-Sprint | 15–25 | 功能开发、MVP 构建 | 2–6 周 |
| NEXUS-Micro | 5–10 | Bug 修复、内容战役、单一交付物 | 1–5 天 |
这里必须说明：表里的周期和 agent 数量都是文档给出的建议区间，不是实测数据，也不是任何承诺。看到”2–6 周”不要理解成”用 Sprint 模式两到六周就能做出 MVP”，它只是文档在描述这个模式适配的时间尺度。
真正的判断依据在第三列的场景描述上：**决定用哪个模式的是交付物的形态，不是项目的重要程度。**单一交付物、修一个 bug、跑一次内容战役 —— 这类事情的共同点是产出边界清晰、不需要跨阶段来回，所以走 Micro；而完整生命周期意味着你要经历从发现到运营的全部七个阶段，才需要 Full。
runbooks.json 里四个可直接照搬的场景 runbook 也印证了这一点：startup-mvp、enterprise-feature、marketing-campaign 三个都是 NEXUS-Sprint，只有 incident-response（事故响应）是 NEXUS-Micro。
事故响应这个 runbook 的分组设计特别值得单独看：它的 always 组是 support-infrastructure-maintainer、engineering-devops-automator、engineering-backend-architect、engineering-frontend-developer 等 6 个，另有一个独立的 post-fix 组，包含 testing-evidence-collector、testing-api-tester、testing-workflow-optimizer、product-sprint-prioritizer 4 个。也就是说，取证、回归测试、流程优化、重排优先级这四件事被显式安排在修复动作之后单独一组 —— 修完不算完。这条设计和”所有评估都要有证据”是同一个思路的两次落地。
阶段之间靠什么交接
阶段划分只解决”谁在什么时候做”，还差一半：上一个 agent 产出什么、下一个 agent 收到什么。这部分在两个地方：
nexus-strategy.md第 11 章 Handoff Protocols，给了三个模板：NEXUS Handoff Document、QA Failure Feedback、Escalation Reportstrategy/coordination/下两份文件：agent-activation-prompts.md（401 行）是各 agent 的激活提示词，handoff-templates.md（357 行）是交接文档模板
除此之外，nexus-strategy.md 还有第 10 章 Agent Coordination Matrix（含 10.1 Full Cross-Division Dependency Map）、第 12 章 Quality Gates、第 13 章 Risk Management、第 14 章 Success Metrics、第 15 章 Quick-Start Activation Guide。想理解阶段之间到底怎么衔接，第 10、11、12 章比七篇 playbook 本身更关键。
顺带一个可以直接搬走的工程经验：runbooks.json 的 agents[] 数组里存的是 slug，也就是 agent .md 文件的文件名主干，比如 engineering/engineering-frontend-developer.md 对应 engineering-frontend-developer、specialized/agents-orchestrator.md 对应 agents-orchestrator。_note 特别提醒：文件名主干并不总是带 division 前缀，而显示名带前缀、还会漂移，所以 roster 一律引用 slug —— slug 抗改名、可测试，scripts/check-runbooks.sh 就负责守住”每个 slug 都能解析到真实 agent 文件”这条线。跨文件引用要引用稳定 id，不要引用展示名，这条规则和 AI 没关系，放在任何配置驱动的项目里都成立。
它没解决什么
- **没有任何东西在强制执行。**模式与阶段划分是建议而非约束，质量门是写在文档里的约定。指望它像 CI 一样拦住你，会失望。
- **同时激活十几二十个角色是有代价的。**上下文和成本压力是真实存在的，具体到什么程度我们没有依据给数字，但在你决定用 Full 模式之前，这笔账要自己算。
- **阶段名称是通用软件生命周期的语汇。**如果你的项目本身就不走这条路径（比如纯研究性质、或者只是给现有系统加一个接口），照搬七阶段只会增加仪式感。挑 Phase 3、Phase 4 两篇读一读，比整套照跑更划算。
最后重申一遍开头那句：这套东西的价值在于它把”多个专业角色怎么配合”这件事写成了可读的文档和可解析的配置，而不在于它能自动跑起来。你仍然是那个负责推进阶段、负责在质量门前停下来的人。
延伸阅读
本文依据 agency-agents 官方仓库（github.com/msitarzewski/agency-agents）的 README、
tools.json、divisions.json、scripts/ 下的安装与校验脚本整理，核对日 2026-08-09。
本文内容为仓库源码与文档口径，我们没有安装或运行过其中任何 agent。
目录、脚本与安装路径随上游更新而变动，请以仓库最新内容与 ./scripts/install.sh --help 的实际输出为准。