GitHub user AlexStocks edited a discussion: [提案] AI 时代 apache/dubbo-go 的演进方向：聚焦 AI-ready 基础设施，而非另一个 AI 框架
# [提案] AI 时代 apache/dubbo-go 的演进方向：聚焦 AI-ready 基础设施，而非另一个 AI 框架 经过对当前 `develop` 分支的多轮内部分析，我认为 `apache/dubbo-go` 在 AI 时代最务实的方向，**不是**变成又一个 AI 应用框架。 相反，`dubbo-go` 更适合演进为**面向 AI 服务的高性能 Go RPC + 治理基础设施**。 本提案试图回答一个问题： > 在 AI 时代，`dubbo-go` 应该朝哪个方向演进，才能既有意义又与其既有优势保持一致？ --- ## 1. 重要的边界：`dubbo-go` 应该成为什么，不应该成为什么 ### `dubbo-go` 应该成为什么 为 Go 生态中的 AI 服务提供坚实基础，包括： - 流式友好的 RPC - 模型/服务能力发现 - 治理感知的路由 - AI 专用的可观测性 - 向外部工具/Agent 安全暴露服务 - 策略驱动的成本/延迟/租户控制 ### `dubbo-go` **不应该**成为什么 它不应该试图将以下内容纳入核心： - Prompt 工程框架 - 记忆/对话历史管理 - RAG 编排 - Agent 工作流运行时 - 将向量数据库集成作为一等公民的核心关注点 - 特定模型提供商的 SDK 逻辑 原因很简单：这些是产品层或生态层的关注点，而 `dubbo-go` 最擅长的是通信/治理/生命周期/互操作性基础设施。 --- ## 2. 为什么这个方向比泛泛的"AI 集成"更适合当前仓库 从当前仓库的信号来看，`dubbo-go` 已经在以下方面具备坚实基础： - Triple / gRPC 兼容通信 - 泛化调用 - 服务发现/元数据/注册中心集成 - 动态配置/路由更新 - 流量治理 - OTel / 指标 / 链路追踪 - OpenAPI / 代码生成工具 因此，最好的 AI 相关演进不是从零开始，而是**针对 AI 工作负载重新诠释这些既有优势**。 换句话说： - 不要在核心中构建"AI 应用运行时" - 在现有 Dubbo-go 原语之上构建"AI 服务运行时治理" --- ## 3. 建议的优先方向 ## P0：AI-ready 的服务治理 ### 3.1 模型/服务能力发现 今天，服务发现主要回答：*实例在哪里？* 对于 AI 工作负载，消费者还需要知道： - 模型系列/模型名称 - 上下文窗口 - 模态（文本/图像/Embedding/音频/工具） - 地域/合规标签 - 延迟 SLA - 成本层级 - 租户可见性 - 版本/发布阶段 这指向一个自然的演进方向： - 扩展元数据/注册中心语义，支持 AI 能力感知的服务发现 - 让消费者能够按**能力**订阅，而不仅仅是按端点身份 这与 `dubbo-go` 非常契合。 --- ### 3.2 治理感知的模型路由 一旦能力元数据存在，下一步就是路由。 `dubbo-go` 应该能够支持针对 AI 工作负载的策略驱动路由，例如： - 按成本预算路由 - 按延迟目标路由 - 按租户/合规级别路由 - 按模型质量层级路由 - 按降级策略路由 - 按金丝雀/实验阶段路由 这里的关键点是：这应该是**规则驱动且可审计的**，而不是"让 LLM 在线决定路由"。 这样可以让系统在保持 AI 感知的同时，仍然是确定性的、可审查的。 --- ### 3.3 AI 专用的可观测性 传统 RPC 可观测性对 AI 服务来说是不够的。 对于 AI 流量，我们还关心： - TTFT（首 Token 延迟） - 流式分块间隔 - 输入 Token 数/输出 Token 数 - 会话/Prompt/模型标识符 - 降级频率 - 因模型/服务退化导致的重试 - 成本归因 `dubbo-go` 的一个有力方向是扩展其现有的可观测性栈，使 AI 工作负载成为追踪和指标中的一等公民。 这具有即时的运维价值，而且不需要将项目变成 AI 框架。 --- ## P1：工具/Agent 生态赋能，但不进入 Agent 运行时核心 ### 3.4 泛化调用 + Schema 暴露给工具 一个强有力的机会是让现有的 Dubbo 服务更容易暴露为机器可消费的工具。 由于 `dubbo-go` 已经具备泛化调用和代码生成/工具基础，它完全有能力支持： - 服务 → 工具描述符生成 - Schema 优先的服务暴露 - 结构化输入/输出约束 - 为外部工具消费者提供安全元数据 这可以让 `dubbo-go` 成为 MCP/工具调用生态的强大后端基础设施，**同时**又不必将 Agent 编排强塞进核心。 --- ### 3.5 一份契约，多个消费者 一个务实的方向是演进 IDL / OpenAPI / Triple 工具链，使一份契约可以服务于： - RPC 客户端 - OpenAPI 消费者 - AI 工具消费者 - 结构化输出验证器 这种 Schema 优先的投入，比起将快速变化的 AI 产品抽象嵌入框架核心，风险更低、更持久。 --- ## P2：面向 AI 流量的流式与长会话语义 AI 工作负载对通信的压力与传统 RPC 不同： - 更长生命周期的会话 - 流式输出 - 对取消的敏感性 - 背压处理 - 大载荷/上下文窗口 `dubbo-go` 在协议层的一个有意义的演进方向是加固和优化： - 流式语义 - 取消传播 - 会话元数据传播 - 流量控制/背压行为 - 围绕流生命周期的可观测性 这直接惠及 AI 服务，同时仍然完全处于 RPC/协议领域之内。 --- ## 4. 判断某个 AI 方向是否应纳入核心的简单原则 我建议使用以下过滤条件： 如果某个方向满足以下条件，就是好的 `dubbo-go` 核心方向： 1. 建立在现有优势之上，如协议/注册中心/路由/配置/可观测性 2. 同时服务于传统微服务和 AI 服务，或者至少干净地复用同一基础设施 3. 保持提供商中立 4. 可审计、确定性、对生产治理友好 5. 不将产品层的 Agent 逻辑强塞进框架核心 如果某个提案依赖于： - Prompt 模板 - 向量存储选型 - 模型厂商 SDK 频繁变更 - 对话记忆策略 - Agent 状态机 那么它可能更适合放在**生态项目/适配器/插件**中，而不是 `dubbo-go` 核心。 --- ## 5. 推荐的路线图形态 ### 阶段一：AI-ready 基础设施 聚焦于： - 能力元数据模型 - AI 感知的服务发现 - 路由策略扩展 - AI 可观测性指标/标签 - 流式/取消加固 ### 阶段二：AI 集成的工具链 聚焦于： - 工具 Schema 生成 - 泛化调用 → 工具暴露 - 更好地对齐 OpenAPI / Triple / AI 消费者的契约/工具链 ### 阶段三：生态孵化 在核心之外孵化： - MCP 适配器 - 服务到工具的桥接 - AI 网关集成模式 - 运维助手/诊断工具 这样可以让核心保持干净，同时仍然能够在 `dubbo-go` 周围赋能 AI 生态。 --- ## 6. 我的具体建议 如果社区想用一句话描述这个方向，我建议： > `apache/dubbo-go` 应该演进为面向 AI 服务的高性能 Go RPC 和治理基础设施，而不是又一个 AI 应用框架。 如果我们想要一个简短的优先级列表，我会这样排序： 1. **AI 能力感知的元数据和发现** 2. **治理感知的模型/服务路由** 3. **AI 专用的可观测性** 4. **面向 AI 流量的流式/取消/会话加固** 5. **基于泛化调用和代码生成的工具/Schema 暴露** 6. **将 Agent/Prompt/RAG 编排留在生态中，而非核心** --- ## 7. 给社区的问题 我认为下一步有用的工作不是立即写代码，而是对齐边界和优先级。 问题： 1. 我们是否同意 `dubbo-go` 在 AI 时代的主要角色应该是 **AI 服务基础设施**，而不是 **AI 应用框架**？ 2. 在元数据/路由/可观测性/工具暴露中，哪一个应该成为第一个社区级方向？ 3. AI 相关功能应该直接进入核心，还是某些部分应该先作为插件/适配器/独立项目孵化？ 4. 社区是否已经有具体的生产用例可以作为锚点场景？ 如果有兴趣，这个讨论后续可以按主题拆分为更小的 RFC / Issue。 GitHub link: https://github.com/apache/dubbo-go/discussions/3454 ---- 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]
