从 LLM 到 Agent：MCP 驱动的 AI 应用架构完整理解

本文是一份面向 AI 应用开发者 / Agent 架构学习者 的系统性笔记，用于澄清 LLM、MCP、Tool、Application、Agent 之间的关系，并建立正确的心智模型。

一、LLM（大语言模型）的本质

1. LLM 能做什么

• LLM 本质是一个 条件概率模型
• 在给定上下文（Context）下：
  • 进行推理（Reasoning）
  • 生成下一步最合理的输出（文本 / JSON / 工具调用意图）

2. LLM 不能做什么

• ❌ 不能执行真实世界操作
• ❌ 不能访问系统、文件、数据库、网络
• ❌ 不知道工具是否真的被执行

结论：LLM 只“会想”，不会“做事”。

二、AI 应用程序（Application）的真实角色

AI 应用程序是整个系统中的 执行与控制中枢。

它通常负责：

• 调用 LLM 获取推理结果
• 维护上下文（历史对话、状态、执行结果）
• 管理工具与资源
• 执行真实操作（代码、API、系统调用）
• 控制整体运行流程（是否继续、是否终止）

真正“会做事”的是应用程序，而不是 LLM。

三、MCP（Model Context Protocol）是什么

1. MCP 的定义

模型上下文协议（Model Context Protocol，MCP） 是一套标准协议，用于规范：

• AI 应用如何向 LLM 提供上下文
• 如何向 LLM 描述可用的外部能力
• 如何让 LLM 理解“它能做什么、不能做什么”

2. MCP 解决的问题

在 MCP 之前：

• 每个应用用各自方式描述工具
• 模型难以迁移、能力难以复用

MCP 提供：

• 统一的工具 / 资源描述方式
• 清晰的能力边界
• 可组合、可扩展的上下文结构

四、MCP 的核心组成

1. Tools（工具）

• Tool ≠ 普通函数
• Tool 是 “可被模型理解的能力描述”

通常包含：

• 工具的语义说明（做什么）
• 输入参数 Schema
• 输出结果 Schema
• 使用约束

2. Resources（资源）

• 外部可读取的信息
• 如：文件、数据库记录、API 数据、系统状态

3. Context（上下文）

• 对话历史
• 中间推理结果
• 工具执行反馈

五、Agent 是什么（非常重要）

1. Agent 不是一个“组件”

Agent 不是：

• 一个类
• 一个函数
• 一个 SDK

而是：

一种系统运行形态（Runtime Pattern）

2. Agent 成立的 4 个必要条件

一个应用程序在满足以下条件时，才可以被称为 Agent：

① 有目标（Goal-driven）

• 面向“完成任务”，而不是单次问答

② 有持续推理（Multi-step Reasoning）

• 不止一次 LLM 调用
• 能基于中间结果调整下一步决策

③ 有行动能力（Actions / Tools）

• 能调用真实工具
• 能改变外部或内部状态

④ 有反馈闭环（Observe → Think → Act）

典型 Agent Loop：

Observe（读取上下文 / 状态）
→ Think（LLM 推理）
→ Act（执行工具）
→ Observe（结果回填）
→ ...

没有闭环，就不是 Agent。

六、应用程序 与 Agent 的关系

1. 是否可以说“应用程序 = Agent”？

结论：视语境而定。

• ❌ 所有应用程序 ≠ Agent
• ✅ 具备 Agent Loop 的应用程序 = Agent

2. 更精确的关系表达

• 应用程序：

  • Agent 的运行载体（Runtime / Executor）

• Agent：

  • 应用程序 + LLM + MCP + 决策闭环 的整体形态

七、推荐的心智模型（强烈建议记住）

层级	角色	职责
LLM	大脑	推理、决策
MCP / Tools	手和感官	能力描述、信息获取
Application	身体与神经系统	执行、调度、状态管理
Agent	活起来的整体	自动完成任务

Agent 不是某一层，而是“跑起来的系统整体”。

八、关键结论总结

• LLM 负责“想”，不负责“做”
• MCP 负责“告诉模型能做什么”
• 应用程序负责“真正执行”
• Agent 是一种 推理 + 行动 + 反馈 的系统运行形态

真正的智能，来自于：

LLM 推理能力 × MCP 能力边界 × 应用程序执行闭环

九、一句话终极总结

Agent = 运行在应用程序中的、以 LLM 为决策核心、通过 MCP 获得行动能力的自动化系统。