去年我接手一个在线学习平台的功能重构时遇到一个特别折磨人的问题用户明明说的是“帮我规划一条学习路径”系统返回的却永远是“你看过的那类内容的延续”。推荐结果本身没有错但它不理解你现在学到哪个阶段了也不理解你下一步最该补什么。抱着解决这个问题的念头我动手做了一个智能学习路径规划 AI Agent用 LLM 辅助个性化学习把“推荐内容”升级成了“规划过程”。这篇文章就是这次实践的全过程记录包含设计思路、关键实现、踩过的坑和实测数据适合想自己搭学习路径规划系统的开发者、产品经理以及所有在研究 LLM Agent 落地方案的朋友。1. 传统学习路径规划的瓶颈为什么规则和推荐算法都不够1.1 静态课程表的问题很多学习平台到今天还在用“从入门到进阶”的静态课程表也就是管理员事先排好一条固定路线所有用户都按这条路线走。这种做法不是没有价值但它默认所有人的基础、目标、可用时间都一样这个前提本身就不成立。举个例子一个想转行做数据分析的平面设计师和一个已经写了三年后端、想学 Python 做自动化脚本的程序员在“学 Python”这件事上需要的东西完全不同。前者要从变量、数据类型开始后者可以直接跳到 requests 库和异常处理。静态课程表给不了这种区分因为它的设计单位是“内容”而不是“人”。我在一开始调研时也想过能不能做一套“分支课程表”根据用户填写的水平测试结果决定他进入哪条分支。但很快发现分支一多就失控了。用户不只会问“我要学 Python”还会问“我三个月后要能独立完成一份电商数据分析报告”“我想从零开始学机器学习但我数学基础一般”。这种开放式目标几乎不可能用有限的静态分支覆盖全。1.2 协同过滤只解决了“同类”没解决“过程”既然静态路线不行那用推荐算法呢我最初在平台上跑过协同过滤效果表面上看不错用户看完“Pandas 入门”系统能推荐“Pandas 进阶”或“数据清洗实战”点击率确实有提升。但点击率高不代表学习路径合理。协同过滤的本质是“和你相似的人还看了什么”它擅长发现“下一个内容”却不擅长规划“三个月以内的完整进阶过程”。更关键的是它没有目标概念。用户说“我想学会用数据分析支撑业务决策”推荐系统根本不知道这个目标意味着哪些知识点、需要什么前置条件、什么顺序才符合认知规律。这也是个性化学习最常见的一个误区把“个性化”等同于“推荐得准”。实际上个性化学习是个序列决策问题核心是“下一步做什么”而不是“相似的人喜欢什么”。推荐算法负责“同类发现”路径规划负责“过程设计”两者要解决的问题完全不同。1.3 个性化学习真正需要的是“规划能力”那如果换成真人老师来规划呢真人老师确实能做到他先问你为什么学、现在什么水平、每周能投入多少时间再结合他对课程体系的了解给你排一条路线过程中还会根据你的反馈调整。这是最理想的状态但成本高得吓人没法规模化。所以我的判断是要规模化地实现个性化路径规划必须同时具备三个能力——理解用户开放式目标的能力、掌握课程知识结构和前置关系的能力、根据反馈动态调整计划的能力。这正是 LLM 系 AI Agent 的用武之地。LLM 擅长的是从自然语言中理解意图、把知识拆成步骤、生成带解释的路径但它并不天然了解你平台里有什么课、每门课的时长和前置要求是什么也容易一本正经地胡编。所以我的结论从一开始就很明确LLM 必须是 Agent 的核心大脑但绝不能让它独自拍板必须给它配上课程库、校验规则和反馈循环这些外部器官。2. Agent 化设计把路径规划拆成可执行的工作流2.1 模块划分目标解析、用户状态、路径生成、反馈循环我第一个版本犯过一个典型错误就是把所有逻辑塞到一个大 Prompt 里让 LLM 一口气输出“用户分析 学习路径 课程推荐 时间安排”。结果输出经常前后矛盾比如路径里第二周要学的东西前置知识到第五周才出现。后来我把整个系统拆成了四个模块才彻底解决这个问题。这四个模块分别是目标解析模块、用户状态模块、路径生成模块、反馈循环模块。目标解析模块负责把用户那句口语化的请求解析成结构化目标。比如“我想学会数据分析”会被拆成“掌握数据清洗、可视化、基础统计分析、业务报告撰写”等若干学习主题同时提取时间约束三个月、用途约束业务决策、基础水平有 Excel 经验无编程基础。用户状态模块负责维护用户的动态画像包括已学内容、练习正确率、最近学习时长、卡壳的知识点。它不是一次性问卷而是每次学习后都会更新的持续状态。路径生成模块是核心它接收目标和状态输出一份“按周划分的学习路径”。但这里的“生成”不是让 LLM 直接给最终答案而是先让 LLM 生成候选路径再交给校验模块检查。反馈循环模块负责动态调整。用户学完一周后如果某个知识点掌握度只有 40%或者用户觉得进度太快这个模块就会触发一次局部路径修正而不是推翻重来。2.2 LLM 在 Agent 中的角色顾问而不是审批员想清楚 LLM 在系统里的角色比选任何技术栈都重要。我的比喻是LLM 是一位经验丰富但偶尔会记错课程名的顾问它负责出方案而课程库、校验规则、评测函数是审批员负责否决不靠谱的方案。在第一个版本里我让 LLM 扮演“全知全能的学习规划大师”结果它自信地列出了几本真实存在但根本没被平台收录的书籍还编了两门不存在的课程名。这就是典型的“幻觉”。问题不在 LLM 本身而在于我给了它太大的自由裁量权。所以第二版我做了两个重要限制。第一课程和资源必须从平台课程库中选LLM 只能引用我提供给它的课程 ID不能自己发明标题。第二路径生成后必须经过规则引擎校验包括前置关系、时间估算、知识点重复度等。如果校验不通过系统会把错误信息反馈给 LLM让它重新生成。这个“先生成、再校验、错了重来”的循环才是 Agent 比单纯 Prompt 调用更稳定的关键。2.3 一个典型规划请求的完整流转说了这么多模块不如走一遍真实请求。假设用户输入“我零基础想三个月后能独立完成电商用户数据分析。”整个 Agent 是这样流转的目标解析模块提取结构化信息零基础、三个月、目标为电商用户数据分析拆解出核心知识点SQL 基础查询、数据清洗、用户行为指标、漏斗分析、可视化、报告撰写。用户状态模块返回画像无编程经验每周可投入 8 小时偏好视频课程。路径生成模块读取课程库目录和前置关系让 LLM 生成一份 12 周的候选路径。校验模块检查每门课是否存在、每周课程是否满足前置依赖、总时长是否超过用户预算。校验通过后路径保存为一份 JSON 计划同时生成一个用户友好的 Markdown 版本。用户每天完成学习后系统上报学习行为反馈循环模块更新用户状态。每周结束如果状态与预期偏差过大触发局部修正生成下一周的调整方案。这样的好处是职责单一、可测试。目标解析错了就单独修目标解析校验规则写错了就单独修校验逻辑不会出现“改一个 Prompt 导致另一个功能崩掉”的情况。3. 核心实现从 Prompt 构想到路径生成3.1 构建用户画像与学习上下文路径生成的第一步是把用户状态模块的数据整理成一个结构化的上下文快照。我最终用的是 JSON 格式因为它方便 LLM 读取也方便后续程序解析。下面是我实际使用的简化版本{ user_profile: { background: 零基础有电商运营经验熟悉 Excel, weekly_hours: 8, learning_style: [video, practice], goal_deadline: 12 周 }, current_state: { completed_courses: [], mastery: { sql_basic: untested, data_cleaning: untested, business_metrics: beginner }, recent_performance: [] }, target: { description: 三个月后独立完成电商用户数据分析, required_skills: [sql_query, data_cleaning, user_behavior_metric, funnel_analysis, visualization, report_writing] } }这个快照的意义在于它把用户当前状态和目标明确地写出来LLM 不用自己去猜。实战中我发现画像字段太杂反而干扰生成效果。比如把用户注册时间、设备类型、是否购买会员都放进去LLM 会关注一些无关信息导致路径偏离目标。我只保留和学习决策强相关的字段其他一律不进 Prompt。3.2 路径生成 Prompt 的结构设计Prompt 写得好不好直接决定路径质量下限。我把路径生成 Prompt 固定为五个部分系统角色说明、用户上下文快照、目标与约束、生成要求、输出格式。下面是一个脱敏版本你是一名资深学习路径规划顾问。请根据用户当前状态、目标、时间预算和平台课程目录生成一份从当前周开始的完整学习路径。 用户上下文快照 {user_profile_json} 生成要求 1. 路径按周划分周次从 1 到 N必须在目标期限内完成。 2. 每周必须包含学习主题、推荐课程或资源只能使用提供的课程目录中的 ID、预期学习时长、每周练习任务。 3. 必须满足课程前置关系后一周不能出现依赖未来课程的练习。 4. 每周学习总时长不超过用户 weekly_hours 的 1.2 倍。 5. 如果用户存在已完成内容跳过相关知识点不要重复安排。 输出格式严格 JSON { overall_goal: ..., estimated_weeks: 12, milestones: [{week: 1, checkpoint: ...}], steps: [ { week: 1, topic: ..., resource_ids: [...], hours: 8, practice: ..., prerequisites_satisfied: true } ] }这个 Prompt 我迭代了很多次才稳定。核心经验是两条第一必须明确告诉 LLM“只能使用提供的课程目录中的资源”这句话能大幅减少幻觉第二输出格式定义得越严格解析代码越好写后续校验越好做。别指望 LLM 能自己理解“差不多这个意思”格式就是契约。3.3 让结果稳定结构化输出与工具校验有了 Prompt还需要处理 LLM 输出不稳定的问题。我第一周上线时JSON 解析失败率高得离谱LLM 偶尔会在 JSON 前后加一段“以下是您的规划”偶尔会用单引号、注释甚至因为超长直接截断。这些问题靠解析器硬扛是扛不住的必须从生成侧和校验侧同时解决。生成侧我用了函数调用方式让模型输出符合预设 schema 的参数而不是自由文本。如果用的是普通文本生成就在 Prompt 里追加一句“不要输出任何解释性文字只输出 JSON”。即使这样我还是在解析层做了容错先按代码块提取再剥离首尾非 JSON 字符最后用 JSON 解析器解析失败则带着错误信息重试一次。校验侧是系统稳定性的真正防线。我写了一个校验函数对生成的每一步检查三件事def validate_plan(plan, course_catalog, weekly_hours): errors [] for step in plan[steps]: if not step[resource_ids]: errors.append(f第{step[week]}周缺少资源) for rid in step[resource_ids]: if rid not in course_catalog: errors.append(f第{step[week]}周引用不存在资源: {rid}) if step[hours] weekly_hours * 1.2: errors.append(f第{step[week]}周时长超预算) # 检查前置依赖 completed set() for step in plan[steps]: for req in step.get(prerequisites, []): if req not in completed: errors.append(f第{step[week]}周前置依赖未满足: {req}) completed.update(step[resource_ids]) return errors这段代码价值极大因为只要校验通过路径大概率是可行的。即使 LLM 抽风生成了不合理内容校验层也能把它拦下来重新生成。我在实际运行中甚至故意用不合适的 Prompt 测试过发现单靠校验层就能把很多错误挡住这也说明分层设计的重要性。3.4 动态调整基于学习反馈的路径修正路径生成了但用户不可能完全按计划走。我遇到最多的反馈是“这周内容太多”“某个概念没听懂”“我想提前学可视化”。如果每次都重新生成全部路径不仅成本高而且用户看到前后两个版本计划不一致会产生困惑。所以反馈循环模块只做“局部修正”。具体流程是先把原始计划和用户一周的学习行为组装成调整 Prompt再让 LLM 只修改需要改动的周次其余保持不变。我在 Prompt 里明确要求“保持原始计划中未涉及的周次完全不变”。调整 Prompt 的核心结构大概是这是原计划{original_plan_json} 这是本周学习反馈{weekly_feedback_json} 用户的调整要求{user_request} 请输出一份修改后的计划。只改动受影响的周次其他周次保持原样。这个做法的好处是用户看到的变化是可控的、可解释的。实测中局部修正的路径接受率明显更高可能是因为它没有推翻用户已经付出的努力。缺陷是如果用户目标发生了根本变化比如从“学数据分析”改成“学前端”那就必须走完整重新规划流程不能硬套局部修正。4. 两个绕不开的坑幻觉问题和成本控制4.1 幻觉导致路径知识点错位幻觉不是 LLM 能不能被消除的问题而是系统能不能容忍的问题。在学习路径场景里最危险的幻觉不是编造书名而是“看似合理但顺序错误的路径”。比如让模型生成“先学线性回归再学数据清洗”这听起来好像没问题但实际业务里数据清洗明明是前置步骤。我处理幻觉的方式有三个层级。第一层是资源白名单LLM 只能从课程目录中选择资源不能自己创造资源标题。第二层是关系校验课程间的先后关系由带约束的课程库决定而不是靠 LLM 记忆校验函数一旦发现顺序逆了直接打回重生成。第三层是目标拆解约束目标到知识点的映射我用了一个事先维护的“目标到技能”模板库作为参考LLM 可以在模板基础上微调但不能完全自由发挥。这样三层下来幻觉对最终路径的影响已经小到可以接受。不要幻想哪一天模型不幻觉了而是要把系统设计成“允许模型犯错但犯错了也不会搞坏结果”。4.2 结构化输出解析的脆弱性第二个让我掉头发的问题是结构化输出。即使 Prompt 里写了“只输出 JSON”模型在实际返回时依然会偶尔带上 markdown 代码块标记偶尔在 JSON 后面补一段“小提示”。更麻烦的是当路径很长比如 12 周内容全写在一个 JSON 里模型输出可能超长被截断导致最后半个括号丢失。我的最终方案分三层第一优先用模型自带的函数调用能力让模型输出一个结构化的参数对象这样能避开大部分文本包装问题第二解析层先剥离 json 标记再从最外层括号截取 JSON 片段第三如果解析失败把错误信息拼进 Prompt 让模型重新生成一次。整套方案跑下来解析成功率从最初的 70% 出头提到了接近 95%。另外一个小建议不要一次性让人工智能生成 12 周的完整路径输出太长既容易截断也容易前后不一致。我后来改成先生成“里程碑计划”也就是每 4 周一个阶段目标然后再让模型一次只生成一个阶段的详细路径。这样每个 JSON 都不大出错了重试成本也低。4.3 Token 成本与延迟缓存、压缩、分级调用把路径规划做成 Agent 之后成本问题很快就浮出水面了。一次全流程规划包括目标解析、路径生成、校验、修正可能要消耗上万个 Token如果用户反复修改目标费用就更可观。另外每次调用耗时可能达到十几秒用户早就没耐心了。我做了几个有效的降本措施。第一是缓存相同或高度相似的目标和用户状态直接复用之前生成的路径模板不再调用模型。第二是分级调用目标解析这种简单任务用低档位小模型路径生成这种核心任务用高档位大模型反馈总结用中档模型。不同任务对模型能力要求不一样没有必要一把梭都用最强的。还有一个思路是压缩上下文。用户画像不需要把全部学习记录塞进去只传最近两周的行为摘要和整体掌握度汇总。这样既省 Token也能减少无关信息对路径生成的干扰。我实测这个改动后单次规划成本下降了约 60%而路径满意度没有明显变化。延迟方面把长路径切成阶段生成之后单次接口调用时间也从十几秒降到了三四秒体感好很多。5. 实测结果与调优经验5.1 评估方法路径合理性和完成率怎么测做完系统之后最难的其实是评估它到底好不好。推荐系统可以看点击率路径规划看什么我最后定了一组混合指标。第一类是离线专家评审。我请了几位在在线教育领域做课程设计的同事让他们对随机抽取的路径从目标匹配度、顺序合理性、资源可获得性三个维度打分。每次迭代后用固定测试集跑一遍确保改动是正向的。第二类是用户行为指标。最核心的是路径完成率也就是用户走到计划终点才算完成中途退出则不计。另一个是阶段测验通过率它反映路径难度是否合理太高说明步子迈太大太低说明安排太水。第三类是过程指标。包括用户每周是否按计划学习、调整请求的频次、对调整后计划的接受率。这些指标能帮我判断路径是不是真的贴合成用户刚需。评估这件事必须从一开始就建立否则后面优化方向会很争吵。5.2 一组对比规则基线 vs LLM Agent在有限样本下我做了一个小规模对比拿旧的静态规则路径和新的 LLM Agent 路径各跑了两个月。测试用户被随机分成两组但样本量不大所以结论只能算是方向性参考不能当严谨实验结果。指标静态规则基线LLM Agent路径完成率38%51%阶段测验通过率61%68%用户主动反馈“计划不合理”的比例12%4%专家路径合理度评分5分制3.24.3从数据看LLM Agent 在完成率上提升明显专家评分更是拉开了差距。不过我也发现一个有意思的现象Agent 生成的路径在“资源可获得性”上偶尔会丢分因为校验规则虽然检查了课程存在性和前置关系但没有检查资源是否已经下架。后来我在校验函数里加入了“有效状态”字段检查这个问题才彻底解决。另一个让我警惕的指标是Agent 路径的平均每周时长比基线长了 15%这说明 LLM 倾向于把路径排得比较满。后来我在 Prompt 里增加了一条“优先考虑可持续性不要安排超过预算的学习量”并配合校验层卡住时长上限情况才好转。5.3 调优经验与后续迭代方向调优过程中我最有感触的一点是Prompt 不要频繁改。你可能会因为一条测试样本不满意就去改 Prompt结果另外三条样本变差了。后来我建了一个几十条样本的回归测试集每次改 Prompt 前先跑一遍测试集分数没有下降才允许上线。这套流程看起来笨但能避免很多“修好一个、弄坏三个”的情况。失败的样本也很有价值。我会把每周失败的路径收集起来分析是目标解析错了、资源引用错了还是顺序错了然后针对高频失败类型补充规则或调整 Prompt。有个意外收获是把失败样本作为 few-shot 示例写进 Prompt 后路径质量提升比直接修改 Prompt 描述更明显。后续我准备做三件事。第一把学习反馈做得更细结合练习记录和答疑记录来自动判断掌握度减少对用户主观反馈的依赖。第二支持跨领域路径迁移比如用户学完 Python 数据分析后想转机器学习Agent 可以直接关联已有技能生成新路径。第三引入多 Agent 协作规划 Agent 负责出路线测评 Agent 负责出测评答疑 Agent 负责解释模糊知识点三个角色通过共享用户状态协同工作。如果让我重新做一次我会从第一天就把反馈闭环的数据结构设计好而不是先做路径生成再做反馈。因为学习路径规划的核心价值不在第一次生成的计划有多完美而在于它能不能在用户偏离计划之后快速、准确地把他拉回一条更适合他的路线上。这个认知是我在这次实践里最大的收获。