Higress MCP 2026-07-28 协议实战验证指南:无状态 HTTP、REST 转换、Legacy 桥接与前置校验
发布时间:2026/9/17 22:29:24来源:尧图网络
Higress MCP 2026-07-28 协议实战验证指南无状态 HTTP、REST 转换、Legacy 桥接与前置校验【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress本篇技术指南以 samples/mcp/protocol/2026-07-28 目录下的 MCP 版本 Demo 手册为核心系统讲解 Higress 对 MCP2026-07-28modern协议基线的实现与验证方法。你将掌握如何在本地 Kind 环境构建固定 commit 的mcp-server插件并通过四个可独立执行的 Demo 逐一验证「无状态 HTTP Tools」「REST-to-MCP 转换」「新版客户端访问 Legacy Server」以及「请求前置校验与阻断」四类核心能力同时结合 mcp-server 插件源码 与 conformance 测试理解其底层实现契约。一、MCP 2026-07-28 基线modern profile 与结果合同Higress 内置的mcp-server插件同时维护两套协议 profile版本目录2026-07-28专门归档 modern 基线Profile精确支持版本生命周期与传输legacy2024-11-05、2025-03-26、2025-06-18保留initialize/notifications/initialized、现有 session 与 HTTP/SSE 兼容行为modern2026-07-28每请求_meta、无 initialize、无协议 session不提供 GET/DELETE/Last-Event-ID 恢复modern profile 本期只实现server/discover、tools/list和tools/call三个 RPC。从 mcp-server 插件 README 可以看到它还会校验 Content-Type、Accept、同源 Origin、JSON-RPC 单消息边界、身份镜像头与资源上限批量、response envelope 和 trailing JSON 会被拒绝。modern 成功结果统一遵守如下结果合同见 能力与结果合同server/discover只声明当前真正可用的tools: {}不声明tools.listChanged、MRTR、subscriptions、resources、prompts 等未实现能力所有 modern 成功结果使用resultType: complete并在_meta.io.modelcontextprotocol/serverInfo携带服务端身份server/discover与tools/list额外返回ttlMs: 0与cacheScope: private仅是 wire contract本期没有 response/descriptor cache 引擎。modern 请求必须同时携带传输头与 body 中的_meta例如MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: get_weather Content-Type: application/json Accept: application/json, text/event-stream{ jsonrpc: 2.0, id: 1, method: tools/call, params: { _meta: { io.modelcontextprotocol/protocolVersion: 2026-07-28, io.modelcontextprotocol/clientInfo: {name: example, version: 1.0.0}, io.modelcontextprotocol/clientCapabilities: {} }, name: get_weather, arguments: {location: Hangzhou} } }二、准备环境与构建固定 commit 插件2.1 前置条件依据 公共环境说明需要Docker 或 PodmanKindkubectlHelmcurljq用于执行各 Demo 的响应断言至少约 4 GiB 可用内存能访问 Higress Helm 仓库和所需镜像仓库。2.2 构建插件并启动环境从 Higress 仓库根目录执行cd samples/mcp ./protocol/2026-07-28/plugin/build.sh ./environment/scripts/up.shbuild.sh的构建逻辑见 plugin/build.sh自动探测可用的容器引擎优先 Docker其次 Podman无可用引擎时报错退出若.runtime/container-engine已存在即环境已启动会拒绝重建插件避免挂载中的 WASM 被覆盖使用 plugin/Dockerfile 构建镜像基于golang:1.24.4-alpine在构建阶段git init后fetch --depth1拉取固定源码并以GOOSwasip1 GOARCHwasm交叉编译 mcp-server 扩展 为 WASM运行产物镜像把plugin.wasm拷入挂载目录.runtime/plugins/mcp-server/2026-07-28/同时写入source-commit.txt与SHA256SUMS供溯源核对。插件默认从以下固定源码构建定义于 plugin/source.envhttps://github.com/higress-group/higress.git 14c36d9bd70b3dc38237cda6175b3f9dede0dccd构建结果写入.runtime/plugins/mcp-server/2026-07-28/plugin.wasmKind 节点和 Higress Gateway 通过公共环境提供的 hostPath 看到该文件因此所有 Demo 的WasmPlugin都引用file:///opt/plugins/mcp-server/2026-07-28/plugin.wasmup.sh会依次完成见 公共环境说明创建名为higress-mcp-demo的 Kind 集群、将.runtime/plugins挂载到节点/opt/plugins、使用固定 Helm Chart2.2.3安装 Higress、部署协议无关的observable-weatherHTTP 服务、建立端口转发。环境地址地址用途http://127.0.0.1:18080Higress Gatewayhttp://127.0.0.1:18081Higress Consolehttp://127.0.0.1:18082可观察 HTTP 后端http://127.0.0.1:18082/__state查询后端调用记录POST http://127.0.0.1:18082/__reset清空后端调用记录2.3 使用其他源码版本编辑plugin/source.env或在执行前覆盖其中的变量三个均可覆盖仓库、commit、构建镜像MCP_DEMO_HIGRESS_REPOSITORYhttps://github.com/owner/higress.git \ MCP_DEMO_HIGRESS_REFcommit-sha \ ./protocol/2026-07-28/plugin/build.sh环境侧同样支持覆盖MCP_DEMO_CLUSTER、MCP_DEMO_GATEWAY_PORT、MCP_DEMO_CONSOLE_PORT、MCP_DEMO_BACKEND_PORT、MCP_DEMO_KIND_NODE_IMAGE与MCP_DEMO_HIGRESS_CHART_VERSION避免端口冲突或多环境并存。2.4 状态检查与清理./environment/scripts/status.sh # 显示 higress-system、mcp-demo Pod 与三个端口转发状态 ./environment/scripts/down.sh # 停止端口转发并删除由本 Demo 创建的 Kind 集群清理时构建产物保留在.runtime/plugins便于复用该目录不提交到 Git。三、Demo 一览Demo验证特性01 Stateless HTTP无 initialize、无协议 Session 的 discover/list/call02 REST-to-MCP将 MCP Tool 调用转换成一次普通 REST 请求03 Modern-to-Legacyrequest-scoped legacy handshake、结果适配和 Header 隔离04 Request Validation参数、Origin、Header/Body 一致性校验以及后端零调用各 Demo 可独立执行进入任一目录部署资源、发送请求、观察证据并清理即可。下面逐一展开。四、Demo 01无状态 HTTP Tools本 Demo 验证 modern 客户端可以通过独立 HTTP 请求完成server/discover、tools/list和tools/call不需要initialize也不会获得协议 Session。完整指引见 01-stateless-http README。4.1 前置与部署cd protocol/2026-07-28/01-stateless-http export GATEWAY_URLhttp://127.0.0.1:18080/mcp export MCP_HOSTstateless.mcp.demo kubectl apply -f resources.yaml kubectl get ingress -n mcp-demo mcp-2026-stateless-http kubectl get wasmplugin -n higress-system mcp-2026-stateless-http等待几秒让 Higress Controller 将配置下发到 Gateway。resources.yaml中的 WasmPlugin 通过server.type: rest声明一个纯静态 REST Server用responseTemplate.body定义返回文本见 01 resources.yamlspec: defaultConfigDisable: true matchRules: - config: server: name: stateless-demo type: rest version: 1.0.0 tools: - name: say_hello description: Return a deterministic greeting args: - name: name description: Name to greet type: string required: true responseTemplate: body: hello {{.args.name}} configDisable: false ingress: - mcp-demo/mcp-2026-stateless-http url: file:///opt/plugins/mcp-server/2026-07-28/plugin.wasmresponseTemplate.body支持{{.args.name}}这样的模板变量把 Tool 参数渲染进响应文本——这正是「无后端、纯网关托管工具」的配置方式。4.2 Step 1发现 Servercurl -sS $GATEWAY_URL \ -H Host: $MCP_HOST \ -H Origin: http://$MCP_HOST \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H MCP-Protocol-Version: 2026-07-28 \ -H Mcp-Method: server/discover \ -H X-Request-ID: demo-stateless-discover \ --data-binary requests/discover.json | jqrequests/discover.json是一个标准 JSON-RPC 2.0 请求params._meta声明协议版本、clientInfo 与 clientCapabilities见 discover.json{ jsonrpc: 2.0, id: stateless-discover, method: server/discover, params: { _meta: { io.modelcontextprotocol/protocolVersion: 2026-07-28, io.modelcontextprotocol/clientInfo: { name: higress-mcp-demo, version: 1.0.0 }, io.modelcontextprotocol/clientCapabilities: {} } } }预期结果包含result.resultType complete result.capabilities {tools: {}} result.ttlMs 0 result.cacheScope private result._meta.io.modelcontextprotocol/serverInfo.name stateless-demo注意 capabilities 只声明tools: {}与插件 README 的「只声明当前真正可用的能力」一致。4.3 Step 2列出工具curl -sS $GATEWAY_URL \ -H Host: $MCP_HOST \ -H Origin: http://$MCP_HOST \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H MCP-Protocol-Version: 2026-07-28 \ -H Mcp-Method: tools/list \ -H X-Request-ID: demo-stateless-list \ --data-binary requests/list-tools.json | jq .result工具列表中应只有say_hello并继续携带resultType: complete、ttlMs: 0和cacheScope: private。4.4 Step 3调用工具并检查 Sessioncurl -sS -D /tmp/mcp-stateless-headers \ $GATEWAY_URL \ -H Host: $MCP_HOST \ -H Origin: http://$MCP_HOST \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H MCP-Protocol-Version: 2026-07-28 \ -H Mcp-Method: tools/call \ -H Mcp-Name: say_hello \ -H X-Request-ID: demo-stateless-call \ --data-binary requests/call-tool.json | jq调用say_hello参数name: Higress的预期文本为hello Higress。响应头中不应包含协议 Sessionif grep -qi ^Mcp-Session-Id: /tmp/mcp-stateless-headers; then echo unexpected MCP session else echo no MCP session returned fi三次请求之间没有 initialize 或 Session 依赖每一个请求都可以独立执行——这就是「无状态 HTTP Tools」的核心特征。4.5 Step 4查看网关证据kubectl logs -n higress-system deployment/higress-gateway --tail200 | grep demo-stateless || true清理kubectl delete -f resources.yaml五、Demo 02REST-to-MCP本 Demo 验证 Higress 将一个 MCPtools/call转换为一次普通 REST 请求并通过协议无关后端的事件账本证明没有重复调用。完整指引见 02-rest-to-mcp README。5.1 前置与部署cd protocol/2026-07-28/02-rest-to-mcp export GATEWAY_URLhttp://127.0.0.1:18080/mcp export BACKEND_URLhttp://127.0.0.1:18082 export MCP_HOSTrest-to-mcp.mcp.demo kubectl apply -f resources.yaml curl -sS -X POST $BACKEND_URL/__reset | jq该 Demo 的 WasmPlugin 与 Demo 01 的关键差异是增加了requestTemplate见 02 resources.yamlserver: name: weather-demo type: rest version: 1.0.0 tools: - name: get_weather description: Query deterministic weather args: - name: location description: City name type: string required: true requestTemplate: url: http://observable-weather.mcp-demo.svc.cluster.local:8080/weather method: GET argsToUrlParam: truerequestTemplate声明工具调用要转换成的 REST 请求url指向集群内observable-weather服务method: GETargsToUrlParam: true表示把 Tool 参数合并进 URL query。从 main_test.go 测试 可以看到requestTemplate的合法组合还包括argsToJsonBody: true参数作为 JSON body以及无参数工具的纯 URL 模板。后端observable-weather是一个协议无关的可观察 HTTP 服务见 server.py只实现GET /weather?locationcity、GET /healthz、GET /__state、POST /__reset它不理解 MCP 版本、JSON-RPC 方法或 Session——正好用于证明转换后的流量是「普通 REST」。5.2 Step 1查看发布的 REST Toolcurl -sS $GATEWAY_URL \ -H Host: $MCP_HOST \ -H Origin: http://$MCP_HOST \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H MCP-Protocol-Version: 2026-07-28 \ -H Mcp-Method: tools/list \ -H X-Request-ID: demo-rest-list \ --data-binary requests/list-tools.json | jq .result.tools应看到必填参数为location的get_weather这是从args声明生成的 tool schema。5.3 Step 2调用 Toolcurl -sS $GATEWAY_URL \ -H Host: $MCP_HOST \ -H Origin: http://$MCP_HOST \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H MCP-Protocol-Version: 2026-07-28 \ -H Mcp-Method: tools/call \ -H Mcp-Name: get_weather \ -H X-Request-ID: demo-rest-call \ --data-binary requests/call-weather.json | jqcall-weather.json传入arguments: {location: Hangzhou}见 call-weather.json。响应应包含weather for Hangzhou和resultType: complete。5.4 Step 3证明只有一次 REST 调用curl -sS $BACKEND_URL/__state | jq事件账本应只有一条{ httpMethod: GET, path: /weather, query: {location: Hangzhou} }可以直接检查事件数量curl -sS $BACKEND_URL/__state | jq -e .events | length 1server.py的record_event会为每个到达/weather的请求写入httpMethod、path、query与递增的seq因此「恰好一条事件」直接证明一个 MCPtools/call只产生一次 REST 上游调用不存在重试或重复转发。清理kubectl delete -f resources.yaml。六、Demo 03新版客户端访问 Legacy MCP Server本 Demo 验证新版无状态客户端通过 Higress 访问 MCP2025-03-26ServerHigress 在每个下游请求内部执行隔离的 legacy handshake同时适配新版结果合同并阻止敏感下游 Header 穿越协议边界。完整指引见 03-modern-to-legacy README。6.1 部署 Legacy MCP fixturefixture 使用python:3.12-alpinePython 源码通过 ConfigMap 挂载kubectl -n mcp-demo create configmap legacy-mcp-fixture \ --from-fileserver.pyfixture/legacy_server.py \ --dry-runclient -o yaml | kubectl apply -f - kubectl apply -f fixture/deployment.yaml kubectl -n mcp-demo rollout status deployment/legacy-mcp --timeout180s部署 Higress 路由和 MCP Proxy并清空 fixture 事件kubectl apply -f resources.yaml kubectl -n mcp-demo exec deployment/legacy-mcp -- python -c \ import urllib.request; urllib.request.urlopen(urllib.request.Request(http://127.0.0.1:8080/__reset, datab, methodPOST))这个 WasmPlugin 演示了mcp-proxy 模式见 03 resources.yamlserver: name: legacy-bridge-demo type: mcp-proxy transport: http protocolStrategy: legacy mcpServerURL: http://legacy-mcp.mcp-demo.svc.cluster.local:8080/legacy tools: - name: proxy_echo description: Echo a deterministic value through a legacy MCP server args: - name: value description: Value to echo type: string required: true关键字段说明对照 插件 README 的 Proxy 配置示例type: mcp-proxy网关作为 MCP 代理转发上游transport: http上游传输为 HTTPJSON-RPC over POSTprotocolStrategy: legacy上游是 legacy profile需要在单次下游交换内执行隔离的 legacy handshakemcpServerURL上游 MCP Server 端点。6.2 Step 1用新版请求列出 Legacy Toolcurl -sS -D /tmp/mcp-bridge-list-headers \ $GATEWAY_URL \ -H Host: $MCP_HOST \ -H Origin: http://$MCP_HOST \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H MCP-Protocol-Version: 2026-07-28 \ -H Mcp-Method: tools/list \ -H Cookie: downstream-cookiesecret \ -H Mcp-Session-Id: downstream-session \ -H Last-Event-ID: downstream-event \ -H Authorization: Bearer downstream-not-policy \ -H x-unrelated-credential: should-not-pass \ -H Mcp-Param-Future: must-not-cross-era \ -H X-Request-ID: demo-bridge-list \ --data-binary requests/list-tools.json | jq这个请求故意携带了一批敏感/伪造 HeaderCookie、下游Mcp-Session-Id、Last-Event-ID、Authorization、无关凭据、未来的Mcp-Param-Future用于验证 Header 隔离。客户端应看到新版合同proxy_echo、resultType: complete、ttlMs: 0和cacheScope: private。响应头不应暴露上游 Sessiongrep -i ^Mcp-Session-Id: /tmp/mcp-bridge-list-headers || echo upstream session is hidden6.3 Step 2调用 Legacy Toolcurl -sS -D /tmp/mcp-bridge-call-headers \ $GATEWAY_URL \ -H Host: $MCP_HOST \ -H Origin: http://$MCP_HOST \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H MCP-Protocol-Version: 2026-07-28 \ -H Mcp-Method: tools/call \ -H Mcp-Name: proxy_echo \ -H Cookie: downstream-cookiesecret \ -H Mcp-Session-Id: downstream-session \ -H Last-Event-ID: downstream-event \ -H Authorization: Bearer downstream-not-policy \ -H x-unrelated-credential: should-not-pass \ -H Mcp-Param-Future: must-not-cross-era \ -H X-Request-ID: demo-bridge-call \ --data-binary requests/call-tool.json | jq预期结果为echo:bridge、isError: false和resultType: complete。6.4 Step 3检查精确握手序列kubectl -n mcp-demo exec deployment/legacy-mcp -- python -c \ import urllib.request; print(urllib.request.urlopen(http://127.0.0.1:8080/__state).read().decode()) | jq两次下游请求应产生严格的六个上游事件initialize notifications/initialized tools/list initialize notifications/initialized tools/call可以直接断言kubectl -n mcp-demo exec deployment/legacy-mcp -- python -c \ import urllib.request; print(urllib.request.urlopen(http://127.0.0.1:8080/__state).read().decode()) | jq -e [.events[].rpcMethod] [initialize,notifications/initialized,tools/list,initialize,notifications/initialized,tools/call]事件中的cookiePresent、lastEventIDPresent、authorizationPresent、unrelatedCredentialPresent应全部为falsefutureParam应为null——证明下游敏感 Header 没有穿越协议边界。Legacy handshake 自己产生的Mcp-Session-Id只在上游交换中使用客户端不可见。从 legacy_server.py 可以看到这个 fixture 每次请求都会记录rpcMethod、protocolVersion、mcpMethod、futureParam以及五个布尔位authorizationPresent、cookiePresent、sessionPresent、lastEventIDPresent、unrelatedCredentialPresent并对initialize返回Mcp-Session-Id: fixture-upstream-session响应头——这正是用于核对握手序列与 Header 隔离的「可观察上游」。同时注意protocolStrategy只描述上游 profile是显式配置现有未配置protocolStrategy的mcp-proxy继续默认使用legacy只有确认上游支持2026-07-28时才应显式切换为modern见 迁移与默认行为。清理kubectl delete -f resources.yaml kubectl delete -f fixture/deployment.yaml kubectl -n mcp-demo delete configmap legacy-mcp-fixture七、Demo 04请求校验与前置阻断本 Demo 验证三类错误在触达 REST 后端前被 Higress 拒绝Tool 参数缺失、恶意跨域 Origin、Mcp-Method与 JSON-RPC Body 不一致。完整指引见 04-request-validation README。7.1 前置cd protocol/2026-07-28/04-request-validation export GATEWAY_URLhttp://127.0.0.1:18080/mcp export BACKEND_URLhttp://127.0.0.1:18082 export MCP_HOSTvalidation.mcp.demo kubectl apply -f resources.yaml curl -sS -X POST $BACKEND_URL/__reset | jq该 Demo 的 WasmPlugin 配置与 Demo 02 相同REST 天气工具argsToUrlParam: true见 04 resources.yaml。7.2 Step 1缺少必填 Tool 参数curl -sS -w \nHTTP %{http_code}\n $GATEWAY_URL \ -H Host: $MCP_HOST \ -H Origin: http://$MCP_HOST \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H MCP-Protocol-Version: 2026-07-28 \ -H Mcp-Method: tools/call \ -H Mcp-Name: get_weather \ -H X-Request-ID: demo-validation-arguments \ --data-binary requests/invalid-arguments.jsoninvalid-arguments.json的arguments为空对象见 invalid-arguments.json。预期 HTTP 为200因为这是一个合法 Tool 调用的执行结果JSON-RPC Result 中应有isError: true和缺少location的说明。这区分了「Tool 执行错误」仍返回合法 RPC 结果与「传输边界错误」直接以 HTTP 状态码拒绝。7.3 Step 2恶意 Origincurl -sS -w \nHTTP %{http_code}\n $GATEWAY_URL \ -H Host: $MCP_HOST \ -H Origin: https://hostile.invalid \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H MCP-Protocol-Version: 2026-07-28 \ -H Mcp-Method: tools/list \ -H X-Request-ID: demo-validation-origin \ --data-binary requests/list-tools.json预期 HTTP403错误消息为untrusted Origin。modern profile 要求同源 Origin请求中的Origin必须与Host匹配跨域来源在传输边界被直接拒绝。7.4 Step 3Header 与 Body 不一致下面的 Body 是tools/list但 Header 声明tools/callcurl -sS -w \nHTTP %{http_code}\n $GATEWAY_URL \ -H Host: $MCP_HOST \ -H Origin: http://$MCP_HOST \ -H Content-Type: application/json \ -H Accept: application/json, text/event-stream \ -H MCP-Protocol-Version: 2026-07-28 \ -H Mcp-Method: tools/call \ -H X-Request-ID: demo-validation-mismatch \ --data-binary requests/list-tools.json预期 HTTP400、JSON-RPC error code-32020错误消息包含header does not match request body。这两类传输边界错误在 conformance_test.go 中有明确的契约断言第 265 行headerMismatchAtHeaders期望HTTPStatus: 400, Code: -32020, Message: MCP header does not match request body第 302 行hostileOrigin期望403, untrusted Origin。运行go test -count1 ./...即可复现这些断言见 可复现验证。7.5 Step 4证明后端调用数为零curl -sS $BACKEND_URL/__state | jq curl -sS $BACKEND_URL/__state | jq -e .events | length 0这一步确认三种错误都在后端调用前结束——校验发生在网关侧流量从未到达observable-weather。清理kubectl delete -f resources.yaml。八、源码级契约插件实现与边界上述四个 Demo 不是孤立的脚本而是 mcp-server 插件 行为的端到端投影。理解以下几点有助于把 Demo 证据与实现契约对应起来8.1 Proxy profile 矩阵protocolStrategy只描述上游 profile本期是显式配置DownstreamUpstream当前状态modernregistered / REST / composed支持modernprotocolStrategy: modern支持每请求无状态转发modernprotocolStrategy: legacy支持在单次下游交换内执行隔离的 legacy handshakelegacylegacy upstream保留现有行为legacymodern-only upstream不支持已暂缓Demo 01/02/04 对应「modern → registered / REST」Demo 03 对应「modern → legacy」。8.2 Outbound Header 隔离Outbound headers 按每个 RPC 重建。Authorization只会根据显式 proxy auth policy 生成或转发Cookie、下游 session、Last-Event-ID、内部路由头和无关凭据默认不转发。未识别但格式合法的Mcp-Param-*仅在 modern→modern 的当前 Tool RPC 中透传不得进入 discover、initialize 或 legacy RPC见 插件 README 的 Header 规则——这正是 Demo 03 中futureParam: null的依据。8.3 明确暂缓范围层级不属于本期的能力Deferred P1protocolStrategy: auto、2025-11-25profile、完整 JSON Schema 2020-12 与 output validation、大规模 tools pagination/cursor、legacy downstream→modern-only bridgeDeferred P2MRTR /input_required生成、subscriptions/listen 与tools.listChanged、通用 state/requestState 的 TTL、持久化与恢复Separate Proposal完整 OAuth resource server/client、Tasks、MCP Apps、Resources、Prompts、Completion了解这些边界可以避免在验证 Demo 时对未实现能力产生错误预期。九、版本目录的组织约定与扩展方式samples/mcp目录的设计目标是「可运行、可复现」见 MCP Demo 首页环境完整用 Kind、Helm 拉起 Higress Controller、Gateway、CRD 和 Console公共依赖复用协议无关的集群、Higress 配置和模拟业务后端统一放在environment/版本边界明确协议相关的插件源码 commit、构建方式和 Demo 归档在protocol/version/逐步可验证每个 Demo 都是一份独立 README说明验证目标、操作步骤、预期响应和网关/后端证据独立执行读者可选择关心的能力按 README 完成实验。新增协议版本时在protocol/version/plugin/记录实现该版本的 Higress commit 与构建方法新增 Demo 时一个目录只验证一个主要能力提供中英文 README、确定性请求与预期证据不依赖真实凭据或私有服务也不提交生成的 WASM、运行日志与临时证据。十、快速上手总览# 从 Higress 仓库根目录执行 cd samples/mcp # 1. 构建目标协议版本对应的 MCP Server 插件固定 commit 14c36d9 ./protocol/2026-07-28/plugin/build.sh # 2. 拉起公共 Higress 环境Kind Helm observable-weather 后端 ./environment/scripts/up.sh # 3. 选择一个 Demo按其 README 逐步验证 less ./protocol/2026-07-28/01-stateless-http/README.md # 4. 全部实验完成后清理环境 ./environment/scripts/down.sh对照四个 Demo 与源码可以形成完整闭环Demo 01验证 modern 无状态 RPC 与结果合同resultType: complete、ttlMs: 0、cacheScope: private、serverInfoDemo 02验证requestTemplate的 REST 转换与「一次调用、一次上游」Demo 03验证mcp-proxyprotocolStrategy: legacy的隔离 handshake 与 Header 隔离Demo 04验证参数、Origin、Header/Body 三类前置校验。每个 Demo 的断言命令都直接依赖jq与后端的__state事件账本证据可复核、结果可复现适合作为 MCP 协议实现验收与回归测试的基准手册。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
网站建设高端定制企业官网