Loop 已死，Graph 新生：AI 工作流的范式革命

"如果你还在用 while 循环写 Agent，那你已经落后了一个时代。"

近年，AI 工程领域发生了一场静悄悄的革命。曾经统治 Agent 开发的 Loop（循环）模式，正在被 Graph（图）模式全面取代。LangGraph、Dify Workflow、Coze、n8n------几乎所有主流框架都转向了图编排。这不是时尚潮流，而是工程实践用血泪换来的教训。本文深入剖析这场范式转移的来龙去脉。

📑 目录

开篇：一个真实的崩溃故事
[Loop 是怎么统治 Agent 开发的](#Loop 是怎么统治 Agent 开发的)
[Loop 的五个致命缺陷](#Loop 的五个致命缺陷)
[Graph 模式的核心思想](#Graph 模式的核心思想)
[DAG vs 循环图：两种 Graph 范式](#DAG vs 循环图：两种 Graph 范式)
[主流 Graph 框架详解](#主流 Graph 框架详解)
[LangGraph 深度解析](#LangGraph 深度解析)
[Dify Workflow：低代码图编排](#Dify Workflow：低代码图编排)
[从单 Agent 到 Multi-Agent Graph](#从单 Agent 到 Multi-Agent Graph)
[生产级 Graph Agent 架构](#生产级 Graph Agent 架构)
[Graph 模式的挑战与局限](#Graph 模式的挑战与局限)
[未来：Graph 之后是什么？](#未来：Graph 之后是什么？)
参考文献

1. 开篇：一个真实的崩溃故事

2023年某天凌晨3点，一个创业公司的运维群突然炸了------他们的 AutoGPT 服务已经连续运行了47个小时，烧掉了2000多美元的 API 费用，却没有产出任何有意义的结果。

原因？AutoGPT 的核心是一个 ReAct 循环：

python 复制代码

while not is_done:
    thought = llm("根据当前状态，下一步该做什么？")
    action = llm("执行什么动作？")
    result = execute(action)
    if should_stop(result):
        break

问题是：谁来判断 should_stop？ 在这个案例中，Agent 陷入了一个"自我改进"的死循环------它不断生成代码、运行测试、发现bug、修复bug、引入新bug、再修复......永远不满足，永远不停止。

这不是个例。在 2023 年的 AI Agent 浪潮中，无数开发者遇到了同样的问题：Loop 模式天然缺乏"刹车"机制。

这就是为什么 2024 年，整个行业开始从 Loop 转向 Graph。

2. Loop 是怎么统治 Agent 开发的

图1：AI 工作流架构演进 ------ 从 Chain 到 Graph 的五年

2.1 Chain 时代（2022）

2022年，LangChain 横空出世 $1$ 。它的核心抽象是 Chain------把多个 LLM 调用串联起来，前一个的输出作为后一个的输入。

python 复制代码

chain = prompt | llm | output_parser
result = chain.invoke({"input": "..."})

Chain 简单直观，但有一个致命问题：它是纯线性的。你不能在中间加条件分支，不能并行执行，不能循环。就像一条单行道------你只能从头走到尾。

2.2 Agent Loop 时代（2023）

2023年3月，一篇名为"ReAct: Synergizing Reasoning and Acting in Language Models"的论文改变了游戏规则 $2$ 。ReAct 提出了一个简洁的 Agent 范式：

复制代码

Thought: 我需要查找XXX的信息
Action: search("XXX")
Observation: 找到了以下信息...
Thought: 我已经得到了答案
Action: answer("...")

这个"思考-行动-观察"的循环，成为了 2023 年 Agent 开发的标准范式。LangChain 的 AgentExecutor、AutoGPT、BabyAGI、GPT-Engineer------几乎所有 Agent 框架都基于这个循环。

python 复制代码

# LangChain AgentExecutor 的核心逻辑
while should_continue:
    output = agent.plan(intermediate_steps)
    if output.is_final:
        return output
    observation = tool.run(output.tool_input)
    intermediate_steps.append((output, observation))

2.3 问题爆发（2023下半年）

随着越来越多的人把 Agent 部署到生产环境，问题开始集中爆发：

死循环：Agent 不知道什么时候该停，无限循环烧钱
不可控：你不知道 Agent 下一步会做什么
不可调试：出了问题，你不知道是哪一步出的错
不可测试：Agent 的行为是非确定性的，没法写单元测试

社区开始反思：我们真的需要一个"自由奔跑"的 Agent 吗？

2.4 Graph 时代（2024-至今）

2024年1月，LangChain 团队发布了 LangGraph $3$ ------第一个将 Agent 工作流建模为有向图 的框架。核心思想是：把 Agent 的每一步操作看作图中的一个节点（Node），节点之间的执行顺序和条件用边（Edge）来定义。

这不是一个全新的概念------工作流引擎（如 Airflow、n8n）在传统 IT 领域已经用了多年。但 LangGraph 的创新在于：它把 LLM 的非确定性能力和工作流的确定性控制结合了起来。

3. Loop 的五个致命缺陷

图2：Loop 的五个致命缺陷 ------ 每一个都可能让你的 Agent 在生产环境中翻车

3.1 致命一：死循环（Infinite Loop）

这是 Loop 最臭名昭著的问题。Agent 陷入循环，不断重复相同或类似的动作，却永远达不到终止条件。

根本原因： LLM 是概率模型------它没有"记忆"自己做了什么的能力（除非你把历史全部塞进上下文）。当上下文窗口满了，或者 LLM 的推理出现"抖动"时，它就可能回到之前的状态，开始重复。

真实案例： AutoGPT 的 GitHub issue 中，"Agent stuck in loop"是最常见的问题之一。有用户报告 Agent 连续执行了数千次相同的搜索操作，直到把 API 额度用完。

Graph 的解决方案： 在 Graph 中，每个节点有明确的输入输出，循环是通过条件边来实现的------你可以设置最大循环次数、超时时间、收敛检测等"刹车"机制。

3.2 致命二：无法并行（No Parallelism）

Loop 天然是串行的------一步做完才能做下一步。但很多时候，多个任务之间是互相独立的，完全可以并行执行。

例子： 用户问"帮我比较 A 公司和 B 公司的财务状况"。在 Loop 中，Agent 可能先搜索 A 公司，再搜索 B 公司，串行执行。但实际上，这两个搜索完全可以同时进行。

Graph 的解决方案： 在 Graph 中，没有依赖关系的节点可以并行执行。LangGraph 支持 fan-out（分叉）和 fan-in（合并），让独立任务自动并行化。

3.3 致命三：分支困难（Branching Hell）

真实业务逻辑充满了条件分支------如果用户是 VIP 就走 A 流程，否则走 B 流程；如果检索结果质量高就直接用，否则重新检索。

在 Loop 中实现分支，需要在循环体内写大量的 if-else。随着分支逻辑的复杂化，代码会变成"意大利面"------难以理解、难以维护、难以测试。

Graph 的解决方案： Graph 的条件边（Conditional Edge）天然支持分支。你可以在边上定义一个条件函数，根据当前状态决定走向哪个节点。分支逻辑清晰可见，不会嵌套在循环体内部。

3.4 致命四：状态不透明（Opaque State）

在 Loop 中，中间状态存在内存里。Agent 执行到第 5 步出错了------第 1-4 步的状态是什么？你不知道。你只能看日志，但日志可能不够详细。

Graph 的解决方案： Graph 框架通常支持 Checkpoint （存档）和 Time Travel（回放）。每个节点执行后，状态都可以被序列化保存。出了问题，你可以回滚到任意一个检查点，查看当时的状态，甚至从那里重新执行。

3.5 致命五：不可组合（Not Composable）

你有两个 Agent------一个负责研究，一个负责写作。你想让它们协作：研究 Agent 的输出作为写作 Agent 的输入。

在 Loop 中，这意味着你要写一个新的循环，在循环体内调用两个 Agent。如果以后还要加一个审核 Agent，你又得改循环逻辑。

Graph 的解决方案： 两个 Graph 可以轻松组合------把一个 Graph 的输出节点连接到另一个 Graph 的输入节点。模块化、可复用、可测试。

4. Graph 模式的核心思想

图3：Graph 的三个核心概念 ------ Node、Edge、State

4.1 Node（节点）

Node 是 Graph 中的执行单元。每个 Node 做一件事------调用 LLM、执行工具、处理数据、做判断......Node 的核心原则是：纯函数------相同的输入永远产生相同的输出（至少在同一 State 下）。

python 复制代码

def retrieve_node(state: AgentState) -> dict:
    """检索节点：根据用户问题检索相关文档"""
    docs = vector_store.similarity_search(state["question"])
    return {"documents": docs}

4.2 Edge（边）

Edge 定义了节点之间的执行顺序。有两种类型：

普通边（Normal Edge）： A → B，A 执行完后一定执行 B。无条件的顺序执行。

条件边（Conditional Edge）： 根据当前状态决定下一步执行哪个节点。

python 复制代码

def should_retrieve(state: AgentState) -> str:
    """判断是否需要检索"""
    if state.get("need_retrieval"):
        return "retrieve"
    return "generate"

4.3 State（状态）

State 是贯穿整个 Graph 的数据载体。每个节点都可以读取 State 中的数据，也可以向 State 中写入数据。State 通常用 TypedDict 或 Pydantic 模型来定义，确保类型安全。

python 复制代码

class AgentState(TypedDict):
    question: str
    documents: list
    answer: str
    need_retrieval: bool
    iteration: int

State 是 Graph 的"血液"------它在节点之间流动，携带信息，记录进度。

4.4 Graph 的执行模型

Graph 的执行遵循一个简单的规则：

从入口节点开始
执行当前节点，更新 State
根据边的定义，确定下一个节点
如果是条件边，调用条件函数判断
重复 2-4，直到到达出口节点

这个过程是确定性的（给定相同的 State，边的判断结果是确定的），只有节点内部的 LLM 调用是非确定性的。这种"确定性控制 + 非确定性智能"的组合，是 Graph 模式的核心优势。

5. DAG vs 循环图：两种 Graph 范式

图4：DAG vs 循环图 ------ 两种范式各有适用场景

5.1 DAG（有向无环图）

DAG 是没有循环的图------任务有明确的先后顺序，不会回头。这是传统工作流引擎（如 Apache Airflow、n8n）的标准范式。

适用场景：

数据处理管线（ETL）
确定性工作流（先做A，再做B和C，最后合并做D）
CI/CD 流水线
批量处理任务

优点： 简单、可预测、容易调试、容易并行化。

缺点： 无法实现"重试"和"迭代优化"逻辑。

5.2 循环图（有向有环图）

循环图允许在图中定义循环------但这种循环是受控的，有明确的终止条件和最大迭代次数。

适用场景：

ReAct Agent（思考→行动→观察→思考...）
迭代优化（生成→评估→改进→再评估...）
人工审核循环（生成→人工审批→继续/修改）
自我反思（Self-Reflection）

优点： 灵活，能处理需要多次迭代的任务。

缺点： 需要小心设计终止条件，否则和 Loop 一样会死循环。

5.3 LangGraph 的做法

LangGraph 同时支持 DAG 和循环图 $3$ 。你可以在图中定义循环，但 LangGraph 提供了多种"刹车"机制：

最大迭代次数 ：recursion_limit 参数
超时：节点级别的超时设置
收敛检测：检查 State 是否变化，如果不再变化就终止
人工介入：在循环中插入人工审核节点

这种设计的哲学是：给你自由，但也给你约束。 就像成年人的生活------你可以做任何事，但要为后果负责。

6. 主流 Graph 框架详解

图5：主流 Graph 框架对比 ------ 各有千秋

6.1 LangGraph

LangGraph 是 LangChain 团队在 2024 年 1 月发布的框架 $3$ ，是目前最灵活、最强大的 Graph Agent 框架。

核心特性：

状态图（StateGraph）：用 TypedDict 定义状态，节点是 Python 函数
条件边：支持复杂的条件分支逻辑
Checkpoint：每个步骤的状态都可以保存和恢复
Time Travel：可以回滚到任意检查点，修改状态后重新执行
人工介入（Human-in-the-loop）：在任意节点插入人工审核
流式输出：支持节点级别的流式输出
子图（Subgraph）：图可以嵌套图，实现模块化

适用场景： 需要高度定制化的复杂 Agent 系统。适合有 Python 开发能力的团队。

缺点： 学习曲线陡峭，API 设计有些抽象，调试需要对 State 有深入理解。

6.2 Dify Workflow

Dify 是一个开源的 LLM 应用开发平台 $4$ ，它的 Workflow 功能用可视化拖拽的方式搭建 AI 工作流。

核心特性：

可视化画布：拖拽节点、连线，所见即所得
丰富的节点类型：LLM、知识检索、代码执行、条件判断、HTTP 请求等
支持条件分支、并行、循环
支持变量传递和模板
开源，可私有化部署

适用场景： 需要快速搭建 AI 工作流的团队，尤其是非工程师或小团队。

缺点： 灵活性不如 LangGraph，复杂的自定义逻辑需要写代码节点。

6.3 Coze（扣子）

Coze 是字节跳动推出的低代码 AI Bot 搭建平台 $5$ 。

核心特性：

零代码搭建 AI Bot
内置插件市场（搜索、天气、数据库等）
支持工作流编排
与飞书、抖音、微信等平台深度集成
免费使用（有额度限制）

适用场景： 快速原型、个人项目、不需要私有化部署的场景。

缺点： 数据在字节的云上，不适合对数据隐私要求高的企业。

6.4 n8n

n8n 是一个开源的通用工作流自动化引擎 $6$ ，近年来增加了大量 AI 相关的节点。

核心特性：

400+ 集成节点（Slack、Gmail、数据库、API 等）
AI 节点（LLM 调用、向量检索、Agent 等）
可视化工作流编辑器
支持代码自定义节点
自托管或云托管

适用场景： 需要将 AI 与传统 IT 系统集成的企业。比如"收到邮件→AI分类→存入数据库→发送通知"。

6.5 AutoGen

AutoGen 是微软在 2023 年发布的多 Agent 对话框架 $7$ 。

核心特性：

多 Agent 对话：多个 Agent 之间可以互相聊天
群聊模式：多个 Agent 在同一个"群"里讨论
代码执行：Agent 可以写代码并执行
人工介入：支持人工参与对话

适用场景： 研究场景、需要多 Agent 协作的复杂推理任务。

6.6 CrewAI

CrewAI $8$ 是一个角色扮演的多 Agent 框架，让多个 Agent 像一个"团队"一样协作。

核心特性：

角色定义：每个 Agent 有自己的角色（如"研究员"、"写手"、"审核员"）
任务委派：一个 Agent 可以把任务委派给另一个 Agent
顺序/并行执行：支持任务的顺序和并行执行
简单直观的 API

适用场景： 内容生产、研究分析等需要多角色协作的场景。

7. LangGraph 深度解析

作为目前最主流的 Graph 框架，值得单独深入讲解。

7.1 核心 API

python 复制代码

from langgraph.graph import StateGraph, END

# 1. 定义 State
class AgentState(TypedDict):
    question: str
    documents: list
    answer: str

# 2. 创建 Graph
graph = StateGraph(AgentState)

# 3. 添加节点
graph.add_node("retrieve", retrieve_node)
graph.add_node("generate", generate_node)

# 4. 添加边
graph.set_entry_point("retrieve")
graph.add_edge("retrieve", "generate")
graph.add_conditional_edges(
    "generate",
    should_continue,  # 条件函数
    {"yes": "retrieve", "no": END}
)

# 5. 编译
app = graph.compile()

# 6. 执行
result = app.invoke({"question": "什么是RAG？"})

7.2 Checkpoint 与 Time Travel

LangGraph 的 Checkpoint 机制是它的杀手级特性之一。

python 复制代码

from langgraph.checkpoint.memory import MemorySaver

# 创建带 Checkpoint 的 Graph
checkpointer = MemorySaver()
app = graph.compile(checkpointer=checkpointer)

# 执行（自动保存每个步骤的状态）
config = {"configurable": {"thread_id": "user-123"}}
result = app.invoke({"question": "..."}, config)

# 回放：获取某个步骤的状态
state = app.get_state(config)

# 修改状态后重新执行
app.update_state(config, {"answer": "修改后的答案"})

这个特性在以下场景中非常有用：

调试：Agent 执行到第 5 步出错了，你不需要从头执行，只需要回滚到第 4 步的状态
人工审核：Agent 生成了答案，人工审核不通过，修改后从该步骤重新执行
多轮对话：用户中途修改了需求，从中间步骤重新执行

7.3 Human-in-the-Loop

LangGraph 支持在任意节点插入人工审核：

python 复制代码

graph.add_node("human_review", human_review_node)

# 在 human_review 节点前暂停，等待人工输入
graph.add_edge("generate", "human_review")

当 Graph 执行到 human_review 节点时，会自动暂停，等待人工输入。人工审核通过后，Graph 继续执行。这在企业级应用中非常重要------AI 生成的内容在发布前需要人工确认。

8. Dify Workflow：低代码图编排

Dify 的 Workflow 是面向非工程师的图编排工具。

8.1 节点类型

Dify 提供了丰富的可视化节点：

节点类型	功能	说明
开始节点	定义输入变量	工作流入口
LLM 节点	调用大语言模型	支持多种模型
知识检索	从知识库检索	RAG 功能
代码执行	运行 Python/JS	自定义逻辑
条件分支	if-else 判断	支持多分支
变量赋值	操作变量	数据转换
HTTP 请求	调用外部 API	工具集成
迭代	循环处理列表	批量操作
参数提取	从文本提取参数	结构化输出
结束节点	定义输出	工作流出口

表1：Dify Workflow 节点类型

8.2 Dify vs LangGraph

维度	LangGraph	Dify Workflow
编程方式	代码	可视化拖拽
灵活性	极高	中等
学习曲线	陡峭	平缓
适用人群	工程师	任何人
Checkpoint	支持	部分支持
自定义逻辑	完全自由	需要代码节点
生态	LangChain 生态	Dify 生态
部署	自托管	自托管/云

表2：LangGraph vs Dify Workflow

选型建议： 如果团队有 Python 工程师且需要高度定制化，选 LangGraph；如果需要快速搭建且团队技术栈多样，选 Dify。

9. 从单 Agent 到 Multi-Agent Graph

9.1 为什么需要 Multi-Agent？

单个 Agent 的能力是有限的。就像一个人不可能同时是程序员、设计师、产品经理和测试工程师一样，一个 Agent 也很难同时擅长所有任务。

Multi-Agent 的思路是：让多个专业化的 Agent 协作完成复杂任务。每个 Agent 有自己的角色、工具和知识，通过 Graph 来编排它们之间的协作流程。

9.2 Multi-Agent 协作模式

模式	说明	适用场景	代表框架
主从模式	主 Agent 分配任务给子 Agent	任务分解	LangGraph
对等讨论	多个 Agent 平等讨论	多角度分析	AutoGen
流水线	Agent 按顺序处理	内容生产线	CrewAI
辩论模式	两个 Agent 辩论	推理、决策	ChatEval
审核模式	执行 Agent + 审核 Agent	质量保证	LangGraph

表3：Multi-Agent 协作模式

9.3 Multi-Agent Graph 示例

一个典型的"研究→写作→审核"流水线：

复制代码

[用户输入] → [研究Agent] → [写作Agent] → [审核Agent] → [输出]
                   ↓                              ↓
              [搜索工具]                    [通过/打回]
                                            ↓
                                    [写作Agent]（修改后重新审核）

在 LangGraph 中，这个流程可以这样实现：

python 复制代码

graph = StateGraph(TeamState)

graph.add_node("researcher", research_agent)
graph.add_node("writer", write_agent)
graph.add_node("reviewer", review_agent)

graph.set_entry_point("researcher")
graph.add_edge("researcher", "writer")
graph.add_conditional_edges(
    "reviewer",
    lambda state: "pass" if state["approved"] else "revise",
    {"pass": END, "revise": "writer"}
)
graph.add_edge("writer", "reviewer")

10. 生产级 Graph Agent 架构

图6：生产级 Graph Agent 六层架构

10.1 六层架构

层次	组件	职责	关键技术
用户接入层	API / Web / IM	接收用户输入	API Gateway
编排层	Graph Engine	执行图逻辑	LangGraph / Dify
Agent 层	多个专业 Agent	执行具体任务	角色 + 工具 + 提示词
工具层	外部工具	执行具体操作	RAG / API / 代码
模型层	LLM	推理和生成	GPT / Claude / DeepSeek
基础设施层	存储/监控/权限	系统支撑	向量DB / 日志 / 鉴权

表4：生产级 Graph Agent 六层架构

10.2 生产环境的关键考量

可观测性（Observability）。 每个节点的输入、输出、耗时、Token 消耗都要记录。LangSmith、LangFuse 等工具提供了专门的 Agent 可观测性支持。

错误处理。 节点执行可能失败（API 超时、工具异常等）。需要在 Graph 中定义错误处理路径------重试、降级、人工介入。

成本控制。 Agent 的每一步都可能调用 LLM，成本会快速累积。需要设置预算上限、Token 限制、最大迭代次数。

延迟优化。 并行执行独立节点可以显著降低延迟。流式输出让用户更快看到中间结果。

安全与权限。 Agent 可以执行代码、调用 API，这些操作需要权限控制。需要在工具层实现细粒度的权限管理。

11. Graph 模式的挑战与局限

Graph 不是银弹。它解决了 Loop 的问题，但也带来了新的挑战：

11.1 设计复杂度

把一个模糊的业务需求翻译成一个精确的 Graph 结构，需要深入理解业务逻辑。对于复杂的业务流程，Graph 的设计可能比写循环代码更费脑子。

11.2 过度工程化

对于简单的任务（比如"检索→生成"），用 Graph 可能是杀鸡用牛刀。一个简单的 Chain 或函数调用就够了。Graph 的价值在于复杂流程------如果你的流程只有两三步且没有分支，不需要 Graph。

11.3 调试困难

虽然 Graph 比 Loop 更容易调试，但当图的规模变大（几十个节点、多层嵌套）时，调试仍然不容易。你需要可视化工具来理解图的结构和执行路径。

11.4 状态管理

State 是 Graph 的核心，但 State 的设计需要仔细考虑------太大会浪费内存和 Token，太小会导致节点之间信息传递不足。

11.5 LLM 的不确定性

Graph 提供了确定性的控制流，但节点内部的 LLM 调用仍然是非确定性的。同一个问题，LLM 可能给出不同的回答，导致 Graph 走不同的分支。这种不确定性在某些场景下是不可接受的。

12. 未来：Graph 之后是什么？

12.1 自适应 Graph

目前的 Graph 是人工设计的------你需要手动定义节点、边和条件。未来的趋势是让 LLM 自己设计和修改 Graph 结构------根据任务的特点，自动选择合适的节点组合和执行路径。

12.2 Graph + 强化学习

用强化学习来优化 Graph 的执行策略------哪些节点应该并行、哪些应该串行、条件边的阈值应该是多少。让 Graph 在执行过程中自我优化。

12.3 标准化

目前各框架的 Graph 定义方式各不相同------LangGraph 有自己的 API，Dify 有自己的 JSON 格式，n8n 有自己的工作流定义。未来可能会出现一个标准的 Graph 描述语言（类似 BPMN 在传统工作流中的地位）。

12.4 Graph OS

把 Graph 编排、状态管理、可观测性、权限控制、成本管理等能力整合到一个统一的平台中------类似于 Kubernetes 之于容器编排。这可能是 2026-2027 年的趋势。

13. 参考文献

$1$ Chase, H. (2022). "LangChain: Building applications with LLMs through composability". GitHub. https://github.com/langchain-ai/langchain.

$2$ Yao, S., et al. (2023). "ReAct: Synergizing Reasoning and Acting in Language Models". Proceedings of ICLR. arXiv: 2210.03629.

$3$ LangChain. (2024). "LangGraph: Build stateful, multi-actor applications with LLMs". https://github.com/langchain-ai/langgraph.

$4$ Dify.AI. (2024). "Dify: Open-source LLM app development platform". https://github.com/langgenius/dify.

$5$ ByteDance. (2024). "Coze: Next-gen AI Bot Building Platform". https://www.coze.com.

$6$ n8n GmbH. (2024). "n8n: Workflow automation tool". https://github.com/n8n-io/n8n.

$7$ Wu, Q., et al. (2023). "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation". arXiv preprint, arXiv:2308.08155.

$8$ CrewAI. (2024). "CrewAI: Framework for orchestrating role-playing autonomous AI agents". https://github.com/crewAIInc/crewAI.

$9$ Anthropic. (2024). "Building effective agents". https://www.anthropic.com/research/building-effective-agents.

$10$ Schick, T., et al. (2023). "Toolformer: Language Models Can Teach Themselves to Use Tools". Advances in Neural Information Processing Systems. arXiv: 2302.04761.

$11$ Xi, Z., et al. (2023). "The Rise and Potential of Large Language Model Based Agents: A Survey". arXiv preprint, arXiv:2309.07864.

$12$ Wang, L., et al. (2024). "A Survey on Large Language Model based Autonomous Agents". Frontiers of Computer Science. arXiv: 2308.11432.