Agent角色设计怎么给Agent分配角色和职责前两篇分别用了CrewAI和AutoGen搭多Agent团队。你大概发现了不管用哪个框架最花心思的环节都是定义Agent的角色。框架只是帮你跑流程角色定义得好不好直接决定输出质量。这篇聊聊Agent角色设计这件事。角色怎么切、粒度怎么把控、角色之间怎么配合、有哪些常见模式和踩坑经验。最后给一套角色定义模板和角色间通信的示例代码你拿去改改就能用。角色设计的核心原则单一职责。一个Agent只干一件事。听起来简单做起来容易跑偏。我见过有人把查数据、分析数据、写报告塞一个Agent里prompt写了三页结果什么都做不好。每个职责拆成独立Agentprompt短了专注度高了输出质量自然上去了。怎么判断一个Agent是不是只干一件事看它的goal能不能用一句话说清楚。说不清楚就拆。边界清晰。每个Agent的职责范围要划清楚哪些归我管、哪些不归我管。模糊的边界会导致两个问题要么两个Agent抢着干同一件事要么都以为对方会干结果没人干。写system_message的时候明确告诉Agent它不该做什么跟告诉它该做什么一样重要。你只负责写代码不要负责执行代码这种约束写进去比不写强太多。能力匹配。角色的职责要跟模型的能力匹配。让一个弱模型当协调者做复杂的路由判断大概率会乱。强模型放关键决策位置弱模型干执行类的活成本和质量能平衡。角色粒度怎么把控粒度是角色设计里最纠结的问题。拆太粗一个Agent管太多事回到单Agent的老路。拆太细Agent数量爆炸协调成本飞涨。我的经验是先粗后细。一开始按大的职能拆三到五个Agent跑起来看效果。哪个Agent输出质量不行再往下拆。哪个Agent存在感太低、跟别的Agent职能重叠就合并掉。判断粒度合不合适有个简单标准。看Agent之间的通信频率如果两个Agent之间消息特别多可能该合并。如果一个Agent的输出从来不被别的Agent用可能该去掉。通信是有成本的Agent之间的消息传递越多token消耗越大出错概率也越高。举个例子内容创作团队一开始拆了调研、写作、润色、审校四个Agent。跑了几轮发现润色和审校总是在讨论同一批问题消息来回飞。后来合并成一个审核员既改语言又查事实效率高了一截。角色间的依赖关系角色设计不能只看单个Agent还要看它们之间怎么配合。常见的依赖关系有几种。线性依赖A的输出是B的输入B的输出是C的输入。流水线模式调试简单一个环节出问题不影响别的。上一篇CrewAI的内容创作团队就是这种。共享上下文依赖多个Agent读同一份数据各自从不同角度处理。比如调研Agent和竞品分析Agent都读同一份市场数据一个看机会一个看风险。这种依赖要注意上下文token的消耗同一份数据塞进多个Agent的上下文里成本翻倍。反馈依赖A的输出给BB的反馈又回给A形成循环。审核场景常见这种写手写完审核员审审核意见回给写手改。这种依赖要设好最大循环次数不然两个Agent能聊到天荒地老。常见角色设计模式做了几个项目以后我发现角色设计有几种反复出现的模式。专家型。一个Agent精通某个领域专门处理这类问题。技术专家、法务专家、财务专家各自只管自己擅长的事。专家型Agent的prompt要突出领域知识给够背景信息让它像真正的专家一样思考。助手型。帮人类或别的Agent干杂活。执行代码、搜索资料、格式化输出这些不需要太多决策的活交给助手型Agent。助手型的特点是工具多、决策少你给它配一堆工具让它调用就行。上一篇AutoGen里的代码执行器就是典型的助手型。监督型。负责检查别的Agent的输出质量有问题打回去重做或者自己改。监督型Agent的prompt要强调批判性思维告诉它宁可误报也不能漏报。审核员、测试员、质检员都属于这类。协调型。负责分配任务、管理流程、决定下一个该谁干活。上一篇CrewAI的hierarchical模式里的manager agent就是协调型。协调型Agent要配强模型因为路由判断的质量决定整个团队的效果。角色定义模板下面给一套角色定义模板和角色间通信的示例代码。模板涵盖了角色设计该考虑的几个维度你拿去改改就能用。importosfromcrewaiimportAgent,Task,Crew,Process,LLM# 环境配置 os.environ[OPENAI_API_KEY]sk-xxx# 强模型用于协调型角色做路由判断strong_llmLLM(modelgpt-4o,temperature0.3)# 普通模型用于执行型角色省钱normal_llmLLM(modelgpt-4o-mini,temperature0.7)# 角色定义模板 defcreate_expert_agent(role,goal,backstory,llmNone):创建专家型Agent的通用模板 参数 - role: 角色名称简洁明确 - goal: 角色目标一句话说清楚 - backstory: 背景故事帮模型理解角色定位 - llm: 使用的模型实例 设计要点 - 专家型Agent的backstory要突出领域经验 - allow_delegation设False专家专注自己的事 - max_iter控制单任务最大迭代次数 returnAgent(rolerole,goalgoal,backstorybackstory,llmllmornormal_llm,verboseTrue,allow_delegationFalse,# 专家不转交任务专注自己的领域max_iter5,# 最多迭代5次防止无限循环)defcreate_supervisor_agent(role,goal,backstory,llmNone):创建监督型Agent的通用模板 设计要点 - 监督型要强调批判性思维 - allow_delegation可以设True发现问题能转交 - max_iter控制循环次数防止来回踢皮球 returnAgent(rolerole,goalgoal,# 在backstory里追加质量要求强化批判性思维backstorybackstory 你对质量问题零容忍发现问题必须指出并给出修改建议。,llmllmornormal_llm,verboseTrue,allow_delegationTrue,# 监督型可以转交任务让原作者修改max_iter3,# 控制循环次数防止来回踢皮球)defcreate_coordinator_agent(llmNone):创建协调型Agent 设计要点 - 协调型用强模型路由判断质量决定整体效果 - backstory要强调全局视角和决策能力 returnAgent(role任务协调员,goal分析任务需求将任务分配给最合适的Agent确保团队高效协作,backstory你是经验丰富的项目经理擅长拆解复杂任务、合理分配资源。你能快速判断每个子任务应该交给谁让团队运转高效有序。,llmllmorstrong_llm,# 协调型用强模型verboseTrue,allow_delegationTrue,max_iter10,)# 角色间通信示例 # 场景 一个技术问答团队# 用户提问 - 协调员分派 - 技术专家回答 - 审核员把关 - 返回用户# 创建四个角色coordinatorcreate_coordinator_agent()frontend_expertcreate_expert_agent(role前端技术专家,goal回答前端开发相关问题包括React、Vue、CSS等,backstory你有8年前端开发经验精通React生态和CSS布局。,)backend_expertcreate_expert_agent(role后端技术专家,goal回答后端开发相关问题包括API设计、数据库、系统架构等,backstory你有10年后端开发经验精通Python、Go和数据库设计。,)reviewercreate_supervisor_agent(role技术审核员,goal审核技术回答的准确性确保没有误导性内容,backstory你是技术团队的技术负责人负责把关所有对外输出的技术内容。,)# 定义任务# 第一个任务交给协调员由它决定分配给哪个专家answer_taskTask(description回答用户的技术问题: {question},expected_output准确、清晰的技术回答包含必要的代码示例,agentcoordinator,# 协调员接收后分配给具体专家)# 第二个任务交给审核员依赖第一个任务的输出review_taskTask(description审核技术回答的准确性修改错误后输出终稿,expected_output审核后的技术回答终稿附带修改说明,agentreviewer,context[answer_task],# 依赖回答任务的输出)# 组建团队用hierarchical模式让协调员自动分配qa_crewCrew(agents[coordinator,frontend_expert,backend_expert,reviewer],tasks[answer_task,review_task],processProcess.hierarchical,# 层次模式协调员负责分配manager_llmstrong_llm,# 指定管理者的模型verboseTrue,)# 执行resultqa_crew.kickoff(inputs{question:React里useEffect和useLayoutEffect有什么区别})print(result)角色设计踩坑经验第一个坑是角色太多。有次我搭一个报告生成系统拆了七个Agent调研、分析、写作、润色、审校、排版、发布每个环节一个。跑起来发现协调成本巨大七个Agent的消息传递和上下文管理吃掉大量token而且每个环节都有信息损耗传到后面精度已经不行了。后来合并成四个调研加分析合成一个润色加审校合成一个效果好很多。角色数量我现在的经验值是三到五个超过五个就要想想能不能合并。第二个坑是角色定位重叠。我做过一个客服系统有退款专员和售后专员两个Agent。结果用户问退款流程两个Agent都抢着回答内容还不一样用户体验很差。问题出在角色边界没划清退款和售后在用户眼里是一回事。后来把退款专员并到售后里让一个Agent处理所有售后问题反而更顺。划角色边界的时候站在用户角度想用户眼里这件事是几件事。用户觉得是一件事的尽量一个Agent搞定。延伸与判断角色设计没有标准答案跟团队分工一样看任务、看人、看资源。但有几个判断可以分享。角色数量宁少勿多。三个角色能搞定的事别用五个协调成本不值得。先跑起来再优化别一开始就追求完美架构。角色边界从用户视角划分不从技术视角划分。用户觉得是一件事的就别拆用户觉得是两件事的就别合。监督型角色一定要有。不管是内容审核还是质量检查有个把关的角色能大幅降低翻车概率。监督型的prompt要强调挑毛病别让它太好说话。我在监督型Agent的system_message里都会加一句宁可误报也不能漏报效果立竿见影。协调型角色用强模型。路由判断出错后面全跟着错。省这个钱不值得。结尾这篇把角色设计的原则、粒度、依赖关系和常见模式理了一遍。角色设计是多Agent系统里最需要人肉经验的环节框架帮不了你太多。拿着模板去试跑几轮看效果该拆的拆该合的合慢慢就找到感觉了。这个系列到这里也告一段落了希望对你搭自己的Agent团队有帮助。