这个标题拆开看，其实是一个很典型的自动化系统问题：一个招聘公告板（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 代理。即使
