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