GitHub user AlexStocks edited a discussion: [提案] Pixiu 在 AI 时代的演进应当聚焦 Dubbo 原生差异化，而非沦为又一个通用 AI 网关
# [提案] Pixiu 在 AI 时代的演进应当加倍投入 Dubbo 原生的差异化，而非沦为又一个通用 AI 网关 Pixiu 已经将自身定位为 `AI / API Gateway`，并明确讨论了 `LLM`、`MCP` 和 Kubernetes 入口。 这意味着真正的问题不再是： > Pixiu 该不该做 AI？ 真正的问题是： > 如果 Pixiu 继续向 AI 方向演进，它如何以 **Dubbo 原生的差异化方式** 来做，而不是沦为又一个通用 AI 网关？ 经过 20 轮内部激烈讨论，我的结论是： > **Pixiu 的独特价值不在于"它也能代理 LLM/MCP"。它的独特价值在于，它能将 Dubbo 时代的企业服务资产和治理体系，转化为 AI > 可调用、可治理、可审计的能力网络。** 这正是通用 AI 网关故事与 Pixiu 专属故事的区别所在。 --- ## 1. 什么是真正的差异化，什么只是叙事？ ## 真正的差异化 ### 1.1 将 Dubbo 服务网络转化为 AI 可调用的能力网络 这是最强的独特方向。 Pixiu 构建于 Dubbo 生态之上，该生态已经具备： - 服务契约 - 方法签名 - 服务分组 / 版本 - 路由规则 - 注册中心元数据 - 流量治理 - 已在生产环境运行的企业微服务资产 如果 Pixiu 能让这些服务安全地被 AI 系统调用（通过 MCP/工具暴露、协议转换、工具 Schema 生成、路由、认证和可观测性），那就是一个有意义的护城河。 通用 AI 网关通常从 HTTP API 和 JSON 负载起步。 Pixiu 可以从**已经存在的企业服务资产**起步。 这更接近真正的企业价值。 --- ### 1.2 将 AI 网关语义与 Dubbo 治理语义相结合 最强的 Pixiu 故事不是： - "我们也支持 OpenAI 兼容流量" - "我们也支持 MCP" 这些越来越成为标配。 更强的故事是： - AI 调用可以继承 Dubbo 风格的路由、标签、金丝雀、重试、降级、隔离、审计和服务治理语义 - 工具暴露不仅是协议转换，更是治理感知的能力暴露 - AI 流量可以像 RPC 流量一样，在生产纪律下被管理 这正是 Pixiu 能够超越"又一个 AI 反向代理"的地方。 --- ### 1.3 复用企业注册中心和元数据作为 AI 控制面资产 Pixiu 已经记录了围绕 MCP 工具 / LLM 端点 / 注册中心驱动配置的动态发现和管理模式。 这很重要，因为它指出了一条路径： - 服务发现不仅关乎端点 - 注册中心元数据成为能力元数据 - 企业控制面（如以 Nacos 为中心的环境）可以复用于 AI 工具 / 模型 / 网关管理 在 Dubbo + Nacos + Java/Go 服务已经构成平台骨干的环境中，这一点尤其强大。 --- ### 1.4 以低迁移成本将存量企业服务桥接到 MCP / 工具生态 这可能是最清晰的实际护城河。 很多企业不需要"又一个 LLM 代理"。 他们需要一种方式，让 AI 系统安全地调用： - 现有的业务 API - 内部 HTTP 服务 - Dubbo 服务 - 内部平台能力 如果 Pixiu 成为从： - Dubbo / HTTP / gRPC / Triple 服务 - 到 MCP / 工具可调用能力表面 的最顺畅路径，那么它就具备了通用网关所不具备的战略价值。 --- ## 大多是标配或叙事（单独来看远远不够） 以下可能有用，但**单独来看不足以形成差异化**： - "支持 OpenAI 兼容 API" - "支持 MCP 协议" - "支持 SSE / 流式" - "支持 Token 指标" - "支持降级 / 重试" - "支持 OAuth / JWT" - "支持 K8s 入口" - "支持多种协议" 这些都很重要，但大多数现代 AI / API 网关都能声称支持其中一些。 所以如果 Pixiu 的 AI 方向仅在这个层面来描述，很容易迷失在通用 AI 网关的竞争中。 --- ## 2. Pixiu 应该优化什么 如果 Pixiu 想建立真正的 Dubbo 原生 AI 差异化，我会优先考虑以下主题。 ## P0：企业服务能力网关 这应该是重心。 Pixiu 应该致力于成为： - 将企业服务能力安全暴露给 AI 系统的网关 - 而不仅仅是转发 AI 模型请求的网关 这意味着： - 服务到工具的暴露 - Schema 感知的工具生成 - 方法级别的认证 / 策略 - 注册中心/元数据驱动的工具目录 - 治理感知的调用 如果 Pixiu 占据这一层，就能获得有意义的护城河。 --- ## P0：基于 Dubbo 治理构建的 AI 治理 Pixiu 应该将现有的 Dubbo 风格治理转化为 AI 时代的控制，例如： - 哪个租户 / Agent 可以调用哪个服务或工具 - 哪些工具是只读的，哪些具有变更能力 - 哪些路由可以访问高端模型，哪些访问廉价模型 - 当一个模型/提供商降级时如何进行降级 - 如何在生产流量下进行模型/工具发布的金丝雀测试 这比单纯的"模型路由"更强，因为它将 AI 流量与企业治理纪律绑定在一起。 --- ## P1：注册中心和元数据驱动的 AI 路由 Pixiu 应该超越"上游列表 + 静态配置"的思维。 更强的方向是： - 注册中心驱动的 LLM / MCP / 工具发现 - 元数据驱动的路由选择 - 按能力、成本层级、租户、区域、合规性、安全级别或缓存亲和性进行路由 这正是 Dubbo 时代服务发现 DNA 能够转化为 AI 时代价值的地方。 --- ## P1：工具感知的可观测性和审计 通用 AI 网关通常只观测模型调用。 Pixiu 应该致力于观测： - 模型请求 - 工具调用 - 下游服务调用 - 业务结果路径 - 降级 / 重试 / 降级路径 这将使企业能够回答诸如： - 为什么 Agent 失败了？ - 哪个下游服务导致了失败？ - 哪个工具路径成本高？ - 哪个模型/工具组合不稳定？ 这种端到端的可观测性比单纯的 Token 计数更有说服力。 --- ## P2：K8s + Dubbo + AI 统一控制面 这在战略上很有趣，但应该在上述内容明确之后再推进。 如果 Pixiu 能够统一： - API 流量 - AI 流量 - MCP/工具流量 - 服务发现和路由 - 入口层治理 在一个 Kubernetes 友好的控制面下，那就是一个强大的平台故事。 但这只有在它与企业服务能力治理绑定时才具有差异化，而不仅仅是通用的入口功能。 --- ## 3. Pixiu 应该避免什么 为了保持方向的清晰，我会避免将 Pixiu 核心变成： - Prompt 工程平台 - Agent 工作流引擎 - RAG 框架 - 记忆/会话产品框架 - 向量数据库集成中心 - 提供商特定的 SDK 集合 这些可能存在于生态项目、插件或适配器中。 但如果它们主导了核心路线图，Pixiu 就有失去最强身份的风险。 一个有用的规则是： > 如果一个能力主要用于构建 AI 应用，它可能应该位于 Pixiu 之上。 > 如果一个能力主要用于治理、暴露、保护、路由或观测企业服务上的 AI 流量，它可能应该位于 Pixiu 内部。 --- ## 4. 更清晰的差异化陈述 我认为 Pixiu 在 AI 时代最强的陈述不应该是： - "Pixiu 是下一代 AI 网关" 这太宽泛，也太容易被复制。 更强的陈述应该是这样的： > **Pixiu 是 Dubbo 原生的 AI 能力网关，将企业服务转化为可治理、AI 可调用的工具和流量平面。** 或者更简单地说： > **Pixiu 是 Dubbo 服务治理与 AI 工具和模型流量交汇的地方。** 这更具体，通用 AI 网关也更难令人信服地声称这一点。 --- ## 5. 我的具体建议 如果社区想让 Pixiu 的 AI 路径更具差异化，我会推荐这个顺序： 1. **将服务到工具的暴露和治理作为旗舰故事** 2. **在注册中心/元数据/治理之上构建 AI 路由，而不仅仅是提供商 API** 3. **加强从模型调用到下游服务/工具结果的端到端可观测性** 4. **将 K8s/Ingress 作为乘数，而不是主要差异化本身** 5. **将 Prompt/Agent/RAG 框架保留在生态中，而不是 Pixiu 核心** 简而言之： - 不是"更多 AI 功能" - 而是"更多 Dubbo 原生 AI 控制面价值" --- ## 6. 给社区的问题 1. 我们是否同意 Pixiu 的 AI 差异化应该围绕**企业服务能力暴露和治理**，而不是通用的模型代理？ 2. 哪个是 Pixiu 更强的旗舰方向： - 模型网关 - 工具网关 - 统一服务能力网关 3. 哪些 Dubbo 原生资产应该优先用于 AI： - 注册中心元数据 - 路由 / 治理规则 - 服务契约 / Schema - 可观测性 / 链路追踪 4. 一些面向 AI 的功能是否应该保留在插件 / 生态项目中，而不是进入核心？ 如果有兴趣，这个讨论以后可以拆分为更小的 RFC，围绕： - 服务到工具的暴露 - AI 治理策略 - 元数据/能力路由 - AI + 下游服务的可观测性 GitHub link: https://github.com/apache/dubbo-go-pixiu/discussions/990 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
