预计阅读时间：9 分钟
求职者最头疼的事，不是没有岗位，而是信息散、节点多、匹配难——政策藏在 FAQ 里，进度要反复刷页，简历投出去像石沉大海。小米这次上线的招聘 Agent，试图用一个对话窗口把这些问题叠在一起解决。
一个 Agent 承担了哪些职责
根据小米官方介绍，这个 Agent 依托自研的 Xiaomi MiMo 大模型，部署在小米招聘官网，核心能力有三层：
- 政策解答：校招时间线、薪酬福利、转岗规则等，直接对话获取，不再翻文档。
- 职位智能推荐：用户上传简历后，Agent 自动解析教育背景、项目经历、技能栈，再与小米在招岗位做语义匹配，输出推荐列表。
- 招聘进展查询：投递状态、面试安排、Offer 节点，Agent 代为整理成时间线呈现。
换句话说，它扮演的是一个"资深 HR"的角色——不是冷冰冰的搜索框，而是能理解你背景、主动给你建议的对话助手。
简历解析 + 岗位匹配的技术推演
小米没有公开底层架构细节，但从功能描述可以推断，Agent 至少包含两个关键 pipeline：
- 简历结构化抽取：从 PDF/Word 中提取字段（学校、专业、项目、技能关键词），这通常依赖 LLM 的信息抽取能力 + 规则后处理。
- 岗位语义匹配：将抽取结果与岗位 JD 的向量做相似度计算，或直接让 LLM 做推理排序。
下面用一个最小示例演示如何用 Python 实现类似逻辑——简历抽取 + 岗位推荐。你可以直接复制运行，只需替换 API Key 和简历内容。
"""
最小招聘 Agent 示例：简历解析 + 岗位推荐
依赖：openai >= 1.0, pydantic >= 2.0
运行前设置环境变量：export OPENAI_API_KEY=sk-xxx
"""
import os
import json
from openai import OpenAI
from pydantic import BaseModel
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
# ---------- 1. 定义简历结构化模型 ----------
class ResumeProfile(BaseModel):
education: str # 例: "浙江大学 计算机科学 本科"
skills: list[str] # 例: ["Python", "PyTorch", "Kubernetes"]
projects: list[str] # 例: ["电商推荐系统重构", "实时日志监控平台"]
years_of_exp: int # 工作年限
# ---------- 2. 简历文本抽取 ----------
RESUME_TEXT = """
张三，浙江大学计算机科学本科，3年工作经验。
项目经历：
- 电商推荐系统重构：使用 PyTorch 训练深度排序模型，QPS 提升 40%
- 实时日志监控平台：基于 Elasticsearch + Kafka 构建，日均处理 2TB 日志
技能：Python, PyTorch, Kubernetes, Elasticsearch, Go
"""
extract_prompt = f"""
从以下简历文本中抽取结构化信息，严格按 JSON schema 输出：
{json.dumps(ResumeProfile.model_json_schema(), indent=2)}
简历文本：
{RESUME_TEXT}
"""
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": extract_prompt}],
response_format={"type": "json_object"},
)
profile = ResumeProfile.model_validate_json(resp.choices[0].message.content)
print("=== 解析结果 ===")
print(profile.model_dump_json(indent=2))
# ---------- 3. 岗位语义匹配 ----------
JOBS = [
{"id": "J001", "title": "推荐算法工程师", "jd": "负责推荐系统算法研发，要求熟悉 PyTorch、深度学习模型训练与部署"},
{"id": "J002", "title": "云原生运维工程师", "jd": "负责 Kubernetes 集群运维与监控体系建设，要求熟悉 K8s、Elasticsearch"},
{"id": "J003", "title": "前端开发工程师", "jd": "负责 Web 端交互开发，要求熟悉 React、TypeScript"},
]
match_prompt = f"""
你是一位资深 HR，根据候选人画像从在招岗位中选出最匹配的 3 个，按匹配度降序排列。
对每个岗位给出匹配理由和匹配度评分(0-100)。
候选人画像：
{profile.model_dump_json(indent=2)}
在招岗位：
{json.dumps(JOBS, ensure_ascii=False, indent=2)}
输出 JSON 数组，每个元素包含：job_id, match_score, reason
"""
resp2 = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": match_prompt}],
response_format={"type": "json_object"},
)
print("\n=== 推荐结果 ===")
print(resp2.choices[0].message.content)
运行后你会得到类似输出：
=== 解析结果 ===
{
"education": "浙江大学 计算机科学 本科",
"skills": ["Python", "PyTorch", "Kubernetes", "Elasticsearch", "Go"],
"projects": ["电商推荐系统重构", "实时日志监控平台"],
"years_of_exp": 3
}
=== 推荐结果 ===
{
"recommendations": [
{"job_id": "J001", "match_score": 92, "reason": "PyTorch 经验直接对口，推荐系统项目高度匹配"},
{"job_id": "J002", "match_score": 78, "reason": "K8s 和 ES 经验吻合，但算法背景稍偏"},
{"job_id": "J003", "match_score": 15, "reason": "无前端技能，不匹配"}
]
}
这个示例用的是 OpenAI API，小米实际生产环境自然换成了 MiMo 模型，但 pipeline 逻辑是同构的：抽取 → 结构化 → 语义匹配 → 排序输出。
从"搜索"到"对话"的交互跃迁
传统招聘网站的交互模型是单向的：用户搜 → 系统列 → 用户选。Agent 模型引入了两个变化：
- 主动推荐：用户不需要知道"推荐算法工程师"这个关键词，只要上传简历，Agent 就能从技能栈推断出匹配方向。
- 上下文延续：追问"这个岗位面试一般几轮"、"校招和社招时间线有什么不同"，Agent 能在同一会话里连贯回答，而不是跳转到另一个页面。
这种交互模式的代价是对模型推理稳定性的要求更高——一旦推荐理由出现事实错误（比如把岗位要求说错），信任感会迅速崩塌。小米选择在官网场景落地而非开放平台，范围可控，风险也可控。
落地启示与注意事项
如果你也在考虑为业务搭建类似的招聘/匹配 Agent，几个实操要点值得留意：
| 维度 | 建议 |
|---|---|
| 简历解析 | 用 Pydantic 定义 schema + response_format=json_object 强约束输出，比纯文本抽取稳定得多 |
| 岗位匹配 | JD 数量少于 50 时可直接让 LLM 推理排序；超过 50 应先做向量检索缩小候选集，再让 LLM 精排 |
| 幻觉控制 | 岗位要求、薪酬范围等硬事实必须从数据库取，不要让模型"自由发挥" |
| 隐私合规 | 简历属于敏感个人信息，存储和传输必须加密，且需明确告知用户数据用途与保留期限 |
| 灰度策略 | 先在内部招聘/校招等窄场景验证，再扩展到全量社招 |
小米这次上线的是一个具体场景的 Agent，不是通用框架。它的价值在于证明：大模型在招聘这种信息密集、决策链长的场景里，确实能把"找岗—投递—跟踪"三步压缩成一个对话流。接下来值得观察的是匹配精度和用户留存——如果推荐命中率低，对话再流畅也只是体验包装。