Hiring Agent 简历评分器
把简历 PDF、GitHub 信号和岗位规则转成可解释评分。
数据流、模型提供方、GitHub 查询、缓存及 CSV 写入均有清楚说明；本地 Ollama 选项和可选 GitHub 令牌体现了一定的最小权限意识。扣分在于：简历属于敏感个人数据，但源码材料没有说明加密、访问控制、保留期限、删除、脱敏或云端传输的隐私保障；CLI 启动可视为总体授权，却没有针对 Gemini/GitHub 外发或持久化文件的逐项确认。依赖虽精确锁定版本，但没有漏洞扫描、供应链验证或更新策略。生成文件可定位，却没有正式回滚或清理流程。MIT 版权和外部讨论来源有署名，但发布者身份仍未知。
架构、结构化模式、角色权重和处理阶段前后一致，并明确承认 LLM 非确定性及提示注入式 PDF 隐形文本问题，因此没有把这些已知弱点误作稳定保证。Ollama 与 Gemini 提供替代后端，且先决条件和模型获取步骤较清楚；但依赖外部模型服务、GitHub API 和指定模型可用性，缺少降级策略。材料没有展示异常分类、可操作错误消息或故障恢复说明，因此 failure_messages 计零。
支持本地或托管模型、不同硬件规模模型以及可扩展角色目录，适合简历评分和角色化量表场景。README 对“不是 ATS、不是客户产品、不是 HackerRank 职位筛选工具”的边界说明充分，故 capability_boundaries 满分。必填 --role 和显式 PDF 路径使触发较精确，但没有输入合法性、角色兼容性或危险配置防护的完整说明。提供 Python 版本、跨平台虚拟环境提示和环境变量配置，但未覆盖容器化、资源预算及企业部署要求。
README 的目录、架构、配置、执行流程和源码布局组织完整；安装步骤、前置条件及命令示例足够普通用户上手，因此信息架构和安装说明满分。角色及模块命名总体一致，但默认模型与示例模型存在多种名称，未给出稳定性或弃用承诺。示例丰富，却没有正式 FAQ 或系统化故障排查。已知的随机性、隐形文本攻击、GitHub 偏向及伦理争议披露充分。MIT 全文和版权声明完整。没有版本发布策略或 changelog。CONTRIBUTING 提供了贡献路径，但所给材料未包含其正文、维护者联系方式、支持期限或明确更新责任方；发布者未经注册表验证仅表示身份未知。
输出包含分类分数、证据、奖励、扣分、可读报告及 CSV，且角色配置驱动模式和列结构，静态设计上的可用性很强。相较人工处理大量简历，结构化提取、GitHub 丰富化和排序具有明确增量价值；但已披露的分数波动、可操纵性和 GitHub 中心偏差降低决策价值。提供无需云 API 密钥的本地路径，但没有模型硬件需求、运行时间、令牌/API 成本或人工复核成本的量化，因此成本效益只能薄弱计分。
评分规则、角色权重、提示模板位置、处理模块和证据字段均指向可检查的仓库构件，主张可追踪性较强。README 汇总了多个外部分析，并与其自身披露的随机性、安全和偏差问题相互呼应，但这些文章内容未作为独立文件提供，生产使用量和配置等陈述也缺少第二来源，故未满分。文档能区分项目用途、非用途、演示配置和外部批评；然而“公平”“客观”“可解释”等价值性主张没有静态证据充分验证，事实与推断分离仍不完整。
- 简历包含高敏感个人信息；在启用 Gemini、GitHub 丰富化、开发缓存或 CSV 导出前，应明确数据去向、合法依据、访问权限、保留期限和删除机制。
- README 明确记录同一简历多次评分会显著波动，且 PDF 隐形文本可能操纵结果；不得把单次分数作为自动淘汰或最终录用依据。
- 公开量表及 GitHub 中心指标可能不利于私有仓库贡献者，并可能诱导候选人针对规则优化材料；需要人工复核、偏差监测和申诉路径。
- 固定依赖版本不等同于供应链安全；部署前应进行漏洞扫描，并验证模型、GitHub API 和外部提供方的当前可用性与条款。
这个 Agent 能做什么，适合哪些场景？
Hiring Agent 是一个自托管的 Python 命令行项目，用于按岗位规则解析、补充并评估简历，而不是完整的 ATS。它通过 PyMuPDF 将 PDF 转成类 Markdown 文本，再由模型按照 Jinja 模板提取 Basics、Work、Education、Skills、Projects 和 Awards 等结构化数据。如果简历包含 GitHub 资料，github.py 会获取个人资料和仓库信号，并让模型筛选 7 个符合提交门槛的项目。evaluator.py 根据 roles/<role_name>/ 中的 role.json 与提示模板生成分类得分、证据、加分和扣分，score.py 负责端到端编排并在开发模式下缓存 JSON、追加 CSV。项目可使用本机 Ollama 或 Google Gemini，但仓库明确说明默认演示配置并非 HackerRank 的生产配置，最终招聘决策仍应由人工完成。
运行 python score.py <PDF> --role <role_name> 后，pymupdf_rag.py 与 pdf.PDFHandler 读取简历 PDF并生成类 Markdown 内容；prompts/templates/*.jinja 指导模型逐节提取数据，并组装 models.py 定义的 JSONResume。transform.py 将较宽松的模型 JSON 规范化为 JSON Resume 风格。若简历中存在 GitHub 用户名，github.py 获取个人资料与仓库、分类项目，并要求模型选出恰好 7 个满足最低作者提交量的不同项目。随后 evaluator.py 按指定岗位目录中的 role.json、criteria.jinja 和 system_message.jinja 计算分类分数、证据、奖励与扣分。score.py 在标准输出打印报告；当 DEVELOPMENT_MODE=True 时，还会写入缓存文件和 resume_evaluations_<role>.csv。
- 需要从数万份实习申请中确定人工阅读顺序的招聘团队，可用较低淘汰阈值先做排序，再由招聘人员复核。
- 希望审查自动评分依据的招聘或合规团队，可查看各分类的证据、加分、扣分以及岗位专属提示模板。
- 需要评估软件工程实习生的团队，可直接采用随附的
software_engineering_intern岗位规则，并结合开源、自主项目、生产经验和技术技能信号。 - 需要为后端工程师等新岗位制作评分规则的维护者，可用
--init-role生成岗位目录后编辑分类、权重和提示。 - 希望比较本地模型与托管模型结果的研究者，可在 Ollama 和 Gemini 之间切换，并在开发模式下利用缓存及 CSV 分析输出。
这个 Agent 有哪些优点和局限？
- 评分规则按岗位封装在独立目录中，分类、权重、总分限制、提示模板、控制台报告和 CSV 列均由岗位配置驱动。
- 支持本地 Ollama 和 Google Gemini 两条模型路径，可在不使用云端 API 密钥的情况下运行默认本地配置。
- 输出不只是总分，还包含分类分数、证据、奖励和扣分，便于人工检查评分依据。
- 把 PDF 提取、结构化解析、GitHub 补充、岗位评估、缓存和 CSV 导出组成了完整的命令行流水线。
- README 收录的分析显示，同一简历重复运行可能出现明显分数波动，项目将其归因于模型的非确定性。
- 文档指出 PDF 中的不可见文本可能显著抬高分数，采用前需要额外的输入清洗与安全防护。
- 随附规则重视 GitHub 信号，可能不利于主要贡献位于私有企业仓库的工程师。
- 项目不是 ATS，也不管理候选人流程；部署、审核、阈值管理及最终决策仍需组织自行承担。
- GitHub 补充和 Gemini 模式依赖网络服务；Gemini 还需要 API 密钥，而本地 Ollama 则需要自行运行模型服务。
如何安装或部署这个 Agent？
前置条件是 Python 3.11+，并选择 Ollama 或 Google Gemini 作为模型后端。
git clone https://github.com/interviewstreet/hiring-agent
cd hiring-agent
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env使用 Ollama 时，先安装 Ollama，然后运行 ollama serve 并拉取已列入 providers.json 的模型，例如：
ollama pull gemma4:latest随后在 .env 中设置相应的 DEFAULT_MODEL。使用 Gemini 时，将 DEFAULT_MODEL 设置为 providers.json 中列出的 Gemini 模型，并提供 GEMINI_API_KEY。GITHUB_TOKEN 可选，用于提高 GitHub API 速率限制。
如何使用这个 Agent？
为随附的软件工程实习岗位评分：
python score.py ./resume/sample.pdf --role software_engineering_intern--role 必填，其值必须对应 roles/ 下的目录。若要创建新岗位框架：
python score.py --init-role backend_engineer然后编辑 roles/backend_engineer/role.json、criteria.jinja 和 system_message.jinja，再运行：
python score.py ./resume/sample.pdf --role backend_engineer--init-role 只生成占位文件，不会评分。config.py 中的 DEVELOPMENT_MODE=True 会启用中间 JSON 缓存和按岗位生成的 CSV；若简历包含 GitHub 资料，流程还会请求 GitHub 数据。
这个 Agent 与同类方案有什么区别？
与完整 ATS 相比，它不负责候选人跟踪或端到端招聘管理，只负责简历排序和评分。与 HackerRank AI Interviewer（Chakra）相比，Hiring Agent 根据简历及 GitHub 信号生成初步评价，而 Chakra 用于自动化第一轮面试。模型后端方面，Ollama 可在本机运行且无需云端 API 密钥；Gemini 需要密钥和网络服务，仓库同时说明实际内部评估使用的是高阶 Gemini 模型，而公开仓库提供的是演示配置。
常见问题
它会自动决定录用或拒绝候选人吗？
能否完全在本地运行？
gemma4:latest 不要求云端 API 密钥。不过，如果流程需要获取 GitHub 个人资料和仓库信号，仍会使用网络。是否必须提供 GitHub Token？
GITHUB_TOKEN 是可选项，但可提高 GitHub API 的速率限制。只有简历中发现 GitHub 资料时，才会执行对应的仓库补充步骤。评分是否稳定且能防止简历操纵？
公开配置与 HackerRank 的实际配置相同吗？
gemma4:latest 演示配置；文档说明实际实习生简历评估使用高阶 Gemini 模型，生产配置并未随仓库提供。