1. 求职信息差这件事到底卡在哪一步找工作最让人抓狂的不是面试被拒而是你根本不知道有哪些岗位在招、薪资到底给到多少、哪些信息是真的。我做了几年技术社区的内容接触过大量求职者发现一个特别普遍的现象大多数人找岗位的方式还停留在“打开招聘软件搜关键词翻前几页投简历”这个循环里。问题在于招聘平台的信息是平台想让你看到的信息排序逻辑、曝光机制、甚至薪资范围的展示方式都经过了层层包装。你看到的“15-25K”可能实际底薪只有8K剩下的全靠绩效画饼你看到的“急招”可能已经挂了三个月没动静。更麻烦的是不同平台的岗位信息是割裂的。A平台偏互联网B平台偏传统行业C平台全是外包。你想做一个全面的岗位调研得同时开五六个页面手动对比复制粘贴到表格里再一条条去查公司背景。这个过程我实测过认真做一轮至少两到三个小时而且做完之后你依然不确定信息是不是最新的、薪资是不是真实的。所以当我看到“用 Seed-2.1-pro-0915 做一个专用雷达12分钟出报告每条薪资都能点开验证”这个思路的时候第一反应是这才是 Agent 该干的事。不是那种“帮你写周报”的玩具 Agent而是真正解决一个具体、高频、信息密度极高的现实问题。这篇文章我就把这个项目的完整思路拆开讲从为什么选这个模型、怎么设计 Agent 架构、SSE 流式输出怎么接、到实际跑起来会遇到哪些坑全部按我自己的实操经验来写。不管你是刚接触 Agent 开发的新手还是已经在用 Claude Code 做项目的开发者应该都能从里面拿到可以直接复用的东西。2. 为什么是 Seed-2.1-pro-0915 加上 Agent 这套组合2.1 模型选型的核心逻辑长上下文加结构化输出先说模型选择这件事。市面上能用的模型很多为什么偏偏选 Seed-2.1-pro-0915我自己的判断标准有三个第一上下文窗口要够大因为岗位雷达这个场景需要同时处理多个来源的文本包括岗位描述、公司信息、薪资数据、用户评价等等如果上下文太小你只能分批处理信息就会断裂第二结构化输出要稳Agent 需要模型返回 JSON 格式的数据如果模型经常返回格式错误的内容整个流程就会卡住第三推理速度要能撑住流式输出因为用户等报告的时候如果十几秒没有任何反馈体验会非常差。Seed-2.1-pro-0915 在这三点上表现比较均衡。它的上下文窗口足够容纳一次完整的岗位调研任务结构化输出经过提示词约束后稳定性不错而且流式返回的 token 速度在可接受范围内。当然这不是说其他模型不能用如果你手头有更熟悉的模型完全可以替换核心是保证上面三个条件满足。这里要特别说一个坑很多人做 Agent 的时候喜欢用最强的模型跑所有环节但实际上不同环节对模型能力的要求是不一样的。比如“解析岗位描述”这个环节其实不需要太强的推理能力用轻量模型就够了但“判断薪资是否合理”这个环节就需要模型有一定的行业知识和推理能力。我的做法是把任务拆成多个步骤每个步骤用不同级别的模型这样整体成本和速度都会好很多。2.2 Agent 架构不是一个大循环而是流水线加决策点很多人对 Agent 的理解还停留在“给一个目标模型自己规划步骤自己调用工具自己循环直到完成”。这种全自主 Agent 在实际项目中非常难控制尤其是涉及外部数据抓取的时候模型可能会陷入死循环或者调用一些你不想让它调用的工具。我的设计思路是“流水线加决策点”。整个岗位雷达的流程被拆成固定的几个阶段信息采集、信息清洗、岗位匹配、薪资验证、报告生成。每个阶段之间是串行的但每个阶段内部Agent 可以根据情况做决策。比如在信息采集阶段Agent 会根据用户输入的关键词决定去哪些数据源、用什么搜索策略在薪资验证阶段Agent 会判断哪些薪资数据需要进一步交叉验证哪些可以直接采信。这种架构的好处是可控。你知道每一步在做什么出了问题也容易定位。坏处是灵活性不如全自主 Agent但对于岗位雷达这种流程相对固定的场景来说可控性比灵活性更重要。2.3 技术栈选择Next.js 加 SSE 的流式体验前端用 Next.js后端用 Node.js 或者 Python 都可以核心是 SSEServer-Sent Events的流式输出。为什么不用 WebSocket因为岗位雷达这个场景是单向的服务器不断推送进度和结果客户端只需要接收。SSE 在这种场景下更轻量实现也更简单。SSE 的关键在于“让用户感知到进度”。12 分钟出报告如果用户盯着一个空白页面等 12 分钟大概率会以为卡死了。但如果你能看到“正在采集第 3 个数据源”“已匹配到 47 个岗位”“正在验证薪资数据”这样的实时进度等待体验就完全不一样了。这也是为什么我在架构里把 SSE 作为核心通信方式而不是等全部处理完再一次性返回。3. 岗位雷达的核心模块拆解与实操要点3.1 信息采集模块多源聚合与去重策略信息采集是整个雷达的入口也是最容易出问题的环节。我的做法是维护一个数据源列表每个数据源有对应的采集策略。比如有些平台提供公开的搜索接口可以直接调用有些平台需要模拟浏览器行为用 Playwright 或者 Puppeteer 来抓取还有一些平台可以通过 RSS 或者公开数据集获取。采集的时候有几个关键点。第一是并发控制不要一次性开太多请求否则很容易被限流或者封禁。我的经验是每个数据源同时最多 3 到 5 个并发请求中间加随机延迟。第二是去重不同平台上的同一个岗位可能标题略有不同但公司名和岗位描述高度相似。我用的是“公司名加岗位标题的模糊匹配”加“岗位描述的前 200 字相似度”双重判断相似度超过阈值就认为是重复岗位只保留信息最全的那一条。第三是数据标准化。不同平台返回的字段名和格式都不一样需要在采集阶段就统一成内部格式。比如薪资字段有的平台返回“15-25K”有的返回“15000-25000元/月”有的返回“面议”。我的做法是定义一个标准的 Job 对象包含 title、company、salary_min、salary_max、salary_unit、location、description、source、source_url、collected_at 这些字段采集的时候就把数据映射到这个结构上。注意采集频率一定要控制。我试过一次性抓太多结果 IP 被限制了好几个小时。后来改成每批之间间隔 2 到 3 秒并且随机化请求头就稳定多了。3.2 信息清洗与岗位匹配让模型做它擅长的事采集回来的原始数据是很脏的。岗位描述里可能夹杂着大量无关内容比如公司介绍、福利待遇、团建活动真正和岗位职责相关的内容可能只占三分之一。这时候就需要清洗。我的做法是先用规则做一轮粗清洗比如去掉 HTML 标签、去掉重复的空格和换行、截断过长的文本。然后把清洗后的文本交给模型让模型提取出“核心职责”“硬性要求”“加分项”这三个部分。提示词大概是这样的你是一个岗位信息提取助手。请从下面的岗位描述中提取以下信息 1. 核心职责3-5 条每条不超过 30 字 2. 硬性要求学历、经验、技能等逐条列出 3. 加分项有则列出无则返回空数组 4. 薪资是否明确返回 true 或 false 岗位描述 {description} 请以 JSON 格式返回不要添加任何额外说明。这个环节的模型可以用轻量级的因为任务本身不复杂主要是信息抽取。但提示词一定要写清楚输出格式否则模型可能会返回一堆解释性文字导致后续解析失败。岗位匹配环节是让模型判断“这个岗位和用户的求职意向匹配度有多高”。用户的求职意向可能是一段自然语言描述比如“我想找北京地区的后端开发岗位3 到 5 年经验薪资不低于 20K最好是大厂或者 B 轮以上的创业公司”。模型需要把这个描述和每个岗位进行对比给出匹配分数和匹配理由。这里有个技巧不要让模型直接给一个 0 到 100 的分数因为模型对分数的判断很不稳定。更好的做法是让模型从几个维度分别打分比如“技能匹配度”“经验匹配度”“薪资匹配度”“地点匹配度”每个维度 1 到 5 分最后加权计算总分。这样不仅更稳定而且用户能看到每个维度的具体情况更有参考价值。3.3 薪资验证每条薪资都能点开看来源这是这个项目最核心的差异化功能。大多数岗位聚合工具只展示薪资范围但不告诉你这个数据是从哪来的、可不可信。我的做法是给每条薪资数据都附上来源链接和采集时间用户点击就能跳转到原始页面验证。具体实现上薪资验证分两步。第一步是“来源标注”每条薪资数据在采集的时候就会记录来源 URL 和采集时间这个在数据标准化阶段就完成了。第二步是“交叉验证”如果同一个公司在多个平台都有岗位我会对比不同平台的薪资数据如果差异超过 30%就标记为“薪资数据存在差异建议进一步核实”。还有一个细节有些岗位的薪资是“面议”这种岗位我会单独归类不参与薪资排序但在报告里会标注出来。因为“面议”往往意味着薪资弹性大或者公司不想公开薪资范围对于求职者来说这类岗位需要单独对待。实操心得薪资验证这个功能看起来简单但实际做的时候会发现数据源的质量参差不齐。有些平台的薪资数据明显是随便填的比如一个初级岗位标 50K 以上。我的做法是加一个合理性校验如果薪资明显偏离行业平均水平就降低这条数据的权重并在报告里标注“薪资数据异常请谨慎参考”。3.4 报告生成12 分钟出报告的时间分配12 分钟出报告这个时间是怎么分配的我实测下来的大致比例如下阶段耗时占比说明信息采集约 40%多源并发采集受网络和限流影响最大信息清洗约 15%规则清洗加模型抽取可以并行处理岗位匹配约 20%模型逐条判断岗位数量多时耗时增加薪资验证约 10%交叉验证和合理性校验报告生成约 15%汇总数据、生成图表和可点击链接这个时间分配不是固定的如果数据源响应慢采集阶段可能会占到 60% 以上。所以我在前端做了进度条和阶段提示让用户知道当前进行到哪一步而不是干等。报告本身的结构包括岗位总览数量、来源分布、薪资区间分布、匹配度排序按加权总分从高到低、每条岗位的详情含薪资来源链接、薪资异常提示、以及一个“下一步建议”模块比如建议优先投递哪些岗位、哪些岗位需要进一步核实。4. SSE 流式输出的完整实现与踩坑记录4.1 为什么 SSE 在这个场景下比 WebSocket 更合适SSE 和 WebSocket 的区别很多人只知道“SSE 是单向的WebSocket 是双向的”但实际选型的时候还要考虑更多。岗位雷达这个场景客户端只需要接收服务器的推送不需要向服务器发送实时消息。SSE 基于 HTTP 协议实现简单浏览器原生支持 EventSource不需要额外的库。而且 SSE 自带重连机制如果连接断了浏览器会自动尝试重新连接。WebSocket 虽然更灵活但需要额外的握手协议、心跳维护、重连逻辑对于这个场景来说属于过度设计。我试过用 WebSocket 做后来发现代码复杂度高了不少而且调试起来更麻烦最后还是换回了 SSE。4.2 后端 SSE 接口的实现要点后端用 Node.js 实现 SSE 接口核心是设置正确的响应头然后持续向客户端写入数据。关键代码如下app.get(/api/radar/stream, async (req, res) { res.setHeader(Content-Type, text/event-stream); res.setHeader(Cache-Control, no-cache); res.setHeader(Connection, keep-alive); res.setHeader(X-Accel-Buffering, no); const sendEvent (event, data) { res.write(event: ${event}\n); res.write(data: ${JSON.stringify(data)}\n\n); }; try { sendEvent(progress, { stage: collecting, message: 正在采集岗位数据... }); const jobs await collectJobs(req.query.keyword); sendEvent(progress, { stage: cleaning, message: 已采集 ${jobs.length} 个岗位正在清洗... }); const cleanedJobs await cleanJobs(jobs); sendEvent(progress, { stage: matching, message: 正在匹配岗位... }); const matchedJobs await matchJobs(cleanedJobs, req.query.intent); sendEvent(progress, { stage: verifying, message: 正在验证薪资数据... }); const verifiedJobs await verifySalary(matchedJobs); sendEvent(progress, { stage: generating, message: 正在生成报告... }); const report await generateReport(verifiedJobs); sendEvent(result, report); res.write(event: done\ndata: {}\n\n); } catch (error) { sendEvent(error, { message: error.message }); } finally { res.end(); } });这里有几个容易踩的坑。第一X-Accel-Buffering: no这个头很重要如果你用了 Nginx 做反向代理不加这个头的话Nginx 会缓冲响应导致客户端收不到实时推送。第二每条消息必须以\n\n结尾否则客户端解析会出问题。第三记得在最后调用res.end()否则连接不会关闭。4.3 前端 EventSource 的接入与断线处理前端用 EventSource 接收 SSE 消息代码很简单const eventSource new EventSource(/api/radar/stream?keyword后端开发intent北京3-5年20K以上); eventSource.addEventListener(progress, (e) { const data JSON.parse(e.data); updateProgress(data.stage, data.message); }); eventSource.addEventListener(result, (e) { const report JSON.parse(e.data); renderReport(report); }); eventSource.addEventListener(done, () { eventSource.close(); }); eventSource.addEventListener(error, (e) { const data JSON.parse(e.data); showError(data.message); eventSource.close(); });但实际用的时候会遇到一个问题如果后端处理时间很长中间又没有发送任何消息连接可能会因为空闲超时而断开。我遇到过stream disconnected before completion: idle timeout waiting for SSE这个报错就是因为采集阶段耗时太长中间没有发送心跳。解决办法是加一个心跳机制每隔 15 到 30 秒发送一条注释消息const heartbeat setInterval(() { res.write(: heartbeat\n\n); }, 15000); req.on(close, () { clearInterval(heartbeat); });注释消息以冒号开头客户端会忽略它但能保持连接活跃。4.4 并发场景下的 SSE 连接管理如果同时有多个用户在使用岗位雷达每个用户都会建立一个 SSE 连接。这时候需要注意连接管理。我的做法是给每个连接分配一个唯一的 session ID后端维护一个连接池记录每个连接的状态和对应的任务。如果用户关闭了页面前端的 EventSource 会自动关闭连接后端的req.on(close)事件会触发清理对应的任务和资源。还有一个问题是任务队列。如果同时有 10 个用户发起请求不可能同时跑 10 个采集任务否则数据源那边肯定扛不住。我的做法是加一个简单的队列每个任务排队执行但通过 SSE 实时推送排队位置和预计等待时间。这样用户知道自己在排队而不是以为卡死了。注意SSE 连接数在浏览器端是有限制的同一个域名下最多 6 个连接。如果你的应用有多个 SSE 接口要注意不要超过这个限制。我的做法是把所有进度信息合并到一个 SSE 接口里通过 event 类型区分不同的消息。5. 常见问题与排查技巧实录5.1 采集阶段被限流怎么办这是最常见的问题。表现是采集到一半突然大量请求失败返回 429 或者 403。我的排查思路是先看失败率如果失败率突然升高基本就是被限流了。这时候不要继续重试而是暂停一段时间降低并发数换请求头再继续。预防措施包括控制并发数每个数据源不超过 3 个并发、加随机延迟1 到 3 秒、轮换 User-Agent、使用多个数据源分散压力。如果某个数据源特别严格可以考虑降低采集频率或者只采集最近几天的数据。5.2 模型返回格式错误怎么处理模型返回的 JSON 格式错误是另一个高频问题。表现是JSON.parse失败或者解析出来的对象缺少必要字段。我的处理方式是加一层校验和重试。先用正则提取 JSON 部分模型有时候会在 JSON 前后加解释文字然后尝试解析如果失败就重新调用模型并在提示词里强调“只返回 JSON不要添加任何其他内容”。如果重试两次还是失败就降级处理用规则提取关键信息或者跳过这条数据。不要让一条数据的格式错误阻塞整个流程。5.3 报告生成后用户说“薪资不对”怎么排查用户反馈薪资不对通常有三种情况。第一种是数据源本身就不准确这个只能通过交叉验证和标注来源来缓解。第二种是薪资单位换算错误比如把“年薪”当成了“月薪”这个需要在数据标准化阶段做好单位统一。第三种是采集时间太久薪资已经变了这个需要在报告里标注采集时间并提示用户“薪资数据采集于 X 时间建议以最新信息为准”。排查的时候我会先看这条薪资数据的来源链接点进去对比原始页面。如果原始页面确实是这样那就是数据源的问题如果原始页面不一样那就是采集或解析的问题。5.4 常见问题速查表问题现象可能原因排查方法解决方案SSE 连接空闲超时断开长时间没有发送消息查看后端日志确认是否有心跳加心跳机制每 15 秒发送注释消息采集大量失败被数据源限流查看失败率和返回状态码降低并发加延迟换请求头模型返回格式错误提示词不够明确打印模型原始返回内容加强提示词约束加重试机制薪资数据异常数据源质量差或单位错误对比原始页面和解析结果加合理性校验标注异常数据报告生成慢岗位数量太多查看各阶段耗时分批处理并行化清洗和匹配5.5 几个我踩过的坑和对应的解法第一个坑是“过度依赖模型做所有事”。一开始我让模型同时做信息抽取、岗位匹配和薪资判断结果发现模型在长文本下容易丢失细节而且速度很慢。后来拆成多个步骤每个步骤用不同的提示词和模型效果好了很多。第二个坑是“忽略数据源的反爬策略”。有些数据源会检测请求频率和行为模式如果太规律就会被识别。我的做法是加随机延迟、随机化请求顺序、模拟真实用户的浏览行为。第三个坑是“报告太长用户不看”。第一版报告生成了几十页用户反馈说根本看不完。后来改成“摘要加详情”的结构摘要部分只展示最关键的 10 个岗位和核心结论详情部分可以展开查看。这样用户先看摘要有兴趣再深入。第四个坑是“没有处理边界情况”。比如用户输入的关键词太宽泛返回几千个岗位处理时间超过 12 分钟或者关键词太窄一个岗位都没匹配到。我的做法是加一个预检机制如果关键词太宽泛就提示用户缩小范围如果没匹配到就建议用户调整条件。6. 从跑通到好用我做了哪些优化6.1 缓存策略让重复查询快起来岗位数据是有时效性的但短时间内重复查询同一个关键词结果差异不会太大。我的做法是加一层缓存同一个关键词在 30 分钟内重复查询直接返回缓存结果并标注“数据缓存于 X 时间”。这样既保证了速度又不会让用户觉得数据太旧。缓存的实现可以用内存缓存比如 Node.js 的 Map也可以用 Redis。如果部署在多实例环境下建议用 Redis保证缓存一致性。6.2 增量更新只采集变化的部分全量采集很慢而且浪费资源。我的做法是记录每个数据源上次采集的时间戳下次采集时只获取这个时间戳之后的新岗位。这样采集量大幅减少速度也快了很多。当然增量更新需要数据源支持按时间筛选如果不支持就只能全量采集后做去重。6.3 用户反馈闭环让雷达越用越准我在报告页面加了一个“反馈”按钮用户可以对每个岗位标记“感兴趣”“不感兴趣”“薪资不准确”。这些反馈数据会被记录下来用于调整后续的匹配权重。比如如果多个用户对某类岗位标记“不感兴趣”模型在匹配时就会降低这类岗位的分数。这个闭环不需要太复杂关键是让用户感觉到自己的反馈被重视了而且确实能影响后续结果。6.4 部署与性能Docker 容器化与资源限制整个项目用 Docker 容器化部署前端和后端分开。后端容器限制 CPU 和内存防止采集任务占用过多资源影响其他服务。SSE 连接比较耗内存每个连接大概占用几十 KB如果并发用户多需要适当增加内存。如果部署在云服务器上注意配置安全组只开放必要的端口。SSE 接口建议走 HTTPS避免被中间设备干扰。7. 这套思路还能怎么扩展岗位雷达这个项目跑通之后我发现这套“多源采集加模型清洗加流式输出”的架构其实可以复用到很多场景。比如租房雷达采集多个租房平台的信息清洗后按通勤时间、租金、面积等维度匹配比如比价雷达采集多个电商平台的价格验证历史价格走势比如舆情雷达采集多个社交平台的内容分析情感倾向和热点趋势。核心逻辑是一样的多源采集解决信息割裂模型清洗解决信息质量流式输出解决等待体验来源标注解决信任问题。只要你的场景符合“信息分散、质量参差、用户需要快速判断”这几个特征这套架构就能直接搬过去用。我在实际使用中发现最关键的其实不是技术实现而是对场景的理解。你得知道用户真正关心什么、哪些信息是噪音、哪些数据需要验证。技术只是工具把工具用在对的地方才能做出真正有用的东西。