MCP Gateway Runtime

wiki/ai/concepts/MCP-Gateway-Runtime.md

分类：ai / concepts · 更新：2026-11-02 09:18 最近更新

MCP Gateway Runtime

每跳实际消费与评测边界： pega-a2a-card-discovery-and-delivery-evidence（A2A / harness-runtime / benchmark-evaluation；关联MCP Gateway / sandbox-security）补Card/健康GET≠执行POST、200≠可解析/用户交付，以及发现/执行凭据分配。secprbench-causal-judge-snapshot-and-containment（sandbox-security / benchmark-evaluation / harness-runtime）补reviewer字段allowlist、私有身份映射/元数据mount外、网络startup gate及失败不能转空成功；文档/固定关键段与7项呈现纯函数检查不是containment或网关实测。Forge逐call/pre-post合同仅raw，与现有逐跳/拒绝零effect机制复用，不另造产品介绍。^[raw/articles/pega-a2a-card-discovery-and-delivery-case-2026-11-02.md] ^[raw/articles/secprbench-causal-judge-snapshot-and-containment-pinned-2026-11-02.md]

目录声明、下一次调用与真实授权： cognigy-a2a-discovery-tool-filter-and-task-contract（A2A / harness-runtime / sandbox-security / context management；关联MCP Gateway）把Card可取/执行凭据、描述skill过滤/Flow强制授权分验，不能用单tool描述掩盖远端动作面。skilllifebench-invoked-code-binding-and-recovery（sandbox-security / benchmark-evaluation / harness-runtime）补selected/loaded/invoked与旧handle失效：registry已更新不证明下一次调用已消费。二者是文档/作者控制实验，不是本机网关验证；Aembit public/proxy说明只raw补证，与旧出口合同复用，不新增薄介绍。^[raw/articles/cognigy-a2a-discovery-tool-filter-and-task-contract-2026-11-01.md] ^[raw/articles/skilllifebench-invoked-binding-and-recovery-2610-35215v1-2026-11-01.md]

服务client、用户context与实际gate： erebots-a2a-conformance-owner-resume-and-consent（A2A / harness-runtime / sandbox-security / benchmark-evaluation；关联 MCP Gateway）展示A2A委托/MCP执行组合，但service Bearer的azp只证明允许client，模型参数user_id被覆盖仍依赖context可信来源；consent字段不等于commit前强制授权。续办可能重放问前工具，持久task不证明副本协调/业务幂等；Card/TCK与auth-on负例分验，不把示例关闭认证配置用于生产，也不宣称四协议联邦已实测。^[raw/articles/erebots-a2a-tck-owner-resume-pinned-2026-10-31.md]

发现缓存与下一跳接收权： mastra-a2a-card-cache-signature-and-task-boundaries（A2A / harness-runtime / sandbox-security / benchmark-evaluation；关联 MCP Gateway）提示Card可信、cache仍有效、当前dispatch被授权、目标有权接收Bearer是四个不同断言。固定核心客户端从Card.url选execution endpoint并共用headers路径，不能以签名成功替代origin/audience/策略撤销；仅静态审查点，非已验证外泄或用户实例漏洞。与旧逐backend header、issuer和授权根合同合用，不修改生产凭据或网关。^[raw/articles/mastra-a2a-card-bootstrap-signature-and-task-store-pinned-2026-10-30.md]

跨域bridge的身份与资源双门： sap-a2a-bridge-principal-resource-and-task-boundaries（A2A / MCP Gateway / harness-runtime / sandbox-security / benchmark-evaluation）将用户断言、应用签名身份、resource换发、consumer allow-list与最终业务权限拆开；wire为JWT-bearer grant，不因token-exchange标题改写协议字段。bridge无静态secret不代表全系统无secret；SAP对外A2A与内部MCP/REST背景不拼成四协议联邦已实测。官方配方/固定样例非用户部署证据，真实audience、撤销和拒绝后零effect另验。^[raw/articles/sap-a2a-gateway-user-client-resource-binding-pinned-2026-10-29.md]

逐接收方凭据边界： envoy-mcp-header-policy-and-oauth-issuer-binding（MCP Gateway / sandbox-security / harness-runtime / benchmark-evaluation）把Envoy 1.40逐backend默认不转发、deny优先与SDK OAuth metadata issuer/旧注册归属分开；header allow不等于audience换发，升级SDK不代替issuer=与旧存储迁移。release/固定代码/上游测试阅读不是本机执行或用户实例暴露证据。^[raw/articles/envoy-140-backend-header-forwarding-pinned-2026-10-28.md] ^[raw/articles/mcp-python-oauth-issuer-credential-binding-advisory-2026-10-28.md]

有效token不是资源授权： unla-oauth-token-validity-versus-resource-authorization（MCP Gateway / sandbox-security / harness-runtime / benchmark-evaluation）把client注册、可信resource owner/服务主体准入、code交换与实际prefix/tool/action验权拆开；PKCE/client secret不补回缺失的授权根，存储中存在且未过期不证明允许当前资源。固定版本及当前main三文件相等仅为静态证据，外层身份代理、实际有效配置和授权负例/零上游副作用仍需隔离验收，不推定用户现网暴露。^[raw/articles/unla-oauth-resource-owner-and-prefix-binding-2026-10-27.md]

命名空间生命周期与健康分账： contextforge-tool-namespace-lifecycle-and-reachability（MCP Gateway / harness-runtime / sandbox-security / benchmark-evaluation）固定ContextForge v1.1.0最终tag，按实际slug调用名、scope、rename/refresh及保留alias核冲突；普通刷新不回溯修好全部历史重复，validation guard不证明并发唯一性。上游reachable与catalog refresh被拒绝可同时成立，最终调用对象/缓存和DB事务另验；未部署或跑上游pytest。^[raw/articles/contextforge-110-tool-namespace-collision-fixed-2026-10-26.md]

撤销时间线与发现/调用分验： redhat-mcp-revocation-timing-and-discovery 区分角色移除、新旧JWT、signed工具列表header与已进入backend的请求；tools/list隐藏不代替tools/call拒绝，示例300秒header寿命不是全链路撤销SLA。官方1.3文档提供机制证据，未连接集群或执行跨网关撤销E2E。^[raw/articles/redhat-mcp-revocation-timing-selected-2026-09-24.md]

认证回退与目标集合： litellm-auth-fallback-and-gateway-blast-radius 把本地认证失败、指定上游透传和已验证身份分开；空/未知/混合目标拒绝回退，目标头优先级仍须与真实数据面一致。MCP访问不等于管理员权限，不能把独立风险拼成必然接管链。21项合成方法fixture不代替上游OAuth/路由E2E。^[raw/articles/litellm-auth-fallback-fixed-code-2026-09-23.md] ^[raw/articles/litellm-wiz-auth-boundaries-2026-09-23.md]

组合合同与最终提交： continuity-security-context-contracts-and-finality 要把授权根、字段来源、阶段角色和合法变换保持到实际effect；签名不代替角色授权，提交时仍核policy/撤销。固定原型本机30项pytest通过，但内存ledger/模拟sink不证明跨网关撤销传播或持久化exactly-once，不是MCP生产集成。^[raw/articles/continuity-security-context-contracts-2026-09-18.md]

协议状态与执行对象： mcp-mrtr-state-and-header-integrity 补全2026-07-28规范：MRTR回传状态必须当不可信输入，影响授权/业务时保护完整性；principal/TTL/请求绑定不自动实现single-use，最多一次消费仍需服务端约束。按镜像头做策略须核协议版本与头体一致；400不能无条件触发旧版降级。本轮规范阅读/编码复算，不是网关E2E。^[raw/articles/mcp-mrtr-state-and-header-integrity-2026-09-16.md]

请求对象一致性： agentgateway-session-policy-and-inspection-boundaries 将 session 保存的 backend、当前 route policy、完整 body 和转换后的最终请求分验；有状态跨 backend 修复不证明同组授权/注销也正确，缺 body 的 deny 失败不能当安全。release 字段文案与固定实现不同，source 保留 contested；只有源码/条件检查，未运行 Rust 回归。^[raw/articles/agentgateway-session-policy-and-inspection-boundaries-2026-09-15.md]

执行前边界： gemini-cli-oauth-bootstrap-and-workspace-trust 将 OAuth discovery 的内网出站与不可信仓库的 MCP/policy/telemetry 装载前置检查。DNS 预检不自动证明连接 IP 绑定；restricted 标记的实际优先级也不能从 PR 标题推出。规范、最终实现和真实下游请求分别取证。^[raw/articles/gemini-cli-oauth-bootstrap-and-workspace-trust-2026-09-14.md]

身份与凭证边界： enterprise-mcp-persona-credential-boundaries 将 User/Non-user 与下游 credential 分轴，强调 User→SA 必须在附加凭证前验 entitlement。论文的机器 ROPC 做法与 RFC 9700 §2.4 冲突；RFC 8693 历史 act 仅作信息记录，不是双边授权证明，撤销也不会自动传播。详细标准对照与 contested 标记保留在 source。^[raw/articles/enterprise-mcp-persona-credential-boundaries-2026-09-12.md] ^[raw/articles/rfc9700-oauth-security-selected-sections-2026-09-12.md] ^[raw/articles/rfc8693-token-exchange-selected-sections-2026-09-12.md]

联邦取证边界： a2a-output-attestation-and-delegation-ancestry 将 released bytes、祖先路径与跨 deployer 双边授权分成不同证据。Gateway 的 trace ID/凭据不自动证明父方同意；本地 nonce 去重不自动成为跨 gateway 防重放。若采用双签，应另验公钥准入、在线 co-sign、撤销传播和独立业务状态，而不是只增加一条审计日志。^[raw/articles/a2a-output-attestation-and-delegation-ancestry-2026-09-11.md]

边界反例： [[grafana-mcp-session-identity-and-egress-boundaries

Grafana MCP]] 说明 session 格式不是身份，凭据不外发也不等于出站受限；入站认证、工具授权、凭据绑定、实际目的地需分别验证。[[pillar-docker-socket-sandbox-trust-handoff

Docker daemon 旁路]] 提醒：控制面还要覆盖 agent 能借用的内网/本地代理权限，不只检查直接工具调用。^[raw/articles/grafana-mcp-session-identity-and-egress-boundaries-2026-09-10.md] ^[raw/articles/pillar-docker-socket-sandbox-trust-handoff-2026-09-10.md]

定义

MCP Gateway Runtime 指把远程 MCP 工具调用放到网关层治理的运行时形态：客户端、Agent、工具服务器不再只是一条点对点长会话链路，而是通过网关承载协议版本协商、工具发现、路由、鉴权、限流、计量、Schema 校验、状态隔离和新旧协议桥接。

[[higress-mcp-gateway-api-inference-extension

Higress v2.2.4 的案例]]显示，MCP 2026-07-28 的无状态 HTTP Tools 基线会把远程工具调用从“先 initialize、再依赖 Session ID 续会话”推向“每个请求带齐协议版本、客户端身份和能力”的模式。这样更适合横向扩容：请求可以落到任意后端实例，网关也更容易在解析完整 JSON Body 前基于 Header 做路由、鉴权、限流和计量。

为什么重要

Agent 工程里的工具调用一旦进入生产，问题就不再只是“模型会不会调用工具”，而是：工具服务器能否横向扩容，旧 MCP Server 如何兼容，新客户端如何逐步迁移，工具入参错误是否能在边界被拦截，Cookie / Session / 内部路由 Header 是否会跨服务泄漏。

这使 MCP Gateway 成为 Harness-Engineering 的基础设施层：它把工具使用从 prompt 约束提升到可执行的网络边界和协议边界。对 Hermes 来说，MCP Server、REST 工具、内部管理 API、外部 SaaS 工具都不应裸暴露给长期 Agent loop；更稳的形态是通过 gateway/runtime 统一收口，保留可观测、可限流、可回滚、可审计的轨迹。

关键设计点

无状态请求优先：每次工具调用自带协议版本、客户端身份和能力，减少对协议级 Session 的依赖。
显式桥接路径：modern 到 modern、modern 到 legacy、legacy 到 legacy 应该是显式策略，而不是升级时静默切换。
边界前置校验：Origin、媒体类型、请求大小、JSON-RPC 消息、Header/Body 一致性、输入 Schema 应尽量在网关边界被验证。
状态与凭据隔离：默认隔离 Cookie、Session、Last-Event-ID、内部路由 Header 和无关凭据，避免代理层把一个工具的状态泄漏到另一个工具。
数据面可验证：如果控制面或 Endpoint Picker 选出了目标端点，数据面必须能证明请求实际送到了对应 PodIP:port 或给出真实 served endpoint。

与推理网关的关系

MCP Gateway 处理的是 Agent 工具调用的协议与治理边界；Gateway API Inference Extension 处理的是大模型推理流量如何落到正确模型端点。二者共同说明：AI 基础设施正在从“把 HTTP 请求转发出去”升级为“理解 Agent 工具、模型端点、队列、缓存、LoRA Adapter、数据并行端口和验证回传”的控制面。

这和 Context-Engineering 也有关：工具列表、工具 schema、协议版本、服务能力发现结果，本身就是 Agent 的上下文。它们应当由 runtime 可靠提供，而不是靠提示词里手写一段过期说明。

开放问题

MCP 2026-07-28 的 Resources、Prompts、Tasks、Subscriptions、MCP Apps、完整 OAuth 等能力在生产网关中如何分阶段落地。
Gateway 如何为不同风险等级的工具提供不同策略：只读、需审批、需 sandbox、需审计回放。
Hermes 若接入更多 MCP Server，应该优先把哪些工具放到统一 gateway policy 下，而不是逐个工具靠 prompt 防误用。

写入记录

2026-08-20 19:24 CST：根据阿里云云原生 Higress v2.2.4 文章新增概念页，提炼 MCP Gateway Runtime 对 Agent 工具调用、协议桥接和推理网关治理的意义。

2026-09-01 补充：从 MCP 聚合到 MCP / A2A / REST / gRPC 联邦控制面

[[ibm-contextforge-mcp-federation-control-plane

IBM ContextForge]] 补充了 MCP Gateway Runtime 的协议联邦维度：gateway 不只代理 MCP server，也可能把 A2A server、REST/gRPC API、OpenAI/Anthropic agent routing、tools/prompts/resources registry、Admin UI、auth、rate limiting、retry、OTel/Prometheus observability 与 Redis/Kubernetes federation 收到同一个控制面。

这和 [[toolhive-enterprise-mcp-runtime

ToolHive]]、[[gate22-mcp-gateway-control-plane

Gate22]]、[[agentflow-flow-centric-agent-security-policy

AgentFlow]] 形成互补：ToolHive 强调企业 registry/runtime/portal，Gate22 强调 bundle/allow-list，AgentFlow 强调信息流策略，而 ContextForge 强调异构后端联邦与跨 gateway trust。对 Hermes 来说，未来 tool registry 不应只记录“这是 MCP server”，还应记录 backend protocol、identity model、credential boundary、policy surface、trace destination、federation risk 和 tool routing explainability。

ContextForge README 中的 UAID cross-gateway routing 安全要求也应进入 Hermes 的高风险工具接入门槛：跨 gateway 调用必须显式 domain allowlist、JWT trust、AUTH_REQUIRED=true、UAID_FORWARD_AUTH=true，默认 fail-closed，并保留 source gateway / user audit trail。否则联邦 gateway 会把多个系统的 blast radius 合并到一个 agent-facing endpoint。

写入记录

2026-09-01 09:00 CST：补充 IBM ContextForge 对 MCP/A2A/REST/gRPC 联邦控制面、跨 gateway trust、观测 receipt 与 Hermes tool registry 字段的启发。

2026-08-22 补充：从协议网关到组织级工具控制面

[[gate22-mcp-gateway-control-plane

Gate22]] 补充了 MCP Gateway Runtime 的组织治理维度：管理员接入远程 MCP server 后，不是把全部工具直接暴露给 agent，而是定义凭据模式、function-level allow list 和可组合 bundle；开发者得到的是一个统一 MCP endpoint，工具面可被压缩为 search/execute，同时保留审计路线。

这把 [[higress-mcp-gateway-api-inference-extension

Higress v2.2.4]] 所强调的协议/数据面治理推进到团队工作流：MCP gateway 不只是负载均衡或协议桥接，也是权限、凭据、上下文压缩、工具 diff、审计和未来预算控制的控制面。Hermes 若把多个内部 API、文件、GitHub、浏览器、数据库工具接进长期 loop，应优先按风险分 bundle，而不是让每个 cron 都继承全量工具面。

写入记录

2026-08-22 09:30 CST：补充 Gate22 对 MCP Gateway Runtime 的组织级权限、bundle 和审计启发。

2026-08-23 补充：Kubernetes MCP Gateway 的数据面/控制面分离

[[microsoft-mcp-gateway-kubernetes-control-plane Microsoft MCP Gateway]] 提供了一个更偏基础设施的 MCP Gateway Runtime 样本：数据面负责 /adapters/{name}/mcp 与 tool router gateway，控制面负责 adapters/tools 的部署、更新、删除、状态和日志；metadata store 保存 server/tool 定义，session affinity 支持有状态 MCP server。

这说明 MCP Gateway 的生产价值不只是协议桥接，而是把工具注册、生命周期、路由、鉴权、日志和未来 agent/session 管理收口为可审计控制面。与 [[gate22-mcp-gateway-control-plane

Gate22]] 的 bundle/allow-list 视角相比，Microsoft 项目更强调 Kubernetes 下的部署与状态管理；两者合起来覆盖组织权限和运行时生命周期两端。

写入记录

2026-08-23 09:00 CST：补充 Microsoft MCP Gateway 对 Kubernetes MCP 数据面/控制面分离、session-aware routing 和 tool lifecycle 的启发。

2026-08-25 补充：从 MCP gateway 到组织级 control plane

[[deco-studio-mcp-control-plane

deco Studio]] 显示 MCP Gateway Runtime 的更高层形态：不是只聚合 server，而是把 agents、connections、models、Virtual MCPs、SSO/RBAC、encrypted token vault、trace/cost/error observability 和 event bus 统一到组织级 control plane。

这提示 Hermes 的 MCP/runtime 设计应维护 connection registry 和 tool contract：工具属于哪个 workspace/project，凭据如何保存，谁能调用，调用如何计费和审计，schema/权限检查是否由 runtime 自动执行。否则“接入更多 MCP server”会扩大工具面和凭据面，而不是形成可治理 agent platform。

2026-08-26 补充：MCP gateway 需要独立 agent identity 与 approval ledger

[[keidai-mcp-gateway-identity-control-plane

Keidai]] 补充了 MCP Gateway Runtime 的身份与凭据边界：Fuda 颁发短期 agent JWT，Torii 在 MCP 边界解析 backend credentials、执行 group policy、维护 approval gate 和 call trace，Shaiden runtime 在 gated task 上 park/resume。相比只把多个 MCP server 聚合成一个 endpoint，这种设计把“谁在调用、凭据归谁、谁批准、调用证据在哪”拆成可审计的控制面。

这对 Hermes 的启发是：未来接入高风险 MCP/tool 时，不应只扩展工具列表，而应先定义 agent/job identity、credential resolver、approval store、call trace 和 operator edge。否则长期无人 loop 会把权限扩张隐藏在“工具更多、能力更强”的表象下。

写入记录

2026-08-26 09:01 CST：补充 Keidai 对 MCP gateway 身份、凭据、审批、call trace 与 gated task park/resume 的启发。
2026-08-25 09:05 CST：补充 deco Studio 对组织级 MCP control plane、connection registry、RBAC、trace/cost observability 的启发。

2026-08-27 补充：MCP runtime 需要 registry、permission profile 与组织入口

[[toolhive-enterprise-mcp-runtime

ToolHive]] 把 MCP Gateway Runtime 进一步拆成 Gateway、Registry Server、Runtime 和 Portal：Registry 负责可信 server 目录、group 和配置；Runtime 负责本地容器或 Kubernetes 部署与生命周期；Gateway 负责统一 endpoint、SSO/OIDC、authz、tool filtering、semantic tool search 和 audit；Portal 负责组织内发现、请求和管理。

[[onecli-team-agent-harness

OneCLI]] 从 team-agent 角度补充了另一种 gateway：agent 在 sandbox 中运行，outbound request 经过 Rust Gateway 才注入凭据并执行 policy，凭据不直接交给 agent。这对 Hermes 的启发是，MCP/tool 接入不应只维护“可用工具列表”，而应维护 per-job identity、permission profile、credential resolver、approval ledger 和 call trace。

写入记录

2026-08-27 09:00 CST：补充 ToolHive 与 OneCLI 对 MCP registry、runtime、gateway 凭据注入、权限 profile 和组织入口的启发。

2026-08-28 补充：本地权限网关与轨迹级 policy proxy

[[aipermission-local-permission-gateway

AIPermission]] 和 [[gatra-zero-trust-agent-security-proxy

GATRA]] 把 MCP Gateway Runtime 的控制面进一步拆成两种互补形态：AIPermission 偏本地开发者 credential boundary，强调凭据留在 localhost gateway 内，agent 只拿 scoped token、connector/action permission、approval 和 audit；GATRA 偏 data-plane policy proxy，强调 Ed25519 capability token、CEL policy、ephemeral directive、trajectory spending cap 和 dry-run audit。

对 Hermes 来说，这说明未来高风险 MCP/tool 接入不应只维护“工具列表”，而应维护 job identity、credential profile、capability token、monotonic task directive、trajectory budget、policy verdict、approval ledger 和 revoke/expiry。单步 allow list 只能防一部分风险；长期 loop 的真实边界需要跨调用累计和可审计证据。

2026-08-29 补充：MCP/control plane 需要 flow policy 与 authority propagation

[[agentflow-flow-centric-agent-security-policy

AgentFlow]] 把 MCP Gateway Runtime 的治理对象从“请求是否允许”扩展到“数据与授权是否沿 agent trajectory 流向允许的 sink”。它的 flow/path rules、task-scoped capability、controlled release、stateful taint semantics 和 bounded SMT verifier，补上了仅靠 function allow-list 或 per-request token 难以覆盖的组合风险。

这和 [[gatra-zero-trust-agent-security-proxy

GATRA]]、[[aipermission-local-permission-gateway

AIPermission]] 形成互补：AIPermission 保护本地 credential boundary，GATRA 控制 request/capability/budget trajectory，AgentFlow 约束 sensitive fields、release sink 与 delegation boundary。Hermes 若未来接入内部 MCP/API，不应只登记 server 和 action，还应记录 data labels、authority scope、release rule、delegation policy 与 verifier/dry-run audit。

写入记录

2026-08-29 09:01 CST：补充 AgentFlow 对 MCP Gateway Runtime 的 flow-centric policy、stateful taint、authority propagation 和 bounded verifier 启发。

2026-08-30 补充：MCP 治理要先有 inventory 与 security preflight

[[golf-scanner-mcp-server-security-audit

Golf Scanner]] 补充了 MCP Gateway Runtime 的前置层：在建设 gateway、RBAC、approval、budget 和 audit 之前，团队必须先知道开发者机器和 IDE 中实际配置了哪些 MCP server。它把 Claude Code、Cursor、VS Code、Windsurf、Gemini CLI、Kiro、Antigravity 等工具中的 MCP 配置扫描出来，并按命令、凭据、脚本/二进制位置、容器权限、registry、漏洞、GitHub trust、digest/signature、OAuth 等信号做风险评分。

这说明 MCP control plane 不应只从“新 server 如何接入”开始，也要覆盖“已有 server 如何发现、分类、审计和下线”。对 Hermes 来说，未来 tool/MCP registry 应包含配置来源、transport、命令/包/镜像、credential boundary、audit timestamp、risk verdict 和是否允许无人 cron 使用；未审计 server 默认只能 read-only 或 HOLD。

写入记录

2026-08-30 09:00 CST：补充 Golf Scanner 对 MCP inventory、security preflight 与 Hermes tool registry 字段的启发。

2026-09-01 补充：MCP / Agent Runtime / Gateway 主题簇

本页作为 [[MCP-Gateway-Runtime

MCP / Agent Runtime / Gateway]] 主题簇的中心页，和 [[ibm-contextforge-mcp-federation-control-plane

IBM ContextForge]]、Context-Engineering、Harness-Engineering、Loop-Engineering、Agent-Benchmarks 共同描述“agent 工具面如何从单个 MCP server 升级为可治理 runtime”。

主题簇的分工是：[[ibm-contextforge-mcp-federation-control-plane

IBM ContextForge]] 提供 MCP/A2A/REST/gRPC federation control plane 样本；Context-Engineering 解释工具 registry、schema、权限和 trace 为什么也是上下文；Harness-Engineering 规定工具/权限/验证/审计合同；Loop-Engineering 处理长期 agent 如何跨轮调度、恢复和静默/打断；Agent-Benchmarks 则评估 runtime、gateway、sandbox 与 verifier 是否真的提升可靠性。

写入记录

2026-09-01 21:16 CST：补齐 MCP / Agent Runtime / Gateway 主题簇互链，明确本页在 runtime、context、harness、loop、benchmark 之间的分工。

2026-09-02 补充：本地 MCP gateway 是个人工作台的控制面

[[moor-local-mcp-gateway-manager

Moor]] 补充了 MCP Gateway Runtime 的本地/个人维度：它把多个 MCP server 收敛到一个 localhost endpoint，通过 Profile 决定当前 agent 暴露哪些 server/tool，并从 Claude Code、Codex、OpenCode、Cursor、Kimi Code、dsh、Grok Build、Pi 等客户端扫描既有 MCP 配置。

这和 [[ibm-contextforge-mcp-federation-control-plane

IBM ContextForge]] 的企业/联邦控制面形成谱系：ContextForge 解决 MCP/A2A/REST/gRPC 跨后端联邦，Moor 解决开发者机器上多 agent 客户端、多 MCP server、工具面漂移和审计入口。对 Hermes 来说，未来工具治理应同时覆盖本地 profile 和远程 federation：每日 radar、代码任务、发布任务不应共享全量工具面，而应按 job identity / risk tier / profile 暴露最小可用工具，并记录调用 receipt。

写入记录

2026-09-02 09:00 CST：补充 Moor 对本地 MCP gateway、Profile 过滤、跨客户端配置发现和 Hermes tool profile/audit 的启发。

2026-09-02 补充：A2A 是 agent-to-agent federation 维度

A2A-Agent2Agent-Protocol 补充了本主题簇的 agent-to-agent 层：MCP 处理 agent-to-tool / agent-to-resource，A2A 处理 agent-to-agent delegation / collaboration。对 gateway/runtime 来说，治理对象不再只是 tool registry，也包括 Agent Card、Agent Discovery、agent registry、task lifecycle、streaming/push notification、跨 agent trace 与委托权限。

架构边界应按对象判断：稳定函数、数据库、API、资源访问优先 MCP；需要多轮协商、长期状态、artifact、异步通知或自有工具链的远程能力优先 A2A。

写入记录

2026-09-02 21:23 CST：补充 A2A-Agent2Agent-Protocol 与本主题簇的关系，明确 A2A 在 agent-to-agent delegation、Agent Card、Discovery、task lifecycle 和实践案例雷达中的位置。

2026-09-03 补充：A2A Samples 让 gateway registry 扩展到 AgentCard receipt

[[a2a-samples-agent-card-discovery-interoperability

A2A Samples]] 提供了 A2A runtime 的实践样本：CLI host 读取远端 AgentCard；multiagent/web host 动态添加 remote agents 并委托任务；content_creation 和 weather/Airbnb planner 显示跨语言/跨框架 agent 可替换协作；AG2 与 weather sample 显示远端 agent 内部仍可调用 MCP/custom tools。

这要求 MCP-Gateway-Runtime 的 registry schema 从 tool/server 扩展到 agent card：card_url、card_hash、skills、input/output modes、streaming/push、auth scheme、owner、risk tier、last_verified_at、sanitization verdict、trace destination 和 allowed delegation scope 都应成为控制面字段。否则 A2A discovery 会把外部 agent 自述混入上游上下文，形成新的供应链注入与不透明委托风险。

写入记录

2026-09-03 09:00 CST：补充 A2A Samples 对 gateway registry、AgentCard receipt、跨 agent 委托和 A2A+MCP 组合控制面的启发。

2026-09-03 补充：知识点雷达与自我优化入口

AI-Knowledge-Point-Radar 把 MCP Gateway / federation control plane 设为核心雷达轴；LLM-Wiki-Optimization-Log 则要求这类 gateway/runtime 页面在发布前完成索引、CVM 与主题簇互链验证。

写入记录

2026-09-03 21:00 CST：加强与 AI-Knowledge-Point-Radar、LLM-Wiki-Optimization-Log 的 wikilink 串联，统一从知识点价值和机制闭环维护本页。

2026-09-04 补充：policy gateway 把 MCP control plane 推到动作级审批与证据链

[[aegisflow-local-first-policy-gateway AegisFlow]] 补充了 MCP Gateway Runtime 的本地 policy-gateway 形态：它不只聚合 MCP upstream，而是把 MCP、OpenAI-compatible API、Anthropic Messages API、GitHub、shell、SQL、HTTP 等动作归一成 ActionEnvelope，再按 protocol/tool/target/capability/actor/task/session 做 allow、review、block 决策。

这让 gateway 的治理对象从“server/tool 是否可见”升级到“某个 job identity 在某个 task 中能否执行某个具体动作”。对 Hermes 来说，未来工具注册表应同时记录 tool/server、risk tier、default decision、approval receipt schema、credential broker、evidence destination 和 direct-tool-bypass 风险；否则 agent 只要绕过 gateway 直接用 shell/editor，就会让 policy 边界失效。

写入记录

2026-09-04 09:00 CST：补充 AegisFlow 对动作级 policy gateway、review-resume、scoped credential 与 signed evidence chain 的启发。

2026-09-05 补充：MCP trust layer 需要 human identity、consent 与 policy verdict

[[permit-mcp-gateway-enterprise-trust-layer

Permit MCP Gateway]] 补充了 MCP Gateway Runtime 的企业 trust-layer 维度：gateway 不只是代理多个 MCP server，而是在每次 agent action 上绑定 human identity、session-scoped token、fine-grained authorization、consent screen、monitor/govern 与 audit trail。

这和 [[aegisflow-local-first-policy-gateway AegisFlow]] 的动作级 envelope 形成互补：AegisFlow 强调本地 allow/review/block 与 evidence chain，Permit 强调企业 SaaS/MCP 的身份继承、OPA/RBAC/ABAC/ReBAC 与同意界面。对 Hermes 来说，高风险工具注册表应增加 human_identity、job_identity、credential_scope、consent_required、policy_verdict、audit_receipt 和 gateway_bypass_risk 字段。

写入记录

2026-09-05 09:00 CST：补充 Permit MCP Gateway 对 enterprise trust layer、identity/consent/policy/audit 的启发。

2026-09-06 补充：task envelope 是 runtime/gateway 的前置控制合同

[[agentmesh-runtime-gateway-task-envelope-sandboxclaim

AgentMesh Runtime Gateway]] 补充了 MCP Gateway Runtime 的 task-level planning 维度：在 action 进入 MCP/A2A/tool gateway 前，系统先把目标、requested capabilities、context refs、data classification、tenant trust、mutation impact、budget、deadline、idempotency key 和 evidence requirement 放进 versioned task envelope，再决定 agent、runtime placement、approval/deny 和 receipt。

这和 [[aegisflow-local-first-policy-gateway

AegisFlow]] 的 action envelope 形成上下两层：task envelope 决定“这类任务能在哪个隔离等级、拿哪些能力、是否值得继续”；action envelope 决定“某一次具体工具调用是否 allow/review/block”。对 Hermes 来说，高风险工具注册表不应只记录 server/tool，也应绑定 job/task envelope：无人雷达、wiki 写入、CVM 发布、代码修改、生产部署分别需要不同 capability set、可写路径、runtime profile、budget 和 evidence boundary。

写入记录

2026-09-06 09:00 CST：补充 AgentMesh 对 task envelope、runtime placement、SandboxClaim、OTel receipt 与 task/action 双层控制面的启发。

2026-09-07 补充：registry-to-runtime bridge 是 gateway 控制面的前置层

[[dsh-nacos-bridge-registry-to-harness-runtime

dsh-nacos-bridge]] 提醒 MCP/A2A gateway 之前还有一个 registry-to-runtime bridge 层：能力提供方把 MCP server 或 A2A Agent Card 注册到 Nacos，bridge 负责发现、diff、mount/unmount 和健康检查，harness runtime 再决定模型、memory、session、skills 如何使用这些能力。

这与 [[agentmesh-runtime-gateway-task-envelope-sandboxclaim

AgentMesh Runtime Gateway]] 的 task envelope 形成上下游关系：registry bridge 维护“有哪些能力可用”，task planner 决定“本任务可用哪些能力”，action gateway 决定“这次调用是否允许”。Hermes 的 tool registry 后续应增加 capability snapshot、schema/card hash、last_seen、health、mount status 与 stale rejection 字段。

写入记录

2026-09-07 09:00 CST：补充 dsh-nacos-bridge 对 MCP/A2A registry-to-runtime bridge、动态能力装配和 capability snapshot 的启发。

2026-09-08 补充：AI asset control plane 把 registry、credential、A2A proxy 与 observability 绑成 receipt

[[agentic-community-mcp-gateway-registry-ai-asset-control-plane

MCP Gateway & Registry]] 把 MCP servers、A2A agents、skills 和 custom entities 都登记为 AI assets，并用同一套 registry/gateway/auth/audit 模型治理。它补充了本页对 federation control plane 的一个关键要求：control plane 不只记录 server endpoint，还要记录 asset type、schema/card、owner、scope、credential boundary、scan verdict、audit sink、OTel metrics、rate-limit/quarantine 与 federation source trust。

尤其值得吸收的是 A2A reverse-proxy 与 per-user egress credential 两个边界：前者让 Agent Card 与 JSON-RPC call 可以选择进入 gateway 数据面并用 invoke_agent gate 控制，后者让第三方 SaaS MCP token 保存在 vault，由 gateway 按目的地注入，coding assistant 只持有 ingress token。对 Hermes 来说，下一版 tool/agent registry 应从“有哪些工具”升级为“每个 job identity 能发现、调用、下线哪些 AI assets，并留下什么 receipt”。

写入记录

2026-09-08 09:01 CST：补充 MCP Gateway & Registry 对 AI asset control plane、A2A reverse-proxy、per-user egress credential、registration gate、audit/OTel 与 quarantine 的启发。

2026-09-09 补充：MCP tool 不应只注册，也要被选择、评测和拦截

[[osworld-mcp-tool-invocation-computer-use-benchmark

OSWorld-MCP]] 把 MCP tool surface 放进 computer-use benchmark，说明 gateway/registry 的价值不止“暴露 158 个工具”，还要让 agent 在 GUI action 与 MCP call 之间做 route choice，并记录 tool-beneficial task、distractor、Tool Invocation Rate、step/cost 和 fallback。工具面越大，越需要按任务生成最小可见工具集，否则 tool schema 会变成上下文噪音和误用入口。

[[agenttrust-runtime-safety-interception

AgentTrust]] 从安全侧补上 action-time membrane：即使 MCP tool 已被注册和授权，每次具体动作仍要经过 normalized action、risk category、policy verdict、safe fix、RiskChain 与 fail-safe review。[[a2a-v1-protocol-binding-governance

A2A v1]] 则提醒同一 registry 还要为 agent assets 记录 supportedInterfaces、protocolVersion、transport binding 与兼容层。因此下一版 MCP/A2A control plane receipt 应同时覆盖：asset discovery、tool-route decision、action interception、protocol-binding compatibility 和 audit/trace。

写入记录

2026-09-09 09:01 CST：补充 OSWorld-MCP、AgentTrust、A2A v1 对 MCP tool-route、action-time safety membrane 与 protocol-binding receipt 的启发。
2026-09-10 09:11 CST：新增 Grafana 身份/出站分离与 Docker daemon 隐式权限反例入口；不再长篇重复追加来源摘要。
2026-09-11 09:09 CST：补充跨 deployer 输出绑定、双边授权与跨 verifier replay 边界入口；未部署网关或修改权限策略。
2026-09-12 09:17 CST：增加 persona×credential、User→SA entitlement 与 RFC 对照入口；明确 ROPC 冲突和 actor-history/撤销边界。
2026-09-14 09:15 CST：补 OAuth bootstrap 出站和 workspace 配置装载边界入口；不把 DNS 静态检查当完整 SSRF 防护证明。
2026-09-15 09:17 CST：补会话/授权对象一致、body检查前提与转换语义入口，保留字段冲突和未运行上游测试边界。
2026-09-16 09:22 CST：补MRTR完整性/single-use与头体一致导航；区分规范版本、客户端声明和真实身份，不冒称网关运行验收。
2026-09-18 09:16 CST：补安全上下文组合合同、合法变换和提交时撤销入口；明确30项pytest与跨网关/持久化生产保证的差别。
2026-09-23 09:14 CST：补认证回退的目标集合、身份责任与分权限面前置条件；只增加source入口，不扩大为真实网关安全结论。
2026-09-24 09:16 CST：补撤销的新旧token、发现/调用、signed-header与在途请求短入口，按事件时间验收而非最新配置。
2026-10-26 09:10 CST：补联邦工具命名空间生命周期、历史重复/并发边界及连接健康/目录接纳短入口，互链最终tag深读source；不改网关或生产数据。
2026-10-27 09:14 CST：补Unla的授权根/有效token/目标prefix分验短入口和正式反链，保留固定源码与真实部署、负例验收的证据边界。
2026-10-28 09:13 CST：补逐backend header策略与OAuth issuer/旧注册绑定入口，区分授权根、资源与凭据接收方；不改生产权限或宣称本机PoC。
2026-10-29 09:15 CST：补跨域bridge用户/客户端/资源与局部secretless边界短入口，反链SAP固定样例深读，不将背景协议图冒称联邦网关实现。
2026-10-30 09:15 CST：补Card缓存/验签与execution origin凭据接收权短入口，反链Mastra固定实现，不将静态路径当真实泄漏或完整联邦实测。
2026-10-31 09:14 CST：加入EREBOTS服务client/可信用户context/consent强制gate与重放副作用短入口；不改现网网关或凭据。
2026-11-01 09:13 CST：补描述过滤/强制权限与选中/装载/调用消费分验入口；Aembit代理规则仅raw，不改生产配置或重启服务。
2026-11-02 09:15 CST：加入Pega逐跳交付及SecPR呈现/执行隔离反链，明确startup gate未运行、原件/纯函数不是安全E2E；Forge仅raw。