open-code-review MCP 会话，消息怎么流

01一个反共识：MCP 不是 API，是消息协议

很多人把 MCP（Model Context Protocol）理解成"AI 调工具的 API"。错。它是一套消息格式约定——客户端和服务器之间用 JSON-RPC 互相发消息，谁发什么、怎么回，都有规定。

关键认知：MCP 服务器不是"被调用的函数"，是"一个会回消息的对端"。客户端发 tools/call 请求，服务器可以立即回结果，也可以先回"我需要更多输入"再继续——这是有状态的对话，不是无状态请求。所以 AI review 里"读 diff"不是一次 RPC，是"请求→服务器调 git 工具→分块返回→客户端组装→喂模型"的消息流。把 MCP 当 API 调，你会漏掉中间所有状态。

02MCP 消息流演示：点一步看消息怎么传

一次 AI review 的完整消息流有 6 步。点每一步，看那一步发的 JSON-RPC 消息长什么样、谁发给谁。

03六个步骤拆解：从用户到评论

把消息流拆开看，每一步都有它要解决的问题：

• 1. 用户发起：用户在客户端点"review 这个 PR"，客户端构造一个 review 请求消息。
• 2. 客户端→服务器：客户端发 tools/call，请求调用 read_diff 工具，参数是 PR 号。
• 3. 服务器调工具：MCP 服务器收到请求，内部调 git 命令读 diff，可能分块（大 diff 要分页）。
• 4. 服务器→客户端：服务器把 diff 内容作为工具结果回传（可能多轮 streaming）。
• 5. 客户端喂模型：客户端把 diff + 提示词组装成模型输入，调 LLM 推理，拿到 review 意见。
• 6. 客户端发评论：客户端把模型意见通过 reviews/create 工具发回服务器，服务器写进 PR 评论。

注意第 3 步和第 5 步是两个不同的"调用"：第 3 步是 MCP 客户端调 MCP 服务器（拿数据），第 5 步是客户端调 LLM（拿推理）。很多人混淆这两步，以为"AI 直接看 diff"——其实 AI 看到的是客户端组装好的文本，它从不知道 diff 是怎么来的。中间这层客户端是 AI review 的真正大脑。

04调优就在消息流里：哪一步慢、哪一步错

理解消息流后，调优有迹可循：

• review 慢：先看是第 3 步（读 diff 慢，大 PR 要分块）还是第 5 步（模型推理慢）。两者解法不同——前者优化分块/缓存，后者换模型或缩短输入。
• review 漏问题：通常是第 4 步 diff 不全（分块丢了）或第 5 步提示词没给上下文。加日志看每步消息内容。
• 评论格式错：第 6 步序列化问题，检查 reviews/create 的参数 schema。
• 超时：MCP 消息有超时，大 diff 第 3-4 步可能超时，要调 timeout 或改 streaming。

所以"AI review 不好用"的第一反应不该是"换模型"，而是打开消息流日志看哪一步出问题。MCP 协议的好处就是每步都是结构化消息，可观测、可重放、可调试——这是它比"黑盒调 API"先进的地方。可观测性是 MCP 给 AI review 最大的礼物。

05带走这套清单