前言

2026 年，AI Agent 不再是一个漂浮在论文里的概念。从 OpenAI 的 GPTs、Anthropic 的 MCP 协议，到国内 Coze/Dify 的低代码 Agent 平台，再到 LangChain、CrewAI、AutoGen 等开发框架的激烈角逐——Agent 正在成为 AI 应用开发的新范式。

但这波浪潮也带来一个问题：信息过载。开发者面对 ReAct、Plan-Act、Function Calling、Tool Use、MCP、A2A 这些名词时，很难理清它们之间的关系。

本文是我「AI Agent 专栏」的第一篇，目标是用一篇文章把 Agent 的核心概念、架构范式、技术选型讲清楚。后续文章会深入到代码实现、框架对比和工作流设计。

---

一、什么是 AI Agent？

1.1 从 LLM 到 Agent

传统的 LLM 调用是一个无状态的函数：输入文本 → LLM → 输出文本。

你问它「今天北京天气怎么样」，它只能回答「我的知识截止到 2024 年，无法获取实时天气」。

Agent 的区别在于，它在 LLM 之外加了三个关键组件，让它从一个「回答问题的人」变成一个「能办事的人」：

Agent 的本质公式：

Agent = LLM + 工具调用 (Tool Use) + 记忆 (Memory) + 规划 (Planning)

1.2 四个核心组件拆解

大脑：LLM

LLM 负责理解任务、拆解步骤、生成工具调用指令。选择模型时考虑三个维度：

维度	说明	代表模型
推理能力	能否正确拆解复杂任务	GPT-4o, Claude 4, DeepSeek-R1
Function Calling	原生支持结构化工具调用	GPT-4o, Claude 4, DeepSeek-V3
延迟与成本	每轮调用的响应速度和费用	GPT-4o-mini, DeepSeek-V3, Qwen-Turbo

手脚：工具调用 (Tool Use)

工具是 Agent 与外部世界交互的接口。技术实现上，LLM 不直接执行工具，而是输出一个结构化的调用指令，由 Agent 运行时去执行：

常见的工具体系：

🔧 工具类型
├── API 调用      → 查天气、发邮件、操作数据库
├── 代码执行      → Python 沙箱、SQL 查询
├── 文件操作      → 读/写/搜索本地文件
├── 网页操作      → 搜索引擎、爬虫、表单提交
└── 多模态        → 图片生成、语音合成、视频分析

海马体：记忆 (Memory)

类型	类比	存储内容	实现方式
短期记忆	工作记忆	当前对话的上下文	消息列表拼接，受 context window 限制
长期记忆	长期记忆	用户偏好、历史知识、经验总结	向量数据库 (RAG) + 结构化存储

短期记忆的挑战是上下文窗口管理——当对话超过 128K tokens，需要做摘要压缩或滑动窗口裁剪。长期记忆的核心是 RAG 管道：信息 → embedding → 向量检索 → 注入上下文。

前额叶：规划 (Planning)

规划决定了任务怎么拆、按什么顺序执行。这是 Agent 最「智能」也最复杂的部分。

---

二、Agent 架构范式对比

目前主流范式有三种：ReAct、Plan-Act、Plan-Then-React。

2.1 三种范式流程对比

2.2 ReAct（Reasoning + Acting）

最主流的范式，OpenAI Function Calling、Anthropic Tool Use 本质上都是 ReAct。

用户: "帮我查北京和上海的天气，告诉我哪个更适合明天出行"

循环1: 思考 → 需要天气数据 → 调用 search_weather("北京")
循环2: 观察结果 → 还缺上海数据 → 调用 search_weather("上海")
循环3: 观察两个结果 → 比较分析 → 生成最终建议

• 优点：灵活，每步能根据上一步结果调整
• 缺点：串行执行慢，每轮都要把历史消息全量发给 LLM，token 消耗大

2.3 Plan-Act

先出完整计划，再执行：

用户: "调研 AI Agent 框架的市场现状"

规划阶段:
  1. 搜索 "AI Agent framework 2025"
  2. 爬取 3-5 篇高相关文章
  3. 提取关键信息
  4. 生成对比分析报告

执行阶段: 按计划逐步执行（独立步骤可并行）

• 优点：全局视角，独立步骤可并行，用户可审核计划
• 缺点：计划可能不准，遇到意外情况难以调整

2.4 选择指南

场景	推荐范式	原因
客服问答	ReAct	问题不确定，需灵活应对
数据分析	Plan-Act	步骤可预测，可并行查数据
代码生成	ReAct	需根据错误迭代修正
工作流自动化	Plan-Act	流程固定，适合批处理

---

三、从单体 Agent 到多 Agent 协作

单个 Agent 的能力有天花板——当任务跨多个领域时，一个 Prompt 很难同时做好搜索、编码、分析。多 Agent 架构把复杂任务拆给专业 Agent：

四种常见协作模式：

模式	说明	典型框架
顺序流水线	Agent A → Agent B → Agent C，线性传递	LangChain LCEL
层级委托	管理者 Agent 分配任务给子 Agent	AutoGen, CrewAI
辩论协作	多个 Agent 讨论/辩论后达成共识	ChatDev, MetaGPT
共享内存	多个 Agent 共享一个记忆空间	自定义实现

一条铁律：能用单 Agent 解决的，不要上多 Agent。增加 Agent 数量会放大延迟、成本和不确定性。

---

四、关键协议：MCP 与 A2A

2024-2026 年，两个协议值得每个 Agent 开发者关注。

4.1 MCP（Model Context Protocol）

Anthropic 发布，定位是 AI 应用的「USB-C 接口」——定义一套标准协议，让任何 AI 应用都能用统一方式对接任何工具/数据源。

为什么重要：MCP 之前，每个框架有自己的一套工具定义格式。LangChain 用 Tool 类，OpenAI 用 function schema，Claude 用 tool_use block。对接一个新工具要写多套适配。MCP 如果成为事实标准，这个碎片化问题将被解决。

4.2 A2A（Agent-to-Agent Protocol）

Google 2025 年 4 月发布，解决的是不同厂商、不同框架的 Agent 如何互操作。如果说 MCP 是「Agent 与工具的接口」，A2A 就是「Agent 与 Agent 的接口」。

两者当前都处于早期推广阶段，值得持续关注但不宜过早绑定生产依赖。

---

五、2026 年技术栈速览

主流开发框架

框架	定位	适合
LangChain	最全面的 LLM 应用框架	需要丰富工具生态
LangGraph	有状态、有分支的 Agent 工作流	复杂多步骤 Agent
CrewAI	多 Agent 角色扮演协作	模拟团队协作
AutoGen（微软）	多 Agent 对话框架	企业级多 Agent
Dify	低代码 AI 应用平台	非开发者/快速搭建
Coze（字节）	零代码 Agent 搭建	C 端快速体验

配套基础设施

监控追踪    → LangSmith, Arize Phoenix, Weave
向量数据库  → pgvector, Milvus, Pinecone, Qdrant
安全网关    → Guardrails, NeMo Guardrails
评估测试    → Ragas, DeepEval

---

六、总结

一张图收尾：

核心观点回顾：

1. Agent = LLM + 工具 + 记忆 + 规划，这是理解一切 Agent 框架的底座
2. ReAct 是当前最主流范式，但 Plan-Act 在可预测任务中更高效
3. 多 Agent 要克制——增加 Agent 数量放大延迟和不确定性，不要为了「多」而多
4. MCP 和 A2A 值得关注，但不要过早绑定——生态还在早期
5. 选框架前先想清楚场景。LangChain 不是唯一答案

---

专栏预告

这是「AI Agent 专栏」的第一篇——建立全局认知。后续内容：

• 第二篇：从零实现一个 AI Agent（纯 Python，不依赖框架，逐行拆解 Agent 循环）
• 第三篇：主流 Agent 框架横评（LangChain vs CrewAI vs AutoGen vs Dify，含避坑指南）
• 第四篇：MCP 协议实战——给你的 Agent 装上工具插件
• 第五篇：Agent 评估体系——如何量化 Agent 好不好用

欢迎关注专栏，点赞收藏不迷路。

---

作者简介：全栈开发者，开源项目 ORIGIN AI Workspace 作者，专注自托管 AI 与 Agent 架构。
I 与 Agent 架构。*