当 AI Agent 开始替人求职：OJCP 如何把职位搜索与申请流程变成可调用协议
让 Agent 帮人找职位，表面上像一个网页自动化问题：搜索岗位、打开详情页、填写表单、提交申请。但真正的难点不是能不能点按钮，而是每家招聘站、ATS 和外链申请页对同一件事使用了不同字段、跳转和权限规则。今天的 Agent 往往依赖抓取、浏览器脚本和脆弱的表单选择器；页面一改、出现验证码或流程跳到第三方 ATS，自动化就失去可靠边界。
OJCP（Open Job Context Protocol） 尝试为这个垂直场景补上数据契约。它是由 Recruitics 发起的开源规范仓库，当前状态明确为 Draft v0.1：目标不是替代 MCP，也不是交付一个“自动海投”产品，而是在 MCP、WebMCP、schema.org JobPosting 和既有招聘 feed 之上，统一描述职位、雇主上下文、申请路径、候选人授权与状态查询。
这一区分很重要。MCP 解决的是“客户端怎样调用工具”；OJCP 试图回答“招聘领域究竟有哪些工具、每一步传什么、哪一步允许 Agent 代办”。如果说 HTTP 不会定义一张订单应该有哪些履约字段，那么通用 Agent 协议也不会天然知道职位申请的 session、验证证明和申请状态该如何关联。
先发现能力，再决定是否自动化
OJCP 的入口不是先抓职位页，而是让提供方在固定位置发布 manifest：/.well-known/ojcp.json。Agent 可以从中获知协议版本、提供方、可用工具、端点、认证选项和限流信息。规范的 manifest schema 要求至少声明 ojcp_version、provider 与 tools；其他信息可按提供方实际能力补充。
一个招聘站可以将自己的能力描述为下列结构。这里的域名和端点是官方示例中的演示值，并不代表存在可直接调用的真实服务：
{
"ojcp_version": "0.1",
"provider": {
"name": "Example Corp Careers",
"employer_id": "example-corp"
},
"feed_endpoints": {
"search": "https://careers.example.com/ojcp/v1/search",
"detail": "https://careers.example.com/ojcp/v1/jobs/{job_id}"
},
"mcp_endpoint": "https://careers.example.com/ojcp/mcp",
"tools": [
"search_jobs",
"get_job_detail",
"get_employer_context",
"begin_application",
"submit_application",
"check_application_status"
]
}
这个设计的价值在于把“站点能做什么”从隐含的网页行为，变成可检查的声明。Agent 不必先猜一个申请按钮是否可以安全操作，而可以先判断该提供方是否支持搜索、是否提供申请初始化、是否有可查询的状态接口。对平台方而言，manifest 本身不等于安全认证；它只是一份能力声明，后续仍应按 schema 验证响应，并对实际工具调用做鉴权、审计和限流。
六个工具，把求职流程拆成可控阶段
OJCP 预定义了六项 MCP-compatible 工具：search_jobs、get_job_detail、get_employer_context、begin_application、submit_application 和 check_application_status。它们对应的不是一个黑箱“帮我投递”，而是一条可拆分的工作流。
例如，求职 Agent 可先以 search_jobs 找出候选岗位，读取 get_job_detail 的完整要求，再用 get_employer_context 补齐团队或雇主信息。只有用户确认目标与授权范围后，才调用 begin_application 建立申请会话；提交和追踪则分别由 submit_application、check_application_status 负责。
拆分的工程意义在于风险分层：搜索可以是低风险读取，提交却会产生外部影响。官方的 submit_application 输入 schema 要求 application_id 与 session_token，把提交动作绑定到前一步创建的上下文，而不是只接收一份简历 URL 就直接执行。可选的 verification_proofs 还能承载外部身份验证结果：
{
"name": "submit_application",
"arguments": {
"application_id": "app_abc123",
"session_token": "sess_def456",
"verification_proofs": [
{
"step_id": "vs_1",
"verifier_id": "id.me",
"verification_type": "identity",
"issued_at": "2026-03-18T14:30:00Z",
"expires_at": "2026-03-19T14:30:00Z"
}
]
}
}
示例表达的是数据形态，并不是让开发者硬编码令牌，更不能据此推断所有招聘系统已经接受这类提交。真正的实现应该在服务端校验 session、授权范围、过期时间和验证方可信度，并记录每一次代表用户发起的动作。
apply_paths 才是职位数据的关键增量
传统 JobPosting 擅长描述职位名称、地点、职责和薪资，却未必能回答：这份职位该从哪里申请？是否允许 Agent 代交？要填写哪些字段？会不会跳到另一个 ATS？
OJCP 通过 apply_paths 描述这些路由信息，涵盖 ats_direct、provider_hosted、platform_native、email、external_redirect 等类型，并用 supports_agent_submission 明示机器代办是否被支持。对工作流设计者而言，这比从页面 DOM 猜测“提交”按钮更有用：可以先筛掉只允许人工完成的路径，把支持自动提交和需要用户接管的路径分流，再为每一类设置不同的审批与回退策略。
这也提示了正确的使用边界。OJCP 不应成为批量投递器的免责外壳。一个负责任的 Agent 至少要在提交前向用户展示岗位、简历版本、将发送的数据和目标站点；遇到外链跳转、补充问答、敏感身份信息或网站未声明支持自动提交时，应停在确认点而不是绕过限制。
在实现层面，还应把“可撤销”视为申请自动化的一部分：begin_application 后不要立即把完整候选人资料散发到多个系统，而应让用户能看到待发送字段、撤回当前会话或选择不继续提交。服务端日志也应区分 Agent 的读取、草稿生成与实际提交，并为每次外部写操作保存用户确认、请求标识和结果摘要。这样即使某个 ATS 临时失败，系统也能明确告诉用户“尚未提交”还是“提交后状态未知”，而不是用模糊的成功提示掩盖不确定性。
隐私与身份：最难的不是字段名
协议中的 CandidateContext 将 consent_scope 设为核心信息，而姓名、邮箱、简历 URL 等个人数据不是一律必填字段。这体现了一个合理的方向：先说明用户允许什么，再按最小必要原则传递资料。项目还把“Agent 身份”“用户授权”“候选人身份核验”区分为不同问题，避免把“某个模型能调用接口”误写成“它有权代表某个人申请”。
仓库中的 Agent 身份 RFC 提出采用 RFC 9421 HTTP Message Signatures，并结合签名时间、过期时间和 nonce 防重放。这是值得关注的安全路线，但它仍是 Draft RFC，而非 OJCP v0.1 已强制落地的要求。部署者应把它视作待验证的设计提案，不能在合规说明中宣称协议已经自动解决授权、歧视、垃圾申请或数据留存问题。
WebMCP 提供渐进式接入，而不是浏览器万能钥匙
OJCP README 还展示了 WebMCP 方向：招聘页面可以通过 document.modelContext.registerTool() 暴露 search_jobs，或以带工具语义的 HTML 表单描述申请参数。其好处是已有招聘站不必立刻重写为全新的 API 平台，也能逐步让浏览器 Agent 理解一部分可调用能力。
但页面声明、浏览器支持和服务端授权是三层不同的事。实现团队应单独核验目标浏览器的 WebMCP 状态，不能因为 README 出现示例就假定所有用户环境可用；更不能把前端工具注册当作后端提交权限。真正的提交接口仍需处理会话绑定、CSRF、防重放、速率限制和人工确认。
把失败状态也建模，避免“已投递”的假阳性
这类协议最容易被忽略的部分，是失败与中断后的状态表达。浏览器自动化里，一个表单点击后跳转到外部 ATS，可能意味着申请已创建、还在补充信息、被验证码拦截，或者网络请求根本没有抵达服务端；仅靠页面是否跳转无法给出可靠结论。OJCP 将申请初始化、提交和状态查询分为独立工具，恰好为实现方留下了显式返回状态的接口边界。
实际接入时，建议在本地工作流中为每次申请保存 provider、岗位标识、申请会话标识、用户确认时间及最后一次查询结果。提交调用超时后，不应自动再次发送同一份资料；应先调用状态查询，或提示用户进入提供方指定的恢复路径。对未声明 check_application_status 能力的平台，也要把最终结果标为“待确认”，而不是把 HTTP 请求发出当成成功。这个保守策略看似降低了自动化率，却避免重复投递、错误承诺和候选人资料被无意扩散。
一份有技术骨架、但尚未被市场验证的草案
OJCP 的可取之处，是没有把招聘自动化简化为“更会填表”。它将发现、领域数据、申请路径、授权、验证和状态回传拆为可审计接口，正好切中了跨站 Agent 工作流最容易失控的连接处。
同时也必须保持克制：项目当前是 Draft v0.1，公开 adopter 列表中只有 Recruitics 的 reference provider；治理文件提出的委员会与中立化安排仍在早期建设阶段。因此，今天最适合把 OJCP 当作一个值得跟踪和试验的协议草案，而不是已经被主流 ATS、招聘网站和 Agent 平台广泛采用的标准。
如果你在做招聘平台、求职助手或浏览器 Agent，实际的起点不是直接自动提交，而是先拿一个低风险的岗位搜索场景验证：发布 manifest、实现只读工具、检查 schema 与日志，再把用户确认和申请状态接进来。只有当能力声明、授权边界和失败回退都能被复查时，Agent 才有资格从“读职位页”走向“代表用户完成流程”。