如果只看今天的产品宣传，Agent 很容易被说成一种突然出现的新物种。 但把时间线拉长一点，你会发现它其实不是一个新词，而是一个老问题在大模型时代重新落地后的新形态：
如何让一个系统在环境里，围绕目标，持续做判断，并真正采取行动。这才是理解 Agent 的起点。
在经典 AI 里，agent 从来不是“聊天机器人”的同义词。
无论是 Russell 与 Norvig 的传统，还是 Berkeley CS188 这类大学课程，都把它描述成一种更基础的存在：
- 它处在环境里
- 它能够感知环境
- 它围绕目标选择动作
- 它的动作会影响环境
也就是说，Agent 最原始的含义，不是“会不会说”，而是“会不会在环境里围绕目标行动”。
这个经典定义到今天并没有过时。 真正改变的，是实现手段。
过去，Agent 更多依赖规则、搜索、规划、强化学习或专用控制器。 到了大模型时代，语言模型开始承担更大比例的理解、分解、协调与选择工作，于是 Agent 不再只是一个 AI 概念，而开始变成一种新的软件组织方式。
今天的现代 Agent，往往同时包含三层东西：
- 模型：负责理解目标、形成下一步判断
- 动作接口：包括工具、代码、API、界面、外部系统
- 运行基础设施：包括状态、记忆、会话、追踪、治理和恢复
因此，现代 Agent 不是“模型多了一个功能”，而是“模型被放进了一套持续运行的任务闭环”。
如果把这件事说得更直接一点，本书给出的工作定义是：
Agent 是一种以目标为中心，
在环境中持续观察、决策、行动，并依据反馈修正过程的运行系统。这个定义为什么比泛泛的“智能体”更有用？ 因为它一下子把问题从人格想象拉回了系统结构。
要判断一个东西是不是 Agent，不该先问它像不像人，而该先问：
- 它在优化什么
- 它看到了什么环境信息
- 它能执行什么动作
- 动作结果会不会改变后续行为
只要这几个问题回答不清，系统再会聊天，也可能还不是 Agent。
也正因为如此，今天公开工程资料虽然措辞不同，但在结构认识上已经开始明显收敛。
Anthropic 把 agentic systems 的重点放在动态过程上，强调 agent 的关键不是模型说得像不像，而是模型会不会在环境反馈中持续决定下一步。
OpenAI 的 Agents 文档和 Agents SDK 则把 Agent 明确放进一个运行时结构里，围绕 tools、sessions、handoffs、guardrails、tracing 来定义它。
Google Cloud 更强调自治和任务推进，明确区分 bot、assistant 和 agent，指出后者不是只响应请求，而是能主动推进目标。
Google ADK 甚至直接把 agent 定义成一个 self-contained execution unit，也就是为特定目标自主行动的执行单元。
Microsoft Foundry、Microsoft Agent Framework 和 AutoGen 则把 Agent 统一放回运行时语境，强调它不是单次模型调用，而是带状态、带工具、带流程控制的系统实体。
AWS、IBM、NVIDIA、ServiceNow 这些企业和平台视角也在强调相近结构：目标、环境、推理、规划、行动、记忆、治理。
这些说法来自不同公司、不同平台、不同产品线，但最后都在回答同一个问题：
Agent 的本质不是“更像人”，
而是“能在不完全确定的任务过程中持续推进目标”。研究界也在沿着同一个方向，把这个概念做得越来越实。
ReAct 的重要性，不在于它给了一个新 prompt，而在于它把 reasoning 和 acting 放进同一个交替循环。
Toolformer 的重要性，不在于“终于会调 API”，而在于它把工具使用解释成一个决策问题：什么时候调、调什么、参数怎么给、结果如何进入下一轮。
Reflexion 进一步说明，Agent 不是一次性推理，而是会从结果和失败中修正后续轨迹。
Generative Agents 则把 observation、memory、reflection、planning 明确拼成一个持续行为架构。
后续 survey 又把这些共性总结成统一框架，说明 LLM Agent 已经不再是零散技巧，而是在形成稳定的方法族。
如果把这些研究压缩成一句话，可以说：
Agent 不是一次回答，而是一套持续运行的认知-执行回路。而 benchmark 的出现，则从反面逼迫我们把定义说得更清楚。
如果 Agent 只是“会调用工具的聊天机器人”，那么它们在真实环境里的表现不应该掉得这么厉害。
但 WebShop、WebArena、AgentBench、OSWorld 这一类 benchmark 共同说明：
- 单轮语言能力并不等于真实任务能力
- 一旦任务需要多步行动、状态保持和环境交互，差距会被迅速放大
- 真正困难的地方不在“会不会答”，而在“能不能长期稳定推进任务”
这意味着，“什么是 Agent”这个问题，不能靠表面现象来回答。
一个系统看起来可能很像 Agent：
- 会对话
- 会列计划
- 会调用工具
但如果它没有明确目标、没有环境感知、没有持续状态、没有反馈回流、没有真正的过程控制，它仍然很可能只是一个能力增强的聊天系统。
所以，理解 Agent，至少要分四层来看。
第一层，是经典定义。 Agent 是一个在环境中围绕目标做选择并采取动作的实体。
第二层，是结构定义。 它至少要包含目标、观察、决策、动作、反馈这些最小环节。
第三层，是运行定义。 它要能在多轮中保持状态、吸收反馈、必要时暂停、恢复、交接或请求人工介入。
第四层，是工程定义。 它必须是可观测、可控制、可评测、可治理的运行系统，而不是一段希望模型“自己搞定”的 prompt。
这四层合起来，才是今天真正稳定、可落地的 Agent 理解方式。
为了避免后面不断混淆，也可以先给几个反例。
第一种，不是 Agent，只是问答接口。 用户问一句，系统答一句，不读取环境，也不改变外部状态。
第二种，不是 Agent，只是工具增强助手。 模型会调用搜索、天气、数据库等接口，但调用路径由程序预先写死，系统并不真正决定任务推进策略。
第三种，介于中间，更接近 agentic workflow。 系统包含多个步骤，但整体路径、异常分支和完成标准大多是预定义的，模型只在局部节点上发挥。
第四种，才是本书要讨论的 Agent。 系统在目标约束下读取环境，自主决定下一步，执行后接收结果，再依据结果决定后续路线，这个过程可能持续很多轮。
举个最直观的例子。
如果任务只是“帮我查一下今天上海天气”，一次工具调用和一次回答就够了，这大概率不是一个需要 Agent 的问题。 但如果任务变成“帮我安排一次周末家庭出行，并根据天气、预算、交通和孩子作息动态调整方案”，系统就必须持续处理：
- 多重约束
- 环境变化
- 信息补查
- 方案比较
- 失败后的改路
- 何时继续自动执行、何时请求确认
这时系统面对的已经不是“一个问题”，而是一段任务过程。 而只要进入任务过程，Agent 的结构性就会立刻显现。
所以，本章最终想留下的，不是一个看起来很炫的名词，而是一条稳定的判断标准：
当一个系统开始围绕目标，在环境中持续观察、决策、行动，
并通过反馈不断修正自己的任务轨迹时，它才真正进入 Agent 形态。反过来说，如果一个系统没有环境感知、没有动作空间、没有状态更新、没有反馈闭环、没有过程控制， 那么无论它多会说、多像人、多会列计划，它都还不是成熟的 Agent。
这也是为什么理解 Agent 的最好方式，不是把它想得更神秘，而是把它看得更具体。
它不是人格。 它不是魔法。 它不是“模型加工具”五个字就能讲完的东西。
它本质上是一种新的系统形态：
让模型不再只负责生成答案，
而是进入任务闭环，成为可运行、可决策、可执行的系统核心。下一章要解决的，就是理解 Agent 时最常见的第一个混淆：
Agent 和 Workflow，到底差在哪。