智能体搜索在实际落地时最容易出问题的不是“找不到答案”而是“控制不住过程”。它和传统搜索增强问答不一样一个具备自主规划能力的智能体会自己拆分问题、决定多路查询策略、阅读页面内容、顺着引用继续深挖直到认为信息足够才停。预算不受约束时它确实可以探索得很充分但真实业务永远有边界单次任务最多几次检索调用、一轮回答最多几千 token、接口并发只有几十 QPS甚至用户只肯等 15 秒。这种局面下怎么平衡“探索新信息”和“利用已有线索”就成了智能体搜索能不能落地的关键问题。这篇文章把“预算受限下的智能体搜索”拆成几件事逐个给出可操作的判断办法探索和利用分别对应什么搜索动作预算要限制在哪些指标上资源比例怎么分配单任务、多轮、批量任务分别怎么调度最后是我实际排查时经常遇到的几个故障方向。如果你正在做 RAG 增强问答、Agent 工具调用、搜索式内容生成或者想把模型调用成本降下来这篇内容值得从头看一遍。1. 先把探索和利用翻译成搜索动作探索和利用听起来是方法论词汇但在智能体搜索里它们必须落到具体动作上否则预算分配就没有抓手。1.1 探索阶段做哪些事探索阶段的目的是构建“信息地图”。智能体此时还不确定答案在哪类来源里所以要主动扩大覆盖把用户问题拆成多个不同角度的子查询。比如“订单超时”可以拆成“网关响应时间”“数据库慢查询”“最近发布变更”“用户侧网络重试”四路。同时查询不同来源。文档库、网页检索、内部知识库、结构化数据库接口都可以各自发一遍。先保留搜索结果标题和摘要不做全文精读。这个时候读完整个页面大概率是浪费。记录哪些来源返回了线索哪些来源完全没有命中后续合并时要用。探索的产出不是答案而是“哪里可能有答案”的最短清单。1.2 利用阶段做哪些事利用阶段的目的是围绕一个高价值线索把信息压实。此时智能体已经知道某些片段相关性高要做的是深挖阅读两到三个高相关页面的全文而不是只看片段。提取页面里的引用链接、关联文档、时间戳、作者或来源再顺着这些线索继续查。把大段落按语义切片对需要精确计算的字段做二次提取。比如故障排查里提取具体报错码、时间区间、批次号。用上一轮已经出现的关键词生成下一轮查询采用“原文里出现的专业表达”而不是重新造句。利用阶段要防止的问题是看见一个相关资料就顺着无限深挖。如果这个线索最终被验证是错的不但浪费预算还会把回答带偏。1.3 合并阶段不能省还有一步经常被忽略就是合并。探索得到一堆候选利用得到几个高相关片段需要放在一起检查这些信息互相矛盾吗覆盖到用户问题的几个子部分了吗还有哪一块完全空白合并阶段在现实里会被吞掉因为智能体总想赶紧生成最终回答。但少了合并会出现两种典型错误一是重复讲同一个角度另外一方面的事实漏得厉害二是两条不同来源的结论相互冲突却没人验证。我建议一开始就把“探索、利用、合并”当作三个独立动作而不是笼统地理解成“多搜几次”。只有拆到动作粒度预算分配才有地方下手。2. 预算到底要限制哪些指标预算不能只是一个成本概念。它要能拆成可以观测、可以写入日志、可以触发熔断的指标不然你根本不知道是哪一个环节花了钱。2.1 五种常见预算类型预算类型限制内容常见起点超限后通常表现搜索次数单任务最多发起多少轮检索简单任务 5 次复杂任务 10 到 15 次回答停在半路或者缺失后半部分信息Token 预算单轮输入输出总量、单步上下文长度根据模型窗口的 50% 到 70% 预留上下文被截断导致错误理解引用时间预算总响应时间、单步超时时间单步 3 到 8 秒总响应 15 到 30 秒用户侧超时返回任务被中断接口配额每分钟请求数、每线程并行数、每日调用量依据外部 API 限流额度反向推导触发限流重试风暴成本突增覆盖指标至少覆盖几个来源、几个查询角度简单问题 2 个来源研究型任务 3 到 5 个回答偏科只使用单一来源这里最容易踩的坑是只做总预算不做阶段预算。如果只有一个“总调用次数”限制智能体可能第一轮就把次数用光之后没有余力利用或者验证。2.2 预算要能被智能体感知而不是只在外部强制切断有的实现会把所有限制放在上层网关比如在外面套一个总时长判断超时就杀掉任务。这种方法只能用做兜底不能用做正常控制逻辑。因为杀掉任务之后智能体没有机会渐进式收敛输出往往停留在中间状态。更好一点的做法是把预算变成智能体可感知的条件。例如智能体知道当前已经用了 6 次检索调用还剩 4 次。已知信息已经覆盖问题中的 3 个子问题只剩第 4 个仍为空缺。最近两轮检索没有返回新来源继续探索的边际收益在下降。这样的话“停止搜索”就不是外部强制中断而是智能体基于剩余预算做出的决策。它在终止前可以多做一个动作把已有证据汇总主动说明哪些部分存在信息缺口。用户至少能看到一份有边界感的结果。2.3 预算用不完可能比超限更值得警惕超限会直接报错容易被发现。预算用不完但输出质量差则更隐蔽。常见原因之一是智能体过早收敛第一次检索看到像样的结果就开始写答案后面几个子问题全部忽略。我一般看到“预算剩余 40% 却已经准备输出”的日志会重点检查是不是查询词分化不够导致所有检索结果来自同一个文档或者页面摘要看起来信息完整但实际只是标题相关正文内容根本没有被利用。这种问题通常要回到探索阶段去调而不是调高预算。3. 推荐一种预算分配模型探索 40%、利用 40%、合并与验证 20%预算分配比例不一定要很复杂但必须有。没有比例的智能体搜索本质上是一棵无限生长的树谁也不知道什么时候该收手。3.1 为什么先给出比例而不是绝对数量不同任务对搜索步数的需求差异极大。“查询一个产品参数”可能只需要 2 次检索“对比三款数据库的锁机制差异”可能需要 15 次以上。如果只写绝对次数换个任务类型又要重新调参。比例分配更稳定。假设单任务总预算为 10 次检索调用那么探索阶段分配 4 次利用阶段分配 4 次合并验证阶段分配 2 次。预算变大或变小时比例可以不变只需要调整总量。3.2 一个可参考的配置骨架下面这段配置不是某家平台的标准答案而是我常用的一套起点。你可以把它当作模板替换成自己环境里的参数。{ budget: { max_search_calls: 10, max_rounds: 3, phase_weight: { explore: 0.4, exploit: 0.4, merge: 0.2 } }, explore: { query_variants: 3, search_sources: [web, doc, db], top_k: 5 }, exploit: { deep_read_docs: 2, follow_links: 2, use_chunk_size: 800 }, merge: { conflict_check: true, coverage_min: 3, gap_summary: true }, stop: { confidence_threshold: 0.8, min_coverage_sources: 3, timeout_seconds: 25 } }这个骨架的作用是让每个阶段都有自己的可用余量。探索阶段用 4 次检索去铺开覆盖面利用阶段用 4 次检索去深挖高价值来源合并阶段只留 2 次给最后的交叉验证和信息填补。实际跑起来之后根据日志调整比例一般比拍脑袋定次数要有效得多。注意这里先不要追求一次性把参数调对。我在新项目里通常先用默认值跑 10 条样例看日志里每个阶段实际消耗了多少预算再回头改比例。3.3 什么时候应该打破默认比例默认比例适合中等复杂度的开放搜索任务。遇到下面几种情况需要主动调整问题是确定型事实查询比如“某个版本的发布时间”“某个接口的返回格式”。探索比例可以降到 10% 到 20%利用比例提到 60%剩下留给验证。问题是综合研究型比如“影响学生压力的主要因素有哪些”。没有明确标准答案需要多看来源探索比例可以升到 60%利用和合并各占 20%。来源可靠性差距大时要专门留出验证预算。比如部分资料来自个人博客部分来自官方文档合并阶段需要交叉验证数据冲突验证预算占 30% 也不过分。比例不是死规矩但它能强制你思考这个任务到底更多在“找”还是更多在“读”还是在“对答案”。这个判断做出来预算分配自然就有了方向。4. 单任务跑通后再加多轮循环和批量调度很多团队一上来就做复杂的批量调度结果单个任务还没跑稳日志一塌糊涂。我更建议按照单任务、多轮、批量的顺序逐步推进。4.1 单任务最小可运行步骤一个智能体搜索任务最小闭环至少包含五步解析用户问题识别出需要回答的核心实体和限定条件。执行第一次探索用一到三个不同查询词去检索。从结果里挑出两三个高相关文档进入利用阶段做全文关键信息提取。合并所有线索检查冲突和空缺。如果空缺严重且预算有余量追加一次定向探索否则直接生成回答并标注不确定部分。这五步看起来基础但能逼着你把日志字段设计清楚。每个阶段都至少记录当前轮次、已用搜索次数、检索到的文档编号、本轮新增线索数量、状态是否为找到足够信息。有这些字段后续调参才不是盲猜。4.2 多轮探索怎么避免空转多轮探索最容易出现的问题是“空转”每一轮都在检索但每一轮返回的新线索很少Token 却在不断消耗。我常用的判断标准是每一轮检索之后新增的有效来源数量要大于 0。如果连续两轮新增线索数都是 0说明当前查询角度已经穷尽应该切换查询策略而不是继续加检索次数。切换策略的方法很直接从一个宽泛查询改成把宽泛查询拆成多个窄查询。从关键词查询改成句子级完整问题查询。更换数据源。同一个问题在网页文库搜不到换成技术社区或者数据库接口可能有完全不同的结果。利用上一轮命中的文档中的原文表达重新构造查询词。不要用自己重新组织过的语言因为原文表达往往更接近目标内容。多轮探索还要设定一个明确的上限。比如最多 3 轮。第 3 轮结束仍未找到足够信息就进入合并把已经拿到的东西整理成回答而不是继续加大预算。4.3 批量任务里的预算调度策略批量场景和单任务差别很大。此时预算不再是某个任务单独拥有而是要在多个任务之间共享和调度。我建议至少实现三层控制批次总预算限制整个批次的检索调用量和 Token 消耗上限防止一批任务把月度配额打爆。单任务超标隔离给每个任务设置独立超时和调用上限。某个任务失败或者超限时进入失败重试队列不阻塞整个批次。优先级排序先跑确定型查询再跑开放研究型任务。确定型查询通常耗时短、结果明确适合用来验证管线开放性任务再逐步消耗剩余预算。另外一个容易出问题的是缓存。批量任务里多个用户的问题经常指向同一批文档。如果每个任务都从第一次检索开始跑既慢又贵。我建议在检索层做一层结果缓存至少对“相同查询词 相同数据源”做缓存。更进一步可以做语义缓存查询意思接近时直接复用之前的搜索结果。缓存命中率上去了批量处理的成本会明显下降。4.4 批量日志要能反推每个任务的消费批量跑完之后最怕什么都看不出来。我要求生成的结果里每个任务至少要带一条查询签名包括任务 ID、总检索次数、Token 消耗、命中来源列表、是否命中缓存、排除重试之后的耗时。有了这些字段才能回答最基础的问题预算花在了哪里哪个任务最耗钱哪个来源从来没有被利用过。5. 参数怎么调结果怎么判断智能体搜索不是“把参数拉满就能变好”的问题。参数之间有明显的联动效应单独调整某一个往往看不出效果。5.1 关键参数与实际调整信号参数控制什么建议起点需要调整的信号单任务最大检索次数搜索深度上限简单任务 5复杂任务 15回答总缺事实时增大响应太慢时减小查询分化数探索阶段的查询变体数量3多个查询返回相同结果时增加分化Top-K 候选数每轮保留多少检索文档进入利用阶段5 到 10文档相关性低时先增加候选数观察深度精读文档数利用阶段真正读全文的文档数量2 到 3答案不够细时增大上下文溢出时减小温度或采样参数查询词和回答生成的随机性知识型用 0 到 0.3多轮结果波动大时降低温度并发数批量任务的请求并发根据 API 配额和机器负载设置出现限流或超时时降低并发缓存命中阈值语义缓存判定相似度的阈值0.85 到 0.95缓存误命中导致结果偏旧时提高阈值5.2 质量判断不能只看“答得对不对”判断智能体搜索质量最好用三个相互独立的标准覆盖率问题中的关键维度是否都提到了。比如“订单超时”这个问题是否覆盖了日志、网络、数据库、发布变更几个可能根因。只答出日志原因就不算覆盖完整。收敛率检索过程中新增线索的下降速度。前两轮新增线索多第三轮几乎为 0说明搜索已经收敛可以停止。如果一直有新增且都是新角度说明问题复杂度高需要更多预算。成本产出比额外花掉的检索次数换来了多少有用的新信息。连续两轮没有新增信息来源这时候再继续探索就是纯消耗。这三个标准可以量化。最简单的做法是每次跑完测试后人工检查结果给覆盖率和有效新增线索数打分然后对照日志里的预算消耗观察高分数和低分数分别对应什么参数组合。5.3 常见质量问题和调整方向如果发现回答内容空洞、缺少具体事实第一反应不要是加预算而是检查探索阶段是否有足够多的查询角度。一个查询词跑到底无论预算多大都找不到多样化信息。如果发现回答流畅但可信度不高问题更大概率出现在利用阶段。智能体可能只拿了摘要片段就当全文阅读或者没有追踪原文引用。这种时候要增加深度精读文档的数量并开启冲突检查让两个不同来源同字段进行比较。如果发现响应非常慢优先检查有没有做阶段性中止。很多慢不是因为模型推理慢而是因为智能体在无限循环“检索→读全文→再检索”。加上第 2.2 节说的可感知预算条件让它在覆盖率达标后提前退出往往比调高并发更有用。注意调参的时候不要一次改多个变量。先跑一组基线数据记录当前质量分数、成本和耗时再只改动一个参数跑同一组测试样例对比差异。不然你永远不知道是哪个参数起的作用。6. 上线后我最常排查的几个问题智能体搜索系统上线之后问题不会从“彻底不可用”开始而是从“偶尔不对劲”开始。下面这几个方向是我在实际调试中反复遇到的。6.1 预算没花完质量却很差这种情况最常见的病因是阶段混乱探索阶段在精读全文利用阶段又在不断发散到新查询。整个搜索循环没有一个清晰的边界预算看似没花完实际上各个阶段都在低效消耗。修复方法是回到阶段划分硬性规定探索阶段只许收集候选不许精读利用阶段只许围绕已选文档深挖不许随手开新主题。跑一轮对比测试通常质量会恢复。6.2 关键信息总是在最后一轮才出现如果每次都在最后一轮检索才找到最关键的那条线索说明探索阶段的方向有问题。智能体用了大量预算在相关性不高的角度上最后才碰到正确答案。我一般会回看日志里的查询词列表检查前三轮的查询是否过于保守是否都基于同一个初始假设。如果是需要在探索阶段加入对抗性查询主动搜索“为什么不成立”“这个方案有什么问题”“哪个方案在这类场景会失败”。这类查询往往能更快暴露反向证据。6.3 缓存污染导致探索失效缓存可以提高效率也可能坑到质量。尤其是语义缓存当两个问题表面相似但实际参数不同时容易被误判为同一个查询直接命中旧结果导致智能体根本没有重新探索输出即使逻辑正确也会缺少最新信息。排查方法是给缓存记录加上来源时效和查询指纹。查询指纹里至少包含核心实体、时间范围、限定条件。指纹不一致时即使语义相似也强制走真实检索并在日志里标记为“缓存跳过”。6.4 批量任务被一个长尾问题卡住批处理时一个复杂的长尾问题很容易拖垮整个队列。它可能涉及几十个子问题反复检索把共享预算消耗完后面正常的简单任务全部失败。建议对批量任务做两层隔离。第一层是按任务复杂度预估预算复杂任务放入独立慢队列。第二层是给每个任务一个硬性最大轮数超过直接终止回到合并阶段输出已有结果和缺失说明。不要因为一个任务让整个批次陪跑。6.5 报错和解耦日志归因最后提醒一点报错本身不代表整个管线崩了。有时候只是一个外部检索接口超时智能体走异常分支仍然可以基于其他来源完成回答。如果只盯是否有报错会误判成全部任务都失败。正确做法是先看日志归因字段失败任务占比、报错类型分布、失败时处于哪个阶段、是否有可用的降级来源。把这些数据和最终回答质量放在一起看才能知道哪些报错需要立即修复哪些只是可以容忍的偶发噪音。预算受限下的智能体搜索本质上是在资源和质量之间找平衡点。先把单任务跑稳再考虑多轮和批量先分清探索、利用、合并三个阶段再去调参数和并发。很多时候问题不是工具能力不够而是预算模型没有设计清楚搜索过程在失控地消耗资源却没有真正增加信息价值。按这个顺序排一遍很多看似无解的性能和成本问题都能找到明确的调整入口。