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

把一款 AI 产品的工具权限全部关掉，再让它“查明天上海天气、改客户拜访、给出行程建议”。它依然能写出一份像样的回复，却不能读取真实预报，也不能确认日历到底有没有改成功。

这条差别就是本讲要划的第一条线。模型擅长生成候选内容，Agent 则要把候选内容接到真实环境里，承担动作、反馈和停止的后果–检索网页、读取文件、调用数据库、运行代码或者修改工单，再根据结果决定下一步。判断一个系统是不是 Agent，不必先看它会不会说话，先看它能否围绕目标形成闭环：观察环境，选择动作，接收反馈，更新状态，并在满足条件时停止。后面关于工具、记忆、规划、多 Agent、协议和安全的讨论，都从这条线展开。

先把模型和智能体拆开看

大语言模型可以理解成一次计算：接收一段输入，生成后续输出。输入可以包含问题、指令、文档、图片和工具说明，输出可以是自然语言，也可以是结构化参数。可从软件系统的角度看，模型本身不知道某个动作是否已经执行，不会在进程重启后自动恢复上一次任务，也没有天然的读文件或发邮件权限。Agent 则把模型放进环境和循环里。

假设用户说：“看看明天上海会不会下雨，如果下午有雨，就把客户拜访改到上午，并给我一份行程建议。”模型可以写出一份看起来合理的建议。要把这件事真的做完，Agent 至少要走完下面八步：

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

难处不在于把中文写通顺，在于让语言决策和现实状态可靠地接上。改期之后要读回日历，失败时要停下，不能只靠一句“已处理”交差。

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

下面这张课程目录图不是要介绍框架名称，而是想指出它把基础、框架、Agentic RAG 和评测排成了一条学习路径–能行动只是起点，后面还要回答怎样验证。

图 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 讲会专门讨论何时值得支付协调成本。

LLM 改变的是入口，不是行动闭环

“Agent”并不是大模型时代才出现的词。经典 AI 长期研究如何让系统感知环境、形成内部状态、规划并行动，专家系统、机器人、游戏智能体和强化学习环境，都包含类似问题。LLM 带来的变化不在于发明了行动闭环，而在于提供了一个通用的语言决策接口。过去为每个任务写状态、规则和解析器的成本很高；现在模型能理解自然语言目标、阅读非结构化材料、生成工具参数、解释异常，并在不同任务间迁移，构建开放式 Agent 的门槛因此下降。

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

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

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

看开源项目时，先找它把控制权放在哪里

不同产品给模型的行动空间完全不同，名字相同并不意味着承担的是同一类风险。一个客服助手可能只能搜索知识库；一个工单 Agent 可以修改客户记录；一个 Coding Agent 能运行终端和改仓库；一个 Computer Use Agent 甚至可以操作登录后的浏览器。它们都可以叫 Agent，但风险、评测和基础设施完全不是一回事。

只看“支持多少工具”“能不能多 Agent”，得到的通常只是功能清单。下面七个问题更值得问：

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

下面这张 Berkeley 课程页把推理、规划、基础设施、应用、评测和安全放在一起，拿它当检查表很合适：一套 Agent 的问题很少只落在模型上。

图 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 分钟）

不用写代码。打开你最近使用的一款 AI 产品，别看宣传页，按它实际拥有的权限把下面这张表填完：

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

然后做三个判断：

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

哪一格答不上来，哪一格通常就是它真正的工程缺口。这张表留着，后面几讲会不断拿它补细节。

边界与下一步

模型负责生成候选决策，系统负责让决策与现实连接，这是本讲最想留下的一句。另外两点也值得先记住：Agency 不是越高越好，行动空间越大，验证、权限和恢复的要求越高；判断一个系统是不是 Agent，看的是它怎样行动、怎样证明、怎样停止，而不是它会不会说话。

上面那个定义是工程工作定义，不试图取代经典 AI、机器人或强化学习里的全部定义，Agency 也会随任务和权限变化。它的用途很简单：当有人说“这是个 Agent”时，你知道该往下问什么。

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

---

资料与延伸阅读

以下链接均为本章引用的原始论文、官方文档或公开课程；建议先读 [1]、[2] 建立定义，再按兴趣进入框架与课程资料。

[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