什么是 AI Agent：从自动化脚本到自主智能体

为什么需要 Agent：自动化的边界在哪里

在理解 Agent 是什么之前，先回到一个最根本的问题：为什么已有了自动化脚本、传统程序和简单 LLM，还需要 Agent？

传统自动化的本质：穷举所有可能

所有传统自动化的工作原理都是相同的：开发者预先想清楚所有可能发生的情况，为每种情况写下处理逻辑，代码最终只是这些预设逻辑的执行器。

这个模式在"世界是可穷举的"时候运转良好：接口返回固定格式、输入数据结构化、异常类型有限且已知。工厂生产线的自动化是完美的例子——工件规格固定，传感器精确，每一步都是确定性的。

但现实世界越来越多的任务不满足"可穷举"这个前提：

自然语言的表达方式无限多，同一个意图可以有几百种说法
用户的真实需求往往和表面描述不同，需要理解上下文
任务执行中途出现的意外情况，开发者根本没有预见到
业务逻辑本身就是模糊的，需要在执行中动态判断

传统程序和 LLM 单独使用的本质区别

这里有一个值得澄清的关键区别：LLM 本身并不是 Agent。一个普通的对话型 LLM，你问它问题，它给你答案——它能"说"，但它不"做"。它没有工具，没有持续执行的循环，没有感知外部环境的能力。它是一个非常强大的文本生成引擎，但它被困在输入输出的单次交互里。

Agent 的出现，是为了打破这道墙。

LLM 如何提供"自主性"

LLM 本质上是一个通用的文本推理引擎。给它一段文本和一个目标，它能生成合理的下一步行动。这个能力来自它在海量人类文本上学到的世界知识和推理模式。

关键在于：这种推理能力不依赖预先枚举所有情况。遇到没见过的输入，LLM 能够推断"这种情况下最合理的做法是什么"——这正是传统自动化做不到的事情。

把 LLM 作为决策核心，配上能与外部世界交互的工具，再加上循环（观察结果 → 重新规划 → 继续行动），就得到了 Agent。

什么是 AI Agent

图：Agent 的核心循环——感知外部输入，经 LLM 推理规划，执行行动，观察环境反馈，再次进入下一轮循环，直到目标达成。

Agent 的权威定义

在学术界和工业界，Agent 的定义有多个来源，理解这些定义能帮助建立清晰的概念基础。

学术定义（Russell & Norvig，《人工智能：一种现代方法》，AI 领域最权威的入门教材）：Agent 是任何能够感知其环境并对环境采取行动的实体。

这个定义覆盖范围很广——温控器也算 Agent。更有实践意义的版本是：Agent 是一个能感知环境、做决策、执行行动、观察结果，并持续循环这个过程以达成目标的自主系统。

AWS（亚马逊云服务）的工程化定义：AI Agent 是与环境交互、收集数据、执行满足预定目标的自主任务的软件程序。人类设定目标，AI 代理独立选择最佳行动方案。

这个工程化定义更接近实践：人给目标，Agent 自主规划路径。

两个关键词

自主（Autonomous）：能在没有人工干预的情况下处理意外情况，而不是遇到未预期的情况就崩溃或停止
循环（Cycle）：不是一次性给出答案，而是观察行动结果、据此调整下一步，形成持续的感知-决策-行动-观察循环

Agent vs 普通 LLM：能说 vs 能做

这是理解 Agent 最重要的一个区分。

维度	普通 LLM（如直接调用 ChatGPT API）	AI Agent
交互方式	单次问答：你问，它答	持续循环：感知、规划、行动、观察
工具能力	没有，只能输出文字	有，可以调用 API、读写文件、执行代码
环境感知	无，只能处理输入的文字	有，能观察工具返回结果、网页内容、数据库数据
任务范围	当前这条消息	可以跨多步骤完成复杂任务
状态记忆	无持久化（除非手动实现）	可以维护跨步骤的任务状态
典型用途	回答问题、写文案、代码解释	订票、数据分析、代码调试、研究报告撰写

一个直观的例子

用户说："帮我分析竞争对手 A 公司最新一个季度的财务数据，和我们公司对比，写一份报告。"

普通 LLM 的处理：基于它训练数据里有的信息给出一个回答，但数据可能是过时的，也无法访问实时财务数据，更无法查询你们公司内部数据。
AI Agent 的处理：先搜索 A 公司最新财报（工具调用），再查询内部数据库获取己方数据（另一个工具调用），按照报告结构逐步生成各个章节，最后整合成完整报告。整个过程多步骤、多工具、动态调整。

这就是"能说"和"能做"的根本区别。

普通LLM vs Agent对比
普通LLM只能"说"，Agent既能"说"也能"做"

Agent 的四个核心能力

一个完整的 Agent 需要具备四种能力：

感知（Perception）

感知是 Agent 获取外部信息的能力。对于 LLM-based Agent，感知的输入可以是文本、图片、工具返回的结果、数据库查询结果、网页内容。感知能力决定了 Agent 能"看到"多大的世界。感知的范围越广，Agent 能处理的任务就越复杂。

规划（Planning）

规划是 Agent 的决策能力。面对一个目标，它能把任务拆解成子任务，确定执行顺序，选择合适的工具。这是 Agent 和普通脚本最核心的区别——脚本的"计划"是硬编码的，Agent 的计划是动态生成的。规划质量直接决定了 Agent 能否有效完成复杂任务。

行动（Action）

行动是 Agent 影响外部世界的能力。调用 API、写文件、执行代码、发送消息、操作浏览器——这些都是行动。行动的范围决定了 Agent 的能力边界。行动范围越大，Agent 的潜在危害也越大，这也是为什么 Agent 安全设计至关重要。

记忆（Memory）

记忆让 Agent 能跨时间保持上下文。没有记忆的 Agent 每次都从零开始，有了记忆，它才能积累经验、保持一致性、学习用户的偏好。记忆分短期（当前对话上下文）和长期（持久化存储）两种，后续章节会专门讲解。

Agent 的感知-规划-行动循环

这个循环是 Agent 的核心。每次行动之后，Agent 都会观察结果，然后重新规划——而不是盲目按预设步骤走下去。这种"感知-决策-行动-学习"的四阶段循环，是所有 AI Agent 的共同底层架构。

Agent感知-规划-行动循环
Agent的感知-规划-行动-观察循环

Agent 的七种类型

AWS 和 AI 学术界的分类框架将 Agent 分为七种类型，理解这些类型有助于在设计时选择合适的架构。

按决策复杂度递进的五种类型

1. 简单反射型 Agent（Simple Reflex Agent）

只根据当前输入做决策，没有内部状态，没有历史记忆。输入什么，按规则输出什么，快速直接。

例子：恒温器——温度高于设定值就开制冷，低于就关。也可以是最简单的客服机器人：用户说"退款"，转接退款部门；用户说"投诉"，转接投诉部门。

优势：速度快、可预测、实现简单。
局限：完全依赖当前感知，无法处理需要上下文的任务，遇到边界情况就失效。

2. 基于模型的反射型 Agent（Model-based Reflex Agent）

在反射式的基础上，引入了"内部世界模型"——对环境状态的持续追踪。即便传感器暂时感知不到，它也能维持对世界状态的判断。

例子：隧道里的自动驾驶汽车，即使摄像头失效，仍知道前方有车，靠的就是这种内部模型。在 LLM Agent 里，这相当于维护一个记录当前任务状态的字典，追踪"哪些步骤已完成、当前进行到哪里"。

优势：比纯反射式更鲁棒，能处理部分信息缺失的情况。
局限：模型可能与真实环境产生偏差，需要及时更新。

3. 基于目标型 Agent（Goal-based Agent）

有明确目标，会规划达成目标的路径。知道"我要去哪里"，并能主动选择路线。

例子：GPS 导航——它不是被动响应，而是主动规划出一条通往目的地的路径。ReAct 范式的 LLM Agent 是这一类的典型：给定一个目标，它会推理"下一步应该做什么来接近这个目标"。

优势：能处理复杂的多步骤任务，执行路径不需要预先指定。
局限：目标定义模糊时，可能走错方向；不能很好地处理多目标之间的权衡。

4. 基于效用型 Agent（Utility-based Agent）

现实中目标往往不止一个，而且相互冲突。不仅要到达目的地，还要时间最短、成本最低、避开拥堵。效用型 Agent 为每种可能的结果赋予一个"满意度分数"，选择期望效用最高的行动。

例子：复杂的行程规划 Agent——不只是"能到目的地"，而是在时间、价格、舒适度之间找到最优平衡。Plan-and-Solve 范式的 Agent 在规划阶段会考虑多种方案并选择最优解，这就是效用驱动的思路。

优势：能处理多目标权衡，做出更合理的决策。
局限：效用函数设计复杂，不同场景需要不同的效用函数定义。

5. 学习型 Agent（Learning Agent）

以上四类的决策逻辑都依赖人工设计。学习型 Agent 的核心突破是：让 Agent 通过与环境交互，自己学出决策策略。强化学习是最典型的实现方式。

例子：AlphaGo 就是这类 Agent——没有人告诉它怎么下棋，它靠自我对弈摸索出了超越人类的策略。更接近实践的例子是能从用户反馈中改进行为的推荐系统。

优势：能在特定环境中超越人工设计的规则，不断自我改进。
局限：训练成本高，需要大量交互数据；策略无法直接迁移到新任务。

两种面向系统架构的类型

6. 分层型 Agent（Hierarchical Agent）

将决策过程组织成多个层次。高层 Agent 做宏观规划，低层 Agent 处理具体执行。这个模式在复杂任务分解中非常有用。

例子：企业 AI 系统中，一个高层"策略 Agent"负责将年度业务目标拆解为季度任务，中层"项目 Agent"负责具体项目的执行规划，低层"执行 Agent"负责单个任务的完成。Plan-and-Solve 范式的 Planner-Executor 架构就是一种两层分层设计。

优势：可以处理超出单 Agent 能力范围的超复杂任务，各层职责清晰。
局限：层间通信增加延迟，协调成本高，出错时调试困难。

7. 多 Agent 系统（Multi-Agent System）

多个专业化 Agent 分工协作，共同完成单个 Agent 无法处理的任务。就像一个专业团队，每个成员负责自己最擅长的部分。

例子：研究报告生成系统——信息收集 Agent 负责搜索、数据分析 Agent 负责处理数字、写作 Agent 负责生成文本、审核 Agent 负责质量把控。各司其职，并行执行，效率远超单 Agent。

优势：通过分工突破单 Agent 的能力边界，支持并行执行，各 Agent 可以专注于各自最擅长的领域。
局限：引入协调复杂度，Agent 间通信需要标准化，调试更困难。

七种类型的选择指南

Agent从简单到复杂的七种类型

Agent 与传统程序、自动化脚本的系统对比

维度	传统程序	自动化脚本	普通 LLM	LLM-based Agent
决策方式	预设 if-else	预设流程	单次推理	动态推理循环
处理意外	捕获已知异常	基本不处理	无法行动	自主应对
工具调用	需要硬编码	需要硬编码	不能调用	动态决策调用
任务灵活性	固定功能	固定流程	只能文字输出	开放目标，动态执行
开发成本	高（需覆盖所有情况）	中	低（直接调用）	中（设计工具+循环）
可解释性	高	高	中（可看推理）	中（可追踪步骤）
可靠性	高（已知范围内）	中	中（幻觉风险）	中低（多步骤累积误差）
适合场景	确定性任务	固定流程任务	单次问答	复杂多步骤自主任务

Agent 的能力边界：什么能做，什么还做不到

理解 Agent 的能力边界，是避免过度期望和正确使用 Agent 的前提。

Agent 真正擅长的

多步骤任务自动化：将原本需要人工多步操作的任务自动化，例如自动收集数据→分析→生成报告
处理非结构化输入：理解自然语言意图，不需要严格格式化的输入
工具组合使用：根据任务动态决定调用哪些工具，以什么顺序调用
适应意外情况：遇到工具返回错误或意外结果时，能够重新规划而不是直接崩溃
跨领域知识综合：利用 LLM 的通用知识，在没有预设规则的情况下处理各种问题

Agent 的已知局限

幻觉问题：LLM 会自信地编造不存在的事实，在需要精确信息的场景（法律、医疗、财务）这是严重风险。缓解方案是让 Agent 通过工具获取真实数据，而不是依赖模型记忆。

多步骤误差累积：每一步的小错误会在后续步骤中放大。一个 10 步骤的任务，每步 90% 准确率，整体只有约 35% 的完美完成率。需要在关键节点设置验证。

不可撤销的危险行动：一旦执行了删除文件、发送邮件、转账这类操作，无法回头。需要在高风险行动前加入人工确认（Human-in-the-Loop）。

规划能力有限：面对非常复杂、需要深度推理的规划任务，LLM 的规划质量不稳定。复杂的多步骤规划往往需要借助 Plan-and-Solve 范式来约束。

上下文窗口限制：LLM 每次推理只能"看到"有限数量的 token，超长任务需要专门的记忆管理策略。

不适合精确计算：LLM 不擅长复杂数学计算，需要给 Agent 配置计算器工具，让工具处理数学，让 LLM 处理推理。

什么时候不应该用 Agent

任务流程固定、要求 100% 准确率 → 传统程序更可靠
简单的单次问答 → 直接调用 LLM 即可，不需要 Agent 的复杂架构
对响应速度有极高要求 → Agent 的多步骤循环引入额外延迟
数据高度敏感且不能离开本地 → 需要特别考虑工具调用的数据安全

最简示例：一个能调用工具的 Agent

以下代码展示了 Agent 的核心结构：循环、工具调用、观察结果、再决策。

验证目的：通过一个能调用真实天气 API 的最小 Agent，观察"LLM 决策调用工具 → 执行工具 → 观察结果 → LLM 再次决策"这个循环是如何工作的，以及 Agent 如何根据工具返回的真实数据动态调整回答。

Agent 工具调用序列图

图：Agent 工具调用的完整时序——用户发起请求，LLM 判断是否需要工具，调用工具获取结果，再基于结果生成最终回答。

python

from openai import OpenAI
import json
import requests

client = OpenAI()

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "获取指定城市的当前天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名称，支持中文或英文"}
                },
                "required": ["city"]
            }
        }
    }
]

def get_weather(city: str) -> str:
    """调用 wttr.in 获取真实天气，免费无需注册"""
    try:
        response = requests.get(f"https://wttr.in/{city}?format=j1", timeout=5)
        response.raise_for_status()
        data = response.json()
        cond = data["current_condition"][0]
        desc = cond["weatherDesc"][0]["value"]
        temp = cond["temp_C"]
        feels = cond["FeelsLikeC"]
        humidity = cond["humidity"]
        return f"{city}：{desc}，气温 {temp}°C（体感 {feels}°C），湿度 {humidity}%"
    except Exception as e:
        return f"天气查询失败：{e}"

def run_agent(user_message: str) -> str:
    messages = [{"role": "user", "content": user_message}]

    # Agent 核心循环
    while True:
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            tools=tools,
        )

        message = response.choices[0].message

        # 模型决定直接回答，不调用工具
        if message.tool_calls is None:
            return message.content

        # 模型决定调用工具（这是 Agent 区别于普通 LLM 的关键）
        messages.append(message)

        for tool_call in message.tool_calls:
            func_name = tool_call.function.name
            func_args = json.loads(tool_call.function.arguments)

            # 执行行动，把结果作为观察反馈给模型
            result = get_weather(**func_args) if func_name == "get_weather" else f"未知工具：{func_name}"

            # 把工具结果追加进对话，让 LLM 观察结果并做出下一步决策
            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "content": result
            })

        # 继续循环，让模型基于观察结果决定下一步

result = run_agent("北京今天天气怎么样？需要带伞吗？")
print(result)

这段代码展示了 Agent 的核心结构：循环、工具调用、观察结果、再决策。模型不是一次性给出答案，而是根据工具返回的真实天气信息动态调整回答。wttr.in 是一个免费的天气服务，无需注册 API Key，可以直接运行验证。

和普通 LLM 调用的对比：如果去掉 tools 参数和 while 循环，只做一次调用，LLM 会基于训练数据中的知识猜测天气（可能是过时的或错误的）。加上工具调用循环之后，LLM 会获取真实的实时天气数据。这就是"能说"变为"能做"的关键所在。

设计 Agent 之前：用 PEAS 框架想清楚任务环境

知道"什么是 Agent"之后，下一个问题是：在动手实现之前，怎么系统地想清楚一个 Agent 需要具备哪些能力？

一个常见的陷阱是凭直觉拍板：觉得需要什么工具就加什么，等上线之后才发现漏了关键能力，或者设计了一堆用不上的功能。

经典 AI 教材《人工智能：一种现代方法》（Russell & Norvig）提出了 PEAS 框架，专门用来在设计阶段把 Agent 的任务环境想清楚：

Performance（性能指标）：怎么衡量 Agent 表现得好不好？
Environment（环境）：Agent 在什么环境下运行？环境是静态还是动态，确定还是随机？
Actuators（执行器）：Agent 能做什么动作？
Sensors（传感器）：Agent 能感知什么信息？

以天气查询 Agent 为例，PEAS 分析是这样的：

维度	内容
Performance	回答准确率、响应速度、用户满意度
Environment	用户对话界面，部分可观察（只知道用户说了什么，不知道用户真实意图）
Actuators	调用天气 API、生成自然语言回答
Sensors	用户输入的文字、天气 API 返回的数据

以电商客服 Agent 为例，PEAS 分析则更复杂：

维度	内容
Performance	问题解决率、客户满意度评分、平均处理时间、人工升级率
Environment	用户对话界面 + 订单数据库 + 商品信息库，部分可观察
Actuators	查询订单、发起退款、发送优惠券、转接人工客服、推送消息
Sensors	用户文字输入、订单系统数据、客户历史记录、当前促销信息

这个分析看起来简单，但在复杂场景下能帮你发现很多设计盲点。第 12 篇会完整讲解 PEAS 框架，并用代码审查 Agent 做深度案例分析。

思考题

温控器算不算 Agent？按照七种类型的分类，它属于哪一类？它的局限在哪里？
你日常用的手机导航（如高德地图）是哪种类型的 Agent？它的 PEAS 是什么？如果遇到道路施工，它是如何处理这种"意外"的？
假设要设计一个"代码审查 Agent"，帮助团队自动审查 GitHub PR。请用七种类型框架分析：它应该是哪种类型？需要哪些工具（Actuators）？有哪些明确的能力边界？
为什么说"普通 LLM 是能说但不能做"？举一个具体例子说明 Agent 在这个场景下的具体优势。