MCP 多智能体开发实战：从协议层到工程落地的完整路径

上周我们把一个内部知识库问答系统从单执行单元架构改成多执行单元编排，最大的瓶颈不是模型推理，而是执行单元之间的上下文传递和工具调用一致性。最终用这套协议把工具层统一起来，把 p99 延迟从 2.3 秒压到 890 毫秒。这篇文章把协议层变更、Go SDK 实战和踩坑记录摊开来讲。

为什么 2026 年的多执行单元架构必须重新考虑这套协议

2025 年我们做多执行单元系统时，每个执行单元自己封装一套工具调用接口，结果是上下文格式不统一、权限校验散落在五处、调试时抓不到完整的调用链。这套协议在 2024 年 11 月推出后，2026 年 5 月 21 日发布了 2026-07-28 版本的 Release Candidate，这是协议自诞生以来最大的修订。

核心变化是无状态协议层。之前的版本要求建立握手，服务端返回粘滞路由头，后续请求必须携带这个 ID。新版本把协议版本、客户端信息、能力声明全部挪到请求元数据里，每个请求自包含，服务端可以跑在普通轮询负载均衡后面，不需要共享状态存储。

对多执行单元系统的影响是直接的：执行单元 A 调用执行单元 B 的工具时，不需要维护长连接，请求可以打到任意实例，网关可以根据方法头直接路由，不需要解析 body。这对水平扩展和灰度发布是刚需。

2026-07-28 版本的核心变更

官方博客列出了六个 SEP（Specification Enhancement Proposal）共同完成了这次重构：

• SEP-2575：移除握手，协议版本和客户端信息放入请求元数据
• SEP-2567：移除粘滞路由头和协议级状态
• SEP-2260：服务端发起的请求只能在处理客户端请求期间发起
• SEP-2322：多轮请求用 InputRequiredResult 替代 SSE 长连接
• SEP-2243：HTTP 传输要求方法头和名称头，网关可路由
• SEP-2549：List 和 Resource Read 结果携带 TTL 和缓存范围，客户端可缓存

对比旧版本，新架构的差异可以用下表概括：

这个版本在 2026 年 7 月 28 日正式发布，包含 breaking changes。如果你现在开始新项目，直接按 RC 写，不要踩旧版本的坑。

实战：用 Go SDK 搭建一个可水平扩展的 Server

我们选 Go 而不是 TypeScript，是因为内部基础设施是 Go 微服务，低延迟场景下 GC 暂停不可接受。官方提供了 Go SDK，GitHub 仓库 modelcontextprotocol/servers 目前 87.4k stars，参考实现覆盖 Filesystem、Git、PostgreSQL、Sequential Thinking 等场景。如果你还在对比不同语言的 SDK 实现，可以参考我们之前的 Go 官方 SDK 与 Python FastMCP 选型对比。

最小可用的无状态 Server 结构如下：用 SDK 创建一个服务端实例，注册一个 search工具，定义输入 JSON Schema，在回调里解析参数、执行检索、返回文本结果。HTTP 层直接挂 /mcp 路径，不需要任何会话中间件。完整的 Go 服务端搭建流程和性能调优细节可以参考 Go 语言 MCP Server 实战：官方 SDK 从零到高性能部署。

客户端调用时，不需要先调初始化接口，直接把协议版本、客户端信息放在请求元数据里。下面是 curl 示例：

curl -X POST http://localhost:8080/mcp \
  -H "Content-Type: application/json" \
  -H "Mcp-Method: tools/call" \
  -H "Mcp-Name: search" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "search",
      "arguments": {"q": "stateless protocol"},
      "_meta": {
        "io.modelcontextprotocol/clientInfo": {
          "name": "my-agent",
          "version": "1.0.0"
        }
      }
    }
  }'

在压测环境（wrk, 100 并发, 30 秒）下，这个服务的 p99 延迟是 12 毫秒，内存占用稳定在 8MB，没有 GC 尖刺。对比 TypeScript 版本（p99 45ms，内存 42MB），Go 在低延迟场景有明显优势。

多执行单元场景下的协议路由与缓存策略

多执行单元系统里，通常有一个编排层（Orchestrator）和多个专业执行单元（检索单元、代码单元、审核单元）。这套协议在这里的角色是工具层统一协议，不是执行单元间的通信协议。关于从单工具直连到生产级网关的工程演进，可以参考 MCP 网关实战：从单工具直连到生产级网关的工程演进。

我们踩过的第一个坑是把这套协议当成了执行单元间的 RPC。它的设计初衷是让 LLM 安全地调用外部工具，不是让执行单元 A 直接调用执行单元 B 的推理能力。正确的做法是：每个执行单元对外暴露 Server，编排层通过 Client 调用它们的工具接口，执行单元之间的状态传递通过工具参数里的显式 handle 完成。

比如检索单元返回一个文档 ID，代码单元的下一次工具调用把这个 ID 作为参数传进去。这种模式比隐式状态更可调试——你可以在日志里看到完整的参数传递链。

缓存策略上，新协议的 TTL 字段很有用。工具列表的结果通常不会频繁变化，我们设置 5 分钟 TTL，客户端缓存后，每次新执行单元启动不需要重新拉取工具列表，冷启动时间从 800 毫秒降到 50 毫秒。

生产环境踩坑记录

以下是我们在 2026 年 3 月到 6 月期间遇到的四个典型问题，以及对应的解决方案：

第四个坑值得展开。旧版的 Server 如果需要用户确认（比如"是否删除这个文件？"），会保持 SSE 连接打开，等用户输入。这在直连场景没问题，但经过 Nginx 或 API 网关时，默认超时 60 秒就会断连。新版用 InputRequiredResult 把确认请求打包在响应里，客户端收集用户输入后，把 inputResponses 和 requestState 一起发回，服务端继续处理。整个流程不需要长连接，对云原生环境友好得多。

常见问题

Q1: 现有系统还在用旧版本，升级成本高吗？

如果只是工具调用，不涉及状态管理，升级成本很低——去掉初始化握手，把客户端信息移到请求元数据，响应头去掉粘滞路由头即可。如果有自定义状态逻辑，需要改成显式 handle 传递，这部分视复杂度 1-3 人天。

Q2: Go SDK 和 TypeScript SDK 选哪个？

看部署环境。如果 Server 要跑在边缘节点或和现有 Go 微服务同进程，选 Go SDK，延迟更低、内存更可控。如果是前端工具链（比如 IDE 插件），TypeScript SDK 更自然。两个 SDK 都支持新协议，功能对等。

Q3: 多执行单元场景下，这套协议和 A2A（Agent-to-Agent）协议怎么选？

这套协议解决的是"LLM 怎么安全地调用工具"，A2A 解决的是"执行单元之间怎么发现和协商任务"。两者互补。我们的做法是：执行单元间任务协商用 A2A，具体的工具执行统一走这套协议。这样工具层的权限、审计、缓存只需要实现一次。关于多执行单元集群的工程化五道坎，可以参考 从单Agent到多Agent集群：2026年企业AI Agent工程化的五道坎。

Q4: 性能瓶颈通常在哪儿？

不在协议本身，而在工具实现。我们压测过，协议的 JSON 编解码 overhead 不到 1 毫秒。真正的延迟来自工具背后的 I/O——数据库查询、HTTP 调用、向量检索。建议在工具层做批量合并和异步化，不要阻塞协议的处理循环。

Q5: 安全方面需要注意什么？

新版本强化了授权，更贴近 OAuth 2.1 和 OpenID Connect。生产环境建议：工具层做 scope 校验，敏感操作（写文件、删数据）必须走 elicitation 流程，服务端发起的请求只能在处理客户端请求期间发起，防止恶意服务端无提示弹窗。

参考

• The 2026-07-28 Model Context Protocol Specification Release Candidate
• modelcontextprotocol/servers (87.4k stars)
• Google Cloud: What is Model Context Protocol?
• MCP 协议：高并发下的带宽延迟优化秘籍