软件工程第二次小组作业

408-Agent：把刷题、复盘、分析、决策接成一条链

考研自习室里最常见的场景是：一个学生做完二十道数据结构题，错了七道，把错题截图存进相册。第二天想复盘，却记不清当时为什么错；想知道自己到底弱在哪，只能凭感觉；想查目标院校的复试线，又得在十几个网页之间来回切换。刷题、复盘、分析、查院校，每一件事都有工具，但没有一个工具把它们连起来。

408-Agent 想做的就是把这条断掉的链接上：练习产生作答记录，作答记录产生学情画像，画像产生补强建议，建议再回到下一轮练习。第一次作业我们回答的是"用户需要什么"，这一次要回答三个更具体的问题——用户怎样一步步完成任务，系统内部怎样协作，数据怎样保存才能在几个月后仍然说得清"当时为什么这么判"。

本文按这三问展开：原型（任务链怎么走）、概要设计（系统怎么分层、Agent 怎么被组织）、数据库（记录怎么留痕），最后是协作记录、验收证据和我们的复盘。

一、项目与本次作业

项目	内容
作业所属课程	2026秋软件工程与软件工程实践
作业要求	第二次团队作业（原型设计+概要设计）
作业目标	在第一次需求分析的基础上，完成可交互原型、系统分层架构、UML 与数据库设计；明确领域智能体与业务功能的协作方式，并通过 GitHub 留下可追踪的任务、评审和交付记录。
团队名称	408小组
团队成员	102401614-林志涛；102401512-任奥辉；102401509-吴瑞鹏；102401625-朱铮睿；102401635-尼玛顿珠；102401510-林富强；102401525-丁鑫河；102401526-林鹏远；102401511-何锦宏；102401519-曾林远见；102401623-杜佳伟；102401632-翁斌；102401633-严科儒
GitHub 仓库	fzu-404-team/kaoyan-agent-platform

408-Agent 面向计算机考研学生，把刷题、错题复盘、学情分析、院校查询和资料整理放进同一个工作台。学生既可以直接使用页面功能，也可以带着当前题目、学习记录或笔记向领域智能体提问。

整个设计围绕两条主线：

• 学练闭环：选择练习 → 提交作答 → 查看判分 → 错题复盘 → 学情分析 → 确认补强练习。
• 备考决策与整理：完善报考条件 → 查询院校或获取推荐 → 查看依据 → 整理资料与个人笔记。

本文依据团队仓库 docs/coursework-02/ 中的原型、系统设计与数据库设计资料编写，协作与交付信息更新至 2026 年 11 月 7 日。主要设计内容沿用团队统一业务设计基线 94b8a9f，后续开发安排为团队拟定计划。

二、原型设计

2.1 先定任务链，再排页面

原型用墨刀组织和分享，项目名 408agent，演示画布为 T01_T02_交互原型。这一轮没有重画页面，而是把已有页面按"用户要做完一件事"重新串起来：补导航、补业务规则、补任务状态，再把 HTML 交互组件导入墨刀的 1280 × 800 画板，形成一个统一的可点击入口。

点击打开墨刀原型

进入后可以从目录选择体验路径。页面顶部的"验收版 v2 · 模拟数据"用于区分演示环境：原型里的账号、学习记录和 Agent 输出都是模拟数据，刷新后恢复初始状态。

原型共 20 个独立 HTML 入口，按任务归为六组。其中若干入口表示同一业务的不同状态——答题前后、诊断中与批次结束后，所以入口数比"页面种类"多。

• 账号与首页：登录、注册、首页、个人中心，用来进入系统、维护备考档案与报考条件。
• 练习与复盘：练习首页、答题、判分、错题本、收藏，按条件练习并从错题继续复盘。
• 诊断与学情：单选诊断、批次结果、学习统计，完成诊断并查看薄弱知识点。
• 智能助手：带上下文对话、建议操作、来源展示。
• 院校与资料：院校列表、院校详情、备考资料、个人笔记。
• 管理后台：题目录入与审核、资料审核。

图1　原型总览与任务路径

2.2 Agent 在原型里不是一个对话框

这是本次原型最想讲清楚的一点。领域智能体如果只做成右下角的聊天窗，用户看到的永远是"我问它答"，看不到它凭什么这样答。所以原型把 Agent 的工作过程放进了页面结构：进入助手时自动带上当前题目或当前笔记，回复里同时给出建议操作和来源，用户确认之后才真正写入业务数据。

下面三条路径，分别对应"带上什么上下文""建议怎么落地""结果怎么留痕"。

从错题进入上下文辅导。 学生提交答案后，页面展示判分、标准答案和解析。答错的题可以从错题本进入"带上下文辅导"，继续问"我的选项错在哪里"。助手拿到题目与这次作答的背景，围绕本题解释思路，用户不必再复制题干、也不必描述自己做错的过程。

这条路径把"答错了"接到"理解为什么错"。职责上也做了切分：练习判分由业务服务完成，结果确定且可复核；智能体只负责解释和辅导；诊断模式则等批次结束后统一展示结果，避免提前揭示答案影响诊断本身。

图2　错题上下文与智能体辅导

从学情分析进入补强练习。 学生在学习统计页看到知识点表现后，可以请求助手分析薄弱环节。助手把分析结果和可执行的补强建议一起展示，学生确认后再创建练习批次。

这里的顺序是刻意的：学习记录提供分析依据，智能体把依据转成学习建议，业务系统负责创建和管理练习。学生可以从建议直接进入下一轮练习，形成"记录—分析—练习—再记录"的闭环，而不是看完一段分析就结束。

图3　学情分析与薄弱知识点

笔记建议先预览，再保存为新版本。 学生先选定一篇已保存的笔记，再请求助手整理内容或提出修改建议。原型展示建议预览，由用户决定是否接受；确认后保存为同一篇笔记的新版本，并可查看历史版本。

我们为这条流程专门设计了未保存离开提示和版本冲突反馈，目的是让"当前正文""助手建议""已保存版本"三者始终分得清。对笔记类功能来说，"AI 改了我的东西但我说不清哪版是哪版"是最容易失去信任的地方。

图4　笔记建议预览与确认

后台的录入、预览与审核。 后台原型覆盖题目录入、批量数据预览、整批送审和审核处理。录入时展示必要字段与来源规则，批量操作先呈现预览；审核人员可以通过或退回，并填写意见。资料审核同样设置了确认与取消两条路径。

图5　后台题目批量送审

2.3 状态与视觉规范

界面采用蓝白配色、固定侧栏与卡片布局，筛选、按钮、表格和状态标签保持一致。答题、生成中、停止、重试、空数据、未保存和审核这些状态都有明确的文字反馈，关键页面还提供"页面规则"说明。

2.4 原型验收

根据仓库中 2026 年 11 月 5 日的原型验收记录：本地完整交互检查 27/27 通过，原有交互回归 13/13 通过，墨刀实际分享页面的匿名访问与关键路径检查 7/7 通过。该记录写清了检查对象与复现方式，可在原型验收报告查看。

需要说明的是，这组数字衡量的是"交互是否走得通"，不是"Agent 答得好不好"。后者是我们下一阶段要补的验证，见第六节。

三、概要设计

3.1 为什么分成三层

系统由 Vue 前端、Java 业务后端、Python Agent 服务和数据基础设施组成。前端只访问 Java；Java 管理业务数据和正式结果；Python 根据当前任务解析意图、调度领域专家、调用检索工具。

这样切分不是技术堆叠，而是按"确定性"划界：判分、事务、记录保存必须是确定的，放在 Java；意图解析、检索、内容生成是不确定的，放在 Python，可以独立迭代模型和提示词而不触碰业务事务。两侧通过内部服务调用衔接，Python 使用 Java 提供的个人数据快照和独立知识资料完成请求，不直接连接业务 MySQL——这条边界让业务数据和对话上下文不会互相污染，Python 侧出问题也不至于写坏业务库。

图6　系统总体架构与主要数据流

四层各自的职责：

表现层用 Vue 3、TypeScript、Vite 和 Element Plus，负责页面展示、表单交互、练习作答、助手流式回答和后台审核。

业务服务层用 Java、Spring Boot 和 MyBatis-Plus，负责认证、档案、题库、判分、学情数据、会话任务、院校目录、笔记与审核。

智能体服务层用 Python、FastAPI、会话协调器和领域专家，负责意图解析、任务编排、知识检索、院校筛选、解释与建议生成。

数据与资源层由 MySQL、Redis、Qdrant、OSS 和版本化语料组成，分别承担业务持久化、令牌撤销与导出缓存、向量检索、头像文件和知识资料管理。

3.2 Agent 怎么被组织

需求层面只提"学情分析""院校推荐"，但实现时必须拆细，否则一个协调器要同时处理所有任务。我们把任务归为六类专家，由协调器按当前请求选择执行：

• 知识专家：知识问答、错题上下文辅导，从题目、错题或助手页面进入，展示解释与相应依据。
• 学情专家：解释学习表现、归纳薄弱环节，使用 Java 提供的学习画像与有效作答快照。
• 院校专家：按报考条件筛选、排序和解释候选，连接院校推荐页面。
• 练习专家：提出补强练习建议，用户确认后由 Java 创建练习批次。
• 笔记专家：生成整理或修改建议，在个人笔记中预览，确认后追加版本。
• 学习计划专家：根据目标和学习表现安排复习，在助手中展示分天任务。

知识问答通过 RAG 从版本化资料中检索相关证据，再组织回答并附上来源。院校推荐先完成条件筛选和排序，再按需生成解释；单所院校的目录事实查询则交给 Java 的院校目录服务。两个入口分别服务"查某校信息"和"比较候选院校"，不混在一条链上。

对于"分析我的薄弱点，并安排下一阶段复习"这样的复合请求，协调器按数据需求和步骤依赖安排专家协作。练习创建、笔记保存这类写操作，一律以用户确认为交互节点，最终由 Java 执行并保存——智能体可以提议，但不能替用户落库。

3.3 五张图，各回答一个问题

UML 部分我们没有追求画全，而是让每张图回答一个具体问题。完整图表在仓库里，博客只放主干。

用例图：谁能用什么。 学生侧覆盖账号、练习、复盘、学情、院校和助手；管理员侧覆盖内容录入、审核和维护。图中用包含、扩展关系区分必要步骤与条件触发的功能。

图7　学生用例图

图8　管理员用例图

用例的价值在于检查入口是否完整：比如"错题复盘"既需要作答记录和判分结果，也需要进入解析与上下文辅导的路径；"内容审核"则需要待审核列表、查看内容和处理意见等配套操作。完整需求映射见 T04 用例与业务活动设计。

活动图：一次练习怎么走。 从进入练习到结束批次，普通练习强调提交后的即时反馈，诊断模式强调批次完成后的集中反馈；草稿、提示、判分与结果统计在流程中各有明确位置。

图9　练习与诊断活动图

仓库另有学情补强、院校查询和院校推荐的活动图，分别对应原型中的"统计—分析—创建练习""院校目录查询"和"推荐条件—候选结果"路径，见 T04 图表目录。

类图：职责怎么分。 博客只取会话主链：ConversationController 提供请求入口，ConversationService 组织消息、任务与结果，AssistantLearningService 按计划读取个人数据并整理建议操作；Python 侧由 ConversationWorkflow 进入 ConversationCoordinator，再调度知识等领域专家。

图10　会话与智能体编排核心类图

图中省略了参数和次要依赖，Java 与 Python 之间的依赖通过内部服务调用实现。题库练习等模块的类与职责见 T03 架构与核心类图。

时序图：一次助手请求怎么走。 采用"计划解析—读取数据—流式执行"的两段式调用：Java 先取得任务需要的专家与数据类别，再读取对应的个人数据快照，最后把计划和快照交给 Python 执行；结果持续推送到页面，并由 Java 保存为正式记录。

图11　助手请求主链时序图

关键算法在这条链上的位置是：

1. 意图解析与专家调度：把用户问题转为结构化任务，依据步骤依赖选择专家。
2. 知识检索：按问题检索版本化语料，用关键词或向量检索结果组织有来源的回答。
3. 院校筛选与排序：按年份、专业、学位类型、考试科目和地区形成候选，再展示排序和可选解释。
4. 练习判分：Java 依据题目版本快照和标准答案判分，把有效作答纳入学习统计，供后续分析使用。

完整设计还包含练习诊断判分、院校目录查询、院校推荐及取消处理等时序，见 T05 Agent 与调用设计。

协作图：对象怎么连。 把同一任务中的关键对象放进一张图，用编号表达消息顺序；相比时序图，更容易看清前端、会话服务、数据读取、协调器和领域工具之间的连接关系。

图12　助手对象协作图

Java 会话服务是业务协调中心，Python 协调器负责领域任务内部的专家协作；完整编号消息与返回关系保留在 T05 原始通信图中，博客只展开主干。

四、数据库设计

4.1 先想清楚要留什么证据

备考平台的价值不在"存了题"，而在"半年后还能说清当时为什么判错、依据是哪一版题、来源是哪份资料"。所以数据库设计的第一原则是留痕：题目有版本，作答存快照，画像存历史，知识存来源。

具体来说，同一道题会被多次修订，如果只存题目当前内容，历史作答就对不上当时的题干；学习画像会随每次练习变化，如果只存当前值，就看不出"这周比上周好在哪"；知识回答需要可追溯，如果只存答案不存来源，用户无从核对。这三点决定了后面几张"看起来多余"的表。

4.2 七个域、28 张表

围绕 28 张表划出七个业务域，并配套字段字典、实体映射和 SQL 结构索引。按域分层的做法是：先说明全局关系，再展开具体表和字段，避免一上来就陷进字段细节。

业务域	代表表	保存的内容
账号与授权	user、assistant_privacy	账号、备考档案、助手数据使用范围
题库与版本	question、question_version	题目内容、来源、审核状态及历史版本
练习与作答	practice_session、practice_record、user_question_mark	练习批次、作答判分、错题与收藏
学情与自动推荐	learning_profile、learning_profile_history、learning_event	当前画像、历史变化、重算事件和推荐设置
院校与招生	school、school_detail、school_admission_metric	院校、专业年份、招生指标与来源口径
Agent 任务与会话	task、chat_conversation、chat_message、chat_generation	任务输入输出、会话消息、生成尝试与终态
资料与个人笔记	document、personal_document、personal_document_version	审核资料、个人笔记正文与版本历史

存储上做了分工：MySQL 保存业务事实；Redis 保存令牌撤销信息和导出缓存；Qdrant 保存独立的知识向量索引；OSS 保存头像文件。领域知识以版本化语料管理，检索证据保留来源和版本，这样回答能对应回具体资料，而不是一句"模型认为"。

4.3 ER 图：先看全局，再看学习主链

总览图展示七个业务域与表之间的联系，分域图补充具体字段和关联。图中实线表示数据库物理外键，虚线表示应用层使用的逻辑关联；具体基数和归属以图例及说明书为准。

图13　数据库总览 ER 图

题库练习域是平台最核心的数据链：用户建立练习批次，批次包含作答项目；作答保留判分所依据的题目快照；错题和收藏通过用户与题目的关联记录管理。

图14　题库与练习分域 ER 图

其余学情推荐、院校招生、任务会话笔记、资料与外部存储的分域图，见 ER 图目录。

4.4 关系数据模型

下面只列核心关系模式的字段节选。PK 表示主键，UK 表示唯一键，省略号表示未在博客展开的字段；完整类型、默认值、索引和约束见数据字典。

user(id [PK], username [UK], role, target_school, target_major, exam_year, ...)
question(id [PK], subject, difficulty, review_status, ...)
question_version(question_id + version [联合PK], ...)
practice_session(id [PK], user_id, kind, state, ...)
practice_record(id [PK], user_id, question_id, session_id, question_snapshot, ...)
user_question_mark(id [PK], user_id + question_id [联合UK], ...)
school(id [PK], ...)
school_detail(id [PK], school_id, ...)
school_admission_metric(school_detail_id + metric_type [联合PK], status, ...)
task(id [PK], user_id, task_type, status, input_payload, result_payload, release_id, ...)
chat_conversation(id [PK], user_id, ...)
chat_message(id [PK], conversation_id, ...)
chat_generation(task_id [PK], message_id, attempt_no, status, ...)
personal_document(id [PK], user_id, ...)
personal_document_version(document_id + version [联合PK], ...)

主要联系包括：用户与任务一对多，院校与专业年份一对多，会话与消息一对多，笔记与版本一对多，用户和题目通过错题收藏记录形成多对多。题目版本和作答快照使历史作答能按当时的题目内容回顾。

4.5 对象与库表映射

系统同时使用 MyBatis-Plus 的 ORM 映射和基于 JDBC 的直接 SQL 访问：已有 10 张表具备实体与 Mapper，覆盖账号、题库、作答、错题收藏、任务和院校这些结构稳定的核心表；会话、个人笔记和受管练习等新增表则由相应 Service 直接访问。

映射规则本身很朴素：Java 属性 userId 对应列 user_id，Task 的输入输出对象对应结构化数据列。ChatRepository 管理 chat_conversation、chat_message、chat_generation；ManagedPracticeService 管理 practice_session、practice_session_item、question_version；PersonalDocumentService 管理 personal_document 与 personal_document_version。

逐字段映射见 T07 实体表映射，字段定义见 T07 数据字典。

4.6 四类记录怎么管

• 领域知识：语料按版本发布，保留来源定位；检索使用独立索引，回答携带本轮检索来源。
• 用户交互：会话、消息和生成尝试分别保存，能够区分连续对话、重试和最终结果。
• 任务执行：task 保存任务类型、输入、结果和状态；建议操作走业务记录，确认后才执行。
• 学习证据：作答保存题目快照与判分状态，画像保存当前值和历史变化，分析可回溯到有效作答。

个人笔记每次保存追加历史版本，助手建议确认后进入同一套版本管理；院校信息把专业年份与指标状态分开记录，展示时保留来源、统计口径与更新状态。完整结构见数据库设计说明书。

五、协作与验证

5.1 任务怎么拆

设计工作拆为 T01—T13，采用"核心设计任务 + 辅助交付任务"的组织方式：核心任务负责原型、系统设计、UML 和数据库；辅助任务整理页面、接口、SQL 依据，并负责博客、排版和交付检查。做法是公共口径先统一，设计任务并行推进，再通过交叉核对完成整合。

本次 13 位成员全部分工参与，林志涛同时负责 T01、T02；丁鑫河负责线下博客整合，与曾林远见配合汇总各部分成果、统一图文和附件入口。

成员	任务	本次具体工作	后续开发拟负责部分
林志涛	C1/T01、C2/T02	学练闭环、账号资源与后台原型，统一墨刀交互入口	前端任务流程、原型与页面交互一致性、关键路径联调
严科儒	C3/T03	系统架构、核心类图、系统设计说明书主编	Java/Python 服务集成、模块边界与系统设计维护
朱铮睿	C4/T04	学生与管理员用例图、业务活动图	用例驱动的流程测试、需求与实现对照
任奥辉	C5/T05	Agent 时序、关键算法交互和协作图	Agent 编排、检索与领域任务交互验证
翁斌	C6/T06	ER、关系模型、存储设计、数据库说明书主编	数据结构与迁移维护、业务数据一致性
何锦宏	C7/T07	数据字典、实体与库表映射	字段约束核对、持久化映射和数据库回归检查
林富强	S1/T08	前端页面、路由与组件清单	页面入口清单维护、导航与展示问题复核
尼玛顿珠	S2/T09	Java/Python API 接口定位索引	接口清单维护、前后端对接记录与接口冒烟检查
吴瑞鹏	S3/T10	SQL 结构摘录、迁移索引	迁移执行说明、结构变更记录与部署材料
曾林远见	S4/T11	团队博客、周计划与协作记录	周进度汇总、项目记录与成果说明
丁鑫河	博客整合（协助 T11，线下协作）	汇总原型与设计章节，统一图片、图注和文档链接，协助核对发布稿	博客与阶段成果整合、发布前图文检查
杜佳伟	S5/T12	两份说明书的格式统一及 Word/PDF 交付	文档发布、版本整理与演示材料排版
林鹏远	S6/T13	原型走查、链接检查与最终交付核对	用户路径验收、缺陷清单与提交材料复核

表中的后续职责为拟定安排，将根据实际开发进度调整。

5.2 评审怎么发生

团队用 Issues 记录任务范围和验收条件，用 Projects 跟踪进度，用 Milestones 归集本次作业节点。成员在工作分支提交文件，通过合并请求（Pull Request，PR）进入评审与整合。

工作记录	仓库记录	用途
建立作业文档入口	PR #27	统一原型、系统、数据库与辅助资料的存放位置
原型设计交付	PR #35	提交可点击原型、说明、分享链接与检查证据
用例与业务活动图	PR #29	把需求细化为角色能力与业务流程
Agent 交互设计	PR #38	说明对象调用、专家调度与关键算法步骤
数据库模型与说明书	PR #36	提交 ER、关系模型和存储设计
字段与实体映射	PR #39	为数据库说明书提供字段、类型与持久化依据
接口定位索引	PR #31	为系统与交互设计提供 Java/Python 接口入口
SQL 结构与迁移索引	PR #41	便于设计与实际建表脚本交叉核对
系统设计说明书初版	PR #42	汇总系统架构、模块、接口与运行设计
页面与原型覆盖清单	PR #44	核对路由、页面包装、原型入口与缺项
Word 与 PDF 交付	PR #45、PR #47	提交两份说明书及 PDF 修订版本
原型走查与交付核对	PR #46	检查学生端、后台、Agent 流程、公开链接与附件
博客与周计划整合	PR #48、PR #55	提交博客、周计划及后续修订

评审中有三类交叉核对起了作用：T04 与 T05 核对了用例编号及练习、院校、助手流程；T06 与 T07 核对了关系模型与字段映射；接口、页面和 SQL 清单则为主编提供可直接引用的依据。

多人协作里最直接的成本是"改同一个文件"。我们的做法是让每位成员独立交付、由主编汇总，尽量把并行写操作变成并发读操作——代价是汇总阶段要花时间统一口径，这一点在复盘里还会提到。

图15　GitHub Project 任务协作看板

图16　GitHub Project 进度记录

5.3 交付节点与证据

本次作业按四步收口：11 月 5 日完成原型交互与各设计任务初稿；11 月 6 日交叉核对并整合系统与数据库说明书；11 月 7 日补齐资料、统一排版并导出 PDF；11 月 8 日做原型走查与链接检查，形成可发布稿。

截至 2026 年 11 月 7 日，页面覆盖清单、两份 PDF、原型走查及博客相关成果均已有合并记录。成员通过 Issue 认领、分支提交、PR 评审与 Project 状态更新串联工作，交付文件和检查记录统一保存在课程作业目录。

贡献分布可以从 Contributors 面板直接看出来。

图17　GitHub Contributors 面板

面板共列出 14 个账号：最高 60 次提交，其后依次是 6、4、4、3、3、2、2、2、1、1、1、1、1 次。除 1 个 AI 编程助手账号（claude）外，其余 13 个账号对应 13 位成员——每位成员在仓库里都有自己的提交记录，但分布很不均衡：少数成员承担了主体开发，多数成员的提交集中在文档、清单和走查记录上。

这种分布和分工表是吻合的：13 位成员各有一块交付物，只是体量差得远。我们没有为了"看起来均匀"去拆分提交，因为提交次数本身说明不了贡献；但它确实暴露了一个问题——线下整合类的工作在仓库里几乎不留痕，丁鑫河汇总章节、统一图注、核对发布稿这些事，只能从周计划和讨论记录里看到。

图18　团队讨论与任务协作记录（一）

图19　团队讨论与任务协作记录（二）

5.4 截止日期之后的开发计划

后续开发以现有成果为基础，优先完善关键用户路径、数据质量与系统联调。下表为预期安排，里程碑按可检查的产出定义。

周次与日期	预期开发内容	主要负责及协作	里程碑	预期产出
第 1 周：11/09—11/15	完成本次课程交付；汇总原型与实现差异，整理练习、助手、院校与笔记的联调问题	林志涛、严科儒；朱铮睿、林富强、尼玛顿珠协作；曾林远见整理记录	M1：确定下一阶段开发范围	作业归档、差异与缺陷清单、更新后的页面/API 清单
第 2 周：11/16—11/22	完善练习、判分、错题和学情主链；复核题目版本、画像与数据库关联	林志涛、翁斌、何锦宏；朱铮睿、吴瑞鹏协作	M2：学练闭环通过集成验收	修复 PR、关键流程检查记录、结构及迁移说明
第 3 周：11/23—11/29	联调 Agent、知识检索、院校查询推荐与笔记建议；优化来源展示和确认操作	任奥辉、严科儒、林志涛；尼玛顿珠、林富强协作	M3：智能体与页面任务形成完整演示	Agent 联调记录、检索与推荐样例、更新后的交互演示
第 4 周：11/30—12/06	完整路径回归，整理部署与演示材料，按问题优先级收口	林鹏远、朱铮睿组织走查；各模块负责人修复；杜佳伟、曾林远见、丁鑫河、吴瑞鹏整理材料	M4：形成可演示、可交付版本	回归记录、发布说明、部署材料、最终演示与更新文档

六、复盘

把这次作业按"已经验证的"和"还没验证的"分开看，结论比较清楚。

已经验证的。 原型是能走通的：27/27、13/13、7/7 三组检查有记录、可复现；PR 与 Project 对得上，每个交付物都能追到提交和评审；13 位成员在仓库里都有自己的提交。

还没验证的。 第一，Agent 到底有没有用，目前没有任何数字支撑。27/27 只说明页面点得通，说明不了诊断准不准、建议会不会被采纳、用了之后学生是否真的少错几道题。第二，贡献记录只反映"提交了多少"，反映不了"做了什么"——整合、校对、走查这类工作在 Contributors 面板上看不见，丁鑫河的线下整合就是典型。第三，原型与实现之间的差距还没有清单化：20 个入口里哪些先做、哪些只作演示，目前只有方向，没有优先级。

下一步。 第 1 周的交付里有一份"原型与实现差异清单"，这三件事都要落在它上面：效果验证怎么做、线下工作怎么记录、入口怎么排优先级。否则下一阶段还会在同样的问题上返工。

七、成果入口

成果	在线入口
GitHub 团队仓库	fzu-404-team/kaoyan-agent-platform
本次作业文档目录	docs/coursework-02
墨刀在线原型	408agent 可点击原型
408小组_系统设计说明书.pdf	下载 PDF
408小组_数据库设计说明书.pdf	下载 PDF
系统设计说明书在线文本	查看 Markdown 版本
数据库设计说明书在线文本	查看 Markdown 版本