一个人造了个AI工具超市，发现最难的不是接API

如果让你把二十几个AI工具塞进同一个界面，你会先解决什么问题？界面设计？用户登录？还是怎么收费？

有个开发者选了最难的那条路：先搞定"它们说话方式都不一样"这件事。

为什么有人要造"AI工具超市"

这个叫OnlyAITools的项目，本质是个实验。作者没想做产品，只想回答一个工程问题：当系统里塞满不同公司的AI服务时，怎么让它们看起来像一个整体？

思路很直接——加一层"中央路由"。用户在前端点一个按钮，后端判断该调哪个API，把请求发过去，再把结果拿回来。

听起来像常见的聚合平台？区别在细节。作者没选简单的跳转方案，而是让每个AI工具成为独立服务模块，前端保持完全统一，底层供应商可以随时换。

这种抽象设计的好处立竿见影：今天接的是OpenAI的接口，明天换成国产大模型，用户端无感知。

真正的坑：API们不会说同一种话

但抽象层刚搭好，第一个硬骨头就出现了。

不同AI服务的返回格式五花八门。同样是生成一段文本，有的包在嵌套JSON里，有的直接扔字符串，有的附带一堆元数据，有的干脆没有。字段命名也各玩各的——这家叫"content"，那家叫"text"，还有叫"response"的。

作者的处理方式很工程师：加一层"规范化层"（normalization layer）。所有外部响应先到这里翻译成内部统一格式，再往上送。

代价很明显。前端逻辑确实简化了，但后端复杂度暴涨。每接入一个新API，就要写对应的转换规则。这活儿没有自动化，只能手工对齐字段、处理边缘情况、测试边界响应。

「最难的部分不是单独集成某个AI工具，而是设计一个能干净抽象它们的系统，同时不引入太多开销。」作者的原话。

200毫秒和5秒的战争

格式问题刚缓解，性能问题又找上门。

不同API的响应时间差距极大。快的200-500毫秒，慢的要等好几秒，而且延迟还随负载波动。这意味着用户点一下按钮，有的工具秒出结果，有的要转圈半天。

更麻烦的是链式调用和并行执行。如果想让A工具的结果传给B工具继续处理，总耗时是叠加的；如果同时调多个工具等结果拼页面，用户就得等最慢那个。

作者的应对是两招：缓存和局部渲染。常用结果先存起来，下次直接拿；页面先展示已返回的部分，没好的区域占位加载。都是成熟技术，但在AI场景下尤其必要——因为大模型推理本身就是不可控的延迟来源。

一个更大的问号

项目做完，作者抛出一个问题：这种中央集权式的架构，到底能走多远？

现在的设计是用户明确选择工具，系统负责路由。但"智能体"（agent-based）的范式正在兴起——AI自己判断该用什么工具，动态调用，不需要用户在界面上点选。

两种模式的核心差异在于"决策权在哪"。聚合平台把选择权交给用户，智能体把选择权交给AI。前者可控、透明，后者灵活、但黑箱。

这不是技术选型问题，是产品哲学问题。用户要的是"我指哪打哪"的确定性，还是"你看着办"的便利性？

给想动手的人

这个实验的价值在于暴露了聚合类产品的真实成本。很多人以为接API就是调个接口，实际上：

• 格式对齐是持续消耗，每新增供应商都要投入
• 延迟优化没有银弹，缓存策略需要业务场景支撑
• 架构选择会锁死产品形态，早期决策影响深远

如果你也在做类似尝试，建议先问自己：用户真的需要"一个入口管所有"，还是"在特定场景下无缝切换"？这两个需求看起来相似，工程实现完全不同。

前者是超级应用思维，后者是插件化思维。OnlyAITools选了前者，但作者的反思暗示，后者可能是更可持续的路径。

项目链接放在开头了。建议别只看界面，重点看作者怎么处理那层规范化——这才是这类系统真正的核心竞争力。