从LLM到Agent：智能体架构演进技术详解
前言
当谈到AI Agent（智能体）时，以下问题被频繁提出：
- Agent是如何工作的？
- 使用Agent与直接使用ChatGPT/Qwen/DeepSeek有什么区别？
- Manus智能体做了什么？为什么人们愿意用Manus而不是原生的ChatGPT？
- Agent和RAG是什么关系？
- 做Agent需要微调模型吗？
这些问题的本质是："Agent"到底是什么？它与直接调用大模型的本质区别是什么？是不是换了个名字的概念包装？
本文将用清晰的语言和图示，系统解答上述问题。
三代架构演进：LLM → Workflow → Agent
智能应用的技术架构经历了三代演进：裸LLM → Workflow → Agent
第一代：裸LLM（对话即终点）
代表产品：ChatGPT、Claude、Qwen、DeepSeek等原生对话界面
架构特征：
特点：单次请求-响应，无状态，无执行能力
能力边界：
| 能做的事 | 做不到的事 |
|---|---|
| 回答问题、生成文本 | 执行实际操作（如查数据库、调API） |
| 提供建议和方案 | 获取实时信息（知识有截止日期） |
| 代码生成、文案撰写 | 跨系统协作完成复杂任务 |
| 单轮或简单多轮对话 | 长时间任务跟踪与状态管理 |
本质定位：一个博学但"只会说不会做"的顾问。
第二代：Workflow（编排LLM）
代表产品：Dify、Coze、百度千帆、LangChain（Chain模式）等
架构特征：
特点：人类设计流程，LLM在预设节点中执行。所有可能的执行路径必须提前设计好。
相比裸LLM的进步：
| 进步点 | 说明 |
|---|---|
| 可执行操作 | 通过API节点调用外部系统 |
| 流程编排 | 多步骤任务可以串联执行 |
| 条件分支 | 根据不同情况走不同路径 |
| 知识增强 | 可集成RAG检索知识库 |
核心局限：
| 问题 | 具体表现 |
|---|---|
| 分支爆炸 | 业务场景组合爆炸式增长，难以穷举 |
| 路径预设 | 所有可能的执行路径必须提前设计好 |
| 长尾问题 | 边缘场景难以覆盖 |
| 灵活性差 | 新场景需要修改流程，响应变化慢 |
本质定位：LLM被"编排"在预设流程中，流程由人类设计，LLM只是流程中的一个执行节点。
第三代：Agent（自主智能体）
代表产品：Manus、OpenAI Operator、Claude Computer Use、AutoGPT、MetaGPT
架构特征：
特点：LLM自己决定做什么、怎么做、用什么工具
核心能力：
| 能力 | 说明 |
|---|---|
| 自主规划 | LLM自己分解任务，决定执行步骤 |
| 工具调用 | 根据需要自主选择合适的工具 |
| 反馈循环 | 执行后观察结果，动态调整策略 |
| 长时任务 | 可以持续执行复杂的多步骤任务 |
本质定位：LLM从"被编排者"变成"编排者"，自己决定调用什么、执行什么、下一步做什么。
三代架构对比总结
| 维度 | 裸LLM | Workflow | Agent |
|---|---|---|---|
| 代表产品 | ChatGPT/Qwen/DeepSeek | Dify/Coze | Manus/Operator |
| 执行能力 | 无，只能输出文本 | 有，但路径预设 | 有，自主决策 |
| 流程控制 | 无 | 人类设计流程 | LLM自主规划 |
| 工具调用 | 无 | 按预设节点调用 | 自主选择调用 |
| 应对长尾 | 差 | 一般 | 好 |
| 维护成本 | 低 | 高（分支爆炸） | 低（无需穷举分支） |
| 灵活性 | 高（但无执行力） | 低（路径固定） | 高 |
| 本质比喻 | 只会说的顾问 | 按剧本演的演员 | 能独立做事的助手 |
一句话总结：
- 裸LLM：告诉你"怎么做"
- Workflow：按预设路径"帮你做"
- Agent：自己想办法"帮你做出来"
Agent核心工作原理
Agent Loop：观察-思考-行动-反馈
Agent的核心是一个持续运行的循环，称为Agent Loop：
四个阶段详解：
| 阶段 | 核心动作 |
|---|---|
| 观察 Observe | 接收用户输入、感知当前状态、获取环境信息 |
| 思考 Think | 理解任务目标、分析当前状态、规划下一步、选择工具 |
| 行动 Act | 调用选定的工具、执行具体操作、与外部系统交互 |
| 反馈 Feedback | 观察执行结果、判断是否达成目标、决定继续/调整/结束 |
Agent核心组件
一个完整的Agent系统包含四个核心组件：
四大组件详解：
| 组件 | 功能 | 说明 |
|---|---|---|
| LLM（大脑） | 理解、推理、决策 | 是Agent的思考中枢，可以是GPT-4/Claude/Qwen等 |
| 工具集（手脚） | 执行外部操作 | API调用、数据库查询、代码执行、网页浏览等 |
| 记忆系统 | 状态管理 | 短期记忆（对话上下文）、长期记忆（用户画像）、工作记忆（任务状态） |
| 规划器 | 任务分解 | 将复杂任务分解为子步骤，确定执行顺序，动态调整计划 |
技术实现范式
目前业界主流的Agent实现范式：
ReAct（Reasoning + Acting）
核心思想：让LLM交替进行"推理"和"行动"，每次行动前先思考为什么这样做。
用户：帮我查一下北京明天的天气
Agent思考：用户想知道北京明天的天气，我需要调用天气查询工具
Agent行动：调用 get_weather(city="北京", date="明天")
Agent观察：返回结果显示晴天，气温 15-25°C
Agent思考：已经获取到天气数据，可以回答用户了
Agent输出：北京明天天气晴朗，气温15-25°C，适合外出活动。优点：推理过程透明，便于调试和审计
缺点：每一步都需要LLM推理，效率较低
Plan-and-Execute（规划后执行）
核心思想：先制定完整计划，再按计划逐步执行。
用户：帮我做一份关于新能源汽车市场的分析报告
Agent规划：
1. 搜索新能源汽车市场最新数据
2. 收集主要厂商的销量信息
3. 分析市场趋势和竞争格局
4. 生成图表和可视化
5. 整理成完整报告文档
Agent执行：按计划逐步执行各步骤...优点：复杂任务处理更有条理
缺点：计划一旦制定，调整灵活性较差
Multi-Agent（多智能体协作）
核心思想：多个专业Agent分工协作，各司其职。
优点：专业分工，复杂任务处理能力强
缺点：系统复杂度高，协调成本大
Agent与RAG的关系
什么是RAG？
RAG（Retrieval Augmented Generation，检索增强生成） 是一种让LLM能够访问外部知识的技术：
三个步骤：
- 检索 Retrieval：将问题转为向量，在知识库中检索相关文档
- 增强 Augmentation：将检索到的文档片段作为上下文注入Prompt
- 生成 Generation：LLM基于上下文生成答案
RAG是Agent的"工具"之一
核心观点：RAG和Agent不是同一层面的概念。
RAG是Agent可以调用的众多工具之一，用于获取知识
详细对比
| 维度 | RAG | Agent |
|---|---|---|
| 本质 | 一种知识增强技术 | 一种系统架构 |
| 作用 | 让LLM能访问外部知识 | 让LLM能自主完成任务 |
| 能力 | 检索 + 回答 | 规划 + 执行 + 反馈 |
| 执行操作 | 不能 | 能 |
| 关系 | 是Agent的一个工具 | 可以包含RAG |
Agent如何使用RAG
在Agent架构中，RAG通常作为一个"知识检索工具"被调用：
用户："根据公司政策，我可以申请多少天年假？"
Agent思考：这是一个需要查询内部政策的问题，我需要检索知识库
Agent行动：调用 rag_search(query="年假申请天数 公司政策")
Agent观察：检索结果显示"工龄1-5年：5天，5-10年：10天，10年以上：15天"
Agent思考：已获取政策信息，但需要知道用户工龄才能给出准确答案
Agent行动：询问用户"请问您的工龄是多少年？"
用户："3年"
Agent输出：根据公司政策，您目前工龄3年，可以申请5天年假。RAG与Agent结合的模式
| 模式 | 说明 | 适用场景 |
|---|---|---|
| RAG Only | 纯知识问答，无执行能力 | 简单FAQ、文档问答 |
| Agent + RAG | Agent调用RAG获取知识，再执行操作 | 需要知识支撑的任务执行 |
| Agentic RAG | RAG流程本身由Agent控制，可动态决定检索策略 | 复杂知识推理 |
Agent是否需要模型微调？
核心结论：通常不需要
Agent的能力主要不来自于模型微调，而来自于系统架构。
关键洞察：
- LLM基础能力：通用LLM（如GPT-4/Claude/Qwen）已经足够，通常不需要微调
- 系统架构能力：工具定义、记忆系统、提示工程（Prompt Engineering）、Agent Loop —— 这是Agent能力的主要来源，与模型微调无关
为什么Agent通常不需要微调？
| 原因 | 说明 |
|---|---|
| LLM能力已足够 | 现代LLM（GPT-4、Claude 3、Qwen2.5等）的通用能力已经足以支撑Agent的推理和规划需求 |
| 能力来自架构 | Agent的"执行能力"来自工具调用，不是模型本身的能力 |
| 提示工程更高效 | 通过精心设计的System Prompt，可以让通用LLM表现出领域专家的行为 |
| 灵活性更强 | 不微调意味着可以随时切换底层模型，享受模型迭代的红利 |
| 成本更低 | 微调需要数据、算力、时间，而提示工程几乎零成本 |
什么情况下可能需要微调？
虽然通常不需要，但以下场景可以考虑微调：
| 场景 | 说明 | 微调目标 |
|---|---|---|
| 领域专业术语 | 模型对特定领域术语理解不准确 | 提升领域语言理解 |
| 特定输出格式 | 需要模型稳定输出特定格式 | 增强格式遵循能力 |
| 成本优化 | 用小模型+微调替代大模型 | 降低推理成本 |
| 私有化部署 | 无法调用云端大模型API | 提升本地小模型能力 |
微调 vs 提示工程 vs RAG
| 技术手段 | 作用 | 适用场景 | 成本 |
|---|---|---|---|
| 提示工程 | 引导模型行为 | 几乎所有场景 | 低 |
| RAG | 注入外部知识 | 需要特定知识的场景 | 中 |
| 微调(LoRA等) | 改变模型参数 | 特殊格式/领域/成本优化 | 高 |
推荐策略：
- 优先：提示工程 + RAG
- 其次：如果效果不够，考虑微调
- 原则：能不微调就不微调，保持架构灵活性
Agent能力提升的正确路径
| 优先级 | 手段 | 具体工作 |
|---|---|---|
| 1 | 提示工程 | 优化System Prompt、设计清晰的工具描述、Few-shot示例 |
| 2 | 工具生态 | 丰富工具集、优化工具接口设计、工具组合能力 |
| 3 | 知识增强 | 构建高质量知识库、优化检索策略、知识更新机制 |
| 4 | 模型微调 | 特定领域术语理解、稳定输出格式、成本优化（仅在必要时） |
行业案例分析
Manus：为什么火？做了什么？
Manus 是2025年初爆火的AI Agent产品，被称为"第一个真正能帮你做事的AI"。
Manus的核心能力
| 能力 | 说明 | 示例 |
|---|---|---|
| 浏览器自动化 | 像人一样操作网页 | 自动搜索信息、填写表单、下载文件 |
| 代码执行 | 编写并运行代码 | 数据处理、文件转换、自动化脚本 |
| 文件操作 | 创建、编辑、管理文件 | 生成报告、整理文档、批量处理 |
| 任务编排 | 将复杂任务拆解执行 | 多步骤任务自动化完成 |
Manus vs 原生ChatGPT 对比
| 任务 | ChatGPT的回答 | Manus的做法 |
|---|---|---|
| "帮我做一份竞品分析报告" | 给你一个报告模板和框架建议 | 自动搜索竞品信息、收集数据、生成完整的分析报告文档 |
| "帮我查一下明天北京的天气" | 告诉你可以去哪个网站查 | 打开天气网站、查询数据、直接告诉你结果 |
| "把这个PDF转成Word" | 推荐一些在线转换工具 | 直接执行转换、生成Word文件给你 |
| "帮我分析这份Excel数据" | 需要你把数据粘贴进去 | 直接读取文件、执行分析、生成图表 |
为什么人们愿意用Manus？
一句话总结：Manus把LLM从"对话工具"变成了"执行助手"。
具体原因：
- 从"建议"到"执行"：不只是告诉你怎么做，而是帮你做出来
- 减少人工介入：用户只需要说目标，不需要一步步指导
- 跨系统能力：可以同时操作多个网站、工具，完成复杂任务
- 结果交付：最终产出是可用的文件、数据，而不只是文字建议
OpenAI Operator / Claude Computer Use
2024-2025年，OpenAI和Anthropic先后推出了Computer Use能力：
| 产品 | 发布时间 | 核心能力 |
|---|---|---|
| Claude Computer Use | 2024.10 | Claude可以控制电脑，像人一样操作鼠标键盘 |
| OpenAI Operator | 2025.1 | GPT可以自动执行网页任务，如购物、预订等 |
这表明：Agent化是大模型应用的必然趋势，头部厂商都在朝这个方向发展。
MCP协议：Agent工具调用的行业标准
2024年11月，Anthropic发布了**MCP（Model Context Protocol）**协议，正在成为Agent工具调用的事实标准：
| 特点 | 说明 |
|---|---|
| 标准化 | 统一的工具描述和调用协议 |
| 生态共享 | 一次开发，多Agent复用 |
| 行业认可 | 支付宝、微信等已推出MCP Server |
如何构建一个Agent系统
技术组件清单
构建一个完整的Agent系统，需要以下技术组件：
各层级详解：
| 层级 | 组件 | 具体内容 |
|---|---|---|
| 1 | Agent运行框架 | Agent Loop实现、规划-执行-反馈循环、多Agent协作机制。可选：LangGraph/AutoGPT/CrewAI/自研 |
| 2 | 工具系统 | 工具定义（MCP/Function Calling）、工具注册中心、调用执行引擎、错误处理与重试 |
| 3 | 记忆系统 | 短期记忆（对话上下文）、长期记忆（用户画像、历史任务）、工作记忆（任务中间状态） |
| 4 | 感知增强 | 多模态输入处理、RAG知识检索、联网搜索 |
| 5 | 安全控制 | 输入安全（注入检测）、执行安全（权限控制）、输出安全（幻觉检测） |
最小可行Agent
如果想快速体验Agent开发，可以从最小可行方案开始：
# 伪代码：最小可行Agent
def minimal_agent(user_input, tools, llm):
# 1. 将用户输入和可用工具描述发送给LLM
prompt = f"""
你是一个AI助手，可以使用以下工具：
{format_tools(tools)}
用户请求：{user_input}
请分析用户需求，决定是否需要调用工具，以及如何回答。
"""
while True:
# 2. LLM思考并决定下一步
response = llm.chat(prompt)
# 3. 如果LLM决定调用工具
if response.has_tool_call:
tool_name = response.tool_call.name
tool_args = response.tool_call.arguments
# 4. 执行工具调用
result = tools[tool_name].execute(tool_args)
# 5. 将结果反馈给LLM，继续循环
prompt += f"\n工具{tool_name}返回：{result}"
else:
# 6. LLM给出最终回答，结束循环
return response.content推荐的框架选择
| 框架 | 特点 | 适用场景 |
|---|---|---|
| LangGraph | LangChain团队出品，支持复杂Agent流程编排 | 复杂多步骤Agent |
| AutoGPT | 早期Agent框架，社区活跃 | 通用自主Agent |
| CrewAI | 专注多Agent协作 | 多角色协作场景 |
| OpenAI Assistants API | OpenAI官方方案，集成度高 | 快速原型、GPT用户 |
| 自研 | 完全可控，可深度定制 | 有特殊需求的生产系统 |
总结
本文系统梳理了从LLM到Agent的技术演进：
- 三代架构：裸LLM（只能说）→ Workflow（按剧本做）→ Agent（自主做）
- Agent核心：观察-思考-行动-反馈的循环，由LLM+工具+记忆+规划组成
- Agent与RAG：RAG是Agent的一个工具，用于知识增强，二者不是同一层面的概念
- 是否需要微调：通常不需要，Agent能力主要来自系统架构而非模型参数
- 行业趋势：Agent化是大模型应用的必然方向，头部厂商都在布局
一句话理解Agent：Agent = LLM（大脑） + 工具（手脚） + 记忆 + 规划能力，让AI从"能说"进化到"能做"。
附录：技术名词解释
| 术语 | 英文 | 解释 |
|---|---|---|
| Agent | Agent | 智能体，能够感知环境、自主决策、执行动作的AI系统 |
| LLM | Large Language Model | 大语言模型，如GPT-4、Claude、Qwen等 |
| Workflow | Workflow | 工作流，预定义的任务执行流程 |
| MCP | Model Context Protocol | 模型上下文协议，Anthropic提出的Agent工具调用标准 |
| RAG | Retrieval Augmented Generation | 检索增强生成，通过检索外部知识增强LLM回答 |
| ReAct | Reasoning + Acting | 一种Agent范式，交替进行推理和行动 |
| CoT | Chain of Thought | 思维链，让LLM展示推理过程的提示技术 |
| Tool Calling | Tool Calling / Function Calling | 工具调用，LLM调用外部工具的能力 |
| LoRA | Low-Rank Adaptation | 低秩适配，一种高效的模型微调方法 |