Multi-Agent 协作CrewAI 实战一个 Agent 是员工多个 Agent 是团队。本文用 CrewAI 搭建一个「产品经理 开发 测试」三人开发小组看他们怎么协作完成一个真实需求。一、为什么需要 Multi-Agent单 Agent 的瓶颈用户帮我做一个待办事项 App需要前端后端和数据库 单 Agent 的困境 - 前端要 React后端要 FastAPI数据库要 PostgreSQL - 一个 Agent 得同时掌握三种技术栈 - 上下文很快被占满 - 生成的代码风格不统一Multi-Agent 的解法用户需求 │ ┌───────▼───────┐ │ PM Agent │ 分析需求拆解任务 └───────┬───────┘ │ ┌───────────┼───────────┐ ▼ ▼ ▼ 前端 Agent 后端 Agent 测试 Agent (React) (FastAPI) (Pytest) │ │ │ └───────────┼───────────┘ ▼ 整合 交付二、CrewAI 核心概念概念含义示例Agent一个 AI 角色PM、前端开发、QATask分配给 Agent 的具体任务“设计 API 接口”CrewAgent 团队“开发小组”Process协作模式sequential顺序/ hierarchical层级三、搭建三人开发团队# pip install crewai langchain-openaifromcrewaiimportAgent,Task,Crew,Processfromlangchain_openaiimportChatOpenAI# ── 共用 LLM ──llmChatOpenAI(modeldeepseek-chat,api_keyyour-key,base_urlhttps://api.deepseek.com/v1)# ── 1. 定义三个 Agent ──pm_agentAgent(role产品经理,goal分析用户需求输出清晰的技术需求文档,backstory你有 5 年 SaaS 产品经验擅长把模糊需求转化为可执行的技术方案,llmllm,verboseTrue)frontend_agentAgent(role前端开发工程师,goal根据技术需求用 React TypeScript 实现前端界面,backstory你是一个 React 专家擅长组件化开发和状态管理,llmllm,verboseTrue)backend_agentAgent(role后端开发工程师,goal根据技术需求用 FastAPI SQLAlchemy 实现后端 API,backstory你是一个 Python 后端专家擅长 RESTful API 设计和数据库建模,llmllm,verboseTrue)qa_agentAgent(role测试工程师,goal验证前后端代码的功能完整性和质量,backstory你有 3 年自动化测试经验擅长单元测试、集成测试和边界条件测试,llmllm,verboseTrue)Agent 设计的核心要素Role角色越具体越好。「前端开发」不如「React 前端工程师擅长 TypeScript 和 Tailwind CSS」。Goal目标单一、明确。「写代码」不如「根据 PRD 用 React TypeScript 实现前端界面包含 Loading/空数据/错误三种状态」。Backstory背景给 Agent 一段「故事」让它的回答更有风格。不是闲聊而是影响它如何做决策。四、定义任务# ── 2. 定义任务链 ──task_prdTask(description 用户需求做一个个人记账 Web 应用。 功能要求 1. 记录收入/支出金额、分类、备注、日期 2. 查看月度收支汇总 3. 分类统计饼图 请输出一份技术需求文档包含 - 数据模型设计 - API 接口定义 - 前端页面结构 - 技术栈选型 ,expected_output一份 Markdown 格式的技术需求文档,agentpm_agent)task_backendTask(description 根据 PM 的技术需求文档实现后端 API。 要求 - FastAPI SQLAlchemy SQLite - 完整的 CRUD 接口 - 月度汇总接口 - 添加请求参数校验和错误处理 ,expected_output完整的 Python 后端代码包含所有 API 接口,agentbackend_agent)task_frontendTask(description 根据 PM 的技术需求文档和后端 API实现前端界面。 要求 - React TypeScript - 记账表单金额、分类下拉、备注、日期选择 - 交易列表分页、筛选 - 月度汇总卡片 - 分类饼图用 recharts ,expected_output完整的前端代码包含所有页面和组件,agentfrontend_agent)task_qaTask(description 审查前后端代码检查 1. 前端是否处理了 Loading/空数据/错误三种状态 2. 后端 API 是否有输入校验 3. 前后端数据格式是否一致 输出测试报告和改进建议。 ,expected_output测试报告列出发现的问题和建议,agentqa_agent)五、组建 Crew 并运行# ── 3. 组建团队 ──dev_teamCrew(agents[pm_agent,frontend_agent,backend_agent,qa_agent],tasks[task_prd,task_backend,task_frontend,task_qa],processProcess.sequential,# 顺序执行PM → 后端 → 前端 → 测试verboseTrue)# ── 4. 启动 ──resultdev_team.kickoff()print(result)执行过程 Crew 启动 ├── PM Agent 正在写 PRD... │ ✅ PRD 完成技术栈React FastAPI SQLite ├── 后端 Agent 正在写代码... │ ✅ 5 个 API 接口完成 ├── 前端 Agent 正在写代码... │ ✅ 4 个页面组件完成 └── 测试 Agent 正在审查... ✅ 发现 3 个问题建议 2 处改进 交付物 - 技术需求文档 × 1 - 后端代码 × 5 文件 - 前端代码 × 6 文件 - 测试报告 × 1六、两种协作模式Sequential顺序模式Task 1 → Task 2 → Task 3 → Task 4 (PM) (后端) (前端) (QA)每个任务的输出自动作为下一个任务的上下文。适合有明确前后依赖的任务。Hierarchical层级模式┌─────────┐ │ Manager │ ← 分配任务、审核结果 │ Agent │ └────┬─────┘ ┌───────────┼───────────┐ ▼ ▼ ▼ Agent 1 Agent 2 Agent 3Manager Agent 负责拆任务、分派、汇总。适合复杂、需要动态决策的场景。# 层级模式示例managerAgent(role技术总监,goal协调开发团队确保项目按时高质量交付,backstory你是技术总监10 年经验擅长资源调配和项目管控,llmllm,allow_delegationTrue# 允许委派任务)hierarchical_crewCrew(agents[manager,frontend_agent,backend_agent,qa_agent],tasks[task_prd,task_backend,task_frontend,task_qa],processProcess.hierarchical,manager_agentmanager)七、Multi-Agent 实战要点7.1 Agent 角色要互补而非重叠❌ 两个 Agent 都会写 React → 代码冲突 ✅ 前端 Agent 写 UIUI 设计 Agent 出设计稿7.2 任务描述要能被下游消费# ❌ 太模糊Task(description写后端代码,...)# ✅ 下游 Agent 能直接用Task(description根据 PRD 实现 API。输出格式Python 代码每个文件用 FILE: xxx.py 分隔,expected_output格式化的 Python 代码,...)7.3 设置重试和超时Task(...,max_retries2,# 失败重试 2 次max_execution_time300# 最多 5 分钟)八、CrewAI vs AutoGen vs LangGraph维度CrewAIAutoGenLangGraph学习曲线⭐⭐ 简单⭐⭐⭐ 中等⭐⭐⭐⭐ 较陡角色定义Role Goal BackstoryAgent System MessageNode 函数协作模式顺序 / 层级对话式状态图适合场景固定流程动态对话精细控制中文支持✅ 好 一般✅ 好建议先用 CrewAI 入门理解 Multi-Agent 的逻辑后再学 LangGraph 做精细控制。九、总结Multi-Agent 解决单 Agent 的复杂度瓶颈——术业有专攻CrewAI 用角色目标背景定义 Agent——像招人一样招 AI顺序模式适合固定流程层级模式适合动态决策Agent 角色要互补、任务描述要明确、输出格式要规范十、生产实战Multi-Agent 的隐藏成本10.1 成本Agent 越多不等于越好单 Agent 完成任务 1 个 LLM 调用 → 5000 Token → 完成 CrewAI 4 个 Agent 完成同一个任务 PM Agent: 2000 Token 后端 Agent: 3000 Token 前端 Agent: 3000 Token 测试 Agent: 2000 Token ─────────────────────── 总计: 10000 Token (2×) 时间: 4×串行模式下经验评估一个任务是否真的需要 Multi-Agent。如果任务能在一个 Agent 的 Context Window 内完成单 Agent 更便宜更快。Multi-Agent 用于「单 Agent 真的搞不定」的场景。10.2 Agent 间的沟通成本Agent 的输出给下一个 Agent ——如果格式不一致后面全乱# PM Agent 输出的数据模型 → 前后端 Agent 必须严格一致{api:{GET /transactions:{params:{month:string},response:{transactions:array,total:number}}}}# 如果 PM 输出 {total: int} 但后端写成 {total: float}# 前端解析会炸 → 而 Agent 不会主动告诉你经验Multi-Agent 项目中PM Agent 的输出用严格的 JSON Schema 约束。后续 Agent 在开始干活前先验证上游输入是否合法。10.3 错误级联一个小错放大 4 倍PM Agent 理解错了一个需求 → 后端按错的写 → 前端按错的对接 → 测试按错的验证 → 4 个 Agent 都在做无用功。# 每步执行后做验证classValidatedTask(Task):defexecute(self,context):resultsuper().execute(context)# 如果是 PM 的输出先给用户看一眼ifself.agent.role产品经理:ifnotconfirm_with_human(result):return{error:用户撤销了 PRD}returnresult经验在 PM Agent 之后加一个「人类确认」环节收益远大于成本。PM 错 全线错。10.4 什么时候不该用 Multi-Agent场景建议理由单步骤简单任务单 AgentMulti-Agent 纯属浪费任务可在一个 Context Window 完成单 Agent串行 Multi-Agent 更慢更贵Agent 角色高度重叠单 Agent两个 Agent 干同样的事 内耗需要极致低延迟 1s单 AgentMulti-Agent 串行延迟叠加复杂多领域任务Multi-Agent单 Agent Context 不够用 系列完结。8 篇文章从 Token 原理写到 Multi-Agent 协作每篇都带了生产环境的真实经验和坑。接下来的关键是把这些串起来做一个你自己的 Agent 产品——代码是学出来的经验是踩坑踩出来的。
CrewAI实战：多智能体协作开发完整指南
Multi-Agent 协作CrewAI 实战一个 Agent 是员工多个 Agent 是团队。本文用 CrewAI 搭建一个「产品经理 开发 测试」三人开发小组看他们怎么协作完成一个真实需求。一、为什么需要 Multi-Agent单 Agent 的瓶颈用户帮我做一个待办事项 App需要前端后端和数据库 单 Agent 的困境 - 前端要 React后端要 FastAPI数据库要 PostgreSQL - 一个 Agent 得同时掌握三种技术栈 - 上下文很快被占满 - 生成的代码风格不统一Multi-Agent 的解法用户需求 │ ┌───────▼───────┐ │ PM Agent │ 分析需求拆解任务 └───────┬───────┘ │ ┌───────────┼───────────┐ ▼ ▼ ▼ 前端 Agent 后端 Agent 测试 Agent (React) (FastAPI) (Pytest) │ │ │ └───────────┼───────────┘ ▼ 整合 交付二、CrewAI 核心概念概念含义示例Agent一个 AI 角色PM、前端开发、QATask分配给 Agent 的具体任务“设计 API 接口”CrewAgent 团队“开发小组”Process协作模式sequential顺序/ hierarchical层级三、搭建三人开发团队# pip install crewai langchain-openaifromcrewaiimportAgent,Task,Crew,Processfromlangchain_openaiimportChatOpenAI# ── 共用 LLM ──llmChatOpenAI(modeldeepseek-chat,api_keyyour-key,base_urlhttps://api.deepseek.com/v1)# ── 1. 定义三个 Agent ──pm_agentAgent(role产品经理,goal分析用户需求输出清晰的技术需求文档,backstory你有 5 年 SaaS 产品经验擅长把模糊需求转化为可执行的技术方案,llmllm,verboseTrue)frontend_agentAgent(role前端开发工程师,goal根据技术需求用 React TypeScript 实现前端界面,backstory你是一个 React 专家擅长组件化开发和状态管理,llmllm,verboseTrue)backend_agentAgent(role后端开发工程师,goal根据技术需求用 FastAPI SQLAlchemy 实现后端 API,backstory你是一个 Python 后端专家擅长 RESTful API 设计和数据库建模,llmllm,verboseTrue)qa_agentAgent(role测试工程师,goal验证前后端代码的功能完整性和质量,backstory你有 3 年自动化测试经验擅长单元测试、集成测试和边界条件测试,llmllm,verboseTrue)Agent 设计的核心要素Role角色越具体越好。「前端开发」不如「React 前端工程师擅长 TypeScript 和 Tailwind CSS」。Goal目标单一、明确。「写代码」不如「根据 PRD 用 React TypeScript 实现前端界面包含 Loading/空数据/错误三种状态」。Backstory背景给 Agent 一段「故事」让它的回答更有风格。不是闲聊而是影响它如何做决策。四、定义任务# ── 2. 定义任务链 ──task_prdTask(description 用户需求做一个个人记账 Web 应用。 功能要求 1. 记录收入/支出金额、分类、备注、日期 2. 查看月度收支汇总 3. 分类统计饼图 请输出一份技术需求文档包含 - 数据模型设计 - API 接口定义 - 前端页面结构 - 技术栈选型 ,expected_output一份 Markdown 格式的技术需求文档,agentpm_agent)task_backendTask(description 根据 PM 的技术需求文档实现后端 API。 要求 - FastAPI SQLAlchemy SQLite - 完整的 CRUD 接口 - 月度汇总接口 - 添加请求参数校验和错误处理 ,expected_output完整的 Python 后端代码包含所有 API 接口,agentbackend_agent)task_frontendTask(description 根据 PM 的技术需求文档和后端 API实现前端界面。 要求 - React TypeScript - 记账表单金额、分类下拉、备注、日期选择 - 交易列表分页、筛选 - 月度汇总卡片 - 分类饼图用 recharts ,expected_output完整的前端代码包含所有页面和组件,agentfrontend_agent)task_qaTask(description 审查前后端代码检查 1. 前端是否处理了 Loading/空数据/错误三种状态 2. 后端 API 是否有输入校验 3. 前后端数据格式是否一致 输出测试报告和改进建议。 ,expected_output测试报告列出发现的问题和建议,agentqa_agent)五、组建 Crew 并运行# ── 3. 组建团队 ──dev_teamCrew(agents[pm_agent,frontend_agent,backend_agent,qa_agent],tasks[task_prd,task_backend,task_frontend,task_qa],processProcess.sequential,# 顺序执行PM → 后端 → 前端 → 测试verboseTrue)# ── 4. 启动 ──resultdev_team.kickoff()print(result)执行过程 Crew 启动 ├── PM Agent 正在写 PRD... │ ✅ PRD 完成技术栈React FastAPI SQLite ├── 后端 Agent 正在写代码... │ ✅ 5 个 API 接口完成 ├── 前端 Agent 正在写代码... │ ✅ 4 个页面组件完成 └── 测试 Agent 正在审查... ✅ 发现 3 个问题建议 2 处改进 交付物 - 技术需求文档 × 1 - 后端代码 × 5 文件 - 前端代码 × 6 文件 - 测试报告 × 1六、两种协作模式Sequential顺序模式Task 1 → Task 2 → Task 3 → Task 4 (PM) (后端) (前端) (QA)每个任务的输出自动作为下一个任务的上下文。适合有明确前后依赖的任务。Hierarchical层级模式┌─────────┐ │ Manager │ ← 分配任务、审核结果 │ Agent │ └────┬─────┘ ┌───────────┼───────────┐ ▼ ▼ ▼ Agent 1 Agent 2 Agent 3Manager Agent 负责拆任务、分派、汇总。适合复杂、需要动态决策的场景。# 层级模式示例managerAgent(role技术总监,goal协调开发团队确保项目按时高质量交付,backstory你是技术总监10 年经验擅长资源调配和项目管控,llmllm,allow_delegationTrue# 允许委派任务)hierarchical_crewCrew(agents[manager,frontend_agent,backend_agent,qa_agent],tasks[task_prd,task_backend,task_frontend,task_qa],processProcess.hierarchical,manager_agentmanager)七、Multi-Agent 实战要点7.1 Agent 角色要互补而非重叠❌ 两个 Agent 都会写 React → 代码冲突 ✅ 前端 Agent 写 UIUI 设计 Agent 出设计稿7.2 任务描述要能被下游消费# ❌ 太模糊Task(description写后端代码,...)# ✅ 下游 Agent 能直接用Task(description根据 PRD 实现 API。输出格式Python 代码每个文件用 FILE: xxx.py 分隔,expected_output格式化的 Python 代码,...)7.3 设置重试和超时Task(...,max_retries2,# 失败重试 2 次max_execution_time300# 最多 5 分钟)八、CrewAI vs AutoGen vs LangGraph维度CrewAIAutoGenLangGraph学习曲线⭐⭐ 简单⭐⭐⭐ 中等⭐⭐⭐⭐ 较陡角色定义Role Goal BackstoryAgent System MessageNode 函数协作模式顺序 / 层级对话式状态图适合场景固定流程动态对话精细控制中文支持✅ 好 一般✅ 好建议先用 CrewAI 入门理解 Multi-Agent 的逻辑后再学 LangGraph 做精细控制。九、总结Multi-Agent 解决单 Agent 的复杂度瓶颈——术业有专攻CrewAI 用角色目标背景定义 Agent——像招人一样招 AI顺序模式适合固定流程层级模式适合动态决策Agent 角色要互补、任务描述要明确、输出格式要规范十、生产实战Multi-Agent 的隐藏成本10.1 成本Agent 越多不等于越好单 Agent 完成任务 1 个 LLM 调用 → 5000 Token → 完成 CrewAI 4 个 Agent 完成同一个任务 PM Agent: 2000 Token 后端 Agent: 3000 Token 前端 Agent: 3000 Token 测试 Agent: 2000 Token ─────────────────────── 总计: 10000 Token (2×) 时间: 4×串行模式下经验评估一个任务是否真的需要 Multi-Agent。如果任务能在一个 Agent 的 Context Window 内完成单 Agent 更便宜更快。Multi-Agent 用于「单 Agent 真的搞不定」的场景。10.2 Agent 间的沟通成本Agent 的输出给下一个 Agent ——如果格式不一致后面全乱# PM Agent 输出的数据模型 → 前后端 Agent 必须严格一致{api:{GET /transactions:{params:{month:string},response:{transactions:array,total:number}}}}# 如果 PM 输出 {total: int} 但后端写成 {total: float}# 前端解析会炸 → 而 Agent 不会主动告诉你经验Multi-Agent 项目中PM Agent 的输出用严格的 JSON Schema 约束。后续 Agent 在开始干活前先验证上游输入是否合法。10.3 错误级联一个小错放大 4 倍PM Agent 理解错了一个需求 → 后端按错的写 → 前端按错的对接 → 测试按错的验证 → 4 个 Agent 都在做无用功。# 每步执行后做验证classValidatedTask(Task):defexecute(self,context):resultsuper().execute(context)# 如果是 PM 的输出先给用户看一眼ifself.agent.role产品经理:ifnotconfirm_with_human(result):return{error:用户撤销了 PRD}returnresult经验在 PM Agent 之后加一个「人类确认」环节收益远大于成本。PM 错 全线错。10.4 什么时候不该用 Multi-Agent场景建议理由单步骤简单任务单 AgentMulti-Agent 纯属浪费任务可在一个 Context Window 完成单 Agent串行 Multi-Agent 更慢更贵Agent 角色高度重叠单 Agent两个 Agent 干同样的事 内耗需要极致低延迟 1s单 AgentMulti-Agent 串行延迟叠加复杂多领域任务Multi-Agent单 Agent Context 不够用 系列完结。8 篇文章从 Token 原理写到 Multi-Agent 协作每篇都带了生产环境的真实经验和坑。接下来的关键是把这些串起来做一个你自己的 Agent 产品——代码是学出来的经验是踩坑踩出来的。
