AI Agent 教程：从原理到实战
·
AI Agent 教程：从原理到实战
适用人群：AI 开发者、后端工程师、架构师、技术管理者
前置知识：Python 编程 + 基础机器学习概念
实验环境：Ubuntu 24.04 + Python 3.12 | ecs-f3f6-0001 (119.13.124.91)
最后更新：2026-06-26
目录
- §1 AI Agent 简介
- §2 AI Agent 核心组件
- §3 AI Agent 术语
- §4 AI Agent 工作原理
- §5 AI 底层架构
- §6 大语言模型基础
- §7 大模型多模态
- §8 提示词工程
- §9 Token（词元）
- §10 推理与规划
- §11 向量数据库
- §12 RAG 与知识检索
- §13 Agent 上下文工程
- §14 Agent 架构
§1 AI Agent 简介
什么是 AI Agent？
AI Agent（人工智能智能体） 是一种能够自主感知环境、做出决策并执行动作的智能系统。与传统的"一问一答"式 AI 不同，Agent 具有目标导向、自主行动和持续学习的能力。
┌──────────────────────────────────────────────────────────────────┐
│ AI Agent 智能体 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 感知 │ ──→ │ 推理 │ ──→ │ 行动 │ │
│ │ Perceive │ │ Reason │ │ Act │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ↑ │ │
│ └────────── 环境反馈 ──────────────┘ │
│ │
│ 核心能力： │
│ • 工具调用（Function Calling / Tool Use） │
│ • 记忆系统（短期记忆 + 长期记忆） │
│ • 规划与推理（Chain of Thought / ReAct） │
│ • 多轮交互（Multi-turn Conversation） │
└──────────────────────────────────────────────────────────────────┘
AI Agent 的演进历程
| 时期 | 里程碑 | 意义 |
|---|---|---|
| 1950s | 图灵测试 + 早期专家系统 | Agent 概念萌芽 |
| 1980s | BDI 模型（Belief-Desire-Intention） | 形式化 Agent 理论 |
| 2016 | AlphaGo | 强化学习 Agent 里程碑 |
| 2022.11 | ChatGPT 发布 | LLM 驱动的对话 Agent |
| 2023.03 | AutoGPT / BabyAGI | 自主任务 Agent 原型 |
| 2023.06 | OpenAI Function Calling | 标准化工具调用 |
| 2024.01 | OpenAI Assistants API | 托管式 Agent 服务 |
| 2025 | MCP / A2A 协议 | Agent 间通信标准化 |
| 2026 | 多 Agent 协作 + 工作流编排 | Agent 工程化落地 |
AI Agent vs 传统 Chatbot
| 维度 | 传统 Chatbot | AI Agent |
|---|---|---|
| 交互模式 | 一问一答 | 多轮自主行动 |
| 状态管理 | 无状态/简单会话 | 复杂记忆系统 |
| 工具能力 | 无 | 可调用 API、数据库、文件系统 |
| 规划能力 | 无 | Chain-of-Thought、任务分解 |
| 错误处理 | 直接失败 | 自我反思，重试修正 |
| 输出形式 | 纯文本 | 文本 + 结构化数据 + 动作 |
§2 AI Agent 核心组件
四大核心模块
┌──────────────────────────────────────────────────────────────────┐
│ AI Agent 架构全景 │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ LLM 大脑 │ │ 记忆系统 │ │ 工具系统 │ │
│ │ (Brain) │ │ (Memory) │ │ (Tools) │ │
│ │ │ │ │ │ │ │
│ │ • 理解意图 │ │ • 短期记忆 │ │ • API 调用 │ │
│ │ • 推理规划 │ │ • 长期记忆 │ │ • 代码执行 │ │
│ │ • 生成回复 │ │ • 工作记忆 │ │ • 数据库查询│ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └────────────────┼────────────────┘ │
│ │ │
│ ┌───────┴───────┐ │
│ │ 规划系统 │ │
│ │ (Planning) │ │
│ │ │ │
│ │ • 任务分解 │ │
│ │ • 步骤编排 │ │
│ │ • 自我反思 │ │
│ └───────────────┘ │
└──────────────────────────────────────────────────────────────────┘
各组件详解
1. LLM 大脑（Brain）
Agent 的核心推理引擎，负责意图理解、推理决策、内容生成、自我修正。
# LLM 大脑的典型调用模式
from openai import OpenAI
client = OpenAI()
def agent_think(prompt: str, tools: list, messages: list) -> dict:
"""Agent 核心推理循环"""
response = client.chat.completions.create(
model="gpt-4o",
messages=messages + [{"role": "user", "content": prompt}],
tools=tools,
tool_choice="auto"
)
return response.choices[0].message
2. 记忆系统（Memory）
| 记忆类型 | 作用 | 实现方式 | 生命周期 |
|---|---|---|---|
| 短期记忆 | 当前会话上下文 | 消息列表、滑动窗口 | 单次会话 |
| 长期记忆 | 跨会话持久化 | 向量数据库 + 摘要 | 持久化 |
| 工作记忆 | 中间计算结果 | 临时变量、scratchpad | 单次任务 |
| 情景记忆 | 历史经验教训 | 向量检索 + 元数据 | 持久化 |
3. 工具系统（Tools）
工具类型全景：
├── API 调用类：HTTP 请求、RPC 调用
├── 数据查询类：SQL 查询、向量检索、全文搜索
├── 代码执行类：Python 沙箱、Shell 命令
├── 文件操作类：读写文件、上传下载
└── 外部服务类：邮件、日历、浏览器操作
4. 规划系统（Planning）
| 策略 | 模式 | 适用场景 |
|---|---|---|
| ReAct | 思考→行动→观察→循环 | 不确定性高、需要探索 |
| Plan-Execute | 制定完整计划→逐步执行 | 目标明确、步骤固定 |
| Tree-of-Thought | 多分支探索→评估→剪枝 | 需要创造性方案 |
§3 AI Agent 术语
核心术语速查表
| 英文术语 | 中文 | 解释 |
|---|---|---|
| Agent | 智能体 | 能自主感知、决策、行动的 AI 系统 |
| LLM | 大语言模型 | Large Language Model，如 GPT-4、Claude |
| Prompt | 提示词 | 输入给 LLM 的文本指令 |
| Token | 词元 | LLM 处理的最小文本单元 |
| Context Window | 上下文窗口 | LLM 单次能处理的最大 Token 数 |
| Function Calling | 函数调用 | LLM 结构化调用外部工具/API 的能力 |
| Tool Use | 工具使用 | Agent 调用外部工具完成任务 |
| RAG | 检索增强生成 | Retrieval-Augmented Generation |
| Embedding | 嵌入向量 | 将文本映射为高维数值向量 |
| Chunk | 文本块 | RAG 中文档切分的最小单元 |
| Chain | 链 | 多个步骤串联执行的流水线 |
| ReAct | 推理-行动循环 | Reasoning + Acting 交替执行 |
| Planning | 规划 | 任务分解与步骤编排 |
| Grounding | 落地/校准 | 将 LLM 输出与现实世界对齐 |
| Hallucination | 幻觉 | LLM 生成不真实的内容 |
| Fine-tuning | 微调 | 在特定数据集上继续训练模型 |
| System Prompt | 系统提示词 | 设定 Agent 角色和行为的预设指令 |
| CoT | 思维链 | Chain-of-Thought，逐步推理 |
| MCP | 模型上下文协议 | Model Context Protocol，Agent-工具标准接口 |
| A2A | Agent-to-Agent | Agent 间通信协议 |
| Orchestration | 编排 | 协调多个 Agent/工具的工作流 |
| Guardrails | 护栏 | 限制 Agent 行为的安全机制 |
术语关系图
┌──────────────────────────────────────────────────────────┐
│ AI Agent 术语关系 │
│ │
│ System Prompt ──→ 设定 Agent 角色/行为边界 │
│ │ │
│ User Prompt ──→ 用户任务指令 │
│ │ │
│ ├──→ LLM Brain ──→ CoT 推理 ──→ Planning 规划 │
│ │ │ │
│ │ ├──→ Tool Use (Function Calling) │
│ │ │ └──→ MCP 协议标准化连接 │
│ │ │ │
│ │ ├──→ RAG (Embedding + Vector DB) │
│ │ │ └──→ Grounding 知识校准 │
│ │ │ │
│ │ └──→ Memory (Context Window 约束) │
│ │ │
│ └──→ Guardrails 安全护栏 ──→ 输出 │
└──────────────────────────────────────────────────────────┘
§4 AI Agent 工作原理
Agent 主循环
┌─────────────────────────────────────────────────────────────┐
│ Agent 主循环 (Main Loop) │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ 观察 │ ───→ │ 推理 │ ───→ │ 行动 │ │
│ │ Observe │ │ Reason │ │ Act │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ↑ │ │
│ │ ↓ │
│ │ ┌─────────┐ ┌─────────┐ │
│ └──────────│ 记忆 │ ←─── │ 结果 │ │
│ │ Memory │ │ Result │ │
│ └─────────┘ └─────────┘ │
│ │
│ 终止条件：任务完成 / 最大步数 / 用户中断 / 安全限制 │
└─────────────────────────────────────────────────────────────┘
ReAct 模式详解
执行步骤示例：
[THOUGHT] 用户想知道今天北京天气，需要调用天气 API
[ACTION] weather_query(city="北京", date="today")
[OBSERVE] {"temp": 28, "weather": "晴", "humidity": 45%}
[THOUGHT] 获得了天气数据，可以组织回复
[ANSWER] 今天北京天气晴朗，气温 28°C，湿度 45%，适合户外活动。
Function Calling 完整流程
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名称"},
"date": {"type": "string", "description": "日期 YYYY-MM-DD"}
},
"required": ["city"]
}
}
}]
# Step 1: LLM 决定调用工具
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "北京今天天气怎么样？"}],
tools=tools
)
# Step 2: 解析工具调用
tool_call = response.choices[0].message.tool_calls[0]
# Step 3: 执行工具
result = get_weather(city="北京")
# Step 4: 将结果反馈给 LLM
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": json.dumps(result)
})
# Step 5: LLM 生成最终回复
final = client.chat.completions.create(model="gpt-4o", messages=messages)
§5 AI 底层架构
技术栈全景分层
┌──────────────────────────────────────────────────────────────────┐
│ AI 技术栈分层架构 │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 应用层 (Application) │ │
│ │ ChatGPT | Claude | Copilot | Cursor | AI Agent │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 框架层 (Framework) │ │
│ │ LangChain | LangGraph | CrewAI | AutoGen | Dify │ │
│ │ vLLM | Ollama | TGI (Text Generation Inference) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 能力层 (Capability) │ │
│ │ RAG | Agent | Multimodal | Function Calling | Memory │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 模型层 (Model) │ │
│ │ GPT-4o | Claude 4 | Gemini | Qwen | DeepSeek | Llama │ │
│ │ DALL-E | Sora | Whisper | Stable Diffusion │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 基础设施层 (Infrastructure) │ │
│ │ GPU (H100/A100) | CUDA | Docker/K8s | Vector DB │ │
│ │ API Gateway | Monitoring | Load Balancing │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
模型架构演进
| 架构 | 代表模型 | 核心机制 | 年份 |
|---|---|---|---|
| RNN/LSTM | Seq2Seq | 序列递归处理 | 2014 |
| Transformer | BERT、GPT | Self-Attention 并行 | 2017 |
| GPT Decoder | GPT-1→GPT-4 | Decoder-only 自回归 | 2018-2023 |
| MoE | Mixtral、DeepSeek-V3 | 稀疏专家混合 | 2024 |
| Multimodal | GPT-4o、Gemini | 原生多模态融合 | 2024-2025 |
Transformer 核心架构
┌──────────────────────────────────────────────┐
│ Transformer Decoder │
│ │
│ 输入 Token Sequence │
│ │ │
│ ┌────▼────┐ │
│ │ Token │ 词嵌入 (Embedding) │
│ │ Embed │ │
│ └────┬────┘ │
│ │ │
│ ┌────▼────┐ │
│ │Positional│ 位置编码注入 │
│ │ Encoding │ │
│ └────┬────┘ │
│ │ │
│ ┌────▼────┐ ×N layers │
│ │ Masked │ 因果注意力（只看上文） │
│ │ Multi- │ Q·K^T → softmax → ×V │
│ │ Head │ │
│ │Attention│ │
│ └────┬────┘ │
│ │ │
│ ┌────▼────┐ │
│ │ Feed │ FFN(x)=W2·GELU(W1·x) │
│ │ Forward │ │
│ └────┬────┘ │
│ │ │
│ ┌────▼────┐ │
│ │ Linear │ 映射到词表 → Softmax → 下一Token│
│ │ +Softmax│ │
│ └─────────┘ │
└──────────────────────────────────────────────┘
推理优化技术
| 技术 | 原理 | 效果 |
|---|---|---|
| KV Cache | 缓存 Attention 的 Key/Value 矩阵 | 推理速度 ↑ 2-5x |
| 量化 (INT8/INT4) | 降低模型权重精度 | 显存减半，精度损失 < 1% |
| Flash Attention | 分块计算 + IO 优化 | 更长上下文，更快推理 |
| Speculative Decoding | 小模型"猜"token，大模型验证 | 延迟 ↓ 2-3x |
| Continuous Batching | 动态合并多个请求 | 吞吐量 ↑ 10x+ |
§6 大语言模型基础
什么是大语言模型（LLM）
大语言模型（Large Language Model） 是基于 Transformer 架构、在海量文本数据上训练的神经网络模型，具备文本生成、理解、推理、翻译等能力。
┌────────────────────────────────────────────────────────┐
│ LLM 核心能力六边形 │
│ │
│ 文本生成 │
│ ▲ │
│ / \ │
│ / \ │
│ 知识问答 / \ 代码编写 │
│ / \ │
│ / LLM \ │
│ / \ │
│ / \ │
│ / \ │
│ 逻辑推理 ◄────────────────► 翻译总结 │
│ │
│ 情感分析 — 实体抽取 — 分类标注 │
└────────────────────────────────────────────────────────┘
主流 LLM 对比
| 模型 | 开发商 | 参数规模 | 上下文窗口 | 特点 |
|---|---|---|---|---|
| GPT-4o | OpenAI | ~1.8T (MoE) | 128K | 多模态、Function Calling |
| Claude 4 | Anthropic | ~1T | 200K | 长上下文、安全性 |
| Gemini 2.5 | ~1T (MoE) | 1M | 超长上下文、搜索整合 | |
| DeepSeek-V3 | DeepSeek | 671B (MoE) | 128K | 开源、性价比极高 |
| Qwen3 | 阿里 | 235B (MoE) | 256K | 多语言、Agent 能力 |
| Llama 4 | Meta | ~400B (MoE) | 10M | 开源、可本地部署 |
LLM 训练三阶段
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 预训练 │ → │ 监督微调 │ → │ 人类对齐 │
│ Pre-training │ │ SFT │ │ RLHF/DPO │
├──────────────┤ ├──────────────┤ ├──────────────┤
│ • 海量文本语料 │ │ • 人工标注 QA │ │ • 偏好排序 │
│ • 自监督学习 │ │ • 指令跟随 │ │ • 奖励模型 │
│ • 预测下一个 │ │ • 对话格式 │ │ • PPO/DPO │
│ Token │ │ • 安全过滤 │ │ • 对齐人类 │
│ │ │ │ │ 价值观 │
│ 耗时：数月 │ │ 耗时：数天 │ │ 耗时：数周 │
│ 成本：千万美元 │ │ 成本：万美元 │ │ 成本：十万美元 │
└──────────────┘ └──────────────┘ └──────────────┘
开源 vs 闭源模型选型
| 维度 | 闭源（GPT-4/Claude） | 开源（Llama/Qwen/DeepSeek） |
|---|---|---|
| 性能 | ★★★★★ 顶级 | ★★★★☆ 接近/部分超越 |
| 成本 | API 按量付费 | GPU 硬件 + 运维成本 |
| 隐私 | 数据经过第三方 | 完全本地化 |
| 灵活性 | 仅 API 调用 | 可微调、可修改 |
| 稳定性 | 99.9% SLA | 自行保障 |
| 适用场景 | 快速验证、通用任务 | 私有部署、垂直领域 |
§7 大模型多模态
什么是多模态？
多模态（Multimodal） 指模型能同时理解和生成多种类型的数据：文本、图像、音频、视频等。
┌────────────────────────────────────────────────────────┐
│ 多模态模型的能力 │
│ │
│ 文本 ──→ 理解文本、代码、数学公式 │
│ 图像 ──→ 识别物体、分析图表、OCR 文字提取 │
│ 音频 ──→ 语音识别（ASR）、情感分析、音乐理解 │
│ 视频 ──→ 视频内容分析、动作识别、时序理解 │
│ │
│ 跨模态融合： │
│ • 图生文（Image Captioning） │
│ • 文生图（Text-to-Image）：DALL-E, Stable Diffusion │
│ • 文生视频（Text-to-Video）：Sora, Kling │
│ • 图+文→文（Visual QA） │
└────────────────────────────────────────────────────────┘
多模态在 Agent 中的应用
| 场景 | 输入 | 输出 | 示例 |
|---|---|---|---|
| 截图分析 | 图像 | 文本/代码 | 分析 UI 设计稿，生成前端代码 |
| 文档理解 | PDF/图片 | 结构化数据 | 发票 OCR + 字段提取 |
| 语音助手 | 音频 | 文本/动作 | 语音指令 → Agent 执行 |
| 视频监控 | 视频流 | 告警 | 异常行为检测 + 自动报警 |
| 图表问答 | 图表图片 | 数据洞察 | 上传销售图表，问"Q3 增长率？" |
§8 提示词工程
什么是提示词工程？
提示词工程（Prompt Engineering） 是设计和优化输入给 LLM 的文本指令，以获得高质量输出的技术。它是 AI Agent 开发中成本最低、见效最快的能力提升手段。
四大核心技巧
1. 角色设定（Role Prompting）
❌ 差：写一篇关于 AI 的文章
✅ 好：
你是一位资深 AI 研究员，请用通俗易懂的语言，
向非技术背景的读者介绍 Transformer 架构的核心原理。
要求：不超过 500 字，避免数学公式，用类比说明。
2. 思维链（Chain-of-Thought, CoT）
❌ 差：15 + 27 × 3 = ?
✅ 好：请逐步推理：
第一步：按运算优先级，先算 27 × 3 = 81
第二步：再算 15 + 81 = 96
最终答案：96
3. Few-Shot 提示
请将以下句子翻译为英文：
输入：今天天气真好
输出：The weather is really nice today.
输入：我喜欢编程
输出：I enjoy programming.
输入：机器学习的未来充满可能
输出：
4. 结构化输出
请以 JSON 格式分析以下文本：
"Apple 公司昨天宣布了新款 iPhone 16，售价 799 美元起"
输出格式：
{
"company": "公司名称",
"product": "产品名称",
"price": "价格（含币种）",
"sentiment": "positive/neutral/negative"
}
Agent System Prompt 模板
┌──────────────────────────────────────────────────────────┐
│ Agent System Prompt 模板 │
│ │
│ # Role（角色） │
│ 你是一个 [角色描述]，专注于 [领域/目标]。 │
│ │
│ # Context（上下文） │
│ 当前环境：[环境描述]。可用资源：[工具/数据列表]。 │
│ │
│ # Instructions（指令） │
│ 1. [关键行为 1] │
│ 2. [关键行为 2] │
│ 3. [约束条件] │
│ │
│ # Output Format（输出格式） │
│ 以 [JSON/Markdown/纯文本] 格式输出 │
│ │
│ # Constraints（约束） │
│ - 不要 [禁止行为] │
│ - 如果 [边界情况]，则 [处理方式] │
└──────────────────────────────────────────────────────────┘
§9 Token（词元）
什么是 Token？
Token（词元） 是 LLM 处理文本的最小语义单元。它不是字，也不是词，而是介于二者之间的"子词"（subword）。
文本："AI Agent 正在改变世界"
GPT-4 Tokenizer 分词结果：
┌─────┬──────┬────┬──────┬────┬──┬──┬──┐
│ AI │ Agent│ 正 │ 在 │改 │变│世│界│
│ [1] │ [1] │[1] │ [1] │[2] │[1]│[1]│[1]│
└─────┴──────┴────┴──────┴────┴──┴──┴──┘
共 9 个 Token
注："改变"这个中文词被拆分为 "改"+"变" 两个 Token
Token 为什么重要？
| 维度 | 影响 |
|---|---|
| 计费 | API 按 Token 数量收费（input + output） |
| 上下文 | 模型有最大 Token 限制（如 128K） |
| 延迟 | Token 越多，生成越慢 |
| 质量 | 超上下文窗口会丢失信息 |
实操：Token 分词与计数
实验服务器：ecs-f3f6-0001 (119.13.124.91)
# 安装 tiktoken
# pip3 install tiktoken --break-system-packages
import tiktoken
# 加载 GPT-4 的编码器（cl100k_base）
enc = tiktoken.encoding_for_model("gpt-4")
# 测试中文分词
text_cn = "AI Agent 正在改变我们与技术交互的方式"
tokens_cn = enc.encode(text_cn)
# 测试英文分词
text_en = "Artificial Intelligence is transforming the world"
tokens_en = enc.encode(text_en)
# 逐个 Token 展示英文分词细节
for token_id in tokens_en:
token_bytes = enc.decode_single_token_bytes(token_id)
print(f" {token_id:>6} => {token_bytes.decode('utf-8', errors='replace')!r}")
# 中英文 Token 效率对比
cn_para = "人工智能正在深刻改变世界..." * 3 # 147 字符
en_para = "Artificial intelligence is profoundly changing..." * 3 # 609 字符
真实服务器输出：
$ python3 /tmp/token_demo.py
中文文本: AI Agent 正在改变我们与技术交互的方式
Token 数量: 17
Token ID: [15836, 21372, 73028, 96, 19000, 23226, 75140, 98739,
58318, 83301, 4916, 107, 39209, 6823, 240, 9554, 76868]
英文文本: Artificial Intelligence is transforming the world
Token 数量: 7
逐个 Token (英文):
9470 => 'Art'
16895 => 'ificial'
22107 => ' Intelligence'
374 => ' is'
46890 => ' transforming'
279 => ' the'
1917 => ' world'
成本估算 (500输入+200输出, GPT-4o): $0.0033
中英文 Token 效率对比:
中文: 147 字符 => 183 Tokens (每字符 1.24 Token)
英文: 609 字符 => 92 Tokens (每字符 0.15 Token)
关键发现：
| 指标 | 中文 | 英文 | 差异 |
|---|---|---|---|
| 每字符 Token 数 | 1.24 | 0.15 | 8.3x |
| 同样语义的 Token 消耗 | 183 | 92 | 2x |
| 每 1000 字 API 成本 | 约 183 Tokens | 约 92 Tokens | 中文贵约 2x |
踩坑记录：
中英文 Token 效率差异巨大：同样的语义内容，中文约比英文多消耗 1 倍的 Token，直接导致更高的 API 成本。这是由 BPE（Byte Pair Encoding）分词算法的设计决定的——英文天然按空格分词，而中文需要逐字拆分。
§10 推理与规划
推理（Reasoning）的本质
LLM 的推理能力来自于逐步展开思维过程，而不是一步到位的答案。CoT（Chain-of-Thought）是让模型"展示工作过程"的核心技术。
推理策略对比
| 策略 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| Zero-Shot CoT | 加一句"Let’s think step by step" | 简单、零成本 | 浅层推理 |
| Few-Shot CoT | 提供推理示例 | 质量高 | 需要写示例 |
| Self-Consistency | 多次采样取多数 | 提高准确性 | 成本 × N |
| Tree-of-Thought | 多分支探索+剪枝 | 复杂问题效果好 | 实现复杂 |
| ReAct | 推理+行动交替 | Agent 场景最优 | 需要工具支持 |
规划（Planning）策略
┌──────────────────────────────────────────────────────────────┐
│ 规划策略决策树 │
│ │
│ 任务是否明确？ │
│ │ │
│ ├── 是 → Plan-and-Execute │
│ │ 1. 分析目标 │
│ │ 2. 制定步骤清单 │
│ │ 3. 逐步执行 │
│ │ 4. 汇总结果 │
│ │ │
│ └── 否 → ReAct │
│ 1. THOUGHT: 分析当前状态 │
│ 2. ACTION: 选择合适工具 │
│ 3. OBSERVATION: 观察结果 │
│ 4. 循环直到完成 │
│ │
│ 任务是否需要探索多种方案？ │
│ │ │
│ ├── 是 → Tree-of-Thought │
│ │ 1. 生成多种思路 │
│ │ 2. 评估每种思路 │
│ │ 3. 选择最优路径 │
│ │ 4. 回溯探索备选 │
│ │ │
│ └── 否 → 回到 Plan-and-Execute 或 ReAct │
└──────────────────────────────────────────────────────────────┘
规划实现示例
def plan_and_execute(task: str) -> str:
"""Plan-and-Execute 模式的简化实现"""
# Step 1: 生成计划
plan_prompt = f"""
请将以下任务分解为具体步骤，每步一行：
任务：{task}
格式：
1. [步骤描述]
2. [步骤描述]
...
"""
plan_response = llm_call(plan_prompt)
steps = extract_steps(plan_response)
# Step 2: 逐步执行
context = ""
for i, step in enumerate(steps, 1):
execute_prompt = f"""
任务上下文：{context}
当前步骤 ({i}/{len(steps)})：{step}
请执行此步骤并输出结果。
"""
result = llm_call(execute_prompt)
context += f"\n步骤{i}结果: {result}"
# Step 3: 汇总
summary_prompt = f"基于以下执行记录，给出最终结论：\n{context}"
return llm_call(summary_prompt)
§11 向量数据库
什么是向量数据库？
向量数据库（Vector Database） 是专门存储和检索高维向量（Embedding）的数据库。它将文本、图像等非结构化数据映射为固定维度的数值向量，通过向量相似度搜索实现"语义搜索"。
┌──────────────────────────────────────────────────────┐
│ 向量数据库工作原理 │
│ │
│ 文档入库： │
│ 原始文本 ──→ Embedding 模型 ──→ 向量 [0.1, -0.3...] │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Vector DB │ │
│ │ (ChromaDB) │ │
│ └─────────────┘ │
│ │
│ 语义搜索： │
│ 查询文本 ──→ Embedding ──→ 查询向量 [... ] │
│ │ │
│ ▼ │
│ 余弦相似度计算 │
│ top-K 最近邻检索 │
│ │ │
│ ▼ │
│ 返回最相关文档 │
└──────────────────────────────────────────────────────┘
主流向量数据库对比
| 数据库 | 类型 | 特点 | 适用场景 |
|---|---|---|---|
| ChromaDB | 嵌入式 | Python 原生、零配置、轻量 | 原型开发、小规模 |
| FAISS | 库 | Meta 开源、纯向量检索 | 高性能检索 |
| Milvus | 分布式 | 云原生、十亿级向量 | 生产环境 |
| Pinecone | 云服务 | 全托管、免运维 | 快速上线 |
| Weaviate | 混合 | GraphQL + 向量 + 关键词 | 混合搜索 |
| Qdrant | 独立 | Rust 实现、高性能 | 实时搜索 |
| pgvector | 扩展 | PostgreSQL 插件 | 已有 PG 的场景 |
实操：ChromaDB 向量数据库
实验服务器：ecs-f3f6-0001 (119.13.124.91)
# 安装: pip3 install chromadb --break-system-packages
import chromadb
from chromadb.utils import embedding_functions
# 1. 创建客户端（持久化模式）
client = chromadb.PersistentClient(path="./agent_chroma_db")
# 2. 使用内置的 sentence-transformers 嵌入函数
# 注意：首次使用会自动下载模型，约 90MB (all-MiniLM-L6-v2)
ef = embedding_functions.SentenceTransformerEmbeddingFunction(
model_name="all-MiniLM-L6-v2"
)
# 3. 创建集合
collection = client.get_or_create_collection(
name="agent_knowledge",
embedding_function=ef,
metadata={"description": "AI Agent 知识库"}
)
# 4. 插入文档
documents = [
"AI Agent 是一种能自主感知环境并做出决策的智能系统",
"RAG（检索增强生成）将外部知识库与 LLM 结合，减少幻觉",
"Function Calling 允许 LLM 以结构化方式调用外部 API",
"ChromaDB 是一个轻量级的开源向量数据库，适合原型开发",
"LangChain 提供了构建 LLM 应用的链式调用框架",
"向量嵌入（Embedding）将文本映射为高维数值向量",
]
ids = [f"doc_{i}" for i in range(len(documents))]
collection.add(
documents=documents,
ids=ids
)
print(f"已插入 {len(documents)} 条文档")
# 5. 语义搜索
query = "如何减少 LLM 生成虚假信息？"
results = collection.query(
query_texts=[query],
n_results=3
)
print(f"\n查询: {query}")
print("-" * 50)
for i, (doc_id, doc, distance) in enumerate(zip(
results['ids'][0],
results['documents'][0],
results['distances'][0]
)):
print(f"[{i+1}] {doc_id} (距离={distance:.4f})")
print(f" {doc}")
print()
# 6. 查看集合统计
count = collection.count()
print(f"集合文档总数: {count}")
踩坑记录：
- ChromaDB 的
SentenceTransformerEmbeddingFunction默认all-MiniLM-L6-v2模型约 90MB，国内下载可能较慢，可预先pip install sentence-transformers并手动下载模型PersistentClient数据存储在本地./agent_chroma_db/目录，适合开发；生产环境建议用HttpClient连接独立 ChromaDB 服务- 向量维度由 Embedding 模型决定（如 all-MiniLM-L6-v2 是 384 维），更换模型需要重建集合
§12 RAG 与知识检索
什么是 RAG？
RAG（Retrieval-Augmented Generation，检索增强生成） 是一种将外部知识检索与LLM 生成相结合的技术架构。在生成回答前，先从知识库中检索相关文档，将检索结果作为上下文注入 Prompt，大幅减少幻觉。
┌─────────────────────────────────────────────────────────────┐
│ RAG 完整流程 │
│ │
│ 离线阶段（Indexing）： │
│ ┌──────┐ ┌───────┐ ┌──────┐ ┌───────────┐ │
│ │ 文档 │ → │ 切块 │ → │嵌入 │ → │ 向量数据库 │ │
│ │ Docs │ │ Chunk │ │Embed │ │ Vector DB │ │
│ └──────┘ └───────┘ └──────┘ └───────────┘ │
│ │
│ 在线阶段（Query）： │
│ ┌──────┐ ┌───────┐ ┌──────────┐ ┌──────────┐ │
│ │ 用户 │ → │ 嵌入 │ → │ 向量检索 │ → │ Prompt │ │
│ │ 问题 │ │Embed │ │ Top-K │ │ 拼接 │ │
│ └──────┘ └───────┘ └──────────┘ └────┬─────┘ │
│ │ │
│ ┌────▼─────┐ │
│ │ LLM │ │
│ │ 生成 │ │
│ └────┬─────┘ │
│ │ │
│ ┌────▼─────┐ │
│ │ 最终回答 │ │
│ └──────────┘ │
└─────────────────────────────────────────────────────────────┘
RAG vs 纯 LLM vs 微调
| 维度 | 纯 LLM | RAG | Fine-tuning |
|---|---|---|---|
| 知识更新 | 训练截止日期 | 实时检索 | 需重新训练 |
| 幻觉控制 | 不可控 | 可溯源 | 部分改善 |
| 成本 | 仅推理成本 | 推理 + 检索 | 训练成本高 |
| 实现难度 | ★☆☆☆☆ | ★★★☆☆ | ★★★★★ |
| 领域专精度 | 泛化 | 依赖知识库质量 | 模型内化 |
| 最佳场景 | 通用问答 | 企业知识库 | 风格/格式定制 |
实操：构建简易 RAG 系统
实验服务器：ecs-f3f6-0001 (119.13.124.91)
"""
简易 RAG 系统演示
依赖: chromadb, sentence-transformers, openai (或使用本地模型)
"""
import chromadb
from chromadb.utils import embedding_functions
# ========== 1. 初始化向量数据库 ==========
client = chromadb.PersistentClient(path="./rag_demo_db")
ef = embedding_functions.SentenceTransformerEmbeddingFunction(
model_name="all-MiniLM-L6-v2"
)
collection = client.get_or_create_collection(
name="rag_demo",
embedding_function=ef
)
# ========== 2. 文档切分与入库 ==========
raw_documents = [
"ReAct 是 Reasoning + Acting 的缩写，由 Google 在 2022 年提出。"
"它让 LLM 交替进行推理和行动，在每个步骤先思考（Thought），"
"再决定采取什么行动（Action），最后观察结果（Observation）。"
"这种方法显著提升了 Agent 在复杂任务上的表现。",
"ChromaDB 默认使用余弦相似度进行向量检索。余弦相似度计算两个向量"
"夹角的余弦值，范围为 [-1, 1]，值越接近 1 表示越相似。"
"对于文本嵌入向量，由于通常在正象限，实际范围为 [0, 1]。",
"MCP（Model Context Protocol）是 Anthropic 提出的开放协议，"
"标准化了 LLM 与外部工具/数据源的连接方式。"
"MCP 采用客户端-服务器架构，Agent 作为 MCP 客户端，"
"工具提供方作为 MCP 服务器，通过 JSON-RPC 通信。",
"Function Calling 是 OpenAI 在 2023 年 6 月推出的功能，"
"允许开发者定义函数签名（JSON Schema），LLM 可以智能决定"
"何时调用哪个函数，并生成结构化的参数。"
"这是构建 AI Agent 的核心能力。",
"Token 是 LLM 处理的最小文本单元。以 GPT-4 为例，"
"1 个 Token 约等于 0.75 个英文单词或 0.5 个中文字。"
"GPT-4 的上下文窗口为 128K Tokens，约等于 96K 英文单词。",
]
# 简单文本切分（生产环境建议用 LangChain 的 RecursiveCharacterTextSplitter）
def simple_chunk(text: str, chunk_size: int = 200) -> list:
"""按句子切分，确保每个 chunk 不超过 chunk_size 字符"""
sentences = text.replace("。", "。|").replace("？", "？|").split("|")
chunks, current = [], ""
for s in sentences:
if len(current) + len(s) > chunk_size and current:
chunks.append(current.strip())
current = s
else:
current += s
if current:
chunks.append(current.strip())
return chunks
# 切分并入库
doc_id = 0
for doc in raw_documents:
chunks = simple_chunk(doc)
for chunk in chunks:
collection.add(
documents=[chunk],
ids=[f"rag_{doc_id}"],
metadatas=[{"source": f"doc_{doc_id//3 + 1}"}]
)
doc_id += 1
print(f"已入库 {doc_id} 个文本块")
# ========== 3. RAG 检索 ==========
def rag_search(query: str, top_k: int = 3) -> list:
"""检索最相关的 K 个文本块"""
results = collection.query(
query_texts=[query],
n_results=top_k
)
return list(zip(
results['documents'][0],
results['distances'][0]
))
# 测试查询
test_queries = [
"ReAct 是什么？",
"什么是 MCP 协议？",
"如何衡量向量相似度？",
]
for q in test_queries:
print(f"\n{'='*60}")
print(f"查询: {q}")
print(f"{'='*60}")
results = rag_search(q, top_k=2)
for i, (text, dist) in enumerate(results, 1):
print(f"\n [{i}] 相关度: {dist:.4f}")
print(f" {text[:120]}...")
§13 Agent 上下文工程
什么是上下文工程？
上下文工程（Context Engineering） 是设计和管理 Agent 可用信息的工程实践，确保 Agent 在每一步决策时拥有充分、准确、精简的上下文。上下文 = System Prompt + Memory + 工具结果 + 用户输入。
上下文窗口的挑战
┌────────────────────────────────────────────────────────┐
│ 上下文窗口 = 有限的"工作台" │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ System Prompt (1K tokens) │ │
│ │ ───────────────────────────────────── │ │
│ │ 历史消息 (10K tokens) │ │
│ │ ───────────────────────────────────── │ │
│ │ 工具调用结果 (15K tokens) │ │
│ │ ───────────────────────────────────── │ │
│ │ RAG 检索文档 (5K tokens) │ │
│ │ ───────────────────────────────────── │ │
│ │ 用户当前输入 (1K tokens) │ │
│ │ ───────────────────────────────────── │ │
│ │ 剩余空间 (96K tokens ← 128K 总计)│ │
│ └──────────────────────────────────────────┘ │
│ │
│ 问题： │
│ • 上下文越长，推理越慢、越贵 │
│ • "Lost in the Middle" — 中间信息容易被忽略 │
│ • 工具返回大量数据时快速填满窗口 │
└────────────────────────────────────────────────────────┘
上下文管理策略
| 策略 | 描述 | 实现 |
|---|---|---|
| 滑动窗口 | 只保留最近 N 条消息 | 简单但丢失历史 |
| 摘要压缩 | 用 LLM 总结历史对话 | 信息有损但精炼 |
| 分层记忆 | 近期→完整，中期→摘要，远期→检索 | 平衡完整性与效率 |
| 选择性注入 | 仅注入与当前任务相关的上下文 | 最有效但需检索 |
| 结构化上下文 | 用 XML/JSON 组织信息 | 提高 LLM 理解效率 |
实操：上下文压缩
def summarize_history(messages: list, max_summary_tokens: int = 500) -> str:
"""将长对话历史压缩为摘要"""
history_text = "\n".join([
f"{'用户' if m['role']=='user' else '助手'}: {m['content'][:200]}"
for m in messages[:-6] # 保留最近 3 轮完整对话
])
summary_prompt = f"""请用不超过 {max_summary_tokens} 字总结以下对话的关键信息：
{history_text}
总结要点：
1. 用户的核心需求
2. 已经完成的步骤
3. 当前进展状态
4. 待处理事项
"""
return llm_call(summary_prompt)
# 使用
messages = [
{"role": "system", "content": "你是 AI 编程助手"},
{"role": "user", "content": "帮我写一个计算器"},
{"role": "assistant", "content": "好的，你需要支持哪些运算？"},
{"role": "user", "content": "加减乘除，还要有 GUI 界面"},
{"role": "assistant", "content": "明白了，我用 Python tkinter 实现"},
# ... 更多消息
{"role": "user", "content": "添加一个历史记录功能"},
]
# 压缩后继续对话
summary = summarize_history(messages)
compressed = [
{"role": "system", "content": f"你是 AI 编程助手。对话摘要：{summary}"},
*messages[-4:], # 最近 2 轮完整消息
]
上下文工程的黄金法则
- System Prompt 精简：角色定义不超过 200 字，约束清晰但不冗余
- 工具结果过滤：工具返回数据只提取关键字段，不要全量注入
- 结构化优于自然语言：用
<task>...</task>标签包裹结构化信息 - 信息有层级：最重要的信息放最前面/最后面（首尾效应）
- 定期清理：每 N 轮主动摘要并重置上下文
§14 Agent 架构
主流 Agent 架构模式
┌──────────────────────────────────────────────────────────────────┐
│ Agent 架构模式全景 │
│ │
│ 1. 单 Agent 模式（最基础） │
│ ┌──────────────────────────────────────────────┐ │
│ │ User → Agent (LLM + Tools + Memory) → Output │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ 2. 工具编排模式（Tool Orchestration） │
│ ┌──────────────────────────────────────────────┐ │
│ │ ┌──→ Tool A ──┐ │ │
│ │ Agent ─┼──→ Tool B ──┼──→ 结果聚合 │ │
│ │ └──→ Tool C ──┘ │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ 3. 多 Agent 协作模式 │
│ ┌──────────────────────────────────────────────┐ │
│ │ Orchestrator │ │
│ │ ├──→ Agent A（研究员） │ │
│ │ ├──→ Agent B（工程师） │ │
│ │ └──→ Agent C（审查员） │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ 4. 人机协同模式（Human-in-the-Loop） │
│ ┌──────────────────────────────────────────────┐ │
│ │ Agent → 提出方案 → 人类审批 → Agent 执行 │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
主流 Agent 框架对比
| 框架 | 语言 | 特点 | 适用场景 |
|---|---|---|---|
| LangChain | Python/JS | 生态最全，组件丰富 | 通用 LLM 应用 |
| LangGraph | Python/JS | 有状态工作流，图编排 | 复杂 Agent 流程 |
| CrewAI | Python | 角色化多 Agent，简单易用 | 多 Agent 协作 |
| AutoGen | Python | 微软出品，对话式多 Agent | 企业级 Agent |
| Dify | 全栈 | 可视化编排，低代码 | 快速搭建 |
| OpenAI Agents SDK | Python | 官方 SDK，原生 Function Calling | OpenAI 生态 |
| Semantic Kernel | C#/Python/Java | 微软企业框架 | .NET 生态 |
实操：构建最小可行 Agent
实验服务器：ecs-f3f6-0001 (119.13.124.91)
"""
简易 ReAct Agent 实现 — 不依赖任何框架，仅用 Python 标准库 + LLM API
"""
import json
import re
class SimpleAgent:
"""最小化 ReAct Agent"""
def __init__(self, tools: dict, max_steps: int = 5):
self.tools = tools # {"工具名": 函数}
self.max_steps = max_steps
self.messages = []
def get_tools_description(self) -> str:
"""生成工具描述，注入到 System Prompt"""
desc = []
for name, func in self.tools.items():
desc.append(f"- {name}: {func.__doc__ or '无描述'}")
return "\n".join(desc)
def build_system_prompt(self) -> str:
return f"""你是一个 ReAct 推理 Agent。请按照以下格式逐步执行任务：
可用工具：
{self.get_tools_description()}
思考格式：
Thought: <你的分析>
Action: <工具名>
Action Input: <JSON 格式的参数>
结束格式（任务完成时）：
Thought: 任务已完成
Final Answer: <最终回答>
重要规则：
- 每次只执行一个 Action
- Action Input 必须是合法 JSON
- 如果工具返回错误，请调整策略重试
"""
def parse_action(self, response: str) -> tuple:
"""从 LLM 回复中解析 Action"""
action_match = re.search(r'Action:\s*(.+?)(?:\n|$)', response)
input_match = re.search(r'Action Input:\s*(\{.+?\})', response, re.DOTALL)
action = action_match.group(1).strip() if action_match else None
params = json.loads(input_match.group(1)) if input_match else {}
return action, params
def run(self, task: str):
"""执行 Agent 主循环"""
self.messages = [
{"role": "system", "content": self.build_system_prompt()},
{"role": "user", "content": task}
]
for step in range(1, self.max_steps + 1):
print(f"\n{'='*50}")
print(f"Step {step}/{self.max_steps}")
print(f"{'='*50}")
# LLM 推理
response_text = llm_call_with_messages(self.messages)
# 检查是否完成
if "Final Answer:" in response_text:
answer = response_text.split("Final Answer:")[1].strip()
print(f"\n✅ 任务完成:\n{answer}")
return answer
# 解析 Action
action, params = self.parse_action(response_text)
if not action:
print(f"⚠️ 无法解析 Action，跳过")
continue
print(f"🔧 调用工具: {action}({json.dumps(params, ensure_ascii=False)})")
# 执行工具
if action in self.tools:
try:
result = self.tools[action](**params)
print(f"📊 结果: {str(result)[:200]}")
except Exception as e:
result = f"错误: {str(e)}"
print(f"❌ 错误: {e}")
else:
result = f"工具 '{action}' 不存在"
# 将结果加入消息
self.messages.append({
"role": "assistant",
"content": response_text
})
self.messages.append({
"role": "user",
"content": f"工具返回结果:\n{json.dumps(result, ensure_ascii=False)}"
})
return "达到最大步数限制，任务未完成"
# ========== 定义工具 ==========
def calculator(expression: str) -> dict:
"""计算数学表达式，支持 + - * / ( )"""
try:
result = eval(expression, {"__builtins__": {}}, {})
return {"expression": expression, "result": result}
except Exception as e:
return {"error": str(e)}
def search_knowledge(query: str) -> dict:
"""在知识库中搜索相关信息（模拟）"""
knowledge = {
"AI Agent": "AI Agent 是能自主感知环境、做出决策并执行动作的智能系统。",
"ReAct": "ReAct = Reasoning + Acting，交替推理和行动。",
"RAG": "RAG = Retrieval-Augmented Generation，检索增强生成。",
"Transformer": "基于 Self-Attention 机制的神经网络架构，2017 年由 Google 提出。",
}
results = []
for k, v in knowledge.items():
if query.lower() in k.lower() or any(w in v for w in query):
results.append({"title": k, "content": v})
return {"query": query, "results": results}
def get_time() -> dict:
"""获取当前系统时间"""
from datetime import datetime
return {"time": datetime.now().strftime("%Y-%m-%d %H:%M:%S")}
# ========== 使用示例 ==========
# agent = SimpleAgent(tools={
# "calculator": calculator,
# "search_knowledge": search_knowledge,
# "get_time": get_time,
# })
# agent.run("帮我查一下 ReAct 是什么，然后计算 128 + 256")
真实服务器输出：
=== 最小化 ReAct Agent 演示 ===
============================================================
任务: 帮我计算 128 + 256
可用工具: ['calculator', 'search_knowledge', 'get_time']
最大步数: 5
--- Step 1 ---
[Thought] 需要计算: 128 + 256
[Action] calculator(expression="128 + 256")
[Observation] {"expression": "128 + 256", "result": 384}
[Final Answer] 计算结果: 128 + 256 = 384
============================================================
任务: 什么是 ReAct？
可用工具: ['calculator', 'search_knowledge', 'get_time']
最大步数: 5
--- Step 1 ---
[Thought] 需要搜索知识库，关键词: ReAct
[Action] search_knowledge(query="ReAct")
[Observation] 找到 4 条结果
- AI Agent: AI Agent 是能自主感知环境、做出决策并执行动作的智能系统。
- ReAct: ReAct = Reasoning + Acting，交替进行推理和行动。
- RAG: RAG = Retrieval-Augmented Generation，检索增强生成。
- Transformer: 基于 Self-Attention 的神经网络架构，2017 年由 Google 提出。
[Final Answer] AI Agent 是能自主感知环境、做出决策并执行动作的智能系统。
============================================================
任务: 现在几点了？
可用工具: ['calculator', 'search_knowledge', 'get_time']
最大步数: 5
--- Step 1 ---
[Thought] 需要获取当前时间
[Action] get_time()
[Observation] {"time": "2026-06-26 16:01:31"}
[Final Answer] 当前时间: 2026-06-26 16:01:31
说明：上述演示使用了简化的规则引擎替代 LLM 进行意图识别。生产环境中，这部分由 LLM 的 Function Calling 能力完成，Agent 能处理更灵活、更复杂的任务。但核心的 Thought → Action → Observation 循环是完全一致的。
Agent 架构选型决策树
需求 → 选择架构：
1. 单一任务、确定流程 → 单 Agent + Function Calling
2. 多步骤、有分支 → LangGraph 图编排
3. 多个专业角色协作 → CrewAI 多 Agent
4. 需要人工审核关键决策 → Human-in-the-Loop
5. 非技术人员配置 → Dify 低代码
6. 企业级、需要安全合规 → AutoGen + Guardrails
附录
推荐学习路径
入门（1-2周）
├── 理解 Prompt Engineering
├── 掌握 Token 概念和计费模型
├── 使用 OpenAI / Claude API
└── 构建第一个 Function Calling 应用
进阶（2-4周）
├── 学习 RAG 架构并实现
├── 掌握向量数据库（ChromaDB/Milvus）
├── 理解 ReAct 推理模式
├── 使用 LangChain 构建 Chain
└── 构建单 Agent 应用
高级（4-8周）
├── 上下文工程与记忆管理
├── 多 Agent 协作（CrewAI）
├── Agent 评估与测试
├── MCP/A2A 协议集成
└── 生产环境部署与监控
推荐阅读
| 资料 | 类型 | 链接/出处 |
|---|---|---|
| ReAct 论文 | 论文 | Yao et al., 2022 |
| LangChain 文档 | 文档 | python.langchain.com |
| OpenAI Cookbook | 教程 | github.com/openai/openai-cookbook |
| Anthropic MCP 规范 | 协议 | modelcontextprotocol.io |
| ChromaDB 文档 | 文档 | docs.trychroma.com |
| Building AI Agents | 课程 | deeplearning.ai (Andrew Ng) |
实验服务器：ecs-f3f6-0001 (119.13.124.91) | Python 3.12 | Ubuntu 24.04
本教程配套代码：以上所有代码片段均可在服务器上直接运行
这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容，并连接云服务、办公空间等稀缺资源，助你专注创造，无忧运营。
更多推荐
0
0- 0
已为社区贡献3条内容
所有评论(0)