从课程表到 AI 岗位：我如何用 Elastic Agent Builder 构建 SkillGap Radar

作者林霆恩Elastic Agent Builder Hackathon三等奖项目完整分享在 Elastic Agent Builder Hackathon 中我开发的 SkillGap Radar 获得了三等奖。它想解决的不是一个遥远的问题而是许多大学生都经历过的困惑课程学了不少招聘信息也看了很多但两者之间究竟差在哪里接下来应该补什么往往只能凭感觉判断。SkillGap Radar 的目标是把公开的课程信息和岗位需求整理成可以检索、统计和追溯的证据再借助 Elasticsearch、ES|QL、Kibana 与 Elastic Agent Builder把 “我该学什么” 变成一个有依据、可复查的问题。图项目宣传图一、产品背景为什么 “学了什么” 与 “岗位要什么” 很难对上作为大学生我经常能接触到两类信息。一类来自培养方案、课程表和课程简介它们告诉我们未来几年会学习哪些基础知识另一类来自招聘平台和企业岗位描述它们告诉我们市场正在使用哪些技术。但真正需要做决定时这两类信息往往没有被放在同一张图里。学生可能知道自己学过数据结构、数据库、操作系统和人工智能导论也看到招聘信息频繁出现 Python、模型部署、RAG、Agent、向量检索等关键词。然而“学过一门相关课程”是否等于“具备岗位要求的能力”某个词没有出现在课程名称里是否就表示完全没有基础仅靠肉眼浏览很难得到稳定答案。这个问题在 AI 应用方向尤其明显。技术栈变化快岗位描述中的表达也不统一同一种能力可能被写成不同名称。学生很容易陷入两个极端要么认为课程与就业完全脱节要么看到一个热门词就立刻追逐新工具。两种判断都缺少证据也不利于形成持续的学习路线。因此我希望做的不是一份静态“技能清单”而是一套可以随数据更新、可以回到原文验证、也能解释结论边界的产品原型。二、信息差并不只是 “资料太少”在设计产品前我把信息差拆成了三个更具体的问题。第一是语言不一致。课程体系通常按知识领域组织如程序设计、计算机系统、算法与人工智能岗位则按任务和工具组织如模型推理服务、RAG 流程、Agent 编排和容器部署。两者存在关联却很少使用相同术语。第二是信息碎片化。一条岗位信息只能说明一个团队在某个时间点的需求多看几条又容易被最醒目的关键词影响。缺少统一结构时学生很难知道一个技能究竟是普遍出现还是偶然出现。第三是建议缺少依据。通用大模型可以快速生成“AI 学习路线”但如果它不知道具体课程、岗位样本和统计口径建议往往正确却泛化。用户真正需要的不只是“学 RAG”而是“为什么现在优先学 RAG、现有课程提供了哪些基础、还缺哪一段实践”。SkillGap Radar 因而把产品任务概括为三问岗位需要什么课程已经覆盖什么学生下一步补什么只有这三个问题使用同一套证据学习建议才有可解释性。在这个问题上最直接的做法是做一张人工维护的对照表但它很难随岗位数据更新也无法方便地回到证据原文。另一种做法是把材料全部交给通用大模型总结生成速度很快却不容易保证每一次统计口径一致。SkillGap Radar 选择了中间路径让结构化数据和查询负责稳定性让 Agent 负责交互与解释。这也形成了产品的三个设计标准。第一任何关键数字都应该可以重新查询第二任何覆盖判断都应该能看到课程或岗位证据第三系统给出的建议必须说明样本边界。对我而言这三个标准比“回答听起来有多聪明”更重要。如果把它看成一个产品闭环输入不是一份简历而是课程证据、岗位证据与统一技能词典中间过程不是一次自由生成而是检索、聚合、比较和解释输出也不是单一分数而是需求排名、覆盖状态与学习优先级。这样的闭环既适合当前原型也为以后扩展更多专业、城市和岗位方向留下了清晰接口。三、目标用户与三个典型使用时刻SkillGap Radar 首先面向计算机相关专业、准备进入 AI 应用开发方向的学生。它并不替代老师、培养方案或招聘平台而是在这些信息之间增加一层 “比较与解释”。第一个使用时刻是选课前。学生可以先查看高频岗位技能再判断哪些选修课能够强化对应基础。第二个使用时刻是准备项目时。系统可以帮助学生把“想做一个 AI 项目”进一步拆成检索、模型调用、评估、部署等能力。第三个使用时刻是投递前。学生可以根据目标岗位重新检查技能覆盖优先补齐高需求但课程中只部分覆盖的内容。图大学生决策旅程这三个场景对应的不是三套产品而是同一条决策链先理解需求再识别已有基础最后安排下一步行动。四、产品边界它不评价什么也不承诺什么一个面向教育与求职的产品很容易因为表述过度而误导用户。因此我从一开始就给 SkillGap Radar 设置了边界。它不评价学校或培养方案的好坏。课程材料只能证明公开文本中是否出现相关内容不能代表真实课堂效果。它不预测录用概率也不承诺学习某项技能就能获得工作。它更不会把 20 条岗位证据写成整个北京就业市场的完整画像。产品使用“当前公开培养方案中未发现明确覆盖”而不是 “学校没教”使用 “当前 20 条岗位样本显示”而不是 “所有岗位都要求”。这些限定语看似保守却是产品可信度的一部分。五、把课程语言与岗位语言变成共同的比较尺度如果直接把课程名称和岗位描述交给大模型结果会随提示词和上下文变化。为了让结论可以复查我先定义了一套统一的数据结构。课程记录保存课程名称、类别、描述和技能标签岗位记录保存公开证据摘录、城市、岗位标题、招聘类型和技能标签技能字典把 “Large Language Model”“ 大语言模型” “LLM” 等表达归一到同一概念覆盖记录则连接技能、课程证据与岗位证据。最终共有 37 条课程记录、20 条北京 AI 应用岗位公开证据摘录以及 18 个统一技能共 75 个文档写入 Elasticsearch 索引skillgap-radar-v1。下面是一个简化的数据结构示例。它不包含公司、姓名或联系方式只展示记录如何支持后续查询。{document_type: coverage,skill: RAG,coverage_status: partial,job_count: 10,job_ratio: 0.50,course_evidence: [数据库原理与应用, 非关系型数据库, 智能文本处理技术],job_evidence_ids: [job-001, job-003, job-004],rationale: 数据库和文本处理课程提供检索与数据基础但当前公开培养方案中未发现RAG的明确课程证据}图证据记录模型六、系统如何工作证据入库、可复现查询统计、智能解释整个流程可以概括为三层。第一层是数据层。我把课程、岗位和覆盖关系整理为结构化文档并保留来源字段让每个标签都能回到原始证据。第二层是分析层使用 ES|QL 计算技能出现频次、岗位占比和课程覆盖状态。第三层是交互层Elastic Agent Builder 根据用户问题调用数据并把统计结果翻译成更容易理解的学习建议Kibana 则负责把核心结果做成可视化图表。图系统架构这种分层有一个直接好处数字不由大模型“猜”而由查询产生大模型主要承担理解问题、组织证据和解释结果的工作。这样既利用了 Agent 的自然语言能力也保留了分析的可复现性。我选择 Elasticsearch不只是因为它能保存文本还因为课程、岗位和技能标签可以在同一个索引中被检索与聚合选择 ES|QL是因为统计逻辑能够以短查询清晰表达选择 Kibana是为了让真实查询结果可视化选择 Agent Builder则是为了把这些能力包装成自然语言入口。七、Query A用 ES|QL 把岗位需求算清楚下面是项目中用于统计技能需求 Top 10 的核心查询。它先筛选北京岗位文档再展开多值技能标签按技能统计不同岗位数量最后计算在 20 条样本中的占比。FROM skillgap-radar-v1| WHERE document_type job AND city 北京| MV_EXPAND skill_tags| STATS job_count COUNT_DISTINCT(job_id) BY skill skill_tags| EVAL job_ratio ROUND(job_count / 20.0, 2)| SORT job_count DESC, skill ASC| LIMIT 10这段查询很短却承担了项目的“统计事实层”。在最终校验样本中LLM 出现在 20/20 条岗位证据中Python 与模型部署均为 18/20深度学习为 14/20Agent 为 12/20RAG 为 10/20。它们不是对所有 AI 岗位的普遍断言而是这 20 条公开样本中可重复得到的结果。图Kibana 中的岗位技能 Top 10图岗位技能需求统计图Kibana 截图展示了真实索引上的聚合结果单独制作的统计图则更适合文章阅读。两张图使用同一组已校验数据既保留产品实操痕迹也避免宣传图脱离可验证的查询结果。Linux、机器学习、数据结构和向量检索均出现于 3/20 条岗位证据中由于查询按job_count DESC, skill ASC排序并限制为 10 条图表按同一规则展示截止位中的 Linux、向量检索和数据结构。八、Query B 与 Query C从“需求排名”走向“技能缺口”只知道哪些技能出现得多还不够。产品还需要回答课程证据覆盖到了哪里。Query B 直接读取经过审核的覆盖记录并把课程证据与判断依据一并返回。FROM skillgap-radar-v1| WHERE document_type coverage| KEEP skill, coverage_status, job_count, job_ratio,course_evidence, rationale| SORT job_count DESC, skill ASCQuery C 则进一步筛选“岗位中有需求但课程材料中只部分覆盖或未发现明确覆盖”的技能。它更接近产品最终要解决的决策问题。FROM skillgap-radar-v1| WHERE document_type coverage| WHERE coverage_status IN (partial, not_explicit)AND job_count 0| KEEP skill, coverage_status, job_count, job_ratio,course_evidence, job_evidence_ids, rationale| SORT job_count DESC, skill ASC三个查询形成一条完整链路Query A 描述需求Query B 描述现有覆盖Query C 找出值得优先关注的差距。它们比一个不透明的“匹配分数”更容易解释也更方便在数据更新后重新运行。九、课程覆盖不是简单的“有”或“没有”如果只按照课程名称做关键词匹配很容易得到错误结论。例如课程里没有直接出现“RAG”并不意味着学生完全没有相关基础数据库、信息检索、机器学习和软件工程都可能提供组成能力。反过来课程名称里出现“人工智能”也不代表已经覆盖当前岗位所需的工程实践。因此项目把覆盖状态分为三类covered表示课程证据中有较明确的对应内容partial表示具备相关基础但仍需要项目或工具链补充not_explicit表示现有课程材料中没有直接证据。对 18 个技能的最终校验结果为9 个已覆盖、7 个部分覆盖、2 个未明确覆盖。图课程覆盖汇总这个结果不能被解读为对培养方案质量的评分。它只回答一个更具体的问题针对当前岗位样本哪些能力已经有课程证据哪些能力需要学生通过实践继续补齐。十、Agent Builder 的价值把统计结果变成可行动的解释用户可以直接询问“北京 AI 应用岗位最常见的技能是什么”“课程对这些技能覆盖到什么程度”“如果准备 Agent 开发方向优先补哪些能力”Agent 会根据索引中的证据与聚合结果组织回答而不是只输出一串排名。为了降低“看起来合理但没有证据”的风险我在 Agent 指令中加入了几条约束回答必须明确样本范围统计数字优先引用 ES|QL 结果课程覆盖与岗位需求要分开说明建议应指出依据不把相关性写成因果关系证据不足时直接说明限制。默认回答结构也被固定为五部分先给结论再给数据然后列证据接着提供最多五项建议最后说明边界。这种结构让用户既能快速获得方向也能继续追问“凭什么”。开发过程中还有一次很有价值的提醒某次实时 Agent 检索只返回了 17 条岗位而索引中的已校验集合是 20 条。如果直接使用自然语言回答里的数字文章就会出现不同口径。最终我把固定 ES|QL 查询和离线校验结果作为统计事实来源让 Agent 专注解释。这次偏差反而帮助我明确了系统边界Agent 很适合交互与归纳但关键计数仍应由可复现的固定查询兜底。十一、从差距到学习优先级SkillGap Radar 不试图给出一份适用于所有人的“标准答案”而是把优先级拆成三个维度岗位需求强度、课程覆盖程度、技能之间的依赖关系。例如Python、深度学习和模型部署在样本中需求较高也构成进一步学习 LLM 应用的重要基础RAG 与 Agent 更偏向应用工程需要把检索、模型调用、评估和系统设计串联起来。对于大学生而言一条更可执行的路线是先巩固已有课程中的编程与算法基础再完成一个可运行的 RAG 小项目随后加入工具调用、状态管理和评估机制把它逐步扩展为 Agent 项目。一次完整的使用流程可以是这样的用户先选择“AI 应用开发”作为目标方向查看需求 Top 10系统再把高频技能与课程覆盖记录对齐标出已具备基础和仍需补充的部分最后Agent 按先修关系把差距组织成若干阶段。用户看到的不只是“缺少 Agent”而是从 Python 与数据库基础到检索增强生成再到工具调用和部署的连续路径。产品还需要避免把所有人推向同一条路线。已经完成过深度学习项目的学生与刚学完程序设计的学生下一步显然不同。当前原型主要验证公共证据层未来加入个人基础配置后同一组市场数据可以生成不同的学习起点同时仍然保留建议依据。图学习建议图这样的建议不是因为某个热门词出现次数高就立即“追热点”而是同时考虑需求、基础与实践成本。最终输出的不是课程替代方案而是一张帮助学生安排课外学习和项目实践的导航图。十二、从原型到可演示产品我做了哪些取舍Hackathon 的时间有限产品必须先证明核心链路。因此我没有一开始就追求大规模抓取、复杂评分模型或完整前端而是优先完成四件事建立小而可校验的样本统一技能词典让核心结论能够用 ES|QL 重算准备 Agent 失败时仍能展示的 Kibana Dashboard。这些取舍让演示不依赖单一路径。如果 Agent 暂时无法完成聚合可以直接执行预设查询如果图表生成失败可以打开已保存的 Dashboard如果网络中断还能使用本地截图说明结果。产品的“可演示性”不是额外包装而是可靠性设计的一部分。同时我也放弃了一个看起来很吸引人的功能把课程和岗位压缩成单一的“技能差距总分”。这个数字虽然便于传播却会掩盖覆盖证据、样本大小和技能依赖关系。相比一个看似精确但难解释的分数我更愿意展示可追溯的分项结果。十三、这次开发带给我的三个认识第一数据定义比界面更早决定项目质量。技能字典、样本边界和去重规则如果不稳定后面的图表和 Agent 回答再漂亮也不可靠。第二ES|QL 与 Agent 并不是替代关系。ES|QL 提供可复现的统计事实Agent Builder 提供自然语言入口与上下文解释两者组合后才形成完整体验。第三好的智能应用需要主动展示限制。20 条岗位证据适合做原型验证和方法展示但不足以代表市场全貌课程描述也不能等同于真实教学效果。把这些限制写清楚不会削弱项目反而让结论更可信。十四、下一步计划与结语后续我希望从三个方向继续完善 SkillGap Radar扩大岗位样本并按时间、城市与岗位方向分层为技能标签增加人工复核和版本管理加入可配置的个人基础信息使学习建议能够区分“已有基础”和“尚未接触”。如果数据持续更新还可以利用 Kibana 展示技能需求随时间的变化帮助用户观察趋势而不只是查看一次性的排名。回看这个原型它首先为学生提供了一种更具体的观察方法把“岗位需要什么”和“现有课程提供了什么”分开呈现再把两者之间的差距转化为可以安排先后的实践任务。用户不必只依赖热门词或笼统经验而能够顺着证据继续追问。在技术层面项目验证了 Elasticsearch、ES|QL 与 Agent Builder 的互补关系。结构化索引负责保存证据固定查询负责形成可复现的统计事实Agent 则负责理解问题、组织上下文和解释结果。即使智能交互暂时失败核心结论仍能通过查询和 Dashboard 独立复核。在产品层面最重要的设计不是给出更多结论而是明确每条结论的适用范围。样本量、城市、课程文本和覆盖状态都被保留在结果旁边使建议既有方向感也不会越过证据边界。这种“先说明依据再提供行动”的思路也可以迁移到其他教育分析与职业规划场景。从大学生的视角出发我想做的并不是另一个泛化的职业问答机器人而是一套能够回答 “依据是什么” 的工具。SkillGap Radar 仍是一个小型原型但它初步验证了一条可行路径先让公开材料成为结构化证据再用 ES|QL 建立可信的事实层最后让 Agent Builder 把事实转化为可理解、可行动的建议。这也是我在本次 Hackathon 中最重要的收获。