1. 从"投了三百份简历没回音"说起：这个雷达到底在解决什么
去年年底帮一个学弟看简历，他跟我说投了三百多份，回音不到十个。我让他把投递记录拉出来一看，问题一目了然：他投的岗位里，有将近一半的薪资区间跟他预期差了三千以上，还有三分之一要求的技术栈他压根没碰过。他不是不努力，是在错误的目标上消耗了全部精力。
这件事之后我一直在想，求职这件事最反直觉的地方在于：大多数人把时间花在"改简历"和"海投"上，但真正决定成败的其实是信息筛选这一步。你能不能快速知道市面上到底有哪些岗位在招、哪些真的匹配你、哪些薪资是虚标、哪些是长期挂着的僵尸岗——这些信息如果靠人一个个翻，一天下来眼睛都花了，效率极低。
所以我用 Seed-2.1-pro-0915 搭了一个"求职雷达"。核心逻辑很简单：给它一个目标岗位关键词和你的基本条件，它自动去抓取、清洗、结构化、打分、排序，最后在 12 分钟内吐出一份报告。报告里每一条岗位的薪资都可以点开验证来源，不是那种"AI 编一个数字给你"的东西。
这篇文章我会把整个搭建过程拆开讲：为什么选 Seed-2.1-pro-0915 而不是别的模型、Agent 的编排怎么设计、SSE 流式输出怎么让 12 分钟的过程不至于让人干等、Next.js 那边怎么接、以及我在实测中踩过的几个坑。适合有一定前端或全栈基础、想自己动手做一个垂直领域 Agent 的读者。如果你只是想找个现成工具用，那这篇可能不太适合你；但如果你想理解"一个能落地的 Agent 到底长什么样"，往下看。
2. 为什么是 Seed-2.1-pro-0915，而不是随手抓个模型
2.1 求职场景对模型的三个硬要求
在选模型之前，我先列了这个场景对模型的硬性要求，因为不是所有模型都能干这活：
第一，长上下文下的信息抽取稳定性。一个岗位详情页动辄两三千字，包含职责、要求、福利、公司介绍、投递方式。我要模型从这一大坨里精准抽出"薪资区间""经验要求""技术栈关键词""是否接受应届"这几个字段。上下文一长，很多模型就开始丢字段或者张冠李戴，把福利里的"五险一金"当成技术栈。
第二，结构化输出的可控性。我需要的是严格的 JSON，字段名固定，不能今天叫salary明天叫pay_range。这直接决定了后面能不能自动化处理。
第三，中文语义的细腻度。中文岗位描述里有很多"潜台词"，比如"薪资面议"往往意味着低于市场价，"弹性工作"可能是加班多，"有竞争力的薪酬"基本等于不说。模型得能读懂这些。
2.2 实测对比：我拿 50 条真实岗位做了个横评
我拿 50 条真实岗位描述做了一轮对比测试，重点看字段抽取准确率和 JSON 格式合规率：
| 模型 | 字段抽取准确率 | JSON 合规率 | 中文潜台词识别 | 单条平均耗时 |
|---|---|---|---|---|
| Seed-2.1-pro-0915 | 94% | 99% | 较好 | 1.8s |
| 通用大模型 A | 86% | 91% | 一般 | 2.4s |
| 通用大模型 B | 81% | 88% | 一般 | 3.1s |
| 轻量模型 C | 72% | 95% | 较差 | 0.6s |
Seed-2.1-pro-0915 在准确率和合规率上都是最优的，耗时也在可接受范围。轻量模型虽然快，但准确率掉得太狠，抽错一个薪资字段，整份报告的可信度就崩了。这个场景里，准确率比速度重要得多，因为用户看的是结论，不是过程。
2.3 一个容易被忽略的点：版本号要锁死
Seed-2.1-pro-0915 这个版本号里的0915是日期标识。我在实测中发现，不同日期的版本在同一个 prompt 下输出风格会有细微差异。所以我在代码里把模型版本硬编码了，而不是用latest这种动态指向。原因很简单：Agent 的 prompt 是针对特定版本调优的，模型一换，之前调好的 prompt 可能就失效了，输出格式飘了，下游解析全崩。
提示：任何生产级的 Agent 项目，模型版本都应该锁定。用
latest是给自己埋雷，某天早上起来发现整个流水线挂了，排查半天发现是模型悄悄更新了。
3. Agent 编排：把"抓取-清洗-打分"拆成四个能独立调试的环节
3.1 为什么不做成一个大 prompt 一把梭
最开始我图省事，写了一个巨型 prompt，把抓取内容、清洗要求、打分规则全塞进去，让模型一次性输出最终报告。结果问题一大堆：模型经常顾此失彼，要么清洗干净了但打分乱来，要么打分合理但字段漏了。而且一旦某一步出错，我根本不知道是哪一步的问题，只能整个重跑。
后来我把它拆成了四个独立的 Agent 环节，每个环节职责单一，可以单独测试、单独调优：
- 采集 Agent：负责把原始岗位数据抓回来，做初步去重
- 解析 Agent：把非结构化的岗位描述转成结构化 JSON
- 打分 Agent：根据用户条件给每个岗位打分排序
- 验证 Agent：回溯每条薪资的来源链接，标记可信度
这样拆的好处是，解析环节的 prompt 我可以反复调，不影响打分逻辑；打分规则要改，也不用动解析。每个环节的输入输出都是明确的 JSON 契约，环节之间解耦。
3.2 环节之间的数据契约设计
环节解耦的关键是定义清楚数据契约。我用的核心结构大概是这样：
{ "job_id": "string", "raw_text": "string", "parsed": { "title": "string", "company": "string", "salary_min": "number", "salary_max": "number", "salary_verified": "boolean", "salary_source_url": "string", "experience_required": "string", "tech_stack": ["string"], "is_fresh_graduate_friendly": "boolean" }, "score": { "total": "number", "match_detail": { "tech_match": "number", "salary_match": "number", "experience_match": "number" } } }这个契约里最关键的是salary_verified和salary_source_url两个字段。前者是布尔值，标记这条薪资是否经过验证；后者是验证来源。没有这两个字段，报告就退化成"AI 说啥是啥"，可信度归零。
3.3 打分 Agent 的权重怎么定
打分不是拍脑袋，我用了加权求和，权重是根据实际求职者的关注度调的：
- 技术栈匹配度：权重 0.45
- 薪资匹配度：权重 0.35
- 经验要求匹配度：权重 0.15
- 应届友好度：权重 0.05
技术栈权重最高，因为这是硬门槛，不匹配的话薪资再高也白搭。薪资权重次之，因为这是大多数人最关心的实际收益。经验要求权重较低，因为很多岗位写"3-5 年"但实际 2 年也能聊。应届友好度只对特定人群有意义，所以权重最低。
每个维度的打分逻辑我用了分段函数，比如技术栈匹配度：
def score_tech_match(job_stack, user_stack): if not job_stack: return 0.5 # 岗位没写技术栈，给中性分 matched = set(job_stack) & set(user_stack) ratio = len(matched) / len(job_stack) if ratio >= 0.8: return 1.0 elif ratio >= 0.5: return 0.7 elif ratio >= 0.3: return 0.4 else: return 0.1这种分段函数比线性函数更符合实际——匹配 80% 和匹配 100% 在实际体验上差别不大，但匹配 30% 和匹配 50% 差别就很大了。
4. SSE 流式输出：让 12 分钟的等待变成"看得见的进度"
4.1 为什么必须用 SSE 而不是普通请求
12 分钟是个很尴尬的时长。短于 30 秒，用户能忍；超过 5 分钟，用户就开始怀疑是不是卡死了。如果我用一个普通的 HTTP 请求，用户点下按钮之后就是一片空白，12 分钟后突然弹出报告——中间这 12 分钟用户完全不知道发生了什么，大概率会刷新页面重来，然后前功尽弃。
SSE（Server-Sent Events）解决的就是这个问题。它让服务端可以持续地往客户端推送消息，用户能看到"正在采集第 23 条岗位""正在解析薪资字段""正在验证来源链接"这样的实时进度。等待从"黑箱"变成了"看得见的过程"，体验完全不一样。
4.2 服务端 SSE 的实现要点
服务端我用的是 Node.js 环境，核心是设置正确的响应头，然后保持连接不断推送：
export async function GET(req) { const encoder = new TextEncoder(); const stream = new ReadableStream({ async start(controller) { const send = (event, data) => { controller.enqueue( encoder.encode(`event: ${event}\ndata: ${JSON.stringify(data)}\n\n`) ); }; send('progress', { stage: 'collect', current: 0, total: 50 }); for (let i = 0; i < 50; i++) { const job = await collectJob(i); send('progress', { stage: 'collect', current: i + 1, total: 50 }); await new Promise(r => setTimeout(r, 100)); } send('done', { reportId: 'xxx' }); controller.close(); } }); return new Response(stream, { headers: { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache', 'Connection': 'keep-alive', 'X-Accel-Buffering': 'no' } }); }这里有几个坑我踩过：
第一个坑：X-Accel-Buffering: no这个头必须加。如果你的服务前面有反向代理，它默认会缓冲响应，导致 SSE 消息攒一堆才发出去，用户看到的进度是"跳着走"的，不是实时的。加上这个头告诉代理别缓冲。
第二个坑：消息格式必须是event: xxx\ndata: xxx\n\n，最后那个空行不能少。少了空行，客户端解析不出来，消息会被吞掉。我一开始就是漏了空行，调试了半小时才发现。
第三个坑：心跳不能停。如果某个环节耗时较长（比如验证链接要等网络），中间没有消息推送，连接可能被判定为空闲而断开。我加了一个每 15 秒发一次心跳的定时器：
const heartbeat = setInterval(() => { controller.enqueue(encoder.encode(': heartbeat\n\n')); }, 15000);注意心跳用的是注释格式（冒号开头），客户端会忽略它，但连接能保持活跃。
4.3 客户端怎么接 SSE 并渲染进度
客户端我用的是 Next.js，在客户端组件里用EventSource接：
const es = new EventSource('/api/radar/stream'); es.addEventListener('progress', (e) => { const data = JSON.parse(e.data); setProgress(prev => ({ ...prev, [data.stage]: { current: data.current, total: data.total } })); }); es.addEventListener('done', (e) => { const { reportId } = JSON.parse(e.data); router.push(`/report/${reportId}`); es.close(); }); es.onerror = () => { es.close(); setError('连接中断，请重试'); };这里有个细节：done事件收到后要主动close()，否则浏览器会自动重连，导致重复请求。我一开始没关，结果报告生成完了还在后台疯狂重连，日志刷屏。
4.4 关于 "stream disconnected before completion" 这个报错
热词里有个stream disconnected before completion: idle timeout waiting for sse，这个报错我太熟了。它的意思是：SSE 连接因为空闲超时被断开了。根因通常是两个：
一是服务端某个环节卡住了，长时间没推送消息，超过了代理或客户端的空闲超时阈值。解决办法就是上面说的加心跳。
二是单个环节耗时太长，比如验证 50 条链接，如果串行做，每条 2 秒，就是 100 秒没有进度推送。我的做法是把验证环节改成并发，每完成一条就推一次进度，既快又有反馈。
注意：SSE 的空闲超时阈值在不同环境下不一样，有的代理默认 60 秒，有的 30 秒。心跳间隔设成 15 秒是比较保险的，能覆盖绝大多数环境。
5. Next.js 这边的工程细节：别让前端成为瓶颈
5.1 路由结构怎么划分
整个应用我分了三个主要路由：
/：输入页，填目标岗位和你的条件/radar/[sessionId]：进度页，展示 SSE 推送的实时进度/report/[reportId]：报告页，展示最终结果
进度页和报告页分开是有意的。进度页只负责展示进度，报告页只负责展示结果，职责清晰。用户刷新进度页不会丢数据，因为 sessionId 在 URL 里，服务端能根据它恢复状态。
5.2 报告页的"薪资可点开验证"怎么实现
这是整个项目的核心卖点，实现上其实不复杂，但细节很重要。每条岗位的薪资旁边有个小图标，点开弹出一个抽屉，里面显示：
- 薪资数值
- 来源链接（可点击跳转）
- 抓取时间
- 验证状态（已验证 / 未验证 / 存疑）
验证状态的判定逻辑是：如果薪资是从岗位详情页的结构化字段里直接读到的，标记"已验证"；如果是从正文里用正则或模型抽取的，标记"存疑"；如果压根没找到薪资信息，标记"未验证"。
function getSalaryStatus(job) { if (job.salary_source === 'structured') return 'verified'; if (job.salary_source === 'extracted') return 'doubtful'; return 'unverified'; }这个设计的意义在于把不确定性透明化。用户看到"存疑"的薪资，心里有数，不会盲目相信。这比那种把所有数据都包装成"精准"的做法要诚实得多，也更实用。
5.3 数据持久化用 Payload 还是直接上数据库
热词里有next.js payload教程，Payload 是个不错的 headless CMS，但在这个项目里我最后没用它。原因是：我的数据结构比较固定，就是岗位、报告、会话三张表，用 Payload 反而增加了一层抽象，查询还要走它的 API，不如直接用数据库来得直接。
我用的是 Postgres 加一个轻量的 ORM。岗位表按job_id建唯一索引，避免重复采集；报告表存 JSON 快照，因为报告一旦生成就不应该再变，存快照比每次重新计算要稳。
如果你要做的是内容型项目，Payload 很合适；但如果是这种数据流水线型的项目，直接上数据库更省心。工具选型要看场景，不要因为某个工具火就用它。
6. 实测踩坑记录：那些文档里不会写的问题
6.1 并发采集把目标站点打挂了
第一次跑全量采集，我图快，开了 50 个并发。结果目标站点直接返回 429（请求过多），后面所有请求全挂。更糟的是，我的 IP 被临时限流了，接下来半小时啥也抓不到。
后来我改成了令牌桶限流，每秒最多 3 个请求，并发控制在 5 个以内。虽然慢了点，但稳定。50 条岗位大概 20 秒抓完，完全能接受。
const limiter = new TokenBucket({ rate: 3, capacity: 5 }); await limiter.acquire(); const res = await fetch(url);这个教训很实在：采集类任务，稳定比快重要。你把目标站点搞挂了，自己也拿不到数据，双输。
6.2 模型偶尔返回带 markdown 包裹的 JSON
Seed-2.1-pro-0915 大部分时候返回的是纯 JSON，但偶尔会抽风，返回json ...这种带代码块标记的。直接JSON.parse会报错。
我的处理是先做一层清洗：
function cleanJSON(text) { let cleaned = text.trim(); if (cleaned.startsWith('```')) { cleaned = cleaned.replace(/^```(?:json)?\n?/, '').replace(/\n?```$/, ''); } return JSON.parse(cleaned); }同时在 prompt 里明确要求"只输出 JSON，不要任何额外文字或代码块标记"。双保险。
6.3 薪资字段的"面议"陷阱
中文岗位里"薪资面议"出现频率极高。一开始我把它当成缺失值，直接跳过。后来发现这样会漏掉很多岗位。
正确的做法是：把"面议"作为一个特殊值保留，在打分时给一个中性分（比如 0.5），并在报告里明确标注"薪资面议，建议面试时确认"。这样既不丢失岗位，也不误导用户。
类似的还有"8k-15k·13薪"这种带薪数标注的，解析时要单独处理·13薪部分，否则薪资区间会解析错。
6.4 报告生成后的缓存策略
报告一旦生成，内容就固定了。我在报告表里存了完整的 JSON 快照，用户再次访问同一个 reportId 时直接读快照，不重新计算。这样既快又省模型调用。
但有个细节：快照里要记录生成时间。如果用户隔了一周再来看，报告里的岗位可能已经下架了。我在报告页顶部加了一行提示："本报告生成于 X 月 X 日，岗位信息可能已变化，建议重新生成。" 这种诚实比假装数据永远新鲜要好。
7. 关于 Agent 并发和稳定性的一些实战体会
热词里ai agent 怎么扛并发这个问题问得很好，我在这上面也交过学费。
Agent 和普通 API 最大的区别是：单次调用耗时长、成本高、有状态。普通 API 你并发 100 个请求可能没啥事，但 Agent 并发 100 个，模型调用费用瞬间爆炸，而且很多 Agent 环节是有状态的（比如采集进度），并发处理不好会互相干扰。
我的做法是分层限流：
- 采集层：令牌桶限流，控制对目标站点的压力
- 模型调用层：信号量控制，最多同时 10 个模型调用
- 报告生成层：队列串行，一个用户一个报告，避免资源争抢
const modelSemaphore = new Semaphore(10); await modelSemaphore.acquire(); try { const result = await callModel(prompt); } finally { modelSemaphore.release(); }这样即使有 100 个用户同时用，系统也不会崩，只是排队慢一点。宁可慢而稳，不要快而崩。
另外，每个 Agent 环节都要有超时和重试。模型调用偶尔会超时，设置 30 秒超时，失败重试 2 次，还失败就标记该条为"解析失败"，不要让整个流程卡死。
8. 这套东西还能怎么扩展
跑通之后我发现这个架构其实挺通用的，核心就是"采集-解析-打分-验证"四段式，换个领域就能复用。
比如做租房雷达，把岗位换成房源，薪资换成租金，技术栈换成通勤距离和户型要求，逻辑几乎不用改。做二手交易雷达也一样，采集商品、解析价格和成色、按你的预算打分、验证卖家信誉。
关键的可复用点是那套数据契约和 SSE 进度推送机制。契约定义清楚了，换领域只是换字段；SSE 机制搭好了，任何长耗时任务都能套上去。
我个人在实际操作中的体会是：做 Agent 项目，别一上来就追求"全自动、端到端"。先把每个环节单独跑通、单独验证，再串起来。我一开始想一步到位，结果调试成本高得离谱。拆成四段之后，每段都能单独测，出问题一眼就能定位。这个思路我觉得比任何具体的技术选型都重要。
