1. 从热榜前五看 AI agent 的“地基焦虑”9 月 22 日这天的 GitHub Trending 榜单一出来我第一反应是这届开发者是真的在给 AI agent 打地基而不是在造花架子。前 5 名里 3 个项目都跟 agent 的底层能力直接相关——要么是让 agent 能记住东西要么是让 agent 能调用工具要么是让 agent 能自己规划任务。这个信号非常明确AI agent 已经从“能聊天”进入“能干活”的阶段而能干活的前提是地基得稳。我自己从去年开始陆续搭过几个 agent 项目踩过的坑基本都集中在“地基”上上下文一长就失忆、工具调用一多就乱套、任务一复杂就死循环。所以看到这期热榜我特别有共鸣。这篇文章不打算复述榜单而是想借这几个项目的思路把 AI agent 的地基到底该怎么打从架构选型到实操落地完整拆一遍。不管你是刚听说 agent 想练手还是已经在做 agent 中台应该都能从里面找到能直接抄作业的部分。先明确一下这篇文章适合谁看如果你只是想用现成的 agent 产品那看个热闹就行但如果你想自己从 0 到 1 搭一个能真正下地干活的 agent或者想理解为什么有些 agent 项目跑着跑着就崩了那这篇值得你花时间。我会尽量用大白话把原理讲清楚同时给出可以直接复现的代码和配置。2. 为什么这期热榜值得单独拿出来说2.1 三个“地基型”项目到底在解决什么问题热榜前 5 里那 3 个跟 agent 相关的项目虽然具体功能不同但指向的是同一个问题agent 的可靠性。一个 agent 要能干活至少得具备三种能力——记忆、工具调用、任务规划。这三样缺一个agent 就只能停留在 demo 阶段。记忆解决的是“它记得住吗”。你让 agent 帮你处理一个多步骤任务它得记住前面发生了什么不然每一步都从零开始任务根本没法推进。工具调用解决的是“它能动手吗”。光会说话没用得能查数据库、发请求、写文件。任务规划解决的是“它知道先干啥吗”。复杂任务得拆成子任务还得知道哪个先做、哪个依赖哪个。这三个能力听起来简单但真做起来每一个都是坑。记忆做不好就是“上下文爆炸”工具调用做不好就是“参数乱传”任务规划做不好就是“无限循环”。热榜上这几个项目本质上都是在用工程手段把这些坑填上。2.2 从“能聊”到“能干活”的分水岭我观察到一个很明显的分水岭2024 年之前的 agent 项目大部分是在证明“agent 能聊天”2024 年之后尤其是最近这几个月大家开始认真解决“agent 能干活”。这个转变背后是需求驱动的——企业不想再要一个只会说“我理解你的需求”的机器人他们要的是能真正把活干完的东西。这个分水岭对开发者的影响是技术栈变了。以前搞个 agent调个 API 加个 prompt 就完事现在得考虑状态管理、工具注册、错误重试、并发控制。这也是为什么热榜上这些“地基型”项目会火——大家都在找能直接用的轮子不想重复造。2.3 对普通开发者的实际影响你可能会想这些底层项目跟我有什么关系我又不去造框架。关系很大。因为框架的选型直接决定你搭 agent 的难度和上限。选对了地基你搭 agent 就是搭积木选错了你就是在流沙上盖楼。举个例子如果你用 LangChain 那套东西工具调用和记忆管理它都帮你封装好了你只需要关注业务逻辑。但如果你自己从零写光是处理工具调用的参数解析和错误重试就能耗掉你一周。所以理解这些地基项目在做什么能帮你在选型的时候少走弯路。3. AI agent 地基的三大核心能力拆解3.1 记忆能力让 agent 不再“金鱼脑”记忆这块很多人第一反应是“把历史对话全塞进上下文不就行了”。我一开始也这么干结果就是 token 烧得飞快而且模型在长上下文里反而容易忽略关键信息。后来我才明白记忆不是“存得多”而是“取得准”。目前主流的记忆方案分三层短期记忆、长期记忆、工作记忆。短期记忆就是当前对话的上下文一般用滑动窗口控制长度长期记忆是跨会话的通常存到向量数据库里需要的时候检索工作记忆是任务执行过程中的临时状态比如“当前执行到第几步”“上一步的输出是什么”。我实测下来最稳的组合是短期记忆用滑动窗口 摘要压缩长期记忆用向量检索工作记忆用结构化存储比如 JSON 或者 Redis。这样既能控制 token 消耗又能保证关键信息不丢。注意不要把所有历史都塞进向量库。向量检索是有噪声的存得越多检索出来的东西越杂。我的经验是只存“结论性”的内容比如用户偏好、任务结果而不是每一句对话。3.2 工具调用agent 的“手”怎么长出来工具调用是 agent 从“嘴炮”变成“实干”的关键。原理其实不复杂你把可用的工具用 JSON Schema 描述清楚模型根据用户需求决定调哪个工具、传什么参数然后你的代码去执行再把结果喂回给模型。但坑在于模型经常传错参数。比如你定义了一个search_flights(origin, destination, date)模型可能把日期格式传成“明天”而不是“2024-09-23”。解决办法有两个一是在工具描述里把参数格式写死二是加一层参数校验和自动修正。# 工具定义示例用 Pydantic 做参数校验 from pydantic import BaseModel, Field, validator from datetime import datetime class SearchFlightsArgs(BaseModel): origin: str Field(..., description出发城市如北京) destination: str Field(..., description到达城市如上海) date: str Field(..., description出发日期格式 YYYY-MM-DD) validator(date) def validate_date(cls, v): try: datetime.strptime(v, %Y-%m-%d) except ValueError: raise ValueError(日期格式必须是 YYYY-MM-DD) return v这样即使模型传错了你也能在代码层拦住而不是让错误一路传下去。3.3 任务规划从“一步一指令”到“自己拆活”任务规划是 agent 最像“智能”的部分也是最容易翻车的地方。最简单的规划是 ReAct 模式想一步、做一步、看结果、再想下一步。这个模式适合简单任务但复杂任务容易绕圈子。进阶一点的是 Plan-and-Execute先让模型把任务拆成子任务列表然后逐个执行。这个模式的好处是全局视角清晰坏处是如果第一步就拆错了后面全错。我一般会加一个“反思”步骤让模型在执行完每个子任务后检查一下是否偏离目标。# Plan-and-Execute 的简化伪代码 def plan_and_execute(task): plan llm.generate_plan(task) # 拆解任务 results [] for step in plan.steps: result execute_step(step, contextresults) results.append(result) if not verify(result, task): # 反思 plan llm.replan(task, results) # 重新规划 return results实操心得规划步骤不要超过 7 步。超过 7 步模型很容易在中途迷失目标。如果任务确实复杂就分层拆解先拆成 3-5 个大阶段每个阶段再拆子任务。4. 从 0 到 1 搭建一个能扛并发的 agent 服务4.1 技术选型为什么是 FastAPI LangChain LangGraph这套组合是我目前用得最顺手的。FastAPI 负责 HTTP 层性能好、异步支持完善LangChain 负责工具调用和模型交互的封装LangGraph 负责状态管理和流程编排。三者分工明确不会互相打架。选 LangGraph 而不是自己写状态机主要是因为 agent 的执行流程经常需要“回退”和“分支”。比如工具调用失败了要重试任务规划错了要重新规划。自己写状态机不是不行但 LangGraph 把这些模式都封装好了省事。4.2 并发处理agent 怎么扛住高并发agent 扛并发难点不在 HTTP 层而在模型调用和工具调用的资源管理。模型调用是 IO 密集型的用异步就能扛工具调用如果是查数据库或者调外部 API也是 IO 密集型同样用异步。真正的瓶颈是状态管理——如果多个请求共享同一个 agent 实例状态就会串。我的做法是每个请求创建一个独立的 agent 实例状态存在请求级别的上下文里。如果要用共享资源比如向量库连接池就用连接池管理不要每个请求都新建连接。# FastAPI 异步 agent 的简化示例 from fastapi import FastAPI from langgraph.graph import StateGraph import asyncio app FastAPI() app.post(/agent/run) async def run_agent(request: AgentRequest): # 每个请求独立的状态 state {messages: [], task: request.task} # 异步执行不阻塞事件循环 result await asyncio.to_thread(agent_graph.invoke, state) return {result: result}注意asyncio.to_thread只适合 CPU 密集度不高的场景。如果 agent 内部有大量计算建议用独立的 worker 进程通过消息队列解耦。4.3 状态管理LangGraph 的 State 怎么设计LangGraph 的 State 是整个 agent 的“记忆中枢”。我一般会设计这几个字段messages对话历史、task当前任务、plan任务规划、results子任务结果、error错误信息。这样在任何一个节点都能拿到完整的上下文。State 的设计原则是能结构化就结构化不要全塞字符串。比如plan用列表而不是一段文本这样后续节点可以直接遍历不用再解析。4.4 完整代码骨架与关键配置from langgraph.graph import StateGraph, END from typing import TypedDict, List class AgentState(TypedDict): messages: List[dict] task: str plan: List[str] results: List[str] error: str def planner_node(state: AgentState): # 调用模型生成计划 plan llm.invoke(f把任务拆成步骤{state[task]}) return {plan: plan} def executor_node(state: AgentState): # 执行当前步骤 step state[plan][0] result execute_tool(step) return {results: state[results] [result], plan: state[plan][1:]} def should_continue(state: AgentState): if state[plan]: return executor return END graph StateGraph(AgentState) graph.add_node(planner, planner_node) graph.add_node(executor, executor_node) graph.set_entry_point(planner) graph.add_conditional_edges(planner, should_continue) graph.add_conditional_edges(executor, should_continue) agent graph.compile()这套骨架跑通之后你只需要往execute_tool里填具体的工具实现就能扩展出各种 agent。5. 实操过程中最容易踩的五个坑5.1 上下文爆炸token 烧得比想象中快我第一个 agent 项目上线第一天就烧掉了预算的一半。原因就是每轮对话都把完整历史塞进去token 消耗是 O(n²) 增长的。后来改成滑动窗口 摘要token 消耗直接降了 70%。具体做法保留最近 5 轮完整对话更早的对话用模型压缩成一段摘要。摘要只保留“用户意图”和“关键结论”不保留过程。5.2 工具调用死循环agent 卡在同一个工具上这个坑我踩过两次。一次是工具一直返回错误agent 就一直重试另一次是 agent 在两个工具之间来回跳。解决办法是加最大重试次数和循环检测。如果同一个工具连续调用 3 次都失败就中断并报错如果检测到两个工具交替调用超过 5 次就强制退出。5.3 模型幻觉agent 编造不存在的工具模型有时候会“发明”一个你没定义的工具然后一本正经地调用。这个问题的根源是工具描述不够清晰。我的经验是在系统提示里明确列出所有可用工具并且强调“只能调用列表中的工具”。另外在代码层加一层校验如果模型调用了不存在的工具直接返回错误让它重新选。5.4 并发下的状态污染这个坑最隐蔽。我一开始用全局变量存 agent 状态单机测试没问题一上并发就乱套。后来改成每个请求独立状态问题解决。如果你用的是 LangGraph注意compile()出来的 graph 是无状态的状态是每次invoke时传入的所以天然支持并发。5.5 错误处理agent 崩了怎么优雅降级agent 执行过程中可能出各种错模型超时、工具报错、参数校验失败。我的做法是分层处理参数错误直接返回给模型让它重试工具错误记录日志并返回友好提示模型超时则降级到备用模型或者直接返回“稍后再试”。问题类型表现排查思路解决方案上下文爆炸token 消耗异常高检查历史消息长度滑动窗口 摘要压缩工具死循环agent 卡住不返回看日志里工具调用次数最大重试 循环检测模型幻觉调用不存在的工具检查工具列表和提示提示明确 代码校验状态污染并发下结果串了检查状态是否共享请求级独立状态错误未处理agent 直接崩看异常堆栈分层错误处理 降级6. 这套地基还能怎么扩展6.1 接入更多工具从“能查”到“能改”现在这套骨架只支持查询类工具如果要让 agent 能“改”东西比如写数据库、发邮件需要加一层权限校验和操作确认。我的做法是危险操作先让 agent 生成操作计划人工确认后再执行。这样既保留了自动化又不会出大乱子。6.2 多 agent 协作让专业的人干专业的事单个 agent 能力有限复杂任务可以拆给多个 agent。比如一个“调研 agent”负责搜集信息一个“分析 agent”负责处理数据一个“写作 agent”负责输出报告。LangGraph 支持多 agent 编排每个 agent 是一个子图通过共享状态通信。6.3 可观测性agent 跑起来之后怎么监控agent 上线之后你得知道它跑得怎么样。我一般会记录这几个指标每次任务的 token 消耗、工具调用次数、任务成功率、平均执行时长。这些数据能帮你发现瓶颈比如某个工具特别慢或者某类任务特别容易失败。6.4 成本控制token 烧钱怎么省省 token 的核心是“能不用模型就不用模型”。比如参数校验、格式转换这些确定性操作直接用代码做不要交给模型。另外简单任务用便宜的小模型复杂任务才用大模型。我实测下来这样能省 50% 以上的成本。7. 我个人在实际操作中的几点体会搭 agent 这件事最忌讳的就是一上来就追求“全自动”。我见过太多项目一开始就想让 agent 端到端搞定一切结果就是各种不可控。我的建议是先从“半自动”开始让 agent 做它擅长的部分人做兜底。等 agent 在某个环节稳定了再逐步扩大它的权限。另外不要迷信框架。LangChain、LangGraph 这些工具确实能省事但它们的抽象层也会带来调试困难。我一般会在关键节点加日志把模型的输入输出都打出来这样出问题的时候能快速定位。最后说一个很实在的点agent 的价值不在于它多智能而在于它多可靠。一个能稳定完成 80% 任务的 agent比一个偶尔能完成 100% 但经常崩的 agent 有用得多。所以地基这件事值得花时间打好。 AI agent 地基实战：记忆、工具调用与任务规划从 0 到 1
1. 从热榜前五看 AI agent 的“地基焦虑”9 月 22 日这天的 GitHub Trending 榜单一出来我第一反应是这届开发者是真的在给 AI agent 打地基而不是在造花架子。前 5 名里 3 个项目都跟 agent 的底层能力直接相关——要么是让 agent 能记住东西要么是让 agent 能调用工具要么是让 agent 能自己规划任务。这个信号非常明确AI agent 已经从“能聊天”进入“能干活”的阶段而能干活的前提是地基得稳。我自己从去年开始陆续搭过几个 agent 项目踩过的坑基本都集中在“地基”上上下文一长就失忆、工具调用一多就乱套、任务一复杂就死循环。所以看到这期热榜我特别有共鸣。这篇文章不打算复述榜单而是想借这几个项目的思路把 AI agent 的地基到底该怎么打从架构选型到实操落地完整拆一遍。不管你是刚听说 agent 想练手还是已经在做 agent 中台应该都能从里面找到能直接抄作业的部分。先明确一下这篇文章适合谁看如果你只是想用现成的 agent 产品那看个热闹就行但如果你想自己从 0 到 1 搭一个能真正下地干活的 agent或者想理解为什么有些 agent 项目跑着跑着就崩了那这篇值得你花时间。我会尽量用大白话把原理讲清楚同时给出可以直接复现的代码和配置。2. 为什么这期热榜值得单独拿出来说2.1 三个“地基型”项目到底在解决什么问题热榜前 5 里那 3 个跟 agent 相关的项目虽然具体功能不同但指向的是同一个问题agent 的可靠性。一个 agent 要能干活至少得具备三种能力——记忆、工具调用、任务规划。这三样缺一个agent 就只能停留在 demo 阶段。记忆解决的是“它记得住吗”。你让 agent 帮你处理一个多步骤任务它得记住前面发生了什么不然每一步都从零开始任务根本没法推进。工具调用解决的是“它能动手吗”。光会说话没用得能查数据库、发请求、写文件。任务规划解决的是“它知道先干啥吗”。复杂任务得拆成子任务还得知道哪个先做、哪个依赖哪个。这三个能力听起来简单但真做起来每一个都是坑。记忆做不好就是“上下文爆炸”工具调用做不好就是“参数乱传”任务规划做不好就是“无限循环”。热榜上这几个项目本质上都是在用工程手段把这些坑填上。2.2 从“能聊”到“能干活”的分水岭我观察到一个很明显的分水岭2024 年之前的 agent 项目大部分是在证明“agent 能聊天”2024 年之后尤其是最近这几个月大家开始认真解决“agent 能干活”。这个转变背后是需求驱动的——企业不想再要一个只会说“我理解你的需求”的机器人他们要的是能真正把活干完的东西。这个分水岭对开发者的影响是技术栈变了。以前搞个 agent调个 API 加个 prompt 就完事现在得考虑状态管理、工具注册、错误重试、并发控制。这也是为什么热榜上这些“地基型”项目会火——大家都在找能直接用的轮子不想重复造。2.3 对普通开发者的实际影响你可能会想这些底层项目跟我有什么关系我又不去造框架。关系很大。因为框架的选型直接决定你搭 agent 的难度和上限。选对了地基你搭 agent 就是搭积木选错了你就是在流沙上盖楼。举个例子如果你用 LangChain 那套东西工具调用和记忆管理它都帮你封装好了你只需要关注业务逻辑。但如果你自己从零写光是处理工具调用的参数解析和错误重试就能耗掉你一周。所以理解这些地基项目在做什么能帮你在选型的时候少走弯路。3. AI agent 地基的三大核心能力拆解3.1 记忆能力让 agent 不再“金鱼脑”记忆这块很多人第一反应是“把历史对话全塞进上下文不就行了”。我一开始也这么干结果就是 token 烧得飞快而且模型在长上下文里反而容易忽略关键信息。后来我才明白记忆不是“存得多”而是“取得准”。目前主流的记忆方案分三层短期记忆、长期记忆、工作记忆。短期记忆就是当前对话的上下文一般用滑动窗口控制长度长期记忆是跨会话的通常存到向量数据库里需要的时候检索工作记忆是任务执行过程中的临时状态比如“当前执行到第几步”“上一步的输出是什么”。我实测下来最稳的组合是短期记忆用滑动窗口 摘要压缩长期记忆用向量检索工作记忆用结构化存储比如 JSON 或者 Redis。这样既能控制 token 消耗又能保证关键信息不丢。注意不要把所有历史都塞进向量库。向量检索是有噪声的存得越多检索出来的东西越杂。我的经验是只存“结论性”的内容比如用户偏好、任务结果而不是每一句对话。3.2 工具调用agent 的“手”怎么长出来工具调用是 agent 从“嘴炮”变成“实干”的关键。原理其实不复杂你把可用的工具用 JSON Schema 描述清楚模型根据用户需求决定调哪个工具、传什么参数然后你的代码去执行再把结果喂回给模型。但坑在于模型经常传错参数。比如你定义了一个search_flights(origin, destination, date)模型可能把日期格式传成“明天”而不是“2024-09-23”。解决办法有两个一是在工具描述里把参数格式写死二是加一层参数校验和自动修正。# 工具定义示例用 Pydantic 做参数校验 from pydantic import BaseModel, Field, validator from datetime import datetime class SearchFlightsArgs(BaseModel): origin: str Field(..., description出发城市如北京) destination: str Field(..., description到达城市如上海) date: str Field(..., description出发日期格式 YYYY-MM-DD) validator(date) def validate_date(cls, v): try: datetime.strptime(v, %Y-%m-%d) except ValueError: raise ValueError(日期格式必须是 YYYY-MM-DD) return v这样即使模型传错了你也能在代码层拦住而不是让错误一路传下去。3.3 任务规划从“一步一指令”到“自己拆活”任务规划是 agent 最像“智能”的部分也是最容易翻车的地方。最简单的规划是 ReAct 模式想一步、做一步、看结果、再想下一步。这个模式适合简单任务但复杂任务容易绕圈子。进阶一点的是 Plan-and-Execute先让模型把任务拆成子任务列表然后逐个执行。这个模式的好处是全局视角清晰坏处是如果第一步就拆错了后面全错。我一般会加一个“反思”步骤让模型在执行完每个子任务后检查一下是否偏离目标。# Plan-and-Execute 的简化伪代码 def plan_and_execute(task): plan llm.generate_plan(task) # 拆解任务 results [] for step in plan.steps: result execute_step(step, contextresults) results.append(result) if not verify(result, task): # 反思 plan llm.replan(task, results) # 重新规划 return results实操心得规划步骤不要超过 7 步。超过 7 步模型很容易在中途迷失目标。如果任务确实复杂就分层拆解先拆成 3-5 个大阶段每个阶段再拆子任务。4. 从 0 到 1 搭建一个能扛并发的 agent 服务4.1 技术选型为什么是 FastAPI LangChain LangGraph这套组合是我目前用得最顺手的。FastAPI 负责 HTTP 层性能好、异步支持完善LangChain 负责工具调用和模型交互的封装LangGraph 负责状态管理和流程编排。三者分工明确不会互相打架。选 LangGraph 而不是自己写状态机主要是因为 agent 的执行流程经常需要“回退”和“分支”。比如工具调用失败了要重试任务规划错了要重新规划。自己写状态机不是不行但 LangGraph 把这些模式都封装好了省事。4.2 并发处理agent 怎么扛住高并发agent 扛并发难点不在 HTTP 层而在模型调用和工具调用的资源管理。模型调用是 IO 密集型的用异步就能扛工具调用如果是查数据库或者调外部 API也是 IO 密集型同样用异步。真正的瓶颈是状态管理——如果多个请求共享同一个 agent 实例状态就会串。我的做法是每个请求创建一个独立的 agent 实例状态存在请求级别的上下文里。如果要用共享资源比如向量库连接池就用连接池管理不要每个请求都新建连接。# FastAPI 异步 agent 的简化示例 from fastapi import FastAPI from langgraph.graph import StateGraph import asyncio app FastAPI() app.post(/agent/run) async def run_agent(request: AgentRequest): # 每个请求独立的状态 state {messages: [], task: request.task} # 异步执行不阻塞事件循环 result await asyncio.to_thread(agent_graph.invoke, state) return {result: result}注意asyncio.to_thread只适合 CPU 密集度不高的场景。如果 agent 内部有大量计算建议用独立的 worker 进程通过消息队列解耦。4.3 状态管理LangGraph 的 State 怎么设计LangGraph 的 State 是整个 agent 的“记忆中枢”。我一般会设计这几个字段messages对话历史、task当前任务、plan任务规划、results子任务结果、error错误信息。这样在任何一个节点都能拿到完整的上下文。State 的设计原则是能结构化就结构化不要全塞字符串。比如plan用列表而不是一段文本这样后续节点可以直接遍历不用再解析。4.4 完整代码骨架与关键配置from langgraph.graph import StateGraph, END from typing import TypedDict, List class AgentState(TypedDict): messages: List[dict] task: str plan: List[str] results: List[str] error: str def planner_node(state: AgentState): # 调用模型生成计划 plan llm.invoke(f把任务拆成步骤{state[task]}) return {plan: plan} def executor_node(state: AgentState): # 执行当前步骤 step state[plan][0] result execute_tool(step) return {results: state[results] [result], plan: state[plan][1:]} def should_continue(state: AgentState): if state[plan]: return executor return END graph StateGraph(AgentState) graph.add_node(planner, planner_node) graph.add_node(executor, executor_node) graph.set_entry_point(planner) graph.add_conditional_edges(planner, should_continue) graph.add_conditional_edges(executor, should_continue) agent graph.compile()这套骨架跑通之后你只需要往execute_tool里填具体的工具实现就能扩展出各种 agent。5. 实操过程中最容易踩的五个坑5.1 上下文爆炸token 烧得比想象中快我第一个 agent 项目上线第一天就烧掉了预算的一半。原因就是每轮对话都把完整历史塞进去token 消耗是 O(n²) 增长的。后来改成滑动窗口 摘要token 消耗直接降了 70%。具体做法保留最近 5 轮完整对话更早的对话用模型压缩成一段摘要。摘要只保留“用户意图”和“关键结论”不保留过程。5.2 工具调用死循环agent 卡在同一个工具上这个坑我踩过两次。一次是工具一直返回错误agent 就一直重试另一次是 agent 在两个工具之间来回跳。解决办法是加最大重试次数和循环检测。如果同一个工具连续调用 3 次都失败就中断并报错如果检测到两个工具交替调用超过 5 次就强制退出。5.3 模型幻觉agent 编造不存在的工具模型有时候会“发明”一个你没定义的工具然后一本正经地调用。这个问题的根源是工具描述不够清晰。我的经验是在系统提示里明确列出所有可用工具并且强调“只能调用列表中的工具”。另外在代码层加一层校验如果模型调用了不存在的工具直接返回错误让它重新选。5.4 并发下的状态污染这个坑最隐蔽。我一开始用全局变量存 agent 状态单机测试没问题一上并发就乱套。后来改成每个请求独立状态问题解决。如果你用的是 LangGraph注意compile()出来的 graph 是无状态的状态是每次invoke时传入的所以天然支持并发。5.5 错误处理agent 崩了怎么优雅降级agent 执行过程中可能出各种错模型超时、工具报错、参数校验失败。我的做法是分层处理参数错误直接返回给模型让它重试工具错误记录日志并返回友好提示模型超时则降级到备用模型或者直接返回“稍后再试”。问题类型表现排查思路解决方案上下文爆炸token 消耗异常高检查历史消息长度滑动窗口 摘要压缩工具死循环agent 卡住不返回看日志里工具调用次数最大重试 循环检测模型幻觉调用不存在的工具检查工具列表和提示提示明确 代码校验状态污染并发下结果串了检查状态是否共享请求级独立状态错误未处理agent 直接崩看异常堆栈分层错误处理 降级6. 这套地基还能怎么扩展6.1 接入更多工具从“能查”到“能改”现在这套骨架只支持查询类工具如果要让 agent 能“改”东西比如写数据库、发邮件需要加一层权限校验和操作确认。我的做法是危险操作先让 agent 生成操作计划人工确认后再执行。这样既保留了自动化又不会出大乱子。6.2 多 agent 协作让专业的人干专业的事单个 agent 能力有限复杂任务可以拆给多个 agent。比如一个“调研 agent”负责搜集信息一个“分析 agent”负责处理数据一个“写作 agent”负责输出报告。LangGraph 支持多 agent 编排每个 agent 是一个子图通过共享状态通信。6.3 可观测性agent 跑起来之后怎么监控agent 上线之后你得知道它跑得怎么样。我一般会记录这几个指标每次任务的 token 消耗、工具调用次数、任务成功率、平均执行时长。这些数据能帮你发现瓶颈比如某个工具特别慢或者某类任务特别容易失败。6.4 成本控制token 烧钱怎么省省 token 的核心是“能不用模型就不用模型”。比如参数校验、格式转换这些确定性操作直接用代码做不要交给模型。另外简单任务用便宜的小模型复杂任务才用大模型。我实测下来这样能省 50% 以上的成本。7. 我个人在实际操作中的几点体会搭 agent 这件事最忌讳的就是一上来就追求“全自动”。我见过太多项目一开始就想让 agent 端到端搞定一切结果就是各种不可控。我的建议是先从“半自动”开始让 agent 做它擅长的部分人做兜底。等 agent 在某个环节稳定了再逐步扩大它的权限。另外不要迷信框架。LangChain、LangGraph 这些工具确实能省事但它们的抽象层也会带来调试困难。我一般会在关键节点加日志把模型的输入输出都打出来这样出问题的时候能快速定位。最后说一个很实在的点agent 的价值不在于它多智能而在于它多可靠。一个能稳定完成 80% 任务的 agent比一个偶尔能完成 100% 但经常崩的 agent 有用得多。所以地基这件事值得花时间打好。