agent 的四种类型

当有人告诉我他们建了一个 agent，我会问三个问题：谁决定下一步？工具返回垃圾结果时会发生什么？运行失败后什么能存活下来？

这些答案把我读过或建过的每个 agent 系统归入四种类型。这四种类型不是能力排名，尽管通常被这样读。它们是一张控制权所在的地图，类型之间的每次跃迁都把控制点从开发者移向模型。搞错跃迁，或者跳过跃迁，是大多数 agent 项目死掉的地方。

领域地图

type 1  LLM workflow        developer-fixed flow, model fills content and params
type 2  model-routed flow   model picks tools and branches inside a fixed frame
type 3  closed-loop agent   model iterates on tool results and decides when it is done
type 4  long-horizon agent  goal decomposition, persistent state, verify -> recover -> replan

其他一切都是这四类之上的一层工程纹理。当我评审一个 agent 系统时，第一件事就是把它放到这张图上，因为每种类型都有自己的失败模式，也都有自己的答案：它需要多少 harness。

类型 1：LLM 工作流

流程由开发者绘制。模型填空：摘要、翻译、RAG 模板里的答案槽、草拟邮件的正文。模型从不决定下一步发生什么；步骤之间的箭头在第一个 token 生成之前就已固定。

大多数生产级 AI 功能就在这里，也应该留在这里。RAG 对话、分类 pipeline、抽取链、起草助手。类型 1 运行便宜、测试便宜，而且每次失败都可复现，因为每次运行的路径完全相同。模型可能犯错，但它不会拐错弯，因为它没有方向盘。

局限在于，系统的聪明程度恰好等于预先写好的计划。计划漏掉的每种情况，系统都会漏掉，永远如此。到了某个点，你必须手写的分支就不再划算，走哪条路的决策应该移进模型。

类型 2：模型路由工作流

框架仍然是固定的：工具集合、顺序约束、退出条件。移动的是一项决策，而且由模型来做。一张支持工单被分类，然后路由到专家 prompt。一个自然语言请求被映射到固定 schema 中的一个函数调用。一个危险转向被检测到，然后改路由到有护栏的流程。

Toolformer 是最干净的证明：这种路由决策可以被学出来，而不是手工指定。Toolformer（Schick et al.，2023）训练模型在每个位置决定：是否调用少数几个 API（计算器、搜索引擎、日历、翻译器）中的某一个、传什么参数、如何把结果折回预测。训练是自监督的，每个 API 只需少量演示，结果是模型自己路由到工具，同时仍然是一个普通的 next-token 预测器。从类型 1 的跃迁虽小但真实：分支点现在是模型判断，所以系统可以绕过开发者从未枚举的情况。

类型 2 仍然做不到的是改变航向。框架是固定的，所以当工具结果说明计划是错的时候，除了开发者预先写好的那个，没有 plan B。

类型 3：闭环工具使用 agent

现在循环打开了。模型发出一个动作，工具运行，观察结果回来，模型再次行动。它组合工具：先搜索，再读取，再写入。它决定何时完成——这是一种微妙的能力，因为完成是模型判断，而不是固定退出条件。

具体例子：一个研究助手，搜索、打开来源、再搜索、写一份综述；一个 coding agent，编辑文件、跑测试、读失败、再编辑；一个运维 agent，检查库存、给客户报价、更新 CRM，顺序按情况需要。

类型 3 的经典读法是 ReAct。ReAct（Yao et al.，ICLR 2023）把推理轨迹和动作交错在一起，让模型可以思考、行动、观察、再思考。在问答和事实核查上，与一个简单的 Wikipedia API 交互，克服了思维链推理孤立运行时的幻觉和错误传播问题，因为一个错误断言可以对照世界核查。在 ALFWorld 和 WebShop benchmark 上，ReAct 仅凭一两个 in-context 示例提示，就在成功率上超过模仿学习和强化学习基线 34 和 10 个绝对百分点。

两个性质让这是类型 3 而非类型 2。迭代：观察结果反馈回来，改变下一个动作，而不只是下一个 token。终止：模型自己判断目标已达成并停止。这两者都是类型 3 才有的，也正是风险集中的地方。一个组合工具的循环可能调用错误的工具、永远调用下去、或者在世界不认可时宣布胜利。

类型 3 的盲点是：仅有迭代不等于纠错。当工具结果的错误方式是模型无法从文本中检测出来的，agent 唯一的杠杆就是生成更多文本。ReAct 不修复这一点；它让失败可见，这已经是一个胜利。通往类型 4 的边界由失败之后发生什么来划定。

类型 4：长程通用 agent

目标分解。持久状态。Shell、浏览器、编辑器、API、GUI。还有让其他一切都可存活的循环：验证、恢复、重新规划。

状态与循环同样重要：文件、数据库、技能库和记忆库，它们比任何单个 prompt 活得更久，所以 agent 会在多次运行之间变好，而不是每次从零开始。

Reflexion 是恢复那一半的读书笔记。Reflexion（Shinn et al.，NeurIPS 2023）在不更新权重的情况下强化 agent：一次失败的尝试之后，agent 口头反思反馈，并把反思保存在引导下一次尝试的情景记忆缓冲里。头条数字是 HumanEval 上 pass@1 达 91%，而当时 GPT-4 为 80%。Reflexion 证明的是：恢复可以是一等机制，而不是 prompt 的事后补充。它没有的是视界：记忆只覆盖单次尝试，目标是通过重试完成一个任务。

Voyager 是文献中最干净、最完整的类型 4。Voyager（Wang et al.，2023）是 Minecraft 里的具身终身学习 agent，由三个组件构成：提出下一个探索目标的自动课程、不断增长的可执行代码技能库、以及把环境反馈、执行错误和自验证喂回程序改进的迭代提示循环。模型以黑盒方式被查询，没有参数微调。测得的数字——多 3.3x 的独特物品、长 2.3x 的旅行距离、科技树关键里程碑比此前最优水平快最多 15.3x——不如架构重要：目标被分解，技能跨任务持久存在并可组合，程序只有在 agent 验证之后才进入技能库。这就是把验证、恢复、重新规划做成结构，而不是文本。

AgentBench 是现实检验。AgentBench（Liu et al.，2023）在八个环境中把 LLM 当 agent 评测，发现障碍是糟糕的长期推理、决策和指令遵循，外加顶级 API 模型与开源模型之间的巨大差距。把它读作类型 4 的表述：长程 agent 的失败是视界错误，而不是工具语法错误：模型跟丢线索，再好的工具也只能让这种丢失可见、可恢复。

跃迁是设计决策，不是能力主张

type 1 -> type 2   who picks the branch:       the developer -> the model
type 2 -> type 3   iteration and termination:  the observation steers the next action, and the model decides done
type 3 -> type 4   who remembers and recovers: the prompt -> persistent state and replanning

每次跃迁都把控制从开发者移向模型，也把一项固定保证转换成模型判断。类型 1 保证路径。类型 2 保证框架。类型 3 保证循环。类型 4 除了 harness 强制执行的之外什么都不保证。最后一句话就是我在乎 harness 的全部原因。

这也是为什么这四种类型是分类体系而不是阶梯。类型 4 的通用 agent 并不比类型 1 的工作流更好；它只是受约束更少，而这只有在约束本身是拖累你的东西时才更好。大多数产品在类型 1 或 2 上做得更好，那里的保证很便宜。你选择的类型应该是你能观察、解释并从其失败中恢复的最高一级。

箭头也反向运行，这正是让这套分类体系承重的部分。拿一个类型 3 的循环，给它加上硬性迭代上限，把终止从模型移到对照世界状态的验收检查：你现在有了一个运行在类型 2 保证下的类型 3 agent，因为框架和退出条件又固定了，模型只能在它们内部做选择。类型是 agent 加其 harness 的属性；单独的 agent 没有类型。harness 就是你买回类型放弃的保证的方式。

把练习用在一个你已经知道的系统上。一个深度研究循环——搜索、打开来源、再搜索、写综述——是教科书式的类型 3，这套分类会替你做两个设计决策：观察结果必须真正改变下一个查询，因为如果搜索计划完全预先写好，你有的就是一条多几步的类型 1 链；完成应该由来源覆盖检查决定，而不是由模型对收尾的感觉决定。给这个循环一个硬性迭代上限，把覆盖检查作为它的验收门，你就刻意把它降级到类型 2 的保证——对于一个有延迟预算、另一端有用户等待的研究功能，这是正确的决定。

我会构建什么

如果今天让我从零设计一个 agent 系统，分类体系会在模型选择之前先决定 harness。模型选择很重要，但 harness 决定失败是否可见、可逆、可学习。

第一，事件日志就是 schema。每个动作、观察和决策都记录在一个可回放的流里，因为你无法监督一个你不能回放的循环，也无法在没留存的轨迹上训练。第二，完成是一道门，而不是一句宣判：agent 可以宣称完成，但由对照世界状态的验收检查决定。第三，不可逆动作提案先行：任何无法撤销的事，未经审查的提案就不会触发。第四，候选计划在触碰真实状态之前先在沙箱里运行，工具访问无论如何信任模型都要沙箱化。这四点是设计立场，每一点下面都有一篇深读。

注意每一点如何映射到分类体系上。类型 1 和 2 几乎不需要这些，因为框架仍然归开发者所有。类型 3 是事件日志和完成门变成产品的地方：循环的可信度只取决于你为它保留的记录。类型 4 是其他一切落地的位置——沙箱化工具、不可逆变更前的审查、以及模型跟丢线索后仍能存活的回放状态。harness 也不是一份固定清单。harness 随类型增长，你的测试也应该如此。

我自己的项目在图上的位置

SafeRoutes 是一个技能，在未经修改的 harness 上为类型 3 宿主 agent 强制不变量（github.com/xesws/SafeRoutes）。洞察是：要让闭环 agent 保持诚实，你不需要重写 harness。你交付一个 agent 加载的技能，不变量约束它能提交什么。

PiPlan.ai 的 agent harness 处于类型 3 和 4 之间，带有类型 1 的审查纪律。每个计划都提案先行：agent 写计划，harness 展示会发生什么变化，由一个人让它落地。候选计划在触碰任何真实事物之前先在模拟沙箱里运行。完整事件日志被保留为训练数据轨迹，因为不能回放自己运行的 agent 无法从中学习。对话式规划器–执行器 agent 仍在进行中。

Loop Supervision 是对多 agent 运行的依赖感知监督（github.com/xesws/Loop_ENG_Hackathon）。一旦一次运行跨越数小时、涉及多个 agent，问题就不再是能否完成，而是谁在阻塞谁、谁在世界不认可时宣称完成。

Engram 是一个把信念写入模型权重的个人 agent（github.com/xesws/AIEHackathon）。类型 3 的 agent 通常把记忆放在检索库里；Engram 问的是：什么应该被内化而不是被检索，并通过关闭检索来证明信念存在于权重中。

ClawConclave 是一个 OpenClaw 多 agent 系统，有不同角色（工部、格物、都察）在共享频道中运作（github.com/xesws/ClawMandate）。多个 agent 同处一个屋檐下，类型 4 的监督问题在这里不再只是理论。

延伸阅读

这篇之下的帖子把分类体系暴露出的控制点讲得更深。

Harness：沙箱化笔记、审查门、2026 年的 agent harness 框架。

评测：function calling、多 agent 系统为何失败、长程 agent、以图为依据的验证。

记忆与上下文：agent 记忆、上下文压缩、记忆作为攻击面。

训练、安全、规划：agentic RL、MCP 工具接口、沙箱化 agent、用经典求解器做规划。

这套分类体系是一张地图，不是一把梯子。有意思的工作不是从类型 3 爬到类型 4，而是在构建的每一步都清楚：你现在处于哪种类型、你刚刚移动了哪个控制点、你又为它换掉了哪项保证。

本文中链接的来源均已抓取并验证。