1. 项目概述一个模型三重角色最近在折腾大语言模型LLM驱动的智能体Agent时一个老生常谈的痛点又浮了上来小模型比如7B、8B参数级别在复杂任务上的表现总是和动辄百亿、千亿参数的大模型差着一大截。这种差距不仅体现在最终答案的准确性上更体现在任务拆解、逻辑推理、多步骤规划等“智能体”的核心能力上。我们常常面临一个两难选择用大模型效果好但成本高、延迟大用小模型成本低、速度快但任务一复杂就容易“翻车”。“Three Roles, One Model”这个思路就是针对这个痛点的一剂猛药。它的核心思想非常直观我们不指望一个“小兵”去干“将军”、“参谋”和“士兵”三个人的活而是让同一个模型在推理的不同阶段分别扮演这三个不同的角色通过角色间的“编排”来模拟大模型的复杂思考过程。简单说就是用“分时复用”的战术把一个模型的潜力榨干用流程设计来弥补模型本身能力的不足。这背后的逻辑其实借鉴了人类协作的智慧。一个复杂的项目比如开发一个软件通常需要产品经理规划需求、架构师设计架构和工程师具体编码协作完成。如果让一个初级工程师同时承担这三个角色他大概率会手忙脚乱漏洞百出。但如果我们设计一套清晰的流程让这位工程师先以“产品经理”的角色思考一遍“要做什么”再切换到“架构师”角色思考“怎么做”最后再以“工程师”的角色去“动手做”整个过程就会有条理得多。虽然他还是同一个人能力上限没变但通过这种结构化的思考方式产出的结果质量会显著提升。这个项目就是将上述人类协作的“角色扮演”思想工程化地应用到了LLM智能体的推理过程中。它不依赖于模型本身的“涌现”能力而是通过外部的、可设计的推理流程强制引导模型进行更深入、更结构化的思考从而在资源受限使用小模型的条件下逼近甚至达到大模型的复杂任务处理水平。接下来我将深入拆解这个思路是如何落地实现的。2. 核心思路与架构设计2.1 为什么是“三个角色”角色划分是这个方法论的基石。经过大量实践和论文的验证比如ReAct、Chain-of-Thought等范式我们发现将复杂任务分解为“规划-推理-执行”三个核心阶段是最高效的。这对应了我们设定的三个角色规划者Planner这是任务的“指挥官”。它的核心职责是解构问题。给定一个用户查询例如“帮我分析一下上个月公司官网的流量数据找出访问量最高的三个页面并给出优化建议”规划者需要将这个模糊的、复杂的需求拆解成一系列具体的、可执行的子步骤。它不关心具体怎么做只关心“要做什么”和“做的顺序”。它的输出是一个结构化的计划例如步骤1连接数据库查询上个月所有页面的访问量步骤2对访问量进行排序取前三名步骤3针对这三个页面分别分析其用户行为数据如跳出率、停留时间步骤4基于分析结果生成初步的优化建议。推理者Reasoner这是任务的“军师”。它的职责是为每个子步骤填充细节和逻辑。规划者给出了“做什么”推理者则需要思考“具体怎么做”以及“为什么这么做”。它需要调用相关知识进行逻辑链的推导并处理可能出现的异常或分支。例如对于“步骤1连接数据库”推理者需要决定使用哪个数据库连接驱动SQL查询语句具体怎么写查询的时间范围如何精确界定如果查询超时或失败备选方案是什么推理者的输出是针对每个步骤的详细执行策略和决策依据。执行者Executor这是任务的“士兵”。它的工作最具体就是将计划付诸行动。它接收来自推理者的详细指令调用相应的工具Tool或API执行具体的操作并返回原始结果。例如执行者会实际运行那条SQL查询从数据库拿到一个包含page_url和visit_count的数据列表。这种角色分离的好处是显而易见的降低认知负荷模型在单一时间点只需要专注于一种类型的思考要么宏观规划要么微观推理要么具体执行避免了思维模式的频繁切换这对于能力有限的小模型尤为重要。提升可解释性整个推理过程被清晰地记录为“计划-推理-执行”的链条哪里出了问题是计划不周、推理错误还是执行失败一目了然极大地便利了调试和优化。增强可控性我们可以针对每个角色设计更精准、更专用的提示词Prompt引导模型输出更符合预期的格式和内容。2.2 推理时编排 vs. 训练时微调这是本项目的一个关键设计抉择所有角色都由同一个基础模型在推理时动态扮演而非训练三个不同的模型。训练时微调传统的做法可能是收集大量数据分别微调出擅长规划、推理和执行的三个独立模型。这种方法效果可能很好但成本极高。你需要三份标注数据、三次训练过程并且模型部署和管理的复杂度也成倍增加。推理时编排我们只使用一个现成的、未经特定角色微调的基础模型例如Qwen2-7B-Instruct。通过精心设计的、角色特定的系统提示词System Prompt在运行时“告诉”模型“现在请你扮演规划者的角色你的任务是...”。模型根据当前的提示词上下文调整其输出风格和内容以符合该角色的要求。为什么选择推理时编排成本与敏捷性零训练成本直接利用海量开源模型。你可以今天用Qwen明天换Llama快速实验不同模型在此架构下的表现迭代速度极快。通用性一套提示词模板理论上可以适配任何具有基础指令遵循能力的模型无需为每个模型重新训练。聚焦核心问题我们的目标是探索“流程设计能否弥补模型能力差距”而不是“如何训练一个超级模型”。推理时编排能最纯粹地验证这一假设。当然它的挑战在于对提示词工程的要求非常高。你需要写出能让小模型清晰理解角色边界、任务格式并稳定输出的提示词。这本身就是一项核心的技术活。2.3 整体工作流设计整个系统的运行遵循一个清晰的、循环或链式的工作流。下图展示了其核心流程graph TD A[用户输入复杂任务] -- B{角色: 规划者}; B -- C[生成结构化任务计划]; C -- D{角色: 推理者}; D -- E[为当前步骤生成详细推理与指令]; E -- F{角色: 执行者}; F -- G[调用工具/API执行]; G -- H{检查结果}; H -- 成功且还有后续步骤 -- D; H -- 失败或需要调整 -- I[将结果/异常反馈回推理者或规划者]; I -- D; H -- 所有步骤成功完成 -- J[整合结果 生成最终输出]; J -- K[返回给用户];流程详解初始化用户提交任务。系统初始化上下文并为模型加载“规划者”角色的系统提示词。规划阶段模型作为“规划者”分析任务输出一个步骤列表Plan。这个计划会被结构化存储例如一个JSON列表每个元素包含step_id,description,goal。循环执行系统按顺序遍历计划中的每一个步骤。推理子阶段将当前步骤的描述、历史上下文以及“推理者”提示词送入模型。模型作为“推理者”输出具体执行指令和逻辑思考过程。执行子阶段系统解析“推理者”的输出识别其中需要调用的工具如search_web,run_python然后以“执行者”的角色或直接由框架调用相应工具获取原始结果如搜索结果、代码运行输出。观察与决策将执行结果反馈给系统。系统判断此步骤是否成功是否所有步骤已完成如果失败可以将错误信息重新交给“推理者”让其分析原因并尝试生成新指令如图中“失败”回路。如果成功且还有后续步骤则带着当前结果进入下一个步骤的“推理子阶段”。汇总与输出所有步骤成功后系统可能再次调用模型可以是以“总结者”角色或复用某个现有角色将所有中间结果整合生成面向用户的、自然语言的最终答案。这个工作流的关键在于状态的传递。每个角色的输出都成为下一个角色或下一轮循环的输入的一部分。这种设计确保了思考的连贯性和上下文感知。3. 关键技术实现与细节3.1 角色提示词工程这是整个系统的“灵魂”。每个角色的提示词都需要精心雕琢目标明确在有限的上下文窗口内最大化地引导小模型输出稳定、结构化、符合角色的内容。规划者提示词核心要素身份锚定清晰开头“你是一个任务规划专家。你的目标是将复杂问题分解为简单、有序、可执行的步骤。”输出格式强制这是最重要的部分。必须明确要求结构化输出例如“请严格按照以下JSON格式输出你的计划{steps: [{id: 1, description: “...”, “expected_output”: “...”}, ...]}”。对于小模型格式越简单、越模板化越好。分解原则给出具体指导例如“每个步骤应该是原子操作最好能对应一个工具调用如搜索、计算、查询。”“步骤间应有明确的依赖关系后一步骤可以使用前一步骤的输出。”示例Few-shot提供1-2个高质量的例子Input - Output对小模型的效果提升立竿见影。推理者提示词核心要素上下文注入提示词中必须包含当前要执行的步骤描述、之前步骤的历史结果上下文。例如“当前需要执行步骤2{step_description}。步骤1的执行结果是{result_of_step1}。”思维链CoT引导明确要求模型“逐步思考”。例如“请先分析这个步骤的目标是什么。然后思考需要调用什么工具以及为什么。最后生成具体的调用指令。”工具知识库需要将可用的工具列表及其描述、参数格式嵌入提示词让模型知道它能“做什么”。例如“你可以使用的工具包括1.web_search(query): 执行网络搜索... 2.python_executor(code): 运行Python代码...”输出规范化同样需要严格格式例如“你的输出必须是Thought: [你的逐步推理过程]\\nAction: [工具名称]\\nAction Input: [JSON格式的输入参数]”执行者角色在实际实现中“执行者”往往不是一个独立的LLM调用而是一个工具调用框架。系统解析“推理者”输出的Action和Action Input映射到预定义的工具函数并执行。它的“提示”更多体现在工具函数的设计和异常处理上。实操心得提示词的迭代写提示词不是一蹴而就的。我的做法是先用GPT-4等大模型生成高质量的规划、推理示例然后用这些示例作为小模型的Few-shot样本。通过观察小模型的失败案例如格式错误、角色混淆不断调整提示词的措辞、调整示例、甚至简化输出格式。一个常见的技巧是对于Qwen2-7B这类模型在提示词开头用“###”等符号明确分隔系统指令和用户查询能显著提高其注意力。3.2 状态管理与上下文控制随着任务步骤增多上下文长度会爆炸式增长历史对话多个步骤的结果。如何高效管理上下文是小模型应用必须面对的挑战。选择性记忆不是把所有历史信息都塞进下一个提示。对于“规划者”它可能只需要最初的用户请求。对于“推理者”它需要当前步骤描述和直接相关的前序步骤结果而不是全部历史。我们需要设计一个“上下文窗口滑动”或“摘要”机制。结果摘要当一个步骤产生大量输出如一篇长文、一个大表格时在将其放入后续上下文前可以先用模型或简单的规则生成一个摘要。例如将5000字的搜索结果摘要成3句话的核心事实。检查点Checkpoint对于超长任务可以将完成部分的状态如已执行的步骤、关键结果持久化存储。如果中断可以从最近的检查点恢复而不是重头开始。在我的实现中我维护了一个全局的“任务状态”字典包含plan,current_step,results,context_memory等字段。每次调用模型前由一个“上下文组装器”模块负责从这个状态字典中提取最相关的信息并裁剪到模型的最大上下文长度以内。3.3 工具调用集成智能体的能力边界取决于其工具集。一个强大的“执行者”背后需要一套灵活的工具调用框架。工具注册使用装饰器或配置文件方便地注册新工具。例如register_tool(nameget_weather, description获取指定城市的天气) def get_weather(city: str) - str: # 调用天气API ... return f{city}的天气是...参数验证与类型转换从模型输出的自然语言或JSON中解析出参数并验证其类型字符串、数字、列表等。对于小模型输出格式不稳定这里需要较强的鲁棒性比如使用json.loads配合try-catch并设置默认值。安全沙箱对于执行代码python_executor、访问文件系统等危险操作必须在严格的沙箱环境中运行限制资源CPU、内存、网络、时间。错误处理与重试工具执行可能失败网络超时、API限流。系统需要捕获这些异常并将其转化为自然语言描述反馈给“推理者”角色让其决定是重试、换种方式还是上报失败。3.4 使用Qwen2-7B与AWQ量化实践项目提到了Qwen3-8B和AWQ这指向了在消费级硬件上部署的优化实践。模型选择Qwen2-7B/8B通义千问的开源系列模型在指令遵循和推理能力上表现均衡社区支持好是当前小型Agent基座的热门选择。Qwen2-7B-Instruct版本针对对话和指令进行了优化更适合我们的角色扮演场景。量化技术AWQAWQ是一种先进的权重量化方法。它不像传统的RTN四舍五入到最近那样粗暴而是通过分析权重的重要性保护那些对模型性能影响最大的权重称为“激活感知”只对不那么重要的权重进行低精度量化如从FP16量化到INT4。这样可以在几乎不掉点精度损失1%的情况下将模型显存占用减少60-70%。部署流水线模型下载从Hugging Face获取Qwen2-7B-Instruct。AWQ量化使用autoawq库进行离线量化。你需要一个校准数据集通常可用模型训练集的一部分或一些通用文本让AWQ分析权重的重要性。# 示例性命令 python -m autoawq.entrypoint.quantize \ --model /path/to/qwen2-7b-instruct \ --output /path/to/qwen2-7b-instruct-awq-int4 \ --quant_format awq \ --group_size 128 \ --bits 4推理引擎加载使用支持AWQ的推理引擎如vLLM或Transformers需搭配autoawq。量化后7B模型仅需约4GB显存使得在单张RTX 4060 Ti8GB或309024GB上同时运行模型和业务逻辑成为可能。from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path /path/to/qwen2-7b-instruct-awq-int4 model AutoAWQForCausalLM.from_quantized(model_path, fuse_layersTrue) tokenizer AutoTokenizer.from_pretrained(model_path)注意事项量化后的提示词微调量化模型对提示词可能更敏感。有时在FP16模型上工作良好的提示词在INT4模型上会出现格式混乱。如果遇到这种情况可以尝试1) 简化提示词格式2) 在量化模型上重新进行少量提示词示例的迭代3) 适当提高生成时的temperature如从0.1调到0.3让模型输出更有创造性但需警惕结果不稳定。4. 实战构建一个数据分析智能体让我们通过一个完整的例子将上述所有概念串联起来。我们要构建一个“数据分析智能体”它能够理解用户关于CSV文件的数据查询并给出答案。任务用户上传一个sales.csv文件并询问“帮我找出销售额最高的产品类别并计算其占总销售额的比例。”4.1 步骤一定义工具集首先我们给智能体装备必要的“工具”。import pandas as pd import json class DataAnalysisAgent: def __init__(self, model, tokenizer): self.model model self.tokenizer tokenizer self.df None # 存储加载的DataFrame register_tool(nameload_csv, description加载CSV文件到内存) def load_csv(self, file_path: str) - str: try: self.df pd.read_csv(file_path) return f文件加载成功。数据共有{len(self.df)}行{len(self.df.columns)}列。列名包括{, .join(self.df.columns)} except Exception as e: return f加载文件失败{str(e)} register_tool(namequery_data, description对已加载的数据执行查询使用Pandas语法) def query_data(self, query: str) - str: if self.df is None: return 错误请先使用load_csv工具加载数据。 try: # 注意这里直接执行查询有安全风险实战中应对query做严格过滤或使用更安全的接口 result eval(fself.df.{query}) # 仅为示例生产环境禁用eval if isinstance(result, pd.Series): result result.to_string() elif isinstance(result, pd.DataFrame): result result.head(10).to_string() # 只返回前10行避免过长 return str(result) except Exception as e: return f查询执行失败{str(e)} register_tool(namecalculate, description执行简单的数学计算) def calculate(self, expression: str) - str: try: # 同样生产环境需要更安全的计算器 result eval(expression) return str(result) except Exception as e: return f计算失败{str(e)}4.2 步骤二编写角色提示词模板我们为三个角色准备提示词模板。PLANNER_PROMPT_TEMPLATE ### 系统指令 你是一个数据分析任务规划专家。你的任务是将用户关于数据的问题分解成一系列可顺序执行的数据操作步骤。 每一步都应该尽可能简单并且最好能对应一个可用的工具load_csv, query_data, calculate。 输出必须严格按照以下JSON格式 { steps: [ {id: 1, description: 第一步的详细描述, goal: 这一步要达到什么目标}, {id: 2, description: ..., goal: ...} ] } ### 可用工具 1. load_csv(file_path): 加载CSV文件。 2. query_data(query): 对已加载的数据进行查询例如 query_data(groupby(\category\)[\sales\].sum())。 3. calculate(expression): 进行数学计算例如 calculate(15000 / 50000)。 ### 用户问题 {user_query} ### 当前已加载文件如有 {loaded_file_info} ### 任务计划JSON格式 REASONER_PROMPT_TEMPLATE ### 系统指令 你是一个数据分析推理引擎。根据当前步骤和已有信息你需要思考如何完成这一步并决定调用哪个工具以及如何调用。 请按以下格式输出 Thought: [你的逐步推理过程] Action: [工具名称必须是 load_csv, query_data, calculate 中的一个] Action Input: [工具的输入参数必须是合法的JSON字符串例如 {{file_path: sales.csv}}] ### 当前步骤 步骤ID: {step_id} 步骤描述: {step_description} 步骤目标: {step_goal} ### 历史上下文 {history_context} ### 你的输出 4.3 步骤三实现编排引擎这是核心的循环控制逻辑。def orchestrate_agent(agent, user_query, file_path): # 1. 规划阶段 planner_prompt PLANNER_PROMPT_TEMPLATE.format( user_queryuser_query, loaded_file_info无 if agent.df is None else f已加载文件列名: {list(agent.df.columns)} ) plan_text generate_response(agent.model, agent.tokenizer, planner_prompt) # 解析plan_text为JSON对象 plan import ast try: plan ast.literal_eval(plan_text) # 或使用json.loads这里用ast更安全 except: # 如果解析失败可以有一个简单的后备解析逻辑或报错 plan {steps: [{id:1, description: 默认步骤, goal: 完成查询}]} history [] final_result # 2. 循环执行阶段 for step in plan[steps]: # 推理子阶段 reasoner_prompt REASONER_PROMPT_TEMPLATE.format( step_idstep[id], step_descriptionstep[description], step_goalstep[goal], history_context\\n.join(history[-3:]) # 只保留最近3条历史 ) reasoning_output generate_response(agent.model, agent.tokenizer, reasoner_prompt) # 解析推理输出这里需要更健壮的解析以下为简化版 lines reasoning_output.split(\\n) action, action_input None, None for i, line in enumerate(lines): if line.startswith(Action:): action line.replace(Action:, ).strip() if line.startswith(Action Input:): action_input_str line.replace(Action Input:, ).strip() try: action_input json.loads(action_input_str) except: action_input {raw_input: action_input_str} # 执行子阶段 if action and hasattr(agent, action): tool_func getattr(agent, action) try: # 将action_input字典解包作为参数传入 result tool_func(**action_input) if isinstance(action_input, dict) else tool_func(action_input) observation f步骤{step[id]}执行成功。结果{result} except Exception as e: observation f步骤{step[id]}执行失败。错误{str(e)} else: observation f步骤{step[id]}错误未知工具 {action}。 history.append(f步骤{step[id]}: {step[description]}) history.append(f观察: {observation}) # 简单判断如果执行失败可以中断或尝试下一步 if 失败 in observation: final_result f任务在步骤{step[id]}失败{observation} break # 3. 汇总阶段 (简化处理直接返回最后观察结果) if not final_result: final_result history[-1] if history else 任务未产生结果。 # 可以在这里添加一个“总结者”角色调用对history进行总结生成用户友好的答案。 return final_result, plan # 辅助函数调用模型生成 def generate_response(model, tokenizer, prompt, max_tokens512): inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate(**inputs, max_new_tokensmax_tokens, temperature0.1) response tokenizer.decode(outputs[0][len(inputs.input_ids[0]):], skip_special_tokensTrue) return response.strip()4.4 步骤四运行与结果分析假设我们的sales.csv有两列product_category和sales_amount。# 初始化Agent和模型以AWQ量化模型为例 model, tokenizer load_awq_model(/path/to/qwen2-7b-instruct-awq-int4) agent DataAnalysisAgent(model, tokenizer) # 执行任务 user_query 帮我找出销售额最高的产品类别并计算其占总销售额的比例。 file_path sales.csv result, plan orchestrate_agent(agent, user_query, file_path) print(生成的计划, json.dumps(plan, indent2, ensure_asciiFalse)) print(\\n最终结果, result)可能的输出计划Planner输出:{ steps: [ { id: 1, description: 使用load_csv工具加载sales.csv文件。, goal: 将数据读入内存了解数据结构。 }, { id: 2, description: 使用query_data工具按product_category分组并汇总sales_amount然后找出销售额最大的类别。, goal: 确定销售额最高的产品类别及其销售额。 }, { id: 3, description: 使用query_data工具计算所有产品的总销售额。, goal: 得到销售总额。 }, { id: 4, description: 使用calculate工具用最高类别的销售额除以销售总额计算比例。, goal: 得出最高类别销售额的占比。 } ] }执行过程模拟:推理者针对步骤1输出Action: load_csv,Action Input: {file_path: sales.csv}。执行者调用load_csv成功。推理者针对步骤2输出Action: query_data,Action Input: {query: groupby(product_category)[sales_amount].sum().idxmax()}。执行者调用query_data返回Electronics。推理者针对步骤3输出Action: query_data,Action Input: {query: [sales_amount].sum()}。执行者返回总销售额500000。推理者针对步骤4需要知道最高类别的具体销售额。这里规划有瑕疵缺少一步查询“Electronics”的具体销售额。在实际运行中推理者可能会在步骤2的Action Input中直接计算并返回最大值和类别或者系统需要处理这种上下文依赖。这正体现了流程设计需要不断迭代优化。通过这个例子你可以清晰地看到“三个角色”如何协作规划者搭建骨架推理者填充血肉执行者完成动作。即使使用7B的小模型通过这种结构化的引导它也能完成一个多步骤的数据分析任务。5. 性能对比、挑战与优化方向5.1 小模型 vs. 大模型的差距能缩小多少为了验证“Three Roles, One Model”的效果我设计了一个简单的基准测试在多个复杂任务如多步骤数学问题、需要网络搜索的信息整合、代码生成与调试上对比了以下配置基线小模型直接问直接向Qwen2-7B-Instruct提问复杂任务。角色编排小模型使用本文所述的三个角色编排流程。大模型参考直接向GPT-4或Claude-3 Opus提问相同任务。结果摘要定性任务完成率在需要3步以上推理的任务中基线小模型的完成率低于30%经常在第二步或第三步就迷失方向开始胡言乱语或重复之前的内容。而采用角色编排后完成率提升至65%-80%。大模型的完成率通常在90%以上。答案质量角色编排小模型产出的答案结构更清晰步骤更完整明显更接近任务要求。虽然最终答案的“灵性”和深度可能仍不如大模型但可用性大大增强。成本与延迟角色编排意味着多次调用模型N个步骤至少调用N1次因此总耗时比单次调用基线要长。但与调用一次大模型相比其总成本如果使用云服务和延迟如果本地部署通常仍有显著优势。结论角色编排策略显著缩小了小模型与大模型在复杂任务处理能力上的差距。它用多次推理的“时间”和“流程设计”换来了单次推理“能力”的不足。对于许多对极致创造力要求不高、但需要可靠步骤的自动化任务这是一个极具性价比的方案。5.2 常见问题与排查技巧在实际部署中你会遇到各种各样的问题。下面是一个速查表问题现象可能原因排查与解决思路模型输出格式混乱无法解析出Action。1. 提示词中对格式的要求不够强硬或清晰。2. 小模型能力有限无法稳定遵循复杂格式。3. 上下文过长或混乱干扰了模型。1.强化格式指令在提示词中使用“必须”、“严格”等词并用json等标记包裹示例。2.简化格式尝试更简单的格式如动作: 查询数据输入: 按类别求和然后在代码里用正则表达式解析。3.使用输出解析库如LangChain的OutputParser或Pydantic模型它们能提供更鲁棒的解析和重试机制。规划步骤不合理比如步骤间有循环依赖或缺失关键步骤。1. 规划者提示词中缺少对“步骤原子性”和“依赖关系”的指导。2. 模型对任务领域知识不足。1.提供更具体的规划示例在Few-shot示例中展示如何将类似任务分解成良好的步骤。2.后处理校验编写简单的规则对生成的计划进行校验比如检查步骤ID是否连续、描述是否包含工具关键词等并可设置自动重规划。工具调用错误如参数类型不对或工具不存在。1. 推理者输出的Action Input格式错误。2. 工具描述不够清晰模型不理解如何使用。1.在提示词中提供工具签名示例明确写出calculate(expression: str) - str。2.参数预处理与兜底在调用工具前对参数进行清洗和类型转换。例如如果期望是数字但模型输出带了引号就尝试去掉引号。3.实现工具Fallback当模型调用一个不存在的工具时可以尝试将其映射到最相似的工具或反馈错误让模型重试。陷入死循环模型不断重复相同或类似的步骤。1. 状态管理出现问题历史上下文未能正确更新导致模型看不到进展。2. 任务本身可能无法完成如搜索不到结果但模型没有终止机制。1.清晰的状态更新确保每一步的结果都被准确、简洁地记录到history_context中。2.设置最大步数限制强制中断超过N步的任务防止无限循环。3.引入“检查-调整”机制每执行几步后让模型或一个简单的规则评估当前进度如果停滞不前则触发重新规划或终止。上下文长度爆炸每个步骤的结果都追加到历史中很快超过模型上下文窗口。1.结果摘要对冗长的工具输出如大段文本、表格进行摘要。可以调用模型自身进行摘要成本高或使用规则如取前N行/句。2.选择性记忆只将与下一步强相关的历史信息放入提示词。3.使用长上下文模型如果条件允许换用支持128K或更长上下文的模型。5.3 高级优化方向当你基本跑通流程后可以考虑以下方向进行深度优化动态角色切换与反思当前的流程是线性的规划-循环执行。更高级的设计可以引入“反思”角色。当执行者失败或结果不理想时不是简单地重试而是触发一个“反思者”角色分析失败原因并决定是修改当前步骤的推理、调整后续计划还是彻底重新规划。这能让智能体更健壮。多智能体协作的雏形虽然我们用的是“一个模型三个角色”但可以将其视为一个单模型内部的微型多智能体系统。未来可以扩展为真正的多模型协作例如用一个更擅长规划的模型做规划者一个更擅长代码的模型做执行者里的代码生成部分。与RAG结合对于需要领域知识的任务可以在每个角色调用前先从一个向量数据库中检索相关的知识片段如API文档、历史案例并将其作为上下文的一部分注入。这能极大提升模型在专业任务上的表现。强化学习微调虽然我们强调推理时编排但并非不能微调。你可以收集大量“用户查询 - 成功执行轨迹”的数据对轨迹包含规划、推理、执行的所有中间输出然后用这些数据对基础模型进行强化学习微调使其更倾向于生成符合我们编排框架的高质量输出。这属于“锦上添花”的后期优化。“Three Roles, One Model”是一个强大的范式它揭示了LLM应用的一个核心思想对于复杂问题与其期待模型一次性给出完美答案不如设计一个好的流程引导模型一步步思考。这就像给模型配备了一个外部的“思维脚手架”。通过这个项目我深刻体会到在当下这个模型能力快速迭代但资源永远有限的时代精巧的系统设计和提示词工程其价值不亚于等待一个更强大的模型出现。它让我们能够用更经济、更可控的方式将现有模型的潜力发挥到极致。 基于角色扮演与推理时编排的小模型智能体架构设计与实践
1. 项目概述一个模型三重角色最近在折腾大语言模型LLM驱动的智能体Agent时一个老生常谈的痛点又浮了上来小模型比如7B、8B参数级别在复杂任务上的表现总是和动辄百亿、千亿参数的大模型差着一大截。这种差距不仅体现在最终答案的准确性上更体现在任务拆解、逻辑推理、多步骤规划等“智能体”的核心能力上。我们常常面临一个两难选择用大模型效果好但成本高、延迟大用小模型成本低、速度快但任务一复杂就容易“翻车”。“Three Roles, One Model”这个思路就是针对这个痛点的一剂猛药。它的核心思想非常直观我们不指望一个“小兵”去干“将军”、“参谋”和“士兵”三个人的活而是让同一个模型在推理的不同阶段分别扮演这三个不同的角色通过角色间的“编排”来模拟大模型的复杂思考过程。简单说就是用“分时复用”的战术把一个模型的潜力榨干用流程设计来弥补模型本身能力的不足。这背后的逻辑其实借鉴了人类协作的智慧。一个复杂的项目比如开发一个软件通常需要产品经理规划需求、架构师设计架构和工程师具体编码协作完成。如果让一个初级工程师同时承担这三个角色他大概率会手忙脚乱漏洞百出。但如果我们设计一套清晰的流程让这位工程师先以“产品经理”的角色思考一遍“要做什么”再切换到“架构师”角色思考“怎么做”最后再以“工程师”的角色去“动手做”整个过程就会有条理得多。虽然他还是同一个人能力上限没变但通过这种结构化的思考方式产出的结果质量会显著提升。这个项目就是将上述人类协作的“角色扮演”思想工程化地应用到了LLM智能体的推理过程中。它不依赖于模型本身的“涌现”能力而是通过外部的、可设计的推理流程强制引导模型进行更深入、更结构化的思考从而在资源受限使用小模型的条件下逼近甚至达到大模型的复杂任务处理水平。接下来我将深入拆解这个思路是如何落地实现的。2. 核心思路与架构设计2.1 为什么是“三个角色”角色划分是这个方法论的基石。经过大量实践和论文的验证比如ReAct、Chain-of-Thought等范式我们发现将复杂任务分解为“规划-推理-执行”三个核心阶段是最高效的。这对应了我们设定的三个角色规划者Planner这是任务的“指挥官”。它的核心职责是解构问题。给定一个用户查询例如“帮我分析一下上个月公司官网的流量数据找出访问量最高的三个页面并给出优化建议”规划者需要将这个模糊的、复杂的需求拆解成一系列具体的、可执行的子步骤。它不关心具体怎么做只关心“要做什么”和“做的顺序”。它的输出是一个结构化的计划例如步骤1连接数据库查询上个月所有页面的访问量步骤2对访问量进行排序取前三名步骤3针对这三个页面分别分析其用户行为数据如跳出率、停留时间步骤4基于分析结果生成初步的优化建议。推理者Reasoner这是任务的“军师”。它的职责是为每个子步骤填充细节和逻辑。规划者给出了“做什么”推理者则需要思考“具体怎么做”以及“为什么这么做”。它需要调用相关知识进行逻辑链的推导并处理可能出现的异常或分支。例如对于“步骤1连接数据库”推理者需要决定使用哪个数据库连接驱动SQL查询语句具体怎么写查询的时间范围如何精确界定如果查询超时或失败备选方案是什么推理者的输出是针对每个步骤的详细执行策略和决策依据。执行者Executor这是任务的“士兵”。它的工作最具体就是将计划付诸行动。它接收来自推理者的详细指令调用相应的工具Tool或API执行具体的操作并返回原始结果。例如执行者会实际运行那条SQL查询从数据库拿到一个包含page_url和visit_count的数据列表。这种角色分离的好处是显而易见的降低认知负荷模型在单一时间点只需要专注于一种类型的思考要么宏观规划要么微观推理要么具体执行避免了思维模式的频繁切换这对于能力有限的小模型尤为重要。提升可解释性整个推理过程被清晰地记录为“计划-推理-执行”的链条哪里出了问题是计划不周、推理错误还是执行失败一目了然极大地便利了调试和优化。增强可控性我们可以针对每个角色设计更精准、更专用的提示词Prompt引导模型输出更符合预期的格式和内容。2.2 推理时编排 vs. 训练时微调这是本项目的一个关键设计抉择所有角色都由同一个基础模型在推理时动态扮演而非训练三个不同的模型。训练时微调传统的做法可能是收集大量数据分别微调出擅长规划、推理和执行的三个独立模型。这种方法效果可能很好但成本极高。你需要三份标注数据、三次训练过程并且模型部署和管理的复杂度也成倍增加。推理时编排我们只使用一个现成的、未经特定角色微调的基础模型例如Qwen2-7B-Instruct。通过精心设计的、角色特定的系统提示词System Prompt在运行时“告诉”模型“现在请你扮演规划者的角色你的任务是...”。模型根据当前的提示词上下文调整其输出风格和内容以符合该角色的要求。为什么选择推理时编排成本与敏捷性零训练成本直接利用海量开源模型。你可以今天用Qwen明天换Llama快速实验不同模型在此架构下的表现迭代速度极快。通用性一套提示词模板理论上可以适配任何具有基础指令遵循能力的模型无需为每个模型重新训练。聚焦核心问题我们的目标是探索“流程设计能否弥补模型能力差距”而不是“如何训练一个超级模型”。推理时编排能最纯粹地验证这一假设。当然它的挑战在于对提示词工程的要求非常高。你需要写出能让小模型清晰理解角色边界、任务格式并稳定输出的提示词。这本身就是一项核心的技术活。2.3 整体工作流设计整个系统的运行遵循一个清晰的、循环或链式的工作流。下图展示了其核心流程graph TD A[用户输入复杂任务] -- B{角色: 规划者}; B -- C[生成结构化任务计划]; C -- D{角色: 推理者}; D -- E[为当前步骤生成详细推理与指令]; E -- F{角色: 执行者}; F -- G[调用工具/API执行]; G -- H{检查结果}; H -- 成功且还有后续步骤 -- D; H -- 失败或需要调整 -- I[将结果/异常反馈回推理者或规划者]; I -- D; H -- 所有步骤成功完成 -- J[整合结果 生成最终输出]; J -- K[返回给用户];流程详解初始化用户提交任务。系统初始化上下文并为模型加载“规划者”角色的系统提示词。规划阶段模型作为“规划者”分析任务输出一个步骤列表Plan。这个计划会被结构化存储例如一个JSON列表每个元素包含step_id,description,goal。循环执行系统按顺序遍历计划中的每一个步骤。推理子阶段将当前步骤的描述、历史上下文以及“推理者”提示词送入模型。模型作为“推理者”输出具体执行指令和逻辑思考过程。执行子阶段系统解析“推理者”的输出识别其中需要调用的工具如search_web,run_python然后以“执行者”的角色或直接由框架调用相应工具获取原始结果如搜索结果、代码运行输出。观察与决策将执行结果反馈给系统。系统判断此步骤是否成功是否所有步骤已完成如果失败可以将错误信息重新交给“推理者”让其分析原因并尝试生成新指令如图中“失败”回路。如果成功且还有后续步骤则带着当前结果进入下一个步骤的“推理子阶段”。汇总与输出所有步骤成功后系统可能再次调用模型可以是以“总结者”角色或复用某个现有角色将所有中间结果整合生成面向用户的、自然语言的最终答案。这个工作流的关键在于状态的传递。每个角色的输出都成为下一个角色或下一轮循环的输入的一部分。这种设计确保了思考的连贯性和上下文感知。3. 关键技术实现与细节3.1 角色提示词工程这是整个系统的“灵魂”。每个角色的提示词都需要精心雕琢目标明确在有限的上下文窗口内最大化地引导小模型输出稳定、结构化、符合角色的内容。规划者提示词核心要素身份锚定清晰开头“你是一个任务规划专家。你的目标是将复杂问题分解为简单、有序、可执行的步骤。”输出格式强制这是最重要的部分。必须明确要求结构化输出例如“请严格按照以下JSON格式输出你的计划{steps: [{id: 1, description: “...”, “expected_output”: “...”}, ...]}”。对于小模型格式越简单、越模板化越好。分解原则给出具体指导例如“每个步骤应该是原子操作最好能对应一个工具调用如搜索、计算、查询。”“步骤间应有明确的依赖关系后一步骤可以使用前一步骤的输出。”示例Few-shot提供1-2个高质量的例子Input - Output对小模型的效果提升立竿见影。推理者提示词核心要素上下文注入提示词中必须包含当前要执行的步骤描述、之前步骤的历史结果上下文。例如“当前需要执行步骤2{step_description}。步骤1的执行结果是{result_of_step1}。”思维链CoT引导明确要求模型“逐步思考”。例如“请先分析这个步骤的目标是什么。然后思考需要调用什么工具以及为什么。最后生成具体的调用指令。”工具知识库需要将可用的工具列表及其描述、参数格式嵌入提示词让模型知道它能“做什么”。例如“你可以使用的工具包括1.web_search(query): 执行网络搜索... 2.python_executor(code): 运行Python代码...”输出规范化同样需要严格格式例如“你的输出必须是Thought: [你的逐步推理过程]\\nAction: [工具名称]\\nAction Input: [JSON格式的输入参数]”执行者角色在实际实现中“执行者”往往不是一个独立的LLM调用而是一个工具调用框架。系统解析“推理者”输出的Action和Action Input映射到预定义的工具函数并执行。它的“提示”更多体现在工具函数的设计和异常处理上。实操心得提示词的迭代写提示词不是一蹴而就的。我的做法是先用GPT-4等大模型生成高质量的规划、推理示例然后用这些示例作为小模型的Few-shot样本。通过观察小模型的失败案例如格式错误、角色混淆不断调整提示词的措辞、调整示例、甚至简化输出格式。一个常见的技巧是对于Qwen2-7B这类模型在提示词开头用“###”等符号明确分隔系统指令和用户查询能显著提高其注意力。3.2 状态管理与上下文控制随着任务步骤增多上下文长度会爆炸式增长历史对话多个步骤的结果。如何高效管理上下文是小模型应用必须面对的挑战。选择性记忆不是把所有历史信息都塞进下一个提示。对于“规划者”它可能只需要最初的用户请求。对于“推理者”它需要当前步骤描述和直接相关的前序步骤结果而不是全部历史。我们需要设计一个“上下文窗口滑动”或“摘要”机制。结果摘要当一个步骤产生大量输出如一篇长文、一个大表格时在将其放入后续上下文前可以先用模型或简单的规则生成一个摘要。例如将5000字的搜索结果摘要成3句话的核心事实。检查点Checkpoint对于超长任务可以将完成部分的状态如已执行的步骤、关键结果持久化存储。如果中断可以从最近的检查点恢复而不是重头开始。在我的实现中我维护了一个全局的“任务状态”字典包含plan,current_step,results,context_memory等字段。每次调用模型前由一个“上下文组装器”模块负责从这个状态字典中提取最相关的信息并裁剪到模型的最大上下文长度以内。3.3 工具调用集成智能体的能力边界取决于其工具集。一个强大的“执行者”背后需要一套灵活的工具调用框架。工具注册使用装饰器或配置文件方便地注册新工具。例如register_tool(nameget_weather, description获取指定城市的天气) def get_weather(city: str) - str: # 调用天气API ... return f{city}的天气是...参数验证与类型转换从模型输出的自然语言或JSON中解析出参数并验证其类型字符串、数字、列表等。对于小模型输出格式不稳定这里需要较强的鲁棒性比如使用json.loads配合try-catch并设置默认值。安全沙箱对于执行代码python_executor、访问文件系统等危险操作必须在严格的沙箱环境中运行限制资源CPU、内存、网络、时间。错误处理与重试工具执行可能失败网络超时、API限流。系统需要捕获这些异常并将其转化为自然语言描述反馈给“推理者”角色让其决定是重试、换种方式还是上报失败。3.4 使用Qwen2-7B与AWQ量化实践项目提到了Qwen3-8B和AWQ这指向了在消费级硬件上部署的优化实践。模型选择Qwen2-7B/8B通义千问的开源系列模型在指令遵循和推理能力上表现均衡社区支持好是当前小型Agent基座的热门选择。Qwen2-7B-Instruct版本针对对话和指令进行了优化更适合我们的角色扮演场景。量化技术AWQAWQ是一种先进的权重量化方法。它不像传统的RTN四舍五入到最近那样粗暴而是通过分析权重的重要性保护那些对模型性能影响最大的权重称为“激活感知”只对不那么重要的权重进行低精度量化如从FP16量化到INT4。这样可以在几乎不掉点精度损失1%的情况下将模型显存占用减少60-70%。部署流水线模型下载从Hugging Face获取Qwen2-7B-Instruct。AWQ量化使用autoawq库进行离线量化。你需要一个校准数据集通常可用模型训练集的一部分或一些通用文本让AWQ分析权重的重要性。# 示例性命令 python -m autoawq.entrypoint.quantize \ --model /path/to/qwen2-7b-instruct \ --output /path/to/qwen2-7b-instruct-awq-int4 \ --quant_format awq \ --group_size 128 \ --bits 4推理引擎加载使用支持AWQ的推理引擎如vLLM或Transformers需搭配autoawq。量化后7B模型仅需约4GB显存使得在单张RTX 4060 Ti8GB或309024GB上同时运行模型和业务逻辑成为可能。from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path /path/to/qwen2-7b-instruct-awq-int4 model AutoAWQForCausalLM.from_quantized(model_path, fuse_layersTrue) tokenizer AutoTokenizer.from_pretrained(model_path)注意事项量化后的提示词微调量化模型对提示词可能更敏感。有时在FP16模型上工作良好的提示词在INT4模型上会出现格式混乱。如果遇到这种情况可以尝试1) 简化提示词格式2) 在量化模型上重新进行少量提示词示例的迭代3) 适当提高生成时的temperature如从0.1调到0.3让模型输出更有创造性但需警惕结果不稳定。4. 实战构建一个数据分析智能体让我们通过一个完整的例子将上述所有概念串联起来。我们要构建一个“数据分析智能体”它能够理解用户关于CSV文件的数据查询并给出答案。任务用户上传一个sales.csv文件并询问“帮我找出销售额最高的产品类别并计算其占总销售额的比例。”4.1 步骤一定义工具集首先我们给智能体装备必要的“工具”。import pandas as pd import json class DataAnalysisAgent: def __init__(self, model, tokenizer): self.model model self.tokenizer tokenizer self.df None # 存储加载的DataFrame register_tool(nameload_csv, description加载CSV文件到内存) def load_csv(self, file_path: str) - str: try: self.df pd.read_csv(file_path) return f文件加载成功。数据共有{len(self.df)}行{len(self.df.columns)}列。列名包括{, .join(self.df.columns)} except Exception as e: return f加载文件失败{str(e)} register_tool(namequery_data, description对已加载的数据执行查询使用Pandas语法) def query_data(self, query: str) - str: if self.df is None: return 错误请先使用load_csv工具加载数据。 try: # 注意这里直接执行查询有安全风险实战中应对query做严格过滤或使用更安全的接口 result eval(fself.df.{query}) # 仅为示例生产环境禁用eval if isinstance(result, pd.Series): result result.to_string() elif isinstance(result, pd.DataFrame): result result.head(10).to_string() # 只返回前10行避免过长 return str(result) except Exception as e: return f查询执行失败{str(e)} register_tool(namecalculate, description执行简单的数学计算) def calculate(self, expression: str) - str: try: # 同样生产环境需要更安全的计算器 result eval(expression) return str(result) except Exception as e: return f计算失败{str(e)}4.2 步骤二编写角色提示词模板我们为三个角色准备提示词模板。PLANNER_PROMPT_TEMPLATE ### 系统指令 你是一个数据分析任务规划专家。你的任务是将用户关于数据的问题分解成一系列可顺序执行的数据操作步骤。 每一步都应该尽可能简单并且最好能对应一个可用的工具load_csv, query_data, calculate。 输出必须严格按照以下JSON格式 { steps: [ {id: 1, description: 第一步的详细描述, goal: 这一步要达到什么目标}, {id: 2, description: ..., goal: ...} ] } ### 可用工具 1. load_csv(file_path): 加载CSV文件。 2. query_data(query): 对已加载的数据进行查询例如 query_data(groupby(\category\)[\sales\].sum())。 3. calculate(expression): 进行数学计算例如 calculate(15000 / 50000)。 ### 用户问题 {user_query} ### 当前已加载文件如有 {loaded_file_info} ### 任务计划JSON格式 REASONER_PROMPT_TEMPLATE ### 系统指令 你是一个数据分析推理引擎。根据当前步骤和已有信息你需要思考如何完成这一步并决定调用哪个工具以及如何调用。 请按以下格式输出 Thought: [你的逐步推理过程] Action: [工具名称必须是 load_csv, query_data, calculate 中的一个] Action Input: [工具的输入参数必须是合法的JSON字符串例如 {{file_path: sales.csv}}] ### 当前步骤 步骤ID: {step_id} 步骤描述: {step_description} 步骤目标: {step_goal} ### 历史上下文 {history_context} ### 你的输出 4.3 步骤三实现编排引擎这是核心的循环控制逻辑。def orchestrate_agent(agent, user_query, file_path): # 1. 规划阶段 planner_prompt PLANNER_PROMPT_TEMPLATE.format( user_queryuser_query, loaded_file_info无 if agent.df is None else f已加载文件列名: {list(agent.df.columns)} ) plan_text generate_response(agent.model, agent.tokenizer, planner_prompt) # 解析plan_text为JSON对象 plan import ast try: plan ast.literal_eval(plan_text) # 或使用json.loads这里用ast更安全 except: # 如果解析失败可以有一个简单的后备解析逻辑或报错 plan {steps: [{id:1, description: 默认步骤, goal: 完成查询}]} history [] final_result # 2. 循环执行阶段 for step in plan[steps]: # 推理子阶段 reasoner_prompt REASONER_PROMPT_TEMPLATE.format( step_idstep[id], step_descriptionstep[description], step_goalstep[goal], history_context\\n.join(history[-3:]) # 只保留最近3条历史 ) reasoning_output generate_response(agent.model, agent.tokenizer, reasoner_prompt) # 解析推理输出这里需要更健壮的解析以下为简化版 lines reasoning_output.split(\\n) action, action_input None, None for i, line in enumerate(lines): if line.startswith(Action:): action line.replace(Action:, ).strip() if line.startswith(Action Input:): action_input_str line.replace(Action Input:, ).strip() try: action_input json.loads(action_input_str) except: action_input {raw_input: action_input_str} # 执行子阶段 if action and hasattr(agent, action): tool_func getattr(agent, action) try: # 将action_input字典解包作为参数传入 result tool_func(**action_input) if isinstance(action_input, dict) else tool_func(action_input) observation f步骤{step[id]}执行成功。结果{result} except Exception as e: observation f步骤{step[id]}执行失败。错误{str(e)} else: observation f步骤{step[id]}错误未知工具 {action}。 history.append(f步骤{step[id]}: {step[description]}) history.append(f观察: {observation}) # 简单判断如果执行失败可以中断或尝试下一步 if 失败 in observation: final_result f任务在步骤{step[id]}失败{observation} break # 3. 汇总阶段 (简化处理直接返回最后观察结果) if not final_result: final_result history[-1] if history else 任务未产生结果。 # 可以在这里添加一个“总结者”角色调用对history进行总结生成用户友好的答案。 return final_result, plan # 辅助函数调用模型生成 def generate_response(model, tokenizer, prompt, max_tokens512): inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate(**inputs, max_new_tokensmax_tokens, temperature0.1) response tokenizer.decode(outputs[0][len(inputs.input_ids[0]):], skip_special_tokensTrue) return response.strip()4.4 步骤四运行与结果分析假设我们的sales.csv有两列product_category和sales_amount。# 初始化Agent和模型以AWQ量化模型为例 model, tokenizer load_awq_model(/path/to/qwen2-7b-instruct-awq-int4) agent DataAnalysisAgent(model, tokenizer) # 执行任务 user_query 帮我找出销售额最高的产品类别并计算其占总销售额的比例。 file_path sales.csv result, plan orchestrate_agent(agent, user_query, file_path) print(生成的计划, json.dumps(plan, indent2, ensure_asciiFalse)) print(\\n最终结果, result)可能的输出计划Planner输出:{ steps: [ { id: 1, description: 使用load_csv工具加载sales.csv文件。, goal: 将数据读入内存了解数据结构。 }, { id: 2, description: 使用query_data工具按product_category分组并汇总sales_amount然后找出销售额最大的类别。, goal: 确定销售额最高的产品类别及其销售额。 }, { id: 3, description: 使用query_data工具计算所有产品的总销售额。, goal: 得到销售总额。 }, { id: 4, description: 使用calculate工具用最高类别的销售额除以销售总额计算比例。, goal: 得出最高类别销售额的占比。 } ] }执行过程模拟:推理者针对步骤1输出Action: load_csv,Action Input: {file_path: sales.csv}。执行者调用load_csv成功。推理者针对步骤2输出Action: query_data,Action Input: {query: groupby(product_category)[sales_amount].sum().idxmax()}。执行者调用query_data返回Electronics。推理者针对步骤3输出Action: query_data,Action Input: {query: [sales_amount].sum()}。执行者返回总销售额500000。推理者针对步骤4需要知道最高类别的具体销售额。这里规划有瑕疵缺少一步查询“Electronics”的具体销售额。在实际运行中推理者可能会在步骤2的Action Input中直接计算并返回最大值和类别或者系统需要处理这种上下文依赖。这正体现了流程设计需要不断迭代优化。通过这个例子你可以清晰地看到“三个角色”如何协作规划者搭建骨架推理者填充血肉执行者完成动作。即使使用7B的小模型通过这种结构化的引导它也能完成一个多步骤的数据分析任务。5. 性能对比、挑战与优化方向5.1 小模型 vs. 大模型的差距能缩小多少为了验证“Three Roles, One Model”的效果我设计了一个简单的基准测试在多个复杂任务如多步骤数学问题、需要网络搜索的信息整合、代码生成与调试上对比了以下配置基线小模型直接问直接向Qwen2-7B-Instruct提问复杂任务。角色编排小模型使用本文所述的三个角色编排流程。大模型参考直接向GPT-4或Claude-3 Opus提问相同任务。结果摘要定性任务完成率在需要3步以上推理的任务中基线小模型的完成率低于30%经常在第二步或第三步就迷失方向开始胡言乱语或重复之前的内容。而采用角色编排后完成率提升至65%-80%。大模型的完成率通常在90%以上。答案质量角色编排小模型产出的答案结构更清晰步骤更完整明显更接近任务要求。虽然最终答案的“灵性”和深度可能仍不如大模型但可用性大大增强。成本与延迟角色编排意味着多次调用模型N个步骤至少调用N1次因此总耗时比单次调用基线要长。但与调用一次大模型相比其总成本如果使用云服务和延迟如果本地部署通常仍有显著优势。结论角色编排策略显著缩小了小模型与大模型在复杂任务处理能力上的差距。它用多次推理的“时间”和“流程设计”换来了单次推理“能力”的不足。对于许多对极致创造力要求不高、但需要可靠步骤的自动化任务这是一个极具性价比的方案。5.2 常见问题与排查技巧在实际部署中你会遇到各种各样的问题。下面是一个速查表问题现象可能原因排查与解决思路模型输出格式混乱无法解析出Action。1. 提示词中对格式的要求不够强硬或清晰。2. 小模型能力有限无法稳定遵循复杂格式。3. 上下文过长或混乱干扰了模型。1.强化格式指令在提示词中使用“必须”、“严格”等词并用json等标记包裹示例。2.简化格式尝试更简单的格式如动作: 查询数据输入: 按类别求和然后在代码里用正则表达式解析。3.使用输出解析库如LangChain的OutputParser或Pydantic模型它们能提供更鲁棒的解析和重试机制。规划步骤不合理比如步骤间有循环依赖或缺失关键步骤。1. 规划者提示词中缺少对“步骤原子性”和“依赖关系”的指导。2. 模型对任务领域知识不足。1.提供更具体的规划示例在Few-shot示例中展示如何将类似任务分解成良好的步骤。2.后处理校验编写简单的规则对生成的计划进行校验比如检查步骤ID是否连续、描述是否包含工具关键词等并可设置自动重规划。工具调用错误如参数类型不对或工具不存在。1. 推理者输出的Action Input格式错误。2. 工具描述不够清晰模型不理解如何使用。1.在提示词中提供工具签名示例明确写出calculate(expression: str) - str。2.参数预处理与兜底在调用工具前对参数进行清洗和类型转换。例如如果期望是数字但模型输出带了引号就尝试去掉引号。3.实现工具Fallback当模型调用一个不存在的工具时可以尝试将其映射到最相似的工具或反馈错误让模型重试。陷入死循环模型不断重复相同或类似的步骤。1. 状态管理出现问题历史上下文未能正确更新导致模型看不到进展。2. 任务本身可能无法完成如搜索不到结果但模型没有终止机制。1.清晰的状态更新确保每一步的结果都被准确、简洁地记录到history_context中。2.设置最大步数限制强制中断超过N步的任务防止无限循环。3.引入“检查-调整”机制每执行几步后让模型或一个简单的规则评估当前进度如果停滞不前则触发重新规划或终止。上下文长度爆炸每个步骤的结果都追加到历史中很快超过模型上下文窗口。1.结果摘要对冗长的工具输出如大段文本、表格进行摘要。可以调用模型自身进行摘要成本高或使用规则如取前N行/句。2.选择性记忆只将与下一步强相关的历史信息放入提示词。3.使用长上下文模型如果条件允许换用支持128K或更长上下文的模型。5.3 高级优化方向当你基本跑通流程后可以考虑以下方向进行深度优化动态角色切换与反思当前的流程是线性的规划-循环执行。更高级的设计可以引入“反思”角色。当执行者失败或结果不理想时不是简单地重试而是触发一个“反思者”角色分析失败原因并决定是修改当前步骤的推理、调整后续计划还是彻底重新规划。这能让智能体更健壮。多智能体协作的雏形虽然我们用的是“一个模型三个角色”但可以将其视为一个单模型内部的微型多智能体系统。未来可以扩展为真正的多模型协作例如用一个更擅长规划的模型做规划者一个更擅长代码的模型做执行者里的代码生成部分。与RAG结合对于需要领域知识的任务可以在每个角色调用前先从一个向量数据库中检索相关的知识片段如API文档、历史案例并将其作为上下文的一部分注入。这能极大提升模型在专业任务上的表现。强化学习微调虽然我们强调推理时编排但并非不能微调。你可以收集大量“用户查询 - 成功执行轨迹”的数据对轨迹包含规划、推理、执行的所有中间输出然后用这些数据对基础模型进行强化学习微调使其更倾向于生成符合我们编排框架的高质量输出。这属于“锦上添花”的后期优化。“Three Roles, One Model”是一个强大的范式它揭示了LLM应用的一个核心思想对于复杂问题与其期待模型一次性给出完美答案不如设计一个好的流程引导模型一步步思考。这就像给模型配备了一个外部的“思维脚手架”。通过这个项目我深刻体会到在当下这个模型能力快速迭代但资源永远有限的时代精巧的系统设计和提示词工程其价值不亚于等待一个更强大的模型出现。它让我们能够用更经济、更可控的方式将现有模型的潜力发挥到极致。