BemoDB 2.0

Back

Lilian Weng 的 LLM Powered Autonomous Agents 和 Anthropic 的 Building Effective Agents 是理解 Agent 概念时最常被引用的两篇文章。前者偏向解释 Agent 的内部结构,后者偏向讨论 Agent 的工程落地方式。放在一起读,基本可以形成一个比较完整的认识框架。

Agent 并不是脱离大模型独立存在的新范式。更准确地说,它是一个由大模型驱动,并与工具、记忆和环境交互的任务系统。

在最简单的聊天场景里,大模型通常只完成单次输入到输出的响应过程;而在复杂任务里,系统需要理解目标、拆分步骤、调用外部资源,并根据中间结果继续推进任务。Agent 的概念正是在这种从“单次回答”走向“持续执行”的过程中形成的。

Agent 可以理解为:由大模型驱动、借助工具和记忆持续完成任务的系统。

Agent 为什么不是“普通聊天模型”#

Lilian Weng 的文章并不把重点放在“模型更聪明了”这一层描述上,而是直接拆解 Agent 系统的能力结构。她给出的核心框架可以概括为三层:PlanningMemoryTool Use。如果顺着这个框架往下读,整篇文章其实会清晰很多。

Planning#

Planning 说的并不只是“分步骤”,而是系统如何围绕目标持续推进任务,而不是对输入做一次性响应。

这一部分包含两个关键点。第一是 task decomposition,即任务拆解。复杂任务往往无法一步完成,需要先被拆成多个更小、更容易执行的子任务。第二是 self-reflection,即反思和修正。系统在完成某一步之后,需要根据中间结果重新检查已有判断,并决定是否调整后续路线。

因此,Planning 的重点不在于“看起来像在思考”,而在于系统具备了面向目标持续推进任务的能力。普通聊天模型更接近于回答当前问题,而 Agent 更接近于推进一个任务。

Memory#

第二层是 Memory。这一部分讨论的也不只是上下文窗口长度,而是系统如何保存、组织和召回任务所需的信息。

Weng 区分了短期记忆和长期记忆。可以先把短期记忆理解为当前上下文窗口中的内容,也就是模型在当前时刻能够直接访问的信息;长期记忆则更接近外部存储,通常依赖检索系统、数据库或向量存储实现。核心问题不是“是否存在记忆”,而是系统如何保存过去的信息,并在合适的时刻重新取回。

因此,所谓“具有记忆的 Agent”并不是模型天然具备了类似人类的长期记忆,而是系统通过保存、检索和上下文注入等机制实现了记忆能力。记忆在很多场景中首先是工程能力,其次才是模型能力。

Tool Use#

第三层是 Tool Use。这一部分几乎构成了 Agent 与普通聊天模型之间最明显的一条分界线。

一个只能生成文本的模型,能力主要停留在分析和表达层面;而一个可以搜索网页、读写文件、执行代码、调用 API、操作浏览器的系统,则开始具备行动能力。Weng 在这里强调的是,工具不是附属增强,而是模型突破参数边界的关键方式。许多当前信息、私有信息、实时信息和执行能力,并不包含在模型权重内部,只能通过工具接入。

从这个意义上说,工具的引入使模型从“生成内容”转向“执行动作”。没有工具,很多系统仍然只是更复杂的文本生成器,而不是能够真正完成任务的 Agent。

如果将 Weng 的论述进一步压缩,可以概括为:Agent 的成立依赖于以下三类能力同时存在:

  • 会围绕目标做规划,而不是只做一次回答
  • 会借助记忆保存和召回上下文,而不是只盯着当前窗口
  • 会通过工具接入外部世界,而不是只在模型参数里打转

Anthropic 眼里的“有效 Agent”#

如果说 Lilian Weng 的文章主要回答“Agent 由什么构成”,那么 Anthropic 的文章更关注“应当如何使用 Agent”。

Anthropic 最核心的提醒是:并不是所有任务都需要直接采用 Agent。许多问题并不需要系统在执行过程中持续规划、反复调用工具并动态修正路线。在很多情况下,一个带有检索、工具或记忆能力的增强型 LLM 就足以解决问题。Anthropic 将其视为 agentic system 的基础积木,而不是必须一步上升到完全自主代理。

这意味着,系统设计并不以复杂性为目标,而是以有效性为目标。Anthropic 的态度很明确:先使用最简单、最低成本、最可控的结构解决问题,只有在简单方案不足时,才增加更高程度的自主性。

Anthropic 提到的几种模式#

Anthropic 文章中提到的几种常见模式可以概括如下:

  • prompt chaining:适合能拆成固定顺序步骤的任务,本质上还是预先设计好的流程
  • routing:适合输入类型差异大、但每类处理方式稳定的任务,本质上是先分流再处理
  • parallelization:适合能拆开并行的任务,要么追求速度,要么追求更高置信度
  • orchestrator-workers:适合编码、研究这类步骤数不固定的复杂任务,已经很接近真正的 Agent
  • evaluator-optimizer:适合需要反复修改打磨、评价标准又比较明确的任务

这些模式都具有一定的 agentic 特征,但它们与真正 Agent 的差别,关键在于系统的自主性水平。

Prompt Chaining#

这一模式将任务拆成固定顺序的多个步骤,使前一步的输出成为后一步的输入。它适合那些能够被清晰拆开的任务,例如先生成提纲、检查提纲,再据此扩写正文,或先生成文案,再转换为另一种语言形式。可以把它理解成一种“按既定顺序执行”的结构。

它与 Agent 的关系在于:系统虽然不再是单次调用,但整体路径仍由人预先规定,因此更接近 workflow,而非自主 Agent。

Routing#

routing 的核心不是多步执行,而是分流。系统先判断当前输入属于哪一类,再将其发送到最合适的 prompt、模型或工具后面。例如,客服问题可以先区分为普通咨询、退款申请和技术支持,再分别进入不同链路;又如将简单问题交给低成本模型,复杂问题交给能力更强的模型。它更像是在不同预设路线之间做选择。

它适合类别差异较大、但每一类内部处理方式相对稳定的任务。它具备一定的决策性,但这种决策通常只是选择预设路线,而不是在执行过程中持续自主规划。

Parallelization#

parallelization 讨论的是并行执行。Anthropic 将其分为两种形式:一种是将任务拆成多个相互独立的部分并同时完成,以提高速度;另一种是对同一个问题进行多次调用,再通过投票或汇总提高置信度。前者更偏效率,后者更偏稳健性。

它适合原本就可以拆开处理的任务,例如多维度评估、安全规则筛查或多轮代码审查。它与 Agent 的差别在于,尽管执行结构更复杂,但每个分支的职责仍然是预先定义好的。

Orchestrator-Workers#

orchestrator-workers 进一步提高了系统的动态性。与 parallelization 中预定义的并行分支不同,这一模式由主管模型根据具体任务临时决定如何拆解子任务,再将其分配给不同 worker 执行,最后统一收束结果。

Anthropic 认为这一模式尤其适合编码和复杂搜索,因为这些任务在开始时往往无法确定最终需要修改多少文件、检索多少轮资料或执行多少步操作。它已经非常接近真正的 Agent,因为系统开始根据输入动态拆解任务,只是整体上仍保留了清晰的编排框架。

Evaluator-Optimizer#

evaluator-optimizer 则体现了另一种复杂性。它不是将任务拆给多个执行者,而是由一个模型先生成结果,再由另一个模型进行评审,并通过多轮循环不断改进输出。

这一模式适合评价标准相对明确、且多轮打磨确有收益的任务,例如翻译、复杂写作或需要反复检索和修订的分析任务。它与 Agent 的关系在于,系统已经形成反馈循环,但反馈循环中的角色分工仍然是预先设定的。

它们和真正的 Agent 到底差在哪#

Anthropic 在最后才单独讨论真正意义上的 agents。在其定义中,workflow 与 agent 的差别在于:workflow 由预定义代码路径编排 LLM 和工具,而 agent 则由 LLM 在执行过程中动态决定步骤和工具使用方式。

换言之,前述模式虽然都具有一定的 agentic 特征,但大多仍处于“由人定义骨架,模型在骨架中运行”的阶段;真正的 Agent 则进一步将“下一步如何执行”的决定权交给模型。

理解 Agent 的一个更有效方式,不是判断“它是不是 Agent”,而是判断“它具有多高的自主性”。可以将其理解为一条连续光谱:

  • 单次调用的模型
  • 带工具或检索的增强型 LLM
  • 预定义路径的 workflow
  • 带动态拆解能力的 agentic workflow
  • 能边执行边自主决定下一步的真正 Agent

这种理解方式有助于避免将概念神秘化。

为什么最后还是工程问题#

两篇文章共同指向的另一个结论是:Agent 的上限固然与模型能力相关,但其下限更多取决于工程实现。即使模型能力很强,如果工具定义不清、返回结果不稳定、权限边界混乱、记忆内容噪声过高,整个 Agent 的表现仍然会很差。相反,即使模型能力没有极端领先,只要工具接口清晰、上下文组织合理、反馈链路明确,系统也可以在许多场景中表现得相当可靠。决定 Agent 可用性的,往往不只是模型本身,而是它所接入的整个系统。

这也解释了 Anthropic 为什么强调 effective 这个词。关键并不在于构建一个表面上复杂、能够连续运行多步的 Agent,而在于构建一个真正能够完成任务、成本可控、过程可追踪、失败可兜底的系统。站在工程角度看,Agent 的价值不在于形式上的复杂性,而在于它能否用更灵活的方式完成复杂任务。

最后一句话#

可以将这两篇文章的分工概括为:Lilian Weng 解释了 Agent 的结构,Anthropic 解释了 Agent 的使用方式。前者说明 Agent 为什么表现出“自主行动”的特征,后者说明真正重要的并不是这种表面特征,而是系统能否稳定完成任务。

回到最初的问题,Agent 可以被理解为一种由大模型驱动的任务系统。它具备规划能力,可以调用工具,可以利用记忆,并能够根据环境反馈调整后续动作。它既不是单纯的聊天系统,也不是静态的工作流,而是介于“生成模型”和“执行系统”之间的一种结构。

agentGo*002 | Agent 的概念理解
https://astro-pure.js.org/blog/2026/agentgo/002
Author Bolaxious
Published at May 15, 2026