| 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服务。可以实时将系统的音频输入转成文本输入给我。
系统的整体运行思路
整个系统可以理解为由四部分组成：
-
网页 PPT 前端
负责展示页面、切换子页面、承载 speaker notes，并把当前页信息回传给后端。
-
后端编排层
负责维护当前演示状态，接收前端事件与用户输入，并决定现在处于正式讲解模式还是问答模式。
-
Agent 运行层
基于 LangGraph 驱动大模型运行，给模型注入必要的上下文、skills 和工具能力，让它在当前页面语境下决定如何回答、是否控制演示流程。
-
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 机制补充背景知识，并通过一组演示控制工具实现讲解、问答、暂停、恢复与跳页等能力。
