每到招聘季信息焦虑都会准时出现。一边是海量岗位在多个渠道反复出现一边是简历要根据不同 JD 调整、网申要在不同平台完成、面试复盘散落在微信和文档里。最近我看到一个项目的定位很有意思一款 Agent想做千万毕业生的“求职搭子”标签是“水下项目”。单看这句话会觉得它讲的是陪伴感。但顺着 Agent 产品落地的工程视角往下想事情远没有“陪你找工作”这么轻松。“求职搭子”这个词听起来轻盈实际要承担的却是相当重的任务解析岗位、比对自己经历、修改简历、准备面试、管理投递节奏。如果只是做到“能聊天”它连一个求职助理的门槛都还没摸到。一个 Agent 要想成为千万毕业生的搭子前提是把一段复杂的求职流程变成一条可运行、可追踪、可复盘的任务流水线。这才是这类产品真正值得被技术人关注的地方。1. 先搞清这个 Agent 到底要做“聊天”还是“跑任务”很多人很容易被“搭子”这个词带偏觉得产品重点应该是情绪陪伴、日常聊天、情感支持。真实求职场景里用户更需要的是有人能替他把大量重复、机械、高信息密度的工作先筛一遍。用户真正愿意长期使用的求职 Agent一定不是只会说“加油”的聊天窗口而是能帮他从“我不知道该做什么”推进到“下一步应该做什么”的系统。1.1 用户说的“搭子”和工程师眼里的“工作流”不是一回事如果你长期看 Agent 类产品会发现一个现象不少团队先把产品做成一个能对话的窗口然后用户问一句它答一句。对话本身没有错但单轮问答很难承载复杂任务。求职不是“今天问一个问题明天再问一个问题”就能结束的事它需要用户在一个较长周期里输入简历、挑选岗位、持续准备、反复复盘。在这种场景里工程师的任务是先拆工作流输入什么简历、目标岗位、所在城市、行业偏好、投递渠道。输出什么岗位推荐、简历优化建议、面试问题、复盘记录、下一步行动清单。过程要记录什么用户看过哪些岗位、投了哪些公司、每一轮面试反馈怎么样、哪类问题回答得不够好。如果只做一个聊天机器人这些过程会全部散落在对话记录里无法变成可复用的结构化数据。真正的求职搭子应该具备把“聊天内容”沉淀成“任务状态”的能力。1.2 第一层拆解求职搭子的最小任务闭环我习惯把一个求职 Agent 的最小闭环拆成下面几个阶段。第一阶段是建档。用户的简历不是一段可以被随意扔进 prompt 的文本它需要被解析成结构化信息教育经历、实习经历、项目经历、技能清单、时间线和自我评价。没有这一步后面所有岗位匹配都不可靠。第二阶段是选岗。Agent 需要从几个真实的岗位源里拉取 JD提取企业、职位、工作地点、薪资范围、岗位职责、任职要求。这里最难的不是“生成总结”而是能不能保证岗位信息新鲜、真实、不过时。第三阶段是匹配。把用户画像与岗位要求做对照输出“哪些技能匹配、哪些经历是加分项、哪些地方可能成为短板”。好的匹配不是只给一个分数还要能解释理由。第四阶段是优化。针对匹配度高的岗位生成简历优化建议。注意这里的建议不能无中生有不能替用户编造一段并不存在的项目经历而是基于用户已有经历调整表达重心。第五阶段是面试模拟。Agent 扮演面试官根据真实 JD 连续追问。用户回答后它既要指出表达问题也要帮用户准备更充分的回答方向。第六阶段是复盘。记录每一次投递和面试结果形成一个个人求职看板。用户在第三周回来时Agent 能知道之前聊到哪、投过什么、面试结果怎样而不是重新认识一个陌生人。这六个阶段并不都需要用最新的大模型技术有些环节用规则就能做有些环节必须依赖 LLM 的判断力。但完整闭环本身决定了它是否是一个能真正被使用的产品。1.3 不要把“生成”当成“完成”我见过很多 Agent 演示最后只停在模型生成了一段建议。模型确实能生成很好的文字但生成结束不等于任务完成。如果用户的投递资料仍然散落在本地如果 Agent 生成的简历版本没有保存记录如果面试复盘无法在下次对话时被调出来那么所谓“搭子”其实只是换了一种形式的搜索框。用户仍然要自己做大量复制、粘贴、对比、整理工作。真正有价值的变化是让 Agent 从“生成内容”进化为“处理状态”。用户不再需要记住自己投了哪些公司因为 Agent 会帮他把状态保存下来用户也不再需要反复上传同一份简历因为 Agent 已经建立过用户档案。这种从“对话式工具”到“流程化产品”的跨越才是求职 Agent 区别于普通聊天机器人的地方。2. 这类产品要跑到正规使用核心难点不是模型而是可被追踪的流程一个 Demo 级的求职 Agent 做起来不难拿一份简历切几段文字让大模型总结能力再调用几个接口看起来就能工作。但在真实毕业生使用中问题会很快暴露昨天刚聊过的目标岗位今天它忘了简历里写的技能它为了匹配岗位擅自扩写岗位库里的信息已经过期它还在当作事实推荐给用户。这些问题本质上不是模型能力不足而是工程链路没有做扎实。2.1 Agent 记忆决定它像不像一个真正的长期搭子求职过程通常以月为单位不是一次会话就能结束。如果 Agent 没有记忆每次对话都从零开始那么用户每次都要重复说明自己的背景。这会让本来应该提高效率的产品变得更加低效。实现长期记忆有两种常见路径把关键信息写入结构化存储比如数据库表用户的基本资料、求职偏好、已投递公司、面试反馈、简历版本记录。把简历和岗位文本向量化放入向量库支持后续检索。比如用户问“上次那个要求英语流利的岗位怎么样了”Agent 能先从记忆库中找到对应对象。真正值得注意的坑是不要把所有历史内容全部塞进上下文。长期记忆的价值在于“选择性召回”而不是“无限堆叠”。一个合理的做法是系统启动时先只加载用户最近一次任务状态和核心档案等到用户询问细节时再按需检索相关历史。如果项目团队在标题里强调“水下项目”我猜测它想做的是不被短期热度带偏的产品。求职 Agent 的记忆模块恰好是最需要长期投入、但短期不容易被看到效果的部分。2.2 岗位信息源和新鲜度决定 Agent 会不会一本正经地“编造”岗位推荐是最容易出问题的环节。模型天然擅长生成一段像模像样的职位描述但如果它没有真实的数据源就会把“看起来合理”当成“真实存在”。一个负责的 Agent 必须建立真实岗位数据链路。常见做法是只允许 Agent 调用经过授权的岗位数据库或企业官方招聘渠道。对拉取到的岗位做结构化解析保存发布时间、截止时间、岗位链接、原文标题和职责描述。当模型回答某个岗位是否存在时必须基于检索到的结果而不是基于参数记忆。如果岗位源更新有延迟需要明确告诉用户“数据更新至某个时间点”不能让用户误以为这就是实时招聘市场。这也是为什么“搭子”不能是一个完全自由发挥的大模型。它更像一个“有信息边界的执行者”只能在真实数据范围内提供建议。超出数据范围时它能承认不知道而不是编造一个岗位来安慰用户。2.3 反幻觉和评估集是上线前最容易欠的技术债简历优化里有一个特别危险的场景Agent 为了帮用户提高匹配度很可能会在改写简历时添加用户原本没有的经历或技能。这在演示视频里看起来效果很好实际却会给用户带来巨大风险。因为面试官一旦追问细节用户答不上来会直接影响信誉。所以求职 Agent 需要在产品约束中加入一条原则所有简历建议都基于原始简历信息模型只能调整表达方式、顺序和重点不能新增事实。如果技术方案没有这一层这个 Agent 就不适合进入真实求职场景。为了验证这类约束是否有效需要建立评估集。建议准备三四十条典型简历样本和岗位 JD 样本人工标注出“推荐结果里是否出现新增事实”“匹配判断是否正确”“简历建议是否可执行”。每次换模型或调 prompt 之后都先跑一遍回归测试。这套评估逻辑看起来和“求职搭子”的定位有点远但恰恰是决定它能否从水下项目浮出来的关键。3. 一套可复现的最小开发路径从零做一个求职搭子如果要把这类产品从想法落到工程实现不建议一开始就搭一个巨大的 Agent 框架。先做一条简单但完整的主链路比先引入微服务、多 Agent 编排和复杂记忆系统更有效。下面不是什么官方标准更接近一种通用实践路径。3.1 先做一个单线程的最小闭环不要一开始就接聊天框可以先做一个后端流水线用户上传简历系统解析结构拉取岗位列表输出推荐和匹配建议。这个流程不依赖用户实时对话也可以批量运行。def run_job_search_agent(user_data, job_sources): # 1. 解析用户简历形成结构化档案 profile parse_resume(user_data[resume_file]) # 2. 从授权数据源拉取岗位 jobs fetch_jobs(job_sources, user_data[filters]) # 3. 对岗位做匹配得到结构化结果 matches [match_profile_to_job(profile, job) for job in jobs] # 4. 只对匹配度最高的几个岗位生成简历建议 top_matches sorted(matches, keylambda x: x[score], reverseTrue)[:5] suggestions generate_suggestions(profile, top_matches) # 5. 保存到用户空间等待用户确认 return save_task_result(user_data[user_id], suggestions)这段伪代码里最关键的不是模型调用而是fetch_jobs和match_profile_to_job这两步。前者决定了信息源是否真实后者决定了匹配结果是否可解释。完成这条主链路之后再考虑把每一步变成对话入口。用户对 Agent 说“帮我找几个北京的产品岗”其实就是触发一次带筛选条件的run_job_search_agent。对话只是前端交互流水线才是产品本体。3.2 简历解析从 PDF 到结构化 JSON这一步决定后面所有质量简历解析看起来像是一个简单预处理实际上非常影响用户体感。把 PDF 转成纯文本只是第一步真正的难点是字段提取。一份普通毕业生简历里的字段大致包含字段可能存在的问题教育经历时间格式不统一学校、专业、学历嵌套在一起实习经历公司名和岗位名混在一起时间跨度不易解析项目经历描述自由度高难以判断“用户承担角色”和“项目结果”技能清单同一技能有多种表达Python / python / 使用 Python时间线不同经历之间有空档模型可能自动脑补由于后面所有简历建议、岗位匹配都依赖这些基础字段解析阶段必须保守处理。对于拿不准的内容宁可标成“待确认”也不要强行猜测。一个字段解析错误可能让后面的建议全部偏离。如果使用大模型做抽取建议规定一个输出 JSON Schema让模型只输出结构化字段不输出多余解释。{ basic_info: { name: , phone: , email: }, education: [ { school: , major: , degree: , start: 2021-09, end: 2025-06 } ], work_experience: [ { company: , title: , start: , end: , achievements: [] } ], skills: [] }如果用户简历里缺信息就让 Agent 主动询问而不是在后续生成里自动补全。3.3 JD 对比和匹配度解释不要只给一个分数很多简历匹配工具会输出一个综合分比如“匹配度 85%”。可用户真正想知道的是这个分数从哪来我到底差在哪我应该改写哪一段经历。比较稳妥的做法是把匹配过程拆成几个可对照的维度岗位要求JD 原文简历中的对应内容匹配判断熟悉 SQL 和数据分析能独立完成数据提取与分析实习期间使用 SQL 做用户留存分析匹配有增长项目经验负责过完整增长活动简历中只有日常运营没有独立活动部分匹配英文可作为工作语言能用英文面试简历未体现英文水平待确认让 Agent 输出这种结构化对照比只输出一个分数更可信。用户看到“部分匹配”时也会更愿意接受下一步优化建议。在做匹配时还要避免一个倾向模型为了讨好用户总是给出“你很合适”的结论。好的 Agent 应该能说实话。如果某个 JD 明确要求 3 年以上经验而用户是应届生直接指出差距比委婉建议要有用得多。3.4 面试模拟和复盘从“一次生成”到“多轮追问”面试模拟是最容易让用户感觉到“Agent 真的懂我”的模块。但如果只生成一组题库让用户自己回答体验其实很单薄。更好的方式是多轮追问。例如 Agent 可以这样开场“我看到你想投字节跳动产品运营岗JD 里特别强调了数据分析能力和活动策划经验。接下来我会以面试官身份问你 3 个问题。你回答之后我会先做口头点评再追问一个细节。”第一问请分享一个你从数据中发现问题的项目。 用户回答后Agent 不是急着跳到下一题而是追问 “你提到用户活跃度下降了 15%当时你把原因确定为内容改版。这个判断是怎么排除其他因素干扰的”这种追问会逼着用户进一步复盘自己的真实经历。如果用户发现自己回答不了Agent 可以基于用户已有经历给出“可以补充哪些信息”的提示而不是替用户编造回答。面试结束后生成复盘记录哪些问题回答得比较完整。哪些问题逻辑链缺失。如果重新回答可以按什么框架组织语言。这些记录如果保存下来会在下一次模拟前被重新调用。这才是“搭子”比一堆面试题库更有价值的地方。4. 从 Demo 到能长期使用参数、编排和排查链路我接触到不少开发者做 Agent 时容易在两个方向走极端。一种是什么都自己写连最简单的解析也硬编码另一种是一上来就上复杂框架引入对话记忆、多个 Agent、多渠道工具结果很多时候不知道问题出在哪个环节。这两种方式在求职 Agent 这种“周期长、状态多、错误影响大”的场景里都容易失控。4.1 Agent 框架、Skill、记忆组件怎么选现在能看到很多 Agent 相关讨论比如 Agent 框架、Skill、记忆、编排。它们听起来很有体系但落地时要先分清先后。以求职搭子为例第一层是任务层。先确定用户任务建档、选岗、匹配、优化、模拟面试、复盘。第二层是工具层。一个工具负责解析简历一个工具负责拉取岗位一个工具负责保存记录。可以把它们理解成可被复用的函数或 Skill。第三层是决策层。大模型根据当前任务选择调用哪个工具并决定输出格式。如果 Agent 需要处理多个独立子任务可以引入多 Agent 编排如果只是简单流程单 Agent 够用。如果看到一个 Agent 项目引进了 Skill 机制不用觉得神秘。它本质上就是把“简历解析”“JD 匹配”“模拟面试”这些动作封装成可复用的能力包让模型在需要时按名称调用。它的价值是降低主任务分支的复杂度而不是为了炫技。参数层面的提醒是不要一开始就把 Temperature 调得很高也不要一上来就设置超长上下文。“温度高”容易让简历改写出现夸张表达“上下文过长”则容易让模型忽略简历里的关键信息。比较稳妥的做法是先把系统 prompt 和结构化输出跑通再逐步扩展。4.2 最容易被忽略的三个工程问题第一个是日志和会话状态。求职 Agent 不只是一次 API 调用它会经历很多轮次。每次执行完匹配或简历改写都要记录模型输入是什么、调用了哪个工具、返回了什么结果、用户是否确认。否则一旦用户说“你上次给的建议不是这样的”开发者和产品都没法排查。第二个是批量任务限流。用户可能一次性导入 50 个岗位要求 Agent 逐个分析。如果直接并发调用模型很容易把服务打满也容易出现输出不稳定。建议先把岗位批量加入队列限制并发控制每次处理的条数。先算一下单个任务的平均耗时再设置合理并发值。第三个是用户数据隔离与脱敏。简历属于高敏感个人数据。系统里至少要有明确的用户隔离逻辑避免不同用户的数据互相串到上下文对外展示时要隐藏手机号、邮箱等联系方式日志中不要明文打印完整身份信息。这三个问题看起来不性感但决定产品能不能长期运行。短期 Demo 可以忽略真正服务千万毕业生时任何一个都是事故源。4.3 排查链路Agent 理不清信息时怎么办实际使用中用户会给出各种奇怪输入一份图片格式的简历、一个没有 JD 全文的链接、一个已经过期的岗位截图。此时不要直接让 Agent “尽力生成”而是先按链路排查。现象优先检查简历解析字段经常错先看 PDF 转文本是否丢失内容再看抽取时是否缺少数值示例Agent 推荐的岗位与用户要求不符先看筛选条件有没有传给数据源再看排序逻辑是否被模型改写简历建议出现用户没有的经历检查 prompt 里是否把“基于原始简历改写”写清楚并增加输出校验多轮复盘后结果越变越差检查上下文是否覆盖了多轮历史确认是否存在旧信息覆盖新信息用户说“上次说好去投的岗位怎么没记录”检查任务状态是否持久化会话 ID 和用户 ID 是否错位最常见的问题往往不是模型不够聪明而是输入数据本身有问题或者状态没有被正确保存。排查顺序可以固定为先查输入和数据源再查上下文和工具调用日志最后再考虑改模型参数。4.4 不要直接让 Agent 自动投递和发信从技术角度一个 Agent 完全可以做到自动访问招聘网站、自动提交申请、自动发送简历。但在没有极强校验机制的情况下我不建议让它全权代理这些动作。原因很简单求职过程里存在大量无法被模型判断的主观因素。用户可能突然不想投某个公司可能对某个城市临时改变偏好可能希望等面试反馈后再决定下一步。Agent 能辅助生成邮件、草拟自荐信、准备好附件但最终发送动作应该由用户确认。更合理的自动化边界是让 Agent 负责所有“准备动作”让用户保留“最终决策”。这样做不仅更安全也更符合真实求职场景里的控制感——用户始终知道自己在做什么。5. 求职搭子真正改变的不是“投简历”而是求职工作流回到最开始的标题一款 Agent想做千万毕业生的“求职搭子”。我觉得它的价值不在于“帮用户投出更多简历”而在于把求职这种长周期、强流程、高焦虑的事情逐步拆成可以被数据记录和优化的系统。5.1 适合谁不适合谁我不认为求职 Agent 对所有毕业生都是必需品。它的适用场景首先要足够结构化。适合不太适合第一次参加校招、对流程不熟悉的毕业生主要通过内推和强人脉推进求职的用户需要海量筛选岗位、整理 JD 的用户更依赖面对面的行业判断和内部信息的用户简历写作经验不足需要反复改写的用户简历已经很成熟且目标明确不愿接受模板化建议的用户需要面试陪练和复盘记录的用户只希望“自动帮我投递并保证通过”的用户需要长期跟踪投递状态的人对数据隐私和使用风险敏感且不信任 AI 工具的人如果产品想服务的是“千万毕业生”更需要理解这些边界而不是试图覆盖所有人。对适合的人来说Agent 能省下大量机械整理时间对不适合的人来说Agent 只能产生更多噪音。5.2 从 Agent 范式角度这个项目能带来什么启发把一个求职 Agent 工程化之后你会发现它几乎覆盖了 Agent 产品的所有核心问题工具调用、结构化输入输出、长期记忆、状态管理、防幻觉、安全边界、多轮交互。这也是为什么 Agent 领域的学习者经常从“求职助手”类项目入手。它不仅业务场景足够真实还能逼着你把技术栈做深。热搜里经常出现 Agent 开发、Agent 架构、Agent 记忆、Agent 面试题本质上都是开发者开始从“会调用 API”向“能搭建可靠 Agent”过渡。一个能在真实求职场景里被信任的 Agent至少要满足三点信息有来源不编造岗位不编造简历事实。过程可追踪用户知道 Agent 为什么给出这个建议。边界清晰什么时候该建议什么时候该让用户自己决策。这三点恰好是大多数 Agent 应用从半成品走向产品的分水岭。5.3 “水下项目”给我们的提醒先把水面之下的部分做扎实“水下项目”这个定位我理解成一种产品策略先不急着把声量做大而把水面之下的流程、记忆、评测、数据边界先打磨扎实。这个选择很务实。因为求职 Agent 不像娱乐聊天产品它可以容忍俏皮话但不能容忍错误信息。用户可能因为 Agent 编了一个岗位而错过真实机会也会因为 Agent 改写简历时多加了一段虚假经历而在面试中陷入尴尬。这些风险意味着产品必须在水下完成大量可靠性工程才能浮到水面上被更多人使用。如果你打算做一个类似的 Agent可以先把上面的最小闭环跑通再用真实用户测试观察在哪个环节开始出现记忆丢失、信息编造、状态混乱。修复这些深水区的问题比界面好不好看、话术像不像“搭子”更重要。等有一天某个毕业生真的因为这个 Agent 省下了大半个月的时间理清了自己的投递节奏也敢在模拟面试里把薄弱回答反复练到自然那个时刻才是它真正配得上“千万毕业生求职搭子”这个名字的时刻。