本文摘要：大模型是无状态的。

我之前有个东西想错了，我觉得大模型是在应用程序中处于中心地位，它能够串起整个流程，在串联流程的过程中可以通过 MCP 和外界交互。

犯了这个错，是因为我把大模型（LLM）和 Agent 的概念弄混了。

正确的理解如下：

1. 大模型是无状态的，是被动的。大模型能表现出连续会话能力，不是因为大模型里面保存了上下文，而是“ChatGPT”这一类“聊天软件”帮你把上下文记下来了，每次和大模型对话时，都会通过 Prompt 带上之前的对话上下文。
2. Agent 是有状态的。Agent 负责几个重要的事情（1）编排逻辑顺序 （2）调用大模型获取智能决策/结果 （3）调用工具（4）维护和用户的交互上下文
3. MCP 是被动的。决策调用哪个 MCP，如何调用 MCP，是大模型的任务。大模型会给 Agent 返回调用方法。具体调用 MCP，是 Agent 的任务。它从大模型处获得调用 Agent 的指令后，会负责执行相应调用逻辑来调用具体的 MCP。 特别注意的是，并不是大模型内部有个什么逻辑会去直接 call MCP，大模型只负责返回一个字符串，Agent 可以把这个字符串解读成对某个 MCP 的调用。

例如：ChatGPT 是 Agent、gpt-5 是大模型。

从 OpenAI 的 API 角度看：

response = client.responses.create(
    model="gpt-5",  // LLM 模型
    tools=tools,    // 告诉 LLM 能调用哪些工具
    input=input_list,  // 给大模型的输入，包括历史会话和当前最新输入
)

上面的 response 里，可能是调用工具的指令，可能是一句普通的对话回复。

如果是调用工具的指令，那么在 Agent 里通过这样的逻辑可以判断和调用工具：

for item in response.output:
    if item.type == "function_call":
        if item.name == "get_weather":
            # 3. Execute the function logic for get_weather
            weather = get_weather(json.loads(item.arguments))

写上面 “大模型是无状态的” 这一段时，我明白了另一个问题。因为大模型无状态，需要在每一次对话中附带上对话上下文，模拟出一个“大模型有状态”的假象。这就自然引入了一个问题：Agent 如何组织对话上下文？
回答这个问题，就让我一下子意识到以前看文章时，经常提到的一些东西到底是干嘛的，比如“上下文工程”，“向量上下文检索”，“长期短期记忆”，“本软件只保留3条上下文对话”。他们都在解决一个问题：对着对话次数增多，如何保证上下文不会爆炸？常见技术有：

• 只保留短期记忆，也就是和 LLM 对话时，只附带最近的几句对话。过去说过啥全忘。模型可能显得很傻。
• 短期记忆+长期记忆，也就是除了最近的几句对话外，还会把历史对话也带上。但历史对话部分没有短期对话那么精确，可能是把多句话组成一个摘要。
• 结构化状态管理，就是维护一个 Agent 层面的状态，如“第几个笑话”，“第三个单词” 之类的，推动大模型继续往前走。至于前面若干个笑话，具体内容不重要。

长期记忆如何检索呢？因为它不是严格字符串匹配，而是要做语义匹配，所以需要embedding，需要向量检索。也就是说，我们很多数据库领域关心的 AI 需求，都是为了上下文工程而来的。

LLM 不是数据库，它不能长期记忆和存储所有知识，只能短期“看输入的 context”。于是就出现了 RAG（Retrieval-Augmented Generation） 的需求。

向量数据库在 LLM 时代主要解决 外部知识接入 问题：
1. 知识检索：
用户问问题 → 把问题 embedding → 去向量数据库里找最相似的文档 → 把结果塞进 LLM → LLM 基于上下文生成回答。
（典型例子：企业知识库问答、法律/医疗问答）
2. 长对话记忆：
聊天内容很长，LLM的上下文窗口有限。
→ 把旧对话 embedding 存进向量数据库
→ 每次新消息时，检索出最相关的历史对话，再交给 LLM。
（解决“聊天不连贯”的问题）
3. 跨模态检索：
• 输入一张图片，检索相关文档
• 输入一句话，找相似代码片段
（统一 embedding 空间 → 统一检索）
4. 个性化推荐/助手：
向量库里存用户偏好、历史行为 embedding，LLM 可以随时查 → 个性化生成。