小白也能看懂的大模型应用架构与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 Calling?

Function Calling(函数调用)是大模型从"只会说"到"会干活"的第一步。

打个比方:你跟朋友说"我好饿",朋友不会只回一句"那你吃点东西吧",而是会掏出手机帮你点外卖——他不仅理解了你的需求,还执行了具体的动作

Function Calling 就是让大模型具备这种能力:当它判断需要调用外部工具时,不再只输出文字,而是输出一个结构化的函数调用请求,告诉应用层"请帮我调用这个函数,参数是这些"。

2.2 工作流程

用户: "北京今天天气怎么样?" │ ▼ ┌─────────────┐ │ 大模型 │ ← 思考:这个问题需要查天气 │ (LLM) │ └──────┬──────┘ │ 输出:调用 get_weather(city="北京") ▼ ┌─────────────┐ │ 应用层 │ ← 解析函数调用,执行真实API │ (你的代码) │ 调用天气API → 返回 "晴,28°C" └──────┬──────┘ │ 把结果喂回大模型 ▼ ┌─────────────┐ │ 大模型 │ ← 结合工具返回结果,生成自然语言回答 └──────┬──────┘ │ ▼ 用户: "北京今天天气晴朗,气温28°C,适合出门哦!"

2.3 代码示例:OpenAI Function Calling

import openai # 第一步:定义大模型可以调用的工具 tools = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的当前天气", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称,如'北京'、'上海'" } }, "required": ["city"] } } } ] # 第二步:发送用户消息 + 工具定义给大模型 response = openai.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "北京今天天气怎么样?"}], tools=tools ) # 第三步:检查大模型是否要调用工具 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( model="gpt-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 到 Agent

Function 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 什么是 ReAct?

ReAct(Reasoning + 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( model="gpt-4o", messages=messages, temperature=0 ) 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(r'Action:\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 = f"Observation: {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: """计算数学表达式,如 '2+3*4'""" try: return str(eval(expression)) except Exception as e: return f"计算错误: {e}" # 创建 Agent llm = ChatOpenAI(model="gpt-4o", temperature=0) tools = [get_weather, calculate] # 使用 LangChain 内置的 ReAct 提示词模板 prompt = hub.pull("hwchase17/react") agent = create_react_agent(llm, tools, prompt) agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True) # 运行 result = agent_executor.invoke({ "input": "北京和上海哪个城市更热?温差是多少?" }) print(result["output"])

运行时你会看到 Agent 自动:

  1. 调用get_weather("北京")→ 晴,28°C

  2. 调用get_weather("上海")→ 多云,25°C

  3. 调用calculate("28-25")→ 3

  4. 输出最终答案

5.3 AutoGen:团队协作型

AutoGen(微软出品)的核心是多 Agent 对话。就像一个团队开会,不同角色各司其职:

from autogen import AssistantAgent, UserProxyAgent # 配置大模型 llm_config = {"model": "gpt-4o", "temperature": 0} # 创建程序员Agent coder = AssistantAgent( name="Coder", system_message="你是一个Python程序员,负责写代码解决问题。", llm_config=llm_config ) # 创建评审员Agent reviewer = AssistantAgent( name="Reviewer", system_message="你是一个代码评审员,负责检查代码质量和正确性。", llm_config=llm_config ) # 创建用户代理(可以执行代码) user = UserProxyAgent( name="User", human_input_mode="NEVER", max_consecutive_auto_reply=3, 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(model="gpt-4o", temperature=0) # 定义Agent(船员) researcher = Agent( role="研究员", goal="收集关于指定主题的最新信息", backstory="你是一个经验丰富的互联网研究员", llm=llm, verbose=True ) writer = Agent( role="作家", goal="将研究结果写成通俗易懂的文章", backstory="你是一个擅长科普写作的作家", llm=llm, verbose=True ) # 定义任务 research_task = Task( description="研究大模型Agent技术的最新进展", agent=researcher ) write_task = Task( description="基于研究结果,写一篇关于Agent技术的科普文章", agent=writer ) # 组建团队并执行 crew = Crew( agents=[researcher, writer], tasks=[research_task, write_task], process=Process.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: """计算数学表达式。输入如 '2+3' 或 '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(model="gpt-4o", temperature=0) tools = [search_web, calculator, get_weather] # 加载 ReAct 提示词模板 prompt = hub.pull("hwchase17/react") # 创建带记忆的 Agent memory = ConversationBufferMemory(memory_key="chat_history") agent = create_react_agent(llm, tools, prompt) agent_executor = AgentExecutor( agent=agent, tools=tools, memory=memory, verbose=True, max_iterations=5, # 最多循环5轮 handle_parsing_errors=True # 解析错误时自动处理 ) # ========== 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.004

RAG 检索

~2000 tokens

~$0.015

Agent(3轮循环)

~5000-10000 tokens

~$0.04-0.08

Agent(复杂任务)

~20000+ tokens

~$0.15+

7.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 5

Prompt工程

好的提示词是免费的微调,CoT让大模型学会"想清楚再说"

Day 6

RAG

给大模型装一个"外挂大脑",先查资料再回答

Day 7

Agent与架构

让大模型从"只会说"进化到"会干活",感知→思考→行动

这7天的知识是一条递进链

推理基础 → 量化加速 → 部署服务 → Prompt优化 → RAG增强 → Agent行动 (怎么跑) (跑更快) (跑起来) (用得好) (更准确) (能干活)

九、系列预告:第四周,我们聊什么?

第三周我们搞定了"推理与部署",大模型已经能跑起来、能干活了。但真实世界的应用远不止于此——

第四周预告:大模型安全、评估与前沿趋势

天数

主题

预告

Day 1

大模型安全

对抗攻击、越狱提示、数据泄露——大模型的"阿喀琉斯之踵"

Day 2

对齐与安全

RLHF之外的对齐方法:Constitutional AI、红队测试

Day 3

大模型评估

怎么知道模型好不好?Benchmark、人工评估、LLM-as-Judge

Day 4

多模态大模型

GPT-4V、LLaVA——当大模型学会"看"和"听"

Day 5

长上下文技术

100K上下文窗口的秘密:RoPE扩展、稀疏注意力

Day 6

小模型与蒸馏

大模型太贵?用知识蒸馏把能力压缩到小模型里

Day 7

大模型未来展望

AGI之路、Scaling Law的尽头、2025-2026趋势预测


写在最后

从第一周的 Transformer 架构,到第二周的训练技术,再到第三周的推理部署与 Agent——我们用21天,从"大模型是什么"走到了"大模型怎么用"。

Agent 是目前大模型应用最激动人心的方向。它让 AI 不再只是一个"百科全书",而是一个能帮你干活的"数字助手"。但也要清醒地认识到,Agent 还远不成熟——可靠性、成本、延迟都是需要解决的问题。

在实际项目中,我的建议是:

  1. 先从简单的开始:Prompt Engineering → RAG → Function Calling → Agent,逐步升级

  2. 能用 Workflow 就别用 Agent:固定流程比自由决策更可靠

  3. 始终保留人工兜底:关键决策让人类确认,别让 Agent 完全自主

  4. 监控和日志是必须的:Agent 的每一步都要记录,出了问题才能排查