1. 项目概述从“会聊天”到“会做事”的智能进化如果你最近关注AI领域一定频繁听到“Agent”这个词。它不再是科幻电影里的概念而是正在重塑我们与AI交互方式的现实技术。简单来说Agent让大模型从一个“博学的聊天伙伴”变成了一个能真正“动手做事”的智能助手。想象一下你不再需要告诉AI“去天气网站查一下北京明天的温度然后告诉我结果”而只需要说“帮我查一下北京明天的天气”它就能自动完成打开浏览器、搜索、提取信息并组织成答案的全过程。这就是Agent带来的根本性转变。这个转变背后是AI应用架构从“裸聊”到“编排”再到“自主”的三代演进。早期的ChatGPT我们称之为“裸LLM”它只能根据输入生成文本无法执行任何外部操作。随后出现的Workflow工作流工具如Dify、LangChain允许我们预先编排好一系列步骤比如先搜索、再总结让LLM在固定流程中扮演一个环节。而如今的Agent则将决策权交还给了LLM本身让它自己决定“何时、调用何种工具、执行什么动作”来完成你的目标。这不仅仅是技术的叠加更是思维范式的升级从“我告诉你步骤你照做”变成了“你理解目标自己想办法完成”。本文旨在为你彻底拆解LLM Agent的架构核心。无论你是开发者希望构建自己的智能体还是产品经理、技术爱好者想理解这一趋势我都会从最底层的原理讲起结合主流框架和实战代码带你从入门到精通看清Agent如何工作、如何构建以及它为何是AI应用的未来。2. 智能体架构的三代演进从执行者到决策者要理解Agent我们必须把它放在技术演进的脉络中去看。这能让我们明白为什么Agent是必然而不仅仅是又一个时髦词汇。2.1 第一代裸LLM对话即终点这是最原始的形态以ChatGPT、Claude的原始聊天界面为代表。核心特征单次请求-响应无状态无执行能力。能力边界只能做它“原生会”的事情回答问题、生成文本、翻译、写代码但无法运行。它就像一个无所不知但瘫痪在床的顾问只能“动嘴”不能“动手”。本质定位一个“只会说不会做”的博学者。你问“怎么发邮件”它会给你详细的步骤说明但不会帮你点击“发送”按钮。2.2 第二代Workflow编排LLM当人们不满足于仅仅获取建议而希望AI能串联多个步骤时Workflow出现了。代表产品有Dify、Coze、LangChain的Chain模式。核心特征人类预先设计好固定的执行流程图Flow。LLM被“编排”在这个流程的特定节点通常是需要理解或生成文本的节点上执行任务。所有可能的执行路径都必须提前设计好。能力进步具备了通过API节点调用外部工具的能力可以执行搜索、查询数据库、生成文件等操作。能够处理简单的多步骤任务。核心局限路径是固化的。就像按剧本演戏的演员LLM不能自己决定下一步去哪。如果用户的需求稍微偏离预设流程系统就会卡住或出错。维护成本高每次业务逻辑变动都需要重新“编排”整个流程。本质定位一个“严格按照剧本表演”的演员。剧本流程由人类编写LLM只是剧中的一个角色。2.3 第三代Agent自主智能体这是当前的前沿代表产品有Manus、OpenAI的Assistants API带代码解释器、AutoGPT以及各类自研Agent框架。核心特征LLM自己担任“导演”和“编剧”。系统提供给LLM一个目标、一套可用的工具双手和记忆由LLM自主进行规划、决策、执行和反思。能力飞跃自主规划能将复杂目标如“做一份竞品分析报告”分解成子任务搜索信息、整理数据、生成图表、撰写文案。自主决策根据当前状态和可用工具动态决定下一步调用哪个工具、传入什么参数。持续学习与反思执行后观察结果判断是否达成目标如果失败则调整策略重试。本质定位一个“能独立解决问题”的智能助手。你只需要告诉它“要什么”它自己去思考“怎么要”。一个生动的类比裸LLM你问厨师“番茄炒蛋怎么做”厨师给你口述了一遍菜谱。Workflow你设计了一个自动炒菜机设置了“放油-打蛋-炒蛋-盛出”的固定流程。厨师LLM只在“判断蛋液是否凝固”这个节点上工作。Agent你告诉厨师助理“我饿了想吃个家常菜。”助理自己打开冰箱查看食材发现有番茄和鸡蛋决定做番茄炒蛋。然后自己去拿锅、开火、炒菜最后端到你面前。过程中如果发现没盐了它会自己去拿盐。3. Agent的核心工作原理感知、思考、行动、反思的循环Agent不是一个静态的程序而是一个持续运行的动态系统。其核心是一个被称为“智能体循环”Agent Loop的闭环过程通常抽象为OODA循环Observe-Orient-Decide-Act或更具体的ReAct模式Reasoning Acting。3.1 智能体循环Agent Loop四步拆解让我们深入这个循环的每一个环节1. 观察Observe这是循环的起点。Agent从环境中接收信息包括用户输入最新的用户指令或问题。系统状态当前任务执行到哪一步了之前做了什么工具执行结果上一步调用工具后返回了什么数据外部环境信息时间、可用资源等。 观察环节将所有相关信息整合形成当前状态的“快照”为思考做准备。关键点观察的全面性和准确性直接决定了后续决策的质量。一个设计良好的Agent会在此处集成RAG检索增强生成从知识库中检索相关背景信息丰富观察内容。2. 思考/规划Think/Plan这是Agent的“大脑”时刻。LLM基于观察到的信息进行推理和规划理解目标用户到底想要什么最终要交付什么分析现状我现在有什么已经完成了什么还缺什么制定计划为了达成目标下一步应该做什么是调用工具A还是先问用户 clarifying question选择工具在众多可用工具中哪一个最适合当前这一步参数应该怎么设置 这个阶段LLM的输出通常是一个结构化的“思考过程”和一个“行动指令”。实操心得为了让LLM更好地规划我们通常在系统提示词System Prompt中明确要求它“逐步思考”Chain-of-Thought并按照特定格式如JSON输出决策便于程序解析。3. 行动Act将思考的结果付诸实践。主要是调用工具。工具执行根据思考阶段的决策调用对应的工具函数并传入参数。例如调用search_web(query“北京明日天气”)或execute_python_code(code“print(‘hello’)”)。行动安全这是关键风险点。工具调用必须有严格的权限控制和沙箱机制防止Agent执行危险操作如删除文件、访问敏感API。重要提示永远不要给Agent不受限制的“写”权限尤其是在生产环境。4. 反思Reflect行动之后评估结果。结果观察工具调用成功了吗返回的结果是什么是否符合预期目标校验当前的结果是否让我们离最终目标更近了一步问题解决了吗策略调整如果行动失败或结果不理想需要分析原因是工具选错了参数不对还是目标本身不清晰并调整后续计划。 反思环节使Agent具备了从错误中学习和适应不确定性的能力。例如如果搜索天气返回“城市不存在”Agent应该反思是否城市名输入有误并可能决定询问用户“您指的是哪个城市”。这个循环会一直持续直到Agent判断任务已经完成或无法完成最终将结果输出给用户。3.2 核心组件构建一个完整Agent的四大支柱一个功能完备的Agent系统离不开以下四个核心组件的协同工作1. 大脑LLM角色提供通用推理、规划、决策和自然语言理解能力。选型通常使用强大的通用模型如GPT-4、Claude 3、Qwen-Max。其核心能力是遵循指令和进行逻辑链推理。注意事项LLM的“幻觉”问题在Agent中会被放大因为它可能基于错误推理做出错误行动。需要通过清晰的提示词设计和反思机制来约束。2. 手脚工具集Tools角色Agent与外部世界交互的接口是其执行能力的来源。内容可以是任何API函数例如网络搜索、数据库查询、代码执行器、文件读写、发送邮件、调用企业内部系统等。设计要点工具的描述必须清晰、结构化以便LLM准确理解其功能和输入参数。业界正朝着标准化发展如MCPModel Context Protocol协议旨在统一工具的描述和调用方式。3. 记忆Memory System角色保存状态和历史让Agent具有连续性和个性化能力。类型短期记忆/对话记忆保存当前会话的上下文确保Agent能理解多轮对话的关联。长期记忆存储用户偏好、历史任务结果等实现个性化服务。工作记忆存储当前复杂任务的中间状态和子目标防止在长流程中迷失。实现可以是简单的列表、向量数据库或更复杂的图结构。4. 规划器Planner角色负责将宏大、模糊的用户目标分解为可执行的具体步骤序列。这是复杂任务执行的关键。策略ReAct思行合一每一步行动前都先输出推理Reasoning再行动Act。优点是透明、易调试缺点是每一步都需LLM推理效率较低。Plan-and-Execute先规划后执行先让LLM制定一个完整计划再逐步执行。适合目标明确、路径可预见的任务缺点是计划一旦制定灵活性较差。Multi-Agent多智能体协作创建多个具有不同专长的Agent如规划师、执行者、审查员通过协作完成任务。能力最强但系统复杂度也最高。4. 主流实现范式与框架实战理解了原理我们来看看如何实现。下面介绍三种主流范式并用伪代码和框架示例说明。4.1 ReAct范式思行合一的典范ReAct要求LLM在每一步输出“Thought/Action/Observation”的格式。# 伪代码示例一个简单的ReAct Agent循环 def react_agent_loop(user_query, tools, llm, memory): prompt initialize_prompt(user_query, tools, memory) max_steps 10 for step in range(max_steps): # 1. LLM 思考并决定行动 response llm.generate(prompt) thought, action parse_response(response) # 解析出“思考”和“行动指令” if action FINISH: final_answer extract_answer(thought) return final_answer # 2. 执行行动调用工具 tool_name, tool_args parse_action(action) if tool_name in tools: observation tools[tool_name].execute(**tool_args) else: observation fError: Tool {tool_name} not found. # 3. 将观察结果加入上下文继续循环 prompt f\nObservation: {observation} memory.append((thought, action, observation)) return 任务超时未能完成。使用框架LangGraphLangGraph是构建有状态、多步骤Agent的理想选择。它用图Graph来定义Agent的工作流节点可以是LLM调用或工具执行边是控制流。from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator class AgentState(TypedDict): question: str scratchpad: Annotated[list, operator.add] # 记录思考过程 answer: str def plan_step(state: AgentState): # LLM根据当前状态规划下一步 llm_response call_llm(f基于问题{state[question]}和已有记录{state[scratchpad]}决定下一步做什么) return {scratchpad: [llm_response]} def execute_step(state: AgentState): # 解析LLM响应执行工具调用 last_thought state[scratchpad][-1] tool_call parse_tool_call(last_thought) result call_tool(tool_call) return {scratchpad: [f工具执行结果: {result}]} # 构建图 workflow StateGraph(AgentState) workflow.add_node(plan, plan_step) workflow.add_node(act, execute_step) workflow.set_entry_point(plan) workflow.add_conditional_edges( plan, # 根据plan节点的输出决定下一步是继续执行还是结束 lambda x: act if should_continue(x) else END ) workflow.add_edge(act, plan) # 执行后回到规划 app workflow.compile()4.2 Plan-and-Execute范式谋定而后动这种范式适合任务分解清晰的项目。# 伪代码示例 def plan_and_execute_agent(user_goal, llm, tools): # 阶段一规划 plan_prompt f请将以下目标分解为具体的步骤列表 目标{user_goal} 可用工具{list_tools(tools)} 输出一个JSON数组每个元素是步骤描述和预计使用的工具。 plan_json llm.generate(plan_prompt) steps parse_json(plan_json) # 阶段二按序执行 results [] for step in steps: print(f执行步骤{step[description]}) if step[tool]: result tools[step[tool]].execute(step.get(args, {})) results.append(result) else: # 如果是纯推理步骤可能只需LLM处理 result llm.generate(f基于当前信息{results}执行{step[description]}) results.append(result) # 阶段三汇总结果 summary llm.generate(f目标{user_goal}\n执行结果{results}\n请生成最终报告。) return summary注意事项这种方式的缺点是“计划赶不上变化”。如果某个步骤失败整个计划可能需要重新制定缺乏动态调整的灵活性。通常需要结合反思机制在步骤失败时重新规划。4.3 多智能体Multi-Agent协作专业分工对于极其复杂的任务可以引入多个各司其职的Agent。角色定义主管AgentManager接收用户需求进行任务分解和调度。研究员AgentResearcher擅长使用搜索工具收集信息。分析师AgentAnalyst擅长处理数据生成图表和分析。撰稿人AgentWriter擅长整合信息撰写报告。审查员AgentReviewer检查最终成果的质量。协作流程主管将“做市场分析报告”的任务分解指派研究员收集数据分析师处理数据撰稿人撰写最后由审查员审核。它们之间通过共享的工作区或消息队列进行通信。框架推荐CrewAI是专门为多智能体协作设计的优秀框架它抽象了角色、任务、工具和流程让构建多Agent系统变得直观。5. Agent与RAG、模型微调的关系澄清在构建Agent时有两个概念经常被混淆或误解RAG和模型微调。它们与Agent是什么关系5.1 RAGAgent的“知识库工具”RAG检索增强生成本身不是Agent而是Agent可以调用的一个强大工具。RAG的作用当Agent需要回答基于特定知识如公司内部文档、最新新闻、专业资料的问题时它可以选择调用RAG工具。该工具会从知识库中检索相关片段并注入到LLM的上下文中帮助生成更准确的回答。在Agent循环中的位置通常在“观察”或“思考”阶段。例如当用户问“根据公司政策我能请多少天年假”Agent在思考时会调用query_company_handbook(question“年假政策”)这个RAG工具来获取准确信息然后再基于此信息回答或执行后续操作。核心区别维度RAGAgent本质一种知识增强技术一个具备自主性的系统架构核心能力检索 生成答案规划 决策 执行 反思执行操作不能能通过工具调用关系Agent系统中的一个可选组件工具可以包含RAG作为其工具之一一句话总结RAG让AI“更懂”Agent让AI“更能干”。一个能干的AgentAgent需要一个懂行的顾问RAG来提供专业知识。5.2 模型微调通常不是构建Agent的必需品一个常见的误区是要做一个厉害的Agent必须先微调一个专用大模型。实际上对于绝大多数Agent应用你完全不需要微调模型。为什么Agent的核心能力规划、工具调用、反思主要依赖于LLM的通用推理能力和指令遵循能力。当前的顶级模型GPT-4、Claude 3、DeepSeek-V3等在这方面已经足够强大。Agent的“智能”更多来自于系统架构设计清晰的提示词、好用的工具、有效的循环机制而非模型本身的特定参数。微调的作用域微调主要改变模型的知识或风格。例如让模型更精通法律术语或模仿某种写作风格。这对于提升Agent在特定领域对话的专业性可能有帮助但无助于提升其“决定下一步该做什么”的规划能力。优先顺序优先优化提示词与工具设计清晰的系统角色提示System Prompt详细描述工具的功能和参数。这是性价比最高的提升方式。引入RAG如果任务需要特定知识为Agent集成RAG工具。最后考虑微调只有当通用模型在领域术语理解、输出格式稳定性上实在无法满足要求且提示词工程和RAG都无效时才考虑微调。微调成本高且会使系统绑定于某个特定模型丧失灵活性。实战建议从通用模型精心设计的提示词开始。你的前90%的Agent效果提升将来自于系统架构和工程实现而非模型微调。6. 从零构建你的第一个Agent实战指南理论说了这么多我们来动手构建一个最简单的Agent。我们将构建一个“网络搜索助手”它能理解你的问题自动决定是否需要搜索并整合搜索结果给出答案。6.1 环境准备与工具定义我们使用OpenAI的API和简单的函数调用Function Calling功能来实现。首先定义Agent可以使用的“工具”。# 安装必要库pip install openai import openai import json import requests from typing import List, Dict, Any # 1. 定义工具函数 def search_web(query: str, num_results: int 3) - str: 使用模拟的搜索引擎进行搜索。 在实际应用中你可以替换为Serper、Google Search API等真实服务。 # 这里是模拟返回真实情况应调用API mock_results { 什么是Agent: Agent是一种能够感知环境、自主决策、执行动作的智能系统..., Python基础教程: Python是一种解释型、高级编程语言以简洁易读著称..., 今天天气: 抱歉此工具仅用于示例请使用专门的天气查询工具。 } # 简单模拟如果查询包含在mock里则返回对应结果 for key in mock_results: if key in query: return f搜索 ‘{query}‘ 的结果{mock_results[key]} return f搜索 ‘{query}‘ 未找到匹配的模拟结果。请尝试其他关键词。 # 工具描述用于告诉LLM这个工具能干什么 tools [ { type: function, function: { name: search_web, description: 在互联网上搜索信息适用于回答需要最新或外部知识的问题。, parameters: { type: object, properties: { query: {type: string, description: 搜索查询词}, num_results: {type: integer, description: 返回结果数量默认3} }, required: [query] } } } ]6.2 构建核心Agent循环接下来我们实现一个简化版的ReAct循环。这个Agent会判断用户问题是否需要搜索如果需要则调用工具然后根据结果生成最终回答。class SimpleAgent: def __init__(self, api_key: str, model: str gpt-3.5-turbo): self.client openai.OpenAI(api_keyapi_key) self.model model self.conversation_history [] # 简单的对话记忆 def run(self, user_input: str) - str: 运行Agent处理一次用户输入 # 准备包含历史记录的对话上下文 messages [ {role: system, content: 你是一个有帮助的AI助手可以调用搜索工具来获取最新信息。 请遵循以下步骤 1. 判断用户的问题是否需要搜索网络来获取更准确或更新的信息。 2. 如果需要就调用‘search_web‘工具。 3. 根据工具返回的结果和你的知识给出最终回答。 如果问题很简单或基于常识请直接回答无需搜索。} ] messages.extend(self.conversation_history[-6:]) # 保留最近3轮对话作为记忆 messages.append({role: user, content: user_input}) # 第一步让LLM思考并决定是否调用工具 response self.client.chat.completions.create( modelself.model, messagesmessages, toolstools, tool_choiceauto, # 让模型自行决定是否调用工具 ) response_message response.choices[0].message tool_calls response_message.tool_calls # 第二步如果有工具调用则执行 if tool_calls: print(f[Agent] 决定调用工具: {tool_calls[0].function.name}) available_functions {search_web: search_web} for tool_call in tool_calls: function_name tool_call.function.name function_to_call available_functions[function_name] function_args json.loads(tool_call.function.arguments) # 执行工具函数 function_response function_to_call(**function_args) print(f[工具 {function_name}] 返回: {function_response[:100]}...) # 将工具响应添加到对话历史中让LLM知晓结果 messages.append(response_message) # 添加包含工具调用的助理消息 messages.append({ tool_call_id: tool_call.id, role: tool, name: function_name, content: function_response, }) # 第三步LLM基于工具结果生成最终回答 second_response self.client.chat.completions.create( modelself.model, messagesmessages, ) final_answer second_response.choices[0].message.content else: # 无需工具调用直接使用第一次的回复 final_answer response_message.content # 更新对话历史 self.conversation_history.append({role: user, content: user_input}) self.conversation_history.append({role: assistant, content: final_answer}) return final_answer # 使用Agent if __name__ __main__: agent SimpleAgent(api_keyyour-openai-api-key) print(agent.run(什么是大语言模型Agent)) print(\n--- 下一个问题 ---\n) print(agent.run(今天的新闻头条是什么)) # 这个问题会触发搜索工具6.3 运行结果与解析当你运行上述代码需填入有效的OpenAI API Key时可能会看到如下输出[Agent] 决定调用工具: search_web [工具 search_web] 返回: 搜索 ‘大语言模型Agent‘ 的结果Agent是一种能够感知环境、自主决策、执行动作的智能系统... 大语言模型Agent是指基于大语言模型构建的智能体系统。它结合了LLM的理解和推理能力以及外部工具的执行能力能够自主完成复杂任务而不仅仅是生成文本。例如它可以自动搜索信息、处理数据、操作软件等。第一个问题触发了搜索工具Agent将搜索结果与自身知识结合给出了回答。第二个问题“今天的新闻头条”同样会触发搜索但由于我们的工具是模拟的可能返回预设结果或提示。这个简单的示例包含了Agent的核心要素大脑GPT模型。工具search_web函数。记忆conversation_history列表。循环判断-调用工具-整合回答。7. 生产级Agent开发避坑指南与最佳实践从玩具示例到生产系统有大量的坑需要避开。以下是我在实际项目中总结的关键经验。7.1 工具设计与安全工具描述务必精确LLM完全依赖你的工具描述来理解何时以及如何使用它。模糊的描述会导致误调用。描述应清晰说明功能、输入参数格式、输出格式以及适用场景。实施严格的权限控制这是生命线务必遵循最小权限原则。文件操作限制在特定沙箱目录禁止向上级目录访问。网络请求限制可访问的域名白名单防止访问内部或恶意网站。API调用使用具有严格权限的API密钥并设置速率限制和用量监控。代码执行必须在完全隔离的沙箱环境如Docker容器中运行并有超时和资源限制。设计健壮的错误处理工具调用可能因网络、权限、参数错误等失败。Agent必须能处理这些错误而不是崩溃。工具函数应返回结构化的错误信息供LLM在“反思”阶段分析。7.2 提示词工程明确系统角色在System Prompt中清晰定义Agent的职责、行为边界和输出格式。例如“你是一个谨慎的助手在采取任何可能产生影响的行动前必须向我确认。”强制结构化输出要求LLM以JSON等固定格式输出其“思考过程”和“行动决策”便于程序解析。例如使用LangChain的StructuredOutputParser或Pydantic模型。提供少量示例Few-Shot在Prompt中提供1-2个完整的“用户输入-Agent思考-行动-结果-最终回答”的示例能极大提升LLM的表现。管理上下文长度Agent循环会产生很长的对话历史。需要设计有效的记忆压缩或摘要策略防止超出模型的上下文窗口。7.3 稳定性与成本优化设置循环超时和最大步数防止Agent陷入死循环。例如最多执行20步超过则强制终止并返回错误。实现“优雅退出”当LLM多次尝试后仍无法取得进展应能识别并主动向用户求助而不是无限重试。成本监控Agent的多次LLM调用和工具调用会产生显著成本。务必记录每次交互的Token消耗和API调用次数设置预算警报。考虑使用小模型进行简单决策并非每一步都需要GPT-4。可以用更便宜、更快的模型如GPT-3.5-Turbo来处理简单的工具选择或结果过滤用大模型处理核心规划。7.4 评估与调试记录完整的轨迹Trace保存每一次LLM的输入输出、工具调用及结果。这是调试复杂问题的唯一途径。可以使用LangSmith、Weights Biases等工具。构建测试集针对常见任务和边缘案例构建输入-期望输出的测试用例定期运行以评估Agent性能是否回退。可视化Agent思考过程在开发界面中展示Agent的“内心独白”思考链这不仅能帮助调试也能增加用户信任。8. 行业案例深度解析Manus为何能火Manus在2025年初的爆发完美诠释了Agent的核心价值。它被称作“第一个真正能帮你做事的AI”。我们来看看它做了什么。传统ChatGPT vs Manus的对比任务“帮我做一份竞品分析报告。”ChatGPT会输出一份报告模板、建议的分析维度、数据来源建议然后说“你可以按照这个框架去收集数据并填写。”Manus规划自动分解任务为“搜索竞品信息”、“提取关键数据”、“制作对比图表”、“撰写分析文案”。执行自动打开浏览器搜索指定竞品从网页中抓取价格、功能等信息将数据整理到表格生成可视化图表最后将所有这些整合成一份格式完整的PDF或PPT报告。交付将最终的报告文件提供给你。Manus火爆的背后逻辑从“建议”到“交付”它完成了价值的闭环。用户要的不是指导手册而是最终成果。Manus交付的是可用的文件和数据而不仅仅是文本建议。减少人工介入用户只需说出目标无需一步步指导如何搜索、用什么工具、如何整理格式。这极大地降低了使用门槛和操作成本。跨系统操作能力它能同时操作浏览器、文档编辑器、数据分析工具等多个软件完成了以前需要人工在多个标签页和应用程序间切换的复杂工作流。这清晰地展示了Agent的终极形态一个真正理解你意图并能调动数字世界资源为你完成任务的数字员工。OpenAI的“Operator”和Anthropic的“Computer Use”功能也沿着同一方向推进让大模型能直接操作电脑界面。这不再是未来展望而是正在发生的现在。构建一个强大的Agent系统技术栈的选择至关重要。它远不止是调用一个API而是需要将推理引擎、工具集、记忆模块和任务规划器有机整合。从简单的函数调用开始逐步引入状态管理、复杂规划和安全控制你会逐渐体会到将思考能力赋予程序的巨大魅力。记住最好的开始就是动手实现一个能解决你实际工作中某个微小痛点的Agent哪怕它只是自动整理你每天收到的邮件标题。