我来到，我看见，我记录。

Authorization Flow 授权流程 1. 背景(Background) 随着模型上下文协议 (Model Context Protocol, MCP) 的应用场景从本地环境扩展到开放的互联网，对服务进行访问控制和身份验证变得至关重要。这直接关系到 MCP Server 的核心安全性。当前，Pixiu 网关已经具备将后端 API 包装为 MCP Server 的能力，下一步的核心任务是利用网关的现有能力，集成一套标准的鉴权机制，以完整实现 MCP 规范中的授权 (Authorization) 要求。 MCP 规范明确指出： Implementations using an HTTP-based transport **SHOULD** conform to this specification. （基于 HTTP 的传输应该实现此规范。） 本方案旨在设计一个健壮、可扩展且符合行业最佳实践的授权流程。 2. 核心原则与角色定位 (Core Principles & Role) 2.1 Pixiu 的角色抉择：资源服务器 A protected MCP server acts as an OAuth 2.1 resource server, capable of accepting and responding to protected resource requests using access tokens. ...

Go 的一些理解 如何解决循环依赖（Circular Dependency） 什么是循环依赖 package a 导入了 package b package b 又反过来导入了 package a 1 2 3 4 5 6 a.go b.go +--------+ +--------+ | package| --> | package| | a | | b | | | <-- | | +--------+ +--------+ 依赖循环是设计的问题，如果遇到依赖的情况，需要重新思考该如何对项目进行设计。 解决循环依赖 核心思想是 打破循环。Go 社区推崇的最佳实践是利用 接口（Interface） 和 依赖倒置原则（Dependency Inversion Principle, DIP）。 方案一：使用接口（最推荐、最优雅的 “Go Way”） 依赖倒置原则的核心是 “依赖于抽象，而不是依赖于具体实现”。在 Go 中，这个“抽象”就是接口。 方案二：提取公共依赖到新包 如果循环仅仅是因为共享了某个数据结构（struct），那么最简单的办法就是把这个公共的数据结构提取到一个新的、更底层的包里。 警告：不要滥用这个模式，避免创建一个什么都往里扔的“垃圾桶”(common, utils)包。这个新包应该只包含稳定、底层、被广泛依赖的数据结构或常量。 Pixiu 里不是什么东西都能放进 model 和 common 里的，这点需要注意，希望最后不用重构。 ...

1. 引言 本文档旨在探讨在 dubbo-go-pixiu 网关中，基于现有的 Http2ListenerService 实现对原生 gRPC 流式传输（包括客户端流、服务端流和双向流）支持的几种设计方案。核心目标是使 Pixiu 能够接收来自 gRPC 客户端的流式请求，并利用 grpcdynamic 库动态地将这些请求代理到后端的 gRPC 服务。 2. 通用前提与核心组件 在讨论具体方案之前，我们明确以下通用前提和将要使用的核心组件： Listener 配置: Pixiu 网关配置了一个 protocol_type: GRPC 或 protocol_type: HTTP2 的 Listener。这将默认或间接使用 Http2ListenerService (位于 pkg/listener/http2/http2_listener.go) 来处理底层的 HTTP/2 连接。 grpcdynamic 库: 用于在网关内部动态地构建和发送 gRPC 请求到后端服务，以及解析响应，无需预编译的 gRPC Stub。 方法描述符 (desc.MethodDescriptor): 网关需要有能力获取目标后端 gRPC 服务的方法描述符。这可以通过 gRPC 反射机制、在网关加载 .proto 文件或 FileDescriptorSet 文件，或通过其他配置服务来实现。 网络过滤器链 (NetworkFilterChain): 请求在 Http2ListenerService 接收后，会经过此处理链。我们需要在这里集成 gRPC 流处理逻辑。 3. 设计方案嵌入式标准 gRPC 服务器与 grpc.UnknownServiceHandler 3.1. 核心思想 修改 Http2ListenerService，使其内部的 http.Server 的 Handler 直接设置为一个标准的 grpc.Server 实例。这个嵌入的 grpc.Server 利用 grpc.UnknownServiceHandler 选项来捕获所有未在网关显式注册的 gRPC 服务调用，然后在其 Handler 内部使用 grpcdynamic 将这些调用动态代理到后端。 ...

RIPER-5 背景介绍 你是Claude 4.0，集成在 Copilot 中，Copilot 是基于AI的VS Code插件。由于你的高级功能，你往往过于急切，经常在没有明确请求的情况下实施更改，通过假设你比用户更了解情况而破坏现有逻辑。这会导致对代码的不可接受的灾难性影响。在处理代码库时——无论是Web应用程序、数据管道、嵌入式系统还是任何其他软件项目——未经授权的修改可能会引入微妙的错误并破坏关键功能。为防止这种情况，你必须遵循这个严格的协议。 语言设置：除非用户另有指示，所有常规交互响应都应该使用中文。然而，模式声明（例如[MODE: RESEARCH]）和特定格式化输出（例如代码块、清单等）应保持英文，以确保格式一致性。 元指令：模式声明要求 你必须在每个响应的开头用方括号声明你当前的模式。没有例外。 格式：[MODE: MODE_NAME] 未能声明你的模式是对协议的严重违反。 初始默认模式：除非另有指示，你应该在每次新对话开始时处于RESEARCH模式。 核心思维原则 在所有模式中，这些基本思维原则指导你的操作： 系统思维：从整体架构到具体实现进行分析 辩证思维：评估多种解决方案及其利弊 创新思维：打破常规模式，寻求创造性解决方案 批判性思维：从多个角度验证和优化解决方案 在所有回应中平衡这些方面： 分析与直觉 细节检查与全局视角 理论理解与实际应用 深度思考与前进动力 复杂性与清晰度 增强型RIPER-5模式与代理执行协议 模式1：研究 [MODE: RESEARCH] 目的：信息收集和深入理解 核心思维应用： 系统地分解技术组件 清晰地映射已知/未知元素 考虑更广泛的架构影响 识别关键技术约束和要求 允许： 阅读文件 提出澄清问题 理解代码结构 分析系统架构 识别技术债务或约束 创建任务文件（参见下面的任务文件模板） 创建功能分支 禁止： 建议 实施 规划 任何行动或解决方案的暗示 研究协议步骤： 创建功能分支（如需要）： 1 git checkout -b task/[TASK_IDENTIFIER]_[TASK_DATE_AND_NUMBER] 创建任务文件（如需要）： 1 mkdir -p .tasks && touch ".tasks/${TASK_FILE_NAME}_[TASK_IDENTIFIER].md" 分析与任务相关的代码： ...

Pixiu AI 演进 AI 应用架构新范式 AI 应用架构图 调用链路说明 用户向AI应用发起请求，请求流量进入流量网关（云原生API网关）。 云原生API网关侧维护管理了不同类型的AI Agent的API或路由规则，将用户请求转发至对应的AI Agent。（可以考虑接入 A2A 协议） AI Agent无论以哪种方式实现，只要其中的节点需要获取数据，便向MCP网关（云原生API网关）请求获取可用的MCP Server及MCP Tool的信息。 因为MCP网关处可能维护了很多MCP信息，可以借助LLM缩小MCP范围，减少Token消耗，所以向AI网关（云原生API网关）发请求和LLM交互。（这一步可选） MCP网关将确定好范围的MCPServer及MCP Tool的信息List返回给AIAgent。 AI Agent将用户的请求信息及从MCP网关拿到的所有MCP信息通过AI网关发送给LLM。 经过LLM推理后，返回解决问题的唯一MCP Server和MCP Tool信息。 AI Agent拿到确定的MCP Server和MCP Tool信息后通过MCP网关对该MCP Tool做请求。 实际生产中 ③-⑧ 步会多次循环交互 云原生 API 网关 [!注释] 南北走向流量为 client-server 的流量 东西走向流量为 server-sever 流量 Web Application Firewall，Web应用防火墙，简称WAF 传统的流量网关和 API 网关集成的微服务网关（SpringCloud Gateway）注重于同 k8s 中的 Pod 进行交互，有东西走向流量和南北走向流量。 而新一代网关 增加了AI 流程的同时，有如下特点 流量网关、API网关，微服务网关、AI网关、MCP网关多合一 统一东西南北向流量 集成 WAF ，内容安全数据面 集成 AI 领域 LLM，MCP 差异化竞争力：服务治理、API管理、LLM管理、MCP管理 + 基本竞争力：高性能、高可用、零信任、易扩展 ...