[提案] AI 时代 apache/dubbo-go 的演进方向：聚焦 AI-ready 基础设施，而非另一个 AI 框架

[AlexStocks]

[提案] 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。