企业官网建设流程全解析

不用从“什么是Agent”这种教科书定义开始。我直接说一个现象：最近半年，几乎每隔几天就会有人在群里问我“AI Agent到底怎么入门”“为什么我调的Agent总是不按套路出牌”“用LangChain搭了个Demo，上生产就崩”。这些问题背后其实是同一个困惑——网上关于Agent的教程一大堆，但大部分要么是概念搬运，要么是跑个玩具Demo就结束，真正能帮你把这套东西落地到业务里的内容很少。

这篇就把我自己的经验捋一遍：从Agent和普通聊天机器人的本质区别，到主流工作架构，再到技术选型，最后手把手拆一个基于FastAPI + LangChain + LangGraph的能“干活”的Agent实例。里面还会专门聊一个大家特别关心的问题——Agent到底怎么扛并发，以及小红书自动发消息、期货交易这类需求靠不靠谱。不管你是刚接触Agent的初学者，还是已经写了不少代码但总觉得差一口气的开发者，这篇都能给你一些可以直接用的思路。

1. 别再纠结AI Agent是不是噱头：先搞清楚它和聊天机器人差在哪

我见过太多人把“接了大模型API的机器人”直接叫Agent。严格来说，那只是套了一层提示词的聊天机器人。搞清楚这点，后面很多困惑都会迎刃而解。

1.1 Agent的本质就四件事：规划、记忆、工具、行动

Agent和普通Chatbot最大的区别，在于它不再只是“生成文字”，而是要“完成任务”。完成一个真实任务，意味着需要四个能力协同：

• 规划（Planning）：把一个大目标拆成若干步骤，决定“先做什么、后做什么”。比如“帮我调研一下目前主流向量数据库的选型”，Agent需要自己拆成“搜资料、对比参数、整理报告”几步。
• 记忆（Memory）：短期记忆负责多轮对话的上下文，长期记忆则把历史结论、用户偏好存下来，下一次接着用。
• 工具（Tools）：调用搜索API、数据库查询、内部系统接口、代码执行器等外部能力。没有工具，Agent就只是个“纸上谈兵”的思考者。
• 行动（Action）：把规划落地成具体调用，并根据反馈结果调整下一步行动。

这四件事缺一不可。用一句话概括：Agent = 大模型 + 规划能力 + 记忆系统 + 工具调用 + 执行闭环。大模型是“大脑”，其他组件是“手和脚”。

1.2 一个“订咖啡”的例子看懂差别

打个比方。你跟一个普通聊天机器人说：“帮我订一杯拿铁，少糖，送到公司前台。”它会很礼貌地回复你：“好的，我建议您尝试某家咖啡店的外卖服务。”然后，就没然后了。

但换成Agent，它会这样做：先通过地图API搜索附近的咖啡店，然后调用外卖平台的接口查看哪家有“少糖拿铁”，再读取你之前存好的配送地址，下单后把订单号推给你。如果某家店刚好打烊了，它会自动换一家继续尝试。

这个例子里，聊天机器人只是“理解”了你的需求，而Agent是“执行”了你的需求。理解只是第一步，执行才是Agent存在的意义。所以，判断一个系统是不是Agent，标准就是：它有没有在脱离人类逐条指挥的情况下，自主完成一串带反馈闭环的动作。

2. 主流的Agent工作架构：ReAct、Plan-and-Execute与多Agent协作

搞清楚Agent的定义之后，下一个问题就是：让Agent“自主工作”的流程模式到底长什么样？目前业界主流的方案有三种，理解它们各自的适用场景，能帮你少走很多弯路。

2.1 ReAct：让模型“边干边想”

ReAct（Reasoning + Acting）是目前最流行、门槛也最低的一种范式。它的核心逻辑是一个循环：

1. Thought（思考）：模型根据当前任务，推理下一步该做什么。
2. Action（行动）：调用某个工具，比如搜索、读文件、查数据库。
3. Observation（观察）：把工具返回的结果拼进上下文，让模型看到。
4. 回到第1步，继续思考。

这个循环有点像人做事的方式：先想一步，做个动作，看看结果，再想下一步。ReAct的好处是灵活、成本低，不需要预先定义完整流程。坏处是模型可能会在循环里反复绕圈，或者被不相关的工具结果带偏。所以用ReAct时，一定要给模型设定清晰的“停止条件”，比如完成步骤就输出最终答案，不要继续调用工具。

2.2 Plan-and-Execute：先订计划再动手

如果说ReAct是“走一步看一步”，Plan-and-Execute就是“先画地图再出发”。它分成两个阶段：

• Planner（规划者）：在动手之前，让模型把任务拆解成一个有序的步骤列表。比如“调研向量数据库”会被拆成：搜集资料、对比功能、分析性能、输出报告。
• Executor（执行者）：按计划依次执行每一步，每一步都可以调用工具。执行完后，再把结果汇总。

这种架构的优点是流程可控、便于跟踪进度，尤其适合步骤明确、周期较长的任务。缺点是灵活性比ReAct低——如果执行过程中发现计划根本行不通，Agent需要重新生成计划，这会增加延迟。

我自己的经验是：如果任务是“目标明确但路径未知”，选ReAct；如果任务是“步骤可预测且逻辑稳定”，选Plan-and-Execute。大多数真实业务场景其实都能拆成后者，所以生产环境里Plan-and-Execute反而更常见。

2.3 多Agent协作：拆给多个角色干

再往上走一层，就是把一个大任务拆给多个各司其职的Agent。每个Agent有自己的系统提示词、工具和记忆，类似一个“虚拟团队”。比如做一个市场分析报告：一个Agent负责收集数据，一个Agent负责数据分析，一个Agent负责写报告，还有一个Agent负责审核校验。它们之间通过消息传递协作，像人和人一起办公一样。

多Agent架构的好处是职责清晰、擅长并行处理、每个子Agent的提示词可以被压得很精准。坏处也很明显：系统复杂度指数级上升，Agent之间的消息协议、上下文传递、死锁处理都是麻烦事。我的建议是：单体Agent能解决的，绝对不要上多Agent。我见过太多项目，明明一个Agent加几个工具就能搞定，硬是拆成四五个Agent，最后光是调参就调了一个月，得不偿失。

3. 技术栈怎么选：LangChain / LangGraph / 自研 / Spring AI / Rust

聊完架构，就得面临一个现实问题：框架用什么？选框架这件事很私人，也很容易踩坑。我把目前的主流方案逐一拆开说。

3.1 为什么大多数生产项目都会绕开纯LangChain

LangChain是Agent生态里名气最大的框架，但它在业界的口碑其实有点两极分化。它非常适合做两件事：一是快速验证想法，二是把各类模型、工具、向量库的API统一封装，省去大量对接代码。我早期做Demo时就用它，半小时就能跑通一个带搜索工具的Agent。

但一旦到了生产环境，LangChain的“过重抽象”就开始带来麻烦。它里面封装的Chain、AgentExecutor等概念层级很深，出了问题要追到具体某一次调用异常，往往得翻好几层源码。而且它的API变动频繁，社区里也经常有人抱怨“上周能跑的代码，升级一个小版本就废了”。

所以我的建议比较直接：Demo用LangChain没问题，但要上生产，要么选LangGraph，要么在LangChain的基础上只拿它当工具库，自己控制主流程。

3.2 LangGraph：把Agent状态变成一张图

LangGraph是LangChain团队后来推出的一个专门用于构建复杂Agent编排的库。它的核心思想是把Agent的整个运行流程定义成一张有向状态图（StateGraph）：每个节点是一个逻辑单元（比如“调用搜索工具”“写报告”），节点之间用边连接，边上可以设置条件跳转。

这种设计带来的最大好处是运行逻辑显式化。你在代码里一眼就能看出“什么情况下走到哪个节点”，而不是靠一堆提示词让模型自己猜。这也意味着调试变得容易很多——状态图可以直接打印出来看，也可以在任何节点处中断，检查当前状态里的所有数据。对我这种有传统软件工程背景的人来说，LangGraph的“可控感”比LangChain那种“黑盒执行器”舒服太多了。

3.3 什么情况下自己写比你想象得更划算

看到这里，你可能会觉得框架真复杂。我的真实想法是：不要神话框架，很多场景下自己写反而更香。

如果你的Agent逻辑非常简单，比如就是“拿到提问->调用工具->把结果交给模型生成回答->返回”，用原生代码加几个函数可以实现，依赖少、逻辑透明、部署体积也小。我在一个内部工具项目里，只用FastAPI加OpenAI的Function Calling，三百行代码就实现了一个符合预期效果的运维助手，比套LangChain之后到处处理版本兼容问题痛快得多。

适合自研的场景有几个特征：工具链少，逻辑线性，不需要复杂的状态管理。反之，如果你的Agent有多个分支、需要人工审批节点、还要做长流程任务，那LangGraph这种“图编排”框架会更合适。

3.4 Spring AI与Rust生态值得关注的点

除开Python，生态里还有两个方向值得知道。

如果团队是Java技术栈为主，可以关注Spring AI——它把大模型调用、向量存储、结构化输出这些能力做成了Spring Boot的starter风格，跟现有Java工程融合度高，能让Java开发者在不太熟悉Python的情况下快速上手Agent开发。它在国内的热度也在上升，如果你搜过“spring ai agent”，应该能看到不少企业落地案例。

而基于Rust的AI Agent目前更多见于追求极致性能和低资源开销的场景。Rust的内存安全和无GC特性，使它特别适合做Agent运行时的基础设施层，比如调度器、网关、工具执行沙箱。但Rust的社区生态和开发效率跟Python比起来差不少，入门期很长。我的看法是：生产链路里的高并发中转层可以用Rust写，但Agent本身的业务逻辑，还是建议用Python这类开发效率高的语言。没必要为了“酷”给整个项目增加不必要的难度。

4. 手把手搭一个能干活的Agent：FastAPI + LangChain + LangGraph

选型聊了不少，接下来进入正题。我以一个“企业技术方案调研Agent”为例，完整走一遍搭建流程。这个场景很典型：既要搜索外部资料，又要调用内部工具，还要分步骤汇报结果，正好能把Agent的核心能力带出来。

4.1 场景和整体结构

假设老板让你做一个“主流向量数据库选型调研”。传统做法是人自己去搜资料、整理表格、写结论——现在把这个任务交给Agent。需求拆解如下：

• 输入：一句话任务描述。
• 输出：一份分段的调研报告，包含对比、结论和推荐。
• 中间过程：搜索资料、提取要点、对比参数、生成报告。

整体技术结构选FastAPI + LangChain + LangGraph：FastAPI负责对外提供HTTP接口；LangChain负责统一调用大模型和工具；LangGraph负责把“搜索—分析—生成报告”编排成一张状态图。目录结构可以按下面这样放：

agent_service/ ├── app.py # FastAPI入口 ├── agent/ │ ├── graph.py # LangGraph状态图定义 │ ├── tools.py # 工具函数 │ ├── state.py # Agent状态数据结构 │ └── prompts.py # 提示词模板 ├── tests/ └── requirements.txt

4.2 工具定义：让Agent有手有脚

工具是Agent的“手”。在这个例子里，我们给Agent准备三个工具：网络搜索、获取数据库文档、代码示例生成。

用LangChain定义工具很简单，用@tool装饰器包一个普通函数就行：

from langchain_core.tools import tool import requests @tool def search_web(query: str) -> str: """搜索互联网，返回与query相关的前几条结果摘要。query应为具体的技术关键词。""" # 这里可以接入你习惯用的搜索API resp = requests.get( "https://your-search-api.example.com/search", params={"q": query, "n": 5}, timeout=10, ) return "\n".join(item["snippet"] for item in resp.json()["results"]) @tool def get_technical_docs(topic: str) -> str: """获取指定技术主题的官方文档关键章节。topic为文档名称或技术名称。""" # 从内部文档库检索 return fetch_from_internal_docs(topic) @tool def generate_code_example(language: str, task: str) -> str: """生成一段示例代码。language为编程语言，task为要实现的功能描述。""" # 调用LLM生成代码示例，加上格式校验 return llm.invoke(f"请用{language}实现：{task}，只输出代码")

这里有个容易忽略的点：每个工具都要写清楚函数签名和docstring。因为模型是靠函数的描述来决定“什么时候调用这个工具”的，描述含糊，Agent就会乱用工具或者不知道该用哪个。

4.3 状态图编排：把流程变成可控制的图

下一步是用LangGraph定义状态和节点。Agent的状态是一个不断累积的数据结构，通常用TypedDict定义：

from typing import TypedDict, Annotated from operator import add class AgentState(TypedDict): task: str research_notes: Annotated[list[str], add] report: str

这里的Annotated[list[str], add]表示每次节点返回的新列表会自动追加到已有列表末尾，而不是覆盖——这就是LangGraph里的“消息累积”机制，非常实用。

接着定义节点函数。每个节点接收整个状态，返回要更新的字段：

from langgraph.graph import StateGraph, END def search_node(state: AgentState) -> dict: """根据任务拆解关键词并搜索资料""" keywords = extract_keywords(state["task"]) # 可调用LLM提取核心关键词 notes = [] for kw in keywords: notes.append(search_web.invoke(kw)) return {"research_notes": notes} def analysis_node(state: AgentState) -> dict: """分析搜索到的资料，提炼对比要点""" analysis = llm.invoke( f"根据以下资料提炼对比要点：\n{state['research_notes']}\n任务：{state['task']}" ) return {"research_notes": [analysis]} def report_node(state: AgentState) -> dict: """生成结构化调研报告""" report = llm.invoke( f"基于以下分析内容，生成一份结构化的调研报告（含对比表、优缺点、推荐结论）：\n{state['research_notes']}" ) return {"report": report}

然后把这些节点串成图：

def build_graph(): g = StateGraph(AgentState) g.add_node("search", search_node) g.add_node("analysis", analysis_node) g.add_node("report", report_node) g.set_entry_point("search") g.add_edge("search", "analysis") g.add_edge("analysis", "report") g.add_edge("report", END) return g.compile() agent_app = build_graph()

就这样，一张最简单的Agent状态图就建好了。它的流程是：搜索资料 -> 分析提炼 -> 生成报告 -> 结束。任何一步如果发现结果不理想，你还可以加条件边，比如“如果搜索到的资料不足，重新搜索”。

4.4 跑起来后的效果与关键实现细节

最后是把它包成一个HTTP服务。用FastAPI可以非常简洁地暴露接口：

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class TaskRequest(BaseModel): task: str # 初始化状态时一定要带上已有的知识或者历史 @app.post("/agent/run") async def run_agent(req: TaskRequest): # 这里用ainvoke异步调用 final_state = await agent_app.ainvoke({"task": req.task}) return {"report": final_state["report"]}

实际跑起来的效果，下面给你一个我自己测试时的缩略例子。输入任务“调研Milvus和pgvector在召回准确率上的差异”，Agent输出了类似这样的报告：

## 调研结论 - Milvus在百万级向量规模下召回率更稳定，索引类型多样（IVF_FLAT、HNSW）， 适合独立部署、数据量大的场景； - pgvector集成在PostgreSQL内，事务一致性最好，适合中小规模场景， 但在大规模向量检索时性能有明显瓶颈； - 推荐：若已有Postgres且数据量在千万级以下，优先pgvector； 若数据量大且对延迟敏感，选Milvus。

这里有个值得注意的细节，状态图初始化时，要把用户的历史偏好、背景知识作为初始状态传入，而不是让Agent每次从零开始。比如调研财务相关任务时，可以在初始状态里带上“公司内部已采用某云服务，推荐优先考虑兼容方案”，这样生成的报告会更贴合实际业务。

5. 让Agent真的扛得住并发：状态存储、异步与流式输出

很多人把Agent做成Demo很容易，但一遇到“线上有几十上百个用户在同时用”，就各种问题。那一张图编好了，到底怎么让它扛住并发？这是搜索热度极高的“ai agent怎么扛并发”这个问题背后真正的技术难点。我把我的经验拆成三点。

5.1 先想清楚什么是Agent里的“状态”

Agent运行过程中的状态分两类：

• 瞬时状态：当前这一轮任务的执行进度、中间结果、工具返回的内容。
• 持久状态：用户长期偏好、历史对话、跨会话需要记住的知识。

很多人扛不住并发的第一个原因，就是把状态放在进程内存里。单个用户跑没问题，十个用户同时跑，内存里全是状态，服务就要崩了。回答是：瞬时状态跟着任务走，持久状态必须外置。

瞬时状态对应下图里的执行上下文，可以通过任务ID来管理；持久状态则要放到Redis或数据库里。每次Agent处理完一步，就把最新状态按任务ID存下来，下次启动或恢复时再从这个任务ID对应的位置继续。

5.2 无状态服务 + Redis记忆

把服务本身做成无状态（Stateless），是扛并发的前提。所谓无状态，就是服务实例本身不保存用户的业务状态，所有状态都从Redis里读取和写入。

用LangGraph时，可以通过Checkpointer机制实现状态快照：

from langgraph.checkpoint.sqlite import SqliteSaver from langgraph.checkpoint.base import BaseCheckpointSaver # 生产环境建议用Redis实现Checkpointer checkpointer = RedisCheckpointer(redis_url="redis://redis:6379/0") g = StateGraph(AgentState) # ...添加节点和边... agent_app = g.compile(checkpointer=checkpointer)

之后每次执行时，把config里的thread_id当作“任务ID”传入。同一个任务ID的状态会自动累积，不同任务ID之间完全隔离：

config = {"configurable": {"thread_id": f"task-{user_id}-{task_uuid}"}} final_state = await agent_app.ainvoke({"task": req.task}, config=config)

这样一来，不管你有多少个服务实例在跑，只要它们连的是同一个Redis，状态就不会丢，水平扩展只需要加实例就行。

5.3 流式输出的正确姿势

Agent任务耗时一般都比较长（几秒到几十秒不等），如果让用户一直等到全部跑完才返回，体验会很差，而且HTTP连接长时间占用本身也是并发压力的一部分。正确处理是使用流式输出（SSE，Server-Sent Events）。

FastAPI里实现流式响应很简单：

from fastapi.responses import StreamingResponse @app.post("/agent/stream") async def stream_agent(req: TaskRequest): config = {"configurable": {"thread_id": f"task-{req.task_id}"}} async def event_generator(): async for event in agent_app.astream_events( {"task": req.task}, config=config, version="v1" ): if event["event"] == "on_chat_model_stream": content = event["data"]["chunk"].content if content: yield f"data: {content}\n\n" yield "data: [DONE]\n\n" return StreamingResponse(event_generator(), media_type="text/event-stream")

这样做的好处是：用户的第一屏反馈几乎实时出现，不需要等全部任务完成。同时，服务端可以更早释放请求资源，并发能力会有肉眼可见的提升。

5.4 压测与性能数据参考

我拿一个类似的Agent服务做过简单压测，给出参考数据方便你有预期。测试环境是4核8G的容器实例，模型调用走云端API，工具只有网络搜索。并发20个用户同时发起调研类任务，每个任务平均要调用6次模型、5次搜索工具：

一个很明显的瓶颈是模型调用时间。如果业务允许，可以把部分工具调用从“必须等结果”改成“后台异步执行并轮询”，能进一步降低P95耗时。但异步会牺牲一些实时性，需要根据业务需求权衡。

6. 把Agent放进真实业务：小红书自动消息、期货交易这些需求到底可不可行

入门之后，很多人会想“Agent能帮我干点实际的活不”。热搜词里我看到两个非常典型的需求：一个是“让小红书自动发消息/自动化运营”，另一个是“个人使用AI Agent做期货交易”。我把这两个需求都认真聊一下，包括怎么做、边界在哪里。

6.1 小红书类自动化消息：能力上能做到，合规和风控才是门槛

先说结论：从纯技术角度，让Agent自动在内容平台上发帖、回复私信是完全可行的。通过平台的开放API，或者桌面自动化工具模拟操作，Agent定时捕捉热点话题、生成内容、发布、回复评论，整套链路实现起来并不难。真正难的是平台对“机器行为”的识别和限制。

主流内容平台对自动化行为非常敏感，一旦识别出同一IP下高频操作、无真人交互特征，轻则限流，重则封号。所以这类需求如果要落地，一定要做好三件事：

• 限频：严格控制Agent的操作频率，模拟真人节奏，比如每次操作之间加随机间隔。
• 内容审核兜底：生成的内容必须过一轮敏感词和平台规范过滤，不能因为模型输出不当内容导致账号违规。
• 人工抽检：Agent发布前设置“待审”状态，由人工确认后再发布，虽然降低自动化程度，但大幅降低风险。

还有一点容易被忽略：平台API的权限边界。许多平台的开放API并不支持“自动发帖”，或者只支持在特定类目下操作。在动手写代码前，先花一天把平台的规则文档读一遍，能帮你省掉后面漫长的封号申诉时间。

6.2 期货交易Agent：技术链路比想象得长，且边界要守住

“个人用AI Agent做期货交易”这个问题在程序员圈子里经常被讨论。技术上它也不是天方夜谭，但它的核心难点根本不在“Agent”上，而在数据和交易执行：

• 数据接入：获取实时行情、合规的交易账户授权，这块往往比想象中繁琐。
• 策略信号：让模型基于历史数据和实时数据生成交易信号。这里有个大坑：模型会产生幻觉，可能给你一个看似合理但完全没有历史依据的信号。
• 交易执行：调用期货公司的交易API下单、撤单、查询持仓。各家API质量不一，而且风控要求严格。
• 风险控制：每笔交易的止损、资金占用比例、最大回撤限制，这些必须写死在代码里，不能让Agent“自主决定”。

关于这块，我必须非常明确地说：我是一个技术分享者，不是投资顾问，任何具体交易策略都请咨询持牌专业人士；同时，用Agent做实盘交易之前，务必确认自身所在地区对自动化交易的监管要求，并走正规证券公司或期货公司的合规通道。很多人在模拟盘上觉得“稳赚”，实盘一跑就亏损，往往不是因为模型不好，而是因为滑点、手续费、资金管理这些真实世界里的成本没有算进去。

回到技术本身，如果你真的想尝试，我建议从“类交易信号研究助手”起步，而不是直接怼“全自动交易Agent”。让Agent负责数据整理、新闻情绪分析、历史回测报告的生成，最终交易决策由你人工控制。这条路既能用上Agent能力，又留有足够的安全边界。

6.3 通用原则：灰度和人工兜底

把Agent接入真实业务，通用原则有三条：

• 先旁路，再并行，最后接管。先让Agent在旁边给出建议/草稿，人在系统里照常操作；对比一段时间的效果后，再让Agent的输出自动流转到审核队列；最后才考虑部分环节的自动决策。
• 兜底开关必须存在。任何自动化Agent，都要有一个紧急停止按钮或者熔断机制。比如连续报错N次、或结果置信度低于阈值时，自动暂停并通知人。
• 日志和审计要跟上。Agent的每一步决策、工具调用、参数变化都要记录，否则出了问题没法定位责任。

“AI落地”这件事，技术占一半，工程化、合规和人的信任占另一半。把握住这三条，Agent就不至于成为失控的“自动捣乱器”。

7. 入门学习路线和最容易踩的坑

最后，给想系统入门的同学一条务实的学习路线，以及我一路走来踩过的坑。跟“多久精通Agent”相比，“多久能自己搭出一个像样的Agent”更现实——我的答案是两到四周，前提是路径走对。

7.1 六个阶段学习路线

第一周，先把提示词和Function Calling练熟。如果你连“让模型稳定输出JSON or 在没有结果时拒绝回答”都搞不定，后面将很难顺利。

第二周，掌握检索增强生成（RAG）。把向量库、Embedding、召回、重排这套链路跑通，因为“让Agent拥有自己的知识库”是绝大多数业务场景的刚需。

第三周，接触LangGraph，从小图开始。先实现一个只有两个节点的图，比如“先判断问题类型，再路由到对应处理节点”，然后逐步增加节点和条件边。状态图的思维和传统代码的“函数调用”很不一样，需要刻意练习。

第四周，做一个小型端到端项目。建议选一个你自己日常工作中重复性高的任务，做成Agent服务。比如自动生成周报、自动整理会议纪要、自动做数据报表的初步分析。做完这个项目，你就算真正入门了。

之后才是扩展方向：多Agent协作、长期记忆、复杂工具链、高并发部署。这些可以按需学，不用一开始就铺开。

7.2 我踩过的几个印象深刻的坑

第一个坑是**“提示词过长导致上下文爆炸”。** 我早期设计Agent的时候，为了“让模型更聪明”，把每一个工具的描述都写得特别详细，还加了一堆背景知识。结果模型每轮对话都要把这些内容全部算一遍，API费用暴涨，响应速度还变慢。后来我学会了给工具描述做“减法”，只保留关键词和触发条件。

第二个坑是**“工具返回格式不受控”。** 刚开始做工具调用时，工具返回的文本格式五花八门，有纯文本、有JSON、有Markdown表格。模型解析这种混合内容时会非常不稳定，有时候会漏掉关键字段。解决方法是：所有工具统一返回结构化JSON，由代码负责解析后再传给模型，而不是让模型自己从自由文本里去“碰运气”。

第三个坑是**“循环失控”。** ReAct模式下，模型可能陷入“搜索—发现资料不够—再搜索—还是不够”的死循环，API账单哗哗涨。我现在所有用ReAct的地方都会在状态图里加一个“最大迭代次数”的条件边，超过就强制结束，让模型基于已有资料输出当前结果，并注明“资料可能不完整”。

第四个坑是**“盲目追求多Agent”。** 正如前面说的，多Agent架构看着高级，调试难度却是指数级上升。我见过有人做一个“文档问答Agent”也要拆成“意图识别Agent、检索Agent、总结Agent、质检Agent”，结果四个Agent之间互相传错消息，最终效果还不如一个Agent直接搞定。能用简单方案解决问题，就不上复杂方案。

7.3 给新手的几条建议

建议一：先在业务里找一个足够小的切点。不要一开始就想着做一个全能的“数字员工”，先把一个重复性的、规则相对清晰的环节自动化，跑通、再扩展。比如先只做“会议纪要点提取”，不要上来就做一个“全能会议助理”。

建议二：多读框架源码，别只会调API。不管是LangGraph还是其他框架，遇到Bug时去读源码能学到比教程多得多的东西。理解了框架的抽象层，你才真正拥有了改造它的能力。

建议三：把“提示词工程”和“系统工程”放在同等位置。很多初学者死磕提示词，试图靠提示词解决所有问题，但真正稳定运行的Agent，靠的是合理的图结构、扎实的工具封装、严格的输入校验和清晰的状态管理。提示词只决定了模型“聪明不聪明”，工程决定了这“聪明”能不能稳定发挥，别偏科。