NEXUS 是什么：写在 markdown 里的多 agent 编排方法论
第一次翻 agency-agents 这个仓库的人，很容易在 strategy/ 这个目录上卡一下：其它顶层目录点进去都是一堆 agent markdown，engineering/ 有 58 个、specialized/ 有 57 个，唯独 strategy/ 点进去是几篇长文档和两个 JSON。你把它当成一个 division 去装，会发现什么都装不出来。
这不是 bug。divisions.json 的 _note 字段把话说死了：strategy/ holds orchestration doctrine, not installable agents——它放的是编排方法论，不是可安装的 agent。仓库的 scripts/check-divisions.sh 里也把它列进了 NON_DIVISION_DIRS，跟 integrations/、examples/、scripts/ 一起被排除在 division 之外。判定一个目录算不算 division 只有一条标准：里面至少有一个带 frontmatter 的 agent 文件。strategy/ 一个都没有。
那它到底是什么？答案就是这篇要讲的 NEXUS。
NEXUS 的全称，以及它想解决的那个具体问题
QUICKSTART.md 把缩写展开写在了显眼位置：N-E-X-U-S = Network of EXperts, Unified in Strategy，专家网络，统一于策略之下。
它的定位说法大意是：NEXUS 把 The Agency 的这批 AI 专家变成一条协同流水线；不用再一个一个激活 agent、然后指望它们自己能配合上，NEXUS 明确定义了谁做什么、什么时候做、每一步的质量怎么验证。
这句话里最值得注意的是它承认的那个前提——一个一个激活 agent，它们默认不会互相配合。255 个 agent 分布在 17 个 division，每个 .md 里都是一段第二人称的角色提示词，各写各的。你今天让 Frontend Developer 写完组件，明天再激活一个测试类 agent，后者并不知道前者做过什么、按什么约定做的。NEXUS 想补的就是这个缝：顺序、职责边界、交接物。
★ 先把最关键的一句说在前面：它不是调度器
这是整篇最重要的判断，也是最容易被名字误导的地方。「编排」「流水线」「质量门」这些词摆在一起，很像在描述一个框架。
不是。NEXUS 是一套写在 markdown 里的方法论，仓库里没有任何代码在强制执行阶段顺序或质量门。
怎么自己验证这一点：strategy/ 下能跑的东西只有 runbooks.json 和守着它的 scripts/check-runbooks.sh，而后者干的活是「检查 runbook 里引用的每个 slug 能不能解析到真实存在的 agent 文件」——它校验的是引用完整性，不是流程执行。其余的 nexus-strategy.md（1110 行）、七篇 playbook（合计 1907 行）、四篇场景 runbook 说明、coordination/ 下的两篇（758 行），全部是给人和模型读的文档。
所以 NEXUS 生效的方式只有一种：你把这套结构写进提示词，让模型自己按阶段推进。 模型跳过一个阶段、在没有证据的情况下宣布质量门通过，没有任何东西会拦住它。理解了这一点，你才知道该把力气花在哪里——不是找配置项，而是自己在每个阶段结束时人工验一次收。
三种激活模式，以及怎么选
QUICKSTART.md 和 nexus-strategy.md 里的这张表是一致的：
| 模式 | 参与 agent 数 | 适用场景 | 文档建议周期 |
|---|---|---|---|
| NEXUS-Full | 全部 | 企业级产品发布、完整生命周期 | 12–24 周 |
| NEXUS-Sprint | 15–25 | 功能开发、MVP 构建 | 2–6 周 |
| NEXUS-Micro | 5–10 | Bug 修复、内容战役、单一交付物 | 1–5 天 |
先声明一句：这三个周期是文档给出的建议时间尺度，不是实测数据，也不是承诺。 我们没有按 NEXUS 跑过任何一次流程，也没有激活过 Orchestrator，看到「2–6 周」不要理解成「用 Sprint 模式两到六周就能做出 MVP」。
选模式的判断依据不该是「我这个项目重要不重要」，而是下面两个更实在的问题：
第一，你这次要交付的是一个东西还是一条产品线。 交付物只有一个（一个 bug 修复、一篇内容、一个接口），对应的是 Micro 那一档，5–10 个 agent；要走从调研到上线再到运营的完整生命周期，才轮得到 Full。中间地带——一个功能、一个 MVP——落在 Sprint。
第二，你的上下文预算撑不撑得住。 这是文档不会替你算的账。同时把十几二十个角色提示词放进一个会话，上下文占用和调用成本都会上去，具体涨多少取决于你的模型和工具，我们没有测过，不给数字。但方向是确定的：模式选大一档，代价是实打实的。 如果你只是想让某一个专家角色帮你看一段代码，直接激活那一个 agent 就够了，不必套 NEXUS。
七个阶段，与 playbook 文件的一一对应
nexus-strategy.md 的章节结构和 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 |
七个阶段之外，nexus-strategy.md 还有几章是真正把「多 agent」这件事往下落的：第 10 章 Agent Coordination Matrix（含 10.1 Full Cross-Division Dependency Map，跨 division 的依赖图）、第 11 章 Handoff Protocols、第 12 章 Quality Gates、第 13 章 Risk Management、第 14 章 Success Metrics、第 15 章 Quick-Start Activation Guide。
如果你只想抄一部分回自己项目，我会建议从第 11 章开始看而不是从 Phase 0 开始看——阶段划分各家都差不多，交接协议才是多 agent 相对单 agent 真正多出来的那部分。
激活提示词长什么样
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.——每个阶段之间都有质量门，所有评估都要有证据。
第二句在花名册里是有对应实体的：Testing division 下确实有一个 testing-evidence-collector（显示名 Evidence Collector）。也就是说「要证据」不只是一句口号，它被落成了一个专门角色，在 Phase 3 的 Dev↔QA 循环里就已经在场。
但仍然回到那句判断：没有代码在执行这两句话。 它们能不能兑现，取决于你读到模型输出「已通过质量门」时，会不会顺手去问一句证据在哪。
四个场景 runbook：文档里唯一机器可读的那一半
runbooks.json 是 strategy/ 里少数能被程序直接吃掉的文件。它的 _note 说明了用途：给 app 一类的消费方把一个 runbook 变成「一键部署一个团队」——读 roster、把每个 slug 映射到目录里的 agent 文件、然后整组安装。
| slug | 标题 | 模式 | roster 分组 |
|---|---|---|---|
startup-mvp | Startup MVP Build | NEXUS-Sprint | always(9) / week 3+(3) / as needed(6) |
enterprise-feature | Enterprise Feature Development | NEXUS-Sprint | always(15) / as needed(4) / as needed(3) |
marketing-campaign | Multi-Channel Marketing Campaign | NEXUS-Sprint | always(5) / as needed(5) / as needed(4) |
incident-response | Incident Response | NEXUS-Micro | always(6) / post-fix(4) |
每组的 activation 字段保留了 runbook 的阶段语义（always、week 3+、as needed、post-fix），四篇对应的说明文档在 strategy/runbooks/scenario-*.md。
四个里最值得单独看的是 incident-response。它的 always 组是六个人在救火，含 support-infrastructure-maintainer、engineering-devops-automator、engineering-backend-architect、engineering-frontend-developer；而 post-fix 组另有四个：testing-evidence-collector、testing-api-tester、testing-workflow-optimizer、product-sprint-prioritizer。
★ 把「取证 + 回测 + 流程优化 + 重排优先级」单独编成修复之后的一组，是这套 runbook 里最值得抄的一处设计。现实里事故响应最常见的失败不是修不好，是修好了就散场——没人补回归用例，没人改流程，下一个迭代的优先级照旧。这四个角色摆在 post-fix 而不是 always，等于把「修完不算完」写进了配置结构里，而不是靠事后的自觉。
顺带一提，runbooks.json 的 agents[] 里引用的是 slug（agent markdown 的文件名主干），不是显示名——理由和 check-runbooks.sh 的校验边界值得单独说，这里不展开。
协同层：两份可以直接拿走的模板
coordination/ 下两个文件：agent-activation-prompts.md（401 行）是各 agent 的激活提示词，handoff-templates.md（357 行）是 agent 之间的交接文档模板。配合 nexus-strategy.md 第 11 章的三个模板——NEXUS Handoff Document、QA Failure Feedback、Escalation Report——构成了「上一个 agent 产出什么、下一个 agent 收到什么」的契约。
如果你手上就一两个自建 agent、没打算搬整套 NEXUS，这两份模板是这个目录里迁移成本最低、也最不依赖 agency-agents 花名册的部分。交接文档的字段结构，跟你用哪家工具、装了几个 agent 都没关系。
什么情况下不该走这套
几条我认为需要明说的边界：
- 单一交付物、单个专家就能干完的活，别套流程。 七个阶段的开销是真实的，收益只有在角色确实要交接时才出现。
- 模式与阶段划分是建议，不是约束。 文档自己也是这么写的。你完全可以只取 Phase 4 的 hardening 清单，而不接受它前面六个阶段。
- 不要把它当成质量保证。 仓库层面的自动化只覆盖结构：
lint-agents.sh查 frontmatter 与章节结构，check-agent-originality.sh查重复度（默认阈值 40 / 20），check-runbooks.sh查 slug 能否解析。没有任何一个脚本在评估提示词好不好用，也没有一个在评估 NEXUS 跑出来的结果对不对。 - 别用热度替你做决定。 这个仓库在 2026-08-09 的快照里有 140729 star，说明关注度不低，但和它适不适合你的项目是两件事。
最后回到开头那个问题。strategy/ 装不了，是因为它本来就不是拿来装的——它是这个仓库里唯一一份告诉你「255 个 agent 该怎么排在一起用」的文档。你可以完全不接受它的阶段划分，但至少先知道，这个目录里放的是方法论，不是你漏装了什么。
延伸阅读
本文依据 agency-agents 官方仓库（github.com/msitarzewski/agency-agents）的 README、
tools.json、divisions.json、scripts/ 下的安装与校验脚本整理，核对日 2026-08-09。
本文内容为仓库源码与文档口径，我们没有安装或运行过其中任何 agent。
目录、脚本与安装路径随上游更新而变动，请以仓库最新内容与 ./scripts/install.sh --help 的实际输出为准。