官方定义#

Anthropic（Building Effective Agents, 2024.12）：

“Agents are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.”（Agent 是这样一种系统：由 LLM 动态决定自己的处理过程和工具调用，并对”如何完成任务”保持控制权。）

Google Cloud：

“AI agents are software systems that use AI to pursue goals and complete tasks on behalf of users. They show reasoning, planning, and memory and have a level of autonomy to make decisions, learn, and adapt.”（Agent 是用 AI 代表用户去追求目标、完成任务的软件系统，具备推理、规划、记忆能力，并拥有一定的自主决策、学习和适应能力。）

Microsoft Learn：

“Agents are dynamic, goal-oriented systems that can reason, plan, and act on behalf of users.” Agent 的三个核心组件是 Model（LLM 作为推理引擎）、Instructions（目标、行为和约束）、Tools（获取知识或执行动作的能力）。

三家定义合起来看，Agent 的本质有三层意思：

第一，它是一个软件系统，不是单一模型，也不是单一函数。第二，它的大脑是 LLM，由 LLM 在运行时即时决定”下一步做什么”。第三，它带着目标工作——用户给的是结果要求，不是步骤指令；具体路径由 Agent 自己摸索。

LLM（Large Language Model，大语言模型）是 Agent 的核心零件，但 Agent ≠ LLM。LLM 本身是无状态的”下一个 token 预测器”，喂文字、吐文字；Agent 在 LLM 外面加了工具调用、循环控制、记忆，使它能”做事”而不仅是”说话”。

一个具体例子#

用户对 Agent 说：“帮我安排一个下周和 Sherry 的 30 分钟 1on1。”

内部发生的事情大致是：Agent 调日历工具查双方下周空闲时段 → 选出 3 个备选 → 调发邮件工具向 Sherry 询问偏好 → 收到回复后调建会议工具创建会议 → 把结果汇报给用户。这一连串决策不是程序员写死的 if/else，而是 LLM 看着目标和工具列表即时决定的。

简而言之#

Agent 是以 LLM 为决策核心、能自主选择工具与路径、以达成用户目标为终点的软件系统。

Agent vs LLM Wrapper（聊天界面算 Agent 吗）#

LLM Wrapper（壳子）指仅在 LLM 外面套了一层 UI 和提示模板的应用。判定方法很直观：如果同样的输入复制到原生 ChatGPT 能得到一样的结果，那它就是 Wrapper。

ChatGPT、Claude、Gemini 的聊天界面在”纯文字问答”模式下并不是 Agent，更接近 Wrapper。但当聊天界面开启了网页搜索、Code Interpreter、Computer Use 等能力，让模型自己决定调工具，它就升级成了 Agent。Claude Code、Cursor 这类编程助手则是非常典型的现代 Agent，因为它们会自己读文件、改代码、跑测试、根据结果决定下一步动作。

Agent vs Workflow#

Anthropic 称：

“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.”

也就是说，Workflow 的执行路径写死在代码里，LLM 只在指定节点干活；Agent 的执行路径由 LLM 在运行时即时决定。这是两者唯一的、也是根本的分界线。

人类在 Agent 系统里”设的不是流程”，而是”边界”——告诉它扮演什么角色、有哪些工具可用、什么时候应该停。具体先调哪个工具、调完之后下一步做什么、要不要重试，全部交给 LLM。

Anthropic 在同一篇文章里给的关键建议是：能用 Workflow 解决的就不要上 Agent。Workflow 可预测、好调试、便宜；Agent 灵活但失控风险高、成本也高。只有”路径无法预先确定”的开放任务，才值得用真正的 Agent。

Agent 是不是只是”LLM 套壳”#

这是常见的批评，对粗糙产品成立，但对成熟 Agent 系统不成立。Andrew Ng 给出过一个被广泛引用的实验：在 HumanEval 编程基准上，强 LLM 直接零样本回答约 67%；弱 LLM 配上完善的 Agentic Workflow（含反思、工具、规划）能到约 95%。架构带来的提升可以超过模型本身的提升。 Agent 外面那层工程，业界叫 Agent Harness（代理外骨骼），由工具集、系统提示、上下文管理、循环控制、子 Agent、外部协议接入等组成。说”套壳”低估了这套工程的复杂度。

Agent vs MCP#

[[MCP]]（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年提出的开放协议，规定了”外部工具如何被 Agent 标准化调用”。它和 Agent 不在同一个层面：

打个比方：MCP 像 USB-C 标准，Agent 像电脑——电脑里有 CPU 会做决策，USB-C 接口只是规定”外设怎么接进来”。在 MCP 出现之前，每个 Agent 想接一个工具都要单独写一段适配代码，N 个 Agent 接 M 个工具就要写 N×M 套集成。MCP 把这件事标准化了：工具方写一次 MCP Server，所有支持 MCP 的 Agent 都能用，因此被称作 “AI 时代的 USB-C”。

落到代码层面的五样东西#

剥开任何一个 Agent 框架，里面通常是这五样：System Prompt（角色和规则的字符串）、Tool Registry（工具清单加 JSON Schema）、Agent Loop（while 循环）、LLM Client（实际调模型 API 的代码）、Memory（短期是消息列表，长期是向量数据库）。

最核心的是 Agent Loop。它的逻辑非常朴素：把当前上下文喂给 LLM，LLM 输出一段思考——如果思考里说要调工具就调，把结果拼回上下文继续下一轮；如果说已经得到答案就跳出循环返回结果。

ReAct：现代 Agent 的事实标准#

Loop 内部的”思考风格”，业界主流是 ReAct（Reasoning + Acting，推理与行动交替）。它让 LLM 每轮显式产出三件事：Thought（在想什么）、Action（要调什么工具）、Observation（工具返回了什么）。这种”想一步、做一步、看一步”的循环已成为大多数 Agent 框架的默认推理范式。

具体形态大致是这样：

1
Thought: 用户想查自己的 manager，需要先知道用户身份
2

3
Action: lookup_current_user()
4

5
Observation: Michael Zhao, employee_id=12345
6

7

8

9
Thought: 有了 employee_id，可以查 manager
10

11
Action: get_manager(12345)
12

13
Observation: Akira Yamamoto
14

15

16

17
Thought: 信息够了，可以回答
18

19
Answer: 你的 manager 是 Akira Yamamoto。

最小可运行 Agent 的尺寸#

值得记住的一点是，最小可运行的 Agent 大约 30 行 Python 就能写完：一个 while 循环、一次 LLM 调用、一次工具调用、消息拼接，仅此而已。Anthropic 原文的态度很明确——“如果能避免就别用框架，大多数 Agent 直接用 LLM API 就能写出来”。LangGraph、CrewAI、Microsoft Agent Framework 这类框架的真正价值是在生产环境里管多 Agent 协作、可观测性、鉴权、容错，而不是 Agent 内核本身有多复杂。