Hello-agent TASK01
要理解智能体的运作,我们必须先理解它所处的任务环境。在人工智能领域,通常使用PEAS模型来精确描述一个任务环境,即分析其性能度量(Performance)环境(Environment)执行器(Actuators)和传感器(Sensors)。以上文提到的智能旅行助手为例,下表1.2展示了如何运用PEAS模型对其任务环境进行规约。在实践中,LLM智能体所处的数字环境展现出若干复杂特性,这些特性直接影响
https://datawhalechina.github.io/hello-agents
在人工智能领域,智能体被定义为任何能够通过传感器(Sensors)感知其所处环境(Environment),并自主地通过执行器(Actuators)采取行动(Action)以达成特定目标的实体。
传统Agent:
- 反射智能体(Simple Reflex Agent)。它们的决策核心由工程师明确设计的“条件-动作”规则构成,如图1.2所示。经典的自动恒温器便是如此:若传感器感知的室温高于设定值,则启动制冷系统。
- 基于模型的反射智能体(Model-Based Reflex Agent)。这类智能体拥有一个内部的世界模型(World Model),用于追踪和理解环境中那些无法被直接感知的方面。例如,一辆在隧道中行驶的自动驾驶汽车,即便摄像头暂时无法感知到前方的车辆,它的内部模型依然会维持对那辆车存在、速度和预估位置的判断。这个内部模型让智能体拥有了初级的“记忆”,使其决策不再仅仅依赖于瞬时感知,而是基于一个更连贯、更完整的世界状态理解。
- 基于目标的智能体(Goal-Based Agent)的发展。与前两者不同,它的行为不再是被动地对环境做出反应,而是主动地、有预见性地选择能够导向某个特定未来状态的行动。这类智能体需要回答的问题是:“我应该做什么才能达成目标?”。经典的例子是GPS导航系统:你的目标是到达公司,智能体会基于地图数据(世界模型),通过搜索算法(如A*算法)来规划(Planning)出一条最优路径。这类智能体的核心能力体现在了对未来的考量与规划上。
- 基于效用的智能体(Utility-Based Agent)它为每一个可能的世界状态都赋予一个效用值,这个值代表了满意度的高低。智能体的核心目标不再是简单地达成某个特定状态,而是最大化期望效用。它需要回答一个更复杂的问题:“哪种行为能为我带来最满意的结果?”。这种架构让智能体学会在相互冲突的目标之间进行权衡,使其决策更接近人类的理性选择。
- 学习型智能体(Learning Agent)智能体能不依赖预设,而是通过与环境的互动自主学习。一个学习型智能体包含一个性能元件(即我们前面讨论的各类智能体)和一个学习元件。学习元件通过观察性能元件在环境中的行动所带来的结果来不断修正性能元件的决策策略。
大语言模型驱动的新范式
简而言之,传统智能体的能力源于工程师的显式编程与知识构建,其行为模式是确定且有边界的;而LLM智能体则通过在海量数据上的预训练,获得了隐式的世界模型与强大的涌现能力,使其能够以更灵活、更通用的方式应对复杂任务。

在LLM智能体出现之前,规划旅行通常意味着用户需要在多个专用应用(如天气、地图、预订网站)之间手动切换,并由用户自己扮演信息整合与决策的角色。而一个LLM智能体则能将这个流程整合起来。当接收到“规划一次厦门之旅”这样的模糊指令时,它的工作方式体现了以下几点:
- 规划与推理:智能体首先会将这个高层级目标分解为一系列逻辑子任务,例如:[确认出行偏好] -> [查询目的地信息] -> [制定行程草案] -> [预订票务住宿]。这是一个内在的、由模型驱动的规划过程。
- 工具使用:在执行规划时,智能体识别到信息缺口,会主动调用外部工具来补全。例如,它会调用天气查询接口获取实时天气,并基于“预报有雨”这一信息,在后续规划中倾向于推荐室内活动。
- 动态修正:在交互过程中,智能体会将用户的反馈(如“这家酒店超出预算”)视为新的约束,并据此调整后续的行动,重新搜索并推荐符合新要求的选项。整个“查天气 → 调行程 → 订酒店”的流程,展现了其根据上下文动态修正自身行为的能力
智能体类型
基于内部决策架构的分类
第一种分类维度是依据智能体内部决策架构的复杂程度,这个视角在《Artificial Intelligence: A Modern Approach》中系统性地提出[1]。正如 1.1.1 节所述,传统智能体的演进路径本身就构成了最经典的分类阶梯,它涵盖了从简单的反应式智能体,到引入内部模型的模型式智能体,再到更具前瞻性的基于目标和基于效用的智能体。此外,学习能力则是一种可赋予上述所有类型的元能力,使其能通过经验自我改进。
基于时间与反应性的分类
除了内部架构的复杂性,还可以从智能体处理决策的时间维度进行分类。这个视角关注智能体是在接收到信息后立即行动,还是会经过深思熟虑的规划再行动。这揭示了智能体设计中一个核心权衡:追求速度的**反应性(Reactivity)与追求最优解的规划性(Deliberation)**之间的平衡,如图1.3所示。

- 反应式智能体
这类智能体对环境刺激做出近乎即时的响应,决策延迟极低。它们通常遵循从感知到行动的直接映射,不进行或只进行极少的未来规划。上文的简单反应式和基于模型的智能体都属于此类别。
其核心优势在于速度快、计算开销低,这在需要快速决策的动态环境中至关重要。例如,车辆的安全气囊系统必须在碰撞发生的毫秒内做出反应,任何延迟都可能导致严重后果;同样,高频交易机器人也必须依赖反应式决策来捕捉稍纵即逝的市场机会。然而,这种速度的代价是“短视”,由于缺乏长远规划,反应式智能体容易陷入局部最优,难以完成需要多步骤协调的复杂任务。
- 规划式智能体(Deliberative Agents)
与反应式智能体相对,规划式(或称审议式)智能体在行动前会进行复杂的思考和规划。它们不会立即对感知做出反应,而是会先利用其内部的世界模型,系统地探索未来的各种可能性,评估不同行动序列的后果,以期找到一条能够达成目标的最佳路径 。基于目标和基于效用的智能体是典型的规划式智能体。
可以将其决策过程类比为一位棋手。他不会只看眼前的一步,而是会预想对手可能的应对,并规划出后续几步甚至十几步的棋路。这种深思熟虑的能力使其能够处理复杂的、需要长远眼光的任务,例如制定一份商业计划或规划一次长途旅行。它们的优势在于决策的战略性和远见。然而,这种优势的另一面是高昂的时间和计算成本。在瞬息万变的环境中,当规划式智能体还在深思熟虑时,采取行动的最佳时机可能早已过去。
混合式智能体(Hybrid Agents)
现实世界的复杂任务,往往既需要即时反应,也需要长远规划。例如,我们之前提到的智能旅行助手,既要能根据用户的即时反馈(如“这家酒店太贵了”)调整推荐(反应性),又要能规划出为期数天的完整旅行方案(规划性)。因此,混合式智能体应运而生,它旨在结合两者的优点,实现反应与规划的平衡。
一种经典的混合架构是分层设计:底层是一个快速的反应模块,处理紧急情况和基本动作;高层则是一个审慎的规划模块,负责制定长远目标。而现代的LLM智能体,则展现了一种更灵活的混合模式。它们通常在一个“思考-行动-观察”的循环中运作,巧妙地将两种模式融为一体:
- 规划(Reasoning) :在“思考”阶段,LLM分析当前状况,规划出下一步的合理行动。这是一个审议过程。
- 反应(Acting & Observing) :在“行动”和“观察”阶段,智能体与外部工具或环境交互,并立即获得反馈。这是一个反应过程。
通过这种方式,智能体将一个需要长远规划的宏大任务,分解为一系列“规划-反应”的微循环。这使其既能灵活应对环境的即时变化,又能通过连贯的步骤,最终完成复杂的长期目标。
基于知识表示的分类
- 符号主义AI(Symbolic AI)
符号主义,常被称为传统人工智能,其核心信念是:智能源于对符号的逻辑操作。这里的符号是人类可读的实体(如词语、概念),操作则遵循严格的逻辑规则。
其主要优势在于透明和可解释。由于推理步骤明确,其决策过程可以被完整追溯,这在金融、医疗等高风险领域至关重要。然而,其“阿喀琉斯之踵”在于脆弱性:它依赖于一个完备的规则体系,但在充满模糊和例外的现实世界中,任何未被覆盖的新情况都可能导致系统失灵,这就是所谓的“知识获取瓶颈”。
-
亚符号主义AI(Sub-symbolic AI)
亚符号主义,或称连接主义,则提供了一幅截然不同的图景。在这里,知识并非显式的规则,而是内隐地分布在一个由大量神经元组成的复杂网络中,是从海量数据中学习到的统计模式。神经网络和深度学习是其代表。 -
神经符号主义AI(Neuro-Symbolic AI)
神经符号混合主义。它的目标,是融合两大范式的优点,创造出一个既能像神经网络一样从数据中学习,又能像符号系统一样进行逻辑推理的混合智能体。
它试图弥合感知与认知、直觉与理性之间的鸿沟。诺贝尔经济学奖得主丹尼尔·卡尼曼(Daniel Kahneman)在其著作《思考,快与慢》(Thinking, Fast and Slow)中提出的双系统理论,为我们理解神经符号主义提供了一个绝佳的类比[2]
- 系统1是快速、凭直觉、并行的思维模式,类似于亚符号主义AI强大的模式识别能力。
- 系统2是缓慢、有条理、基于逻辑的审慎思维,恰如符号主义AI的推理过程。

智能体的构成与运行原理
任务环境定义
要理解智能体的运作,我们必须先理解它所处的任务环境。在人工智能领域,通常使用PEAS模型来精确描述一个任务环境,即分析其性能度量(Performance)、环境(Environment)、执行器(Actuators)和传感器(Sensors) 。以上文提到的智能旅行助手为例,下表1.2展示了如何运用PEAS模型对其任务环境进行规约。
在实践中,LLM智能体所处的数字环境展现出若干复杂特性,这些特性直接影响着智能体的设计。
【记忆和探索能力】首先,环境通常是部分可观察的。例如,旅行助手在查询航班时,无法一次性获取所有航空公司的全部实时座位信息。它只能通过调用航班预订API,看到该API返回的部分数据,这就要求智能体必须具备记忆(记住已查询过的航线)和探索(尝试不同的查询日期)的能力。
【结果】其次,行动的结果也并非总是确定的。根据结果的可预测性,环境可分为确定性和随机性。旅行助手的任务环境就是典型的随机性环境。当它搜索票价时,两次相邻的调用返回的机票价格和余票数量都可能不同,这就要求智能体必须具备处理不确定性、监控变化并及时决策的能力。
【多智能体】此外,环境中还可能存在其他行动者,从而形成多智能体(Multi-agent) 环境。对于旅行助手而言,其他用户的预订行为、其他自动化脚本,甚至航司的动态调价系统,都是环境中的其他“智能体”。它们的行动(例如,订走最后一张特价票)会直接改变旅行助手所处环境的状态,这对智能体的快速响应和策略选择提出了更高要求。
最后,几乎所有任务都发生在序贯且动态的环境中。“序贯”意味着当前动作会影响未来;而“动态”则意味着环境自身可能在智能体决策时发生变化。这就要求智能体的“感知-思考-行动-观察”循环必须能够快速、灵活地适应持续变化的世界。
智能体的运行机制
智能体并非一次性完成任务,而是通过一个持续的循环与环境进行交互,这个核心机制被称为 智能体循环 (Agent Loop)。
该循环描述了智能体与环境之间的动态交互过程,构成了其自主行为的基础。
- 感知 (Perception):这是循环的起点。智能体通过其传感器(例如,API的监听端口、用户输入接口)接收来自环境的输入信息。这些信息,即观察 (Observation),既可以是用户的初始指令,也可以是上一步行动所导致的环境状态变化反馈。
- 思考 (Thought):接收到观察信息后,智能体进入其核心决策阶段。对于LLM智能体而言,这通常是由大语言模型驱动的内部推理过程。如图所示,“思考”阶段可进一步细分为两个关键环节:
- 规划 (Planning):智能体基于当前的观察和其内部记忆,更新对任务和环境的理解,并制定或调整一个行动计划。这可能涉及将复杂目标分解为一系列更具体的子任务。
- 工具选择 (Tool Selection):根据当前计划,智能体从其可用的工具库中,选择最适合执行下一步骤的工具,并确定调用该工具所需的具体参数。
- 行动 (Action):决策完成后,智能体通过其执行器(Actuators)执行具体的行动。这通常表现为调用一个选定的工具(如代码解释器、搜索引擎API),从而对环境施加影响,意图改变环境的状态。
行动并非循环的终点。智能体的行动会引起环境 (Environment) 的状态变化 (State Change),环境随即会产生一个新的观察 (Observation) 作为结果反馈。这个新的观察又会在下一轮循环中被智能体的感知系统捕获,形成一个持续的“感知-思考-行动-观察”的闭环。智能体正是通过不断重复这一循环,逐步推进任务,从初始状态向目标状态演进。
智能体的感知与行动
为了让LLM能够有效驱动这个循环,我们需要一套明确的交互协议 (Interaction Protocol) 来规范其与环境之间的信息交换。
在许多现代智能体框架中,这一协议体现在对智能体每一次输出的结构化定义上。智能体的输出不再是单一的自然语言回复,而是一段遵循特定格式的文本,其中明确地展示了其内部的推理过程与最终决策。
这个结构通常包含两个核心部分:
- Thought (思考):这是智能体内部决策的“快照”。它以自然语言形式阐述了智能体如何分析当前情境、回顾上一步的观察结果、进行自我反思与问题分解,并最终规划出下一步的具体行动。
- Action (行动):这是智能体基于思考后,决定对环境施加的具体操作,通常以函数调用的形式表示。
例如,一个正在规划旅行的智能体可能会生成如下格式化的输出:
Thought: 用户想知道北京的天气。我需要调用天气查询工具。
Action: get_weather("北京")
这里的Action字段构成了对外部世界的指令。一个外部的解析器 (Parser) 会捕捉到这个指令,并调用相应的get_weather函数。
行动执行后,环境会返回一个结果。例如,get_weather函数可能返回一个包含详细天气数据的JSON对象。然而,原始的机器可读数据(如JSON)通常包含LLM无需关注的冗余信息,且格式不符合其自然语言处理的习惯。
因此,感知系统的一个重要职责就是扮演传感器的角色:将这个原始输出处理并封装成一段简洁、清晰的自然语言文本,即观察。
Observation: 北京当前天气为晴,气温25摄氏度,微风。
这段Observation文本会被反馈给智能体,作为下一轮循环的主要输入信息,供其进行新一轮的Thought和Action。
综上所述,通过这个由Thought、Action、Observation构成的严谨循环,LLM智能体得以将内部的语言推理能力,与外部环境的真实信息和工具操作能力有效地结合起来。
动手体验:5 分钟实现第一个智能体
在前面的小节,我们学习了智能体的任务环境、核心运行机制以及Thought-Action-Observation交互范式。理论知识固然重要,但最好的学习方式是亲手实践。在本节中,我们将引导您使用几行简单的Python代码,从零开始构建一个可以工作的智能旅行助手。这个过程将遵循我们刚刚学到的理论循环,让您直观地感受到一个智能体是如何“思考”并与外部“工具”互动的。让我们开始吧!
在本案例中,我们的目标是构建一个能处理分步任务的智能旅行助手。需要解决的用户任务定义为:"你好,请帮我查询一下今天北京的天气,然后根据天气推荐一个合适的旅游景点。"要完成这个任务,智能体必须展现出清晰的逻辑规划能力。它需要先调用天气查询工具,并将获得的观察结果作为下一步的依据。在下一轮循环中,它再调用景点推荐工具,从而得出最终建议。
准备工作
- request 访问网络API
- tavily-pthon AI搜索API客户端,用于实时获取网络搜索结果。可以在官网注册后获取API。
- openai是OpenAi官方提供的Python SDK 用于调用GPT等大语言模型服务。
pip install requests tavily-python openai
1) 指令模板
驱动真实LLM的关键在于提示工程(Prompt Engineering)。我们需要设计一个“指令模板”,告诉LLM它应该扮演什么角色、拥有哪些工具、以及如何格式化它的思考和行动。这是我们智能体的“说明书”,它将作为system_prompt传递给LLM。
AGENT_SYSTEM_PROMPT = """
你是一个智能旅行助手。你的任务是分析用户的请求,并使用可用工具一步步地解决问题。
# 可用工具:
- `get_weather(city: str)`: 查询指定城市的实时天气。
- `get_attraction(city: str, weather: str)`: 根据城市和天气搜索推荐的旅游景点。
# 行动格式:
你的回答必须严格遵循以下格式。首先是你的思考过程,然后是你要执行的具体行动。
Thought: [这里是你的思考过程和下一步计划]
Action: [这里是你要调用的工具,格式为 function_name(arg_name="arg_value")]
# 任务完成:
当你收集到足够的信息,能够回答用户的最终问题时,你必须使用 `finish(answer="...")` 来输出最终答案。
请开始吧!
"""
2)工具1:查询真实天气
我们将使用免费的天气查询服务wttr.in,它能以JSON格式返回指定城市的天气数据。下面是实现该工具的代码:
import requests
import json
def get_weather(city: str) -> str:
"""
通过调用 wttr.in API 查询真实的天气信息。
"""
# API端点,我们请求JSON格式的数据
url = f"https://wttr.in/{city}?format=j1"
try:
# 发起网络请求
response = requests.get(url)
# 检查响应状态码是否为200 (成功)
response.raise_for_status()
# 解析返回的JSON数据
data = response.json()
# 提取当前天气状况
current_condition = data['current_condition'][0]
weather_desc = current_condition['weatherDesc'][0]['value']
temp_c = current_condition['temp_C']
# 格式化成自然语言返回
returnf"{city}当前天气:{weather_desc},气温{temp_c}摄氏度"
except requests.exceptions.RequestException as e:
# 处理网络错误
returnf"错误:查询天气时遇到网络问题 - {e}"
except (KeyError, IndexError) as e:
# 处理数据解析错误
returnf"错误:解析天气数据失败,可能是城市名称无效 - {e}"
3) 工具2:搜索并推荐旅游景点
我们将定义一个新工具search_attraction,它会根据城市和天气状况,互联网上搜索合适的景点:
import os
from tavily import TavilyClient
def get_attraction(city: str, weather: str) -> str:
"""
根据城市和天气,使用Tavily Search API搜索并返回优化后的景点推荐。
"""
# 1. 从环境变量中读取API密钥
api_key = os.environ.get("TAVILY_API_KEY")
ifnot api_key:
return"错误:未配置TAVILY_API_KEY环境变量。"
# 2. 初始化Tavily客户端
tavily = TavilyClient(api_key=api_key)
# 3. 构造一个精确的查询
query = f"'{city}' 在'{weather}'天气下最值得去的旅游景点推荐及理由"
try:
# 4. 调用API,include_answer=True会返回一个综合性的回答
response = tavily.search(query=query, search_depth="basic", include_answer=True)
# 5. Tavily返回的结果已经非常干净,可以直接使用
# response['answer'] 是一个基于所有搜索结果的总结性回答
if response.get("answer"):
return response["answer"]
# 如果没有综合性回答,则格式化原始结果
formatted_results = []
for result in response.get("results", []):
formatted_results.append(f"- {result['title']}: {result['content']}")
ifnot formatted_results:
return"抱歉,没有找到相关的旅游景点推荐。"
return"根据搜索,为您找到以下信息:\n" + "\n".join(formatted_results)
except Exception as e:
returnf"错误:执行Tavily搜索时出现问题 - {e}"
最后,我们将所有工具函数放入一个字典,供主循环调用:
# 将所有工具函数放入一个字典,方便后续调用
available_tools = {
"get_weather": get_weather,
"get_attraction": get_attraction,
}
接入大语言模型
当前,许多LLM服务提供商(包括OpenAI、Azure、以及众多开源模型服务框架如Ollama、vLLM等)都遵循了与OpenAI API相似的接口规范。这种标准化为开发者带来了极大的便利。智能体的自主决策能力来源于LLM。我们将实现一个通用的客户端OpenAICompatibleClient,它可以连接到任何兼容OpenAI接口规范的LLM服务。
from openai import OpenAI
classOpenAICompatibleClient:
"""
一个用于调用任何兼容OpenAI接口的LLM服务的客户端。
"""
def __init__(self, model: str, api_key: str, base_url: str):
self.model = model
self.client = OpenAI(api_key=api_key, base_url=base_url)
def generate(self, prompt: str, system_prompt: str) -> str:
"""调用LLM API来生成回应。"""
print("正在调用大语言模型...")
try:
messages = [
{'role': 'system', 'content': system_prompt},
{'role': 'user', 'content': prompt}
]
response = self.client.chat.completions.create(
model=self.model,
messages=messages,
stream=False
)
answer = response.choices[0].message.content
print("大语言模型响应成功。")
return answer
except Exception as e:
print(f"调用LLM API时发生错误: {e}")
return"错误:调用语言模型服务时出错。"
要实例化此类,您需要提供三个信息:API_KEY、BASE_URL和 MODEL_ID,具体值取决于您使用的服务商(如OpenAI官方、Azure、或Ollama等本地模型),如果暂时没有渠道获取,可以参考Datawhale另一本教程的1.2 API设置。
执行行动循环
下面的主循环将整合所有组件,并通过格式化后的Prompt驱动LLM进行决策。
import re
# --- 1. 配置LLM客户端 ---
# 请根据您使用的服务,将这里替换成对应的凭证和地址
API_KEY = "YOUR_API_KEY"
BASE_URL = "YOUR_BASE_URL"
MODEL_ID = "YOUR_MODEL_ID"
TAVILY_API_KEY="YOUR_Tavily_KEY"
os.environ['TAVILY_API_KEY'] = "YOUR_TAVILY_API_KEY"
llm = OpenAICompatibleClient(
model=MODEL_ID,
api_key=API_KEY,
base_url=BASE_URL
)
# --- 2. 初始化 ---
user_prompt = "你好,请帮我查询一下今天北京的天气,然后根据天气推荐一个合适的旅游景点。"
prompt_history = [f"用户请求: {user_prompt}"]
print(f"用户输入: {user_prompt}\n" + "="*40)
# --- 3. 运行主循环 ---
for i in range(5): # 设置最大循环次数
print(f"--- 循环 {i+1} ---\n")
# 3.1. 构建Prompt
full_prompt = "\n".join(prompt_history)
# 3.2. 调用LLM进行思考
llm_output = llm.generate(full_prompt, system_prompt=AGENT_SYSTEM_PROMPT)
print(f"模型输出:\n{llm_output}\n")
prompt_history.append(llm_output)
# 3.3. 解析并执行行动
action_match = re.search(r"Action: (.*)", llm_output, re.DOTALL)
ifnot action_match:
print("解析错误:模型输出中未找到 Action。")
break
action_str = action_match.group(1).strip()
if action_str.startswith("finish"):
final_answer = re.search(r'finish\(answer="(.*)"\)', action_str).group(1)
print(f"任务完成,最终答案: {final_answer}")
break
tool_name = re.search(r"(\w+)\(", action_str).group(1)
args_str = re.search(r"\((.*)\)", action_str).group(1)
kwargs = dict(re.findall(r'(\w+)="([^"]*)"', args_str))
if tool_name in available_tools:
observation = available_tools[tool_name](**kwargs)
else:
observation = f"错误:未定义的工具 '{tool_name}'"
# 3.4. 记录观察结果
observation_str = f"Observation: {observation}"
print(f"{observation_str}\n" + "="*40)
prompt_history.append(observation_str)
通过以上步骤,我们构建了一个完整的、由真实LLM驱动的智能体。其核心在于“工具”和“提示工程”的结合,这正是当前主流智能体框架(如LangChain、LlamaIndex等)的设计精髓。
运行案例分析
以下输出完整地展示了一个成功的智能体执行流程。通过对这个三轮循环的分析,我们可以清晰地看到智能体解决问题的核心能力。
用户输入: 你好,请帮我查询一下今天北京的天气,然后根据天气推荐一个合适的旅游景点。
========================================
--- 循环 1 ---
正在调用大语言模型...
大语言模型响应成功。
模型输出:
Thought: 首先需要获取北京今天的天气情况,之后再根据天气情况来推荐旅游景点。
Action: get_weather(city="北京")
Observation: 北京当前天气:Sunny,气温26摄氏度
========================================
--- 循环 2 ---
正在调用大语言模型...
大语言模型响应成功。
模型输出:
Thought: 现在已经知道了北京今天的天气是晴朗且温度适中,接下来可以基于这个信息来推荐一个适合的旅游景点了。
Action: get_attraction(city="北京", weather="Sunny")
Observation: 北京在晴天最值得去的旅游景点是颐和园,因其美丽的湖景和古建筑。另一个推荐是长城,因其壮观的景观和历史意义。
========================================
--- 循环 3 ---
正在调用大语言模型...
大语言模型响应成功。
模型输出:
Thought: 已经获得了两个适合晴天游览的景点建议,现在可以根据这些信息给用户提供满意的答复。
Action: finish(answer="今天北京的天气是晴朗的,气温26摄氏度,非常适合外出游玩。我推荐您去颐和园欣赏美丽的湖景和古建筑,或者前往长城体验其壮观的景观和深厚的历史意义。希望您有一个愉快的旅行!
")
任务完成,最终答案: 今天北京的天气是晴朗的,气温26摄氏度,非常适合外出游玩。我推荐您去颐和园欣赏美丽的湖景和古建筑,或者前往长城体验其壮观的景观和深厚的历史意义。希望您有一个愉快的旅行!
这个简单的旅行助手案例,集中演示了基于Thought-Action-Observation范式的智能体所具备的四项基本能力:任务分解、工具调用、上下文理解和结果合成。正是通过这个循环的不断迭代,智能体才得以将一个模糊的用户意图,转化为一系列具体、可执行的步骤,并最终达成目标。
智能体应用的协作模式
上一节,我们通过亲手构建一个智能体,深入理解了其内部的运作循环。不过在更广泛的应用场景中,我们的角色正越来越多地转变为使用者与协作者。基于智能体在任务中的角色和自主性程度,其协作模式主要分为两种:一种是作为高效工具,深度融入我们的工作流;另一种则是作为自主的协作者,与其他智能体协作完成复杂目标。
作为开发者工具的智能体
在这种模式下,智能体被深度集成到开发者的工作流中,作为一种强大的辅助工具。它增强而非取代开发者的角色,通过自动化处理繁琐、重复的任务,让开发者能更专注于创造性的核心工作。这种人机协同的方式,极大地提升了软件开发的效率与质量。
目前,市场上涌现了多款优秀的AI编程辅助工具,它们虽然均能提升开发效率,但在实现路径和功能侧重上各有千秋:
- GitHubCopilot: 作为该领域最具影响力的产品之一,Copilot 由 GitHub 与 OpenAI 联合开发。它深度集成于 Visual Studio Code等主流编辑器中,以其强大的代码自动补全能力而闻名。开发者在编写代码时,Copilot 能实时提供整行甚至整个函数块的建议。近年来,它也通过 Copilot Chat 扩展了对话式编程的能力,允许开发者在编辑器内通过聊天解决编程问题。
- Claude Code: Claude Code 是由 Anthropic 开发的 AI 编程助手,旨在通过自然语言指令帮助开发者在终端中高效地完成编码任务。它能够理解完整的代码库结构,执行代码编辑、测试和调试等操作,支持从描述功能到代码实现的全流程开发。Claude Code 还提供了无交互(headless)模式,适用于 CI、pre-commit hooks、构建脚本和其他自动化场景,为开发者提供了强大的命令行编程体验。
- Trae: 作为新兴的 AI 编程工具,Trae 专注于为开发者提供智能化的代码生成和优化服务。它通过深度学习技术分析代码模式,能够为开发者提供精准的代码建议和自动化重构方案。Trae 的特色在于其轻量级的设计和快速响应能力,特别适合需要频繁迭代和快速原型开发的场景。
- Cursor: 与上述主要作为插件或集成功能存在的工具不同,Cursor 则选择了一条更具整合性的路径,它本身就是一个AI原生的代码编辑器。它并非在现有编辑器上增加AI功能,而是在设计之初就将AI交互作为核心。除了具备顶级的代码生成和聊天能力外,它更强调让AI理解整个代码库的上下文,从而实现更深层次的问答、重构和调试。
作为自主协作者的智能体
与作为工具辅助人类不同,第二种交互模式将智能体的自动化程度提升到了一个全新的层次,自主协作者。在这种模式下,我们不再是手把手地指导AI完成每一步,而是将一个高层级的目标委托给它。智能体会像一个真正的项目成员一样,独立地进行规划、推理、执行和反思,直到最终交付成果。这种从助手到协作者的转变,使得LLM智能体更深的进入了大众的视野。它标志着我们与AI的关系从“命令-执行”演变为“目标-委托”。智能体不再是被动的工具,而是主动的目标追求者。
当前,实现这种自主协作的思路百花齐放,涌现了大量优秀的框架和产品,从早期的 BabyAGI、AutoGPT,到如今更为成熟的 CrewAI、AutoGen、MetaGPT、LangGraph 等优秀框架,共同推动着这一领域的高速发展。虽然具体实现千差万别,但它们的架构范式大致可以归纳为几个主流方向:
- 单智能体自主循环:这是早期的典型范式,如 AgentGPT 所代表的模式。其核心是一个通用智能体通过“思考-规划-执行-反思”的闭环,不断进行自我提示和迭代,以完成一个开放式的高层级目标。
- 多智能体协作:这是当前最主流的探索方向,旨在通过模拟人类团队的协作模式来解决复杂问题。它又可细分为不同模式: 角色扮演式对话:如 CAMEL 框架,通过为两个智能体(例如,“程序员”和“产品经理”)设定明确的角色和沟通协议,让它们在一个结构化的对话中协同完成任务。 组织化工作流:如 MetaGPT 和 CrewAI,它们模拟一个分工明确的“虚拟团队”(如软件公司或咨询小组)。每个智能体都有预设的职责和工作流程(SOP),通过层级化或顺序化的方式协作,产出高质量的复杂成果(如完整的代码库或研究报告)。AutoGen 和 AgentScope 则提供了更灵活的对话模式,允许开发者自定义智能体间的复杂交互网络。
- 高级控制流架构:诸如 LangGraph 等框架,则更侧重于为智能体提供更强大的底层工程基础。它将智能体的执行过程建模为状态图(State Graph),从而能更灵活、更可靠地实现循环、分支、回溯以及人工介入等复杂流程。
这些不同的架构范式,共同推动着自主智能体从理论构想走向更广泛的实际应用,使其有能力应对日益复杂的真实世界任务。在我们的后续章节中,也会感受不同类型框架之间的差异和优势。
Workflow和Agent的差异
在理解了智能体作为“工具”和“协作者”两种模式后,我们有必要对Workflow和Agent的差异展开讨论,尽管它们都旨在实现任务自动化,但其底层逻辑、核心特征和适用场景却截然不同。
简单来说,Workflow 是让 AI 按部就班地执行指令,而 Agent 则是赋予 AI 自由度去自主达成目标。

工作流是一种传统的自动化范式,其核心是对一系列任务或步骤进行预先定义的、结构化的编排。它本质上是一个精确的、静态的流程图,规定了在何种条件下、以何种顺序执行哪些操作。一个典型的案例:某企业的费用报销审批流程。员工提交报销单(触发)-> 如果金额小于500元,直接由部门经理审批 -> 如果金额大于500元,先由部门经理审批,再流转至财务总监审批 -> 审批通过后,通知财务部打款。整个过程的每一步、每一个判断条件都被精确地预先设定。
火山引擎开发者社区是火山引擎打造的AI技术生态平台,聚焦Agent与大模型开发,提供豆包系列模型(图像/视频/视觉)、智能分析与会话工具,并配套评测集、动手实验室及行业案例库。社区通过技术沙龙、挑战赛等活动促进开发者成长,新用户可领50万Tokens权益,助力构建智能应用。
更多推荐



所有评论(0)