多Agent项目实战，搭建一个产品加开发加测试的AI项目团队

多Agent项目实战搭建一个产品加开发加测试的AI项目团队上篇把Agent通信的原理和代码讲完了。道理都懂了但真要把多个Agent捏成一个团队干活光有通信层还不够。谁干什么活谁先干谁后干中间产物怎么传出了岔子谁兜底这些得安排好。今天这篇就上手搭一个完整的AI项目团队三个角色产品经理Agent负责拆需求开发Agent负责写代码测试Agent负责写测试用例并执行。我用CrewAI来做这个框架天然适合定义角色和任务省得自己搭协作骨架。走完一遍你会发现从需求到代码到测试整条流程能自己跑起来。为什么用CrewAICrewAI的核心概念就三个Agent、Task、Crew。Agent定义角色和工具Task定义具体任务和期望输出Crew把Agent和Task组装起来管流程。跟你拉一个项目组的逻辑一样先定人再分活最后排个顺序开干。对比LangGraphCrewAI不用你手写状态图和路由逻辑。角色之间的传递顺序用Task的列表顺序就能控制想搞条件分支也有现成的机制。代价是灵活性差一些特别定制化的流程CrewAI不好搞。但搭一个标准的项目团队这种场景CrewAI足够了。安装很简单pip install crewai crewai-tools然后配好OpenAI的API key就行。CrewAI底层用的LangChain的LLM接口所以你用其他模型也行换个LLM配置就好。角色定义和职责划分三个Agent的职责得划清楚跟真实项目组一样。产品经理Agent拿到一个模糊的需求描述输出结构化的需求文档。包括功能点列表、验收标准、技术约束。这个Agent要会追问需求太模糊就给出合理的假设并标注出来。开发Agent拿到需求文档输出可运行的代码。要给出完整的函数实现加上注释附上使用说明。不能只给个函数签名就完事。测试Agent拿到需求文档和代码输出测试用例并执行。覆盖正常路径和边界情况给出测试报告哪些过了哪些没过。职责重叠是多Agent最容易出的问题。我一开始让开发Agent也写测试结果它自己写的代码自己测bug一个都测不出来。后来把测试单独拆出来测试Agent拿到代码以后从外部视角挑刺效果好多了。协作流程设计流程是串行的产品经理先干开发跟上测试收尾。前一个的输出是后一个的输入。需求进来先到产品经理Agent它分析完输出需求文档。需求文档传给开发Agent开发根据文档写代码。代码连同需求文档一起传给测试Agent测试Agent根据需求写测试用例拿代码跑测试最后出测试报告。如果测试没过怎么办。最简单的处理是测试Agent把失败原因反馈回来人工看一眼决定要不要让开发Agent重写。CrewAI也支持自动重试测不过就回到开发那一步重做但我建议先手动跑通再考虑自动化不然一个bug可能让三个Agent来回折腾消耗大量token。下面是完整代码三个Agent加三个Task组装成一个Crew跑起来。importosfromcrewaiimportAgent,Task,Crew,Processfromcrewai.llmimportLLM# ---------- LLM配置 ----------# 用OpenAI的模型也可以换成其他的# 实际项目里把key放环境变量别硬编码os.environ[OPENAI_API_KEY]你的API_KEY# 创建一个LLM实例所有Agent共用llmLLM(modelgpt-4o,temperature0.3)# temperature低一点输出稳定# ---------- 定义三个Agent ----------# 产品经理Agent负责把模糊需求拆成结构化文档pm_agentAgent(role产品经理,goal把用户的需求拆解成清晰可执行的需求文档包含功能点、验收标准和技术约束,backstory(你是一个有10年经验的产品经理擅长把模糊的需求拆成开发能直接用的文档。你会主动标注假设和风险。),llmllm,verboseTrue,# 打印详细执行过程调试用allow_delegationFalse,# 不允许把活派给别人各干各的)# 开发Agent负责根据需求文档写代码dev_agentAgent(role开发工程师,goal根据需求文档写出完整可运行的Python代码包含函数实现、注释和使用说明,backstory(你是一个资深Python开发代码风格简洁清晰。你写的代码必须能直接运行不省略关键逻辑。),llmllm,verboseTrue,allow_delegationFalse,)# 测试Agent负责根据需求和代码写测试并执行test_agentAgent(role测试工程师,goal根据需求文档和代码编写测试用例覆盖正常路径和边界情况给出测试报告,backstory(你是一个严谨的测试工程师擅长找边界情况和异常输入。你会客观评估代码质量不放过任何潜在问题。),llmllm,verboseTrue,allow_delegationFalse,)# ---------- 定义三个Task ----------# 产品经理的任务输入是原始需求输出是需求文档pm_taskTask(description(分析以下需求输出一份结构化的需求文档。\n\n需求描述: {requirement}\n\n文档要包含以下几个部分:\n1. 功能概述一段话说清楚要做什么\n2. 功能点列表每个点具体做什么\n3. 验收标准怎么算做完了\n4. 技术约束用什么语言、有什么限制\n5. 假设和风险你做了哪些假设有什么风险\n),expected_output一份Markdown格式的需求文档,agentpm_agent,)# 开发的任务输入是产品经理的输出输出是代码dev_taskTask(description(根据上面的需求文档编写完整的Python代码。\n\n要求:\n1. 函数要有完整实现不能只给签名\n2. 关键逻辑加注释\n3. 附上使用示例\n4. 处理常见异常输入\n),expected_output完整的Python代码包含注释和使用示例,agentdev_agent,context[pm_task],# 依赖产品经理的输出作为上下文)# 测试的任务输入是需求文档和代码输出是测试报告test_taskTask(description(根据需求文档和开发给出的代码编写测试用例。\n\n要求:\n1. 覆盖所有功能点\n2. 包含正常输入、边界输入、异常输入的测试\n3. 给出每个测试用例的预期结果\n4. 评估代码是否满足验收标准\n5. 输出测试报告列出通过和未通过的项\n),expected_output测试用例列表和测试报告,agenttest_agent,context[pm_task,dev_task],# 同时依赖需求和代码)# ---------- 组装Crew并运行 ----------# 创建Crew三个Agent三个Task串行执行project_crewCrew(agents[pm_agent,dev_agent,test_agent],tasks[pm_task,dev_task,test_task],processProcess.sequential,# 串行模式按task列表顺序执行verboseTrue,)# 输入需求启动整个流程requirement(做一个密码强度检查工具输入一个密码字符串返回强度等级弱、中、强和具体建议。要求长度至少8位才算合格包含大小写字母、数字、特殊字符的越多越强。)# kickoff启动result是最后一个Task的输出resultproject_crew.kickoff(inputs{requirement:requirement})# 打印最终结果print(\n*60)print(最终测试报告:)print(*60)print(result)# 如果想看中间每一步的输出可以这样取# pm_task.output 就是产品经理Agent的输出# dev_task.output 就是开发Agent的输出print(\n*60)print(需求文档:)print(*60)print(pm_task.output.rawifhasattr(pm_task.output,raw)elsepm_task.output)print(\n*60)print(开发代码:)print(*60)print(dev_task.output.rawifhasattr(dev_task.output,raw)elsedev_task.output)效果验证运行这段代码你会看到三段输出依次出现。第一段是产品经理Agent输出的需求文档包含功能概述、功能点、验收标准这些。第二段是开发Agent输出的Python代码一个完整的密码强度检查函数。第三段是测试Agent输出的测试报告列出测试用例和通过情况。判断成功有几个标准。需求文档里功能点和验收标准都齐全没有遗漏。代码能直接复制运行不报语法错误。测试报告覆盖了正常输入和边界情况比如空字符串、超长密码、纯数字密码这些。一个常见问题是CrewAI跑着跑着卡住不动。大概率是某个Agent的LLM调用超时了。检查网络和API key确认模型能正常访问。CrewAI默认没有设超时你可以在LLM配置里加timeout参数。还有一个问题是Agent输出格式不稳定有时候给你Markdown有时候给你纯文本。在Task的expected_output里把格式要求写明确比如一份Markdown格式的需求文档比写需求文档效果好。踩坑记录第一个坑Agent之间上下文丢失。一开始我没给dev_task加context参数开发Agent拿不到产品经理输出的需求文档自己瞎编了一个需求开始写代码。写出来的东西跟原始需求完全对不上。CrewAI的串行模式默认只把上一个Task的输出传给下一个如果你需要更早的Task输出得在context里显式指定。我后来给test_task同时加了pm_task和dev_task测试Agent才能同时看到需求和代码。第二个坑角色定义太宽泛导致输出质量差。最早我的开发Agent backstory就写了一句你是一个Python开发结果它写的代码经常省略实现给个pass就完事。后来把backstory和goal写具体了“代码必须能直接运行不省略关键逻辑”输出质量才上来。角色定义越具体越好别指望模型自己理解你想要什么。第三个坑串行流程太慢。三个Agent一个等一个每个调一次大模型几秒到十几秒跑完一遍要一分钟。如果需求复杂产品经理拆出来的功能点多开发Agent写一大坨代码测试Agent再写一堆测试整体可能要两三分钟。后来对于简单需求我把三个Agent的prompt精简了限制输出长度速度提升不少。对于复杂需求可以考虑把功能点拆开每个功能点独立跑一遍流程再合并。延伸与判断这个项目团队的模式可以套到很多场景。把角色换一换就行比如内容创作团队策划Agent出选题写作Agent写正文编辑Agent做润色。再比如数据分析团队取数Agent写SQL取数据分析Agent做统计报告Agent出可视化报告。CrewAI也有它的局限。复杂的条件分支和循环不好搞比如测试不过自动回到开发重写CrewAI的串行模式做不到得用Process.hierarchical加一个管理Agent来控制流程配置起来比较麻烦。对流程控制要求高的场景还是LangGraph更合适。还有一个现实问题token成本。三个Agent每个都要调大模型跑一遍需求消耗的token不少。如果频率高成本不低。建议在prompt里限制输出长度去掉verbose输出简单需求用便宜一点的模型。我的建议先用CrewAI把标准串行流程跑通理解角色定义和任务编排的思路。流程固定了以后如果对控制灵活度有要求再迁移到LangGraph自己搭状态图。两个框架的Agent定义和prompt可以复用迁移成本主要在流程编排那块。结尾三个Agent组成一个项目团队从需求到代码到测试自动跑一遍这件事CrewAI做起来不复杂。关键是把角色定义写具体把任务依赖理清楚剩下的框架替你搞定。下一篇把这个团队封装成API服务让它能被外部系统调用。