从LLM到Agent：核心循环、工具调用与记忆管理实战-北京尧图网络

1. 从会聊天的模型到能办事的系统Agent到底在解决什么问题很多人第一次接触Agent这个概念脑子里冒出来的画面是一个更聪明的聊天机器人。这个理解不算错但差得有点远。聊天机器人解决的是信息问答问题你问它答一轮结束而Agent解决的是任务执行问题——你给它一个目标它自己拆解步骤、调用工具、观察结果、调整策略直到把事办完或者确认办不了。这两者的差距不是模型参数量的差距而是系统架构的差距。我刚开始做Agent项目的时候踩过一个很典型的坑把一个能力不错的LLM直接接上几个工具函数就以为这就是Agent了。结果发现它经常在第一步就卡住——不知道该先干什么或者干了两步就忘了最初的目标。后来才明白LLM只是Agent的大脑但光有大脑没有手脚和记忆它什么也办不成。Agent的本质是一个围绕LLM构建的闭环系统这个闭环至少包含四个部分推理决策、工具调用、记忆管理、循环控制。这篇文章想做的事情是把Agent这个被各种框架和概念包装得越来越复杂的东西拆开来看清楚。我会从核心循环机制讲起然后逐个拆解工具调用、记忆管理、并发处理这些实际开发中绕不开的问题最后聊聊框架选型和落地时的真实经验。不管你是刚听说Agent想入门还是已经在写Agent代码但总觉得哪里不对劲希望这些内容能帮你把脑子里那团乱麻理清楚。提示本文讨论的Agent指的是基于大语言模型构建的、具备自主任务执行能力的软件系统不涉及任何特定厂商或平台的专有实现。2. Agent的核心循环机制它到底是怎么想和做的2.1 ReAct范式推理与行动的交替循环Agent最基础的运行模式叫ReAct全称是Reasoning and Acting。这个名字听起来学术但逻辑特别朴素让模型先想一步再做一步看看结果再想下一步。就像你让一个实习生去订会议室他不会闷头直接冲过去而是先想我需要知道哪个会议室有空然后去查查到之后再想这个时间合适吗然后去确认如此往复。具体到代码层面一个最简化的ReAct循环长这样def agent_loop(task, tools, max_steps10): history [{role: user, content: task}] for step in range(max_steps): # 1. 让LLM基于当前历史做推理决定下一步 response llm.chat(history, toolstools) # 2. 如果模型认为任务完成直接返回 if response.is_final_answer: return response.content # 3. 否则执行模型选择的工具 tool_name response.tool_call.name tool_args response.tool_call.arguments observation tools[tool_name].run(**tool_args) # 4. 把工具结果塞回历史进入下一轮 history.append(response.message) history.append({role: tool, content: observation}) return 达到最大步数限制任务未完成这段代码看起来简单但里面藏着几个关键设计决策。max_steps这个参数不是随便设的设太小任务做不完设太大一旦模型陷入死循环就是烧钱。我一般会根据任务复杂度设5到15之间同时在循环里加一个重复动作检测——如果模型连续两次调用同一个工具、传同样的参数直接中断并让它重新规划。2.2 循环终止条件比你想的要复杂新手最容易忽略的就是什么时候停。表面上看模型说我完成了就停呗。但实际跑起来你会发现模型经常在任务没完成的时候就说完成了或者明明完成了还在那儿瞎折腾。所以终止条件得设计成多层判断显式完成信号模型明确输出最终答案且答案里不包含待办事项步数上限硬性熔断防止无限循环重复检测连续N步动作高度相似判定为卡死错误累积连续多次工具调用失败判定为环境问题提前退出超时控制整个任务设置wall-clock时间上限我见过一个真实案例某个Agent在调用搜索工具时因为返回结果格式和预期不符模型反复重试了四十多次每次都在微调查询词最后账单直接爆了。如果当时加了重复检测和错误累积判断这个问题在第五步就能被发现。2.3 从ReAct到Plan-and-Execute什么时候该换模式ReAct适合步骤不多、每步依赖上一步结果的任务。但如果你让Agent做调研十个竞品并生成对比报告这种任务ReAct就会显得很笨——它每做一步都要重新想全局效率低还容易跑偏。这时候就该上Plan-and-Execute模式了先让模型生成一个完整的执行计划然后按计划逐步执行执行过程中允许局部调整。这个模式的好处是全局视野清晰坏处是计划一旦定错后面全错。所以我的经验是计划生成阶段用能力最强的模型执行阶段可以用便宜一些的模型这样既保证规划质量又控制成本。模式适用场景优点缺点ReAct步骤少、强依赖中间结果灵活、容错好全局视野弱、易跑偏Plan-and-Execute步骤多、结构清晰全局清晰、成本可控计划错误代价大混合模式复杂长任务兼顾灵活与全局实现复杂度高实际项目中我更多用的是混合模式先出一个粗粒度计划每个计划步骤内部用ReAct执行。这样既有全局方向又保留了局部灵活性。3. 工具调用Agent的手脚怎么接才不出事3.1 工具描述的质量决定调用成功率工具调用这块最大的坑不在代码在工具描述。很多人写工具定义的时候就写一句search: 搜索信息然后纳闷为什么模型总是传错参数。你得站在模型的角度想它只能看到你给的描述描述不清楚它就只能猜。一个好的工具描述应该包含这个工具做什么、什么时候该用、什么时候不该用、每个参数的含义和格式、返回结果的结构。举个例子{ name: search_flights, description: 查询指定日期和航线之间的航班信息。当用户需要预订机票或查询航班时刻时使用。不适用于查询火车票或酒店。, parameters: { departure: 出发城市的三字码如北京是BJS, arrival: 到达城市的三字码如上海是SHA, date: 出发日期格式YYYY-MM-DD, max_results: 返回结果数量上限默认5最大20 } }对比一下search: 搜索航班这种描述调用成功率能差出一大截。描述里明确写出不适用于什么能显著减少误调用这是我从多次调试中总结出来的。3.2 参数校验与错误回传让Agent自己纠错工具执行前一定要做参数校验但校验失败后怎么处理很关键。直接抛异常让整个流程崩掉是最差的做法。正确的方式是把错误信息结构化地回传给模型让它自己修正。比如模型传了个日期2024-13-45工具返回{ error: INVALID_DATE, message: 日期格式应为YYYY-MM-DD且月份需在01-12之间您提供的月份13无效, suggestion: 请检查日期并重新提供 }模型看到这个大概率下一轮就能传对。我实测下来带suggestion字段的错误回传能让模型自我纠错的成功率提升不少。相反如果只返回参数错误四个字模型往往不知道该改什么容易反复试错。3.3 工具粒度太粗和太细都是灾难工具设计有个粒度问题。工具太粗比如一个处理订单工具包揽所有订单操作模型很难用对工具太细比如把查询订单拆成按ID查按手机号查按时间查三个工具模型又容易选错。我的经验法则是一个工具对应一个明确的动作意图参数控制在3到5个以内。如果一个工具的参数超过7个基本可以考虑拆分了。另外工具之间最好有清晰的边界不要出现两个工具功能高度重叠的情况那会让模型陷入选择困难。注意工具数量不是越多越好。我做过一个测试当工具数量从10个增加到30个时模型选错工具的概率明显上升。如果确实需要大量工具建议做一层工具路由先让模型选工具类别再在类别内选具体工具。4. 记忆管理Agent的记性该怎么设计4.1 短期记忆与长期记忆的分工Agent的记忆分两层。短期记忆就是当前任务的对话历史存在上下文窗口里任务结束就清掉。长期记忆是跨任务保留的信息比如用户偏好、历史交互记录需要持久化存储。短期记忆的管理核心是上下文窗口有限怎么塞最有用的信息。我的做法是分层保留最近几轮对话完整保留稍早的做摘要压缩更早的只保留关键结论。这样既控制了token消耗又不至于丢失重要信息。长期记忆的管理核心是存什么、怎么取。不是什么都要存我一般只存三类用户的稳定偏好比如喜欢靠窗座位、历史任务的关键结论、用户明确要求记住的信息。存储用向量数据库做语义检索需要的时候根据当前任务相关性召回。4.2 上下文压缩token预算的精细化管理上下文窗口是Agent最稀缺的资源。一个长任务跑下来历史记录轻松就能撑爆窗口。这时候就需要压缩。压缩不是简单截断那样会丢失关键信息。我常用的策略是滚动摘要当历史记录超过阈值时把最早的一部分对话交给模型做摘要用摘要替换原文。摘要要保留的信息包括已经完成了什么、得出了什么结论、还有哪些待办、遇到过什么错误。def compress_history(history, threshold8000): if count_tokens(history) threshold: return history # 保留最近N轮完整对话 recent history[-6:] older history[:-6] # 对较早的对话做摘要 summary llm.summarize(older, prompt提取以下对话中的关键结论、已完成事项、待办事项和遇到的错误) return [{role: system, content: f历史摘要{summary}}] recent这里有个细节摘要的prompt要明确指定保留哪些类型的信息否则模型容易摘要出一堆无关紧要的寒暄内容把真正重要的结论丢了。4.3 记忆检索的时机与相关性判断长期记忆不是每次都要召回那样既慢又容易引入噪声。我的做法是在任务开始时召回一次在任务执行过程中如果遇到似曾相识的场景再召回。相关性判断也有讲究。纯向量相似度有时候会召回一些看起来相关但实际没用的记忆。我一般会加一层过滤召回后用一个小模型判断这条记忆对当前任务是否真的有用过滤掉噪声。这一步虽然增加了延迟但能明显提升Agent的表现。5. 并发与稳定性Agent扛不住并发时的排查思路5.1 并发场景下Agent会遇到什么单用户跑得好好的Agent一上并发就各种问题。常见的有上下文串了A用户的记忆跑到B用户那儿去了、工具调用限流、LLM API超时、状态管理混乱。上下文串台是最严重的问题本质是状态管理没做好。每个用户会话必须有独立的上下文空间不能共用全局变量。我见过有人把对话历史存在一个全局list里单用户测试没问题一并发就全乱了。5.2 限流、重试与降级策略LLM API和外部工具都有速率限制。并发上来之后必须做限流和重试。限流用令牌桶或者信号量控制并发数。重试用指数退避但要注意不是所有错误都值得重试网络超时可以重试参数错误重试多少次都没用。降级策略也要提前设计主模型不可用时切备用模型工具不可用时返回缓存结果或提示用户稍后再试。import time from functools import wraps def retry_with_backoff(max_retries3, base_delay1): def decorator(func): wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except RetryableError as e: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) time.sleep(delay) except NonRetryableError: raise return wrapper return decorator关键是把错误分成可重试和不可重试两类这个分类要在工具层就做好。5.3 状态隔离与超时熔断状态隔离的核心是每个会话一个独立的Agent实例或上下文对象绝不共用可变状态。如果Agent需要访问共享资源比如数据库连接池那共享的应该是资源本身不是状态。超时熔断是保护系统的最后一道防线。每个任务设置总超时每个工具调用设置单次超时超时后要么中断任务要么走降级路径。我一般会把超时时间设成正常耗时的3倍这样既能容忍偶发的慢响应又不会让异常任务拖垮整个系统。问题类型表现排查方向解决手段上下文串台用户看到别人的信息检查状态是否全局共享会话级状态隔离API限流大量429错误检查并发数和调用频率令牌桶限流退避重试任务卡死长时间无响应检查循环终止条件超时熔断重复检测成本失控token消耗异常高检查循环次数和上下文长度步数上限上下文压缩6. 框架选型与落地LangGraph这类工具到底该不该用6.1 从裸写循环到框架编排的临界点刚开始做Agent我建议先用裸写循环跑通一个最小可用版本。这样你能真正理解Agent的运行机制知道每一步在发生什么。直接用框架的话很多细节被封装了出了问题你都不知道从哪儿查。但当你发现自己在反复写类似的状态管理、条件分支、循环控制代码时就该考虑上框架了。LangGraph这类框架的核心价值是把Agent的执行流程抽象成图结构节点是操作边是流转条件这样复杂的控制逻辑会清晰很多。6.2 LangGraph的图结构思维LangGraph用状态图来组织Agent逻辑。每个节点是一个处理函数接收当前状态、返回状态更新边定义了节点之间的流转规则可以是固定的也可以是根据状态动态决定的。这种思维的好处是把什么时候该走哪条路显式化了。裸写循环的时候这些判断散落在各种if-else里时间一长自己都理不清。用图结构表达之后整个Agent的行为一目了然调试和修改都方便很多。不过LangGraph也有学习成本而且它对你的Agent逻辑有一定的规训作用——你得按它的方式组织代码。如果Agent逻辑很简单用LangGraph反而显得笨重。我的建议是逻辑分支超过5个、或者需要多Agent协作时再考虑上LangGraph。6.3 自研与框架的取舍判断自研的好处是可控、轻量、没有额外依赖坏处是什么都要自己写容易在细节上踩坑。框架的好处是开箱即用、社区验证过坏处是抽象层多、出问题难排查、版本升级可能破坏兼容性。我的判断标准是看团队规模和项目生命周期。小团队、短周期项目用框架快速出活大团队、长周期项目核心逻辑自研、外围用框架。另外如果Agent逻辑是这个产品的核心竞争力那核心部分一定要自研不能把命脉交给框架。7. 那些文档里不会写的实战经验7.1 提示词里的三个点key、query、value热词里提到的token三个点key我是谁、query我在找什么、value我能提供什么这个类比很精准。在Agent的提示词设计里这三个点对应的是角色定位我是谁、任务目标我在找什么、能力边界我能提供什么。角色定位决定模型的语气和决策风格任务目标决定它往哪个方向努力能力边界决定它什么时候该说这个我做不了。很多Agent表现不稳定就是因为这三个点在提示词里没写清楚模型只能靠猜。7.2 别让Agent太自由新手容易犯的错是给Agent太多自由度觉得这样它更智能。实际上约束越清晰的Agent表现越稳定。该用哪个工具、什么情况下必须停下来问用户、哪些操作绝对不能做这些都要在提示词和系统设计里明确。我一般会给Agent设几条硬规则涉及资金、删除、对外发送的操作必须二次确认连续失败三次必须停下来报告不确定的信息必须标注待确认而不是编造。7.3 测试Agent的正确姿势测Agent不能像测普通函数那样只测输入输出。因为Agent的行为有随机性同样的输入可能走不同的路径。我的做法是构造一批典型任务跑多次看成功率、平均步数、平均成本、失败模式分布。更重要的是记录完整的执行轨迹每一步的输入、输出、决策都要留痕。出问题的时候回放轨迹比看最终结果有用得多。我现在的项目里每个Agent任务都会生成一份执行日志包含每轮的prompt、模型输出、工具调用和结果排查问题时直接看日志就行。7.4 成本控制的几个实用技巧Agent的成本主要花在LLM调用上控制成本就是控制调用次数和上下文长度。几个实用技巧简单任务用小模型复杂任务才用大模型工具返回结果做截断别把整个网页内容都塞回上下文能并行调用的工具并行调减少轮次缓存高频查询的结果。我算过一笔账一个中等复杂度的Agent任务优化前后成本能差三到五倍。优化的大头就是上下文压缩和模型分级使用。8. 关于Agent能力边界的一点个人看法做了这么多Agent项目我越来越觉得Agent的能力上限不取决于模型有多强而取决于你对任务的理解有多深。模型再强如果你说不清楚要它干什么、判断不了它干得对不对那这个Agent就是不可靠的。现在各种Agent框架和工具层出不穷很容易让人产生有了这些就能做出好Agent的错觉。但真正决定Agent好不好用的是那些不起眼的东西工具描述写得清不清楚、错误处理做得完不完善、记忆管理合不合理、边界条件考虑得全不全。这些没有捷径只能一个坑一个坑踩过来。如果你正在做Agent我的建议是先把一个简单场景做深做透把循环、工具、记忆、并发这些基础问题都趟一遍再考虑扩展场景。基础打牢了后面加什么功能都是水到渠成的事。

从LLM到Agent：核心循环、工具调用与记忆管理实战

相关推荐

Flask生产级应用开发实战：从零搭建到部署优化指南

华为鲲鹏+昇腾双引擎：智慧交通算力底座架构与实操优化

DeepSeek电商用户画像构建：多源融合到偏好预测全链路实战

更多资讯

手写签名提取工具：基于OpenCV与颜色空间的自适应抠图实现

BP神经网络频谱预测：4-20-1模型复现与MATLAB实现

嵌入式内存实战：malloc、栈溢出与堆栈冲突全解析

AIC、BIC与交叉验证：模型选择方法详解

从零搓出一个Claude Code，一篇超详细的总结！TaoToken 统一 Key 接入实战

GWO-RRT无人机三维路径规划：灰狼优化与RRT结合的Python实现

今日更新

企业AI转型实战指南：从场景选择到落地避坑的完整路线图

OpenRig：本地大模型服务编排的轻量级运行时框架

夸克网盘1TB免费扩容领取全攻略：新老用户实操流程与避坑指南

本周精选

如何彻底离线使用 Laya-CoreML：Hugging Face 下载、缓存机制与 local_files_only 详解

基于1Panel 部署MySQL MCP 服务：TaoToken 统一 Key 接入与 config.toml 配置实战

崇州园区营销网站建设避坑指南：5大注意事项保备案安全

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？