MCP 解决了工具连接的标准化但在企业多用户场景下会话隔离和权限管理这一层它没有覆盖。这篇说清楚这个问题在本方案里是怎么解决的以及为什么选择 MQTT 作为通信骨干。问题从哪里来一个企业部署的 AI 工作台同时在线的用户可能有几十个。张三在让数字员工查采购记录李四在生成出库单王五在分析设备维护历史。这三个会话在时间上是重叠的在数据上是完全不同的在权限上也可能不一样比如张三能看采购数据王五只能看设备数据。这带来一系列工程要求如会话之间的消息不能串台、每个会话的权限边界必须独立维护、Agent 的推理过程是异步的用户发出请求之后不是同步等待一个返回值而是等待一个可能持续几十秒甚至几分钟的流式过程等。MCP 的主价值在工具描述和调用标准化虽然它现在也已经支持流式传输、通知和订阅不只是一个同步请求-响应协议。但它本身并不是为企业级多用户会话治理设计的。要在 MCP 之上实现这三个要求仍然需要在外层补上会话管理、权限隔离和审计机制而且这些能力通常不会由 MCP Server 自动统一提供。MQTT 从协议设计上就是为异步消息、多客户端并发、主题隔离这类场景设计的恰好和企业多用户场景的需求对齐。MQTT 的基本结构MQTT 是一个发布-订阅协议核心概念是三个Broker消息代理、Topic主题、Client客户端。Broker 是消息中转站所有消息都经过它流转。Client 可以发布消息到某个 Topic也可以订阅某个 Topic 上的消息。发布者和订阅者不需要同时在线也不需要知道对方是谁只需要约定好 Topic 的命名规则。Topic 是一个字符串类似文件系统的路径格式比如agent/session_001/input或agent/session_001/output。Broker 根据 Topic 把消息路由到对应的订阅者。这个结构很适合表达隔离不同会话用不同的 Topic 前缀Broker 就能基于这个前缀做路由和授权控制。Topic 命名规则定义了隔离边界真正让隔离生效的是客户端身份认证和 Broker 的 ACL 规则。双链路设计本方案里MQTT 承载了两条独立的链路它们对应架构里的两个不同方向的通信。链路一用户到 Agent。用户在交互层发出任务请求这条消息通过 MQTT Client 发布到一个以当前用户会话 ID 为前缀的 Topic比如oc/user_zhang/input。Agent 订阅了这个 Topic收到消息后开始处理。处理过程中的中间反馈和最终结果Agent 发布到对应的输出 Topic比如oc/user_zhang/output交互层订阅这个 Topic实时展示给用户。这条链路的隔离边界由 Topic 前缀定义。张三的请求发到oc/user_zhang/input李四的请求发到oc/user_li/input两条消息在 Broker 里走的是独立通道。在 Topic 设计、客户端身份绑定和 ACL 配置都正确的前提下会话串台的风险可以被压到很低。即便两个请求几乎同时到达各自的处理过程和结果也可以保持独立。链路二Agent 到业务系统。Agent 决定调用某个业务系统的接口时不是直接发起 HTTP 请求而是把调用指令发布到一个 Topic业务系统侧的 MQTT Client 订阅这个 Topic收到指令后执行实际的接口调用把结果发布回另一个 TopicAgent 订阅这个结果 Topic拿到返回数据继续推理。这条链路解决的是另一个问题业务系统部署在内网Agent 执行层部署在 DMZ隔离网络两者之间不能直接建立 HTTP 连接。在本文讨论的网络拓扑里MQTT Broker 被放在一个内外两侧都可达的位置内网的业务系统主动连出DMZ 里的 Agent 也主动连出两者通过 Broker 中转不需要彼此直接连通。在这种部署方式下内网不需要为 Agent 单独开放入站端口安全边界更容易保持清晰。Topic 的隔离机制Topic 隔离不只是消息不串台它还是权限控制的基础。MQTT Broker比如 EMQX支持基于 Topic 的访问控制可以配置某个客户端只能发布或订阅哪些 Topic 前缀。张三登录工作台系统为他分配一个会话 Token这个 Token 对应的 MQTT Client 只能访问oc/user_zhang/*这个前缀下的 Topic。他发出去的消息只能发到这个前缀他能收到的消息也只能来自这个前缀。即便有人恶意伪造一个请求发到李四的 TopicBroker 会直接拒绝因为这个客户端没有发布到那个 Topic 的权限。这个机制减少了在业务代码里手写会话隔离逻辑的需求把消息级别的隔离和访问控制尽量收敛到 Broker 的认证与授权层。异步模型的价值Agent 处理一个复杂任务可能需要一两分钟在这段时间里用户不应该傻等一个同步返回。MQTT 的发布-订阅模型天然是异步的——用户发出请求之后可以继续做别的事Agent 处理完一个阶段就把中间结果发布到输出 Topic交互层实时展示用户看到的是一个动态更新的进度而不是一个转圈等待的界面。这也让人在回路的实现更自然。Agent 在某个决策点需要用户确认时把问题发布到输出 Topic交互层展示给用户用户的回答通过输入 Topic 发回Agent 继续。这整个过程都在同一个会话的 Topic 通道里流动通信链路本身不需要额外设计一套同步阻塞机制但 Agent 的任务状态、暂停点和上下文仍然需要由执行层自己维护。同步模型在这里是反向的如果用 HTTP 请求-响应做这件事要么请求一直挂着等 Agent 处理完连接超时问题要么轮询低效且增加服务端压力要么 WebSocket可以做但需要额外管理连接状态。MQTT 的发布-订阅模型把这些问题都绕开了。和 MCP 是什么关系把 MQTT 定位清楚之后再回头看 MCP两者的关系就清楚了。MCP 解决的是工具的接口怎么描述和调用这个问题是工具层的标准化协议。MQTT 解决的是消息怎么在用户、Agent、业务系统之间路由和隔离这个问题是通信层的传输机制。两者解决的不是同一层的问题不是替代关系。即便未来在本方案里引入 MCP它更适合承担的也是工具接入和能力描述这一层而不是直接替代消息总线、会话隔离和跨网络通信骨干。技术选型应该跟着工程需求走而不是跟着某个协议或框架的知名度走。选 MQTT 不是因为它比 MCP 更好是因为它在企业多用户异步通信这个具体问题上提供的是一个更匹配的解。
为什么不用 MCP，而用 MQTT？企业级多用户场景的通信架构选择
MCP 解决了工具连接的标准化但在企业多用户场景下会话隔离和权限管理这一层它没有覆盖。这篇说清楚这个问题在本方案里是怎么解决的以及为什么选择 MQTT 作为通信骨干。问题从哪里来一个企业部署的 AI 工作台同时在线的用户可能有几十个。张三在让数字员工查采购记录李四在生成出库单王五在分析设备维护历史。这三个会话在时间上是重叠的在数据上是完全不同的在权限上也可能不一样比如张三能看采购数据王五只能看设备数据。这带来一系列工程要求如会话之间的消息不能串台、每个会话的权限边界必须独立维护、Agent 的推理过程是异步的用户发出请求之后不是同步等待一个返回值而是等待一个可能持续几十秒甚至几分钟的流式过程等。MCP 的主价值在工具描述和调用标准化虽然它现在也已经支持流式传输、通知和订阅不只是一个同步请求-响应协议。但它本身并不是为企业级多用户会话治理设计的。要在 MCP 之上实现这三个要求仍然需要在外层补上会话管理、权限隔离和审计机制而且这些能力通常不会由 MCP Server 自动统一提供。MQTT 从协议设计上就是为异步消息、多客户端并发、主题隔离这类场景设计的恰好和企业多用户场景的需求对齐。MQTT 的基本结构MQTT 是一个发布-订阅协议核心概念是三个Broker消息代理、Topic主题、Client客户端。Broker 是消息中转站所有消息都经过它流转。Client 可以发布消息到某个 Topic也可以订阅某个 Topic 上的消息。发布者和订阅者不需要同时在线也不需要知道对方是谁只需要约定好 Topic 的命名规则。Topic 是一个字符串类似文件系统的路径格式比如agent/session_001/input或agent/session_001/output。Broker 根据 Topic 把消息路由到对应的订阅者。这个结构很适合表达隔离不同会话用不同的 Topic 前缀Broker 就能基于这个前缀做路由和授权控制。Topic 命名规则定义了隔离边界真正让隔离生效的是客户端身份认证和 Broker 的 ACL 规则。双链路设计本方案里MQTT 承载了两条独立的链路它们对应架构里的两个不同方向的通信。链路一用户到 Agent。用户在交互层发出任务请求这条消息通过 MQTT Client 发布到一个以当前用户会话 ID 为前缀的 Topic比如oc/user_zhang/input。Agent 订阅了这个 Topic收到消息后开始处理。处理过程中的中间反馈和最终结果Agent 发布到对应的输出 Topic比如oc/user_zhang/output交互层订阅这个 Topic实时展示给用户。这条链路的隔离边界由 Topic 前缀定义。张三的请求发到oc/user_zhang/input李四的请求发到oc/user_li/input两条消息在 Broker 里走的是独立通道。在 Topic 设计、客户端身份绑定和 ACL 配置都正确的前提下会话串台的风险可以被压到很低。即便两个请求几乎同时到达各自的处理过程和结果也可以保持独立。链路二Agent 到业务系统。Agent 决定调用某个业务系统的接口时不是直接发起 HTTP 请求而是把调用指令发布到一个 Topic业务系统侧的 MQTT Client 订阅这个 Topic收到指令后执行实际的接口调用把结果发布回另一个 TopicAgent 订阅这个结果 Topic拿到返回数据继续推理。这条链路解决的是另一个问题业务系统部署在内网Agent 执行层部署在 DMZ隔离网络两者之间不能直接建立 HTTP 连接。在本文讨论的网络拓扑里MQTT Broker 被放在一个内外两侧都可达的位置内网的业务系统主动连出DMZ 里的 Agent 也主动连出两者通过 Broker 中转不需要彼此直接连通。在这种部署方式下内网不需要为 Agent 单独开放入站端口安全边界更容易保持清晰。Topic 的隔离机制Topic 隔离不只是消息不串台它还是权限控制的基础。MQTT Broker比如 EMQX支持基于 Topic 的访问控制可以配置某个客户端只能发布或订阅哪些 Topic 前缀。张三登录工作台系统为他分配一个会话 Token这个 Token 对应的 MQTT Client 只能访问oc/user_zhang/*这个前缀下的 Topic。他发出去的消息只能发到这个前缀他能收到的消息也只能来自这个前缀。即便有人恶意伪造一个请求发到李四的 TopicBroker 会直接拒绝因为这个客户端没有发布到那个 Topic 的权限。这个机制减少了在业务代码里手写会话隔离逻辑的需求把消息级别的隔离和访问控制尽量收敛到 Broker 的认证与授权层。异步模型的价值Agent 处理一个复杂任务可能需要一两分钟在这段时间里用户不应该傻等一个同步返回。MQTT 的发布-订阅模型天然是异步的——用户发出请求之后可以继续做别的事Agent 处理完一个阶段就把中间结果发布到输出 Topic交互层实时展示用户看到的是一个动态更新的进度而不是一个转圈等待的界面。这也让人在回路的实现更自然。Agent 在某个决策点需要用户确认时把问题发布到输出 Topic交互层展示给用户用户的回答通过输入 Topic 发回Agent 继续。这整个过程都在同一个会话的 Topic 通道里流动通信链路本身不需要额外设计一套同步阻塞机制但 Agent 的任务状态、暂停点和上下文仍然需要由执行层自己维护。同步模型在这里是反向的如果用 HTTP 请求-响应做这件事要么请求一直挂着等 Agent 处理完连接超时问题要么轮询低效且增加服务端压力要么 WebSocket可以做但需要额外管理连接状态。MQTT 的发布-订阅模型把这些问题都绕开了。和 MCP 是什么关系把 MQTT 定位清楚之后再回头看 MCP两者的关系就清楚了。MCP 解决的是工具的接口怎么描述和调用这个问题是工具层的标准化协议。MQTT 解决的是消息怎么在用户、Agent、业务系统之间路由和隔离这个问题是通信层的传输机制。两者解决的不是同一层的问题不是替代关系。即便未来在本方案里引入 MCP它更适合承担的也是工具接入和能力描述这一层而不是直接替代消息总线、会话隔离和跨网络通信骨干。技术选型应该跟着工程需求走而不是跟着某个协议或框架的知名度走。选 MQTT 不是因为它比 MCP 更好是因为它在企业多用户异步通信这个具体问题上提供的是一个更匹配的解。
