Skip to content

什么是 AI Agent

本页速览 拆解 AI Agent 的精确定义与公式(LLM + 规划 + 记忆 + 工具),对比 Anthropic、OpenAI、IBM 的权威表述,梳理 2023-2026 年 Agent 爆发的技术前提,并用 30 行伪代码展示最小 Agent 的完整循环。

什么是 AI Agent ​

这是整个网站的立论页。后面的每一个章节——Agent Loop、工具、记忆、规划、多智能体、评测——都是对这一页定义的展开。所以这一页值得读慢一点:先把「Agent 是什么」钉死,再谈怎么学。

先说一句题外话:「agent(智能体)」在 AI 领域是个老词,强化学习、多智能体系统研究用它几十年了。2023 年之后它被重新发明了一遍——核心从「在环境中学习策略的实体」换成了「用 LLM 做决策的系统」。本网站讨论的是后者,也就是行业现在说「Agent」时默认所指的东西。两者有概念上的血缘关系,但技术栈几乎完全不同,读老文献时注意区分语境。

一、一句话定义 ​

先给出本站采用的工作定义:

AI Agent(LLM Agent)是由大语言模型驱动的、能自主使用工具在环境中完成多步任务的系统。

这句话里有五个关键词,缺一不可:

  • LLM 驱动:决策核心是语言模型,不是规则引擎。这是 2023 年之后的 Agent 和古典 AI 里「智能体」概念的分水岭。
  • 自主:模型自己决定下一步做什么,而不是沿着人写死的流程走。
  • 使用工具:能调函数、查数据库、发请求、读写文件——能对环境产生真实影响。
  • 在环境中:工具执行的结果会反馈回来,模型基于「环境的真实回应」修正自己的行为,而不是闭门生成。
  • 多步任务:单次问答不是 Agent;Agent 的价值恰恰体现在需要十步、二十步才能完成的任务上。

业界权威定义对比 ​

「Agent」这个词在业界并没有唯一标准答案。Anthropic 在《Building Effective Agents》一开篇就承认了这点:有人用它指完全自主的系统,有人用它指按预定义流程执行的实现。他们把这些统称为 agentic systems,并划出一条关键的架构分界线:

"Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." —— Anthropic, Building Effective Agents(2024 年 12 月,Erik Schluntz & Barry Zhang)

译过来:workflow 是 LLM 和工具沿着预定义代码路径编排的系统;agent 则是 LLM 动态指挥自己流程和工具使用的系统。区别的本质是控制流由谁主导——是人写的 if/else,还是模型自己的判断。

OpenAI 在《A Practical Guide to Building Agents》(2025 年 4 月)里给了一个更产品化的定义:

"Agents are systems that independently accomplish tasks on your behalf."

并且补了一刀:接了 LLM 但不用 LLM 控制流程执行的系统——简单聊天机器人、单轮问答、情感分类器——不是 Agent。OpenAI 还把 Agent 的核心拆成三个组件:Model(驱动推理的 LLM)、Tools(可调用的外部函数/API)、Instructions(行为准则与护栏)。

IBM 的定义则更克制:"An AI agent is a software program capable of acting autonomously to understand, plan and execute tasks"——能自主理解、规划并执行任务的软件程序,强调由 LLM 供能、可与外部工具和数据源对接。

来源核心表述侧重点
AnthropicLLM 动态指挥自身流程与工具使用架构区分:workflow vs agent
OpenAI独立替用户完成任务的系统产品视角:接管整个 workflow
IBM自主理解、规划、执行的软件程序经典 Agent 概念的 LLM 化

三个定义措辞不同,但都指向同一个结构判据:谁在做决策、决策是否在循环中基于环境反馈不断更新。这也是本站判断「一个系统是不是 Agent」的标准,详见概念辨析。

面试高频考点

「Agent 和 workflow 的区别是什么?」几乎是 Agent 岗位的必答题。标准答案就是 Anthropic 那条线:控制流由预定义代码主导的是 workflow,由模型动态主导的是 agent。但要能继续往下聊——两者是一条光谱而非二元对立(下文第三节),且生产系统里绝大多数是两者的混合体。

二、Agent 公式拆解 ​

业界流传最广的一个工程公式是:

Agent = LLM(大脑)+ 规划(Planning)+ 记忆(Memory)+ 工具使用(Tools)

这个分解最早系统性出现在 Lilian Weng 的《LLM Powered Autonomous Agents》和复旦 NLP 团队的综述《A Survey on Large Language Model based Autonomous Agents》中,此后成为事实上的分析框架。用一张图表示:

                    ┌─────────────────────────────┐
                    │          用户任务            │
                    └──────────────┬──────────────┘
                                   ▼
              ┌─────────────────────────────────────┐
              │        LLM(大脑 / 推理核心)         │
              │  理解目标 · 决策下一步 · 生成动作      │
              └──────┬───────────────┬──────────────┘
                     │               │
          ┌──────────▼───┐     ┌─────▼──────────┐
          │  Planning    │     │    Memory      │
          │  任务分解     │     │ 短期:上下文    │
          │  反思/自我修正 │     │ 长期:向量库等  │
          └──────────────┘     └────────────────┘
                     │               │
                     ▼               ▼
              ┌─────────────────────────────┐
              │   Tools(工具 / 执行层)      │
              │ 搜索 · 代码执行 · 文件 · API  │
              └──────────────┬──────────────┘
                             ▼
                    ┌─────────────────┐
                    │   Environment   │  环境返回真实结果
                    │  (环境反馈)    │──┐ (Observation)
                    └─────────────────┘  │
                        ▲                │
                        └──── 反馈回 LLM,进入下一轮循环

四个组件各自解决什么问题:

  • LLM 是大脑,不是全部。裸模型只会「说」,不会「做」。Agent 工程的本质是把模型的语言能力转化为决策能力。
  • 规划解决「一步想不清楚」的问题:任务分解、逐步推理、执行后的反思与自我修正。详见规划与推理。
  • 记忆解决「上下文装不下、跨会话记不住」的问题:短期记忆就是 context window 里的对话历史,长期记忆通常靠外部存储加检索。详见记忆系统。
  • 工具是 Agent 的手和眼:没有工具,模型对世界的唯一影响就是输出文字。工具调用的质量(描述、参数设计、错误信息)往往比模型选择更决定 Agent 的上限。详见工具与 MCP。

Anthropic 把这三样增强能力的合体称为 augmented LLM(增强型 LLM)——检索、工具、记忆齐备的模型调用,是一切 agentic system 的基础积木。这个提法值得记住:它提醒你,搭 Agent 不是从零造火箭,而是把四个各自成熟的组件正确地接在一起。工程难点从来不在任何一个组件本身,而在它们的接缝处:工具描述怎么写模型才不会选错、记忆检索回来的东西会不会污染上下文、规划失败时怎么检测并回退。全站核心组件栏目的五篇文章,本质上就是在逐个讲这些接缝。

Anthropic 的极简视角

Anthropic 在同一个定义之外还有一句更狠的话:"agents are typically just LLMs using tools based on environmental feedback in a loop"——Agent 通常就是「在循环里基于环境反馈使用工具的 LLM」。规划、记忆并不是独立的神秘模块:规划是 prompt 里的推理过程,短期记忆是不断累积的 message 列表。上手的正确姿势是先把这个最小循环跑起来,缺什么补什么,而不是一上来就套重型框架。

三、自主性光谱:Agent 不是一个二元概念 ​

新手最容易陷入的争论是「这个系统算不算真正的 Agent」。这个问题本身就问错了。Anthropic 把 workflow 和 agent 都归入 agentic systems,这暗示了一个更重要的事实:自主性是一条连续光谱,不存在非黑即白的分界线。

低 ◄──────────────────────────── 自主性 ────────────────────────────► 高

单次 LLM 调用    固定 workflow       受限 Agent           全自主 Agent
(问答/翻译)   (链式/路由/并行)   (人在关键节点把关)   (长时间自主执行)
     │               │                  │                    │
     │               │                  │                    │
  模型只输出文本   模型沿人写死的路径走  模型主导流程,       模型自主规划、
                 模型不决定「下一步」  但步数/权限受限、    执行、纠偏,
                                     人类可随时接管      无人值守运行

一个系统在这条光谱上的位置,由三个变量决定:

  1. 控制流归谁:预定义代码路径占比越高,越靠左;模型自主决策占比越高,越靠右。
  2. 循环开多大:单轮调用在最左;有步数上限、有退出条件的工具循环居中;理论上可以无限跑下去的在最右。
  3. 动作可逆性:只读工具(搜索、查询)可以放心往右走;写操作(发邮件、改代码、付款)通常要拉回中间,加 human-in-the-loop 关卡,详见人机协作。

实践结论很明确:绝大多数生产系统应该建在光谱中间,而不是右端。Anthropic 的建议是「找到能解决问题的最简单方案,只在必要时增加复杂度」——能用单次调用加检索搞定的,别上 workflow;能用 workflow 搞定的,别上 agent。OpenAI 的指南同样建议先最大化单 Agent 能力,再考虑多 Agent。这不是保守,是血泪经验:自主性每往右走一格,成本、延迟和错误复合率都在涨,详见成本与延迟。

三道判断题,自测你是否真的理解了 ​

  1. 「接了大模型的客服机器人,按固定话术树回复,算 Agent 吗?」 不算。控制流是话术树(预定义代码路径),LLM 只负责润色措辞,这是 workflow 甚至不是 workflow——OpenAI 明确把这类系统排除在外。
  2. 「一个脚本依次调用 LLM 做摘要、翻译、校对,算 Agent 吗?」 不算,这是 prompt chaining workflow。每一步做什么、顺序如何,全是人写死的。它可能非常实用,但模型没有任何自主权。
  3. 「一个循环里模型自己决定搜什么、读什么、何时停,但只允许只读工具,算 Agent 吗?」 算,只是自主性受限的 Agent。限制工具权限不改变控制流的归属——这正是光谱中间的典型形态。

如果你三题都答对了,定义这关就过了;如果答错了,回到第一节再读一遍 Anthropic 的那两句话。

四、为什么是现在:Agent 爆发的技术前提 ​

Agent 的概念在 AI 领域存在了几十年,但直到 2023 年才真正可用。这不是营销周期,而是几块关键拼图在 2022-2025 年间相继就位:

时间事件补上了哪块拼图
2022 年 10 月ReAct 论文(arXiv:2210.03629)发表用 prompt 交替生成「推理-行动」轨迹,证明了 LLM 可以边想边做
2023 年 6 月OpenAI 发布 function calling工具调用从「解析模型文本输出」的工程杂技变成结构化 API,可靠性质变
2024 年 2 月Gemini 1.5 Pro 发布,百万级 token 上下文开放预览长上下文让多步任务的历史、文档、工具结果装得进一个窗口
2024 年 9 月OpenAI 发布 o1-preview推理模型登场:模型学会了在回答前「多想一会儿」,复杂规划能力跳升
2024 年 10 月Anthropic 发布 Claude 3.5 Sonnet 的 computer use(beta)模型第一次能直接看屏幕、动鼠标键盘,工具面从 API 扩展到任意 GUI
2024 年 11 月Anthropic 开源 Model Context Protocol(MCP)工具/数据源接入有了统一开放标准,N×M 集成问题变成 N+M
2025 年 1 月起DeepSeek-R1 等开源推理模型把推理能力价格打下来长循环 Agent 的 token 成本进入可承受区间
2025 年 3 月Manus 发布并刷屏,通用 Agent 产品出圈「Agent 元年」从产品侧坐实,资本市场和招聘市场跟进

换个角度看,这张表回答的是「Agent 的四个组件分别在什么时候变得可用」:

  • 工具使用:2023 年 function calling 解决「可靠地调」,2024 年底 MCP 解决「标准化地接」。
  • 记忆/上下文:长上下文窗口(百万 token 级)加上成熟的 RAG 工程,让 Agent 能处理真实规模的材料。
  • 规划/推理:o1 开启的推理模型范式(RL 训练的 test-time compute)让多步规划从「经常翻车」变成「大体可用」。
  • 环境交互:computer use 让 Agent 摆脱「必须有现成 API」的限制,能操作任意软件界面。

到 2026 年的今天,这四块拼图已经不再是研究问题,而是工程问题——这正是「现在学 Agent」和「三年前学 Agent」的本质区别。更完整的编年梳理见演进简史。

别被「Agent 元年」叙事带偏

每年都被某些人称为 Agent 元年。技术拼图确实在 2023-2025 年陆续就位,但「能用」不等于「可靠」。当前的 Agent 在结构化、可验证的领域(编码、检索、数据操作)已经创造真实价值;在开放性、不可逆、高风险的场景里仍然需要大量人工兜底。把它当成一个能力很强但会犯低级错误的实习生,比当成数字员工更接近现实。

五、一个最小 Agent:30 行伪代码 ​

理解了定义之后,最值得记住的一件事是:Agent 的核心循环简单到令人失望。下面这段伪代码(Python 风格,API 调用做了简化)就是一个功能完整的 Agent:

python
# 最小 Agent:模型在循环里自主决定调工具还是给出最终答案
def run_agent(task, tools, max_steps=20):
    messages = [
        {"role": "system", "content": "你可以使用工具完成任务。想清楚再行动。"},
        {"role": "user", "content": task},
    ]
    for step in range(max_steps):
        # 1. 模型看完整历史,决定下一步:调工具 or 直接回答
        response = llm.chat(messages, tools=tools.schemas)

        # 2. 模型决定不再调工具 → 任务结束,返回最终答案
        if not response.tool_calls:
            return response.content

        # 3. 执行模型要求的每个工具调用,结果写回上下文
        messages.append(response)
        for call in response.tool_calls:
            try:
                result = tools.execute(call.name, call.arguments)
            except Exception as e:
                result = f"工具执行失败: {e}"   # 错误也要喂给模型,让它自己纠偏
            messages.append({"role": "tool", "tool_call_id": call.id,
                             "content": str(result)})

    return "已达最大步数,任务未完成"   # 永远要有退出条件

拆解这段代码,它包含了 Agent 的全部本质要素:

  • 循环 + 退出条件:for 循环就是 Agent Loop,max_steps 是防止失控烧钱的护栏。真实系统里还会有超时、token 预算、人类接管等更多退出条件。
  • 模型主导控制流:下一步做什么完全由 llm.chat 的输出决定——这正是 Anthropic 定义里「LLM 动态指挥自身流程」的代码形态。
  • 环境反馈闭环:工具结果(包括报错)追加进 messages,模型下一轮能看到真实后果并自我修正。这就是 ReAct 论文「reasoning + acting」交替循环的工程实现。
  • 记忆就是 messages:短期记忆没有独立模块,就是那个不断变长的列表。等它装不下窗口了,才需要摘要、压缩、外部检索——那就是上下文工程要解决的问题。

市面上所有框架——LangGraph、OpenAI Agents SDK、Claude Agent SDK——本质上都是在这个循环外面加状态管理、流式输出、中断恢复、权限控制。先能手写出这个循环,再去选框架,你会知道每一层抽象到底替你做了什么。动手教程见从零构建你的第一个 Agent与动手教程。

六、能力边界:Agent 能做什么,不能做什么 ​

对 Agent 建立正确的期望,比学会写 Agent 更重要。以下是 2026 年当下比较诚实的判断。

已经可靠的 ​

  • 编码类任务:代码有自动化测试作为客观验证,环境反馈(编译错误、测试结果)清晰,是 Agent 最先跑通的领域。Claude Code、Cursor 等产品的成功都建立在这一判断上,详见Claude Code 案例与Cursor 案例。
  • 检索与研究类任务:目标明确、步骤是「搜索-阅读-综合」的循环,容错率高(查错了再查一次),Perplexity、Deep Research 类产品已规模化,详见Perplexity 案例。
  • 结构化流程的自动化:客服工单、数据录入、报告生成——OpenAI 指南总结的三类高价值场景是:复杂决策、规则难维护、重度依赖非结构化数据。

仍然困难的 ​

  • 长链条任务的错误复合:单步 95% 的准确率,二十步之后只剩约 36%。多步任务是 Agent 的价值所在,也是它的阿喀琉斯之踵——步数越多,越需要评测和护栏,详见评测体系。
  • 不可逆的高风险操作:付款、删除、对外发送。模型的一次幻觉就可能造成真实损失,这类动作必须有人类确认或硬性规则兜底,详见安全与护栏。
  • 模糊目标的判断:「帮我做得好一点」这类没有明确验收标准的任务,Agent 会在「看似忙碌」中耗尽预算。成功的 Agent 任务几乎都有清晰的成功判据。
  • 跨会话的长期记忆:目前的记忆方案(RAG、摘要、结构化画像)都还是补丁,不是解法。Agent 会「忘记」上周教过它的东西。
  • 成本与延迟:一个二十分钟的多步任务可能烧掉数百万 token。能用一次调用解决的,别用二十次——这句话值得贴在显示器上。

一句话总结边界:Agent 擅长「目标明确、可验证、可试错」的任务;惧怕「目标模糊、不可逆、错不起」的任务。选场景时先问这三个问题,比纠结框架选型有用得多。更多反面教材见常见陷阱。

七、接下来怎么学 ​

本站的内容就是围绕这一页的定义组织的。推荐顺序:

  1. 建立全景:读全景解剖,看一个真实 Agent 系统的完整组件图;再读概念辨析,把 Agent、workflow、RAG、Copilot 这些词分清楚。
  2. 吃透核心循环:从Agent Loop开始,依次读工具与 MCP、记忆、规划、上下文工程。这五个组件合起来就是本页公式的完整展开。
  3. 动手实现:跟着从零构建手写一个无框架的 Agent,再用一个框架(选型见框架总览)重写一遍,体会抽象层的得失。
  4. 进阶架构:单 Agent 玩熟之后,再碰多智能体、评测、可观测性——顺序不要反,多 Agent 在大多数时候是过度设计。
  5. 看真实产品:读案例栏目里 Claude Code、Manus、Devin 等系统的拆解,对照本页的光谱判断它们各自站在哪个位置。
  6. 面向求职:如果目标是转行或求职,直接去岗位版图和知识地图,按 JD 倒推学习重点。

完整的路径设计见学习路径。

参考资料 ​