基于大语言模型智能体协作的自动化多选题生成与评估系统实践

1. 项目概述：当大模型“科学家”学会协作

最近在折腾一个挺有意思的课题：如何让多个大语言模型（LLM）智能体像一支训练有素的科研团队一样协同工作，去完成一项具体的科学任务。这个想法源于一个很实际的痛点：在科研辅助、教育内容生成等领域，单一模型的能力往往有短板，比如一个模型擅长逻辑推理，但文笔生硬；另一个模型创意十足，却可能偏离事实。如果能让它们各司其职、互相校验，是不是能产生“1+1>2”的效果？

我这次选择的“练兵场”是多项选择题（MCQ）的生成与评估。这可不是随便出几道题那么简单。一道高质量的MCQ，需要题干清晰、选项具有干扰性但唯一正确、知识点准确，并且最好能考察不同层次的认知能力（比如记忆、理解、应用）。传统上，这依赖领域专家大量的时间和精力。现在，我们想看看，能否通过精心编排一组LLM智能体，自动化地完成从知识素材到高质量题库的整个流程。

这个项目的核心，就是“编排”（Orchestrating）。它不是简单地把几个模型调用接口串起来，而是要设计一套清晰的协作机制、交互协议和评估回路，让智能体们能够有序、高效、可靠地共同解决问题。这背后涉及到智能体架构设计、任务分解、提示工程、以及如何量化评估生成结果的质量等一系列挑战。接下来，我就把自己搭建这个“智能体科研小队”的全过程、踩过的坑和收获的心得，详细拆解一遍。

2. 智能体编排框架的整体设计思路

2.1 为什么选择“编排”而非“单模型”？

最开始的想法很直接：找一个最强的模型，比如GPT-4，让它直接根据材料生成MCQ。我试过，效果确实比小模型好，但问题很快浮现：

1. 质量不稳定：同一段材料，多次生成的结果在难度、风格、知识点覆盖上差异很大。
2. 评估缺失：模型生成即结束，题目本身是否有歧义、选项是否合理、答案是否绝对正确，缺乏一个独立的校验环节。
3. 思维过程黑箱：我们不知道模型是如何构思干扰项的，这不利于后续的优化和调整。

因此，“编排”的思路应运而生。它的核心优势在于模块化和专业化。我们可以为MCQ生成流程中的不同子任务，设计专门的智能体角色，每个角色专注于做好一件事，并通过明确的输出规范进行交互。

2.2 我们的“科研小队”角色分工

我设计了一个由四个核心智能体组成的流水线，它们分别扮演不同的角色：

1. 知识解析与大纲生成智能体：它的任务是深入理解输入的科研材料（如一篇论文的摘要、一个教科书章节），提取核心概念、关键事实、理论间的逻辑关系，并生成一个结构化的知识大纲。这个大纲是后续所有工作的蓝图。
2. 题目生成智能体：它接收知识大纲，并负责根据指定的认知层级（如记忆、理解、应用）和题型要求，创作出初步的MCQ题干和选项。它的重点是“创意”和“符合格式”。
3. 严谨性校验与优化智能体：这是一个“挑刺者”角色。它负责审核生成的题目：题干是否存在歧义？选项是否在语法和逻辑上都是并列的？是否有不止一个选项看似合理？它需要提出具体的修改建议。
4. 综合评估智能体：这是最终的“质量守门员”。它不直接修改题目，而是从多个维度（如准确性、清晰度、干扰项有效性、教育价值）对优化后的题目进行打分，并给出简要评语。这个评分可以作为题目入库的阈值依据。

这个分工模仿了真实的教研流程：学科专家梳理重点（角色1），出题老师初步命题（角色2），资深编辑或另一专家审题（角色3），最后教研组长做最终审核（角色4）。

2.3 智能体间的通信与协作协议

智能体不能各干各的，需要对话。我采用了基于“结构化提示”和“标准化输出JSON”的通信方式。

每个智能体都被赋予一个清晰的系统提示（System Prompt），定义其角色、职责、输入格式和必须遵守的输出格式。例如，给“题目生成智能体”的指令中会明确要求：

你的输出必须是一个合法的JSON对象，包含以下字段：{ “question”: “题干文本”, “options”: {“A”: “选项A文本”, “B”: “选项B文本”, …}, “correct_answer”: “A”, “explanation”: “考察知识点X，因为…”, “cognitive_level”: “记忆/理解/应用” }

而“严谨性校验智能体”的输入就是这个JSON，它的输出则是另一个JSON：

{ “issues_found”: true/false, “issues”: [ {“type”: “歧义”, “location”: “题干”, “description”: “…”, “suggestion”: “…”}, … ], “revised_question_json”: {…} }

通过强制规定JSON输出，我确保了信息能在智能体间无损、准确地传递，方便程序化处理。整个流程就像一个精密的流水线，上游智能体的输出是下游智能体的输入，任何格式错误都会导致流水线中断，这反而有利于早期发现提示词设计的问题。

3. 核心模块的细节实现与提示工程

3.1 知识解析智能体：从乱麻中理出脉络

这是整个流程的基石。如果知识大纲跑偏，后面生成的题目都是无本之木。这里的挑战在于，LLM容易陷入细节复述，而缺乏对知识结构的宏观提炼。

我的提示词设计核心：

1. 指令明确：要求模型“以教育学专家的身份，为设计多项选择题的目的，提取以下材料的结构化知识要点”。
2. 提供输出模板：明确要求输出分层级的大纲（如I. 核心概念 -> A. 定义 -> B. 关键特征；II. 重要过程 -> A. 步骤1 -> B. 步骤2；III. 常见误区/对比）。
3. 限制与聚焦：指令中强调“避免直接复制长句，用简洁的短语或短句概括”、“优先提取适合用选择题考察的离散知识点和概念对比”。

实操心得：

• 给模型一个“角色”能显著提升输出质量。“教育学专家”这个角色会让模型下意识地思考哪些知识点适合出题。
• 在提示词中举例非常有效。我会附上一个简短示例，展示从一段关于“光合作用”的文字到知识大纲的转换过程，模型模仿的效果立竿见影。
• 对于非常专业的科研材料，需要在提示词中“投喂”一些该领域的核心术语，帮助模型更好地理解上下文。

3.2 题目生成智能体：在约束下发挥创意

这个智能体需要在严格遵循知识大纲和格式要求的前提下，发挥创造性思维，构思有意义的干扰项。这是最难平衡的一点。

关键提示策略：

1. 分解任务：在提示词中，将“生成一道MCQ”分解为几个子步骤：a) 从大纲中选择一个具体知识点；b) 确定考察的认知层级；c) 构思一个清晰的问题情境（题干）；d) 生成唯一正确的答案；e) 构思3-4个具有吸引力的错误选项。
2. 干扰项生成技巧：直接要求模型“使用常见的学生误解、相关但非核心的概念、部分正确的陈述、或过度概括的结论来构造干扰项”。这比单纯说“生成错误选项”有效得多。
3. 多样性控制：通过系统提示，要求同一批生成的题目在知识点和认知层级上尽可能分布均匀，避免扎堆。

注意：直接让模型生成“A. 正确选项 B. 明显错误 C. 明显错误 D. 明显错误”这种题目是毫无意义的。必须通过提示词引导它去挖掘那些“似是而非”的选项，这才是MCQ质量的关键。

3.3 校验与评估智能体：构建质量防火墙

这两个智能体是保障产出质量的“矛”与“盾”。

严谨性校验智能体（矛）：我把它设计得非常“挑剔”。它的提示词里包含一个详细的检查清单：

• 题干清晰度：问题是否无歧义？是否包含所有必要信息？
• 选项独立性：选项之间是否互斥？是否存在包含关系？
• 选项同质性：所有选项在长度、语法复杂度和形式上是否基本一致？（避免正确答案长得特别突出）
• 唯一正确性：在给定知识背景下，是否绝对只有一个选项是正确的？
• 干扰项合理性：每个错误选项是否代表一个可能的学生错误概念？

它会针对每一项给出“通过/不通过”的判断和修改建议。这个智能体通常使用推理能力较强的模型（如Claude 3或GPT-4），因为它需要细致的逻辑分析。

综合评估智能体（盾）：这个智能体采用评分制。我会设计一个简单的评分量表（例如，每项1-5分）：

• 准确性：题目及答案与源材料知识是否100%吻合。
• 清晰度：题干表述是否直接易懂。
• 干扰项强度：错误选项对未完全掌握知识的学生是否具有吸引力。
• 教育价值：该题目是否能有效检测学生对目标知识点的掌握情况。

评估智能体输出分数和简短理由。这个分数可以作为自动化筛选的阈值，比如只保留总分高于4分的题目。

4. 工作流编排与系统实现

4.1 技术栈选择与考量

为了实现这个多智能体流水线，我选择了以下技术栈，主要基于其灵活性和成熟度：

• 智能体运行时/框架：我尝试了LangChain和LlamaIndex。对于这种线性流水线清晰的任务，LangChain的SequentialChain或LCEL非常直观。它的Runnable接口让智能体（在这里是LLM调用）之间的连接和组合变得像搭积木。而LlamaIndex在复杂检索和知识库结合方面更强，但本项目中知识解析智能体已经完成了“检索”工作，因此LangChain的轻量化和对工作流编排的原生支持更胜一筹。
• LLM后端：采用混合模型策略。知识解析和题目生成对“创意”和“广度”要求高，可以使用GPT-4、Claude 3或国内领先的大模型。而严谨性校验需要极强的逻辑推理，GPT-4是当前首选。评估智能体则可以使用成本更低的模型如GPT-3.5-Turbo，因为它的评分规则相对固定。关键是要为不同任务匹配性价比最高的模型。
• 通信与状态管理：每个智能体的输入输出都是JSON，这天然适合用Python的字典（Dict）在内存中传递。对于更复杂、可能失败重试的流程，可以考虑引入轻量级状态机，但本项目线性流程中，用LangChain的RunnablePassthrough等组件来传递和添加数据已经足够。

4.2 编排流程的代码级视角

以下是一个高度简化的、基于LangChain LCEL的思想示例，展示了流程如何串联：

from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import JsonOutputParser from langchain_openai import ChatOpenAI from langchain_core.runnables import RunnablePassthrough # 1. 定义各个角色的提示模板 knowledge_parser_prompt = ChatPromptTemplate.from_template(“”” 你是一位教育学专家。请为出题目的，解析以下材料，生成结构化知识大纲。 要求：{outline_requirements} 材料：{input_text} 输出格式：{format_instructions} “””) question_gen_prompt = ChatPromptTemplate.from_template(“”” 你是一位资深出题老师。基于以下知识大纲，生成一道{认知层级}层次的多项选择题。 大纲：{knowledge_outline} 输出格式：{format_instructions} “””) # 2. 创建模型实例，并绑定输出解析器（强制JSON输出） model_gpt4 = ChatOpenAI(model=“gpt-4-turbo”, temperature=0.3) parser = JsonOutputParser() # 3. 构建智能体链（Runnable） knowledge_agent_chain = knowledge_parser_prompt | model_gpt4 | parser question_gen_agent_chain = question_gen_prompt | model_gpt4 | parser # 4. 编排完整流程 def full_orchestration_pipeline(input_text): # 阶段1: 知识解析 knowledge_outline = knowledge_agent_chain.invoke({ “input_text”: input_text, “outline_requirements”: “提取核心概念、过程、对比，适合出题”， “format_instructions”: parser.get_format_instructions() }) # 阶段2: 题目生成 raw_question = question_gen_agent_chain.invoke({ “knowledge_outline”: knowledge_outline, “认知层级”: “应用”， “format_instructions”: parser.get_format_instructions() }) # 阶段3 & 4: 校验与评估 (类似方式调用校验和评估智能体链) # verification_result = verification_agent_chain.invoke({“question”: raw_question}) # evaluation_score = evaluation_agent_chain.invoke({“question”: verification_result[“revised_question”]}) # return evaluation_score return {“outline”: knowledge_outline, “raw_question”: raw_question} # 调用 result = full_orchestration_pipeline(“你的科研材料文本...”)

在实际实现中，需要将校验和评估智能体也以同样的方式接入，并处理可能的错误（如JSON解析失败），通过try...catch进行重试或降级处理。

4.3 异步执行与性能优化

当需要处理大量材料生成题库时，同步调用效率太低。这里的优化点在于：

• 并行化：知识解析阶段可以并行处理多份材料。但题目生成、校验、评估对于同一道题必须是串行的。
• 异步调用：使用asyncio和LangChain的异步接口（如ainvoke）可以显著提升整体吞吐，尤其是在调用云端LLM API存在网络延迟时。
• 缓存：对于相同的知识大纲和生成参数，可以使用本地缓存（如diskcache）存储生成的题目，避免重复计算和API调用，这对成本控制至关重要。

5. 评估体系构建与效果分析

5.1 如何评估“评估系统”？

这是一个元问题。我们设计了一套智能体来生成和评估题目，那么如何评估这套系统本身的好坏？我采用了三层评估体系：

1. 内部一致性评估：让同一套系统（特别是综合评估智能体）对同一批题目在不同时间进行多次评分，计算评分者内部信度（如科隆巴赫阿尔法系数）。理想情况下，系统对自己的评判应该是稳定的。
2. 人工专家评估：这是黄金标准。邀请领域专家和资深教师，对智能体生成的题目进行盲审打分（使用与智能体评估类似的维度）。然后将专家评分与智能体评分进行相关性分析（如皮尔逊相关系数）。高相关性说明智能体的评估标准与人类专家对齐。
3. 端到端效用评估：将生成的题目用于真实的小规模教学测试，分析题目的难度系数、区分度等经典测量学指标。这是最终极的验证，但实施成本也最高。

5.2 试点研究中的发现

在我进行的试点研究中（使用计算机科学入门教材章节作为材料），有一些有趣的发现：

• 智能体协作显著优于单次生成：经过“生成-校验-优化-评估”流水线的题目，在人工专家评分中，在“选项严谨性”和“题干清晰度”两个维度上，平均分比单次直接生成的题目高出约30%。
• 校验智能体是关键瓶颈也是质量保障：大约40%的初版题目被校验智能体发现了至少一个严重问题（如歧义、多解）。这证明了独立校验环节的必要性。校验智能体的提示词细节（检查清单的完备性）对最终质量影响巨大。
• 成本与质量的权衡：使用GPT-4作为所有角色的后端，成本高昂。将知识解析和题目生成替换为成本更低的模型（如Claude Haiku），质量仅有轻微下降，但成本减少70%以上。而校验环节的模型不能轻易降级，否则会引入更多错误。
• 评估智能体的评分与人工评分呈中度相关（相关系数约0.6-0.7）。这说明它能够大致区分题目的好坏，但还不能完全替代人类专家。它更适合作为第一轮粗筛工具，将明显低质量的题目过滤掉。

5.3 常见失败模式与调优策略

在多次运行中，我观察到一些典型的失败情况及其应对策略：

失败模式	可能原因	调优策略
知识大纲偏离主题	源材料过于复杂或模型理解偏差。	1. 在提示词中强化“为出题服务”的目标。2. 先让模型用一句话总结核心，再基于总结扩展大纲。3. 使用更强大的模型进行解析。
生成的题目过于简单或机械	模型创造性不足，或提示词限制过死。	1. 适当提高temperature参数（如从0.3调到0.7）。2. 在提示词中要求“模拟真实考试中具有挑战性的题目”。3. 提供高质量题目示例作为参考。
校验智能体“过度挑剔”	检查清单过于严苛，或模型过于保守。	1. 区分“致命问题”（歧义、答案错误）和“建议优化”（表述微调）。2. 让校验智能体在提出问题时，必须引用源材料中的依据。3. 引入“仲裁者”智能体，对校验意见进行二次判断。
评估分数集中，区分度低	评分标准模糊，或模型不愿打极端分。	1. 将评分标准细化并量化（例如，清晰度：1分-有严重歧义，5分-任何学生都能看懂）。2. 要求评估智能体先陈述每个维度的优缺点，再给分，迫使它进行更细致的思考。
流程因JSON解析错误中断	模型未严格遵守输出格式。	1. 使用LangChain的OutputFixingParser或RetryOutputParser自动尝试修复。2. 在提示词中用更醒目的方式强调格式（如json …）。3. 设置重试机制，并在多次失败后降级为更简单的任务或记录错误。

6. 扩展思考与未来方向

通过这个试点项目，我深刻体会到，将LLM应用于复杂任务，其核心挑战往往不在于模型本身的能力上限，而在于如何通过精巧的系统设计和流程编排，将模型能力可靠地、规模化地转化为实际价值。多智能体协作是一条非常有前景的路径。

这个MCQ生成框架可以很自然地进行扩展：

• 领域自适应：通过微调提示词或引入领域知识库（如医学教科书、法律条文），可以快速适配到医学、法律、金融等专业领域的题库建设。
• 支持更多题型：将智能体角色扩展，可以用于生成填空题、简答题甚至开放式论述题的评分标准。
• 动态工作流：当前是线性流水线，未来可以引入路由智能体。例如，校验智能体如果发现题目问题太大，可以直接将其路由回题目生成智能体进行重构，而不是简单修改，形成一个带循环的优化流程。
• 人机协同：系统生成题目和评估后，将不确定的题目（如评估分数中等）高亮提交给人类专家复审，实现效率与质量的最优平衡。

最后，一个最实际的体会是：提示词（Prompt）是智能体的“源代码”。设计多智能体系统，很大一部分工作是在编写、调试和优化这些角色之间的“对话协议”。它需要你对任务有深刻的分解能力，同时对LLM的行为模式有敏锐的直觉。这个过程虽然充满挑战，但看到一个个智能体像齿轮一样咬合转动，最终产出高质量结果时，那种成就感是无可替代的。