AI Agent 开发入门：从概念到架构的系统学习总结

发表于 2026-03-23 分类于 LLM 阅读次数：本文字数： 8.9k 阅读时长 ≈ 16 分钟

本文为 AI Agent 开发入门的系统性学习总结。Agent 技术仍在快速演进中，建议持续关注领域内的最新进展。

从 ChatGPT 的爆发开始，大语言模型（LLM）已经深入到开发者的日常工具链中。但 LLM 本身只是一个”文本生成器”——给它一段输入，它返回一段输出。它不能自主决策，不能调用外部系统，也不能根据执行结果动态调整行为。

AI Agent（智能体）的出现改变了这一点。Agent 将 LLM 从被动的问答工具升级为能够感知环境、自主推理、调用工具、持续执行的智能系统。理解 Agent 的核心概念，是每个希望深入 AI 应用开发的工程师都需要建立的知识基础。

本文系统梳理 AI Agent 的核心概念体系，覆盖架构设计、推理模式、工具调用、记忆系统、规划能力和多 Agent 协作等关键主题，帮助有编程基础的开发者建立完整的认知框架。

1. 什么是 AI Agent

从 LLM 到 Agent 的演进

传统的 LLM 应用模式是”输入-输出”式的：用户提问，模型回答。即使加上了 Prompt Engineering 和 RAG（检索增强生成），本质上仍是单轮或多轮的文本生成。

AI Agent 引入了一个关键转变：自主行动能力。Agent 不仅能理解和生成文本，还能根据理解的结果去”做事”——调用 API、查询数据库、执行代码、操作文件系统，并根据执行结果决定下一步行动。

Agent 的定义

一个 AI Agent 可以理解为：一个以 LLM 为核心推理引擎，具备感知环境、自主决策和执行行动能力的智能系统。

它的工作模式是一个持续的循环：

感知（Perception）→ 推理（Reasoning）→ 行动（Action）→ 观察结果 → 继续推理 → ...

这个循环会持续进行，直到 Agent 判断任务完成或无法继续。

Agent 与传统 LLM 应用的区别

维度	传统 LLM 应用	AI Agent
交互模式	单轮/多轮对话	自主循环执行
能力边界	文本生成	文本生成 + 工具调用 + 环境交互
决策方式	被动响应	主动规划和决策
执行能力	无	可调用外部工具和 API
状态管理	依赖上下文窗口	拥有独立的记忆系统
错误处理	无自动纠错	可根据反馈自我调整

一句话理解

Agent = LLM + Memory + Tools + Planning

LLM 提供推理能力，Memory 提供上下文和经验积累，Tools 提供与外部世界交互的能力，Planning 提供任务分解和执行策略。这四个组件共同构成了 Agent 的能力基础。

2. Agent 的核心架构

感知-推理-行动循环

Agent 的架构围绕一个核心循环展开：

感知（Perception）：接收输入信息——用户指令、工具返回的结果、环境状态变化
推理（Reasoning）：LLM 分析当前情况，结合记忆和目标，决定下一步行动
行动（Action）：执行具体操作——调用工具、生成回答、修改状态
观察（Observation）：获取行动的结果，作为下一轮推理的输入

这个循环并非固定次数。Agent 会根据任务的复杂度自动决定循环多少次。一个简单的查询可能只需要一轮，而一个复杂的研究任务可能需要十几轮甚至更多。

四大核心组件

LLM（大脑）

LLM 是 Agent 的核心推理引擎。它负责：

理解用户意图
分析当前状态
决定是否需要调用工具
选择调用哪个工具、传递什么参数
整合工具返回的结果
判断任务是否完成

不同的 LLM 在推理能力、工具调用能力、上下文窗口大小上存在差异，这直接影响 Agent 的表现。

Tools（手脚）

工具扩展了 Agent 的能力边界。没有工具，Agent 只是一个文本生成器；有了工具，Agent 可以搜索信息、读写文件、调用 API、执行代码、操作数据库。

工具的本质是预定义的函数，每个工具有明确的名称、描述和参数定义。LLM 通过 Function Calling 机制来选择和调用这些工具。

Memory（记忆）

记忆让 Agent 具备了上下文理解和经验积累的能力。没有记忆，每次交互都是”从零开始”；有了记忆，Agent 可以记住之前的对话、学到的知识和执行的结果。

Planning（策略）

规划能力让 Agent 能够处理复杂任务。面对一个大目标，Agent 不是一股脑地行动，而是先将任务拆解为多个子步骤，制定执行计划，然后逐步执行。

后续章节将分别深入每个组件。

3. 推理与行动：ReAct 模式

ReAct 的由来

ReAct（Reasoning + Acting）模式由 Yao 等人在 2022 年的论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出。这是 AI Agent 领域最重要的设计模式之一。

在 ReAct 出现之前，推理（Chain-of-Thought）和行动（Action）是分开处理的：

纯推理：让 LLM 一步步思考，但不与外部环境交互，容易产生幻觉
纯行动：让 LLM 直接调用工具，但缺少中间推理过程，难以处理复杂场景

ReAct 的核心思路是将两者交替进行：思考一步，行动一步，观察结果，再思考下一步。

Thought → Action → Observation 循环

ReAct 的工作流程由三个交替出现的元素组成：

Thought（思考）：Agent 分析当前状况，决定接下来该做什么
Action（行动）：Agent 执行一个具体操作（如搜索、查询、计算）
Observation（观察）：获取行动的结果

以下是一个假设的例子（数据为示意），展示 ReAct 如何回答”苹果公司最新一季的营收是多少？”：

Thought 1: 用户想知道苹果公司最新一季的营收。我需要搜索最新的财报数据。
Action 1: search("Apple Inc Q1 2026 revenue earnings report")
Observation 1: Apple reported Q1 2026 revenue of $124.3 billion...

Thought 2: 搜索结果显示苹果 2026 年 Q1 营收为 1243 亿美元。我现在有足够信息回答用户。
Action 2: finish("苹果公司最新一季（2026 Q1）的营收为 1243 亿美元。")

每一步 Thought 都有明确的推理过程，每一步 Action 都有具体的执行操作。这种交替模式让 Agent 的决策过程变得可追踪、可解释。

ReAct 解决了什么问题

减少幻觉：通过与外部工具交互获取真实数据，而非仅依赖模型内部知识
可追踪性：每一步思考和行动都有记录，便于调试和理解
动态适应：根据每步的观察结果动态调整后续策略，而非执行固定计划
错误恢复：当某一步的结果不理想时，Agent 可以在 Thought 中识别问题并调整策略

ReAct 模式奠定了现代 Agent 设计的基础，当前主流 Agent 框架几乎都以 ReAct 或其变体作为核心执行模式。

4. 工具调用（Tool Use / Function Calling）

为什么 Agent 需要工具

LLM 的能力有明确边界：它擅长语言理解和生成，但无法直接访问实时数据、执行精确计算、操作外部系统。工具弥补了这些缺陷：

搜索引擎：获取实时信息
计算器：精确数学运算
代码执行器：运行代码并返回结果
API 调用：与外部服务交互（数据库、邮件、日历等）
文件系统：读写文件

工具让 Agent 从”只能说”变成”能说也能做”。

Function Calling 的工作机制

Function Calling 是 LLM 与工具之间的桥梁。它的工作流程如下：

第一步：定义工具

开发者以结构化的方式（通常是 JSON Schema）定义可用工具的名称、功能描述和参数说明：

{
  "name": "get_weather",
  "description": "获取指定城市的当前天气信息",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "城市名称"
      }
    },
    "required": ["city"]
  }
}

第二步：LLM 决策

将用户请求和工具定义一起发送给 LLM。LLM 判断是否需要调用工具，如果需要，生成结构化的调用请求：

{
  "tool_call": {
    "name": "get_weather",
    "arguments": {"city": "北京"}
  }
}

关键点在于：LLM 不直接执行工具。它只生成一个描述调用意图的数据结构。

第三步：应用执行

应用程序接收 LLM 输出的调用请求，解析参数，执行实际的函数调用，获取结果。

第四步：结果返回

将执行结果返回给 LLM，LLM 结合结果生成最终回答或决定是否需要继续调用其他工具。

MCP（Model Context Protocol）

MCP 是由 Anthropic 提出的一项协议标准，旨在解决工具集成的标准化问题。它定义了 Agent 如何发现、描述和调用外部工具的统一协议，类似于 Web 领域的 HTTP 协议为客户端和服务器之间的通信建立了标准。

MCP 的核心价值在于互操作性：不同的 Agent 框架可以通过同一套协议接入同一套工具，工具提供者只需实现一次 MCP 接口，就能被各种 Agent 使用。

工具设计的关键原则

设计 Agent 工具时，需要注意：

描述清晰：工具的 description 决定了 LLM 能否正确选择和使用它
参数明确：每个参数都应有类型和描述，减少 LLM 的歧义
功能单一：一个工具做一件事，避免过于复杂的多功能工具
错误处理：工具应返回清晰的错误信息，帮助 Agent 理解失败原因
安全边界：工具的权限范围应严格控制，避免 Agent 执行越权操作

5. 记忆系统（Memory）

为什么 Agent 需要记忆

LLM 的上下文窗口是有限的。即使最新的模型支持 128K 甚至更长的上下文，对于长时间运行的任务或跨会话的交互，仍然不够。记忆系统为 Agent 提供了超越上下文窗口限制的信息持久化能力。

没有记忆的 Agent，每次交互都是独立的——它不记得上一次对话的内容，不记得用户的偏好，不记得之前执行过的操作。这对于需要持续交互的应用场景来说是致命的限制。

短期记忆 vs 长期记忆

短期记忆（Short-term Memory）

短期记忆对应当前会话的上下文信息，包括：

对话历史
当前任务的中间状态
最近一次工具调用的结果

实现方式通常是直接维护在 LLM 的上下文窗口中。当上下文过长时，需要通过摘要、截断或滑动窗口等策略管理。

长期记忆（Long-term Memory）

长期记忆是跨会话持久化的信息，包括：

用户偏好和历史行为
之前任务的执行经验
积累的领域知识

实现方式通常依赖外部存储，如向量数据库、关系数据库或知识图谱。

现代分类：三种记忆类型

借鉴认知科学的分类，现代 Agent 记忆系统通常区分三种类型：

记忆类型	含义	Agent 中的对应	示例
情景记忆（Episodic）	具体事件的记录	交互日志、任务执行记录	“上次用户让我查北京天气时用了 get_weather 工具”
语义记忆（Semantic）	结构化知识和事实	知识库、FAQ、领域知识	“北京是中国的首都”
程序记忆（Procedural）	操作技能和流程	工具使用模式、任务执行模板	“部署流程：先构建 → 再测试 → 最后发布”

常见实现方式

Context Window

最简单的方式——直接把信息放在 LLM 的提示中。优点是简单直接，缺点是受窗口大小限制，且成本随上下文长度增加。

向量数据库 + Embedding

将信息转化为向量（embedding），存储在向量数据库（如 Pinecone、Chroma、Weaviate）中。查询时通过语义相似度检索相关信息。这是目前最主流的长期记忆实现方式。

RAG（检索增强生成）

RAG 不完全等于记忆系统，但它是记忆系统的重要实现手段。其核心流程：

将知识文档切分成块（chunk）
生成 embedding 存储到向量数据库
用户查询时，先从向量库检索相关片段
将检索到的片段与用户问题一起送入 LLM 生成回答

RAG 让 Agent 能够访问远超上下文窗口容量的知识库。

记忆对 Agent 能力的影响

记忆系统的质量直接影响 Agent 的表现：

个性化：记住用户偏好，提供定制化服务
一致性：避免在多轮交互中自相矛盾
学习能力：从过去的经验中总结规律，避免重复犯错
效率：避免重复执行已完成的操作

6. 规划能力（Planning）

任务分解（Task Decomposition）

面对复杂任务，Agent 需要将大目标拆分为可执行的小步骤。这个过程类似于软件工程中的任务分解。

例如，”帮我写一篇关于微服务的技术博客”可以被分解为：

确定文章主题和受众
调研相关资料
设计文章提纲
逐章节撰写
整体校对和优化

任务分解有三种常见模式：

线性分解：子任务按顺序排列，前一个完成才能开始下一个
并行分解：识别可以同时进行的子任务，提高效率
层级分解：将子任务进一步拆分为更小的子任务，形成树状结构

规划策略对比

Plan-then-Execute（先计划后执行）

先生成完整的执行计划，然后按照计划逐步执行。

优点：计划完整，执行有序
缺点：如果中间步骤失败或环境变化，整个计划可能需要重新制定
适用：目标明确、步骤可预测的任务

Interleaved Planning（交错规划）

边执行边调整计划。每执行一步，根据结果动态更新后续计划。

优点：灵活性高，能适应变化
缺点：可能缺乏全局视角，容易陷入局部最优
适用：环境不确定、需要动态适应的任务

ReAct 式（边推理边执行）

不生成显式计划，每步通过推理决定下一个行动。

优点：最灵活，适应性最强
缺点：对于复杂任务可能效率低，容易偏离目标
适用：简单到中等复杂度的任务

自我反思与纠错

高级 Agent 系统支持自我反思（Self-Reflection）机制：

执行一步操作后，评估结果是否符合预期
如果结果不理想，分析原因
调整策略或回退到之前的步骤
重新尝试

这类似于人类的”复盘”过程。典型的实现如 Reflexion 框架，让 Agent 在失败后生成反思文本，指导后续尝试。

规划能力的局限性

当前 Agent 的规划能力仍有明显局限：

长程规划不稳定：步骤越多，累积错误越大
难以处理高度不确定性：当多个步骤的结果都不可预测时，规划的价值下降
容易陷入循环：Agent 可能反复尝试同一个失败的策略
计划执行不一致：Agent 生成的计划可能与实际执行行为不一致

这些局限性是当前 Agent 研究的活跃方向。

7. Multi-Agent 系统

为什么需要多 Agent 协作

当任务复杂度超过单个 Agent 的处理能力时，引入多个专门化的 Agent 进行协作是自然的选择。这类似于软件系统中的微服务架构——将一个大系统拆分为多个专注单一职责的服务。

Multi-Agent 的优势：

专业化：每个 Agent 专注一个领域，降低单个 Agent 的复杂度
可扩展：可以灵活添加或替换 Agent
可维护：独立测试和调试单个 Agent
优化空间：不同 Agent 可以使用不同的模型和工具组合

五种核心编排模式

根据 Microsoft Azure Architecture Center 的架构指南，多 Agent 系统有五种核心编排模式：

Sequential（顺序编排）

Agent 按预定义的线性顺序链式执行，每个 Agent 处理前一个 Agent 的输出。

输入 → Agent A → Agent B → Agent C → 结果

适用场景：流水线处理，如”起草 → 审核 → 润色”工作流。

注意事项：早期 Agent 的失败会级联影响后续所有 Agent。

Concurrent（并行编排）

多个 Agent 同时处理同一个输入，各自独立产出结果，最后汇总。

        → Agent A → 结果 A ─┐
输入 ──→ Agent B → 结果 B ──→ 汇总 → 最终结果
        → Agent C → 结果 C ─┘

适用场景：需要多维度分析的场景，如从技术、商业、法律角度同时评估一个方案。

注意事项：需要设计好结果冲突时的合并策略。

Group Chat（群聊编排）

多个 Agent 在共享的对话线程中协作讨论，由聊天管理器（Chat Manager）协调发言顺序。

适用场景：需要协商、辩论或达成共识的场景。

注意事项：Agent 数量超过 3 个时，对话流难以控制。

一种常见的特殊形式是 Maker-Checker Loop（生成-验证循环）：一个 Agent 生成内容，另一个 Agent 验证质量，不通过则返回修改，反复循环直到通过。

Handoff（交接编排）

Agent 之间动态委派任务。每个 Agent 评估自身是否能处理当前任务，如果不能则转交给更合适的 Agent。

输入 → Agent A → (判断需要转交) → Agent B → (判断需要转交) → Agent C → 结果

适用场景：客服系统中的分级处理——通用客服 → 技术支持 → 专家处理。

注意事项：需要防止 Agent 之间无限循环转交。

Magentic（动态规划编排）

面向开放式问题的编排模式。管理 Agent 动态构建任务清单（Task Ledger），协调其他 Agent 收集信息、制定方案、执行操作。

适用场景：问题定义不清晰、没有预设解决路径的复杂场景，如故障排查、研究探索。

注意事项：收敛速度慢，可能陷入停滞。

选择编排模式的原则

Microsoft 的架构指南强调了一个重要原则：从最低复杂度开始。

复杂度	方案	何时使用
低	直接 LLM 调用	单步任务（分类、翻译、摘要）
中	单 Agent + 工具	需要动态工具调用的单领域任务
高	Multi-Agent 编排	跨领域、需要专业分工或安全隔离的场景

不要为了使用多 Agent 而使用多 Agent。协调多个 Agent 带来的额外开销（延迟、成本、调试复杂度）需要有足够的收益来证明其合理性。

8. 开发框架概览

了解核心概念后，选择合适的开发框架是将理论付诸实践的关键一步。以下是当前主流的 Agent 开发框架简要对比：

框架	核心特点	适用场景
LangChain / LangGraph	最成熟的生态系统；LangGraph 支持有状态、可控的工作流图	通用 Agent 开发，需要精细控制执行流程
OpenAI Agents SDK	OpenAI 官方出品，轻量且与 OpenAI 模型深度集成	使用 OpenAI 模型的快速原型开发
AutoGen	微软开源，聚焦多 Agent 对话式协作	研究型项目，多 Agent 实验
CrewAI	基于角色定义的 Agent 团队，API 简洁	快速搭建基于角色的多 Agent 应用
Microsoft Agent Framework	微软新一代 Agent 编排框架，内置五种编排模式	企业级多 Agent 应用，Azure 生态集成

选择框架时需要考虑的因素：

模型兼容性：是否支持你计划使用的 LLM
编排能力：是否满足你的 Agent 协作需求
生态和社区：文档质量、社区活跃度、第三方集成
生产就绪度：是否支持可观测性、错误处理、状态持久化等生产级需求
学习曲线：概念复杂度与 API 设计是否适合团队水平

建议初学者从 LangChain/LangGraph 或 OpenAI Agents SDK 入手——前者生态最完整、资料最丰富，后者上手最快。

9. 总结与学习路径建议

核心概念回顾

AI Agent 知识体系
│
├── 基本概念
│   └── Agent = LLM + Memory + Tools + Planning
│
├── 核心循环
│   └── 感知 → 推理 → 行动 → 观察 → ...
│
├── 推理模式
│   └── ReAct：Thought → Action → Observation 交替循环
│
├── 工具调用
│   ├── Function Calling 机制
│   └── MCP 标准化协议
│
├── 记忆系统
│   ├── 短期记忆 / 长期记忆
│   ├── 情景 / 语义 / 程序记忆
│   └── 实现：Context Window / 向量数据库 / RAG
│
├── 规划能力
│   ├── 任务分解
│   ├── Plan-then-Execute / Interleaved / ReAct
│   └── 自我反思
│
└── Multi-Agent 系统
    ├── Sequential / Concurrent / Group Chat / Handoff / Magentic
    └── 原则：从最低复杂度开始

建议的学习路径

理解基础：熟悉 LLM 的基本原理、Prompt Engineering、Function Calling
掌握 ReAct：理解 Thought-Action-Observation 循环，尝试手写一个简单的 ReAct Agent
学习框架：选择一个框架（推荐 LangChain 或 OpenAI Agents SDK），跟着官方教程搭建第一个 Agent
深入组件：逐一深入 Tool Use、Memory、Planning 的设计和实现
探索多 Agent：理解编排模式，尝试搭建简单的多 Agent 系统
生产实践：关注可观测性、安全性、成本控制、错误处理等生产级问题