# Convoke Agents：基于BMAD方法论的AI智能体团队协作框架 > Convoke是一个基于BMAD方法论的多智能体协作框架，提供Vortex产品发现团队和Gyre生产就绪团队，支持模块化安装和团队工厂功能。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-04-03T07:15:15.000Z - 最近活动: 2026-04-03T07:22:14.161Z - 热度: 114.9 - 关键词: AI智能体, 多智能体协作, BMAD, 产品发现, 生产就绪, Claude, 工作流, 团队工厂 - 页面链接: https://www.zingnex.cn/forum/thread/convoke-agents-bmadai - Canonical: https://www.zingnex.cn/forum/thread/convoke-agents-bmadai - Markdown 来源: ingested_event --- ## 背景：从单智能体到智能体团队\n\n随着大语言模型能力的不断提升，AI智能体（AI Agent）正在从简单的问答工具演变为能够执行复杂任务的自主系统。然而，单一智能体在处理复杂业务场景时往往面临能力边界的问题——一个智能体难以同时精通用户研究、产品设计、技术实现和运维保障等多个领域。\n\nConvoke Agents的出现正是为了解决这一问题。它基于BMAD（Behavioral Model for Agent Development）方法论，将多个专业智能体组织成协作团队，每个智能体专注于特定领域，通过结构化的工作流和契约实现高效协作。\n\n## 项目概述\n\nConvoke由开发者Amalik创建，是一个模块化的AI智能体团队协作框架。它的核心理念是：复杂问题需要专业分工，而专业分工需要结构化的协作机制。\n\nConvoke提供了两种类型的可安装模块：\n\n- **团队（Teams）**：为特定领域带来一组专业智能体\n- **技能（Skills）**：为现有智能体添加新的能力\n\n用户可以独立安装或组合使用这些模块，构建适合自己需求的智能体团队。\n\n## 核心组件\n\n### Vortex：产品发现团队\n\nVortex是一个由7个智能体组成的产品发现团队，包含22个工作流，帮助团队从用户洞察到基于证据的决策。\n\n#### 七流七智能体架构\n\nVortex采用连续发现循环的设计，而非一次性的检查清单。七个智能体分别负责七个发现流：\n\n```\n┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐\n│ Isla │──▶│ Mila │──▶│ Liam │──▶│ Wade │\n│ Empathize │ │ Synthesize │ │ Hypothesize │ │ Externalize │\n└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘\n ▲ │\n │ │\n │ ┌─────────────┐ ┌─────────────┐ │\n └────────│ Emma │◀──│ Max │◀──│ Noah │◀───────┘\n │Contextualize│ │ Systematize │ │ Sensitize │\n └─────────────┘ └─────────────┘ └─────────────┘\n```\n\n#### 智能体职责\n\n| 智能体 | 流 | 职责 |\n|--------|-----|------|\n| Emma 🎯 | Contextualize | 框定正确的问题——定义用户画像、产品愿景、范围 |\n| Isla 🔍 | Empathize | 理解用户——共情图、访谈、发现研究 |\n| Mila 🔬 | Synthesize | 将研究汇聚成清晰的问题定义 |\n| Liam 💡 | Hypothesize | 将问题转化为可测试的假设和实验 |\n| Wade 🧪 | Externalize | 用MVP、实验和原型测试假设 |\n| Noah 📡 | Sensitize | 解读生产信号、用户行为和参与度模式 |\n| Max 🧭 | Systematize | 捕获学习并决策：转向、修补或坚持 |\n\n每个工作流结束时，Compass会路由到需要关注的流——用户可以从任何智能体开始或返回。\n\n#### 实际应用示例\n\n以"忙碌父母的膳食规划"项目为例：\n\n**Emma框定问题**：\n\n> 待完成工作：消除每天下午5:30的晚餐决策负担，让我能在时间压力下为家人提供良好的饮食，而不需要规划、购物和决策的心理负担。\n>\n> 最危险的假设：\n> - 决策疲劳——而非烹饪技能或食材获取——是工作日晚餐成功的首要障碍\n> - 父母会信任并执行外部提供的晚餐建议，而不需要自己选择\n> - "足够好"的营养是可接受的标准——父母不追求完美，他们寻求的是摆脱内疚感\n\n**Liam将问题转化为可测试的想法**：\n\n> 假设1：通勤前决策消除器\n>\n> 我们相信，忙碌的父母会在下午4:00收到单一晚餐建议后的3分钟内采取行动，因为决策负担——而非烹饪——是他们的首要障碍，而更早的干预能在焦虑螺旋开始之前抓住他们。\n\n**Max捕获学习并决策下一步**：\n\n> 建议：修补（迭代时间，不转向方向）\n>\n> 核心假设已验证。产品方向（通过单一建议消除决策）是正确的。时间机制需要优化——从固定的下午4:00推送改为基于每个用户观察到的参与模式的自适应推送。\n\n### Gyre：生产就绪团队\n\nGyre是一个由4个智能体组成的生产就绪团队，包含7个工作流，评估项目是否准备好发布。\n\n#### 四智能体四契约架构\n\n```\n┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐\n│ Scout │──▶│ Atlas │──▶│ Lens │──▶│ Coach │\n│ Detect │ │ Model │ │ Analyze │ │ Review │\n│ Stack │ │ Capabil. │ │ Gaps │ │ Refine │\n└─────────────┘ └──────▲──────┘ └─────────────┘ └──────┬──────┘\n │ │\n └────────── GC4 feedback ───────┘\n```\n\n#### 智能体职责\n\n| 智能体 | 角色 | 职责 |\n|--------|------|------|\n| Scout 🔎 | Detect | 扫描文件系统产物，分类技术栈——语言、容器、CI/CD、可观测性、云提供商 |\n| Atlas 📐 | Model | 使用行业标准（DORA、OpenTelemetry、Google PRR）生成能力清单 |\n| Lens 🔬 | Analyze | 对比能力与实际存在的内容——发现缺失、复合风险、按严重性排序的发现 |\n| Coach 🏋️ | Review | 对话式审查发现——修正模型、捕获反馈、跟踪进度 |\n\n#### 结构化产物\n\nGyre将结构化产物写入项目根目录的`.gyre/`文件夹：\n\n- **Stack Profile** (`.gyre/stack-profile.yaml`)：分类的技术栈及检测置信度\n- **Capabilities Manifest** (`.gyre/capabilities.yaml`)：20+能力，涵盖可观测性、部署、可靠性和安全性\n- **Findings Report** (`.gyre/findings.yaml`)：基于缺失的发现，按严重性、置信度和来源标记\n- **Feedback Log** (`.gyre/feedback.yaml`)：团队修正，持续改进模型\n\n三种运行模式：\n\n- **Crisis（危机）**：首次运行，完整流水线\n- **Anticipation（预期）**：使用缓存模型重新分析\n- **Regeneration（再生）**：全新模型重建\n\n### Enhance：技能增强\n\nEnhance为现有智能体添加新的工作流，通过菜单补丁安装，而非修改智能体本身。首个技能为PM智能体添加了RICE评分的待办事项管理：\n\n```\n┌─────────────┐ ┌─────────────┐ ┌─────────────┐\n│ [T] Triage │ │ [R] Review │ │ [C] Create │\n│ Ingest new │ │ Rescore │ │ Bootstrap │\n│ findings │ │ existing │ │ from scratch│\n└──────┬──────┘ └──────┬──────┘ └──────┬──────┘\n │ │ │\n ▼ ▼ ▼\n┌──────────────────────────────────────────────────┐\n│ initiatives-backlog.md │\n│ RICE-scored · Categorized · Change-tracked │\n└──────────────────────────────────────────────────┘\n```\n\n### Team Factory：团队工厂\n\n团队工厂通过引导式工作流创建完全符合BMAD标准的团队，无需事后修复：\n\n- **组合模式选择**：独立模式或顺序模式\n- **智能体范围定义**：带重叠检测\n- **契约设计**：定义智能体间的交接契约\n- **集成布线**：自动完成集成\n\n三种能力：\n\n- **Create Team**：从头构建新团队\n- **Add Agent**：扩展现有团队\n- **Add Skill**：为现有智能体添加新工作流\n\n## BMAD方法论\n\nConvoke基于BMAD（Behavioral Model for Agent Development）方法论，该方法论定义了：\n\n1. **智能体行为模型**：每个智能体有明确的角色、职责和行为边界\n2. **契约驱动协作**：智能体间通过结构化的契约（Contract）进行交接\n3. **工作流编排**：复杂任务分解为可编排的工作流\n4. **持续改进机制**：通过反馈循环不断优化团队表现\n\n## 安装与使用\n\n### 环境要求\n\n- Node.js 18+ 或 Bun\n- Git\n- Claude Code 或 Claude.ai\n\n### 安装\n\n**完整安装（Vortex + Gyre）**：\n```bash\nnpm install convoke-agents@latest\nnpx convoke-install\n```\n\n**仅Vortex**：\n```bash\nnpm install convoke-agents@latest\nnpx convoke-install-vortex\n```\n\n**仅Gyre**：\n```bash\nnpm install convoke-agents@latest\nnpx convoke-install-gyre\n```\n\n### 配置\n\n编辑`_bmad/bme/_vortex/config.yaml`或`_bmad/bme/_gyre/config.yaml`，将`{user}`替换为您的姓名。智能体会使用此配置个性化交互。\n\n### 激活智能体\n\n**Claude Code（技能）**：\n```\n# Vortex\n/bmad-agent-bme-contextualization-expert # Emma 🎯\n/bmad-agent-bme-discovery-empathy-expert # Isla 🔍\n...\n\n# Gyre\n/bmad-agent-bme-stack-detective # Scout 🔎\n/bmad-agent-bme-model-curator # Atlas 📐\n...\n```\n\n每个智能体是一个包含完整角色、菜单系统和工作流指令的Markdown文件。当Claude读取文件时，它会采用该智能体的专业知识并呈现交互式菜单。\n\n## 应用场景\n\n### 产品团队\n\n- 新产品从0到1的发现过程\n- 现有产品的持续优化迭代\n- 用户研究和需求验证\n\n### 工程团队\n\n- 新项目的技术栈评估\n- 生产就绪性检查\n- 技术债务识别和优先级排序\n\n### 跨职能协作\n\n- 产品-工程对齐\n- 需求到实现的完整追踪\n- 持续交付流程优化\n\n## 总结与展望\n\nConvoke Agents代表了AI智能体应用的重要演进——从单一智能体到专业化团队协作。通过BMAD方法论的结构化指导，Convoke使得复杂业务场景的AI辅助成为可能。\n\nVortex和Gyre两个团队分别覆盖了产品发现和生产就绪两个关键领域，而团队工厂和技能增强机制则提供了强大的扩展能力。对于希望系统性地引入AI智能体辅助的团队来说，Convoke提供了一个经过深思熟虑的框架和实践路径。\n\n随着AI智能体技术的不断发展，像Convoke这样的协作框架将成为企业级AI应用的重要基础设施。