AI 常见概念解析:从大模型到智能体的技术图谱
AI 常见概念解析:从大模型到智能体的技术图谱
Frank Dum前言
“LLM、Function Call、MCP、Agent”这些词单独看都认识,但一旦放进同一张架构图里就开始打架——很正常:它们不在同一个抽象层,很多文章还会把不同厂商的术语混在一起讲。
这篇文章只做一件事:把这些概念放回各自的位置,并给你能直接跑起来的最小示例(Python + TypeScript)。读完你至少能回答三个问题:
- LLM 到底是什么,和“泛称的大模型”差在哪?
- 工具调用(Tool/Function Calling) 是什么能力,为什么它比“让模型输出 JSON”更像工程?
- MCP 与 Agent 分别解决什么问题,什么时候该用、什么时候别用?
基础概念:大模型、基础模型、LLM(别只盯参数)
1)”大模型”到底大在哪里?
“大模型(Large Model)”更像一个工程尺度的说法,而不是严格的学术分类。通常它意味着:
- 参数量大、训练数据大、训练算力大(但参数量不是唯一指标)
- 训练过程复杂:预训练(pretrain)+ 指令微调(SFT)+ 偏好对齐(如 RLHF/RLAIF 等)
- 部署成本高:推理延迟、显存、并发、成本控制都变成显性问题
很多人把“参数量 = 能力”当成公式,其实只能算“经验相关”,远谈不上“决定因素”。同样 70B,有的模型像瑞士军刀,有的像钝刀——训练数据、训练目标、对齐方式、推理策略都会改变“刀刃形状”。
2)LLM 是什么?它和“大模型”的关系
- LLM(Large Language Model):专注自然语言(以及代码等序列数据)的模型家族。
- 大模型:更宽泛的称呼,可以包括视觉、多模态、语音、推荐、科学计算等方向的“基础模型”。
一句话记法:
LLM 是“大模型”里专门负责“语言/序列”的那一支。
3)上下文学习 vs 微调(很多误解来自这里)
- 上下文学习(In-Context Learning):你在提示词里给示例,模型在当前对话里“临时学会”一种模式。
- 微调(Fine-tuning):你真的改了模型参数,让它长期稳定地产生某种行为。
工程上更常见的路线是:先做提示词 + 工具/检索,真的到了规模化、稳定性和成本要求很高时,再考虑微调。
交互增强:Tool Calling / Function Calling(让模型”能做事”)
“Function Call”这个词在不少旧文章里出现得更多;在较新的 API/产品里,你会更常看到 Tool Calling(工具调用)。本质是一件事:
模型不只是“回答”,而是能输出一个结构化的“调用意图”,让你的程序去执行,再把结果喂回模型继续生成。
工具调用解决的不是“格式”,而是“闭环”
只让模型输出 JSON,你依然会遇到:
- 参数不合法、字段缺失、类型乱飞
- 多工具协同:先查,再算,再写入
- 幂等与重试:同一个调用重复执行会不会造成副作用?
- 超时与失败:工具失败后模型如何恢复?
工具调用把这些问题摆到台面上:你必须写“工具路由 + 参数校验 + 结果回传”,这才像工程。
可运行示例:OpenAI 工具调用(Python,含严格参数约束)
下面给一个“查天气”的最小闭环示例。你可以把它保存为 tool_call_weather.py 直接运行。
依赖与环境
1 | pip install -U openai |
tool_call_weather.py
1 | import json |
这个示例里隐藏的最佳实践
- 参数校验别只靠模型:即使开了
strict,你也应该在服务端做校验与兜底。 - 工具输出用 JSON 字符串:统一格式,后续更容易调试、落日志、重放。
- 工具要可观测:记录
call_id、入参、耗时、错误码,否则排错会很痛。
协议标准:MCP(Model Context Protocol)
MCP 解决的是什么问题?
如果说“工具调用”是在模型 ↔ 你的应用代码之间做闭环,那么 MCP 更像是在应用 ↔ 外部工具/数据源之间做标准化:
- 你可以把“工具、资源、提示模板”打包成一个 MCP Server
- 不同的 MCP Client(桌面应用、IDE、你的产品)可以用统一方式发现、调用这些能力
- 你不用为每个客户端各写一套“插件协议”
MCP 的核心对象通常会这样讲:
- Tools:可执行动作(查询、计算、写入)
- Resources:可读取的上下文(文件、数据库视图、知识库条目)
- Prompts:可复用提示模板(把“问法”标准化)
MCP 与传统 API 的区别(更工程化的说法)
| 维度 | 传统 API | MCP |
|---|---|---|
| 面向对象 | 人/程序员 | LLM 客户端与工具生态 |
| 发现机制 | 你手动查文档、配路径 | 客户端可列出 tools/resources/prompts |
| 调用语义 | 自定义 | 协议统一(工具、资源、提示) |
| 集成形态 | 单点集成 | “可插拔”的工具服务器 |
注意:MCP 不是“替代 REST”。它更像一层“给 AI 客户端用的插件总线”。
可运行示例:最小 MCP Server(TypeScript,stdio)
下面示例使用 TypeScript 的 MCP SDK(v1 系列常见写法)。把它保存为 server.ts。
初始化与运行
1 | npm init -y |
server.ts
1 | import { z } from "zod"; |
你会注意到:这个 Server 没有暴露“HTTP 路由”。stdio 模式的目标就是让 MCP Client 以“启动子进程”的方式连接它(典型在桌面端/IDE 集成里)。
智能系统:Agent(智能体)= LLM + 工具 + 规划 + 状态
“Agent”在工程语境里不是一个单一技术点,更像一个系统形态:
- LLM:负责理解、推理、生成
- 工具系统:能查数据、能执行动作(工具调用 / MCP / 内置工具都行)
- 规划与控制:多步任务拆解、循环、终止条件
- 状态(Memory/State):短期对话上下文 + 长期记忆/业务状态 + 运行时轨迹
Agent 和“脚本自动化”的关键差异
| 维度 | 传统脚本/工作流 | Agent |
|---|---|---|
| 路径 | 预定义流程 | 动态选择步骤 |
| 失败处理 | 人写分支兜底 | 让模型基于反馈调整策略 |
| 抽象层 | 工程师驱动 | 目标驱动(Goal-driven) |
| 适用范围 | 稳定、规则清晰 | 复杂、多变、信息不完备 |
但也别神化:很多“Agent”项目最后都会回到一个朴素结论——该确定的部分尽量确定,LLM 负责不确定的部分。
可运行示例:一个“最小 Agent 循环”(Python,安全计算器 + 搜索桩)
把它保存为 simple_agent.py。
依赖
1 | pip install -U openai |
simple_agent.py
1 | import ast |
概念对比与关系:一张“分层图”更不容易混
把这些东西按层级放回去,会清晰很多:
1 | ┌─────────────────────────────────────────────┐ |
关系一句话总结
- LLM:负责“想”(理解与生成)
- 工具调用:让 LLM 能“伸手做事”(但手要你来接)
- MCP:让“工具与上下文”变成可复用、可共享的标准接口
- Agent:把“想 + 做 + 记 + 控制”组织成一个能长期运行的系统
怎么选:从最小可用到可扩展(别一上来就 Agent)
一个更现实的演进路线通常是:
- LLM + 提示词:先把任务跑通(别急着上工具)
- 加工具调用:解决实时数据/动作执行/结构化提取
- 工具变多后上 MCP:统一接入方式,减少重复集成
- 任务变复杂再做 Agent:引入规划、状态、评估与安全
你会发现:很多场景其实在第 2 步就够用了。
总结
- “大模型/LLM”讲的是模型能力与训练尺度
- “Tool/Function Calling”讲的是模型如何把意图变成可执行的调用
- “MCP”讲的是工具与上下文如何标准化、可插拔、可复用
- “Agent”讲的是把多步任务做成系统:规划、状态、循环、终止与治理
如果你准备把文章里的示例改成你自己的业务版本,我可以基于你的具体场景(比如:客服、数据分析、研发提效、运维自动化)帮你把“工具设计、参数 schema、错误与幂等、日志与评估”补齐成一套更像生产系统的骨架。
参考资源
- OpenAI Function Calling / Tools 指南:
https://platform.openai.com/docs/guides/function-calling - OpenAI API Reference(Responses / Chat Completions):
https://developers.openai.com/api/reference - MCP 官网与规范入口:
https://modelcontextprotocol.io/ - MCP TypeScript SDK:
https://github.com/modelcontextprotocol/typescript-sdk - LangChain Agents 概念(对比用):
https://python.langchain.com/docs/concepts/agents/





