去年我们团队把招聘从“需求提出”到“录用建议”的整条链路交给了一组AI Agent去跑。不是那种单窗口问答助手而是一群各司其职的智能体有的负责抓岗位需求有的负责筛简历有的扮演面试官做评估最后还有一个汇总决策的。这套多智能体招聘系统跑通了大半年我踩过不少坑也沉淀了一些真正管用的设计经验。这篇就把它拆开来讲讲多智能体之间到底怎么协同为什么这么设计以及你照着复刻时最容易翻车的地方在哪。如果你是正在搭AI招聘系统、想用AI改进HR流程的同学这篇会比较对胃口。我会直接给架构思路、关键配置、实测数据以及一堆常规文档里不会写的教训。纯理论聊天的内容我不会说这篇全程都是可落地的东西。1. 为什么是“多智能体”而不是“一个超级Prompt搞定一切”1.1 招聘流程对AI的三个苛刻要求招聘这件事表面上是“筛简历、约面试、发offer”真落地起来却是典型的“长链路、多角色、强审计”场景。先说长链路。一个候选人从投递到入职中间要经历岗位需求解析、简历初筛、笔试/技术面、行为面、薪资匹配、录用决策。这个链路横跨几天甚至几周中间的信息是逐步累积的。如果让一个大模型吃掉所有数据一次性输出结论Prompt会越堆越长最后模型根本分不清哪些是早期需求、哪些是中期反馈、哪些是最终的决策依据。我试过把一个月内面试记录全部拼进同一个上下文结果模型把“候选人不擅长分布式系统”这种负面结论当成了录用理由原因就是早期信息在长上下文里发生了位置偏移。再说多角色。招聘里至少有四类角色提需求的业务线负责人、把关简历的HR、考察能力的面试官、做综合判断的决策者。这四个角色的诉求经常是冲突的。业务方想要“能干活还便宜”HR想要“背景干净稳定性好”面试官想要“技术栈契合”决策者想要“性价比高”。你让同一个Agent同时扮演四个角色它一定会给你一个“和稀泥”的结论看起来谁的要求都兼顾了实际上谁都不满意。不同角色需要不同的Prompt、不同的数据视角、不同的输出格式这本质上就不是一个Prompt能解决的问题。最后是强审计。招聘决策涉及候选人隐私、岗位标准一致性每一步都必须能回查这个候选人为什么进了面试谁拍的板依据是哪条简历信息单一大模型生成的答案你很难做细粒度的审计因为你不知道结论是基于哪一小段上下文得出的也无法让前序环节为后续结论负责。多智能体环境下每个Agent的输入输出都是独立可记录的哪里出了问题直接定位到具体环节这才是工程上可以接受的形态。1.2 多智能体架构带来的三个关键收益基于上面这三个痛点我当时的设计思路很明确把一个招聘流程拆成多个专业Agent每个Agent只干一段事再由一个编排器串起来。这套架构带来的收益远不止“代码结构清晰”这么简单。第一个收益是职责分离也就是“让每个Agent只做自己最擅长的事”。需求解析Agent只需要把一句话扩写成结构化JD简历筛选Agent只需要产出“匹配度评分证据”面试评估Agent只需要啃透一份简历和一段面试记录。每个Agent的上下文窗口里只放自己需要的数据模型注意力不会被无关信息稀释。我实测下来职责切分之后单个环节的判断准确率反而比一个全能Prompt高出不少。原因很朴素上下文越聚焦幻觉越少。第二个收益是上下文隔离与分层记忆。这是多智能体最有价值的技术点。我的做法是给每个Agent分配私有上下文只属于本环节的输入输出同时维护一个全局共享的“候选人档案库”。智能体之间不直接传大段Prompt而是传“候选人ID任务单”。需要某个历史环节的信息时按需从档案库里检索而不是把所有历史一股脑塞进去。这就避免了招聘系统里最常见的“上下文污染”问题——面试评估Agent不需要知道社会招聘阶段HR对候选人的初筛备注否则它会被“这个人之前被怀疑过造假”之类的主观信息带偏。第三个收益是人机协同有了天然节点。多Agent架构下每个Agent的输出边界非常清晰这让你可以很方便地在任意两个Agent之间插入“人工审批节点”。岗位需求是不是解析偏了简历进入面试池之前要不要HR确认录用推荐的薪资区间合不合理这些都可以做成“人审机评”的环节。单一大模型你做不到这一点因为你不知道该在哪里打断模型。用流水线来类比就很好懂你不会让一个工人从零件铸造一直干到整机装配而是拆成工位每个工位专精一道工序工位之间放质检点。招聘系统里的Agent就是这些工位编排器就是传送带人就是在质检点把关的。想通这一点整套架构的骨架基本就定了。2. 把“招聘全流程”拆成一张智能体分工图2.1 需求解析Agent先建“岗位画像”而不是直接写JD大多数公司招人最初的输入都是非常模糊的。业务负责人丢过来一句话“招个懂NLP的算法工程师最好搞过电商推荐。”这句话直接拿去生成JD效果一定很烂因为“搞过电商推荐”到底是加分项还是硬性要求不知道。要带团队还是纯执行不知道。薪资区间多少完全没提。需求解析Agent要解决的问题就是把这种模糊输入转成一份结构化“岗位画像”。我给它定的输出Schema大体包含这些字段岗位名称、汇报关系、核心职责按权重排序、硬性要求、加分条件、工作年限区间、薪资区间、招聘信心等级Setter评估、技能权重表。为了让解析稳定我会用少样本抽取而不是纯自由发挥同时接一个内部历史职位库做RAG让它参考历史相似岗位的薪资和职责表述避免拍脑袋。这里有个实操细节不要让这个Agent直接输出给候选人的JD文案它输出的是结构化画像JD文案由另一个生成模板工具渲染。这样做的原因是JD文案和内部需求画像的信息颗粒度完全不同。对外JD讲究吸引力对内画像讲究匹配逻辑。我们试过让Agent一次同时产出两种结果对外JD里出现了“内部推荐奖金”这种不该给候选人看的字段。拆开之后这种乌龙就没了。这个Agent还有一个人工确认节点输出岗位画像后系统会生成一个确认卡片推给业务负责人让他勾选核心职责权重。看起来多了一步操作实际上避免了后面所有Agent跟着一个错画像跑到底。我踩过这个坑早期没有确认节点需求解析Agent把“熟悉Java”写成了硬性要求结果简历筛选阶段直接漏掉了一个经验匹配但技术栈不同的候选人整个流程重新跑了一遍。从那以后岗位画像确认改成了强制步骤。2.2 简历筛选Agent多路召回加语义精排别让LLM直接读所有简历简历筛选阶段最容易犯的错误是直接把所有简历丢给LLM让它“挑出合适的”。简历一多Token成本瞬间起飞而且模型对几十份简历的判断会越来越随意。我设计的简历筛选Agent分两步走先用低成本的召回策略圈定候选池再用LLM做精排。召回层我同时跑三路第一路是关键词/规则匹配比如硬性工作年限、学历门槛、必会技能这一路用正则和倒排索引就搞定第二路是向量召回把JD画像和简历分别转成Embedding算语义相似度解决“简历里写的是‘NLP’JD画像里写的是‘自然语言处理’”这种同义表达问题第三路是差异化召回专门捞那些规则和向量都漏掉的“偏才”比如学历不达标但项目经历非常亮眼的候选人。三路结果求并集再进入精排。精排层才是LLM真正干活的地方。我需要它对每份候选简历输出一个结构化的评分结果而不是一句“这个候选人看起来很适合”。我的评分格式是总分0-100分维度得分技术匹配、经验匹配、稳定性预期、成长潜力证据引用从简历里摘出来的原话亮点标签如“有大模型微调实战经验”。这样返回的好处是HR后续想看候选人为什么得这个分可以直接对证据引用而不是重新翻简历。阈值设计也很关键。我实际跑下来总分85分以上进“直接约面池”70到85分进“备选池”70分以下进“人才库”。但分数不能卡太死所以我又加了一个“维度保底”规则技术匹配分低于40的即使总分过了85也要降级防止一个偏科候选人靠其他维度把总分堆上去。这个策略看起来简单却是我踩了两次坑才总结出来的——第一次全靠总分排序选进来的候选人技术栈完全不搭第二次分维度卡得太严一个跨行业转型的候选人被误杀后来靠人工捞回来才学会“总分维度保底”的组合。2.3 面试评估Agent像资深面试官一样提问和打分面试评估Agent是整套系统里最难做的部分因为它不只是“打分”还要负责生成面试提纲、解析面试对话、评估笔试答案。我的做法是把它再拆成三个子角色但它们共享同一个候选人档案。第一个子角色是“面试提纲生成器”。它读取岗位画像和候选人简历生成三类问题行为面问题按STAR法则考察比如“讲一次你在项目中推倒重来技术方案的经历”、技能面问题针对岗位核心技能设计由浅入深的提问比如“Transformer的注意力机制你如何理解”、项目深挖问题针对候选人简历里的高亮项目提问检验真实参与度。这里有个重点提纲生成必须绑定JD的技能权重技能权重越高的领域出题数量越多、深度越深。否则它只会按简历内容平均分配问题结果最关键的技能考察反而被弱化了。第二个子角色是“面试对话解析器”。它接收面试录音转写的文本按维度抽取出候选人的回答要点、情绪信号、关键措辞。它不负责判断只负责结构化事实提取这也是一种职责分离设计让判断和提取互不干扰。提取结果会进入档案库供评估子角色使用。第三个子角色是“评估与评分器”。它结合面试提纲、对话解析结果和候选人简历按技能矩阵打分。我的评分表长这样每个技能维度从0到5分配有“得分依据必须引用候选人原话”、“存疑点需要后续面试确认”。如果得分依据无法引用到原话系统会强制要求评估器重新判断这是我从幻觉问题里学到的后面会详细讲。实测下来这种方式产出的面试评价面试官委托的满意度是最高的因为每一条结论都能对上实际对话而不是一段模棱两可的总结。2.4 决策汇总Agent把分散结论聚合成“推荐”而不是“决定”面试评估Agent跑完之后你手上已经有了一堆分散的数据初筛评分、三轮面试评分、笔试结果、技能矩阵。决策汇总Agent就是为了把这些东西聚合成一张清晰的决策卡片包括综合排名、薪资建议区间、风险提示、待人工确认事项。这里我想强调一点决策汇总Agent的输出永远只是“推荐”不是“决定”。它的职责是把数据间的冲突暴露出来让人来做最终判断。比如面试官A给了技术分5分面试官B给了技术分2分这种分歧如果只算平均分会把一个巨大的风险掩盖掉。所以我会让决策汇总Agent专门输出一个“分歧预警”字段把评分标准差大于阈值的维度列出来提示招聘负责人复核。薪资建议区间也比较讲究。它需要结合岗位画像、候选人当前薪资需候选人确认、公司薪酬体系、同类岗位历史offer数据最后给出一个区间而不是单一数值。区间通常跨度在15%左右比如25K到29K给谈判留空间。这个Agent使用的数据源比较复杂我会把薪酬体系的历史记录做成向量库让它可以检索相似岗位的薪酬基准不然每次都是按固定规则套完全没法应对不同level的岗位。最后决策汇总Agent还有一个特殊使命向业务负责人用自然语言解释“为什么推荐这三位”。我会让它在卡片顶部生成一段摘要像“张三技术栈匹配度最高但稳定性预期偏低李四综合评分最高且证据充分王五在电商推荐方向经验显著但项目含金量待确认”。这段摘要往往决定了业务负责人是先看人还是先看数据。一个不写摘要的版本我同事反馈说“感觉像是在查数据库”交互体验差很多。3. 多智能体怎么真正“协同”起来3.1 编排器只做路由不写业务多智能体系统里最容易被搞砸的组件不是Agent本身而是编排器。我见过很多团队把编排器写成超大的业务逻辑类里面塞满了“if 候选人分数 85 then 进入面试”这种设计跑两三个星期就变成一个没人敢改的泥潭。我自己的原则是编排器只负责两件事——状态流转和任务路由一切判断逻辑都下沉到Agent内部或独立的规则服务里。状态流转是业务流的状态机。我用了一套Event-Driven的方式每个Agent处理完任务后向事件中心抛出一个领域事件比如“Candidate.ScreenPassed”编排器订阅这个事件查询当前阶段状态决定下一个要路由的任务。这样新增一个环节比如加一家第三方背调Agent的时候我只需要注册新的事件订阅不需要改动既有Agent的代码。路由逻辑只包含比较纯粹的部分当前阶段是什么、需要哪个Agent、有没有人工审批节点要等。具体“这个候选人该不该进入面试”的判断编排器根本不关心那是简历筛选Agent的职责。这种解耦带来的直接好处就是排障的时候你不用通读所有逻辑只看事件流就能定位问题在哪一环卡住了。3.2 记忆分三层私有上下文、共享档案、全局规则多智能体协同最容易出的问题就是记忆串线。我在系统里设计了三个层次的记忆用来约束信息的流向。第一层是Agent私有上下文。每个Agent在执行单次任务时只看到当前任务的输入数据任务结束就清空。这是避免上下文污染的第一道防线。举个例子需求解析Agent在处理“招聘一名前端工程师”的时候它不需要知道两个月前“招聘一名后端工程师”时业务负责人给过什么反馈除非它主动去检索。第二层是共享档案库。候选人所有的结构化信息、简历文件、面试纪要、评分记录都以“候选人ID”为主键统一存在PostgreSQL加向量库里。Agent需要跨环节信息时通过一个统一的档案API按需读取读取行为本身会被记录。这样做既实现了信息共享又保证了每一次数据读取都可审计。我会刻意让Agent读取的字段最小化比如面试评估Agent默认只能读到简历结构化数据和前序面试摘要读不到初筛阶段的内部备注——除非那个备注被显式标记为“可共享”。第三层是全局规则记忆。这是一份只读配置包含公司的招聘制度、阈值规则、通用价值观比如“宁缺毋滥”。每个Agent在初始化的时候都会加载但它不能修改只能遵守。这一层的设置很像公司的员工手册Agent可以在自己的上下文里引用规则来解释自己的行为比如简历筛选Agent会写“依据硬性学历门槛规则该候选人不满足条件”HR一看就知道它是按制度走的。三层记忆体系跑起来之后连一个很隐蔽的bug都被自动消除了之前有一次一个候选人在初筛时被标注了“疑似简历造假待核实”这个备注因为没有被共享标记面试评估Agent完全没读到从而避免了它在后续面试中对候选人产生偏见。这其实是我故意设计的正向案例但也说明信息隔离不只是技术洁癖它有真实的业务价值。3.3 人机协同的“红灯点”哪些环节必须人工介入多智能体招聘系统能不能全自动跑完整个流程从技术上可以但从业务上不应该。我强制设置了三个“红灯点”Agent跑到这些位置必须停下来等人类确认。第一个是岗位画像确认在需求解析Agent完成任务之后。业务负责人需要勾选核心职责权重确认硬性条件没有遗漏。第二是进面名单确认在简历筛选Agent完成精排之后。HR可以批量审批“直接约面池”的候选人也可以手动把备选池的人拉进来。第三是offer建议确认在决策汇总Agent产出推荐之后招聘负责人要确认薪资区间和候选人优先级。这三个红灯点不是随便拍的。它们的共同特征是“一旦错了后面所有环节都会跟着错”而且“错误难以被机器自动发现”。画像错了简历筛选就偏了进面名单错了面试评估再准也无用offer建议错了直接影响候选人的体验和公司成本。我把这三个点比喻成红绿灯Agent是自动驾驶人是在关键路口等红绿灯的司机。早期版本里我想多放几个红灯点后来发现审批过多会让人失去耐心硬生生把“每个Agent输出都确认”改成了现在的三个反而通过率更高——因为人只关注真正重要的决策。人确认之后系统会让人工的修改反向喂给Agent做增量学习HR把一个人从备选池挪进面试池这个行为会被记录并在下次相似情况时作为few-shot示例提示简历筛选Agent。这个过程不是训练模型而是调整提示词指令但效果还挺明显我们的“误杀率”在一个月内下降了约20%。4. 实操过程从零搭一套最小可用的多智能体招聘系统4.1 技术选型模型、向量库、任务编排框架如果你也想复刻这套系统我的选型可以给你参考。大模型层面我主力用的是Claude和GPT-4级别的能力但推理成本敏感的部分换成了本地部署的Qwen2.5-72B实测在简历精排和面试解析这类结构化任务上效果差距能控制在5%以内。Embedding模型我用的是BGE-M3中文简历场景下召回效果比很多闭源接口还稳。向量库我选的是pgvector直接挂在PostgreSQL上。招聘系统的数据量不算大一个中型公司一年也就几万份简历pgvector在十万级向量的场景下性能完全够而且还省去单独维护Milvus的成本。任务编排框架这块我一开始用的LangGraph后来因为人机审批节点越来越多我换成了Temporal来做长任务状态管理配合LangChain调LLM。LangGraph适合把事情串起来但遇到“等HR审批一天再继续跑”这种长暂停场景Temporal的工作流持久化能力明显更扎实。我自己跑下来的组合是Temporal管流程LangChain管Agent工具与模型调用PostgreSQL管主数据和向量。4.2 Agent注册与任务配置示例每个Agent用一套统一的配置注册到编排器。下面是我简化之后的YAML配置结构重点不是语法而是看每个Agent怎么声明自己的职责、数据来源和人工审批点。agents: job_requirement_agent: name: 需求解析Agent description: 将模糊的招聘需求转换为结构化岗位画像 model: claude-sonnet triggers: - event: JobRequirement.Submitted inputs: - source: event.payload fields: [raw_text, dept, requester] - source: vector_store.jd_history query: 相似岗位画像 top_k: 3 outputs: schema: jd_profile_schema destination: jd_profile_store human_approval: type: required approver_role: hiring_manager timeout_hours: 24这个配置表达的核心意思是需求解析Agent收到“岗位需求提交”事件后启动一次解析任务它的数据输入之一是事件里的原始文本另一个是从向量库检索到的三条历史相似JD输出必须符合固定Schema并且必须等待业务负责人在24小时内确认。Agent的实际处理逻辑我用LangChain的LangGraph子图来组织。核心是让每个Agent拥有自己的“小图”输入校验节点、检索节点、生成节点、输出校验节点。输入校验会检查事件数据是否满足Schema要求输出校验会用Pydantic解析JSON解析失败就自动重试一次重试仍失败就发告警。这套机制保证了任一Agent跑出来的东西都可被下一个环节直接消费团队里任何一个人改某个Agent的内部逻辑都不会影响全局数据一致性。4.3 用一个真实JD跑完整流程我拿一个实际的岗位来说。某天业务负责人提交了这样一句话“急招大模型应用工程师做过LangChain项目懂RAG能给算法团队做工程支撑。”系统马上执行了这样一个调用链第一步需求解析Agent运行输出岗位画像。核心权重是“大模型应用开发”40%、“RAG工程能力”30%、“工程支撑经验”20%、“LangChain生态熟悉度”10%。硬性条件写了“3年以上后端开发经验熟悉Python”加分项是“有生产级大模型应用部署案例”。业务负责人看了一眼把“工程支撑经验”权重调到了30%“RAG工程能力”调到了20%然后点击确认。第二步简历筛选Agent的召回层在简历库里捞出了47份候选简历其中关键词召回19份向量召回23份差异化召回12份去重合并后31份。精排层对31份逐一打分耗时约17分钟token消耗约32万。输出结果是3份简历86分以上10份在70到85分之间其余落库。HR在审批界面勾选了3份“直接约面”又从备选池里手动捞了1位“虽无直接LangChain项目经验但工程能力突出”的候选人一共4人进入面试。第三步面试评估Agent为这4人生成了面试提纲并调度了两轮面试。第一轮技术面每位候选人约45分钟评估器产出了5个技能维度的评分第二轮为行为面重点考察“在算法团队与工程团队之间做技术对接时遇到的冲突”。四人的面试记录全部转写并解析进档案库。这个阶段耗时最长但每一步都有据可查。第四步决策汇总Agent聚合成推荐卡片输出排序候选人A综合得分87推荐度最高候选人B技术分最高但稳定性预期偏低候选人C工程经验匹配但RAG深度不够候选人D是HR手动捞进来的预期需要额外培养周期。薪资建议区间分别为28-32K、26-30K、24-28K、22-25K并标注了“候选人D可能需要以培养预期来谈”。招聘负责人看到卡片后直接约了A和B的终面。这整个流程没有阻塞点人只需要在三个红灯点做三件事确认画像、确认进面名单、确认推荐卡片。整套跑下来HR至少省下了80%的机械筛选时间。4.4 成本与效果我的实测数据我不太信那些“AI取代HR”的夸张说法所以做这套系统时给自己定的衡量标准是人效提升多少、判断一致性多少、单候选人成本多少。下面是跑了大半年后整理的实测值覆盖了约1200份简历、86个实际招聘岗位。指标计算方式实测值对比基准简历初筛耗时HR从看到简历到完成粗筛单份约1.2分钟纯人工约6分钟初筛准确率人工复核初筛结果匹配度92.3%纯规则初筛约80%进面候选人的面试通过率初筛后进入面试并最终通过率41.2%未用AI初筛约28%单候选人筛选成本全流程LLM Token费用摊薄约8.4元/人纯人工约23元按工时折算评分一致性面试官评分与系统驱动评分差异小于1分的比例76.4%多轮人工均值约65%成本这块我要说个细节简历筛选阶段如果让LLM直接读全部简历单份简历的处理成本约0.06元看起来不贵但1200份简历算下来要72元。而我用“召回精排”方式只有约30%的简历进入LLM精排实际成本降到27元左右节省超过60%。钱不多但规模越大差距越明显。另外面试评估阶段是成本大头每场1小时面试的转写加分析Token消耗约15万折算约7.5元。面试是必要的这个钱省不掉但能换来每场面试的结构化存档我觉得值。5. 常见问题与排查技巧实录5.1 简历解析不准先别急着怀疑模型简历解析结果是整条流水线的原料它一出错后面全错。我最开始用纯LLM抽取简历结构化信息遇到PDF扫描件、图片简历、多栏排版抽出来的字段经常乱。项目式简历里的“项目经验”会被抽成“工作经历”技能标签把“Java”和“Java Script”混在一起。排查之后发现问题不只在模型而在我没给步骤。后来我加了一个前置处理流程先用OCR工具统一转成纯文本再丢给LLM同时准备一个“技能同义词表”把“JS”全称映射到“JavaScript”把“React”和“React.js”合并。这一步做完解析准确率直接从81%升到了94%。想告诉你的经验是多智能体系统里的每个Agent都得喂干净的原料别指望模型自动纠错。遇到解析不准先排查上游再排查模型。5.2 上下文污染明明不该知道的信息“被知道”了追查一次offer决策失误时我发现决策汇总Agent在给出薪资建议前竟然在推理过程中引用了“候选人在初筛阶段被标注为疑似学历造假”这个信息。这个备注本来只允许HR看到从未被共享标记它怎么会出现在Agent的输出里我排查了很久最后定位在共享提示词上我当时为了省事把所有背景信息里的“补充材料”都直接拼进了System Prompt导致每个Agent都能读到档案里的原始备注字段。修复方案就是前面提到的三层记忆隔离私有信息不共享共享信息必须显式标记全局规则只读。修复之后我专门加了一条自动化检查每次Agent输出前校验输出中不能包含未授权字段名。这套组合下来同类问题再没出现过。多智能体系统的信息权限设计必须当成一等公民来对待不能指望Agent“自觉不看”。5.3 幻觉式匹配让每个结论都给出证据引用简历筛选Agent曾经对一个候选人打出极高的“技术匹配分”理由是“该候选人有大模型分布式推理优化经验”。但我翻遍简历原文只找到三个关键词HPC、性能优化、PyTorch。这三个关键词拼不出“分布式推理优化”这个结论就是幻觉。我不能接受这种没依据的判断所以强制改了输出规范所有得分维度必须带“证据引用”引用内容必须是简历原文的连续片段如果某个维度引不出原文该维度分数直接按0分处理并打上“证据不足”标签。这个特调整治效果立竿见影。系统对幻觉的容忍度变低之后Agent开始更保守地表达比如它会写“候选人表述为‘熟悉分布式推理’但简历中未找到对应项目经历建议面试中重点验证”。这才是我要的产出——不是讨好式的确定而是诚实的评估。如果你也做类似的智能体系统我强烈建议把“证据引用”作为硬性输出字段。5.4 Token成本失控漏斗式分层配置多智能体系统最大的隐性成本陷阱是每个Agent默认用最强的模型、最长的上下文跑所有任务。我的经验是建立一个分层漏斗便宜的规则和向量召回做前置粗筛中等性价比的本地模型处理中等难度的结构化抽取最强模型只用在面试提纲生成和决策汇总这种真正需要深度推理的地方。具体策略我总结成这样初筛阶段用Qwen2.5-72B跑精排因为这个任务输入输出结构固定不需要太强大的推理需求解析和决策汇总因为要理解模糊语言、做多源信息融合才用Claude级模型而PDF转文本那些事直接走OCR服务连LLM都不用。按照这个策略系统的综合成本比“全链路大模型”方案低了约55%核心环节的准确率反而没有下降。我还给每个Agent设了Token预算上限单次任务超预算就终止并告警避免了“一个异常大叔简历把整月成本跑爆”的事故。这套多智能体招聘系统让我体会最深的一点是AI落地最难的不是模型能力而是把流程拆得足够清楚给每个环节匹配它该有的角色、数据权限和成本预算。招人不该是一个模糊的宏观任务而是一系列边界清晰的小任务——多智能体的思路本质上就是逼你把业务逻辑拆明白。最后再补一个小经验别一上来就追求全自动跑完先把“人审机评”的半自动跑顺让团队建立对系统的信任再逐步放开红灯点这条路稳得多。