当 PPT 也开始“自己写自己”：一个多智能体系统从想法到整套演示稿的完整落地实践

内容分享1个月前发布球球次不饱

3 0 0

一、先讲人话：这个项目到底解决了什么痛点？

如果你常常需要做汇报、写方案、准备分享，你大致经历过这种时刻：

领导一句“明天给我一份 XX 方向的 PPT”，你默默看了一眼时间——23:07；
打开 PowerPoint，对着空白第一页发呆十分钟，连目录都写不出来；
网上搜的 PPT 模板看上去光鲜亮丽，但内容还得自己肝。

MultiAgentPPT 想干的事实则很简单——把“从零开始做 PPT”这件费脑又费时间的活，交给一群 AI Agent 去干：

你只需要输入一个主题，列如“电动汽车发展概述”。
系统先帮你生成可编辑的大纲。
你确认或修改后，它会自动拆成多个子 Topic。
一群并行工作的 Research Agent 去做资料检索和内容整理。
Summary / PPT Agent 把这些研究结果汇总成 每一页 PPT 的结构化内容，还支持流式实时返回给前端。
最后再结合模板，可以一键导出 pptx文件。

一句话概括：这是一个“从一句话题目到一套可编辑 PPT”的多智能体协作系统，而不是一个简单的“帮我写几行大纲”的小脚本。

下面我们从整体架构、技术选型、核心流程和应用场景，带你把这个项目从“会用”理解到“看得懂内部设计思路”。

当 PPT 也开始“自己写自己”：一个多智能体系统从想法到整套演示稿的完整落地实践

二、整体技术架构：从浏览器到多智能体的协同工厂

先看一下官方 README 里的简洁版总览：

frontend/：Next.js + Tailwind CSS 的前端界面，负责交互、展示、流式结果渲染和历史记录管理；
backend/：一堆以功能拆分的 Python 服务：

simpleOutline/：不用外部检索的简单大纲生成；
simplePPT/：不用并发/检索的简单 PPT 内容生成；
slide_outline/：接入 MCP 检索的高质量大纲生成；
slide_agent/：真正的多智能体并发 PPT 内容生成核心；
以及辅助的 ppt_api/、save_ppt/、super_agent/等；

tools/：搜索、RAG、缓存等通用能力封装，列如 Bing / 微信搜索、本地 LLM 缓存等；

从技术栈上看，它是一个超级典型的“前后端分离 + 多服务后端”的架构：

前端：Next.js + React + Tailwind + Prisma(PostgreSQL)，UI 和数据持久化都在这里；
后端 Agent 层：FastAPI + A2A + Google ADK（Agent Development Kit）；
工具层：MCP(FastMCP)、RAG 工具、外部搜索工具等。

用一句不严谨但好理解的比喻：

❝

浏览器像是总控大厅，Next.js 是前台小妹，后端的多个 Python 子项目是几条不同的生产流水线，而每条流水线里又有一群各司其职的 AI 工人（Agent），负责选题、调研、写稿、质检、导出 PPT。

这一整套架构最有意思的地方在于：

它不是写死一个“大模型直接吐完所有页”的粗暴调用；
而是把“做 PPT”拆成多个环节，用不同职责的 Agent 去做；
通过 A2A + ADK 管理状态、回调与并发，让流程既可观测又可扩展。

接下来我们把几块关键模块拆开聊。

三、后端多智能体设计：从“大纲”到“每一页”的流水化 AI 生产线

3.1 四种后端模式：从入门到进阶

backend/目录下，实则提供了不同复杂度的“生成路径”：

simpleOutline/：

单 Agent，根据主题直接吐一个 Markdown 风格大纲；
不依赖外部检索、不搞并发，适合本地调试 / Demo；

simplePPT/：

在有大纲的前提下，生成结构化 PPT 正文（多为 XML 格式的结构描述）；
同样是相对线性的调用，不强调多 Agent 协作；

slide_outline/：

核心特征是 接入 MCP 检索工具；
前置需要通过 FastMCP 启动 mcpserver/rag_tool.py，实现外部资料检索 + 摘要；
生成的大纲不再是拍脑袋式的“主观胡编”，而是基于检索结果的“半 RAG 风格”内容；

slide_agent/：

真正的“主角”模块，多智能体并发调研 + 汇总 + 每页 PPT 内容写作；
可以看成对上面几种模式的全量升级版本。

这几层结构很像你给新手同事安排任务：

先学会“不查资料也能写个勉强能看的大纲”（simpleOutline）；
再学会“把大纲展开成每一页 PPT 内容”（simplePPT）；
然后开始“学会先查资料再写大纲”（slide_outline）；
最后才是“多线程并行查资料＋写每一页内容＋自检质检”（slide_agent）。

3.2 slide_outline：带检索的大纲 Agent

backend/slide_outline的 README 把流程说得很清楚：

先根据 mcp_config.json启动一个 FastMCP SSE 服务：

cd backend/slide_outline
fastmcp run --transport sse mcpserver/rag_tool.py

然后启动主 API：

python main_api.py
# 或指定模型
python main_api.py --provider deepseek --model deepseek-chat

通过 a2a_client.py发起请求，Agent 会：

拿到类似“我想调研电动汽车发展”的自然语言需求；
通过 MCP 工具进行多轮 DocumentSearch；
把检索结果汇总、抽象，最后吐出一个 Markdown 或 JSON 结构的大纲。

示例结果大致长这样（简化版）：

# 电动汽车发展概述
- 电动汽车的定义与分类
- 发展历程
- 优势与劣势

# 技术发展
- 电池技术
- 电机技术
- 电控技术
- 充电技术

# 市场分析
...

这里的关键点在于：

Agent 不再是“凭感觉生成大纲”，而是 有检索、有引用依据；
背后通过 ADK 的回调机制，把搜索工具的调用过程、文档 ID、元数据都串联在一起，方便后续调试和排错；
大纲本身被设计成结构化文本（标题 + 子点），超级适合后续再次加工，列如交给 slide_agent 做拆分和写作。

3.3 slide_agent：多智能体并发生成 PPT 内容

backend/slide_agent则是整套系统里最“有故事性”的一部分，它实现了 README 里那张美丽的 Mermaid 流程图：

当 PPT 也开始“自己写自己”：一个多智能体系统从想法到整套演示稿的完整落地实践

从代码结构看：

slide_agent/agent.py：多 Agent 管理与调度；
slide_agent/config.py：不同 Agent 使用哪个模型、什么参数；
slide_agent/create_model.py：根据配置创建模型实例（可以是 OpenAI、DeepSeek、Gemini 等）；
slide_agent/sub_agents/：

split_topic/agent.py：负责把大纲拆成多个 topic；
research_topic/agent.py + tools.py：对每个 topic 做检索 / RAG 调研；
summary_writer/agent.py：把多个 topic 的研究结果整理为一页或多页幻灯片内容；

真正有意思的是：

这些 Agent 不是“排队挨个慢慢来”，而是 通过 A2A / ADK 并发执行；
每个 Research Agent 会独立发起 DocumentSearch，然后结构化输出；
Summary Agent 再进行汇总，保证每页 PPT 是相对自洽的小闭环内容。

3.4 Loop PPT Agent + Check Agent：不是“一次性吐完”，而是“写一页，审一页”

这实则是一个很实用的工程 trade-off：

让大模型一次性吐完 30 页 PPT， 超级考验上下文长度和稳定性；
更好的做法是：

把大纲拆成一个个 page-level 的任务；
对每一页单独调用“写作 Agent”；
再加一个“检查 Agent”来做结构校验、关键字段检查甚至风格一致性检查；
不通过就重试，最多 N 次；

这样做有几个好处：

自然绕过了单次调用 token 限制；
某几页翻车不会拖垮整套 PPT，可单页重试；
可以在每一页的元数据里记录更多调试信息（列如引用了哪些文档 ID、使用了哪些图片 query）。

你在 save_ppt/里会看到后端还提供了一个 Python 脚本，利用python-pptx把前端 JSON / XML 结构渲染成真正的 PPTX 文件，这也是工程上超级关键的一步：

❝

前端只关心“结构化内容”，导出就交给统一的后端渲染，这样前端完全不需要跟 PPTX 格式细节死磕。

四、前端：一个会“看懂 XML+JSON 的 Gamma 风格 PPT 工厂”

如果说后端是一群 AI 打工人，那么 frontend/就是他们的 showroom。

4.1 技术选型与项目骨架

前端是一个标准的 Next.js 14（App Router）项目：

UI：React + Tailwind CSS；
数据层：Prisma + PostgreSQL（用 Docker 快速起一个本地库）；
文本编辑：Plate Editor + ProseMirror；
UI 组件：Radix UI + 自建组件库；
认证部分在原仓库上被简化成默认用户（方便本地直接玩）。

核心交互路径聚焦在 src/components/presentation：

dashboard/PresentationGenerationManager.tsx：

管理从用户输入主题到大纲生成、编辑再到 PPT 生成的完整流程；
通过 /api/presentation/outline与后端大纲服务对接；

outline/*：

承载 AI 生成的大纲展示与编辑能力；
支持用户在正式生成 PPT 前对结构做二次加工；

editor/*：

对已经生成的 PPT 内容进行可视化编辑，支持文本修改、样式调整等；

theme/*：

管理不同主题风格（配色、排版、字体等），有点类似 Gamma 的“模板系统”。

4.2 与多 Agent 后端对接：SSE + 自定义解析器

README 里给了一个超级典型的示例：

// src/components/presentation/utils/parser.ts
// 里面有一个 parseChunk 函数

后端的返回不是“一坨 JSON 一次性给完”，而是通过类似 LangChain / ADK 风格的流式输出，前端需要做几件事情：

以 SSE（Server-Sent Events）的方式持续接收片段；
每来一块调用 parseChunk，把文本碎片、状态更新、结构化字段拆出来；
对于 XML/自定义标记语言（如）做增量拼接与校验；
渲染成可编辑的可视化页面。

项目中有一段超级典型的“自定义数据流”示例（模拟后端输出）：

async function* customTextStream {
const lines = example_ppt.split('
');
for (const line of lines) {
yield line;
awaitnewPromise(resolve => setTimeout(resolve, 500));
}
}

exportasyncfunction POST(req: Request) {
const stream = iteratorToStream(customTextStream);
return LangChainAdapter.toDataStreamResponse(stream);
}

这里的精髓在于：

前端不在意底层到底是哪个大模型、是 ADK 还是 LangChain；
只要服务端能按照约定的“分片协议”源源不断吐数据，前端就能渐进式渲染；
这给后续替换模型、替换 Agent 框架留出了超级大的余地。

4.3 数据落地：不仅能“看”，还能“存得住”

Prisma 负责把演示文稿相关的数据结构落在 PostgreSQL 中，一般包括：

用户表（当前用的是一条固定 Admin 账号）；
Presentation / Slide / Outline 相关表：

标题、主题、创建时间、使用的 Agent 配置等；
每一页幻灯片的结构化 JSON / XML 片段；
下载历史与导出记录。

这一层做得好的直接收益是：

你可以像产品一样管理“最近的 PPT”；
可以针对某个旧的演示稿做“再生成 / 增量修改”；
可以统计最常用主题、最常用 Agent 配置，为下一步做 SaaS 化打基础。

五、从一次请求看完整调用链：一套 PPT 是怎么被“造”出来的？

我们用一个具体链路把整个系统串起来：

❝

用户在前端输入：“请帮我做一份《电动汽车发展概述》的 PPT，10 页左右。”

5.1 前端：生成大纲

前端把主题、语言、页数等信息封装为 JSON，通过 /api/presentation/outline发给后端（可以是 simpleOutline 或 slide_outline）；
如果使用 slide_outline：

后端将请求转为 A2A 格式的 message；
交给基于 ADK 的 Outline Agent；
Agent 再通过 MCP 调用 RAG 工具，检索电动车相关报告 / 统计；
把多轮检索到的摘要组合成结构化大纲；

前端通过 EventSource式流不断收到大纲片段，parseChunk逐步拼出完整大纲；

用户可以在前端 UI 里对每一节标题 / 要点进行修改。

5.2 后端：大纲拆分 & 主题并行调研

当用户点击“生成 PPT 内容”时：

前端把大纲（一般是 Markdown 或 JSON）发给 slide_agent的main_api.py；
在 slide_agent/agent.py中：

通过 tools.py里的搜索工具（可以是 Bing / RAG / MCP）；
每个 Agent 聚焦一个子问题，生成结构化研究报告；

第一调用 split_topic子 Agent，把大纲拆成多个 topic（有 ID、标题、描述、研究重点等字段）；
然后对每个 topic 启动一个 research_topicAgent：
整个过程是并发执行的，节约大量等待时间。

5.3 后端：Summary / PPT Agent 写出每一页

研究结果准备好后来，会进入“汇总 + 写 PPT 内容”的阶段：

Summary Agent 把所有 topic 的研究结果整合为“全局理解”；
Loop PPT Agent 按照大纲的章节逐页生成：

每一页生成的内容一般是类似 XML-like 的结构：

SECTION layout="left">
H2>电池技术现状H2>
BULLETS>
DIV>
H3>能量密度H3>
P>......P>
DIV>
...
BULLETS>
IMG query="现代电动汽车电池组剖面图" />
SECTION>

或者是一段包含的完整 XML；

Check Agent 对页面内容做结构和质量检查：

是否有标题、正文、至少一个要点？
是否有合适的图片 query？
是否满足长度限制（太水或太长都不行）？

不通过则触发重试逻辑（最多 3 次），通过才继续下一页；

整个写作 / 检查 / 重试过程的状态，会以流的形式同步给前端，前端可以展示“第 n 页：写作中 / 检查中 / 重试中 / 通过”等状态。

5.4 导出：从结构化 JSON/XML 到真正的 PPTX

当所有页面内容都准备好后，数据会被持久化到 PostgreSQL，同时可以调用 save_ppt/里的 API：

读取前端 JSON/XML 描述；

使用 python-pptx逐页创建幻灯片；

应用对应页面布局（标题页、左右图文、时间线、列表、对比等）；

根据

替换为真实图片地址（该部分可以接第三方图像生成服务，项目已预留接口）；最终生成 .pptx文件并返回下载链接。

到这里，一套完整的 PPT 就从“一个自然语言需求”一路生成落地了。

六、工程设计中的几个有价值的“套路”

这套项目除了“能用”，更值得借鉴的是它在工程设计上的一些取舍。

6.1 用多 Agent 拆问题，而不是把一切推给大模型

许多人第一次写“生成 PPT”的 Demo 时，写法类似：

❝

Prompt：请你帮我按照以下要求，一次性输出 20 页 PPT 内容……

这种写法最大的问题是：

token 爆炸、上下文丢失、格式极难稳定；
一旦中途模型“走神”，后面内容基本废了；

MultiAgentPPT 采用的是“流水线式拆解”：

大纲 Agent：只负责提炼结构；
拆分 Agent：只负责拆解任务；
Research Agent：只负责查资料、总结；
Summary / PPT Agent：只负责写每一页；
Check Agent：只负责质量把控与重试。

这种拆分思路带来的不止是“稳定性提升”，还有：

可以超级方便地 插拔 Agent（列如替换 Research Agent 的数据源）；
单个 Agent 的 prompt 更短、更清晰、更易调优；
agent 间传递的是结构化结果（JSON/XML），而不是乱七八糟的长文本。

6.2 MCP + RAG：把“检索”做成可替换的插件

在 slide_outline和slide_agent里，你会看到 MCP 相关配置：

mcp_config.json决定了可以调用哪些工具，例如本地文档库、网络搜索、企业知识库等；
fastmcp run ...把这些工具以 SSE server 的形式暴露出来；
Agent 在运行过程中，通过工具调用拿到检索结果，并把涉及的文档 ID 放进 metadata；

这个设计的好处是：

你可以很轻松地接企业内部的知识库 / 报表系统；
模型层与数据源层解耦，迁移到别的 LLM 提供商也不会太痛；
元数据链路清晰，方便后续做可解释性和审计。

6.3 元数据流转：从客户端到工具再回到客户端

在 simpleOutline/README.md中有一段专门讲 metadata 流动的说明，超级值得一看：

客户端在 payload 里携带 metadata（列如user_data、业务 ID 等）；
adk_agent_executor.py里把 metadata 存进 session state；
Agent 回调（before/after model callback）中都能拿到这个 state；
工具层可以在 state 上继续追加数据，列如 tool_document_ids；
最终在客户端接收到的 artifact 中，metadata 会完整带回：
```
"metadata": {
"user_data": "hello",
"tool_document_ids": [0, 1, 2, 3]
}
```

这意味着：

你可以很方便地做“端到端链路追踪”：某个 PPT 是基于哪些文档生成的；
也给后续的安全审计、数据权限管理预留了空间。

6.4 分层服务化：simple* 系列的工程价值

simpleOutline/simplePPT的存在看起来像“缩小版”，但工程意义很大：

它们是最小可用 Demo，适合作为“本地测试 / 教学示例”；
真正出问题时，你可以先打 simple 版，确认问题是 Agent 流程还是外部检索；
新人接手项目时，从 simple* 入手要远比直接啃 slide_agent 轻松许多。

这种“提供不同层级复杂度实现”的习惯，超级值得在自己的项目里学习照抄。

七、适用场景：这套系统什么时候真能帮你省时间？

7.1 日常工作场景

把一周 / 一月的工作纪要 + Issue 列表 + Meeting Notes 喂给 Agent；
让系统帮你先产出结构化的大纲，然后逐页生成 PPT 内容；
你只需要在前端做最后的改写和数据替换。

行业研究 / 市场分析 PPT

例如“电动汽车市场概述”“AIGC 行业格局分析”；
搭配企业内部 RAG 知识库，能生成相当像样的“第一版 PPT 草稿”；
人可以主要精力放在观点修正与数据核对，而不是纯手工堆字。

产品宣讲 / 内部培训

输入产品文档或功能说明书，指定目标受众（技术 / 销售 / 客户）；
让 Agent 用不同语言风格和深度自动“翻译”成对应受众看的 PPT。

7.2 更“重”的企业级场景

给一个客户行业 + 目标产品 + 标准模板；
系统自动根据 CRM 中的客户信息、过往案例库生成销售 PPT；

定期报告自动化：

财报、运营报表、数据看板本身就是结构化数据；
MultiAgentPPT 可以做的是 把数据“讲出来”，而不是只是画图。

培训资料的多版本复用：

同一个课程内容，为不同业务线、不同国家、不同语言输出不同版本 PPT；
不再需要一个人反复 copy&paste + 改措辞。

7.3 什么时候不太适合用？

也很坦诚地说，这套系统也不是“万能按钮”：

如果你要做的是 极高创意要求的 keynote（列如发布会主 Keynote），人类的故事设计和审美判断目前还是不可替代；
如果你的内容 需要极严谨的数据和法律合规，那么 Agent 输出只能作为草稿，必须有人类逐条核对数据来源；
如果你只有一句超级模糊的需求（列如“帮我做个有点酷炫的 PPT”），模型也很难真正做到“读心术”。

但在绝大多数“信息型、结构化” PPT 里，它能帮你节省的时间是量级上的：从原来一整天写稿 + 排版，变成几个小时的验证和润色。

八、如何快速在本地跑起来？（含命令清单）

下面给一套相对贴心、一步一脚印的本地体验指引（Windows 环境同样适用，只是命令行工具不同）。

8.1 启动后端环境（Python）

conda create --name multiagent python=3.12
conda activate multiagent

cd backend
pip install -r requirements.txt

cd backend/simpleOutline && cp env_template .env
cd ../simplePPT && cp env_template .env
cd ../slide_outline && cp env_template .env
cd ../slide_agent && cp env_template .env

根据自己使用的模型服务，修改对应目录下的 .env（API Key、Base URL 等）。
启动大纲服务：

# 方案一：简单大纲
cd backend/simpleOutline
python main_api.py # 默认端口 10001

# 方案二：带检索的大纲
cd backend/slide_outline
fastmcp run --transport sse mcpserver/rag_tool.py
python main_api.py # 同样监听 10001

# 简单 PPT 生成
cd backend/simplePPT
python main_api.py # 默认端口 10011

# 多 Agent 并发 PPT 生成
cd backend/slide_agent
python main_api.py # 同样监听 10011

❝

注意：slide_outline与simpleOutline、slide_agent与simplePPT端口是共用的，不要同时启两个在同一端口。

8.2 启动前端（Next.js）

docker run --name postgresdb -p 5432:5432 
-e POSTGRES_USER=postgres 
-e POSTGRES_PASSWORD=welcome -d postgres

cd frontend
cp env_template .env

重点变量：

DATABASE_URL="postgresql://postgres:welcome@localhost:5432/presentation_ai"
A2A_AGENT_OUTLINE_URL="http://localhost:10001"
A2A_AGENT_SLIDES_URL="http://localhost:10011"
DOWNLOAD_SLIDES_URL="http://localhost:10021"