AI Agent有哪些类型？简单反射到多智能体

AI agent 的类型

AI agent 的类型来自同一套分类法：简单反射型、基于模型的反射型、基于目标型、基于效用型和学习型 agent。每个名称描述一个方面：agent 在行动前能记住多少信息，以及能提前规划多远。另有两个术语，即多 agent 和分层 agent，它们描述多个 agent 如何连接协作，而不是描述单个 agent 如何做出决策。

这套分类早于您使用过的所有模型。它源自标准 AI 教材。大型语言模型出现后，这套分类仍然适用，因为它提出的问题仍然决定设计：这个对象在行动前需要了解什么？如果您还在确定 agent 与其运行所依赖的聊天助手从哪里区分，请先阅读 AI agent 与其运行所依赖的 LLM 的区别。本页从这一步之后开始。

简单反射型智能体：一个条件对应一个操作

简单反射型智能体将当前输入映射为一个操作，不保留任何先前信息。如果温度高于 25，则打开风扇。这就是它的全部机制。

您几乎肯定使用过这类智能体。一个触发 n8n 工作流的 webhook 读取表单提交内容，并将一行数据写入数据库，这就是简单反射型智能体。即使中间加入语言模型，为该行数据选择一个类别，它仍然属于这一类型。询问它一小时前做了什么，它无法回答，因为没有任何机制保存这个答案。

这类智能体的实际表现通常比人们预期的更好。它的运行成本低，而且故障原因清晰：条件匹配了，或者没有匹配。当任务确实是“收到 X 后执行 Y”时，引入记忆只会增加出错方式，并不会带来收益。由 webhook 触发的 n8n 智能体就是这一分类中的类型，只是在上层增加了用户界面。

只要正确操作取决于历史记录，它就会失效。没有线程状态的回复机器人会在第三条消息时自相矛盾，因为前两条消息从未成为它的输入。

基于模型的反射型智能体：在事件之间保留状态

基于模型的反射型智能体会在内部维护一份环境状态，并在收到新输入时更新这份状态。这里的“模型”指的是世界模型，而不是神经网络。这个术语在当前含义出现前约40年就已存在，因此几乎所有人第一次读到时都会感到困惑。

一个在20分钟内未检测到活动后关闭灯光的家庭自动化规则，就是基于模型的。它必然如此。“当前没有活动”和“自21:40以来没有活动”对简单反射型智能体来说是相同的输入，只有已保存的状态才能区分二者。

LLM 版本指的是任何在后端使用内存存储的智能体：可以是滚动更新的对话摘要，也可以是智能体每次运行开始时读取的普通 markdown 文件。面向智能体的本地内存服务就是将这一思路封装起来的实现。机制没有改变。智能体对世界的状态表示会持续存在，不会随着创建它的事件结束而消失。

状态需要付出代价。过时的事实比没有事实更糟，因为智能体会充满信心地依据它采取行动，却不会发出警告。任何存储的数据都需要设置过期机制，或提供重新检查的方式，否则智能体会继续基于一台已在3月停用的服务器进行推理。

基于目标的代理：规划并达到可验证的状态

基于目标的代理接收一个目标状态，并搜索一系列能够达到该状态的操作。它从最终状态反向规划，因此无需预先写出完整路径。

编码代理是您可以亲自运行的最清晰示例。“让失败的测试通过”没有指定文件，也没有指定步骤。代理读取测试，制定计划，修改内容，运行测试，读取错误，然后再次尝试。循环在代理能够实际执行的检查上结束，这正是该指令有效而“改进这段代码”无效的原因。代理能够评估的目标，才是代理能够达到的目标。代理无法评估的目标会变成一个不断循环、同时持续产生费用的过程。在您自己的 VPS 上运行编码代理可以将这个循环放到不会占用您笔记本电脑的环境中运行。

成本就在这一环节中产生。每个规划步骤都需要再次调用模型，并携带目前为止的历史记录，因此一个十步任务的成本不只是单步任务的十倍，而是更多。真正重要的工程工作在于设计循环的结构，以及设置使循环停止的条件；循环工程正是讨论这一主题的内容。

基于效用的代理：在多个可接受答案之间进行选择

目标是二元的。效用是一个分数。基于效用的代理会面对多个可接受的结果，并根据您编写的函数选择得分最高的结果。

备份作业必须在工作日开始前完成，同时不能占满上行链路，这就是一个效用问题。这里没有唯一正确的答案，只有权衡。路由器根据价格和回答质量进行权衡，决定由哪个模型处理哪个请求，其问题结构也是如此。

算法不是难点。难点在于编写诚实的效用函数。如果只按成本评分，系统就会为每个请求选择最便宜的模型，包括那个确实需要昂贵模型的请求。系统会严格优化您测量的指标；而当您选择某个指标只是因为它易于测量时，这就会造成问题。

学习型代理：大多数人以为自己已经拥有的类型

学习型代理会根据过去结果的反馈改变自身行为。它需要一个用于评估结果的组件，以及一个根据评估结果调整策略的组件。

真正符合这一条件的自托管系统非常少。能够读取上周写入的笔记的代理，只是带有记忆文件的基于模型的代理。它的权重没有变化，策略也没有变化。检索不是学习。这个区别很重要：基于记忆的系统会无限重复同一个错误，除非有人修改记忆；而学习型系统应该能够停止犯这个错误。

如果需要实现学习部分，应先构建评估机制。一个带评分的测试集、对变更运行测试，以及决定保留还是丢弃变更，这三者构成一个闭环；在这个闭环中，您就是学习组件。这个过程比听起来更慢，也是目前在自托管组件上能够工作的唯一实现方式。自托管评估工具链就是从这里开始。

多智能体和分层系统：组织方式，而非类型

这不是第六种和第七种类型。它们描述的是智能体的组织方式。

多智能体系统会在共享环境中同时运行多个智能体，例如队列或 git 仓库。由于环境是共享的，智能体会在其中发生冲突。两个智能体同时编辑同一个文件是最常见的故障，解决方法是使用锁或工作队列。提示词无法解决这个问题。

分层系统会在工作智能体之上设置一个监督者。监督者拆分任务，分发各个部分，然后合并返回的结果。这种方式很常用，因为它符合人们分工协作的方式；但它的成本较高，因为监督者读取的每份报告都会使其上下文变大。多智能体框架展示了实际的接线方式。

一个真正能工作的智能体，胜过四个大多时候能工作的智能体。

每次交接都可能丢失信息。先从一个循环开始。只有在能够明确指出瓶颈步骤时，才将其拆分。

为什么几乎所有真实系统都是混合型

以一个您自行运行的部署代理为例。Webhook 会启动它，这是反射式行为。它会读取当前发布状态，这是基于模型的行为。它会规划从运行中版本到目标版本的步骤，这是基于目标的行为。它会根据当前负载选择发布窗口，这是基于效用的行为。它不会修改自身策略，因此不属于学习型系统。

一个系统可以同时对应分类法中的四个类别。分类法的价值在于作为设计检查清单，而不是给成品贴标签。系统行为异常时，关键问题是出错的是哪一层。触发器因错误事件而触发、状态变得过时、目标检查永远无法通过，以及评分机制奖励了错误结果，这是4类不同的错误，也需要4种不同的修复方法。

哪种类型适合哪类任务

• 触发条件固定、响应固定且不需要历史记录：简单反射。
• 正确响应取决于之前发生的情况：基于模型的反射。
• 最终状态可验证，但事先不知道路径：基于目标。
• 存在多个可接受结果，且它们之间确实需要权衡：基于效用。
• 需要结果随时间改进：构建评估闭环，并接受您本身就是学习组件。

您可以自行托管这些代理吗？成本是多少？

可以，成本分为两部分。编排的成本很低。n8n 实例或 Python 中的代理循环大部分时间都在等待网络调用，因此 2 vCPU 和 4 GB RAM 就足够运行。真正产生费用的是模型。

如果代理调用托管 API，服务器几乎不需要配置，账单则随 token 数量增长。对于目标驱动型代理，成本还会随允许的规划步骤数增长，因此应限制循环次数。

如果在自己的硬件上运行模型，RAM 决定了您实际能够运行哪些模型。以下数据是截至 August 2026 发布的 4-bit 量化权重的典型文件大小，同时给出了总 RAM 的规划值，因为上下文窗口和运行时也需要为权重以外的内容预留空间。

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

4-bit 量化的 8B 模型约占用 4.9 GB 权重；配备 10 GB RAM 的机器可以在不使用交换空间的情况下运行它。同样量化的 70B 模型占用 43 GB 权重，通常需要约 64 GB RAM。请注意，这些数字没有体现速度。在没有 GPU 的 VPS 上，4-bit 量化的 8B 模型每秒只能生成个位数的 token。对于需要连夜处理队列的代理来说，这已经足够；但如果有人正在等待结果，速度就会很慢。本地推理应保留给批处理任务，交互式部分则使用 GPU 或 API。可自行托管的 AI 代理简表介绍了哪些项目值得占用磁盘空间，2026 年代理学习路径介绍了应按什么顺序学习哪些内容。

分类法无法继续提供帮助

它没有涉及工具或权限。教材中的智能体只负责感知和执行。编写该章节的人并未考虑智能体持有生产环境 API token 的情况。拥有 shell 访问权限的目标型智能体，与仅拥有一个只读数据库连接的目标型智能体，在表格中属于同一行，但两者面临的风险完全不同。先确定智能体可以访问哪些资源，再决定它应当具备多高的智能程度；向智能体授予凭据前，请先阅读如何避免将密钥交给 AI 智能体。

它同样没有涉及步骤失败时会发生什么。真实智能体的大部分运行时间都在处理错误：例如遇到速率限制，或工具返回了模型未预期的内容。相关代码决定了系统是否可用，而分类法中的任何一行都没有描述这一点。

FAQ

AI agent 有哪 5 种类型？

简单反射型、基于模型的反射型、基于目标型、基于效用型和学习型 agent。它们按照 agent 在行动前掌握的信息量排序。简单反射型 agent 只能看到当前输入。基于模型的 agent 会保存环境状态。基于目标型 agent 会围绕目标状态进行规划。基于效用型 agent 会评估多个可接受结果，并选择得分最高的结果。学习型 agent 会根据反馈修改自身策略，但几乎没有自托管环境真正这样做。

简单自动化应该使用哪种类型的 AI agent？

使用简单反射型 agent。实际操作中，这通常意味着由 webhook 或计划任务触发固定的执行序列。如果正确响应只取决于刚到达的输入，记忆只会增加故障模式，不会带来额外能力。当您能够明确指出某个决策必须知道之前发生了什么时，再升级为基于模型的设计。

可以在 VPS 上运行自己的 AI agent 吗？

可以。编排层资源开销很小，因此 2 vCPU 和 4 GB RAM 足以让工作流引擎或 agent 循环稳定运行。真正需要决定的是模型的运行位置。使用托管 API 可以保持服务器配置较小，并将成本转为 token 用量。本地模型所需的 RAM 与参数量成正比；没有 GPU 时，其生成速度通常只有每秒个位数 token，更适合排队处理批量任务，而不是用于聊天窗口。

大型语言模型本身就是 AI agent 吗？

不是。模型将输入文本映射为输出文本，然后停止运行。只有当某个封装层将模型放入循环，使其能够对外部环境执行操作，并将结果反馈回循环时，模型才会成为 agent。这需要模型可调用的工具，以及一个告诉循环何时停止的条件。封装层才是 agent，模型只是其中一个组件。

需要多 agent 系统吗？

通常不需要。单个循环配合多个工具即可处理大多数任务，而且调试难度低得多。只有当任务的某些部分确实相互独立、可以同时运行，或者某个部分需要使用不同模型时，多个 agent 才有帮助。代价是协调复杂度：需要共享状态，还需要一个 supervisor；它读取每个 worker 的报告后，自身上下文会不断增大。当您能够明确指出哪个步骤运行缓慢时，再添加第二个 agent。