Resume-Matcher Agentic E2E Monitor用 AI Agent 驱动真实应用、沉淀证据包并判定质量的端到端监控方案【免费下载链接】Resume-MatcherThe #1 AI Harness for Building Resumes, PDFs, Cover Letters more, locally with 100 LLMs support.项目地址: https://gitcode.com/GitHub_Trending/re/Resume-Matcher本篇技术指南围绕 Resume-Matcher 仓库中的 agentic 端到端监控组件apps/backend/e2e_monitor/展开它回答的是传统测试结构上无法回答的问题——正在运行的系统是否真的产出了好的简历。读完本文你将掌握该组件的设计动机、安装启用方式、sweep 捕获流程、基线对比与刷新机制、Claude Code 判定技能monitor-e2e的接入方式以及它作为开源仓库如何做到对随机克隆者零影响的 OSS 安全模型。一、为什么需要 Agentic E2E Monitor确定性测试的三个盲区Resume-Matcher 的常规确定性测试后端/前端测试套件与 pre-push 门禁只能验证管道是否正确——schema 能校验、路由能返回、i18n 结构保持。但按照 设计规格 第 1 节的描述它们对以下三类运行期问题天生失明输出质量漂移一次提示词改动可能仍然通过所有结构化评分器却让定制简历变得更差相关性下降、更平淡、微妙地不真实。没有任何固定断言能捕获变差。流程/渲染损坏管道返回200 OK但 PDF 是空白的或某个阶段静默吞掉了错误。这是直播事故级别的高可见性故障。本地 Provider 的真实性用户反复抱怨Ollama 不工作而 Mock LLM 的测试套件看不到这一点——只有对真实 Provider 的真实调用才能暴露。因此该项目需要一个非确定性、agentic的验证层驱动真实应用端到端运行捕获持久化的证据痕迹再由 Claude Code 实例进行判定。它的定位是报告而非门禁——只提供信息绝不阻塞推送也永远不会接入 CI。设计与实现的完整记录分别见 设计规格 与 实现计划。二、双层架构确定性捕获 Harness Agentic Judge组件的核心设计决策是把流程拆成两层见设计规格第 2、3 节的决策表Harness捕获层确定性一个可独立运行的 Python 包通过uv run python -m e2e_monitor move调用。它负责启动真实服务、执行定制流程、运行结构化评分、生成证据包——每一步都是确定性的、可重复的。Judge判定层非确定性Claude Code 实例通过/monitor-e2eskill 或直接对话触发读取证据包 日志把真实问题与噪音区分开写出带证据引用的report.md。之所以分离是因为模糊的判定不能像 pre-push 钩子那样阻塞推送把可复现的捕获与非确定性的判定分开既保证了证据可信又让成本可控。架构图来自设计规格第 4 节如下YOU ──► /monitor-e2e (Claude Code skill the agent-in-the-loop) │ │ 1. runs the default sweep ┌─────────────────────────┐ ├──────────────────────────────────► HARNESS (moves) │ │ 4. re-invokes targeted moves │ boot · seed-master · │ │ to investigate │ tailor · render · │ │ │ collect · baseline-diff│ │ └────────────┬────────────┘ │ │ spawns drives over HTTP │ ┌────────────▼────────────┐ │ 2. reads bundle ◄────writes──────│ backend :8000 (uvicorn) │ │ 3. applies rubric baseline diff │ frontend :3000 (Next) │ │ 5. writes report.md │ (real configured LLM) │ ▼ └─────────────────────────┘ report.md session summary零应用改动的日志捕获技巧harness 自己拥有子进程——由它直接 spawn uvicorn 和 Next.js并把它们的 stdout/stderr 重定向到证据包内的日志文件从而在不给app/添加任何FileHandler的情况下获得持久日志痕迹见 servers.py。如果服务已经在运行harness 也可以选择挂接attach而非重新 spawn。三、安装可选 extra绝不默认安装e2e_monitor依赖被声明为可选 extra默认的uv sync或uv sync --extra dev都不会拉取它。安装命令README 原文cd apps/backend uv sync --extra dev --extra e2e-monitor # keep dev so test deps / the pre-push gate keep working这里有个关键细节必须与--extra dev一起同步。因为e2e-monitorextra 只包含 PDF 文本探测所需的依赖基于 pypdf 的非空白检查。如果只执行uv sync --extra e2e-monitor会把你现有的测试依赖移除导致 pre-push 门禁无法运行 pytest。未安装该 extra 时harness 依然可以运行只是非空白检查会退化为文件头 字节大小的启发式判断。该 extra不属于默认uv sync或--extra dev随机克隆仓库的人完全不受影响。在 pyproject.toml 中该可选依赖被放在[project.optional-dependencies]的e2e-monitor键下设计规格第 5 节明确要求任何超出既有后端依赖的东西都必须走这一通道。四、启用与运行RM_E2E_MONITOR1双锁门禁 sweep4.1 双重门禁Gate运行任何昂贵move 之前harness 都会先调用ensure_enabled()它要求两把锁同时打开见 gate.py环境变量RM_E2E_MONITOR1明确的启用意图已配置可用的 LLM key/Provider通过app.llm.get_llm_config()校验逻辑与 eval 的_needs_key()一致ollama与openai_compatible两种本地 Provider 视为已配置。任一条件缺失都会抛出MonitorDisabled并打印说明性消息什么都不会运行。唯一的例外是update-baselinerequire_keyFalse因为它不发起任何 LLM 调用。4.2 执行 sweepexport RM_E2E_MONITOR1 cd apps/backend uv run python -m e2e_monitor sweep一次 sweep 完整执行 8 个步骤README 原文预置一个隔离的DATA_DIR绝不会触碰你的真实 SQLite 数据库进程内启动后端让主简历master resume针对内置的 3–4 个 JD 进行定制tailor尝试 PDF 渲染若缺少node或前端则跳过/降级用结构化 eval 评分器给每个变体打分调用配置好的 LLM 作为判定者进行 rubric 打分把自包含的证据包写入artifacts/e2e-monitor/run-id/与baseline/baseline.json对比写出baseline-diff.json。从 __main__.py 的实现可以看到细节sweep 会先于服务启动前预置隔离数据库seed_master_db并通过ResumeData.model_validate(raw_master).model_dump()把夹具主简历规范化为与 app 存储完全一致的 round-trip 形态——否则 improve/preview 与 improve/confirm 之间的 hash 门禁会因字段差异返回 400。随后依次对每个 JD 执行tailor → judge → render将状态记录进flow-trace.json。进度叙述输出到 stderr而机器可解析的bundle: path行独占 stdout方便脚本与 Agent 解析。4.3 sweep 只捕获证据不产生结论sweep 只负责捕获证据包不负责判定。它是确定性的一半。真正的判定由回路中的 Agent完成——一个 Claude Code 实例通过下面的/monitor-e2eskill或者直接让任何 Claude Code 会话judge the latest e2e-monitor bundle读取证据包 日志区分真实问题与噪音写出report.md。sweep 的终端输出会逐步叙述每个动作并指向这个交接点。在实践中前门是/monitor-e2e一步同时完成 sweep 与判定裸 CLI 是 Agent 驱动的管道——适合快速捕获或作为后台/cron 运行供 AI Agent 之后取走调试而你照常开发应用。五、安装 Agent Skill从已提交的 Playbook 到 Gitignored 技能monitor-e2eClaude Code skill 运行时位于.claude/skills/monitor-e2e/SKILL.md——被 gitignore永远不会随仓库分发给其他克隆。它的已提交事实源source of truth是本目录下的 AGENT_PLAYBOOK.md。每个克隆安装一次bash apps/backend/e2e_monitor/install_skill.shinstall_skill.sh 的实现非常直接定位仓库根目录mkdir -p .claude/skills/monitor-e2e然后把AGENT_PLAYBOOK.md复制为SKILL.md。安装后在 Claude Code 中调用monitor-e2eskill 即可得到判定报告它读取证据包判定三个运行期任务输出质量、流程/渲染完整性、Provider 真实性并把report.md写入证据包目录。5.1 Agent 的判定流程playbook 原文要点依据 AGENT_PLAYBOOK.mdAgent 的职责边界非常清晰——永远不修改 app 代码与测试永远不自己运行update-baseline输出只是建议性的。具体流程前置条件否则拒绝这会发起真实、计费的 LLM 调用并启动服务器仅在维护者明确要求时运行需要RM_E2E_MONITOR1 已配置 LLM key从apps/backend运行。先低成本定向先读summary.json和baseline-diff.json——关注 provider、变体数量、flow_all_passed、renders_non_blank、min_judge_score以及相对已提交基线的任何回归。判定三个任务每个论断都要引用工件A. 输出质量对每个variations/jd/读scores.json结构化底线——fabricated_employers必须为[]、personal_info_unchanged必须为 true以及sections_preserved/is_valid_resume/jd_keyword_coverage与judge.json1–5 rubric打开tailored.json对照job_description.txt判断是否针对该 JD 做了强且真实的定制。B. 流程 渲染完整性读flow-trace.json每个阶段是否通过与每个render.jsonnon_blank然后在logs/backend.log中 grepTraceback、ERROR、500、TimeoutError、wait_for与吞掉的异常。一个 200 响应可能掩盖损坏的 PDF——相信日志与非空白检查。C. Provider 真实性从manifest.json记录 providermodelgrep 日志中的本地 Provider 挣扎指纹JSON-mode 回退、截断 /_appears_truncated、内容质量重试、超时升级、重试耗尽、Ollama/api/show。调查异常对任何可疑点低 judge 分、空白渲染、日志错误先打开该变体的文件与日志深挖再下结论。写报告把report.md写进证据包目录附简短会话摘要结构为每个任务的判定结论、相对基线的回归附证据引用、复现说明与建议修复。5.2 JD 关键词策略ATS 定制 ≠ 造假playbook 与 judge.py 中维护者策略2026-06指出把 JD 中的关键词/技能纳入简历是预期的 ATS 定制而非造假容忍上限为JD_KEYWORD_TOLERANCE当前0.20即约 20% 的简历内容可以来自 JD 措辞。注意该容差只软化 LLM 判定者的定性真实性视角而flow.py中的硬性结构护栏no_fabricated_employers、personal_info_unchanged保持严格、不受影响。真正构成缺陷的仍是编造的雇主、伪造的职位头衔/日期、超出容差的职业整体转换。product-managerJD 是真实性压力测试允许少量 PM 风格措辞但定制绝不能制造出主简历从未有过的 PM 职业经历诚实的产物应是职业转型者框架。judge 的 rubric_RUBRIC要求 LLM 以严格但公平的技术招聘官身份从 RELEVANCE、TRUTHFULNESS、FORMATTING 三个维度打分输出纯 JSON{score: int 1-5, reasons: ...}。分数规范化_normalize_score会拒绝 bool、非有限数、垃圾字符串失败时一律收敛为None并用四舍五入int(x 0.5)而非银行家舍入。六、证据包Bundle布局Agent 读什么每次运行的证据包统一落在 gitignored 的artifacts/e2e-monitor/run-id/下设计规格第 7 节artifacts/e2e-monitor/run-id/ manifest.json summary.json baseline-diff.json flow-trace.json report.md ◄── written by the agent logs/{backend,frontend}.log master/{upload_response,processed_data}.json variations/jd-key/ job_description.txt keywords.json tailored.json scores.json judge.json resume.pdf render.jsonbundle.py 定义了目录结构与 JSON 读写辅助logs/、data/隔离 DB、master/、variations/jd-key/。collect.py 中的build_flow_trace汇总每个阶段的ok状态与耗时产出all_passedbuild_summary生成 Agent 最先读取的轻量定向对象provider、变体数量、flow_all_passed、失败的阶段列表、非空白渲染数、min_judge_score。manifest.py 记录的 manifest 包含 run-id、来自配置的 provider model、git SHA、时间戳、经过密钥擦洗的配置快照。七、基线对比与刷新floor tolerance 的双层回归检测7.1 基线结构已提交的 baseline/baseline.json 是接受的黄金标准包含三个部分{ variations: { backend-eng: { jd_keyword_coverage: 0.5, judge_score: 4, non_blank: true }, frontend-eng: { jd_keyword_coverage: 0.75, judge_score: 2, non_blank: true }, ml-eng: { jd_keyword_coverage: 0.625,judge_score: 2, non_blank: true }, product-manager:{ jd_keyword_coverage: 0.625,judge_score: 2, non_blank: true } }, floor: { min_judge_score: 2, min_keyword_coverage: 0.5 }, judge_tolerance: 1 }7.2 回归判定逻辑baseline.py 的diff_against_baseline实现了两层机制绝对底线floor硬性失败jd_keyword_coverage min_keyword_coverage、judge_score min_judge_score、non_blank false都立即记为回归基线有分而本次judge_score缺失如判定器报错比任何低分都糟同样标记。容差带judge_tolerance捕获漂移即使仍高于底线只要 judge 分比基线下降超过 1 分base_judge - judge tol就标记为judge_drop回归——这避免了模型抖动被误判为回归。此外还有missing_variation基线有而本次缺失等类别。值得注意的细节夹具集故意包含与主简历距离较远的 JDfrontend/ML/PM其真实定制合理得分为 2 左右——所以 judge 底线设成 2 而非 3以避免对诚实但偏弱的变体产生误报见 baseline.py 的注释。7.3 刷新基线维护者的审阅提交只有在你对某次 sweep 输出满意后才更新黄金基线cd apps/backend uv run python -m e2e_monitor update-baseline artifacts/e2e-monitor/run-id # review the diff, then: git add apps/backend/e2e_monitor/baseline/baseline.json git commit -m chore(e2e-monitor): update baseline after run-id这是刻意的、经过审阅的人工动作。Agent skill 永远不会运行update-baseline——刷新黄金基线永远是维护者的提交就像更新 snapshot 测试一样cmd_update_baseline会把指定 run 目录的变体结果汇总成新的 baseline 并写入文件然后提示review commit it。八、OSS 安全模型为什么随机克隆者零感知整个 harness 的设计目标是让克隆仓库并运行常规工作流完全不受影响。README 中的机制对照表如下MechanismEffectOptional extra (--extra e2e-monitor)不被uv sync或--extra dev拉取RM_E2E_MONITOR1opt-in每个入口点都检查门禁没有该环境变量时完全惰性No import side effects该包不被app/、tests/或任何其他模块导入Not in the pre-push hook.githooks/pre-push只运行pytest——无 e2e sweepGitignored skill.claude/skills/monitor-e2e/被 gitignoreplaybook 源已提交但可运行的 skill 仅存在于本地IsolatedDATA_DIRsweep 从不读写开发者的真实数据库设计规格第 10 节把三个泄漏向量逐一封闭依赖安装harness 专属依赖放在e2e-monitor可选 extra 后构造上封闭。误触发运行代码惰性无导入副作用uv run pytest永不触及它 行为 opt-inRM_E2E_MONITOR1与_needs_key()双条件。构造 门禁封闭——即使好心的陌生人 Agent 运行它也只得到默认禁用的 no-op。Agent 自动发现skill不作为项目 skill 提交否则每个克隆者的 Agent 都会看到而是 gitignore 在.claude/skills/monitor-e2e/已提交的AGENT_PLAYBOOK.md才是事实源。通过不发布来封闭。密钥安全捕获的日志与 manifest 在写入gitignored证据包之前会经过 scrub.py 的_scrub_secrets哲学处理——正则模式覆盖sk-风格 API key、JWT、32 位以上十六进制、GoogleAIzakey、Bearertoken配置快照则对api_key/api_keys/llm_api_key/authorization等键值一律替换为[REDACTED]而provider/model/api_base予以保留manifest 需要它们且它们不是秘密。报告而非门禁不在 pre-push 钩子里不在.github/workflows/里。九、反演戏Anti-theaterharness 自我校验设计规格第 11 节要求纯函数、无依赖的辅助逻辑——baseline-diff、非空白启发式、日志擦洗器、flow-trace 构建器——必须在常规测试套件中以无 key、离线的单元测试形式被覆盖确保 harness 逻辑受版本保护且确实会被触发。仓库中的对应测试包括test_e2e_monitor_baseline.py——baseline-diff必须能标记注入的回归test_e2e_monitor_render.py——非空白检查必须能判空白 PDF 为失败test_e2e_monitor_scrub.py——擦洗器必须擦除植入的密钥test_e2e_monitor_collect.py、test_e2e_monitor_judge.py、test_e2e_monitor_manifest.py 覆盖其余纯逻辑。有副作用的部件子进程 spawn / HTTP / LLM只在上门 sweep 中运行——所以uv run pytest依然永不启动服务器、不花一分钱 token。被测试的纯辅助函数不得依赖可选e2e-monitorextra深度pypdf文本探测在缺少 extra 时被 mock 或跳过。十、Moves 一览确定性命令库除了sweep与update-baseline设计规格第 6 节还规划了完整的 move 命令集每个 move 都是确定性的并追加写入证据包boot— spawn 后端 前端或 attach把日志重定向到证据包等待双方/health写manifest.jsonseed-master— 通过/resumes/upload上传规范主简历保存processed_data.json记录resume_idtailor --jd key—/jobs/upload→/resumes/improve/preview→/improve/confirm保存关键词与tailored.json运行 5 个结构化评分器产出scores.jsonrender --variation key—/resumes/{id}/pdf保存 PDF非空白检查大小 页数 可提取文本探测 计时产出render.jsonjudge --variation key— 复用 eval rubriccomplete_jsonrelevance/truthfulness/formatting → 1–5并把分数记录到证据包以支持基线对比collect— 冲刷日志最终化flow-trace.json写summary.jsonbaseline-diff— 对比本次分数 flow-trace 与baseline.json产出baseline-diff.jsonteardown— 停止 spawn 的服务。其中tailorflow.py的完整 HTTP 链路是/jobs/upload拿job_id→/resumes/improve/preview拿resume_previewimprovements→/resumes/improve/confirm拿tailored_resume_id随后score_tailoring复用 tests/evals/scorers.py 中已证明的 5 个确定性评分器sections_preserved、no_fabricated_employers、personal_info_unchanged、is_valid_resume、jd_keywords_present保证 harness 与 eval 套件对什么是一次好的定制定义一致。renderrender.py则通过httpx请求/resumes/{id}/pdf模板swiss-single、A4再对字节做非空白判定is_pdf%PDF-头 大小 ≥ 1000 字节 可选pypdf 页数与文本探测且None值不会否决一个真实 PDF。十一、适用边界与未来方向从实现计划与设计规格可以确认以下边界无 Provider 矩阵每次只针对配置中的单一 Provider 运行要对比 Ollama 与云端就改配置跑两次由回路中的 Agent 对比两个证据包。无运行历史存储已提交基线是参考点而非累积趋势日志未来可能增加gitignored分数/耗时趋势日志以检测缓慢漂移、自动的本地 vs 云端对比、以及定时本地运行。无浏览器自动化流程是 HTTP 驱动的PDF 来自既有/pdf端点。使用场景按需运行——打 release tag 前或修改提示词后运行/monitor-e2e无 cron。测试夹具为一份内容丰富的规范主简历个人信息、摘要、2–3 条工作经历、教育、项目、技能、自定义章节 3–4 个跨角色 JDbackend / frontend / ML / PM见 fixtures/master.json 与 fixtures/jds。总而言之这个组件把测试通过与产品真的好用之间的鸿沟用一条可复现的捕获管道 一个证据驱动的 Agent 判定者填补了它不做门禁只做如实报告并在开源仓库的安全边界内把真实 LLM 调用、真实服务启动与真实证据留痕全部收进维护者的按需控制之下。【免费下载链接】Resume-MatcherThe #1 AI Harness for Building Resumes, PDFs, Cover Letters more, locally with 100 LLMs support.项目地址: https://gitcode.com/GitHub_Trending/re/Resume-Matcher创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考