为什么 MCP 服务器难以部署在 Serverless 架构上？随着大模型生态的发展，MCP（Model Context Protocol，模型上下文协议）成为了连接 AI 助手与外部工具的热门选择

Thu, 16 Jul 2026 15:14:45 GMT

为什么 MCP 服务器难以部署在 Serverless 架构上？

随着大模型生态的发展，MCP（Model Context Protocol，模型上下文协议）成为了连接 AI 助手与外部工具的热门选择。然而，在实际部署中，开发者很快就会遇到一个棘手的架构问题：MCP 服务器默认是有状态的（Stateful）。

1. 单客户端的尴尬限制

在最基础的 HTTP/SSE（Server-Sent Events）实现中，服务器通常会将连接通道（Transport）保存在内存变量中。这意味着，一旦有第二个客户端尝试连接，前一个客户端的连接就会被迫中断。

2. 内存常驻与 Serverless 的冲突

即便我们通过引入 ID 标识来管理多个连接，依然无法解决核心问题——连接状态依然保存在服务器的内存中。

这种“有状态”的特性，直接把 Serverless 部署方案（如 Vercel、AWS Lambda）排除在外。因为 Serverless 函数在请求结束后会随时销毁实例，导致内存中的连接状态丢失。要维持连接，你只能选择 VPS 等需要持续运行的服务器，这增加了运维成本。

3. 如何实现无状态化？

目前最可行的解决方案是将状态外置。我们可以将 Transport 信息存储到像 Redis 这样的键值数据库中。

通过将状态抽离到 Redis，MCP 服务器成功实现了无状态化（Stateless），从而能够自由地部署到 Vercel 等 Serverless 平台上。Vercel 官方开源的 mcp-on-vercel 项目正是采用了这种架构设计。

思考

虽然通过 Redis 解决了部署问题，但这无疑增加了系统的复杂度。我们不禁会想：在协议设计之初，是否应该让客户端去承担更多的状态维护，从而避免让服务端背上数据库的包袱？

---

原文链接：https://www.aihero.dev/the-problem-with-mcp-stateful-server

#MCP #Serverless #系统架构 #Redis #AI开发

www.aihero.dev

The Problem With MCP: Stateful Servers

Discover how to deploy MCP servers statelessly using Redis, enabling compatibility with serverless platforms like Vercel and AWS Lambda.

AI 记忆系统不该靠“设计”，而应靠“演化”如今，开发者们热衷于为 AI 助手构建各种复杂的记忆架构，比如向量检索、知识图谱、语义记忆、遗忘机制等

Sun, 28 Jun 2026 07:23:27 GMT

AI 记忆系统不该靠“设计”，而应靠“演化”

如今，开发者们热衷于为 AI 助手构建各种复杂的记忆架构，比如向量检索、知识图谱、语义记忆、遗忘机制等。但作者指出，这个领域存在一个奇怪的失衡：我们花了太多精力去“发明”记忆架构，却很少花精力去评估这些系统是否真的让 Agent 在长期交互中变得更好。

很多所谓的记忆系统，大多只是基于开发者个人对“好记忆”的狭隘定义而做出的过度工程（Over-engineering）。

💡 核心观点：记忆是“涌现”出来的

记忆并不是系统的第一顺位基础能力。相反，记忆是在持续交互的压力下，为了让系统表现得更好而涌现出来的“二阶效应”。

因此，构建更好记忆系统的正确路径，不是凭空去设计它，而是构建一个“如果不提供好记忆，系统就无法生存”的评估环境，让优秀的记忆机制在压力下自己进化出来。

⚠️ 现有静态评估的缺陷

目前的记忆评估大多是静态的：给 AI 一段历史记录，问一个当前问题，检查 AI 能否检索到相关事实。
这种方式的弊端显而易见：

• 它只能测试单一时间节点的检索能力。
• 它无法评估记忆随着时间推移的更新、冲突解决和衰减。
• 它忽略了用户体验的反馈循环——如果 AI 记忆表现不佳，用户在现实中会逐渐失去耐心，减少或停止相关交互。

🛠️ 理想的“纵向记忆评估”方案

为了解决这一问题，我们需要构建一个**纵向记忆评估（Longitudinal Eval）**环境，主要包含以下要素：

1. 可重放的交互历史与未来依赖：模拟一连串（例如 200 次）的连续对话，后续的测试点会深度依赖前期的隐性偏好或数据。
2. 动态用户模拟（User Simulation）：用模拟的用户 Agent 来产生真实的对话。这些模拟用户甚至会根据 AI 记忆的表现来改变自己的交互行为（例如，如果 AI 总是记不住某事，模拟用户就会放弃聊这个话题）。
3. 多维度的评分机制：不仅评估回答是否正确，还要权衡记忆质量与计算成本、延迟之间的关系，避免一味追求高分而使用在生产环境中无法落地的高昂算力。

结语

不要再尝试自上而下地去设计完美的记忆架构了。我们应该先建好“角斗场”（评估环境），让环境压力筛选出最合理的记忆方案。

阅读原文：https://linghao.io/posts/memory-systems-should-be-evolved

#人工智能 #AI_Agent #记忆系统 #大语言模型 #系统评估

linghao.io

Evolving Memory Systems: An Eval-First Approach

AI memory systems are often designed as architectural bets: vector stores, profiles, summaries, graphs, etc. This post argues for a different starting point: build longitudinal eval environments where systems without good memory cannot survive, then let better…

系统架构 | 面条的草稿箱

为什么 MCP 服务器难以部署在 Serverless 架构上？随着大模型生态的发展，MCP（Model Context Protocol，模型上下文协议）成为了连接 AI 助手与外部工具的热门选择

AI 记忆系统不该靠“设计”，而应靠“演化”如今，开发者们热衷于为 AI 助手构建各种复杂的记忆架构，比如向量检索、知识图谱、语义记忆、遗忘机制等