这个标题拆开看其实是一个很典型的自动化系统问题一个招聘公告板job board里雇主不是人意味着职位发布、简历筛选、候选人沟通、面试时间协调都由 AI 代理和一堆脚本代替。Demo 阶段感觉哪都很顺一旦真实的候选人投递量起来各种之前没想过会坏的地方就全冒出来了。下面按我的实测顺序拆重点说那些容易让系统直接停摆、或者让候选人体验崩掉的细节。1. 先把“雇主不是人类”翻译成系统需求“雇主不是人类”并不是说把一个聊天机器人挂在网站首页。它意味着整个招聘公告板的核心流程里没有一个人去读简历、没有一个人写拒信、没有一个人确认面试时间。企业或者说职位发布方可能只是在后台配置了一堆关键词、评分权重和自动动作此后系统的 AI 代理会根据这些配置去完成所有面向候选人的动作。这种设计的好处是效率高、响应快代价是早期常见的错误没有人能人工兜住。要理解后面那些故障先把链路拆开。一个应聘者从投递到结束至少要经过这些环节创建职位雇主配置职位名称、技能要求、经验年限、地点、薪资区间、筛选权重。发布与展示职位进入公告板可能调用外部通知来提醒匹配候选人。简历投递候选人上传 PDF 或录入在线简历。简历解析把非结构化内容提取成职业经历、技能、学历、联系方式等结构化字段。初筛与评分AI 代理基于预设策略给候选人打分输出“面试/备选/拒绝”三类建议。面试协调通过日程代理查找空闲时间向候选人和面试官发送邀请。反馈与跟进候选人面试后系统自动收集反馈、维护状态直到最终 offer 或结束流程。这个链路看起来不复杂但每一环都有崩溃点。环节之间依赖越强问题连锁反应越明显。比如简历解析失败后续评分和通知就会全部空转职位配置里如果缺少筛选规则AI 代理就会用自己的“经验”自由发挥结果就是同一天提交的两个应聘者收到的反馈标准完全不一样。所以第一件事不是设计炫酷的 AI 交互界面而是定义清楚系统边界。哪些环节必须全自动、哪些环节可以失败后等待人工处理、哪些环节需要记录原始上下文必须在开始写代码之前定好。否则后面每修一个问题都会牵动整条链路的输出格式和状态流转。1.1 这里的“雇主”到底是什么在独立开发者的测试项目里“雇主”完全可以是一段配置好的 Agent。它读取职位描述和候选人的评分摘要然后调用邮件接口发通知。在真实生产系统里雇主可能是一个企业后台里的自动招聘策略模块或者人力资源系统对外开放的 API。不管哪种形态开发者的任务都是把“雇主”的意图固化成一堆可执行的规则和数据模型。比较常见的错误是把“AI 代理”当成一个能处理一切的黑盒给它一个职位描述就让它自己决定怎么筛选、怎么沟通。这种设计在少量测试候选人时有新鲜感但很难稳定。因为 AI 代理的输出不是确定性的同一个职位在三次运行里可能给出三套不同的筛选维度。正确做法是把 AI 代理放在一个有限决策空间里。它负责评分、写摘要、生成沟通内容但做不了决定——因为决定权在规则引擎和人工复核流程那里。1.2 一条申请从创建到 offer 需要经过几个环节建议在动手前先画一张状态图把申请单的状态穷举出来。常见状态包括已投递、解析中、解析失败、评分中、待人工审核、面试待确认、面试已确认、面试完成、已通过、已拒绝、已过期。状态和状态之间要有明确的动作触发。比如“解析中”到“评分中”必须依赖解析结果成功“评分中”到“面试待确认”必须依赖候选人分数超过预设阈值。这里有一个经验状态越少越不容易出错但可追溯性越差。状态拆得太粗出问题时不知道卡在哪一步拆得太细又容易因同步问题产生分叉状态。我的建议是先把核心状态控制在 8 到 10 个额外的信息放记录字段而不是状态字段。你后期会发现大批量故障里反复出现的不是“少了一个状态”而是“状态被重复更新”和“状态顺序被颠倒”。2. 最先出问题的是输入输出格式不是模型能力做这类系统很多开发者一开始担心的是模型不聪明、筛选不准。实际上跑起来以后首先崩掉的往往是格式问题。2.1 AI 代理返回了不可解析的结果AI 代理如果直接使用通用文本输出来生成职位描述、筛选理由、回复邮件在单条场景下是能看到的因为人眼能理解。但一旦接入自动化管道下一个环节是代码代码只认结构化数据。最常见的情况是AI 返回了一段包含 Markdown 表格、冒号、制表符的文本后端按 JSON 解析直接报错或者 JSON 字段名变了本来应该是 skill_experience_years它写成了 skill_years。解决办法是两层。第一层调用 AI 接口时尽量启用结构化输出能力比如 JSON Schema 或函数调用把返回字段明确限定。第二层在后端加一个 schema 校验而不是直接信任模型输出。校验不通过时最好附带原始文本重试一次让模型基于“上次返回无法解析”这个错误再输出一次。这样做比直接判失败更有效也能把偶发的解析失败率降下来。一个简单的输出示例大概是这样的{ candidate_id: app_20250301_001, skill_match_score: 4, experience_years: 5, summary: 候选人在后端服务方面有五年经验 }如果模型返回的 summary 里混进了评分字段或者 experience_years 写成了字符串“五年”校验层立刻就能发现并决定是重试还是进入人工处理池。2.2 简历解析PDF、DOCX 和扫描件各有各的坑简历解析在这个系统里承担的是“眼睛”角色。它的稳定性直接决定后续所有环节能不能跑。实测里遇到最多的问题集中在三类PDF 使用表格布局解析后字段顺序全部乱了扫描件或图片型 PDF不经过 OCR 之前提取出来是空内容DOCX 模板不同有的把技能写在页眉有的写在侧边区简单的段落提取会漏掉关键字段。不要一开始就追求解析器完美。先做失败分类明确哪些文件是“解析成功但字段缺失”哪些是“完全无法读取”两类走不同逻辑。解析成功但字段缺失的可以继续用低置信度标记走评分流程完全无法读取的应该直接进入人工处理池或者让候选人手动补充在线简历不要让候选人流程静默失败。2.3 评分字段要结构化不能靠自由文本见过一个典型问题测试效果挺好AI 代理读取简历后直接生成一段自然语言评价人力资源那边觉得“看起来很有洞察”。但这套流程在自动化回传阶段就会卡住因为后续系统不知道如何把“候选人在写后端接口方面有经验”转换成数量化的评分。更合理的做法是把评分拆成固定维度技能匹配度、经验时长、教育背景、稳定性、可联系性。每个维度由 AI 打一个 1 到 5 分并给出依据最后加权汇总。这样既能保留 AI 判断的灵活性又能让规则引擎在阈值判断时使用确定性输入。如果某份简历缺失某维度信息应该显式标记为 unknown而不是默认给 0 分否则会把“没有提到”和“不满足”混为一谈对候选人不公平。3. 并发投递一上来队列和幂等才是真正的临界点格式问题解决之后下一个问题出现在什么时候往往是某个职位被外部渠道引了流量半小时内投递量涨到几十倍。此时最先扛不住的往往不是 AI 模型而是消息队列、数据库和重复处理机制。3.1 高并发时的三种常见故障第一种是解析服务被打爆。简历解析是个外部依赖或者计算密集的服务每秒处理能力有限。投递量一高任务全部堆积超时重试又叠加进来最后队列整体阻塞。第二种是数据库锁竞争。多个消费者同时更新同一条申请单或者对同一个职位 ID 做计数更新会出现锁等待和死锁。尤其是 PostgreSQL 或 MySQL 的行锁在批量更新时特别明显。第三种是重复消费。消息队列在分布式环境下很难完全避免至少一次投递如果消费逻辑没有做幂等同一份申请可能会被解析两次、评分两次、甚至发送两次邮件。高并发不会创造新问题只是把这些问题放大到你能注意到的程度。3.2 幂等性处理重复消息不能触发重复动作幂等设计的核心是给每条业务消息一个稳定唯一 ID。候选人投递简历时在入口生成一个申请 ID后面的每一步都拿这个 ID 做去重。比如消费简历解析任务前先检查该申请 ID 是否已经存在解析结果存在则直接返回不存在才解析。同时在数据库里对申请 ID 的某些关键操作加唯一约束形成双保险。对于发送通知这类有外部副作用的动作幂等更难做。因为你不能保证邮件服务本身会帮你幂等。比较稳的做法是先写通知记录表在发送前插入一条唯一记录插入成功才真正调用邮件接口。这个流程看着多一步但能避免大量重复邮件投诉。3.3 重试策略和死信队列如何设计重试不能无脑“失败就重试”。如果 API 本身超时或者数据库连接池满重试只会拖垮系统。通常可以这样设计第一次失败后等几秒再重试前两次重试间隔短后面的间隔拉长达到最大重试次数后任务进入死信队列死信队列里的任务只做告警和记录不自动重跑。死信队列的价值不只是兜底它能告诉你系统里哪些环节长时间失败。通过统计死信任务集中在哪里你能快速看到是简历解析接口故障、AI 服务配额耗尽还是数据库连接异常。不要觉得“任务失败了我手动改数据就行”在大批量任务场景手动改数据是另一个生产事故来源。4. AI 代理的“自由发挥”问题筛选漂移和自动决策边界当系统能稳定跑起来之后新的挑战转向 AI 代理的决策质量。自动化系统最怕的其实不是运行故障而是没有错误提示的错误决策。4.1 筛选标准漂移是怎么出现的同一个职位月初创建的筛选策略和月末创建的筛选策略很可能不一样因为 AI 代理对“合适候选人”的理解会受到批次、时间、甚至当时上下文的影响。比如第一次运行时 AI 跳过了没有本地工作经验的人第二次可能把“愿意异地办公”也当成加分项。这不是模型坏掉了而是自由文本决策空间的固有风险。解决思路是让 AI 代理每次都基于同一份结构化评分卡做判断而不是重新读取长职位描述。职位描述可以允许 AI 生成但筛选权重必须来自配置卡片。系统在运行过程中记录每一次筛选执行的评分版本并定期抽样对比不同时间段的评分分布。如果发现某个维度的平均分在两周内明显上升或下降就要检查是不是规则被悄悄改动了。4.2 自动拒信、自动面试邀请的风险控制自动拒信是最伤人气的环节。把完全不匹配的候选人自动拒绝问题不大但评分在中位线附近的候选人直接让 AI 发送拒信等于放弃了一个可能合适的人。所以通常会把自动动作分档高分候选人自动发送面试邀请中分段进入备选池不做自动动作等人工或规则触发低分段自动发送拒信但必须限制每日发送量并在邮件中提供反馈入口。自动面试邀请也有细节问题。如果日程代理计算的时间候选人不合适很多系统直接发一个固定时间结果就是大量“改期请求”涌进来。更稳妥的方式是回复一个可选时间列表让候选人选择。表面上看多了一步实际上减少了大量协商消息。4.3 给自动决策留一条人工复核回路不建议把“最终拒绝/最终录用”这两个动作完全交给 AI 代理。即使