[提案] Pixiu 在 AI 时代的演进应当聚焦 Dubbo 原生差异化，而非沦为又一个通用 AI 网关 #990
Replies: 2 comments
-
|
我认为这里还有一个重要的联合策略问题：
我目前的看法是：
这意味着两个项目不需要在同一层面竞争。 建议的分工
|
Beta Was this translation helpful? Give feedback.
-
深入研究两份方案后的现实检验我花了几天时间，用实际的代码库、竞争格局以及真实 Dubbo 用户的生产实践来验证这两份方案。以下是我的发现——有些可能不太好听。 房间里的大象：Pixiu 的 MCP Server 是 HTTP→MCP，而非 Dubbo→MCP我仔细查看了 所以所谓"Dubbo-native MCP"的故事，实际上是"HTTP gateway + 一个恰好放在 Dubbo 仓库里的 MCP shell"。任何带有 MCP 插件的 API gateway 都能做到同样的事情。Kong、Higress 和 Envoy 几个月前就已经发布了这个功能。 这不是在批评工程质量——MCP 实现本身是扎实的（约1800行代码，SSE、OAuth、Nacos 动态配置、完善的 session 管理）。但称其为"Dubbo-native"有些牵强。 真实用户的选择这部分更让人难受。我查看了 Dubbo 用户实际为 AI gateway 需求部署了什么：
甚至在阿里巴巴内部，当 HSF（≈Dubbo）服务需要 MCP 暴露时，使用的是 Higress 做协议卸载——而不是 Pixiu。 Dubbo 官方文档甚至有一页标题就是"如何通过 Higress Gateway 代理 Dubbo 服务"。社区已经在告诉用户使用 Higress。 时机问题确实存在MCP Gateway 市场整合正在快速进行：
而 Pixiu 停留在547 stars，没有 MCP 生产案例。ISG 2025 报告显示31%的 AI 用例已经进入生产阶段。市场不是"即将爆发"——而是已经爆发，赢家已经选好了座位。 Dubbo Java 早已解决的问题（6196行代码）Dubbo Java 在2025年10月合并了 这是正确的方向：在框架层面将 Dubbo 服务暴露为 MCP tools，而不是通过一个独立的 gateway。dubbo-go 应该移植这个设计，而不是在 gateway 层面与之竞争。 filter chain 的阻碍我还研究了将 Pixiu 变成真正 AI Gateway 需要什么。filter chain（ 将 filter chain 异步化是一个破坏性变更，会影响所有15+个现有 filters。估计需要约5.75人月，风险很高。这是"AI Gateway"愿景的硬阻碍。 Triple 协议自身的问题Triple 的 streaming 实现（ 无论 AI 方向如何，这些都需要修复——它们影响所有 Triple 用户。 我认为 dubbo-go 应该做什么别再试图成为另一个 AI gateway。做 Java 做不到的事。
我认为 Pixiu 应该成为什么Pixiu 的 MCP Server 代码写得确实很好。但它解决的问题 Higress 已经解决了，目标用户群已经选择了 Higress。 选项：
残酷的现实"Dubbo-native AI Gateway"的叙事在方案中听起来很有说服力，但经不起现实的检验。用户不关心"Dubbo-native"——他们关心的是"为现有服务提供零成本的 AI 集成"。Higress + Spring AI Alibaba + Nacos 已经提供了这个能力，并有携程、森马等的生产验证。 dubbo-go 在 AI 时代的真正价值不是构建另一个 gateway。而是成为任何 gateway 都能与之对话的，最快、最可靠、最 MCP 友好的 RPC 框架。这是一个可防守的定位，能发挥现有优势。 Java 端已经想通了这一点（dubbo-mcp）。Go 端应该遵循同样的逻辑，适配 Go 的云原生优势。 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
[提案] Pixiu 在 AI 时代的演进应当加倍投入 Dubbo 原生的差异化，而非沦为又一个通用 AI 网关
Pixiu 已经将自身定位为
AI / API Gateway，并明确讨论了LLM、MCP和 Kubernetes 入口。这意味着真正的问题不再是：
真正的问题是：
经过 20 轮内部激烈讨论，我的结论是：
这正是通用 AI 网关故事与 Pixiu 专属故事的区别所在。
1. 什么是真正的差异化，什么只是叙事？
真正的差异化
1.1 将 Dubbo 服务网络转化为 AI 可调用的能力网络
这是最强的独特方向。
Pixiu 构建于 Dubbo 生态之上，该生态已经具备：
如果 Pixiu 能让这些服务安全地被 AI 系统调用（通过 MCP/工具暴露、协议转换、工具 Schema 生成、路由、认证和可观测性），那就是一个有意义的护城河。
通用 AI 网关通常从 HTTP API 和 JSON 负载起步。
Pixiu 可以从已经存在的企业服务资产起步。
这更接近真正的企业价值。
1.2 将 AI 网关语义与 Dubbo 治理语义相结合
最强的 Pixiu 故事不是：
这些越来越成为标配。
更强的故事是：
这正是 Pixiu 能够超越"又一个 AI 反向代理"的地方。
1.3 复用企业注册中心和元数据作为 AI 控制面资产
Pixiu 已经记录了围绕 MCP 工具 / LLM 端点 / 注册中心驱动配置的动态发现和管理模式。
这很重要，因为它指出了一条路径：
在 Dubbo + Nacos + Java/Go 服务已经构成平台骨干的环境中，这一点尤其强大。
1.4 以低迁移成本将存量企业服务桥接到 MCP / 工具生态
这可能是最清晰的实际护城河。
很多企业不需要"又一个 LLM 代理"。
他们需要一种方式，让 AI 系统安全地调用：
如果 Pixiu 成为从：
的最顺畅路径，那么它就具备了通用网关所不具备的战略价值。
大多是标配或叙事（单独来看远远不够）
以下可能有用，但单独来看不足以形成差异化：
这些都很重要，但大多数现代 AI / API 网关都能声称支持其中一些。
所以如果 Pixiu 的 AI 方向仅在这个层面来描述，很容易迷失在通用 AI 网关的竞争中。
2. Pixiu 应该优化什么
如果 Pixiu 想建立真正的 Dubbo 原生 AI 差异化，我会优先考虑以下主题。
P0：企业服务能力网关
这应该是重心。
Pixiu 应该致力于成为：
这意味着：
如果 Pixiu 占据这一层，就能获得有意义的护城河。
P0：基于 Dubbo 治理构建的 AI 治理
Pixiu 应该将现有的 Dubbo 风格治理转化为 AI 时代的控制，例如：
这比单纯的"模型路由"更强，因为它将 AI 流量与企业治理纪律绑定在一起。
P1：注册中心和元数据驱动的 AI 路由
Pixiu 应该超越"上游列表 + 静态配置"的思维。
更强的方向是：
这正是 Dubbo 时代服务发现 DNA 能够转化为 AI 时代价值的地方。
P1：工具感知的可观测性和审计
通用 AI 网关通常只观测模型调用。
Pixiu 应该致力于观测：
这将使企业能够回答诸如：
这种端到端的可观测性比单纯的 Token 计数更有说服力。
P2：K8s + Dubbo + AI 统一控制面
这在战略上很有趣，但应该在上述内容明确之后再推进。
如果 Pixiu 能够统一：
在一个 Kubernetes 友好的控制面下，那就是一个强大的平台故事。
但这只有在它与企业服务能力治理绑定时才具有差异化，而不仅仅是通用的入口功能。
3. Pixiu 应该避免什么
为了保持方向的清晰，我会避免将 Pixiu 核心变成：
这些可能存在于生态项目、插件或适配器中。
但如果它们主导了核心路线图，Pixiu 就有失去最强身份的风险。
一个有用的规则是：
4. 更清晰的差异化陈述
我认为 Pixiu 在 AI 时代最强的陈述不应该是：
这太宽泛，也太容易被复制。
更强的陈述应该是这样的：
或者更简单地说：
这更具体，通用 AI 网关也更难令人信服地声称这一点。
5. 我的具体建议
如果社区想让 Pixiu 的 AI 路径更具差异化，我会推荐这个顺序：
简而言之：
6. 给社区的问题
如果有兴趣，这个讨论以后可以拆分为更小的 RFC，围绕：
Beta Was this translation helpful? Give feedback.
All reactions