05 · Agent 有哪些类型？ - Agent Types
所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：01 · Agent 是什么？它如何工作？ - Fundamentals
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：如何建立能够解释 Agent 运行机制、控制权分配、状态管理和工程约束的分类体系？经典 Agent 架构与现代 LLM Agent 有什么关系？如何将任务特征转化为可检验的类型画像、架构选择和测试方案？
专题导读
Agent 的类型不是一份按产品名称排列的清单。研究 Agent、编程 Agent、浏览器 Agent 描述任务；反应式、计划式和混合式描述决策控制；同步、异步和事件驱动描述执行组织；建议型、审批型和受限自主型描述行动授权。不同维度可以组合，因此“研究型、异步、计划驱动、只读受限自主 Agent”是合理的完整画像，而“研究型与计划型二选一”则混淆了分类轴。
本篇首先建立分类对象、分类轴和可操作的判定方法，随后深入研究经典反射式、内部状态式、目标式、效用式和学习式 Agent 的行动机制，说明它们与现代模型驱动执行循环之间的继承与区别。接着从决策控制拓扑、自主权、时间模型、环境接口、状态和组织结构等维度研究现代 Agent 的类型，分析各类型对状态机、工具协议、故障恢复和评测的影响。
文章进一步提出一套可执行的分类画像与架构选择程序：使用任务契约和运行轨迹作为输入，通过显式规则提取类型特征，检测概念冲突，形成候选架构及验证计划。Python 标准库示例展示的是规则化类型判定与一致性检查，不宣称能够自动判断一个 Agent 在真实环境中的能力。最后通过研究助理、编程与浏览器操作案例，讨论同一任务如何在不同控制架构下实现，以及类型标签何时会失效。
一、研究对象：我们究竟在给什么分类？
1.1 四种常被混淆的对象
首先区分任务类型（研究、编码、客服）、Agent 架构类型（反应式、规划式、混合式）、运行部署类型（同步请求、后台任务、常驻服务）和系统组织类型（单 Agent、多 Agent 协作）。它们的分类对象分别是业务目标、行动决策机制、执行生命周期与组织关系。将这些概念并列为一组互斥选项，会使分类无法指导工程实现。
另一个重要区别是Agent 定义与Agent 的某次运行。定义可以声明允许使用的工具和最大自主范围；一次 Run 实际上可能只执行了模型问答，也可能触发审批、调用工具或进入后台等待。类型画像应区分 declared（设计声明）、configured（已绑定配置）和 observed（执行轨迹已证实）。例如，工具被注册不代表工具被调用；提示词写着“会反思”不代表系统实现了反思后的策略更新。
1.2 分类的目的：预测设计后果
有价值的分类必须能够帮助回答：谁决定下一步行动？谁执行动作？何时保存状态？遇到未知信息如何获得观察？什么操作需要批准？发生超时后能否恢复？如何验证任务完成？如果某个标签对上述问题没有任何可检验的影响，它可能只是产品定位或营销语言，而不是有效的工程分类。
因此本文采用多维类型画像 + 可观察判据 + 工程后果的方法。这里提出的类型字段是研究用的分析模型，不是统一行业标准；具体框架可能采用不同术语。
二、分类方法：从名称归纳转向可操作的类型判定
2.1 九条互相独立但可能关联的分类轴
| 分类轴 | 分类对象与判定问题 | 典型取值 | 主要工程后果 |
|---|---|---|---|
| 任务域 | 产物和成功条件是什么 | 研究、编程、浏览器、数据、业务、机器人 | 工具、证据与评测 |
| 决策机制 | 行动由什么机制决定 | 规则、反应式模型、计划驱动、效用选择、混合 | 控制器、搜索与状态 |
| 自主权 | 谁选择/批准/执行操作 | 建议、逐项审批、预授权受限、自主执行 | 权限、审计、审批 |
| 执行时间 | 何时启动、是否持续 | 同步、异步、事件驱动、定时、常驻 | 队列、检查点、通知 |
| 环境接口 | 可观察和可改变什么 | 文本、API、代码、浏览器、桌面、物理 | 适配器、沙箱、反馈 |
| 规划深度 | 行动序列如何形成 | 单步、迭代、多步计划、层级计划 | 计划表示、重规划 |
| 状态依赖 | 哪些信息跨步/跨任务保留 | 无状态、会话状态、持久运行状态、长期记忆 | 存储与一致性 |
| 组织拓扑 | 谁参与任务协作 | 独立单 Agent、受编排成员、协作网络 | 消息协议、责任归属 |
| 行动影响 | 外部操作有何副作用 | 只读、可逆写入、不可逆/高风险 | 幂等、补偿、审批 |
最后一条“行动影响”刻意独立于自主权。一个可以自主搜索公开网页的 Agent，可能风险低于一个每一步经人工批准但最终能够删除生产数据的 Agent。自主性高低不能代替风险分析。
2.2 标签判定需要证据
建议为每条标签记录三个字段：claim（声称的类型）、evidence（配置或轨迹依据）、confidence（证据是否充分）。例如，判断“计划驱动”，至少需要观察到显式计划结构或具有前瞻性的任务序列，并且后续行动以该计划为依据；仅凭模型在回答里写出“第一步、第二步”不足以确认运行时存在计划控制器。
判断“长期记忆增强”，应看到跨 Run 的持久化写入、检索与使用链路；同一会话的历史消息不自动构成长期记忆。判断“事件驱动”，需要看到外部事件作为触发条件进入执行器；用户发送一条普通消息通常属于交互触发，不能因此把所有聊天 Agent 都称为事件驱动系统。
2.3 分类不是能力排行榜
不存在“多 Agent 一定强于单 Agent”“计划型一定优于反应型”“高自主一定优于审批型”的普遍规律。类型选择本质上是对任务不确定性、行动成本、可观察性、风险、延迟和工程复杂度进行约束优化。分类的任务是揭示设计差异，而不是给出单一优劣排名。
三、经典 Agent 架构：五种机制如何决定行动
经典智能体理论提供了现代 Agent 类型研究的机制基础。其核心不是“产品属于哪类”，而是 Agent 如何根据感知、内部状态、目标和评价函数选择行动。
3.1 简单反射式 Agent（Simple Reflex Agent）
简单反射式架构采用条件-动作规则：action = rule(percept)。系统读取当前可观察输入，与规则条件匹配后输出行动，不必显式维护环境历史。典型实现是规则表、优先级规则链或确定性分支。
假设自动工单分流器仅根据当前工单字段决定部门：包含“发票”转财务，包含“账户登录”转技术支持。它实现了可解释、低延迟的决策，但当一条工单包含多种意图、信息缺失或依赖历史上下文时，单步规则容易产生错误。增加规则可以扩大覆盖，但也引入规则冲突与维护成本。
3.2 基于内部模型的反射式 Agent（Model-Based Reflex Agent）
当当前观察不足以确定真实环境状态时，系统维护一个内部状态 s_t。一般形式可写为：
s_t = update(s_(t-1), observation_t, action_(t-1))
action_t = policy(s_t, observation_t)
这里的 model 是对环境状态转移或隐藏信息的内部表示，不等同于现代语境中的“大语言模型”。例如，浏览器自动化只看到当前页面，但必须记住已经填写的表单、是否完成身份验证、上一次提交是否成功。内部状态可能是一组结构化字段，而不必是神经网络。
状态模型的关键挑战是状态估计错误：系统可能错误认为“提交未发生”，随后重复点击；也可能根据过期页面快照采取行动。状态更新需要以可信观察为依据，而不是把模型猜测当成已确认事实。
3.3 目标导向 Agent（Goal-Based Agent）
目标式 Agent 不只根据当前状态触发规则，还考虑行动能否通向目标。其基本形式是给定初始状态、目标谓词、候选动作与转移模型，寻找一条满足约束的行动序列。若动作和状态空间可形式化，可以使用图搜索或规划算法；若任务开放、环境变化快，可能由 LLM 产生候选计划并由运行时校验和执行。
例如，目标是“生成具有三种方案对比和来源依据的研究报告”。计划可以分解为识别评价维度、检索证据、逐项比较、形成结论、验证引用。执行过程中若某一来源失效，应调整后续路径，而不是盲目遵循初始计划。拥有目标不等于已经实现目标规划：只有目标描述、没有行动选择或计划更新机制的系统，不应被夸大为规划型 Agent。
3.4 效用导向 Agent（Utility-Based Agent）
当多个行动都能达到目标，但成本、风险和质量不同，系统可以使用效用函数进行选择。抽象形式为：
a* = argmax_a E[U(outcome) | state, a]
工程上通常不能精确计算期望效用，因此会使用启发式评分、预算约束或多目标排序。例如研究 Agent 在“继续检索”和“开始撰写”之间权衡证据增益、剩余时间与检索费用。必须明确评分是设计者定义的外部决策函数，不能未经证据便声称这就是 LLM 内部真实的行动算法。
效用函数的失败模式包括目标代理失真（优化检索数量而非证据质量）、权重不可解释、成本估计不准和高风险动作被低估。重要约束应作为硬规则处理，而不是仅通过效用惩罚来表达。
3.5 学习型 Agent（Learning Agent）
学习型架构通过反馈改变未来的决策能力。需要区分至少三种更新：①当前 Run 的上下文和状态变化；②跨 Run 的外部记忆、策略文件或技能资产更新；③模型参数或策略参数更新。它们都可能改善后续行为，但机制和验证方式不同。特别是“模型记住了本轮对话”不等于模型权重发生学习。
可用 policy_(t+1) = learn(policy_t, experience_t) 表示策略更新，但 learn 可能是参数训练、规则修订、技能改写或记忆写入。评价学习型 Agent 需要设置跨任务测试，确认性能提升来自可复用更新，而不是单次上下文变长或测试数据泄漏。
3.6 五类并非互斥的产品目录
现代 LLM Agent 可以同时维护状态、围绕目标规划、按风险与成本选择工具，并保存经验。因此经典五类更适合作为机制原型。其价值在于提出诊断问题：行动由什么信息决定？隐藏状态如何估计？目标如何表示？候选行动如何比较？反馈如何改变未来行为？
四、现代 LLM Agent 的控制架构：真正决定系统行为的分类
4.1 固定工作流：程序拥有主要控制权
固定工作流按预定义图或顺序执行：解析输入 → 检索 → 生成 → 验证。模型可以负责某些节点的语义处理，但不能任意决定跳过强制步骤或调用未授权工具。优势是执行路径易测试、成本易预测、故障边界清晰；缺点是对开放环境和未知分支的适应性有限。
严格说，固定工作流不一定构成自主 Agent。本篇保留它作为重要对照组：若固定流程已能可靠完成任务，就没有必要为了标签而引入动态控制器。
4.2 反应式工具 Agent：每次观察后决定下一步
其典型循环为：
State + Observation → Model/Policy → Proposed Action
→ Validate → Execute → New Observation → Update State → Repeat决策通常依赖当前上下文与最新工具结果，可能没有独立的长程计划对象。ReAct 是研究语言推理与行动交替的代表性工作：模型生成与任务相关的推理和行动，外部环境返回观察，后续决策继续依赖新观察。具体产品中的隐藏推理、工具协议和运行时执行不应被简单等同于论文的文本轨迹形式。
反应式方式适合探索性任务，但若缺少预算、去重和停止判据，容易重复搜索、陷入循环或在局部反馈下偏离总体目标。
4.3 计划-执行型 Agent：计划成为独立控制对象
该架构先建立计划 P = [step_1, …, step_n] 或任务依赖图，再由执行器逐步完成，并在必要时重规划。其技术区别在于计划具有可引用、可更新的状态，例如每个节点的依赖、输入、完成条件、失败策略和产物引用。模型可能生成计划，程序负责调度，模型再根据观察修订计划。
典型风险是计划在早期基于错误假设，执行器却持续推进。需要设置计划有效性检查：关键依赖是否满足、证据是否过期、是否出现新的约束、重规划是否会重复产生外部副作用。
4.4 分层控制型 Agent：不同层级处理不同时间尺度
分层架构将高层目标规划与低层操作执行分开。例如高层研究规划器确定“比较三种技术路线”，中层任务管理器安排“读取源代码、核对官方文档”，低层工具执行器处理具体 API 请求。不同层级拥有不同状态和决策频率。
分层的价值是减少单个模型调用同时承担长期规划、即时操作和权限执行的负担；代价是跨层契约、状态同步与错误归因更加复杂。只有真正存在独立职责和交接协议时，才应称为分层架构，而不是把长提示词分成几个标题。
4.5 混合控制型 Agent：模型提出行动，程序落实约束
现代工程中常见的实用方案是：模型负责不确定的语义理解、候选计划和行动建议；确定性运行时负责状态转换、权限校验、预算、工具执行、持久化和终止判定。可以把控制权拆成三个层次：选择权（提出下一步做什么）、执行权（实际触发外部操作）、批准权（允许高风险操作）。
例如模型选择 publish_report，运行时发现该操作需要审批，将任务置于 WAITING；只有审批事件通过、参数未变化、权限仍有效时，执行器才真正发布。这样的 Agent 可以具有较高的自主规划能力，同时保持严格的操作边界。
4.6 控制架构的关键差异
| 架构 | 下一步由谁决定 | 是否有独立计划 | 主要优势 | 主要失效模式 |
|---|---|---|---|---|
| 固定工作流 | 程序 | 预定义流程图 | 可预测、可验证 | 无法覆盖未知分支 |
| 反应式 Agent | 模型/策略每轮决策 | 可无 | 灵活、快速响应反馈 | 局部最优、循环 |
| 计划-执行型 | 计划器 + 执行器 | 有 | 管理依赖和进度 | 计划过时、重规划成本 |
| 分层控制型 | 多层控制器 | 通常有 | 复杂任务分解 | 协调开销、状态失配 |
| 混合控制型 | 模型建议 + 程序约束 | 可选 | 灵活且可控 | 适配器和策略复杂 |
这些分类可以交叉：一个计划-执行型 Agent 也可以采用混合控制；一个分层架构也可能在底层使用反应式循环。
五、自主性与权限：不能合并的一组维度
5.1 将自主性拆为四个可观察权限
自主性至少包含：目标分解权、行动选择权、外部执行权和持续运行权。一个 Agent 可以独立规划任务，却只能输出建议；另一个 Agent 可以自动执行有限的只读工具，却不能自行决定最终业务目标。因此不能仅用“低、中、高自主”代替实际授权描述。
可将每个能力定义为三元组：(action, resource_scope, approval_policy)。例如 ('search', 'public_web', 'auto')、('publish', 'team_website', 'per_action_approval')。这里的结构是工程建议，具体系统应使用权威的权限策略引擎执行，而不能仅依赖模型遵守提示词。
5.2 自主性与风险的二维分析
| 低影响动作（只读、沙箱） | 高影响动作（付款、删除、发布） | |
|---|---|---|
| 低自主决策 | 人工操作或逐步确认 | 严格审批、操作前验证 |
| 高自主决策 | 受限自主执行、预算控制 | 强制策略、审批、幂等、补偿与审计 |
“自主”不表示“获得无限授权”；“人工审批”也不自动意味着动作安全。审批需要绑定具体资源、参数和有效期，执行前仍须重新校验。
5.3 如何验证自主性声明
通过执行轨迹区分模型提议与真实执行：记录 proposed_action、policy_decision、approval_decision、executed_action、verified_effect。只有观察到真实的行动路径，才能确认系统实际拥有何种自主权。若一个产品只生成浏览器操作脚本，却没有实际执行能力，应称为操作建议或脚本生成，而不是已验证的浏览器操作 Agent。
六、执行时间与生命周期：同步、异步、事件与常驻
6.1 同步交互型
一次用户请求触发一个短 Run，通常在请求响应窗口内完成。其设计重点是端到端延迟、流式输出、用户取消、超时与预算。同步并不意味着无状态：同一会话可以连续触发多个 Run。
6.2 异步任务型
Run 被持久化并进入队列，由 Worker 执行；用户不必一直保持连接。关键机制包括任务 ID、状态查询、检查点、重试、结果通知和资源清理。长时研究、批量代码分析和复杂报告生成通常更适合这一模式。
6.3 事件驱动型
由外部事件（例如仓库提交、工单变化、监控告警）触发执行。设计重点是事件去重、触发条件、关联业务对象、重复投递与幂等。事件驱动描述触发机制，并不决定内部使用固定工作流还是动态 Agent。
6.4 定时与常驻型
定时任务按时间计划触发；常驻 Agent 或服务持续等待输入、维护订阅或管理任务队列。两者也可以组合：常驻服务接收定时事件，为每次执行创建独立 Run。常驻进程不应成为持久状态的唯一存储位置。
6.5 运行模式对架构的直接影响
同一个研究 Agent 可以作为聊天工具同步运行，也可以作为后台任务异步运行。两者的模型与研究方法相同，但生命周期契约不同：后台任务需要明确 Run 状态、暂停恢复、审批等待、进度通知和产物引用。运行模式因此应作为独立类型轴，而不是混入“研究 Agent”定义。
七、环境接口：Agent 到底能够观察和改变什么？
7.1 文本与 API 工具型
Agent 通过结构化工具接口读取数据或执行服务操作。核心机制是工具描述、参数验证、授权、调用调度、结果适配和错误处理。只读 API 与写入 API 具有不同的重试语义；发送邮件请求超时不代表邮件未发送。
7.2 代码执行型
Agent 能生成并执行代码，通常需要文件系统、终端、依赖管理和测试环境。执行能力应与生成能力分开：代码生成只是文本输出；代码执行涉及真实环境状态和副作用。沙箱隔离、命令白名单、资源预算与产物差异验证是关键约束。
7.3 浏览器与桌面操作型
Agent 可基于 DOM、无障碍树、截图或视觉模型理解界面，并通过点击、输入、滚动等动作操作环境。由于界面异步变化，系统通常需要“观察-定位-操作-验证”的闭环；不能把发出点击指令等同于操作成功。尤其要处理页面变化、重复提交、身份验证和不可信网页内容中的提示注入。
7.4 物理环境与机器人型
Agent 连接传感器与执行器，受到实时性、控制稳定性和物理安全约束。语言模型可用于高层任务规划，但低层闭环控制通常需要专门的控制器。将“LLM 能提出机器人动作”直接等同于“具备安全的机器人控制能力”是明显的技术误判。
7.5 可观察性与可控性是独立维度
环境可能部分可观察，行动可能不可逆。研究类型时应同时记录观察来源、观察延迟、动作执行确认方式和副作用等级。尤其对于网页、外部 API 和机器人，真实世界状态与模型推断状态之间可能长期存在差异。
八、规划、状态、知识与学习：跨越多个类型的能力轴
8.1 规划深度的操作性定义
单步型仅选择下一动作；迭代型每轮根据观察调整；计划型保存显式计划对象；层级型维护多层目标与子任务依赖。分类依据是控制机制和可观察数据结构，不是提示词里出现“计划”二字。
8.2 状态层级
至少区分模型调用上下文、会话历史、Run 的权威执行状态、跨 Run 的长期记忆和外部知识库。一个 Agent 可以具有丰富的会话上下文却没有长期记忆；也可以使用检索增强知识但不保存用户偏好。状态依赖分类要说明存储范围、读取条件和更新方式。
8.3 学习的证据门槛
如果系统声称“自我改进”，应能展示更新对象、触发条件、更新算法和跨任务评价。例如在完成一次任务后写入失败经验，后续任务检索到该经验并改变行动选择，这支持“记忆增强的行为适应”；但并不能证明基础模型完成在线参数训练。关于反思与学习的代表性研究应区分语言反馈、外部记忆更新和权重更新。
九、单 Agent、多 Agent 与工作流：组织拓扑不是认知类型
9.1 三种常见组织形态
单 Agent：一个主要决策主体负责当前任务，内部可调用多个工具或子流程。受编排的多 Agent：主控制器将任务交给多个具有独立角色或状态的 Agent，管理交接与结果汇总。协作型多 Agent：多个 Agent 通过消息或共享状态协调，可能存在协商、竞争或并行探索。
多 Agent 的关键不是出现多个模型调用，而是是否存在多个具有相对独立任务契约、决策状态和交接关系的执行主体。把“检索模型 + 写作模型”简单串联，并不自动构成有意义的多 Agent 系统。
9.2 为什么不应默认拆分为多 Agent
多 Agent 可能改善角色隔离、并行探索和职责清晰度，但会增加通信成本、上下文重复、结果冲突、故障归因和系统复杂度。只有任务可以有效拆分、角色之间存在稳定契约、并行收益足以覆盖协调开销时，才值得采用。
具体通信协议、共享状态、调度和协同一致性属于后续 Agent System 研究。本篇仅将组织拓扑作为类型画像中的独立轴。
十、类型画像的数据契约：把标签变成可检查的架构描述
10.1 建议的类型画像结构
{
"agent_id": "research-assistant",
"task_domain": "research",
"controller": "plan_execute_hybrid",
"autonomy": {
"goal_decomposition": "automatic",
"tool_selection": "automatic",
"external_write": "approval_required"
},
"execution_mode": "async",
"interfaces": ["web_search", "document_read", "report_write"],
"state_scope": ["run_checkpoint", "session", "project_memory"],
"planning": "explicit_plan_with_replanning",
"organization": "single_agent",
"effect_policy": "read_auto_write_approved",
"evidence_status": "configured"
}这是本文提出的说明性数据契约，不对应某个 SDK。其意义在于把“研究 Agent”转化为可审查的设计断言。比如 external_write=approval_required 必须能在工具执行器中找到相应的审批门禁；run_checkpoint 必须有持久化与恢复测试；explicit_plan_with_replanning 必须能观察到计划对象与更新事件。
10.2 标签与证据的映射
| 声称 | 最小验证证据 | 不能作为充分证据的内容 |
|---|---|---|
| 能调用工具 | 实际调用记录与结果 | 仅注册工具 Schema |
| 可暂停恢复 | 进程中断后恢复成功 | 仅在内存中设置 PAUSED |
| 具有长期记忆 | 跨 Run 写入与读取 | 单次对话历史 |
| 计划驱动 | 独立计划对象与执行依赖 | 回答里列出步骤 |
| 审批控制 | 执行前强制门禁及拒绝测试 | 提示词要求“先征求同意” |
| 自我改进 | 更新记录与跨任务效果验证 | 模型声称“吸取教训” |
10.3 分类冲突检查
分类系统应检测明显矛盾，例如同时声明“没有持久状态”与“崩溃后恢复原 Run”，或者同时声明“所有外部写入自动执行”与“所有外部写入必须逐项审批”。但需要避免误报：只读工具可以自动执行，写入工具需要审批，这不是冲突；异步与事件驱动也可以同时成立，因为一个描述执行模式，另一个描述触发来源。
十一、从任务契约推导类型：一套工程选择流程
11.1 先分析任务，不先选择标签
输入应包含任务目标、成功判据、环境不确定性、行动副作用、时间跨度、可预测的步骤比例、外部反馈需求和可用预算。若流程可预设且变化少，应先建立固定工作流基线；若需要根据未知观察动态选择工具，再考虑模型驱动 Agent；若任务包含明确依赖和长程目标，考虑显式计划；若任务长时间运行，则补充异步执行与检查点；若存在写操作，独立设计授权与幂等机制。
11.2 类型推导不是线性打分游戏
可把设计视为带约束的选择：
choose architecture minimizing (cost + latency + operational_risk)
subject to task_quality >= threshold, permission_policy satisfied, recoverability >= required_level
实际工程通常缺乏足够数据精确求解，适合使用候选架构、基线实验和消融测试，而不是给任务打一个“复杂度 78 分”后自动宣称必须采用多 Agent。
11.3 四种候选基线
| 候选方案 | 适用特征 | 首要验证 |
|---|---|---|
| 确定性程序 | 输入结构稳定、规则明确 | 功能正确性与异常覆盖 |
| 模型辅助固定工作流 | 需要语义处理但路径可预设 | 节点质量、错误传播 |
| 动态单 Agent | 需要根据观察选择步骤 | 行动质量、循环与预算 |
| 多 Agent 系统 | 可拆分角色且协同收益明显 | 协调收益、通信成本与冲突 |
这些方案是递进的候选复杂度，不是能力等级。应选择满足任务约束的最低充分复杂度。
十二、贯穿案例：同一个研究任务的三种类型实现
任务：比较三种 Agent 框架的持久化与恢复机制，形成具有原始来源的技术报告。
12.1 实现 A：模型辅助固定工作流
程序固定执行“检索官方文档 → 抽取指定字段 → 填写对比表 → 验证引用 → 生成报告”。模型负责抽取和归纳，程序控制每一步。类型画像：研究任务、固定工作流、同步或异步均可、只读工具、较低自主权。优点是路径可预测，适合研究对象已知、比较维度固定的场景；不足是难以自主发现新的重要问题。
12.2 实现 B：动态单 Agent
模型在每轮观察后选择继续检索、读取源代码、运行实验或撰写结论。运行时负责工具授权、预算、状态保存和终止检查。类型画像：研究任务、反应式或混合控制、受限自主、工具增强、可选长期记忆。优点是能应对未知资料和意外发现；不足是可能重复检索、遗漏关键维度或成本失控。
12.3 实现 C：计划-执行型研究 Agent
先形成研究任务图：确定评价标准 → 分别调查三种框架 → 交叉验证 → 实验复现 → 综合比较。每个节点有依赖、证据要求和完成判据。执行过程中允许根据新证据重规划。类型画像：研究任务、计划-执行与混合控制、异步、持久 Run 状态、只读自动/发布审批。适合研究周期长、证据链要求高的任务；代价是计划维护、检查点和状态一致性成本。
12.4 选择应基于实测
同一批研究任务分别运行三种方案，比较证据覆盖率、来源准确性、报告完整度、平均工具调用次数、人工干预次数、成本、延迟和失败恢复情况。若 A 已达到质量门槛且成本更低，就没有理由仅因 B 或 C 更“Agent 化”而选择它们。若 C 在复杂任务上显著减少遗漏，则显式计划的额外复杂度可能合理。
十三、跨领域案例：类型画像如何改变系统设计
13.1 编程 Agent
典型任务包含代码搜索、文件修改、测试与差异审查。类型画像可能是动态单 Agent、代码执行接口、持久 Run 状态、沙箱内受限自主、主分支合并需审批。评价重点是测试通过、变更范围、回归风险和可恢复性。若只输出代码建议而不修改仓库，应将执行能力标为“未实现”，不能混同于具备文件操作能力的 Agent。
13.2 浏览器操作 Agent
类型画像可能是反应式、视觉/DOM 观察、部分可观察环境、带外部副作用的动作、关键提交前审批。技术重点是每次动作后重新观察、元素定位、页面状态核验和重复提交防护。用户点击确认之前填写好订单，与自动完成付款，是两种风险和授权条件完全不同的类型配置。
13.3 业务审批 Agent
适合混合控制：模型解析自然语言和非结构化附件，确定性程序执行金额阈值、角色权限和审批流转。即使模型能够解释“为什么建议通过”，最终授权仍应由权威业务规则决定。其类型不应只叫“客服/办公 Agent”，还必须标注高约束、事件触发、审计型执行等属性。
十四、工程实现：可运行的类型画像验证器
以下示例仅使用 Python 3 标准库。它实现了三件事：对类型画像做结构与一致性校验；根据任务契约生成候选控制架构；输出需要进一步测试的能力断言。它不会调用模型，也不会替代真实架构评审。代码与正文分开提供，便于直接运行和测试。
14.1 关键数据结构
TaskContract 包含 dynamic_observations、long_horizon、write_effects、stable_steps 等任务特征；AgentProfile 包含控制架构、执行模式、持久状态和写入审批策略；validate_profile 返回设计冲突。通过将“能力声称”变成结构化字段，才能建立自动检查与人工审查之间的接口。
14.2 判定算法
候选选择遵循明确规则：稳定流程优先固定工作流；存在动态观察则优先动态控制；长程任务且具有明确依赖时考虑计划-执行；长时执行需要持久状态；有写入副作用时必须明确授权策略。规则是教学用启发式，不是经过统计学习或大规模基准验证的最优选择器。
14.3 完整代码
from dataclasses import dataclass
from typing import Literal
Controller = Literal["workflow", "reactive", "plan_execute"]
@dataclass(frozen=True)
class TaskContract:
stable_steps: bool
dynamic_observations: bool
long_horizon: bool
write_effects: bool
high_risk_write: bool
@dataclass(frozen=True)
class AgentProfile:
controller: Controller
async_run: bool
persistent_run_state: bool
write_policy: Literal["none", "approved", "auto"]
def recommend(task: TaskContract) -> AgentProfile:
if task.long_horizon and task.dynamic_observations:
controller: Controller = "plan_execute"
elif task.dynamic_observations:
controller = "reactive"
else:
controller = "workflow"
return AgentProfile(
controller=controller,
async_run=task.long_horizon,
persistent_run_state=task.long_horizon,
write_policy="approved" if task.write_effects else "none",
)
def validate_profile(task: TaskContract, profile: AgentProfile) -> list[str]:
issues = []
if task.long_horizon and not profile.persistent_run_state:
issues.append("Long-running task lacks durable run state")
if task.high_risk_write and profile.write_policy != "approved":
issues.append("High-risk write lacks approval policy")
if task.write_effects and profile.write_policy == "none":
issues.append("Write-capable task has no write policy")
if not task.write_effects and profile.write_policy == "auto":
issues.append("Automatic writes declared for read-only task")
return issues
def test_research_case():
task = TaskContract(
stable_steps=False,
dynamic_observations=True,
long_horizon=True,
write_effects=True,
high_risk_write=True,
)
profile = recommend(task)
assert profile.controller == "plan_execute"
assert profile.async_run and profile.persistent_run_state
assert profile.write_policy == "approved"
assert validate_profile(task, profile) == []
unsafe = AgentProfile("reactive", True, False, "auto")
issues = validate_profile(task, unsafe)
assert len(issues) == 2, issues
def test_simple_case():
task = TaskContract(True, False, False, False, False)
profile = recommend(task)
assert profile.controller == "workflow"
assert profile.write_policy == "none"
assert validate_profile(task, profile) == []
if __name__ == "__main__":
test_research_case()
test_simple_case()
print("profile tests passed")14.4 代码能够证明什么，不能证明什么
若上述断言通过，只能证明分类规则在给定样例下输出一致，且能识别两类明显的配置冲突。它不能证明计划-执行型一定优于反应式、长期任务一定必须异步，也不能证明实际系统已经实现了审批、持久化或工具执行。要验证真实能力，需要结合运行时日志、状态存储、权限拒绝测试与端到端任务结果。
十五、类型分类的评估方法：从标签准确性到架构效果
15.1 两种评估任务必须分开
分类准确性评估：给定 Agent 的配置和运行轨迹，类型画像是否真实反映其机制？需要人工标注样本、判定标准和分歧复核。架构有效性评估：在同一任务集上，不同控制架构能否以合理成本达到质量、延迟与安全要求？需要对照实验。一个标签即使分类准确，也不代表该类型适合所有任务。
15.2 建议指标
| 指标 | 适用场景 | 注意事项 |
|---|---|---|
| 任务成功率 | 所有任务型 Agent | 成功需外部验收，不依赖模型自报 |
| 工具调用正确率 | 工具型 | 区分调用意图、参数、真实结果 |
| 计划完成与重规划质量 | 计划型 | 计划步骤数多不等于质量高 |
| 无效循环率 | 反应式 | 定义重复状态/动作的检测窗口 |
| 中断恢复成功率 | 异步长任务 | 必须实际重启执行进程 |
| 越权阻断率 | 高自主/高风险 | 必须测试拒绝路径 |
| 副作用重复率 | 外部写入 | 需要业务级操作记录 |
| 成本、延迟、人工介入 | 所有架构 | 在相同质量门槛下比较 |
| 跨任务收益 | 学习/记忆增强 | 防止测试泄漏和任务差异 |
15.3 消融实验
以同一研究任务为例，分别关闭显式计划、关闭长期记忆、将动态工具选择改为固定流程、将后台执行改为同步执行。保持任务集、工具权限、模型预算和验收标准尽量一致，比较质量与成本。若关闭某项能力后结果不变，应重新审视该能力是否必要；若结果变差，需要排除其他配置差异的影响。
15.4 失败注入
至少测试工具超时、来源不可用、重复事件、审批拒绝、运行中断、权限撤销、预算耗尽与不可信工具输出。分类画像应预测需要哪些防护：事件驱动型关注重复投递，长任务型关注恢复，浏览器操作型关注状态变化，高风险写入型关注幂等与审批。
十六、常见误分类与纠正
| 常见说法 | 问题 | 更精确的表达 |
|---|---|---|
| “研究 Agent 属于计划型” | 任务域不能推出控制机制 | 研究型；控制机制另行验证 |
| “能调用工具就是高自主 Agent” | 工具能力不等于授权范围 | 工具增强；明确自主权与审批 |
| “用了多个模型就是多 Agent” | 多模型调用不等于多主体协作 | 模型路由或流水线；检查独立职责 |
| “有聊天历史就是长期记忆” | 会话上下文不等于跨 Run 持久记忆 | 会话状态型 |
| “写了思考步骤就是规划型” | 文本步骤不等于执行计划 | 需验证计划对象和执行依赖 |
| “可以重试就是可恢复 Agent” | 重试不等于状态重建 | 需验证检查点与副作用 |
| “能生成代码就是编程执行 Agent” | 生成不等于执行 | 代码生成型或可执行型，分别说明 |
| “Agent 越自主越先进” | 忽略成本与风险 | 依据任务契约选择控制权 |
| “反思就是模型在线学习” | 反馈、记忆与权重更新混淆 | 说明更新对象及跨任务证据 |
十七、与后续专题的关系
本篇的任务是建立类型分析方法，而不是在这里完整实现所有架构。Agent Design 将研究如何从任务契约选择具体方案；Agent Lifecycle 将研究运行、暂停、恢复与终止；Internal Architecture 中的 Model、Context、Memory、Knowledge、Tools、Skills、Planning & Reasoning 和 Permissions & Constraints 将分别解释这些能力如何实现。多 Agent 的通信与协调、平台级部署与运营则在 Agent System 和 Agent Platform 中深入研究。
在知识地图中，Agent Types 最重要的作用是建立设计语言：当说“异步、计划-执行、受限自主、具有外部写入的研究 Agent”时，开发者应能立即推导出需要计划状态、检查点、工具契约、审批门禁、幂等处理和对应测试，而不只得到一个产品名称。
十八、核心结论
Agent 类型应采用多维画像而非互斥清单。经典反射式、内部模型式、目标式、效用式和学习式 Agent 提供理解行动机制的理论坐标；现代 LLM Agent 则需要进一步区分模型决策、程序控制、计划结构、执行时间、环境接口、持久状态、自主权与副作用。任务领域决定研究什么问题，控制架构决定如何选行动，运行模式决定如何调度和恢复，权限策略决定哪些动作真正能够执行。类型标签只有在能被配置、运行轨迹与测试证实时，才具有工程意义。
最终的选型原则是：先建立任务契约与固定工作流基线，再按不确定性、反馈需求、长时状态和行动风险增加必要的 Agent 机制；在满足质量与安全约束的前提下，选择最低充分复杂度的方案。
参考资料与延伸阅读
- Stuart Russell & Peter Norvig, Artificial Intelligence: A Modern Approach, 4th ed., Pearson, 2021。经典智能体结构、目标与效用框架。
- Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023。https://arxiv.org/abs/2210.03629 。推理-行动-观察交替的代表性研究。
- Noah Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS 2023。https://arxiv.org/abs/2303.11366 。语言反馈与跨试次经验的研究案例；不应与基础模型在线权重更新混淆。
- Shunyu Yao et al., Tree of Thoughts: Deliberate Problem Solving with Large Language Models, NeurIPS 2023。https://arxiv.org/abs/2305.10601 。候选推理路径搜索的代表性研究。
- Qingyun Wu et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, 2023。https://arxiv.org/abs/2308.08155 。多 Agent 对话式协作的代表性研究。
- Anthropic, Building Effective Agents, 2024。https://www.anthropic.com/engineering/building-effective-agents 。工作流与 Agent、路由、并行、编排的工程视角。
- OpenAI, A Practical Guide to Building Agents, 2025。https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf 。Agent 组件、工具与护栏的工程视角。
- LangGraph 官方文档，https://docs.langchain.com/oss/python/langgraph/overview 。状态图、持久化与执行控制的框架参考。
- Temporal 官方文档，https://docs.temporal.io/ 。持久化工作流、事件历史与执行恢复的通用工程参考。
研究声明
资料来源与论证边界： 本文以经典智能体理论、代表性 LLM Agent 研究和通用工程架构原则为基础，对现代 Agent 类型进行技术归纳。九轴类型画像、类型数据契约和架构推导规则属于本文提出的工程分析模型，不是行业统一标准。论文、框架及官方工程文章主要用于说明不同技术路线，不能由此推断某个具体产品已具备全部相关能力。
资料核验状态： 本次修订未逐项在线核验所有论文、官方文档与框架在 2026 年 10 月的最新实现细节；涉及具体版本、API、产品能力的实施判断，应在实际开发时核对原始资料和源代码。参考文献不构成本文所有工程建议均已被实验验证的证明。
实验与代码状态： 文中 Python 示例为离线、确定性的类型画像判定与冲突检测，旨在说明可操作分类方法。它不包含真实 LLM、外部工具、权限服务或持久化运行时，不验证实际 Agent 的任务表现。若随附运行记录，应以本地执行结果为准；真实架构优劣仍需端到端对照实验。