尧图网站建设 
BMAD-METHOD 多智能体协作用架构决策记录ADR前置消解 Agent 实现冲突【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD当多个 AI 智能体Agent并行实现同一系统的不同部分时各自做出的局部技术决策极易相互矛盾——API 风格、数据库命名、状态管理方案可能各走一端。BMAD-METHOD 通过bmad-architecture技能在实施前生成一份架构脊柱Architecture Spine以 ADRArchitecture Decision Record和共享约定把高冲突风险决策显式固化让每个 Agent 在动手前读到同一份公共协议。读完本篇你将理解三类典型冲突的成因、架构文档防冲突的三大机制以及如何借助仓库中的lint_spine.py、评审门禁Reviewer Gate和bmad-correct-course技能把这些机制落地为可验证的工程实践。一、冲突从哪来多 Agent 并行实现的三个高发地带BMAD-METHOD 的工作流把做什么PRD与怎么做architecture epic/story 拆分分开solutioning 阶段负责把跨 epic 的关键技术决策写清楚避免到实施阶段才暴露分歧。防止智能体冲突 一文的核心论点正是架构文档化通过建立共享标准来防止冲突而不是靠事后返工去修复。以下三类冲突是该文档归纳的高发地带。1. API 风格冲突没有架构约束时各 Agent 会各选一套接口范式智能体 A 使用 REST路径形如/users/{id}智能体 B 使用 GraphQL mutations结果接口模式不一致调用方和集成层复杂度暴涨有了架构约束后ADR 会明确规定例如所有客户端-服务端通信统一使用 GraphQL所有智能体遵循同一套 API 规则。为什么解决方案设计很重要 一文用同一场景佐证了这一点智能体 1 用 REST 实现 Epic 1、智能体 2 用 GraphQL 实现 Epic 2最终集成成本暴涨而先定规则所有 API 使用 GraphQL后各 story 实现一致、集成顺滑。2. 数据库设计与命名冲突智能体 A 使用snake_case列名智能体 B 使用camelCase列名结果schema 不一致查询与迁移成本上升架构约束下的做法是标准文档统一命名约定和迁移策略所有智能体按同一模式实现。在 架构脊柱模板 中这一层被固化为 Consistency Conventions 表要求至少覆盖三类约定命名实体、文件、接口、事件、数据与格式ID、日期、错误形状、信封结构、状态与横切关注点变更方式、错误、日志、配置、认证——即独立开发者会漂移之处就是需要约定绑住之处。3. 状态管理冲突智能体 A 使用 Redux 管理全局状态智能体 B 使用 React Context结果状态层碎片化维护复杂度增加架构约束下ADR 明确状态管理方案如 Redux vs Context vs Zustand不同 story 的实现保持一致。二、架构防冲突的三大机制机制 1用 ADR 固化关键决策原文档要求每个重要技术选择都伴随五要素记录上下文为什么这个决策重要、备选方案有哪些选择、最终决策选了什么、理由为什么选它、后果接受了哪些权衡。仓库源码把这一要求落实为更严格的结构。bmad-architecture技能产出的脊柱文档中每个存活的决策变成一个AD-n块模板spine-template.md规定其最小形态### AD-1 — {decision} - **Binds:** {该决策绑定的能力 / 单元 ID / fr-nfr 范围或 all} - **Prevents:** {它防止的漂移divergence} - **Rule:** {下游必须遵守的可执行约束}注意这里与经典 ADR 的一个关键差异bmad-architecture/SKILL.md 明确只记录决策不记录理由决策的理由留在 memlog 工作记忆中而Prevents字段直接指向若不做此决策下层两个单元会怎样分叉——这正是对文档中冲突预防主题的结构化表达。技能中还有一个判定某决策是否应进入脊柱的测试如果下一层有两个单元各自独立构建此部分它们是否可能做出不兼容的选择只有当答案为是、且该决策非显而易见、且是真实权衡时才在此固化否则写入 Deferred暂缓即可。这条标准直接回应了原文档避免过度文档化的告诫——脊柱保持短小且收敛防止分析瘫痪。机制 2把 FR/NFR 映射到技术实现原文档强调架构不是抽象原则清单而是把需求落到可执行方案FR-001用户管理→ GraphQL mutationsFR-002移动端性能→ 查询裁剪与缓存策略模板中的 Capability → Architecture Map 表正是这一映射的载体| Capability / Area | Lives in | Governed by | | --- | --- | --- | | {CAP-id / 领域} | {组件 / 模块} | {AD-id, 约定, 范式} |它把规格书中的每个能力桥接到代码住在哪里 受哪条 AD/约定/范式约束相当于一致性审计的核对清单。只有当运行由 spec 驱动时该节才会保留避免小项目被模板拖肥。机制 3显式文档化标准与惯例原文档列出必须显式文档化的四项目录结构、命名规则、代码组织方式、测试模式。在 架构脊柱模板 中目录结构落入 Structural Seed 一节只固定冷启动时值得固定的形状如{root}/{dir}/ # 存放什么命名与数据格式落入前述 Consistency Conventions 表设计范式Design Paradigm则以命名模式如 hexagonal、layered、pipes-and-filters、actor统领全局——命名一个已知范式等于免费加载一整套模型。三、架构作为所有 Agent 的共享上下文原文档给出了一段简洁的心智模型值得原样保留PRD: 做什么 ↓ architecture: 怎么做 ↓ 智能体 A 读 architecture → 实现 Epic 1 智能体 B 读 architecture → 实现 Epic 2 智能体 C 读 architecture → 实现 Epic 3 ↓ 结果实现一致仓库源码在此基础上补充了一个防冲突的关键设计——继承与冲突上抛。bmad-architecture/SKILL.md 规定当下层脊柱例如某个 epic 级脊柱继承父级脊柱时父级的 AD、约定和范式是只读绑定约束按原始 ID 列入 Inherited Invariants永不重新编号、永不重新推导一条与继承项矛盾的新 AD 是必须上抛的冲突conflict to surface而不是本地覆盖。这从机制上杜绝了子 Agent 静默推翻上层决策这一类最隐蔽的冲突来源。四、优先写清的 ADR 主题文档给出的防冲突高价值决策清单可直接用作 ADR 选题表主题示例决策API 风格GraphQL vs REST vs gRPC数据存储PostgreSQL vs MongoDB认证机制JWT vs Session状态管理Redux vs Context vs Zustand样式方案CSS Modules vs Tailwind vs Styled Components测试体系Jest Playwright vs Vitest Cypress补充一条仓库内的实操约束bmad-architecture/SKILL.md 要求在绑定任何命名技术之前先到网上核对其当前版本与适配性模板中的 Stack 表也要求名称 已固定版本。这一点会被机械检查强制执行lint_spine.py 会扫描## Stack表凡点名技术却无版本version_pin检查项即报 medium 级发现——防止架构陈旧这一反模式从版本层面开始发酵。五、源码级纵深机械校验与对抗性评审如何把关BMAD-METHOD 没有把架构防冲突停留在文档自觉层面bmad-architecture的 Reviewer Gatereviewer-gate.md提供了两层互补把关恰好对应原文档避免陈旧架构、避免无效约定的告诫第一层确定性机械校验。lint_spine.py 以固定规则检查脊柱的机械完整性输出紧凑 JSON 发现项包括placeholder残留的 TBD / TODO / similar to AD-n 未解析引用 / 未填模板占位符{token}因误报风险降为 low 级提示ad_idAD-n编号重复或非单调递增编号只能升、永不重排——保证下游引用稳定ad_fields某个AD-n块缺失 Binds / Prevents / Rule 任一必填字段version_pinStack 表条目无版本。脚本设计细节值得一提扫描前会把围栏代码块替换为等量空行因此 mermaid 图与源码树不会触发误报同时行号仍与真实文件对齐退出码恒为 0发现项全部走 JSON 由调用方Reviewer Gate / rubric walker处置。它明确分工LLM 会数错 ID、漏掉字面占位符grep 不会——脚本管机械错误语义判断留给评审。第二层对抗性子智能体评审。customize.toml 默认配置了两个finalize_reviewers评审镜头以并行子智能体形式对照ARCHITECTURE-SPINE.md独立评审独立上下文正是关键——新鲜的眼睛能发现作者视而不见的分歧。其中对抗镜头的提示词几乎就是本文主题的源码版表述以攻击者姿态审视脊柱构造下一层的两个单元各自严格遵行每条 AD却仍然构建出不兼容的结果——共享数据形状冲突、同一实体出现两个属主、状态变更路径相抵。你找到的每一对都是需要用新 AD 或收紧现有 AD 来填补的洞。另一默认镜头则核验每条已承诺的决策都经过网络调研或现实核查而非来自训练数据的断言。评审按 stakes 分级伸缩一次性原型可安静地跑门禁甚至跳过但一旦门禁运行配置的finalize_reviewers全部强制参与配置下限不可摘选headless无人值守模式则永不跳过门禁。六、常见反模式与正确做法原文档归纳的三个反模式对照仓库机制可以更精确地理解其危害应避免的做法Common Mistakes隐式决策——API 风格等写代码时再定的心态必然导致不一致没有显式 AD就没有可被lint_spine.py或对抗评审检查的约束两个单元分叉无从拦截过度文档化——把每个微小选择都写成 ADR 会造成分析瘫痪技能的一测判定标准两个下层单元是否可能不兼容地选择就是防止决策泛滥的过滤器不满足条件的决策进 Deferred 而非 AD陈旧架构——只写不更新的文档会让 Agent 遵循过时模式bmad-correct-course 技能正是为此而设。推荐的正确做法记录跨越 epic 边界、高冲突概率的决策把精力集中在会影响多个 story 的规则上随项目演进持续更新架构——bmad-architecture的 Update 意图会从既有 memlog决策权威来源恢复运行保持 AD ID 稳定就地修订 Rule、新增 AD-n绝不重排或复用已退役 ID再重新蒸馏并走评审门禁保证下游引用不失效出现重大偏移时调用bmad-correct-course它要求全量加载 PRD、Epics、Architecture、UX 与 Spec 等规划产物逐项评估变更影响产出带修改前/修改后对照的 Sprint Change Proposal并按影响范围Minor 直接由 Developer 实现 / Moderate 需 PO/DEV 重组待办 / Major 升级至 PM/Architect 重规划路由交接。值得强调的是correct-course 的输入发现逻辑会读取受影响仓库中AGENTS.md的bmad:context块——那是项目级的政策、冻结路径与约定修正课程时必须遵守的上下文。把项目约定维护在 项目上下文 与架构脊柱两条线中并保持同步是防止文档漂移的日常功课。七、小结与延伸阅读架构文档在多 Agent 协作中的角色可以概括为一句话把高冲突风险决策前置为可检查的共享契约让冲突在实施前被拦截而不是在集成时被发现。BMAD-METHOD 用AD-n的 Binds/Prevents/Rule 结构落实 ADR 五要素用lint_spine.py与对抗性评审门禁提供两层防冲突校验用 memlog 与 stable AD ID 保证架构演进时引用不漂移再用bmad-correct-course兜底处理实施中的重大偏移——四者合起来构成了原文档共享标准防冲突论点的完整工程闭环。延伸阅读为什么解决方案设计很重要中文版见 why-solutioning-matters项目上下文工作流地图bmad-architecture 技能定义 与 架构脊柱模板【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 BMAD-METHOD 多智能体协作：用架构决策记录（ADR）前置消解 Agent 实现冲突
BMAD-METHOD 多智能体协作用架构决策记录ADR前置消解 Agent 实现冲突【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD当多个 AI 智能体Agent并行实现同一系统的不同部分时各自做出的局部技术决策极易相互矛盾——API 风格、数据库命名、状态管理方案可能各走一端。BMAD-METHOD 通过bmad-architecture技能在实施前生成一份架构脊柱Architecture Spine以 ADRArchitecture Decision Record和共享约定把高冲突风险决策显式固化让每个 Agent 在动手前读到同一份公共协议。读完本篇你将理解三类典型冲突的成因、架构文档防冲突的三大机制以及如何借助仓库中的lint_spine.py、评审门禁Reviewer Gate和bmad-correct-course技能把这些机制落地为可验证的工程实践。一、冲突从哪来多 Agent 并行实现的三个高发地带BMAD-METHOD 的工作流把做什么PRD与怎么做architecture epic/story 拆分分开solutioning 阶段负责把跨 epic 的关键技术决策写清楚避免到实施阶段才暴露分歧。防止智能体冲突 一文的核心论点正是架构文档化通过建立共享标准来防止冲突而不是靠事后返工去修复。以下三类冲突是该文档归纳的高发地带。1. API 风格冲突没有架构约束时各 Agent 会各选一套接口范式智能体 A 使用 REST路径形如/users/{id}智能体 B 使用 GraphQL mutations结果接口模式不一致调用方和集成层复杂度暴涨有了架构约束后ADR 会明确规定例如所有客户端-服务端通信统一使用 GraphQL所有智能体遵循同一套 API 规则。为什么解决方案设计很重要 一文用同一场景佐证了这一点智能体 1 用 REST 实现 Epic 1、智能体 2 用 GraphQL 实现 Epic 2最终集成成本暴涨而先定规则所有 API 使用 GraphQL后各 story 实现一致、集成顺滑。2. 数据库设计与命名冲突智能体 A 使用snake_case列名智能体 B 使用camelCase列名结果schema 不一致查询与迁移成本上升架构约束下的做法是标准文档统一命名约定和迁移策略所有智能体按同一模式实现。在 架构脊柱模板 中这一层被固化为 Consistency Conventions 表要求至少覆盖三类约定命名实体、文件、接口、事件、数据与格式ID、日期、错误形状、信封结构、状态与横切关注点变更方式、错误、日志、配置、认证——即独立开发者会漂移之处就是需要约定绑住之处。3. 状态管理冲突智能体 A 使用 Redux 管理全局状态智能体 B 使用 React Context结果状态层碎片化维护复杂度增加架构约束下ADR 明确状态管理方案如 Redux vs Context vs Zustand不同 story 的实现保持一致。二、架构防冲突的三大机制机制 1用 ADR 固化关键决策原文档要求每个重要技术选择都伴随五要素记录上下文为什么这个决策重要、备选方案有哪些选择、最终决策选了什么、理由为什么选它、后果接受了哪些权衡。仓库源码把这一要求落实为更严格的结构。bmad-architecture技能产出的脊柱文档中每个存活的决策变成一个AD-n块模板spine-template.md规定其最小形态### AD-1 — {decision} - **Binds:** {该决策绑定的能力 / 单元 ID / fr-nfr 范围或 all} - **Prevents:** {它防止的漂移divergence} - **Rule:** {下游必须遵守的可执行约束}注意这里与经典 ADR 的一个关键差异bmad-architecture/SKILL.md 明确只记录决策不记录理由决策的理由留在 memlog 工作记忆中而Prevents字段直接指向若不做此决策下层两个单元会怎样分叉——这正是对文档中冲突预防主题的结构化表达。技能中还有一个判定某决策是否应进入脊柱的测试如果下一层有两个单元各自独立构建此部分它们是否可能做出不兼容的选择只有当答案为是、且该决策非显而易见、且是真实权衡时才在此固化否则写入 Deferred暂缓即可。这条标准直接回应了原文档避免过度文档化的告诫——脊柱保持短小且收敛防止分析瘫痪。机制 2把 FR/NFR 映射到技术实现原文档强调架构不是抽象原则清单而是把需求落到可执行方案FR-001用户管理→ GraphQL mutationsFR-002移动端性能→ 查询裁剪与缓存策略模板中的 Capability → Architecture Map 表正是这一映射的载体| Capability / Area | Lives in | Governed by | | --- | --- | --- | | {CAP-id / 领域} | {组件 / 模块} | {AD-id, 约定, 范式} |它把规格书中的每个能力桥接到代码住在哪里 受哪条 AD/约定/范式约束相当于一致性审计的核对清单。只有当运行由 spec 驱动时该节才会保留避免小项目被模板拖肥。机制 3显式文档化标准与惯例原文档列出必须显式文档化的四项目录结构、命名规则、代码组织方式、测试模式。在 架构脊柱模板 中目录结构落入 Structural Seed 一节只固定冷启动时值得固定的形状如{root}/{dir}/ # 存放什么命名与数据格式落入前述 Consistency Conventions 表设计范式Design Paradigm则以命名模式如 hexagonal、layered、pipes-and-filters、actor统领全局——命名一个已知范式等于免费加载一整套模型。三、架构作为所有 Agent 的共享上下文原文档给出了一段简洁的心智模型值得原样保留PRD: 做什么 ↓ architecture: 怎么做 ↓ 智能体 A 读 architecture → 实现 Epic 1 智能体 B 读 architecture → 实现 Epic 2 智能体 C 读 architecture → 实现 Epic 3 ↓ 结果实现一致仓库源码在此基础上补充了一个防冲突的关键设计——继承与冲突上抛。bmad-architecture/SKILL.md 规定当下层脊柱例如某个 epic 级脊柱继承父级脊柱时父级的 AD、约定和范式是只读绑定约束按原始 ID 列入 Inherited Invariants永不重新编号、永不重新推导一条与继承项矛盾的新 AD 是必须上抛的冲突conflict to surface而不是本地覆盖。这从机制上杜绝了子 Agent 静默推翻上层决策这一类最隐蔽的冲突来源。四、优先写清的 ADR 主题文档给出的防冲突高价值决策清单可直接用作 ADR 选题表主题示例决策API 风格GraphQL vs REST vs gRPC数据存储PostgreSQL vs MongoDB认证机制JWT vs Session状态管理Redux vs Context vs Zustand样式方案CSS Modules vs Tailwind vs Styled Components测试体系Jest Playwright vs Vitest Cypress补充一条仓库内的实操约束bmad-architecture/SKILL.md 要求在绑定任何命名技术之前先到网上核对其当前版本与适配性模板中的 Stack 表也要求名称 已固定版本。这一点会被机械检查强制执行lint_spine.py 会扫描## Stack表凡点名技术却无版本version_pin检查项即报 medium 级发现——防止架构陈旧这一反模式从版本层面开始发酵。五、源码级纵深机械校验与对抗性评审如何把关BMAD-METHOD 没有把架构防冲突停留在文档自觉层面bmad-architecture的 Reviewer Gatereviewer-gate.md提供了两层互补把关恰好对应原文档避免陈旧架构、避免无效约定的告诫第一层确定性机械校验。lint_spine.py 以固定规则检查脊柱的机械完整性输出紧凑 JSON 发现项包括placeholder残留的 TBD / TODO / similar to AD-n 未解析引用 / 未填模板占位符{token}因误报风险降为 low 级提示ad_idAD-n编号重复或非单调递增编号只能升、永不重排——保证下游引用稳定ad_fields某个AD-n块缺失 Binds / Prevents / Rule 任一必填字段version_pinStack 表条目无版本。脚本设计细节值得一提扫描前会把围栏代码块替换为等量空行因此 mermaid 图与源码树不会触发误报同时行号仍与真实文件对齐退出码恒为 0发现项全部走 JSON 由调用方Reviewer Gate / rubric walker处置。它明确分工LLM 会数错 ID、漏掉字面占位符grep 不会——脚本管机械错误语义判断留给评审。第二层对抗性子智能体评审。customize.toml 默认配置了两个finalize_reviewers评审镜头以并行子智能体形式对照ARCHITECTURE-SPINE.md独立评审独立上下文正是关键——新鲜的眼睛能发现作者视而不见的分歧。其中对抗镜头的提示词几乎就是本文主题的源码版表述以攻击者姿态审视脊柱构造下一层的两个单元各自严格遵行每条 AD却仍然构建出不兼容的结果——共享数据形状冲突、同一实体出现两个属主、状态变更路径相抵。你找到的每一对都是需要用新 AD 或收紧现有 AD 来填补的洞。另一默认镜头则核验每条已承诺的决策都经过网络调研或现实核查而非来自训练数据的断言。评审按 stakes 分级伸缩一次性原型可安静地跑门禁甚至跳过但一旦门禁运行配置的finalize_reviewers全部强制参与配置下限不可摘选headless无人值守模式则永不跳过门禁。六、常见反模式与正确做法原文档归纳的三个反模式对照仓库机制可以更精确地理解其危害应避免的做法Common Mistakes隐式决策——API 风格等写代码时再定的心态必然导致不一致没有显式 AD就没有可被lint_spine.py或对抗评审检查的约束两个单元分叉无从拦截过度文档化——把每个微小选择都写成 ADR 会造成分析瘫痪技能的一测判定标准两个下层单元是否可能不兼容地选择就是防止决策泛滥的过滤器不满足条件的决策进 Deferred 而非 AD陈旧架构——只写不更新的文档会让 Agent 遵循过时模式bmad-correct-course 技能正是为此而设。推荐的正确做法记录跨越 epic 边界、高冲突概率的决策把精力集中在会影响多个 story 的规则上随项目演进持续更新架构——bmad-architecture的 Update 意图会从既有 memlog决策权威来源恢复运行保持 AD ID 稳定就地修订 Rule、新增 AD-n绝不重排或复用已退役 ID再重新蒸馏并走评审门禁保证下游引用不失效出现重大偏移时调用bmad-correct-course它要求全量加载 PRD、Epics、Architecture、UX 与 Spec 等规划产物逐项评估变更影响产出带修改前/修改后对照的 Sprint Change Proposal并按影响范围Minor 直接由 Developer 实现 / Moderate 需 PO/DEV 重组待办 / Major 升级至 PM/Architect 重规划路由交接。值得强调的是correct-course 的输入发现逻辑会读取受影响仓库中AGENTS.md的bmad:context块——那是项目级的政策、冻结路径与约定修正课程时必须遵守的上下文。把项目约定维护在 项目上下文 与架构脊柱两条线中并保持同步是防止文档漂移的日常功课。七、小结与延伸阅读架构文档在多 Agent 协作中的角色可以概括为一句话把高冲突风险决策前置为可检查的共享契约让冲突在实施前被拦截而不是在集成时被发现。BMAD-METHOD 用AD-n的 Binds/Prevents/Rule 结构落实 ADR 五要素用lint_spine.py与对抗性评审门禁提供两层防冲突校验用 memlog 与 stable AD ID 保证架构演进时引用不漂移再用bmad-correct-course兜底处理实施中的重大偏移——四者合起来构成了原文档共享标准防冲突论点的完整工程闭环。延伸阅读为什么解决方案设计很重要中文版见 why-solutioning-matters项目上下文工作流地图bmad-architecture 技能定义 与 架构脊柱模板【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考