把求职流程交给 AI 编程 Agent 前，先把状态、审批与数据边界搭好：Job Seeker 的本地工作流拆解
让 Claude Code、Codex 或其他编程 Agent 替人检索职位、填写表单，乍看只是“多接一个浏览器自动化脚本”。实际难点却不在点击按钮，而在于把高度个人化、会持续变化的求职过程做成可暂停、可复核、可追溯的工作流：职位来源、筛选条件、简历信息、沟通草稿、投递记录和面试节点，不能散落在聊天上下文里，更不能让 Agent 在信息不完整时自行补全。
Job Seeker 是一个 MIT 许可的 JavaScript 项目，它把这类流程组织为供编程 Agent 读取的 Markdown skills、浏览器包装脚本和 PostgreSQL 数据层。项目目前强调可与 Devin、Claude、Cursor、OpenCode 等 Agent 配合；这里更值得借鉴的不是“自动投递”本身，而是它如何把自动化拆成不同阶段，并把人工登录、信息确认与最终判断留在流程边界上。
自动化的对象不是“投递按钮”，而是一条有状态的管道
求职的输入与输出远比一次 HTTP 请求复杂。候选人的偏好会影响筛选，已投递职位会影响后续去重，招聘方来信又会反过来改变优先级。若只让 Agent 每次从自然语言对话中临时理解状态，常见结果是重复申请、遗失对话上下文，或把未经确认的资料填进表单。
Job Seeker 的做法是用 Postgres 保存档案、偏好、申请、消息与面试等状态，并把浏览器会话放入专用 profile。README 将流程明确拆成 onboarding、profile、strategy、radar、targets、news、apply、referrals、daily、memory、dashboard 等单元：例如 profile 用于建立职业档案和偏好；strategy 负责设定搜索积极程度；apply 才进入搜索、过滤、Easy Apply 与登记记录；daily 则按既定顺序执行例行检查。
这种分层有一个重要工程含义：Agent 的一次执行可以失败或中断，但数据库中的管道状态仍然存在。下一次运行不必依赖模型“记得”上一轮说过什么，而是可以从已登记的职位、消息和阶段继续。对任何需要长时间运行的个人自动化任务——报销、线索跟进、客户支持或资料整理——这都是比“给 Agent 一个万能提示词”更可靠的起点。
先跑 onboarding，再让 Agent 读取技能说明
项目的 Quick Start 没有假设用户安装一个神秘的全局命令，而是从普通仓库初始化开始：克隆、安装依赖、提供数据库连接，然后在仓库内启动编程 Agent。README 给出的关键操作如下；其中数据库地址应只放在本地 .env，不要提交到 Git。
git clone https://github.com/galiprandi/job-seeker.git cd job-seeker npm install
随后让 Agent 阅读 AGENTS.md 与 .agents/skills/onboarding/SKILL.md 并执行 onboarding。这样做看似比直接说“帮我申请五个职位”多了一步，却把必要前置条件显式化：浏览器需要人工登录 LinkedIn 与 Gmail；数据库连接由使用者提供；个人资料由 onboarding 收集，而不是让模型从零散对话中猜测。
这里要特别注意，自动化并不绕开网站身份验证或平台规则。README 也要求使用者先审阅各求职平台的服务条款。更稳妥的实践是将验证码、二次验证、账户授权和最终提交保留为人工动作；Agent 可以准备筛选结果、草稿和结构化记录，但不应把“能操作浏览器”误认为“拥有替用户作决定的授权”。
把“能做什么”限制在技能和脚本的明确接口内
Job Seeker 的一个可复用设计是：把 Agent 需要遵守的操作步骤写成仓库中的 Markdown skills，而不是只藏在一段系统提示里。apply、news、daily、db 等技能各自描述输入、顺序与限制；脚本则承担具体执行，例如浏览器包装器、数据库 CLI、LinkedIn 检索、Easy Apply、Gmail 发送、管道看板等。
这给 Agent 增加了两层约束。
- 流程约束：先建档、再设策略、再检索和登记，减少未经确认就填写资料的机会。
- 数据约束：项目中的数据库工具默认只读；需要写入时必须显式传入
--write。这类“默认保守、写操作额外声明”的接口，比依赖模型自行保持谨慎更可审计。
例如，申请状态并非只有“已投”与“未投”。项目的终端看板会按阶段展示卡片，并支持查看关闭项目、漏斗统计、移动卡片和读取详情。README 所示的调用入口是：
node scripts/pipeline.js node scripts/dashboard.js --open
前者适合让 Agent 或终端使用者检查当前队列；后者启动本地仪表板，展示 KPI、漏斗、看板、目标公司与近期消息，并会定时刷新。关键是把“发起动作”与“检查工作台”分开：即使自动化运行正常，人仍应有一个不依赖聊天记录的地方检查到底投了什么、处于哪个阶段、哪些沟通只生成了草稿。
记忆应是可查询的偏好，不是无限增长的对话
许多 Agent 求职方案会把用户的薪资、地点、岗位偏好与写作风格塞进一段长 prompt。这种方式一旦上下文被截断、多人共用会话或策略改变，就难以定位旧规则从何而来。
Job Seeker 采用的是更朴素的办法：将偏好和历史置于数据库，memory 流程负责检测、保存并在其他流程开始时加载有效偏好。它还把平台目录和策略文档独立为 PLATFORMS.md、STRATEGIES.md，避免把“去哪找”与“怎样执行”硬编码进某一个脚本。
不过，持久化并不等于应当永久保存一切。实践中可以给敏感字段分级：简历与公开履历可进入工作数据库；密码、一次性验证码和高敏感身份资料不应由 Agent 写入普通日志；每次策略变化最好带时间戳和来源。对于“自动检测的偏好”，也应提供人工复核与撤销路径，否则一条偶然表达可能长期扭曲后续筛选。
一个适合落地的人工审阅闭环
如果要将这一模式迁移到自己的工作流，可采用下面的节奏，而非一上来就开放全自动投递：
- 初始化：完成数据库、浏览器 profile 与人工登录；确认
.env未进入版本控制。 - 只读试运行：先让 Agent 执行检索、归类和看板登记，不填写、不发送，检查筛选是否符合预期。
- 草稿审阅：将职位匹配理由、表单字段来源与招聘方回复都呈现为草稿；用户确认后才执行外部写操作。
- 每日收敛：用
daily或等价例程汇总新消息、待处理职位和失败原因，避免多个独立会话并行修改同一条申请记录。 - 异常回滚：对超时、页面结构变化、缺失字段和权限失效建立明确状态，不把失败伪装成成功；必要时回到看板人工处理。
这一闭环的价值在于，它承认浏览器自动化、招聘网站和 Agent 推理都可能出错。系统的目标不是让人永远不看流程，而是让人把注意力集中在不可替代的判断：是否申请、资料是否准确、沟通是否合适，以及是否愿意承担某次外部操作的后果。
适用边界
Job Seeker 更适合作为“个人求职运营台”的参考实现，而不是一个无监督投递机器人。它依赖 Node.js、浏览器自动化、Postgres，以及使用者自己的 LinkedIn、Gmail 与数据库账户；这意味着部署和维护成本真实存在。对职位数量不多、希望精细打磨每一份申请的人，手工流程可能更简单；对需要长期跟踪大量来源、反复整理消息与阶段状态的人，结构化技能加数据库管道才会体现优势。
更一般地说，Agent 自动化的成熟标志不是动作越多，而是每个动作都有清晰的状态、数据来源、权限边界和人工接管点。Job Seeker 用求职这个高风险、强个人化的场景说明了这一点：让 Agent 做重复劳动可以节省时间，但让系统能解释“为什么这么做、数据从哪里来、下一步谁来确认”，才是能够长期使用的基础。