小白也能看懂的大模型应用架构与Agent:让AI从“只会说“变成“会干活“

小白也能看懂的大模型应用架构与Agent:让AI从“只会说“变成“会干活“
系列文章AI大模型知识体系 | 第三周·第七篇引言大模型不只是聊天机器人——从对话到行动上一篇我们聊了 RAG检索增强生成让大模型学会了查资料再回答不再一本正经地胡说八道。但你有没有想过一个问题——大模型只会说话不会做事。你让它帮你订个机票它洋洋洒洒给你写了一篇如何订机票的攻略你让它查一下今天的天气它给你编了一个大概也许可能是晴天的回答。这就好比你雇了一个超级博学的顾问上知天文下知地理但——他只会动嘴不会动手。你让他帮你点个外卖他说好的你可以打开手机App搜索附近餐厅……然后就没有然后了。Agent智能体就是让大模型从只会说进化到会干活的关键。它让大模型不仅能思考和回答还能调用工具、执行操作、完成真实世界的任务。今天这篇是第三周的收官之作我们不仅要聊 Agent还要把大模型应用的整体架构讲清楚——从 API 服务到业务逻辑从函数调用到智能体框架帮你建立完整的认知地图。一、大模型应用架构全景图三层楼的故事想象你开了一家AI餐厅大模型就是你的主厨。但光有主厨是不够的——你还需要前厅接待客人、后厨准备食材、跑堂送菜上桌。大模型应用也是一样典型的架构分三层┌─────────────────────────────────────────────────┐ │ 用户 / 客户端 │ │ 网页、App、微信、API调用者 │ └────────────────────┬────────────────────────────┘ │ 请求 ▼ ┌─────────────────────────────────────────────────┐ │ API 服务层前厅 │ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │ │ 认证鉴权 │ │ 限流熔断 │ │ 日志监控 │ │ │ └───────────┘ └───────────┘ └───────────┘ │ │ ┌─────────────────────────────────────────┐ │ │ │ 请求路由 会话管理 │ │ │ └─────────────────────────────────────────┘ │ └────────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────┐ │ 业务逻辑层主厨 菜单设计 │ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ Prompt │ │ RAG │ │ Agent │ │ │ │ 编排 │ │ 检索 │ │ 智能体 │ │ │ └──────────┘ └──────────┘ └──────────────┘ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ 对话记忆 │ │ 输出解析 │ │ 工作流编排 │ │ │ └──────────┘ └──────────┘ └──────────────┘ │ └────────────────────┬────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────┐ │ 工具层后厨 食材库 │ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ 搜索引擎 │ │ 数据库 │ │ 代码执行器 │ │ │ └──────────┘ └──────────┘ └──────────────┘ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ API接口 │ │ 文件系统 │ │ 外部服务 │ │ │ └──────────┘ └──────────┘ └──────────────┘ │ └─────────────────────────────────────────────────┘层级生活类比核心职责典型组件API 服务层餐厅前厅接待请求、身份验证、流量控制FastAPI、Nginx、API Gateway业务逻辑层主厨菜单设计编排大模型、管理对话、调用工具LangChain、LlamaIndex、自研框架工具层后厨食材库提供真实世界的数据和操作能力搜索API、数据库、代码沙箱关键洞察大模型本身只是业务逻辑层的一个组件而不是整个应用。就像主厨再厉害没有前厅接客、没有后厨备料餐厅也开不起来。二、Function Calling让大模型学会打电话叫外卖2.1 什么是 Function CallingFunction Calling函数调用是大模型从只会说到会干活的第一步。打个比方你跟朋友说我好饿朋友不会只回一句那你吃点东西吧而是会掏出手机帮你点外卖——他不仅理解了你的需求还执行了具体的动作。Function Calling 就是让大模型具备这种能力当它判断需要调用外部工具时不再只输出文字而是输出一个结构化的函数调用请求告诉应用层请帮我调用这个函数参数是这些。2.2 工作流程用户: 北京今天天气怎么样 │ ▼ ┌─────────────┐ │ 大模型 │ ← 思考这个问题需要查天气 │ (LLM) │ └──────┬──────┘ │ 输出调用 get_weather(city北京) ▼ ┌─────────────┐ │ 应用层 │ ← 解析函数调用执行真实API │ (你的代码) │ 调用天气API → 返回 晴28°C └──────┬──────┘ │ 把结果喂回大模型 ▼ ┌─────────────┐ │ 大模型 │ ← 结合工具返回结果生成自然语言回答 └──────┬──────┘ │ ▼ 用户: 北京今天天气晴朗气温28°C适合出门哦2.3 代码示例OpenAI Function Callingimport openai # 第一步定义大模型可以调用的工具 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: { type: string, description: 城市名称如北京、上海 } }, required: [city] } } } ] # 第二步发送用户消息 工具定义给大模型 response openai.chat.completions.create( modelgpt-4o, messages[{role: user, content: 北京今天天气怎么样}], toolstools ) # 第三步检查大模型是否要调用工具 message response.choices[0].message if message.tool_calls: for tool_call in message.tool_calls: func_name tool_call.function.name func_args tool_call.function.arguments print(f大模型想调用: {func_name}({func_args})) # 输出: 大模型想调用: get_weather({city: 北京}) # 第四步执行真实函数把结果喂回大模型 import json def get_weather(city: str) - str: 实际调用天气API这里用模拟数据 weather_data {北京: 晴28°C, 上海: 多云25°C} return weather_data.get(city, 未知城市) # 执行函数调用 tool_call message.tool_calls[0] args json.loads(tool_call.function.arguments) result get_weather(args[city]) # 把工具结果返回给大模型让它生成最终回答 response2 openai.chat.completions.create( modelgpt-4o, messages[ {role: user, content: 北京今天天气怎么样}, message, # 大模型第一次的回复包含工具调用 { role: tool, tool_call_id: tool_call.id, content: result # 工具返回的结果 } ] ) print(response2.choices[0].message.content) # 输出: 北京今天天气晴朗气温28°C适合出门哦注意大模型本身并不执行函数它只是决定要调用哪个函数、传什么参数。真正执行函数的是你的应用代码。这就像主厨说去冰箱拿两个鸡蛋主厨自己不去拿是帮厨去拿的。三、Agent智能体大模型的自主驾驶模式3.1 从 Function Calling 到 AgentFunction Calling 让大模型能调用工具了但每次调用都需要人工编排——你来决定什么时候调用、调用什么、调用几次。Agent 则更进一步让大模型自己决定调用什么工具、调用几次、什么时候停止。打个比方普通大模型 导航软件你问路它告诉你怎么走但你自己开车Function Calling 导航语音助手你问路它帮你打电话给餐厅订座Agent 自动驾驶你告诉它目的地它自己规划路线、自己开车、自己应对路况3.2 Agent 的核心循环感知→思考→行动Agent 的运行遵循一个经典循环┌──────────────────────────────────┐ │ │ ▼ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ 感知 │───▶│ 思考 │───▶│ 行动 │ │ Perceive │ │ Think │ │ Act │ └───────────┘ └───────────┘ └───────────┘ ▲ │ │ 观察行动结果 │ └──────────────────────────────────┘阶段做什么生活类比感知Perceive接收用户输入、工具返回结果、环境信息你睁开眼看到路况思考Think分析当前状态决定下一步做什么你判断前面红灯该刹车行动Act调用工具、生成回复、执行操作你踩下刹车这个循环会一直转直到 Agent 认为任务完成。3.3 一个具体的例子用户说帮我查一下北京和上海的天气然后推荐一个适合出行的城市。Agent 的运行过程第1轮循环: 感知: 用户要查北京和上海天气并推荐 思考: 需要先查两个城市的天气再比较 行动: 调用 get_weather(city北京) 第2轮循环: 感知: 北京天气晴28°C 思考: 还需要查上海天气 行动: 调用 get_weather(city上海) 第3轮循环: 感知: 上海天气多云25°C 思考: 两个城市天气都拿到了可以比较并推荐了 行动: 生成最终回答 → 北京晴天28°C上海多云25°C推荐北京出行 任务完成 ✓看到了吗Agent 自己规划了步骤、自己决定调用顺序、自己判断什么时候该停。这就是自主驾驶。四、ReAct 框架推理 行动的黄金搭档4.1 什么是 ReActReActReasoning Acting是目前最流行的 Agent 范式之一由 Yao 等人在 2022 年提出。核心思想很简单先想清楚再动手做完之后再想想。这就像你做数学题❌ 不好的做法看到题目直接猜答案✅ 好的做法先分析题目推理→ 列式计算行动→ 检查结果再推理4.2 ReAct 的工作流程用户输入: 2024年奥斯卡最佳影片的导演是谁他之前拍过什么电影 │ ▼ ┌─────────────────────────────────────────────────┐ │ Thought 1: 我需要先查2024年奥斯卡最佳影片是什么 │ │ Action 1: search(2024奥斯卡最佳影片) │ │ Observation 1: 《奥本海默》获得最佳影片 │ ├─────────────────────────────────────────────────┤ │ Thought 2: 知道了是《奥本海默》导演是诺兰 │ │ 但我需要确认并查他之前的作品 │ │ Action 2: search(克里斯托弗·诺兰 电影作品列表) │ │ Observation 2: 《盗梦空间》《星际穿越》《信条》.. │ ├─────────────────────────────────────────────────┤ │ Thought 3: 我已经获得了所有需要的信息可以回答了 │ │ Answer: 2024年奥斯卡最佳影片《奥本海默》的导演 │ │ 是克里斯托弗·诺兰他之前执导过《盗梦 │ │ 空间》《星际穿越》《信条》等知名影片。 │ └─────────────────────────────────────────────────┘4.3 ReAct vs 纯推理 vs 纯行动方式做法优点缺点纯推理CoT只思考不行动逻辑清晰无法获取新信息容易空想纯行动只调用工具不推理能获取信息盲目调用效率低容易跑偏ReAct推理行动交替有理有据灵活高效Token消耗较多4.4 代码示例手动实现 ReAct 循环import openai import json # 定义可用工具 def search(query: str) - str: 模拟搜索工具 knowledge { 2024奥斯卡最佳影片: 《奥本海默》获得2024年奥斯卡最佳影片, 诺兰 电影作品: 《盗梦空间》《星际穿越》《信条》《敦刻尔克》 } for key, value in knowledge.items(): if key in query: return value return 未找到相关信息 tools { search: { func: search, description: 搜索互联网获取信息 } } # ReAct 循环 def react_agent(question: str, max_steps: int 5): messages [ { role: system, content: 你是一个ReAct智能体。请严格按照以下格式回答 Thought: 分析当前情况思考下一步 Action: 调用工具格式为 tool_name(argument) Observation: (工具返回结果由系统填入) 当你有足够信息回答问题时使用 Thought: 我已经获得了足够的信息 Answer: 最终答案 }, {role: user, content: question} ] for step in range(max_steps): response openai.chat.completions.create( modelgpt-4o, messagesmessages, temperature0 ) reply response.choices[0].message.content messages.append({role: assistant, content: reply}) print(f--- Step {step 1} ---) print(reply) # 检查是否已经给出最终答案 if Answer: in reply: break # 解析并执行工具调用 if Action: in reply: # 简单解析 Action: search(xxx) import re match re.search(rAction:\s*(\w)\((.?)\), reply) if match: tool_name match.group(1) tool_arg match.group(2).strip(\) if tool_name in tools: result tools[tool_name][func](tool_arg) observation fObservation: {result} messages.append({role: user, content: observation}) print(observation) react_agent(2024年奥斯卡最佳影片的导演是谁他之前拍过什么电影)五、主流 Agent 框架三大门派现在市面上 Agent 框架百花齐放但最主流的有三个。我用开公司来类比5.1 三大框架对比框架核心理念生活类比适合场景LangChain Agents链式编排工具驱动一个全能员工什么工具都会用单Agent多工具的任务AutoGen多Agent对话协作一个团队开会讨论需要多角色协作的复杂任务CrewAI角色分工流程驱动一家公司各司其职有明确流程的多步骤任务5.2 LangChain Agents全能型选手LangChain 是目前最流行的 LLM 应用开发框架它的 Agent 模块让你可以快速搭建一个有手有脚的大模型应用。from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import tool from langchain import hub # 定义工具 tool def get_weather(city: str) - str: 查询指定城市的天气 weather_data {北京: 晴28°C, 上海: 多云25°C, 广州: 雨30°C} return weather_data.get(city, 未知城市) tool def calculate(expression: str) - str: 计算数学表达式如 23*4 try: return str(eval(expression)) except Exception as e: return f计算错误: {e} # 创建 Agent llm ChatOpenAI(modelgpt-4o, temperature0) tools [get_weather, calculate] # 使用 LangChain 内置的 ReAct 提示词模板 prompt hub.pull(hwchase17/react) agent create_react_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) # 运行 result agent_executor.invoke({ input: 北京和上海哪个城市更热温差是多少 }) print(result[output])运行时你会看到 Agent 自动调用get_weather(北京)→ 晴28°C调用get_weather(上海)→ 多云25°C调用calculate(28-25)→ 3输出最终答案5.3 AutoGen团队协作型AutoGen微软出品的核心是多 Agent 对话。就像一个团队开会不同角色各司其职from autogen import AssistantAgent, UserProxyAgent # 配置大模型 llm_config {model: gpt-4o, temperature: 0} # 创建程序员Agent coder AssistantAgent( nameCoder, system_message你是一个Python程序员负责写代码解决问题。, llm_configllm_config ) # 创建评审员Agent reviewer AssistantAgent( nameReviewer, system_message你是一个代码评审员负责检查代码质量和正确性。, llm_configllm_config ) # 创建用户代理可以执行代码 user UserProxyAgent( nameUser, human_input_modeNEVER, max_consecutive_auto_reply3, code_execution_config{work_dir: coding} ) # 开始对话 user.initiate_chat( coder, message写一个Python函数判断一个数是否是质数 )5.4 CrewAI公司型组织CrewAI 把 Agent 组织成船员Crew每个 Agent 有明确的角色和目标from crewai import Agent, Task, Crew, Process from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o, temperature0) # 定义Agent船员 researcher Agent( role研究员, goal收集关于指定主题的最新信息, backstory你是一个经验丰富的互联网研究员, llmllm, verboseTrue ) writer Agent( role作家, goal将研究结果写成通俗易懂的文章, backstory你是一个擅长科普写作的作家, llmllm, verboseTrue ) # 定义任务 research_task Task( description研究大模型Agent技术的最新进展, agentresearcher ) write_task Task( description基于研究结果写一篇关于Agent技术的科普文章, agentwriter ) # 组建团队并执行 crew Crew( agents[researcher, writer], tasks[research_task, write_task], processProcess.sequential # 按顺序执行任务 ) result crew.kickoff() print(result)六、实操用 LangChain 构建一个完整的 Agent让我们把前面学的知识串起来构建一个智能助手 Agent它能搜索信息、做计算、查天气from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import tool from langchain import hub from langchain.memory import ConversationBufferMemory # 1. 定义工具 tool def search_web(query: str) - str: 搜索互联网获取信息。输入搜索关键词。 # 实际项目中替换为真实的搜索API如 Tavily、SerpAPI mock_results { Python: Python是一种广泛使用的高级编程语言, LangChain: LangChain是构建LLM应用的开源框架, } for key, value in mock_results.items(): if key.lower() in query.lower(): return value return f搜索{query}暂无结果请接入真实搜索API tool def calculator(expression: str) - str: 计算数学表达式。输入如 23 或 100*0.15。 try: allowed set(0123456789-*/.() ) if not all(c in allowed for c in expression): return 错误只支持基本数学运算 return f计算结果: {eval(expression)} except Exception as e: return f计算错误: {e} tool def get_weather(city: str) - str: 查询城市天气。输入城市名称。 # 实际项目中替换为真实天气API mock_weather { 北京: 晴28°C空气质量良好, 上海: 多云25°C有轻微雾霾, 深圳: 阵雨31°C湿度85%, } return mock_weather.get(city, f{city}暂无天气数据) # 2. 创建 Agent llm ChatOpenAI(modelgpt-4o, temperature0) tools [search_web, calculator, get_weather] # 加载 ReAct 提示词模板 prompt hub.pull(hwchase17/react) # 创建带记忆的 Agent memory ConversationBufferMemory(memory_keychat_history) agent create_react_agent(llm, tools, prompt) agent_executor AgentExecutor( agentagent, toolstools, memorymemory, verboseTrue, max_iterations5, # 最多循环5轮 handle_parsing_errorsTrue # 解析错误时自动处理 ) # 3. 运行 Agent # 测试1简单查询 print( * 50) result1 agent_executor.invoke({input: 北京今天天气怎么样}) print(f回答: {result1[output]}) # 测试2多步推理 print( * 50) result2 agent_executor.invoke({ input: 北京和上海哪个更热温差是多少度 }) print(f回答: {result2[output]}) # 测试3跨工具协作 print( * 50) result3 agent_executor.invoke({ input: 搜索LangChain是什么然后告诉我100乘以0.15等于多少 }) print(f回答: {result3[output]})运行后你会看到 Agent 的完整思考过程——每一步的 Thought、Action、Observation 都清晰可见就像看着一个聪明人在一步步解决问题。七、Agent 的局限与挑战别被智能冲昏了头Agent 很酷但远没有到万能的程度。目前 Agent 面临几个严峻的挑战7.1 可靠性问题Agent 会犯傻大模型本身就不完全可靠Agent 更是如此。它可能死循环反复调用同一个工具停不下来幻觉调用编造一个不存在的工具名来调用参数错误传了错误的参数格式导致工具执行失败中途跑偏做着做着就忘了原始任务用户: 帮我订一张去上海的机票 Agent: Thought: 需要订机票 Action: book_flight(from北京, to上海) Observation: 错误 - 没有book_flight工具 Thought: 让我试试另一个工具 Action: search(如何订机票) Observation: 1. 打开携程App 2. 选择出发地... Thought: 我应该告诉用户怎么订机票 Answer: 你可以打开携程App选择出发地北京... ← 完全跑偏了用户要的是帮忙订不是教你怎么订7.2 成本问题Token 消耗惊人Agent 每一步都要把完整的对话历史、工具定义、中间结果发给大模型Token 消耗是普通对话的5-20 倍。场景大约 Token 消耗成本GPT-4o简单问答~500 tokens~$0.004RAG 检索~2000 tokens~$0.015Agent3轮循环~5000-10000 tokens~$0.04-0.08Agent复杂任务~20000 tokens~$0.157.3 延迟问题等不起Agent 每一轮循环都需要一次大模型推理 工具调用3轮循环可能需要10-30秒。对于需要实时响应的场景如客服这个延迟是不可接受的。7.4 应对策略挑战应对策略可靠性设置max_iterations限制循环次数添加输出校验使用更可靠的模型成本使用更便宜的模型做简单判断缓存工具结果减少不必要的工具定义延迟流式输出中间步骤并行调用独立工具用 Workflow 替代自由 Agent核心建议不要为了用 Agent 而用 Agent。如果你的任务步骤是固定的用Workflow工作流比 Agent 更可靠、更便宜、更快。Agent 适合步骤不确定、需要动态决策的场景。八、第三周知识回顾7天内容一图总结第三周我们聚焦大模型推理与部署从模型怎么跑到应用怎么搭完整走了一遍┌──────────────────────────────────────────────────────────────┐ │ 第三周 · 大模型推理与部署 │ ├──────────┬───────────────────────────────────────────────────┤ │ Day 1 │ 推理基础KV Cache、采样策略、Temperature │ │ Day 2 │ 量化技术INT8/INT4/GPTQ/AWQ让模型更小更快 │ │ Day 3 │ 推理加速vLLM/PagedAttention/TensorRT-LLM │ │ Day 4 │ 模型部署FastAPI/Docker/Triton/模型服务化 │ │ Day 5 │ Prompt工程系统提示词、Few-shot、CoT │ │ Day 6 │ RAG检索增强生成让大模型学会查资料 │ │ Day 7 │ Agent与架构从对话到行动大模型应用全景图 │ └──────────┴───────────────────────────────────────────────────┘天数主题一句话总结Day 1推理基础KV Cache 是推理加速的基石采样策略决定输出的多样性Day 2量化技术用更少的位数存参数模型变小变快效果损失可控Day 3推理加速vLLM 的 PagedAttention 解决显存碎片吞吐量翻倍Day 4模型部署从能跑到能服务API化容器化规模化Day 5Prompt工程好的提示词是免费的微调CoT让大模型学会想清楚再说Day 6RAG给大模型装一个外挂大脑先查资料再回答Day 7Agent与架构让大模型从只会说进化到会干活感知→思考→行动这7天的知识是一条递进链推理基础 → 量化加速 → 部署服务 → Prompt优化 → RAG增强 → Agent行动 (怎么跑) (跑更快) (跑起来) (用得好) (更准确) (能干活)九、系列预告第四周我们聊什么第三周我们搞定了推理与部署大模型已经能跑起来、能干活了。但真实世界的应用远不止于此——第四周预告大模型安全、评估与前沿趋势天数主题预告Day 1大模型安全对抗攻击、越狱提示、数据泄露——大模型的阿喀琉斯之踵Day 2对齐与安全RLHF之外的对齐方法Constitutional AI、红队测试Day 3大模型评估怎么知道模型好不好Benchmark、人工评估、LLM-as-JudgeDay 4多模态大模型GPT-4V、LLaVA——当大模型学会看和听Day 5长上下文技术100K上下文窗口的秘密RoPE扩展、稀疏注意力Day 6小模型与蒸馏大模型太贵用知识蒸馏把能力压缩到小模型里Day 7大模型未来展望AGI之路、Scaling Law的尽头、2025-2026趋势预测写在最后从第一周的 Transformer 架构到第二周的训练技术再到第三周的推理部署与 Agent——我们用21天从大模型是什么走到了大模型怎么用。Agent 是目前大模型应用最激动人心的方向。它让 AI 不再只是一个百科全书而是一个能帮你干活的数字助手。但也要清醒地认识到Agent 还远不成熟——可靠性、成本、延迟都是需要解决的问题。在实际项目中我的建议是先从简单的开始Prompt Engineering → RAG → Function Calling → Agent逐步升级能用 Workflow 就别用 Agent固定流程比自由决策更可靠始终保留人工兜底关键决策让人类确认别让 Agent 完全自主监控和日志是必须的Agent 的每一步都要记录出了问题才能排查