想解决的问题
上一个项目（Gym-Agent）里我踩到的最大坑是：Agent 的行为只能靠手点去试，改一版提示词完全不知道是变好还是变坏。 所以 Job-Agent 我从一开始就不是「做一个会聊天的求职助手」，而是想把 简历准备 → 岗位发现 → 匹配分析 → 投递跟进 → HR 沟通 → 模拟面试 → 复盘提升 → 行动确认 这条完整链路跑通，并且让每一层都可观测、可评测。
用户端：一条真实的求职流程
- 简历上传后走解析与评分：文件用 Apache Tika / POI / PDFBox 抽取，MinIO 存原文件，预览和「设为默认简历」都有；
- 岗位列表、详情、收藏、推荐、搜索，简历与岗位做匹配分析，输出匹配分、优势、风险点和优化建议；
- 投递记录带状态流转和跟进提醒，HR 沟通记录支持回复识别与跟进动作；
- Agent Inbox 把跟进、面试、日报、提醒这些模块产生的待处理事项汇到一个地方；
- 行动确认中心：AI 生成的可执行建议先进这里，由用户点确认才执行。 这条规则和上一个项目一样——模型可以提议，但不可以替用户做决定。
AI 模拟面试：链路最长的一条
选岗位和简历创建面试 → 从题库/RAG 知识库抽题（去重、难度配比、知识点关联、用户错题优先）→ 用户开摄像头和麦克风用语音作答 → 接火山引擎/豆包 ASR 转文本 → 大模型拿参考答案 + RAG 知识 + 用户回答做相似度判断与评分 → 生成总体评分、逐题复盘、 薄弱知识点、优化建议和学习计划 → 错题自动沉入错题本，并反过来影响下一轮抽题策略。
这条链路上最难的不是模型调用，是失败怎么收场：ASR 挂了、复盘 JSON 解析不出来、 总结生成超时，每一种都有标准错误码和兜底路径，不会让面试卡在中间状态。
Agent 的分层工程化
这是我认为这个项目里最值得写的部分：
| 层 | 做什么 |
|---|---|
| Planner | 把用户目标拆成计划、步骤、工具选择和完成条件 |
| Executor | 按计划执行工具调用，记录步骤状态与输入输出 |
| Tool Schema | 统一工具的名称、入参、出参、错误码、权限、副作用、是否需要用户确认 |
| Guardrails | Prompt 注入、工具越权、敏感操作拦截、PII 脱敏、JSON 输出校验 |
| Long-term Memory | 沉淀偏好、简历摘要、面试反馈、历史决策；带冲突检测与版本历史 |
| Model Gateway | 模型配置、API Key、路由、超时、重试、熔断、成本统计统一收口 |
| Prompt 管理 | 模板、版本、场景编码、灰度，业务方在页面上就能改 |
| Trace | 主链路 + 工具链路 + 模型调用，耗时、token、费用、失败原因 |
| Eval | 评测用例与批量回归，看工具选择准确率、参数准确率、RAG 命中率、JSON 与回答质量 |
RAG 侧做了文档与 chunk 两级入库、增量索引、删除同步、权限过滤、引用展示， 以及混合检索 + 重排序的第一版；召回质量本身也可以评测—— 知识库最容易出现的问题不是「没实现」，而是「看着能用，其实什么都没命中」。
工作流与连接器
不适合在请求线程里同步做的事交给异步工作流：任务创建、状态机流转、失败重试与恢复、进度记录、定时调度，
比如面试准备任务创建后给用户发提醒邮件；Admin 端能看到任务列表、失败原因和处理状态。
外部连接器（招聘平台、邮箱、日历、通知渠道、简历导出）单独放在 Job-Agent-Mcp-Tools 里，
目前是预留接口，还没有真实对接。
哪里还不够
- 连接器的真实对接没做完，「自动同步岗位」还只是设计；
- Eval 用例覆盖的是核心链路，长尾场景没有；
- 项目进入现在这个阶段，我更该做的是少加功能、多提质量，把回归跑稳。
技术栈
后端 Java 17 / Spring Boot 3.5.x / MyBatis-Plus / MySQL / Redis / Sa-Token / MinIO / LangChain4j / SpringDoc，前端 Vue 3 + TypeScript + Vite + Pinia + Element Plus（地图用高德 JS API）， 模型侧统一走 OpenAI 兼容接口，语音用火山引擎 ASR。