AI Agent 入门第二课:主流框架大对比,选哪个不踩坑?

# AI Agent 入门第二课：主流框架大对比，选哪个不踩坑？

上周一个朋友跟我说，他兴冲冲用 LangChain 做了个 Agent，本以为一天搞定，结果连最简单的工具调用都要自己一层层搭管道——工具注册、输入解析、输出格式化、异常处理，全得手写。折腾了整整两天才勉强上线，人都麻了。

他说了句话我觉得挺有道理：框架选对了，省的不是时间，是命。

为什么直接调 API 不够用？

很多人刚入门，第一反应是：我直接调 OpenAI 的 API 不就行了？

能用，但差很远。

打个比方：直接调 API，就像开手动挡汽车——每次换挡都得自己踩离合、推挡位、配合油门，操作没问题，但你的脑子得一直盯着换挡这件事，没法专心看路。

用 Agent 框架，就像开自动挡——你只管踩油门，换挡的事车自己处理。

Agent 框架帮你封装的那些”换挡”动作，包括：

• 工具调用：怎么调搜索、怎么调数据库、怎么调计算器，框架帮你规范化
• 记忆管理：上下文怎么存、怎么召回、多轮对话怎么不乱
• 错误重试：工具调用失败了怎么处理，是重试还是换策略
• 多轮对话：每次对话状态怎么传递，不用你手动拼 prompt

你只需要关心：我想让这个 Agent 干什么，能用什么工具，有什么约束。底层的脏活框架干了。

快速原型三板斧

理解了”为什么用框架”，再来看框架给你提供了哪三个最核心的能力。

模块化组件

就像乐高积木，AI 连接器、工具定义、记忆模块、提示模板都是现成的，拼一拼就是 Agent。

举个例子：你想搭一个能搜索 + 回答 + 记住上下文的客服 Agent。不用从零写，直接把搜索工具模块、对话记忆模块、回答生成模块拼在一起，配置一下，跑起来。就像装修不用烧砖，材料商都备好了，你只需要设计怎么摆。

协作工具

多个 Agent 分工协作——数据抓取 Agent 负责搜集信息，分析 Agent 负责看懂数据，决策 Agent 负责给出结论。就像一个研究团队，组长不用既爬数据又写报告还做判断，各司其职，效率高，出错了也容易定位是哪个环节的问题。

实时学习

新员工刚入职，前两周摸不清楚老板喜好，慢慢交互多了才能摸透——Agent 也一样。每次交互都有反馈，系统会动态调整行为偏好，不是死板的 if-else 规则系统。你告诉它”这个回答太长了”，它下次会自动收着点。

MAF vs Azure AI Agent Service：到底选哪个？

先看表格，一目了然：

官方的建议是：先用 MAF 写 Agent，再用 Azure AI Agent Service 部署上线。

我觉得这个顺序真的是对的，说说我的理解——

MAF 是纯 SDK，本地跑，依赖少，报错清晰，改一行代码秒看效果。你在验证想法的阶段，最怕的就是环境问题挡路，想测一个工具调用逻辑，结果发现 Azure 某个权限没开、某个资源没创建，折腾半天还没开始正题。

等逻辑跑通了，再迁移到 Azure AI Agent Service 上线。这时候你已经知道 Agent 该干什么、工具怎么用，只剩部署这一层的事，心里有底，遇到配置问题也能快速定位。

先把事情想清楚，再搞环境；别一上来就在环境里挣扎。

代码上手：创建你的第一个 Agent

别怕，就这么几行：

`python

import os

from azure.ai.projects import AIProjectClient

from azure.identity import DefaultAzureCredential

from azure.ai.projects.models import AgentProvider, AzureAIProjectAgentProvider

# 用 DefaultAzureCredential 做身份认证

# 本地开发时会自动读取你 az login 的账号

credential = DefaultAzureCredential()

# 创建项目客户端，连接到你的 Azure AI 项目

# AZURE_AI_PROJECT_CONNECTION_STRING 从项目设置里复制

client = AIProjectClient.from_connection_string(

credential=credential,

conn_str=os.environ[“AZURE_AI_PROJECT_CONNECTION_STRING”],

)

# 用 MAF 提供的 Agent Provider 初始化

provider = AzureAIProjectAgentProvider(client=client)

# 创建一个最简单的 Agent

# name：给 Agent 取个名字

# instructions：就是你告诉 Agent 它是谁、该怎么干活的 system prompt

agent = provider.create_agent(

model=”gpt-4o”,                          # 用哪个模型

name=”my-first-agent”,                   # Agent 名字

instructions=”你是一个有用的助手，回答问题要简洁清晰。”,  # 行为指令

)

# 创建对话线程（可以理解为一次会话的容器）

thread = provider.create_thread()

# 往线程里发一条用户消息

provider.create_message(

thread_id=thread.id,

role=”user”,

content=”帮我解释一下什么是 AI Agent”,

)

# 让 Agent 处理这条消息并运行

run = provider.create_and_process_run(

thread_id=thread.id,

agent_id=agent.id,

)

# 获取 Agent 的回复

messages = provider.list_messages(thread_id=thread.id)

print(messages.get_last_text_message_by_role(“assistant”).text.value)

`

看上去挺长，但核心逻辑就五步：连接项目 → 创建 Agent → 开一个对话线程 → 发消息 → 拿回复。

新手最容易卡的地方是 AZURE_AI_PROJECT_CONNECTION_STRING 怎么拿——去 Azure AI Studio 项目页面，左下角有个”项目连接字符串”，复制粘贴进环境变量就行，不用手动拼。

框架选择决策树

每次有人问我”我该用哪个框架”，我都想给他们看这个：

`

我该选哪个框架？

├─ 还在探索/快速验证想法？

│  └─ → 选 Microsoft Agent Framework（MAF）

├─ 需要支持非 OpenAI 的开源模型（Llama/Mistral/Cohere）？

│  └─ → 选 Azure AI Agent Service

├─ 需要企业级部署、高可用、与 Bing/AI Search 深度集成？

│  └─ → 选 Azure AI Agent Service

└─ 从原型走向生产？

└─ → 先 MAF 原型 → 再迁移到 Azure AI Agent Service

`

99% 的初学者都该从 MAF 开始。别高估自己对部署复杂度的耐受力。

踩坑清单

真实踩过的或者见别人踩过的，记下来给你省事：

1. 上来就直接上 Azure AI Agent Service

环境配置这一关就能搞你两天——订阅权限、资源组、API Key、网络策略……每一个都能让你卡住。先用 MAF 把业务逻辑跑通，再迁移上线，顺序反了效率差十倍。

2. 把 Agent 框架当普通 API wrapper 用

有人用了框架，但没有定义工具，没有接记忆模块，就是把 chat.completions.create 套了个壳——这跟直接调 API 没区别，还多了一层封装的理解成本。框架的价值在工具调用和状态管理，不用这些不如不用。

3. 忽略 token 消耗

多 Agent 协作是真的烧 token——每个 Agent 每次运行都要把上下文喂进模型，三个 Agent 协作一次对话，成本可能是单次对话的五六倍。没做成本估算就直接上线，月底账单会给你惊喜。上线前一定要算清楚 QPS × 平均 token 数 × 单价，心里有个数。

课后三道思考题

不用回复我，自己想一想：

• 你现在手头有没有某个重复性的工作——每次都要查信息、整理、输出——如果让一个 Agent 来干，它需要哪几个工具？记忆要存什么？

• MAF 和 Azure AI Agent Service 的分工，像不像你公司里”研发环境”和”生产环境”的关系？它们之间最大的隔离是什么？

• 如果一个 Agent 系统的 token 消耗超出预算，你会优先砍哪个环节——上下文长度、Agent 数量、还是模型档次？为什么？

AI 的世界每天都比昨天更陌生一点，但也更有意思一点。我们明天见。

这是「AI Agents for Beginners」系列笔记第2课，下一课：Agent 设计原则——怎么让 AI 既好用又不乱来，期待的扣1。