AI 聚合平台分类
所谓 AI 聚合平台，到底在聚合什么：6 类产品的技术拆解
这两年，`AI 聚合平台` 这个词被用得太宽了。
`OpenRouter`、`Poe`、`Open WebUI`、`ChatALL`、`OneKey`、零一万物的 `万知 / 万智`，经常被放进同一张对比表里。表上通常写着模型数量、价格、能不能联网、能不能上传文件。看起来很全面，实际上经常把问题越写越糊。
原因不复杂。
这些产品虽然都在“接模型”，但系统位置并不一样。有的做入口，有的做网关，有的做控制面，有的已经开始做任务执行。你拿入口层的产品去和路由层比较，拿本地工具去和企业 agent 平台比闭环，最后当然只会得出一个热闹但没什么判断力的结论。
我更愿意换个问法：
`它到底帮你省掉了哪一层复杂度？`
这比“它接了多少模型”更接近真实选型。
六类产品的公开页面总览
图 1 里放的是六类产品的公开页面或信息卡。只看这一页，其实已经能看出一些很有意思的差别：
– `OpenRouter` 首屏强调的是统一接口、provider 数量和可用性。
– `Poe` 公开页更像套餐和消费入口，不像基础设施。
– `Open WebUI` 讲的是 freedom stack，本质上是在讲控制权。
– `ChatALL` 的信息密度来自仓库本身，说明它更像工具，而不是平台。
– `OneKey` 公开材料强调统一 API、项目级 key、路由和 workspace。
– `万知 / 万智` 的页面语气明显已经偏向 agent 和企业业务，不再只是聊天入口。
先把它们放回系统位置
很多争论，其实到这一步就能停掉一半。
如果把这几类产品放回应用栈里，大概是下面这个结构：
这里最容易混的几组是：
– `OpenRouter` 和 `OneKey` 更像统一路由层，核心问题是“怎么把不同模型接成一个出口”。
– `Open WebUI` 更像控制与编排层，核心问题是“怎么把模型纳入自己的权限、知识和流程体系”。
– `万智 2.5` 已经更接近执行层，核心问题不是聊天，而是“任务怎么拆、工具怎么调、结果怎么回收”。
这也是为什么我不太认同把它们简单排个一二三四。
它们解决的不是同一个问题。
分产品看，边界就更清楚了
1. OpenRouter：像网关，不像工作台
`OpenRouter` 的价值，不在聊天页，而在接口层。
它把不同模型、不同 provider、不同价格和不同可用性，收成一个 OpenAI 兼容出口。对开发团队来说，这件事很重要。因为一旦应用开始上线，真正烦人的问题往往不是“模型回得好不好”，而是“某个 provider 掉了以后系统怎么办”“同一套逻辑怎么切模型不改代码”“不同数据策略怎么分流”。
所以它强在：
– 统一接入
– provider routing
– fallback
– 成本与可用性的折中
它不强的地方也很明显：
它不负责把事情做完。它解决的是接入层和容灾，不负责项目协作、知识沉淀，也不直接负责结果闭环。
2. Poe：像分发层，不像基础设施层
`Poe` 最强的地方，其实不是“模型多”，而是“起得快”。
打开就能用。切模型很顺。Bot 生态也比较自然。对于还没决定长期技术路线的人，它是一个很低摩擦的入口。图 1 里那张订阅页也能看出来，Poe 已经把自己做成了一套比较标准的平台套餐体系，而不只是“多模型聊天网页”。
但平台式产品都有同一个代价：
`方便` 和 `控制权` 往往不是同时给你的。
个人用户不一定在意这点。团队和企业就不一样了。一旦你要管成本、权限、审计、模型替换，平台边界就会立刻冒出来。
3. Open WebUI：从“能用”往“可控”迈一步
`Open WebUI` 很多人第一眼把它当成“自建 ChatGPT 壳子”。这个理解太浅了。
它真正有价值的部分，在于把模型、权限、知识库、审计、函数扩展、pipeline 这类东西，装进了一套自己能部署、自己能管理的系统里。到了这里，AI 不再只是一个网页书签，而开始变成内部系统的一部分。
这类产品的逻辑很朴素：
– 好处是数据和控制权在自己这边
– 代价是运维和安全责任也回到自己这边
所以 `Open WebUI` 适合的是已经有内部协作和治理要求的团队，不是“我想先玩一下模型”的那一类需求。
4. ChatALL：像测试夹具，不像中台
`ChatALL` 的定位反而最干脆。
它擅长的是同题多答。你给一个 prompt，同时看多个模型的回复，马上能看出风格差、结构差、容错差。这对写作、评测、提示词迭代都很好用。
但也正因为这样，它不应该被误会成“聚合平台中枢”。
它更像一套本地比较工具。适合横向看答案，不适合拿来承担路由、权限或者流程闭环。
5. OneKey：统一出口和工作区，想两头一起吃
`OneKey` 的有意思之处，在于它想做的不只是 API 门面。
从公开材料看，它在试图把统一端点、项目级 key、路由策略、workspace 这一层连起来。换句话说，它不是只想解决“接进来”，还想顺手解决“怎么组织这些调用”和“怎么在一个工作区里用起来”。
这个方向是成立的。
因为现在很多团队碰到的问题，正好不是模型不够，而是：
– 订阅和 API 太散
– 项目和个人 key 混在一起
– 模型切换没有策略
– 工作流挂在不同工具里，收不拢
不过客观说一句，截至 `2026-04-28`，它的公开讨论密度还不算高。方向是清楚的，但长期第三方验证样本还没有 OpenRouter、Poe、Open WebUI 这么厚。
6. 万知 / 万智：已经不只是“接模型”
如果还拿“多模型聚合聊天工具”的尺子去量 `万知 / 万智`，大概率会看偏。
从公开页面和近一年的产品表达看，它已经明显在往 `agent + 企业业务` 这个方向倾斜。这里的重点不是“哪个模型答得像人”，而是“谁来拆任务，谁来调工具，谁来回收结果，谁来保证过程可控”。
说得再直一点：
前面几类产品，大多在解决“模型怎么进来”；
`万智` 这层，开始解决“模型进来以后，事情怎么做完”。
再看两个坐标：即用性和控制权
如果只看用户视角，我觉得最实用的一张图反而不是参数表，而是下面这个二维定位：
这张图没有总分，只有位置。
– `Poe` 靠右下，因为它离“开箱即用”很近，但控制权相对少。
– `Open WebUI` 靠左上，因为它更偏向内部可控系统。
– `OpenRouter` 和 `OneKey` 在中间偏上，因为它们解决的是统一出口和策略层。
– `ChatALL` 偏右，但更像个人工具，不承担中台职责。
– `万知 / 万智` 在中上区域，因为它比普通入口更重，又没有完全落到自托管控制平面的左上角。
这张图的用法很简单：
如果你现在最缺的是 `先用起来`，往右看。
如果你现在最缺的是 `把边界收回来`，往上看。
真正有用的，不是总榜，而是能力矩阵
做技术选型，最怕一句“谁最强”。
更可靠的做法，是把能力拆开看。
这里我只看六个维度：
– 统一入口
– 路由调度
– 权限 / 数据控制
– 扩展 / 工具
– 结果闭环
– 部署门槛
从这张矩阵可以读出几件很实在的事：
1. `OpenRouter` 和 `OneKey` 的强项都不在界面，而在路由层。
2. `Poe` 的优势非常明确，就是低门槛、多模型、快速起步。
3. `Open WebUI` 的强项几乎都在“把 AI 收回自己体系里”。
4. `ChatALL` 是好工具，但它不是中台，不该被误用。
5. `万知 / 万智` 更接近业务闭环能力，而不是单纯的模型入口。
最后一句
今天再问“谁是最强 AI 聚合平台”，其实已经有点问偏了。
更应该问的是：
`我现在卡住的，到底是入口、路由、控制，还是交付？`
如果卡在入口，优先看 `Poe`。
如果卡在统一 API 和容灾，优先看 `OpenRouter / OneKey`。
如果卡在权限、知识、审计和私有化，优先看 `Open WebUI`。
如果卡在横向比较，`ChatALL` 很合适。
如果卡在企业任务怎么跑完，重点就不该再放在“聊天聚合器”上，而应该看 `万智` 这一层。
很多产品表面上都在“聚合 AI”。
真正决定它值不值得用的，是它替你拿走了哪一种复杂度。