Keidai：MCP Gateway、Agent Identity 与 Operator Control Plane

wiki/ai/sources/keidai-mcp-gateway-identity-control-plane.md

分类：ai / sources · 更新：2026-08-26 09:12

Keidai：MCP Gateway、Agent Identity 与 Operator Control Plane

一句话结论

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

Keidai]] 值得入库，因为它把 MCP-Gateway-Runtime 从“工具聚合 endpoint”推进到 agent identity、credential boundary、approval ledger、call trace 与 operator UI 的完整控制面。它和 [[deco-studio-mcp-control-plane

deco Studio]]、[[microsoft-mcp-gateway-kubernetes-control-plane

Microsoft MCP Gateway]] 形成互补：一个偏组织/产品平台，一个偏 Kubernetes 生命周期，Keidai 则把身份与工具边界拆得更清楚。

为什么对用户重要

用户当前关注 MCP gateway、权限/审批/预算/审计、served endpoint 或执行证据回传。Hermes 未来如果接入更多 MCP server、浏览器、GitHub、文件、数据库和发布工具，最大风险不是“工具不够多”，而是不同 agent/cron/worker 共享同一套无边界凭据，导致工具面、凭据面和审计面混在一起。

Keidai 的价值在于给出一个可迁移的 control-plane vocabulary：

agent identity provider（Fuda）负责短期身份；
MCP gateway（Torii）负责工具边界、凭据解析、policy、approval 和 trace；
agent runtime（Shaiden）负责执行和在 gated task 上 park/resume；
operator BFF/UI 负责人类管理入口，且是唯一 browser-facing edge。

机制 / 一阶原理

Keidai 的架构把“谁在调用工具”“凭据归谁保管”“谁批准副作用”“调用记录在哪里”分成不同信任边界。README 与架构文档显示：Shaiden 向 Fuda 换取短期 agent JWT；Torii 离线验证 JWKS，不把每次授权都回调给 Fuda；Torii 再按 backend credential mode（user_oauth、service_key、none）解析后端凭据，并记录 approval records 与 call traces。

Torii 子模块也体现了生产 MCP gateway 的最小形态：

connections/：后端 registry 与 MCP client connector。
catalog/：fan-out tools/list 与 server.tool 命名空间。
credentials/：用户 OAuth、service key、none 的 resolver。
policy/：group policy enforcement、approval gate、store、API。
trace/：结构化 CallTrace 与 Postgres trace store。
identity/：入站 agent identity，使用 Fuda JWT。

关键点：gateway 不只是转发 JSON-RPC，而是在 effect boundary 处拥有策略、凭据和证据。

与既有 wiki 概念的关系

与 MCP-Gateway-Runtime：补充身份、审批、trace 和 operator edge 的分层设计。
与 Harness-Engineering：Keidai 将 prompt-level policy 变成运行时边界，尤其适合无人 loop 的高风险工具调用。
与 Loop-Engineering：Shaiden 的 gated task park/resume 对长期 agent loop 很重要；审批不是中断流程，而是可恢复状态。
与 Agent-Benchmarks：未来 MCP/control-plane benchmark 应评测 unknown group fail-closed、credential non-exposure、approval ledger 和 trace completeness，而不只是工具调用成功率。

可执行启发

Hermes 的 MCP 接入应按 agent/cron/job 建立最小身份，而不是让所有 loop 共享默认用户权限。
高风险工具（发布、数据库、支付、删除、外发）应返回 gated task，由 runtime park/resume，而不是让模型在同一轮里自批自执行。
最终日报/任务报告中的“调用了哪个工具、用了什么凭据范围、是否审批、是否成功”应来自 trace/ledger，而不是自然语言总结。
若未来做 Hermes MCP gateway，应优先实现：tool catalog namespace、credential resolver、group policy、approval store、call trace、operator edge；模型路由和 marketplace 可以后置。

失败模式 / 边界条件

Keidai 当前 star 很低，仍需实际部署/测试验证；本页不应把 README claim 当作生产成熟度证明。
Control plane 可能引入额外复杂度：Postgres、JWT、operator registry、BFF 都需要运维，个人场景应先抽取轻量机制。

- Gateway 只解决工具边界；模型输出诚实度、任务完成 verifier、benchmark 统计仍需 Agent-Benchmarks 和 [[reliable-cua-statistical-computer-use-eval

reliable-cua]] 这类层补齐。

写入记录

2026-08-26 09:01 CST：根据 nathanlb/keidai README、Torii README 与 architecture docs 新增 source 页，提炼 MCP gateway 身份、凭据、审批、trace 和 operator control plane 设计。