3小时：OpenClaw 打造 HR 简历筛选助手

1. 需求背景

老婆是 HR，给公司开发团队提了一个需求：自动按照岗位描述在招聘网站上收集候选人信息，整理成表格，分析岗位匹配度，定期发送，针对高匹配度候选人再下载完整简历，以提高筛选效率。希望先做一个 demo 看看可行性，问大致需要多久。

研发团队评估要 3 周。难点是做爬虫，需要适配不同招聘网站，还要绕开登录验证、设备限制等。这在传统软件开发时代确实是个合理的时间评估。

我觉得这个需求特别匹配 OpenClaw 作为个人智能助手的场景，刚好写完了《操控浏览器，让 OpenClaw 解锁超能力》，是个不错的练手项目。于是周末花了半天时间，亲自实践一把。

2. 方案设计

2.1. 方案思路

• 招聘平台：选择前程无忧，因为支持多设备登录（有数量限制），其他平台只能单设备登录，意味着需要多个账号才能实现需求。

• 账号登录：通过远程桌面在 OpenClaw 托管的 Brave 浏览器中登录招聘平台账号。

• 输入文件：input.csv 保存职位信息，包括：职位名称、职位描述、工作地、工作年限、资质证书等。

• 输出文件：output/ 目录保存简历筛选信息，每个岗位一个 csv 文件，包括：姓名、年龄、工作经历、项目经验、期望薪酬等。

• 业务逻辑：

  • OpenClaw 调用 OpenCode 完成开发任务

  • OpenCode 调用 Playwright 操作 OpenClaw 托管的 Brave 浏览器，访问登录后的招聘平台

  • 遍历 input.csv 中的职位信息，设置搜索条件获取简历，提取主要信息，输出到 output 目录下。

    因为安全性考量，OpenClaw 托管的浏览器与操作系统的浏览器是隔离工作区的。为了让 Playwright 与 OpenClaw 共用同一个浏览器工作区、复用招聘平台的登录状态，需要使用 CDP 模式，让 Playwright 连接到 OpenClaw 托管的浏览器实例上。

2.2. 开发过程

主要提示词如下：

# HR简历助手 - 开发需求
## 功能描述
开发一个自动化HR简历搜索工具，使用 Playwright 控制 Brave 浏览器访问 51job。

## 输入
- input.csv: 岗位名称、工作地、经验要求(年)、性别要求、教育经历、岗位描述
- 测试阶段编写2条测试数据

## 配置
- config.yaml: max_resumes（每次获取人才数量，默认10）

## 搜索逻辑
1. 读取 input.csv，获取岗位信息
2. 访问 https://ehire.51job.com/Revision/talent/search
3. 根据岗位信息设置搜索条件
4. 点击搜索按钮，等待结果加载

## 提取逻辑
- 每个岗位提取最多 max_resumes 份简历
- 进入简历详情，提取以下字段

## 输出
- output/岗位名称.csv（每个岗位单独一个CSV文件，GBK编码）
- 字段：姓名、年龄、性别、工作年限、技能或优势、期望工资、学历、工作经历、项目经验、教育经历、证书、原始链接

## 技术要求
- Python 3.11+、Playwright、Brave 浏览器(CDP: http://127.0.0.1:18800)
- 51job需要用户自行在Brave浏览器中登录

使用《OpenClaw折腾笔记四 – 编程实战：开发博客转公众号助手》提到的 tmux + Ralph + OpenCode 方式开发，Claude 4.6 Opus 模型，4 分钟就完成了初版开发任务。

但运行下来还有各种问题，主要是无法正确识别并设置招聘平台的搜索条件控件。最终，还是需要人工引导 AI 先通过 Playwright 访问招聘平台，调研搜索条件控件的页面元素、操作方式和可选内容，再编写脚本。

让 opencode 调用 brave 访问 ehire 网站，
看看搜索条件的页面元素、操作方式和可选内容，
然后根据真实页面元素修改脚本，并测试确认搜索条件正常。

前前后后花了 2 个多小时，最终完成了开发任务。

2.3. 测试运行

注意直接使用 OpenClaw 的 exec 命令调用工具有 180 秒超时限制，所以还需要使用 tmux 来执行脚本测试。

# 1. 进入项目目录
cd ~/workspace/hr-resume-assistant

# 2. 启动 OpenClaw Brave 浏览器
openclaw browser restart

# 3. 在 Brave 中登录 51job ehire
# 手动访问 https://ehire.51job.com 并登录

# 4. 使用 tmux 后台运行程序
tmux new-session -d -s hr_run "python3 -u main.py > /tmp/hr_output.log 2>&1"

# 5. 查看运行状态
tmux list-sessions | grep hr_run

# 6. 实时查看日志
tail -f /tmp/hr_output.log

# 7. 程序完成后，查看结果
ls -la output/

过程当然不是一帆风顺，有一些 bug 可以让 OpenClaw 操作 OpenCode 来修复，最终顺利完成了开发任务，输出了结果。

2.4. 遗留问题

在开发过程中，遇到最严重的问题就是 OpenClaw 无响应，其原因是多方面的：

• 前文提到 OpenClaw 的 exec 命令有 180 秒超时，调用工具过程中出现卡顿、超时都会引起无响应。
• OpenClaw 的 SubAgent 协同机制还不成熟，也导致了各种无响应、回复信息乱序等奇葩现象。
• 在之前文章中我也提过，使用 tmux + Ralph + OpenCode 方案，信息通知机制也有问题。

所以，我在开发过程中会多次出现以下让人恼火的情况：

2.4.1. Agent Client Protocol

Agent Client Protocol 简称 ACP，是一种旨在标准化代码编辑器（IDE）与 AI 编程助手（Agents）之间通信的开放协议，通过解耦工具与服务，实现不同 AI 智能体与各类开发环境之间的无缝互操作。

说简单点就是把 AI Coding Agent 当作 Tool，让其他工具如 IDE 去操作 AI Coding Agent，如 ClaudeCode、OpenCode、Codex 等。

OpenClaw 在 2026.02.26 版本上线了 ACP Agents，可以让 OpenClaw 更顺滑地操作 AI Coding Agent，并且专门优化了异步调度和状态同步。也就是说使用 ACP + OpenCode 可以替代 tmux + OpenCode 的旧模式。但目前没办法在 ACP 模式下使用 Ralph + OpenCode。

我也对比了这几种方案的适合场景：

ACP 的协同和通知机制更好，但 Ralph 的自动循环是其独特优势。如果 OpenClaw 能在 ACP 中加入原生 Ralph Loop 支持，或者 OpenCode 自身支持 Ralph Loop，将是最佳方案。

抱着美好的期待，我也尝试了 ACP + OpenCode 的方案，但实际效果也一般，因为 OpenClaw 无响应的问题是多方面的，还需要等待优化和成熟。

3. 延展与思考

项目做到这里，可以向老婆大人交差了，但其实还有很多可延展和优化的空间：

• 增加简历匹配度分析：运行完脚本后，让 OpenClaw 读取 input.csv 和 output 目录下的文件，用岗位描述去检查简历信息的匹配度，形成打分和简评。
• 增加定时发送文件任务：运行完脚本并分析完简历匹配度后，将最终的文件定时发送到邮箱或者 IM 工具中。
• 增加简历去重机制：目前的方案没有对简历进行去重，多次执行脚本可能获取重复的候选人，可以增加简历信息库进行比对和去重。
• 适配更多招聘平台：目前只支持前程无忧，依照这个方案，可以让 AI 完成更多招聘平台的适配，以便获取更多候选人信息。
• 增加后续流程任务：筛选完简历后，如果有合适的候选人，可以发送候选人信息给 OpenClaw，让他调用脚本下载详细简历，再发送给自己。甚至可以让 OpenClaw 直接给候选人发面试邀约邮件。

这样，OpenClaw 就可以向着 HR 智能助手的路上不断演进，这也是 AI Agent 未来主要的应用场景。

回顾整个项目，这个需求并不复杂，AI 时代没有来临前，我们依然可以依靠写爬虫脚本、写定时任务实现需求，甚至创建一个网站来让用户发布简历筛选任务。流程方面，分析、设计、编码、测试、部署、优化，这些 SDLC 的标准流程一个不少。但软件交付的效率，软件开发的模式，软件部署的形态，软件使用的方法都发生了变化。

最直接的体现是，我把需求的实现从 3个周 变成了 3个钟。

AI 时代，人人担心 AI 会替代人的工作，不可否认的是在简历筛选这个需求上它确实表现出了可替代性，但在这个项目的某一些环节中需要更专业的知识来设计方案、给 AI 更好的提示词、给 AI 排查问题的方向等等。目前看来，想把 AI Agent 使用的好，它对使用者的门槛似乎更高。