AI Agent 深度解析：基于 generative-ai-for-beginners 课程理解五大 Agent 框架与实战构建

本篇技术文章基于 generative-ai-for-beginners 课程的第 17 课 AI Agents，系统讲解 AI Agent 的核心概念（LLM + 状态 + 工具）以及 LangChain Agents、AutoGen、Microsoft Agent Framework、Taskweaver、JARVIS 五大主流框架的设计思想、状态管理方式与工具接入机制，并给出可直接运行的 Python 代码示例与实战练习，帮助读者从"调用 LLM 补全文本"进阶到"让 LLM 自主规划并执行任务"。

什么是 AI Agent

AI Agent 是生成式 AI 领域中一个令人兴奋的进展：它使大语言模型（LLM）从单纯的"助手"进化为能够采取行动的"智能体"。Agent 框架为开发者提供了让 LLM 访问工具（tools）和状态管理（state）的应用能力，同时增强了可见性——用户和开发者可以监控 LLM 计划执行的动作，从而更好地管理交互体验。

由于该领域术语繁多、容易混淆，本课程采用了一个简洁且能涵盖大多数工具的定义：

AI Agent 通过为大语言模型（LLM）提供"状态（state）"和"工具（tools）"的访问权限，使其能够执行任务。

三个核心术语拆解如下：

• 大语言模型（LLM）：即本课程贯穿始终提到的 GPT-3.5、GPT-4、Llama-2 等模型，是 Agent 的"大脑"。
• 状态（State）：指 LLM 工作的上下文（context）。LLM 会基于过去的动作历史与当前上下文来指导后续决策。Agent 框架的价值之一，就是让开发者更容易地维护这份上下文。
• 工具（Tools）：为完成用户请求、执行 LLM 规划出的任务，LLM 需要访问工具。工具可以是数据库、API、外部应用，甚至是另一个 LLM。

从上面配图可以看出，LLM 负责"推理该用哪个工具"，State 负责维护"过去与现在的上下文及结果"，Tools 则指向数据库、API、另一个 Agent 等外部系统，三者构成闭环：工具执行结果会写回状态，状态又反过来影响下一次工具选择。

五大 Agent 框架总览

框架	核心关注点	状态管理方式	工具形态
LangChain Agents	通用 Agent 执行与可观测性	AgentExecutor 内置聊天历史	社区工具目录，导入即用
AutoGen	多 Agent 对话	Assistant Agent 生成 Python 代码管理状态	函数调用 + UserProxyAgent
Microsoft Agent Framework	单 Agent 到多 Agent 工作流	线程（threads）维护消息历史	带类型注解的 Python 函数、MCP
Taskweaver	"代码优先"的数据分析 Agent	Planner 拆解任务 + experience 长期记忆	Plugins（Python 类/代码解释器），以嵌入方式检索
JARVIS	LLM 编排多个专用 AI 模型	LLM 本身管理对话状态	专用模型（目标检测、转写、图像描述等）

LangChain Agents：AgentExecutor 与工具目录

LangChain Agents 是上述定义的典型实现。它以两种方式满足 Agent 的两个核心要素：

1. 状态管理：使用内置的 AgentExecutor 函数，它接收一个已定义的 agent 和该 Agent 可使用的 tools 列表。AgentExecutor 同时保存聊天历史，为后续对话提供上下文。
2. 工具接入：LangChain 提供了一个工具目录（由社区和 LangChain 团队共同维护），可以导入到你的应用中供 LLM 访问，然后你只需定义这些工具并传递给 AgentExecutor 即可。

关于可观测性（visibility）：对应用开发者而言，理解"LLM 正在用哪个工具、为什么用"至关重要。LangChain 团队为此开发了 LangSmith 来提供这种可见性，这也是评估 Agent 框架时值得关注的维度——当 Agent 行为出错时，你需要能追溯到具体是哪一步的工具选择出了问题。

AutoGen：以"对话"为核心的 Agent 框架

AutoGen 的主打方向是对话（conversations）。其 Agent 同时具备两个特性：

• 可对话（Conversable）：LLM 之间可以发起并维持对话以完成任务。通过创建 AssistantAgent 并赋予其特定的系统消息（system message）来实现。
• 可定制（Customizable）：Agent 不仅是 LLM，还可以是用户或工具。开发者可以定义 UserProxyAgent，负责与用户交互获取反馈；反馈既可以让任务继续执行，也可以让它停止。

autogen.AssistantAgent(name="Coder", llm_config=llm_config)
pm = autogen.AssistantAgent(
    name="Product_manager",
    system_message="Creative in software product ideas.",
    llm_config=llm_config,
)

user_proxy = UserProxyAgent(name="user_proxy")

AutoGen 的状态与工具执行流程

在 AutoGen 中，Assistant Agent 通过生成并运行 Python 代码来改变和管理状态。整个流程分为四步：

第一步：用系统消息定义 LLM 的职责边界

system_message="For weather related tasks, only use the functions you have been provided with. Reply TERMINATE when the task is done."

这条系统消息告诉该 LLM 哪些函数与它的任务相关、以及何时终止。注意 AutoGen 允许同时定义多个 AssistantAgent，各自携带不同的系统消息，从而实现"分工"。

第二步：用户发起对话

user_proxy.initiate_chat(
    chatbot,
    message="I am planning a trip to NYC next week, can you help me pick out what to wear?"
)

来自 user_proxy（人类）的这条消息启动了 Agent 探索"应执行哪些函数"的过程。

第三步：函数被执行

chatbot (to user_proxy):

***** Suggested tool Call: get_weather *****
Arguments: {"location":"New York City, NY","time_period":"7","temperature_unit":"Celsius"}
--------------------------------------------------------------------------------

>>>>>>>> EXECUTING FUNCTION get_weather...
user_proxy (to chatbot): ***** Response from calling function "get_weather" *****
112.22727272727272 EUR

初始对话被处理后，Agent 会发出"建议的工具调用"——本例中是 get_weather 函数。根据你的配置，该函数可以被 Agent 自动执行并读取结果，也可以等待用户输入后再执行。这正是 Agent 框架中"人工介入点（human-in-the-loop）"的体现。

Microsoft Agent Framework：单 Agent 到多 Agent 工作流

Microsoft Agent Framework 是微软开源的构建 AI Agent 与多 Agent 系统的 SDK，同时支持 Python 和 .NET。它将 Semantic Kernel 的企业级能力与 AutoGen 的多 Agent 编排能力整合为单一受支持的框架，是当前新 Agent 项目的推荐起点。框架可以从单个聊天 Agent 扩展到复杂的多 Agent 工作流，并通过 OpenTelemetry 提供内建的可观测性，让你能追踪 Agent 的每一步行为。

状态（State）与工具（Tools）

• 状态：框架通过**线程（threads）**管理对话上下文。Agent 会自动跟踪消息历史（用户请求、工具调用及其结果），每一轮都建立在上一轮之上；线程还可以持久化，使对话能够暂停并在之后恢复。
• 工具：通过传入普通的 Python 函数来赋予 Agent 工具。带类型注解的参数会被自动转换为 schema（函数调用机制），让模型知道何时以及如何调用工具；框架还支持 Model Context Protocol（MCP）服务器和托管工具（如代码解释器）。

下面是一个带自定义工具的单 Agent 完整示例：

import asyncio
from typing import Annotated

from pydantic import Field
from agent_framework import Agent
from agent_framework.openai import OpenAIChatClient


def get_weather(
    location: Annotated[str, Field(description="The location to get the weather for.")],
) -> str:
    """Get the weather for a given location."""
    return f"The weather in {location} is sunny with a high of 22°C."


async def main():
    agent = Agent(
        client=OpenAIChatClient(),
        instructions="You are a helpful assistant that can answer weather questions.",
        tools=[get_weather],
    )

    response = await agent.run("What's the weather in Amsterdam?")
    print(response)


asyncio.run(main())

这里值得注意的细节是 Annotated[str, Field(description=...)]：Field 中的描述会进入自动生成的工具 schema，直接影响模型对工具用途的理解——这与第 11 课 函数调用中"响应格式一致性"的思想一脉相承：工具 schema 定义得越精确，Agent 的工具选择与参数填充越可靠。

若要连接 Azure OpenAI（Microsoft Foundry）而非标准 OpenAI，只需向客户端传入端点与凭据：

from azure.identity.aio import AzureCliCredential
from agent_framework.openai import OpenAIChatClient

client = OpenAIChatClient(
    model="my-gpt-4o-deployment",
    azure_endpoint="https://my-resource.openai.azure.com",
    credential=AzureCliCredential(),
)

多 Agent 工作流

该框架的突出能力是编排多个 Agent 协同工作，支持两种典型模式：

from agent_framework.orchestrations import SequentialBuilder, ConcurrentBuilder

# 顺序执行：每个 Agent 将上下文传递给下一个（如 研究 -> 写作 -> 编辑）
sequential = SequentialBuilder(participants=[researcher, writer, editor]).build()

# 并行扇出：同时调用多个 Agent，再聚合结果
concurrent = ConcurrentBuilder(participants=[analyst_a, analyst_b, analyst_c]).build()

安装与依赖：

pip install agent-framework-core
# 可选集成
pip install agent-framework-openai       # OpenAI 与 Azure OpenAI
pip install agent-framework-foundry      # Microsoft Foundry

Taskweaver："代码优先"的数据分析 Agent

Taskweaver 被称为"code-first"（代码优先）Agent：与严格处理字符串不同，它能直接在 Python 中操作 DataFrames。这在数据分析与数据生成任务中极其实用——例如创建图表、生成随机数等。

Planner 与 Plugins

• 状态管理：Taskweaver 使用 Planner（规划器）概念。Planner 是一个 LLM，负责接收用户请求，规划出完成该请求所需执行的任务序列。
• 工具：Planner 暴露给一组称为 Plugins（插件）的工具集合，插件可以是 Python 类或通用代码解释器。插件以嵌入（embeddings）形式存储，便于 LLM 检索到正确的插件——这与第 15 课 RAG 与向量数据库中"用嵌入做检索"的思路同源，只是这里检索的对象是工具而非文档。

一个处理异常检测的插件示例：

class AnomalyDetectionPlugin(Plugin):
    def __call__(self, df: pd.DataFrame, time_col_name: str, value_col_name: str):
        ...

Taskweaver 还有两个重要的工程细节：

1. 代码先验证后执行：生成的代码在执行前会经过验证，降低直接执行 LLM 生成代码的风险。
2. experience 长期记忆：Taskweaver 通过 experience 机制将对话上下文长期保存到 YAML 文件中，可配置为让 LLM 基于历史对话在特定任务上随时间推移不断改进。这是"状态"概念从"会话内上下文"扩展到"跨会话长期记忆"的典型设计。

JARVIS：用 LLM 编排专用 AI 模型

JARVIS 的独特之处在于：它用 LLM 来管理对话的状态，而工具是其他 AI 模型本身。每个 AI 模型都是执行特定任务的专用模型，例如目标检测、语音转写、图像描述等。

其工作流程为：

1. 作为通用模型的 LLM 接收用户请求，识别出具体的子任务以及完成任务所需的参数/数据，并以专用模型可解析的格式（如 JSON）格式化请求：

[{"task": "object-detection", "id": 0, "dep": [-1], "args": {"image": "e1.jpg"}}]

2. 专用 AI 模型根据任务返回预测结果，LLM 接收该响应；
3. 若任务需要多个模型协作，LLM 还会先解读各模型的响应，再将它们整合生成最终回复。

例如用户请求"描述并统计图片中的物体"时，LLM 会将请求拆成"物体计数"和"图像描述"两个子任务分发给对应专用模型，再聚合结果。这种"LLM 做路由与聚合、专用模型做单点任务"的架构，与前面框架中"LLM + 工具"的模式形成了对比：在 JARVIS 中，工具不再是 API 或代码，而是模型本身。

实战练习：用多 Agent 模拟商务会议

课程给出的动手练习是：使用 Microsoft Agent Framework 构建一个模拟教育初创公司商务会议的应用。具体要求：

1. 创建不同部门的 Agent，模拟一场商务会议；
2. 编写系统消息（system messages），引导 LLM 理解各部门的角色（persona）与优先级，并让用户能够提出新产品创意（pitch）；
3. 让 LLM 从每个部门的角度生成跟进问题，以打磨和改进该创意与产品方案。

这个练习同时覆盖了本课的三个核心知识点：用系统消息定制 Agent 角色（AutoGen 式思维）、为 Agent 赋予上下文（状态管理）、以及多 Agent 顺序/并行编排（Microsoft Agent Framework 的 SequentialBuilder）。

在课程仓库中继续深入

本课的概念在本仓库中有两处可直接衔接的实操入口：

• 工具即函数调用的基础：第 11 课 Integrating with function calling 展示了如何用 Azure OpenAI 将用户查询路由到函数发起 API 请求（如查询课程目录），这是所有 Agent 框架"工具"概念的底层基础，其配套练习位于 aoai-assignment.ipynb。
• 工具即向量检索：Taskweaver 将插件存为嵌入进行检索，这一模式与第 15 课 RAG 与向量数据库 的嵌入检索流程一致，可参考 notebook-rag-vector-databases.ipynb。

此外，仓库 shared/ 目录提供了各课共用的工程化基础模块，编写 Agent 应用时可直接复用：

• shared/python/api_utils.py：提供 create_openai_client 与 create_azure_openai_client，统一处理 OpenAI / Azure OpenAI（v1 端点，base_url 指向 <endpoint>/openai/v1/）的客户端构造与凭据校验，避免在各应用中重复样板代码。
• shared/python/env_utils.py：get_required_env 与 validate_env_vars 用于安全地读取和校验 OPENAI_API_KEY、AZURE_OPENAI_ENDPOINT 等环境变量，缺失时给出可读的错误提示。
• requirements.txt：课程代码的依赖基线（openai>=1.12.0、pandas==3.0.0、python-dotenv==1.2.2 等）。Agent 框架本身（如 agent-framework-core、autogen、langchain）需按各框架文档另行安装，且运行任何示例前都需先配置对应的 API 凭据环境变量。

小结

• AI Agent 的本质是 LLM + 状态 + 工具：LLM 负责推理"用哪个工具"，状态维护过去与现在的上下文，工具（数据库、API、甚至其他模型）负责真正执行动作。
• 五大框架的差异化焦点清晰：LangChain 强在通用执行器与工具生态；AutoGen 强在多 Agent 对话与代码执行；Microsoft Agent Framework 强在单 Agent 到多 Agent 工作流的统一 SDK、线程化状态与 OpenTelemetry 可观测性；Taskweaver 强在 DataFrame 级代码优先分析与长期 experience 记忆；JARVIS 强在"LLM 编排专用模型"的路由聚合模式。
• 评估或选型 Agent 框架时，建议围绕本课的三个问题展开：状态如何维护（会话内 / 可持久化 / 长期记忆）、工具如何暴露（函数 schema / 插件检索 / 专用模型）、以及出错时如何追溯（可见性/可观测性机制）。