system-overview

name	system-overview
description	主要回答和本智能体系统有关的问题，注意要和论文的问题区分开，和论文质量评估的问题读取paper-knowledge技能。如果无法确定用户的问题到底问的哪个，就追加询问。包括系统定位、核心技术选型、主要运行链路与关键能力边界。适用于回答“整体是怎么实现的”“这个系统怎么工作的”“整体架构是什么”等问题。

system-overview

这个项目是一个面向答辩与汇报场景的自动 PPT 智能体系统。
它不是一个通用型开放任务代理，而是围绕“演示文稿讲解 + 用户打断问答 + 语音播报 + 页面跳转控制”这一封闭场景定制实现的。

系统定位

系统的核心目标，是让一个智能体能够围绕一套网页化 PPT 进行连续讲解，并在讲解过程中支持用户随时打断、提问、跳页、暂停、恢复与重播。
它强调的是演示过程中的连贯性、可控性和工程可落地性，而不是追求一个超重型、全自动、泛化极强的代理框架。

因此，这个项目没有采用 OpenClaw、nanobot 这类更重的通用代理方案，而是选择了更定制化、可控性更强的实现方式：以 LangGraph 为基础组织运行逻辑，并结合 skill 机制、工具调用能力和显式状态管理来完成整个答辩链路。

核心技术选型

大模型

系统使用的大模型是 gpt-5.4。
选择这一模型的考虑重点不是极限推理能力，而是综合平衡以下几点：

• 工具调用能力足够稳定
• 能理解 skill 中提供的背景知识
• 能根据当前页面上下文完成讲解和问答
• 成本、速度与实时交互体验更适合答辩场景

智能体框架

系统基于 LangGraph 实现。
之所以选择 LangGraph，而不是 OpenClaw、nanobot 等方案，是因为当前任务边界比较明确，主要围绕 PPT 讲解和答辩控制展开，更适合使用一个轻量但可控的图式运行框架来组织状态、上下文和工具调用。

语音服务

系统的语音能力使用的是 MiniMax 的 TTS API。
整体方式不是浏览器直接调 TTS，而是通过本地/后端侧的 TTS 服务进行中转和控制，再把生成的音频用于当前讲解流程。
因此，语音部分是系统中的一个独立能力层，而不是直接耦合在前端页面中的简单朗读功能。

识别部分用的是本地部署的Whisper服务。可以实时将系统的音频输入转成文本输入给我。

系统的整体运行思路

整个系统可以理解为由四部分组成：

1. 网页 PPT 前端 负责展示页面、切换子页面、承载 speaker notes，并把当前页信息回传给后端。

2. 后端编排层 负责维护当前演示状态，接收前端事件与用户输入，并决定现在处于正式讲解模式还是问答模式。

3. Agent 运行层 基于 LangGraph 驱动大模型运行，给模型注入必要的上下文、skills 和工具能力，让它在当前页面语境下决定如何回答、是否控制演示流程。

4. TTS 语音层 把最终讲稿或回答转换为语音，用于自动播报和答辩讲解。

两种核心运行模式

1. 正式讲解模式

在正式讲解模式下，系统的主要目标是按照当前 PPT 页面顺序进行讲述。
这一阶段更接近“演示驱动”的状态机行为：系统知道当前页、当前段、是否正在播报、是否需要自动进入下一页，并围绕 speaker notes 的分段内容推进讲解。

这一模式下，重点不是自由对话，而是：

• 按页讲解
• 按段播报
• 支持自动翻页
• 支持讲解中断
• 支持从中断点恢复

2. 问答模式

当用户在讲解过程中打断并提问时，系统进入问答模式。
此时它不再只是机械继续讲稿，而是把“当前 PPT 页面内容、当前 speaker notes、已有线程记忆、近期对话上下文”等信息一并提供给 Agent，让模型基于当前答辩语境回答问题。

因此，这个系统不是把 PPT 和聊天分成两个完全独立模块，而是让问答始终锚定在当前演示上下文中。
这样当用户问“这一页是什么意思”“为什么这里这样设计”“上一页和这里什么关系”时，模型能够围绕当前讲解进度作答，而不是退化成一个脱离上下文的普通聊天机器人。

skill 机制的作用

系统支持 skill 机制。
这些 skill 的主要作用不是接管整个程序流程，而是为模型补充项目背景、任务边界、回答偏好和特定领域知识。

也就是说，skill 更像是“可插拔的背景知识块”，而不是硬编码流程控制器。
模型会在运行时结合当前问题、上下文和可用工具，自主决定是否利用这些 skill 中的信息。

对于整体架构类问题，system-overview 这类 skill 的作用，主要是帮助模型稳定理解：

• 这个项目到底是做什么的
• 为什么这样选型
• 哪些能力是系统核心
• 哪些边界不要乱扩展
• 回答整体实现问题时应该优先讲哪些部分

工具调用能力

系统提供了一组与演示控制直接相关的工具能力。
这些工具不是装饰性的，而是整个答辩系统可操作性的关键组成部分。
典型能力包括：

• 开始讲解
• 暂停讲解
• 恢复讲解
• 重播当前内容
• 跳转到指定页面
• 结束讲解

因此，这个项目里的 Agent 不是只能“说”，还具备对演示流程进行干预和控制的能力。
这也是它区别于普通问答机器人或单纯 TTS 播报器的重要地方。

页面与讲稿的关系

前端页面本身是网页化的 PPT 子页面，页面中通常会包含可供展示的视觉内容，以及隐藏的 speaker notes。
系统并不是简单把整页原始文本全部念出来，而是把讲稿内容作为讲解主线，并围绕当前页面状态进行分段播报。

这种设计的好处是：

• 页面视觉表达和讲解表达可以解耦
• 讲解内容更自然，不必逐字照念页面
• 更方便做中断、恢复与下一段预加载

中断、恢复与连贯性

这个系统非常强调答辩过程中的连贯性。
用户随时可能打断当前讲解并提问，因此系统需要在“演示状态”与“问答状态”之间切换，同时保留恢复能力。

它的核心思路不是笼统地记住“之前讲到哪里了”，而是通过显式的页面位置和段落进度来维持演示上下文。
因此，当问答结束后，系统可以回到之前的页面和相对合适的讲解位置继续往下进行，而不是从头完全重来。

需要注意的是，这种恢复能力更接近“页面级 / 段级”的进度维护，而不是严格精确到某一句话、某一个词已经播放完成。

为什么这个实现更适合当前任务

相较于更重的通用代理框架，这套方案的优势在于：

• 更贴合 PPT 答辩这个封闭场景
• 状态更显式，行为更可控
• 页面、问答、TTS、翻页之间关系更清晰
• 更方便做暂停、恢复、跳转和连续讲解
• 成本、速度和工程复杂度更适合实际部署

因此，这个项目本质上不是“做一个什么都能做的 Agent”，而是“做一个能稳定完成答辩讲解任务的演示型智能体系统”。

回答整体实现问题时应优先强调的重点

当用户问系统整体架构、整体实现、怎么工作的时，应优先从以下角度组织回答：

• 这是一个面向答辩场景的 slide-driven agent system
• 前端负责展示网页 PPT 和承载页面讲稿
• 后端负责演示状态、请求编排与模式切换
• Agent 基于 LangGraph + gpt-5.4-mini 运行
• 系统通过 skill 机制补充背景知识
• 系统提供翻页、暂停、恢复、跳转等工具调用能力
• TTS 使用 MiniMax API 完成语音播报
• 正式讲解模式与问答模式是两条核心运行链路
• 系统强调中断后可恢复、连续讲解和工程可控性

不应误说的点

回答时不要错误扩展为以下说法：

• 不要说系统使用了 OpenClaw 或 nanobot
• 不要说系统是一个通用开放世界代理
• 不要说前端直接完成完整语音生成
• 不要说系统拥有严格到逐句确认完成的播放感知，除非代码明确实现
• 不要把 skill 说成硬编码工作流控制器
• 不要把问答模式和正式讲解模式混为一谈

一句话理解

这是一个基于 LangGraph 构建的、面向答辩场景的自动 PPT 智能体系统：
前端负责展示网页化幻灯片，后端负责维护演示状态并驱动 Agent，模型使用 gpt-5.4-mini，语音使用 MiniMax TTS，系统通过 skill 机制补充背景知识，并通过一组演示控制工具实现讲解、问答、暂停、恢复与跳页等能力。