Agent基础导读-从自动化脚本到自主智能体
> **本章阅读时间**：约2.5小时（共20篇）
Agent 基础导读：从自动化脚本到自主智能体
本章阅读时间：约2.5小时（共20篇）
对产品经理/业务人员的价值：Agent 是让 AI 从"回答问题"升级到"完成任务"的技术。读完本章导读，你能判断你的产品场景是否适合用 Agent，以及需要注意哪些风险。
AI Agent 是一个以 LLM 为核心推理引擎、能够自主感知环境、规划行动并调用工具完成目标的系统。AWS 的权威定义将其描述为：与环境交互、收集数据、执行满足预定目标的自主任务的软件程序——人类设定目标，AI 代理独立选择最佳行动方案。
它和传统程序的根本区别在于：传统程序的决策逻辑由开发者预先编码，Agent 的决策由模型在运行时推理生成。它和普通 LLM 的根本区别在于：普通 LLM 只能"说"（生成文字回答），而 Agent 能"做"（感知环境、调用工具、持续循环直到完成目标）。
为什么需要 Agent？因为现实世界的任务往往无法预先枚举所有情况。当任务需要多步骤、动态决策、工具协作时，固定逻辑的自动化脚本会失效，而 Agent 能够根据上下文自主调整执行策略。
本章是 LLM 应用开发体系的综合应用层。在理解了 LLM 基础、API 调用、Prompt 工程、工具调用和 RAG 之后，本章把这些能力整合成一个完整的 Agent 系统设计框架。
1.1 AI Agent 是什么
官方定义（来自 Anthropic《Building Effective Agents》）：
Agents are systems where LLMs dynamically direct their own processes and tool usage.
Agent 是由 LLM 动态指导自身流程和工具使用的系统。
Anthropic 同时定义了与 Agent 相对的概念 Workflow：
Workflows are systems where LLMs and tools are orchestrated through predefined code paths.
Workflow 是通过预定义代码路径编排 LLM 和工具的系统。
这个对比揭示了 Agent 的本质：不是固定流程，而是 LLM 自主决策。
AWS 的权威定义从另一角度补充：
AI agents are software programs that interact with environments, collect data, and execute autonomous tasks to meet predetermined goals. Humans set the goals, and the AI agent independently chooses the best actions to fulfill them.
AI Agent 是与环境交互、收集数据、执行自主任务以实现预定目标的软件程序。人类设定目标，AI Agent 独立选择最佳行动方案。
如果这两个定义还是有点抽象，可以这样理解：普通程序是一张固定的乐谱，每次演奏都按谱来；Agent 是一位有即兴能力的演奏者，知道目标是什么，能根据现场情况自主决定怎么演奏。
自动化脚本解决什么，Agent 解决什么
自动化脚本在可预期的世界里非常高效：表单填写、定时任务、数据同步、批量处理。它的运行方式是确定的映射：给定输入 A，执行步骤 1-2-3，输出 B。
问题在于现实世界并不可预期。API 返回格式变了，网络出现抖动，用户的意图模糊，任务的中间步骤需要根据上一步结果动态调整——自动化脚本在这些情况下，要么崩溃，要么静默失败。
传统方案是写更多的 if-else 分支、更复杂的异常处理。但这带来了另一个问题：代码中的分支数量永远跟不上现实世界的复杂度。 每处理一种新的意外情况，就要修改代码、重新部署。
Agent 的价值在于把这种"应对意外"的能力内化到系统本身。Agent 不需要开发者预先枚举所有情况，它能够感知当前状态、推理该做什么、执行行动，并根据结果调整计划。这个循环不依赖硬编码的规则，而是依赖推理能力——这正是 LLM 提供的核心价值。
值得特别说明的是：普通 LLM（直接调用 ChatGPT、DeepSeek API）本身也不是 Agent。LLM 很强大，但它被困在"输入问题→输出答案"的单次交互模式里。它没有工具，没有持续循环，没有感知外部环境的能力。Agent 是给 LLM 加上工具、循环和记忆之后的系统，是把 LLM 从"对话机器"变成"自主执行者"的关键工程架构。
发展脉络：从符号 AI 到 LLM-based Agent
第一阶段：符号主义 Agent（1960-1990 年代）
早期 AI Agent 的智能来自专家知识的符号化。代表系统有 STRIPS（规划系统，1971 年）、专家系统 MYCIN（1976 年）。这类 Agent 逻辑清晰、可解释性强，但知识库需要人工构建，无法处理知识库之外的情况，维护成本极高。
第二阶段：反应式与行为式 Agent（1980-2000 年代）
Rod Brooks 提出了"无需表示的智能"，通过直接的感知-行动映射实现机器人控制。这类 Agent 不再维护内部模型，响应速度快，但没有规划能力，只能处理简单任务。
第三阶段：强化学习 Agent（2000-2020 年代）
Agent 通过与环境交互、收到奖励信号来学习策略。AlphaGo（2016 年）是这个阶段的代表。强化学习让 Agent 能在特定环境中达到超人水平，但训练成本极高，策略无法迁移，每个新任务都需要重新训练。
第四阶段：LLM-based Agent（2022 年至今）
GPT-3（2020 年）展示了语言模型惊人的泛化能力，但真正让 Agent 实用的是 ChatGPT（2022 年底）和 GPT-4（2023 年）带来的 Function Calling 能力。ReAct 范式（2022 年）将 LLM 的推理与工具调用结合，奠定了现代 Agent 的基本架构。此后，AutoGPT、BabyAGI、LangChain Agent、LangGraph 相继出现，整个生态在 2023-2026 年快速成熟。
LLM-based Agent 的核心突破是：用自然语言描述目标，模型就能自主规划步骤、选择工具、处理意外。不再需要为每个任务写专用逻辑。
核心概念地图
这六个维度构成了理解任何 Agent 系统的分析框架。评估一个 Agent 的设计，首先问这六个问题：它能感知什么、如何规划、能做哪些行动、如何记忆、有哪些工具、如何评估效果。
Agent 的七种类型：设计决策的起点
在动手构建 Agent 之前，需要明确一个根本性的设计问题：这个 Agent 需要什么程度的"智能"？
AWS 和 AI 学术界将 Agent 分为七种类型，这个分类不是学术摆设，而是实际设计决策的参考框架：
| 类型 | 核心特征 | 典型场景 |
|---|---|---|
| 简单反射型 | 规则驱动，无状态 | 关键词触发的自动回复 |
| 基于模型的反射型 | 维护内部状态 | 需要跟踪任务进度的助手 |
| 基于目标型 | 规划路径达成目标 | ReAct Agent，多步骤任务执行 |
| 基于效用型 | 多目标权衡优化 | 行程规划、资源调度 |
| 学习型 | 从经验中自我改进 | 从用户反馈优化的推荐系统 |
| 分层型 | 多层次决策架构 | Plan-and-Solve，高层规划+低层执行 |
| 多 Agent 系统 | 专业化分工协作 | 研究员+写作者+审核者团队 |
大多数 LLM-based Agent 项目落在第 3-7 类。第 18 篇讲解的多 Agent 协作就是第 7 类的工程化实现。
本章 20 篇文章的学习路径
本章的文章按照"概念理解 → 范式学习 → 深度机制 → 实战实现 → 工程进阶"的顺序编排。
基础概念（第 1-2 篇）
01 和 02 是概念建立的两篇文章。01 讲清楚 Agent 是什么、和传统程序以及普通 LLM 的本质区别，包含七种 Agent 类型的完整分类，并在末尾引入 PEAS 框架；02 梳理从符号 AI 到 LLM Agent 的完整历史脉络，重点讲清楚每一代技术解决了什么、又引入了什么新问题。这两篇建立坐标系，不适合跳过。
核心范式（第 3-5 篇）
03、04、05 分别介绍 ReAct、Plan-and-Solve、Reflection 三大范式。这是目前 LLM-based Agent 的三种主流设计思路：03 讲推理与行动交织的 ReAct；04 讲先规划后执行的 Plan-and-Solve；05 讲通过自我反思迭代优化的 Reflection。三篇最好按顺序阅读，它们有递进关系。
关键机制（第 6-8 篇）
06 讲记忆系统的设计：短期记忆（对话上下文）和长期记忆（向量存储）的区别与使用场景。07 讲上下文工程（Context Engineering），这是比 Prompt 工程更深层的概念，直接影响 Agent 的有效上下文利用率。08 讲 Workflow 与 Agent 的边界，帮助在合适的场景选择合适的方案。
动手实践（第 9-10 篇）
09 用 100 行 Python 手写一个 ReAct Agent，理解 Agent 循环的每一行代码。10 从零构建一个完整的 Agent 框架。这两篇是本章的实战核心，需要实际运行代码才能真正掌握。
工程与进阶（第 11-17 篇）
11 讲 Agent 评估体系：如何量化 Agent 的效果，从感觉好不好到数据说话。12 讲 PEAS 模型（Performance/Environment/Actuators/Sensors），提供 Agent 设计的系统化分析框架。13 讲工具设计原则：如何定义清晰的工具边界，避免 Agent 工具选择混乱。
关于第 12 篇的阅读时机：PEAS 是经典 AI 理论中描述 Agent 的分析框架，第 01 篇已经做了简要引入。第 12 篇是完整展开，适合在读完第 01-02 篇建立基础认知后就阅读，而不必等到第 12 篇的编号位置。如果你希望在设计 Agent 时有一套系统化的分析工具，建议在第 02 篇之后就读第 12 篇，再继续第 03 篇往后。14 讲多模态 Agent，处理图片和音频输入。15 讲 Tool Retrieval，工具数量多时如何让 Agent 高效找到合适的工具。16 讲可观测性，用 LangSmith 追踪 Agent 的思考过程。17 讲 Human-in-the-Loop，设计 Agent 在需要人工介入时暂停等待的机制。
系统架构与调试（第 18-20 篇）
18 讲多 Agent 协作：Orchestrator-Worker 与 Supervisor 两种模式的设计与实现，对应 Agent 七种类型中的多 Agent 系统，适合需要多个专业 Agent 分工协作的复杂任务场景。19 讲 Agent 长期运行：状态持久化与任务断点续跑，解决长时间运行任务的可靠性问题。20 讲 LLM 应用调试指南：从 print 调试到系统化排查，帮助快速定位 Agent 行为异常的根因。
什么时候不应该用Agent
Agent 功能强大，但不是万能药。以下场景用 Agent 反而会增加复杂度：
| 场景 | 更好的方案 | 原因 |
|---|---|---|
| 流程固定、步骤确定 | 直接写代码/工作流 | Agent的自主决策在这里是多余的 |
| 对延迟要求极高（<1秒） | 传统API调用 | Agent的推理循环会增加延迟 |
| 结果必须100%可预期 | 规则引擎 | LLM的随机性无法保证完全一致 |
| 简单的单步任务 | 直接调用LLM | 不需要Agent的规划和工具调用 |
经验法则：如果你能把任务写成固定的步骤列表，就不需要Agent；如果任务需要根据情况灵活决策，才考虑Agent。
与其他章节的关联
与 LLM 基础（第 6 章）的关系
Agent 的规划能力依赖 LLM 的推理质量。理解 Temperature、Function Calling、上下文窗口管理这些 LLM 参数，能帮助调优 Agent 的行为。LLM 是 Agent 的"推理引擎"，第 6 章的内容是理解 Agent 设计决策的必要前置。
与 Prompt 工程（第 8 章）的关系
Agent 的 System Prompt 设计是工具性能的关键因素之一。第 8 章提供具体的 Prompt 设计方法，建议重点阅读 System Prompt 设计和结构化输出两篇。
与工具使用与 Function Calling（第 9 章）的关系
工具调用是 Agent 与外部世界交互的核心机制。第 9 章详细介绍了 Function Calling 的底层原理和工具设计方法，是理解 Agent 工具能力的直接前置章节。
与 RAG（第 11 章）的关系
Agent 的长期记忆和知识检索依赖 RAG 技术。第 11 章的 Agentic RAG 把检索决策权交给 Agent，是本章概念的延伸应用。
与 LangGraph（第 13 章）的关系
LangGraph 是本章 Agent 概念的工程化实现。本章理解了有状态 Agent 的设计需求，才能理解 LangGraph 为什么要引入状态机模型。第 13 章是本章概念的直接延伸。
与生产化部署（第 18 章）的关系
本章建立 Agent 的概念认知，第 18 章解决如何把 Agent 从原型推向生产。可观测性（第 16 篇）和 Human-in-the-Loop（第 17 篇）与生产化部署章节的内容有直接呼应。
学完本章能做什么
完成本章 20 篇文章后，应当具备以下能力：
- 概念辨析：能清楚解释 Agent、Workflow、自动化脚本、普通 LLM 之间的区别，在设计讨论中准确使用这些概念。知道什么时候该用 Agent，什么时候用普通 LLM 调用已经足够。
- 类型判断：面对一个 Agent 需求，能参照七种类型框架判断该 Agent 的设计属于哪一类，需要哪些核心能力。
- 范式选择：面对一个 Agent 需求，能判断应该用 ReAct、Plan-and-Solve 还是 Reflection，并说明理由。
- 手写实现：能不借助任何框架，用 LLM API 和 Python 实现一个完整的 Agent 循环，包括工具调用和观察反馈。
- 设计评审：能评审一个 Agent 设计方案，识别记忆设计是否合理、工具定义是否清晰、上下文管理是否高效、能力边界是否清楚。
- 评估量化：能为一个 Agent 任务设计评估方案，定义成功指标，运行评估并解读结果。
本章是整个教程体系的地基。Agent 开发中遇到的很多困惑——为什么 Agent 会绕圈子、为什么工具调用出错、为什么效果不稳定——大多数根源都在本章涉及的基础概念中。理解了这些基础，使用框架（LangGraph、LangChain）时也能准确判断问题出在哪一层。