我参与过一个后来被朋友戏称为“AI老板”的项目。对方是一家二十几人的SaaS创业公司招聘全靠创始人手动刷简历试用期评估靠主管拍脑袋。招进来的人常常没过试用期就闹出不愉快三个月走两个人是常事。他找到我提了一个不复杂的要求能不能让AI把招聘启事生成、简历筛选、试用期跟踪、风险预警都自动化我基于AI Agent搭了一套系统第一版上线时从填表到发布招聘启事只要五分钟。系统上线四个月后第一次给出了“解除试用期”的建议最后也真的开除了第一个人。这里我想完整复盘一遍需求怎么梳理、Agent怎么分工、评估链路怎么设计、工程上有什么坑以及为什么最后还是必须由人按那个按钮。1. 从需求到方案为什么叫它“AI老板”1.1 核心需求招聘慢、评估主观、止损不及时朋友公司大概二十多人产品是SaaS创始人和技术合伙人要花大量时间面试。招聘启事挂在平台后筛选简历靠人工一份份看候选人体验很差。试用期管理几乎没有标准mentor凭感觉打分新员工三个月内离职率很高。他找我时说的原话是“能不能让AI替我干HR的活至少把招聘和试用期评估标准化。”这里的关键不是AI代替人类决策而是把流程里重复、主观、容易遗漏的部分变成可量化、可追溯、可自动提醒的机制。核心需求其实是三点第一招聘流程提速JD生成和简历初筛自动化第二试用期过程数据自动跟踪减少主观偏见第三触发风险时能及时预警避免拖到转正后才发现不合适。如果只做一个聊天机器人陪聊这个项目没有任何意义。真正的价值是把没有规则的流程变成有规则的流水线。1.2 方案选型为什么用多Agent协作而不是单个聊天机器人很多人问我为什么不用一个全功能chatbot直接问答。我试过早期原型一个全功能Agent在同一个上下文里又写JD、又筛简历、又做绩效评估。结果就是上下文越用越长输出越来越不稳定而且一旦某个环节出错很难定位是Prompt问题还是数据问题。最后我拆成了多个小Agent招聘Agent、简历筛选Agent、面试调度Agent、评估Agent、预警Agent、审批Agent。每个Agent只做一件事输入输出是结构化的JSON。这样就像工厂里的流水线每个工位质量检查简单出了问题可以直接按工位排查。多Agent协作还有一个好处不同环节可以使用不同的模型和Prompt策略。比如JD生成用大参数模型简历初筛用速度快、成本低的模型评估Agent用带工具调用的模型去查数据。这个设计在后面工程实现上节省了非常多调试时间。1.3 系统边界AI决策与人审批的“双轨制”做设计时我和朋友定了一条铁律AI可以决定“要不要建议”但“能不能执行”必须由人来拍板。所以系统里每一个高风险动作——终止试用期、退回招聘流程、标记为不通过——都必须经过一个审批节点。审批节点会收到完整证据链和AI建议而不是一个孤零零的分数。这条铁律救了我们好几次。后面会详细讲第一起解雇案例里AI的建议是“建议终止试用期”但最终和当事人谈、确认事实、走流程的还是人。没有这条兜底这个项目大概率会变成一场公关灾难。所以如果你们要复刻这套方案先把权限边界画清楚再谈效率。权限边界不是限制AI是保护公司。2. 五分钟挂出招聘启事招聘与发布模块实操2.1 招聘启事生成的Prompt设计JD生成是整个系统里最早完成的模块。我最初的版本是给模型一个很宽泛的指令结果输出了一大堆“我们寻找充满激情的伙伴”这类废话。后来我把Prompt改成强约束模板让模型只做润色和排版而不是凭空创造。核心模板长这样你是一名资深人力资源顾问请根据以下信息生成一篇招聘启事。 岗位名称{{岗位名称}} 所在部门{{部门}} 汇报对象{{汇报对象}} 岗位职责要点{{职责要点}} 任职要求要点{{要求要点}} 福利亮点{{福利信息}} 公司简介{{公司介绍}} 要求 1. 标题吸引候选人但不要标题党。 2. 800-1200字分职责、要求、我们提供、投递方式四段。 3. 用公司真实口吻不要过度承诺。 4. 输出JSON格式为{title:..., content:[...,...], keywords:[...]}为什么输出JSON为了直接对接页面、招聘平台API和邮件模板。实测下来从填写岗位信息表到生成并发布招聘启事五分钟内可以完成。这也是标题里“五分钟”的来源。另外我特意在Prompt里加了“不要过度承诺”因为如果招聘启事写了13薪但公司其实没有候选人进来后一旦发现很容易引发争议。AI可以帮我们写得更快但不能替我们说假话。2.2 简历初筛与面试邀请的自动化JD发出去之后真正的挑战是简历量。简历可能是PDF、Word、网页格式先交给解析Agent转成纯文本再调用一个抽取Agent把姓名、工作经历、技能、教育背景等字段抽出来。这里有个关键教训千万不要直接让LLM对整篇简历打分你会被幻觉坑惨。正确做法是先把简历结构化存入向量数据库然后根据招聘启事里的核心要求用关键词和向量相似度做第一轮粗筛。粗筛通过的简历再进入评估Agent用少样本评分卡打分。我用的维度是“匹配度、项目经验深度、稳定性、技能符合度”每个维度1到5分最后输出总分和推荐等级。推荐等级分A/B/CA类进入面试B类待定C类直接自动发送拒绝信。面试邀请也不是全部用同一个模板。Agent会根据候选人经验和岗位相关性生成一封带具体理由的邀请邮件。比如“看到你在电商行业有过三年订单系统开发经验这个背景和我们当前需求很匹配”这种个性化邀请的回复率实测比通用模板高不少。自动化不是群发而是让每个候选人都觉得自己被认真看过。2.3 招聘模块的合规与权限细节简历属于个人敏感信息这句话必须反复强调。系统处理简历时我把所有数据放在公司自己的对象存储里字段级加密。页面展示时只暴露脱敏信息手机号只在约定时间段让面试官看到。候选人可以要求删除简历系统要支持一键清理。接口权限上招聘Agent的API Key只授了招聘数据的读写权限没有让它去读绩效和工资数据。数据隔离不仅是为了合规也是避免AI做交叉推断。比如系统知道候选人上一份薪资后可能影响Offer建议这类敏感信息最好在招聘阶段就物理隔离。合规问题不是事后补而是从第一条数据入库前就要想清楚。3. 四个月后开除第一个人试用期评估与决策链路3.1 试用期评估的数据源与指标设计招聘只是开始。我给朋友公司设计的试用期评估覆盖了四类数据工作成果、协作表现、出勤和客观可追踪的行为记录。具体来说工作成果来自项目管理工具和代码仓库比如任务完成率、需求交付及时率、代码提交频率、Bug关联数。协作表现来自周报、会议纪要和同事评价这部分由评估Agent定期读取并输出结构化摘要。出勤记录来自考勤系统不是说迟到两次就淘汰而是看趋势。关键事件来自客户反馈和内部工单比如某次线上事故和运营人员操作直接相关这种事件权重非常高。每个数据源在评分卡里有一个权重。最终权重设计为工作成果40%协作表现25%出勤与行为15%关键事件20%。这个权重不是拍脑袋而是和业务负责人一起过了一遍把“业绩导向”和“过程管理”做了平衡。如果你在设计类似系统权重一定要让业务部门参与确认否则后面很容易被挑战。3.2 自动化绩效评分卡是怎么算出来的每周日晚上定时任务会触发评估Agent汇总过去七天数据生成一张结构化的评分卡。评分卡不是简单的平均分而是带趋势的第一月权重低第二三月权重逐渐提高因为要给新人学习期。我用了一个分段加权公式effective_score base_score * learning_factor trend_bonus learning_factor min(0.7 week_index * 0.1, 1.0) trend_bonus 连续上升/下降的修正分取值范围 -0.5 到 0.5base_score由各维度分数加权得到trend_bonus是为了捕捉“连续两周下滑”这种危险信号。光看平均值会掩盖问题比如某人前四周都很优秀后两周突然摆烂平均值看起来还凑合但趋势分已经拉响警报。Agent每周会输出一份不超过200字的解释说清楚为什么分数变化比如“第6周任务完成率从上期的85%下降到40%关键事件中存在一次客户投诉建议人工复核”。这段解释是给审计用的事实依据不是给领导看的形式主义。3.3 解雇决策的触发条件与人工兜底系统不会因为某周分数低就建议开除。我设计了三道触发条件必须同时满足第一连续两周评分低于60分或者出现一次严重关键事件第二三个月内累计低绩效周数超过五周第三评估Agent生成的改善计划已经发送给员工和直属主管且一周内没有明显改善。第三点很重要很多管理者跳过沟通直接开人这既不合理也容易引发争议。系统会先自动生成一封“改善提醒”由直属主管审阅后发给员工内容包含具体数据和改进建议而不是冷冰冰的“你绩效不达标”。如果一周后数据没有起色系统才生成“解除试用期建议书”并附上三个月的证据链、评分趋势、沟通记录。这份文档会进入审批Agent推送给HR和老板老板点确认后系统才会进入线下流程。整个过程中AI是“打工人”人是“签字人”。3.4 第一个被开除的人真实场景复盘系统上线第四个月迎来了第一个触发案例。主角是运营专员第一个月表现很好第二个月开始任务完成率下滑周报内容逐渐空洞连续三周评分低于红线。关键事件是某次活动配置错误导致用户收到错误优惠券客诉量上升。评估Agent连续发出三周低绩效预警第三周结束时生成了改善提醒。主管和员工谈了一次员工承认家里出了一些事状态不好承诺会调整。但接下来一周数据仍然没有恢复。系统于是输出了解除试用期建议书。我朋友看到建议书后没有直接点确认而是把证据链拉出来人工复核了一遍确认数据没有错才约谈员工。员工最终接受了公司决定办完手续后还主动说“如果早点被数据点醒我可能不会拖到状态崩了还不说。”这句话让我印象很深。这个案例说明AI老板不是冷酷机器数据透明反而让离职沟通少了很多互相扯皮。当然它不是让AI背锅而是让流程有据可依。4. 工程实现细节从模型部署到多Agent协作4.1 技术栈与基础设施选型整个系统用Python写的核心组件包括LLM API、向量数据库、工作流引擎和定时任务调度。模型层我没有选择本地部署而是接了商用API原因很简单项目团队没有GPU运维能力而且招聘和评估任务的实时性要求不高API完全够用。商用API数据不会存简历明文因为我们在调用前就完成脱敏所以隐私风险可控。向量数据库用了开源方案里面只存简历的向量和摘要不存原文件。工作流引擎用的是轻量级状态机框架每个Agent的输入输出用JSON Schema校验跑不通就在入口拦截。定时任务负责每周日的评估调度以及每天早晨的风险扫描。技术栈不追求新潮稳定、易排查、可替换才是关键。4.2 多Agent协作的通信与状态管理多Agent最怕各说各话。所以我给每个Agent定义了标准输入输出内部通信全部走消息总线。比如简历筛选Agent的输出{ candidate_id: C-2024-001, resume_summary: 3年后端开发熟悉Python和MySQL, scores: {match: 4, experience: 3, stability: 4}, recommendation: A, reject_reason: null }调度Agent拿到这个JSON后再决定是发面试邀请、进入待定池还是发拒绝信。所有Agent之间不直接调函数而是通过消息队列解耦。这样如果一个Agent挂了重启后可以继续处理不会影响整条线。状态管理用数据库表记录每份候选人和员工的状态机比如“已投递-初筛中-面试中-已入职-试用期-观察期-终止”每次状态变更都写审计日志。这样即使某个流程突然中断也能从日志恢复现场而不是重新跑一遍所有LLM调用。4.3 可观测性与审计日志让AI可解释做管理流程最忌讳黑盒。我在系统里加了两个层面的可观测性第一业务层面每一次Agent决策都要生成Human-readable的说明比如为什么推荐A类、为什么触发预警第二技术层面记录完整的调用链路包括输入数据摘要、模型名称、温度参数、输出结果和延迟。这些日志会加密保存并且和员工数据分离。可解释性不是事后补文档而是每个动作发生时就留下一个“为什么”。朋友一开始也不放心觉得AI是不是抓错数据。后来有一次他抽查预警记录发现Agent不仅看到了考勤异常还关联到了项目管理系统里一个过期任务证据链条完整他当场就放心多了。没有可解释性的AI管理没人敢用。4.4 Prompt调优与幻觉控制的几条实测经验工程上最花时间的其实是Prompt调优。我有几条亲身经验。第一输出格式永远用JSON约束并在Prompt里给一个示例响应。第二温度参数不要高我用0.2既能保证一定多样性又不至于胡说八道。第三凡是涉及数据的判断不要只让LLM凭上下文意会要先让工具函数查到真实数据再放入Prompt。比如评估Agent不能看着摘要说“他最近表现不好”而是要把任务完成率实际数值作为变量注入Prompt。第四做回归测试集。我整理了一批历史简历和评估案例每次调整Prompt之后先跑一遍测试集看输出有没有明显退化。这套回归测试花一天搭建但后面省了无数个夜晚。很多团队重上线轻回归最后反而花更多时间救火。5. 常见问题与避坑实录5.1 新员工“新手红利”造成的评估失真前面提过新员工入职头一个月往往因为新鲜感和学习热情表现分虚高。这个阶段如果直接进入正式评分会拉高整体均值导致后续几周的下滑显得特别刺眼。我一开始就吃过大亏系统把第一个月当成评估基准第二个月数据稍微回落Agent就连续报警结果人工复核发现完全正常。解决方法是调整learning_factor前两周分数权重降低并且把“趋势变化”的判定窗口拉长到三周以上。新手评估要解决的是“看不见成长曲线”而不是“揪住第一周的光环”。任何在试用期场景里使用的评估模型都要考虑到人的学习曲线否则系统会变成误报机器。5.2 LLM幻觉污染简历匹配结果简历筛选这个模块我最早犯的错是让LLM直接阅读整段简历然后打分。结果它会把不相干的经验强行关联比如候选人做过行政Prompt里有“支持团队”四个字它就匹配“团队合作”高分。这种现象对AI工程师来说叫幻觉对HR来说就是筛错人。解决办法是先用抽取Agent抽关键字段转成半结构化的简历档案再用规则和向量检索做粗筛最后让评估模型只基于结构化结果打分。整个过程里LLM只处理结构化提取和润色任务不直接做“感觉型判断”。如果你也做类似项目务必把“提取事实”和“价值判断”两件事拆给不同的Agent。5.3 被开除员工的申诉与数据更正流程既然是自动化管理流程就必须考虑“被判不好”的人要翻案。我们设计了一个简单的申诉机制员工对评分有异议可以提交申诉申诉触发重算Agent。重算Agent不是把原数据重新跑一遍而是先检查数据采集是否完整、是否有误比如考勤机把下午请假记成旷工。发现问题后修正数据再重算评分。这个流程在第一个案例里没有用到但我认为必不可少。没有申诉渠道的自动化管理本质上就是裁判和记录员同一个人这是危险的。给员工留一个“说出数据之外的故事”的出口也是给人情味留一个位置。5.4 不要让AI直接发“解雇通知”最后一条也是最容易踩的雷即使AI把建议书、证据链、评分卡都准备好了最后的沟通尤其涉及解雇这种高风险通知绝不能由AI自动发送。我们的系统生成的是待办任务推送给HR和老板而不是直接发邮件给员工。发送给员工的最终通知必须由人确认后用公司的正式渠道发出。这不仅是合规需要更是基本的人性化管理。员工需要和有温度的人沟通而不是收到一封署名“AI老板”的冷冰冰邮件。如果你把这一步也交给AI麻烦很快会找上门。5.5 常见问题速查表现象原因建议简历匹配总把无关技能当成强项LLM直接通读全文打分先抽取结构化字段再基于结构化结果评分新员工第二个月频繁预警未设置学习曲线增加分段权重趋势窗口拉长到三周以上评估解释像车轱辘话Prompt没有给数据上下文注入真实指标数值并要求输出具体原因Agent反复调用导致成本飙升未做缓存和状态跳过增加结果缓存、失败重试上限、幂等设计员工对评分有异议时无处理入口缺少申诉机制增加重算Agent修正数据后重新评分解雇通知由AI直接发出过度自动化高风险动作生成待办任务人审批后人发送这个表是我后期整理项目文档时沉淀下来的基本涵盖了最容易翻车的六个位置。每次新需求进来我习惯先对着这张表过一遍能省很多沟通成本。我个人在这个项目里最大的收获是理解了“AI做管理”这件事的边界。模型本身不复杂复杂的是流程设计、数据质量和人的兜底。“AI老板”听起来很酷但如果没有人盯着最后一关它会用错误的数据做出冷冰冰的决定。我现在把AI当成“数据整理、初稿生成、风险预警”的放大器把最终判断权留给人。这个项目之后我再接企业内部的自动化流程第一件事永远不是选模型而是问客户哪些决定你愿意交给机器哪些必须留给自己。想清楚这个问题比任何技术选型都重要。