GitHub user AlexStocks edited a comment on the discussion: [提案] Pixiu 在 AI 时代的演进应当聚焦 Dubbo 原生差异化，而非沦为又一个通用 AI 网关
我认为这里还有一个重要的**联合策略**问题： > 在 AI 时代，`dubbo-go` 和 `pixiu` 应当如何协同工作，而不是各自演化为两个互不关联的 AI 叙事？ 我目前的看法是： - `dubbo-go` 应主要演进为**面向 AI 的服务基础设施** - `pixiu` 应主要演进为**AI 能力网关 / 控制平面** 这意味着两个项目**不需要**在同一层面竞争。 它们可以形成更清晰的分工： ## 建议的分工 ### `dubbo-go` 专注于服务侧能力，例如： - 对 AI 友好的服务元数据 - 流式/会话语义 - 工具/schema 暴露原语 - 服务/运行时侧的 AI 专项可观测性 - 服务调用和服务发现内部的治理原语 ### `pixiu` 专注于入口/控制平面能力，例如： - 服务到工具的暴露 - 模型/工具/API 流量路由 - 策略执行 - 租户/成本/安全管控 - MCP / gateway / ingress 集成 - 从用户请求到下游服务/工具结果的端到端可观测性 ## 为什么这样拆分是合理的 如果两个项目都试图成为"AI 平台"，它们会相互重叠并稀释彼此的价值。 如果它们转而形成分层叙事，整个 Dubbo 生态会变得清晰得多： - `dubbo-go` = 企业服务能力的生产和描述层 - `pixiu` = 企业服务能力的暴露、路由、安全和治理层，面向 AI/API 消费者 换言之： - `dubbo-go` 回答的是：**服务应如何变得 AI-ready？** - `pixiu` 回答的是：**AI 系统应如何安全地大规模消费这些服务？** 这比两个项目各自独立添加通用 AI 功能要站得住脚得多。 ## 可能的后续 RFC 拆分 如果这个讨论获得关注，我认为可以拆分为几个更聚焦的主题： 1. **RFC: 面向 AI/工具暴露的 Dubbo 服务元数据模型** - 主要针对 `dubbo-go` 2. **RFC: Pixiu 服务到工具的网关模型** - 主要针对 `pixiu` 3. **RFC: 基于注册中心/元数据驱动的 dubbo-go + pixiu AI 路由** - 联合主题 4. **RFC: 模型 → 工具 → 下游服务的端到端可观测性** - 联合主题 5. **RFC: 服务基础设施与网关控制平面之间的安全/治理边界** - 联合主题 我认为，厘清这种生态层面的协作模式，会比孤立地讨论 Pixiu 的 AI 故事更有说服力。 GitHub link: https://github.com/apache/dubbo-go-pixiu/discussions/990#discussioncomment-17431513 ---- 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]
