什么是智能体：从经典 AI Agent 到 LLM Agent

很多人第一次接触 Agent，会把它理解成“更聪明的聊天机器人”。

这个理解抓住了表面，却漏掉了最重要的变化：聊天机器人主要生成内容，Agent 还会在外部环境中采取行动。它可能检索网页、读取文件、调用数据库、运行代码、修改工单，然后根据结果决定下一步。

所以，判断一个系统是不是 Agent，不能只看它说得像不像人。要看它是否形成了一个闭环：围绕目标观察环境，选择动作，接收反馈，更新状态，并在满足条件时停止。

这是整套教程的第一条边界。后面讲工具、记忆、规划、多 Agent、协议和安全，都从这条边界展开。

一、先把“模型”和“智能体”分开

大语言模型做的事情，可以压缩成一句话：接收一段输入，生成后续输出。

输入里可以有问题、指令、文档、图片和工具说明；输出可以是自然语言，也可以是结构化参数。但从软件系统的角度看，模型仍然只是一次计算。它不会天然知道某个动作是否真的执行，也不会在进程重启后自动记得上一次运行，更不会天然拥有读取文件或发送邮件的权限。

Agent 则多了环境和循环。

假设用户说：“看看明天上海会不会下雨，如果下午有雨，就把客户拜访改到上午，并给我一份行程建议。”

模型可以写出一份看起来合理的建议。但一个真正执行任务的 Agent 至少要做这些事：

确认“明天”对应的日期；
调用天气工具，读取逐小时预报；
读取日历，找到客户拜访；
判断是否满足改期条件；
在有权限时修改日历，或者请求用户批准；
再次读取日历，确认修改后的状态；
根据真实结果生成行程建议；
在成功、失败、超时或用户拒绝时停止。

这里真正困难的部分，并不是把中文写通顺，而是让语言决定与现实状态可靠地连接起来。

OpenAI 的工程指南把 Agent 描述为能代表用户、相对独立地完成任务的系统，并强调模型、工具和指令三类基本组成。Hugging Face 则用 Agency Spectrum 表达自治程度：从完全由程序规定流程，到模型能够动态选择工具和步骤，Agency 是一条连续光谱，不是非黑即白的标签。[1][2]

Hugging Face AI Agents Course 课程目录

图 1：Hugging Face 的公开课先讲 Agent 基础，再进入框架、Agentic RAG 和评测。来源见文末。

二、一个严格但不复杂的定义

为了避免后面的概念混乱，这套教程采用下面的工作定义：

LLM Agent 是一个以大语言模型作为决策组件，围绕目标，在环境反馈下多次选择并执行动作、更新状态，并在成功、失败或约束触发时停止的软件系统。

这个定义有六个必要部分。

1. Goal：它必须面向某个目标

“随便聊聊”可以没有明确终态，任务执行不行。

目标不一定是一条数学公式，但至少要能回答：系统准备改变什么现实状态？写一份报告、关闭一张工单、修复一个测试、完成一次预订，都是目标。单纯说“尽力帮忙”不是可验收目标。

2. Environment：它必须面对环境

环境可以是网页、代码仓库、数据库、企业系统、游戏或真实设备。环境提供事实，也承受动作的后果。

没有环境，模型只能在文本里推演；有了环境，系统才会遇到权限、网络、并发、失败和副作用。

3. Observation：它需要读取反馈

工具返回的数据、命令退出码、测试结果、页面变化、数据库终态，都是 Observation。

如果系统发出动作后不检查反馈，就谈不上真正的闭环。它只是连续发指令。

4. Action：它必须能选择动作

Action 不一定具有破坏性。检索、读取和计算也是动作。关键在于模型可以根据当前状态，在多个合法动作中选择下一步，而不是所有步骤都由开发者事先写死。

5. State：它必须知道任务进行到哪里

状态包括当前计划、已经获得的证据、工具结果、剩余预算、待审批事项和失败记录。状态不等于聊天记录。聊天记录只是状态的一种载体，而且通常不是最可靠的载体。

6. Stop：它必须有停止条件

Agent 不应该靠“我觉得已经完成”停止。更可靠的停止条件来自环境：测试通过、目标记录已经更新、文件工件存在、用户批准完成，或者预算、时间、重试次数已经耗尽。

把六项放在一起，可以写成一个简单表达：

Agent System
= Goal
+ Model Policy
+ Actions
+ Environment Feedback
+ State
+ Stop Conditions

模型很重要，但它只是这个等式中的一项。

三、五个经常混用的词

1. Chatbot：重点是对话

Chatbot 的核心交互是用户发消息、系统回复。它可以调用知识库，也可以有会话历史，但通常不承担开放式、多步骤的环境行动。

有工具的 Chatbot 可能逐渐接近 Agent。区别不在界面，而在系统是否允许模型根据反馈持续选择动作。

2. Copilot：重点是辅助人

Copilot 往往把人保留在主循环里。它建议代码、整理材料、生成草稿，由人决定是否采用。

Agent 则可能在边界内自行完成多个步骤。两者没有高低之分。高风险任务里，Copilot 反而可能是更合理的产品形态。

3. Workflow：重点是预定路径

Workflow 由工程师规定步骤、分支和依赖。即使某些节点调用了大模型，整体路径仍然可以非常确定。

Agent 会在运行时决定下一步。现实系统常把二者结合：Workflow 规定必须经过的审批和验证，Agent 处理其中难以穷举的部分。

4. RPA：重点是重复操作

传统 RPA 依赖选择器、规则和固定脚本，适合稳定界面和重复流程。浏览器 Agent 能理解更开放的页面和语言目标，但也更难预测、更难验收。

5. Multi-Agent：重点是多个决策主体

多个 Agent 可以分工、并行或相互检查。但如果它们共享同一个模型、同一份上下文和同一组工具，仅仅换了角色名称，并不会自动获得新的能力。

多 Agent 是一种系统设计选择，不是 Agent 的毕业形态。第 14、15 讲会专门讨论什么时候值得支付协调成本。

四、从经典 AI 到 LLM Agent，变化在哪里

“Agent”并不是大模型时代才出现的词。经典 AI 长期研究如何让系统感知环境、形成内部状态、规划并行动。专家系统、机器人、游戏智能体和强化学习环境，都包含类似问题。

LLM 带来的关键变化，不是发明了“行动闭环”，而是提供了一个通用的语言决策接口。

过去，为每个任务写状态、规则和解析器的成本很高。现在，模型可以直接理解自然语言目标、阅读非结构化材料、生成工具参数、解释异常，并在不同任务间迁移。这显著降低了构建开放式 Agent 的门槛。

但门槛下降不等于问题消失。过去写在代码里的确定性，常被搬进了概率模型。系统更灵活了，也更容易出现这些情况：

工具选对了，参数却不符合业务规则；
计划写得完整，执行到第二步环境就变了；
找到了相似资料，却把旧信息当成当前事实；
任务其实失败了，模型仍然生成“已完成”；
一次演示成功，多跑几次却不稳定。

ReAct 的重要性就在这里。它把推理与行动交替组织：模型根据当前观察选择动作，环境返回新观察，模型再继续。这种 Thought-Action-Observation 结构成为现代 Agent Loop 的共同祖先之一。[3]

LLM 提供了更通用的策略，软件工程仍要提供边界、状态和证据。

五、为什么今天到处都是“Agent”，却很难比较

因为不同产品给模型的行动空间完全不同。

一个客服助手可能只能搜索知识库；一个工单 Agent 可以修改客户记录；一个 Coding Agent 能运行终端和改仓库；一个 Computer Use Agent 甚至可以操作登录后的浏览器。

它们都可以叫 Agent，但风险、评测和基础设施完全不是一回事。

比较 Agent 时，至少要问七个问题：

问题	真正要了解的内容
目标是什么	有无明确成功状态
能观察什么	数据来源、时效和可信度
能做什么	工具和动作空间
谁决定下一步	模型、代码、状态图还是人工
状态放哪里	消息、数据库、Checkpoint 或外部运行时
怎样证明完成	文本判断、规则、测试还是环境终态
失败后怎么办	重试、降级、回滚、暂停还是人工接管

只看“支持多少工具”“能不能多 Agent”，得到的往往是功能清单，不是系统判断。

Berkeley LLM Agents 课程页面

图 2：Berkeley 的 LLM Agents 课程把推理、规划、基础设施、应用、评测和安全放在同一研究框架中。来源见文末。

六、四类开源项目，分别应该看什么

smolagents：看最小 Agent 结构

Hugging Face 的 smolagents 刻意保持轻量，适合观察模型、工具、循环和最终答案之间的最小关系。它还展示了 JSON Tool Call 与代码动作两种路线。[4]

OpenAI Agents SDK：看少量核心原语

它以 Agent、Runner、Tool、Handoff、Guardrail、Session 和 Trace 组成执行系统。值得看的不是 API 数量，而是如何在较少原语下保留普通代码的控制力。[5]

LangGraph：看显式状态

LangGraph 把状态、节点和边放在中心。模型可以在节点里决策，但系统允许哪些路径、在哪里暂停、怎样恢复，由图和 Checkpoint 负责。[6]

Google ADK：看完整生命周期

Google ADK 同时提供 Agent、确定性 Workflow Agent、Session、Memory、Evaluation 和部署能力，适合观察一个框架怎样从本地循环走向运行系统。[7]

这四个项目不是同一场比赛的四位选手。它们选择了不同的控制位置。

七、20 分钟练习：判断一个系统到底有多少 Agency

不写代码也能完成这次练习。

选择你正在使用的一款 AI 产品，填写下面这张表：

目标：
环境：
可用动作：
谁决定下一步：
状态保存在哪里：
成功证据：
失败出口：
最高风险动作：

然后做三个判断：

如果删掉所有工具，它还剩下什么？
如果模型连续判断错误三次，什么机制会阻止它继续？
如果进程现在重启，系统能否从正确位置恢复？

答不上来的部分，通常正是这个 Agent 真正的工程缺口。

八、这一讲最重要的三句话

第一，模型负责生成候选决策，系统负责让决策与现实连接。

第二，Agency 不是越高越好。行动空间越大，验证、权限和恢复要求越高。

第三，不要用“会不会说”判断 Agent，要用“怎样行动、怎样证明、怎样停止”判断。

下一讲，我们会把镜头从 Agent 移到模型之外：一个模型怎样被装进上下文、工具、权限、状态和运行生命周期，最终变成能工作的 Harness。

参考资料

[1] OpenAI, A practical guide to building agents. https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/

[2] Hugging Face, What are agents?. https://huggingface.co/docs/smolagents/conceptual_guides/intro_agents

[3] Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models. https://arxiv.org/abs/2210.03629

[4] Hugging Face, smolagents. https://github.com/huggingface/smolagents

[5] OpenAI, OpenAI Agents SDK. https://openai.github.io/openai-agents-python/

[6] LangChain, LangGraph Overview. https://docs.langchain.com/oss/python/langgraph/overview

[7] Google, Agent Development Kit. https://google.github.io/adk-docs/

[8] UC Berkeley, Large Language Model Agents, Fall 2024. https://rdi.berkeley.edu/llm-agents/f24