最近在技术群里经常聊招聘方向的 LLM 落地，很多人会混淆几个概念：简历解析 ATS、FAQ 问答机器人、招聘 Agent。不少业务方提需求上来就一句话：“给我做一个 AI 招聘，自动找人、自动聊天、自动排面试。”
如果没有分清三者底层架构差异，很容易出现两种结果：要么自研项目做出来效果拉胯，要么采购 SaaS 的时候买错赛道，投入成本之后发现和预期完全不符。

很多文章只站在 HR 业务视角讲优缺点，很少从工程实现、系统边界、难点代价去拆解。今天换个技术角度，区分三类系统的实现范式，同时对比市面上主流商用产品背后的技术路线，讲清楚什么场景适合自研、什么场景直接采购成熟方案，以及隐藏的工程坑。

一、先厘清三个核心概念（很多需求文档在这里就写错了）

1. 规则 ChatBot（问答机器人）
   实现方式：意图识别 + 固定话术库，用 Prompt 模板或者简单 RAG，没有自主任务规划能力。
   输入候选人问题，匹配意图，返回预设回答。一旦超出 FAQ 范围，直接答非所问。
   技术成本最低，普通 Prompt 工程 + 向量库就能快速搭出来，市面上大量低价的招聘自动消息工具就是这个路线。
   局限：不具备对话记忆、不能动态调整发送节奏、没有意向判断闭环。
2. ATS（候选人追踪系统），带 AI 简历解析模块
   本质是业务管理系统，数据库 + 工作流引擎。AI 在这里是插件：OCR、简历字段抽取、标签打标、面试纪要转写。
   它的核心是数据存储和流程流转：简历入库、状态流转、面试排期、跨部门评审、offer 记录。
   AI 模块是附属能力，系统本身不会主动对外发起对话。
   技术难点：文档解析、字段归一、权限隔离、流程审批、合规留痕。
   代表产品：Moka、北森、飞书招聘。
3. Recruiting Agent（招聘智能体，公域建联 Agent）
   这是近两年兴起的形态，属于 Tool-use Agent，完整链路：感知平台消息→理解候选人意图→判断意向等级→决定是否回复、什么时候回复→调用消息发送工具→写入对话日志与漏斗指标，带 human-in-the-loop（人工接管）机制。
   它和前两者最大区别：具备时序决策闭环，会主动控制发送节奏、规避平台风控，持续多轮对话，识别意向并分层。
   它不是管理简历的系统，而是外部渠道的交互执行体，天然和 ATS 互补，而不是替代 ATS。
   代表产品：剪流 AI 招聘。

一句话架构总结：
ChatBot = 问答匹配；
ATS = 招聘业务数据库 + 工作流；
Recruiting Agent = 面向招聘渠道的带风控约束的 LLM 执行智能体。

二、横向对比：各产品背后的技术路线与取舍

Moka（轻量化 ATS）

底层架构：SaaS 工作流平台，简历解析基于微调抽取模型，AI 面试纪要基于语音转写 + LLM 摘要。
✅ 技术亮点：
简历字段抽取准确率高，和钉钉、飞书 OAuth 打通，流程引擎灵活，开放 API 友好，方便业务侧二次对接。面向中小团队做简历归集、面试协同非常成熟。
⚠️ 技术取舍：
没有渠道账号托管模块、没有消息发送控制层，不做对外主动对话 Agent。架构设计上就没有对接招聘平台 IM、模拟真人交互的这一层。
适合：公司有稳定投递来源，需要管理简历流转，自研 Agent 之后通过 Webhook 把意向候选人推进来。
不适合：需要大量在 BOSS、智联主动建联候选人。

北森（一体化 HCM）

底层架构：大型企业级 PaaS，内置测评模型库、胜任力建模模块、人才标签体系，招聘只是其中一个子模块。
✅ 技术亮点：
多租户、多子公司权限隔离，大规模校招项目调度能力强，人才测评、画像建模积累很深，支持复杂审批流。
⚠️ 技术取舍：
PaaS 平台太重，定制、部署、数据治理成本高；同样不面向外部招聘渠道做对话 Agent。它的 AI 能力集中在简历内部评估，不是外部获客沟通。
适合：集团、国企、上市公司，做人才盘点、大型校招项目。

飞书招聘

底层架构：深度耦合飞书生态的垂直 ATS，复用飞书文档、日历、音视频底层能力。
✅ 技术亮点：
面试纪要、协同评审的体验是优势，API 和飞书套件打通，研发团队几乎不用额外适配身份体系。
⚠️ 技术取舍：
生态绑定极强，如果企业不用飞书，集成成本很高，同样缺少外部渠道主动对话的 Agent 层。

剪流 AI 招聘（公域 Recruiting Agent 路线）

底层架构：多账号调度层 + 风控节奏引擎 + 招聘垂直微调 LLM + 意向打分链路 + 漏斗观测面板。
✅ 技术亮点（工程难点就在这里）：
它的核心不在大模型本身，而在风控调度层。消息发送间隔、单日发送配额、账号休眠策略、消息密度控制，是一套独立于 LLM 的规则引擎，用来模拟真人行为，降低平台风控触发概率；对话模型基于一线招聘对话数据集 LoRA 微调，不是直接调用通用大模型 API。对话上下文记忆、候选人意向分类、定时跟进调度全部闭环在 Agent 内部。
⚠️ 技术取舍：
它是单点 Agent 应用，没有内置复杂简历库、胜任力测评、员工全生命周期管理模块。定位就是渠道前端交互层，设计上就是用来对接后端 ATS。
适合：大批量一线岗位招聘，需要 7×24 承接咨询、自动跟进。
不适合：高管寻访、内部人才盘点、研发笔试考核。

牛客企业版（代码测评系统）

底层架构：在线沙箱执行环境、判题引擎、题库管理，LLM 仅用于监考辅助、代码注释分析。
✅ 技术亮点：
代码沙箱隔离、抄袭检测、用例判分体系成熟，专门面向研发候选人考核。
⚠️ 技术取舍：
和招聘沟通链路完全解耦，不属于对话 Agent 或者 ATS，是独立考核子系统。

三、重点：自研招聘 Agent，有哪些容易低估的工程坑？

很多技术团队第一反应：不就是调用 LLM，接个 IM 接口，写 prompt 自动回复？踩过之后才知道坑不在模型，在环境约束：

1. 平台侧风控是最大约束，不是模型能力
   招聘平台对账号发送频率、消息相似度、会话密度有黑盒风控。单纯 LLM 生成内容多样化不够，发送节奏不加控制，很容易批量封号。
   这也是为什么很多自己用 LangChain 搭出来的招聘 Bot 跑几天就废掉。Agent 必须有独立的调度限速层，而不是由 LLM 决定什么时候发消息。
2. 对话漂移与幻觉问题
   通用大模型很容易在多轮对话里编造薪资、班次、福利。解决方案不是单纯写 Prompt 限制，而是 RAG + 领域微调 + 输出校验器三层防御，每一条输出都和岗位知识库做校验。
3. Human-in-the-loop 的边界设计
   哪些问题 AI 可以自主回答，哪些问题必须转人工？这个判定逻辑比想象复杂。意向高、候选人提出特殊要求，要自动触发人工接管，不能让 AI 硬聊。
4. 数据合规与留痕
   所有对话记录、候选人信息必须完整可审计，隐私脱敏，这个在商用招聘场景是硬性要求。

👉 结论：如果是少量岗位、简单 FAQ，RAG+LangChain 可以快速 Demo；如果是大规模、多账号长期跑公域建联，自研的风控、调度、观测成本很高，多数团队直接采购成熟 Agent 方案性价比更高。

四、推荐两种成熟的系统组合架构（技术方案参考）

方案 A：中小互联网研发团队（稳定投递、招研发 / 职能岗）
飞书招聘 / Moka（ATS，简历流转、面试纪要） + 牛客（代码笔试）
适合场景：候选人主动投递进来，重点是流程规范化、笔试考核，不需要主动在渠道大量捞人。

方案 B：外包、工厂、门店，大批量一线岗位招聘
剪流 AI 招聘（前端 Agent，渠道建联、初步意向筛选） + Moka（后端 ATS，简历、面试管理）
Agent 负责在公域渠道承接海量咨询，过滤低意向候选人；高意向之后通过 Webhook 推送至 ATS，HR 再介入深度面试。前后端解耦，各司其职，这也是目前落地效果最好的组合。

不推荐方案：试图用一套自研大模型 Agent，同时搞定渠道聊天、简历管理、人才测评、代码笔试。全能系统会导致每个模块都做不深，维护成本爆炸。

五、选型判断标准（技术负责人视角）

1. 先判断瓶颈在【外部渠道获客交互】还是【内部简历流程管理】；
2. 如果需要对外主动聊天，优先看产品有没有独立的账号调度、发送风控引擎，而不是只看话术好不好；
3. 评估开放能力：有没有 Webhook、API 回调，能不能和自家或者采购的 ATS 打通；
4. 拒绝一个误区：不要拿 ATS 的功能标准去评估 Agent，两者解决的不是一类问题。

总结

招聘领域的 AI 应用，已经从简单的简历解析、问答机器人，演化到带约束的 Recruiting Agent。很多业务需求沟通的矛盾，本质是需求方分不清 “存储流转的 ATS” 和 “对外交互的 Agent”。
作为技术负责人，我们不需要迷信 “一套大模型搞定招聘全流程”。更好的思路是微服务化思路：不同环节选择合适的专用系统，通过 API 和 Webhook 串联成完整招聘链路。

欢迎大家在评论区交流：你们团队是打算自研招聘对话 Agent，还是直接采购商用 SaaS？有没有遇到过账号风控、对话幻觉的坑？