1. AI Agent是什么一年烧钱踩坑后的重新认识去年年初我刷到铺天盖地的 AI Agent 宣传各个都说“Agent 元年来了”“AI 要自己干活了”我当时也是上头得不行觉得这就是下一个风口。刚好手头有点闲钱项目预算也批了一部分我就真金白银地去试前后搭了十几个项目一年下来光调用模型的费用就烧掉了几千块这还是我控制得很克制的结果。今天这篇就是把这一年踩过的坑、试出来的结论、真正跑得通的经验全写出来给准备入坑或者已经在坑里的朋友做一个参考。先说清楚我理解的 AI Agent 到底是什么。如果只用一句话概括AI Agent 不是一个独立的算法而是一个能让大模型自主完成目标任务的工程系统。它跟普通的 Chatbot 最大的区别在于“闭环”二字。聊天机器人往往是单轮或者多轮对话你说一句它答一句状态和上下文都锁在会话里。Agent 不一样它内部有一个持续运转的循环——感知当前任务状态、调用大模型做决策、执行工具调用、然后再次读取新的状态——这个循环可以一直跑下去直到目标达成或者撞上预设的终止条件。打个生活化的比方。普通的 AI 聊天像一个向导你问路它给你指路但它只负责“告诉你”至于你到底走没走到它不管。Agent 更像一个项目经理它接到一个目标之后会自己拆任务、找资源、协调外部工具、验证结果中途卡住了还会换条路走。这个“自己拆任务 自己验证结果”的能力才是 Agent 的核心价值。这一年我自己搭过的架构从小到单 Agent、大到多 Agent 协作群跨度很大但总结下来无非就几件事目标拆解、记忆管理、工具调用、结果校验。你不管看多少篇行业白皮书底层翻来覆去就是这四件事。很多刚入门的同学容易被各种名词绕晕什么计划模式、反思模式、子 Agent 编排、Tool Router其实都是这四件事在不同粒度上的拆法。然后聊聊钱是怎么烧掉的。使用大模型 API 计费分两块一块是上下文输入计费一块是输出计费。Agent 跟聊天不一样的地方在于它为了达成一个目标可能要循环调用模型很多次而每一次调用都会把历史上下文重新发送一遍。哪怕这个上下文已经几万字了API 每次都按全部 token 收一次费所以同一个对话循环到第 20 轮时单次调用的费用可能已经是第 1 轮的十几倍。这个问题在几个月前我专门算过一笔账后面第三章会详细拆解。还有一个让我比较意外的点很多 Agent 项目到最后根本不是被技术卡死的而是被成本结构和可靠性一起卡死的。比如你搭了一个很酷的自动创作 Agent它可以自动搜集资料、整理大纲、写完整篇稿子。Demo 演示效果很好但月底一看出账就傻眼了——一个任务跑完平均要烧掉几块钱的模型调用费而且任务成功率只有七成失败的还要重新跑。这种项目你自己私底下折腾没问题真要拿去面向用户先想想谁为这个成本买单。所以这篇不仅是讲“Agent 是什么”更想讲清楚“怎么在烧钱的情况下把 Agent 做稳、做实用”。我从底层原理到实际选型都过一遍重点讲 Token 的成本陷阱、并发处理、以及当前最实用的 LangChain LangGraph FastAPI 技术栈。文章末尾还整理了这一年遇到过的高频问题全是能直接抄作业的排错经验。2. Token经济学为什么我的钱总是烧得莫名其妙很多第一次接触 Agent 开发的开发者心里都会有个疑问我平时用 ChatGPT 聊天一个月也花不了几块钱为什么自己做 Agent 却像烧钱一样快这背后其实是“Agent 的循环机制”在疯狂推高调用量。理解 Token 的消耗机制比理解模型本身更重要因为Token 就是 Agent 世界的货币每一轮决策、每一段记忆、每一次工具调用的结果最后都会变成 Token 账单一并出现在 API 的出账明细里。2.1 Token到底是什么费用Token 最直白的理解就是“模型计费的最小文本单元”。英文场景下一个 Token 大概对应 0.7 个单词中文场景下一个 Token 大概对应 0.5 到 0.7 个汉字在主流模型上1000 个 Token 约等于 700 个中文字符。模型不是按字符收钱而是按 Token 收钱这是第一步。国内外的模型计费单位都差不多要么是每 1K Token 计费要么是每 1M Token 计费。关键点来了大模型的计费拆分成了Input Token 和 Output Token两类。Input 是你发给模型的全部文本Output 是模型生成出来的回复内容。很多模型 Output 单价是 Input 的 3 到 5 倍所以设计 Agent 的时候不光要省钱省在“输入”上“输出”更要控制。我自己刚起步的几个月犯过一个大错误以为让模型多输出一点效果会更好。结果一个简单的任务我刻意让模型输出 JSON 过程中的思考链、候选方案、执行计划十几轮下去单次任务的输出 Token 是正常方案的 3 倍多。效果确实没见得好成本倒是肉眼可见地上涨。后来我才意识到给 Agent 设定清晰的输出格式和输出边界比一味追求自由发挥更省钱也更稳定。2.2 上下文叠加效应烧钱的真实原因如果你只是单纯聊天上下文再长每一轮对话也就发送“目前累计的全部聊天记录 新问题”。但 Agent 的内存机制不一样。Agent 通常会用messages数组记录历史信息每次调用模型时要发送整个数组。假设你第一轮上下文是 2000 Token第二轮增加 500 Token表面上只增加了 500实际上你把累积的 2500 全部重新发了一遍。第 50 轮的时候最后一次调用发送的是累积起来的 1 万甚至几万 Token。算一笔实际账。假设你做一个自动客服 Agent高峰期一个用户问题平均要让 Agent 跑 20 轮内部循环才能给到最终答案。每轮发送的累积上下文长度逐步递增平均估算下来大约要消耗 6 万 Token 输入外加 8000 Token 输出。用市场上中价位模型来算一次完整交互的成本可能在 0.3 到 0.5 元左右一天只有 1000 个真实用户使用这个 Agent 一天的成本就在 300 到 500 元之间一个月下来是五位数。我见过很多个人开发者不是被技术打败的是被成本模型打败的。他们功能做得很炫酷但没有在系统设计里做“上下文压缩”Agent 每跑完一轮就把全部历史记录原封不动发给下一轮成本想压都压不下来。解决这个问题的思路一般有四个方向做记忆摘要、做滑动窗口、做状态裁剪、做任务拆分。2.3 降低Token消耗的四个实操手段先把最直接有效的方法列个表然后再逐条讲实践细节降本手段原理适用场景历史对话摘要化定期把老对话用模型压缩成摘要只保留关键信息长周期多轮任务工具结果裁剪只保留工具返回内容的关键字段不整段塞入上下文搜索、数据库查询任务粒度拆小拆成多个子任务每个子任务单独一次模型调用复杂目标拆解缓存Prompt模板系统提示和固定指令用服务端缓存大量固定指令场景第一个“历史对话摘要化”是我这一年认为最有效的省钱手法。我最初的 Agent 启动后会把所有历史记录都留着后来改成每当累积超过 5000 Token就用模型生成一段 300 Token 以内的摘要旧记录直接丢掉关键时刻再把摘要注入新上下文里。这个做法牺牲了大概百分之几的回忆精度但把长任务成本直接砍掉了一半。第二个“工具结果裁剪”经常被人忽略。搜索工具返回的网页正文往往有几万字Agent 真正需要的只是一个数字、一段话。如果不做裁剪搜索结果全量塞进上下文一次工具的调用成本可能比模型总结还高。后来我把所有工具返回值统一包了一层“格式化协议”只提取结构化字段其余全部丢弃。第三个任务粒度拆分我从实际工程里感受到的是一个 10 轮内能解决的任务不要拆成 30 个子任务。拆得太细会增加大量的模型调度请求每一个子任务都包含一次完整的上下文传递累计费用未必比一次大任务低。所以拆分的度要把握在“必要的边界”上——当任务跨越了不同的数据源或者需要清晰的阶段性验证时才去拆。最后说 Prompt 模板缓存这个不算所有的模型都支持但主流模型已经陆续支持前缀缓存。系统提示词如果超过几百个 Token 且相对稳定服务端会把前缀缓存起来后续相同前缀的请求会有大幅折扣。我把常用的 Agent 系统说明、角色定义、输出格式约束都统一整理在同一个“固定前缀段”实测下来这部分费用能省不少。3. 主流架构与技术选型LangChain、LangGraph和FastAPI怎么就火了先聊一个热词搜索里的高频问题AI Agent 的主流架构到底是什么。我这一年试了不少从纯 Prompt 工作流、LangChain 的 AgentExecutor、到 LangGraph 的图状态机再到自己手写循环调度器各有优劣。如果让我直接给结论现阶段最稳妥、最适合生产落地的是 LangGraph LangChain 工具生态 FastAPI 作为服务入口。这套组合能覆盖绝大多数真实的业务场景也是我现在的主力方案。3.1 为什么不是 Python 裸写而是选择 LangChain 生态很多初学者会问我都用 Python 了为什么还要套一层 LangChain直接用 Requests 调模型 API自己写逻辑不是更清晰吗这个问题我在动手前也想过但真正写了几轮之后发现手写架构的蔽大于利。LangChain 最大的价值不是模型封装而是工具生态和标准接口。做 Agent 最核心的环节就是让模型调外部工具一个实用的 Agent 可能要对接搜索、数据库、HTTP 接口、文件系统、缓存等各类资源。LangChain 里已经内置了几十种工具的封装从内置的数学计算、天气查询到社区贡献的各种 API 适配器你写几行代码就能接入一个新工具。如果全部自己实现光做接口适配和错误重试就够你忙活一星期。另一个价值是 Model 层的统一抽象。市面上的模型厂家太多了不同家的参数名、返回格式、工具调用协议都有差异。LangChain 把这些差异都抹平了你在 LangChain 里切换底模只需要改一个环境变量整个 Agent 逻辑代码完全不用动。这对实际项目太重要了我在项目中期因为成本问题从贵的模型切到便宜模型整个切换过程没有改一行业务逻辑。不过也要说句公道话LangChain 确实有它烦人的地方。它的版本迭代很快API 变来变去网上教程经常是老版本的写法照着抄跑不起来。我的经验是遇到问题优先看官方文档和当前版本的源码不要把网上代码无脑复制。老教程里的initialize_agent、AgentExecutor在 LangChain 0.2 之后逐渐被 LangGraph 的方式取代很多新人还在抄旧代码自然一脸懵。3.2 LangGraph把Agent从黑盒变成可控流程LangGraph 是 LangChain 团队后来主推的状态驱动框架。它解决的核心问题是把 Agent 的执行流程从“隐式循环”变成“显式图结构”。在传统 LangChain 的 AgentExecutor 里Agent 内部自己决定下一步调什么工具、什么时候停止开发者很难干预每一个中间步骤。你只能看它最终输出什么中间过程一旦出错很难定位和恢复。LangGraph 把流程抽象成节点和边节点代表一个计算单元比如“调用模型”“执行工具”“人工确认”边代表节点之间的跳转条件。整个 Agent 的运行变成了一个可以被人为控制的状态机。这样做有几个实际好处。第一节点级监控。你在每个节点里都可以插入日志、计数、异常捕获能看到任务执行到哪一步、耗时多少、调了多少次工具、积攒了多少上下文。第二断点与恢复。LangGraph 支持在任意节点插入中断比如在调用外部发送大量消息之前插入一个人工审批节点审批通过后才继续执行。这个功能在面向真实用户的场景中非常关键。第三循环控制。图结构本身支持循环边你可以设计一个“最多重试三次”的循环边界避免 Agent 在同一个错误上反复烧钱。我用一个实际例子说明。之前接了一个大量生成内容的项目要求让 Agent 自动去多个站点抓取资料并整理。手写循环的时候经常出现的问题是 Agent 截断、超时、或者陷入工具调用死循环出错之后很难回滚。改成 LangGraph 之后我把整个流程拆成了四个节点节点一规划任务、节点二并行抓取、节点三内容总结、节点四格式校验。每个节点独立捕获异常只要任何一个节点失败图就跳转到重试节点或者退出。线上稳定性明显提升了一个档位。3.3 FastAPI为什么服务层绕不开它Agent 终究要提供服务给外部调用FastAPI 就是目前最顺手的服务层方案。它的好处是三个关键字异步、类型、文档。异步在 Agent 场景里尤其重要因为调度模型、调用外部工具都属于 IO 密集型操作如果同步执行单个请求会长时间占用一个 Worker 线程。FastAPI 原生的 async 支持配合httpx.AsyncClient可以在单个 Worker 上同时跑几十个 Agent 任务的 IO 等待这东西对并发能力的帮助远超加服务器。类型的价值是跟 LangGraph 的 Pydantic 模型无缝对接。Agent 的输入输出如果要做严格的 Schema 校验FastAPI 可以直接拿 Pydantic 模型做请求体和响应体声明开发期少掉一大半的字段错误问题。文档就没什么好说的了FastAPI 自动生成 OpenAPI 文档前端对接和测试都方便。3.4 Rust能做Agent吗搜热词里出现了“基于 Rust 语言 AI Agent”我还专门花了一个周末调研过。结论是可以做但现阶段对大部分开发者不值得。Rust 的优势是高并发和内存安全在 Agent 这种大量 IO 异步调度场景下确实有性能优势。但问题在于 Rust 的生态相比 Python 差得太远。LangChain 和 LangGraph 的 Rust 版本不成熟很多工具链接口还是空的开发一个同样功能的 AgentRust 的耗时可能是 Python 的 3 到 5 倍。我的建议是除非你的核心业务本身就是超低延迟、超高并发的链路并且有成熟的 Rust 团队否则别在 Rust 上死磕 Agent。如果是研究性的项目把它当学习方向没有问题但如果目标是快速落地和迭代Python 依然是第一选择。4. AI Agent怎么扛并发架构思想和线路上限做过 Agent 部署的人都有体感单个 Agent 跑起来没问题一旦同时来几十个请求整个服务就开始变慢、超时、甚至报错。原因不只是服务器的 CPU 不够更多是 Agent 的运行特性决定了它天生比普通接口更容易被打挂。普通 HTTP 接口一般几十毫秒就返回了Agent 一个任务动辄十几秒到几分钟而且期间要多次调用外部的模型和 API。如果不做并发控制系统很容易被拖垮。4.1 无状态与异步扛并发的第一原则Agent 服务要扛并发第一件事是做到“无状态化”。所谓无状态就是指单个请求的 Agent 运行过程不依赖服务进程内存里保存的任何上下文。每一次请求进来都从请求参数和外部存储中重新构建 Agent 的初始状态。任务结束之后把结果写入数据库或者消息队列进程本身不保留任何运行痕迹。为什么必须无状态因为一旦 Agent 把中间状态存在进程内存里就意味着这个请求只能被某个固定实例处理。如果该实例挂了或者被重启整个任务就丢了。而且进程内存会被慢慢堆满最终导致 OOM。无状态设计配合外部的 Redis 或者数据库存状态才能在任意实例上恢复任务也才能水平扩展。实际的架构我一般这样拆请求入口用 FastAPI 接收任务参数立即返回一个 Task ID然后任务进入后台队列异步执行。Agent 在后台跑用户端通过轮询或者 WebSocket 拿结果。这种“同步接收、异步执行”的模式比同步调用扛并发能力强得多。同步调用的意思是用户一直握着连接不放等 Agent 跑完才返回。假设平均任务 30 秒一个 Worker 一分钟只能处理两个请求而异步模式里 Agent 的等待时间不占请求连接平台可以同时接收上千个请求再按队列依次处理。4.2 并发上限到底被什么卡住我实测下来一个 Agent 服务的并发上限通常不是被服务器 CPU 卡住而是被外部依赖卡住。外部依赖主要有三个模型 API 的速率限制、工具 API 的速率限制、数据库连接池上限。模型 API 的速率限制是最容易踩的。几乎所有大模型厂商的服务都有 RPM 和 TPM 限制——RPM 是每分钟请求数TPM 是每分钟 Token 数。如果 Agent 每个任务内部要调用模型 10 次那么 20 个并发任务就是每分钟 200 次模型调用分分钟触发限流。解决思路是在应用层做令牌桶限流和请求排队。我自己写了一个简单的令牌桶把模型调用封装成一个统一的异步入口所有 Agent 的模型调用都走这个入口保证全局 QPS 不超过限制线。工具 API 也一样。有些免费的搜索 API 每分钟只允许 5 次请求如果 Agent 一个任务要搜 3 次那 2 个并发任务都能把它打满。这个问题的解决方式就比较朴素了在每个工具封装里增加一个本地延迟队列或者干脆把容易超限的工具替换成付费的高配额版本。数据库连接池是很多人忽视的坑。我用 LangGraph 做状态持久化的时候每个 Agent 的每一步状态都可能读写一次数据库。默认的 SQLite 连接池在并发几十个时就会出现锁等待。后来我把状态存储迁到了 PostgreSQL配置了合适的连接池大小才彻底解决。4.3 并发架构的参考实现给一个可以直接抄作业的并发架构方案按组件划分如下FastAPI 负责接收 HTTP 请求和参数校验返回 Task ID。Redis 做任务队列用RPUSH放入任务Worker 用LPOP拉取任务。Worker 进程运行 LangGraph 图通过AsyncGraph执行。Redis Stream 或者独立的 Job 表保存运行状态与最终结果。模型 API 调用统一封装内置令牌桶限流和指数退避重试。定时任务负责超时任务清理和失败任务重试。这套架构我跑了快半年单机 8 核 16G 的机器常规的复杂 Agent 任务大概能稳定跑 30 个并发。如果继续加 Worker 进程还可以再往上扩。但这只是参考值真正上线以前还是建议花一天做压测把自己业务里最复杂的任务拎出来跑一下看看平均耗时和外部 API 配额再定并发上限。想特别强调一件事不要为了并发而并发。很多个人项目其实用户量很小一天就几十个请求用最简单的方式反而更省心。我一期项目也冲过并发后来发现真正的问题根本不是扛不住并发而是没有一个用户。部署架构和业务阶段要匹配才行。5. 实操记录用FastAPI LangChain LangGraph搭建能真正干活的Agent这一章我把这一年跑过的最有代表性的项目拿出来拆一遍项目是“让 Agent 自动到小红书和资讯网站搜集指定领域的内容素材整理成结构化选题表”。选择这个项目的原因是它符合一个通用 Agent 的完整链路收到目标、拆解任务、调用搜索工具、总结内容、校验输出。整个过程既有模型调用又有工具调用还有循环重试麻雀虽小五脏俱全。5.1 项目结构和环境准备先看目录结构我的代码仓库里基本是这样组织的agent_project/ ├── app.py # FastAPI入口 ├── agent/ │ ├── graph.py # LangGraph图定义 │ ├── nodes.py # 各节点函数 │ ├── tools.py # 自定义工具集 │ └── state.py # Agent状态模型 ├── core/ │ ├── limiter.py # 令牌桶限流器 │ ├── llm.py # 模型统一入口 │ └── config.py # 配置与常量 ├── worker.py # 异步任务消费进程 └── requirements.txt环境依赖我用的是 Python 3.11装langchain、langgraph、fastapi、uvicorn、httpx、pydantic这几个核心包。版本方面我不写死具体的因为库更新太快建议读者按照官方最新的稳定版本安装。我自己会遇到的最大的坑就是 LangGraph 的 API 变动上一次升级之后StateGraph的构建方式变了导致旧代码大批量报错。后来学聪明了每次升级前先看 Changelog代码里也尽量只用稳定接口。5.2 定义Agent状态LangGraph 的核心是用状态对象串联各个节点。我用的状态模型长这样基于TypedDictfrom typing import TypedDict, List class AgentState(TypedDict): target_topic: str # 用户需求研究什么主题 plan: List[str] # Agent拆解的子任务列表 search_results: List[dict] # 搜索工具返回的结果 draft: str # 中间生成的草稿 final_output: dict # 最终结构化输出 retry_count: int # 当前重试次数这个状态贯穿整个图的执行过程每个节点都能读取和更新任意字段。有一点注意状态字段不要塞太多大文本否则每次状态持久化都要多写很多存储。比如搜索结果我存的是精简过的字段列表完整网页正文只留在节点内部临时变量里用完即弃。5.3 工具封装和限流统一入口工具是 Agent 跟外部世界交互的通道我先说封装原则。所有工具函数的输入输出都必须是 JSON 友好的输入是dict输出也是dict。这样模型生成参数时可以直接用 JSON mode解析也简单。一个搜索工具的例子import httpx from langchain_core.tools import tool tool def search_content(keyword: str, limit: int 5) - list[dict]: 搜索指定关键词的公开网页内容返回标题、来源和摘要 # 实际调用搜索API并做结果裁剪 results [] # ... 省略具体API调用细节 ... return [{title: x[title], url: x[url], summary: x[snippet][:200]} for x in results]每个工具函数内部不要写太多的业务逻辑只做“取数据和格式化输出”两件事。后续要替换数据源也方便。工具本身挂了怎么办我的做法是工具函数内部捕获所有异常返回一个{error: ...}不会让异常直接向外抛。这样 Agent 拿到错误信息后有可能自我纠正比如换一个关键词再搜一次而不是整个任务直接失败。5.4 节点的设计与图编排接下来定义四个节点。第一个节点plan_task把用户给的“主题”拆成三个搜索方向和一份大纲。第二个节点execute_search并行调用工具搜索内容。第三个节点synthesize把搜索结果合并成结构化选题表。第四个节点check_output做最终格式校验不合格就触发重试边。代码大概长这样from langgraph.graph import StateGraph, START, END async def plan_task(state: AgentState) - AgentState: prompt f...将主题 {state[target_topic]} 拆解为具体的搜索子任务... resp await llm.apredict(prompt) state[plan] parse_plan(resp) return state async def execute_search(state: AgentState) - AgentState: results [] for keyword in state[plan]: try: res search_content.invoke({keyword: keyword}) results.extend(res) except Exception: continue state[search_results] deduplicate(results) return state async def synthesize(state: AgentState) - AgentState: # 将搜索结果和计划交给模型生成结构化输出 ... return state async def check_output(state: AgentState) - AgentState: # 校验输出字段是否齐全不合格则 retry_count 1 ... return state graph StateGraph(AgentState) graph.add_node(plan, plan_task) graph.add_node(search, execute_search) graph.add_node(synthesize, synthesize) graph.add_node(check, check_output) graph.add_edge(START, plan) graph.add_edge(plan, search) graph.add_edge(search, synthesize) graph.add_edge(synthesize, check) graph.add_conditional_edges(check, should_retry, {retry: plan, continue: END})这段代码不是能直接跑完整的工程但结构上非常清楚每个节点是一个纯函数输入的是状态输出的也是状态。图把节点串起来边上的跳转条件控制着流程的走向。实际运行时 LangGraph 会把每个节点的返回作为状态的新片段给下一个节点。5.5 为什么要这样设计图我在设计这个四节点图的时候反复考虑过一个问题中间步骤到底该由模型决策还是由代码写死。最后我选择了“主干流程代码写死细节策略模型决策”的混合方式。为什么不全交给模型因为内容搜集这个任务流程是相对固定的如果让模型每一步都决定下一步干嘛会引入很多不确定性和额外的模型调用。多一次决策就多一次模型调用多一次模型调用就多一次 Token 费用。主干流程写死之后整个任务的模型调用次数是可控的成本可预期。为什么不全由代码写死因为搜索的关键词怎么拆、结果怎么组织成选题表这些策略性强的内容需要模型的理解能力。代码强行写规则的话换一个领域语义就失效了。最优方案就是在节点内部让模型做小额决策在节点之间的宏观流程上用代码控制。5.6 异步服务入口的完整逻辑FastAPI 入口我采用“同步接收、异步后台跑”的模式。用户 POST 一个任务服务器立刻返回 Task ID然后把任务塞进 Redis 队列。Worker 进程消费队列跑完把结果写入 Redis 的一个 Hash 中用户侧通过 GET 接口查询。FastAPI 的核心代码如下import redis from fastapi import FastAPI from pydantic import BaseModel r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) app FastAPI() class TaskIn(BaseModel): topic: str app.post(/agent/task) async def create_task(task: TaskIn): task_id str(uuid.uuid4()) r.hset(task:{}.format(task_id), mapping{ status: pending, topic: task.topic, result: }) r.lpush(agent_queue, task_id) return {task_id: task_id, status: pending} app.get(/agent/task/{task_id}) async def get_task(task_id: str): data r.hgetall(task:{}.format(task_id)) if not data: return {error: task not found} return dataWorker 那边用r.brpop(agent_queue)阻塞式取任务取到后调用 LangGraph 的graph.ainvoke(...)。这里有一个实际经验ainvoke内部最好是可中断的。因为一个任务可能跑 30 秒甚至更久如果 Worker 进程被强制重启任务状态就丢了。LangGraph 官方支持持久化把状态存储挂到 PostgreSQL 上可以在进程重启后恢复未完成的任务。这个是进阶功能必要时再上。6. 一年烧钱总结出的高频问题与避坑指南最后这部分是我这一年个人项目里实操性最强的内容。所有的问题我都经历过所以每条都能给出具体的排查思路。按出现频率排了个序新人照着筛一遍能省很多事。6.1 模型调用没有响应卡了很久才超时这个问题的原因多半是网络不稳定或者 API 代理超时。我的排查顺序是先手动执行最简单的补全请求确认网络链路正常如果正常再看是不是限流导致的排队等待如果还不是检查是不是消息数组里塞了太大的图片或文件导致传输变慢。解决的办法是给模型调用统一设置超时和重试。我封装模型入口时固定用了timeout60并加了两次指数退避重试。6.2 Agent陷入工具循环调用疯狂烧钱症状是 Agent 不停调用同一个工具每次结果都一样但模型仍然决定继续调。LangGraph 里我用条件边设置了重试上限超过次数直接强制结束。同时我在工具返回中增加标记字段比如already_searched: true提示模型这个关键词已经搜索过了换一个方向。设置这一点之后死循环出现的概率明显下降了。6.3 输出格式不稳定JSON解析总是报错这个是 LLM 应用永恒的问题。解决方式有几层第一层是 Prompt 里给严格的 JSON 格式样例第二层是用模型的 JSON Mode 或者强制结构化输出参数第三层是写一个健壮的解析函数能够容忍文本内容中夹杂的杂字符最后一层是失败后重试最多重试两次。实测下来四层配合能把格式错误率从 5% 降到 1% 以内。6.4 并发一高就触发限流报429这个问题的解决思路我前面已经讲过。应用层必须自己做令牌桶限流和排队不能依赖上游给你无限配额。同时重试策略必须是退避式的尤其是触发 429 之后不能马上重试否则会把情况搞得更糟。我自己的实现是第一次重试等待 3 秒第二次 9 秒第三次 27 秒超过三次直接标记任务失败避免无限重试。6.5 长上下文导致成本爆炸这个问题是成本侧最常见的高频问题。解决方法就是把历史摘要机制做好。我在 LangGraph 的状态里专门设置了conversation_summary字段每当状态消息数组超过 8000 Token就调用模型把前面的内容压缩成摘要存入该字段然后把消息数组裁剪到只剩最近 3000 Token。实测后长任务成本能降 40% 到 60%。要特别注意的是摘要不能用一次调用就替换全部上下文——模型还需要保留最近几轮详细消息来保持语义连续。6.6 选LangChain还是自己手写前面专门写过一节这里给一个更直白的判断标准如果你的 Agent 只有一种固定工作流且不需要复杂工具生态手写完全可以代码反而更清爽。如果你要对接多种工具、需要流程控制、或者经常切换模型直接用 LangGraph。这不是技术崇拜的问题而是工程效率的问题。我的建议是两条路都熟悉一下然后在实际项目中灵活选择。6.7 给新人的学习路线参考搜热词里有“AI Agent学习路线”我结合自己的折腾经验给一个排序。第一步先熟悉 LangChain 的基础组件一边看文档一边写几个调用模型和工具的小例子。第二步学 LangGraph 的 StateGraph能做简单的两节点图。第三步把 FastAPI 接进来做一个有 HTTP 接口的最小 Agent。第四步加 Redis 和异步队列把并发和任务状态管理做起来。最后一步才是上多 Agent 协作、记忆系统、复杂工具链这些进阶功能。很多人一上来就想着搭一个多 Agent 编排系统我劝你先别。多 Agent 协作的调试成本是指数级上升的你不知道哪个 Agent 在哪个环节给出了错误结果排查起来极其痛苦。先从一个 Agent 把单任务链路跑通跑稳了再做扩展才是正道。个人在实际使用中最深的体会有两个。第一个是不要追求架构的完美先追求任务成功率。一个能不烧钱、稳定跑完任务的简单 Agent比一个花哨但偶尔失控的复杂系统有价值得多。第二个是成本意识必须在设计阶段就进入不要等功能上线了再回头来做压缩和限流。我前期烧掉的钱里至少有一半可以省下来。写这篇文章就当是给大家交点学费的实录你照着做能少走不少弯路。