企业官网建设流程全解析

Agent框架这东西，最近这两年真是被问烂了。不管是刚转大模型方向的新人，还是已经在业务里摸爬滚打了一阵子的工程师，最后基本都会卡在同一个问题上：市面上框架这么多，我到底该用哪个？今天这篇就专门聊聊Agent常用开发框架，把主流的、小众但好用的、以及那些被吹上天但落地就翻车的，一锅端讲清楚。

我自己的背景先说清楚，免得误导人。我做大模型应用开发三年多，从最早的LangChain 0.0.x一路用到现在的LangGraph、CrewAI、Semantic Kernel，也自己手写过不依赖框架的Agent调度器。踩过的坑不少，但正因为踩过，下面这些内容才不是PPT级别的框架介绍，而是实打实的选型和落地经验。这篇文章适合正在选型的技术负责人、刚入门的Agent开发工程师，以及那些打算从零搭一套Agent系统但还在纠结框架选择的同学。

1. 主流Agent开发框架全景与选型逻辑

1.1 现阶段绕不开的几个主流框架

先说结论：目前能进入生产环境视野的Agent框架，我按照使用频率和社区活跃度排个序，大概是LangChain/LangGraph、LlamaIndex、CrewAI、AutoGen、MetaGPT、Semantic Kernel、Spring AI、PydanticAI，以及国内团队常用的Dify、Coze这类偏平台化的方案。

LangGraph是目前我在生产环境里用得最多的。它跟LangChain的关系很多人搞混，其实LangGraph不是LangChain的简单升级，而是把LangChain那套链式调用改成了图结构的编排。为什么图结构重要，因为这个年代Agent已经不是简单的一次LLM调用，而是多个节点之间的状态流转，一个节点决策完以后要走哪个分支、要不要循环、要不要终止，用Chain那套线性结构根本表达不了。LangGraph把状态、节点、边这三件事抽象得很清楚，写复杂Agent时心智负担小很多。

CrewAI则是另一种思路，它强调的是角色扮演和协作。你定义几个Agent，每个Agent有自己的role、goal、backstory，然后定义Task和Crew，让Agent们协同完成一个目标。这东西上手极快，小学生也能在两小时内写出一个“市场分析师+文案写手”的组合。但我要泼一盆冷水，CrewAI在简单场景下确实漂亮，一旦你的任务链路变长、分支变多，它的流程控制就会变得捉襟见肘，调试起来也很痛苦。

AutoGen是微软出品，特点是支持多Agent对话式的协作，Agent之间可以像聊天一样你来我往地解决问题。学术气息比较重，实验性质也很强。MetaGPT则更进一步，它试图模拟一家软件公司的组织架构，让产品经理Agent、架构师Agent、工程师Agent各司其职，输入一句话需求直接生成一个完整的代码项目——这个理念我很喜欢，但实际用起来对Token的消耗非常夸张，适合秀肌肉，不适合当生产工具。

Java系和.NET系的技术栈也别慌。微软自家还有个Semantic Kernel，它从设计之初就没打算只服务Python，C#、Java都覆盖得不错。Spring AI在Java生态里的地位这两年也在上升，它吃透了Spring Boot的套路，让Java工程师用写Spring的姿势来写Agent。至于PydanticAI，它是我最偏爱的轻量级方案——它不搞那么多抽象概念，核心就两件事：Pydantic模型做结构化输出，加上一套简洁的Agent执行循环。如果你的Agent逻辑不复杂、但你又希望保留完整的代码控制力，PydanticAI是非常好的选择。

1.2 那堆被过度吹捧的Agent框架套路

选型最怕的不是没得选，而是被框架绑架。

我见过不少团队，上来就想用AutoGen搞一个全自动的多Agent系统，结果被它的对话流程绕得晕头转向，最后连一个简单的客服问答都跑不顺。也见过一个团队用MetaGPT做代码生成，跑一次要烧掉几百块钱Token，生成的代码还得人工改一半。框架不是越复杂越强，而是越贴合你的业务模型越好。

我的建议是，先想清楚你的Agent是单Agent还是多Agent。如果你只需要一个能感知环境、调用工具、自主规划的智能体，LangGraph和PydanticAI足够。如果你非得搞多角色协作，先问问自己业务是不是真的有这个需求——很多场景下，一个设计良好的单Agent加上一套完善的工作流引擎，效果远比三个Agent互相聊天要好。

另外一个容易掉的坑，是框架提供的那套内置工具链。很多框架都自带一堆工具，什么搜索、计算器、数据库查询，看起来开箱即用，实际一用全是坑。内置工具的质量参差不齐，有的工具Prompt写得很差，Agent根本不会正确调用。我的习惯是：框架只用来做编排和状态管理，所有工具全都自己写，这样出了问题你知道该查谁。

1.3 框架选型决策表：直接从场景出发

我直接给你一张决策表，这是我自己在不同项目里验证过的参考方案：

这张表的意思不是告诉你哪个框架天下第一，而是让你顺着自己的业务特征去找对应的工具。选完框架，接下来更重要的事情是搞清楚Agent框架内部的那些关键机制——这个坑我见过太多人踩了。

2. Agent框架的核心模块与设计思路

2.1 Agent执行循环：从ReAct到Plan-and-Execute

任何一个Agent框架，最内核的部分都是那个执行循环。你在教科书上看到最多的可能是ReAct——Reasoning and Acting，模型在每次迭代里先思考再行动，然后观察结果继续思考，直到满足终止条件。

ReAct逻辑上非常优雅，实际用起来却有一个致命问题：它一轮一轮地思考，遇到复杂任务时可能会陷入死循环，代理在一个工具调用结果上反复做推理，Token烧得飞快，任务却毫无进展。后来业界就提出了Plan-and-Execute，让Agent先做一个完整规划，一次性生成多个步骤，然后按计划逐步执行。LangChain里有Plan-and-Execute的Agent类型，LangGraph里你也可以自己实现一套。

我的经验是，真实业务里ReAct和Plan-and-Execute不是二选一，而是分层组合。顶层用Plan-and-Execute做任务拆解，底层对每个子任务再走ReAct式循环。这种设计思路其实就是你后面会看到的很多主流框架默认架构的雏形。有些框架把这一步封装好了，比如LangGraph的create_agent方法带了规划能力，CrewAI的Process写死了一部分，但如果你理解了这个抽象，换任何框架你都能快速上手。

2.2 工具调用与Function Calling机制

Agent框架的第二大核心模块是工具调用。现在几乎所有主流大模型都支持Function Calling（或者叫Tool Calling），模型本身不执行代码，它只输出一个结构化调用意图，把工具名和参数传给你的程序，你的程序执行完再把结果返回给模型。

框架在这里要做的事情其实很重。它要负责把函数签名转成JSON Schema给模型看，要在模型返回调用意图后帮你做参数校验，要在执行出错时决定是重试还是直接报错。LangChain的@tool装饰器就是干这个的，PydanticAI用类型注解干这事，CrewAI则提供了tool装饰器。

我踩过的坑是：很多人把工具的函数签名写得很随意，参数名用a、b这种缩写，也没写清晰的docstring。你可能会觉得模型理解能力强，无所谓，但实际上模型对工具的理解完全依赖于它对函数签名的自然语言感知。参数名模糊、描述缺失，模型就会频繁传错参数。我现在的要求是：每个工具都必须有完整的docstring，每个参数都必须有清晰描述，如果参数是枚举值，尽量用Literal类型标出来。

2.3 Agent状态管理与多轮记忆的落地方式

第三个关键模块是状态。Agent和普通对话机器人的区别就在于它有记忆，而且是分层的记忆。框架通常会把记忆拆成短期工作记忆和长期记忆。短期工作记忆在当前会话里生效，通常就是一个包含上下文消息的列表；长期记忆则需要外挂存储，把历史信息向量化存到向量数据库里，在需要时检索回来。

LangGraph的状态管理做得比较认真，它强制你定义State对象，所有节点间的数据流动都通过这个State走。这意味着你的Agent在什么时候需要保留什么信息，代码里一目了然。相比之下，CrewAI的记忆就相对薄弱，更多是靠上下文窗口硬扛，任务一长上下文就爆。

长期记忆这块我多说两句，因为没有哪个框架是开箱即用的。你用LangGraph也好，CrewAI也好，长期记忆都得你自己接。常见做法是把对话摘要或关键事实写入向量库，每次推理前用相似度检索取回相关片段塞进上下文。这个机制听起来简单，真正的坑在于数据写入的策略——哪些信息值得写入记忆，哪些信息是噪音，如果你什么都存，记忆库很快就变成一个垃圾场。这个我放到后面“记忆设计实录”里详细讲。

2.4 Agent框架与编排（Orchestration）的关系

很多人搞不清框架和编排的边界，特别是看到“Agent框架与编排”这个词的时候容易懵。

我打个比方：框架是给你提供零件和图纸的工厂，编排则是流水线。框架帮你把Agent的建造成本降下来，但多个Agent之间谁先执行、谁后执行、执行条件是什么、下一个Agent的输入从哪里来，这些事情框架不帮你定，需要你自己编排。

LangGraph的Graph、LangChain的RunnableSequence、CrewAI的CrewProcess，本质上都是在做编排。区别在于编排粒度不同。LangGraph可以在节点级别做精细编排，而CrewAI只能在任务级别做一些简单的顺序或并行控制。如果你的系统里只是几个固定顺序的Agent跑跑流程，CrewAI够用；如果你的系统里Agent之间还有条件跳转、并行聚合、重试补偿，我建议你直接用LangGraph这类图编排引擎。

我自己在实际项目里见过一个很典型的翻车案例：某团队用AutoGen做了四个Agent，想让它们像开会议一样协同分析数据，结果Agent之间互相发消息、互相等待，谁也不干活。最后我帮他们把四Agent改成了一个调度器加三个独立Agent，调度器负责编排和结果汇总，Agent本身只做执行。这其实就是编排权重的区别——编排越靠外、越集中越好控制。框架提供编排能力，但真正的编排架构必须由你自己设计，框架能帮你做的是把单一Agent内部的循环跑好。

3. 手把手拆解：搭一个生产级Agent框架

3.1 技术栈选择：Python生态的生产配置

先明确一下技术栈，这决定了你后面所有环节的使用姿势。我目前的主力组合是：Python 3.11 + LangGraph + FastAPI + Pydantic + Qdrant（向量库）+ Redis（短期状态缓存）。这个组合的好处是每一层都有清晰的替代方案，LangGraph不喜欢可以换PydanticAI，Qdrant不喜欢可以换Milvus，Redis则基本是标配。

为什么要Python做主力？不是因为Python多么高贵，而是Agent生态里最好的LLM SDK、工具抽象、数据处理库都在Python这边，先不说LangGraph，就那个Message结构和Tool接口，Python版本永远比Java版本先进两个大版本。Java系的应用如果只是嵌入一个不复杂的Agent，用Spring AI没问题；如果你要做重逻辑的Agent编排，在JVM生态里会觉得处处受限。在这个阶段，两套生态差距是客观存在的。

但分布式这一层，我会用Java或Go来顶住。Python做Agent调度吞吐量有限，用FastAPI承接并发本身就有点吃力。我现在常用的架构是Java网关层负责对外API和并发控制，内部把任务转发给Python Agent服务。这篇文章后面讲并发的时候再展开讲。

3.2 从一个最简单的Agent跑起来

先别管多Agent，也别管复杂编排。我先带你跑通一个最小可用的Agent，这样你才能看清楚框架里到底发生了什么。

用LangGraph实现一个最简单的“搜索助手”Agent，代码如下：

from typing import Annotated, TypedDict from langgraph.graph import StateGraph, START, END from langgraph.prebuilt import ToolNode from langgraph.graph.message import add_messages from langchain_openai import ChatOpenAI from langchain_community.tools import DuckDuckGoSearchRun class AgentState(TypedDict): messages: Annotated[list, add_messages] def build_agent(): tools = [DuckDuckGoSearchRun()] model = ChatOpenAI(model="gpt-4o-mini", temperature=0) model_with_tools = model.bind_tools(tools) def call_model(state: AgentState): return {"messages": [model_with_tools.invoke(state["messages"])]} def should_continue(state: AgentState): last_message = state["messages"][-1] if last_message.tool_calls: return "tools" return END graph = StateGraph(AgentState) graph.add_node("agent", call_model) graph.add_node("tools", ToolNode(tools)) graph.add_edge(START, "agent") graph.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END}) graph.add_edge("tools", "agent") return graph.compile()

这段代码就是ReAct循环在LangGraph里的最小实现。StateGraph定义了图，agent节点是模型调用，tools节点是工具执行，should_continue是条件判断，决定是继续调用工具还是结束。只要模型返回了tool_calls，流程就会走向tools节点；工具执行完以后，结果作为新消息回到agent节点，喂给模型做下一轮推理。

你也可以用PydanticAI写同样的东西，代码甚至还要短：

from pydantic_ai import Agent, DuckDuckGoSearchTool agent = Agent("openai:gpt-4o-mini", tools=[DuckDuckGoSearchTool()]) result = agent.run_sync("帮我搜索一下LangGraph最新版本")

两款都跑得通。PydanticAI更轻，LangGraph更可控。在实际项目里，一开始用PydanticAI快速验证会非常舒服，等逻辑变复杂了再迁到LangGraph也不迟。

3.3 如何在LangGraph里实现多工具、多分支的复杂Flow

单Agent跑通以后，你的下一个问题肯定是：如果我的任务里要同时用多个工具、还要根据不同的结果走不同分支怎么办？

LangGraph的解法是加节点、加条件边。你可以把不同的工具包在不同的节点里，也可以把不同子任务拆成独立的子图。一个稍微复杂一些的例子：一个数据分析Agent，需要先根据用户的模糊问题生成SQL，然后去数据库执行，执行完以后根据结果判断是直接生成报告还是要再追问用户。

这个流程里至少有四个节点：plan（生成SQL）、execute（执行SQL）、check（判断结果是否满足需求）、reply（生成最终答复）。check节点返回两个方向，满足就走向reply，不满足就回到plan重新生成新的SQL。这里的关键在于State的设计——你需要在State里保存SQL历史，避免它反复生成一模一样的错误SQL。

这种多分支Flow的调试经验，我后面在踩坑那节里详细说。先记住一个原则：图越复杂，State里的字段越要克制，不要让Agent把乱七八糟的中间变量全塞进去。

3.4 代码里的“为什么”：参数设计和结构选择的逻辑

现在我来解释一下刚才那些写法背后的“为什么”。

为什么State用TypedDict而不是用一个Class？因为LangGraph对State的校验和更新依赖类型注解，Annotated[list, add_messages]告诉框架这个消息列表应该如何增量更新——是替换还是追加。这个设计直接影响多轮对话时消息会不会丢。

为什么条件边要单独写一个函数？因为Agent的行为决策本身是动态的，你不可能用静态的图就把所有路径画完。should_continue本质上就是把“决定下一步做什么”这件事从代码逻辑挪给了运行时判断。

为什么temperature要设成0？对工具调用的Agent，特别是涉及检索、计算、结构化输出的场景，创造性是毒药。你希望模型每次都稳定地输出同样的工具调用意图，而不是偶尔来点“创意”。以后做代码生成类Agent，甚至温度应该调到更低的区间。

为什么先跑通最小Agent再上框架？因为所有花哨的抽象都必须建立在你对基础执行循环的真实体感之上。你在最小例子里走一遍推理->调用->观察->再推理的循环，后面看任何框架的文档都不会懵。

4. Agent框架的并发、安全与记忆设计实录

4.1 并发处理：AI Agent怎么扛住生产流量

讲完框架核心逻辑，我单独开一节聊AI Agent怎么扛并发，太多了，这个问题，几乎所有Agent项目一到上线阶段都会遇到。

先坦白一个事实：Agent跟传统API最大的不同是，一次请求的处理时间可能长达几十秒甚至几分钟。如果你还按传统思路，把每个请求都独占一个线程或一个Worker，你的服务容量会瞬间耗尽。

我现在用的方案也是一个分层结构，核心思想是“同步入口，异步执行”。对外暴露同步API，收到请求后立刻返回一个任务ID；内部把任务丢进消息队列，由多个Agent Worker并发处理；前端或调用方通过轮询或WebSocket拿最终结果。这个设计让Agent服务对并发的要求一下子降下来了，真正扛并发的是消息队列和Worker池。

队列用什么？我建议用Redis Stream或者RabbitMQ。Kafka也行，但对Agent任务来说有点重，除非你有非常高的吞吐需求。每个Worker去队列里拉一个任务，然后执行Agent图。要注意的是Worker的并发数不能太大，因为每个Agent任务在推理阶段都会占用大量GPU或API配额，并发堆太多，模型API先给你限流，性能瓶颈不在你的Worker，而在模型侧。

还要考虑超时控制。Agent任务跑几分钟不结束是常态，你必须有超时机制，不要无限等下去。我的做法是在LangGraph的配置里设置recursion_limit，同时在外面套一层Python的asyncio.timeout；如果超时就标记为失败，写入补偿队列，给用户一个可重试的任务状态。

4.2 记忆设计：短期工作记忆与长期向量记忆

记忆这一节，是干货里的干货。我见过很多Agent项目，效果不稳定，最后排查下来都是记忆设计的问题。

短期记忆要解决的核心问题是上下文窗口管理。现在的模型上下文窗口虽然越来越大，但一个任务执行几十轮工具调用以后，塞进去的中间消息照样把窗口撑爆。我常用两个策略：一是消息截断，保留系统提示词和最近N轮消息，中间的细节压缩成摘要；二是关键信息的持久化，把任务过程中的事实、决策、数值提取出来写入State的专门字段，消息本身可以丢，关键数据不能丢。

长期记忆，也就是跨会话记忆，则需要靠外部存储。流程是这样的：每个会话结束或进行中，Agent把值得记住的东西写入向量库。写入的时机和内容要有策略。我现在的标准是：只记忆两类东西，一类是用户偏好和身份信息，一类是任务结果和领域知识；临时推理过程的中间产物一律不写。检索的时候做两路召回，一路按相似度检索向量库，另一路从结构化存储里直接取出与当前用户相关的固定信息，两条结果合并塞进上下文。

有人问要不要用专门的Memory框架，比如Mem0或者LangMem这种。我用过Mem0，理念很好，开箱即用，但有一个问题：它默认帮你管理记忆的提取和存取，这恰恰是我最想自己控制的部分。生产环境我更喜欢自己控制记忆提取策略，因为框架的通用策略并不了解你的业务什么重要、什么不重要。

4.3 安全边界：工具权限与Agent沙盒

Agent安全这个热词现在越来越重要，但我发现很多人理解的Agent安全就是“模型不输出危险内容”，这是远远不够的。

真实环境的Agent安全至少要考虑四层问题。第一层是工具权限控制，Agent能调用哪些工具、不能调用哪些工具，你必须做细粒度控制，不能把带删除功能的数据库工具直接交给Agent。第二层是参数校验，任何来自模型生成的参数都要过一层白名单校验，防止让Agent传进去一个异常值直接把你库给删了。第三层是沙盒执行环境，凡是Agent需要执行代码、操作文件的地方，都应该放进容器或者沙箱里，不能直接在宿主机上跑。第四层是记忆数据保护，Agent的记忆库里会沉淀大量用户数据，这些数据本身的访问权限和脱敏规则，你要走数据安全那一套流程。

一个具体例子。我们做过一个报表Agent，前端给Agent配了一个“查询数据库”工具，参数里包含一个表名。结果模型在一次推理中生成的表名变成了系统表，如果权限校验没拦住，Agent就能把系统的元数据表都拖出来。后来我们把工具的参数改为枚举列表，只允许传有权限的表名，再配合SQL解析器二次校验，这个问题才彻底堵住。

关于Agent记忆安全，学术界也在同步推进。我看到AMemGuard这类研究，核心思路是给LLM Agent的记忆系统加一层主动防御，防止通过记忆注入的手段来操纵Agent行为。这个思路很有价值，但在工程落地上还早，现阶段还是要靠我们自己做好访问控制和数据隔离。

4.4 Worker架构与状态缓存的工程化细节

最后说一个工程化细节，也是Agent框架生产落地时最容易忽略的：当你部署了多个Worker实例时，Agent的当前运行状态存哪里？

答案是一个共享存储。我用Redis作为短时运行状态的存储。LangGraph本身就支持在checkpointer参数里配置一个持久化后端。配置了以后，你的Agent图可以从任意节点恢复，即使Worker重启了，状态也不会丢。这是生产环境必不可少的能力，因为没有哪个Worker能保证不出错。

我给一个LangGraph里配置Redis Checkpointer的参考代码：

from langgraph.checkpoint.memory import InMemorySaver from langgraph.checkpoint.redis import RedisSaver config = {"configurable": {"thread_id": "user_123_task_456"}} # 单机开发用内存 checkpointer = InMemorySaver() # 生产用Redis # checkpointer = RedisSaver(redis_client) graph = build_agent() app = graph.compile(checkpointer=checkpointer) result = app.invoke( {"messages": [{"role": "user", "content": "帮我分析最近30天的销售数据"}]}, config=config )

thread_id是关键，它相当于一个会话标识。用户继续上一次会话时，你用同一个thread_id去调用图，框架会自动把历史状态拉回来。这个设计解决了多轮交互和断点恢复两大问题。

5. 常见问题与排查技巧实录

5.1 Agent不调用工具、死循环、Token爆炸的排查清单

下面这些是Agent开发里出现频率最高的问题，我把排查思路整理成了一张速查表，都是我实际在线下踩过、然后一步步查出来的经验。

Agent不调用工具或调用错误工具

先确认工具描述是不是足够清晰。如果工具是“查询订单信息”，docstring写的是“这个函数用于查询订单”，那模型很可能不理解什么时候该调用它。正确的写法是写明触发条件、参数格式、返回值结构和使用场景。其次确认模型对工具Schema的可见性，如果是GPT系列，工具名称和描述都会进入上下文，如果工具数量太多，模型也可能分不清。这种情况下，减少工具数量或给工具加前缀分类是有效手段。

Agent陷入死循环

LangGraph里默认有recursion_limit，超了会抛异常。调高它是一个办法，但不解决根本问题。真正的问题通常是条件循环的判断设计有问题，比方说工具返回错误后没有把错误信息正确传给模型，导致模型以为结果正常，又基于错误结果继续规划。排查办法是打开LangGraph的debug模式，把每一步的输入输出都打出来看，条件节点走错了你一眼就能捕捉到。

Token消耗爆炸

最常见的原因是工具返回结果过大。比方说查询数据库返回了一万行，直接塞给模型，Token瞬间爆掉。解决方法是加工具结果处理层，把大结果做截断、汇总或结构化提取之后再返回给模型。另外就是每轮ReAct循环的模型输出都有几千Token，多循环几轮就爆了。优化方向是精简Prompt，让它每次只输出必要的字段。

5.2 LangGraph调试三板斧与可视化检查

我带过的所有新人，一开始都会被LangGraph的图逻辑绕晕。投喂一个解决思路：利用LangGraph自带的可视化能力绘图，然后用debug工具逐步查。

你可以直接把图结构画出来：

from IPython.display import Image, display display(Image(graph.get_graph().draw_mermaid_png()))

这个方法会把所有节点和边直观地展现在你面前。你可以一眼看出来哪条边连错了、哪个条件分支漏了。

定位到可疑节点后，进入该节点的函数里打点日志，把输入、输出、State变化全部打印出来。LangGraph是一个确定性框架，节点执行顺序完全由图和运行时状态决定，所以只要日志打全了，没有查不出来的问题。

5.3 Agent沙盒环境报错与框架兼容性的处理经验

框架版本迭代引发的兼容性问题，真的应该单列一条好好说说。LangChain和LangGraph是出了名的版本更新快、API变动大，你上网查攻略时总会查到过时的代码，跑起来直接报错。

我的习惯是：创建项目时就锁死版本，然后严格按照这个版本的官方文档写代码。升级框架版本前，先看Release Notes，尤其关注Breaking Changes，而不是闭着眼睛pip install -U。如果你的团队里有多个项目，建议做一个内部模板仓库，把经过验证的配置固定下来，新项目直接基于这个模板初始化。

至于“codex无法发送消息，显示更新agent沙盒”这一类问题，虽然看起来是具体某个产品的报错，但底层其实都是同样的逻辑：Agent执行环境和沙盒版本不匹配，或者沙盒内的依赖过期导致代码执行失败。排查思路也很简单，检查沙盒版本、更新运行时依赖、确认镜像与本地环境一致，基本能覆盖七八成的问题。

5.4 实战案例复盘：问诊助手Agent框架演进

我拿一个真实做过的问诊助手项目来复盘。第一版用的是CrewAI，两个Agent，一个负责问诊，一个负责生成报告。跑了一个月，效果能看，但出现了两个硬伤：一是对话超过十轮以后上下文塞满，回复质量断崖式下降；二是问诊Agent偶尔会跳过关键问题直接下结论，这是ReAct循环缺少流程约束的表现。

第二版改成LangGraph。我把问诊流程拆分成了五个节点：意图识别、症状采集、既往史采集、辅助检查建议、报告生成。每个节点之间通过条件边约束流转，没采集完症状不会跳到下一步。结果质量大幅提升，Token消耗还降了30%，因为不再需要每轮都让模型自己思考下一步该干嘛了。

这个例子说明什么问题呢？Agent框架的选型和演进，不是越新越好，而是越贴合业务流程约束越好。CrewAI适合业务逻辑简单、Agent自主性要求高的场景；LangGraph适合业务约束强、流程节点明确的场景。你要做的是判断自己属于哪一种。

6. Agent开发学习路线：从入门到放弃（不是）

6.1 新人最容易走偏的三种方式

现在网上的Agent学习资源多到爆炸，但很多人越学越懵，是因为他们一开始就走偏了路。

第一种“偏”，是直接啃框架源码。我不反对读源代码，但反对在连ChatGPT API都还没调过的时候就去啃LangGraph源码。你连Agent的基础执行循环都没有体感，看源码就像看天书，看完也记不住。

第二种“偏”，是疯狂刷八股。什么Agent八股文、面试题、手写ReAct，我承认这有一定的用处，但它只能帮你通过面试，不能帮你做项目。面试造火箭，进去拧螺丝，你也得先搞明白螺丝和火箭的关系。

第三种“偏”，是盲目跟热点。今天MetaGPT火去玩MetaGPT，明天AutoGen火换AutoGen。框架换来换去，最后发现核心原理全没学会。主流的Agent框架再多，底层都是模型调用、工具执行、状态管理、记忆检索这几个关键词的排列组合。

6.2 一条我觉得最能落地的学习路线

如果你愿意参考，我建议按这个顺序来：第一周，不碰框架，直接用OpenAI或任意大模型的API裸写一个ReAct循环，用最朴素的循环加Function Calling搞定一个单工具Agent；第二周，开始上手LangGraph或PydanticAI，把之前裸写的逻辑迁移到框架里，同时把LangChain的Tool抽象、Prompt模板机制搞清楚；第三周，设计一个真实业务场景，比如电商客服、数据分析助手，完整实现一个带记忆、带短期记忆、带工具校验的Agent；第四周，研究别人完整的Agent项目源码，重点看它的State怎么设计、编排怎么组织、并发和存储怎么解决。

最后再强调一下：一个Agent开发工程师值钱的地方，不在于会用多少个框架，而在于能不能徒手设计一套Agent架构来解决业务问题。我面试人的时候，从来不问“你用过LangGraph吗”，我问的是“如果不用任何框架，你打算怎么写一个支持多轮对话、能调用工具、有记忆的Agent”。能把这个问题的设计逻辑讲清楚的，框架对他来说是加分项；讲不清楚的，框架对他来说只是掩饰。

学习路线从来不是框架清单，而是底层能力加工程认知的沉淀。把Agent框架当工具，不要当信仰；把业务需求当中心，不要把自己变成框架的奴隶——这大概是我三年Agent开发下来最想传递的一句话。