skip to content
Liu Yang's Blog
Table of Contents

事先说明：这次实践是为了探索 Agent 的能力边界，也尝试让个人生活中的事务更 Agent-Native，让 Agent 能直接参与和协助处理。对于 Agent 编辑的简历内容和搜索到的岗位，我都会严格核查材料的真实性、岗位信息的真实性与有效性，认真对待每家公司和岗位的要求，并在确认后再投递。

最近投简历，我把不少重复工作交给了 Code Agent：看岗位、整理项目描述，以及在招聘网站上反复填写教育经历、实习、论文和奖项。

这套东西其实很简单：

  • 一个上下文仓库，存个人信息和简历文件；
  • 一个 playwright-cli，负责操作浏览器；
  • 再加一份 Skill，告诉 Agent 怎么用。

这套组合速度快的关键在于：填表这类多步操作可以写成一段代码一次执行完，不用每一步都等模型确认再往前走——后面会展开讲这是怎么做到的。

我自己用的是 Codex，但并不必须用 Codex。只要 Code Agent 能读取本地文件、执行终端命令，就能按这个思路工作，不需要它自带 Computer Use 能力，也不需要安装专门的浏览器控制插件。

先给 Agent 一个了解我的地方

所谓“上下文仓库”，就是把投简历要用的材料放进一个文件夹，让 Agent 开始工作时先读。目录可以很普通，比如：

recruiting/
├── 个人信息.md
├── 项目与实习经历.md
├── 网申填写素材.md
├── 简历/
│   └── 最新简历.pdf
└── 投递记录.md

个人信息里放学校、专业、时间等基础资料；项目和实习经历写得比简历详细一些；网申素材放自我介绍、项目描述等经常要复制的内容。

这样做，是因为一页 PDF 装不下网申需要的所有信息。有的网站只让写两百字，有的可以写很长。Agent 有了完整材料，就能根据字段要求调整表达，不用每次都问我“这段经历具体做了什么”。

我的要求也很直接：按材料填，缺什么就问，别编。 改过的内容更新到文件里，下次继续用。换一个 Agent，也可以把同一个目录交给它。

这些是私人资料，仓库留在本地就可以，不需要公开到 GitHub。

用 playwright-cli 给它接上浏览器

先介绍一下它的来历：Playwright 是微软开源的浏览器自动化工具，playwright-cli 同样是微软官方维护的项目。 Playwright 的主要定位是网页端到端测试，可以控制真实浏览器，完成点击、输入、跳转等操作，也能用来抓取需要 JavaScript 渲染或交互后才能获得的网页内容。比如爬虫框架 Crawlee 就提供了基于它的 PlaywrightCrawler。Playwright 官网、微软的 playwright-cli 仓库、Crawlee 文档

所以，这套方法用的是已有的浏览器自动化能力。以前由人写脚本规定每一步，现在让 Agent 根据任务和页面反馈决定下一步，再通过 CLI 执行。

从这个层面看，它和 Browser Use 的基本思路相通：读取页面 → 决定动作 → 操作浏览器 → 检查结果。在这套组合里，Code Agent 负责判断，Playwright 负责执行。这里的 Browser Use 泛指 Agent 使用浏览器的能力，不特指同名开源项目，也不意味着所有方案的底层实现都一样。

Code Agent 本来就擅长读文件、写代码、运行命令。playwright-cli 把浏览器操作也变成了命令：打开页面、读取内容、填输入框、点按钮，都可以从终端完成。

Skill 可以理解成给 Agent 看的使用说明。装好后，让它先读 Skill，再按说明操作，没必要由我手动教它每个命令。

准备好 Node.js 和浏览器后，安装大致就是：

Terminal window
npm install -g @playwright/cli@latest
playwright-cli install --skills=agents

第二条适用于使用 .agents/skills 目录的 Agent；其他宿主按它支持的位置放置 Skill，也可以直接让它读取 SKILL.md。具体选项见 安装说明，或运行 playwright-cli --help install。

接下来，我会让 Agent 打开一个专门投简历的浏览器。我自己登录，后面继续用同一个会话。比如把会话叫作 recruiting，以后每次操作都带上这个名字，就不容易搞混窗口。

实际使用时，我给的指令可以很简单：

先读这个目录里的个人资料和最新简历，用 playwright-cli 打开招聘网站，我来登录。然后帮我看看适合的岗位，按材料填写网申。复用 recruiting 会话，填完检查必填项和内容，最后投递前让我看一下。

换家公司时，材料还在，工具也还在，只需要换一个网站。

为什么我更喜欢 CLI，而不是依赖浏览器插件

Codex 本身的 Tool Use 质量并不差。但在我的使用中，Codex 的浏览器插件经常出问题，我会花时间处理工具连接，而不是推进投递。这也是我转向 playwright-cli 的一个很实际的原因。

往下查了一下原因：Codex CLI 连浏览器插件走的是原生消息桥（native messaging）——先靠一个 native host manifest 找到插件，再通过一个 browser-client 脚本建立连接，插件那边暴露出来的也是一组一次只能调一个的动作（打开页面、点击、输入、截图），形态上和 MCP Server 把工具暴露给客户端调用是一回事。GitHub 上一个还开着的 issue 提到，桌面版能正常连上插件，终端里跑的 CLI 却连不上，插件、manifest、Chrome 进程本身都没问题，缺的是 CLI 运行时里一段用来发现原生后端的权限元数据。看起来我踩到的连接问题不是个例，这条路径在 CLI 场景下本身还不太稳定。

对我来说，CLI 这条路用起来更快、更稳。这里说的是我的使用体验，尤其是少了折腾插件的时间。

另外一个原因是，CLI 很容易和代码组合起来。Agent 可以把读取资料、整理文本、填写、检查串成一段逻辑。例如填写一段项目经历：

读取项目材料
  → 按字数限制整理描述
  → 填入项目名称、时间和内容
  → 读取已填结果
  → 检查有没有遗漏或填错

几个互不影响的文本框，可以放在一小段代码里连续处理；遇到学校搜索、日期选择这类有联动的控件，就等选项出现，选好再继续。填完后，还可以把网页中的值读出来，和材料比较。playwright-cli 支持运行 Playwright 代码，所以不必把每个动作都拆成一次模型往返。

条件判断、循环、文本处理和结果检查，本来就是 Code Agent 擅长的事情。浏览器也能通过 CLI 操作以后，这些能力就能一起用上。

顺手的做法再写进 Skill，比如“先读哪份材料”“继续使用哪个会话”“学校下拉框要选中候选项”“保存后检查结果”。后面重复用，不必每次从头解释。

流程自己定，资料自己管

整套流程都可以按自己的习惯定制。 先筛岗位还是先整理简历、不同方向突出哪些经历、哪些步骤交给 Agent、哪些地方停下来让我检查，都可以写进 Skill。想把结果记到自己的投递记录里，也可以接上。用着不顺手，就修改规则或脚本，让流程逐渐适合自己。

资料也由自己管理。 简历、个人信息、素材和投递记录放在自己的目录里，哪些文件交给 Agent、什么时候更新或删除，都由自己决定。这样可以减少向额外的代投平台上传完整资料的需要，对数据去向也更有把握。

但本地存文件不等于数据全程不出电脑：使用云端模型时，Agent 读取的文件内容和网页信息仍可能发送给模型服务商。所以供应商是否可信，同样重要。

不要使用任何中转站！请使用模型供应商官方的 Coding Plan，并确保供应商足够可信。 这里处理的是自己的真实简历和个人信息。我会认真看服务商的数据使用、保留和隐私设置，不会为了便宜一点，把这些材料交给来源不明的转发服务。官方渠道能减少一层中间环节，但仍然需要自己判断供应商是否可信。

我自己还需要做什么

我主要负责登录、验证码、确认材料，以及决定最终投哪个岗位。Agent 负责搬运和整理信息、填写表单，再检查一遍。

如果你通过 iPhone 与 Mac 的短信联动、Google Messages 的设备配对，或者自己配置的 Hook、USB 调试等方式，让电脑也能收到手机短信，就能少一些在手机和电脑之间来回切换的操作，整个流程会方便不少。

当然，CLI 也会遇到难处理的控件。我填携程时，学校和专业需要从候选项里选择，只把文字输进去还不算完成；那次保存又遇到了手机验证，需要我接手。工具能帮忙操作，页面有没有真正保存成功，还是要看结果。

我觉得这套方法最方便的地方，是材料和流程都掌握在自己手里。个人信息存在文件里，操作方法写在 Skill 里，浏览器通过 CLI 控制。以后换 Code Agent，仍然可以沿用这一套。

如果你也在反复填网申，可以先整理一个自己的上下文仓库，再让 Agent 试着填一段经历。走通之后，剩下的就是逐步把重复劳动交给它。

最后还是一句话：认真对待别人的付出，也认真对待每一个可能成为自己未来工作的岗位。 用 Agent 是为了减少重复劳动，让自己有更多精力了解公司、阅读岗位要求、判断是否合适。每一次投递都应该经过认真考虑，而不是批量制造无效申请，给招聘方带来信息污染，甚至变成一种“DDoS”。