大模型教育应用：自适应级联专家系统架构设计与工程实践-平芜编程栈

1. 项目概述：当大模型遇上教育，我们如何让它“因材施教”？

最近在折腾大模型应用落地的朋友们，估计都绕不开一个核心痛点：模型能力很强，但一到具体场景，比如教育答疑，回答要么太笼统，要么专业深度不够，要么干脆“一本正经地胡说八道”。通用大模型就像一个知识渊博但教学经验为零的教授，他知道很多，却不懂如何根据学生的不同水平，把知识精准地“喂”到嘴边。这正是“Pangu-ACE：基于自适应级联专家的大模型教育响应生成系统”这个项目要解决的核心问题。它不是一个简单的提示词工程包装，而是一套试图让大模型在教育领域真正“专业化”和“个性化”的系统架构。

简单来说，Pangu-ACE的核心思想是“分而治之”和“量体裁衣”。它不再依赖单一的、庞大的通用模型去应对所有教育问题，而是构建了一个由多个“专家”模型组成的“会诊”系统。这个系统能自动判断学生问题的类型、难度以及隐含的学习阶段，然后动态地调用最合适的“专家”来生成回答，甚至可以让多个“专家”协作，共同打磨出一个最优解。这里的“自适应”和“级联”是技术关键词。“自适应”意味着系统能根据输入（学生问题、历史交互等）自动调整决策路径；“级联”则描述了这些专家模型并非并行独立工作，而是可以像流水线一样，前一个专家的输出作为后一个专家的输入，进行层层精炼和深化。

这套系统瞄准的，正是当前教育科技领域最迫切的几个需求：个性化学习路径推荐、精准的学科答疑、以及适应不同认知水平的教学内容生成。无论是开发在线教育平台的智能助教，还是构建企业内部的培训问答系统，亦或是打造一个能陪伴孩子成长的AI家教，Pangu-ACE提供了一种可落地的技术框架思路。它试图弥合通用大模型的“广度”与教育垂直领域的“深度”、“精度”之间的鸿沟。接下来，我将结合当前大模型应用开发的主流技术栈，深入拆解这个系统的设计思路、核心模块的实现细节，以及在实际部署中会遇到的那些“坑”。

2. 系统核心架构与设计哲学拆解

2.1 为什么是“级联专家”而不是“单一巨模型”？

在深入代码之前，我们必须先理解这个架构选择的底层逻辑。当前，直接使用GPT-4、Claude-3或国内顶尖大模型，通过精心设计的提示词（Prompt）似乎也能完成不错的答疑。那为什么还要大费周章地设计一个级联系统呢？原因主要在于成本、可控性和精准度的“不可能三角”。

成本考量：最强大的通用模型API调用费用高昂。让一个每次回答都消耗上百K tokens的模型去处理“一元二次方程怎么解”这种基础问题，从经济上看是极大的浪费。级联系统的第一层完全可以用一个轻量、廉价的模型（甚至是本地部署的小模型）进行问题分类和路由，只有复杂、专业的问题才“升级”到更强大的专家模型处理。

可控性与可靠性：通用模型为了保持“通用”，其知识边界和行为模式存在不可预测性。在教育场景，答案的准确性和安全性是红线。通过训练或精调（Fine-tuning）一系列专注于特定领域（如初中数学、高中物理、编程语法）的“专家模型”，我们可以将风险约束在更小的、可审计的范围内。每个专家只对自己的领域负责，出错了也更容易定位和修复。

精准度与深度：一个模型很难同时在“趣味性讲解给小学生”和“严谨证明给大学生”这两个维度上都做到极致。级联架构允许我们部署多个针对不同教学风格和知识深度的专家。例如，系统可以先用一个“难度评估专家”判断学生水平，再用一个“知识点解析专家”抽取核心概念，最后将一个“讲解风格适配专家”来生成最终符合该生认知水平的回答。

Pangu-ACE的“自适应”就体现在这个动态路由和组合决策上。它不是固定的流水线，而是一个基于实时评估的、动态的决策树。系统的智能，很大程度上就体现在这个路由决策模块的设计上。

2.2 核心模块分解与数据流设计

一个典型的Pangu-ACE系统可以分解为以下几个核心模块，其数据流如下图所示（概念描述）：

输入预处理与意图理解模块：这是系统的“前台接待”。它接收原始的学生提问（可能是文本、语音转文本，甚至包含图片）。它的任务是对问题进行清洗、归一化，并完成初步的意图分类（是概念提问、习题求解、学习规划还是知识追溯？）和关键信息抽取（涉及哪些学科、章节、知识点？）。这里通常可以集成一个轻量级的NLP模型或基于规则的解析器。
自适应路由决策器：这是系统的“大脑”或“调度中心”。它接收来自预处理模块的结构化信息（意图、知识点、难度信号等），结合学生的历史交互画像（如过往问题记录、答题正确率、自我报告的水平等），决定调用哪个或哪几个专家模型，以及调用的顺序（级联路径）。决策逻辑可以是基于规则的（if-else树），也可以是基于一个轻量级机器学习模型（如分类器或强化学习智能体）的预测。这是“自适应”的核心体现。
专家模型池：这是一个预先准备好的、各司其职的模型集合。每个专家都是在大模型基础上，针对特定任务进行精调（Fine-tuning）或通过提示词工程（Prompt Engineering）高度定制化的。例如：
- 学科知识专家：精调于特定学科课本、教辅和真题数据，确保知识准确性。
- 解题步骤专家：专门训练用于将复杂问题分解为可执行的步骤，并遵循标准的解题规范。
- 口语化讲解专家：擅长用比喻、故事和生活例子解释抽象概念，针对低龄或初学者。
- 严谨推导专家：注重逻辑严密性和公式推导，适合高阶学习者。
- 错因分析专家：根据学生的错误答案，反向分析其可能的知识漏洞或思维误区。这些专家可以部署在同一个大模型服务（通过不同提示词区分），也可以是多个不同的模型实例。
响应合成与后处理模块：当级联调用完成后（可能是一个专家的输出，也可能是多个专家输出的中间结果），这个模块负责将最终答案整合成格式友好、风格统一的响应。它可能包括：格式化输出（添加重点标注、步骤编号）、安全检查（过滤不当内容）、以及添加鼓励性或引导性的交互语句（如“你理解了吗？可以试试下面这个类似问题。”）。

注意：在具体实现中，并非所有模块都需要独立的模型。一个高效的实践是，路由决策器和部分专家可以共享同一个大模型的基础能力，通过精心设计的不同“系统提示词（System Prompt）”来扮演不同角色。这能极大降低部署和运维的复杂性。

3. 关键技术实现与实操要点

3.1 专家模型的构建：精调（Fine-tuning） vs. 提示词工程（Prompt Engineering）

这是构建专家池时面临的首要技术选型。两种路径各有优劣，需要根据资源、数据和质量要求权衡。

方案A：基于提示词工程的“软专家”这种方法不改变模型权重，只为通用大模型（如通过API调用GPT-4，或本地部署Llama 3、Qwen等）设计高度专业化的提示词。

操作方法：为每个专家角色编写详细的“角色扮演”提示词。例如，给“小学数学讲解专家”的提示词可能是：“你是一位富有耐心的小学数学老师，擅长用糖果、苹果等具体物品举例。你的解释要避免使用复杂术语，语言活泼亲切。现在，请回答以下问题：[用户问题]”。
优点：实现快速，成本低，无需训练数据，易于迭代和调试。可以直接利用顶级大模型的最新能力。
缺点：对模型本身的指令遵循能力和知识广度依赖极高。在非常垂直、专业或需要严格遵循特定格式（如特定解题步骤）的场景下，可能表现不稳定，容易“跑偏”。
实操心得：提示词不是一次性写好的，需要通过大量真实场景的测试进行迭代优化。一个技巧是使用“少样本学习（Few-shot Learning）”，在提示词中提供2-3个高质量的输入输出示例，能显著提升模型输出的稳定性和格式一致性。

方案B：基于精调的“硬专家”这种方法需要收集或构造特定领域的训练数据，在基础大模型上进行有监督的精调，使模型权重发生改变，真正“学会”该领域的专业模式和风格。

操作方法：
1. 数据准备：收集（或人工生成）高质量的问答对、解题步骤对、讲解文本对。数据质量是生命线。例如，对于“物理错因分析专家”，数据格式可能是：{"question": "为什么物体浮在水面？", "wrong_answer": "因为它轻。", "analysis": "这个回答混淆了‘密度’和‘质量’的概念。正确的思路是比较物体密度和水的密度...”}。
2. 选择精调方法：对于大多数场景，LoRA (Low-Rank Adaptation)是首选。它只训练少量的额外参数，效率高，且能避免灾难性遗忘。使用像LlamaFactory、Axolotl这样的工具可以大大简化精调流程。
3. 训练与评估：在保留的验证集上评估模型，不仅看答案是否正确，更要看其讲解风格、步骤完整性是否符合专家定位。
优点：专家特性更稳定、更内化，对提示词的依赖降低，在专业领域表现通常优于提示词工程。可以部署在本地，保障数据隐私。
缺点：需要数据、计算资源和时间成本。管理多个精调模型会增加运维负担。
实操心得：不要一开始就追求大规模精调。可以先在一个小的、高质量的数据集上做LoRA精调，验证方案可行性。精调时，重点设计好训练数据的“格式”，让模型在训练过程中就学会你想要的输出结构，这比事后用提示词约束要有效得多。

混合策略：在实际的Pangu-ACE系统中，往往采用混合策略。对准确性要求极高的核心学科知识专家采用精调；对风格适配、难度转换等“软技能”专家采用提示词工程。路由决策器本身也可以用一个轻量级精调模型来实现。

3.2 自适应路由决策器的实现逻辑

路由决策器的目标是：给定问题Q和上下文C，输出一个决策D（例如：[专家A，专家B]，表示先调用A，将其输出作为输入再调用B）。实现方式主要有三种，由简到繁：

1. 基于规则的路由：这是最简单、最可解释的起点。你可以定义一系列规则。

def rule_based_router(question, student_grade): keywords_math = ["方程", "几何", "函数"] keywords_physics = ["力", "加速度", "电路"] if any(kw in question for kw in keywords_math): if student_grade <= 6: return ["primary_math_expert"] # 调用小学数学专家 else: return ["math_knowledge_expert", "step_by_step_solver"] # 先知识后解题 elif any(kw in question for kw in keywords_physics): return ["physics_expert"] else: return ["general_tutor"] # 兜底通用专家

优点：透明、可控、零训练成本。
缺点：规则难以覆盖所有复杂情况，维护成本随场景扩大而剧增。

2. 基于分类模型的路由：将路由决策视为一个多分类或多标签分类问题。你需要标注一批数据，格式如(question, context) -> expert_label。

训练：使用BERT、RoBERTa等预训练文本分类模型，在你的标注数据上进行微调。特征可以包括问题文本、学生年级、历史知识点等。
推理：模型输出每个专家标签的概率，你可以选择概率最高的一个，或者选择超过阈值的所有专家（用于级联）。
优点：能处理更复杂的语义匹配，泛化能力比规则强。
缺点：需要标注数据，且当专家数量或组合方式变化时，可能需要重新标注和训练。

3. 基于强化学习（RL）的路由（进阶）：这是实现“自适应”的终极形态。系统将路由决策视为一个序列决策问题，通过与环境的交互（学生收到回答后的反馈，如“是否理解”、“答题正确率”）来学习最优的路由策略。

状态（State）：当前问题、学生画像、交互历史。
动作（Action）：选择调用哪个专家。
奖励（Reward）：根据回答质量、学生满意度、问题解决效率等综合计算。
优点：能长期优化，实现真正的个性化适应。
缺点：系统设计复杂，训练成本极高，需要在线交互数据，不稳定。
实操建议：对于大多数项目，从基于规则开始，快速迭代；积累一定数据后，过渡到基于分类模型的路由。强化学习方案更适合大型、成熟的在线教育平台进行长期优化。

3.3 系统集成与部署架构考量

当各个模块开发完毕后，如何将它们集成为一个稳定、高效的服务？

架构模式选择：

流水线式（Pipeline）：这是最直观的方式。一个请求依次经过预处理、路由、专家调用、合成等步骤。优点是逻辑清晰，缺点是延迟有累积，且难以处理需要多个专家并行工作的场景。
编排式（Orchestration）：引入一个中央编排器（Orchestrator）。路由决策器只决定“需要谁”，编排器负责并发调用多个专家，并管理它们之间的数据流和依赖关系。这种方式更灵活，支持复杂的专家协作图。
智能体式（Agent-based）：这是当前的热点。将整个系统视为一个“教师智能体”，路由决策、工具（专家）调用都是这个智能体自主规划的结果。可以利用LangChain、LlamaIndex或Semantic Kernel这类框架来构建，它们内置了工具调用、记忆等能力，能快速搭建原型。

部署实践：

模型部署：对于精调后的专家模型，推荐使用vLLM或TGI (Text Generation Inference)进行部署。它们专为高效服务大模型设计，支持连续批处理、PagedAttention等优化，能极大提高吞吐量。对于需要快速迭代的提示词工程专家，可以直接调用云端大模型API（如OpenAI, Anthropic，或国内平台），但需考虑网络延迟和成本。
服务化：将每个模块（预处理、路由、每个专家服务）都封装为独立的HTTP或gRPC服务（如使用FastAPI）。这便于独立开发、部署和扩展。
网关与流控：在系统入口设置API网关，负责认证、限流、负载均衡和请求分发。路由决策器本身也可以作为一个服务被网关调用。
缓存策略：对于常见、标准的问题（如“勾股定理是什么？”），可以在路由决策层或专家响应层设置缓存，直接返回历史答案，大幅降低模型调用开销和响应延迟。

一个简化的部署参考如下：

[客户端] -> [API网关] -> [输入预处理服务] -> [路由决策服务] | v [专家模型池] - 专家A (vLLM部署) - 专家B (TGI部署) - 专家C (云端API) | v [响应合成服务] -> [客户端]

4. 实战开发流程与核心代码剖析

假设我们要构建一个针对K-12数学的简易版Pangu-ACE系统，包含一个“概念讲解专家”和一个“解题专家”，路由规则基于关键词。

4.1 环境准备与依赖安装

我们使用Python作为主要语言，利用FastAPI构建服务，使用OpenAI API作为专家模型的基底（出于原型开发效率考虑，实际生产可替换为本地模型）。

# 创建项目目录并初始化环境 mkdir pangu-ace-demo && cd pangu-ace-demo python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # 安装核心依赖 pip install fastapi uvicorn httpx python-dotenv openai pydantic

创建.env文件存放密钥：

OPENAI_API_KEY=your_openai_api_key_here

4.2 构建专家模型（提示词工程版）

我们首先定义两个专家，它们本质上是两个高度特化的提示词模板。

# experts.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) class ConceptExpert: """概念讲解专家：擅长用生活化例子解释数学概念""" system_prompt = """你是一位风趣幽默的小学数学老师。你的任务是向小学生解释数学概念。 要求： 1. 必须使用至少一个生活中的具体例子（比如分 pizza、数糖果）。 2. 语言要简单、亲切，避免使用专业术语。 3. 最后提一个相关的小问题，引发学生思考。 格式： 【例子】... 【核心思想】... 【考考你】... """ @staticmethod def generate_response(question: str) -> str: try: response = client.chat.completions.create( model="gpt-3.5-turbo", # 原型阶段可用gpt-3.5，生产考虑gpt-4或本地模型 messages=[ {"role": "system", "content": ConceptExpert.system_prompt}, {"role": "user", "content": question} ], temperature=0.7, max_tokens=500 ) return response.choices[0].message.content except Exception as e: return f"概念专家暂时无法回答：{str(e)}" class ProblemSolvingExpert: """解题步骤专家：擅长将应用题分解为清晰步骤""" system_prompt = """你是一位严谨的中学数学解题助手。你的任务是将数学应用题分解为清晰的步骤。 要求： 1. 逐步推理，每一步都要有明确的理由。 2. 使用标准的数学符号和格式。 3. 最后总结答案和关键知识点。 格式： 【步骤1】... (理由：...) 【步骤2】... (理由：...) ... 【答案】... 【知识点】... """ @staticmethod def generate_response(question: str) -> str: try: response = client.chat.completions.create( model="gpt-3.5-turbo", messages=[ {"role": "system", "content": ProblemSolvingExpert.system_prompt}, {"role": "user", "content": question} ], temperature=0.3, # 解题需要更确定性，温度调低 max_tokens=800 ) return response.choices[0].message.content except Exception as e: return f"解题专家暂时无法回答：{str(e)}"

4.3 实现自适应路由决策器

我们实现一个简单的基于规则和关键词的路由器。

# router.py import re from typing import List class SimpleRouter: def __init__(self): # 定义关键词列表（实际中会更复杂，可能使用词向量或分类模型） self.concept_keywords = ["是什么", "什么意思", "解释一下", "概念", "定义", "介绍"] self.solving_keywords = ["怎么解", "怎么做", "步骤", "应用题", "计算", "求解", "多少"] def route(self, question: str) -> List[str]: """ 根据问题内容决定调用哪些专家，以及顺序。 返回专家名称的列表。 """ question_lower = question.lower() # 规则1：包含“概念”类关键词，优先使用概念专家 if any(kw in question_lower for kw in self.concept_keywords): return ["concept_expert"] # 规则2：包含“解题”类关键词，优先使用解题专家 if any(kw in question_lower for kw in self.solving_keywords): return ["solving_expert"] # 规则3：复杂问题，先概念再解题（级联） # 这里用一个简单的启发式规则：问题长度较长且包含“为什么”和数字 if len(question) > 30 and "为什么" in question and re.search(r'\d+', question): return ["concept_expert", "solving_expert"] # 级联调用 # 默认：使用概念专家作为兜底 return ["concept_expert"]

4.4 集成服务与API暴露

使用FastAPI将上述模块组装起来，提供一个HTTP API。

# main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List from experts import ConceptExpert, ProblemSolvingExpert from router import SimpleRouter app = FastAPI(title="Pangu-ACE Demo API") router = SimpleRouter() class QuestionRequest(BaseModel): question: str student_id: str = "default" # 可用于未来扩展，基于学生历史画像路由 class ExpertResponse(BaseModel): expert_name: str response: str class SystemResponse(BaseModel): question: str decision_path: List[str] # 记录了调用路径 final_answer: str expert_responses: List[ExpertResponse] # 各级专家的原始输出 @app.post("/ask", response_model=SystemResponse) async def ask_question(req: QuestionRequest): """核心问答接口""" # 1. 路由决策 expert_chain = router.route(req.question) decision_path = expert_chain.copy() # 2. 级联调用专家 expert_responses = [] current_input = req.question final_answer = "" for expert_name in expert_chain: if expert_name == "concept_expert": response_text = ConceptExpert.generate_response(current_input) expert_responses.append(ExpertResponse(expert_name=expert_name, response=response_text)) elif expert_name == "solving_expert": response_text = ProblemSolvingExpert.generate_response(current_input) expert_responses.append(ExpertResponse(expert_name=expert_name, response=response_text)) else: # 处理未知专家 response_text = f"未配置的专家：{expert_name}" expert_responses.append(ExpertResponse(expert_name=expert_name, response=response_text)) # 将当前专家的输出作为下一个专家的输入（级联的核心） current_input = response_text # 3. 最终答案合成（此demo简单取最后一位专家的输出） final_answer = expert_responses[-1].response if expert_responses else "系统未能生成回答。" return SystemResponse( question=req.question, decision_path=decision_path, final_answer=final_answer, expert_responses=expert_responses ) if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

运行服务：python main.py。现在你可以通过http://localhost:8000/docs访问交互式API文档并进行测试。

4.5 测试与效果验证

发送一个测试请求：

curl -X POST "http://localhost:8000/ask" \ -H "Content-Type: application/json" \ -d '{"question": "请解释一下什么是分数？", "student_id": "stu_123"}'

系统会路由到“概念专家”，返回一个包含生活化例子的解释。

再发送一个复杂请求：

curl -X POST "http://localhost:8000/ask" \ -H "Content-Type: application/json" \ -d '{"question": "小明有15个苹果，他给了小红三分之一，又给了小刚剩下的二分之一，请问小明还剩几个苹果？为什么这么算？", "student_id": "stu_456"}'

由于问题较长且包含“为什么”和数字，路由器可能触发级联规则["concept_expert", "solving_expert"]。你会看到返回结果中decision_path记录了调用链，expert_responses包含了两位专家的输出，final_answer是解题专家的最终答案。

5. 生产环境进阶考量与避坑指南

将上述Demo推向实际生产环境，会面临一系列严峻挑战。以下是基于经验的关键注意事项和解决方案。

5.1 性能、延迟与成本优化

挑战：级联调用意味着多次模型推理，总延迟是各环节之和，可能无法满足实时交互需求（如课堂互动）。成本也随调用次数线性增长。
解决方案：
- 异步与并行化：如果专家间没有严格的先后依赖，应使用异步请求并行调用。FastAPI支持async/await，结合httpx或aiohttp可以并发请求多个专家服务。
- 缓存无处不在：
  - 路由结果缓存：对相同或相似的问题，直接缓存路由决策，跳过分类模型推理。
  - 专家响应缓存：对通用、确定性的知识问答（如公式、定义），缓存专家输出。可以使用Redis或内存缓存（如cachetools）。
  - 向量语义缓存：更进一步，使用向量数据库（如Milvus, Pinecone）存储问题和答案的嵌入向量。新问题时，先进行语义相似度搜索，如果找到高度相似的缓存，直接返回答案，完全绕过模型调用。
- 模型蒸馏与小型化：对于响应速度要求极高的场景，考虑将大型专家模型的知识蒸馏到更小的模型（如TinyLlama, Phi-3-mini）中，并在本地部署，消除网络延迟。
- 预算与限流：为每个用户或每个会话设置模型调用预算和频率限制，防止滥用。

5.2 可靠性、容错与降级策略

挑战：任何一个专家服务或路由服务宕机，都会导致整个系统失败。云端API可能不稳定。
解决方案：
- 服务健康检查与熔断：在调用任何外部服务（专家模型API）前，检查其健康状态。使用熔断器模式（如pybreaker），当某个专家失败率过高时，暂时切断对其的调用，避免雪崩。
- 优雅降级：当首选专家失败时，应有备用方案。例如，解题专家失败，可以降级到概念专家，并返回“我现在可以帮你理解这个问题涉及的知识点，但详细步骤计算暂时无法提供”。或者，直接返回一个预先准备好的、常见的答案模板。
- 重试机制：对于暂时的网络错误或模型过载，实现带指数退避的自动重试。
- 超时控制：为每个模型调用设置严格的超时时间（如5秒），超时后立即放弃，触发降级逻辑。

5.3 回答质量评估与持续迭代

挑战：如何确保系统生成的回答质量始终在线？如何发现并修复不好的回答？
解决方案：
- 构建评估管道：建立一个离线评估系统，定期用一批标注好的测试题（涵盖各种类型、难度）去跑你的系统，自动评估答案的准确性、相关性和安全性。评估指标可以包括：
  - 事实准确性：与标准答案对比（对于有标准答案的题）。
  - 相关性：答案是否切题。
  - 安全性/合规性：是否包含不当内容。
  - 人工评估：定期抽样，由专业教师进行人工评分，这是黄金标准。
- 收集反馈闭环：在产品界面提供“有帮助/没帮助”或“纠错”按钮。将用户反馈与对应的问题、路由路径、专家输出关联起来，形成数据闭环，用于优化路由决策和专家模型。
- A/B测试路由策略：当你想优化路由规则或升级分类模型时，不要全量上线。通过A/B测试，对比新旧策略在关键指标（如用户满意度、问题解决率）上的差异。

5.4 安全与内容过滤

挑战：学生可能提出无关问题甚至恶意问题。模型也可能生成不合适的内容。
解决方案：
- 输入过滤与拦截：在预处理模块，集成一个轻量级的内容安全分类器，识别并直接拒绝明显违规、无关或恶意的提问。
- 输出过滤：在响应合成模块，必须对最终答案进行内容安全扫描。可以使用专门的 moderation API（如OpenAI Moderation）或本地过滤模型。
- 知识边界声明：让系统学会说“我不知道”。在专家提示词中明确其知识范围（如“你只回答小学数学相关问题”），对于超出范围的问题，应统一返回“这个问题超出了我的知识范围，建议你请教老师或查阅教材”。
- 审计日志：记录所有的问题、回答、路由决策和学生ID，便于事后审计和追溯。

构建Pangu-ACE这样的系统，是一个从简单规则出发，不断迭代、增加复杂性和智能性的过程。它没有一劳永逸的终点，核心在于建立起一个能够持续从数据中学习、从反馈中改进的闭环。从最简单的两个专家和几条规则开始，跑通整个流程，再逐步引入更精细的分类模型、更丰富的专家类型、更智能的路由策略，最终演化成一个真正能“因材施教”的AI教育伙伴。在这个过程中，对教育场景的深度理解，往往比单纯追求模型参数大小更为重要。