MCP vs RAG vs AI Agent：三者核心区别速览

生产客户体验代理在发布后需要什么（赞助）

让 CX 机器人上线只是第一步。真正的挑战在于，当真实用户开始使用它之后。

我们的新指南将探讨 Lyft、沃达丰和拉塔姆航空等企业的团队如何在生产环境中运行 CX 机器人。内容涵盖他们如何评估回复质量、监控故障，并利用实际对话持续优化系统。

您将学会：

• 如何避免提示词质量拖累开发进度
• 从一开始就为机器人构建可观测性
• 在故障波及更多用户之前及时发现并应对
• 将客户对话转化为对支持、产品和运营都有价值的信号
• 选择能够在真实 CX 工作流中稳定运行的架构

阅读CX客服人员指南

本周系统设计速览：

• 《JVM 的工作原理》（YouTube 视频）
• MCP 对比 RAG 对比 AI 代理
• 你应该掌握的 9 种分布式系统模式
• 虚拟化与容器化
• HTTP 与 HTTPS

JVM 的工作原理

MCP 对比 RAG 对比 AI 代理

MCP 是一种开放标准协议，用于将 AI 模型与外部工具和数据源连接起来。这些外部资源可以是 API、数据库，也可以是 Gmail、Slack 或 GitHub 等应用。

因此，无需为每个应用单独编写或实现集成，MCP 提供了一种标准化的接入方式。

RAG 模式下，模型会在收到查询时实时检索最新信息。这使得模型不必凭空生成答案，而是从文档、PDF 和数据库等外部数据源获取最新资料，从而给出最贴近当下情况的回应。

AI 代理则是一种能够自主执行任务并作出决策的 AI 系统。与仅负责请求—响应的聊天机器人不同，AI 代理会主动确保整个流程顺畅运行。

你应该掌握的 9 种分布式系统模式

• 在复制模式中，您会制作数据的精确副本，并将其存储在不同的服务器上。
• 在分片模式中，您会将大型数据库水平切分，使不同行的数据分别存放在不同的机器上。
• 在一致性哈希模式中，您借助一个虚拟的环形结构，将数据均匀地分布到多台机器或服务器上。
• PubSub 是一种异步消息传递模式，可实现服务提供者与服务使用者之间的解耦。
• 在断路器模式中，当某个操作很可能失败时，系统会阻止该应用反复执行这一操作。
• 在带有退避机制的重试模式中，您可以从容应对临时性的网络波动或短暂的服务超时问题。这是一种提升系统韧性的模式。
• 在领导者选举模式中，您会指定一个主节点来协调各项操作并维护集群状态，从而避免出现两个节点同时自认为“掌权”的情况。
• 在多数派读写模式中，每次读写操作都会确保有足够多的副本达成一致，使各副本集之间存在交叠。这是一种用于分布式数据库的数据一致性模式，旨在保障信息的实时性。
• Saga 是一种设计模式，通过一系列跨多个微服务的本地事务来管理分布式事务。一旦某一步骤失败，其之前的每一步都将由相应的补偿操作予以撤销。

虚拟化与容器化

在容器技术简化部署之前，虚拟化已经彻底改变了我们利用硬件的方式。两者都能隔离工作负载，但实现方式各有不同。

• 虚拟化（硬件级隔离）：每台虚拟机都运行着一套完整的操作系统——Windows、Fedora 或 Ubuntu——自带内核、驱动程序和库文件。虚拟机监控程序（如 VMware ESXi、Hyper‑V、KVM）直接部署在物理硬件之上，为每个客户操作系统模拟出一台独立的物理机器。这使得虚拟机体积较大，但隔离效果极佳。想在同一台物理机上同时运行 Windows 和 Linux？虚拟机轻松搞定。由于需要从头启动整个操作系统，典型虚拟机的启动时间通常以分钟计。
• 容器化（OS 级隔离）：容器共享宿主机的操作系统内核，不再为每个容器配备独立的 OS，只运行各自隔离的进程，并拥有独立的文件系统和依赖项。容器引擎（Docker、containerd、CRI‑O、Podman）负责管理容器的生命周期、网络连接及隔离，但所有这些都在同一个共享内核之上运行。轻量且启动迅速——因为无需启动操作系统，只需直接启动进程即可。不过有个限制：同一宿主机上的所有容器必须与其内核兼容。如果没有采用嵌套虚拟化等特殊手段，就无法在 Linux 宿主机上运行 Windows 容器。

现在轮到您了：您常用的部署方案是容器运行在虚拟机里、裸金属容器，还是其他方式？

HTTP 与 HTTPS

当您访问一个网站时，HTTP 和 HTTPS 的区别决定了您的数据是在安全状态下传输，还是暴露在明处。以下是它们背后的运作机制：

HTTP：

• 以明文形式发送数据，网络中的任何人都可能截获。
• 客户端和服务器仅进行简单的 TCP 握手：SYN、SYN‑ACK、ACK。
• 速度快，但完全不安全。密码、令牌和表单数据在传输过程中都可能被窃听。

HTTPS（SSL/TLS）：

• 步骤 1：TCP 握手——建立标准连接。
• 步骤 2：证书检查——客户端问候，服务器以问候和自身的 SSL/TLS 证书作为回应。该证书包含服务器的公钥，并由受信任的证书颁发机构签名。您的浏览器会验证该证书是否合法有效、未过期，且确实属于您正尝试访问的域名。这证明您正在与真正的服务器通信，而非冒充它的攻击者。
• 步骤 3：密钥交换——非对称加密在此发生。服务器持有公钥和私钥，客户端生成一个会话密钥，用服务器的公钥加密后发送过去。只有服务器能用自己的私钥解密。至此，双方都掌握了同一把会话密钥，而这把密钥不可能被第三方截获。它将成为后续会话期间使用的对称加密密钥。
• 步骤 4：数据传输——此后，每一次请求和响应都将使用这把会话密钥进行对称加密。

现在轮到您了：您习惯用 openssl、curl -v 还是其他工具来排查 TLS 相关问题？