一个人做AI工具聚合平台：最难的不是接API

如果让你把20个AI工具塞进同一个界面，你会先写前端还是搞后端？一个独立开发者的选择是：先解决"它们说话方式不一样"的问题。

https://onlyaitools.lovable.app/ 这个看起来简单的网站，背后是一套关于"如何让不同AI和平共处"的工程实验。作者没打算做产品，只想回答一个问题：统一调度多个AI服务，瓶颈到底在哪？

为什么要造这个"中间层"

直接调用OpenAI、Claude、Midjourney的API不就行了？这是大多数人的第一反应。

但作者的实际体验是：每个服务商返回的数据结构完全不同。有的用嵌套JSON，有的混着文本和元数据，有的连错误码格式都不统一。前端如果直接对接，代码会迅速变成"if-else地狱"。

他的解法是做一层"翻译器"——规范化层（normalization layer）。所有外部API的响应先在这里被转换成统一的内部格式，再交给UI渲染。

代价很明显：后端复杂度飙升。但收益也实在：前端可以稳定复用同一套组件，换供应商时改配置就行，不用重写页面逻辑。

这种设计在软件工程里叫抽象层，但AI时代的特殊之处在于：输出内容的不可预测性让"规范化"本身成了动态问题。同样请求"总结这段文字"，GPT-4可能返回带markdown的段落，Claude可能拆成 bullet points，某个开源模型可能直接丢给你未格式化的原始文本。

200毫秒 vs 5秒： latency的残酷现实

多工具聚合的第二个坑，是速度的不对等。

作者实测：不同API响应时间在200毫秒到数秒之间波动，取决于负载和模型大小。这带来一个UX难题——用户点了按钮，有的结果秒出，有的要转圈半天。

他的应对策略是两招：缓存（对重复请求直接返回历史结果）和部分渲染（先展示已返回的内容，不等慢的那个）。

但这引出一个更深的问题：当系统需要串联多个AI完成任务时，最慢的那个节点会拖垮整条链路。比如先让A模型提取关键词，再让B模型生成摘要，如果A花了4秒，B再快也没用。

并行执行是理论解，但现实中很多任务有依赖关系。作者没给出完美答案，只是记录了真实的权衡：响应速度和功能复杂度，只能二选一。

中心化架构的隐忧

整个项目做完，作者的核心结论有点反直觉：最难的不是"怎么连上每个AI"，而是"怎么设计一个干净的抽象层，同时不引入过多开销"。

这背后是一个行业级追问。现在的AI工具聚合，本质上是"用户选工具→系统调API"的中心化模式。但作者怀疑，这种模式可能不是终局。

他提到的替代方向是"智能体架构"（agent-based models）：系统自己判断该用什么工具，用户不需要在界面层做显式选择。这有点像从"手动换挡"进化到"自动驾驶"。

区别很微妙。现在的聚合平台是"工具超市"，用户自己挑；未来的系统可能是"任务代理"，你说"帮我写个周报"，它自动决定用哪个模型查数据、哪个生成图表、哪个润色文字。

给从业者的三个启示

这个实验性项目没融资、没团队、没商业计划，但暴露的问题却很典型。

第一，API标准化是伪需求，响应规范化才是真刚需。行业不会统一接口格式，但你的系统必须统一内部语言。

第二，latency在多AI场景下是架构问题，不是优化问题。缓存和流式渲染是补丁，真正的解法是重新设计任务编排逻辑。

第三，聚合平台的竞争壁垒不在"接了多少工具"，而在调度智能。谁能用最少的人工干预完成复杂任务链，谁就能吃掉下一波红利。

作者最后把代码开源了。对于正在做多模型路由、AI工作流引擎、或者企业级AI中台的团队，这个"一个人的工程笔记"值得翻一遍——不是为了抄代码，是为了确认那些让你头疼的问题，别人也躲不掉。