PaiAgent：一个面向 AI 播客生成的可视化工作流编辑与执行平台

这篇文章记录了我近期完成的一个个人项目 PaiAgent。它是一个围绕 AI 工作流编排 展开的实践型项目，目标是通过可视化拖拽的方式，把“大模型生成内容 + 语音合成”串成一条完整链路，最终实现 AI 播客内容的一键生成。

一、项目背景

随着大语言模型能力越来越强，AI 应用的重心也逐渐从“单轮对话”转向“流程编排”。很多时候，真正有价值的并不是让模型只回答一句话，而是让它能够在一个明确的业务流程中，完成内容生成、结果加工、格式转换以及最终输出。

我在做这个项目时，思考的核心问题是：

能不能做一个足够轻量、足够直观的平台，把 AI 的能力以工作流的方式组织起来，并且直接落地到一个具体场景中？

基于这个想法，我实现了 PaiAgent。它本质上是一个 AI Agent 工作流编辑与执行平台，用户可以通过拖拽节点的方式，自定义一条完整的 AI 执行链路，并在前端界面中直接完成调试与运行。

而我为这个项目选择的第一个核心场景，就是 AI 播客生成。

简单来说，这条工作流可以抽象为：

用户输入文本 -> 大模型节点处理 -> TTS 语音合成节点 -> 输出音频结果

相比单纯的文本生成，这种流程更接近一个真实可用的 AI 应用：输入的是需求，输出的是可以直接播放的音频内容。

二、项目介绍

2.1 项目定位

PaiAgent 是一个偏工程实践导向的项目，主要目标不是做一个“功能特别庞大”的平台，而是围绕 可视化编排、节点执行、结果调试、音频输出 这几个核心能力，搭建出一个可运行、可扩展、可继续迭代的 MVP 系统。

这个项目更关注以下几个点：

1. 可视化：降低工作流编排门槛，让流程定义更直观。

2. 模块化：把输入、LLM、TTS、输出等环节抽象成独立节点。

3. 可执行：不仅能画流程，还能真正运行并返回结果。

4. 场景落地：不只停留在概念验证，而是能直接服务于 AI 播客生成这样的具体应用。

2.2 核心场景

目前项目聚焦的场景是 AI 播客生成。

用户可以先输入一段原始文本，例如新闻摘要、知识讲解稿、产品介绍或者个人随笔，然后通过 LLM 节点进行改写、润色或者扩写，再把生成后的文本交给 TTS 节点进行语音合成，最终输出成可播放的音频文件。

这条链路的价值在于，它把原本割裂的几个步骤串联起来了：

• 文本输入

• LLM 内容生成或改写

• 语音合成

• 音频返回与播放

也就是说，PaiAgent 并不是单独做“聊天”，而是把 AI 能力组织成一条完整的业务流水线。

2.3 项目地址

GitHub 仓库地址：

https://github.com/lwh-Labs/PaiAgent

三、技术架构

从整体实现来看，PaiAgent 采用的是比较清晰的前后端分离架构。

3.1 前端技术栈

前端部分主要负责工作流编辑、节点拖拽、参数配置、调试运行以及结果展示，使用的技术包括：

• React 18：负责整体界面构建

• TypeScript：提升类型安全与工程可维护性

• Vite：提供更快的开发体验与构建效率

• React Flow v11：实现可视化节点编排与连线能力

• Ant Design：用于构建后台风格的交互界面

其中，React Flow 是整个前端体验的核心。借助它，我可以比较自然地实现节点拖拽、连线、删除、位置调整等能力，也让工作流编辑器从“普通表单页面”升级成了更贴近实际生产工具的交互模式。

3.2 后端技术栈

后端主要负责工作流管理、节点执行、API 集成、执行结果持久化以及音频文件访问，技术选型如下：

• Spring Boot 3.x

• Java 17

• Spring Data JPA

• MySQL 8.x

在后端设计中，我实现了一个轻量级的 DAG 工作流引擎。因为工作流本质上就是一张有向图，所以在执行阶段，需要解决几个关键问题：

• 节点的依赖关系如何组织

• 节点的执行顺序如何确定

• 是否存在循环依赖

• 每个节点的输入输出如何传递

这部分的实现虽然不算复杂，但它是整个系统真正“跑起来”的基础。

3.3 AI 能力接入

在模型和工具层，PaiAgent 主要集成了两类能力：

（1）大模型能力

目前支持通过统一节点方式调用以下模型提供方：

• OpenAI

• DeepSeek

• 通义千问

在实际使用时，LLM 节点可以承担多种职责，例如：

• 文本扩写

• 文案润色

• 摘要生成

• 风格改写

• 播客口播稿生成

（2）语音合成能力

在音频输出部分，我接入了 阿里云 CosyVoice，用于完成文本到语音的转换。

相比传统“只输出文本”的 AI 系统，TTS 节点的加入让整个项目更像一个完整应用，而不是一个简单的模型调用 Demo。用户在执行完成后，可以直接获得音频结果，并在调试面板中进行播放。

四、项目结构设计

为了让项目保持清晰、易扩展，我把整体结构划分为前后端两个主要部分：

PaiAgent/
├── backend/              # Spring Boot 后端项目
│   ├── src/main/java/com/paiagent/
│   │   ├── controller/   # REST API 接口
│   │   ├── engine/       # DAG 工作流引擎核心
│   │   ├── entity/       # JPA 实体类
│   │   ├── service/      # 业务逻辑
│   │   └── ...
│   ├── src/main/resources/
│   │   ├── application.yml
│   │   └── schema.sql
│   └── pom.xml
├── frontend/             # React 前端项目
│   ├── src/
│   │   ├── components/   # 页面与组件
│   │   ├── api/          # API 封装
│   │   ├── hooks/        # 自定义 Hooks
│   │   └── types/        # TypeScript 类型
│   └── package.json
└── README.md

这样的结构划分有几个明显好处：

• 前后端职责清晰，便于独立开发与调试

• 后端引擎与业务逻辑解耦，方便后续扩展新的节点类型

• 前端组件、接口、类型分层明确，便于维护

五、核心功能实现

5.1 可视化工作流编辑器

PaiAgent 的核心入口就是工作流编辑器。

在这个编辑器中，用户可以从左侧节点面板中拖出所需节点，然后在中间画板中完成流程搭建。当前已经支持以下几类节点：

• START 节点：工作流起始节点，用于接收用户输入

• LLM 节点：调用大模型接口进行文本处理

• TTS 节点：调用语音合成服务生成音频

• END 节点：工作流终止节点，用于输出最终结果

这种设计其实对应了一条非常经典的 AI 应用流程：

输入 -> 推理处理 -> 工具执行 -> 输出结果

从开发者视角看，这种节点化抽象也为后续扩展更多能力留出了空间。例如后面如果继续迭代，就可以加入：

• 条件分支节点

• 循环节点

• HTTP 请求节点

• 文件处理节点

• 知识检索节点

5.2 节点配置能力

单纯把节点拖到画布上还不够，真正决定工作流行为的是“节点配置”。

因此我在前端中设计了节点参数抽屉，点击某个节点后可以打开配置区域，对不同类型节点填写对应参数。

例如在 LLM 节点 中，可以配置：

• provider

• model

• apiKey

• systemPrompt

• temperature

• maxTokens

而在 TTS 节点 中，则可以配置：

• apiKey

• voiceId

• speed

• pitch

这样一来，工作流不再只是静态结构图，而是真正具备“可运行逻辑”的执行图。

5.3 工作流执行与调试

为了让整个平台更接近真实开发体验，我加入了调试执行能力。

在调试面板中，用户可以：

1. 输入测试文本

2. 点击运行工作流

3. 查看节点执行状态

4. 查看中间输出结果

5. 在音频生成完成后直接播放结果

这个功能很关键，因为它把“设计流程”和“验证流程”放在了同一个界面中，大幅降低了调试成本。

很多 AI 项目在演示时看起来很完整，但一到实际联调阶段就会暴露出大量问题，比如参数不一致、节点输出格式不统一、执行顺序出错等。调试面板的存在，本质上就是为了缩短这部分问题的定位路径。

5.4 工作流管理接口

后端还提供了一套比较完整的 REST API，用于支撑工作流的创建、查询、更新、删除以及执行。

工作流管理

• GET /api/workflows：获取工作流列表

• GET /api/workflows/{id}：获取工作流详情

• POST /api/workflows：创建工作流

• PUT /api/workflows/{id}：更新工作流

• DELETE /api/workflows/{id}：删除工作流

工作流执行

• POST /api/workflows/{id}/execute：执行工作流

• GET /api/executions/{executionId}：获取执行记录

• GET /api/workflows/{id}/executions：获取执行历史

音频访问

• GET /api/audio/{filename}：获取音频文件

这些接口为前端工作流编辑器和调试面板提供了基础支撑，也让后续与其他系统集成成为可能。

六、项目亮点

结合当前版本来看，我认为 PaiAgent 有几个比较明显的亮点。

6.1 从“模型调用”走向“流程编排”

很多初学者做 AI 项目时，往往停留在“调用一下 API，返回一段文本”的层面。但从真实应用来看，更有价值的是把多个环节组织起来，让 AI 参与完整流程。

PaiAgent 尝试做的，正是把单点能力提升为流程能力。

6.2 选取了更有落地感的播客场景

相比单纯做聊天机器人，AI 播客生成 这个方向更贴近内容生产实际需求。

它同时涉及：

• 文本生成

• 语言风格控制

• 音频合成

• 结果播放与交付

这也让项目不只是“能跑”，而是具备明确的应用想象空间。

6.3 架构足够轻量，便于继续扩展

这个项目目前仍然是一个 MVP 版本，但基础骨架已经搭好了。无论是前端节点类型扩展，还是后端执行引擎增强，都有比较明确的演进路径。

对于个人开发者来说，这种“先搭出核心框架，再逐步扩展功能”的方式，往往比一开始就追求大而全更有效。

七、项目中遇到的思考

在做 PaiAgent 的过程中，我越来越明显地感受到：

AI 应用开发的重点，已经不再只是“模型够不够强”，而是“如何把模型能力编排成一个可交付的系统”。

一个真正可用的 AI 系统，往往离不开下面几个方面：

• 明确的输入输出结构

• 稳定的执行链路

• 易于调试的可视化界面

• 能够扩展更多工具能力的架构设计

也正因为如此，我没有把这个项目只当成一次简单的接口调用练习，而是更希望把它做成一个具有工程完整性的作品。

它未必已经很成熟，但至少在“从 0 到 1”这一步上，把关键链路完整跑通了。

八、目前版本的不足

当然，当前版本还有不少可以继续完善的地方。

例如：

• 目前更偏向单用户使用，暂时没有完整的权限体系

• 工作流版本管理能力还不够完善

• 节点并行执行能力还没有加入

• 节点类型仍然偏少，复杂流程表达能力有限

• 实时推送和更细粒度的执行监控还有提升空间

这些问题并不意外，因为当前版本本身就是一个 MVP。对我来说，更重要的是先把基础闭环搭建出来，再逐步往“更强的执行引擎”和“更丰富的节点生态”推进。

九、后续计划

接下来如果继续迭代 PaiAgent，我比较希望往以下几个方向推进：

1. 增加更多节点类型，例如条件分支、循环、HTTP 请求、知识检索等。

2. 完善执行引擎，支持更复杂的依赖关系与并行执行。

3. 增强可观测性，把节点执行日志、耗时、失败原因展示得更清晰。

4. 支持多用户与权限管理，让它从个人项目进一步靠近真正的平台化产品。

5. 扩展更多应用场景，例如 AI 内容生产、自动化报告生成、知识整理、智能客服流程等。

如果这些能力逐步补齐，那么 PaiAgent 就不仅仅是一个“AI 播客 Demo”，而会成长为一个更通用的 AI 工作流平台。

十、总结

总体来说，PaiAgent 是我围绕 AI 工作流编排与内容生成场景做的一次完整工程实践。

它让我真正把以下这些能力串联了起来：

• 前端可视化工作流编辑

• 后端 DAG 执行逻辑

• 大模型能力接入

• TTS 音频生成

• 调试执行与结果回放

从结果上看，这个项目已经完成了一个比较完整的最小可用闭环：

用户输入内容 -> 系统自动处理 -> 生成可播放音频 -> 返回结果

对我个人而言，PaiAgent 的意义不仅在于做出了一个项目，更在于通过这个项目进一步理解了 AI 应用从“能力调用”走向“系统编排”的过程。

后面如果有新的迭代成果，我也会继续整理并更新到博客里。

附：运行环境要求

如果你也想在本地运行这个项目，可以先准备以下环境：

• Java 17+

• Maven 3.8+

• Node.js 18+

• MySQL 8.0+

项目启动流程也比较直接：

1. 初始化数据库

2. 配置后端 application.yml

3. 启动 Spring Boot 后端

4. 安装前端依赖并运行前端项目

如果后续我有时间，也会把这个项目进一步整理成更完整的部署文档与使用说明。

项目仓库： https://github.com/lwh-Labs/PaiAgent