历历在练：团队展示+选题报告+需求分析

团队项目第一次作业

作业所属课程	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS
作业要求	https://edu.cnblogs.com/campus/gdgy/Class56-Grade2024-CS/homework/16766
作业目标	构建一个能说会做的智能体
团队名称	嘿嘿嘿
团队成员	温美如-3224004081、陈婉怡-3224004078、兰羽-3224004079

目录

• 1 团队展示
• 2 选题报告
• 3 技术设计
• 4 需求分析

一、团队展示

1.1 团队名称与项目名称

团队名称：嘿嘿嘿

项目名称：历历在练——面向大学生的简历修改智能体

(https://github.com/w7885/resume-rehearsal-agent)

前端界面：https://resume-rehearsal-agent.vercel.app/

1.2 团队成员与分工

姓名	学号	特点	兴趣	技术与实践方向	希望承担的角色	项目分工
温美如	3224004081	爱玩，关注项目整体推进，细节实现	羽毛球，骑行，爱看点烧心小漫剧	AI 全栈应用开发	FDE	前后端工作台与业务链路开发，负责数据保存、建议确认及事实和版本保护等功能，开发联网搜索，项目优化，负责部署上线
陈婉怡	3224004078	INTJ，细心负责，认真严谨	阅读，追剧，羽毛球	设计与 Agent 开发	Agent 应用开发	负责 Agent 意图识别与任务路由，持续优化对话追问、生成质量、事实保护和岗位适配
兰羽	3224004079	幽默，项目中响应迅速，尽职尽责	画画，运动，追星	测试开发与反馈	测试开发	负责项目测评与测试，设计测试方案、验证关键流程和边界场景，复现并记录问题，跟进复测与反馈优化建议

1.3 团队合照

1.4 项目愿景

我们希望让每一位准备实习和毕业求职的大学生，都能从真实经历出发，看见自己的成长与价值。历历在练通过对话帮助用户回忆经历、理清个人贡献，并结合岗位需求改善表达，让简历修改更加清晰、有依据、可掌控，陪伴用户更自信地迈出职业发展的第一步。

二、选题报告

2.1 背景调查

随着大学生实习与就业准备逐渐提前，简历已成为展示个人能力和实践经历的重要途径。然而，根据项目组开展的大学生简历制作需求问卷调查，许多学生在简历制作过程中仍面临经历整理困难、个人贡献描述不清、岗位重点把握不准以及AI生成内容难以核实等问题。尤其对于参与过课程设计、学科竞赛和团队项目的学生而言，如何从已有经历中提炼真实的个人贡献，并将其转化为符合目标岗位要求的简历内容，是简历制作中的一大难点。

通过制作问卷大学生简历制作需求调查，我们从90多份的问卷中获取信息，总结出同学们在简历制作时遇到的实际问题，选择了最具代表性的问题“到目前为止，哪些步骤最费精力？”，该题共有41人做出了有效回答，最终截取了前五项最费精力的过程进行排序。


调查结果反映出，大学生简历制作的主要困难集中在经历整理、个人贡献提炼和岗位匹配，而不只是文字措辞与排版。因此，简历修改需要从真实经历出发，并结合目标岗位要求开展针对性优化。

2.2 选题描述

本项目设计了“历历在练”简历修改智能体，利用大语言模型的对话理解与内容生成能力，帮助用户梳理个人经历、完善简历表达，并通过建议依据展示与用户确认机制，最终提升简历修改的准确性和可控性。

其前端界面展示如下：

2.3 产品功能与目标用户

（1）功能架构思维导图

主要功能分为会话与恢复、材料与用途、对话与建议、当前稿与交付、安全与成本、联网与可选输入。

核心路径：提供简历与目标 → 识别信息缺口 → 追问个人经历 → 生成可核对建议 → 用户确认 → 更新当前稿。

（2）目标用户：准备实习、校招求职的在校大学生

1. 主要人群：需要制作、迭代优化简历的本科生，正在找实习、毕业校招的学生。这类学生往往拥有课程项目、学科竞赛、团队实践经历，但不擅长提炼个人贡献，不清楚如何结合岗位 JD 打磨简历表述。问卷调研显示该群体普遍存在经历整理困难、岗位重点把握不准、AI 生成内容难以核验的痛点。
2. 用户能力特征：会基础浏览器操作，可以自行核对简历个人事实；不需要掌握大模型、数据库等底层技术知识，使用中文界面完成简历对话优化。
3. 非主要目标人群：拥有多年职场工作经验的社会求职者，不在本项目重点覆盖范围内。
4. 用户责任边界：系统只提供改写建议，用户本人需要对简历经历的真实性负责，工具不做经历真实性认证，也不承诺提升求职录用结果。
5. 使用诉求：希望梳理零散的实践经历，获得有来源依据的简历修改建议，规避 AI 凭空编造经历的问题，产出贴合岗位的 Markdown 格式简历，降低简历打磨的精力消耗。

2.4 创新点

创新维度	创新点概括
交互方式创新	从传统的一次性简历润色，转变为围绕个人经历逐段追问、诊断和修改的连续对话
内容可信度创新	通过个人来源、原文快照和版本校验，限制 AI 无依据地添加个人经历
修改决策机制创新	AI 负责提出建议，用户负责确认，只有确认且校验成功后才更新正式简历

我们优化了agent链路，解决了文本分段错误、部分格式简历环节缺失等问题，新增了联网搜索、会话重命名等功能。

三、技术设计

3.1 前端

本项目采用 React + TypeScript + Vite 构建前端，主要负责用户交互、简历展示及 Agent 运行状态反馈。

（1）前端技术选型

• React： 用于构建页面组件，将会话列表、聊天区域和简历预览等模块拆分，便于维护。
• TypeScript： 为前后端交互的数据结构提供类型约束，减少字段不一致问题。
• Vite： 提供本地开发服务器和开发代理，便于前后端联调。

（2）页面功能划分

前端主界面主要分为以下几个区域：

• 左侧会话管理区： 支持会话的新建、打开、重命名和删除，并可恢复历史消息及修改进度。
• 中间对话交互区： 展示用户消息、Agent 回复及修改建议，支持材料提交、经历补充、追问回答和建议确认。
• 右侧当前简历区： 展示并编辑当前简历，支持预览、复制和 Markdown 下载，同时区分初始简历与修改后的当前稿。
• 材料与依据查看区： 展示上传材料、解析状态及修改建议对应的原文依据，便于核对内容真实性。
• 联网控制区： 提供岗位相关联网查询及候选信息确认入口，联网功能默认关闭，需经用户授权后启用。

（3）前后端通信与状态管理

前端通过 HTTP API 与后端交互，使用 JSON 传递会话、消息、材料及简历编辑等业务数据，并通过 SSE（服务器发送事件）接收 Agent 的运行状态和处理结果。

在消息处理过程中，前端先保存用户原始消息，再携带 requestId、userMessageId 和 expectedStateRevision 发起分析请求，以区分消息保存与 Agent 分析两个阶段。对于返回的事件，前端根据事件类型更新处理进度、追问及待确认建议；分析完成后读取后端已保存的数据，并校验请求归属及事件顺序，避免旧请求或迟到事件覆盖当前状态。

3.2 后端

本项目采用 Python + FastAPI + Uvicorn 构建后端，主要负责业务接口、Agent 调度、数据管理及业务逻辑处理。

（1）后端技术选型

• Python： 作为主要开发语言，便于整合大模型调用、文本处理及 Agent 工具。
• FastAPI： 用于构建 HTTP API，负责请求处理、参数校验及业务响应，并支持异步处理和 SSE 事件传输。
• Uvicorn： 作为 ASGI 服务器，负责运行 FastAPI 应用。

（2）后端模块划分

后端按照业务职责划分为以下模块：

• 接口层（api.py）： 负责接收前端请求并调用业务服务，普通请求返回 JSON，Agent 分析请求通过 SSE 传递运行事件。
• 业务服务层（business_service.py）： 负责处理会话、消息、材料、简历及建议决定等业务操作，并统一管理数据校验和事务。
• 数据访问层（repository.py）： 负责 SQLite 数据读写，以及数据关联、版本和来源校验。
• Agent 协调层（agent_host.py）： 负责启动和管理 Agent 运行，检查消息归属、会话状态及预算条件，并协调处理结果。
• 材料处理模块： 负责接收和解析简历、岗位描述及补充材料，保留原始材料及来源信息。
• 预算管理模块（agent_budget.py）： 负责模型调用费用的预算预留与实际结算，避免费用统计遗漏。

（3）请求处理与异常控制

后端将用户操作拆分为消息保存和 Agent 分析等阶段，并在启动分析前检查消息归属、简历版本、运行状态及预算条件。同时，通过请求去重、版本校验和数据库事务，避免重复操作、过期结果及并发修改造成的数据冲突。

对于模型调用、文件解析和数据库写入等异常，后端进行相应处理；即使 Agent 暂时不可用，用户仍可使用基础文字编辑、预览和 Markdown 导出功能。

3.3 Agent 链路

Agent 是本项目实现智能化简历修改的核心，通过大语言模型与工具调用相结合，将简历修改拆分为意图识别、上下文组织、事实提取、主动追问、建议生成和用户确认等环节，其链路流可展示为如图所示。

（1）路由与执行分离

采用外层 RouterAgent 与内层 run_loop 分离的设计：外层结合用户消息和会话状态判断任务意图，并通过 RouterOutput 校验结果；内层接收确定的动作和目标段落，负责具体任务执行；业务层则负责建议确认及正式数据写入。

（2）上下文与多轮记忆

每轮执行前，系统组装会话信息、目标岗位、当前经历、已确认事实、问题状态、来源材料及当前简历稿，使 Agent 能够关联用户的连续回答，减少重复追问。

（3）结构化工具调用

模型根据当前上下文输出结构化动作，包括 save_facts（保存事实）、ask_user（主动追问）、propose_change（生成修改建议）和 finish（结束处理）。输出经过 Pydantic 和 guard.check() 校验，确保动作、参数、目标及事实依据符合约定。

（4）事实约束与用户确认

修改建议需附带修改前后内容、理由及来源引用，并进入待确认状态。用户可以接受、拒绝或要求调整；只有用户明确接受且后端通过相关校验后，修改才会正式写入当前简历。

（5）分段处理与状态管理

Agent 默认检查项目经历、工作经历、技能和自我评价，并保存当前段落、待回答问题及待确认建议等状态，支持历史会话恢复和分段继续处理。

3.4 数据库

本项目采用 SQLite 作为本地业务数据库，负责保存会话、简历材料、对话记录、事实来源、修改建议及 Agent 运行状态等数据，由后端统一管理数据读写。

（1）核心数据组织

数据库主要保存以下几类数据：

• 会话与消息数据： 保存会话信息、用户消息及 Agent 回复，支持历史会话恢复。
• 简历与材料数据： 保存原始简历、当前稿、历史版本及用户上传的材料。
• 事实与来源数据： 保存用户补充并确认的事实、原始文本及来源引用，支持修改内容追溯。
• 建议与决定数据： 保存修改建议、修改前后内容及用户接受、拒绝或调整的结果。
• Agent 运行数据： 保存分析请求、运行状态及处理进度，支持任务恢复。
• 项目费用数据： 记录模型调用预算、费用预留及实际结算情况。

（2）数据关联与一致性控制

数据库通过 session_id 和 resume_id 等标识关联会话、简历及相关数据，确保不同会话之间相互隔离。同时，结合正文版本校验、请求去重和数据库事务，避免过期建议覆盖最新内容，以及重复操作或异常中断造成的数据不一致。

四、需求分析

需求说明文档

4.1 迭代记录表格

4.2 数据对象与类图

本图是领域类图，说明核心改稿对象、属性与关系，不要求源码中存在同名类，同时，补充联网对象关系图后，核心关系如下表。

业务对象	主要信息与作用
会话／消息	显示名称、求职目标、用户与助手原话、上下文和处理进度；限定材料与操作的归属
附件	原文件、文件类型、用途、解析状态和结果；上传不直接代表事实已确认
来源文本	从附件或用户原句形成的可定位内容及版本，供建议回查
正文块	简历的段落内容、顺序和版本，组成当前稿并保留历史
建议／用户决定	修改前后内容、目标、理由、来源，以及接受、拒绝或调整记录
联网设置／目标／外部参考	会话授权及版本、岗位身份、来源网址与正文版本；与个人事实来源分开保存
运行／费用记录	处理状态、取消与重放依据，以及调用预留和结算信息

4.3 验收标准

测试类别	代表性测试内容	预期结果
材料输入	上传不同格式的简历	正确提取或提示格式、解析问题
对话诊断	用户询问、补充、纠正经历	正确区分意图，不错误推进问题
修改确认	接受、拒绝、要求调整	只有有效接受才修改正式简历
事实保护	输入没有依据的数字和成果	不生成未经证实的个人经历
版本管理	修改正文后接受旧建议	拒绝过期建议写入
历史恢复	刷新页面、重启后端	恢复已经保存的内容
预算管理	预算不足或模型未配置	阻止不允许的调用
联网控制	关闭联网、更换岗位	旧岗位结果不能污染新任务
异常恢复	模拟请求超时、取消失败	不重复保存、不丢失已保存消息