你要是做过几个月的智能体（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 Searcher
REDSearcher 这个名字里的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转化率”就会有非常清晰的感知，也就知道下一步该优化哪个环节了。
