| 项目 | 内容 |
|---|---|
| 作业所属课程 | https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering |
| 作业要求 | https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering/homework/16773 |
| 作业的目标 | 在第一次需求分析基础上，完成可交互原型、分层概要设计、UML 设计、数据库设计和后续开发协作计划，重点说明领域 Agent 如何与软件功能结合。 |
| 团队名称 | 奶娃工程 |
| 团队成员学号-名字 | 052403146-蔡明润；102401603-张馨恬；102401606-黄丽婷；102401416-唐捷；102401605-王乐禾；102401502-王钰涵；152402217-陈霁然；102401403-潘岳；102401601-李佳雨 |
一、项目概述：为什么做校园事务智能办事助手
校园事务信息分散在学校官网、学院通知、规章制度和不同业务入口中。学生常见的困难不是完全找不到信息，而是不知道哪个版本适用、材料是否齐全、流程应该先做什么，也不确定网上答案是否可靠。
团队对 56 份有效问卷进行分析后发现：71.43% 的受访者认为信息分散是主要困难，57.14% 遇到过材料不全而白跑，73.22% 愿意使用校园事务智能办事助手；另一方面，73.21% 担心回答不准确，73.21% 担心来源不可靠，82.14% 希望按照年级、专业和校区筛选政策，78.58% 需要截止时间提醒。
因此，我们没有把目标设定为“什么都能回答的聊天机器人”，而是设计一个有证据、有边界、能给出下一步行动的校园办事助手。首期明确聚焦请假/销假、国家奖学金、优秀学生综合奖学金三类事务；具体政策内容必须经团队核验后再进入知识库。
二、原型设计
2.1 原型工具与交付链接
- 正式原型工具： 墨刀
- 正式在线展示链接： 墨刀只读预览（访问权限：所有人；已用匿名窗口核验）。
- 离线补充原型： 架构负责人提供了
prototype/index.html，用于补充演示 Agent 问答状态、证据来源、风险提示、材料清单、提醒确认、个人画像和管理端核验状态。它使用预设政策样例与浏览器 localStorage，不连接后端、实时政策检索、大模型、学校审批系统或真实通知服务；正式提交仍以团队发布的墨刀原型为准。
【原型截图展示】
下图展示了用户端“智能问答”的核心初始界面。页面左侧为功能导航（包含智能问答、办事指南、材料清单、提醒中心等），中间为对话交互区，右侧侧边栏直观展示了“我的办事画像”（学历、年级、校区）及“高频事务”快捷入口。底部输入框提示用户可直接输入校园事务问题。
*
2.2 原型交互亮点（结合领域 Agent）
虽然目前原型展示的是初始页，但我们的设计核心不是单纯的聊天页面，而是把 Agent 输出拆成可执行组件：结论卡、适用条件、步骤列表、材料清单、官方来源、风险提示和下一步按钮。概要设计目标是让用户从回答进入清单、负责部门或提醒流程，并在有副作用的操作前确认。
- 来源卡片前置： 回答不只给文本，还给政策名称、发布部门、发布日期、原文链接和最后核验时间。
- 风险可见： 没有证据、政策冲突或可能过期时，界面显示“不确定/需人工确认”，而不是伪装成肯定答案。
- Agent 与功能结合： Agent 负责理解和规划，确定性工具负责检索、清单、提醒和联系方式；用户能看到每个动作的结果。
- 画像筛选： 用户主动填写学历、年级、专业、校区后，政策卡片显示“适用/不直接适用”的匹配结果。
三、概要设计与 UML
3.1 总体架构
系统采用前后端分离的模块化单体：表示层负责用户端和管理端；应用层负责 API、会话、政策、清单、提醒和反馈服务；领域层包含事务 Agent、证据门禁、政策模型和受控工具注册表；基础设施层负责关系数据库、检索索引、原文存储、模型适配和日志。
flowchart TBUI[Web/H5 用户端与管理端] --> API[API/鉴权层]API --> App[会话/政策/清单/提醒应用服务]App --> Agent[事务 Agent 编排器]Agent --> Tools[PolicySearch / Checklist / Reminder / Contact]Agent --> Gate[证据门禁与风险规则]Tools --> DB[(业务数据库)]Tools --> Index[(全文/关键词索引)]DB --> Source[(政策原文/附件)]Agent --> Adapter[模型适配层]Adapter --> LLM[大模型 API]App --> Audit[审计与可观测性]### 3.2 Agent 集成方式与运行逻辑在本系统中，Agent 的定位是“任务规划与语言组织层”，而非直接操作数据库的超级大脑。为了避免大模型产生幻觉或越权操作，我们采用了 **“单事务 Agent + 多个确定性工具 + 证据门禁”** 的集成架构。#### 1. Agent 的职责边界
* **意图识别与条件补全：** 通过多轮对话理解用户真实的办事需求（如：区分“本科生”与“研究生”的请假规则），若缺少必要条件（如：请假天数），主动发起追问。
* **受控工具调度：** Agent 本身不包含政策数据，而是根据意图规划调用哪个后端工具（如 `PolicySearchTool`、`ChecklistTool` 等）。
* **格式化输出：** 将工具返回的结构化数据（条件、材料、步骤）组织成用户易读的自然语言，并附带来源引用。#### 2. 确定性工具（受控调用）
系统中的副作用操作和事实检索由后端封装的确定性工具完成，Agent 无权直接修改数据：
* `PolicySearchTool`：根据用户画像（年级、专业等）、事项关键词和时效状态，在关系数据库中检索政策证据。
* `ChecklistTool`：根据匹配的政策，生成标准化的材料清单。
* `ReminderTool` / `ContactTool`：在用户明确确认后，保存提醒或查询已核验的部门联系方式。#### 3. “证据门禁”（Evidence Gate）机制
这是 Agent 与软件功能结合的关键安全阀。在 Agent 生成最终回答前，必须经过证据门禁的校验：
1. **校验通过：** 只有当检索到的政策记录状态为“已发布”且未过期、适用对象匹配时，才允许 Agent 生成确定性回答。
2. **校验失败（风险降级）：** 若无检索结果、政策存在版本冲突或可能过期，系统强制 Agent 切换为“保守答复”模式，向用户提示风险，并提供官方渠道或人工咨询入口，绝不让大模型“编造”答案。**完整交互生命周期如下：**
`用户提问` → `Agent 识别意图与条件` → `调用 PolicySearchTool 获取证据` → `Agent 生成候选回答` → `证据门禁校验（来源/时效/对象）` → `通过则输出结构化回答及引用 / 失败则降级提示`。### 3.3 主要 UML 设计清单关于 UML 的详细绘图与源文件，我们已完整整理并提交至 GitHub 团队仓库及《系统设计说明书》PDF 中。为直观展示系统核心逻辑，以下提供主要的模型清单及关键流程的 Mermaid 渲染图：#### 1. 用例模型（Use Case）
* **学生端：** 提出政策问题、补充条件、浏览事务、查看流程与来源、生成/勾选清单、创建提醒、查看历史、收藏、反馈。
* **管理端：** 政策草稿录入、核验政策、发布/下线或标记过期。
* **外部渠道：** 提供制度原文、通知、办事指南和联系方式。#### 2. 核心活动图（Activity Diagram）- Agent 问答主流程
描述用户提问后，Agent 如何识别意图、调用工具并经过证据门禁输出答案的完整业务流程：```mermaid
flowchart TDA[用户输入问题] --> B[识别意图与条件]B --> C{条件足够?}C -- 否 --> D[追问关键条件]D --> BC -- 是 --> E[检索政策知识库]E --> F[核验证据/冲突/时效]F --> G{证据校验通过?}G -- 否 --> H[保守降级: 提示风险/提供官方渠道]G -- 是 --> I[生成结构化回答 + 来源 + 风险提示]H --> J[返回结果]I --> J## 四、数据库设计数据库设计采用“政策主对象—政策版本—来源文件—回答引用”链路，确保政策更新后历史回答仍可追溯。核心表包括：用户与画像、角色、部门、政策、政策版本、适用对象、来源文件、会话、消息、回答、引用、材料清单、提醒、收藏、反馈、工具调用日志和审计日志。### 4.1 核心关系（ER 设计）详细 ER 图与数据字典请参见《奶娃工程_数据库设计说明书.pdf》。核心实体关系如下：* USER 1—1 USER_PROFILE
* USER 1—N CONVERSATION 1—N MESSAGE 1—N CITATION N—1 POLICY_VERSION
* POLICY 1—N POLICY_VERSION 1—N POLICY_SOURCE N—1 SOURCE_DOCUMENT
* POLICY 1—N POLICY_AUDIENCE；DEPARTMENT 1—N POLICY
* USER 1—N CHECKLIST 1—N CHECKLIST_ITEM
* USER 1—N REMINDER；USER 1—N FAVORITE；USER 1—N FEEDBACK### 4.2 Agent 数据边界Agent **不直接连接数据库**。后端工具负责权限、字段投影、状态过滤、脱敏和审计，只向 Agent 返回已发布且未过期的政策证据包。向量检索是后续增强项，关系数据库仍是政策事实源；回答引用必须保存 `policy_version_id` 和原文片段。## 五、团队协作记录与开发计划### 5.1 团队成员分工* **版本与验收统筹：** 蔡明润
* **政策知识核验：** 张馨恬、黄丽婷
* **Agent 与系统架构：** 唐捷、王乐禾
* **前后端接口与数据库设计：** 王钰涵、陈霁然
* **墨刀原型与测试验收：** 潘岳、李佳雨*(注：团队使用专业项目管理平台飞书进行协作，每位成员均已在 GitHub 上留下贡献记录。具体截图见仓库目录。)*### 5.2 后续每周计划| 周期 | 里程碑 | 产出 |
| :--- | :--- | :--- |
| 11-09—11-15 | 冻结技术栈和 API/数据库契约 | 接口文档、迁移脚本、分支规则 |
| 11-16—11-22 | 知识库 P0 | 政策及核验记录 |
| 11-23—11-29 | 非生成式功能 | 政策详情、清单、画像、来源 |
| 11-30—12-06 | Agent P0 | RAG 检索、回答模板、证据门禁 |
| 12-07—12-13 | 用户端联调 | 问答、提醒、历史、反馈 |
| 12-14—12-20 | 管理端和权限 | 核验发布、RBAC、审计 |
| 12-21—12-27 | 测试评测 | 20+问题集、回归报告、风险修复 |
| 12-28—01-03 | 部署演示 | Docker Compose、HTTPS、演示数据 |
| 01-04—01-10 | 答辩复盘 | 演示脚本、指标图和迭代清单 |## 六、提交材料链接* **GitHub 团队仓库：** [https://github.com/trony33/fuxiaotong-campus-affairs](https://github.com/trony33/fuxiaotong-campus-affairs)
* **团队设计文档（含系统设计说明书、数据库设计说明书）：** [点击下载百度网盘文件](https://pan.baidu.com/s/1kknABYpBVIEKGYwgh_Gl-w) （提取码：`rdqm`）
* **原型设计展示链接：** [墨刀只读预览](https://modao.cc/proto/RXDXHlcLto8ebhZYV3MNe8/sharing?view_mode=read_only&screen=rbpVaTLNX8pb7I5Z5)
* **架构负责人基线文档：** [04_Agent与系统架构最终稿（V1.0）](https://mi.feishu.cn/docx/WA5ud2GyGoyYBpxdcT4clwcLnwf)## 七、总结本次设计的核心不是把大模型嵌入页面，而是把领域知识、确定性工具和风险控制组织成可解释的系统闭环：**用户问题 → 事务识别 → 画像过滤 → 政策证据 → 受控生成 → 引用校验 → 可执行操作/保守降级**。这样既体现 Agent 的领域价值，也保留普通政策查询、流程详情和材料清单在模型不可用时的可用性。后续开发应坚持 P0 闭环，先让三类代表性任务做到有来源、可追溯、能降级，再扩展更多校园事务。