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

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

  • 领导一句“明天给我一份 XX 方向的 PPT”，你默默看了一眼时间——23:07；

  • 打开 PowerPoint，对着空白第一页发呆十分钟，连目录都写不出来；

  • 网上搜的 PPT 模板看上去光鲜亮丽，但内容还得自己肝。

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

  1. 你只需要输入一个主题，比如“电动汽车发展概述”。

  2. 系统先帮你生成可编辑的大纲。

  3. 你确认或修改后，它会自动拆成多个子 Topic。

  4. 一群并行工作的 Research Agent 去做资料检索和内容整理。

  5. Summary / PPT Agent 把这些研究结果汇总成每一页 PPT 的结构化内容，还支持流式实时返回给前端。

  6. 最后再结合模板，可以一键导出 pptx 文件。

一句话概括：这是一个“从一句话题目到一套可编辑 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 内容写作；

    • 可以看成对上面几种模式的全量升级版本。

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

  1. 先学会“不查资料也能写个勉强能看的大纲”（simpleOutline）；

  2. 再学会“把大纲展开成每一页 PPT 内容”（simplePPT）；

  3. 然后开始“学会先查资料再写大纲”（slide_outline）；

  4. 最后才是“多线程并行查资料＋写每一页内容＋自检质检”（slide_agent）。

3.2 slide_outline：带检索的大纲 Agent

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

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

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

  2. 然后启动主 API：

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

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

    • 拿到类似“我想调研电动汽车发展”的自然语言需求；

    • 通过 MCP 工具进行多轮 DocumentSearch；

    • 把检索结果汇总、抽象，最后吐出一个 Markdown 或 JSON 结构的大纲。

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

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

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

# 市场分析
...

这里的关键点在于：

  • Agent 不再是“凭感觉生成大纲”，而是有检索、有引用依据；

  • 背后通过 ADK 的回调机制，把搜索工具的调用过程、文档 ID、元数据都串联在一起，方便后续调试和排错；

  • 大纲本身被设计成结构化文本（标题 + 子点），非常适合后续再次加工，比如交给 slide_agent 做拆分和写作。

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

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

flowchart TD
		A[大纲生成 Agent] --> B[Topic 拆分 Agent]
		B --> C1[Research Agent 1]
		B --> C2[Research Agent 2]
		B --> C3[Research Agent N]
		C1 --> D[Summary Agent 汇总输出]
		C2 --> D
		C3 --> D
		D --> E[实时流式返回前端]

从代码结构看：

  • 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：不是“一次性吐完”，而是“写一页，审一页”

在主 README 的流程图里，还有一个关键设计：

subgraph Loop PPT Agent
		L1[Write PPT Agent\n生成每页幻灯片]
		L2[Check PPT Agent\n检查每页内容质量，最多重试 3 次]
		L1 --> L2
		L2 --> L1
end

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

  • 让大模型一次性吐完 30 页 PPT，非常考验上下文长度和稳定性；

  • 更好的做法是：

    • 把大纲拆成一个个 page-level 的任务；

    • 对每一页单独调用“写作 Agent”；

    • 再加一个“检查 Agent”来做结构校验、关键字段检查甚至风格一致性检查；

    • 不通过就重试，最多 N 次；

这样做有几个好处：

  1. 自然绕过了单次调用 token 限制；

  2. 某几页翻车不会拖垮整套 PPT，可单页重试；

  3. 可以在每一页的元数据里记录更多调试信息（比如引用了哪些文档 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 风格的流式输出，前端需要做几件事情：

  1. 以 SSE（Server-Sent Events） 的方式持续接收片段；

  2. 每来一块调用 parseChunk，把文本碎片、状态更新、结构化字段拆出来；

  3. 对于 XML/自定义标记语言（如 <PRESENTATION>...</PRESENTATION>）做增量拼接与校验；

  4. 渲染成可编辑的可视化页面。

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

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

export async function 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 前端：生成大纲

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

  2. 如果使用 slide_outline：

    • 后端将请求转为 A2A 格式的 message；

    • 交给基于 ADK 的 Outline Agent；

    • Agent 再通过 MCP 调用 RAG 工具，检索电动车相关报告 / 统计；

    • 把多轮检索到的摘要组合成结构化大纲；

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

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

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

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

  1. 前端把大纲（通常是 Markdown 或 JSON）发给 slide_agent 的 main_api.py；

  2. 在 slide_agent/agent.py 中：

    • 首先调用 split_topic 子 Agent，把大纲拆成多个 topic（有 ID、标题、描述、研究重点等字段）；

    • 然后对每个 topic 启动一个 research_topic Agent：

      • 通过 tools.py 里的搜索工具（可以是 Bing / RAG / MCP）；

      • 每个 Agent 聚焦一个子问题，生成结构化研究报告；

    • 整个过程是并发执行的，节约大量等待时间。

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

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

  1. Summary Agent 把所有 topic 的研究结果整合为“全局理解”；

  2. Loop PPT Agent 按照大纲的章节逐页生成：

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

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

    • 或者是一段包含 <PRESENTATION>...</PRESENTATION> 的完整 XML；

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

    • 是否有标题、正文、至少一个要点？

    • 是否有合适的图片 query？

    • 是否满足长度限制（太水或太长都不行）？

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

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

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

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

  • 读取前端 JSON/XML 描述；

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

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

  • 根据 <IMG query="..." /> 替换为真实图片地址（该部分可以接第三方图像生成服务，项目已预留接口）；

  • 最终生成 .pptx 文件并返回下载链接。

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

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

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

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

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

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

这种写法最大的问题是：

  • token 爆炸、上下文丢失、格式极难稳定；

  • 一旦中途模型“走神”，后面内容基本废了；

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

  1. 大纲 Agent：只负责提炼结构；

  2. 拆分 Agent：只负责拆解任务；

  3. Research Agent：只负责查资料、总结；

  4. Summary / PPT Agent：只负责写每一页；

  5. 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 流动的说明，非常值得一看：

  1. 客户端在 payload 里携带 metadata（比如 user_data、业务 ID 等）；

  2. adk_agent_executor.py 里把 metadata 存进 session state；

  3. Agent 回调（before/after model callback）中都能拿到这个 state；

  4. 工具层可以在 state 上继续追加数据，比如 tool_document_ids；

  5. 最终在客户端接收到的 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 日常工作场景

  1. 周报 / 月报 / 项目复盘 PPT

    • 把一周 / 一月的工作纪要 + Issue 列表 + Meeting Notes 喂给 Agent；

    • 让系统帮你先产出结构化的大纲，然后逐页生成 PPT 内容；

    • 你只需要在前端做最后的改写和数据替换。

  2. 行业研究 / 市场分析 PPT

    • 例如“电动汽车市场概述”“AIGC 行业格局分析”；

    • 搭配企业内部 RAG 知识库，能生成相当像样的“第一版 PPT 草稿”；

    • 人可以主要精力放在观点修正与数据核对，而不是纯手工堆字。

  3. 产品宣讲 / 内部培训

    • 输入产品文档或功能说明书，指定目标受众（技术 / 销售 / 客户）；

    • 让 Agent 用不同语言风格和深度自动“翻译”成对应受众看的 PPT。

7.2 更“重”的企业级场景

  1. 销售资料自动生成：

    • 给一个客户行业 + 目标产品 + 标准模板；

    • 系统自动根据 CRM 中的客户信息、过往案例库生成销售 PPT；

  2. 定期报告自动化：

    • 财报、运营报表、数据看板本身就是结构化数据；

    • MultiAgentPPT 可以做的是把数据“讲出来”，而不是只是画图。

  3. 培训资料的多版本复用：

    • 同一个课程内容，为不同业务线、不同国家、不同语言输出不同版本 PPT；

    • 不再需要一个人反复 copy&paste + 改措辞。

7.3 什么时候不太适合用？

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

  • 如果你要做的是极高创意要求的 keynote（比如发布会主 Keynote），人类的故事设计和审美判断目前还是不可替代；

  • 如果你的内容需要极严谨的数据和法律合规，那么 Agent 输出只能作为草稿，必须有人类逐条核对数据来源；

  • 如果你只有一句非常模糊的需求（比如“帮我做个有点酷炫的 PPT”），模型也很难真正做到“读心术”。

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

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

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

8.1 启动后端环境（Python）

  1. 创建虚拟环境（推荐 Conda）：

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

  1. 安装依赖：

cd backend
pip install -r requirements.txt

  1. 为各个子模块复制环境模板：

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

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

  2. 启动大纲服务：

# 方案一：简单大纲
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

  1. 启动 PPT 内容生成服务：

# 简单 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）

  1. 本地起一个 PostgreSQL（示例命令）：

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

  1. 在 frontend/ 下创建并检查 .env：

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"

  1. 安装依赖 & 初始化数据库：

pnpm install
pnpm db:push

  1. 启动前端开发环境：

pnpm dev

  1. 在浏览器访问：

  • 大部分 demo 页面在：http://localhost:3000/presentation

接下来，你就可以像在 Gamma 或 Tome 一样：

  • 输入主题 → 生大纲 → 调大纲 → 生 PPT → 微调 → 导出 PPTX。

九、未来可以怎么玩得更花？

从目前的代码和架构来看，MultiAgentPPT 已经把一套多智能体生成 PPT 的完整闭环走通了。但它还留出了不少可以“继续折腾”的空间：

  1. 更多“角色” Agent

    • 例如：视觉设计 Agent，根据内容给出版式建议、配图风格统一建议；

    • 审核 Agent：检查是否包含敏感内容、合规风险提示；

    • 多语言对照 Agent：同一页 PPT 自动生成中英 / 多语版本。

  2. 结合日常工作流

    • 和企业 Wiki、Jira、飞书文档集成；

    • 输入只是一句“用项目 X 最近两周的进度，帮我做个复盘 PPT”。

  3. 更强的模板系统

    • 目前 XML / JSON 已经抽象出 Section / Layout / Bullets / Timeline 等组件；

    • 后续可以把“版式 + 动画 + 图标集”打包成可配置主题，通过一个简单 DSL 描述。

  4. Agent 调度策略优化

    • 现在每个 topic 基本是均匀处理；

    • 将来可以根据“信息密度 / 重要程度”为不同章节分配不同算力预算。

从更大的视角看，MultiAgentPPT 其实是一个非常典型的多 Agent 应用模板：

  • 有清晰的任务拆解；

  • 有实际可见的前端产品形态；

  • 有 debug 友好的状态流和 metadata 链路；

  • 工程结构也足够清晰。

你完全可以把它当作“多智能体项目脚手架”，复制到其他场景：报告生成、方案撰写、代码评审、运营内容排期……

十、结语：当我们讨论 PPT，其实是在讨论“知识的结构化表达”

表面上看，MultiAgentPPT 做的是“自动写 PPT”，但如果你把架构和代码走一遍，就会发现：

  • 它真正做的，是一层一层地把“知识”变成“结构”，再把“结构”变成“视觉化表达”；

  • 多 Agent 不是噱头，而是针对“做 PPT”这个复杂任务的合理任务拆解；

  • MCP / RAG / 元数据流转，则是保证这一切可控、可查、可扩展的底座。

也许将来，有一天你再打开 PPT，不再是从空白页开始，而是从一个已经七八成成型、结构合理、逻辑自洽的版本开始。而你真正需要做的，是往里注入你自己的判断和观点——这部分短时间内 AI 还替代不了。

如果你对多智能体、RAG、应用级 AI 工程化这些方向感兴趣，不妨亲自把 MultiAgentPPT 跑起来，改一改、拆一拆、接入你自己的数据源，这个过程本身，就已经是一份非常不错的“进阶实践教程”了。

更多AIGC文章

RAG技术全解：从原理到实战的简明指南

更多VibeCoding文章

更多Agent文章

Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

cover

如何快速降低AIGC痕迹？推荐5款高效降重网站

avatar 2048 AI社区
cover

Selenium vs Playwright vs Helium：2026年测试框架完全指南

avatar 2048 AI社区
cover

Air8000开发板LCD屏开发：图片、中英文显示与图形绘制全解析！

avatar 2048 AI社区