做了好几年Agent工程我最常被问的一个问题就是ReAct框架是不是已经被新范式替代了我的答案一直没变——只要Agent还需要“先想一想再做”ReAct这条主线就不会过时。但2026年再回头看经典的Thought / Action / Observation三件套确实已经撑不起真实业务了。Agentic ReAct 3.0的意义不是把ReAct推倒重来而是在主循环里塞进两个真正能救命的模块Multimodal Memory多模态记忆和Cost Control成本控制让Agent从“回答得不错”变成“记得住、花得起、干得完”。这篇文章就是我落地这个升级版框架的完整记录包含整体设计思路、多模态记忆的工程实现、成本控制的预算机制、核心代码与配置示例以及我实际踩过的坑。适合正在做Agent产品、被上下文爆炸和账单失控折磨过的团队参考。如果你只是想把ReAct跑通Demo那经典版本就够了但如果你要做的是周级甚至月级连续运行的Agent3.0这套东西迟早要补上。1. 为什么2026年的Agent需要ReAct 3.01.1 经典ReAct的短板一次性会话与失控预算经典ReAct的核心思想是让大模型在真实环境里交替执行两件事Reasoning推理下一轮该做什么、为什么和Acting行动调用工具、观察返回结果。这个思路本身没有错但它隐含着两个与生俱来的假设每一轮任务都是从零开始所有历史信息都可以靠重新塞进Prompt来恢复同时没有人真正关心这一轮跑了多少次模型、烧了多少token。2026年的真实业务场景早就不满足这两个假设了。拿我一直在做的某客服场景来说用户会同时发来文字描述和截图Agent需要翻历史工单、查知识库、调用内部接口还要记住用户上一轮强调过的偏好。如果继续把所有历史对话、历史截图、历史工具返回结果全量塞进上下文第一件事是Token先爆炸第二件事是模型开始“选择性失明”——上下文越长关键信息越容易被淹没。成本问题就更直接。经典ReAct没有一个“记账”的概念一个看起来简单的任务可能因为模型反复试错调了十几次工具最后账单下来比人工处理还贵。我见过很多团队做完PoC后不敢上线不是因为效果不行而是因为成本完全不可控。这类问题在框架设计层面不解决靠工程侧打补丁永远治标不治本。1.2 Agentic ReAct 3.0的核心理念从三件套到五段闭环Agentic ReAct 3.0做的最重要的事是把经典循环从Thought / Action / Observation扩展成一个带记忆和预算监控的闭环。我自己习惯把它拆成五个阶段Perceive感知接收多模态输入包括文本、图像、音频、表格等Reason推理基于当前问题、历史记忆和工具返回规划下一步Act行动调用工具、执行动作或者直接给出最终答案Observe观察获取工具执行结果判断是否达到目标Memory Budget记忆与预算结算把值得保留的信息写入多模态记忆库同时扣除本轮成本、检查预算余量。这个设计本质上没推翻ReAct只是在Reason和Act之间加了两个“后台常驻进程”一个负责把短期经验转成长期记忆另一个负责在每次循环结束时决定“继续跑、降级跑、还是赶紧停”。我叫它后台进程是因为它们不该阻塞主链路而是像系统的财务和档案部门一样每轮都被调用但尽量不打扰决策本身。为什么2026年必须这样做因为Agent的评判标准变了。过去评价一个Agent看的是单轮回答准确率现在评价一个Agent看的是能不能连续完成多轮任务、能不能在固定预算内完成任务、能不能在下次遇到相似问题时调用已有经验。准确率只是及格线记忆和成本才是分水岭。2. Multimodal Memory实现细节三种记忆形态与多模态向量库2.1 三种记忆形态会话记忆、摘要记忆、模态记忆多模态记忆不是简单地把图片和文字存进同一个数据库而是要区分不同生命周期、不同用途的记忆。我在系统里把记忆分成四类每一类的写入策略和存储载体都不一样记忆类型存储内容典型载体写入时机会话短期记忆最近几轮的原始消息、工具返回原文Redis / 内存缓存每轮结束摘要长期记忆任务目标、用户偏好、决策原因文本摘要 向量存储关键节点模态记忆截图、图表、音频片段等非文本信息多模态向量存储Observation中模态信息显著时技能记忆工具调用成功经验、参数选择模式结构化事件记录工具执行成功后这里最容易踩的第一个坑就是把会话短期记忆和摘要长期记忆混在一起。短期记忆的特点是原始、量大、时效性高适合用TTL比较短的缓存长期记忆的特点是浓缩、可检索、跨会话复用必须做摘要和向量化。两者不分就会出现一个任务做完几小时后向量库存了上万条未经筛选的原始消息检索时全是一堆噪音。我自己的经验是短期记忆只要保留最近半小时内的原始数据就够了超过半小时或者超过固定轮数就必须触发摘要化流程把原始记录浓缩成结构化摘要再决定是否写入长期记忆。这样既能保证短期上下文完整又不会让长期记忆库被稀释。2.2 多模态Embedding、向量库与分层存储模态记忆的核心是让不同模态的数据能在同一个向量空间里互相检索。我当前实现用的是CLIP风格的多模态模型把图片和文本分别编码为向量并让相似的图文在向量空间中距离更近。这样用户后续问“上次那张报错图里的错误码是什么”时系统可以直接拿文本Query去检索图片向量而不需要先做一次OCR或VLM理解。向量存储选型上我推荐先考虑带着Metadata过滤能力的向量库。纯向量检索在真实场景里不够用因为记忆检索几乎总是附带条件时间范围、会话来源、业务线、是否已确认有效。在实际项目里我会给每条记忆写入统一的Metadata结构包括memory_id、session_id、timestamp、modality_type、importance_score。检索时先按Metadata粗筛再做向量相似度排序效果比纯向量检索稳定得多。存储分层方面我分了热、温、冷三层。热层用Redis或内存缓存只保存当前会话高频访问的记忆温层用向量库持久化保存跨会话的摘要和模态记忆冷层用对象存储加离线索引保存几乎不会再被直接检索的原始数据。每一条记忆刚写入时都在热层重要性评分下降后逐步迁到温层和冷层。这样做的直接收益是向量库的体积不会无限膨胀单次检索延迟也能控制在可接受范围。2.3 记忆的写入、检索与遗忘机制记忆写入如果每轮都执行那这个系统基本废了。我用的原则是“关键事件提交”每轮循环结束以后先判断这一轮是否满足写入条件比如Action执行成功且Observation中包含用户明确表达的需求用户提供了新的图片、文件或音频当前任务完成了重要阶段比如工单已创建、方案已确认系统发生了异常而这个异常可能是未来的参考经验。满足任意一条才触发记忆提交。提交时除了写入向量还会生成一段简短的文本摘要方便后续快速浏览。不要小看这个“摘要动作”它决定了记忆检索时返回内容的可读性。只有向量没有摘要检索出来的结果是碎片化的模型很难直接重用。遗忘机制同样重要。我给每条记忆算了两个分重要性分和新鲜度分。重要性分由任务完成度和用户反馈决定新鲜度分随年龄衰减。最终保留分数是两者的加权和低于阈值后记忆先从热层迁到温层再过一段时间没被命中就迁到冷层。这套机制陪我解决了“记忆库越跑越慢”的问题比单纯做向量数量限制要优雅得多。3. Cost Control成本控制怎么做预算分层、模型路由与Token压缩3.1 预算分层总预算、单轮预算与熔断预算成本控制的第一件事不是砍模型而是先把预算定义清楚。我在Agentic ReAct 3.0里设计了三个层级的预算总预算total_usd整个任务允许花费的上限单轮预算round_usd每轮循环允许花费的上限防止单轮异常消耗拖垮全局熔断预算emergency_ratio总预算消耗到某比例后强制触发降级或终止。单轮预算往往被忽略但它是防止“失控循环”的关键。我遇到过一种情况模型在一个简单查询上反复调用工具每轮花费不高但轮数无限多。如果没有单轮预算和最大轮数限制总预算再大也扛不住。所以单轮预算要配合max_rounds一起用双保险。熔断预算的触发动作我一般配置成三级先切换到小模型继续尝试再关闭非必须的工具如网页搜索、截图理解最后转人工或返回已有记忆中的最佳答案。一定要避免“预算超了直接报错”因为对用户来说任务没完成就是最差体验。降级到人工或返回近似答案至少保留了可用的结果。3.2 模型路由与工具调用的成本优先级模型路由的价值是让简单任务不要动用复杂模型。我在系统里放了一个本地的小型分类器基于Prompt文本和模态类型判断任务难度把任务分到Simple、Medium、Complex、Vision四条链路上。比如“查询订单状态”这种结构化操作走小模型几乎不耗什么成本“比较两份合同并总结差异”就必须走复杂推理模型“分析一张系统报错截图”则走视觉语言模型。工具调用也有成本优先级。我把工具的调用权限分成了几类内置计算类工具永远开放企业内部API按次收费且次数有限第三方搜索类工具既贵又不稳定每任务最多允许5次所有工具的相同入参结果都做缓存命中缓存时只扣除检索成本不扣除工具调用费。这个优先级设计本质上是把“贵的调用”放在最后一道防线而不是让模型自由发挥。成本记账需要精确到每个环节。我维护了一个统一的CostLedger以事件为单位记录三类成本模型推理的输入输出Token费用、工具API调用费用、向量库检索与存储费用。每轮循环结束后统一结算一次然后把累计花费写回记忆库。这里有一个容易被忽视的点多模态检索不是免费的Embedding计算和向量查询都要算进成本否则总账会低估。3.3 Token压缩与上下文裁剪策略上下文压缩是Cost Control里最立竿见影的手段。经典ReAct把全部历史对话、工具返回、中间推理过程全量拼进PromptAgentic ReAct 3.0只允许把“记忆检索结果”和“当前任务上下文”拼进Prompt。每个新任务开始时系统先根据当前问题从记忆库检索TopK条相关内容然后把这些内容按重要程度排序合并成一段结构化摘要。实际的压缩效果很惊人。在我压测的某模拟项目M里单个任务的Prompt Token从平均16K降到了2.4K降幅超过85%。原因很简单不是所有Observation都需要再次进入上下文很多工具返回内容只对当时那轮决策有用一次性消费完就可以归档只有那些被写进记忆库的摘要才会在后续轮次被重新检索使用。这里需要处理好一个取舍压缩过头会导致模型失去关键细节。我的方案是双通道保留结构化摘要进入Prompt完整的原始Observation留在记忆库中并关联memory_id。如果模型发现摘要信息不足可以主动发起一次记忆检索读取原始记录。这样既控制Token又保留拿到细节的路径不会因为压缩造成能力下降。4. 落地实操一套可用的配置、核心代码与实测数据4.1 配置样例预算、模型路由与记忆参数直接把我的一个可运行配置骨架贴出来这套配置面向的是某模拟项目M中的多模态客服Agent生产环境可以在这个基础上调整。注意这里的模型名是占位符你可以替换成自己实际可用的模型服务。agent: name: multi_modal_support_agent budget: total_usd: 1.0 round_usd: 0.05 emergency_ratio: 0.2 failover_action: escalate_human max_rounds: 15 memory: short_term: backend: redis ttl_seconds: 1800 long_term: backend: vector_store collection: support_mem embedding_model: openclip_b32 top_k: 5 metadata_filter: enabled: true commit_threshold: 0.7 summary_llm: fast_summary_model model_router: difficulty_classifier: local_binary_clf routes: simple: model: fast_small_model max_rounds: 3 token_budget_round: 2000 medium: model: default_chat_model max_rounds: 8 token_budget_round: 6000 complex: model: strong_reasoning_model max_rounds: 15 token_budget_round: 16000 vision: model: vlm_model max_rounds: 10 token_budget_round: 12000 tools: search: max_calls: 5 cache_ttl: 3600 calculator: provider: builtin internal_api: max_calls: 10 cost_per_call: 0.002几个关键参数值得解释。commit_threshold控制记忆提交的严格程度设得太低会导致记忆库噪音大设得太高会导致重要信息丢失我用0.7试过不少场景算是比较稳的一个起点。top_k控制每次检索取回的记忆条数它不是越大越好5条左右通常在相关性和上下文占用之间平衡得比较好。emergency_ratio表示总预算消耗到20%时系统就开始准备降级这个值要看业务的不可控程度越不可控越应该早点触发降级。4.2 核心循环代码预算检查、记忆提交与工具执行伪代码写烂了我直接贴一段可运行的最小实现思路用Python风格描述。重点是三个机制每轮开始前检查预算、每轮结束后提交记忆、只把记忆检索结果拼进Prompt。import json from dataclasses import dataclass class AgenticReAct3: def __init__(self, config): self.cfg config self.memory MemoryHub( short_term_redis_urlconfig.memory.short_term.backend, vector_storeconfig.memory.long_term.backend, embed_modelconfig.memory.long_term.embedding_model, ) self.cost CostLedger(round_limitconfig.budget.round_usd) self.router ModelRouter(config.model_router.routes) def run(self, goal: str, user_input): pkg self.perceive(user_input, goal) while self.cost.can_continue(): self.cost.tick(loop_start) if self.cost.emergency_triggered(): return self.cfg.budget.failover_action recalled self.memory.recall(pkg) prompt self.build_prompt(goal, user_input, recalled) route self.router.route(prompt) plan_text route.model.generate(prompt) plan self.parse_action(plan_text) # 强制JSON Schema if plan[type] finish: self.memory.commit(pkg, actionNone, observationNone) return plan[answer] obs self.tools.execute(plan[tool], plan[params]) self.memory.commit(pkg, actionplan, observationobs) pkg pkg.merge(observationobs) self.cost.record( model_costroute.last_cost, tool_costplan.get(estimated_cost, 0), memory_costself.memory.last_retrieval_cost, ) return self.cfg.budget.fallback_response这段代码里最反直觉的地方是build_prompt不接收历史列表只接收recalled结果。第一次写的时候我非常不习惯总觉得会丢信息但实际跑下来发现记忆检索返回的内容已经包含了与当前任务最相关的历史效果反而比全量拼接更准。parse_action也是容易被低估的一步。我要求模型输出严格JSON包含type、tool、params、estimated_cost这几个字段。estimated_cost让模型自己对动作的成本做预估虽然不完全准但能跨过“盲目调用工具”的门槛。如果模型输出不符合Schema我会直接让它重新生成一次而不是强行解析因为硬解析常常把语义搞歪。4.3 某模拟项目M的实测数据成本降幅与效果指标我在某模拟项目M的多模态客服场景上跑了一组对比实验一组用经典ReAct全量上下文一组用Agentic ReAct 3.0。任务是连续处理10轮用户咨询其中夹杂图片截图、历史工单引用和用户偏好记忆总共跑了200个模拟会话。指标经典ReActAgentic ReAct 3.0变化单任务平均费用0.350.08下降77.1%Prompt平均Token数16K2.4K下降85.0%任务完成率82%91%提升9个百分点用户偏好命中率46%88%提升42个百分点平均决策延迟8.2s4.6s下降43.9%费用下降最直接的来源是模型路由和Token压缩完成率提升则要归功于记忆召回尤其是用户偏好命中率从46%跳到88%这个提升对客服场景几乎是质变。需要注意的是这是内部压测数据不同业务场景差异会很大但“成本大幅下降、效果小幅提升”这个趋势在我接触过的多数场景里是稳定的。5. 踩坑记录与问题排查速查表5.1 记忆膨胀导致检索噪音变大系统上线第一周我遇到最典型的问题是向量库存量涨得很快但检索质量越来越差。排查后发现问题出在记忆写入策略太激进。初期我把每轮Observation都当成“事件”写入记忆库结果一个10轮任务就会产生十几条记忆其中大量内容只是工具返回的中间状态根本没有长期价值。解决方案是双管齐下。一是把写入阈值从默认的0.4提高到0.7只有明确包含用户需求、决策结果或异常经验的Observation才允许入库二是给记忆写入加了一个前置判断模块先用一个小模型判断“这条记忆未来是否可能被再次使用”不满足就不写。调完之后记忆库周增量降低了约65%检索命中率明显回升。这里我自己的体会是记忆系统宁缺毋滥少写一点比写多了再清理更划算。5.2 多模态对齐失败图片和文本对不上某个交互场景里用户上传了带错误码的截图系统应该记住“这张图对应某个报错类型”但后续检索时文本Query指向了另一张截图。排查发现根因是图片Embedding和文本摘要使用了两套互相独立的ID体系图片存的file_id和文本摘要存的memory_id没有任何关联。修复方案是在写入模态记忆时强制建立统一memory_id每一组多模态数据共享一个ID图片向量和文本摘要通过这个ID相互索引。同时在提交阶段增加一个对齐校验步骤如果文本摘要描述的内容与图片OCR结果差异过大就拒绝这次写入并打出警告。统一ID后跨模态检索的准确率提升非常明显这个坑也让我养成了习惯——任何多模态系统第一件事先把ID规则定死比选模型更重要。5.3 成本超支与模型降级实战有次压测一个复杂分析任务模型反复在工具之间试错15轮里调了9次外部API最终单任务费用突破1美元触发了熔断。事后分析账单发现大头不是模型Token而是外部API调用费。这说明成本控制不能只盯着模型费用工具调用费同样需要设独立配额。我把工具费用单独拆出来每个外部API设了每任务调用上限调用前先查缓存同时让路由对“是否值得调用某工具”做一次快速判断。模型降级策略也做了细化前5轮允许使用复杂推理模型超过5轮后强制切到中等模型如果问题仍未解决第10轮前转人工。这套策略上线后复杂任务极少触发熔断更重要的是用户不再觉得Agent是个“无底洞”。5.4 常见问题速查表症状可能原因处理方式记忆库增长快但检索命中率低写入阈值太低垃圾记忆过多提高commit_threshold增加前置判断任务中途成本突然超支外部API调用次数失控给每个工具设独立配额调用前查缓存图片和文本检索结果对不上多模态ID体系不统一统一memory_id提交时做对齐校验简单任务被路由到复杂模型难度分类器置信度过低低于置信度阈值时改为走中等模型模型频繁返回非法JSONSchema约束不够或者模型能力不足强制Schema校验失败后只允许重试一次多模态检索延迟高向量库没有按Metadata预过滤先按时间/类型过滤再做向量排序熔断后用户得到空结果fallback策略配置缺失配置转人工或返回记忆中的最佳答案多模态检索延迟的问题我多说一句。最初我直接对所有向量做相似度搜索结果图片类记忆多了以后查询延迟直线上升。后来改成先按timestamp和modality_type做Metadata过滤再把候选集控制在100条以内做向量排序延迟从接近600ms降到120ms左右。这个优化很小效果却非常明显建议所有向量检索场景都加上。最后再分享一个我自己的实操心得Agentic ReAct 3.0里的记忆和预算最好在项目第一天就引入而不是等出问题再补。记忆决定了Agent能不能越用越聪明预算决定了Agent敢不敢真上线。先把成本记账做出来哪怕只是简单打印每轮花费也比闭着眼睛跑一百轮强。另一个小技巧是所有记忆写入操作最好同步记录一次成本因为多模态检索和向量存储并不是免费的这笔账不算清楚总账单迟早会给你惊喜。