OpenClaw 有价值应用（2026-06-18）：多Agent架构决策记录流——把架构决策从"口口相传"变成"系统化知识资产"

场景演示

"我们上次为什么选 PostgreSQL 而不是 MySQL？"

"啊，那个……好像是张工定的吧，具体原因我也不太记得了。"

这是很多技术团队的真实困境：架构决策靠会议、靠口口相传，几个月后连当事人自己都说不清楚当时为什么做了那个选择。 结果是：新人 onboarding 要重新踩一遍坑，架构评审变成重复讨论，换人之后技术债务叠加。

ADR（Architecture Decision Record，架构决策记录） 是解决这个问题的行业最佳实践——每个重要技术决策，都写成一份结构化文档：背景、决策、后果、替代方案，一目了然。

但现实中，团队要么懒得写（"太忙了"），要么写得散落在各种文档、Notion、飞书文档里，检索困难，无法追踪。

今天这套流，就是把 ADR 从"手动写"变成"多Agent流水线自动驱动"：

• 触发层：当研发提交代码/PR/MR 涉及架构变更关键词时，触发决策记录流程
• 捕获Agent：自动提取决策上下文（相关讨论、代码变更内容、相关文档）
• 撰写Agent：根据模板生成结构化 ADR
• 审查Agent：检查完整性（背景/决策/后果/替代方案是否齐全）
• 分发Agent：将 ADR 归档到知识库，并通过飞书/Bitable 通知相关人

最终效果：每一个架构决策，留下可检索、可追溯、可更新的知识资产，而不是消失在聊天记录里。

Step by Step

Step 0：理解 ADR 标准模板

一个合格的 ADR 至少包含以下字段：

# ADR-XXX: [决策标题]

## 状态
[Proposed | Accepted | Deprecated | Superseded]

## 背景
[做出该决策的问题场景和上下文]

## 决策
[核心决策内容，明确说明"我们决定……"]

## 后果
### 正面后果
- ...

### 负面后果
- ...

## 替代方案（Considered Alternatives）
- 方案A：[方案描述] → 被否决原因
- 方案B：[方案描述] → 被否决原因

## 相关决策
- [链接到相关ADR]
- [链接到相关Issue/PR]

Step 1：创建触发规则配置

在飞书Bitable中建立架构决策触发器表，用于监控需要触发 ADR 的场景：

Step 2：启动多Agent流水线

触发Agent（Watcher）
  → 上下文捕获Agent（Collector）
    → ADR撰写Agent（Writer）
      → 审查Agent（Reviewer）
        → 分发Agent（Publisher）
          → 归档到Bitable + 飞书通知

触发Agent：扫描代码提交记录、PR描述、会议纪要文档，识别架构决策信号。

上下文捕获Agent：收集相关历史讨论（飞书聊天记录、GitHub PR、文档评论），提取决策相关背景信息。

ADR撰写Agent：基于模板 + 上下文，自动生成结构化 ADR 草案。

审查Agent：检查草案完整性，标注缺失字段（如缺少"替代方案"），打回补充或直接通过。

分发Agent：将最终 ADR 写入飞书Wiki/文档，并同步到飞书Bitable架构决策台账。

Step 3：Bitable 架构决策台账管理

建立架构决策台账 Bitable，包含以下字段：

可复制提示词

🎯 触发判断提示词（给触发Agent）

你是架构决策触发识别Agent。请分析以下内容，判断是否涉及需要记录架构决策的重大变更。

判断标准（满足任一即触发）：
1. 引入新的技术组件或中间件（数据库、缓存、消息队列、网关等）
2. 改变现有系统架构（如从单体拆分为微服务、更换核心框架）
3. 涉及 API 协议或数据格式的重大变更
4. 引入新的安全机制或权限模型
5. 性能/可扩展性架构调整

待分析内容：
---
{content}
---

输出格式：
- 触发判断：[是/否]
- 触发原因：如果"是"，说明符合上述哪条标准
- 决策概述：50字以内描述核心决策是什么
- 建议优先级：[P0-必须记录 / P1-强烈建议 / P2-可选]

📝 ADR撰写提示词（给撰写Agent）

你是架构决策记录专家（ADR Writer）。请根据以下上下文，撰写一份标准的架构决策记录（ADR）。

## 必须包含的章节
1. **标题**：ADR-{序号}：[核心决策简述]
2. **状态**：Proposed（初稿）
3. **背景**：说明为什么会面临这个决策问题，相关的约束和压力是什么
4. **决策**：明确说明"我们决定……"，语气果断，不模糊
5. **正面后果**：列出采用该方案的好处（3条以上）
6. **负面后果**：诚实列出该方案的代价和风险（2条以上）
7. **替代方案**：列出至少2个被否决的替代方案，并说明否决原因
8. **相关决策**：链接到相关的历史ADR或上下文文档

## 上下文素材
- 决策标题：{title}
- 相关讨论摘要：{discussion_summary}
- 代码变更描述：{code_change_desc}
- 相关技术背景：{tech_context}

## 格式要求
- 使用标准Markdown格式
- 每个章节用## 标题
- 列表使用 - 或 1. 格式
- 保持专业但可读，避免过于技术 jargon
- 决策章节要具体可操作，不要模糊表态

请生成完整的 ADR 文档。

🔍 ADR审查提示词（给审查Agent）

你是架构决策记录审查Agent。请审查以下 ADR 初稿，检查其完整性和质量。

## 审查维度

### 1. 完整性检查
- [ ] 是否包含背景（Context）章节，且背景描述清晰
- [ ] 是否包含明确的决策（Decision）章节
- [ ] 是否列出正面后果（至少2条）
- [ ] 是否列出负面后果/风险（至少1条）
- [ ] 是否列出替代方案（至少1个），并说明否决原因
- [ ] 决策内容是否具体，避免模糊表述（如"选择合适的方案"）

### 2. 可读性检查
- [ ] 背景描述是否让不了解上下文的人也能理解问题
- [ ] 决策章节是否足够明确，新人能看懂团队做了什么决定
- [ ] 替代方案是否有实质性对比（不是走过场）

### 3. 可操作性检查
- [ ] 负面后果是否有对应的缓解措施或建议
- [ ] 后续维护者能否根据这份文档理解如何调整或撤销该决策

## 待审查 ADR
---
{adr_content}
---

## 输出格式
对每个检查项给出 [✅通过 / ⚠️建议修改 / ❌缺失]，最后给出总体评价和改进建议。

使用的Skills

价值与注意事项

💡 核心价值

1. 知识资产沉淀：架构决策不再是"会议结束即丢失"，而是变成可检索、可引用的结构化文档。
2. 新人 onboarding 加速：新来的工程师可以通过 ADR 台账快速了解团队为什么做了这些技术选择，而不是自己重新摸索。
3. 避免重复讨论：当有人再次提出"我们为什么要用PostgreSQL而不是MySQL"时，直接甩ADR链接，而不是再开一次评审会。
4. 技术债务可视：通过 ADR 台账的"有效期"字段，定期审视过去的决策是否还适用，主动管理技术债务。
5. 审计与合规：在需要安全合规的场景（如金融、医疗），架构决策的完整记录本身就是合规要求。

⚠️ 注意事项

1. 不要为了写ADR而写ADR：只有真正影响系统架构、涉及多方权衡的重大决策才需要记录。不是什么小事都触发流水线，否则团队会疲劳。
2. 决策状态要定期更新：ADR 有生命周期（Proposed → Accepted → Deprecated → Superseded），要定期巡检，避免"僵尸ADR"误导团队。
3. 触发规则要精准：触发关键词如果设置太宽泛，会产生大量噪音。建议结合代码仓库的标签/PR分类来双重判断。
4. ADR不能替代面对面讨论：复杂的架构决策需要充分讨论，ADR是讨论后的记录工具，不是讨论的替代品。先讨论清楚，再写ADR。
5. 知识库要有人维护：ADR 归档到飞书Wiki后，建议指定一位架构负责人定期巡检，确保文档质量和可访问性。

一句话总结：多Agent架构决策记录流，让每一个"为什么这样设计"都有据可查，让团队的智慧真正沉淀下来，而不是随着人员流动而流失。