AI Agent 入门指南

AI Agent 核心概念：从零理解智能体的工作原理

AI Agent（智能体）本质上是“根据当前上下文自主决定动作序列与停止时机”的程序，其核心价值不在于大规模参数，而在于大语言模型（LLM）作为“大脑”动态掌控循环、调用工具并自主判断何时完成任务。

课程背景与核心路线

本系列视频由杨旭主讲，核心目标是使用 Rust 编程语言从零开始构建一个 AI Agent，而不是依赖任何现成的 Agent 搭建框架（如 LangGraph、CrewAI、OpenAGent 等）。

为什么选择从零构建： 现有框架虽然能帮助快速搭建 Agent，但内部真正发生的事情被隐藏了，不利于深入理解 Agent 的每个零件如何工作。本系列不使用 Python，而是 Rust，需要先了解底层原理才能更好地开发。

课程预期成果： 彻底搞清楚 AI Agent 每一个零件的工作方式——从 Agent 循环、工具调用到上下文管理等核心机制。

一、Agent 的三大分类

市面上 AI Agent 大致分为三类：

类型	代表产品	主要功能
个人助理	ChatGPT、Claude、Gemini、豆包（中国）	搜索网页、生成并执行代码、分析文档、生成图像/视频
面向客户的商业 Agent	各类处理订单/客服场景的 Agent	处理订单退款、客户问题解答等
专业垂直 Agent	Claude Code、Cursor（编码助手）；深度研究类 Agent	自主修改代码库、修复 Bug、扫描上百个来源生成报告

三者关键共同点： 底层都是大语言模型（LLM），都依赖 LLM 来做出决策。

二、大语言模型（LLM）的本质

2.1 什么是 LLM

大语言模型是在几乎所有互联网公开文本上训练出来的语言模型。虽然现在的大语言模型已经演化为能够处理图像、音频、视频等多模态输入的模型，但它们共享同一个基础的架构，因此仍可统称为 LLM。

2.2 核心原理

大语言模型的根本原理非常基础——通过处理海量文本数据来学习预测下一个词（token）。

2.3 关键能力：泛化能力

LLM 的关键在于泛化能力，即不需要针对每个任务单独训练即可完成新任务的能力：

Few-shot learning（少样本学习）： 给出几个示例即可学习新的任务模式
Zero-shot（零样本）： 即使完全不提供示例也能完成任务

这种泛化能力正是 LLM 能够充当 Agent“大脑”的根本原因——无需为每个新任务重新训练模型。

三、Agent 的定义与典型行为

3.1 研究型 Agent 的典型案例

假设一个研究型 Agent 收到用户提问：“2025年全球科研的方向是哪个方向”，它的工作流程是：

从多个来源收集信息
确定 2025 年科研的主要成就
搜索学术论文，查阅主要网站（如维基百科）
将信息综合成连续报告，说明科研成就及对 A 领域的影响

关键点： 每个步骤（先检查哪个来源、搜索结果是否足够、下一步查什么、何时开始写报告）都不是硬编码的，而是 LLM 在每个时刻根据当前上下文实时做出的决策。

3.2 Agent 的核心定义

大语言模型 Agent（AI Agent）是根据当前上下文自主决定动作序列与停止时机的程序。

3.3 传统软件 vs. AI Agent

对比维度	传统软件	AI Agent
控制流（Control Flow）	开发者事先写死在代码里（if/else、for 循环、函数调用顺序）	部分控制流的决策权交给大语言模型
决策时机	编译期/编码时已确定	运行时根据当前上下文动态决策
灵活性	固定路径	自主决定下一步与停止条件

四、Agent 的三要素

一个完整的 AI Agent 必须包含以下三个要素：

① LLM 大脑

职能：理解当前情景、决定下一步做什么
地位：Agent 的决策中枢

② 工具

背景：LLM 本身只能生成文本，无法直接与外部世界交互
作用：使 Agent 可以真正地进行网页搜索、代码执行、数据库查询等外部操作
本质：弥合大模型与实际物理/数字世界之间的鸿沟

③ 循环

大多数任务的完成不是一步就能解决的，需要反复执行迭代
什么时候停止由 LLM 自主决定，由其自行判断任务是否达成目标

五、Agent 循环（The Agent Loop）

5.1 循环存在的必要性

循环之所以必要且重要，是因为很难事先知道需要哪些工具，以及完成任务需要多少步骤。

5.2 循环的完整流程示例

以“查询 2024 年诺贝尔物理奖相关信息”为例，Agent 的工作流如下：

步骤一——评估状态： LLM 评估当前上下文，判断是否需要工具
步骤二——选择工具： 如果信息不足，根据缺失的内容决定使用哪些工具（例如：搜索“2024 年诺贝尔物理学奖”，查询约翰·霍普菲尔德与杰弗里·辛顿，查找学术论文，访问维基百科获取背景知识等）
步骤三——执行工具： 工具执行完成后产生结果
步骤四——追加上下文： 工具结果被添加回 LLM 的上下文中，丰富模型对主题的理解，累积上下文，使后续迭代中能做出更明智的决策
步骤五——判断是否循环： 评估信息是否足够；如果不够，重复步骤一至四；如果足够，LLM 自主决定停止
步骤六——生成最终报告

5.3 循环的本质意义

这种 思考（推理）→ 行动 → 观察 的迭代过程使 Agent 能够处理复杂度不可预知的任务：

简单任务可能只需一次搜索即可得到结果
复杂的研究任务可能需要数十个信息来源、经历数十次迭代循环

六、自主性级别与架构选择

将 LLM 集成到程序中时，开发者面临一个根本性架构选择：LLM 应该在多大程度上控制执行流程？

6.1 七个自主性级别

从左到右自主性递增，共七个节点：

纯代码 → 单次调用 → 链式调用 → 路由 → 工具调用 → 多步循环 → 工具创造
（工作流）────────────────────→（真正的 AI Agent）────────────────→

6.2 三个评估维度

七个节点分别从三个维度评估：

谁产生当前的输出
谁决定接下来发生什么（下一步做什么）
谁定义可用的选项

6.3 各级别详细解析

第 1 级：纯代码（传统软件）

输出、决策流程、可用选项均由开发者编写的代码决定
最不智能的一级

第 2 级：单次 LLM 调用

最基础的 LLM 集成形式：一个提示词进、一个响应出
适用于文本分类、摘要生成、翻译等功能
特定任务委托给模型，其余一切保持开发者控制
重要发现： 即使形式简单，设计良好时也能处理出人意料的复杂任务

第 3 级：链式调用

将多个 LLM 调用按预定义顺序连接；前一步输出成为下一步输入
整个流程由开发者预先设计，LLM 按流程逐步执行
设计原理： LLM 在执行专注且定义明确的任务时表现最好
案例对比：让模型“分析该文档并创建一个更好的 PPT”属于模糊任务；链式调用将其拆解为独立步骤（如先提取文档关键点→按章节组织生成 PPT 内容→润色），每个步骤更简单、更容易成功

第 4 级：路由

引入逻辑条件分支：遇到分叉点时由 LLM 决定走哪条预定义的路径
模型对用户查询进行分类，然后路由到相应处理流程/程序

第 5~6 级：工具调用与多步循环 — 真正的 AI Agent

Agent 的定义： 一种系统，其中 LLM 动态主导自己的处理过程和工具使用，掌握完成任务的主动权
两个标志性能力结合： ① 使用外部工具的工具调用能力 ② 任务完成前持续运行的自主性
工具的作用： 将外部功能（网络搜索、代码执行、数据库调用、API 调用、执行二进制文件等）暴露为可供 Agent 调用的函数
工具调用过程： LLM 审查可用工具→判断某些工具是否可能有帮助→指定工具并传入相应参数
关键区别： Agent 不是单次工具调用后就停止，而是在周期中循环运行——评估当前状态→决定行动→调用工具→获取结果→观察状态→追加到上下文→判断是否继续循环直到完成

第 7 级：工具创造

最高自主性级别：Agent 不仅从已有工具中选择，还能创造新工具
通常涉及代码生成，以实现预定域工具包中不存在的功能
例如编码 Agent 可能自主编写 Python/Node.js/PowerShell 脚本来执行特定任务（原因：提供的工具不具备该功能，或 Agent 无法在工具描述中找到合适匹配）
核心价值： 允许 Agent 动态扩展自身能力，适应设计系统时未曾预料到的需求

七、何时需要使用 Agent

AI Agent 很强大，但并非万能。需要做两层判断：

7.1 第一层：任务需要大语言模型吗？

如果任务的输入是结构化的，数据逻辑规则清晰 → 传统代码可能更快、更便宜
不需要 LLM 的场景使用 Agent 是过度设计

7.2 第二层：需要 Agent 还是单次 LLM 调用就够？

例如“把德文翻译成中文”→ 单次 LLM 调用即可解决，不需要 Agent

7.3 使用 Agent 的三个必要条件

条件	说明	不适合的案例	适合的案例
① 任务复杂度高且步骤数不确定	如果步骤可预测且流程固定，用传统方式更优	查询 A 地区人口（调用系统接口即可获得数据）	分析大语言模型对未来的影响（步骤难以预先确定）
② 任务价值足够高	需评估多次调用 LLM 的显性成本（Token 费用）和额外开销是否值得	低成本任务使用 Agent 导致亏损	值得投入调用数十万/百万/千万次 Token 的成本时
③ 错误可以被检测	Agent 犯错很常见，如果无法检测错误发生且该错误风险较高，不能使用 Agent	高风险专业场景且缺乏检测机制	有验证机制的条件下可考虑

总结： 在专业领域采用 AI Agent 应保持谨慎态度。如果存在验证机制，才可考虑使用。

八、GAIA：Agent 基准测试

8.1 基本背景

发布方： Meta 和 Hugging Face
发布时间： 2023 年
定位： 专门为需要 Agent 的任务设计的数据集/评测基准

8.2 测试内容的针对性

GAIA 收集的是以下类型的问题：

单次大语言模型调用搞不定的问题
预定义工作流也无法清晰写出的问题

→ 这些问题恰好是需要 Agent 的典型场景。

8.3 示例问题

“如果那个人以维持马拉松世界纪录的速度从地球跑到月球需要多久？”

回答此问题需要：

搜索这个“人”是谁（马拉松世界纪录保持者）
查询该人的纪录成绩是多少
搜索地球到月球的距离
进行单位换算和速度计算

8.4 选择 GAIA 作为基准的三大理由

答案清晰： 可以立即验证答案对错，支持快速迭代
难度适中： 能够完整走完开发、调试、改错的循环
无需专业知识： 以网页搜索和信息综合为主

课程计划： 在 Rust 实现每个主要特性后，都会使用 GAIA 测试来验证实际效果。

九、上下文工程（Context Engineering）

9.1 提示词（Prompt）的两大类型

提示词是用户发给大语言模型的输入文本，主要分为：

① 系统提示（System Prompt）

给系统设定人设，规定模型应该如何响应和行为
例如：“你是一个友善的编程向导”——这样模型就会以友善的方式指导编程

② 用户信息（User Message）

用户的实际需求或实际请求

9.2 上下文（Context）

上下文是比提示词更大的概念，包括：

系统提示
用户信息
历史对话
工具执行结果
检索到的文档信息

上下文的核心地位： 大语言模型在生成回复时会参考上下文中的所有信息。上下文相当于 LLM 的工作内存——模型只能基于上下文中的信息进行预测。如果关键信息不在上下文里，再聪明的模型也给出不了正确答案。

9.3 Agent 失败的两大原因

原因	说明	解决方式
① 模型智能不足	模型本身能力不够	等待更强的模型出现
② 上下文缺少必要信息	Agent 失败的更常见原因	通过上下文工程技术解决

上下文工程的定义： 在正确的时间、以正确的形式，向大语言模型提供它所需的信息。

十、上下文腐烂（Context Rot）

10.1 越多越好吗？——并非如此

当前许多模型支持 100 万 Token 的超长上下文，但研究结论表明：直接将所有信息塞进去并不正确。

10.2 核心问题

① 上下文腐烂（Context Rot）

现象：上下文长度增加，模型性能反而下降
实验数据：不同模型在不同长度的上下文下测试，所有模型都表现出性能随 Token 数量增加而下降的趋势

② 中间迷失效应（Lost in the Middle）

现象：模型倾向于忽略放在上下文中间的重要信息
影响：随着上下文长度增加，该效应更明显

10.3 正确结论

不是给大语言模型的信息越多越好，而是要精确提供高度相关的信息。这正是上下文工程要解决的核心问题。

10.4 上下文工程的五大策略

策略	核心操作	典型做法示例
生成（Generate）	利用 LLM 的输出来构造上下文	先生成计划 → 完成后反思
检索（Retrieve）	从外部获取信息并加入上下文	网页搜索、数据库搜索、文件读取
写入（Write）	将上下文信息持久化到外部	写入 Markdown 文件
压缩（Compress）	主动压缩上下文	对对话历史做摘要、删除无关信息
隔离（Isolate）	将任务或工具放入独立环境	沙箱隔离、使用专业的子 Agent

总结与下一步

本节内容核心回顾：

LLM 的本质： 预测下一个 token 的语言模型，核心价值在于泛化能力
AI Agent 的定义： 根据上下文自主决定动作序列与停止时机的程序
Agent 三要素： LLM 大脑 + 工具 + 循环
Agent 循环是实现复杂度不可预知任务处理的核心机制——思考→行动→观察→迭代
自主性七级别从纯代码逐步过渡到工具创造，其中后三级（工具调用、多步循环、工具创造）才被称为真正的 Agent
使用 Agent 需谨慎判断： 任务复杂度高、价值高、错误可检测时才适合使用
上下文工程是 Agent 成败的关键——正确的时间、以正确的形式提供需要的信息
上下文过长会引发上下文腐烂和中间迷失效应，因此信息的精准性比数量更重要
GAIA 基准用于评测 Agent 处理复杂多步任务的能力

课程预告： 第二节视频开始进入编码实战环节，使用 Rust 动手构建 AI Agent。