别再用 Playwright 模拟投递了，AI 招聘 Agent 需要一套标准协议

现在很多开发者在做 AI 自动投递 Agent 时，习惯性地选择 Playwright 或 Browser Use 这种自动化工具去硬扛 ATS（申请人追踪系统）的表单。这种方案本质上是在做“暴力模拟”，虽然能跑通，但极其不稳定。只要对方网站稍微改动一下 DOM 结构，或者触发了 Cloudflare 的反爬验证，整个投递链路就直接崩掉。最糟糕的是，这种方式让雇主面对海量不匹配的 AI 垃圾申请，而求职者却在石沉大海中焦虑，形成了一个低效的死循环。

我认为问题的核心不在于大模型是否能精准识别输入框，而在于“授权”与“信任”的缺失。一个 Agent 如果只是完美模拟人类填表，它在雇主眼中依然是一个高级的“冒充者”，无法证明投递行为经过了候选人的真实授权，也无法验证调用者的身份合法性。

要打破这个僵局，必须把投递行为从“模拟点击”转向“标准化 API 调用”。这里我想深挖一下 OJCP（Open Job Communication Protocol）试图解决这个问题的逻辑。它并不是要推翻现有的 schema.org 结构，而是在其基础上做了一层关键的扩展。

OJCP 的核心设计是在域名的 /.well-known/ojcp.json 路径下建立一个公开清单。这意味着 Agent 不再需要通过解析 HTML 页面去猜测哪里是“申请”按钮，哪里是“上传附件”区域，而是直接通过该路径获取服务提供商的端点信息。例如，一个典型的配置文件会包含 provider 名称、endpoint 接口地址以及 schema_version: "1.0" 等关键元数据。这种机制让 Agent 能够像处理 DNS 记录一样快速定位服务，彻底摆脱了对网页前端结构的依赖。

在信任机制的实现上，OJCP 借鉴了 CloudFlare 和 OpenAI 的方案，引入了签名请求和 JWKS（JSON Web Key Set）校验。这解决了两个痛点：首先是身份验证，Agent 必须通过签名请求证明其合法性；其次是隐私控制，通过信任分级机制，系统可以根据校验结果决定传输多少 PII（个人可识别信息）。如果信任等级不足，Agent 只能获取基础岗位信息，而无法触达候选人的敏感隐私数据。

此外，在成本控制上，它采取了“浏览免费，交互付费”的策略。Agent 在搜索和浏览阶段不产生校验成本，只有在真正发起投递交互并需要验证身份时，才会触发校验流程。这种设计极大地降低了 Agent 规模化运行时的开销。

如果你想验证这套逻辑的实际运行效果，建议直接尝试他们的 MCP（Model Context Protocol）终端。将投递过程标准化为 API 调用，而非在不稳定的 DOM 树中寻找输入框，才是 AI Agent 能够真正规模化落地的正确方向。