招聘这件事儿，说实话，早就变味了。你有没有想过当你辛辛苦苦把那份排版精美、图文并茂的PDF简历投出去之后它在HR的屏幕上，或者在AI Agent的眼里到底是个什么样子？

现实往往有点骨感。现在的流程大多是这样的：HR把一份职位描述随手扔给一个AI Agent，然后这个Agent就开始像没头苍蝇一样，在成百上千份PDF文档里乱撞。为什么？因为PDF这东西，本质上就是给人类眼睛kan的，它是为了打印而生的，根本不是为了机器阅读而设计的。那些复杂的排版、花哨的表格、甚至是嵌入的图片，对于AI来说简直就是一场灾难。信息被分散在各个角落，无法精确查询，Agent读起来费劲，理解起来geng费劲。

这时候我就忍不住想问一句：既然我们dou在谈论AI原生，为什么不干脆把简历也变成“AI原生”的呢？我指的不是那种所谓的“AI友好型”简历——那种词藻堆砌的废话——而是真正让AI AgentNeng够像连接数据库一样，连上来、按需查询、Zuo结构化分析的数据源。

带着这个念头，我折腾出了一个新玩意儿：我给自己的简历加了一个MCP Server。这听起来可Neng有点极客，但逻辑其实hen简单。当有人访问我的公开主页时AI AgentNeng够自动发现这个端点，连上来之后Ke以随意搜索我的项目经历、分析岗位匹配度，甚至查询我对某项技Neng的熟练程度。整个项目我Yi经开源了今天咱们不聊那些枯燥的代码实现细节，重点来探讨一下“简历 + MCP”这个组合，到底意味着什么以及它如何改变招聘的游戏规则。

什么是MCP？AI时代的API新标准

在深入之前，得先科普一下这个核心概念。MCP是AnthropicZui近提出的一个开放协议。它的核心目标非常纯粹：让AI AgentNeng够以一种标准化的方式，去连接外部的数据源和工具。

你Ke以把它理解为“AI时代的API”。但咱们传统的API，那是写给人调用的，你得kan文档，你得写代码，你得处理各种错误码。而MCP不一样，它是“自描述”的。什么意思呢？就是说这个工具自带名字、描述、输入参数的Schema。AI Agent只要连上MCP，就Neng自动理解这个工具是干嘛的，该怎么用，完全不需要人类去写什么对接文档。这就好比给AI发了一张通用的通行证，它自己就Neng找到路。

当AI Agent连上你的简历，它NengZuo什么？

想象一下当招聘方的AI Agent通过MCP连上你的简历服务器，它就不再是被动地“阅读”一份文档，而是主动地“查询”一个数据库。这种交互方式的转变，带来了无限可Neng。

比如说Agent可Neng会发出这样的指令：

场景一：精准搜索特定经历 Agent问：“帮我找找这人在大数据方面的相关经历。” 你的MCP Server响应：

search_resume
// 返回结果：
{
  "highlights": ,
  "source_module": "project_experience",
  "relevance_score": 0.95
}

这比让AI去PDF里瞎猜“大数据”三个字在哪，要准确得多。

场景二：岗位匹配度分析 Agent问：“这个候选人适合我们要招的高级全栈工程师吗？我们需要5年以上经验，熟悉React和Node.js，Zui好有大数据平台开发经验。” MCP Server迅速计算并返回：

evaluate_fit({ 
  job_description: "高级全栈工程师，5年+经验，React/Node.js，有大数据平台开发经验，熟悉DevOps" 
})
// 返回结果：
{
  "score": 92,
  "matched_skills": ,
  "missing_skills": ,
  "recommendation": "Strong match! 候选人在全栈开发和大数据处理方面有深厚积累，虽然Kubernetes经验未明确提及，但DevOps背景表明上手极快。"
}

场景三：生成全面评估报告 Agent问：“给我一份关于这个人的全面职业。” MCP Server直接输出结构化画像：

get_career_summary
// 返回结果：
{
  "seniority": "senior",
  "total_years": 6,
  "domains": ,
  "core_strengths": ,
  "top_skills": 
}

kan到区别了吗？所有这些dou是标准的JSON数据，AI AgentKe以直接拿去程序化处理，生成报告，或者Zuo进一步的对比分析，完全不需要去费劲巴力地解析PDF格式，也不用担心因为排版错乱而漏掉关键信息。

从“投递文档”到“建立连接”的范式转移

咱们来对比一下传统的流程和这个新流程，你会发现其中的微妙之处。

在传统流程里是你把一份冷冰冰的PDF扔出去，然后HR或者他们的初级筛选工具，像扫描仪一样过一遍。Ru果运气好，你的关键词被捕捉到了可Neng会转给AIZuo辅助判断。整个过程，你是被动的，文档是静态的。

而在新的MCP流程里你给HR的是一个链接，外加一个邀请码。HR的AI Agent通过这个链接连上你的MCP Server。这时候，主动权发生了转移：AgentKe以根据它关心的问题，动态地发起查询，而不是被动地读一份固定格式的死文档。

这不仅仅是技术上的小修小补，这是信息查询主动权的根本性转移。从HR的人工扫视，转移到了AI Agent的按需检索。

设计亮点：邀请码机制与反向筛选

在这个设计里我个人Zui满意的部分，其实是那个kan似简单的“邀请码”机制。

当你投递简历时你给对方的是“链接 + 邀请码”。HR必须把这个邀请码配置到他们的AI客户端，Agent才Neng通过认证，查到深度的结构化信息。

这其实是一个非常巧妙的反向筛选机制。试想一下Ru果一个团队的AI素养不够，根本不知道怎么配置MCP客户端，或者不知道怎么用邀请码，那这个流程对他们来说就是走不通的。Neng走通这个流程的团队，说明他们Yi经在使用AI Agent进行招聘工作了大概率也是一个geng现代化、geng拥抱技术变革的团队。

而且，邀请码还支持追踪功Neng。你Neng在后台kan到对方的Agent具体查了哪些工具，在什么时间查的。这比传统招聘网站上那种“您的简历Yi被查kan”的模糊通知要有价值多了。你Neng知道对方真正关心什么——是查了你的项目经验，还是重点kan了你的技Neng栈？这种数据反馈，对于求职者来说简直是金矿。

AI Agent是如何发现你的简历服务的？

你可Neng会问，AI Agent怎么知道我的简历主页上藏着一个MCP服务呢？这可是整个设计里Zui关键的一环——发现，往往比连接geng重要。

我设计了一套三层发现机制，由浅入深，层层递进：

# 1. AI Agent 访问你的公开主页 https://your-domain.com
# ↓
# 2. 解析 HTML 头部，发现特殊的 Link 标签
# ↓
# 3. 请求 /.well-known/mcp 标准端点，获取完整的元数据
# ↓
# 4. 使用邀请码通过 Authorization header 进行连接
# ↓
# 5. 开始查询数据

这三层发现机制，每一层dou有它的使命：

第一层：HTML Head 注入

这是Zui浅的一层，公开页面的HTML头部会自动注入一些标签，维护成本几乎为零。只要页面Neng打开，AI就Neng嗅到味道。

第二层：/.well-known/mcp 标准端点

这一层是给机器kan的。利用互联网标准的`well-known`路径，返回机器可读的完整MCP配置。

{
  "mcp": {
    "endpoint": "/mcp",
    "transport": "http",
    "auth": { "type": "bearer" },
    "tools": 
  }
}

这三层信息全部dou是由服务端自动生成的，数据源头只有一份，那就是你的`resume.json`。只要你改了简历内容，所有的发现信息dou会自动同步geng新，完全不用手动去改HTML或者配置文件。

技术实现：不追求高大上，只追求够用

说完了产品形态，咱们简单聊聊技术实现。这个项目定位为一个自托管的全栈应用，不是那种收费的SaaS。单用户，部署在你自己的服务器上，数据完全掌握在自己手里。

核心原则非常简单：数据只有一份。无论是前端的编辑器，还是后端的MCP服务，它们共享同一个数据源——`resume.json`。MCP每次请求dou是实时读取Zui新数据，不存在缓存不一致的尴尬问题。

至于技术栈，其实没什么好吹的，dou是大家熟悉的老朋友：

前端编辑器React + Vite + Tailwind CSS。写起来快，界面也还算清爽。

服务端Node.js 原生 HTTP。为了这点小流量上Express或者Koa有点杀鸡用牛刀，原生API足矣。

协议层官方的 MCP SDK。

数据校验Zod。这玩意儿在前后端数据一致性上简直是神器。

关于搜索功Neng，我实话实说用的是自实现的TF评分加上中英混合分词。这水平够用，但绝对算不上顶尖。也就是个关键词匹配的程度，跟那些基于向量嵌入的真正语义搜索比起来差距还是有的。不过对于简历这种结构化程度相对较高的数据，关键词匹配往往比瞎猜的语义搜索geng精准。

几个值得玩味的技术决策

在开发过程中，我Zuo了几个小的技术决策，虽然不起眼，但我觉得挺有意思，值得拿出来聊聊：

1. 原子写入而不是数据库 简历数据撑死也就2KB，为了这点数据去搞个SQLite或者MySQL，未免太重了。我直接用了文件系统。为了保证并发安全，用了“写临时文件 + 重命名”的策略，这是Unix/Linux系统下保证原子操作的经典Zuo法。再加上一个简单的写队列防止并发冲突，实测下来稳得一匹。

2. MCP请求时实时创建Server实例 我没有在应用启动时就建一个长驻的MCP Server，而是每次收到MCP请求时才调用`createMcpServer`。这样Zuo的好处是保证每次读到的dou是内存里Zui新的数据。前端编辑器一点保存，后端的MCP服务立刻就Nengkan到变化，没有任何延迟。

3. Zod Schema 校验 不管是读数据还是写数据，我dou加了一层Zod校验。前端编辑器虽然理论上也会Zuo校验，但作为后端开发者，“永远不信任前端输入”应该刻在骨子里。Zod在这里充当了守门员的角色。

4. Stdio 模式的支持 除了标准的HTTP传输，我还支持了`start:stdio`模式。这意味着你Ke以直接在Claude Desktop的配置文件里指向这个项目，本地开发的时候甚至dou不需要起HTTP服务器，直接通过标准输入输出流通信，调试起来极其方便。

部署与体验：把简历握在手里

部署这事儿，我尽量Zuo到了傻瓜化。Ru果你有Docker环境，那简直是一键启动：

# 复制配置文件
cp config.example.json config.json  
# 修改里面的 authCode
# 启动服务
docker compose up -d

当然Ru果你想本地体验，也Ke以直接在Claude Desktop里配置直连：

{
  "mcpServers": {
    "my_resume": {
      "command": "npx",
      "args": ,
      "cwd": "/path/to/your-resume-project"
    }
  }
}

说点真话：算法虽菜，愿景hen大

写到这儿，我得坦诚一点。这个项目的搜索算法和匹配逻辑，说实话，真的hen一般。TF评分就是Zui基础的关键词频率统计，技Neng标准化也就是个查表映射，那个`evaluate_fit`的匹配逻辑本质上还是在Zuo字符串包含检测。这些东西离所谓的“精准理解个人数据”还有十万八千里。

但是这个项目真正有趣、真正有价值的地方，从来不在于算法有多牛逼。

它的核心价值在于探索了“简历 + MCP”这个组合所产生的新可Neng性：

交互方式的质变从“阅读文档”变成了“查询服务”。

筛选机制的创新用技术门槛筛选出懂AI的团队。

反馈闭环的形成Nengkan到对方真正关心什么而不是盲投。

这三个变化，跟技术实现的复杂度没多大关系，它们是产品形态层面的创新，是对未来人机交互方式的一种预演。

拥抱AI原生的未来

我知道，MCP现真正会去用AI Agent连MCP的招聘方，目前可Neng凤毛麟角。但大方向肯定是没错的——当AI越来越多地介入到我们工作和生活的每一个流程时我们的个人展示方式，也必须从“给人kan的文档”，进化成“给AI查的数据源”。

这不仅仅是简历的问题，这是所有个人数字资产面临的问题。Ru果你也在玩MCP，或者对“AI原生的个人信息展示”有什么奇思妙想，欢迎随时来交流。

Zui后Ru果你觉得这个项目有点意思，或者对你有启发，欢迎去GitHub给个Star。你的支持是我继续折腾的动力。

在线体验地址http://example-resume-site.com

GitHub项目地址github.com/Leeson-Wong/resume-mcp-server

---