ai-agent教程-01-认识AI-Agent

本章目标:给 AI Agent 一个可操作的定义,厘清它与 LLM 应用 / Workflow / RAG 的边界, 拆解它的能力栈,并建立一个用于全书的分类学。

1. 什么是 AI Agent

「Agent」一词源于拉丁语 agere (去做),在人工智能领域最早用于描述自主行动的实体: 它处于某个环境之中,能通过传感器感知环境,通过执行器作用于环境,并以此达成目标。这个定义来自经典的「智能体-环境」框架(Bratman 的 BDI 模型、Russell & Norvig 的《人工智能:一种现代方法》),它不依赖大模型------机器人、游戏 AI、推荐系统都是 Agent。

**LLM Agent(大模型智能体)**是这个框架在大模型时代的具体化:

一个以大语言模型为大脑 的系统,它能够感知 (读取用户指令与工具反馈)、思考 (推理、规划、决策)、行动 (调用工具、执行代码、访问外部系统)、并在与环境的交互中迭代直至完成目标。

去掉所有修辞,一个 LLM Agent 的最小定义是三条:

有目标:用户的请求被转化为一个需要完成的任务;
能行动:不只是「回答」,而是可以通过工具改变外部世界或获取外部信息;
能迭代:行动后观察结果,根据结果决定下一步,直到目标达成或放弃。

这三个特征把 Agent 与「一次性的 LLM 调用」区分开来。一个没有工具、没有循环、只做单轮问答的聊天机器人,严格说不是 Agent------它是一个 LLM 应用。

2. 为什么是现在:Agent 的三次解锁

Agent 概念存在了几十年,为什么 2023 年之后突然爆发?因为三个能力同时成熟了:

解锁	时间	内容	后果
模型能力	2020--2023	指令遵循、CoT 推理、多步推理的模型出现	模型「读得懂」复杂指令并分解任务
对话接口	2022--2023	Chat Completion API 成为事实标准	任何程序都能低成本接入模型
工具调用	2023--2024	Function Calling 被纳入模型原生能力	模型可以结构化地请求调用工具

其中最关键的是第三个:function calling 让模型从「只会输出文本」变成「会发出行动请求」 。行动请求(tool_calls)和文本一样是模型输出的一部分,程序可以解析它、执行它、把结果回喂给模型------于是「循环」诞生了。循环一旦存在,规划、记忆、反思、多智能体协作这些更高层的能力就有了地基。

理解要点:Agent 的爆发不是某个单一模型的功劳,而是「接口标准化」的功劳。当「模型的输出可以驱动真实动作」成为平台的默认能力,Agent 就从论文变成产品。

2.1 从经典 Agent 到 LLM Agent:一条被低估的演化线

「Agent」不是一个 2023 年才发明的新词。理解它的前世,才能理解它的今生 ------LLM Agent 不是凭空出现的,它是一长串研究路线的集大成者:

时代	代表	核心思想	为什么没成为主流
1950--70 逻辑派	Shakey 机器人、STRIPS 规划	用一阶逻辑表示知识与目标,规划器求解动作序列	需要人类手写所有规则,世界稍有变化就崩
1980--90 符号派	SOAR、ACT-R、BDI 架构	「感知-推理-行动」的分层认知架构;信念-愿望-意图三要素	知识工程成本高,无法规模化
1990--2010 行为派	强化学习 Agent、机器人控制	通过试错与环境交互学策略,不依赖显式知识	需要大量环境交互,样本效率低
2010--2020 深度派	DQN、AlphaGo	深度网络做感知与决策,端到端学习	单任务专用,缺乏通用语言理解
2022-- 语言派	LLM Agent(本教程主题)	用大模型做「大脑」,语言作为通用接口,工具作为手脚	------(正在发生)

关键认识 :LLM Agent 与所有前辈的本质区别在于**「通用性」来自预训练语言模型**, 而不是手写规则或专用网络。规划(SOAR 的梦想)、感知-行动循环(强化学习的框架)、工具使用(Shakey 的机械臂)这些经典课题,在大模型时代第一次被同一个模型统一起来。

对工程师的启示:很多「LLM Agent 的新概念」其实是旧问题的重新包装------ 规划、记忆、反思、多智能体,在经典 Agent 研究里都有对应物。读旧文献能帮你识别「哪些是本质问题,哪些只是新词」。

3. Agent vs 相邻概念

这一节非常重要,因为业界对这几个词的使用极度混乱。我们给出一组可操作的区别。

3.1 Agent vs LLM 应用

维度	LLM 应用	LLM Agent
输入→输出	单次(或固定流水线)	循环:可能多次往返
是否行动	只输出文本	可以调用工具改变世界
是否自主	无,完全由代码决定流程	有,模型决定流程
失败处理	代码抛错	模型看到错误后自我修正
例子	文本分类器、翻译、摘要、单轮聊天	自主修 bug 的代码助手、自动调研机器人

判断标准:如果程序的执行路径在代码里被完全写死,它就是 LLM 应用; 如果执行路径由模型根据环境反馈动态决定,它就是 Agent。

3.2 Agent vs Workflow(工作流)

这是 Andrew Ng 在 2024 年反复强调的区别,值得全文引用:

Workflow:代码定义好每一步(「先检索、再总结、后翻译」),LLM 只负责其中的一步。流程是确定性的、可预测的、可审计的。
Agent:LLM 决定每一步做什么。流程是不确定性的,模型自主选择「是搜索还是计算, 是继续还是结束」。

关键洞察 :两者不是优劣关系,而是谱系关系 。同一个系统里, 你可以在「确定部分」用 Workflow(如必须的合规检查),在「不确定部分」用 Agent(如任务拆解)。工程上的最佳实践是:能确定就不要交给模型,不能确定才交给 Agent。这控制成本、提高可靠性与可审计性。

3.3 Agent vs RAG(检索增强生成)

RAG 是 Agent 的一种能力而非对立体:

RAG = 检索外部知识 → 拼进上下文 → 让模型基于证据回答;
Agent = 在循环中自主决定何时检索、检索什么、如何利用检索结果。

简单说:RAG 是 Agent 工具箱里的一件工具 。一个 Agent 可以拥有 search 工具, 并在需要时调用它------那它就是「Agent + RAG」。把两者对立起来是常见的错误。

3.4 Agent vs MCP / A2A

MCP(Model Context Protocol)与 A2A(Agent-to-Agent)是协议,不是 Agent:

MCP 解决「Agent 如何连接工具/数据」(Agent ↔ 工具);
A2A 解决「Agent 如何连接 Agent」(Agent ↔ Agent)。

Agent 是实现,协议是契约。实现可以用协议,也可以不用;协议服务于实现。详见第 07、08 章。

3.5 判断清单:如何识别一个系统是不是 Agent

把前面对比浓缩成一个可执行的「四问」判断法。遇到任何被称作「Agent」的系统, 按顺序问四个问题,任何一个答「否」,它就不是严格意义上的 LLM Agent:

有目标吗? 输入是「一个待完成的任务」,而不是「一个待回答的问题」?
能行动吗? 它能否通过工具/代码/外部 API 改变世界或获取外部信息? 还是只能输出文本?
能迭代吗? 行动后会观察结果、根据结果决定下一步吗?还是单次请求-响应?
路径由谁决定? 执行路径由模型根据环境反馈动态决定,还是被代码完全写死?

问题	回答「否」的含义
1. 有目标	它只是一个问答接口
2. 能行动	它只是一个 LLM 应用(聊天机器人)
3. 能迭代	它是一次性生成,没有循环
4. 路径由模型决定	它是 Workflow,不是 Agent

边界案例的诚实处理:

「有循环但没工具」------只能自我对话,不能改变世界,通常算「推理器」不算 Agent;
「有工具但路径写死」------工具由代码决定何时调,这是 Workflow 加了工具;
「模型能调工具但被强制每一步确认」------仍然是 Agent,只是低自主度 Agent (第 01 章 §5.2 的 L2 自主度),「是否自主」是谱系而不是二分。

这个判断法在全书反复使用:第 08 章判断「要不要多 Agent」、第 10 章判断「该评测什么」,都从「它到底是不是 Agent、自主度多高」出发。

4. Agent 的能力栈

一个完整的 Agent 系统,从上到下可以拆成几层(这也是后续各章的索引):

scss 复制代码

┌─────────────────────────────────────────────┐
│  应用层  具体产品形态(客服、编码助手、调研员) │  第 16 章
├─────────────────────────────────────────────┤
│  协作层  多智能体拓扑 / 通信协议(A2A)        │  第 08 章
├─────────────────────────────────────────────┤
│  认知层  规划 / 反思 / 任务分解 / 决策        │  第 02 章
├─────────────────────────────────────────────┤
│  记忆层  短期对话 / 长期向量 / 摘要 / 工作记忆 │  第 04 章
├─────────────────────────────────────────────┤
│  工具层  工具注册 / 校验 / 执行 / 集成(MCP)   │  第 03、08 章
├─────────────────────────────────────────────┤
│  模型层  LLM 接口 / function calling / 流式   │  第 03 章
├─────────────────────────────────────────────┤
│  底座层  评测 / 安全 / 可观测 / 部署          │  第 09--11 章
└─────────────────────────────────────────────┘

三个关键认识:

大脑是模型,但 Agent 不等于模型。模型是「推理引擎」,Agent 是「装了引擎的机器」。同一套 Agent 代码,换一个模型,行为可能天差地别。
工具决定能力的边界。模型再聪明,没有工具也查不了实时数据、改不了文件。「工具是否丰富、定义是否良好」往往比「模型是否强大」更影响 Agent 的实际能力。
记忆决定体验的深度。没有记忆的 Agent 每次对话都像陌生人; 有了长期记忆,Agent 才能个性化、持续学习、跨会话积累。

5. Agent 的分类学

给 Agent 分类有很多维度。这里给出四个最有用的轴。

5.1 按「记忆」分:无状态 vs 有状态

无状态 Agent:每次请求独立,不记忆过去。简单、便宜、容易横向扩展。
有状态 Agent:维护会话状态与长期记忆,能引用之前的对话与事实。复杂、贵、难扩展。

5.2 按「自主程度」分(自主性谱系)

级别	名称	描述	例子
L0	无自主	完全由代码驱动,LLM 只是组件	固定的分类流程
L1	单步自主	模型决定一次动作	一次工具调用
L2	多步自主	模型在循环中决定多步动作	标准 Agent 循环
L3	目标自主	模型自主制定并执行完整计划	长期自主运行的 Agent
L4	自适应	根据长期目标自我调整策略	未来的开放世界 Agent

绝大多数生产 Agent 处于 L1--L2。L3--L4 通常意味着更多的不可控与更贵的运行成本。

5.3 按「行动类型」分

对话 Agent:主要行动是对话(客服、助手);
工具 Agent:主要行动是调用工具(自动化、数据操作);
代码 Agent:主要行动是读写文件、执行代码(编码助手);
计算机使用 Agent:直接操作 GUI(点击、输入,类似人类操作电脑);
具身 Agent:控制机器人、自动驾驶等物理世界行动。

5.4 按「结构」分(第 08 章详述)

单 Agent:一个循环完成任务;
多 Agent 协作:编排者-工作者 / 辩论 / 市场等;
层级 Agent:父 Agent 递归拆解子任务给子 Agent(类似管理者)。

6. 一个具体例子:客服 Agent 的完整旅程

为了把抽象概念落地,全书反复使用一个贯穿例子------电商客服 Agent:

ini 复制代码

用户:我上周买的耳机没到货,能查一下吗?
  ↓
Agent 感知:理解意图 = 查询订单物流
Agent 思考:需要订单号 → 询问用户 / 或从记忆里找
  ↓
Agent 行动:调用工具 query_order(order_id="...")
  ↓
Agent 观察:返回「已发货,预计明天到达,承运商:顺丰」
  ↓
Agent 思考:信息已足够 → 组织回复
Agent 行动:回复用户 + 把订单号存入长期记忆

如果查询失败(比如订单不存在),Agent 会看到工具返回的错误,自主决定: 换一种查询方式?请求用户提供正确订单号?还是转人工? ------这个「看到失败并自我修正」的过程,就是 Agent 与 Workflow 的本质区别。

这个例子在后续章节中会不断被引用:

第 03 章:如何定义 query_order 工具;
第 04 章:如何记住用户的订单号;
第 10 章:如何评测它「服务得好不好」;
第 11 章:如何防止它被提示注入诱导退款;
第 12 章:如何部署并监控;
第 16 章:完整实现它。

7. 对照 mini-agent

在第 07 章,我们会亲手实现这些概念。提前剧透映射关系:

概念	mini-agent 代码
模型层(大脑)	`ChatProvider` 接口 + `MockProvider` / `OpenAIProvider`
工具层(手脚)	`ToolRegistry` + `createBuiltinTools` + JSON Schema 校验
记忆层	`MemoryManager` + `ConversationBuffer` + `VectorMemory`
认知层(循环/规划)	`Agent.run()` 主循环 + `Planner`
协作层	`MessageBus` + `Orchestrator`
协议层	`StdioMcpClient`(MCP 客户端)
底座层	`Tracer` + 测试套件

你可以现在就 cd mini-agent && node examples/chat.ts 跑起来, 观察那个「计算 → 记住 → 回忆 → 再计算」的循环------那就是本概念的活体。

8. 本节要点

Agent = 有目标 + 能行动 + 能迭代。三个条件缺一,严格说都不是 Agent。
Agent 的爆发源于工具调用接口的标准化,而非单一模型突破。
Workflow 与 Agent 是谱系而非对立:能确定的用代码,不能确定的交给模型。
RAG 是 Agent 的工具,不是 Agent 的对立。
Agent 的能力 = 模型 × 工具 × 记忆 × 循环,四者相乘而不是相加。
生产级判断:可预测性 > 花哨。L1--L2 自主度覆盖了绝大多数真实场景。
「四问」判断法(有目标 / 能行动 / 能迭代 / 路径由模型决定)可以识别任何自称 Agent 的系统------「自主度」是谱系不是二分。
LLM Agent 是经典 Agent 研究(规划 / 记忆 / 工具使用)的集大成者------ 「新概念」常常是旧问题的重新包装,读旧文献能帮你抓住本质。

下一章,我们深入 Agent 的核心------那个「循环」到底怎么转,规划与反思如何让它更可靠。