我见过不少号称“AI老板”的东西但真正挂着系统跑满四个月、最后给出第一个“开除建议”的这是头一个。这个项目我拆开看了一遍本质是一个基于大语言模型的人事管理 Agent 系统岗位需求丢进去五分钟内自动生成招聘启事并发布到招聘渠道员工入职后它每周自动读日报、盯绩效、分析代码提交到我写这篇复盘的时候它已经对一位连续六周不达标的员工给出了解除建议而且实际执行的是 HRAI 只负责把证据链摆清楚。这套东西非常适合正在做 AI Agent 工作流、大模型部署或者想用 AI 改造人事流程的团队参考里面有不少值得抄作业的设计也有不少必须避开的坑。1. 项目整体设计与思路拆解1.1 为什么想到让 AI 来当“老板”先交代一下背景。这个项目不是公司正规立项是几个工程师闲不住搞出来的内部实验。起因特别朴素团队负责招聘的同事每天被 JD 撰写、渠道发布、简历初筛、面试安排这些流程化的事情绑住手脚一天下来没时间做真正需要判断的面试和谈薪。当时内部已经在用大模型写文案、写代码大家就问了一个问题能不能让大模型把招聘到管理的整条链路串起来答案是可以而且比想象中更顺。招聘启事本质上是“结构化信息 表达渲染”的组合岗位需求是输入JD 是输出渠道发布是接口调用每一环都是可以被工作流框架编排的。真正难的不是生成文字而是怎么让整个链路在无人盯着的状态下稳定跑四个月并且不出乱子。这个项目最值得说的也不是“AI 写了个招聘启事”而是它证明了一件事流程确定性足够高的管理场景完全可以交给 Agent 工作流来做。1.2 系统整体架构四类 Agent 的分工这个“AI 老板”不是一个单体大模型而是由四类 Agent 组成的工作流网络。需求解析 Agent把产品经理或负责人口语化的岗位需求比如“找个搞订单系统的后端最好有高并发经验”转成结构化字段包括岗位名称、职责列表、硬性要求、软性要求、薪资范围、工作地点。JD 生成 Agent基于结构化字段生成面向候选人的招聘启事文本同时控制语气和长度。合规审查 Agent专门检查 JD 里的歧视性表述、年龄限制、性别倾向等敏感内容发现就自动重写。评估管理 Agent负责简历初筛、面试追问、周报分析、绩效打分以及触发预警。前三个 Agent 只在招聘阶段工作真正贯穿四个月的是评估管理 Agent。它每天定时任务读取当天的代码提交记录、工作日志、任务完成状态写入一个绩效指标库。预警模块各自独立某个指标跌破设定阈值并不直接触发处罚只有连续多周多维度不达标才会进入人工复核队列。1.3 为什么选择 Agent 工作流而不是单模型对话最初有人提议干脆做个聊天机器人式的管理助手管理者跟它对话让它给建议。这个方案做演示没问题但跑四个月会出大问题对话型应用的输入不可控今天问绩效、明天问午饭状态管理非常混乱而且没有固定流程很多判断必须依赖上下文记忆模型一旦忘了前两周的数据整个评估就失真了。所以走了 Agent 工作流方案。核心思路是把流程固定在代码里把判断留给模型。比如“每周五晚上八点汇总本周指标”是代码逻辑而“这个候选人的回答是否体现自驱力”是模型判断。代码负责确定性部分模型负责非确定性部分两者边界清楚排查问题也容易。实测下来四个月里真正导致流程中断的故障绝大多数出在接口调用上而不是模型判断漂移上——这正好印证了流程拆分的重要性。2. 五分钟挂出招聘启事核心实现过程2.1 JD 生成的完整处理链先看发布招聘启事这条链路。发起人只需要在系统里输入一句需求比如“招一名资深后端工程师Go 语言负责订单系统重构要求 5 年以上经验有高并发项目经历薪资可以给到 40K办公地点北京。”这句话进去后需求解析 Agent 会把它转成结构化 JSON大致是下面这个形状。配合结构化输出约束模型不会漏字段也不会自己额外发明一个“要求 211 学历”这种根本没人提过的条件from pydantic import BaseModel from typing import List, Optional class JobRequirement(BaseModel): title: str years_experience: int tech_stack: List[str] responsibilities: List[str] salary_range: Optional[str] location: Optional[str] extra_benefits: List[str] [] prompt 你是HR业务助理请从下面的岗位需求描述中提取结构化信息 {raw_input} 要求 1. 只提取原文中明确提到的字段不要推测。 2. responsibilities 概括为主责描述不超过3条。 3. 如果原文没有 salary_range就返回 None。 raw_input 招一名资深后端工程师Go语言负责订单系统重构要求5年以上经验有高并发项目经历薪资可以给到40K办公地点北京。输出 JSON 之后进入 JD 生成 Agent。这一步讲究的是“翻译能力”要把内部语言转成候选人愿意看的话术。比如原文的“有高并发项目经历”会被扩写为“参与过日活百万级系统的接口优化与架构升级”。实测下来GPT 级别的模型直接输出可用的 JD 成功率在九成以上剩下的主要是语气过于生硬。2.2 合规审查环节为什么不能省JD 生成的另一头是合规审查 Agent。这一步是血的教训换来的。刚开始做的时候没有这个环节有一次系统生成的 JD 里写出了“要求男性优先因为需要频繁出差”发布之后差点出大事。后来把合规审查 Agent 单独抽出来专门检查年龄、性别、地域、婚姻状况、民族这几类高风险字段。这个 Agent 的处理逻辑并不复杂先把 JD 文本里所有实体和修饰词抽取出来再做一次敏感类别判定。判定规则既有关键词匹配也有语义判断。比如“年轻有活力”这种说法关键词匹配不到但语义判断会标记为年龄倾向然后自动重写为“能够适应快节奏工作”。当时内部讨论过是否直接用提示词让模型“自我检查”实测效果不稳定还是单独一个 Agent 加规则兜底最可靠。2.3 多渠道发布与实际可靠性设计JD 审核通过后就到了发布环节。这个环节要对接招聘网站、公司官网、内部推荐群、社交频道等渠道。每个渠道的接口格式都不一样有些是标准 REST API有些只能通过机器人往群里发 Markdown。为了把这一步做成“五分钟挂出招聘启事”工程上做了三个关键设计。第一个是适配器模式。每个渠道一个独立适配器底层接口怎么调用上层不关心。新增渠道只需要写一个适配器不需要改动主流程。第二个是幂等控制。发布动作以岗位 ID 为幂等键接口返回超时不能立刻重试要先查询上一条发布请求是否已经成功。否则重试时很容易同一个岗位在网站上出现两次后期删除反而麻烦。第三个是发布后校验。每个渠道发布成功后需要拉取一次页面信息确认标题、薪资范围、工作地点渲染正常防止接口返回成功但页面数据缺失。时间构成方面实测整个过程是这样分配的需求解析加 JD 生成大约 45 秒合规审查 5 秒渠道发布 2 分钟发布后校验加回调 2 分钟预留 1 分钟重试。整个链路跑下来不到五分钟其中最不可控的是外部渠道接口的响应速度内部环节基本都在秒级。2.4 几个渠道的对比实测渠道接口类型发布耗时审核机制备注招聘网站REST API约 60 秒机器审核为主字段限制最严格学历字段必填官网招聘页内部 API约 10 秒无最稳定可自定义字段内部推荐群机器人消息约 5 秒无需要处理 Markdown 渲染社交频道Webhook约 20 秒流量限制短链接容易被吞需重试这条链路稳定跑了一个半月后开始有候选人通过官网招聘页投递简历。简历进入系统的那一刻才是这个“AI 老板”真正的工作开始。3. 四个月运行中的关键机制从简历筛选到绩效评估3.1 简历初筛规则与语义的双通道简历初筛系统是四个月里迭代最多的模块。最开始只用一个 Embedding 模型算简历和 JD 的语义相似度然后按相似度排序排在前面的进入面试。跑了两个星期就发现问题语义相似度会把“有着丰富项目管理经验”这种泛泛表述的简历排得很高但真正做过复杂系统重构的简历反而因为术语表达差异被排到后面。后来改成双通道。第一通道是硬性规则比如工作年限、必会技术栈、学历门槛直接过滤明显不达标的简历。第二通道才是语义模型在通过硬性规则过滤的简历里做相关性排序。两个通道加权后得到综合分。实测首批 100 份简历硬性规则过滤掉 71 份语义排序后推荐了 12 份进入面试。这个 12% 的通过率跟人工初筛的习惯接近后来就固定下来了。这里要特别提一句简历初筛的阈值必须让 HR 参与定。工程师容易陷入调模型的快感里但模型指标不等于业务指标。简历召回率再高候选人到面率低就是浪费面试官时间。四个月里我们把阈值从最初的 0.72 调整到 0.65因为发现 0.72 会筛掉一部分学历一般但项目贴合的人而 0.65 虽然多了一些噪音但总到面率高不少。3.2 AI 面试与评分卡问什么、怎么追问面试这个环节AI 现在的水平还撑不住全流程。系统做的是“半自动面试”AI 负责一轮结构化技术面试面试官观察并负责终面。结构化面试的问题由模型基于 JD 生成比如针对订单系统重构岗位会生成“讲一个你做过的并发瓶颈排查案例”和“如果让你重写订单超时处理逻辑你会怎么设计”这类问题。追问逻辑是这里比较有意思的地方。面试 Agent 会根据候选人的回答提取关键实体如果回答里提到了“Redis 分布式锁”它会继续追问“锁的续期和红锁问题怎么处理”如果候选人回答里没有出现具体技术名词则追问会更偏向业务场景。评分用 5 分钟卡技术深度、表达能力、项目匹配度、自驱力、风险点。一轮面试跑下来约 40 分钟AI 会在结束后的 5 分钟内生成评分报告和录音转写摘要。实测中一个比较准的观察候选人如果在前 15 分钟内没有提到任何具体数据量级比如 QPS、订单量、代码规模后续表现大概率也一般。这不是面试官玄学而是有数据支撑——四个月里面试评分前 20% 的候选人93% 会在前 15 分钟提及量化指标。3.3 试用期绩效OKR、周报与代码数据的整合员工入职之后“AI 老板”就开始每个工作日收集数据。它的数据源是三个项目管理系统里的任务状态、代码仓库的提交记录、周报文本。每周五晚上三个数据源的数据汇入绩效计算模块生成一个绩效简报。任务维度的核心指标是任务完成率代码维度的核心指标是提交频率、单次提交代码量、评审通过率周报维度是靠模型判断员工本周是否有关键产出。四个维度的权重分配如下任务完成率30%代码质量与产出30%周报与关键产出25%协作响应度15%协作响应度是后来加的指标。当时发现有个员工任务完成率和代码指标都很正常但同事普遍反馈他很难配合群里 他经常隔天才回。后来在绩效系统里接入协作响应时长自动统计他回复同事消息的时间差中位数直接把他的综合分拉下来了。这一步做完绩效评估的准确度提高了不少因为纯看任务数据很容易漏掉协作层面的问题。3.4 模型部署与成本监控的实测数据说下模型部署相关的经验。这个系统里的 JD 生成、简历筛选、面试评分分别在三个不同规格的模型上运行。JD 生成用了通用对话模型走 API 调用成本低、效果好。简历筛选的 Embedding 模型是本地部署的开源模型用 vLLM 起服务单卡 24G 就能跑并发压力不大。面试评分模型最复杂因为需要处理长对话转写上下文窗口要求高我们把它单独部署在一个 70B 级别模型上。四个月里推理成本大约占整个项目开支的三成另外六成是人力调试成本剩下一成是渠道接口费用。如果是正式项目我一定会建议先把模型调用做成内部网关统一做缓存、鉴权和配额管理否则每个 Agent 都直接调模型接口密钥管理会乱套。这个判断在项目后期应验了面试 Agent 和绩效 Agent 同时跑定时任务时偶尔会出现并发限流错误早期没有统一网关排查起来非常痛苦。4. 四个月后开除第一个人触发、决策与复盘4.1 触发条件连续六周的低绩效信号系统跑满三个月的时候评估管理 Agent 的预警模块开始频繁提示一个编号为 E04 的员工。他的绩效数据非常典型连续六周综合分低于团队基准分 25% 以上任务完成率只有 31%代码评审通过率从最初的 70% 一路掉到 44%协作响应时长中位数超过 12 小时。最初两周预警被当成普通波动但到第四周的时候系统提示他维度命中数已达到 3/4评估管理 Agent 自动生成了一个降级提示要求主管介入。这里需要说明AI 不会直接“开除”任何人。系统生成的是绩效异常报告和解除用工建议真正的解聘动作由 HR 和员工主管执行最终盖 HR 章的是人而不是系统。但在流程层面I 系统做了大量的证据固定把每周绩效简报、代码提交记录、周报关键产出、协作响应数据完整打包任何一条判断都能追溯。4.2 决策链路AI 建议人决定开除决策的工程实现可以总结成一条链路指标预警 → 自动归因 → 复核建议 → 人工确认 → 书面通知 → 权限回收。前两步是系统自动完成的后四步都需要人参与。自动归因这部分系统做得比较有意思。它不是简单说“这个人绩效低所以建议开除”而是会把低绩效拆到具体原因上。比如 E04 的周报里连续出现“依赖同事提供数据”“环境问题阻塞”这类表述代码提交记录显示确实有一段时间集中在非核心模块上。系统给出的归因结论是“产出质量不足且长期未改善而非环境阻塞导致”这个结论是靠把周报文本和任务完成数据对齐后得出的。人工确认环节我们坚持一个原则任何解除决定都应该有至少一次面对面复核。AI 给的建议只能作为起点主管和 HR 会和员工本人聊一次了解是否存在系统无法感知的特殊情况。E04 这个案例里复核后发现员工本人处于长期疲劳状态确实不是态度问题但考虑到产出长期不达标且已经连续两周没有任何关键产出最终还是执行了解除建议。这个决定是团队集体做出的AI 只是让证据更透明。4.3 这次“开除”暴露的设计漏洞这件事做完之后团队做了一次非常认真的复盘。复盘发现一个此前完全没料到的问题初筛简历时的量化指标偏好可能和实际岗位需求错位。系统筛简历时倾向于挑“项目经历多、技术栈广”的候选人但这批人在真实工作里往往更擅长“广”而非“深”。E04 就是典型他简历上有多个项目经历面试表现也很好但实际工作是长期深入重构一个模块这种工作模式跟他的特性并不匹配。另一个漏洞是试用期前两周的数据污染。新员工入职前两周本来就在熟悉环境任务完成率低是正常的但系统直接把这两周数据纳入绩效计算导致 E04 的基线从一开始就被拉低了。后面我们把前两周设为“免考核期”只采集数据不计入评分。4.4 改进方案多维度评估与人工兜底针对上面的漏洞系统在第四个月后做了三项升级。第一项是评估维度扩展增加“长周期项目里程碑达成”指标避免只看短期任务完成率。第二项是引入同事匿名互评让团队成员的反馈也能进入绩效模型。第三项是设定三个月 baseline任何新员工的绩效评分在入职后前三个月都只跟自己比不跟团队基准比。这套改进并不能让系统变成完美管理者但至少让“开除”这个决定不再依赖单一数据源。我个人觉得这里的核心不是技术而是流程设计AI 负责收集和分析数据人负责做决策和承担后果。整套系统里最重要的代码不是模型调用而是那条“必须经过人工复核才能执行解聘”的 if 判断。5. 常见问题与排查技巧实录5.1 五个高发问题速查表跑四个月遇到过的问题远不止上面那些我把最高频的几个整理成了一张速查表方便后来的人排查。问题现象可能原因排查与解决思路招聘启事发布出去但页面上字段为空渠道接口要求字段非空但适配器未正确映射检查适配器字段映射增加发布后拉取校验JD 里出现岗位需求里没提到的福利模型幻觉补充了凭空捏造的福利在合规审查 Agent 后加一轮字段一致性比对AI 拒信语气过于生硬候选人体验差模型默认输出偏向简短冷淡提示词里加“共情语气”要求并给两版供选择绩效预警误报高绩效员工被标记异常数据源统计周期没对齐某周数据缺失统一数据采集时间窗口缺失数据自动补采接口并发限流导致夜间任务失败多个 Agent 同时触发模型调用做统一模型网关加配额管理和重试队列5.2 关于人机边界、数据安全和流程透明的几条建议最后说几条从这套系统里沉淀下来的实操经验都是平时文档里不会写的。招聘和绩效场景下AI 的输出一定不能直接对外发送。JD 需要人确认一遍拒信需要人看一眼解聘建议更需要人点头。不是模型能力不够而是出了问题需要有人负责。系统跑得再好也不可能替你去开仲裁庭。我们在所有对外消息接口前加了一个“人审开关”默认开启只有内部测试时才临时关闭。数据安全方面系统里所有简历、面试录音、绩效数据都做了字段级脱敏。模型调用时传入的是脱敏后的文本比如姓名用「候选人A」代替手机号中间四位打码。面试录音转写之后原音频文件只保留 30 天到期自动删除。这套做法在内部审计的时候很有用至少能说清楚每一份数据被谁、在什么时间、用于什么目的。流程透明方面所有 Agent 的关键动作都记录审计日志。JD 生成了几次、谁确认的、发布到哪些渠道、简历筛选阈值是多少、面试评分卡谁填的全部可回溯。E04 的解除决策之所以执行得顺利很大程度上就是这些日志让整个流程经得起追问。6. 写在最后一些实际的体会这套系统跑下来我最深的体会是AI 当管理者价值不在“决策多聪明”而在“过程多透明”。过去开除一个人全靠主管的主观判断员工不服气也没办法现在 AI 能把六周的数据、代码记录、周报摘要、协作时长全部摆出来争议一下子小了很多。这就是数据的力量哪怕它只是一个辅助工具。再分享一个小技巧。如果你也要做类似的人事 Agent 系统开局千万别做“全流程自动化”。先做招聘启事这一个点跑一周确认模型输出稳定、渠道发布可靠、人工审核不烦再往简历筛选、面试评分、绩效管理扩展。一次只拆一个流程每个流程都加人工兜底这是我踩过几次坑之后总结出来的最稳的路径。这套系统的下一步我打算在解除建议里加入更丰富的上下文记忆让 AI 的归因解释能结合员工长期成长曲线给出而不是只看当前六周的快照。