vibe coding多Agent协同解决方案

单会话里让一个模型又当 PM、又画界面、又写代码、又去测试，往往会出现两类问题：职责混在一起导致决策漂移，以及上下文越来越长导致成本和延迟一起上涨。那能不能用多Agent协同来解决这个问题呢？

方案一 通过共享目录实现多Agent协同通信

1. 能不能用多Agent搭建一个team呢？

参考我们日常的工作模式，给每个Agent创建一个角色，让他们各司其职，这个方案也许值得一试

### 📋 任务分配原则

用户需求 → 赵六分析 → 分配给对应AI → 执行 → 赵六汇总

**分配规则**:
- 设计类需求 → 张三处理
- 开发类需求 → 李四处理
- 测试类需求 → 王五处理
- 管理类需求 → 赵六处理

graph LR
    A[用户需求] --> B[赵六分析]
    B --> C{任务类型}
    C -->|设计| D[张三处理]
    C -->|开发| E[李四处理]
    C -->|测试| F[王五处理]
    C -->|管理| G[赵六处理]

    D --> H[common/状态同步]
    E --> H
    F --> H
    G --> H

    H --> I[赵六汇总]
    I --> J[交付成果]

其实，就是想定一个协议——谁读需求、谁写产物、产物落在哪、最后谁汇总，都要写得像 API 一样清楚。

典型五步：从需求到交付

回想一下我们日常交付有哪些环节呢？

1. 需求分析 —— 协调侧判断类型与优先级
2. 任务分配 —— 按职责边界交给对应角色
3. 分角色执行 —— 各角色只在己方边界内产出，可以通过person.md定义角色
4. 状态同步 —— 通过 common/ 等共享区写进度与产物
5. 成果汇总 —— 协调侧整合后对用户交付

2. 那怎么打通流程呢？

2.1 设计交给开发：不是简单的来一句「你实现吧」

设计侧要检查布局、规范、组件状态、交互与异常，再生成说明，输入给开发——这其实是跨 Agent 的约定：

### 1. 检查设计完整性

确认设计稿包含：
- [ ] 页面布局（ASCII图示）
- [ ] 设计规范（颜色、字体、间距）
- [ ] 组件状态（默认、hover、active、disabled）
- [ ] 交互说明
- [ ] 异常状态处理

### 2. 生成开发交付文档

# 设计交付 - [功能名称]

## 交付信息
设计师: 张三
交付日期: YYYY-MM-DD
设计稿位置: ../common/designs/[文件名].md

2.2 多会话之间怎么「看见」彼此

人是在不同聊天窗口里切换「角色」的，机器并不会自动共享内存。我们可以用共享目录（如 common/ 下的状态、任务、设计、评审）做统一出入口，并辅以基于文件变更的通知检查——先比时间戳/缓存，再决定要不要读大段通知数据，这是在多 Agent 场景里很务实的**省钱与省 token的策略。

通知脚本：

#!/bin/bash

################################################################################
# 通知检查脚本 - 智能缓存版本
# 用途: AI会话启动时检查是否有新通知
################################################################################

# 配置
AI_NAME="${1:-zhangsan}"  # 第一个参数为AI名称，默认zhangsan
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
SHARED_DIR="$(dirname "$SCRIPT_DIR")"
NOTIFICATION_FILE="$SHARED_DIR/xxx.json"
CACHE_FILE="$SHARED_DIR/.xxx_cache.json"

2.3 同一仓库里如何多路并行？

面向 issue / worktree 的并行工作流我们可以这么处理：用「流」划分文件边界，用提交与进度文件进行通信，如果有冲突则交给我们人工兜底。

部分rules

文件级并行与显式协调：

## Parallel Execution Principles

1. **File-level parallelism** - Agents working on different files never conflict
2. **Explicit coordination** - When same file needed, coordinate explicitly
3. **Fail fast** - Surface conflicts immediately, don't try to be clever
4. **Human resolution** - Conflicts are resolved by humans, not agents

并行协调类角色的职责：

## Core Responsibilities

### 1. Read and Understand
- Read the issue requirements from the task file
- Read the issue analysis to understand parallel streams
- Identify which streams can start immediately
- Note dependencies between streams

### 2. Spawn Sub-Agents
For each work stream that can start, spawn a sub-agent using the Task tool:

3. Token、模型与 Task 分解

多 Agent 如果只靠「多开聊天」，最容易失控的是同一问题被多个会话重复解释，token 与延迟一起上涨。必须要把成本意识写进机制。

具体思路：在基础调用上选对模型档、在质量与成本之间做权衡、对可拆任务做 **Task 分解。各角色侧重的 tactic 不同（管理结构化、设计模板化、开发模块化、测试报告模板化等），但目标一致：少重复、少“空转”。

任务复杂度评估
├─ 简单操作（文件读写、格式化）→ 轻量档
├─ 中等复杂（分析、设计、开发）→ 默认档
└─ 高度复杂（战略、强创新）→ 最高档

双重强制优化：一侧要求每次交互先对齐优化策略文档，另一侧在检测到「多步骤 / 多文件 / 可并行」时倾向走 Task 工具分解，让主会话只接受摘要结果，而不是吞掉所有中间探索的过程。

4. 标准化接口

若把每个角色看作一个服务，命令就是对外最稳定的 API：用户不必每次重新描述如「我要写测试用例」，而是调用约定好的入口。README 中按角色列出的技能命令包括：

角色	示例命令
协调	状态汇总、项目报告、会议与待办、产品建议
设计	界面/原型、设计交付（如 handoff）、规范类流程
开发	编码与架构、部署、调试、代码审查
质量	测试、安全/代码审查、需求验收、质量报告

职责边界需要写在 PERSONA.md 里：角色分工互不干扰——这是减少上下文污染的有效协调手段

方案二 官方Agent Teams（Claude Code为例）

1. Claude Code Agent Teams

Claude Code Agent Teams 是 Claude Code 的实验功能（默认关闭）：多个 独立会话 作为队友协作，带 共享任务列表 与 Mailbox，成员之间可互相发消息。
Lead 负责建队、派活、汇总与清理。
官方要求 v2.1.32+，需要注意的是Token 显著高于单会话。

1.1 与 Subagents 的取舍

维度	Subagents	Agent Teams
通信	只回报主会话	成员之间可直接通信
协调	主代理统管	共享任务列表 + 自协调
Token	较低	较高
典型场景	聚焦子任务	需协作、并行探索、多视角审查或竞争性假设调试

顺序依赖重、同文件抢改、任务很碎时，优先单会话或 Subagents。

1.2 命令行用法（CLI）

版本查询

claude --version

需 2.1.32 或更高 才具备 Agent Teams。

用环境变量开启实验能力（当前 Shell）

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude

或在登录脚本、~/.zshrc 中持久化 export（按个人习惯二选一；与 settings.json 的 env 重复时以实际生效为准）。

进入仓库再启动（绑定工作目录与 CLAUDE.md）

cd /path/to/your-repo
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude --project .

子目录多包场景可改为 claude --project packages/frontend 等。

队友展示模式（单次会话强制 in-process）

claude --teammate-mode in-process

全局默认写在 ~/.claude.json 的 teammateMode中（如 "in-process"、"tmux"、"auto"），与 CLI 叠加时以文档与当前版本行为为准。

权限（全员继承 Lead，仅可信环境）

claude --dangerously-skip-permissions

Lead 若带此参数，所有队友同样跳过权限闸门，需要慎重哦

分屏依赖与 tmux 排障

which tmux
tmux ls
tmux kill-session -t <session-name>

分屏需 要tmux 或 iTerm2

1.3 配置文件（与 CLI 二选一或并用）

持久开启推荐 settings.json（macOS/Linux 常见为 ~/.claude/settings.json）：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

修改后重启 Claude Code

1.4 建队：在 Lead 里用自然语言

在已开启实验能力的 Lead 会话中，优先用自然语言描述任务与分工，例如：

Create an agent team to explore this from different angles: one teammate on UX,
one on technical architecture, one playing devil's advocate.

可补充人数、模型（如「Use Sonnet for each teammate」）、是否 plan approval（先计划后改代码）。

命令示例

# 1. 创建团队（指定负责人名称）
/team create --lead "架构师"

# 2. 添加智能体团队成员（指定成员名称与角色）
/team add --name "设计工程师" --role "负责设计"
/team add --name "开发工程师" --role "负责开发"
/team add --name "测试工程师" --role "负责测试用例更新"

# 3. 创建共享任务列表，设置任务依赖
/team task add "重构设计" --assignee "登录设计工程师"
/team task add "重构开发" --assignee "注册开发工程师"
/team task add "更新测试用例" --assignee "测试工程师" --depends-on "重构设计流程,重构开发流程"

# 4. 启动智能体团队协作（开始执行任务）
/team start

• --depends-on：有的版本要求填任务 ID 而非标题
• 若依赖未生效，用 /team task list核对后再改
• 若提示未知命令，可以使用自然语言建队，或查阅 Agent teams 官方文档

1.5 架构与本地路径

组件	作用
Team lead	建队、派活、汇总、清理
Teammates	独立实例，独立上下文
Task list	共享任务与依赖
Mailbox	成员间消息（广播成本高，慎用）

本地自动生成（勿手改）：

• ~/.claude/teams/{team-name}/config.json
• ~/.claude/tasks/{team-name}/

1.6 终端内操作（会话已启动后）

• In-process：Shift+Down 在 Lead 与队友间切换并可直接输入
• Enter 查看队友、Escape 打断、Ctrl+T 任务列表
• Split panes：点击各窗口与队友单独对话
• 收尾：向 Lead 说 「Clean up the team」；结束前可先让 Lead shutdown 指定队友
• 队友不宜自行执行 cleanup
• Hooks：TeammateIdle、TaskCreated、TaskCompleted 等（退出码 2 可拦截）

1.7 延伸阅读

• Agent teams 官方文档
• Token 与成本 · agent team
• Subagents、Git worktrees 并行会话

总结：

整体来说，多Agent协同确实会让各个Agent职责清晰，同时上下文理解变得容易些，但也带来很多边界问题，特别是我们一开始采用共享文件进行通信的做法。考虑到种种原因，我们最后并没有选择这套方案落地，但还是写下了摸索的过程，大家有尝试过这种方案并且落地的吗？欢迎评论区讨论。