CrewAI实战用CrewAI快速搭建多角色协作团队上一篇聊完多智能体的概念和协作模式这篇上手CrewAI。选CrewAI的原因很简单它把Agent、Task、Crew这几个概念抽象得特别直白像搭积木一样把多角色团队拼起来不用自己写一堆路由和状态管理代码。今天要做的就是用CrewAI搭一个内容创作团队一个调研员负责查资料一个写手负责写文章一个审核员负责把关质量。跑完以后你会看到三个角色怎么分工协作最后输出一篇结构完整的文章。CrewAI是什么CrewAI是一个开源的多Agent编排框架核心思路是把多Agent协作拆成三个层次。Agent定义角色和能力Task定义具体任务Crew把Agent和Task组装到一起并管理执行流程。跟LangGraph比CrewAI更偏声明式。你告诉框架谁干什么、流程怎么走框架帮你跑。LangGraph是你自己画状态图自己写节点和边灵活但要写的样板代码多。做内容创作这类流程比较固定的场景CrewAI省事得多。环境准备装CrewAI之前先确认Python版本3.10以上才行。我一开始在3.9的虚拟环境里装直接报错花了我十分钟才反应过来。pip install crewai crewai-tools还需要配置大模型的API Key。CrewAI默认用OpenAI的模型设好环境变量就行。importos os.environ[OPENAI_API_KEY]sk-xxx想用别的模型也可以CrewAI支持通过LiteLLM接入各种模型比如Claude、通义千问、DeepSeek这些。配置方式后面代码里会提到。第一步定义Agent角色CrewAI里每个Agent有三个核心属性role、goal、backstory。role是角色名称goal是这个角色要达成的目标backstory是背景故事帮模型更好理解角色定位。很多人觉得backstory这东西花里胡哨的其实它对输出质量影响挺大。模型有了背景设定生成的语气和角度会贴合角色。比如审核员你告诉它你是有十年经验的内容编辑对事实错误和逻辑漏洞零容忍它挑刺就挑得更狠。fromcrewaiimportAgent# 调研员Agent负责收集和整理资料researcherAgent(role内容调研员,goal收集指定主题的背景资料、关键数据和最新进展整理成结构化的调研报告,backstory你是一名资深内容调研员擅长快速从海量信息中提炼关键点。你的调研报告总是数据详实、来源可靠为写作团队提供扎实的事实基础。,verboseTrue,allow_delegationFalse,# 这里用默认的OpenAI模型也可以通过llm参数指定别的# llmLLM(modeldeepseek/deepseek-chat, api_keyxxx))第二步定义Task任务Task是分配给Agent的具体活。每个Task有description任务描述和expected_output期望输出格式还要指定由哪个Agent执行。expected_output这个字段别偷懒不写。写清楚输出格式Agent的输出会规范很多。不写的话模型自由发挥格式五花八门后面的Agent拿到乱七八糟的输入质量跟着拉胯。fromcrewaiimportTask# 调研任务交给调研员research_taskTask(description 围绕主题{topic}进行调研需要覆盖以下方面 1. 主题的基本概念和背景 2. 当前的主要技术方案或观点 3. 实际应用案例 4. 存在的争议或挑战 请确保信息准确标注信息来源。 ,expected_output一份结构化的调研报告包含四个部分每部分300字左右附带信息来源,agentresearcher)第三步组建Crew并运行Crew把Agent和Task装到一起通过process参数指定执行流程。sequential是串行模式任务按顺序一个个来前一个的输出自动传给后一个。hierarchical是层次模式有个manager agent负责分配任务。内容创作团队用串行就行调研完写写完审流程清晰。fromcrewaiimportCrew,Process# 组建团队content_crewCrew(agents[researcher,writer,reviewer],tasks[research_task,write_task,review_task],processProcess.sequential,verboseTrue)# 启动执行resultcontent_crew.kickoff(inputs{topic:AI Agent在企业中的应用})print(result)完整代码下面是完整的可运行代码包含三个Agent、三个Task和Crew的组建。注释写得比较详细方便你照着改。importosfromcrewaiimportAgent,Task,Crew,Process,LLM# 环境配置 # 设置OpenAI的API Keyos.environ[OPENAI_API_KEY]sk-xxx# 如果想用DeepSeek等国产模型取消下面的注释# llm LLM(# modeldeepseek/deepseek-chat, # 指定模型名称# api_key你的deepseek api key, # 对应的API Key# temperature0.7 # 温度参数控制输出随机性# )# 默认用OpenAIllm设为None即可llmNone# 第一步定义三个Agent # 调研员负责收集资料researcherAgent(role内容调研员,goal收集指定主题的背景资料、关键数据和最新进展整理成结构化的调研报告,backstory你是资深内容调研员擅长快速从海量信息中提炼关键点。你的调研报告数据详实、来源可靠为写作团队提供扎实的事实基础。,verboseTrue,# 打印执行过程方便调试allow_delegationFalse,# 不允许转交任务给其他Agentllmllm)# 写手负责根据调研报告写文章writerAgent(role技术写手,goal根据调研报告撰写一篇结构清晰、通俗易懂的技术文章,backstory你是技术专栏作者擅长把复杂的技术概念用通俗的语言解释清楚。你的文章逻辑清晰代码示例丰富读者反馈很好。,verboseTrue,allow_delegationFalse,llmllm)# 审核员负责审核文章质量reviewerAgent(role内容审核员,goal审核文章的事实准确性、逻辑连贯性和可读性给出修改建议并输出终稿,backstory你是有十年经验的内容编辑对事实错误和逻辑漏洞零容忍。你审核文章时既严格又 constructive会在指出问题的同时给出具体修改建议。,verboseTrue,allow_delegationFalse,llmllm)# 第二步定义三个Task # 调研任务research_taskTask(description 围绕主题{topic}进行调研需要覆盖以下方面 1. 主题的基本概念和背景 2. 当前的主要技术方案或观点 3. 实际应用案例 4. 存在的争议或挑战 请确保信息准确标注信息来源。 ,expected_output一份结构化的调研报告包含四个部分每部分300字左右附带信息来源,agentresearcher)# 写作任务输入是上一个任务的输出write_taskTask(description 根据调研报告围绕主题{topic}撰写一篇技术文章。 要求 1. 开头用具体场景引入不要太学术 2. 正文分3-4个小节每节有代码或案例支撑 3. 结尾给出实践建议 4. 全文1500-2000字 ,expected_output一篇1500-2000字的技术文章结构清晰包含代码示例,agentwriter,context[research_task]# 明确依赖调研任务的输出)# 审核任务输入是写作任务的输出review_taskTask(description 审核以下技术文章检查 1. 事实是否准确 2. 逻辑是否连贯 3. 语言是否通顺 4. 代码示例是否合理 如果有问题直接修改并输出终稿没有问题也输出最终版本。 ,expected_output审核后的文章终稿附带简短的审核说明指出做了哪些修改,agentreviewer,context[write_task]# 依赖写作任务的输出)# 第三步组建Crew并执行 content_crewCrew(agents[researcher,writer,reviewer],tasks[research_task,write_task,review_task],processProcess.sequential,# 串行执行前一个任务的输出传给后一个verboseTrue)# 启动传入主题参数resultcontent_crew.kickoff(inputs{topic:AI Agent在企业中的应用})# 打印最终结果print(*50)print(最终输出)print(*50)print(result)# 也可以拿到完整执行过程的token用量统计# print(content_crew.usage_metrics)效果验证跑起来以后你会看到终端不断打印每个Agent的执行过程。先是调研员输出调研报告然后写手根据报告写文章最后审核员审核并输出终稿。判断成功的标准很简单看最终输出的文章是否结构完整、内容跟主题相关、没有明显的事实错误。CrewAI的verbose模式会把每步的中间结果都打出来方便你定位问题出在哪个环节。常见报错有这么几个。API Key没配好会报AuthenticationError检查环境变量。模型超时会报TimeoutError任务描述太长或者模型负载高的时候容易碰到重试或者换模型。Agent之间的输出格式不匹配导致下一个Agent无法理解这时候去检查expected_output的描述是否够明确。踩坑记录踩的第一个坑是context参数。一开始我没给write_task加context参数以为串行模式下前一个任务的输出会自动传给后一个。结果写手拿不到调研报告只能自己重新搜了一遍。后来查文档发现串行模式下虽然任务按顺序执行但要显式指定context才能把上游任务的输出传进来。加上context[research_task]以后才正常。第二个坑是allow_delegation。审核员我一开始设了allow_delegationTrue想让它发现问题可以找写手改。结果审核员把任务转回给写手写手改完又转回给审核员两个Agent来回踢皮球跑了十几轮才停。后来直接关掉delegation让审核员自己改问题就解决了。多Agent协作不一定非得互相转交有时候让一个Agent从头改到尾反而更高效。延伸与判断CrewAI适合流程比较固定的多角色场景内容创作、报告生成、代码审查这类任务用它很顺手。但如果你需要复杂的条件分支、动态路由、循环重试这些CrewAI的表达力不够LangGraph更合适。选框架的思路跟上一篇说的一样看任务复杂度。流程固定、角色清晰选CrewAI流程灵活、需要自己控制选LangGraph。别一上来就选最灵活的灵活的框架你要写的代码也最多。CrewAI的hierarchical模式适合任务需要动态分配的场景manager agent会自己判断哪个任务给谁。但manager的判断质量依赖模型能力弱模型容易分配错。用的时候选强一点的模型当manager。结尾这篇用CrewAI搭了一个内容创作团队三个角色串行协作跑完整流程。核心就三步定义Agent、定义Task、组装Crew。下一篇上手AutoGen看看微软的多Agent对话框架是怎么玩的跟CrewAI的路子完全不一样。