OopsAgent Strategy Board

山东科技大学 · 思途杯挑战赛 · 2026

Agent 项目方向评审板

这不是一个“先聊再选”的交互原型，而是一份可直接发给团队成员的方案评审页。 页面把 校园师生助手、生活情感助手 和 高价值工具型 Agent 放到同一套标准下，集中比较参赛匹配度、 技术可行性、商业价值、路演表现和最终落地难度。

直接看总对比 看服务器部署方案
报名截止：2026 年 5 月 12 日 18:00 作品提交：2026 年 5 月 30 日前 决赛路演：2026 年 6 月 6 日

比赛信息提炼

比赛要求速览

以下内容来自你提供的比赛通知 PDF，决定了这个项目不能只做聊天界面， 而要像一个真实可用的业务 Agent 产品。

展示形式

必须以 Web 页面展示，强调简洁、美观、大方，并带有商务化风格。

核心能力

最好具备 RAG 检索、工具调用、大模型调用、意图识别能力。

价值导向

要求具备创新思维、正向价值，并尽量体现商业价值或社会价值。

推荐风格

比赛样例明显偏向流程自动化、知识检索、问数分析、文档处理等工具型场景。

方向判断

三种方案全维度对比

三个方向都能做，但它们适合的团队状态、数据准备方式、演示方式和答辩打法完全不同。

Option A

校园师生助手

把校园通知、制度流程、赛事资料、教务信息和日常问答统一到一个入口里。

  • 最贴近学校环境，天然容易解释“为什么值得做”
  • RAG 和文档检索最自然，适合直接用比赛通知做 Demo
  • 如果做得好，很像学校内部知识服务平台的雏形
比赛贴合度 9.0 / 10
开发风险 7.0 / 10
Option B

生活情感助手

主打陪伴感、情绪记录、压力疏导和行动建议，走高颜值对话产品路线。

  • 最容易做出有温度的 UI，适合展示连续对话和情绪可视化
  • 如果没有额外资源与机制，RAG 和工具调用会显得比较弱
  • 需要特别注意边界，避免变成“普通聊天机器人”
比赛贴合度 7.2 / 10
开发风险 6.5 / 10
Option C · 推荐

高价值工具型 Agent

聚焦“文档理解 + 规则校验 + 自动建议”，做毕设助手、材料审查助手或审批助手。

  • 商业价值最清晰，老师和队友最容易一眼看懂它解决什么问题
  • 能天然串起上传文档、RAG 检索、规则校验、工具链执行和结果可视化
  • 答辩时特别好讲 ROI、可扩展性和实际落地路径
比赛贴合度 9.4 / 10
开发风险 6.8 / 10

比较矩阵

同一标准下看清三种方向的差异

表格里的评分不是绝对真理，而是帮助团队快速统一判断标准。分数越高，越适合作为本次比赛主方向。

比较维度 A 校园师生助手 B 生活情感助手 C 高价值工具型 Agent
核心场景 校园通知、流程答疑、资料检索、表单引导 情绪陪伴、成长记录、压力管理、行动建议 文档审阅、规则校验、版本比对、材料补全
目标用户 学生、老师、辅导员、社团负责人 学生个体、情绪压力较大用户 参赛学生、老师、行政事务场景使用者
RAG 适配度 9.5，知识库非常自然 5.5，需要额外设计知识源 9.3，文档和规则库非常适合做检索增强
工具调用适配度 8.8，适合通知解析、资料摘要、流程清单 6.0，更多依赖对话记忆和策略生成 9.4，适合 OCR、解析、校验、导出、对比
商业价值 8.4，可做校园知识服务和办事助手 6.8，价值感强但商业闭环更难讲 9.6，能直接映射到企业文档审核与业务协同
社会价值 9.2，提升师生获取信息和办事效率 8.9，关注陪伴与心理支持 8.5，提升材料审核与知识处理效率
创新表达空间 8.0，关键看知识图谱和流程编排 8.7，关键看个性化体验与连续记忆 9.0，关键看审阅流程、结果解释和可追溯性
页面展示效果 8.7，适合工作台 + 对话双栏 9.1，最适合做精致沉浸式聊天 UI 9.3，最适合做商务工作台和对比分析面板
数据准备难度 中，需整理校园通知、制度与流程文档 中低，数据依赖度较低但机制设计更难 中，规则文档与示例材料可控且复用率高
开发周期风险 中，需要花时间做知识清洗和权限边界 中，容易前期好看但后期价值发散 中低，范围更集中，闭环更容易收束
路演讲述性 8.9，用“学生真的会用”打动评委 7.8，需要额外说明与普通聊天产品的差别 9.5，最容易现场演示“上传后立刻见效”
总判断 非常稳，适合作为校园场景主线 可以做，但必须强化独特机制与价值论证 综合最优，最适合作为本次比赛主推方向

一句话判断

什么时候选哪条路线

选 A 的前提

你们希望作品明显贴校园、好讲社会价值，并且愿意投入时间整理校园知识库。

选 B 的前提

你们团队前端表达力强，想做体验型产品，并且能把“陪伴”延展为行动闭环。

选 C 的前提

你们想在最短时间里做出像产品、像平台、像业务系统的 Agent，并且需要最稳定的答辩叙事。

前端分工

推荐技术栈组合

你列的前端项目都能用，但它们不是平替关系，更像是“各负责不同角色”。真正好用的方案是组合，不是单选。

shadcn/ui

最适合作为全站基础组件层：表单、抽屉、弹窗、Tabs、命令面板、数据输入等。

定位：底座组件库

Vercel AI SDK

适合 React/Next.js 聊天流式交互，能把消息流、工具调用结果和输出体验接顺。

定位：对话流式层

Ant Design X

官方定位就是 AI 应用复合工具集，适合做更商务的 AI 助手界面、消息流、Markdown 渲染和动态卡片。

定位：AI 界面工作台

Magic UI

用来做首页动效、背景、数字跃迁、视觉节奏，不建议拿它当业务 UI 主骨架。

定位：视觉增益层

XYFlow

适合把 Agent 流程、审批链路、工具编排、工作流节点画出来，答辩时特别加分。

定位：流程可视化

react-markdown

适合把回答、引用、总结和结构化说明安全渲染出来，如果不用 Ant Design X 的 Markdown 能力，它非常实用。

定位：回答渲染层

A 的推荐组合

shadcn/ui + Ant Design X + react-markdown + XYFlow

适合知识库问答、校园工作台、通知摘要、流程编排展示。

B 的推荐组合

shadcn/ui + Vercel AI SDK + Magic UI + react-markdown

适合情绪记录、陪伴对话、连续记忆和轻量成长档案。

C 的推荐组合

shadcn/ui + Ant Design X + XYFlow + react-markdown

适合材料上传、审阅结果对比、规则说明、引用证据和流程可视化。

后端路线

后端 Agent 框架建议

如果你们项目是前后端分离，这里建议把前端固定成一个可展示的 React 工作台，后端再根据方向选择 Agent 编排方案。

方案 1：FastAPI + LangGraph + Qdrant

综合推荐

适合 A 和 C。LangGraph 更适合做有状态、多步骤、可追踪的 Agent， 比如“上传文档 → 解析 → 检索 → 校验 → 生成建议 → 导出结果”的链路。

  • 优点：工作流清晰、可扩展、适合工具链和人工干预节点
  • 适合：校园知识助手、审批/文档审阅助手
  • 前端对接：SSE 或 WebSocket 流式返回结果

方案 2：FastAPI + LlamaIndex + Qdrant / Chroma

RAG 优先

适合 A 和 C 中偏“知识库 / 文档理解”的形态。LlamaIndex 在 RAG、文档接入、工作流上很自然， 对 PDF、知识库、规则库类项目很友好。

  • 优点：做知识检索和文档问答上手快
  • 适合：校园知识库、比赛通知解析、毕设文档问答
  • 前端对接：对话 + 文档证据卡片最合适

方案 3：FastAPI + PydanticAI + 轻量工具编排

轻量快速

适合 B，或者你们只想先做一个较轻的 MVP。它更适合先把对话体验和工具调用做通， 但如果后期流程越来越复杂，扩展性不如前两个稳定。

  • 优点：实现快，结构清爽，适合原型期
  • 适合：情感陪伴、轻工具型助理
  • 风险：复杂工作流可视化和多阶段状态管理稍弱

推荐落地组合

如果你要我给团队一个最稳的“先做这个，不容易走偏”的建议，我会推荐： 前端 React 工作台 + FastAPI + LangGraph + Qdrant， 然后把模型接入设计成抽象层，方便后续切换阿里百炼、火山、DeepSeek 或其他兼容接口。

执行节奏

落地路线图

如果团队尽快确定方向，下面这条路线最适合在较短周期内做出一个能演示、能路演、能继续扩展的版本。

01

先定方向与 Demo 叙事

决定是做 A 还是 C，B 只在你们明确要走体验型产品路线时再推进。

02

最小知识库与工具链

先准备 10 到 30 份文档和 2 到 3 个工具能力，让 Agent 真能完成一个闭环任务。

03

做一个好讲故事的工作台

左侧输入与上传，中间回答与证据，右侧流程或结果摘要，让评委一眼看懂在发生什么。

04

准备路演材料

把“问题有多真实、为什么用 Agent 解决、怎么比普通检索更强、后续如何商业化”讲完整。

发布与共享

部署到 Debian 13 + 1Panel

这套页面是静态站点，最适合先以 OpenResty 静态网站 的方式发到 1Panel， 给团队成员统一访问。等你们后面真做前后端分离项目，再把正式前端构建产物替换进去即可。

推荐方式：静态网站

  1. 在 1Panel 的应用商店里安装 OpenResty。
  2. 进入网站管理，创建一个 Static Website。
  3. 绑定域名或临时端口，记录网站目录。
  4. 把本项目文件上传到网站目录，确保首页是 index.html。

后续升级：反向代理

  1. 如果后面前端变成 Vite / Next.js 构建站，仍可继续用静态网站承载构建产物。
  2. 如果后面前端是长期运行的 Node 服务，则在 1Panel 新建 Runtime 或单独容器。
  3. 再通过网站里的 反向代理，把域名流量转发到对应端口。
  4. 正式 API 可以走 /api 路由，由 OpenResty 统一转发到 FastAPI 服务。
# 本地预览
python -m http.server 8080

# 或者用 Debian 服务器手动上传到自定义目录
scp -r ./ user@your-server:/opt/oopsagent-board

# 如果你不用 scp，也可以直接在 1Panel 文件管理里上传 index.html 和 assets 目录