LangGraph 进阶：如何设计循环图与条件边实现真正的“自主代理”？

AI大模型应用之禅

177人浏览 · 2026-06-12 21:07:43

AI大模型应用之禅 · 2026-06-12 21:07:43 发布

LangGraph 进阶：如何设计循环图与条件边实现真正的“自主代理”？| 从ReAct到自我修正Agent全链路落地指南

关键词

LangGraph、自主代理、循环图、条件边、ReAct框架、自我修正Agent、大模型应用开发

摘要

当前90%以上的大模型Agent都属于“伪自主”：遇到代码报错就直接抛给用户、查资料不全就输出残缺结果、逻辑推导出错也不会自我校验，本质是开发者仍在用线性链式思维设计Agent流程，没有构建起“感知-决策-行动-反思”的闭环反馈机制。本文从核心概念解析入手，用生活化类比拆解LangGraph循环图与条件边的本质，结合数学模型、算法流程图、可运行的Python代码示例，一步步教你设计可控、可扩展、生产级的自主代理。全文包含完整的自我修正代码Agent项目落地全流程，涵盖架构设计、接口实现、最佳实践、避坑指南，以及自主Agent技术的未来发展趋势，适合有LangChain基础、希望打造真正自主智能体的开发者和架构师阅读。

一、背景介绍

1.1 问题背景：你做的Agent为什么是“伪自主”？

我见过很多开发者晒自己做的Agent：能搜资料、能写代码、能回答问题，但一到真实场景就掉链子：

让它写一个FastAPI登录接口，生成的代码少了JWT依赖，运行报错直接把错误信息返回给你，不会自己修正；
让它查2024年AI顶会的录用率，搜索了一次没找到准确数据，就直接说“找不到相关信息”，不会换关键词、换数据源继续查；
让它做一道需要多步推导的数学题，中间算错了一个系数，最后输出错误结果，不会自己复盘检查每一步的推导逻辑。
这些Agent的本质是“线性流程木偶”：所有步骤都是预定义的固定链路，没有反馈循环，没有自主决策分支，遇到异常就直接终止，完全谈不上“自主”。
2024年LangGraph的出现彻底打破了这个困局：它用图结构替代了传统的线性Chain，允许开发者自定义循环逻辑和条件分支，让Agent具备了动态调整流程、自我修正错误的能力，真正具备了“自主”的基础。

1.2 目标读者

本文面向的是：

有LangChain基础，做过简单Agent，但无法落地复杂场景的开发者；
希望打造生产级自主代理的大模型应用架构师；
对Agent工作流编排有兴趣的AI技术爱好者。
你不需要有很深的图论基础，只要会写Python代码，理解大模型调用的基本逻辑就能看懂全文。

1.3 核心问题与挑战

要实现真正的自主代理，我们需要解决三个核心问题：

闭环构建：怎么设计“思考-行动-反思-修正”的循环，让Agent遇到错误能自动回头修正，而不是直接终止；
动态决策：怎么设计灵活的条件分支，让Agent能根据当前状态自主选择下一步走哪个流程，而不是走预定义的固定链路；
风险可控：怎么避免Agent陷入死循环烧光你的OpenAI账单，怎么保证流程可监控、可调试、可干预。
本文接下来的内容就围绕这三个问题展开，一步步给出可落地的解决方案。

二、核心概念解析

2.1 核心概念生活化类比

我们用“招聘实习生”的类比来解释所有核心概念，你会发现自主代理的逻辑和一个优秀的实习生工作逻辑完全一致：

技术概念	生活化类比	核心作用
自主代理（Agent）	优秀的实习生	不需要你全程盯着，能自主完成你交代的复杂任务
状态（State）	实习生的工作笔记本	记录任务目标、历史工作步骤、中间结果、错误信息、剩余时间等所有关键信息
节点（Node）	实习生要做的具体工作：查资料、写代码、检查错误、提交结果	执行具体的逻辑，更新状态
普通边（Edge）	做完A事接下来必然做B事：写完代码接下来要跑测试	连接两个节点，定义固定的流程走向
条件边（Conditional Edge）	做完测试之后如果过了就提交，没过就回去改代码	根据当前状态的判断结果，动态选择下一个节点
循环图（Cyclic Graph）	改完代码再测试，测试没过再改，直到过了或者到了截止时间	支持流程的反复执行，形成反馈闭环
终止条件	任务完成/到了截止时间/尝试次数太多放弃	避免无限循环，控制成本和风险

什么是真正的“自主代理”？

我们给出一个可量化的定义：具备以下四个能力的智能体才能被称为自主代理：

环境感知：能获取当前任务的所有上下文信息，包括历史操作、外部工具返回结果、错误信息；
自主决策：能根据当前状态自主判断下一步要做什么，不需要人工干预；
行动执行：能调用工具、生成内容、完成具体的任务动作；
反思修正：能判断当前结果是否符合要求，不符合就找到问题所在，回头修正。
而这四个能力的底层支撑，就是LangGraph的循环图+条件边。

2.2 概念核心属性对比

我们把传统线性Agent和基于LangGraph的自主代理做一个全面对比，你就能直观感受到差异：

对比维度	线性Chain（伪Agent）	循环图+条件边（真自主Agent）
流程结构	固定线性，只能从前往后走，不可跳转	动态分支，支持循环、跳转、多分支选择
错误处理	遇到错误直接终止，返回错误信息给用户	自动识别错误类型，跳转到对应节点修正，直到成功或达到终止条件
决策能力	无自主决策，所有流程预定义，只能处理固定场景	自主决策下一步行动，根据环境反馈动态调整路径，可处理开放场景
适用场景	简单单轮任务：单轮问答、文本摘要、简单分类	复杂多轮任务：代码开发、科研调研、故障排查、内容创作
资源消耗	固定，和预定义步骤数成正比	动态，根据任务复杂度调整，最差情况不超过最大步数限制
可控性	极高，所有路径完全已知	中高，路径动态但可通过终止条件、监控、人工干预完全控制
落地成本	极低，简单拼接Chain即可	中高，需要设计状态、节点、条件边、终止条件、监控体系

2.3 概念结构与交互关系

2.3.1 核心实体ER关系图

我们用Mermaid ER图展示LangGraph实现自主代理的核心实体及其关系：

2.3.2 自主代理运行交互流程图

自主代理的完整运行逻辑如下，所有的动态决策和循环都基于状态和条件边实现：

2.4 边界与外延

适用场景

循环图+条件边的自主代理特别适合以下场景：

高容错需求场景：代码开发、文案创作等允许多次尝试、需要修正的场景；
不确定路径场景：科研调研、故障排查等不知道需要多少步、不知道需要调用哪些工具的开放场景；
高质量要求场景：法律文书撰写、学术论文写作等需要多次校验、确保结果准确的场景。

不适用场景

不要为了用LangGraph而用LangGraph，以下场景用普通线性Chain更合适：

简单单轮场景：单轮问答、文本分类、摘要等一次调用就能完成的任务；
低延迟需求场景：实时客服、实时推荐等要求毫秒级返回的场景，循环会增加延迟；
固定流程场景：发票识别、数据清洗等流程完全固定、不需要动态决策的场景。

认知误区

很多人误以为LangGraph本身能提升Agent的智能水平，这是错误的：LangGraph只是一个流程编排框架，Agent的智能上限完全由你调用的大模型决定，LangGraph的作用是把大模型的能力充分释放出来，通过闭环反馈让大模型有机会修正自己的错误，而不是一次输出定终身。

三、技术原理与实现

3.1 数学模型

自主代理的本质是带条件分支的有限状态机（CFSM），我们可以用严格的数学公式定义其运行逻辑：

3.1.1 基础定义

我们定义自主代理由以下五元组组成：
$\langle S, A, T, F, R \rangle$
其中：

$S$ ：状态集合，所有可能的State的集合，每个State包含任务上下文、历史操作、指标等所有信息；
$A$ ：动作集合，所有可执行的节点（思考、调用工具、生成结果、反思等）的集合；
$T$ ：转移函数， $\times A \rightarrow S$ ，输入当前状态和执行的动作，返回新的状态；
$F$ ：终止函数， $\rightarrow \{0, 1\}$ ，返回1表示满足终止条件，流程结束，返回0表示继续运行；
$R$ ：奖励函数， $\rightarrow \mathbb{R}$ ，用于评估当前状态的收益，可用于优化循环效率，提前终止低收益的循环。

3.1.2 条件边的数学表示

条件边本质是转移函数的分支逻辑，我们可以用分段函数表示：
$\begin{cases} a_1 & \text{if } c_1(s) = True \\ a_2 & \text{if } c_2(s) = True \\ ... \\ a_k & \text{otherwise} \end{cases}$
其中 $c_i(s)$ 是第i个条件判断函数，输入当前状态，返回布尔值， $a_i$ 是对应的下一个要执行的动作（节点）。

3.1.3 循环效率优化模型

为了避免无意义的循环浪费资源，我们可以引入价值函数来判断当前循环的收益，当收益低于阈值时提前终止：
$V(s_t) = R(s_t) + \gamma \max_{a \in A} V(T(s_t, a))$
其中 $V(s_t)$ 是当前状态 $s_t$ 的价值， $R(s_t)$ 是当前状态的即时奖励， $\gamma \in [0,1]$ 是折扣因子，代表未来收益的权重。当 $V(s_t)$ 低于预设阈值时，我们可以提前终止循环，避免浪费Token和时间。

3.2 设计原则

3.2.1 循环图设计原则

状态设计原则：最小必要+可追溯
- 只存储必要的信息，避免State过大导致上下文窗口溢出；
- 所有关键操作都要留痕，包括历史思考、工具调用结果、错误信息，方便大模型回溯和开发者调试；
- 优先使用LangGraph提供的Reducer（比如add_messages）来更新State，避免直接修改可变对象导致状态跟踪异常。
终止条件多维度原则
必须设置至少三个维度的终止条件，避免死循环：
- 最大步数：比如最多循环10次，避免大模型抽风无限调用工具；
- 最大Token消耗：比如最多消耗10000 Token，避免账单爆炸；
- 目标达成标志：状态里设置is_success布尔字段，任务完成就终止。
循环粒度适中原则
循环粒度不要太粗也不要太细：
- 太粗：把整个任务做成一个循环，错误定位困难，修正效率低；
- 太细：每写一行代码就循环一次，Token消耗极高，延迟大；
- 最佳实践：把“思考-行动-校验”做成一个最小循环单元，比如“生成代码-运行-检查错误”是一个循环单元。

3.2.2 条件边设计原则

结构化判断原则
条件判断的输入必须是结构化输出，不要用自然语言匹配关键词：
- 用Pydantic定义大模型的输出结构，强制大模型返回布尔型的判断字段、枚举型的下一步选项；
- 配合JSON Schema校验，避免大模型胡编输出导致条件判断失效。
兜底分支原则
所有条件边必须设置兜底分支，当所有判断条件都不满足时走兜底分支，避免流程卡住报错：
- 兜底分支可以是回到思考节点重新决策，也可以是触发人工介入，或者终止流程返回错误。
低成本判断原则
条件判断尽量用低成本的方式实现，不要每次都调用GPT-4：
- 简单的条件判断（比如步数是否超过上限、是否有错误信息）用规则实现，不需要调用大模型；
- 复杂的判断（比如结果是否符合要求）可以用小模型（比如GPT-3.5、Llama3 8B）实现，成本降低90%以上。

3.3 算法流程图

我们以自我修正代码Agent为例，给出完整的算法流程图：

3.4 基础代码实现（可直接运行）

我们先实现一个最简单的循环图示例：数字猜谜Agent，让大模型自主猜1-100之间的数字，根据反馈循环调整，直到猜对或者超过10次。

3.4.1 环境安装

pip install langgraph langchain-openai python-dotenv pydantic

3.4.2 完整代码

from typing import TypedDict, Annotated, Literal
from langgraph.graph import StateGraph, END
from langgraph.graph.message import add_messages
from langchain_openai import ChatOpenAI
from dotenv import load_dotenv
import os

# 加载环境变量，需要在.env文件里配置OPENAI_API_KEY
load_dotenv()
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)

# 1. 定义State
class GuessState(TypedDict):
    messages: Annotated[list, add_messages] # 历史对话记录，用add_messages Reducer追加
    min_num: int # 当前猜测范围的最小值
    max_num: int # 当前猜测范围的最大值
    target_num: int # 要猜的目标数字
    guess_count: int # 已经猜测的次数
    is_correct: bool # 是否猜对

# 2. 定义节点函数
def guess_node(state: GuessState) -> GuessState:
    """猜数字节点，大模型根据当前范围生成猜测"""
    prompt = f"""
    你现在在玩猜数字游戏，数字范围是{state['min_num']}到{state['max_num']}。
    之前已经猜了{state['guess_count']}次，历史猜测记录：{[m.content for m in state['messages'] if m.type == 'ai']}
    请你猜一个数字，只返回数字本身，不要返回其他任何内容。
    """
    response = llm.invoke(prompt)
    guess_num = int(response.content.strip())
    
    # 判断猜测结果，更新范围
    min_num = state['min_num']
    max_num = state['max_num']
    is_correct = False
    if guess_num == state['target_num']:
        is_correct = True
        result = f"恭喜你猜对了！数字是{guess_num}，一共猜了{state['guess_count'] + 1}次。"
    elif guess_num > state['target_num']:
        max_num = guess_num - 1
        result = f"你猜的{guess_num}太大了，当前范围是{min_num}到{max_num}。"
    else:
        min_num = guess_num + 1
        result = f"你猜的{guess_num}太小了，当前范围是{min_num}到{max_num}。"
    
    # 返回更新后的State
    return {
        "messages": [response, ("user", result)],
        "min_num": min_num,
        "max_num": max_num,
        "guess_count": state['guess_count'] + 1,
        "is_correct": is_correct
    }

# 3. 定义条件边判断函数
def after_guess(state: GuessState) -> Literal["guess_node", END]:
    """猜完之后判断是继续猜还是终止"""
    if state['is_correct'] or state['guess_count'] >= 10:
        return END
    return "guess_node"

# 4. 构建并编译Graph
workflow = StateGraph(GuessState)
# 添加节点
workflow.add_node("guess_node", guess_node)
# 设置入口节点
workflow.set_entry_point("guess_node")
# 添加条件边
workflow.add_conditional_edges(
    "guess_node",
    after_guess
)
# 编译Graph
app = workflow.compile()

# 5. 运行测试
if __name__ == "__main__":
    initial_state = {
        "messages": [],
        "min_num": 1,
        "max_num": 100,
        "target_num": 42, # 目标数字是42
        "guess_count": 0,
        "is_correct": False
    }
    # 流式运行，输出每一步的结果
    for event in app.stream(initial_state):
        for value in event.values():
            print(value['messages'][-1].content)

3.4.3 运行结果

你会看到大模型用二分法，最多7次就能猜对数字，完美演示了循环和条件边的运行逻辑：

你猜的50太大了，当前范围是1到49。
你猜的25太小了，当前范围是26到49。
你猜的37太小了，当前范围是38到49。
你猜的43太大了，当前范围是38到42。
你猜的40太小了，当前范围是41到42。
你猜的41太小了，当前范围是42到42。
恭喜你猜对了！数字是42，一共猜了7次。

四、实际应用：自我修正代码Agent项目落地

我们现在实现一个生产级可用的自我修正代码Agent：用户输入代码需求，Agent自动生成代码、在沙箱里运行、报错自动修正、校验功能是否符合需求，最多尝试5次，最终返回可运行的代码和文档。

4.1 项目介绍

这个Agent可以用于：

开发者辅助写代码，自动生成可运行的示例代码；
低代码平台的后端逻辑生成，用户输入需求直接生成可部署的代码；
教育场景，自动生成编程题的参考答案和解析。

4.2 系统架构设计

我们采用三层架构设计，保证可扩展、可监控、可维护：

4.3 系统接口设计

我们用FastAPI提供REST接口，方便其他系统调用：

接口地址	请求方法	参数	返回值	说明
`/api/v1/code-agent/run`	POST	`requirement`：代码需求字符串，`max_fix_count`：最大修正次数（可选，默认5）	`task_id`：任务ID，`status`：任务状态	提交代码生成任务
`/api/v1/code-agent/result/{task_id}`	GET	`task_id`：任务ID	`status`：任务状态，`code`：最终代码，`error_msg`：错误信息，`doc`：代码文档	获取任务结果

4.4 核心实现源代码

4.4.1 依赖导入和基础定义

from typing import TypedDict, Annotated, Literal
from langgraph.graph import StateGraph, END
from langgraph.graph.message import add_messages
from langchain_openai import ChatOpenAI
from pydantic import BaseModel, Field
from dotenv import load_dotenv
from fastapi import FastAPI
import subprocess
import tempfile
import os
import uuid
import json

load_dotenv()
app = FastAPI(title="自我修正代码Agent")
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
# 生产环境用E2B等专业沙箱，这里用临时文件简化演示
# 任务存储，生产环境用Redis或数据库
task_store = {}

# 定义大模型结构化输出
class CodeOutput(BaseModel):
    code: str = Field(description="可运行的Python代码")
    requirements: list[str] = Field(description="需要安装的依赖包列表")
    thought: str = Field(description="生成代码的思考过程")

class CheckOutput(BaseModel):
    is_success: bool = Field(description="代码是否符合要求")
    error_msg: str = Field(description="错误信息，如果符合要求则为空")
    suggestion: str = Field(description="修正建议，如果符合要求则为空")

# 定义State
class CodeState(TypedDict):
    messages: Annotated[list, add_messages]
    requirement: str
    code: str
    requirements: list[str]
    error_msg: str
    fix_count: int
    max_fix_count: int
    is_success: bool
    token_used: int

4.4.2 节点函数实现

def generate_code_node(state: CodeState) -> CodeState:
    """生成代码节点"""
    llm_with_struct = llm.with_structured_output(CodeOutput)
    prompt = f"""
    请根据用户需求生成可运行的Python代码，需求：{state['requirement']}
    之前的错误信息：{state['error_msg'] if state['error_msg'] else '无'}
    之前的修改次数：{state['fix_count']}
    注意：代码要包含测试用例，运行后直接输出结果，不需要用户输入。
    请返回代码、依赖列表和你的思考过程。
    """
    output = llm_with_struct.invoke(prompt)
    # 估算Token消耗，生产环境用实际返回的Token统计
    token_used = state['token_used'] + len(prompt) // 4 + len(output.json()) // 4
    return {
        "code": output.code,
        "requirements": output.requirements,
        "fix_count": state['fix_count'] + 1,
        "token_used": token_used,
        "messages": [("ai", f"生成代码，思考过程：{output.thought}")]
    }

def run_code_node(state: CodeState) -> CodeState:
    """运行代码节点，生产环境用沙箱避免安全风险"""
    # 安装依赖
    for req in state['requirements']:
        subprocess.run(['pip', 'install', req], capture_output=True, text=True, timeout=30)
    # 写代码到临时文件
    with tempfile.NamedTemporaryFile(mode='w', suffix='.py', delete=False, encoding='utf-8') as f:
        f.write(state['code'])
        temp_file = f.name
    # 运行代码
    try:
        result = subprocess.run(
            ['python', temp_file], 
            capture_output=True, 
            text=True, 
            timeout=10
        )
    except subprocess.TimeoutExpired:
        result = type('Result', (), {'returncode': -1, 'stderr': '代码运行超时', 'stdout': ''})()
    # 删除临时文件
    os.unlink(temp_file)
    # 更新状态
    if result.returncode == 0:
        return {
            "is_success": True,
            "error_msg": "",
            "messages": [("ai", f"代码运行成功，输出：{result.stdout}")]
        }
    else:
        return {
            "is_success": False,
            "error_msg": result.stderr,
            "messages": [("ai", f"代码运行失败，错误：{result.stderr}")]
        }

def check_code_node(state: CodeState) -> CodeState:
    """校验代码是否符合需求节点"""
    llm_with_struct = llm.with_structured_output(CheckOutput)
    run_output = state['messages'][-1].content
    prompt = f"""
    请检查以下代码是否完全符合用户需求：{state['requirement']}
    代码：{state['code']}
    运行输出：{run_output}
    请返回是否符合要求，错误信息和修正建议。
    """
    output = llm_with_struct.invoke(prompt)
    token_used = state['token_used'] + len(prompt) // 4 + len(output.json()) // 4
    return {
        "is_success": output.is_success,
        "error_msg": output.error_msg,
        "token_used": token_used,
        "messages": [("ai", f"代码校验结果：{'通过' if output.is_success else '不通过'}，建议：{output.suggestion}")]
    }

4.4.3 条件边实现

def after_run(state: CodeState) -> Literal["check_code_node", "generate_code_node", END]:
    """运行代码之后的条件判断"""
    if not state['is_success']:
        if state['fix_count'] >= state['max_fix_count']:
            return END
        return "generate_code_node"
    return "check_code_node"

def after_check(state: CodeState) -> Literal["generate_code_node", END]:
    """校验代码之后的条件判断"""
    if state['is_success'] or state['fix_count'] >= state['max_fix_count']:
        return END
    return "generate_code_node"

4.4.4 Graph编译和接口实现

# 构建Graph
code_workflow = StateGraph(CodeState)
code_workflow.add_node("generate_code_node", generate_code_node)
code_workflow.add_node("run_code_node", run_code_node)
code_workflow.add_node("check_code_node", check_code_node)
code_workflow.set_entry_point("generate_code_node")
code_workflow.add_edge("generate_code_node", "run_code_node")
code_workflow.add_conditional_edges("run_code_node", after_run)
code_workflow.add_conditional_edges("check_code_node", after_check)
code_app = code_workflow.compile()

# 接口实现
@app.post("/api/v1/code-agent/run")
async def run_agent(requirement: str, max_fix_count: int = 5):
    task_id = str(uuid.uuid4())
    initial_state = {
        "messages": [],
        "requirement": requirement,
        "code": "",
        "requirements": [],
        "error_msg": "",
        "fix_count": 0,
        "max_fix_count": max_fix_count,
        "is_success": False,
        "token_used": 0
    }
    # 异步运行任务，生产环境用Celery等任务队列
    final_state = None
    for event in code_app.stream(initial_state):
        for value in event.values():
            final_state = value
    task_store[task_id] = {
        "status": "success" if final_state['is_success'] else "failed",
        "code": final_state['code'],
        "error_msg": final_state['error_msg'],
        "doc": f"## 代码说明\n需求：{requirement}\n\n## 代码\n```python\n{final_state['code']}\n```\n\n## 依赖\n{','.join(final_state['requirements'])}\n\n## 运行结果\n{final_state['messages'][-1].content}",
        "fix_count": final_state['fix_count'],
        "token_used": final_state['token_used']
    }
    return {"task_id": task_id, "status": task_store[task_id]['status']}

@app.get("/api/v1/code-agent/result/{task_id}")
async def get_result(task_id: str):
    if task_id not in task_store:
        return {"status": "not_found"}
    return task_store[task_id]

4.5 运行测试

你可以启动FastAPI服务，然后调用接口测试：

uvicorn main:app --host 0.0.0.0 --port 8000

调用/api/v1/code-agent/run接口，传入需求：写一个Python函数，输入一个列表，返回列表中所有偶数的平方和，用输入[1,2,3,4,5,6]测试，打印结果，你会得到一个可运行的代码，Agent会自动修正任何语法错误和逻辑错误，最多尝试5次。

4.6 最佳实践Tips

安全第一：代码运行一定要用专业沙箱，比如E2B、Docker容器，不要直接在宿主机运行用户提交的代码，避免被攻击；
结构化输出校验：用Pydantic + LangChain的with_structured_output强制大模型返回结构化数据，避免条件判断失效；
监控告警：每个节点的运行时间、Token消耗、循环次数都要监控，超过阈值立即告警，必要时人工终止任务；
成本优化：代码生成可以用GPT-4，校验和错误分析用GPT-3.5，成本降低70%以上，效果几乎没有差异；
上下文管理：循环次数多了之后State会越来越大，要定期截断历史对话，只保留最近3轮的关键信息，避免上下文窗口溢出；
人工干预入口：生产环境要加人工干预接口，当Agent卡住的时候，人工可以修改State，引导Agent继续运行。

五、行业发展与未来趋势

5.1 自主代理技术发展历史

我们用表格梳理自主代理技术的发展历程：

时间	技术阶段	核心特征	代表产品/技术	局限性
2022年以前	规则驱动Agent	基于有限状态机，预定义所有流程和分支	传统客服机器人、RPA	只能处理固定场景，无法应对开放问题
2022-2023年上半年	大模型线性Agent	基于大模型的链式调用，单轮或固定多轮流程	初代ChatGPT插件、简单LangChain Agent	没有反馈循环，遇到错误直接失败，无法处理复杂任务
2023年下半年	黑盒循环Agent	平台封装循环逻辑，开发者无法自定义流程	AutoGPT、GPTs	循环逻辑不可控，容易死循环，无法定制化，难以落地到生产
2024年至今	可控自主Agent	基于图结构，开发者可自定义循环、条件边、状态管理	LangGraph、自定义工作流引擎	需要开发者掌握图设计能力，成本较高
2025-2026年（预测）	多自主Agent协作	跨Agent的循环和条件边，多智能体分工协作完成复杂目标	泛化AI员工、自主科研系统	对齐成本高，多Agent协同效率有待提升
2027年以后（预测）	通用自主Agent	具备跨领域通用能力，自动设计循环和流程完成任意开放目标	AGI雏形	伦理、安全问题有待解决