Agent到底是什么

背景

最近一段时间，我们陆续完成了三个循序渐进的 Agent 实践：

• 01_build_agent_from_scratch：用最朴素的 ReAct 文本协议（正则解析）跑通“思考→行动→观察”的闭环，并输出文章 100行代码从零实现一个Agent
• 02_tool_calling_fc：把“工具调用”升级为 Function Calling（结构化 tool_calls），让调用更稳定、更可控，并输出文章 Agent工具调用：从正则解析到Function Calling
• 03_mcp_practice：引入 MCP，把工具服务化、可发现，进一步提升扩展性，并输出文章 这就是MCP

随着对 Agent 理解的加深，困惑也随之增多：

• Agent 与 大模型是什么关系？
• 先有大模型还是先有 Agent？
• 如果一个 AI 应用程序没有通过大模型调用工具，那么还算不算 Agent？
• Agent 有没有什么典型架构？
• Agent 与 ReAct 框架的关系是什么？
• ...

本文将带着读者逐一拆解这些问题，用更系统的视角把 Agent 彻底讲明白。

Agent 前世今生

这张图来自《人工智能：现代方法》一书，它可以帮我们理解 Agent 的概念。

agent.png

在这张图里，智能体通过传感器从外界感知环境，并将接收到的信息交给中央的“大脑”处理，然后“大脑”做出决策，让执行器执行相应的动作，对环境产生影响。

根据书里的定义，任何先通过传感器（Sensor）感知环境（Environment），然后通过“大脑”决策，再通过执行器（Actuator）作用于该环境的事物都可以视为智能体（Agent）。

首先，人是一种智能体，眼睛、耳朵等器官是传感器，手、腿等器官是执行器，比如你看短视频时发现一款商品很好且价格合适（传感器感知环境），然后决定购买（大脑决策），再点击链接下单（执行器执行动作）。

接着，你可能也想到了，我们开发的软件系统也是一种智能体。接受外部的请求就是在感知环境，通过业务规则来处理请求就是通过“大脑”决策，回复应答就是在对环境执行动作。

这样一来，智能体就不像之前以为的那样高高在上了。但是，如果我们开发的软件系统也算是智能体的话，那今天谈论的 Agent 到底和它有什么区别呢？答案就是“大脑”。在传统的软件系统中，所有业务处理规则都是我们硬编码在其中的，即“大脑”的思考是固定不变的，而在人工智能领域，这个“大脑”是具备灵活性的，它可以自行推断出下一步该做什么。

所以，Agent 是一种能够自主感知周围环境、做出决策、采取行动达成特定目标的系统。

Agent 在解决问题的过程中，我们完全没有参与，都是其“大脑”自己思考该干什么，然后执行相应的动作，这就是“自主”（Autonomous）的含义。“自主”是 Agent 与传统软件系统之间的最大差异。

Agent 虽然在人工智能领域已经存在了很长的时间，但终究只在这个领域内部讨论，一个重要的原因就是 Agent 缺少一个好“大脑”，直到 ChatGPT 横空出世。因为大模型有很强的推理能力，Agent 需要的好“大脑”已经具备，于是一大批人开始尝试以大模型为基础开发新一代的 Agent，其中最典型的就是 AutoGPT。

AutoGPT 是 GitHub 上的一个开源项目，它致力于使 GPT4 完全自主。用户使用 AutoGPT，只需要告诉 AutoGPT 一个目标，AutoGPT 会自主生成执行计划，自主和 GPT4 交互，并一步一步完成计划，最后输出用户想要的结果，整个过程完全不需要用户参与。另外， AutoGPT 实现了很多工具，可以进行网络搜索、文件操作、代码执行等操作，和现实世界打通，极大扩展了大模型的能力，这远远超出普通人对大模型边界的认知。随着 AutoGPT 的流行，各种以大模型为新脑的 Agent 纷纷问世，AI 领域曾经无法很好实现的 Agent 终于可以落地了。

Agent 架构

agent-system.png

一个完整的 Agent 架构包括规划、记忆、工具和行动四个组件：

• 规划（Planning）：负责将大目标分解成小目标，也可以对既有行为进行反思和自我改善
• 记忆（Memory）：包括短期记忆和长期记忆，短期记忆提供多轮对话的能力，长期记忆提供长时间保留和回忆信息的能力
• 工具（Tools）：能力集合，是手和脚等执行器，用于扩展大模型的能力边界
• 行动（Action）：把“下一步要做什么”落地执行，最常见的是根据大模型的规划完成一次工具调用，也可以是静态调用一个 API

从这些组件的简介我们不难看出，规划组件的能力是需要智能完成的，这个部分要归属于大脑，在实现中，我们可以让大模型来做这部分工作。在记忆组件中，短期记忆可以用聊天历史的方式解决，而长期记忆，我们可以存放到向量数据库中，采用类似 RAG 的方式解决。工具组件主要是与不同的内容集成，这个部分是程序员最熟悉的部分，属于常规的编码。行动组件就是对环境执行一个动作，最常见的行动载体是工具。

架构图中有实线，也有虚线，分别代表什么？

实线代表主流程，是最小可用的 Agent 闭环：

• Agent -> Tools：工具是“外部世界接口”（Calendar/Calculator/Search/CodeInterpreter 等），Agent 知道自己有哪些能力可用，并基于这些能力做选择
• Agent -> Memory：Agent 把本轮输入、工具运行结果、关键中间结论写入记忆，下一轮再从记忆取上下文
• Agent -> Planning：Agent 触发规划/推理，产出下一步策略（可能是子目标、下一步行动等）
• Agent -> Action：把“决定好的下一步”落地执行（通常就是一次工具调用或一次静态 API 调用）

虚线代表可选分支，是 Agent 的增强能力：

• Tools → Action：Tools 本身不是“动作”，它只是能力集合，Action 才是把某个 Tool 调用落地的一次执行，虚线强调 Action 一般是通过 Tools 来完成的，但也有特殊情况，比如 Planning 评审完一段代码后，Action 调用 Gerrit 的 API 将评审意见写到变更单
• Memory → Planning/Reflection：用记忆驱动更强的规划与自我修正，虚线强调这些“高级规划/自我修正能力”通常需要回看历史轨迹与关键状态（来自 Memory），并且不一定每轮都触发，同时 Reflection 会直接消费记忆（不一定通过 Planning 来“转发”），Reflection 的产物再回到 Planning 和 Agent，影响后续决策

看过前面三篇文章的读者可能会发现，之前的 Agent 实现代码中并没有 Tools、Action、Memory、Planning 这四个组件对应的四个模块。在“架构语境”里，组件描述 Agent 必须考虑的职责，而不是模块。四个组件描述 Agent 必须考虑的四类职责，而不是限定 Agent 一定要做成四个独立模块。

在“工程语境”里，模块是系统的一个实现单元，粒度可大可小：

• 小型项目：可能只有一个 Agent 类 + 一堆函数，Tools、Action、Memory、Planning 混在一起（职责存在，但模块不独立）
• 大型项目：Tools、Action、Memory、Planning 会拆成独立模块，甚至 Reflection 也拆成独立模块

我们审视一下大模型与 Agent 的关系：

• 从“系统归属”看，大模型是 Agent 的一个关键能力提供方，但不属于 Agent
• 从“能力归属”看，大模型是 Agent 的“大脑”，属于 Agent 的一部分

ReAct 框架

ReAct 是 "Reasoning + Acting" 的缩写，也就是推理 + 行动，由普林斯顿大学和 Google 在 2022 年提出。

ReAct 的核心思想很简单：让大模型像人一样，先思考再行动，看到结果后继续思考。

大模型每做一个任务都会经历思考（Thought）、行动（Action）、观察（Observation）三个阶段：

• 思考，决定下一步的动作，一般是选工具填参数，相当于大脑决策
• 行动，完成一个具体的动作，一般是执行一个工具，相当于大模型有了手和脚等执行器
• 观察，反馈行动的结果，一般是将工具运行结果注入给大模型，相当于大模型有了眼睛和耳朵等传感器

大模型为了完成一个目标，需要不断地做一些任务。思考、行动和观察这三个阶段不断循环，直到目标达成：

Thought → Action → Observation → Thought → Action → Observation → ... → Answer

我们假定 Agent 工具调用使用正则解析方式，以智能点餐助手为例来逐步推演 Agent 架构的四个组件是如何支撑 ReAct 三个阶段的：

• Agent 在初始化阶段把 Tools 组件提供的工具说明（系统提示词，role:system）写入 Memory 组件（基于消息列表的短期记忆）
• 用户: 我要2份汉堡和1杯可乐，Agent 将用户问题作为第一轮输入（用户提示词，role:user）写到 Memory 组件
• Thought: Planning 组件从 Memory 组件得到工具说明和用户问题，分解任务并决定下一步动作（查询汉堡价格[Call: ask_menu_price: 汉堡]），并将下一步动作（AI 助手的回复，role:assistant）写到 Memory 组件
• Action: Action 组件调用 Tools 组件中的工具 ask_menu_price(汉堡)
• Observation: 工具运行结果是“汉堡的价格是25元”，Agent 将结果作为下一轮输入（用户提示词，role:user）写入 Memory 组件
• Thought: Planning 组件从 Memory 组件得到对话历史和 Action 组件的执行结果，规划下一步动作（查询可乐价格[Call: ask_menu_price: 可乐]），并将下一步动作（AI 助手的回复，role:assistant）写到 Memory 组件
• Action: Action 组件调用 Tools 组件中的工具 ask_menu_price(可乐)
• Observation: 工具运行结果是“可乐的价格是8元”，Agent 将结果作为下一轮输入（用户提示词，role:user）写入 Memory 组件
• Thought: Planning 组件从 Memory 组件得到对话历史和 Action 组件的执行结果，规划下一步动作（计算总价[Call: calculate: 25*2 + 8*1]），并将下一步动作（AI 助手的回复，role:assistant）写到 Memory 组件
• Action: Action 组件调用 Tools 组件中的工具 calculate(25*2 + 8*1)
• Observation: 工具运行结果是“58元”，Agent 将结果作为下一轮输入（用户提示词，role:user）写入 Memory 组件
• Thought + Answer: Planning 组件从 Memory 组件得到对话历史和 Action 组件的执行结果，判断任务已完成，可以输出答案（您的订单：汉堡x2=50元，可乐x1=8元，总计58元），并将思考和答案（AI 助手的回复，role:assistant）写到 Memory 组件
• Agent 发现没有工具调用，结束循环

由此可见，“ReAct 的三个阶段”其实就是“Agent 四个组件职责”的一次闭环。Agent 调用工具方式从正则解析到 Function Calling，再到 MCP，闭环的骨架完全不变，仅仅是工具如何被模型选择以及工具如何被执行又一些变化。

为了更直观地理解，我们从“工具”这一条主线做一次对比：

总结

本文从前面的三次实践出发，先回到 Agent 的经典定义与历史脉络，再拆解 Agent 典型架构的四类职责，最后通过 ReAct 机制将这四类职责组装成一个可持续推进的闭环。

Agent 是一种能够自主感知周围环境、做出决策、采取行动达成特定目标的系统，它在 AI 领域比大模型出现的早，只不过一直缺少一个好“大脑”，直到 ChatGPT 横空出世。各种以大模型为新脑的 Agent 纷纷问世，AI 领域曾经无法很好实现的 Agent 终于可以落地了。

Agent 架构包括四个组件：Planning、 Memory、Tools 和 Action。这四个组件代表四类职责，分别解决“怎么想、记什么、能做什么、怎么执行”的问题，并不一定需要四个模块来实现。在 Agent 架构图中，实线代表主流程，是最小可用的 Agent 闭环，而虚线代表可选分支，是 Agent 的增强能力。

在运行机制上，ReAct 把 Agent 架构的四类职责组装成一个可持续推进的闭环：Thought（规划/决策）→ Action（执行，常见为调工具）→ Observation（结果反馈并写入记忆）→ 再次 Thought，直到产出最终 Answer。Agent 调用工具方式从正则解析到 Function Calling，再到 MCP，闭环的骨架完全不变，仅仅是工具如何被模型选择以及工具如何被执行有一些变化。

参考文献

• 极客时间专栏，《程序员的 AI 开发第一课》，郑晔
• 微信读书，《人工智能：现代方法（第4版）（上下册）》，斯图尔特·罗素