最近连续处理了几个后端项目的通信问题，从老旧的HTTP接口调试到gRPC服务治理，再到接MCP这种新的AI工具链，发现很多同学对RPC的理解还停留在“远程调用”四个字上。RPC（Remote Procedure Call，远程过程调用）是后端系统之间最核心的通信方式，而MCP（Model Context Protocol，模型上下文协议）又把这层通信逻辑带到了AI应用与外部工具之间。这篇内容我不打算从教材定义讲起，而是直接结合后端常见项目场景，把RPC的通信基础、MCP跟RPC的关系、实际落地时的踩坑点一起梳理清楚，适合刚接触分布式后端的同学，也适合已经在写业务接口、想搞清楚底层通信原理的工程师参考。
1. 后端通信体系里，RPC到底站在什么位置
1.1 从“本地调用”到“远程调用”的那道坎
理解RPC最快的方式，是回想你自己写代码时的普通函数调用。你在UserService里调用orderService.createOrder(...)，参数在栈上传递，返回值直接拿到，整个过程是同步的、透明的，你不需要关心这个函数跑在哪个进程里，也不需要关心数据怎么从内存A拷贝到内存B。RPC要做的事情，就是把这套“本地调用”的体验复制到“远程调用”上——被调用的函数可能跑在另一台机器上，中间隔着一层网络协议栈。
但这里有个根本性的矛盾：本地调用是内存地址跳转，远程调用是网络报文传输。内存地址跳转纳秒级完成，网络报文传输至少是毫秒级，中间还夹着序列化、反序列化、连接管理、超时重试这些额外开销。所以任何一个RPC框架，本质解决的都不是“能不能调用”的问题，而是“怎么在远程调用的代价下，尽量让调用方感觉像在本地调用”。
很多后端项目一开始用HTTP接口也能跑通，但是一旦服务数量上来，比如拆分出订单服务、用户服务、库存服务三个模块，服务之间互相调用，HTTP接口的几个痛点就暴露了：没有内置的服务发现，URL配置靠手写；没有统一的重试和熔断机制，A服务挂了直接拖垮B服务；JSON序列化效率不够高，高并发下带宽和CPU都扛不住。RPC框架（比如gRPC、Dubbo）把这些能力做成了内置基础设施，这就是后端常见项目从单体走向微服务时，几乎必然引入RPC的原因。
1.2 RPC的三板斧：序列化、传输协议、服务治理
剥开任何一个RPC框架，核心就三块：序列化协议、网络传输协议、服务治理能力。这三块的选型直接决定了RPC的性能和稳定性。
序列化负责把内存中的对象变成字节流，传输的时候把字节流还原成对象。常见的序列化方案有JSON、Protobuf、Hessian、Kryo。JSON可读性好、跨语言方便，但体积大、解析慢；Protobuf体积小、解析快，但需要维护.proto文件、学习成本高。实际项目里，内部服务调用追求性能，用Protobuf或Hessian的居多；对外开放接口追求兼容性，用JSON的居多。
传输协议负责在网络上搬运字节流。gRPC底层走HTTP/2，支持多路复用、头部压缩，一个连接上可以并发跑多个请求，避免了HTTP/1.1的队头阻塞问题。Dubbo默认走Netty自定义协议，纯TCP层实现，性能更高但调试没那么方便。传输协议的选择跟业务场景强相关：如果你要兼容浏览器客户端，HTTP/2是必然选择；如果你只在内部服务间通信，自定义TCP协议更占优势。
服务治理是RPC区别于“裸HTTP调用”的核心增量。它包含服务注册与发现（服务实例挂在注册中心上，调用方动态获取可用地址）、负载均衡（按权重/一致性哈希选择目标实例）、熔断降级（下游异常时快速失败或返回降级数据）、链路追踪（贯通全链路的traceId透传）。没有服务治理的HTTP接口调用，本质上是在手写一套不完整的RPC，而完整RPC框架把这些能力统一封装好了，这也是为什么后端项目稍微有点规模就会切换到成熟RPC框架。
2. 后端常见项目里的RPC选型思路
2.1 Java生态：Dubbo与Spring Cloud的抉择
Java后端项目里，Dubbo和Spring Cloud是两条最常见的RPC路线，很多团队在这两者之间摇摆。Dubbo是阿里开源的高性能RPC框架，自带服务注册、负载均衡、集群容错，底层支持多种协议（dubbo协议、triple协议等），在内部服务间高吞吐场景下表现非常突出。Spring Cloud不是单一框架，而是一整套微服务治理生态，通信基础用的是Spring Cloud OpenFeign（声明式HTTP调用）或Spring Cloud LoadBalancer，底层走HTTP，配合注册中心（Eureka、Nacos、Consul）完成服务发现。
我个人的选型经验是：如果团队以Java为主、追求极致性能、服务规模中等偏大，Dubbo更合适，因为它在注册中心、序列化、负载均衡策略上做了大量深度优化，而且和Nacos搭配使用非常顺手。如果团队需要更强的生态整合能力，尤其要接入Spring Cloud Gateway、Spring Cloud Stream这种周边组件，或者组织里有多个语言（Java、Go、Node）共存，Spring Cloud的HTTP+JSON路线更稳妥，因为HTTP协议跨语言支持天然好。说到底选型不是比谁性能高，而是比谁的配套设施更匹配你团队的技术积累和业务形态。
顺带提一下RuoYi这类常见的Java后台管理框架。RuoYi-Vue-Pro在近期版本里开始支持合并MCP功能以及gRPC集成，搜索“ruoyi-vue-pro合并mcp功能”的热度也比较高。这说明后端脚手架项目已经在主动迎接RPC跟AI工具链的打通，而不是拒绝变化。如果你手上的项目恰好是基于这类后台管理系统改造的，可以留意官方更新日志里关于集成MCP Server、暴露Service方法给AI客户端调用的部分，这部分内容放到第4节详聊。
2.2 Python生态：FastAPI的性能与异步通信
Python后端的RPC选择跟Java完全不同。Java体系里RPC框架是标配，但Python项目更多是用FastAPI这类Web框架直接暴露HTTP接口，配合现代ASGI服务器（Uvicorn）达到不错的并发能力。FastAPI的风格是“类型驱动”，用Pydantic做参数校验、自动生成OpenAPI文档，上手非常快，特别适合AI应用的后端——你定义一个/chat接口，用类型注解描述请求体，框架自动帮你做校验、生成文档，前后端联调效率比Java那套高很多。
但FastAPI本身并不算传统意义上的RPC框架，它走的是HTTP+JSON的路子。如果你的Python服务需要跟Java服务做高性能内部通信，常见做法是Python侧起一个gRPC客户端/服务端，通过protobuf定义接口。FastAPI有官方的grpc集成方式，也可以用grpcio库手动启动一个gRPC服务，跟FastAPI的HTTP服务共存。实测下来，Python侧gRPC服务配合异步调用的性能表现尚可，但序列化后的数据结构和强类型约束对Python这种动态语言来说，维护成本会高一些。如果接口变更频繁，建议在proto文件设计上留足兼容字段，把可选的参数都标记为optional。
还要多提一句“前后端分离”场景。现在很多后端项目是前后端完全分离的，前端走Vue/React，通过HTTP/HTTPS调用后端Gateway或BFF层。这里RPC的工作就落在BFF（Backend For Frontend）层：BFF接收前端请求后，再通过RPC调用下游微服务，组装好数据返回给前端。这种分层的好处是前端只需要面向BFF的“聚合接口”，不需要关心下游到底有几个服务、各服务怎么调用。BFF层用Java（Dubbo）或Node（通过gRPC client）都可以，关键是协议边界要清晰。
2.3 想用JS写后端？Node框架的通信定位和选择
“想用JS写一个后端项目，用什么框架好”这个热搜词几乎每个季度都会出现。坦率说，JS后端跟Java/Python后端在RPC体系里的位置完全不一样。Node.js生态里，Express是经典之选，路由中间件清晰、生态成熟，适合快速做一些BFF层和API服务；NestJS则是目前更接近“工程化完整”的方案，它内置了依赖注入、模块化、装饰器，对TypeScript支持极佳，如果你用TS写后端，NestJS基本是首选。但在RPC层面，JS世界的选择相对简单：一是直接跑gRPC（Node官方有grpc-js库），二是走HTTP/JSON跟其他语言服务通信，很少见到JS团队像Java团队那样搭一套完整的注册中心+负载均衡体系。
如果你的“用JS写后端”是指独立开发一个中小型项目，我建议选择NestJS+TS写业务逻辑，数据库用PostgreSQL或MySQL，接口设计用RESTful或者GraphQL，部署时用Docker起服务。大部分场景下，Node后端作为BFF层跟Java/Python核心服务通过gRPC或HTTP沟通即可，没必要硬上“全套微服务”的复杂度。只有当Node服务收敛了很多业务边界、需要治理服务发现和链路追踪时，才需要引入RPC框架体系。
2.4 数字后端的“通信基础”，一条经常被搞混的线
热搜词里“芯片后端”“数字后端”“innovus数字后端”是另一个完全独立的“后端”概念——它不是软件后端的服务端，而是集成电路设计流程里“逻辑综合之后”的物理设计阶段。在这里，“通信基础”更多指的是芯片内部不同模块之间的互连，也就是片上网络（NoC）、总线协议、时钟树上的信号传播。这些物理层面的“通信”跟RPC虽然是完全不同的抽象层次，但思想上有相通之处：都是“如何在多个单元之间可靠、高效地传递信息”，差别只是一个在芯片里用金属导线传电信号，一个在服务器之间用网络报文传数据。
所以如果你搜RPC时看到“数字后端”，别慌，那大概率是在讲芯片物理设计。学软件后端的人不需要掌握Innovus，但了解一下这个概念有好处——至少跟别人聊“后端”的时候，不会混淆两个完全不同的领域。
3. MCP：把“模型上下文”和RPC通信底座结合起来
3.1 MCP是什么，它跟RPC到底什么关系
MCP全称Model Context Protocol（模型上下文协议），本质上是给AI应用（比如大模型客户端）提供一套标准化的方式来访问外部工具和数据源。你可以把它理解成“AI界的USB接口”：以前每个AI应用要接入不同的数据源，都得单独定制集成方式；有了MCP，数据源（比如数据库、文件系统、设计工具）只要实现了MCP Server，任何支持MCP的客户端就能统一调用它。
那MCP跟RPC是什么关系？一句话概括：MCP在通信机制上本质是基于RPC思想构建的，但它面向的是“AI模型与工具之间的调用”，关注的是“让模型拿到它需要的上下文”。RPC解决的是“怎么让一个程序像调用本地函数一样调用远端函数”，MCP解决的是“怎么让AI模型标准化地调用外部工具、读取外部资源”。MCP底层用的是JSON-RPC 2.0协议，这是一种轻量的RPC协议，请求/响应用JSON封装，方法调用通过method字段区分。所以从这个意义上看，MCP就是RPC思想在AI领域的落地形态——只是它把“函数”变成了“工具”，把“返回值”扩展成了“资源（Resource）”。
搜索热词里频繁出现“mcp是什么”“mcp 基础知识”“mcp resource实战”，说明大家对这个新协议的基础概念和实战方式都很感兴趣。我在第4节会给出一个具体的MCP Server配置示例，那里面你能直观看到JSON-RPC请求长什么样。
3.2 MCP的三个核心原语：工具、资源、提示
MCP协议设计里，最核心的是三个原语：Tools（工具）、Resources（资源）、Prompts（提示）。理解这三样东西，基本就理解了MCP能干什么。
Tools是“可执行的函数”，AI模型通过调用tool来触发外部动作，比如查询数据库、调用计算器、发送邮件。Tools的描述（description）对模型非常重要，大模型通过tool的description字段决定“这个任务该调用哪个工具”，所以写清晰的工具描述比写正确的工具实现还要重要。Resources是“可读取的数据”，比如数据库表内容、文件内容、API响应结果，模型通过读取resource来获取上下文。Prompts是“可复用的提示模板”，把一套固定的提问流程封装起来，让模型按照模板工作。三者组合起来，就构成了一个完整的AI工具链：模型先读资源（了解背景）→ 调用工具（执行动作）→ 返回结果（继续推理）。
从RPC角度理解这三个原语会更清晰：Tools和Resources都是JSON-RPC方法（method），它们被定义为类似tools/call、resources/read这样的标准方法名，客户端（AI应用）调用这些方法，服务端（MCP Server）处理并返回结果。这跟gRPC里定义service接口、通过stub去调用远端方法，本质思维是一致的。
3.3 MCP在前后端项目中的接入形态
MCP的实际落地形态，目前主要是两类：一类是给AI IDE（比如带AI能力的编辑器、通义灵码这类插件）接入MCP Server，让IDE里的AI助手能直接读数据库、操作代码；另一类是给独立AI应用（比如企业内的AI客服、AI报表工具）接入MCP Server，让模型能访问内部业务系统数据。
热词里“idea插件通义灵码怎么使用mcp链接oracle”“codex 接入 figma mcp”“codex 接入 蓝湖mcp”都是这类场景。以通义灵码为例，要在IDE的AI助手里通过MCP连接Oracle数据库，流程大概是：先在MCP Server里实现一个查Oracle的工具（比如query_oracle），再把Server地址配置到IDE的MCP客户端设置里，之后AI助手就能在对话里直接执行query_oracle("select * from users")这样的工具调用来查库。这背后的通信链路就是：AI模型发送“调用query_oracle”的JSON-RPC请求到MCP Server → Server执行SQL → 返回结果给模型。
热词里还有“x32dbg 的mcp插件”“cheat engine 桥接 mcp教程”“ue5.8 mcp codex”这些偏逆向/游戏/渲染领域的MCP实践。这些都是同一个模式：把某个特定领域的工具能力封装成MCP Server，让AI模型能够调用。说明MCP标准化之后，接入AI的工具类型正在快速扩展，从后端数据库到前端设计工具，再到调试器，都在尝试变成“AI可调用的工具”。
4. 实操：RPC调用失败排查与MCP Server配置
4.1 典型的“RPC调用失败”报错到底是什么回事
热词里有一条非常典型的报错：“cannot finish rpc call in 30 seconds: nul,done. error: rpc 失败。curl 56 recv failure: 连接超时00 kib/s error: 预期仍”。这看起来很乱，但拆开来看其实是三个不同层面的问题混在一起。
“cannot finish rpc call in 30 seconds”通常是RPC框架自带的超时控制，框架规定一次RPC调用最长时间是30秒，超过就强制中断。这个“30秒”是很多框架的默认值，在高并发或下游服务响应慢的场景下极易触发。“curl 56 recv failure: 连接超时00 kib/s”是curl的错误码，56代表“接收数据时连接失败”，说明TCP连接虽然建立了，但数据传输过程中断，传输速率跌到0 KB/s。“error: 预期仍”应该是“预期仍有数据未收到”的截断——服务端没有返回完整的响应体就关闭了连接。
排查这类问题，我的固定顺序是：先看错误发生在“连接建立阶段”还是“数据传输阶段”。连接建立阶段超时（connect timeout），大概率是网络不通、防火墙拦截、目标端口未监听；数据传输阶段超时（read/write timeout），大概率是服务端处理慢、响应体过大、客户端缓冲区设置不合理。这个案例的curl 56发生在数据传输阶段，优先怀疑服务端响应慢或连接被中间设备断开。接着看服务端日志里的处理耗时，如果某个方法执行时间接近30秒，优先优化该方法的数据库查询或外部依赖调用；如果日志里没有耗时记录，说明请求压根没到服务端逻辑层，就要查网络链路和负载均衡的健康检查配置。
4.2 超时参数与服务端处理能力的关系
超时时间设置，不是越大越好，也不是越小越好，它需要跟服务端的P99耗时曲线对齐。假设你调用的下游接口，P99耗时是800毫秒，那客户端超时设置成2秒就够宽裕；如果P50都要3秒，那超时最少也要给到5秒以上。比较稳妥的做法是先给一个宽裕的初始值（比如10秒），压测时观察实际耗时分布，再把超时逐步收紧到P99的1.5~2倍左右。设置太短，偶发波动会导致大量“超时误杀”；设置太长，下游故障时请求会全堆在服务端等待队列里，适得其反。
跟超时并列的一个重要参数是重试次数。RPC框架默认可能开3次重试，但重试是有代价的：每次重试都会给下游增加一份压力。如果下游已经因为过载而慢响应，重试只会雪上加霜。正确做法是区分“幂等请求”和“非幂等请求”，只有查询类（幂等）接口才允许自动重试，写操作（下单、扣款）一律禁止自动重试，需要引入分布式事务或最终一致性方案来兜底。这是我踩过多次坑后的真实体会，很多线上事故都是“超时→重试→下游更堵→再超时→再重试”的恶性循环造成的。
4.3 一个RPC（gRPC）与MCP Server的最小可运行对照
先从RPC视角看一个最简gRPC服务。用Protobuf定义一个返回当前时间的service：
// time.proto syntax = "proto3"; package time; service TimeService { rpc GetCurrentTime (TimeRequest) returns (TimeResponse); } message TimeRequest { string req_id = 1; } message TimeResponse { string formatted_time = 1; }生成对应语言的stub代码后，服务端实现GetCurrentTime方法，客户端通过生成的stub发起调用，整个过程对调用方而言就像调用本地方法。这就是RPC框架的标准形态：.proto文件定义接口边界，stub封装网络细节，调用方无感知。
再看MCP Server的最小实现。目前最简单的方式是基于官方SDK写一个Python服务，下面这个示例暴露一个“读取时间”的tool：
# mcp_server.py from mcp.server.fastmcp import FastMCP import datetime mcp = FastMCP("time-server") @mcp.tool() def get_current_time() -> str: """返回当前服务端时间，格式为 YYYY-MM-DD HH:MM:SS""" now = datetime.datetime.now() return now.strftime("%Y-%m-%d %H:%M:%S") if __name__ == "__main__": mcp.run() # 默认走 stdio 传输运行这个脚本后，MCP Server会在标准输入输出（stdio）上监听JSON-RPC请求。你再用任意支持MCP的客户端（比如支持MCP的AI IDE）配置好该Server的启动命令，客户端就能在对话里调用get_current_time这个工具。整个调用链路上，客户端发的请求大致是这样的（JSON-RPC 2.0格式）：
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "get_current_time", "arguments": {} } }Server端收到tools/call后，把执行结果封装成JSON-RPC响应返回。这就是最基础的MCP通信过程，底层就是标准的JSON-RPC远程调用，跟RPC的思想完全一致。理解了这一个请求的完整流转，再看任何MCP框架的文档都会轻松很多，因为工具定义再怎么花哨，底层都是这套方法调用。
如果要把MCP Server接入远程网络环境，可以把传输方式从stdio改成SSE（Server-Sent Events）或者Streamable HTTP，客户端通过HTTP地址来连接。改动也很小，FastMCP底层封装好了，把mcp.run()改成带传输参数的运行方式即可。但要注意，改成远程传输后，认证和网络暴露面就成了必须考虑的问题，MCP Server本质上是一个可以执行任意定义工具的远程服务，暴露在公网上必须加访问控制。
4.4 常见工具与框架的MCP接入方式速查
| 场景 | 做法 | 关键要点 |
|---|---|---|
| IDEA插件通义灵码连接Oracle | 在MCP Server里实现调用JDBC的tool，将连接串/账号配置到Server环境变量 | 注意SQL注入防护，tool描述写清楚参数含义 |
| Codex接入Figma/蓝湖 | 配置Codex的MCP客户端设置，指向Figma/蓝湖官方MCP Server | 授权通常走OAuth，需要先完成令牌获取 |
| Debugger（x64dbg/CE）桥接MCP | 实现对应调试器的MCP插件，通过MCP Server暴露内存读写/寄存器读取工具 | 注意调试会话隔离，避免工具调用阻塞UI线程 |
| UE5.8 + MCP | 在UE项目中嵌入MCP Server插件，暴露关卡控制/资产查询工具给AI | 引擎线程与网络线程分离，注意线程安全 |
| Dify平台接入浏览器MCP | 在Dify工具配置里添加MCP Server URL，自动发现工具列表 | 确认工具Schema兼容，工具别名匹配时优先 |
| PostgreSQL 查询工具 | 实现query_pg工具，底层走连接池执行SQL并返回结果集 | 单次查询限制返回行数，防止大结果集拖垮模型上下文 |
这张表覆盖了我最近看到的高频场景，也都是实际项目中比较容易踩坑的地方。表格里每一条背后的细节都够单独写一篇，这里先给方向，遇到具体问题再按协议排查即可。
5. 前后端分离项目里的RPC地基：跨域、重复提交与接口设计
5.1 不要被“前后端分离”骗了，通信基础决定上层体验
前后端分离项目里，RPC的“后端”视角和“前端”视角是完全不同的。后端工程师眼里的RPC是Dubbo、gRPC、Feign这些服务间调用工具，前端工程师眼里的“通信”更多是浏览器发出的HTTP请求、CORS跨域、接口鉴权、重复提交。这两个视角在同一个项目里需要互相理解：前端调用的BFF接口，后端在BFF里通过RPC去聚合下游服务，一旦下游RPC超时，BFF返回给前端的响应也会变慢，前端表现就是“请求一直转圈”。
搜索热词里“前后端分离项目实战”“后端跨域”“前后端对于按钮重复提交校验方法”这些都是前后端交互中的高频问题。跨域问题的本质是浏览器的同源策略：页面A来自http://localhost:3000，要请求http://localhost:8080的接口，被浏览器拦截。后端最常见的解法是加CORS响应头，比如在Spring Boot里配置CorsFilter，允许指定来源、指定方法、指定Header。但要注意，CORS拦截只是浏览器层面的拦截，服务端其实能正常接收请求，所以真正的安全防控不能只靠CORS，还需要做服务端鉴权和校验。
5.2 按钮重复提交：前后端双保险
按钮重复提交在前后端项目里非常经典。用户快速点两下“提交订单”按钮，前端可能发出两次请求，后端可能就会创建两笔订单。前端能做的有：按钮置灰（用loading状态禁用按钮）、请求去重（同一时间窗内相同的请求直接丢弃）、防抖节流（一定时间内只触发一次）。但前端手段永远不是绝对可靠的——页面刷新、网络重试、恶意脚本都可能绕过前端限制。所以真正可靠的做法是后端加幂等校验：创建订单的接口接收一个“幂等键”（通常用前端的UUID或业务ID），后端在Redis里检查这个幂等键是否已存在，存在就直接返回第一次的响应，不存在才继续处理并写入幂等键。这里用到的本质还是分布式系统中的幂等设计，跟RPC重试时的幂等判断是同一个道理。
真实项目里，我把“前端提交按钮最佳实践”整理成了一条约定：所有涉及写操作的提交按钮，必须实现“请求中状态+结果失败恢复”的双重状态机，杜绝重复请求；同时后端必须实现“幂等键+RPC最终一致性”兜底。前端防误触，后端防重放，只有两层都做透了，重复提交才算真正解决。
6. 后端项目实战中的RPC与MCP避坑经验
6.1 服务注册中心的那些隐性坑
注册中心是RPC链路里的“通讯录”。服务实例启动时把自己注册进去，下线时把自己移除，调用方从注册中心拿到可用实例列表。但注册中心有几个隐性坑：第一，实例下线通知不一定实时，服务提供方被强杀（比如kill -9）时，注册中心可能在心跳超时（默认几十秒）之后才摘除该实例，这段时间内调用方依然会路由到死节点，大量请求超时；第二，注册中心节点本身的高可用很重要，很多人依赖一个单点Nacos或单点Consul，注册中心一挂，整个RPC链路全断。
应对思路有两个方向：一个是靠客户端缓存，RPC框架的客户端（如Dubbo Consumer）会缓存服务地址列表，即使注册中心暂时不可用，现有连接还能继续工作一段时间；另一个是靠多级容错，在注册中心不可用时回退到本地配置或最后已知地址。我实际排查过的一个案例里，某个服务频繁超时，最后定位到问题竟然是服务实例的IP地址是内网保留段，注册到Nacos后调用方从另一个VPC访问不到——这类网络拓扑问题，排查优先级比调参高得多。
6.2 MCP Server开发中的线程与协议问题
MCP Server虽然代码写起来很简单，但放到生产环境，还是有一些和业务系统耦合的坑。第一个坑是线程模型：如果你的MCP Server里某个工具会阻塞调用（比如同步查数据库），而这个工具又被多个请求同时触发，服务端的线程池一旦被占满，其他工具的响应也会跟着变慢。解决方式是对耗时操作使用异步执行（FastMCP里支持async工具，底层用asyncio事件循环），同时给阻塞型工具做好超时和并发限制。
第二个坑是工具描述（description）的质量。大模型选择工具时，靠的是工具名和描述文本的语义匹配，而不是人类在UI里做的“先选后填”。如果你把一个查询订单的工具描述写成“order_detail”，模型很难知道这个工具适合什么时候用；但如果你写成“根据订单号查询订单的详细状态，包括金额、物流、退款进度”，模型就能精准触发。我实测过，在MCP工具多的情况下，描述写得精准与否，直接决定模型能不能在第一步就选对工具，这比去调整模型温度参数有效得多。
第三个坑是错误返回格式。工具执行失败时，不要直接抛异常让整个JSON-RPC请求失败，应该把失败信息包装成工具返回值的一部分返回给模型。比如查询数据库失败，工具应该返回{"success": false, "error": "数据库连接超时, traceId: xxx"}，而不是让MCP Server直接返回error。原因很简单：模型看到结构化错误信息，才能理解失败原因并调整后续策略；模型收到一个异常堆栈，只会复述“我遇到了错误”。
6.3 从“会用RPC”到“懂得设计RPC边界”
最后想聊一个后端常见项目里最容易忽略的点：RPC边界的划分。通信基础讲得再细，如果服务之间的边界划分不合理，再好的RPC框架也救不回来。比如订单服务跟支付服务之间，边界是“状态机+领域事件”，订单服务只关心“支付完成”这个事件，具体怎么跟第三方支付渠道交互是支付服务自己的事。如果你把第三方支付的通信逻辑放在了订单服务里，跨服务RPC调用就会缠成一团乱麻。
设计RPC边界时，我会先问三个问题：这个接口是给谁调的（内部服务/BFF/外部系统）？数据一致性要求是什么（强一致/最终一致/读多写少）？失败之后能容忍多大延迟和丢失（不能容忍→必须同步RPC+重试；能容忍→可以走异步消息）？回答完这三个问题，接口粒度、同步/异步、重试策略基本就定了。跟产品经理确认需求时，也要把这三个问题摆在桌面上聊清楚，很多“接口到底该谁来做”的争论，根源就是边界没对齐。
RPC只是工具，边界设计才是后端架构的灵魂。这也是我在这篇文章最后最想表达的东西：不管是RPC还是MCP，通信协议最终都是为业务边界服务的，你把边界想清楚了，工具选型自然就有了答案。
