2026 AI Agent 大年!26年必学技能,万字长文教你打造智能体(内含代码)

张开发
2026/4/6 11:10:39 15 分钟阅读

分享文章

2026 AI Agent 大年!26年必学技能,万字长文教你打造智能体(内含代码)
unsetunset什么是 Agentunsetunset2025 被成为 AI Agent 元年26 年更是明确为 Agent 大年比如最近爆火的 OpenClaw 就是一个 Agent并且大量各种各样的 Agent 正将像雨后春笋般出现很可能改变我们的工作与生活方式。所以 Agent 这个词出现的频率非常之高但你真要问 Agent 是个撒又没几个人说得清楚。Agent 一词源自拉丁语 agere本义是 “去做、去行动”。从概念上看Agent 就是行动者一个能主动发起动作、感知环境、围绕目标自主行动的实体。放到专业领域AI Agent智能体 就是把这种 “行动者能力” 赋予 AI 系统。它不再是只会被动响应指令、给出答案的大模型而是一个能自主感知、自主决策、自主执行的智能实体。 简单说传统大模型擅长 “回答问题”而 Agent 擅长 “完成任务”。它可以理解你的目标自动拆解步骤、规划路径、调用工具一步步把事情真正做完只不过最近我看见最为经典的图还是这张他其实更清晰的回答了 Agent 是什么并且隐约表述了其发展规律一场 Workflow 的复杂度的迁移泛化能力极强的Workflow或者说Agentic Workflow理解这句话就理解了什么叫让AI自己去干活其实 Agent 不过是模型使用范式其中一种罢了。unsetunset如何让 AI 做事unsetunset现在的大模型像 gpt、qwen、deepseek 这些它们学了很多公开知识推理和逻辑能力很强他们的核心执行逻辑是通过我们输入的内容经过计算推理之后输出一个结果给我们。以 DeepSeek 官方 API 调用为例import osfrom openai import OpenAIclient OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com)response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: You are a helpful assistant}, {role: user, content: Hello}, ], streamFalse)print(response.choices[0].message.content)从这个例子可以看到模型接收的 messages 包含系统提示和用户提问模型最终只输出一段文字content然后就结束了也就是说大模型本身不会执行任何实际操作它只会“告诉你怎么做”而不会“替你去做”。那么如何才能让 AI 真正完成一项任务呢答案是为 AI 提供执行任务所需的能力。如果在没有 AI 的情况下也能完成这件事那说明我们已经具备了相应的工具或函数。接下来我们只需要把这些函数“告诉”AI并引导它在需要时选择合适的函数。下面我们就用开发一个旅游规划助手的智能体来举例。unsetunset开发 Agentunsetunset我们将通过开发一个旅游规划助手的智能体案例来详细讲解如何让 AI 真正做事设计功能和函数在引入 AI 之前我们首先要确保即使没有 AI用户也能独立完成旅游规划。因此我们需要先设计好旅游助手所需的核心功能并实现对应的函数**查询天气**根据目的地获取未来几天的天气预报。**查询热门景点**列出目的地的热门景点及其简介、门票等信息。**查询酒店**根据目的地和日期推荐附近的酒店及价格。**查询公交路线**规划两个地点之间的公共交通路线。在没有 AI 的情况下用户需要自己依次执行这些查询先查天气决定出行时间再查景点筛选感兴趣的地方然后查附近酒店最后查景点与酒店之间的交通路线。用户通过这些工具完全有能力自己规划旅游行程就是过程比较繁琐一点。让 AI 接管规划流程我们希望只需说一句“帮我规划下周去北京的行程”AI 就能自动调用上述函数获取信息并生成完整的旅游计划。那么我们需要做什么关键在于系统提示词。我们需要告诉 AI它的身份和任务。它可以使用哪些工具函数。如何通过结构化的方式例如 JSON告诉我们它想调用哪个工具。以及是否已经收集足够信息。这里随便提个问题为什么需要 JSON 格式呢AI 模型本身输出的是自然语言文本。为了让程序能够理解 AI 的意图并执行相应的函数我们需要 AI 以 结构化的数据格式如 JSON来输出它的决策。这样我们解析 JSON 后就知道该调用哪个函数并传递什么参数。所以用不用 JSON 格式无所谓你非要用 XML 都行只要对模型友好、程序又方便解析就行。系统提示词案例下面是一个为旅游规划助手的系统提示词案例明确要求AI在返回结果的时候使用json 格式json需要包含以下字段**action**动作类型可以是call_tool调用工具或respond(直接回答用户)**tool**当action的值为call_tool时指定要调用的工具名称(例如get_weather)**parameters**调用工具所需的参数以键值对形式提供。**isSufficient**表示当前收集到的信息是否足够完成用户的需求true 表示可直接生成最终回答false 表示还需要继续调用工具。**message**当action为respond时输出的自然语言回答。你是一位专业的旅游规划助手。你的目标是根据用户的需求提供详尽、合理的旅游行程建议。你有以下工具可以使用每个工具都有对应的名称和参数。get_weather(目的地, 日期) - 查询目的地天气预报。get_attractions(目的地) - 查询热门景点列表含简介、门票、开放时间。get_hotels(目的地, 入住日期, 退房日期) - 查询推荐酒店及价格。get_route(起点, 终点) - 查询公共交通路线。你必须输出一个 JSON 对象不得包含其他任何文本。JSON 对象应包含以下字段 action: 字符串值为 call_tool 或 respond。 tool: 当 action 为 call_tool 时此处填写要调用的工具名称如 get_weather否则留空。 parameters: 当 action 为 call_tool 时此处填写调用工具所需的参数对象例如 {目的地: 北京, 日期: 2025-03-15}否则为空对象。isSufficient: 表示当前收集到的信息是否足够完成用户的需求。如果为 true则下一步应直接回答用户如果为 false则还需继续调用工具获取更多信息。 message: 当 action 为 respond 时此处填写你要对用户说的自然语言回答否则留空。工作流程1. 你需要理解用户的请求提取关键信息。2. 如果需要调用工具获取信息你需要将action的值设置成call_tool同时设置 parameters 的值并将 isSufficient 设为 false。3. 当你已经获得足够信息可以回答用户的问题你需要将action设置为respond在 message 中给出完整的旅游规划建议并将 isSufficient 设为 true。接下来就是 Agent 的本质循环实现了循环调用把用户问题和系统提示词一起发送给 AIAI 经过推理后会按照提示词约定格式输出我们需要在代码中解析json获取参数来处理。action 的值为 “call_tool” 时则根据tool和parameters调用对应的函数获取结果然后将结果作为新的消息加入对话再次请求模型。action 的值为 “respond” 时则将message展示给用户结束对话下面是一个简化的 Python 伪代码示例import jsonimport openaidef get_weather(destination, date): return f{destination} {date} 天气晴朗def get_attractions(destination): return f{destination} 的热门景点有故宫、颐和园...# ... 其他函数# 系统提示词如上system_prompt ...messages [ {role: system, content: system_prompt}, {role: user, content: 帮我规划下周去北京的行程}]client OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com)while True: response client.chat.completions.create( modeldeepseek-chat, messagesmessages, streamFalse ) # 解析 JSON try: decision json.loads(response.choices[0].message.content) except: print(模型输出非 JSON错误处理...) break if decision[action] call_tool: tool_name decision[tool] params decision[parameters] # 调用对应工具 if tool_name get_weather: result get_weather(**params) elif tool_name get_attractions: result get_attractions(**params) # ... 其他工具 # 将工具结果加入对话 messages.append({role: tool, content: result, tool_call_id: tool_name}) # 继续循环 elif decision[action] respond: print(decision[message]) break看到这里一个简单的旅行助手智能体就开发完成啦用户只需一句话它就能自主调用工具完成一次完整的旅行规划。回顾一下我们用了哪些技术其实非常简单**大模型**作为核心的推理引擎。**系统提示词**在其中定义了工具的功能和使用规则。**预先写好的函数**提供实际执行能力。**解析 JSON 的代码**将模型的决策转化为函数调用。可以看见这里的核心就是模型 工具。通过提示词告诉模型有哪些工具可用、名称和参数是什么何时应该使用模型便能自主规划并调用工具来完成任务整个过程并不复杂非常简单。将工具的定义和说明全部写在提示词里在工程上并不优雅提示词会变得冗长难以维护。工具一多修改和版本管理会很麻烦。模型的输出格式完全依赖提示词的约束不够稳定。于是在2022年论文《ReAct: Synergizing Reasoning and Acting in Language Models》开始探讨工程实现随后才有各个模型的Function Calling、Tools Calling 方法。GPT的 Function Calling函数调用就是专门为大模型设计的原生工具调用机制可以让我们以结构化的方式向模型注册工具模型则会以标准化的格式返回调用请求省去了我们自己解析 JSON 的繁琐也让工具管理变得清晰高效。所以接下来我们就来详细介绍 Function Calling 看看它如何让智能体的开发更加规范。unsetunsetFunction CallingunsetunsetFunction Calling 最早由 OpenAI 在2023 年 6 月 13 日在其 API 更新中以标准化接口的形式正式引入。OpenAI 发布了新版本的 gpt-3.5-turbo 和 gpt-4 模型并新增了 functions 参数使得开发者可以描述可用的函数模型会智能地决定是否需要调用这些函数并返回符合函数签名的JSON对象。很快其他模型提供商Anthropic Claude 、Google Gemini、Qwen、DeepSeek纷纷跟进使得 Function Calling 成为现代 LLM 的一项标配能力。我们来看一下 deepseek 如何使用 function calling 来实现我们的旅行规划助手代码一下就清爽起来了。定义工具函数需要按照模型API要求的工具格式来定义工具。每个工具包含名称、描述和参数结构json schema。tools [{type: function,function: { name: get_weather, description: 查询目的地的天气预报, parameters: { type: object, properties: { destination: { type: string, description: 目的地城市名称 }, date: { type: string, description: 查询日期格式为 YYYY-MM-DD如果不指定则返回未来几天的天气 } }, required: [destination] }}},# 其他函数 也和get_weather 这个方法一样定义 这里我们省略]改写系统提示词模型支持tools参数后我们在提示词里面就不需要在详细的描述工具信息了只需要定义AI的角色和任务目标system_prompt 你是一位专业的旅游规划助手。你的目标是根据用户的需求调用可用的工具获取信息并整合成一份详尽的旅游行程建议。循环我们需要循环与模型交互如果模型返回需要调用工具程序需要通过模型返回的工具名称和参数去执行工具的代码将工具执行结果添加到提示词中继续请求模型如果模型返回不需要调用工具了表示这是模型的最终回答则输出给用户plaintextimport openaiimport json# 初始化客户端DeepSeek API 兼容 OpenAI 格式client openai.OpenAI( api_key“your-deepseek-api-key”, # 替换为你的 API Key base_url“https://api.deepseek.com”)# 工具的具体实现模拟数据def get_weather(destination, dateNone): # 实际场景中应调用天气 API return f{destination} 的天气晴朗气温15-25℃适合出行。“其他的方法省略…llm OpenAI( api_keyos.environ.get(“DEEPSEEK_API_KEY”), base_url“https://api.deepseek.com”)messages [ {“role”: “system”, “content”: “你是一个天气助手”}, {“role”: “user”, “content”: input}]# 第一步定义的标准格式while True: result llm.chat.completions.create( messagesmessages, model“deepseek-chat”, streamFalse, toolstools) # 大模型输出的结果 有工具调用说明模型思考后 需要调用工具 if result.choices[0].message.tool_calls: tool_call result.choices[0].message.tool_calls[0] function_name tool_call.function.name function_args tool_call.function.arguments print(tool_call.id,function_name, function_args) messages.append({“role”: “assistant”, “content”: None, “tool_calls”: [{“id”: tool_call.id, “type”: “function”, “function”: {“name”: tool_call.function.name, “arguments”: tool_call.function.arguments}}]}) # 调用对应的函数 if function_name “get_weather”: result get_weather(function_args) elif function_name “get_attractions”: result get_attractions(function_args) elif function_name “get_hotels”: result get_hotels(function_args) elif function_name “get_route”: result get_route(function_args) else: result f未知工具: {function_name}” messages.append({“role”: “tool”, “content”: result, “tool_call_id”: tool_call.id}) else: break我们使用 大模型 Function Calling 的方式构建了一个能够自主执行任务的旅行智能体。但是这个智能体还不是很完善**它无法记住用户对话历史。** 当用户完成一次问答后继续提问比如“帮我把早上的景点换成更有深厚历史背景的景点”模型会感到困惑它并不清楚“早上的景点”指的是什么。 因为每一次模型请求调用都是独立的模型只会根据当前输入的提示词生成回答而不会主动回顾之前的调用记录。 要让模型拥有记住之前的历史记录不能指望模型自己去查找历史而是需要在工程层面手动保存每次对话的交互记录并在下一次调用时将完整的对话历史包括之前的用户问题、模型回复、工具调用结果等一并拼接到提示词中作为上下文提供给模型。 只有这样模型才能理解当前问题与过往对话的关联从而给出合理的回答毕竟模型能认识的也就只有提示词。 那么如何为智能体添加记忆能力我们将为旅行助手添加对话历史的存储与管理让智能体真正具备持续对话的能力。 unsetunset记忆能力unsetunset ------------------------ 要让智能体真正拥有持续对话的能力关键在于解决它的“记忆”问题所谓记忆指的是模型在当前输入之外仍然能够访问和使用的信息集合。 这些信息可能来自历史对话、外部存储或系统内部状态但核心目标只有一个为当前推理提供必要的上下文补充。 构建记忆能力我们需要解决三个核心问题 1. **记在哪里**。存储机制比如使用数据库还是内存。 2. **怎么记住**。写入策略区分短期记忆与长期记忆。 3. **怎么想起**。检索机制如何在需要时高效地找到相关信息。 针对这些问题目前已经有多种记忆实现方式它们各有侧重适用于不同场景 ![](http://cdn.zhipoai.cn/8d4f32d1.jpg) ### 上下文记忆 这是最基础的记忆实现方式做法最简单将历史对话按照时间顺序原样拼接到当前的提示词中一起发送给模型。模型通过阅读完整的对话历史来保持语义连贯性。 * **优点**实现成本低适合原型验证或短对话场景。 * **缺点**受限于模型的Token上限对话越长成本越高无法支持跨会话或长期记忆。 * **本质**这是一种短期、一次性的情景记忆。 ### 滑动窗口记忆 滑动窗口记忆是在上下文记忆基础上的一种约束策略只保留最近固定轮数的对话其余内容直接丢弃。它主要解决的是 Token 成本控制问题而非记忆能力的增强。 * **优点**有效控制提示词长度降低开销。 * **缺点**一旦关键信息被滑出窗口就会永久丢失。 * **适用场景**上下文有效期明确、业务流程较短的对话。 * **本质**可以理解为情景记忆的生命周期管理机制。 ### 摘要记忆 摘要记忆通过调用模型对历史对话进行压缩将大量情景信息提炼成一段简要描述并在后续对话中使用该摘要替代原始内容。 * **优点**显著降低Token消耗同时保留对话的整体脉络。 * **缺点**摘要过程不可避免会造成信息丢失且质量高度依赖模型的总结能力。 * **适用场景**需要保留“整体脉络”但对精确细节要求不高的场景。 * **本质**将情景记忆转化为低精度的语义记忆。 ### 向量记忆 向量记忆是一种长期记忆实现方式。将用户对话内容、用户偏好、经验知识向量化后存入向量数据库在用户发起对话时将用户的问题向量化在数据库中查找出语义相似的内容。 * **优点**不受对话长度限制支持跨会话长期记忆能够基于语义匹配相关信息。 * **缺点**检索结果是“语义相似”而非“精确匹配”实现复杂度较高。 * **适用场景**需要长期知识积累和个性化服务的智能体。 * **本质**当前Agent系统中最常见的语义记忆工程实现。 以上几种记忆方式并非互斥实际应用中往往组合使用。例如可以用滑动窗口保存短期上下文用向量记忆存储长期用户偏好再结合摘要记忆定期压缩历史。 unsetunset记忆系统的实现unsetunset --------------------------- **考虑难度与阅读伪代码就好** 为了让智能体具备记忆能力需要设计一个记忆管理系统包含短期记忆和长期记忆两部分。下面给出简化版的伪代码演示如何保存和查询记忆并将查询结果拼接到提示词中 ![](http://cdn.zhipoai.cn/feb4a513.jpg) ### 短期记忆 短期记忆说白了就是记住用户刚说过什么。但咱不能无限记毕竟大模型的上下文窗口就那么大点塞太多不仅贵还容易让模型“眼花缭乱”。 所以最常见的做法就是滑动窗口只保留最近 N 轮对话超出的直接丢掉。 为什么留最近几轮因为用户刚刚聊的东西大概率还热乎着呢和当前问题最相关。那些陈年旧事交给长期记忆去管。 代码实现上Python 自带的 collections.deque 设个最大长度新消息进来自动把老的挤出去省心 plaintext from collections import dequeclass ShortTermMemory: def __init__(self, max_messages20): 初始化短期记忆。 :param max_messages: 最多保留的消息条数而非对话轮数。每条消息对应一个 roleuser/assistant/tool。 self.messages deque(maxlenmax_messages) def add(self, message: dict): 添加一条消息到短期记忆。message 格式需符合 OpenAI 消息格式。 self.messages.append(message) def get_all(self) - list: 返回当前短期记忆中所有消息按时间顺序。 return list(self.messages) def clear(self): self.messages.clear()长期记忆长期记忆用于存储需要跨会话保留的信息比如用户的旅行偏好、之前讨论过的目的地、历史规划中的特殊要求等。这些信息不能简单用滑动窗口保留因为时间太久对话次数过多后就被遗弃了。长期记忆的经典实现是“向量检索”将文本转化为向量存入向量数据库当需要回忆时将当前问题也转为向量通过相似度找到最相关的历史内容。为什么用向量检索因为用户的问题每次都不一样如果用关键字检索就必须要内容一样才能检索出来。向量能捕捉语义相似性比关键词匹配更智能。如果想要召回的答案更加可靠可以考虑 使用 问题重写BM25关键字查询最后使用重排等优化手段。下面的代码使用Python中的列表模拟向量数据库存储和查询实际项目应替换为 Chroma、FAISS、Pinecone 等专用工具。embedding_model 可以是 sentence-transformers、OpenAI Embeddings、通义千问的向量模型等。import numpy as npfrom typing import List, Dictclass LongTermMemory:def __init__(self, embedding_model): self.embedding_model embedding_model self.vectors [] # 存储向量 self.texts [] # 存储原始文本 self.metadatas [] # 存储元数据如时间戳、重要性等 def _embed(self, text: str) - np.ndarray:return self.embedding_model.encode(text) def add(self, text: str, metadata: dict None):将一段文本存入长期记忆。 vector self._embed(text) self.vectors.append(vector) self.texts.append(text) self.metadatas.append(metadata or {}) def query(self, query_text: str, top_k: int 3) - List[str]:根据查询文本返回最相关的 top_k 条记忆文本。if not self.vectors: return [] query_vec self._embed(query_text)# 计算余弦相似度 similarities [ np.dot(query_vec, v) / (np.linalg.norm(query_vec) * np.linalg.norm(v)) for v in self.vectors ] top_indices np.argsort(similarities)[-top_k:][::-1]return [self.texts[i] for i in top_indices]记忆管理器整合短期与长期记忆管理器专门用来管理记忆的保存并提供构建最终提示词的方法。它的核心逻辑是从短期记忆拿到最近的对话历史。从长期记忆检索与当前问题相关的背景知识。将长期记忆作为系统提示的一部分短期记忆按顺序排列最后加上当1. 前用户输入形成完整的 messages 列表。class MemoryManager: def __init__(self, embedding_model, short_term_max_messages20, long_term_top_k3): self.short_term ShortTermMemory(max_messagesshort_term_max_messages) self.long_term LongTermMemory(embedding_model) self.long_term_top_k long_term_top_kdef add_short_term(self, message: dict): self.short_term.add(message)def add_long_term(self, text: str, metadata: dict None): # 实际应用中可在此处进行重要性过滤 self.long_term.add(text, metadata)def build_messages(self, current_query: str, system_prompt_base: str ) - List[dict]: # 从长期记忆检索 long_memories self.long_term.query(current_query, top_kself.long_term_top_k) # 构建最终的系统提示 if long_memories: memory_context 以下是可能与当前问题相关的历史记忆\n \n.join(f- {mem}for mem in long_memories) system_content f{system_prompt_base}\n\n{memory_context} else: system_content system_prompt_base # 获取短期记忆中的最近消息 short_context self.short_term.get_all() # 将消息组合到一起 messages [{role: system, content: system_content}] messages.extend(short_context) messages.append({role: user, content: current_query}) return messages在对话循环中使用记忆管理器下面将记忆管理器集成到之前的旅行规划助手对话循环中。关键变化是每次用户输入后通过 build_messages() 构造带有记忆的上下文。每次模型回复后将用户消息和助手消息存入短期记忆。在适当的时候如用户明确表达偏好、生成最终规划后将关键信息存入长期记忆。memory MemoryManager(embedding_modelembedding_model)system_base 你是一位专业的旅游规划助手。你可以调用工具获取天气、景点、酒店和路线信息。tools [...] # 同之前的 Function Calling 工具定义while True: user_input input(用户) if user_input.lower() in (exit, quit): break # 构建带记忆的消息 messages memory.build_messages(user_input, system_prompt_basesystem_base) # 工具调用循环同之前 while True: response client.chat.completions.create( modeldeepseek-chat, messagesmessages, toolstools, tool_choiceauto ) assistant_msg response.choices[0].message messages.append(assistant_msg) if not assistant_msg.tool_calls: final_answer assistant_msg.content break for tool_call in assistant_msg.tool_calls: # 调用工具并追加结果代码略同前 # ... pass # 将本轮交互存入短期记忆 memory.add_short_term({role: user, content: user_input}) memory.add_short_term({role: assistant, content: final_answer}) # 判断是否需要存入长期记忆 # 示例如果用户明确说了偏好就存否则不存。这里简单演示实际可用模型判断。 if我喜欢in user_input or 偏好in user_input: memory.add_long_term(f用户偏好{user_input}, metadata{type: preference}) # 也可以将最终生成的旅游计划存入长期记忆 if规划in user_input and final_answer: memory.add_long_term(f旅游计划{final_answer}, metadata{type: plan}) print(f助手{final_answer})这个伪代码展示了记忆系统的核心架构可以根据实际业务需求选择合适的记忆存储和检索方案。最近两年大模型发展很迅速在理论研究方面得到很大的拓展基础模型的能力也取得重大突破大模型现在正在积极探索落地的方向如果与各行各业结合起来是未来落地的一个重大研究方向大模型应用工程师年包50w属于中等水平如果想要入门大模型那现在正是最佳时机2025年Agent的元年2026年将会百花齐放相应的应用将覆盖文本视频语音图像等全模态如果你对AI大模型入门感兴趣那么你需要的话可以点击这里大模型重磅福利入门进阶全套104G学习资源包免费分享扫描下方csdn官方合作二维码获取哦给大家推荐一个大模型应用学习路线这个学习路线的具体内容如下第一节提示词工程提示词是用于与AI模型沟通交流的这一部分主要介绍基本概念和相应的实践高级的提示词工程来实现模型最佳效果以现实案例为基础进行案例讲解在企业中除了微调之外最喜欢的就是用提示词工程技术来实现模型性能的提升第二节检索增强生成RAG可能大家经常会看见RAG这个名词这个就是将向量数据库与大模型结合的技术通过外部知识来增强改进提升大模型的回答结果这一部分主要介绍RAG架构与组件从零开始搭建RAG系统生成部署RAG性能优化等第三节微调预训练之后的模型想要在具体任务上进行适配那就需要通过微调来提升模型的性能能满足定制化的需求这一部分主要介绍微调的基础模型适配技术最佳实践的案例以及资源优化等内容第四节模型部署想要把预训练或者微调之后的模型应用于生产实践那就需要部署模型部署分为云端部署和本地部署部署的过程中需要考虑硬件支持服务器性能以及对性能进行优化使用过程中的监控维护等第五节人工智能系统和项目这一部分主要介绍自主人工智能系统包括代理框架决策框架多智能体系统以及实际应用然后通过实践项目应用前面学习到的知识包括端到端的实现行业相关情景等学完上面的大模型应用技术就可以去做一些开源的项目大模型领域现在非常注重项目的落地后续可以学习一些Agent框架等内容上面的资料做了一些整理有需要的同学可以下方添加二维码获取仅供学习使用

更多文章