2026秋软工实践奶蛙工程——项目原型设计+概要设计

项目 内容
作业所属课程 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，不连接后端、实时政策检索、大模型、学校审批系统或真实通知服务；正式提交仍以团队发布的墨刀原型为准。

【原型截图展示】

下图展示了用户端“智能问答”的核心初始界面。页面左侧为功能导航（包含智能问答、办事指南、材料清单、提醒中心等），中间为对话交互区，右侧侧边栏直观展示了“我的办事画像”（学历、年级、校区）及“高频事务”快捷入口。底部输入框提示用户可直接输入校园事务问题。

1
*

2.2 原型交互亮点（结合领域 Agent）

虽然目前原型展示的是初始页，但我们的设计核心不是单纯的聊天页面，而是把 Agent 输出拆成可执行组件：结论卡、适用条件、步骤列表、材料清单、官方来源、风险提示和下一步按钮。概要设计目标是让用户从回答进入清单、负责部门或提醒流程，并在有副作用的操作前确认。

  1. 来源卡片前置： 回答不只给文本，还给政策名称、发布部门、发布日期、原文链接和最后核验时间。
  2. 风险可见： 没有证据、政策冲突或可能过期时，界面显示“不确定/需人工确认”，而不是伪装成肯定答案。
  3. Agent 与功能结合： Agent 负责理解和规划，确定性工具负责检索、清单、提醒和联系方式；用户能看到每个动作的结果。
  4. 画像筛选： 用户主动填写学历、年级、专业、校区后，政策卡片显示“适用/不直接适用”的匹配结果。

三、概要设计与 UML

3.1 总体架构

系统采用前后端分离的模块化单体：表示层负责用户端和管理端；应用层负责 API、会话、政策、清单、提醒和反馈服务；领域层包含事务 Agent、证据门禁、政策模型和受控工具注册表；基础设施层负责关系数据库、检索索引、原文存储、模型适配和日志。

flowchart TB UI[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 如何识别意图、调用工具并经过证据门禁输出答案的完整业务流程：

flowchart TD A[用户输入问题] --> B[识别意图与条件] B --> C{条件足够?} C -- 否 --> D[追问关键条件] D --> B C -- 是 --> E[检索政策知识库] E --> F[核验证据/冲突/时效] F --> G{证据校验通过?} G -- 否 --> H[保守降级: 提示风险/提供官方渠道] G -- 是 --> I[生成结构化回答 + 来源 + 风险提示] H --> J[返回结果] I --> J

3. 核心时序图（Sequence Diagram）- 请假咨询与引用

展示前端、后端 API、Agent 与政策工具库之间的消息传递关系。从提交问题、识别意图、检索证据到最终渲染来源卡片，清晰体现了各个对象间的协作。

deepseek_mermaid_20261109_304fc2

4. 类模型与协作关系

  • 类图（Class Diagram）： 核心结构包含用户及会话实体（User、UserProfile、Conversation、Message）、政策知识实体（Policy、PolicyVersion、Citation）、业务操作实体（Checklist、Reminder、Feedback）以及核心 Agent 编排层（AgentOrchestrator、EvidenceGate、PolicySearchTool）。
  • 协作图（Collaboration Diagram）： 关键对象协作顺序为：前端提交消息 → 后端创建并定位会话 → AgentOrchestrator 识别意图并请求 PolicySearchTool → 工具返回政策片段与时效信息 → Agent 生成初步回答 → EvidenceGate 校验引用和风险字段 → 前端展示回答与来源卡片。清单保存、提醒创建等副作用操作由独立业务服务在用户确认后执行。

四、数据库设计

数据库设计采用“政策主对象—政策版本—来源文件—回答引用”链路，确保政策更新后历史回答仍可追溯。核心表包括：用户与画像、角色、部门、政策、政策版本、适用对象、来源文件、会话、消息、回答、引用、材料清单、提醒、收藏、反馈、工具调用日志和审计日志。

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 答辩复盘 演示脚本、指标图和迭代清单

六、提交材料链接

七、总结

本次设计的核心不是把大模型嵌入页面，而是把领域知识、确定性工具和风险控制组织成可解释的系统闭环：用户问题 → 事务识别 → 画像过滤 → 政策证据 → 受控生成 → 引用校验 → 可执行操作/保守降级。

这样既体现 Agent 的领域价值，也保留普通政策查询、流程详情和材料清单在模型不可用时的可用性。后续开发应坚持 P0 闭环，先让三类代表性任务做到有来源、可追溯、能降级，再扩展更多校园事务。

posted @ 2026-11-09 22:11  halttt  阅读(2)  评论(0)    收藏  举报