1. 项目定位为什么偏要用 Agent 来做个性化学习路径推荐做教育后端的人应该都有同感传统的“用户画像 协同过滤 内容推荐”方案在真实学习场景里经常失灵。我接手这个项目时需求方一开始提的也是“做一个类似电商的推荐系统”给每个用户推荐课程和资料。但聊到最后我们发现学习这件事和买东西完全不是一回事。买东西是单点决策用户看到喜欢的东西下单就结束了。学习是连续过程用户需要的不是一个“结果推荐”而是一条“路径”先学什么、再学什么、用什么方式学、学到什么程度可以进入下一阶段。这里面有先修依赖、有认知难度阶梯、有个人的薄弱点校准还有随时可能发生的状态变化——今天状态好能推进度明天某个点卡住了就得停下来补。这些都是静态推荐算法很难建模的。这个项目想做的就是用 Agent 构建一套个性化学习路径推荐系统让系统像一个懂教学又有耐心的私人助教能主动问、能诊断、能规划、能调整。Agent 在这里不是简单的对话机器人而是一整套以“目标拆解 - 水平诊断 - 路径生成 - 动态调整”为主线的智能学习编排体系。这套系统适合哪类人参考如果你正在做在线教育产品、企业培训平台、知识付费App或者单纯想研究怎么把 Agent 从“聊天玩具”变成一个能真正解决业务问题的工具这篇内容应该能给你一些可以直接用的思路。我会把整个项目的架构设计、Agent 分工、关键模块的实操要点、核心代码落地、还有我们在测试阶段踩过的坑都摊开来讲。先给一个结论用 Agent 做学习路径推荐真正的难点不在于模型能力而在于你怎么把“教学逻辑”显式地写进 Agent 的工作流里。模型可以帮你理解用户的自然语言反馈但“先修关系”“难度阶梯”“掌握判定标准”这些东西必须靠结构化的领域知识来约束。想明白这一点后面的设计才不会跑偏。这个项目我们前前后后调了三版架构最终稳定运行的方案就是把“领域知识图谱”和“Agent 规划器”绑定在一起让 Agent 在受限的知识结构上做动态决策而不是让它凭空发挥。2. 系统架构与 Agent 分工设计2.1 从单体推荐器到多 Agent 协作的原因第一版原型我们试过用一个“全能 Agent”完成所有事情接收用户输入、诊断水平、生成路径、回答问题。结果很热闹但基本不可用。因为诊断和规划是两种不同的目标诊断要的是严谨和收敛必须基于证据得出用户当前能力的判断规划要的是策略和平衡需要考虑目标难度、时间资源、兴趣偏好。把这两种逻辑塞在同一个 Agent 的上下文里模型一会儿想当考官一会儿想当导师输出风格漂移非常严重。更麻烦的是一旦路径需要调整你很难定位是“诊断错了”还是“规划错了”。所以第二版开始我们彻底转向了多 Agent 协作架构。每个 Agent 只干一件事通过结构化数据传递信息而不是靠对话来回传话。整个系统拆成了四个核心 Agent各自职责如下用户画像 Agent负责首次访谈和持续画像更新。它收集用户的当前身份学生/在职/转行、学习目标、可用时间、兴趣偏好最终输出结构化的用户画像 JSON。水平诊断 Agent负责评估用户的现有知识水平。它会主动生成定级测试题分析作答过程和结果输出“知识点-掌握度”映射表。路径规划 Agent负责生成学习路径。它基于知识图谱和用户画像规划出进阶式的学习节点序列并为每个节点指定学习资源范围、练习强度、达标标准。学习督导 Agent负责路径执行期的动态陪伴。它追踪用户的学习记录定期做简短复盘发现异常例如连续做错、进度停滞时触发路径调整流程。这四个 Agent 不是说四个模型实例它们共用一个模型底座只是使用不同的系统提示词和工作流编排。这样既省资源又能各司其职。2.2 知识图谱与状态管理层Agent 再聪明也不能裸奔着规划路径。我们花了大概两周时间把课程内容整理成了一张可计算的知识图谱这是整个系统的基石。知识图谱的节点是“知识点”而不是课程或章节。每个知识点带有元数据唯一标识 ID所属学科与模块难度等级1 到 5预计学习时长掌握判定方式通过正确率阈值或实操任务完成度先修知识点列表关联学习资料 ID 列表图谱里的边代表先修关系比如“排列组合”是“古典概率”的先修。路径规划 Agent 在生成路径时必须保证输出序列满足拓扑序任何一个知识点在出现时它的全部先修节点已经出现在用户的学习记录里。这个约束是写死在规划逻辑里的不依赖模型自觉。状态管理层则是用户的动态记忆库。每次学习记录、诊断结果、路径调整都会写回这里。它分两层短期会话状态只保留当前交互上下文长期用户档案保存完整的历史画像、学习路径版本、掌握度变化曲线。Agent 每次做决策前会把状态管理层拉取出来作为上下文的一部分。这套设计的核心思考是把“记忆”和“推理”分离。模型只负责理解当前输入和生成规划建议记忆的存储、更新、一致性由工程层保证。不用让模型去翻历史记录字段做筛选它只需要读我们整理好的摘要快照就行。做生产级 Agent这条经验一定要记住。3. 核心模块的实操要点3.1 用户画像 Agent别让用户填长长的表单传统做法是让用户注册时填一堆表单学习背景、目标、偏好……但真实用户的填写意愿极低填出来的信息也经常失真。我们让用户画像 Agent 用聊天的形式完成这个采集过程通常 5-8 轮对话画像就出来了。关键点在于画像 Schema 要设计得足够细但又不能太僵。我们最终沉淀的字段大概包括学习身份、目标类型、目标知识点范围、每周可投入时长、学习节奏偏好、内容形式偏好视频/图文/练习、动机水平、过往经历关键词。其中“节奏偏好”和“动机水平”是后续规划路径时的重要控制参数。实操中要注意一个细节不要一次性把所有问题抛给用户而要像真正的助教一样根据回答上下文追问。比如用户说“我是做数据分析想学机器学习”Agent 会追问“目前用过哪些建模工具”这样的回答比表单里的“技术水平新手/进阶/专家”要可靠得多。Prompt 层面的做法是让 Agent 从对话记录中提取画像 JSON遵循“缺省优先”原则——不确定的字段不猜标记为未采集宁可后续补采也不要给路径规划器传递错误的画像数据。3.2 水平诊断 Agent用贝叶斯式思路逼近真实水平诊断模块是最容易做重也最容易做水的地方。我们的思路是先根据用户画像预估一个初始水平区间然后在这个区间附近动态出题根据答题结果不断收敛。具体实现上诊断 Agent 维护一个“知识点掌握度估计表”每个知识点对应一个 0 到 1 的置信值。每出一道题Agent 会先预测用户答对的概率这个预测由知识点难度和当前掌握度估计综合得出。用户作答后根据实际结果更新掌握度估计。这里的计算逻辑不复杂你可以把它理解成一个简化版的贝叶斯更新预测答对概率 sigmoid(当前掌握度 - 知识点难度系数)。如果用户答对了掌握度上调答错了下调。调整幅度由题目区分度决定。跑 8-10 题之后我们就认为估计已经收敛到了可以规划路径的精度。这个模块还做了一个很关键的设计用户答题过程中Agent 会记录用户的作答耗时、犹豫点、求助行为这些过程性数据最终会合并到画像里用于后续调整内容形式偏好。比如有人看到公式就发懵但很擅长做类比推理Agent 后续会给他的学习材料里多配一些类比讲解。诊断结果必须可解释。每次诊断结束Agent 要生成一段用户能看懂的反馈“你在微积分基础部分掌握度较高但概率分布部分还有明显短板建议先补充相关先修知识。”我们把这句解释放在路径生成之前用户看完之后才进入下一步。这在产品体验上非常重要用户信任感完全不一样。3.3 路径规划 Agent在约束里寻找最优路径路径规划是整个系统技术含量最高的部分。它接收三层输入知识图谱子图与用户目标相关的部分、用户掌握度估计表、用户画像偏好参数。输出是一段有序的学习节点序列。实现方式不是让模型自由生成而是“模型生成 约束校验 自动修正”三步走。第一步模型基于当前上下文生成候选路径每个节点附带一个推荐理由。这里的 Prompt 会明确要求模型按“热身节点 - 核心节点 - 挑战节点”的节奏组织并且对每个节点标注预计学习时长。第二步校验器检查候选路径是否合法。校验规则有三条拓扑序校验所有先修关系是否满足不满足就调整顺序。难度梯度校验相邻节点难度差是否合理避免从 1 级直接跳到 5 级。时间预算校验路径总时长是否在用户周时长预算的合理倍数范围内太紧或太松都要修正。第三步修正逻辑基于预设规则自动调整比如把难度跳跃过大的节点中间插入一个过渡节点或者把总时长过长的路径拆分阶段。我在这个模块上最大的心得是不要迷信模型直接输出“最优路径”而是把模型当成生成器把规则引擎当成裁判。模型发挥创造性规则做底线。这个组合跑起来之后路径质量的稳定性提升非常明显。完全让模型自由规划前期测试中大约有 30% 的路径会出现至少一处明显问题加了规则校验之后这个比例降到了 5% 以下。3.4 学习督导 Agent动态调整才是 Agent 的价值所在路径生成出来只是开始。真实学习过程中用户一定会偏离路径督导 Agent 的价值就在这里。它每一到两天做一次轻量沟通频率由用户的周投入时长决定。沟通内容不是僵化的“学习了吗”而是基于当前节点状态的有意义询问。比如用户上次停在“线性回归假设检验”这个节点督导 Agent 会问“你在检验残留假设时对多重共线性这个点感觉怎么样”用户回答“分不清”之后督导 Agent 会做两个动作触发微评诊断或生成补充学习材料请求。动态调整的逻辑是如果用户在某个节点连续两次测验不达标系统会将当前节点标记为“卡壳”自动插入一个降难度补充节点路径整体顺延如果连续三个节点一次通过且用时低于预期系统会自动提升后续节点的难度档位。这个模块还承担了“防放弃”职能。如果用户连续三天无学习记录督导 Agent 会发一条短消息不是催学习而是问“是不是最近时间紧张要不要我把路径节奏放缓一些”很多用户反馈这个细节是最让他们觉得系统像真人助教的地方。4. 从零实现关键步骤与代码落地4.1 环境与框架选型我们用了一套比较主流的技术栈Python 3.11、一个大模型 API兼容 OpenAI 接口格式、LangGraph 风格的图工作流编排框架、PostgreSQL 存用户档案Redis 做会话缓存。向量数据库存学习资源语义索引。这里不指定具体某个框架因为从架构上说这套模式可以迁移到任何支持条件分支和循环的编排框架上。建议评估 Agent 工作流框架时重点关注三件事是否支持循环回归Agent 决策结果要能回到某个前置节点重新执行、是否支持并行节点、是否支持人工干预如果产品要审阅 Agent 的输出。很多看起来很酷的框架在真实工作流里一跑就会因为缺少循环支持而别别扭扭。4.2 路径规划 Agent 的核心代码骨架下面这段代码是对我们路径规划模块的简化模拟保留了最核心的逻辑骨架。它演示了“生成 - 校验 - 修正”的完整流程。import json from typing import Any, Callable class PathPlanner: def __init__(self, llm_agent: Callable[[str], str], skill_graph: dict, validator, corrector): self.llm_agent llm_agent self.skill_graph skill_graph self.validator validator self.corrector corrector def prepare_context(self, user_profile: dict, mastery: dict[str, float], target_goals: list[str]) - str: 组装给模型的上下文提示 subgraph self.extract_relevant_subgraph(target_goals) profile_summary { learning_hours_per_week: user_profile.get(weekly_hours, 5), content_preference: user_profile.get(content_preference, mixed), pace_preference: user_profile.get(pace, normal) } return json.dumps({ user_profile: profile_summary, knowledge_mastery: mastery, available_nodes: subgraph }, ensure_asciiFalse) def generate_candidate_path(self, context: str, system_prompt: str) - list[dict]: response self.llm_agent(system_prompt \n\n context) try: nodes json.loads(response)[path] except Exception: # 模型输出不是合法 JSON 时走重试逻辑 response self.llm_agent(system_prompt \n\n你上次的输出格式非法请严格按 JSON 格式返回。 context) nodes json.loads(response)[path] return nodes def plan(self, user_profile, mastery, target_goals) - dict: system_prompt 你是学习路径规划助手。请根据用户画像、知识点掌握度和可选知识图谱节点规划一条学习路径。 要求 1. 路径中的每个节点必须是图谱中存在的知识点 ID。 2. 遵守先修关系难度逐步递进。 3. 输出格式为 JSON{path: [{node_id: ..., reason: ..., estimated_hours: 2}, ...]} 4. 总预计时长不能超过用户每周投入时长的八倍。 context self.prepare_context(user_profile, mastery, target_goals) candidate self.generate_candidate_path(context, system_prompt) # 规则校验 修正 validated, errors self.validator.validate(mastery, candidate) if errors: corrected self.corrector.correct(candidate, self.skill_graph, errors) return self.finalize(corrected) return self.finalize(validated) def finalize(self, path): return {status: success, path: path, generated_at: 2024-12-01T10:00:00Z}这段代码的重点是generate_candidate_path里的重试逻辑模型返回的 JSON 偶尔会格式不完整轻量级方案就是提示词里强调“上次输出格式非法请重新生成”成功率很高。如果你了解 Pydantic 之类的结构校验工具也可以用它们做输出解析但我在生产环境里的经验是提示词重试通常比结构解析更省事。4.3 校验器与修正器设计校验器是最值得认真写的部分。它接收候选路径和用户掌握度表输出校验错误列表。class TopoValidator: def __init__(self, skill_graph): self.skill_graph skill_graph # {node_id: {prerequisites: [...], difficulty: 1-5}} def validate(self, mastery, candidate_path): seen set(mastery.keys()) # 已掌握的知识点视为已满足先修 errors [] for position, node in enumerate(candidate_path): node_id node[node_id] prereqs self.skill_graph.get(node_id, {}).get(prerequisites, []) missing [p for p in prereqs if p not in seen] if missing: errors.append({ type: PREREQUISITE_MISSING, node_id: node_id, position: position, missing: missing }) seen.add(node_id) return candidate_path, errors校验逻辑本身不复杂但有一个容易踩的坑已掌握知识点的处理方式。如果用户当前掌握度表里显示某个知识点掌握度高于 0.8那么它在后续路径里不能当作“已完成”节点重复出现但可以作为“先修已满足”的条件存在。我在代码里用seen集合同时融合了这两层信息注意区分mastery键和路径中出现的节点。修正器的逻辑我们采用了一套贪心式的调整策略。比如遇到PREREQUISITE_MISSING错误修正器会在缺失的先修知识点中取出一个最容易的插入到当前位置之前并删除候选路径中与它重复的高难度节点。遇到DIFFICULTY_GAP错误当前节点难度比前一个高于 2 级以上修正器会在图里找一个难度处于两者之间的节点自动补上。很多团队会认为“让模型自己反思改正”就够了但实测下来二次生成仍然有 10% 左右的概率犯同样的错。规则修正器虽然机械但它可靠、稳定、可测试。这是工程中我特别想强调的取舍创新环节给模型保障环节给规则。4.4 用户掌握度更新的简化实现诊断和督导模块最终都会回到一个核心动作更新用户掌握度。我们用一个统一的函数处理。def update_mastery(current_mastery: float, difficulty: float, is_correct: bool, delta: float 0.15) - float: 简化版掌握度更新逻辑 # 题目区分度介于 0.1-0.5 之间难度越接近当前水平区分度越高 predicted 1 / (1 0.5 ** (current_mastery - difficulty)) if is_correct: return min(1.0, current_mastery delta * (1 - predicted)) else: return max(0.0, current_mastery - delta * predicted)这里约等于要让答对的题目在“预测概率高”的时候加分少在“预测概率低”的时候加分多答错相反。这个设计保证用户做简单题对了很多次时掌握度不会疯涨而一旦做出一道难题掌握度提升会很明显。它没什么高深的数学但比简单加减分科学得多。5. 上线后踩过的坑与排查思路5.1 Agent 上下文膨胀导致路径质量下降系统运行一段时间后我们发现在长对话场景下路径规划的准确率明显下降。排查后发现督导 Agent 和规划 Agent 共享了一部分历史会话记录而在连续沟通 20 次之后上下文里的冗余信息已经远超有效信息。模型被大量无关的寒暄和过程记录干扰规划时“看不见”真正的用户状态了。解决办法是引入上下文压缩机制每次对话结束后不是把全量历史传给下一个环节而是由专门的状态摘要更新器把本次对话提炼成一个结构化的“增量档案”。档案只包含三个字段本次覆盖的知识点、掌握度变化结果、用户情绪与节奏信号。这样传给规划 Agent 的上下文永远是一个干净紧凑的当前状态快照而不是一段冗长的聊天记录。5.2 模型幻觉在诊断中的风险有一段时间诊断 Agent 会给用户推荐“后续进阶方向”但推荐内容明显超出了当前知识图谱的覆盖范围。模型甚至编造出了图谱里根本不存在的知识点。这个问题很危险因为学习路径如果指向了错误的知识节点用户会学一个不存在大纲课程。排查后发现根因是系统提示词里没有明确“只能在给定图谱里选择”的约束。我们在所有 Agent 的 Prompt 里统一追加了一句“你只能引用给定的知识图谱节点不得使用图谱之外的任何知识结构信息。”同时在规划 Agent 的代码里加了图谱节点的白名单过滤模型输出任何图谱外节点都直接拦截丢弃。这个教训很值得记住Agent 应用在生产环境里LLM 永远只是一个带推理能力的输入输出组件它的输出必须经过系统层的白名单约束。你可以把它类比为模型是司机规则是红绿灯没有红绿灯的司机再厉害也会出事。5.3 “教学路线正确”但“用户不爱学”的尴尬这是一个产品层面的问题我们差点漏掉。最初版本的路径规划完全以“知识掌握效率”为目标排出来的路径在逻辑上无懈可击但很多用户反馈“学得很闷”。后来我们仔细分析了学习记录发现用户放弃路径的次数和学习材料的形式、节奏高度相关。我们之后在规划器里加入了偏好强化机制对用户画像里标记“视频偏好”强的用户路径节点偏向选择视频讲解为主的知识点对“练习驱动型”用户每个节点后强制安排一个实战任务。这个因素对完成率的提升比我预期得还要大。路径规划不只是知识逻辑也是体验设计。每个节点的呈现方式、节奏长度、即时反馈设计都需要纳入规划模型的考虑范围。5.4 成本控制与响应延迟优化多 Agent 协作的副作用就是模型调用次数成倍增加。每次路径规划四个 Agent 加起来要调用 8-12 次模型接口单次规划成本不低响应时间接近 15 秒。我们对几个环节做了降本优化。第一水平诊断的题目生成改用小模型配合题库模板让题库提供大部分固定题目小模型只负责调整出题参数。第二路径规划只在“首次生成”和“卡壳调整”两个时机触发日常学习推进不重复规划。第三督导沟通尽量用短对话每次只调用一次模型接口。优化之后单用户月度模型成本下降了大约 60%响应时间控制在 5 秒以内。多 Agent 系统一定要在设计阶段就想清楚哪些流程需要重推理、哪些流程可以轻量执行不然后期优化成本会非常高。6. 项目复盘与可复用的经验这个项目从设计到上线前后差不多三个月。最终跑通的时候系统已经能够为每个用户在首次使用后的 10 分钟内生成一份符合拓扑约束、时间预算、难度递进的学习路径并且在后续学习过程中持续动态调整。我们拿了一批测试用户跑了一段时间路径完成率比原先用静态推荐算法的时候提升了明显一个档次用户主动回访率也有了可观测的上升。我复盘整个项目时有几条经验是特别想分享给后来者的。Agent 驱动的推荐系统最大的优势不是“更懂用户”而是“可以解释每一个推荐决策”。我们系统里的每个路径节点都带着推荐理由用户可以点进去看“系统为什么让我先学这个”。这看起来只是一个产品细节但它实际上对用户信任感的建立起到了决定性作用。传统推荐算法给不出这种透明度而 Agent 天然可以做到。第二条经验是“领域约束永远走在模型自由度前面”。你在 Agent 项目里投入的工程质量最终会体现在输出的稳定性上。没有知识图谱、没有规则校验、没有白名单过滤的 Agent 推荐系统在白日梦状态下会给用户推荐出完全离谱的路径。你越是在框架层面限制它的自由度它就越像一个靠谱的助教。第三点Agent 系统一定要单独设计一套观测面板。我们做了两个看板一个展示用户画像状态和路径拓扑一个展示每次模型调用的输入输出摘要。调试 Agent 应用如果只能看日志会非常被动。可视化地看到“当前用户处于哪个节点、Agent 决策依据是什么”排查问题的速度会快一个数量级。后续这个系统的扩展方向我们已经在计划的是多目标学习路径用户同时学两个方向时如何做交叉安排以及消息推送与学习计划的日历集成。如果你也在搭建类似的系统建议一开始就把状态管理层和知识图谱层做扎实一点它们是整个 Agent 系统能够长期稳定运转的地基。
