Agent 是什么：从 Chatbot 到 Autonomous Agent 的范式跃迁
第 1 章 Agent 是什么：从 Chatbot 到 Autonomous Agent 的范式跃迁
2023 年 11 月，当 OpenAI 把 Assistants API 和 GPTs 商店推上线的那个周末，我的朋友圈被同一个问题刷屏了："这玩意儿到底是不是 Agent？" 半年后，Anthropic 推出 Computer Use，Devin 拿 2400 万美元融资做"AI 程序员"，Manus 走红又翻车，LangGraph、AutoGen、CrewAI 在 GitHub 上的 star 数三个月翻三倍。Agent 这个词，从论文里的术语变成了所有人嘴边的高频词——但与此同时，它也变成了所有人嘴边的"伪概念"。
所以这一章我们要解决的，就是一个看似简单、实则让整个行业打了两年口水仗的核心问题：到底什么是真正意义上的 AI Agent？它和 Chatbot、Workflow、Copilot 的本质区别在哪里？ 我们会从历史演进、三要素定义、判别标准三个层面切入，最后用一段 30 行的 Python 代码跑出一个"最小可运行 Agent"，让你在读完本章的五分钟内，亲手摸到 Agent 的边界。
---
1.1 从 Chatbot 到 Autonomous Agent：一场静悄悄的能力跃迁
要理解 Agent 的本质，最好的方式不是先给定义，而是先看它"从哪里来"。过去四年，LLM 应用大致经历了四个阶段，每一个阶段都解决了上一阶段"不能做什么"的问题，同时也引出了下一阶段"必须做什么"的新约束。这四个阶段分别是：Prompt-only Chatbot、RAG 增强问答、Copilot 协助交互、以及 Autonomous Agent 自主执行。
第一阶段：Prompt-only Chatbot（2020-2022）。这是 ChatGPT 之前和最初期的状态。用户在一个文本框里输入 prompt，模型返回一个回答。代表产品是早期的 GPT-3 demo、Replika、以及各种"套壳 ChatGPT"网站。这个阶段的应用有几个鲜明特征：第一，没有记忆——每次对话都是独立的，模型不知道你昨天聊过什么；第二，没有工具——模型只能用它在训练数据里学到的知识，无法联网、查数据库、调 API；第三，没有目标——模型是"被动的"，你问它就答，你不问它就沉默。从产品形态上看，它就是一个"更聪明的搜索框"。
第二阶段：RAG 增强问答（2023 上半年）。这个阶段解决的问题是"模型的知识过时了，而且会胡编"。RAG（Retrieval-Augmented Generation）的做法很直接：在模型回答之前，先从外部知识库（向量数据库、文档库、Wiki）里检索相关片段，把这些片段作为上下文塞进 prompt，再让模型基于这些片段生成回答。代表产品是 ChatGPT 的 Browsing 模式、各家企业的知识库问答、以及最初的 LangChain / LlamaIndex 演示。这个阶段的能力跃迁很显著：模型开始能回答"今天的新闻"、能引用内部文档、能给出可追溯的来源。但它仍然有局限——它还是"被动的"，还是单轮或有限多轮，你还是得问，它才会答。
第三阶段：Copilot 协助交互（2023 下半年-2024）。这个阶段的代表产品是 GitHub Copilot Chat、Microsoft 365 Copilot、Cursor、以及各种 IDE 插件。它的核心特征是"人在回路（Human-in-the-Loop）"：模型不再只是回答问题，而是主动参与用户的工作流。Copilot 的标志性能力是：它能理解你的代码、你的邮件、你的文档上下文，然后给出"下一步建议"，但最终执行动作（保存代码、发送邮件、提交 PR）仍然由人类完成。这个阶段引入了两个关键概念：多轮交互和工具调用（Tool Use / Function Calling）。OpenAI 在 2023 年 6 月正式上线 Function Calling，Anthropic 在 2023 年底上线 Tool Use，这些能力让模型第一次能够"动"外部系统。但 Copilot 范式里，模型始终是"助手"，决策权在人。
第四阶段：Autonomous Agent（2024-至今）。这个阶段做的事情，本质上是一次"决策权的让渡"：模型不再只是给建议，而是真的自己去规划、自己去执行、自己去纠错、自己去迭代，直到完成一个开放式的目标。代表产品是 AutoGPT、BabyAGI、Devin、Manus、Claude with Computer Use，以及各类企业内部的多 Agent 系统。
我们可以用一张图把这四个阶段的能力跃迁画清楚：
```mermaid flowchart TD A["Prompt-only Chatbot<br/>(2020-2022)"] --> B["RAG Chatbot<br/>(2023 H1)"] B --> C["Copilot<br/>(2023 H2-2024)"] C --> D["Autonomous Agent<br/>(2024-now)"]
A1["静态知识"] --> A A2["无记忆"] --> A A3["被动响应"] --> A
B1["外部知识库"] --> B B2["引用溯源"] --> B B3["仍被动"] --> B
C1["工具调用"] --> C C2["人在回路"] --> C C3["多轮上下文"] --> C
D1["自主规划"] --> D D2["工具组合"] --> D D3["错误恢复"] --> D D4["长期记忆"] --> D ```
这张图想传达的核心信息是：每一次跃迁，本质上都是在解决"模型不能动"的问题。Chatbot 不能动——它只能生成文字；RAG 让模型能"读"外部知识，但仍然不能"写"外部世界；Copilot 让模型能调用工具，但人类仍然是按下扳机的人；Agent 则把扳机也交给了模型。
但这里必须打一个重要的补丁：不是所有场景都需要 Agent。事实上，我见过大量团队为了"赶时髦"，把简单的问答场景强行包装成 Agent，结果系统变得复杂、脆弱、难调试。这本书反复强调的一个判断原则是：当一个任务可以在三轮以内、有明确输入输出的情况下完成时，它大概率不是 Agent 问题，而是一个普通的 LLM 调用或 Workflow 问题。Agent 的必要性来自于任务的"开放性"和"长链路"——任务目标可能模糊、需要多步骤推理、需要根据中间结果动态调整策略、需要在执行中处理异常。这种任务，恰恰是过去所有范式都搞不定的。
---
1.2 Agent 的三要素定义：感知、决策、行动
给 Agent 下定义，是一件让学术界和工业界都头疼的事。一方面，Agent 这个词被滥用到几乎失去了意义；另一方面，狭义定义又会排除掉很多有价值的东西。我个人倾向于采用一个"三要素 + 三辅助"的结构化定义，主体来自经典的 AI 文献，辅助部分则补足了大模型时代的特性。
主体三要素：感知（Perception）、决策（Decision）、行动（Action）。
这套框架最早可以追溯到 Stuart Russell 和 Peter Norvig 在经典教材《Artificial Intelligence: A Modern Approach》（中文版《人工智能：一种现代方法》）中给出的智能体定义："An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators." 翻译过来：Agent 是任何可以通过传感器感知环境、并通过执行器作用于环境的事物。这套定义的好处在于它的普适性——它既可以描述一个恒温器，也可以描述一个自动驾驶系统，也可以描述一个基于 LLM 的 Agent。
我们把它映射到大模型 Agent 的语境里：
感知（Perception） 对应的是 Agent 的输入层。在大模型 Agent 中，感知不仅仅是用户的自然语言 prompt，还包括：工具调用的返回结果（搜索结果、API 响应、数据库查询）、环境的实时状态（当前时间、文件系统内容、浏览器渲染后的页面）、其他 Agent 的消息、以及长期记忆系统检索出来的历史片段。感知的质量直接决定了 Agent 的"视野"——一个只能感知用户文字的 Agent，和一个能感知屏幕像素、文件系统、网络请求的 Agent，能力上限是完全不同的。
决策（Decision） 对应的是 Agent 的"大脑"。在大模型 Agent 中，决策通常由 LLM 完成，但 LLM 的输出必须经过一个规划器（Planner）的处理，才能变成可执行的步骤。决策的本质问题是："在当前状态下，下一步应该做什么？" 它需要解决三个子问题：第一，把模糊的最终目标分解成可执行的子目标（Planning / Task Decomposition）；第二，从当前可用的工具和记忆中选出最合适的那一个（Tool Selection）；第三，当执行结果不如预期时，决定是重试、换策略还是放弃（Recovery）。决策能力的强弱，是区分"伪 Agent"和"真 Agent"的最关键指标——很多所谓的 Agent 其实只有一个固定的 if-else 决策树，根本不涉及真正的推理和规划。
行动（Action） 对应的是 Agent 的输出层。在大模型 Agent 中，行动通过工具调用（Tool Calling / Function Calling）实现。行动可以是：调用一个搜索 API、读写数据库、发送邮件、执行一段代码、操作浏览器、甚至调用另一个 Agent。行动的颗粒度和多样性，决定了 Agent 能完成的任务复杂度。一个只能"生成文字"的 Agent，无论它看起来多么聪明，本质上仍然是个 Chatbot——因为它不能"动"外部世界。
但仅有这三要素，还不足以描述 2024 年之后真正可用的 LLM Agent。我们需要补充三个辅助要素：记忆（Memory）、工具（Tools）、反思（Reflection）。
记忆（Memory）解决的是"跨时间的一致性"问题。短期记忆通常就是当前对话的上下文窗口；长期记忆则需要外挂一个向量数据库或知识图谱，让 Agent 能够"记住"几天、几周、几个月前的交互。记忆的引入，让 Agent 从"金鱼"变成了"人类"——它能基于历史经验做出更好的决策。
工具（Tools）解决的是"能力边界"问题。LLM 本身的能力是有限的（它不能联网、不能算大数、不能操作文件系统），工具是它延伸能力的"触手"。一个 Agent 拥有多少高质量、定义清晰的工具，直接决定了它的能力上限。这也是为什么 Anthropic 在 2024 年底推出 MCP（Model Context Protocol） 时，整个行业为之振奋——MCP 本质上是给工具调用定义了一个标准化协议，让 Agent 可以像拼乐高一样接入各种工具。
反思（Reflection）解决的是"错误恢复"问题。真正可用的 Agent 必须在执行过程中能够监控自己的状态、判断当前策略是否有效、并在中途调整。ReAct 框架（Reasoning + Acting，2022 年由 Yao 等人提出）正是这一思想的经典实现：让 Agent 在每次行动之后，显式地评估"我刚才的决策是不是对的"，如果不正确就调整策略。这种"边做边想"的能力，是 Agent 区别于普通 Workflow 的核心特征。
把这六个要素放在一起，就构成了我们对 Agent 的工作定义：一个基于大模型的、具备感知-决策-行动闭环、拥有记忆和工具、能进行自我反思的自主系统。这听起来很抽象，但下一节的判别标准会让它变得可操作。
---
1.3 Agentic vs Non-Agentic：四个判别维度
读完上面的定义，你可能会问："那我做的这个应用，里面有一个 LLM，它能调几个 API，它算不算 Agent？" 这是一个非常常见的困惑，也是行业里口水仗的源头。我个人在工程实践中，总结了四个判别维度，可以用来快速判断一个系统的"Agentic 程度"。
判别维度一：自治性（Autonomy）——系统能否在没有人类实时干预的情况下自主完成任务？这是最直观但也最容易被滥用的标准。一个真正 Agentic 的系统，应该能够端到端地完成一个任务，人类只在任务开始时给出目标、在任务结束时验收结果。如果系统的每一步都需要人类确认、每一个工具调用都需要人类审批，那它本质上仍然是个 Copilot，不是 Agent。需要强调的是，自治性是一个程度问题，不是非黑即白的——很多生产环境的 Agent 会在关键节点（如高风险操作、金额超过阈值）主动询问人类，这叫"人在回路的安全护栏"，不破坏 Agent 的本质。
判别维度二：循环深度（Loop Depth）——系统能在多深的循环里自主推理和行动？一个简单的 Workflow 可能是 LLM 调用一次工具就结束（深度=1）；一个 Copilot 可能是人类和 LLM 来回交互几轮（深度=2-3，由人驱动）；一个真正的 Agent 可能是 LLM 自己和自己来回交互十几轮甚至几十轮，自己拆解子任务、自己评估结果、自己重试失败的步骤（深度=N，由 LLM 驱动）。循环深度越深，任务的"智能密度"越高，但也越容易陷入死循环或幻觉。ReAct、Reflexion、Self-Refine 这些论文讨论的就是如何让深层循环更可控。
判别维度三：工具使用密度（Tool Use Density）——系统在完成任务的过程中，会调用多少种不同的工具？组合方式有多复杂？一个伪 Agent 可能从头到尾只用同一个工具（比如只调一个搜索引擎）；一个真正的 Agent 会根据任务需要，在搜索、代码执行、数据库查询、文件操作、API 调用等多种工具之间动态切换。工具的组合方式也反映了 Agent 的智能水平——是固定顺序的 pipeline（那叫 Workflow），还是动态规划的 DAG（那才是 Agent）。
判别维度四：环境耦合度（Environment Coupling）——系统的行为是否会真实改变外部环境的状态，并且能感知到这种改变？一个调用计算器 API 的应用，虽然形式上是 Agent，但它的"行动"几乎不影响外部世界；而一个能下真实订单、发真实邮件、转真实资金的 Agent，它的行为会真实地改变环境状态，并且能从环境的反馈（订单成功/失败、邮件已读/未读）中学习。环境耦合度越高，Agent 的设计难度越大，但价值也越高。
把这四个维度组合起来，可以做一个简单的"Agentic 程度"评分。0-3 分基本是 Chatbot 或 Workflow，4-7 分是 Copilot 或半 Agent，8-10 分是真正的 Autonomous Agent。这不是科学严谨的评分体系，但在工程评审会上，它能快速终结"这玩意儿算不算 Agent"的争论。
还有一个判断方法更简单：看 Agent 在执行过程中会不会"自己改变主意"。如果一个系统从开始到结束，它的执行路径完全由预设的代码逻辑决定（哪怕路径很复杂），那它就不是 Agent；如果系统在执行中能根据中间结果动态调整策略、放弃当前路径走另一条、甚至完全推翻自己之前的决策，那它就是 Agent。这背后的本质区别是：Workflow 是"编译时决定"，Agent 是"运行时决定"。
---
1.4 为什么是现在：2024-2026 Agent 突然可行的三个条件
把时间拨回 2022 年中，让任何一个 AI 研究员想象一下"自主 Agent"的样子，他们会觉得技术上是可行的，但工程上是不现实的——LLM 太笨、工具调用太原始、生态太原始。为什么到 2024 年之后，Agent 突然从"科幻概念"变成了"工程现实"？有三个条件在 2023-2024 年间同时成熟，缺一不可。
第一个条件：模型能力的飞跃。具体来说，是 LLM 在几个关键能力上的突破。长上下文（Long Context）——Claude 的 200K、GPT-4 Turbo 的 128K，让 Agent 能在一次会话里塞下完整的工具定义、历史记录、当前任务上下文，而不需要复杂的摘要和压缩。指令遵循（Instruction Following）——GPT-4 和 Claude 3.5 这一代模型，对复杂 prompt 的遵循能力大幅提升，能可靠地按照 ReAct 格式输出"思考-行动-观察"的循环。Function Calling 的稳定性——OpenAI 在 2023 年 6 月、Anthropic 在 2023 年底推出的 Function Calling / Tool Use，让 LLM 输出结构化 JSON 调用成为工业级稳定的能力，告别了之前用正则表达式解析 LLM 输出的土法炼钢。推理能力的提升——2024 年 9 月 OpenAI o1 的发布，标志着 LLM 第一次具备了"慢思考"能力，能在输出前进行内部的多步推理，这直接让复杂任务的规划质量提升了一个数量级。
第二个条件：协议的成熟。这里必须重点讲一下 MCP（Model Context Protocol）。MCP 是 Anthropic 在 2024 年 11 月开源的一个协议，它做的事情，本质上是给"Agent 和工具之间的连接"定义了一个标准接口。在此之前，每个 Agent 框架都有自己的工具接入方式（LangChain 的 Tool、AutoGen 的 Function、CrewAI 的 Tool），每个工具作者都要为不同的框架写不同的适配器。MCP 借鉴了 LSP（Language Server Protocol）的思想——只要你的工具实现了 MCP 接口，任何 Agent 都能用；只要你的 Agent 支持 MCP，任何工具都能接入。这个协议的出现，标志着 Agent 生态开始从"各自为战"走向"互联互通"，是 Agent 走向工业化部署的关键一步。类似的还有 Google 在 2024 年推的 Agent2Agent（A2A）协议，专注于多 Agent 之间的通信。
第三个条件：生态的完善。2023 年只有 LangChain 一家独大；2024 年开始，LangGraph、Ll