招聘过程中的摩擦
一个岗位需要反复切换 JD、搜索引擎、LinkedIn、候选人页面和表格，最后还要手工整理成可以比较的结论。
- 英文 JD 与本地 HR 的阅读和判断之间存在转换成本
- 职位名称、Boolean Search、目标公司通常靠经验临时拼接
- 候选人页面信息不完整，抓到的内容也不一定能直接使用
个人作品 · Recruiting AI
把海外招聘里的重复搜索，变成一套可控的 AI 工作流
这是一个面向 HR 的本地招聘工作台：从一份岗位 JD 出发，自动整理搜索策略、研究目标公司、处理候选人资料，并把结果交给 HR 审核，而不是让模型直接替人做不可逆的决定。
定位：个人作品集 Demo · 本地部署 · 人机协作 · 不自动发送或骚扰候选人
FROM JOB DESCRIPTIONRUN STATUS · CONTROLLED
01岗位与 JD英文输入，目标市场语境保留
02策略 Agent职位词 · 条件 · 公司 · 搜索轮次
03候选人档案结构化履历 · 证据 · 评分理由
04HR 决策● 只读建议 · 人工确认后继续
5串行策略 Agent，各自有独立职责与 Schema
1本地招聘工作台，岗位、候选人与过程统一管理
0模型直接点击任意页面、自动 Connect 或自动发信
100%关键动作保留 HR 确认门与可追踪运行状态
实机演示
从岗位卡片到人才搜索，把过程留在 HR 看得见的地方
这段录屏展示海外招聘助手的实际界面：岗位信息、策略生成与人才搜索在同一个本地工作台中流转，HR 可以随时回看、调整和确认。
演示内容为本地测试环境。视频中的人才信息与界面状态仅用于说明工作流，不代表真实招聘决策或自动触达行为。
为什么做它
HR 真正缺的不是一个聊天框，而是一条能落地的工作流
海外人才搜索往往卡在信息分散、职位词不统一、候选人履历难以比较，以及 AI 结果无法解释和接续执行。这个项目把这些碎片连接起来。
这个作品的回答
让模型负责理解、整理和提出建议，让确定性代码负责边界、状态和执行，让 HR 把时间放在真正需要判断的地方。
- 策略先生成、可读、可修改，再进入浏览器执行
- 候选人资料整理成中文履历，并保留评分依据
- 推荐触达对象与邮件草稿都停在人工审核前，不越过确认门
AI 策略层
不是一个“大 Prompt”，而是五个可以被验证的角色
每个 Agent 都有明确输入、输出、失败状态和运行记录，严格串行读取上游结果。这样可以知道问题发生在哪一步，也可以只重跑受影响的节点。
RouterAgent
理解本次请求，标准化岗位信息，并判断最早需要重跑的节点。
负责路由，不替其他 Agent 做决定JobTitlesAgent
生成标准职位名、扩展职位词、职级变体和排除词。
保留目标市场的真实职位语言JDSplitAgent
拆解职责、Must-have、Preferred、Risk 与候选人分层。
不让模型输出任意数字权重TargetCompanyAgent
在受控的公开 HTTPS 范围内研究目标公司，输出匹配理由。
搜索失败时可安全回退到模型知识SearchPlanAgent
汇总前序结果，生成可编辑的 LinkedIn 搜索轮次与约束。
只生成计划，不直接操作浏览器从输入到结果
HR 看到的是结论，系统内部保留的是一条可恢复的过程
输入岗位名称与 JD
可以直接使用英文岗位描述，例如 International Business Development Sales Manager (Hong Kong)。系统不会强迫 HR 先把岗位翻译成另一套格式。
生成中文可读的搜索策略
系统把职位词、Boolean Search、目标公司、地区约束、Must-have 和 Risk 组织成一份只读策略。HR 可以通过自然语言修改，后端从最早受影响的 Agent 开始重跑。
用受控工具研究公开公司
TargetCompanyAgent 只能调用固定的公司搜索和公开页面读取工具，接受 HTTPS、GET/HEAD、超时与正文预算等约束。网页文字只是参考内容，不能改变 Agent 角色或审批策略。
扩展只执行固定动作白名单
浏览器扩展按计划执行搜索、筛选、收集、打开档案和导入等原子步骤。每一步都有租约、心跳、失败分类和恢复语义，模型不能临时生成 CSS selector 或 shell 命令。
候选人进入可比较的中文档案
LinkedIn 页面内容经过清理、去噪和结构化，整理为工作经历、教育、项目、技能、评分证据与触达建议。邮件最多生成草稿，发送仍需要 HR 的最终确认。
候选人档案
Business Development · APAC
82
履历摘要
将跨境业务合作、渠道拓展和项目落地经历归纳为可快速浏览的中文要点，同时保留原始职位与公司名称，方便 HR 对照原页面。
核心技能
证据提示
评分理由引用结构化履历片段，而不是只给一个无法追溯的总分。
Candidate Intelligence
把“抓到一堆网页文字”变成 HR 能读的履历
这个项目的重点不是把所有 DOM 原样搬进后台，而是把噪声清理掉，再用模型完成中文整理和结构化，让候选人的经历、项目和技能可以被整体浏览。
✓
工作经历与项目分开呈现避免页面导航、推荐模块和无关侧栏混入候选人档案。
✓
原文与中文理解并存岗位名、公司名、技能词保留市场语言，解释与过程信息使用中文。
✓
评分理由可回看Must-have 状态、Risk 标记和证据引用一起交给 HR 审核。
工程设计
我刻意把 AI 放在适合它的位置
模型擅长理解非结构化信息，确定性代码擅长做边界和状态机。两者分工清晰，系统才不会因为一次模型输出就失去可控性。
Local-first
FastAPI + SQLite + React 本地运行，业务数据和运行记录保存在当前电脑。模型只接收经过边界处理的必要信息。
PII boundary
邮箱、电话、凭据和原始网页内容不进入不必要的模型输入、SSE 或普通日志；邮箱来源和审批绑定可审计。
Deterministic gate
模型不能改变审批门、工具白名单、访问域名、评分硬门或浏览器动作。每次执行前后都有后端校验。
Recoverable run
每个 Agent 节点与浏览器步骤独立记录状态。失败只重试当前安全范围，旧计划失效时不会继续使用。
技术栈与实现
从接口、数据到浏览器扩展，完整走了一遍
FastAPI / Python策略编排、任务状态机、SSRF 校验、候选人导入和邮件审批 API。
React / TypeScript岗位、策略确认、候选人档案、评分和触达建议工作台。
SQLite / Alembic策略修订、Agent trace、浏览器计划、候选人和草稿的可恢复持久化。
Chrome MV3与主系统通过受控 mailbox 连接，只执行明确的浏览器动作白名单。
一个真实岗位输入示例
International business development sales manager (Hong Kong) → 中文策略理解 + 国际职位词保留 + 海外业务拓展相关 Boolean Search + 目标公司研究 + 候选人中文履历整理。
诚实的项目边界
这是一个可演示、可审计、持续迭代的个人作品，不是假装已经替代招聘团队
我更希望展示如何把 AI 变成可靠的工作流组件，而不是把所有能力都写成“自动完成”。
当前作品展示重点
- 岗位到搜索策略的多 Agent 串行生成
- 受控联网研究和失败回退
- LinkedIn 公开页面导入与 Recruiter 契约隔离
- 中文候选人履历、评分证据与 HR 审核工作台
明确不自动做的事
- 不自动 Connect、InMail、发帖或修改资料
- 不绕过 LinkedIn 登录、验证码或权限边界
- 不猜测邮箱，不调用第三方邮箱补全
- 不未经 HR 确认发送邮件或推进候选人阶段