🧠 LLM 赋能的 AI Agent：从“会说”到“会做”的智能行动系统

🧠 LLM 赋能的 AI Agent：从“会说”到“会做”的智能行动系统

AI Agent（智能体）的浪潮正在将 AI 从“能对话的工具”升级为“能行动的系统”。本文将系统性地梳理 LLM、Agent、Prompt、Function Calling 和 MCP 之间的演进关系和协同机制，带您理解支撑 Agent 行动的核心技术架构。

💡 导语：LLM 与 Agent 的本质区别

Agent 不是 LLM 的替代品，而是它的 进化形态。

1. LLM：语言与推理引擎（会说，不会做）

LLM（大语言模型）能生成文本、推理问题、理解意图、输出结构化内容（如 JSON / Schema），甚至生成 SQL/代码。但它不能执行真实动作（写文件、下单、API 调用）、不能与系统交互、不能保存长期记忆、不能控制状态机，也无法稳定完成多轮复杂任务。

• LLM 的本质是一个超级语言补全器 + 世界模型。
• 示例： 当用户要求“帮我订一个明天飞上海的机票，预算 500 元以内”时，LLM 只会根据训练数据“猜测机票价格”给你几段建议，但不会去查真实航班。本质上，它是在 说 ，不是在 做。

2. Agent：让 LLM 变成“能行动的智能体”（会做）

Agent 是让 LLM 的“推理能力”在系统中运作起来的框架。Agent 必须具备完整闭环：感知 $\rightarrow$ 记忆 $\rightarrow$ 推理 $\rightarrow$ 工具调用 $\rightarrow$ 执行动作 $\rightarrow$ 观察结果 $\rightarrow$ 再推理 $\rightarrow$ 完成任务。

• Agent 的核心价值：完成任务，而不是回复。
• 示例： Agent 会识别意图 $\rightarrow$ 调用真实 API 查询航班 $\rightarrow$ 过滤预算范围 $\rightarrow$ 生成可购买方案。最终 Agent 的输出是找到符合预算的航班方案，而不是建议。

核心总结： LLM 只能“说”，Agent 才能“做”。

类别	LLM	Agent
推理	✔️	✔️
工具调用	❌	✔️
状态管理	❌	✔️
长期记忆	❌	✔️
对外行动	❌	✔️
自我修正	❌	✔️
多轮任务执行	❌	✔️

🛠️ 第二部分：Agent 的持续行动力——系统与循环

Agent 之所以能持续行动，是因为它是一套 “带状态的推理—行动循环系统” 。

1. Agent 的四大核心能力

Agent 若要能“持续行动”，必须至少具备四类能力：

1. 感知 (Perception)： 接收环境输入。数据来源包括 API 返回数据、用户输入、文件内容等。
2. 记忆 (Memory)： 管理不同层级的状态和知识。长期记忆（文档、向量数据库）的检索、写入、聚合是 Agent 可靠性的核心分水岭。
3. 工具与行动 (Tools & Action)： LLM 仅负责 决定 使用哪个工具，工具负责 执行 实际任务。
4. 推理与规划 (Reasoning & Planning)： 核心能力在于任务拆分、决策下一步以及自我纠错。

2. Agent 的标准工作循环（案例详解）

Agent 的工作不是“一次调用模型”，而是一个循环过程。

步骤	Agent 必要能力	作用
读取记忆	状态管理	让模型知道“我上一轮做到哪了”
推理下一步	规划	决定下一步动作
执行工具	行动	让“语言输出”变成“真实动作”
写入记忆	状态更新	保证下一轮不会遗忘
判断完成	收敛机制	避免无限循环

案例：自动化报销 Agent 完整循环

1. 第一轮： 规划 $\rightarrow$ OCR 识别发票（调用 read_invoice()） $\rightarrow$ 写记忆（发票金额 = 320）。
2. 第二轮： 读记忆 $\rightarrow$ 规划 $\rightarrow$ 查预算（调用 get_budget()）。
3. 第三轮： 读记忆 $\rightarrow$ 规划 $\rightarrow$ 创建报销单（调用 create_ticket()）。

结论： 一个 Agent 是一套 “带状态的推理—行动循环系统” ，循环 + 状态 才是核心。

3. Agent 的设计范式

工业界普遍采用三类 Agent 范式：

范式	思维方式	主要特征	适用场景
Reactive（反应式）	无规划、即时反应	输入→输出，延迟低	助手问答、单步命令
Deliberative（规划式）	先思考再行动	生成明确 Plan，推理深但成本高	代码调试、法律文书
ReAct（推理+行动）	边做边想	有状态循环；支持自我纠错	复杂多步骤任务、跨工具工作流

🔗 第三部分：从 Prompt 到 Function Calling 的演进

要让 LLM（大脑）指挥 Agent（身体）调用工具（手脚），必须解决 通信格式的稳定性 问题。

1. Prompt：早期 Agent 的通信基础

Prompt 分为 System Prompt（系统预设）和 User Prompt（聊天内容）。

早期 Agent（如 AutoGPT）通过将工具的 自然语言描述 和调用规则（例如：“如果你想调用 XXX 工具，请返回 - 我要调用 + 工具名 + 参数”）写入 System Prompt，然后发送给 LLM。

Prompt 机制的局限性：LLM 本质是概率模型，容易出现忘记格式、缺少字段、JSON 不合法等问题。这迫使 Agent 必须写大量的“重试逻辑”来检查和修正格式。

2. Function Calling：标准化的工具调用方式

Function Calling 解决了早期 Agent 依赖自然语言描述工具所带来的 不稳定格式问题。

• 定义： 它是一种让 LLM 能够生成 结构化 JSON 来表达调用工具意图的能力。
• 机制： 它使用 JSON Schema 来标准化工具描述和返回格式。工具信息不再以自然语言形式存在。
• 优势： 现代大模型利用 约束解码（constrained decoding），只允许模型生成符合预定义 Schema 的 Token，从而在生成时就拦截格式错误。这节省了用户端重试带来的 Token 开销。

Function Calling 工作流程（参考图表）：

1. 程序（Agent）将工具信息（如天气查询的参数、地点、时间等）发送给大模型。
2. 大模型判断是否需要调用工具，若需要，输出工具名称和解析的参数。
3. 程序根据模型指令在应用中运行工具。
4. 工具结果返回给程序，程序发起第二次调用，将结果带给大模型。
5. 大模型根据工具结果给出最终回复。

LLM 返回的结构化指令示例：

{
  "type": "call",
  "name": "search_web",
  "args": {
    "query": "CSgo 安装地址"
  }
}

🤖 第四部分：Agent 与工具的解耦与标准化——MCP

Function Calling 解决了 LLM ↔ Agent 的通信问题，而 MCP (Model Context Protocol) 旨在解决 Agent ↔ 工具（Tool） 之间的通信标准化问题。

1. MCP 的概念与目标

• 定义： MCP 是一个通信协议，专门用来规范 Agent（MCP Client）和 Tools 服务（MCP Server）之间的交互。

• 角色分工：

  • Agent (MCP Client)： 项目经理，负责编排、转达和执行。
  • MCP Server (工具服务)： 外包工具团队，提供实际能力。

• MCP Server 提供的内容：可以提供函数调用的形式（Tool），类似文件读写的服务（Resource），或者提示词模板（Prompt）。

• 优势：MCP 统一了 Agent 与外部世界的能力接口。它带来的优势包括工具复用、统一格式、工具与 Agent 彻底解耦、跨平台以及模型无关性。

2. Function Calling 和 MCP 的互补关系

Function Calling 和 MCP 是不同层面上的 互补关系，不存在取代。

• Function Calling： 是 LLM 内部 的输出机制，表达调用意图。
• MCP： 是 LLM 外部 Agent 与工具之间的通信标准。
• 协同方式：Agent 会将 MCP 工具的标准化定义转换为 LLM 可以理解的 Function Calling Schema 喂给 LLM。LLM 利用 Function Calling 发出指令，Agent 再利用 MCP 执行指令。

Agent (MCP Client) 执行 MCP 调用示例：

# Agent (MCP Client) 执行代码片段
# 1. 接收 LLM 指令（Function Calling JSON）
llm_instruction = {"name": "get_weather", "args": {"city": "Beijing"}}

# 2. 通过 MCP 协议调用 MCP Server 上的工具
# (MCP Client 负责将 JSON 参数传递给工具服务)
weather_data = mcp_client.call_tool(
    tool_name=llm_instruction['name'],
    params=llm_instruction['args']
)

# 3. 将 weather_data 发送回 LLM 进行总结

📈 第五部分：综合案例——MCP 架构下的 Agent 工作流

我们通过一个完整的流程（参考图表），来理解所有组件是如何协作的：

步骤	组件	行动	协议/数据流
1. 用户提问	用户 $\rightarrow$ Agent	提出问题 (USER PROMPT)。
2. 工具获取	Agent $\rightarrow$ MCP Server	Agent 通过 MCP 协议 获取可用工具信息（如 web_browse 的 Schema）。	MCP 协议
3. 模型决策	Agent $\rightarrow$ LLM	Agent 将工具信息（Function Schema）和用户问题一起发送给 AI 模型。	Function Schema (JSON)
4. 输出指令	LLM $\rightarrow$ Agent	AI 模型通过 Function Calling 格式生成调用 web_browse 的 JSON 指令。	Function Calling/JSON
5. 执行动作	Agent $\rightarrow$ MCP Server	Agent 接收指令，通过 MCP 协议 调用 web_browse 工具。	MCP 协议
6. 返回结果	MCP Server $\rightarrow$ Agent	工具（如网页内容 <html />）将内容返回给 Agent。	HTML 内容
7. 最终推理	Agent $\rightarrow$ LLM	Agent 将工具结果转发给 AI 模型。	HTML 内容
8. 给出答案	LLM $\rightarrow$ Agent $\rightarrow$ 用户	AI 模型根据结果生成最终回复（如“多喝热水”），再返还给 Agent。	文本

在这个案例中：用户是客户，Agent (MCP Client) 是项目经理，AI 模型是顾问，MCP Server 是外包工具团队。

---

❓ 概念澄清与常见疑问（Q&A 整合）

这部分旨在消除在学习 LLM 和 Agent 架构时常见的概念混淆。

Q1：Agent 里面是不是一定包含 LLM？为什么有些图把它们画开？

A：不一定，但现代 Agent 通常包含 LLM。

1. Agent 比 LLM 更广义： 广义的 Agent 指的是能感知环境、做出决策并采取行动的系统。传统 Agent（如游戏 NPC、专家系统）可以不包含 LLM。
2. 现代 Agent： 特指 LLM-based Agent，LLM 是核心组件。
3. 架构分离的原因： 在架构图中，为了区分职责，习惯把 “负责干活的程序/编排器” 标记为 Agent/Client（躯干和四肢），把 “负责思考的模型” 标记为 Model/LLM（大脑）。它们通常物理上分开部署，Agent 通过 API 调用 LLM。
4. 核心结论： LLM 是 Agent 的大脑，而 Agent 是一个更大的系统范畴，它等于 LLM + Planning + Memory + Tools。

Q2：System Prompt 何时传入 LLM？它会消耗 Token 吗？

A：System Prompt 每次对话都会传入，并且消耗 Token。

• 传输时机：System Prompt（系统预设的规则和角色）和 User Prompt（用户聊天内容）会一起打包发送给 AI 模型。
• Token 消耗：它们都属于上下文，会消耗 Token。
• 包含内容：System Prompt 用来设定模型的角色、行为边界和规则。在 Function Calling 出现前，它也会包含工具的自然语言描述。

Q3：如何解决工具过多导致上下文超限的问题？

A：工具不是“塞进 prompt”，而是“筛选后以结构化方式注入”。

现代 Agent 系统采用多种优化策略：

1. 按需注入（On-Demand Injection） ：Agent 会根据用户的任务意图（例如提到“浏览网页”），只加载相关的少量工具。
2. 向量检索选择（Vector-Based Tool Retrieval） ：将所有工具描述向量化，当用户提出需求时，Agent 检索出 Top-K（通常 3~10 个）最相关的工具注入模型。
3. 结构化字段传入：在许多主流 API 中，Function/Tool Calling 的 Schema 是一个独立字段，不以系统提示词形式写入 Prompt，模型内部使用结构化约束解析调用，减少对上下文容量的压力。

Q4：Function Calling (函数调用) 与 MCP 是什么关系？谁取代了谁？

A：它们是不同层面上的互补关系，不存在取代。

• Function Calling： 是 LLM 内部 的输出机制。它让 LLM 能生成结构化 JSON 来表达调用意图。
• MCP： 是 LLM 外部 Agent 与工具之间的通信标准。它定义了工具如何向 Agent 暴露自身能力。
• 协同方式： Agent 将 MCP 工具的标准化定义转换为 Function Calling Schema 喂给 LLM。LLM 生成指令，Agent 利用 MCP 执行指令。

Q5：MCP 是直接给 LLM 使用的协议吗？

A：不是。MCP 是 Agent 与工具之间的标准通信协议，是 Agent 的接口，不是 LLM 的接口。

LLM 只负责生成文本/JSON 指令，它本身无法主动发起交互。实际的调用和执行（即通过 MCP 与 Tool Service 通信）是由 Agent（MCP Client）负责的。

---

🚀 总结：Agent 的本质与未来

AI Agent 是一个能感知、能规划、能行动、能调用工具、能观察、能自我纠错、能持续多轮执行的 智能行动系统。

• LLM 是大脑，Agent 是生命体。
• 未来的软件范式将是 从写代码 $\rightarrow$ 到写意图，从编程 $\rightarrow$ 到引导。