找工作这件事里最消耗人的往往不是投简历而是筛选。每天打开招聘平台几十条新职位涌进来JD 写得越来越长技能栈叠了一层又一层你很难一眼判断它到底适不适合自己。更麻烦的是这种判断本质上不是“有没有某个关键词”的问题而是“这个职位和我的背景、方向、薪资预期、通勤半径、职业阶段是否匹配”的问题。关键词搜索能帮你过滤掉完全不相关的岗位但过滤完之后剩下几十条还是要靠人一条条读、一条条判断。JobRadar 这类项目引起我注意的地方不是“AI 帮我找工作”这个噱头而是它把两个设计选择放在了同一条线上开源加上本地 LLM 打分。用本地模型给职位打分听起来只是隐私层面的一种权衡但实际意义要大得多。它改变的不仅是数据流向而是整个筛选流程的可定制性、可复现性和可解释性。换句话说它不帮你做最终决定它帮你把“判断一个职位合不合适”这件事从一次性的临时阅读变成了一个可以反复迭代的流程。这篇文章不会把它夸成求职神器。我更想拆清楚几件事JobRadar 到底解决哪一层重复劳动它的工作流里最值得研究的模块是什么本地部署要提前想清楚哪些边界单次跑通和长期使用之间差了几块关键拼图以及它背后代表的这一类 agent 项目应该用什么样的框架去评估、去上手、去落地。1. 先搞清楚这个工具真正解决的是哪一类重复劳动1.1 求职筛选不是关键词过滤而是判断职位筛选之所以难是因为它既要有“硬条件匹配”也要有“软性判断”。硬条件匹配比较好处理工作地点在不在你能接受的范围薪资区间够不够技术栈里面有没有你熟悉的语言。这些事情用一个搜索过滤器就能做。真正的瓶颈是软性判断JD 里写着一堆技术栈到底是哪一种占主导团队招人是想要一个能立刻上手的熟手还是愿意培养一个潜力型候选人公司是这个业务的核心团队还是边缘项目的外包岗位这些信息很少直接写在 JD 里更多是靠工作环境、公司规模、职位描述里的措辞去推断。很多招聘平台会提供“推荐职位”功能但它的推荐逻辑通常是基于历史浏览和关键词匹配很难理解你在一段时间里的真实偏好。你可能会想有没有一个东西能让我自定义一套评分标准然后让它在新职位出现时自动按我的标准打分这就是 JobRadar 这类 agent 的核心价值。它把“读 JD、对照自己的需求、给出一个适配度”的任务从一个人肉过程变成了一个可重复执行的程序化过程。1.2 “本地 LLM”不是保守而是工作流的归属问题很多人看到“本地 LLM”第一反应是隐私简历、薪资预期、联系方式这些信息确实不想随便传给一个第三方 API。这个理由已经足够充分了但我认为它还有另外两层意义。第一层是评分标准的可控性。如果打分模型跑在云端 API 上你只能给一段 Prompt然后用供应商提供的模型参数。但跑在本地模型可以随时换量化版本可以自己选Prompt 可以反复调打分的温度系数、随机种子、输出格式都掌握在自己手里。你可以做 A/B 测试今天用这个模型觉得太宽松换个模型再跑一遍。这对于一个以“判断标准”为核心功能的 agent 来说是很重要的事。第二层是成本结构。本地模型不需要按调用次数付费可能只需要电费和硬件折旧。代价是你得到的是一个能力上限更有限的模型。所以我在评估这类项目时最关注的不是“本地模型比云端模型聪明”而是“这个任务需不需要那么聪明的模型”。给职位打分并不需要一个能写出哲学论文的模型它更需要的是稳定、可控、愿意每一条都给出依据。本地小模型在这个任务上比很多人想象中要合适。这一点也决定了 JobRadar 这类工具的性质它不是 SaaS 产品不是一个打开网页就能用的服务而是一个需要你自己维护、自己配置、自己理解每一步在做什么的工程实践。2. 从“抓取列表”到“打分推荐”JobRadar 这类 agent 的核心流程2.1 一个职位雷达 agent 的基本模块从项目定位来看JobRadar 做的事情可以拆成一条流水线。虽然不同实现有差异但一个“职位雷达” agent 通常都会包含下面几个部分数据源接入从招聘平台、职位 RSS、邮件订阅、自定义链接列表里拉取职位信息。内容解析把 HTML、JSON、纯文本等不同来源的职位描述抽取成结构化的字段比如职位标题、公司名称、技术栈、工作地点、经验要求、薪资区间。去重和历史记录同一个职位在不同渠道可能出现多次或者同一家公司重复发布需要记录已经处理过的职位 ID避免重复打分。打分器这是核心。把结构化职位信息和用户定义的评分标准一起交给本地 LLM让模型对匹配度给出一个分数并附上理由。输出模块把打分结果输出成表格、Markdown 文件、邮件通知或者直接打印到终端方便人工复核。调度和生命周期管理定时运行、增量更新、失败重试、日志记录。这看起来像是很常见的爬虫加分析的流程但它和普通爬虫脚本有一个本质区别普通脚本只能告诉你“这条职位包含哪些关键词”而 agent 可以告诉你“这条职位在你的标准下值多少分为什么值这个分”。后者需要的不是规则匹配而是对上下文的理解。2.2 打分逻辑才是这个 agent 的“判断标准”如果让我在一个 JobRadar 类项目里找一个最值得花时间研究的地方那一定不是爬虫怎么写而是打分 Prompt 和评分维度怎么设计。打分听起来很简单就是让模型打个分但实际上有不少坑。首先评分维度需要你自己定义。你是更看重技术栈匹配还是更看重远程办公你是只接受薪资在某个数字以上的职位还是愿意为了公司背景接受略低的薪资这些偏好必须写进评分标准里不能指望模型替你推断。常见的做法是给每个维度分配一个权重比如技术栈匹配40%工作模式远程/混合/坐班20%薪资区间20%公司阶段与行业10%风险信号外包、急招、描述语焉不详10%然后是评分输出格式。我不建议只让模型输出一个 0 到 100 的数字因为数字没有可解释性。更好的做法是要求模型同时输出分数、关键理由、以及命中的正面信号和负面信号。这样当模型把一个职位打出 85 分时你能看到它是因为“要求 3 到 5 年 Java 经验你是否匹配”这一条加分还是因为“工作地点在另一个城市”这一条扣分。即便打分解释清楚也不要设一个太高的阈值然后盲目投递。这个工具的价值在于把候选池从几百条压缩到十几条而不是替你做投资决策。最终投不投依然要看你是否愿意为这个职位付出一次面试的机会成本。2.3 最小可用流程先跑一条再跑一批这类项目最容易犯的错误是一上来就想让它自动监控所有平台然后每天定时推送结果。我的建议是先跑通一个最小流程。第一步准备一条输入。可以是一个职位链接、一个保存好的职位描述文件或者几行以 JSON 格式整理好的职位字段。确保你在没有 agent 的情况下自己也知道这条职位值不值得投。第二步让 agent 对这条输入做完整流程抓取、解析、打分、输出。这一步主要验证的是流程有没有断掉以及打分结果是否合理。第三步把输入扩展到十条左右观察打分稳定性看看同样的职位重复跑是不是得到同样的分数。第四步再考虑加调度、加去重、加通知。这个顺序看起来慢但能避免很多麻烦。因为一旦流程中间有一步不稳定在批量场景下会被放大几十倍。先跑通再优化看着笨实际上是最快的一条路。3. 本地化部署和数据边界环境和隐私比模型能力更先待办3.1 本地 LLM 要准备的不只是模型很多人理解的本地部署就是安装一个模型推理软件然后拉一个模型文件回来。但放到一个真实 agent 项目里环境问题会复杂得多。首先是硬件资源。本地模型运行需要内存和算力。小型量化模型可以在普通个人电脑上跑但推理速度会比较慢尤其是在批量打分时。如果你同时还想跑一个大参数模型还需要考虑显存、内存、磁盘空间和电源散热。原始项目说明里如果没有明确给出最低配置落地前一定要自己测一遍。一般来说先选一个能在自己机器上流畅运行的模型而不是选一个理论上最强的模型。其次是模型上下文长度。职位打分这个任务有一个特点既要读职位描述也要读你的评分标准。如果职位描述很长加上评分标准、输出要求示例可能会超过小模型的有效上下文窗口。超出上下文后模型要么丢信息要么输出质量下降。常见做法是先在代码里做文本截断或摘要再把关键信息塞给模型而不是把所有内容一股脑丢进去。还有一点是模型切换。本地模型不是不可替代的你可以今天用这个模型明天换成另一个。但这个可切换性需要一个前提你的输入输出格式必须足够稳定。把打分 Prompt 和模型调用封装成独立模块这样换模型的时候改动范围可以控制在一个文件里而不是散落在整个项目各处。3.2 需要哪些依赖和前置条件虽然我不能凭空列出 JobRadar 的具体安装命令但从这类项目的常见实践看你大概需要准备以下几类东西Python 环境或 Node 环境取决于项目实现语言。一个可以调用本地模型的运行时比如通过标准化的模型服务接口来加载模型。抓取 HTML 和解析结构化文本的通用库。数据库或轻量存储用来记录历史职位、去重状态和评分结果。一个定时调度方案比如 cron、系统任务计划或者在程序内部实现循环调度。在实际落地前应该先查看项目 README 里有没有明确写环境要求。如果没有不要急着踩坑先按照“输入是职位信息、输出是打分结果”这个边界把依赖一项项跑通。3.3 数据本地化不等于数据绝对安全本地 LLM 确实让职位数据和你的个人背景留在自己机器上但这并不等于绝对安全。还有几个点要想清楚。第一个点是日志。如果程序把每次输入的完整职位描述、评分结果、甚至你的求职偏好都写进日志文件那这些日志文件就变成了敏感数据。长期运行后日志比数据库还危险因为日志通常是明文且保留时间很长。第二个点是外部依赖。即使打分用本地模型如果你在流程里接入了其他在线服务比如翻译 API、地理位置解析服务、公司信息查询 API那么部分数据仍然会离开你的机器。这时候就不能说“完全本地”。第三个点是模型文件本身。你下载的模型也可能经过第三方分发渠道是否可信本身就是一个供应链问题。所以比较准确的说法是本地 LLM 把数据控制权交还给了使用者但使用者也要承担相应的管理责任。这个边界在给自己的项目做安全评估时要想清楚。4. 真正落地时最容易翻车的不是模型而是流程细节4.1 输入格式混乱是头号问题在真实使用中职位数据的来源五花八门。有些职位页面是结构良好的 HTML有些是动态渲染的页面抓下来全是脚本和空壳还有些职位描述是图片或者 PDF。你辛辛苦苦把抓取模块做好结果发现 30% 的职位在解析后是空的这事一点都不罕见。这类问题有一个统一的处理思路把“抓取”和“解析”当成两个独立环节并且为解析结果定义一个统一的中间结构。无论来源是 HTML还是 JSON最后都转换成一种标准字段格式比如{ title: Python Backend Engineer, company: 某科技公司, location: 上海/远程, salary_min: null, salary_max: null, tags: [Python, Django], description: ……, url: ……, source: …… }如果某个字段缺失不要直接跳过而是把缺失情况记录下来。因为打分模型必须依赖这个字段缺失或错误会给后面的分数带来连锁影响。在同样一条职位上如果第一次打 80 分第二次变成 60 分先别怀疑模型先去看输入字段是不是变了。4.2 打分不稳定往往出在上下文和采样参数本地小模型的一个常见问题是同一个输入跑两次结果可能不完全一样。这种现象叫采样随机性。要控制住这种不稳定通常要做两件事。第一把采样温度调到比较低的值。职位打分这类任务不追求创造性低温度会让输出更稳定。很多项目默认值不一定适合所有场景落地时应该针对自己的使用方式调整。第二如果模型和推理框架支持指定随机种子seed可以在测试时固定它用同一份输入做回归测试。这样你就能区分哪些分数变化来自模型本身哪些来自采样随机性。另一个影响稳定性的因素是上下文顺序。模型对内容结尾部分的记忆通常比较好对中段的记忆弱一些。所以我会建议把最重要的信息放在 Prompt 靠后的位置比如把“输出格式要求”放在最后把“职位描述”放在中间把“评分标准”放在前面。这个顺序不同打分结果可能有明显差异。这里其实可以沉淀成一个通用判断框架当输出不稳定时先看输入是否一致再看上下文长度是否超限最后才调模型参数。不要上来就把问题归咎于“模型太笨”。4.3 一套可复用的排查链路如果你真的在 JobRadar 或者类似项目里遇到了问题可以按这个顺序排查而不是对着日志乱猜层级检查内容常见问题现象报错、卡住、无输出、输出异常先确认是程序故障还是结果不符合预期输入职位链接、字段、编码、文件路径解析不到内容、字段缺失、URL 失效环境模型版本、依赖版本、权限、端口模型加载失败、运行时版本冲突参数上下文长度、温度、随机种子、评分阈值打分忽高忽低、前后不一致工具边界页面反爬、模型能力上限、项目未支持的功能抓不到页面、理解不了复杂隐含要求这条链路的核心思想是先定位是哪一层出问题再决定怎么修。如果发现是输入层的问题就不要去调模型参数如果发现是环境问题改代码也没有用。写得越久我越觉得维护这个项目最重要的能力不是写 Prompt而是会分层次地排查问题。5. 适合谁不适合谁把它当成一个工程化练习而不是求职外挂5.1 什么场景适合用JobRadar 这类开源 agent最适合的是下面几类人。第一类对 agent 技术感兴趣想通过一个有真实业务场景的项目来学习的人。职位打分这个任务边界清晰既能用上 LLM也能用上数据处理、调度、持久化这些工程技能是一个很好的练手项目。第二类对隐私敏感不希望自己的求职背景被互联网平台反复分析的开发者。第三类求职方向明确愿意花时间把自己的偏好写清楚的人。这个工具不是给你推荐意外的机会而是帮你过滤噪音。你的方向越清晰打分的准确度就越高。第四类机器上已经有可用的本地模型运行环境不需要额外买硬件的人。在这些前提下它会成为一个很好用的“筛选助理”。注意是助理不是决策者。5.2 什么场景不适合如果你正在海投阶段连自己想做什么方向都没想好那这个工具帮不上什么忙。因为它做的是“在你的标准下判断匹配度”可如果你的标准每天都在变那打分结构就不会稳定。如果你是零基础学习者第一次接触 Python 或者 agent 概念想通过它一键找工作那会很受挫。因为你会同时面对模型环境配置、数据抓取、文本解析、调试日志等一系列问题任何一个环节都可能让你卡住。这类项目更适合有一定基础至少能理解“输入、处理、输出”这个概念的人。另外如果你指望它每天自动把所有平台的职位都抓下来那你可能会遇到很多平台层面的限制。大多数招聘平台都有反爬机制如果为了绕过限制去过度访问而放弃了合规使用的前提这条路从一开始就走错了。开源的 fetch agent 只能解决流程问题不能替你解决访问权限问题。5.3 要长期使用还缺哪几块拼图把单次跑通变成长期使用中间还差几块拼图历史记录和去重。没有去重第二天就会有一堆重复职位重新被打分。调度与增量。不是每次都全量抓取而是用上次的时间戳做增量更新。失败告警。抓取失败、模型调用失败、输出格式异常都需要有日志和提醒。评分标准的版本管理。你的偏好会变Prompt 会被反复修改需要能看清哪一版标准在什么时间产生了什么结果。模型升级后的回归验证。换了一个更强的新模型不代表打分结果一定更准要用旧样本跑一遍确认没有明显退化。这几点都不是 JobRadar 特有的事所有自托管 agent 项目时间一长都会遇到。这也是为什么我会说长期使用这个工具的价值不在于“帮我省了每天刷招聘网站的时间”而在于它逼你建立起一套可维护、可解释、可回溯的数据处理流程。6. 从 JobRadar 回看 agent 开发的三件小事6.1 agent 的本质是一个有限循环最近 agent 相关的讨论非常多各种框架和名词层出不穷。但如果把 JobRadar 这种项目拆开来看会发现它本质上就是一条有限循环获取数据解析判断执行动作然后循环。一个 agent 并没有那么神秘它不过是把“读取、理解、决策、行动”这个过程用模型和代码串起来。关键是它要有一个明确的终止条件。JokRadar 做完一次打分、输出一条结果这个循环就结束了。它不是无限的自主智能体它只是把一段固定流程自动化了。理解这一点你就不会被“AI 自主找工作”这类夸张说法带偏。6.2 把 harness、模型、任务拆开理解在 agent 开发里经常听到“harness”和“agent”这两个词很多人不知道它们有什么区别。简单说harness 是承载 agent 运行的框架层负责调用模型、管理执行循环、处理错误重试、控制生命周期agent 则是你定义的任务执行体它使用模型做推理也使用工具做动作。模型是脑子harness 是身体骨架任务是你要达成的目标。用 JobRadar 这个概念来类比本地 LLM 负责“打多少分”这个判断循环和调度逻辑负责“什么时候处理哪些职位”这个流程你写下的评分标准则定义了“这个 agent 到底要达成什么目标”。把这三层拆开理解你才能知道一个问题出现时到底该改哪一层。6.3 这类项目真正值得学习的是流程工程回到最早的问题JobRadar 真正解决的是什么它解决的是一类非常典型的重复劳动在信息不充分、判断标准因人而异的情况下持续对一个列表做筛选和评分。这件事过去靠人眼现在可以交给一个由本地模型驱动的 agent。但最值得学习的不是它帮你找到了什么工作而是它背后那条从模糊需求到可执行流程的转化路径把“我想找一个好工作”翻译成“技术栈权重 40%、远程偏好 20%、薪资区间 20%”再把这条标准变成模型 Prompt再让结果落到一个可回顾的表格里。这套能力比 JobRadar 这个项目本身更有复利价值。如果你也想动手试我的建议是先不要急着找最新最强的模型也不要盲目扩大抓取范围。先拿十条真实的职位数据把你自己的筛选标准写清楚然后让这个开源 agent 跑一遍看看打分结果和你的直觉差多少再去调那些变量。一次循环跑通了后续的工程化才有意义。