你要是做过几个月的智能体Agent开发大概率对“跑一个长程搜索任务烧掉几十块token费结果给你一堆重复、过期、抓不住重点的资料”这种体验不陌生。长程搜索智能体一直背着两个标签一个是“烧钱”一个是“笨拙”。REDSearcher 这个项目想做的事情就是把这两个标签一起撕掉——它用一套“小模型规划、中模型执行、大模型总结”的分层架构把单次长程调研的推理成本压到原来的五分之一甚至更低同时让搜索过程始终围绕目标展开而不是让模型漫无目的地越搜越偏。这个项目本身是一个研究型Demo但它解决的是工程界普遍头疼的问题当任务需要多轮搜索、跨多个信息源汇总、持续数十分钟乃至数小时时怎么让智能体既不失控又不让账单失控。代码结构也足够轻量本地部署和调优的门槛都不高。如果你正在做RAG、深度调研、舆情分析或金融信息追踪这类应用这篇文章值得看完——它不光拆解REDSearcher的架构还会把关键参数、踩坑记录和成本测算方式一并讲清楚。1. 先把痛点掰开为什么长程搜索智能体普遍“烧钱且笨拙”1.1 烧钱是怎么烧起来的token账单的失控逻辑很多人以为长程搜索智能体贵是因为搜索次数多。其实搜索API调用本身并不贵——真正烧钱的是模型在每一轮搜索时都要在上下文里反复“重读”之前的所有内容。我举一个自己碰到的实际例子。某次做一个模拟的产业调研Agent任务很简单“梳理近一年动力电池上游材料的价格波动”。按照最朴素的做法直接给强模型一个系统提示让它自己决定搜什么、怎么搜最后给出报告。结果模型第一轮就把“碳酸锂”“氢氧化锂”“六氟磷酸锂”“铜箔”“隔膜”五个方向全部塞进一次搜索请求里然后因为结果太长它又拆成多轮搜索继续翻。等到跑完日志显示总消耗接近40万token按当时的商用API单价算折合约50美元。更气人的是最终报告里“碳酸锂价格”出现了六次而“铜箔供需关系”这个关键信息反而一个数据点都没有。问题的根源在于让一个通用模型在“搜索决策”和“信息消化”上同时负责它会把大量token花在重复阅读、无效整理和计划摇摆上。模型不是被设计来控制成本的——它只知道继续生成最可能的下一段文字不知道自己的行为正在把上下文窗口撑爆。1.2 笨拙体现在哪里长程任务中的三种失控形态“笨”不是指模型不聪明而是指它在长程任务中缺乏结构性约束。我做过的复盘里最常见的失控是这三类一是上下文漂移。任务做到第十五分钟模型已经彻底忘了最初的问题是什么。它从“动力电池材料价格”漂移到“新能源车企销量”再漂移到“充电桩布局”虽然每一步单独看都合理但整体已经偏离目标。二是重复劳动。同一个信息点通过不同措辞搜了三四遍。比如“碳酸锂价格走势”“电池级碳酸锂行情”“碳酸锂现货报价”在模型看来是三个不同query但返回的内容高度重叠白白消耗token。三是证据悬浮。模型在报告里给出一个看起来很笃定的结论但追问“这个数据是哪里来的”它引用的是自己的推测而不是搜索结果中的真实数据。这种幻觉在短对话里不怎么显眼但在长程任务里会被积累和放大最后整个报告都站不住脚。这三种失控本质上都是同一个原因模型没有一个外部化的“目标管理机制”。它把目标放在上下文里上下文越来越长目标就越来越模糊。1.3 为什么“加钱上更大模型”解决不了问题一个很自然的想法是既然模型容易跑偏那就用更聪明的模型给它更大的上下文窗口。这条路我试过效果并不理想。更大的上下文窗口解决的是“装得下”问题但没有解决“找得着”问题。注意力机制在长上下文上的表现并不均衡——模型很容易被中间部分的细节带偏对早期关键约束的记忆反而被稀释。换句话说就算你有200k的上下文窗口任务跑到第80k的时候模型对“原始问题是什么”的把握可能还不如第10k时清楚。更致命的是成本曲线的形状。假设每轮搜索都要把前面积累的内容发给模型那么第N轮的输入token大约是前N-1轮的总和。这种平方级的增长意味着任务越长边际成本越高而且高得越来越离谱。这不是模型选型能解决的问题必须在架构层面把“需要模型看的内容”和“不需要模型看的内容”切分开。2. REDSearcher 的整体设计思路换一套打法而不是硬扛2.1 名字的含义Recursive Evidence-driven Deep SearcherREDSearcher 这个名字里的R.E.D.展开来是Recursive Evidence-driven Deep Searcher也就是“递归式的、证据驱动的深度搜索器”。“递归式”指的是搜索任务的拆解方式不是一次规划完所有搜索步骤而是每走一步根据当前获得的证据重新规划下一步“证据驱动”指的是每一步搜索都以获取可验证的证据为目标而不是以“把对话继续下去”为目标“深度搜索”强调纵向挖掘而不是横向泛泛地搜。这三个词合在一起决定了它的整体姿态这个系统不是一个“一次性问答机”而是一个“越查越清楚”的调研助理。2.2 核心分工让不同层级的模型各干各的活REDSearcher 的架构可以用一句话概括小模型做规划调度中型模型做记忆和证据管理强模型只做最终报告。这个分工在实现上对应三个独立模块搜索规划器Planner由一个参数较小的开源模型担任负责把大任务拆成子问题、改写查询、判断下一步搜什么。执行与证据管理器Executor/Evidence Manager由一个中等规模的模型担任负责调用搜索API、抽取网页片段、给证据打分、维护摘要缓存。报告生成器Reporter只在最后阶段启动由最强的商用或本地大模型担任读取整理完毕的证据链生成最终长报告。为什么要这样分层因为长程任务里90%的token其实消耗在“中间过程”上而不是“最后输出”上。规划器只需要输出很短的决策文本Executor只需要处理结构化的JSON数据真正需要巨额算力和强大推理能力的是把一堆证据组织成连贯论点的那一步——而这一步在整个任务里只发生一次。打个比方这就像一家咨询公司接了一个大项目。规划器是项目经理负责任务分解和进度安排Executor是分析师负责查资料、整理数据、筛选可信来源报告生成器是首席顾问只负责在最后把分析结果写成报告。你当然可以让首席顾问一个人干所有事情但那个费用和交期都是灾难。2.3 成本对比一份真实的token账单我按REDSearcher的架构把之前那个“动力电池材料价格”任务重新跑了一遍记录下各级模块的token开销结果非常直观模块模型规格消耗token费用占比搜索规划器7B级开源模型约9k极低执行与证据管理中等商用模型约58k中等报告生成器强商用模型约22k较高合计-约89k约为原来的五分之一这还只是按token量算。实际部署中规划器可以在本地跑量化模型费用几乎可以忽略执行层用批处理和缓存之后还能再砍掉一部分。最终的单任务成本甚至能压到原来的八分之一左右。这个成本下降的幅度来自一个简单的数学事实把小模型的便宜利用足把大模型的昂贵用到位。规划器不需要聪明到能写报告它只需要输出“下一个该搜什么”的决策信号Executor不需要文采它只需要把搜索摘要做成结构化条目。每个模型都在自己的舒适区里工作没有任何一个环节在浪费能力。2.4 模块化架构的额外收益可观测性与恢复能力分层设计带来的不只是成本优势还有一个容易被忽略的收益可观测性。在单体式智能体里你很难搞清楚模型为什么做出某个搜索决策。但在REDSearcher里规划器的每次决策都是一个独立的JSON输出Executor的每次证据评分都有明确的分数和理由报告生成器的输入是一份结构化的证据清单。这意味着你可以把整个任务过程导出成一个“搜索日志”逐条回放哪一步搜得好哪一步是垃圾哪一步浪费了token一目了然。这种可观测性还带来了恢复能力。单体智能体跑偏之后只能靠模型自己“意识到错误”并纠正REDSearcher则可以在每一步决策之后做显式校验发现偏离就回溯到最近的可靠节点重新开始规划。这种“外部化纠错机制”才是长程任务稳定性的真正保障。3. 关键技术细节与实现方案3.1 搜索子任务的拆解策略从“一次搜完”到“边搜边修正”REDSearcher把搜索过程组织成一颗“目标树”。根节点是原始任务向下展开为多个可验证的子问题每个子问题再根据搜索结果细分为更具体的问题。以“近一年动力电池上游材料价格波动”为例规划器不在最开始就把所有事情定死而是先产出三个粗粒度子问题锂盐类材料、正极材料前驱体、负极与辅材。搜索完第一轮之后规划器发现“锂盐类材料”的搜索结果显示碳酸锂和氢氧化锂走势差异很大于是自动把该节点拆成两个更细的问题继续向下搜索。目标树的深度是可以动态增长的——如果一个子问题的证据不足它会一直往下追直到有足够支撑数据如果一个子问题已经有多条可靠证据覆盖它就会标记为“完成”不再消耗token。这里的关键点是拆解节奏不要把目标树一次性建完。REDSearcher每次只展开当前最有信息增量价值的节点搜索完一步再展开下一步。这种“贪心式”的逐步拆解避免了模型在信息不全时做出错误的长远规划也避免了多余搜索。3.2 记忆压缩与重写让上下文永远不会失控长程任务最大的工程瓶颈是上下文管理。REDSearcher把记忆分成两层工作记忆和长期记忆。工作记忆只保存当前子任务的搜索操作和证据片段数量被严格限制在最近若干条之内超出即被清理。长期记忆保存的是被压缩过的摘要格式固定为三段“结论”、“支持证据”、“待验证疑点”。当工作记忆里的结构化条目超过预设阈值比如30条Executor会触发一次摘要重写把当前子任务的成果合并进长期记忆然后清空工作记忆。这个设计非常关键。它保证模型在任何时刻需要重新读取的总量是恒定的——不会因为任务时间拉长而线性增长。不管任务是5分钟还是5小时每轮搜索前模型看到的上下文都是同样的大小。把“任务时长”和“上下文长度”解耦这才是长程系统不失控的根本手段。当然压缩必然有信息损失。为了减少损失摘要重写有一个强制要求必须保留所有数字、日期和来源编号。不能让摘要重写把“碳酸锂现货价从60万跌到25万”模糊成“碳酸锂价格大幅下跌”。保证量化信息的完整性是证据链有效的前提。3.3 自我反思与回溯恢复处理跑偏和死胡同在每完成几个搜索步之后规划器会进入一个反思步骤输出一段固定格式的反思标记包含三个问题当前已获取的证据是否支持初始目标的回答是否出现了与目标无关的搜索内容是否有一个更值得优先处理的子问题被忽略了如果反思标记显示“当前搜索偏离目标”系统不会强求模型继续“硬拉回来”而是把目标树的状态保存下来回溯到最后一个可靠的决策节点清掉偏离分支上的搜索结果然后重新规划。这种方式借鉴了传统搜索算法里的回溯思想只不过把“状态”从程序变量换成了“记忆快照”。我用一个实例来说明某次搜索“隔膜材料龙头企业产能扩张”模型搜着搜着跑到了“电解液添加剂”上而且已经消耗了四轮搜索。单体式智能体在这种情况下通常只能把错误信息硬着头皮留在报告里REDSearcher则直接把四个错误分支的搜索结果判定为“低相关”从记忆里丢弃回溯到搜索“隔膜产能”之前的决策点重新出发。最终报告里一条电解液信息都没有出现干净利落。3.4 搜索工具调用与证据评分机制调用搜索API这件事本身也有不少省钱细节。REDSearcher做了三件事查询改写、结果截断、响应缓存。查询改写由规划器执行一个关键词扩展成多个语义变体同时在需要时加上时间范围限定词。例如“碳酸锂价格”改写为“碳酸锂价格 走势 最新”“碳酸锂现货 报价 月涨跌”“battery-grade lithium carbonate price trend”三路并发。但三个变体并不等于三次消耗而是合并成一次批量请求减少API调用次数。结果截断则更简单搜索返回的每个结果条目只保留标题、摘要前200字、发布时间和URL正文内容不直接进入上下文只有当摘要被判定为高相关时Executor才回调API获取正文片段。这样一来绝大多数搜索请求消耗的token非常少只有真正有价值的页面才会触发“深读”。证据评分是REDSearcher控制质量的核心。每个候选证据片段进来Executor按三个维度打分与当前子问题的相关性权重0.6、来源页的可信度等级权重0.2、信息时效性权重0.2。低于0.65分的一律丢弃不进入长期记忆。这个打分操作本身也由模型完成但因为只需要输出一个数字和一句话理由token开销很低。响应缓存则是对同类搜索查询的兜底用查询文本的哈希值做缓存键相同的查询在一天内直接命中缓存不再重复搜索。在多次运行相同调研任务的场景下这个缓存能省掉大量重复消费。4. 从零搭建 REDSearcher 的实操记录4.1 环境与模型选型最低成本组合方案实操之前先说选型。REDSearcher的模型选型原则是“化整为零”不同模块用不同规格的模型。我实际用下来的组合如下规划器7B级别的指令微调开源模型量化到4bit本地部署。执行器中等规模的商用模型或同级别的更大开源模型要求有稳定的JSON输出能力。报告生成器当前可用能力最强的商用模型只在最终生成报告时调用。这套组合有一个硬性前提规划器和执行器的工作都被设计成“短文本决策”和“结构化数据操作”对复杂推理的要求不高。我在实际测试中验证过规划器换成3B级别的模型时会开始出现频繁的无效查询和拆解逻辑混乱7B是稳定性和成本的最佳平衡点。硬件方面7B量化模型的本地运行需要一台8GB显存以上的GPU如果没有GPU资源用一个提供开源模型推理的云服务也完全可行。搜索API用一个稳定的搜索服务提供商即可建议提前确认它对高频批量请求的支持。4.2 核心模块的配置与关键参数如果你照着搭最需要关心的配置集中在三个地方记忆管理阈值、反思间隔、证据评分权重。下面是我验证过的初始参数照着用基本能跑通工作记忆条目上限30条摘要重写触发条件工作记忆超过30条或子问题切换反思步骤间隔每完成3个子步骤回溯窗口大小只回溯1层证据接受阈值0.65分查询并发数3路这几个参数直接决定了任务的稳定性。比如反思间隔设得太长跑偏的风险就会累积设得太短又会因为频繁反思而打断搜索节奏、增加开销。3个子步骤一次的频率是我在多次测试后觉得最不容易出问题的设置。证据接受阈值调到0.65也有讲究。阈值太高会漏掉有价值的长尾信息阈值太低会让垃圾证据混进报告。实际测试中0.6到0.7之间是一个比较合理的区间低于0.6的搜索结果基本都来自时效性差的页面或泛泛的行业综述放进最终报告只会稀释可信度。4.3 跑通一个端到端的长程搜索任务用一个实际任务走一遍完整流程。任务设定是“分析某地区近一年新能源产业政策与市场变化的交互影响”。这是一个典型的开放型长程调研没有标准答案需要跨多个维度收集信息。任务启动后规划器生成了四个粗粒度子问题政策脉络、市场数据、重点企业与项目动态、政策与市场互动关系。随后Executor按子问题顺序执行搜索每完成一个子问题就打分、压缩、写进长期记忆。跑到“重点企业与项目动态”这个子问题时搜索出现了一个明显的“高噪声”现象返回的大量结果都是企业PR稿可信度低。证据评分器把这些条目全部打低分没有一条超过0.65。规划器在反思步骤中发现该子问题证据不足于是回溯一层放弃“企业动态”改为搜索“重大项目 产能落地”因为项目库信息通常比企业新闻稿更客观。最终汇总阶段报告生成器读取长期记忆里的结构化摘要生成了一份约4000字的分析报告引用证据编号36条每个关键论点都能追溯到对应的搜索来源。整次任务耗时为22分钟token支出折算成费用大约是传统单体式方案的三成——考虑到这是一次三路查询并发、做了大量信息筛选的任务这个成本表现相当理想。4.4 我自己追加的优化两步后处理基础版本跑通之后我额外加了两个后处理步骤效果明显。第一步是“报告论点-证据双检”。报告生成后用一个轻量模型逐段抽取报告中的核心论断反向核对证据列表看每条论断是否有对应来源编号。没对应上的论断会被高亮标记由人工决定去留。这一步能有效挡住幻觉残留。第二步是“搜索复盘脚本”。每次任务结束后记录最终报告引用的证据条目对应的是哪个搜索查询统计每个查询的“引用率”。引用率为零的查询就是浪费下一次运行时可以考虑从规划器的候选模板里删掉类似表述。这相当于给系统加了一个自我进化的闭环——每次任务跑完下一次的搜索策略都会变得更精准。5. 踩坑实录与问题排查速查表5.1 常见问题的定位与修复方案长程系统的问题往往是结构性的症状五花八门根源就那么几类。我把实际运行中遇到的高频问题整理成了这个速查表症状根本原因解决方案规划器反复输出同一个查询反思间隔太长模型没有意识到该子问题已经完成把反思间隔从5步缩到3步给已完成的节点打“完成”标记摘要里丢失关键数字摘要重写模型能力不足或者模板没有强制保留量化信息在重写提示词中硬性要求“必须保留所有数字和日期”并对输出做断言校验回溯导致死循环回溯窗口太窄或回溯后没有清空引发偏离的搜索分支检查回溯触发条件确保回溯时丢弃对应分支的记忆搜索API频繁限流查询并发数过高或缺少缓存把并发降到2路开启响应缓存在API限流后增加指数退避最终报告包含未引用证据报告生成器自行“脑补”了逻辑连接启用报告后处理双检把无来源论断筛选出来人工复核任务跑到一半成本突然飙升某个子问题进入“深挖循环”不断触发正文页回调给正文页回调次数设置上限达到上限后标记为“证据不足”并跳过5.2 几个容易被忽略的细节坑第一摘要重写的时间点不要固定在“第几步”而应该放在“子问题切换时”。如果在一个子问题中间触发重写前后两段记忆的边界会非常模糊后续回溯也找不到准确的恢复点。我一开始把触发条件设为“每30条强制重写”结果出现了一个子问题的证据被切开分进两段摘要的情况后续引用经常错位。改成“只在子问题切换时重写”后问题立刻消失。第二搜索结果的时间过滤必须在查询阶段完成而不是在评估阶段完成。换句话说要在搜索API层面把时间范围限定好而不是等一堆老文章返回来了再让证据评估器去判断新旧。预过滤的成本远低于后过滤——一个是API参数的事一个是模型推理的事。第三规划器输出的搜索查询一定要做“查询去重校验”。因为规划器是本地小模型很容易在措辞变了但语义相同的情况下反复生成同一类查询。用嵌入向量做一次相似度比对重复度超过0.85的查询直接丢弃能省下不少无效token。5.3 关于成本压榨的最后一道刀法在REDSearcher的架构已经尽量精简的情况下还有最后一道省钱手段值得做对搜索结果里高相关页面的“正文深读”不要整页全读而是只抽取与当前子问题相关的段落。实现上很简单拿到正文的纯文本之后先用正则切分成段落再用嵌入模型算每个段落与当前查询的语义相似度只取最高的1到2段进入上下文。整页读和精读段落的token消耗通常是5倍以上的差距。对于长程任务动辄几十次搜索来说这个优化省下的钱相当可观。我实测过一个极端案例某次调研的正文页平均长度超过8000字精读段落之后单页消耗从约5000 token降到了900 token且报告质量没有下降——因为不相关的正文本来就不会被引用读了也是白读。写在最后的实操体会调了这么多轮REDSearcher之后我个人最大的体会是长程智能体的工程重心不在模型多聪明而在系统是否给模型提供了足够清晰的结构。小模型规划、中模型管理、大模型总结这套分工最大的价值不是省了多少钱而是让每一条token都有明确的职责。如果你也打算在项目里采用类似的思路我建议从最小闭环开始先只做一个规划器和执行器的两级架构跑通一个五步以内的短任务确认记忆管理没有bug再逐步加长任务。不要一上来就追求超长任务长程系统的问题往往藏在第20轮之后——到那时你才会真正理解为什么需要一个随时可以回溯的记忆结构。最后说一个小技巧每次跑完任务把最终报告里真正引用的搜索条目导出来算一算哪些搜索查询贡献了有效证据。坚持看几次你对自己系统的“token转化率”就会有非常清晰的感知也就知道下一步该优化哪个环节了。