Agent API 网关应该支持哪些协议转换

1️⃣ 考察意图

面试官想看你能否识别 Agent 系统中的协议异构性问题，并设计转换方案。刁钻点在于：很多人只答"HTTP 转 gRPC"，但说不出 MCP stdio 桥接、同步转异步、Streaming 转批量等 Agent 特有的协议转换需求。答好了能展示你对 Agent 通信协议全景的理解。

2️⃣ 标准答

Agent 网关需要支持五类协议转换：

1. HTTP/REST ↔ gRPC

场景：Agent 用 HTTP 调用网关，后端工具用 gRPC（如代码执行服务）
转换：JSON ↔ Protobuf。网关解析 HTTP JSON 请求 → 转换为 Protobuf 消息 → 调用 gRPC 后端 → Protobuf 响应 → 转换为 JSON 返回
实现：用 grpc-gateway 或自研转换层。Schema 映射用 proto3 的 JSON mapping 规则
坑：JSON 的字段名是 camelCase（如 userId），Protobuf 是 snake_case（如 user_id），需要做命名转换

2. HTTP ↔ stdio（MCP 桥接）

场景：MCP Server 用 stdio 通信（本地进程），远程 Agent 需要通过 HTTP 调用
转换：HTTP 请求 → JSON-RPC 消息 → 写入 MCP Server 的 stdin → 读取 stdout → HTTP 响应
实现：网关启动 MCP Server 作为子进程，用 pipe 通信。Anthropic 的 MCP SDK 提供 StdioServerTransport 和 HTTPServerTransport 的桥接
挑战：stdio 是阻塞的——一个 MCP Server 同时只能处理一个请求。网关需要维护 MCP Server 进程池（如 5 个实例），支持并发

3. 同步 ↔ 异步

场景：Agent 发同步 HTTP 请求，但后端工具是异步的（如消息队列触发的长时间任务）
转换：HTTP 请求 → 消息队列消息 → 返回 202 Accepted + task_id → Agent 轮询 GET /tasks/{task_id} 或接收 Webhook 回调
实现：网关维护 Task 状态表（Redis），后端完成后更新状态并触发回调
挑战：超时处理——Agent 等待 30s 后超时，但任务可能需要 5 分钟。解法：Agent 超时后返回"任务处理中，结果稍后通知"，而非直接报错

4. Streaming ↔ 批量

场景：后端工具返回 Streaming 数据（如 SSE 实时搜索结果），但 Agent 期望一次性返回（批量）
转换：网关收集所有 Streaming 数据 → 聚合为批量响应 → 一次性返回给 Agent
反向转换：Agent 发批量请求 → 网关拆分为多个 Streaming 请求并行发送给后端 → 聚合结果
实现：用 asyncio/Go channel 做 Streaming 缓冲。设置最大等待时间（如 5s），超时后返回已收集的数据

5. OpenAI Function Calling ↔ MCP

场景：Agent 用 OpenAI Function Calling 格式，但工具用 MCP 协议
转换：Function Calling 的 tools 参数（JSON Schema）→ MCP 的 tools/list 响应格式。Function Calling 的 tool_calls → MCP 的 tools/call 请求
实现：网关在 Agent 启动时调用 MCP tools/list 获取工具列表 → 转换为 Function Calling 格式传给 LLM → LLM 输出 tool_calls → 网关转换为 MCP tools/call 调用 MCP Server → 结果转换回 Function Calling 格式
价值：让任何支持 Function Calling 的模型（GPT-4、Claude、Gemini）都能使用 MCP 工具，无需修改模型

3️⃣ 答题模板（30 秒电梯版）

"Agent网关五类协议转换：HTTP↔gRPC——JSON↔Protobuf，用grpc-gateway，注意camelCase/snake_case转换。HTTP↔stdio(MCP桥接)——HTTP请求→JSON-RPC→MCP Server stdin→stdout→HTTP响应，进程池支持并发。同步↔异步——HTTP→消息队列+202+task_id轮询/Webhook。Streaming↔批量——SSE聚合为批量或批量拆分为Streaming。Function Calling↔MCP——tools参数格式互转，让任何模型都能用MCP工具。总结一句：网关是Agent通信的'万能适配器'。"

4️⃣ 高频追问 & 应对

追问 1：MCP stdio 桥接的并发问题怎么解决？

三个方案：(1) 进程池——网关维护 N 个 MCP Server 实例（如 5 个），并发请求分配到不同实例。缺点：每个实例占用内存（约 50-100MB），5 个实例 = 500MB；(2) 多路复用——修改 MCP Server 支持并发（用 asyncio 或线程池处理多个 stdin 请求）。需要 MCP Server 支持，不能用于第三方 Server；(3) HTTP MCP Server——用 HTTPServerTransport 替代 StdioServerTransport，MCP Server 直接暴露 HTTP 接口。最佳方案但需要 MCP Server 支持 HTTP 模式

追问 2：协议转换会不会丢失信息？比如 gRPC 的 metadata 在 HTTP 中怎么传递？

信息保留方案：(1) Metadata 映射——gRPC 的 metadata 映射到 HTTP header（如 x-trace-id、x-tenant-id），网关做双向转换；(2) 自定义字段——gRPC 特有字段（如 deadline、compression）在 HTTP 中用自定义 header 表示（如 x-grpc-deadline: 30s）；(3) Schema 约束——用 Protobuf 的 google.api.http annotation 定义 HTTP↔gRPC 的字段映射规则，确保双向转换一致。不能转换的信息：gRPC 的流控（flow control）在 HTTP 中无法精确表达，需要用 HTTP/2 的流控替代

追问 3：Function Calling 和 MCP 的工具定义格式差异大吗？转换有损吗？

格式差异小，转换无损。Function Calling 的 tool 定义：{"type": "function", "function": {"name": "search", "description": "...", "parameters": {JSON Schema}}}。MCP 的 tool 定义：{"name": "search", "description": "...", "inputSchema": {JSON Schema}}。核心字段（name、description、parameters/inputSchema）一一对应。唯一差异：Function Calling 支持嵌套 type: "function" 包装，MCP 不需要。转换是无损的——JSON Schema 完全兼容

5️⃣ 避坑 · 常见错误答法

❌ "所有工具统一用 HTTP 就行，不需要协议转换" → ✅ "有些工具只能用特定协议——MCP Server 只支持 stdio、gRPC 服务只支持 Protobuf。强制统一 HTTP 会限制工具选择范围。网关的协议转换让 Agent 用统一接口调用任意协议的工具。"
❌ "协议转换太复杂，直接让 Agent 适配各协议" → ✅ "Agent 适配 N 个协议 = O(N) 复杂度。网关适配 = O(1) 复杂度（Agent 只用 HTTP）。且 Agent 代码和工具代码解耦——工具换协议不影响 Agent。"
❌ "Streaming 转批量会丢失实时性" → ✅ "可以配置转换策略——默认聚合为批量（适合大多数场景），但保留 Streaming pass-through 模式（适合需要实时反馈的场景）。网关根据请求参数自动选择模式。"

6️⃣ 简历呼应

如果你有协议适配项目：从"多协议网关"切入，描述你实现的五类协议转换和性能数据
如果你只做过 API 网关：用"API 网关协议适配"迁移——HTTP↔gRPC 直接适用，额外需要的是"MCP stdio 桥接"和"Function Calling↔MCP 格式转换"
如果你是校招无项目：实现一个 MCP stdio-to-HTTP 桥接器，让远程 Agent 能调用本地 MCP Server
"grpc-gateway: HTTP↔gRPC Proxy" (protobuf, 2024)
"MCP Transport: stdio vs HTTP" (Anthropic, 2024)
"Protocol Adaptation in Agent Systems" (Wang et al., 2025)

—— 本场面试完 ——