MCP 协议：跨进程工具的"AI 的 USB-C"
Function Calling 解决"做什么"（LLM 输出结构化调用），MCP 解决"怎么做"（跨语言/跨进程/跨团队的工具如何注册、发现、调用）。MCP 是工具的 gRPC——用 JSON-RPC over stdio 统一 IDL，用 tools/list 做服务发现，用 tools/call 做远程调用。三句话看懂：① 工具定义在另一个进程里，通过 JSON-RPC 单独通信；② 框架把 MCP 工具翻译成 LLM 能看懂的 tools 数组项，加 mcp__ 前缀做命名空间；③ LLM 完全不知道 MCP 的存在——它看到的只是扁平 tools 数组，选工具只看 description。
1x2x
0/14 · 待播放
Agent → 配置Server → 启动子进程 → tools/list 发现 → 翻译 tools 数组(mcp__前缀) → tools/call 调用 → 结果回传
光点 = 当前环节 · LLM 看到的只有扁平 tools 数组
LLM 看到的 tools 数组（扁平、加前缀）LLM 选工具只看 description
就绪点 ▶ 播放，看一个浏览器自动化工具怎么跨进程被 Agent 调用。MCP 协议
⚡ 运行时动作：正在发生什么💡 知识讲解：为什么这么设计
MCP 生命周期日志配置→启动→发现→延迟加载→使用→断连恢复
知识点一句话总结：MCP 是跨进程工具的"AI 的 USB-C"：Function Calling 解决"做什么"（LLM 输出结构化调用），MCP 解决"怎么做"（跨语言/跨进程/跨团队工具如何注册、发现、调用）。核心链路：配置（settings.json 声明 mcpServers）→ 启动（fork 子进程，JSON-RPC over stdio，零网络开销）→ 发现（tools/list 返回 name/description/inputSchema）→ 延迟加载（首次调用才 fetch 完整 Schema，工具名不变 → Cache 不受影响）→ 翻译（框架加 mcp__server__tool 前缀做命名空间，LLM 完全不知道 MCP 存在）→ 调用（tools/call {name, arguments}）→ 断连恢复（崩溃自动重启 + 缓存 tools/list）。关键差异：FC 的 tool 定义在 LLM API 请求的 tools 数组里（一次 HTTP 全搞定）；MCP 多一步服务发现——先 JSON-RPC 发现→缓存→再放进 tools 数组，这一步就是 MCP 连接/断开会破坏 Cache 的原因。同进程工具用 MCP 是过度设计（@Tool 零网络开销）。