现在学 AI没必要一上来研究几十个框架。真正做 AI 应用先把几个核心问题搞明白大模型为什么会胡说 AI 怎么知道我的私人数据 AI 为什么能操作电脑 Agent 和普通聊天有什么区别 MCP 到底解决了什么这几个问题搞懂AI 应用开发的主线基本就通了。一、大模型为什么会“胡说八道”很多人以为大模型内部存着一个巨大数据库。其实不是。大模型回答问题本质更接近根据前面的内容 预测下一个最可能出现的 Token例如中国的首都是模型发现北京出现概率最高于是继续生成。所以模型并不是先查数据库 ↓ 找到答案 ↓ 返回答案而是理解上下文 ↓ 计算概率 ↓ 生成下一个词 ↓ 继续生成这也解释了为什么大模型有时候会一本正经地编东西。因为“语言上合理”不等于“事实一定正确”。工程上怎么解决不能单纯告诉模型不要胡说。真正有效的思路是模型负责理解和生成 数据库负责保存事实 搜索系统负责寻找资料 程序负责验证关键结果也就是LLM 数据 工具而不是让 LLM 一个人包办所有事情。二、AI 怎么知道公司的内部资料假设你公司有接口文档 产品文档 数据库设计 技术规范 业务流程 几十万个 Markdown / PDF这些东西大模型本身并不知道。这时候最常见的方案就是RAGRAG 可以简单理解为先查资料再让 AI 回答。流程非常简单用户 公司的退款规则是什么 ↓ 系统搜索公司知识库 ↓ 找到退款规则相关文档 ↓ 问题 文档 ↓ 发送给大模型 ↓ 大模型根据资料回答注意这里一个非常关键的区别。不是把公司资料训练进模型而是需要的时候临时找出来给模型看RAG 为什么需要 Embedding假设用户问登录后一直提示没有权限怎么办你的文档标题可能叫Spring Security 403 异常处理方案如果只使用普通关键词搜索没有权限可能搜索不到。Embedding 的作用就是把文字转换成具有“语义”的向量。于是没有权限 403 鉴权失败 认证异常 权限校验失败虽然文字不同但是语义比较接近。系统就可以把它们搜索出来。所以 RAG 可以理解成文档 ↓ 切片 ↓ Embedding ↓ 向量数据库 用户问题 ↓ Embedding ↓ 搜索相似内容 ↓ 交给 LLM这就是现在绝大多数 AI 知识库的基本原理。三、为什么普通 AI 只能聊天Agent 却可以干活普通大模型用户 ↓ LLM ↓ 回答例如帮我看看项目为什么启动失败。普通模型只能告诉你你可以检查配置文件…… 你可以检查数据库……但是 Agent 不一样。Agent 可以用户 ↓ AI 分析 ↓ 读取项目 ↓ 搜索代码 ↓ 执行命令 ↓ 查看错误 ↓ 修改代码 ↓ 运行测试 ↓ 继续判断所以Agent 并不是一个新的大模型。它本质是LLM 工具 任务循环 状态管理核心逻辑甚至可以简化成whileTrue:actionAI决定下一步()result执行工具(action)AI读取结果(result)if任务完成:break这就是 Agent 最核心的思想。Agent 最重要的不是“智能”而是“闭环”一个真正能工作的 Agent 必须形成思考 ↓ 行动 ↓ 观察结果 ↓ 重新判断 ↓ 继续行动例如代码 Agent发现报错 ↓ 读取日志 ↓ 定位 UserService ↓ 检查代码 ↓ 修改 ↓ 执行单元测试 ↓ 测试失败 ↓ 继续分析 ↓ 再次修改 ↓ 测试通过这才是真正的AI 执行任务而不仅仅是AI 回答问题四、AI 为什么能够调用文件、数据库和 Git这里涉及一个很重要的概念Tool Calling大模型自己其实不会读取文件 操作 Git 执行 Shell 查询 MySQL 调用浏览器 发送邮件模型真正做的是“我认为现在应该调用这个工具。”例如系统提供read_file(path) search_code(keyword) run_command(command)用户说看看 UserService 为什么报错。模型可能决定{tool:search_code,keyword:UserService}真正执行搜索的是程序。然后程序把搜索结果返回给模型UserService.java 位于 src/main/java/...模型再继续决定调用 read_file因此整个过程其实是LLM负责决定 程序负责执行这是理解 AI Agent 最关键的一点。五、MCP 为什么突然这么重要假设你准备开发一个 AI 编程助手。它需要连接文件系统 GitHub 数据库 浏览器 Docker Jira 内部 API以前你可能需要自己写GitHubAdapter FileAdapter DatabaseAdapter DockerAdapter BrowserAdapter每套 AI 系统又有自己的一套接口。非常乱。于是就有了 MCP。MCP 可以简单理解成给 AI 工具提供一套统一的连接标准。结构大概是AI │ │ MCP │ ┌────────┼────────┐ ↓ ↓ ↓ GitHub 文件 数据库例如文件 MCP Server 提供read_file write_file search_file list_directoryGitHub MCP Server 提供search_repository read_issue create_issue read_pull_requestAI 不需要关心底层到底怎么实现。只需要知道有哪些工具 参数是什么 返回什么结果六、Function Calling、Agent、MCP 到底什么关系这是很多初学者最容易混淆的地方。可以直接这样理解Function Calling AI 怎么调用工具 MCP 工具怎么标准化提供给 AI Agent AI 怎么不断调用工具把任务做完组合起来就是用户 ↓ Agent ↓ LLM 判断 ↓ Function / Tool Calling ↓ MCP ↓ Git / 文件 / 数据库 / API ↓ 返回结果 ↓ Agent继续判断最终形成一个完整 AI 系统。七、真正的 AI 应用架构其实并不神秘把上面的东西全部组合起来用户 │ ↓ Agent │ ↓ LLM ┌─────┼─────┐ ↓ ↓ ↓ RAG Memory Tools │ │ ↓ ↓ Vector DB MCP │ ┌────────┼────────┐ ↓ ↓ ↓ Git DB Files其中LLM 负责理解和推理 RAG 负责提供知识 Memory 负责保存长期信息 Tool 负责执行操作 MCP 负责连接外部能力 Agent 负责控制整个执行流程最后一个核心思路学习 AI 开发最容易走错的一条路就是把所有注意力都放在哪个模型最强 参数多少 哪个框架最好真正做工程更应该思考模型应该负责什么 哪些事情必须交给程序 哪些数据应该通过 RAG 获取 什么时候应该调用工具 工具需要什么权限 执行失败以后如何恢复 如何验证 AI 给出的结果真正可靠的 AI 系统从来不是一个超级聪明的大模型而是LLM 知识 工具 权限 状态 验证模型负责思考系统负责让它可靠地工作。这才是 AI 应用开发最核心的工程思路。
现在学 AI没必要一上来研究几十个框架。真正做 AI 应用先把几个核心问题搞明白大模型为什么会胡说 AI 怎么知道我的私人数据 AI 为什么能操作电脑 Agent 和普通聊天有什么区别 MCP 到底解决了什么这几个问题搞懂AI 应用开发的主线基本就通了。一、大模型为什么会“胡说八道”很多人以为大模型内部存着一个巨大数据库。其实不是。大模型回答问题本质更接近根据前面的内容 预测下一个最可能出现的 Token例如中国的首都是模型发现北京出现概率最高于是继续生成。所以模型并不是先查数据库 ↓ 找到答案 ↓ 返回答案而是理解上下文 ↓ 计算概率 ↓ 生成下一个词 ↓ 继续生成这也解释了为什么大模型有时候会一本正经地编东西。因为“语言上合理”不等于“事实一定正确”。工程上怎么解决不能单纯告诉模型不要胡说。真正有效的思路是模型负责理解和生成 数据库负责保存事实 搜索系统负责寻找资料 程序负责验证关键结果也就是LLM 数据 工具而不是让 LLM 一个人包办所有事情。二、AI 怎么知道公司的内部资料假设你公司有接口文档 产品文档 数据库设计 技术规范 业务流程 几十万个 Markdown / PDF这些东西大模型本身并不知道。这时候最常见的方案就是RAGRAG 可以简单理解为先查资料再让 AI 回答。流程非常简单用户 公司的退款规则是什么 ↓ 系统搜索公司知识库 ↓ 找到退款规则相关文档 ↓ 问题 文档 ↓ 发送给大模型 ↓ 大模型根据资料回答注意这里一个非常关键的区别。不是把公司资料训练进模型而是需要的时候临时找出来给模型看RAG 为什么需要 Embedding假设用户问登录后一直提示没有权限怎么办你的文档标题可能叫Spring Security 403 异常处理方案如果只使用普通关键词搜索没有权限可能搜索不到。Embedding 的作用就是把文字转换成具有“语义”的向量。于是没有权限 403 鉴权失败 认证异常 权限校验失败虽然文字不同但是语义比较接近。系统就可以把它们搜索出来。所以 RAG 可以理解成文档 ↓ 切片 ↓ Embedding ↓ 向量数据库 用户问题 ↓ Embedding ↓ 搜索相似内容 ↓ 交给 LLM这就是现在绝大多数 AI 知识库的基本原理。三、为什么普通 AI 只能聊天Agent 却可以干活普通大模型用户 ↓ LLM ↓ 回答例如帮我看看项目为什么启动失败。普通模型只能告诉你你可以检查配置文件…… 你可以检查数据库……但是 Agent 不一样。Agent 可以用户 ↓ AI 分析 ↓ 读取项目 ↓ 搜索代码 ↓ 执行命令 ↓ 查看错误 ↓ 修改代码 ↓ 运行测试 ↓ 继续判断所以Agent 并不是一个新的大模型。它本质是LLM 工具 任务循环 状态管理核心逻辑甚至可以简化成whileTrue:actionAI决定下一步()result执行工具(action)AI读取结果(result)if任务完成:break这就是 Agent 最核心的思想。Agent 最重要的不是“智能”而是“闭环”一个真正能工作的 Agent 必须形成思考 ↓ 行动 ↓ 观察结果 ↓ 重新判断 ↓ 继续行动例如代码 Agent发现报错 ↓ 读取日志 ↓ 定位 UserService ↓ 检查代码 ↓ 修改 ↓ 执行单元测试 ↓ 测试失败 ↓ 继续分析 ↓ 再次修改 ↓ 测试通过这才是真正的AI 执行任务而不仅仅是AI 回答问题四、AI 为什么能够调用文件、数据库和 Git这里涉及一个很重要的概念Tool Calling大模型自己其实不会读取文件 操作 Git 执行 Shell 查询 MySQL 调用浏览器 发送邮件模型真正做的是“我认为现在应该调用这个工具。”例如系统提供read_file(path) search_code(keyword) run_command(command)用户说看看 UserService 为什么报错。模型可能决定{tool:search_code,keyword:UserService}真正执行搜索的是程序。然后程序把搜索结果返回给模型UserService.java 位于 src/main/java/...模型再继续决定调用 read_file因此整个过程其实是LLM负责决定 程序负责执行这是理解 AI Agent 最关键的一点。五、MCP 为什么突然这么重要假设你准备开发一个 AI 编程助手。它需要连接文件系统 GitHub 数据库 浏览器 Docker Jira 内部 API以前你可能需要自己写GitHubAdapter FileAdapter DatabaseAdapter DockerAdapter BrowserAdapter每套 AI 系统又有自己的一套接口。非常乱。于是就有了 MCP。MCP 可以简单理解成给 AI 工具提供一套统一的连接标准。结构大概是AI │ │ MCP │ ┌────────┼────────┐ ↓ ↓ ↓ GitHub 文件 数据库例如文件 MCP Server 提供read_file write_file search_file list_directoryGitHub MCP Server 提供search_repository read_issue create_issue read_pull_requestAI 不需要关心底层到底怎么实现。只需要知道有哪些工具 参数是什么 返回什么结果六、Function Calling、Agent、MCP 到底什么关系这是很多初学者最容易混淆的地方。可以直接这样理解Function Calling AI 怎么调用工具 MCP 工具怎么标准化提供给 AI Agent AI 怎么不断调用工具把任务做完组合起来就是用户 ↓ Agent ↓ LLM 判断 ↓ Function / Tool Calling ↓ MCP ↓ Git / 文件 / 数据库 / API ↓ 返回结果 ↓ Agent继续判断最终形成一个完整 AI 系统。七、真正的 AI 应用架构其实并不神秘把上面的东西全部组合起来用户 │ ↓ Agent │ ↓ LLM ┌─────┼─────┐ ↓ ↓ ↓ RAG Memory Tools │ │ ↓ ↓ Vector DB MCP │ ┌────────┼────────┐ ↓ ↓ ↓ Git DB Files其中LLM 负责理解和推理 RAG 负责提供知识 Memory 负责保存长期信息 Tool 负责执行操作 MCP 负责连接外部能力 Agent 负责控制整个执行流程最后一个核心思路学习 AI 开发最容易走错的一条路就是把所有注意力都放在哪个模型最强 参数多少 哪个框架最好真正做工程更应该思考模型应该负责什么 哪些事情必须交给程序 哪些数据应该通过 RAG 获取 什么时候应该调用工具 工具需要什么权限 执行失败以后如何恢复 如何验证 AI 给出的结果真正可靠的 AI 系统从来不是一个超级聪明的大模型而是LLM 知识 工具 权限 状态 验证模型负责思考系统负责让它可靠地工作。这才是 AI 应用开发最核心的工程思路。
