AI简历筛选怎么做？基于千问办公AI Agent的企业人才库筛选解决方案

30万条候选人数据里，找出10个真正值得继续沟通的人，需要多久？

乍一看，这不该是个难题。

数据不少，系统也能搜。可真正为一个岗位找人时，顾问还是要反复拆条件、查结果、改条件，再重新筛一轮。AI 简历筛选真正要解决的，不是“有没有简历”，而是怎么从已经积累的人才库里，更快找到值得继续看的候选人。

所以问题很快就从“系统能不能搜”，变成了另一件事：顾问要花多少时间，把脑子里的判断一遍遍翻译成查询条件，再从结果里继续找。

我们这次服务的是一家约20-30人规模的猎头公司。客户现有HR系统里已经沉淀约30万条候选人记录，其中约80%的历史记录存在不同程度的信息不完整。数据又是不同顾问在不同年份持续维护的。人才库确实越来越大，可真到为一个岗位找人时，查询、比较、改条件、再查一轮，这些工作并没有因为“数据多了”就自动消失。

所以这个项目我们没有重新做一套 AI 招聘系统。客户原来的 HR 系统继续使用，我们在现有系统和人才数据之上增加了一个 AI Agent 入口：顾问把 JD 或招聘要求说出来，Skill 先把需求整理成可查询的条件，确认后，再通过 MCP 从人才库里按字段筛出候选人。

第一轮结果出来以后，也不是到此为止。顾问可以继续追问某个候选人的工作经历、项目经历和技能等已有信息，也可以调整条件再查一轮；AI 再根据查询到的详细信息辅助整理和分析。

这个项目真正改变的，其实不是谁来做最终判断，而是顾问从哪里开始找。过去是先钻进 30 万条数据里慢慢筛，现在可以先把需求说清楚，再让系统把符合条件的人找出来。

如果把整个方案拆开看，关系其实并不复杂：原来的 HR 系统仍然负责日常业务和人才数据维护，AI Agent 负责理解顾问的需求，Skill 负责把需求整理成查询条件，MCP 再去连接实际的人才数据。

图-方案架构图

正式HR系统继续承载原有业务；用于AI查询的数据同步到独立查询副本。Agent通过Skill整理查询条件，再由MCP访问数据。

而这套方案真正开始的地方，还是客户原来那套 HR 人才库。

客户已经在这里积累了约 30 万条候选人记录。换句话说，我们不是从“怎么把简历放进 AI”开始，而是在解决另一个问题：这些已经存在系统里的数据，怎么更方便地被重新找出来、继续查询和判断

图-客户现有HR系统中的人才库

一、系统明明能搜，为什么顾问还是要花时间找人？

如果条件真的只有“本科、5年以上工作经验、熟悉Java”，传统HR系统完全能查，这里没必要硬上AI。

可招聘筛选偏偏不是一道条件固定的选择题。换一个岗位，查询条件会变；就算岗位没变，看完第一轮人选以后，顾问也可能继续增加、放宽或收紧某些条件。

传统高级搜索要求顾问先把自己的判断翻译成字段和条件。我们这次把顺序倒了过来：先让顾问按平时的说法讲需求，再让AI把这些自然语言整理成系统能执行的查询条件。

所以我们这次真正改的，不是 HR 系统会不会搜，而是顾问和系统打交道的方式。顾问先按平时的说法讲需求，AI 再把这些话整理成系统能执行的查询条件。

二、真正让这个 Agent 跑起来，靠的不只是一个聊天框

前面说的是为什么要把 AI 加进这段招聘流程。

但如果只是让顾问多了一个可以聊天的窗口，这件事其实没有太大意义。真正要让它在业务里跑起来，还得解决两个问题：

顾问说的招聘要求，它能不能听懂？听懂以后，它能不能真的去人才库里查？

这个项目里，我们把前一件事放进了招聘 Skill。

顾问输入 JD，或者直接说希望找什么样的人，Skill 会把这些自然语言里的要求整理出来，变成后面可以继续使用的查询条件。

学历、工作年限、行业经验、岗位经历、技能、项目经历，这些原来需要顾问自己一点点拆出来的内容，现在先由 Agent 帮忙整理。

当然，整理出来不代表马上就拿去查。

后面真正执行查询之前，我们还是会把这些条件重新摆给顾问看，让人确认一遍。

我们在千问办公的“技能”中直接导入已经准备好的SKILL的ZIP压缩包即可，导入后就可以在“已安装”中看到这个SKILL了。

图-千问办公中招聘Skill的实际配置

导入的SKILL压缩包中包含几个关键文件，里面是一些示例和约束：

SKILL.md

---
name: qwenwork-ats-search
display_name: ATS 人才库增强搜索
display_name_en: ATS Talent Search
description: 通过受保护的 MCP 工具按权限完成候选人新搜索、多轮续筛、JD 匹配与证据化展示。
description_zh: 按登录身份和数据范围查询 ATS 候选人，并在每轮查询前让用户确认关键词。
description_en: Search and refine authorized ATS candidates, requiring keyword confirmation before every query.
allowed-tools: get_my_access, get_search_schema, classify_search_intent, prepare_candidate_search, refine_search, match_jd, similar_candidates, bulk_match, confirm_search, search_candidates, preview_search_sql, get_candidate, explain_match, list_my_queries, sync_status
version: 0.1.0
author: L&S
---

# ATS 人才库增强搜索

当用户要找候选人、粘贴 JD、继续筛选、查看候选人详情或查询本人历史时使用本技能。候选人数据只能通过本连接器的 MCP 工具访问。

## 不可绕过的顺序

1. 每个新对话或认证状态变化后，先调用 `get_my_access`。认证失败、账号停用或没有工具权限时停止，不要请用户在聊天中提供数据库账号、密码、`user_id` 或 `role`。
2. 首次使用或工具报告字段不一致时调用 `get_search_schema`。字段、操作符和枚举只能取工具返回值，完整简历不能作为筛选字段。
3. 调用 `classify_search_intent` 判断 `new_search`、`refine_search`、`other` 或 `ambiguous`。如果返回 `ambiguous`，先让用户明确是新搜索还是承接上一轮。
4. 从用户原话或 JD 提取结构化变更。新搜索调用 `prepare_candidate_search`；明确承接已有 `session_id` 时调用 `refine_search`；JD 使用 `match_jd`。不要生成或传递 SQL。
5. 把工具返回的全部 `keywords` 展示给用户，区分必须与偏好，并明确询问是否确认。本步骤每一轮都执行。
6. 只有用户明确确认后才调用 `confirm_search(confirmed=true)`，随后调用 `search_candidates`。不得把沉默、含糊回复或模型自己的判断当成确认。
7. 用户更正时不要确认旧 `proposal_id`。按更正重新准备 proposal，再展示完整关键词并重新确认。
8. 分页、详情、匹配解释和历史查询仍由 MCP 重新鉴权。不要根据前一页结果推断下一页可见范围。

`similar_candidates` 只用已授权可见的结构化字段和标签生成待确认 proposal，不代表向量相似度。`bulk_match` 在本地 DEMO 中最多准备 3 个 JD，并非生产异步任务；每个 proposal 都要单独确认。

## 条件处理

- 新搜索只包含当前请求。续筛从 MCP 保存的会话条件开始，使用 `add`、`replace` 或 `remove` 表达本轮变化。
- 会话归属以 MCP 返回的 `session_id` 为准，与用户开几个对话窗口无关：每个会话独立走自己的搜索流程，`session_id` 只在收到它的那个会话内使用，**不要把 A 会话的 `session_id` 带到 B 会话**。用户在新会话里直接提问时按新搜索走（不传 `session_id`）；用户明确要求承接另一个会话的结果时，让他把条件再说一遍（或贴回上一会话的确认清单），按这些条件开新搜索——跨会话继承由用户显式提供，不靠模型记忆。
- “上海也可以”是同字段增加值；“改成杭州”是替换；“取消 QS”是删除字段；“电商经验优先”是 `prefer`，不能变成硬过滤。
- 技能年限若数据库没有独立证据，只把技能作为标签，把年限作为总工作年限；输出中将特定技能年限写成待核实。
- `search_tags` 和 `company_relation_tags` 使用完整纯词，不带“技能:”或“关联:”前缀。
- 手机和邮箱只能做完整值精确查询，并且仍受字段权限控制。
- 候选人的唯一锚点是 `candidate_id`，姓名不是唯一标识（数据中存在同名）。用户只给姓名要看详情/解释时，先用姓名条件搜索出候选列表（可能多人），让用户按 ID 或其他特征确认是哪一位，再调 `get_candidate` / `explain_match`；不要把搜索结果中的第一个人直接当作目标。向用户展示和引用候选人时，始终带 `candidate_id`，便于区分同名。

### 公司词的匹配口径（match_mode）

公司类条件（`current_company`、`company_relation_tags`）带一个 `match_mode`：

- `exact`（默认）：严格按用户说的字面值搜，服务端一个字都不扩展。**任何情况下都不要自己把"阿里云智能"改写成"阿里巴巴"**——归一由服务端按词典做，不由模型做。
- `group`：由服务端按词典展开到同组词，例如"阿里云智能"展开成阿里系全部公司。

判断规则：

- 用户强调单点时用 `exact`：「就要阿里云智能」「只要蚂蚁」「仅菜鸟网络」「搜阿里云智能，不要别的」。
- 用户明确要整组时才用 `group`：「阿里系」「阿里相关的都看看」「蚂蚁菜鸟也算」「平安旗下」。
- 拿不准就按 `exact` 走，并在确认清单里补问一句：「只按 X 精确匹配，还是要扩展到 X 所在的集团？」

`group` 模式下服务端会把展开后的实际搜索词回显在 `expanded_values`。展示确认清单时把它一并列出，让用户看得见"阿里云智能"变成了哪几个词，再让他确认。

...

## 输出

- 先写已确认条件和当前工具返回的权限范围摘要，再写本页数量和范围内总数。
- 每位候选人只陈述 MCP 返回事实。保留 `matched_evidence.excerpt_markdown` 中已有的反引号高亮，例如 `Java`。
- 分开写匹配证据、未匹配或待核实项、风险点。没有字段证据时写"待核实"，不要补推。
- 每页最少 20 人、最多 30 人：调用 `search_candidates` 时传 `limit=20`；用户明确要更多时最多加到 30，不要超过。结果用一行一人的紧凑列表（姓名 | 现任公司职位 | 关键匹配点及高亮），不要逐人展开长段落。
- 工作经历摘要（`work_experience_summary`）默认不输出：内容是逐段经历流水，放进展示只会拖慢回复。仅当用户明确说"看他的工作经历"时，才按候选人 ID 调 `get_candidate` 单条获取。匹配证据只引用 `matched_evidence`，不要自行从摘要里摘句子。
- 需要完整资料时按候选人 ID 调 `get_candidate`，不要在一次搜索中要求所有完整简历。
- 不显示工具未返回的手机号、邮箱、出生日期或其他无权字段。

## 服务不可用时

MCP 连不上（连接拒绝/超时/401 且用户无法自行解决）时，只回复"系统服务暂不可用，请联系管理员"，停止并等待；不要尝试本地启动服务、不要运行命令、不要修改配置、不要给用户排查步骤。启动 MCP 是管理员的手动操作。

## 失败与恢复

- `Authentication required`：提示用户在连接器页面重新填写或刷新演示令牌。
- `not mapped`、`no assigned role`、`not permitted`：停止查询，请管理员修正身份或权限库。
- `proposal expired`：重新准备条件并再次让用户确认。
- `outside the caller's data scope`：说明该候选人不存在或当前账号不可见，不泄露是哪一种。
- `Audit persistence failed`：停止返回候选人数据，待审计库恢复后重试。
- SQL 或 schema 校验失败：刷新 `get_search_schema` 后重新构造结构化条件，不自行降级为任意 SQL。

workflows.md

# 调用流程示例

## 新搜索

用户：找上海 5 年以上会 Java 的候选人。

1. `get_my_access`
2. `classify_search_intent(question, change_count=3)`
3. `prepare_candidate_search`，提交城市、总工作年限和 Java 标签三个必须条件
4. 向用户展示返回的完整 `keywords`
5. 用户确认后调用 `confirm_search`
6. `search_candidates(limit=20)`
7. 按 Skill 规定展示候选人和高亮证据

## 继续筛选

用户：再加上 QS 前 100 的计算机硕士。

1. 使用上一轮 MCP 返回的 `session_id`
2. `classify_search_intent` 返回 `refine_search`
3. `refine_search` 添加 `qs_rank <= 100`、`major contains 计算机`、`degree_level >= 4`
4. 向用户展示工具返回的完整条件，其中包含上一轮仍有效条件
5. 用户确认后执行新 proposal

## 更正歧义

用户看到关键词后说：“不是总工作 3 年，是至少 3 年 Python 项目经验。”

当前样本没有独立的 Python 年限字段。不要把它改写成总工作年限。将 Python 保留为技能条件，把“3 年 Python 项目经验”列为待核实；如用户接受，再生成并确认新 proposal。

## JD

先把 JD 条件拆成必须、偏好和待核实，再调用 `match_jd` 创建 proposal。JD 原文只作为有长度限制的输入，数据库查询仍仅使用结构化条件。结果需逐项引用字段证据，不得把行业相近自动写成经历匹配。

search-contract.md

# 搜索契约

## 变更对象

`prepare_candidate_search`、`refine_search` 和 `match_jd` 接收 `SearchChange` 列表：

- `action`: `add`、`replace` 或 `remove`
- `field`: `get_search_schema` 返回的可筛选字段
- `operator`: `eq`、`neq`、`gte`、`lte`、`contains` 或 `any_contains`
- `values`: 1 至 20 个标量；`remove` 整个字段时可为空
- `requirement`: `must` 或 `prefer`
- `match_mode`: `exact`（默认，按字面值精确匹配，服务端不做任何同义词扩展）或 `group`（服务端按词典展开到同组词，如"阿里云智能"→阿里系全部）。仅公司类字段有效；用户强调"就要 X"时保持 `exact`，明确说"X 系 / 集团 / 都算"才用 `group`。

数字字段只能使用数字操作符。标签字段只能使用 `contains` 或 `any_contains`。偏好条件只参加排序，不排除候选人。

## 字段选择优先级

1. 公司/集团/行业归属 → `company_relation_tags`；技能/专长 → `search_tags`（与打标字段 `skill_keywords` 同源）。
2. 打标字段查不到、或用户明确要看经历原文时，才兜底用 `work_experience_summary` / `project_experience_summary`。
3. 明确指"现在在哪"才用 `current_company` / `current_title` 等当前字段。

## 固定边界

- `degree_level`: 大专 2、本科 3、硕士 4、博士 5。
- `qs_rank`: “QS 前 N”使用 `lte`。
- `total_experience_years`: 总工作年限，不等于某项技能的使用年限。
- `major`: “计算机相关”使用 `contains` 和值“计算机”；精确专业才使用 `eq`。
- `search_tags`: 技能等纯词标签，多个必须技能用 `contains` 的多个值；任一技能可用 `any_contains`。
- `company_relation_tags`: 有明确经历证据的公司标准词，不按同行、竞品或赛道自动扩展。
- `complete_candidate_profile`: 仅详情展示，禁止筛选。

MCP 服务端会把模型输入转换为参数化 SQL，强制注入数据范围和 LIMIT，并用 SQL 解析器校验最终语句。模型不得提交自由 SQL。

其实也能看出一件事：我们并不是临时写一段提示词，让大模型“自己发挥”。

招聘场景里哪些信息需要识别、怎么整理成查询条件，后面拿到候选人的工作经历和项目经历以后又怎么继续处理，这些业务逻辑都会围绕实际招聘流程放到 Skill 里。

这样 Agent 前面看起来是在聊天，背后其实已经有一套比较明确的做事方式。

但只听懂还不够。

条件整理出来以后，最终还是要落到那 30 万条真实人才数据上。

这就是 MCP 在这个项目里要做的事情。

我们把人才数据的查询能力通过 MCP 接进 Agent。等顾问确认查询条件以后，Agent 才会继续调用 MCP，去访问已经准备好的查询数据。

图-用于企业人才库查询的 MCP 配置

所以 Skill 和 MCP 在这里其实分工得很清楚：

Skill 负责“听懂”，MCP 负责“查到”。

一个把顾问平时说的招聘要求整理成系统能理解的条件，一个把这些条件真正带到企业已有的人才数据里。

图-招聘 Agent中Skill与MCP的能力关联

到这里，这个 Agent 才算真正有了“干活”的基础。

后面顾问看到的条件确认、人才查询、权限控制，以及查到一个候选人以后继续往下问，都是从这两部分能力继续展开的。

三、AI Agent 先别急着查库，得先把“你要找谁”听明白

顾问可以直接在千问办公里粘贴JD，也可以像平时沟通需求那样，直接说希望找什么样的人。Agent会调用已经配置好的招聘Skill，把这段话拆成学历、工作年限、行业与岗位经验、技术技能、工作经历、项目经历等维度。

不过我们没有让它听完就直接去查库，先让顾问确认。

Agent会先把自己提取出来的查询条件摆出来。这个动作看起来多了一步，其实很关键。JD本身可能写得不够明确，AI也可能理解偏；如果一开始条件就错了，后面数据库查得再快，结果也会从错误的方向开始。

顾问确认没问题，再继续往下走。我们希望AI负责“理解和执行”，但这一轮到底按什么标准找人，关键条件还是由顾问自己把关。

图-招聘查询流程图

图-AI提取招聘条件并让用户确认

四、条件听懂了。接下来，它去哪里查这30万条数据？

到这里，才轮到一个很现实的技术问题。

30万条人才数据都在客户正式HR系统里。那是不是让AI Agent每次筛选都直接去查生产数据库？我们没有这么做。

我们把用于查询的人才数据先同步到独立的数据库副本，再按后续筛选需要做清洗和打标。千问办公里的Agent需要找人时，通过MCP查的是这份副本。

另外，这份查询数据可以围绕人才筛选去整理字段、标签和数据质量，后面查起来也更顺手。

当然，数据库副本只是这个项目的选择，不是所有企业都要照搬。换一个系统，我们还是会重新看接口能力、数据规模、更新频率、安全要求，以及现有系统能承受什么，再决定是直接接，还是单独准备一份查询数据。

权限怎么管？这件事我们没有交给提示词去“自觉遵守”

数据一旦接进Agent，权限就不能突然消失。不同用户原本能看到的数据范围不一样，接入AI以后也应该继续守住这条边界。

这个项目里，我们把用户登录和角色权限带进了MCP的数据访问逻辑。MCP真正去查数据时，会结合当前用户的身份和角色，先控制他能访问哪些数据，再把结果交回Agent。

你可以把它理解成两件事：Agent负责听懂“你想查什么”，权限控制负责回答“你本来能查什么”。接入AI，并不等于原来的数据边界就可以被绕过去。

不同企业原来的账号体系、角色划分和数据边界都不一样。真要接入时，权限要细到什么程度，我们会沿着现有系统继续设计，而不是因为多了一个AI入口，就另外造一套脱离业务的权限逻辑。

图-用户权限与数据查询链路

在这条链路里，Agent理解需求，MCP结合当前用户身份和角色控制查询范围，再把允许返回的数据交给Agent。

图-MCP 中的用户角色与数据访问控制配置 

五、第一轮结果先列出来。这里没有一个“神秘的匹配分”

条件确认以后，Agent通过MCP按字段条件去查人才数据。查到的人选先以表格形式列出来，这就是当前方案最核心的一步。

但做到这里，很容易走进另一个坑：只给一个分数。

当前结果更接近“把符合条件的人先查出来”。如果某些字段或文本里有和当前招聘需求相关的关键词，可以单独列出来给顾问参考；没有的话，就直接展示查询到的字段信息，不必额外造一个看似精确的分数。

表格只是第一层结果。顾问看到某个人以后，如果想继续了解，就可以直接在同一轮对话里让Agent往下查这个候选人的详细信息。

图-候选人查询结果

六、表格里看到一个候选人，接下来还能继续往下问

招聘筛选很少会在第一次搜索后就结束。

这时候，多轮对话就比“一次查完就结束”更有用。顾问可以直接指定某个候选人，继续查询他在人才库里的工作经历、项目经历、技能等已有信息；AI拿到这些详细数据后，也可以结合当前岗位需求，帮助把相关经历整理出来，或者辅助分析哪些信息值得继续关注。

如果看完结果以后发现查询范围太宽或太窄，也可以继续在这轮对话里修改条件，再让MCP重新查一轮。这里的“多轮”重点不是给候选人不断调权重，而是让查询和继续了解候选人这件事可以自然接着往下走。

这一步，才开始有点像真实的招聘工作。

这也是我们觉得Agent比单独做一个查询框更顺手的地方：先查一批人，再顺着结果继续查某个人，或者改条件再查，不需要每次都从头开始描述上下文。

图-多轮对话继续查询候选人详细信息

七、找着找着，人才库里另一个问题也跟着露出来了

人才库用了很多年，又是不同顾问持续维护，做到这一步以后，问题就不只剩“怎么找人”了。

同一个候选人，可能在不同年份被录入过不止一次。早期那条只有姓名和联系方式，后来的记录又多了新的工作经历和项目经验。系统里看起来是两个人，实际很可能还是同一个人。

这种数据一多，后面的匹配也会跟着受影响。记录长期分散，顾问看到的是多个候选人，AI也可能把同一个人重复当成不同对象。

这也让我们看到一个可以继续往下做的方向：利用姓名、电话等关键身份信息，辅助发现疑似重复记录，再让顾问人工核对。确认确实重复后，仍然回到原HR系统里合并记录或补充信息。

如果后续把这部分做进去，我们也不会让AI直接改正式人才数据。更合适的边界是：AI负责把可疑记录挑出来、提醒人去看，最后要不要合并、怎么补，仍然由人确认。

图-疑似重复候选人数据治理闭环图

如果后续启用这类能力，AI负责提示疑似重复记录；正式人才数据仍由人确认，并回到原HR系统处理。

人才库不是一次“清洗完”就结束，后续查询中发现问题 → 人工确认 → 回到原系统补充或合并 → 后续查询使用更完整的数据。数据质量和后续查询效果，在实际使用里形成了一个可以持续改善的闭环。 

八、最后真正变的，不是多了一个AI按钮，而是顾问从哪里开始判断

客户原来的HR系统没有被推翻，顾问也还是用熟悉的千问办公。真正变化的，是面对30万条人才数据时，顾问不再从“先搜哪几个条件”开始。

过去是顾问先从大量记录里自己组合条件、搜索、再逐个打开资料；现在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简历筛选，这几个问题可以先看

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，还是要把现有系统、数据、权限和实际流程一起看清楚。