7.1 智能体（Agent）简述

基于大语言模型的上层应用，已经从基于提示词、无状态、无计划和无记忆的阶段，进入到了更加复杂的阶段，这个阶段需要结合工程实践来赋能大语言模型，虽然大模型在推理阶段只是面向上下文，但是我们可以通过外挂的方式，通过一些传统的工程实现来使得整个AI应用和服务变成有状态、有计划和有记忆的存在。到这里我们就会触及AI Agent这个LLM上层应用形态，也是目前以及未来都会很流行的东西

那么什么是AI Agent呢？很多人有不同的认知，我认为AI Agent就是给大模型工具和环境，这样大模型可以在思考后决定采用什么动作，这其中就有通过工具使用来感知环境，这样可以得到外部的信息，比如命令行执行的结果，请求API的结果，网页搜索的结果，甚至是物理世界的视觉反馈或传感器的结果。基于这些信息，AI Agent可以结合自身在训练阶段得到的通识能力去做决策、执行和判断。这种也是目前以ReAct为基础的一种AI Agent的通用范式

另外，Agent相比于RAG和提示词技术这些来说是更加复杂的系统，需要在稳定且连续的情况之下，让大模型通过计划、执行和观察等手段实现多轮次的循环，直到最终解决问题。这其中不是简单的写下提示词，对接外部工具和大模型就行，更多的还是在于从系统层面进行调度的能力，推理和执行链路，以及状态和记忆的管理，包括一些边界情况的管控和收敛。因此我们会认为AI Agent的能力体现可以用以下的等式来表示：

AI Agent=80%的工程能力+20%的AI

因为底座是基于大语言模型（LLMs），也有一些提示词相关的技术，其他的更多还是涉及传统行业的工程技术，不管是缓存，还是上下文存储、置换等技术，因此到Agent这里，可以认为是需要有工程化能力的同时还具备AI思维

在脱离研究层面往应用层面走的过程中，我们会越来越容易感受到这个现象，我们需要从最基础的提示词设计开始，到记忆、知识库、工具的管理，再到整个Workflow的编排，甚至进一步到多Agent的编排和协作，除了这些以外，我们还需要涉及到一些可观测的铺设，数据采集回补调优，还需要弹性部署（可以是云原生那一套）和监控（也是云原生那一套），甚至还需要沙盒环境，长短周期任务执行引擎等

可能看到这里有些人会觉得没有这么复杂，其实这恰巧反映了现在的情况。现在我们其实可以花几天就可以做出一个AI Agent，但是这是一个Toy Agent，大白话就是一个玩具，0-1的一个MVP，我们随便用一个AI Agent的框架就可以轻松Build出来，网上也有大把的教程，但是现实和理想之间的Gap是非常大的，一旦我们进入到追求有业务价值、有商业价值的AI Agent层面，不是一个人一个AI几天就能做出来的，通常需要花费团队很多时间精力和资源去优化，我相信这个也是2025年剩下的日子里和2026年最大的研究课题和应用方向了

下面我们来看一张Letta去年整理的一张图：

虽然数据已经是一年前的了，但是我们也可以看出，现在AI Agent已经如雨后春笋不断涌现了，2025年更是被称为Agent之年。Agent也是目前业界统一共识的方向，因为Agent未来是可以继续演进的，甚至可以一直持续到AGI时代。接下去我们一起来看看AI Agent的相关设计范式

7.2 智能体设计范式

7.2.1 ReAct

在基础提示技术章节中我们也有提到ReAct，实际上ReAct的思想在Agent领域得到了最大的发挥，其思想也在很大程度上影响了后面出现的一些框架。ReAct也已经在生产环境得到了验证，是一个Agent Loop的通解

回归AI Agent的根本，其实就是Loop+Tokens，我们拆解来看看：

Loop：其实也就是循环，类比人类解决一个问题，就是不断去尝试，直到解决，这就是一个循环，只不过循环长短不同，人的一生也可以看作是一个大几十年上百年的Loop。
Tokens：这算是一个比较Tech的说法了，就是Loop中，就是不断的去让大模型思考决策，行动，和收集反馈信息继续下次的计划和执行。这个其实也是ReAct的核心思想了

所以实际上我们要实现一个AI Agent，最简单的就是以ReAct为基础，去构建一个不断循环的推理（Reason），行动（Act）和观察（Observe）

7.2.2 Self-Reflection

Self-Reflection是Noah Shinn等人在2025年5月提出的（后发布在当年的NeurIPS）。可以理解是带了复盘系统的Agent，架构如下：

相比于ReAct来说，Self-Reflection在Action之后通过记忆来沉淀出一些策略，持续的纠错和优化改进。通过这样的手段来提升整体的效果

7.2.3 CodeAct

CodeAct是以Xingyao Wang为首的几个人在2024年2月提出来的，在那之后的2024年3月OpenHands（原OpenDevin）诞生了，Xingyao也把这个应用到了OpenHands中

CodeAct的核心思想很简单，就是让大模型输出并执行可执行代码，实现高效、精准的工具调用，以进一步完成复杂任务的手段。说到这里聪明的你应该也想到这个怎么和工具调用或函数调用（Tool/Function Calling）有点类似？实际上CodeAct和函数调用都是为了让大模型调用外部工具而设计的机制，只不过有一些差别：

函数调用通常定义对应的调用格式，比如JSON，难以实现复杂操作
CodeAct可以通过LLM生成完整的可执行的Python代码，支持较为复杂的操作

我们看个对比的例子，大模型吐出的函数调用为：

{
  "function": "get_weather",
  "parameters": { "location": "Shanghai", "date": "2025-08-16" }
}

而同样情况下，CodeAct为：

get_weather("Shanghai", "2025-08-16")

并且其实CodeAct可以完成更加复杂的操作，比如：

weather = get_weather("Shanghai", "2025-08-16")
send_email(to="user@example.com", content=weather)

这样可以连续串联多个操作，也就是CodeAct的核心，输出完整的可操作代码，外部服务负责具体的执行逻辑。另外具备了一些流程控制的能力，比如条件、循环等，可以进一步降低任务复杂度。最后是复用已有基础设施，比如CodeAct最初提出就是针对Python常见，这种情况下是可以复用Python里的标准库或三方库，无需重复定义新的工具

CodeAct正是因为其特性，现在也被众多AI Coding Assistant采用，很多跟Coding有关的Agent都会集成CodeAct或者以CodeAct思想为基础的变体

7.2.4 Workflow

我觉得工作流Workflow也可以列在Agent设计范式里，以Coze、Dify、n8n等为主的工作流编排是一个很重要的应用分支。我们也可以看到很多人在讨论Agent or Workflow？这个就需要我们先分辨一下这两者的差别了

引用n8n官方repo里的这张图：

典型的Workflow就是通过一个一个节点组成的流，这些节点有不同的类型和用途，有条件分支节点，有调用大模型的节点等等。Workflow通常是一个比较固定的流程，大模型没有太大的自主决策权，通常是以DAG（Directed Acyclic Graph，有向无环图）存在的

Anthropic的这篇文章划分了Workflow的好几种形态：

通过Prompt chaining（提示链）连接：

Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one. You can add programmatic checks (see “gate” in the diagram below) on any intermediate steps to ensure that the process is still on track.

Prompt Chaining就是前一个输出给到下一个输入，串联了多个节点，这多个节点可能同时都请求了大模型，但是可能拥有不同的Prompt。

Routing（路由）通过路由将问题路由到不同的节点处理，可以应对不同场景的需求

Parallelization（并行化）是通过并行执行，最后在进行结果聚合，适合一些可拆分成可并行执行的任务，多个子任务单元一起执行，可以获得很快的速度。

Orchestrator-workers（编排工作者）是前面的并行化的提升，通过大模型对任务的拆解后分配对应的worker执行，有一定的弹性空间，但是依然还是在预定义的Worker里选择

Evaluator-optimizer（评估-优化循环）一个节点生成结果一个节点做评估，不断循环直到结束

正如前面Anthropic文章里提到的

When to use this workflow: This workflow is ideal for situations where the task can be easily and cleanly decomposed into fixed subtasks. The main goal is to trade off latency for higher accuracy, by making each LLM call an easier task.

Workflow适合任务是可以被清除的解构成固定的子任务单元。Workflow相对于Agent有个天然的优势就是高效率，且效果非常稳定，执行基本都能在预期范围内，不可预知或者说未知性很低。缺点自然就是不够灵活了，面对一些开放的或者无法预定义的任务就无法处理了。有一句话特别好：Workflow和Agent的差别在于控制权，Workflow是程序控制模型，而Agent是模型控制程序。

现在大家的一个共识是基于Routing去做路由，可以路由到Workflow，也可以路由到Agent，这样可以让已知的场景可以稳定高效的执行，未知的场景可以Agent兜底自主决策。

简单用一个表格来对比Workflow和Agent：

7.2.5 Multi-Agent

当面对复杂任务的时候，通常会将任务拆解成多个子任务来处理，这样有助于追踪完成情况，也有助于Agent可以专注于某个子任务的执行。这个也是Planning+Action的思路，但是在实际应用中会发现，任务复杂度不断提高的情况下，Agent的上下文里会充满了各种工具调用的信息，哪怕前一个任务执行完后，执行那个任务的相关信息依然滞留在上下文里，导致上下文不断膨胀，最终可能影响后续任务的执行和最终结果的输出。

基于这样的背景之下，结合我们之前学习的上下文隔离手段，现在行业里普遍的做法是使用多智能体（Multi-Agent）的架构来组织多智能体，这样可以将不同的子任务交给对应的Agent来执行，达到上下文隔离和每个Agent独立迭代优化的目的。

从理论角度看有不少多智能体的组织方式（甚至类似网络拓扑的感觉），比如ddd这张图就展示了7种：

但是在实践过程中最流行的是Supervisor（或LeadAgent、Orchestrator）+SubAgent的组织方式（对应图里的Hierarchical），其实就是主Agent+子Agent的方式。

7.2.6 小结

到这里已经了解了一些流行的范式，其实从更高维度来划分是可以划分为：

Single Agent（单智能体）：以ReAct为主，Self-Reflection和CodeAct还有其他的变种都可算作这个分类
Workflow（工作流）：以DAG去编排节点，LangGraph、Dify、Coze等在一定程度上都可以看作是工作流的一种
Multi-Agent（多智能体）：不管是Swarm还是Supervisor，本质上都是将上下文隔离拆分进不同的Agent实例的一种多Agent组织和写作方式
Hybrid（混合模式）：可能混合以上的内容，最常见的就是通过Workflow形式来编排Agent，典型例子就是通过LangGraph编排，本质上是工作流，但是内部的节点有可能是Agent在执行。还有一种是通过意图判断和路由层来将已知的场景路由到工作流，未知的场景用Agent来兜底

汇总成一个直观的表格：

7.3 总结

相信前面的内容让我们对于Agent有了一个全局的认知了，接下去基本上是HandsOn去尝试，从Toy、Demo和MVP出发，最终打造出Production-Ready的Agent，在这期间有几个关键点有助于在选型和迭代过程中去辅助决策：

权衡好延迟、费用和性能，这能进一步决定是采用workflow、agent还是混合两者
平衡好控制和授权的关系，可以更好地选择合适的agent系统设计范式
用最简单有效的手段达到既定目标

但是知易行难，这也是行业快速发展背后最强的阻力，基本表现为就是效果不好，成本高企等等。这也是我们必须要正视的问题，也是上下文工程存在的必要。引用一段这篇文章里的内容：

可以看到，在Build一个Agent的过程中，会陆续遇到很多问题，心路历程也是一变再变。因此本质上还是没有银弹，一切应该回归业务和用户导向，Agent是手段而不是目的。

至此，我们对于上下文工程的一些正在流行的技术有了全面的认知了，但是更多还是概念性或者理论性的，要做好这个工程并不容易，正如Anthropic这篇文章里的一句话：

Implementing this practice is much easier said than done

我相信这也是现在为什么上下文工程是一个非共识的实践学科。因为好坏、合适之类的标准都是比较难以量化的。我坚信能不断推动效果提升的主要集中在这么几点上：

有夯实的认知：对于现有的可行技术有个全面的认知，可以随意取用
能积极跟进前沿技术的发展：不管是个人还是企业，都可以在这块赢得时间差的优势
迭代，快速迭代：只有这样才可以不断推陈出新，包括不断试错和探索
保持不断重构现有产品和架构的能力和意识：技术发展伴随着不断重建
闭环能力：部署只是开始，需要不断收集数据进行调优和改进

接下去，Let’s Rock!

大模型上下文工程实践指南-第7章：智能体