做 AI 聚合站这个项目的时候，我一开始的想法很直接：把分散的 AI 创作能力收进同一个入口，做成一个一站式平台。但随着它跑起来，我的野心也慢慢变大了——我不再满足于「调一个模型出一张图」，而是想试试看，能不能用多个 Agent 协作，自动生成一份真正可编辑的 PPT。
技术栈是 Next.js 16（App Router）加 React 19，数据库用 Prisma 接 PostgreSQL，认证用 Auth.js，UI 是 Tailwind CSS 和 shadcn/ui，校验用 Zod。它是一个有用户、有积分、有后台、有完整业务流的产品，而不只是一个玩具页面。
先把图片创作这条线跑通
聚合站最早落地的是图片创作工作台。它不是那种「输入提示词、点一下、出一张图」的单次工具，而是做成了会话式的：一个会话里可以有多轮生成，支持文生图和图生图，能看历史轮次、复用之前的提示词、继续编辑。每一轮生成会记录用了哪个上游模型、实际像素、张数、成功失败数和耗时。
围绕图片生成，我搭了一整套产品该有的东西：
- 注册登录，区分普通用户和管理员；
- 积分系统，注册赠送、生成消耗、充值、管理员调整、失败退款，每一笔都记流水；
- 充值订单、生成记录、素材库和素材广场，带收藏、点赞、举报和审核流程；
- 管理员后台，有仪表盘、用户管理、订单、系统设置、上游 API 配置，还有审计日志。
这套东西让我第一次完整地想清楚：一个 AI 平台要持续运转，不能只有生成功能，还得有计费、有审计、有运营后台。
BYOK 和三级 API 配置
图片生成涉及到「用谁的 Key」这件事，我设计了一套三级配置：用户可以在设置里填自己的 API Key（自带 Key，BYOK），启用后走自己的通道、不消耗平台积分；用户没配置就走平台管理员配的上游；再往下还有环境变量兜底。
API Key 全部用 AES-256-GCM 加密后存进数据库。这个设计让我开始认真对待「别人的密钥」这件事——它不是一段普通的配置，而是必须加密、必须可更换、必须区分归属的数据。
真正的难点：用多 Agent 生成可编辑 PPT
图片跑通之后，我给自己出了一个更难的题：能不能让多个 Agent 协作，从主题、文档或网页，自动生成一份原生可编辑的 PowerPoint？
「可编辑」是这里的关键。市面上很多 AI 做 PPT，最后给的是一张张截图拼成的幻灯片，每个页面是一整张图，不能改。我想要的是：每一个形状都能单独选中，文字能编辑，颜色能调——是一份真正的 PPT 文件，不是图片。
为了做到这一点，我复刻了一个叫 ppt-master 的多 Agent 架构。整套流程是这样的：
- 先把来源（主题、文档、网页或 Markdown）统一转成 Markdown；
- Strategist 角色进场，分析内容、规划设计风格，输出设计规范；
- Executor 角色逐页生成 SVG 幻灯片，并在页与页之间传递上下文，保持视觉一致；
- 采集配图，做 SVG 后处理；
- 最后把 SVG 转成 PPTX。
每个角色都带着一份很长的系统提示词，动态切换 persona。这让我第一次真切地体会到「多 Agent 协作」不是个 buzzword：不同角色看同一个任务，分工、传递上下文、互相校对，出来的结果比单个 Agent 一次性生成稳定得多。
Python 和 Node 的混合架构
SVG 转 PPTX 这一步，ppt-master 已经有一整套成熟的 Python 代码。我没有选择用 Node 重写，而是通过 child_process 把 Python 工具桥接进来，直接复用它全部的核心逻辑。
这是一个很务实的取舍：重写意味着重新踩坑，而桥接能让我把精力放在编排和产品化上。混合架构在工程上虽然要多管一个运行时，但换来的是稳定和速度。Node 负责 Web、数据库、编排和流式进度，Python 负责文档转换和最终的 SVG 到 PPTX 转换，各干各的擅长事。
并发、成本和退款的诚实账
PPT 生成是个又慢又贵的任务，动辄要几分钟、调十几次模型。所以我必须认真处理并发和成本：
- 全局信号量把并发控制在最多 3 个，防止触发上游限流，也防止成本失控；
- 每个用户同一时间只允许 1 个进行中的项目；
- 生成过程通过 SSE 把进度实时推给前端，让用户看到「正在分析内容」「渲染第几页」「导出 PPTX」；
- 积分采用预扣费，按目标页数扣，生成失败自动退款。
我也老老实实算过一笔账：单个项目按页数和调用次数算，在某些价格下其实是亏的。这件事提醒我，做 AI 产品不能只想着「能不能实现」，还得想清楚「这样跑下去公司亏不亏」。后来我把计费方式、并发上限都做了调整，让它至少在合理的定价下能跑得下去。
我也清楚它现在的边界
我没有假装它已经完美。这些是我现在就知道的局限：
- 并发控制是内存级的，服务一重启队列状态就没了，生产环境应该换成基于 Redis 的持久化队列；
- 文件上传入口当时还没完全接好，临时靠主题或 URL 输入兜底；
- 质量检查失败会直接报错，还没有做自动重试或人工介入；
- 积分按目标页数预扣，实际生成页数不一样时，计费不够精确。
把这些写下来，是因为我觉得一个项目诚实地承认自己哪里还没做好，比假装什么都搞定了更值钱。
我学到的东西
第一，我学到「多 Agent」真正有价值的地方是分工和上下文传递。让不同角色各司其职、互相校对，比把所有要求塞进一个超长提示词更稳。
第二，我学到混合技术栈不可怕，关键是谁擅长什么。复用成熟代码比自己重写更聪明，只要桥接层足够干净。
第三，我学到 AI 产品必须从一开始就算成本账。并发、限流、预扣费、退款、定价，这些不是上线以后才补的，而是架构的一部分。
回头看
聚合站现在是一个有图片创作、积分体系、运营后台，还能用多 Agent 生成可编辑 PPT 的平台。它离商业化还有距离，但对我来说是一次跨度很大的成长。
它让我从一个「调接口出结果」的开发者，变成一个会去想计费、并发、成本、多 Agent 编排和混合架构的人。从做功能，走向做系统；从追求「能跑」，走向追求「能持续跑下去」。这也是我做完毕业设计之后，往前迈出的很重要的一步。