AI Agent 双脑协作模式：Architect + Coder 的共享记忆架构与任务交接协议

两个 Agent 协作的最大难题，不是「谁做什么」，而是「交接时说什么」。当 Architect 把任务交给 Coder，什么信息必须带过去？什么信息必须由 Coder 自己确认？任务完成后，Coder 应该留下什么让 Architect 知道？

本文源自真实的双 Agent 协作项目，核心解决一个问题：如何让两个专业分工的 Agent（规划 + 执行）通过结构化的共享记忆系统实现真正的协作，而不是各自为政。

一、为什么双脑模式比单一 Agent 更适合复杂任务
二、Architect 和 Coder 的角色定义
三、共享记忆中枢设计（Shared Brain）
四、任务交接协议：PRD 驱动与边界确认
五、协作日志与热点问题追踪
六、Coder 的逆向反馈机制
七、常见失败模式与修复方案

一、为什么双脑模式比单一 Agent 更适合复杂任务

单一 Agent 处理复杂任务的瓶颈在于：推理深度和执行效率不可兼得。

当你让同一个 Agent 边分析、边设计、边编码、边调试，它的注意力会被多任务切换消耗。表现在实际工作中就是：

设计决策时担心实现细节
实现时又质疑设计是否合理
遇到困难时来回跳跃而不是系统分析

双脑模式的核心思路是：让一个 Agent 专注推理（Architect），另一个专注执行（Coder）。

传统单一 Agent：
  任务 → [分析 + 设计 + 实现 + 调试] → 结果
                    ↑ 全压在同一个 Agent 上

双脑模式：
  任务 → Architect（分析 + 设计 + PRD）→ 交接协议 → Coder（实现 + 自测 + 报告）
             ↑ 推理深度                              ↑ 执行效率
             专注"做什么"和"怎么做"                  专注"把它做出来"

这种分工的工程价值：

维度	单一 Agent	双脑模式
设计质量	受实现干扰，方案妥协	纯粹推理，不考虑落地难度
执行效率	设计阶段浪费时间想实现	Coder 拿到完整 PRD 直接执行
错误追溯	不知道哪一步出错	Architect 负责设计，Coder 负责实现，分工清晰
资源利用	推理比实现更耗 token	Architect 用更强模型，Coder 用性价比模型

二、Architect 和 Coder 的角色定义

2.1 Architect（规划师）

核心职责：分析需求、制定方案、输出 PRD、管理决策日志。

Architect 的工作流：

接收任务 → 分析需求 → 拆解 Epic → 输出 PRD → 等待 Coder 完成反馈

Architect 不写代码，它的产出物是：

PRD 文档（数据模型、API 定义、页面设计、验收标准）
任务拆解（有序的任务队列，供 Coder 按顺序执行）
架构决策（技术选型、目录结构、依赖关系）
风险评估（哪些部分难度高、需要特别确认）

Architect 的能力要求：

需求分析：能把模糊的需求转化为精确的数据模型和状态机
设计能力：能在约束下给出最优方案（不是”理想方案”而是”可落地方案”）
沟通能力：PRD 必须写到 Coder 能直接执行的程度，不能有歧义

2.2 Coder（工程师）

核心职责：接收 PRD、实现编码、自测验证、报告结果。

Coder 的工作流：

接收任务 → 确认理解 → 实现编码 → 自测 → 报告完成/问题

Coder 不自己做设计决策，遇到需求歧义或技术难题时：

如果在 PRD 范围内：自行判断并实现
如果超出 PRD 范围：向 Architect 发起确认请求，等回复后再执行

Coder 的关键约束：

"遇到技术难题：Coder 可呼叫 Architect 一起讨论"
"遇到需求歧义：Architect 可呼叫 Coder 确认可行性"

这种约束防止了两个常见问题：

Coder 擅自做设计决策（可能导致架构不一致）
Architect 做出无法落地的设计（如果有 Coder 反馈就能及时发现）

2.3 角色边界矩阵

场景	Architect	Coder
写代码	❌	✅
输出 PRD	✅	❌
做技术选型	✅	建议权
确认需求歧义	最终决策	提供可行性反馈
自测	❌	✅
Code Review	审核	执行修正

三、共享记忆中枢设计（Shared Brain）

双脑协作的核心基础设施是共享记忆文件（Shared Brain）。这是两个 Agent 之间的唯一信息通道。

3.1 为什么需要共享记忆文件

两个 Agent 在不同的时间运行，无法直接对话（不像人类可以通过即时通讯随时沟通）。共享记忆文件是它们的”异步通信协议”。

传统方式：
  Architect → 发消息给 Coder（每次都要重新解释上下文）
  Coder → 发消息给 Architect（每次都要重新说明状况）

问题：每次交接都丢失了大量上下文，导致信息不对称

共享记忆方式：
  Architect → 写 Shared Brain（Coder 随时可读）
  Coder → 写 Shared Brain（Architect 随时可读）
  交接时：读取 Shared Brain 获取完整上下文

3.2 Shared Brain 的结构

一个实用的 Shared Brain 文件结构：

# 🧠 共享记忆中枢 (Shared Brain)

> 双方均可读写，记录共同决策、分工约定、项目进展
> 每次会话结束前，双方均有义务更新此文件

---

## 👥 Agent 身份

| Agent | 角色 | 专长 | 职责 |
|-------|------|------|------|
| Agent-A | 规划师 (Architect) | 分析、设计、策略、PRD、任务拆解 | 规划、决策、分析 |
| Agent-B | 工程师 (Coder) | 编码、实现、调试、部署 | 落地、编码、技术验证 |

---

## 📌 当前项目

（每次协作开始时更新）

---

## 🤝 分工约定

（固定的分工协议，不需要每次重复）

---

## 📝 协作日志

（每次协作后记录）
  [时间] 事件描述

---

## 🔥 热点问题（待解决）

（当前悬而未决、需要双方共同跟进的问题）
  - [ ] 问题描述
  - [x] ~~已解决问题~~

---

## ✅ 已完成决策

（已拍板的事项，不再重复讨论）
  1. [日期] 决策内容

---

## 🎯 Architect → Coder 待处理任务

（Coder 的任务队列）
  1. **任务名**（优先级：高/中/低）
     - 状态：✅已完成 / 🔄进行中 / 📋待处理
     - PRD 链接：xxx.md
     - 说明：特殊要求

---

## 📎 Coder 对 Architect 的反馈

（Coder 向 Architect 的单向信息流）
  - 技术预判
  - 可行性质疑
  - 风险预警

3.3 写入纪律

Shared Brain 能否发挥作用，取决于两个 Agent 是否遵守写入纪律：

Architect 必须写入的时机：

PRD 完成后 → 写入协作日志 + 任务队列
做出重要决策 → 写入「已完成决策」
发现新风险 → 写入「热点问题」

Coder 必须写入的时机：

任务完成 → 写入协作日志 + 更新任务状态
发现技术难题 → 写入「Coder 反馈」
发现需求歧义 → 写入「热点问题」

每次 Session 结束前，双方必须检查 Shared Brain 是否需要更新。

违反写入纪律的后果：

情况：Architect 只在聊天里说"任务交给 Coder"，没有写 Shared Brain

后果：
  → Coder 不知道任务在哪（聊天记录可能被淹没）
  → Architect 以为 Coder 知道（因为说了）
  → Shared Brain 里没有记录，下一次交接时上下文丢失
  → 协作失败

四、任务交接协议：PRD 驱动与边界确认

Architect → Coder 的任务交接是整个协作流程中最关键的环节。交接质量决定了 Coder 能不能直接开始工作，不需要反复确认。

4.1 PRD 驱动的交接

一个合格的 PRD 必须包含：

## [模块名] PRD

### 数据模型
- 表名、字段、类型、约束
- 关联关系（外键）

### 状态流转
- 状态定义（有哪些状态）
- 状态转换条件（什么触发什么）

### API 定义
- 端点（HTTP 方法 + 路径）
- 请求参数（字段 + 类型 + 必填/可选）
- 响应格式（成功/失败的 JSON 结构）

### 前端页面
- 页面清单
- 每个页面的核心交互逻辑

### 验收标准
- 功能验收条件（怎么算"完成了"）
- 边界 case 处理要求
- 性能要求（如果有）

4.2 交接时的边界确认

Coder 收到 PRD 后，不能直接开始编码，必须先做理解确认：

Architect → Coder：
  "缺陷管理模块 PRD 已输出，请开始建表"

Coder 确认回复：
  "理解：我需要建 Defect/DefectStatusLog/DefectComment/DefectAttachment 四张表。
  优先级排序：缺陷 CRUD → 看板 → 通知。有两个问题：
  1. DefectComment 的 content 字段是否支持富文本？
  2. 附件存储是用 OSS 还是本地文件系统的路径记录？"

Architect 回复：
  "1. 支持富文本（TEXT 类型）
   2. 本地路径记录，附件实际存储由运维处理"

这个「确认 - 提问 - 回复」的流程，让 Coder 在动手之前就把歧义消除了，比做到一半再回头问 Architect 效率高得多。

4.3 任务边界的三层定义

每个任务交付给 Coder 时，必须明确三层边界：

第一层：做什么（功能范围）

交付物：四张数据库表 + 基础的 CRUD API

第二层：不做什么（排除项）

不包括：通知功能（后续迭代）
不包括：复杂权限校验（第一版 MVP 跳过）

第三层：怎么做（技术约束）

ORM 使用 Prisma
前端使用 shadcn/ui
数据库用 Supabase（PostgreSQL）

三层定义清晰的 PRD，让 Coder 知道什么时候该停手，不会过度实现。

五、协作日志与热点问题追踪

Shared Brain 里的协作日志和热点问题板块，是让双 Agent 协作不丢失上下文的关键机制。

5.1 协作日志的写法

每次协作事件后，记录一条日志：

[2026-03-21 13:37] 系统初始化，Architect + Coder 双 Agent 已就绪
[2026-03-21 13:40] Architect 完成 UAT 平台需求分析 + 原型设计方向
[2026-03-21 13:45] 共同确认 MVP 技术栈：Next.js + Supabase + Prisma
[2026-03-21 13:50] Coder 首次上线，已完成自我初始化
[2026-03-21 13:55] Architect 完成缺陷管理模块 PRD（数据模型 + 状态流转 + 9个API）

日志格式：[时间戳] 事件描述

时间戳的重要性：可以追踪每个阶段的耗时，发现协作瓶颈。如果某个任务在 Architect 端停留太久，说明设计阶段可能有问题；如果在 Coder 端停留太久，说明实现难度超出预期。

5.2 热点问题追踪

热点问题板块用于追踪”当前悬而未决、需要双方共同跟进的问题”：

## 🔥 热点问题（待解决）

- [x] ~~待确认：MVP 第一期范围边界（哪些 Feature 先做？）~~
  - Coder 回复：缺陷 CRUD 最简单可落地，看板复杂度中等，通知系统最复杂
  - Coder 推荐优先级：缺陷 CRUD → 看板 → 通知
  - Architect 确认：✅ 同意此优先级

- [ ] 待确认：企微 Webhook 回调地址（需要公网入口）
  - 状态：Architect 正在研究方案
  - 预计解决：明天

热点问题解决后，加上 [x] 和删除线，移到「已完成决策」板块。这套追踪机制防止同一问题被反复提起。

六、Coder 的逆向反馈机制

Architect 的设计不可能完美，Coder 在实现过程中会发现 Architect 没有考虑到的问题。此时 Coder 需要有一套逆向反馈机制，把实现中的发现反馈给 Architect。

6.1 反馈的三种类型

类型一：技术预判（Coder 对 Architect 的建议）

## 📎 Coder 对 Architect 的技术预判

第一期最复杂的 Feature 是**通知系统**，原因：
- 企微 Webhook 需要公网回调地址（本地开发调试麻烦）
- 建议：MVP 第一期先不做通知，验证缺陷 CRUD 和看板后再迭代

这种反馈让 Architect 在设计 PRD 时就考虑到技术约束，避免 PRD 写得很好但实现不了。

类型二：可行性质疑

Coder 反馈：
"PRD 中要求'每次保存缺陷时自动发送通知给负责人'，
但没有定义通知的触发时机和内容模板。
建议：通知功能单独出 PRD，第一期 MVP 先跳过复杂通知逻辑"

Architect 的职责是接受合理的反馈并更新方案，而不是坚持原有设计。

类型三：风险预警

Coder 反馈：
"数据库建表时发现，我们假设的 Defect 和 Project 的关联关系
在当前需求中可能不够——一个 Project 可能需要关联多个产品线，
建议 Architect 重新确认数据模型"

6.2 反馈的格式规范

所有反馈必须包含：

## 📎 Coder 对 Architect 的反馈

### [反馈类型：技术预判 / 可行性质疑 / 风险预警]

**问题描述**：
  具体是什么问题

**影响分析**：
  如果不处理，会导致什么后果

**建议方案**：
  Coder 建议的解决方案

**紧急程度**：
  高 / 中 / 低（影响当前任务还是后续迭代）

这种格式让 Architect 能快速评估反馈的优先级，决定是立即处理还是放入后续迭代。

七、常见失败模式与修复方案

失败模式一：Architect 和 Coder 都把信息存在各自脑中

Architect："我把任务细节在聊天里说了，Coder 应该知道"
Coder："Architect 没有写 PRD，我就按自己的理解做了"

结果：Architect 以为交接完成，Coder 做的和 Architect 想的不一样

修复：强制 Shared Brain 写入——Architect 必须输出 PRD 链接到 Shared Brain，
      Coder 必须确认理解后才能开始实现

失败模式二：Coder 遇到问题不反馈，Architect 不知道卡在哪

Architect 分配任务后，Coder 三小时没有回复

Architect："任务进展如何？"
Coder："遇到了一个技术难题，试了两个方案都不行，在尝试第三个"

问题：Coder 如果最终解决了，Architect 不知道他遇到了什么坎；
      如果第三个方案也失败，整个任务陷入未知状态

修复：Coder 的约束是"遇到技术难题可以呼叫 Architect 一起讨论"，
      不是"自己硬扛到成功"。遇到难题应该立即反馈，让 Architect 知道

失败模式三：Shared Brain 变成单向日志

现象：Architect 写了大量 PRD 和任务说明，但 Coder 从不更新 Shared Brain
      Shared Brain 变成了 Architect 的独角戏

问题：Coder 的进展和反馈对 Architect 不可见，双方信息不对称

修复：要求 Coder 在每次任务完成后必须写入协作日志，
      连续三次不写入，Architect 应主动呼叫 Coder 要求更新

失败模式四：Architect 做了太多实现决策

现象：Architect 在 PRD 里写了"目录结构、变量命名、函数拆分"
       Coder 变成了"打字员"，没有自己的判断空间

问题：Architect 的实现决策不一定最优，Coder 有实现经验可以优化设计

修复：Architect 的 PRD 只定义"做什么"和"做到什么程度"，
      具体的"怎么做"留给 Coder 判断（除非涉及架构一致性）

八、完整协作流程图

┌─────────────────────────────────────────────────────────────┐
│  Architect                                                  │
│                                                             │
│  [接收任务] → [分析需求] → [输出 PRD] → [写入 Shared Brain]  │
│                                       ↓                    │
│                                   [通知 Coder]               │
│                                                             │
│  [读取 Shared Brain] ← [接收 Coder 反馈] ← [Coder 实现完成]   │
│         ↓                                              ↑   │
│    [评估结果]                                         │   │
│    [更新决策] ─────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Shared Brain 是唯一的信息交换通道：

  Architect 写入：PRD 链接、任务队列、已完成决策
  Coder 写入：    协作日志、任务状态更新、技术反馈、热点问题

九、总结：双脑协作的核心原则

角色边界清晰：Architect 不写代码，Coder 不做设计决策
Shared Brain 是唯一信息通道：不在聊天里做关键交接，所有重要信息必须写入 Shared Brain
PRD 驱动交接：Architect 的输出物必须达到 Coder 能直接执行的程度
边界确认在前：Coder 收到任务后先确认理解，再开始实现
反馈是双向的：Coder 可以质疑 Architect 的设计，Architect 必须接受合理反馈
协作日志持续更新：每次协作事件后，双方都有义务更新 Shared Brain

双脑协作的目标不是让两个 Agent 变成一个，而是让两个 Agent 在各自擅长的领域做到最好，然后通过结构化的协作机制把它们的能力串联起来。

Shared Brain 是这个协作机制的神经中枢。没有它，两个 Agent 只是在各自运行；有它，两个 Agent 才是真正在协作。

目录