30万条候选人数据里，找出10个真正值得继续沟通的人，需要多久？
乍一看，这不该是个难题。
数据不少，系统也能搜。可真正为一个岗位找人时，顾问还是要反复拆条件、查结果、改条件，再重新筛一轮。AI 简历筛选真正要解决的，不是“有没有简历”，而是怎么从已经积累的人才库里，更快找到值得继续看的候选人。
所以问题很快就从“系统能不能搜”，变成了另一件事：顾问要花多少时间，把脑子里的判断一遍遍翻译成查询条件，再从结果里继续找。
我们这次服务的是一家约20-30人规模的猎头公司。客户现有HR系统里已经沉淀约30万条候选人记录，其中约80%的历史记录存在不同程度的信息不完整。数据又是不同顾问在不同年份持续维护的。人才库确实越来越大，可真到为一个岗位找人时，查询、比较、改条件、再查一轮，这些工作并没有因为“数据多了”就自动消失。
所以这个项目我们没有重新做一套 AI 招聘系统。客户原来的 HR 系统继续使用，我们在现有系统和人才数据之上增加了一个 AI Agent 入口：顾问把 JD 或招聘要求说出来，Skill 先把需求整理成可查询的条件，确认后，再通过 MCP 从人才库里按字段筛出候选人。
第一轮结果出来以后，也不是到此为止。顾问可以继续追问某个候选人的工作经历、项目经历和技能等已有信息，也可以调整条件再查一轮；AI 再根据查询到的详细信息辅助整理和分析。
换句话说，我们没有让 AI 替顾问选人，而是先把“在 30 万条数据里反复找人”这一步接了过去。
如果把整个方案拆开看，关系其实并不复杂：原来的 HR 系统仍然负责日常业务和人才数据维护，AI Agent 负责理解顾问的需求，Skill 负责把需求整理成查询条件，MCP 再去连接实际的人才数据。
图-方案架构图
正式HR系统继续承载原有业务；用于AI查询的数据同步到独立查询副本。Agent通过Skill整理查询条件，再由MCP访问数据。
而这套方案真正开始的地方，还是客户原来那套 HR 人才库。
客户已经在这里积累了约 30 万条候选人记录。换句话说，我们不是从“怎么把简历放进 AI”开始，而是在解决另一个问题：这些已经存在系统里的数据，怎么更方便地被重新找出来、继续查询和判断
图-客户现有HR系统中的人才库
这个项目真正改变的，不是“谁来做最终决定”最终选谁，仍然由招聘顾问判断。AI接手的是前面那段反复查询、比较和缩小范围的工作——先把30万条数据收敛成一批真正值得人继续看的候选人。 |
一、系统明明能搜，为什么顾问还是要花时间找人？
如果条件真的只有“本科、5年以上工作经验、熟悉Java”，传统HR系统完全能查，这里没必要硬上AI。
可招聘筛选偏偏不是一道条件固定的选择题。换一个岗位，查询条件会变；就算岗位没变，看完第一轮人选以后，顾问也可能继续增加、放宽或收紧某些条件。
传统高级搜索要求顾问先把自己的判断翻译成字段和条件。我们这次把顺序倒了过来：先让顾问按平时的说法讲需求，再让AI把这些自然语言整理成系统能执行的查询条件。
说得简单一点，AI没有替顾问做判断，它只是先接过了“把业务语言翻译成查询条件”这一步。
二、AI Agent 先别急着查库，得先把“你要找谁”听明白
顾问可以直接在WorkBuddy里粘贴JD，也可以像平时沟通需求那样，直接说希望找什么样的人。Agent会调用已经配置好的招聘Skill，把这段话拆成学历、工作年限、行业与岗位经验、技术技能、工作经历、项目经历等维度。
不过我们没有让它听完就直接去查库，先让顾问确认。
Agent会先把自己提取出来的查询条件摆出来。这个动作看起来多了一步，其实很关键。JD本身可能写得不够明确，AI也可能理解偏；如果一开始条件就错了，后面数据库查得再快，结果也会从错误的方向开始。
顾问确认没问题，再继续往下走。我们希望AI负责“理解和执行”，但这一轮到底按什么标准找人，关键条件还是由顾问自己把关。
图-招聘查询流程图
图-WorkBuddy中输入JD或招聘要求
图-AI提取招聘条件并让用户确认
三、条件听懂了。接下来，它去哪里查这30万条数据？
到这里，才轮到一个很现实的技术问题。
30万条人才数据都在客户正式HR系统里。那是不是让AI Agent每次筛选都直接去查生产数据库？我们没有这么做。
我们把用于查询的人才数据先同步到独立的数据库副本，再按后续筛选需要做清洗和打标。WorkBuddy里的Agent需要找人时，通过MCP查的是这份副本。
另外，这份查询数据可以围绕人才筛选去整理字段、标签和数据质量，后面查起来也更顺手。
当然，数据库副本只是这个项目的选择，不是所有企业都要照搬。换一个系统，我们还是会重新看接口能力、数据规模、更新频率、安全要求，以及现有系统能承受什么，再决定是直接接，还是单独准备一份查询数据。
权限怎么管？这件事我们没有交给提示词去“自觉遵守”
数据一旦接进Agent，权限就不能突然消失。不同用户原本能看到的数据范围不一样，接入AI以后也应该继续守住这条边界。
这个项目里，我们把用户登录和角色权限带进了MCP的数据访问逻辑。MCP真正去查数据时，会结合当前用户的身份和角色，先控制他能访问哪些数据，再把结果交回Agent。
你可以把它理解成两件事：Agent负责听懂“你想查什么”，权限控制负责回答“你本来能查什么”。接入AI，并不等于原来的数据边界就可以被绕过去。
不同企业原来的账号体系、角色划分和数据边界都不一样。真要接入时，权限要细到什么程度，我们会沿着现有系统继续设计，而不是因为多了一个AI入口，就另外造一套脱离业务的权限逻辑。
图-用户权限与数据查询链路
在这条链路里，Agent理解需求，MCP结合当前用户身份和角色控制查询范围，再把允许返回的数据交给Agent。
图-MCP 中的用户角色与数据访问控制配置
如果你的系统里也有“数据不少，但找起来还是很费人”的环节可以先挑一个具体的查询、筛选或匹配流程，把现有做法梳理清楚，再判断AI Agent有没有合适的介入位置。 【了解企业AI Agent场景评估 →】 |
四、第一轮结果先列出来。这里没有一个“神秘的匹配分”
条件确认以后，Agent通过MCP按字段条件去查人才数据。查到的人选先以表格形式列出来，这就是当前方案最核心的一步。
但做到这里，很容易走进另一个坑：只给一个分数。
当前结果更接近“把符合条件的人先查出来”。如果某些字段或文本里有和当前招聘需求相关的关键词，可以单独列出来给顾问参考；没有的话，就直接展示查询到的字段信息，不必额外造一个看似精确的分数。
表格只是第一层结果。顾问看到某个人以后，如果想继续了解，就可以直接在同一轮对话里让Agent往下查这个候选人的详细信息。
候选人 | 基础字段信息 | 相关关键词（如有） | 下一步 |
候选人A | 按实际查询字段展示 | 按实际结果展示 / 无则留空 | 查看详细信息 |
候选人B | 按实际查询字段展示 | 按实际结果展示 / 无则留空 | 继续查询 |
候选人C | 按实际查询字段展示 | 按实际结果展示 / 无则留空 | 结合详细信息再判断 |
图-候选人查询结果
五、表格里看到一个候选人，接下来还能继续往下问
招聘筛选很少会在第一次搜索后就结束。
这时候，多轮对话就比“一次查完就结束”更有用。顾问可以直接指定某个候选人，继续查询他在人才库里的工作经历、项目经历、技能等已有信息；AI拿到这些详细数据后，也可以结合当前岗位需求，帮助把相关经历整理出来，或者辅助分析哪些信息值得继续关注。
如果看完结果以后发现查询范围太宽或太窄，也可以继续在这轮对话里修改条件，再让MCP重新查一轮。这里的“多轮”重点不是给候选人不断调权重，而是让查询和继续了解候选人这件事可以自然接着往下走。
这一步，才开始有点像真实的招聘工作。
这也是我们觉得Agent比单独做一个查询框更顺手的地方：先查一批人，再顺着结果继续查某个人，或者改条件再查，不需要每次都从头开始描述上下文。
图-多轮对话继续查询候选人详细信息
六、找着找着，人才库里另一个问题也跟着露出来了
人才库用了很多年，又是不同顾问持续维护，做到这一步以后，问题就不只剩“怎么找人”了。
同一个候选人，可能在不同年份被录入过不止一次。早期那条只有姓名和联系方式，后来的记录又多了新的工作经历和项目经验。系统里看起来是两个人，实际很可能还是同一个人。
这种数据一多，后面的匹配也会跟着受影响。记录长期分散，顾问看到的是多个候选人，AI也可能把同一个人重复当成不同对象。
这也让我们看到一个可以继续往下做的方向：利用姓名、电话等关键身份信息，辅助发现疑似重复记录，再让顾问人工核对。确认确实重复后，仍然回到原HR系统里合并记录或补充信息。
如果后续把这部分做进去，我们也不会让AI直接改正式人才数据。更合适的边界是：AI负责把可疑记录挑出来、提醒人去看，最后要不要合并、怎么补，仍然由人确认。
图-疑似重复候选人数据治理闭环图
如果后续启用这类能力，AI负责提示疑似重复记录；正式人才数据仍由人确认，并回到原HR系统处理。
人才库不是一次“清洗完”就结束，后续查询中发现问题 → 人工确认 → 回到原系统补充或合并 → 后续查询使用更完整的数据。数据质量和后续查询效果，在实际使用里形成了一个可以持续改善的闭环。
很多企业不缺系统，缺的是把某个麻烦的环节处理得更顺如果现有SOP里长期存在反复查询、核对、匹配或整理，可以先从这一小段流程入手，而不是一开始就重做整套系统。 【看看哪些业务环节适合AI改造 →】 |
七、最后真正变的，不是多了一个AI按钮，而是顾问从哪里开始判断
客户原来的HR系统没有被推翻，顾问也还是用熟悉的WorkBuddy。真正变化的，是面对30万条人才数据时，顾问不再从“先搜哪几个条件”开始。
原来的方式 | 引入AI Agent后的方式 |
先把招聘需求自己拆成多个搜索条件 | 直接输入JD或自然语言描述招聘需求 |
反复组合字段、筛选、打开候选人比较 | AI先提取条件并让用户确认 |
从大量结果中逐条判断谁值得继续看 | AI按确认后的字段条件查询，并把候选人结果整理成表格 |
条件变化后重新进入搜索流程 | 在多轮对话里修改查询条件，或者继续查某个候选人的详细信息 |
重复人才数据主要依靠人工发现 | 后续可增加AI辅助识别和提示，仍由人工确认 |
过去是顾问先从大量记录里自己组合条件、搜索、再逐个打开资料；现在AI先把需求整理成查询条件，通过MCP查出一批候选人。顾问需要继续看谁，就在同一轮对话里往下查详细信息，再结合AI的辅助分析做判断。
我们没有给这个变化硬套一个“效率提升多少”的百分比。对这个项目来说，工作起点从“自己去30万条数据里找”，变成“从AI已经收敛过的一批人里判断”，这本身就是最直观的变化。
八、AI可以先帮你把范围收窄，但最后那一下还是得人来
30万条数据，不等于30万条记录都同样完整。这个客户约80%的历史记录存在不同程度的信息缺失，JD本身也可能写得不够明确。
再往后，候选人的沟通状态、职业意愿，以及很多软性的匹配判断，本来就不可能只靠几个数据库字段下结论。
它负责听懂需求、把需求整理成查询条件、查数据、缩小范围，并在继续查询候选人详细信息时辅助整理和分析；顾问负责确认条件、看完整履历、和候选人沟通，再做最后判断。
这条边界留着反而更踏实。先让AI接手最重复、最耗时间的那一段，关键判断继续掌握在人手里，项目也更容易从一个具体环节开始。
九、从 AI 简历筛选往外看，很多企业都有类似的一段 SOP
这个项目是从AI简历筛选开始的。但把“招聘”两个字拿掉，你会发现背后其实就是一条很常见的企业工作链路：
提出需求 → 查询数据 → 组合条件 → 比较结果 → 继续调整 → 人工确认
HR里有，CRM、ERP、OA、项目管理、客户服务和内部运营里也可能有。很多工作单看每一步都不复杂，真正消耗时间的，是这些查询、核对、整理和判断每天都在重复。
所以我们现在和企业聊 AI 时，反而不会先问“要不要做一个 AI 平台”，而会先看一个更具体的问题：
你们现在到底哪一步最费人？
如果某个环节反复发生、规则相对清楚，而且最后仍然可以由人确认，就值得单独拿出来看看，AI Agent 能不能先把其中一部分接过去。
这个招聘项目也是这样。客户原来的 HR 系统没有被替换，我们只是在现有系统和人才数据之上增加 Agent 能力：先理解招聘需求，通过 MCP 查询候选人，再沿着对话继续查看详细信息、辅助整理和分析。
不一定先改造整套系统。先把那个每天都在重复的问题找出来，往往更容易看清 AI 到底适不适合。
把你的业务场景告诉我们，先看看哪一步最值得改 我们可以结合现有系统、数据、权限和实际流程，一起判断 AI Agent 适合放在哪个环节。 |
如果你也在考虑AI简历筛选，这几个问题可以先看
Q：AI简历筛选就是把PDF简历上传给大模型吗？
不一定。这个项目里，候选人信息本来就已经在HR系统里完成字段化处理，所以我们没有再做一遍PDF解析。Agent主要使用现有的人才数据理解招聘需求、整理查询条件、发起查询，并在继续查看候选人详细信息时辅助整理和分析。
Q：AI可以直接连接企业现有HR系统或数据库吗？
可以，但连接方式要看现有系统。这个项目里，我们把数据同步、清洗、打标后放到独立查询副本，再由MCP访问；换到其他企业，也可能直接通过API或MCP接现有系统，关键还是看接口、数据规模和安全边界。
Q：为什么这个项目还要让用户确认AI提取的条件？
因为后面真正拿去查数据库的，就是这一轮查询条件。先让顾问确认学历、工作年限、行业经验、技能、项目经历等条件，可以尽量把理解偏差挡在查询之前。
AI是怎么从人才库里筛候选人的？
当前方案先由Agent把JD或自然语言招聘需求整理成字段条件，再由MCP根据这些字段去数据库查询。结果以候选人表格为主；如果查询结果里有相关关键词，也可以作为单独信息展示。现阶段不把它描述成一套综合匹配评分或自动优先级排序。
Q：AI能完全替代HR或猎头筛选候选人吗？
不能。AI更适合先把需求听懂、整理成查询条件、从人才库里缩小范围，再在需要时继续查询某个候选人的详细信息并辅助分析。最后要不要继续沟通、候选人到底合不合适，还是要招聘人员结合完整履历、沟通情况、职业意愿和实际业务要求来判断。
Q：当前方案会自动给候选人打分或按匹配度排序吗？
目前不把这部分作为已实现能力来描述。MCP主要依据字段条件查询候选人；如果结果中有相关关键词，可以单独展示。后续如果要增加综合评分、权重或排序机制，需要再根据实际招聘规则设计，不能把它和当前字段查询混为一谈。
Q：除了招聘，哪些企业SOP适合评估AI Agent？
可以先看那些反复发生、规则相对清楚，又经常需要查询、筛选、核对、匹配、整理、分析或跨系统操作的环节。不是看到重复工作就一定上AI，还是要把现有系统、数据、权限和实际流程一起看清楚。
