一、什么是 Agent？
一个最简单的理解：Agent = 大模型（LLM）+ 工具（Tools）+ 记忆（Memory）+ 规划（Planning）。
传统的大模型只能"聊天"——你问一句，它答一句。Agent 则更进一步，它能自己思考、自己调用工具（比如执行命令、读写文件、搜索网页），再根据工具返回的结果继续思考，直到完成任务。
打个比方：如果大模型是一个"大脑"，Agent 就是给这个大脑装上了"手"和"脚"，让它不只是想，还能做。
二、核心概念拆解
2.1 LLM（大语言模型）
Agent 的"大脑"，负责理解任务、制定计划、做决策。目前主流的大模型有 GPT-4、Claude、Gemini 等。
2.2 Tools（工具）
Agent 的"手脚"。大模型本身只能生成文字，但通过工具调用（Tool Call / Function Call），它可以：
- 执行命令行指令
- 读写文件
- 搜索互联网
- 调用 API
- 操作数据库
- 等等...
2.3 Memory（记忆）
Agent 的"笔记本"。分为两种：
- 短期记忆：当前对话的上下文，Agent 记得刚才说了什么、做了什么
- 长期记忆：跨会话保存的关键信息，比如"上次我们用的是 Flask + SQLite"，下次启动时还能想起来
记忆让 Agent 不会"每句话都像第一次见面"。
2.4 Planning（规划）
Agent 的"施工图纸"。面对复杂任务时，不是想到哪做到哪，而是先拆解成步骤，理清依赖关系，再按顺序执行。
三、ReAct 模式：Agent 的基本工作方式
ReAct = Reasoning（推理）+ Acting（行动）。这是最基础的 Agent 工作模式。
3.1 核心循环
Thought（思考）→ Action（行动）→ Observation（观察）→ Thought → ... → Final Answer
每一步：
- Thought：Agent 思考"我现在该做什么？"
- Action：调用工具执行具体操作
- Observation：获取工具返回的结果
- 根据结果决定下一步，直到任务完成
- Final Answer：给出最终答案
3.2 一个简单例子
用户说："帮我查一下北京今天的天气。"
Thought: 我需要获取北京今天的天气，应该使用天气查询工具。
Action: 调用 get_weather(city="北京")
Observation: {"temperature": 25, "condition": "晴"}
Thought: 已经拿到了天气数据，可以回答用户了。
Final Answer: 北京今天晴，气温 25°C。
这就是最基础的 ReAct 循环。对于简单任务，ReAct 完全够用。
四、Plan-ReAct 模式：复杂任务的利器
当任务变得复杂（比如"搭建一个博客系统"），纯 ReAct 就容易出问题了——可能做到一半发现顺序错了，或者遗漏了关键步骤。
这时就需要 Plan-ReAct 模式：先规划，再执行。
4.1 三阶段流程
第一阶段：Planning（规划）
↓
第二阶段：Execution（执行）
↓
第三阶段：Summary（总结）
4.2 第一阶段：规划
Agent 拿到任务后，先不急着做，而是制定一个详细的执行计划。计划中每个步骤包含：
- step_id：步骤编号
- description：步骤描述
- tool：需要用到的工具
- dependencies：依赖的其他步骤（必须先完成哪些步骤才能做这个）
同时输出 reasoning（推理理由），解释为什么这样安排。
4.3 第二阶段：执行
按照计划，逐步执行。每完成一步就更新状态：
==================================================
执行计划:
✓ Step 1: 创建项目目录结构 [execute_command]
✓ Step 2: 编写后端依赖 requirements.txt [write_file]
⏳ Step 3: 编写后端数据库模型 [write_file] (依赖: 2)
⏳ Step 4: 编写后端 API 路由 [write_file] (依赖: 3)
⏳ Step 5: 编写前端首页 HTML [write_file] (依赖: 1)
⏳ Step 6: 编写前端 JavaScript [write_file] (依赖: 5)
⏳ Step 7: 初始化数据库并运行后端 [execute_command] (依赖: 4)
⏳ Step 8: 测试 API 接口 [execute_command] (依赖: 7)
==================================================
✓ 表示完成，⏳ 表示待执行。依赖关系确保不会出现"前端写完了发现后端还没启动"的尴尬。
执行过程中，Agent 会持续存储关键信息到记忆中。
4.4 第三阶段：总结
所有步骤完成后，Agent 输出最终结果，包括项目结构、功能验证、启动方式等。同时存储记忆供后续会话使用。
五、记忆系统详解
记忆是 Agent 区别于普通"一次性的 AI 对话"的关键特性。
5.1 记忆的结构
## 相关记忆
[2026-03-21T10:30:00] 创建了 Flask 项目，包含基础路由
[2026-03-21T14:20:00] 使用过 SQLAlchemy 做数据库操作
[2026-03-22T09:15:00] 写过用户认证功能（session-based）
每条记忆包含时间戳和内容，方便 Agent 在规划阶段参考历史经验。
5.2 什么时候存记忆？
- 创建/修改了重要文件
- 完成了关键步骤
- 学到了新的技术方案
- 遇到并解决了问题
5.3 记忆的价值
假设你在周二搭建了一个博客系统，周四想要加一个新功能。Agent 加载相关记忆后，立刻知道项目用了 Flask + SQLite，数据库模型是 User 和 Post，API 有哪些路由——不需要你重新解释一遍。
六、实战案例：搭建完整博客系统
下面通过一个完整的实战案例来理解 Plan-ReAct Agent 的运作方式。
6.1 任务描述
搭建一个博客系统，包含：
1. 后端 API（Flask + SQLite）
2. 前端页面（HTML + CSS + JS）
3. 用户登录功能
4. 文章 CRUD 操作
5. 运行测试确保能用
6.2 System Prompt（系统提示词）
Agent 启动时，会收到以下系统指令：
你是 Plan-ReAct Agent。
## 相关记忆
[2026-03-21T10:30:00] 创建了 Flask 项目，包含基础路由
[2026-03-21T14:20:00] 使用过 SQLAlchemy 做数据库操作
[2026-03-22T09:15:00] 写过用户认证功能（session-based）
## 模式
先制定完整计划，再按步骤执行。
## 执行格式
Thought: [思考]
Action: [工具调用]
Observation: [结果]
Remember: [关键信息]
Final Answer: [最终答案]
6.3 第一阶段：生成计划
Agent 的 LLM 看到任务后，输出了以下计划：
json
{
"plan": [
{
"step_id": 1,
"description": "创建项目目录结构（backend/frontend/static/templates）",
"tool": "execute_command",
"dependencies": []
},
{
"step_id": 2,
"description": "编写后端依赖 requirements.txt",
"tool": "write_file",
"dependencies": []
},
{
"step_id": 3,
"description": "编写后端数据库模型（User, Post）和配置",
"tool": "write_file",
"dependencies": [2]
},
{
"step_id": 4,
"description": "编写后端 API 路由（认证 + 文章 CRUD）",
"tool": "write_file",
"dependencies": [3]
},
{
"step_id": 5,
"description": "编写前端首页 HTML 和基础 CSS",
"tool": "write_file",
"dependencies": [1]
},
{
"step_id": 6,
"description": "编写前端 JavaScript（登录、文章列表、创建文章）",
"tool": "write_file",
"dependencies": [5]
},
{
"step_id": 7,
"description": "初始化数据库并运行后端服务",
"tool": "execute_command",
"dependencies": [4]
},
{
"step_id": 8,
"description": "测试 API 接口（创建用户、登录、CRUD 文章）",
"tool": "execute_command",
"dependencies": [7]
}
],
"reasoning": "这是一个标准的多层 Web 应用，需要前后端分离。先搭建后端 API 确保数据流正常，再构建前端界面。数据库模型是核心依赖，必须在路由之前完成。最后集成测试验证端到端功能。"
}
关键观察：
- Step 1 和 Step 2 没有依赖 → 可以并行执行
- Step 3 依赖 Step 2 → 先确定依赖包，再写模型代码
- Step 4 依赖 Step 3 → 先有数据模型，再写 API 路由
- Step 7 依赖 Step 4 → 后端代码写完才能启动服务
- Step 8 依赖 Step 7 → 服务启动了才能测试
这就是 Plan 模式的核心价值：理清"先做什么、后做什么、什么可以同时做"。
6.4 第二阶段：逐步执行
Step 1：创建目录结构
Thought: Step 1 是基础设施，创建清晰的目录结构便于后续开发。
backend 放 Python 代码，frontend 放静态文件。
Action: execute_command("mkdir -p blog/{backend,frontend/{static/{css,js},templates}}")
Observation: [done]
状态更新: ✓ Step 1
Step 2：编写依赖文件
Thought: Step 2 无依赖，可并行执行。需要 flask 核心、
sqlalchemy 做 ORM、session 做登录状态保持。
Action: write_file("blog/backend/requirements.txt", "flask==3.0.0\n...")
Observation: created: blog/backend/requirements.txt
记忆存储: [记忆+] 创建文件 blog/backend/requirements.txt
Step 3：编写数据库模型
Thought: Step 3 依赖 Step 2 完成。设计 User 和 Post 模型，一对多关系。
Action: write_file("blog/backend/models.py", "...")
关键设计：
- User 模型：id, username, password_hash, created_at
- Post 模型：id, title, content, user_id（外键关联用户）
- 一对多关系：一个用户有多篇文章
Observation: created: blog/backend/models.py
记忆存储: [记忆+] 创建博客系统数据库模型
Step 4：编写 API 路由
依赖 Step 3 完成后，编写完整的 RESTful API：
注册路由：POST /api/register
登录路由：POST /api/login
退出路由：POST /api/logout
文章列表：GET /api/posts
创建文章：POST /api/posts
更新文章：PUT /api/posts/<id>
删除文章：DELETE /api/posts/<id>
权限控制：
- 只有登录用户才能创建文章
- 用户只能修改/删除自己的文章
Step 5-6：编写前端页面
Step 5 和 Step 6 与后端开发可以并行进行。
前端结构：
- index.html：登录表单、文章列表、发布文章
- app.js： 前端交互逻辑（fetch API 调用后端）
- style.css：页面样式
Step 7：初始化数据库并运行
Action: pip install -r requirements.txt
Action: python -c "创建数据库表"
Observation: DB initialized
记忆存储: [记忆+] 博客系统数据库初始化完成
Step 8：测试 API
测试内容：
1. 注册新用户 → 201 Created ✓
2. 用户登录 → 200 OK ✓
3. 创建文章 → 201 Created ✓
4. 查询文章 → 返回文章列表 ✓
6.5 第三阶段：最终总结
成功搭建完整博客系统！
项目结构：
blog/
├── backend/
│ ├── requirements.txt # Flask + SQLAlchemy + Session
│ ├── models.py # User, Post 模型
│ └── app.py # RESTful API（认证 + CRUD）
└── frontend/
├── static/
│ ├── css/style.css
│ └── js/app.js # 前端交互逻辑
└── templates/
└── index.html # 主页面
功能验证：
✓ 用户注册/登录（session-based 认证）
✓ 文章增删改查（RESTful API）
✓ 权限控制（只能修改自己的文章）
✓ 前后端分离（CORS 支持）
启动方式：
cd blog/backend && python app.py
七、Plan vs 无 Plan：关键对比
做到一半发现目录没建临时建目录，可能路径混乱不会，Step 1 已确保目录存在测试时发现缺依赖回头补装，打断流程不会，Step 2 已安装依赖前端写完发现后端没跑先后端启动，再重新测试前端不会，Step 7 明确在后端完成后任务中断后恢复不知道做到哪了看 Plan 状态，精确恢复
Plan 模式的核心价值一句话总结：复杂任务的"施工图纸"，确保不遗漏、顺序对、可追踪。
八、Agent 的核心执行格式
一个标准 Agent 的每一步都遵循这个格式：
Thought: [我现在的思考，为什么要做这个操作]
Action: [具体调用的工具和参数]
例如：write_file({"path": "...", "content": "..."})
execute_command({"command": "..."})
Observation: [工具返回的结果]
Remember: [需要存到记忆中的关键信息，可选]
Final Answer: [任务完成后的最终输出]
九、什么时候用哪种模式？
纯 ReAct 模式（不用 Plan）
适用场景：
- 简单的一问一答
- 只需要调用 1-2 个工具
- 不需要规划顺序的任务
例子："帮我查一下今天天气"、"把这段文字翻译成英文"
Plan-ReAct 模式
适用场景：
- 多步骤复杂任务（3 步以上）
- 步骤之间有依赖关系
- 需要用到多种不同的工具
- 任务可能被中断，需要可恢复
- 需要确保不遗漏任何步骤
例子："搭建一个博客系统"、"从零创建一个 React 项目并部署"、"分析这个数据集并生成报告"
十、总结：一张图看懂 Agent
┌──────────────────────────────────────────────────┐
│ Agent │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────────────┐ │
│ │ LLM │ │ Tools │ │ Memory │ │
│ │ (大脑) │ │ (手脚) │ │ (笔记本) │ │
│ └────┬────┘ └────┬────┘ └───────┬─────────┘ │
│ │ │ │ │
│ └────────────┼───────────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ Planning │ │
│ │ (施工图纸) │ │
│ └────────┬───────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ Execution │ │
│ │ Thought→Action │ │
│ │ →Observation │ │
│ └────────┬───────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ Summary │ │
│ │ Final Answer │ │
│ └─────────────────┘ │
└──────────────────────────────────────────────────┘
十一、下一步学习建议
- 理解 Function Call：这是 Agent 调用工具的技术基础，建议了解 OpenAI 或 Anthropic 的 Function Calling / Tool Use API 文档
- 尝试简单 Agent：用 LangChain 或直接调用 API，写一个能调用 1-2 个工具的简单 Agent
- 学习 Prompt Engineering：Agent 的行为很大程度上取决于 System Prompt 的设计
- 进阶阅读：了解 Multi-Agent（多 Agent 协作）、RAG（检索增强生成）、Agentic Workflow 等概念
笔记整理时间：2026年8月
核心参考：Plan-ReAct Agent 实战——搭建博客系统
评论与交流
评论管理 ↗