前几天分享了部分关于 Agent 的内容
引起了不少同学的关注，但也达成了我历史文章最夸张反差数据：分享数 * 10 > 阅读数，甚至呈现出了近2倍的差距！
只能说明一件事：大家觉得很有用，但大家真的不想读，非常想让基友赶紧去学，后续也确实有不少粉丝反馈：很有用，但太有用了，希望能稍微“没用点”，也希望再来点...
所以，今天这篇文章我尽量减少努力！
什么是 Agent
2025 被成为 AI Agent 元年，26 年更是明确为 Agent 大年，比如最近爆火的 OpenClaw 就是一个 Agent，并且大量各种各样的 Agent 正将像雨后春笋般出现，很可能改变我们的工作与生活方式。
所以 Agent 这个词出现的频率非常之高，但你真要问 Agent 是个撒？又没几个人说得清楚。
Agent 一词源自拉丁语 agere，本义是 “去做、去行动”。从概念上看，Agent 就是行动者，一个能主动发起动作、感知环境、围绕目标自主行动的实体。
放到专业领域，AI Agent（智能体） 就是把这种 “行动者能力” 赋予 AI 系统。
它不再是只会被动响应指令、给出答案的大模型，而是一个能自主感知、自主决策、自主执行的智能实体。 简单说：传统大模型擅长 “回答问题”，而 Agent 擅长 “完成任务”。
它可以理解你的目标，自动拆解步骤、规划路径、调用工具，一步步把事情真正做完：
只不过最近，我看见最为经典的图还是这张：
他其实更清晰的回答了 Agent 是什么，并且隐约表述了其发展规律：一场 Workflow 的复杂度的迁移，泛化能力极强的Workflow，或者说Agentic Workflow！
理解这句话，就理解了什么叫让AI自己去干活，其实 Agent 不过是模型使用范式其中一种罢了。
如何让 AI 做事
现在的大模型，像 gpt、qwen、deepseek 这些，它们学了很多公开知识，推理和逻辑能力很强，他们的核心执行逻辑是通过我们输入的内容，经过计算（推理）之后输出一个结果给我们。
以 DeepSeek 官方 API 调用为例：
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ.get('DEEPSEEK_API_KEY'),
base_url="https://api.deepseek.com")
response = client.chat.completions.create(
model="deepseek-chat",
messages=[
{"role": "system", "content": "You are a helpful assistant"},
{"role": "user", "content": "Hello"},
],
stream=False
)
print(response.choices[0].message.content)
从这个例子可以看到：
-
模型接收的 messages 包含系统提示和用户提问； -
模型最终只输出一段文字（content），然后就结束了；
也就是说，大模型本身不会执行任何实际操作，它只会“告诉你怎么做”，而不会“替你去做”。
那么，如何才能让 AI 真正完成一项任务呢？答案是：为 AI 提供执行任务所需的能力。
如果在没有 AI 的情况下也能完成这件事，那说明我们已经具备了相应的工具或函数。接下来，我们只需要把这些函数“告诉”AI，并引导它在需要时选择合适的函数。
下面我们就用开发一个旅游规划助手的智能体来举例。
开发 Agent
我们将通过开发一个 旅游规划助手 的智能体案例，来详细讲解如何让 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 的本质，循环实现了：
循环调用
把用户问题和系统提示词一起发送给 AI，AI 经过推理后，会按照提示词约定格式输出，我们需要在代码中解析json，获取参数来处理。
action 的值为 “call_tool” 时，则根据tool和parameters调用对应的函数，获取结果，然后将结果作为新的消息加入对话，再次请求模型。
action 的值为 “respond” 时，则将message展示给用户，结束对话：
下面是一个简化的 Python 伪代码示例：
import json
import openai
def 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_key=os.environ.get('DEEPSEEK_API_KEY'),
base_url="https://api.deepseek.com")
while True:
response = client.chat.completions.create(
model="deepseek-chat",
messages=messages,
stream=False
)
# 解析 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 ，看看它如何让智能体的开发更加规范。
Function Calling
Function 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 = "你是一位专业的旅游规划助手。
你的目标是根据用户的需求，
调用可用的工具获取信息，并整合成一份详尽的旅游行程建议。"
循环
我们需要循环与模型交互：如果模型返回需要调用工具，程序需要通过模型返回的工具名称和参数去执行工具的代码，将工具执行结果添加到提示词中，继续请求模型，如果模型返回不需要调用工具了，表示这是模型的最终回答，则输出给用户：
import openai
import 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, date=None):
# 实际场景中应调用天气 API
return f"{destination} 的天气晴朗，气温15-25℃，适合出行。"
其他的方法省略...
llm = OpenAI(
api_key=os.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(
messages=messages,
model="deepseek-chat",
stream=False,
tools=tools)
# 大模型输出的结果 有工具调用，说明模型思考后 需要调用工具
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 的方式构建了一个能够自主执行任务的旅行智能体。但是这个智能体还不是很完善：它无法记住用户对话历史。当用户完成一次问答后继续提问，比如“帮我把早上的景点换成更有深厚历史背景的景点”，模型会感到困惑，它并不清楚“早上的景点”指的是什么。
因为每一次模型请求调用都是独立的，模型只会根据当前输入的提示词生成回答，而不会主动回顾之前的调用记录。
要让模型拥有记住之前的历史记录，不能指望模型自己去查找历史，而是需要在工程层面手动保存每次对话的交互记录，并在下一次调用时，将完整的对话历史（包括之前的用户问题、模型回复、工具调用结果等）一并拼接到提示词中，作为上下文提供给模型。
只有这样，模型才能理解当前问题与过往对话的关联，从而给出合理的回答，毕竟模型能认识的也就只有提示词。
那么，如何为智能体添加记忆能力？我们将为旅行助手添加对话历史的存储与管理，让智能体真正具备持续对话的能力。
记忆能力
要让智能体真正拥有持续对话的能力，关键在于解决它的“记忆”问题，所谓记忆，指的是模型在当前输入之外，仍然能够访问和使用的信息集合。
这些信息可能来自历史对话、外部存储或系统内部状态，但核心目标只有一个：为当前推理提供必要的上下文补充。
构建记忆能力，我们需要解决三个核心问题：
-
记在哪里。存储机制，比如使用数据库还是内存。 -
怎么记住。写入策略，区分短期记忆与长期记忆。 -
怎么想起。检索机制，如何在需要时高效地找到相关信息。
针对这些问题，目前已经有多种记忆实现方式，它们各有侧重，适用于不同场景：
上下文记忆
这是最基础的记忆实现方式，做法最简单：将历史对话按照时间顺序原样拼接到当前的提示词中，一起发送给模型。模型通过阅读完整的对话历史来保持语义连贯性。
-
优点：实现成本低，适合原型验证或短对话场景。 -
缺点：受限于模型的Token上限，对话越长，成本越高；无法支持跨会话或长期记忆。 -
本质：这是一种短期、一次性的情景记忆。
滑动窗口记忆
滑动窗口记忆是在上下文记忆基础上的一种约束策略：只保留最近固定轮数的对话，其余内容直接丢弃。它主要解决的是 Token 成本控制问题，而非记忆能力的增强。
-
优点：有效控制提示词长度，降低开销。 -
缺点：一旦关键信息被滑出窗口，就会永久丢失。 -
适用场景：上下文有效期明确、业务流程较短的对话。 -
本质：可以理解为情景记忆的生命周期管理机制。
摘要记忆
摘要记忆通过调用模型对历史对话进行压缩，将大量情景信息提炼成一段简要描述，并在后续对话中使用该摘要替代原始内容。
-
优点：显著降低Token消耗，同时保留对话的整体脉络。 -
缺点：摘要过程不可避免会造成信息丢失，且质量高度依赖模型的总结能力。 -
适用场景：需要保留“整体脉络”但对精确细节要求不高的场景。 -
本质：将情景记忆转化为低精度的语义记忆。
向量记忆
向量记忆是一种长期记忆实现方式。将用户对话内容、用户偏好、经验知识向量化后存入向量数据库，在用户发起对话时，将用户的问题向量化，在数据库中查找出语义相似的内容。
-
优点：不受对话长度限制，支持跨会话长期记忆；能够基于语义匹配相关信息。 -
缺点：检索结果是“语义相似”而非“精确匹配”，实现复杂度较高。 -
适用场景：需要长期知识积累和个性化服务的智能体。 -
本质：当前Agent系统中最常见的语义记忆工程实现。
以上几种记忆方式并非互斥，实际应用中往往组合使用。例如，可以用滑动窗口保存短期上下文，用向量记忆存储长期用户偏好，再结合摘要记忆定期压缩历史。
记忆系统的实现
考虑难度与阅读，伪代码就好！
为了让智能体具备记忆能力，需要设计一个记忆管理系统，包含短期记忆和长期记忆两部分。下面给出简化版的伪代码，演示如何保存和查询记忆，并将查询结果拼接到提示词中：
短期记忆
短期记忆说白了就是记住用户刚说过什么。但咱不能无限记，毕竟大模型的上下文窗口就那么大点，塞太多不仅贵，还容易让模型“眼花缭乱”。
所以最常见的做法就是滑动窗口，只保留最近 N 轮对话，超出的直接丢掉。
为什么留最近几轮？因为用户刚刚聊的东西，大概率还热乎着呢，和当前问题最相关。那些陈年旧事，交给长期记忆去管。
代码实现上，Python 自带的 collections.deque 设个最大长度，新消息进来自动把老的挤出去，省心：
from collections import deque
class ShortTermMemory:
def __init__(self, max_messages=20):
"""
初始化短期记忆。
:param max_messages: 最多保留的消息条数（而非对话轮数）。每条消息对应一个 role（user/assistant/tool）。
"""
self.messages = deque(maxlen=max_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 np
from typing import List, Dict
class 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_messages=20, long_term_top_k=3):
self.short_term = ShortTermMemory(max_messages=short_term_max_messages)
self.long_term = LongTermMemory(embedding_model)
self.long_term_top_k = long_term_top_k
def 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_k=self.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}nn{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_model=embedding_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_base=system_base)
# 工具调用循环（同之前）
while True:
response = client.chat.completions.create(
model="deepseek-chat",
messages=messages,
tools=tools,
tool_choice="auto"
)
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}")
这个伪代码展示了记忆系统的核心架构，可以根据实际业务需求，选择合适的记忆存储和检索方案。
结语
今天为追求简单，连 MCP、Skills、ReAct 等都省了，只留下了最简单的概念！
怎么样，这次足够简单了吧！不可能看着吃力了吧？
没理由不会 Agent了 吧！
叶老师高产啊，牛逼😂