先问一个很多搜索、推荐、广告团队都遇到过的问题线上策略已经稳定跑了一段时间头部内容贡献了大部分点击这时候算法工程师提了一个新方案你到底是直接上线上 A/B Test还是先在离线数据集上反复调参很多人会下意识选择后者原因是“线上流量太贵了不敢随便试”。但这个决定本身就隐含了一个权衡——你在用“少做尝试”换“确定性收益”也就是在用未来的信息增长换当下的稳定报表。这正是搜索系统、推荐系统、乃至大模型 Agent 在真实业务里每天都要面对的难题探索Exploration与利用Exploitation的冲突。过去我们处理这个问题基本靠经验新方案先小流量老方案保大盘。可真到了预算有限、流量有限、试错成本极高的场景里这种“拍脑袋分配”的方式就开始失控了。这篇文章想聊清楚一件事在预算受限的前提下智能体搜索如何做到“更充分地利用已有信息更聪明地探索未知空间”。我会从决策理论的视角把探索和利用的权衡拆开讲透然后用 Python 实现一个最小可运行的实验环境对比几种常见策略的效果最后给出工程落地的建议和避坑清单。读完你至少能回答三个问题我的搜索系统为什么要做探索预算到底怎么分配才合理以及用 UCB、Epsilon-Greedy 这类策略时真正的坑在哪里。1. 这篇文章真正要解决的问题先说结论预算受限下的智能体搜索本质不是“换一个更好的召回模型”或者“堆更多的算力”而是要在有限的尝试次数里把“不确定性”折算成可计算的成本再决定每一次请求到底该走“追求收益最大化”的路线还是“探索新信息”的路线。很多团队的问题在于把探索和利用当成了两个互相独立的阶段平时闷头做利用等到需要评测新策略时才临时开一个探索通道。这种做法的问题非常明显探索成本不可控要么流量给多了伤线上指标要么流量给少了统计不显著探索结果不可复用试过的经验散落在实验报告里没有沉淀成搜索策略的一部分预算没有参与决策探索流量是“固定拨给”的而不是根据不确定性动态分配的。如果只是站在“调参工程师”的角度这些问题都能靠人工安排来兜底。但当你面对的是一个自主决策的智能体时人工兜底就失效了。智能体搜索里的“智能体”可以是推荐系统里的排序模块可以是大模型 Agent 里的工具选择器也可以是一个自动定价策略。它必须自己在每轮决策中回答这次调用是继续用当前最优策略还是尝试一个可能更好但不确定的新策略。这篇文章要解决的问题就是把这个“自己回答”的过程变成可工程实现的机制。我会先解释探索和利用的理论背景再说明预算约束为什么是核心难点接着给出三种典型策略的对比和代码实现最后讨论如何评估、上线和监控这类策略。适合的读者包括正在做搜索、推荐、广告排序的算法工程师给大模型 Agent 设计工具调用和检索策略的开发者负责策略评测、A/B Test 平台、成本控制的数据团队以及所有需要在“试错”和“收敛”之间找平衡的技术负责人。如果你只是想看一个能跑的代码示例可以直接跳到第 6 节。但建议还是先花五分钟把前四节读完否则你很难理解为什么一个小小的探索函数值得在整个策略体系里占据这么重要的位置。2. 智能体搜索的底层逻辑从“找内容”到“做决策”很多人第一次听到“智能体搜索”这个词会以为它只是在搜索框后面接一个大模型或者给搜索结果加一个 AI 摘要。这是把“智能体”理解得太窄了。在决策智能的视角下搜索系统本质上是一个在不确定环境中做连续决策的智能体它接收用户的查询从候选集合中挑选内容观察用户的反馈点击、停留、转化然后更新自己对内容质量的估计再继续下一次决策。整个过程其实是一个不断“试错-学习-再试错”的循环。传统搜索引擎倾向于隐藏这个循环系统把所有候选内容按相关性打分取 topK 返回给用户然后把用户行为记录下来离线训练模型定期更新线上策略。这个流程的问题是模型训练和数据收集之间存在明显的时间差而且系统默认“当前模型已经足够好”没有给真正的探索留出空间。智能体搜索和传统搜索的关键区别不在于用了什么模型而在于它是否具备在线决策能力。这里有一个更准确的判断如果一次搜索请求的返回结果只依赖当前模型的打分没有任何随机性、不确定度估计或探索机制那么无论模型多复杂这个系统仍然不是“智能体式”的它只是一个函数。只有当系统能基于历史反馈动态调整下一次返回策略并且在必要时主动尝试低置信度的高潜力内容时它才真正进入了智能体搜索的范畴。这样做的好处是显而易见的系统不再是“后知后觉”地等待离线训练而是能在线感知内容质量的变化对新内容、新商品、新文档系统可以通过少量试探快速积累数据对用户兴趣的漂移系统可以更快响应而不是死死抱住历史统计不放。代价也很明显每一次探索都可能带来一次次优的用户体验。这就是为什么探索和利用的权衡会成为智能体搜索绕不开的核心问题。3. 探索与利用的权衡不是一次抉择而是连续决策探索Exploration和利用Exploitation的概念最早来自强化学习和多臂老虎机Multi-Armed Bandit问题。用一个场景来理解最直观假设你现在管理一个搜索结果页有 10 个候选位置每个位置可以放不同类型的摘要格式。你已经知道格式 A 的点击率稳定在 5%而格式 B、C、D 因为数据量太少点击率估计很不准——可能是 1%也可能是 10%。这时候来了一次新请求你选择 A 还是 B选 A是利用Exploitation基于当前已知信息做最优选择收益确定但没有新增信息选 B是探索Exploration收益不确定但如果 B 真的更好你不仅拿到了这单次的收益还获得了“B 值得继续用”这个信息。这里最容易产生的误解是探索和利用是一次性的二元选择。实际上在连续决策中你既不是“纯探索”也不是“纯利用”而是在每一轮根据最新的信息重新评估哪些选项的不确定性最大哪些选项的期望收益最高然后决定是否值得为不确定性买单。新手的另一个常见误区是把“探索”等同于“随机”。随机策略确实是探索的一种但不是好探索。好的探索应该有明确的目标——降低对未知选项估计的不确定性并且把有限的尝试次数花在最值得试探的选项上。完全随机的探索本质上是在均匀地浪费预算。所以探索与利用权衡的正确理解方式应该是每一轮决策都在做一次不确定性投资。投资对象是“尚未被验证但可能更优的选项”投资预算是“容忍一次次优反馈的能力”投资收益是“未来决策中信息增益带来的长期回报”。4. 预算受限约束条件如何改变问题本质如果探索和利用只是多臂老虎机里的一个理论问题那解决它并不难——给足试验次数任何策略都能慢慢收敛到最优。但真实业务里的约束条件让这个问题一下子变得棘手起来。我把它总结为四类预算第一类流量预算。这在搜索排序和广告系统里最典型。一个日均千万请求的搜索系统你可以拨出 5% 的流量做探索但当业务要求新内容冷启动、新策略验证、节假日流量突变同时发生时5% 和 1% 之间的抉择直接关系到 KPI。流量预算的本质是你能承受多少次“可能不如当前最优策略”的线上交互。第二类Api 调用预算 / Token 预算。这是大模型 Agent 场景下的新约束。如果你的搜索智能体需要调用外部工具、外部知识库或者大模型接口每一次探索都会产生真实的费用。很多团队在做 Agent 工具评测时都会遇到“想多试几个方案但 API 账单不允许”的窘境。这时候探索策略的价值就不只是效果提升而是实打实地省钱。第三类时间预算。新内容从入库到获得足够曝光中间需要多长时间如果系统完全没有探索机制一条新内容可能永远得不到展示机会。反过来如果探索机制过于激进可能在用户还没建立认知之前就把内容的生命周期耗尽了。时间预算考验的是策略的“耐心”。第四类人力预算。每一次探索都意味着后续要有人分析数据、判断结果、决定是否放量。如果一个探索策略产生了大量需要人工介入的异常 case那它的工程成本可能会远超它的收益。预算约束之所以深刻是因为它把“最优策略”变成了“预算分配策略”。在无约束环境下最优策略是唯一的——尽可能多探索最终收敛到全局最优。在有约束环境下最优策略变成了在预算耗尽之前最大化信息增益和收益的加权组合。这两个问题在数学上难度完全不同在日常决策中的指导意义也完全不同。理解了这一点再看市面上的搜索策略你就会明白为什么单纯追求“模型精度”是不够的。一个在离线评测里 AUC 很高的模型如果没有考虑探索预算线上效果可能反而不如一个“稍微欠拟合但允许探索”的模型。这不是模型本身的问题而是决策框架的问题。5. 三种常用策略Epsilon-Greedy、UCB 与 Thompson Sampling在预算受限的场景里有几种经典的在线决策策略值得掌握。它们各有侧重适合的约束条件也不同。我先把对比放在这里后面再逐一解释。策略核心思想探索方式适合场景主要风险Epsilon-Greedy以固定概率 epsilon 随机探索其余时间利用随机流量充足、探索成本低探索太盲目浪费预算UCB1按“均值 不确定度上界”选择确定性选择高潜力项需要快速识别最优项对奖励分布敏感冷启动需处理Thompson Sampling按后验概率分布随机采样后选择概率采样贝叶斯奖励噪声大、需要平滑决策先验假设影响大实现略复杂Epsilon-Greedy 是最容易理解的策略。它的思路是每次决策时以概率 epsilon 随机选一个非当前最优的选项以 1-epsilon 的概率选当前已知最优的选项。这个策略实现简单但问题也很明显随机探索完全忽略了“哪些选项更值得探索”所以预算利用率低。在预算受限场景下epsilon 设多少本身就是一个需要反复调参的问题。UCB1Upper Confidence Bound是另一个经典策略。它的选择逻辑是对每个选项计算一个“置信上界”上界由两部分组成——当前估计的均值加上一个与尝试次数相关的奖励项。已经验证过很多次且效果好的选项均值分高尝试次数少、不确定度高的选项上界分高。UCB1 会优先选择上界最高的选项在“已知的好”和“可能的好”之间自动做平衡。它的优点是探索方向有目的性缺点是冷启动阶段所有选项尝试次数都少时行为会接近纯随机。Thompson Sampling 是贝叶斯方法的代表。它假设每个选项的奖励服从某个概率分布通常用 Beta 分布每次决策时先从每个选项的后验分布中采样一个值然后选择采样值最大的选项。因为采样过程天然带有随机性Thompson Sampling 的探索更平滑在噪声大的环境下通常比 UCB 更稳定。它也更接近“人类直觉”每次决策前先在心里对每个选项的潜力做一个概率判断然后按判断行事。这里给出一个非常实际的选择建议如果你的预算很低希望在头几百次尝试内尽量不翻车Epsilon-Greedy 用小的 epsilon比如 0.05-0.1更稳如果预算中等且候选选项数量可控UCB1 的上界机制能帮你更快找到最优项如果奖励噪声大、候选多、且你能接受一定的计算复杂度Thompson Sampling 通常表现最好如果你的场景里混入了大量低质量选项任何纯探索策略都可能浪费预算此时应该在探索前先加一层“候选过滤”。6. 最小实现在 Python 里模拟一个预算受限的智能体搜索下面我们用代码把上面的策略跑起来。场景假设如下有一个搜索服务候选内容池里有 10 个内容项每个内容项都有一个真实的“点击率”但系统并不知道这个点击率只能通过每次请求后的用户反馈点击或不点击来估计。我们有一个总预算请求次数目标是在预算内最大化总点击次数。先写一个搜索环境的模拟类# 文件路径agent_search_env.py import random import numpy as np class SearchEnv: 模拟一个搜索环境10个候选结果每个有真实点击率。 def __init__(self, n_items10, seed42): self.n_items n_items self.rng np.random.RandomState(seed) # 真实点击率用 Beta 分布生成范围大致在 0.01 ~ 0.2 之间 self.true_ctr self.rng.beta(2, 20, sizen_items) def get_true_ctr(self): return self.true_ctr def reward(self, item_id): 请求一次返回是否点击1/0。 p max(0.0, min(1.0, self.true_ctr[item_id])) return 1 if random.random() p else 0注意这里用true_ctr表示内容项的真实质量策略只能通过 reward 反馈来间接估计它。这是在线决策问题的标准抽象环境是未知的决策者只能观察反馈。接着实现两种探索策略UCB1 和 Epsilon-Greedy。先写 UCB1# 文件路径strategies/ucb1.py import numpy as np class UCB1: UCB1 策略均值 置信上界。 def __init__(self, n_items): self.n_items n_items self.counts np.zeros(n_items) # 每个选项被尝试的次数 self.values np.zeros(n_items) # 每个选项的平均奖励估计 def select(self, t): 给定当前总步数 t选择下一个要尝试的 item_id。 # 每个选项至少尝试一次避免除零 for item_id in range(self.n_items): if self.counts[item_id] 0: return item_id # UCB1 上界均值 sqrt(2 * ln(t) / count) ucb_scores self.values np.sqrt(2 * np.log(t) / self.counts) return int(np.argmax(ucb_scores)) def update(self, item_id, reward): 根据反馈更新统计。 self.counts[item_id] 1 n self.counts[item_id] value self.values[item_id] # 增量式更新平均值 self.values[item_id] ((n - 1) / n) * value (1 / n) * reward再实现 Epsilon-Greedy# 文件路径strategies/epsilon_greedy.py import random import numpy as np class EpsilonGreedy: Epsilon-Greedy以固定概率随机探索。 def __init__(self, n_items, epsilon0.1): self.n_items n_items self.epsilon epsilon self.counts np.zeros(n_items) self.values np.zeros(n_items) def select(self, t): if random.random() self.epsilon: return random.randint(0, self.n_items - 1) return int(np.argmax(self.values)) def update(self, item_id, reward): self.counts[item_id] 1 n self.counts[item_id] value self.values[item_id] self.values[item_id] ((n - 1) / n) * value (1 / n) * reward最后写一个批量实验脚本对比 UCB1、Epsilon-Greedy 和一个“纯利用”基线每次都选当前估计均值最高的选项# 文件路径run_experiment.py import random import numpy as np from agent_search_env import SearchEnv from strategies.ucb1 import UCB1 from strategies.epsilon_greedy import EpsilonGreedy class GreedyBaseline: 基线纯利用每次都选择当前均值最高的选项。 def __init__(self, n_items): self.n_items n_items self.counts np.zeros(n_items) self.values np.zeros(n_items) def select(self, t): return int(np.argmax(self.values)) def update(self, item_id, reward): self.counts[item_id] 1 n self.counts[item_id] value self.values[item_id] self.values[item_id] ((n - 1) / n) * value (1 / n) * reward def run_once(strategy_class, env, budget, **kwargs): 运行一轮实验返回累计点击数和每个策略的奖金列表。 random.seed(0) np.random.seed(0) env SearchEnv(seed0) n_items env.n_items strategy strategy_class(n_items, **kwargs) total_reward 0 rewards [] for t in range(1, budget 1): item_id strategy.select(t) reward env.reward(item_id) strategy.update(item_id, reward) total_reward reward rewards.append(total_reward) return total_reward, rewards if __name__ __main__: budget 2000 env SearchEnv(seed0) print(真实点击率, np.round(env.get_true_ctr(), 4)) print(最优项, int(np.argmax(env.get_true_ctr()))) print(预算, budget) print(- * 50) ucb_total, ucb_rewards run_once(UCB1, env, budget) eps_total, eps_rewards run_once(EpsilonGreedy, env, budget, epsilon0.1) greedy_total, greedy_rewards run_once(GreedyBaseline, env, budget) print(f纯利用基线累计点击数{greedy_total}) print(fEpsilon-Greedy(0.1) 累计点击数{eps_total}) print(fUCB1 累计点击数{ucb_total})这段代码做了三件事建立了一个可重复的模拟环境固定随机种子保证结果可复现实现了三种策略并统一了select(t)和update(item_id, reward)接口在同一个环境里跑同样预算的多次请求输出累计点击数作为对比指标。需要提醒的是代码里的run_once为了简化复用了同一个 seed实际实验中应该用多组随机种子取平均否则结论容易受单次随机性影响。这一点在下一节会继续讲。7. 运行结果与效果验证如何判断策略是否更优运行上节的脚本后你会有类似这样的输出具体数值会因版本和随机种子略有不同真实点击率 [0.021 0.034 0.118 0.067 0.049 0.186 0.092 0.041 0.144 0.109] 最优项 5 预算 2000 -------------------------------------------------- 纯利用基线累计点击数 152 Epsilon-Greedy(0.1) 累计点击数 178 UCB1 累计点击数 194这是一个非常典型的实验结果。三种策略里纯利用基线只依赖早期几次尝试的结果如果早期某个选项碰巧拿到一次点击它就会长期占据高位如果早期最优项没有获得点击它可能永远没有被充分探索的机会。这是“纯利用”在在线决策场景中最致命的缺陷——不是效果差而是很可能永远找不到最优项。Epsilon-Greedy 因为有一段固定比例的随机流量提高了探索覆盖度所以累计点击数通常优于纯利用。UCB1 的探索机制是有方向的它倾向于把尝试次数花在“均值高或不确定度高”的选项上因此在同样的预算下累计点击数一般会更高。单次实验的数值只能说明趋势不能当作严谨结论。正确的验证方式是固定预算使用多组随机种子重复实验观察累计点数的均值和方差。每组种子里环境可以随机生成真实点击率策略的执行顺序也受种子影响。这样能避免“这个策略只是运气好”的错觉。除了累计点击数还有一个更值得关注的评估维度累积遗憾Cumulative Regret。累计遗憾的定义是如果每一步都选择真实点击率最高的那个选项理论上能获得的总点击次数减去当前策略实际获得的总点击次数。遗憾越低说明策略越接近“预算用在了刀刃上”。对预算受限场景来说累计遗憾几乎是比绝对点击数更敏感的指标因为它直接量化了“因为未知而错失的收益”。我在项目实践中发现很多团队在评估探索策略时只盯着 A/B Test 的显著性却忽略了一个问题A/B Test 本身的预算也是有限的。如果探索策略在前 1000 次请求里表现不佳但在 5000 次后显著反超而你的评测周期只有 2000 次预算那从业务视角来看这个策略就是“不可用”的。所以预算受限场景下的策略评估一定要把预算范围写进评估指标而不是默认“只要样本量够大就能检测出差异”。8. 常见问题与排查方法理论再清晰落地时也一定会遇到各种问题。我整理了智能体搜索中探索-利用机制最常见的五类问题和排查思路。问题现象可能原因排查方式解决方案探索流量太多线上核心指标明显下降epsilon 或探索概率设置过高查看探索流量占比和分桶指标降低初始探索比例改为动态衰减的探索率探索了很久最优项始终没被找到候选集合过大或奖励信号太稀疏检查每个候选的平均尝试次数和 reward 方差引入候选过滤或层次化探索先粗筛再细探UCB1 后期探索彻底停止某个选项尝试次数大置信上界收紧其他选项上界始终更低查看 counts 分布和各选项上界分数检查是否需要对非最优选项强制最小探索比例线上反馈噪声大策略频繁切换奖励波动导致均值估计不稳定查看滑动窗口内的均值变化使用 Thompson Sampling 替代确定性策略探索策略和离线评测结论矛盾离线数据集缺少探索轨迹样本分布有偏检查离线数据是否覆盖探索策略的返回结果建立带探索日志的数据管线让离线反馈能模拟在线分布这些问题里有几个是新手特别容易踩的。第一个坑是“探索比例拍脑袋”。很多团队把 epsilon 设成固定值比如 0.1然后上线后发现核心指标掉了就把 epsilon 调成 0.01再跑一轮来回折腾。更合理的做法是先设定一个“可接受的指标损失上限”倒推探索比例。比如你的核心指标允许掉 0.5%那就先用离线模拟或小流量试出探索比例和指标损失之间的关系再决定正式值。第二个坑是“只探索不沉淀”。探索的目的是获取信息获取信息的目的是改进决策。如果你的探索策略只是把结果记录到日志里却没有人、没有流程去消费这些日志那探索就是在烧预算。一个合格的探索机制至少要配套一个“探索结果分析任务”定期查看哪些内容被尝试过、哪些内容显著优于当前最优、哪些内容被证明无效需要下线。第三个坑是“把探索和业务规则隔离”。搜索系统里通常已经有大量业务规则比如类目兜底、新品保护、风险内容过滤。探索策略不应该脱离这些规则独立运行。如果一条内容因为合规原因不能被展示那么任何探索策略都不应该尝试它。探索的边界必须由业务规则定义而不是由数学公式定义。9. 最佳实践预算分配、日志埋点与安全边界聊完了机制和排错最后给出一套可以落地的工程规范。这些规范来自我参与过的搜索策略类项目不一定适合所有团队但方向是通用的。9.1 预算分配先给下限再给上限预算分配是预算受限场景的第一步也是最容易被忽略的一步。我的建议是不要直接把总预算除以天数得出“每天固定流量”而是把预算拆成两层。第一层是“探索下限”。这个下限保证每一个候选内容、每一个新策略在最坏情况下也能获得最小可用的尝试次数。没有这个下限冷启动问题就永远解决不了。第二层是“探索上限”。这个上限保护线上指标防止探索流量过度挤占核心收益。常见做法是设置一个动态上限它与当前策略的总收益挂钩收益越差探索上限越低收益越好探索上限可以适度放宽。一句话总结下限用来保证“有机会发现更好的”上限用来保证“不会因为探索而翻车”。9.2 日志埋点必须记录决策原因探索策略上线后日志系统要能从一次曝光记录里还原出“当时为什么选了这个 item”。这不是简单的请求参数而是决策过程本身的记录。建议至少埋以下字段请求 ID、用户 ID、时间戳候选列表和最终返回列表本次决策使用的是哪个策略ucb1 / epsilon_greedy / thompson_sampling当前探索概率或不确定性分数每个候选的均值估计、尝试次数和上界分数。有了这些数据你就可以在事后复盘时回答一个核心问题某一次探索是合理的尝试还是策略 bug 导致的选择错误。没有决策日志的探索系统出了问题只能靠猜。{ request_id: req_20250101_001, ts: 1735689600, user_id: u_1001, strategy: ucb1, candidates: [ {doc_id: d_01, estimate: 0.052, tries: 120, ucb_score: 0.087}, {doc_id: d_05, estimate: 0.183, tries: 30, ucb_score: 0.191} ], selected: d_05 }上面的 JSON 是一个简化示例实际生产环境字段会更多但核心是同一个你要能证明每一次决策都是“有依据的探索”而不是随机乱试。9.3 安全边界探索不能绕过权限与合规这一点必须单独强调。探索机制最容易出现的失控是“为了获取数据而忽略了业务红线”。在实际项目中至少要建立三个安全边界内容安全所有候选内容在进入探索池之前必须通过合规审核探索机制不能绕过内容过滤、权限校验、频控策略用户隐私探索日志中的数据要按最小化原则收集涉及用户行为的数据必须脱敏操作安全探索策略的更新和回滚必须走配置中心或灰度发布流程不能在线上直接改代码。如果你的探索策略需要在生产环境上直接调整参数请务必先在测试环境用离线模拟验证再通过配置中心灰度发布。9.4 迭代流程小步快跑持续收集反馈探索策略本身也需要迭代。我建议采用下面这种循环节奏设定一个明确的业务目标比如“新内容冷启动成功率提升 10%”“策略探索成本下降 20%”选择一种合适的策略上线记录基线和探索日志每 2-3 天做一次探索日志分析重点看探索比例、尝试次数分布、探索到的最优项根据分析结果微调 epsilon、置信区间参数或候选过滤规则每 1-2 周做一次完整的策略评审决定是继续放量、收缩还是回滚。这套循环的核心不是“找到最优算法”而是“让探索过程变成团队可观测、可控制、可改进的工程流程”。10. 总结与延伸从“调参”到“建立探索机制”这篇文章从“预算受限下的智能体搜索”这个题目切入重点讲了三件事第一智能体搜索的探索与利用本质是一个预算分配问题而不是模型精度问题。系统每一次决策都在“已知的收益”和“未知的信息”之间做选择预算决定了这个选择的空间有多大。第二Epsilon-Greedy、UCB、Thompson Sampling 这些经典策略提供了不同风格的回答。UCB 偏向有方向的确定性探索Epsilon-Greedy 偏向简单稳重的随机探索Thompson Sampling 偏向概率化的平滑探索。在实际工程里没有“万能策略”只有“适合当前约束的策略”。第三探索策略要真正落地必须配套完整的预算分配、决策日志、安全边界和迭代流程。数学上再漂亮的算法如果没有日志、没有回滚方案、没有合规边界都只能停在离线实验阶段。下一步你可以做这样几件事拿一份真实的搜索或推荐日志统计一下当前系统的“探索覆盖率”用第 6 节的代码框架跑一组对比实验看看 UCB 和 Epsilon-Greedy 在你自己的数据分布下表现如何最后从最小的探索比例开始把它接入到你的策略评测系统里观察它是否改变了团队的决策方式。预算受限不是一个需要绕开的障碍它就是智能体搜索最现实的约束条件。理解了这一点你就能在每次“到底是继续吃老本还是试点新东西”的纠结里找到一个可以量化、可以执行、可以复盘的回答。 预算受限的智能体搜索：探索与利用策略的权衡与实现
先问一个很多搜索、推荐、广告团队都遇到过的问题线上策略已经稳定跑了一段时间头部内容贡献了大部分点击这时候算法工程师提了一个新方案你到底是直接上线上 A/B Test还是先在离线数据集上反复调参很多人会下意识选择后者原因是“线上流量太贵了不敢随便试”。但这个决定本身就隐含了一个权衡——你在用“少做尝试”换“确定性收益”也就是在用未来的信息增长换当下的稳定报表。这正是搜索系统、推荐系统、乃至大模型 Agent 在真实业务里每天都要面对的难题探索Exploration与利用Exploitation的冲突。过去我们处理这个问题基本靠经验新方案先小流量老方案保大盘。可真到了预算有限、流量有限、试错成本极高的场景里这种“拍脑袋分配”的方式就开始失控了。这篇文章想聊清楚一件事在预算受限的前提下智能体搜索如何做到“更充分地利用已有信息更聪明地探索未知空间”。我会从决策理论的视角把探索和利用的权衡拆开讲透然后用 Python 实现一个最小可运行的实验环境对比几种常见策略的效果最后给出工程落地的建议和避坑清单。读完你至少能回答三个问题我的搜索系统为什么要做探索预算到底怎么分配才合理以及用 UCB、Epsilon-Greedy 这类策略时真正的坑在哪里。1. 这篇文章真正要解决的问题先说结论预算受限下的智能体搜索本质不是“换一个更好的召回模型”或者“堆更多的算力”而是要在有限的尝试次数里把“不确定性”折算成可计算的成本再决定每一次请求到底该走“追求收益最大化”的路线还是“探索新信息”的路线。很多团队的问题在于把探索和利用当成了两个互相独立的阶段平时闷头做利用等到需要评测新策略时才临时开一个探索通道。这种做法的问题非常明显探索成本不可控要么流量给多了伤线上指标要么流量给少了统计不显著探索结果不可复用试过的经验散落在实验报告里没有沉淀成搜索策略的一部分预算没有参与决策探索流量是“固定拨给”的而不是根据不确定性动态分配的。如果只是站在“调参工程师”的角度这些问题都能靠人工安排来兜底。但当你面对的是一个自主决策的智能体时人工兜底就失效了。智能体搜索里的“智能体”可以是推荐系统里的排序模块可以是大模型 Agent 里的工具选择器也可以是一个自动定价策略。它必须自己在每轮决策中回答这次调用是继续用当前最优策略还是尝试一个可能更好但不确定的新策略。这篇文章要解决的问题就是把这个“自己回答”的过程变成可工程实现的机制。我会先解释探索和利用的理论背景再说明预算约束为什么是核心难点接着给出三种典型策略的对比和代码实现最后讨论如何评估、上线和监控这类策略。适合的读者包括正在做搜索、推荐、广告排序的算法工程师给大模型 Agent 设计工具调用和检索策略的开发者负责策略评测、A/B Test 平台、成本控制的数据团队以及所有需要在“试错”和“收敛”之间找平衡的技术负责人。如果你只是想看一个能跑的代码示例可以直接跳到第 6 节。但建议还是先花五分钟把前四节读完否则你很难理解为什么一个小小的探索函数值得在整个策略体系里占据这么重要的位置。2. 智能体搜索的底层逻辑从“找内容”到“做决策”很多人第一次听到“智能体搜索”这个词会以为它只是在搜索框后面接一个大模型或者给搜索结果加一个 AI 摘要。这是把“智能体”理解得太窄了。在决策智能的视角下搜索系统本质上是一个在不确定环境中做连续决策的智能体它接收用户的查询从候选集合中挑选内容观察用户的反馈点击、停留、转化然后更新自己对内容质量的估计再继续下一次决策。整个过程其实是一个不断“试错-学习-再试错”的循环。传统搜索引擎倾向于隐藏这个循环系统把所有候选内容按相关性打分取 topK 返回给用户然后把用户行为记录下来离线训练模型定期更新线上策略。这个流程的问题是模型训练和数据收集之间存在明显的时间差而且系统默认“当前模型已经足够好”没有给真正的探索留出空间。智能体搜索和传统搜索的关键区别不在于用了什么模型而在于它是否具备在线决策能力。这里有一个更准确的判断如果一次搜索请求的返回结果只依赖当前模型的打分没有任何随机性、不确定度估计或探索机制那么无论模型多复杂这个系统仍然不是“智能体式”的它只是一个函数。只有当系统能基于历史反馈动态调整下一次返回策略并且在必要时主动尝试低置信度的高潜力内容时它才真正进入了智能体搜索的范畴。这样做的好处是显而易见的系统不再是“后知后觉”地等待离线训练而是能在线感知内容质量的变化对新内容、新商品、新文档系统可以通过少量试探快速积累数据对用户兴趣的漂移系统可以更快响应而不是死死抱住历史统计不放。代价也很明显每一次探索都可能带来一次次优的用户体验。这就是为什么探索和利用的权衡会成为智能体搜索绕不开的核心问题。3. 探索与利用的权衡不是一次抉择而是连续决策探索Exploration和利用Exploitation的概念最早来自强化学习和多臂老虎机Multi-Armed Bandit问题。用一个场景来理解最直观假设你现在管理一个搜索结果页有 10 个候选位置每个位置可以放不同类型的摘要格式。你已经知道格式 A 的点击率稳定在 5%而格式 B、C、D 因为数据量太少点击率估计很不准——可能是 1%也可能是 10%。这时候来了一次新请求你选择 A 还是 B选 A是利用Exploitation基于当前已知信息做最优选择收益确定但没有新增信息选 B是探索Exploration收益不确定但如果 B 真的更好你不仅拿到了这单次的收益还获得了“B 值得继续用”这个信息。这里最容易产生的误解是探索和利用是一次性的二元选择。实际上在连续决策中你既不是“纯探索”也不是“纯利用”而是在每一轮根据最新的信息重新评估哪些选项的不确定性最大哪些选项的期望收益最高然后决定是否值得为不确定性买单。新手的另一个常见误区是把“探索”等同于“随机”。随机策略确实是探索的一种但不是好探索。好的探索应该有明确的目标——降低对未知选项估计的不确定性并且把有限的尝试次数花在最值得试探的选项上。完全随机的探索本质上是在均匀地浪费预算。所以探索与利用权衡的正确理解方式应该是每一轮决策都在做一次不确定性投资。投资对象是“尚未被验证但可能更优的选项”投资预算是“容忍一次次优反馈的能力”投资收益是“未来决策中信息增益带来的长期回报”。4. 预算受限约束条件如何改变问题本质如果探索和利用只是多臂老虎机里的一个理论问题那解决它并不难——给足试验次数任何策略都能慢慢收敛到最优。但真实业务里的约束条件让这个问题一下子变得棘手起来。我把它总结为四类预算第一类流量预算。这在搜索排序和广告系统里最典型。一个日均千万请求的搜索系统你可以拨出 5% 的流量做探索但当业务要求新内容冷启动、新策略验证、节假日流量突变同时发生时5% 和 1% 之间的抉择直接关系到 KPI。流量预算的本质是你能承受多少次“可能不如当前最优策略”的线上交互。第二类Api 调用预算 / Token 预算。这是大模型 Agent 场景下的新约束。如果你的搜索智能体需要调用外部工具、外部知识库或者大模型接口每一次探索都会产生真实的费用。很多团队在做 Agent 工具评测时都会遇到“想多试几个方案但 API 账单不允许”的窘境。这时候探索策略的价值就不只是效果提升而是实打实地省钱。第三类时间预算。新内容从入库到获得足够曝光中间需要多长时间如果系统完全没有探索机制一条新内容可能永远得不到展示机会。反过来如果探索机制过于激进可能在用户还没建立认知之前就把内容的生命周期耗尽了。时间预算考验的是策略的“耐心”。第四类人力预算。每一次探索都意味着后续要有人分析数据、判断结果、决定是否放量。如果一个探索策略产生了大量需要人工介入的异常 case那它的工程成本可能会远超它的收益。预算约束之所以深刻是因为它把“最优策略”变成了“预算分配策略”。在无约束环境下最优策略是唯一的——尽可能多探索最终收敛到全局最优。在有约束环境下最优策略变成了在预算耗尽之前最大化信息增益和收益的加权组合。这两个问题在数学上难度完全不同在日常决策中的指导意义也完全不同。理解了这一点再看市面上的搜索策略你就会明白为什么单纯追求“模型精度”是不够的。一个在离线评测里 AUC 很高的模型如果没有考虑探索预算线上效果可能反而不如一个“稍微欠拟合但允许探索”的模型。这不是模型本身的问题而是决策框架的问题。5. 三种常用策略Epsilon-Greedy、UCB 与 Thompson Sampling在预算受限的场景里有几种经典的在线决策策略值得掌握。它们各有侧重适合的约束条件也不同。我先把对比放在这里后面再逐一解释。策略核心思想探索方式适合场景主要风险Epsilon-Greedy以固定概率 epsilon 随机探索其余时间利用随机流量充足、探索成本低探索太盲目浪费预算UCB1按“均值 不确定度上界”选择确定性选择高潜力项需要快速识别最优项对奖励分布敏感冷启动需处理Thompson Sampling按后验概率分布随机采样后选择概率采样贝叶斯奖励噪声大、需要平滑决策先验假设影响大实现略复杂Epsilon-Greedy 是最容易理解的策略。它的思路是每次决策时以概率 epsilon 随机选一个非当前最优的选项以 1-epsilon 的概率选当前已知最优的选项。这个策略实现简单但问题也很明显随机探索完全忽略了“哪些选项更值得探索”所以预算利用率低。在预算受限场景下epsilon 设多少本身就是一个需要反复调参的问题。UCB1Upper Confidence Bound是另一个经典策略。它的选择逻辑是对每个选项计算一个“置信上界”上界由两部分组成——当前估计的均值加上一个与尝试次数相关的奖励项。已经验证过很多次且效果好的选项均值分高尝试次数少、不确定度高的选项上界分高。UCB1 会优先选择上界最高的选项在“已知的好”和“可能的好”之间自动做平衡。它的优点是探索方向有目的性缺点是冷启动阶段所有选项尝试次数都少时行为会接近纯随机。Thompson Sampling 是贝叶斯方法的代表。它假设每个选项的奖励服从某个概率分布通常用 Beta 分布每次决策时先从每个选项的后验分布中采样一个值然后选择采样值最大的选项。因为采样过程天然带有随机性Thompson Sampling 的探索更平滑在噪声大的环境下通常比 UCB 更稳定。它也更接近“人类直觉”每次决策前先在心里对每个选项的潜力做一个概率判断然后按判断行事。这里给出一个非常实际的选择建议如果你的预算很低希望在头几百次尝试内尽量不翻车Epsilon-Greedy 用小的 epsilon比如 0.05-0.1更稳如果预算中等且候选选项数量可控UCB1 的上界机制能帮你更快找到最优项如果奖励噪声大、候选多、且你能接受一定的计算复杂度Thompson Sampling 通常表现最好如果你的场景里混入了大量低质量选项任何纯探索策略都可能浪费预算此时应该在探索前先加一层“候选过滤”。6. 最小实现在 Python 里模拟一个预算受限的智能体搜索下面我们用代码把上面的策略跑起来。场景假设如下有一个搜索服务候选内容池里有 10 个内容项每个内容项都有一个真实的“点击率”但系统并不知道这个点击率只能通过每次请求后的用户反馈点击或不点击来估计。我们有一个总预算请求次数目标是在预算内最大化总点击次数。先写一个搜索环境的模拟类# 文件路径agent_search_env.py import random import numpy as np class SearchEnv: 模拟一个搜索环境10个候选结果每个有真实点击率。 def __init__(self, n_items10, seed42): self.n_items n_items self.rng np.random.RandomState(seed) # 真实点击率用 Beta 分布生成范围大致在 0.01 ~ 0.2 之间 self.true_ctr self.rng.beta(2, 20, sizen_items) def get_true_ctr(self): return self.true_ctr def reward(self, item_id): 请求一次返回是否点击1/0。 p max(0.0, min(1.0, self.true_ctr[item_id])) return 1 if random.random() p else 0注意这里用true_ctr表示内容项的真实质量策略只能通过 reward 反馈来间接估计它。这是在线决策问题的标准抽象环境是未知的决策者只能观察反馈。接着实现两种探索策略UCB1 和 Epsilon-Greedy。先写 UCB1# 文件路径strategies/ucb1.py import numpy as np class UCB1: UCB1 策略均值 置信上界。 def __init__(self, n_items): self.n_items n_items self.counts np.zeros(n_items) # 每个选项被尝试的次数 self.values np.zeros(n_items) # 每个选项的平均奖励估计 def select(self, t): 给定当前总步数 t选择下一个要尝试的 item_id。 # 每个选项至少尝试一次避免除零 for item_id in range(self.n_items): if self.counts[item_id] 0: return item_id # UCB1 上界均值 sqrt(2 * ln(t) / count) ucb_scores self.values np.sqrt(2 * np.log(t) / self.counts) return int(np.argmax(ucb_scores)) def update(self, item_id, reward): 根据反馈更新统计。 self.counts[item_id] 1 n self.counts[item_id] value self.values[item_id] # 增量式更新平均值 self.values[item_id] ((n - 1) / n) * value (1 / n) * reward再实现 Epsilon-Greedy# 文件路径strategies/epsilon_greedy.py import random import numpy as np class EpsilonGreedy: Epsilon-Greedy以固定概率随机探索。 def __init__(self, n_items, epsilon0.1): self.n_items n_items self.epsilon epsilon self.counts np.zeros(n_items) self.values np.zeros(n_items) def select(self, t): if random.random() self.epsilon: return random.randint(0, self.n_items - 1) return int(np.argmax(self.values)) def update(self, item_id, reward): self.counts[item_id] 1 n self.counts[item_id] value self.values[item_id] self.values[item_id] ((n - 1) / n) * value (1 / n) * reward最后写一个批量实验脚本对比 UCB1、Epsilon-Greedy 和一个“纯利用”基线每次都选当前估计均值最高的选项# 文件路径run_experiment.py import random import numpy as np from agent_search_env import SearchEnv from strategies.ucb1 import UCB1 from strategies.epsilon_greedy import EpsilonGreedy class GreedyBaseline: 基线纯利用每次都选择当前均值最高的选项。 def __init__(self, n_items): self.n_items n_items self.counts np.zeros(n_items) self.values np.zeros(n_items) def select(self, t): return int(np.argmax(self.values)) def update(self, item_id, reward): self.counts[item_id] 1 n self.counts[item_id] value self.values[item_id] self.values[item_id] ((n - 1) / n) * value (1 / n) * reward def run_once(strategy_class, env, budget, **kwargs): 运行一轮实验返回累计点击数和每个策略的奖金列表。 random.seed(0) np.random.seed(0) env SearchEnv(seed0) n_items env.n_items strategy strategy_class(n_items, **kwargs) total_reward 0 rewards [] for t in range(1, budget 1): item_id strategy.select(t) reward env.reward(item_id) strategy.update(item_id, reward) total_reward reward rewards.append(total_reward) return total_reward, rewards if __name__ __main__: budget 2000 env SearchEnv(seed0) print(真实点击率, np.round(env.get_true_ctr(), 4)) print(最优项, int(np.argmax(env.get_true_ctr()))) print(预算, budget) print(- * 50) ucb_total, ucb_rewards run_once(UCB1, env, budget) eps_total, eps_rewards run_once(EpsilonGreedy, env, budget, epsilon0.1) greedy_total, greedy_rewards run_once(GreedyBaseline, env, budget) print(f纯利用基线累计点击数{greedy_total}) print(fEpsilon-Greedy(0.1) 累计点击数{eps_total}) print(fUCB1 累计点击数{ucb_total})这段代码做了三件事建立了一个可重复的模拟环境固定随机种子保证结果可复现实现了三种策略并统一了select(t)和update(item_id, reward)接口在同一个环境里跑同样预算的多次请求输出累计点击数作为对比指标。需要提醒的是代码里的run_once为了简化复用了同一个 seed实际实验中应该用多组随机种子取平均否则结论容易受单次随机性影响。这一点在下一节会继续讲。7. 运行结果与效果验证如何判断策略是否更优运行上节的脚本后你会有类似这样的输出具体数值会因版本和随机种子略有不同真实点击率 [0.021 0.034 0.118 0.067 0.049 0.186 0.092 0.041 0.144 0.109] 最优项 5 预算 2000 -------------------------------------------------- 纯利用基线累计点击数 152 Epsilon-Greedy(0.1) 累计点击数 178 UCB1 累计点击数 194这是一个非常典型的实验结果。三种策略里纯利用基线只依赖早期几次尝试的结果如果早期某个选项碰巧拿到一次点击它就会长期占据高位如果早期最优项没有获得点击它可能永远没有被充分探索的机会。这是“纯利用”在在线决策场景中最致命的缺陷——不是效果差而是很可能永远找不到最优项。Epsilon-Greedy 因为有一段固定比例的随机流量提高了探索覆盖度所以累计点击数通常优于纯利用。UCB1 的探索机制是有方向的它倾向于把尝试次数花在“均值高或不确定度高”的选项上因此在同样的预算下累计点击数一般会更高。单次实验的数值只能说明趋势不能当作严谨结论。正确的验证方式是固定预算使用多组随机种子重复实验观察累计点数的均值和方差。每组种子里环境可以随机生成真实点击率策略的执行顺序也受种子影响。这样能避免“这个策略只是运气好”的错觉。除了累计点击数还有一个更值得关注的评估维度累积遗憾Cumulative Regret。累计遗憾的定义是如果每一步都选择真实点击率最高的那个选项理论上能获得的总点击次数减去当前策略实际获得的总点击次数。遗憾越低说明策略越接近“预算用在了刀刃上”。对预算受限场景来说累计遗憾几乎是比绝对点击数更敏感的指标因为它直接量化了“因为未知而错失的收益”。我在项目实践中发现很多团队在评估探索策略时只盯着 A/B Test 的显著性却忽略了一个问题A/B Test 本身的预算也是有限的。如果探索策略在前 1000 次请求里表现不佳但在 5000 次后显著反超而你的评测周期只有 2000 次预算那从业务视角来看这个策略就是“不可用”的。所以预算受限场景下的策略评估一定要把预算范围写进评估指标而不是默认“只要样本量够大就能检测出差异”。8. 常见问题与排查方法理论再清晰落地时也一定会遇到各种问题。我整理了智能体搜索中探索-利用机制最常见的五类问题和排查思路。问题现象可能原因排查方式解决方案探索流量太多线上核心指标明显下降epsilon 或探索概率设置过高查看探索流量占比和分桶指标降低初始探索比例改为动态衰减的探索率探索了很久最优项始终没被找到候选集合过大或奖励信号太稀疏检查每个候选的平均尝试次数和 reward 方差引入候选过滤或层次化探索先粗筛再细探UCB1 后期探索彻底停止某个选项尝试次数大置信上界收紧其他选项上界始终更低查看 counts 分布和各选项上界分数检查是否需要对非最优选项强制最小探索比例线上反馈噪声大策略频繁切换奖励波动导致均值估计不稳定查看滑动窗口内的均值变化使用 Thompson Sampling 替代确定性策略探索策略和离线评测结论矛盾离线数据集缺少探索轨迹样本分布有偏检查离线数据是否覆盖探索策略的返回结果建立带探索日志的数据管线让离线反馈能模拟在线分布这些问题里有几个是新手特别容易踩的。第一个坑是“探索比例拍脑袋”。很多团队把 epsilon 设成固定值比如 0.1然后上线后发现核心指标掉了就把 epsilon 调成 0.01再跑一轮来回折腾。更合理的做法是先设定一个“可接受的指标损失上限”倒推探索比例。比如你的核心指标允许掉 0.5%那就先用离线模拟或小流量试出探索比例和指标损失之间的关系再决定正式值。第二个坑是“只探索不沉淀”。探索的目的是获取信息获取信息的目的是改进决策。如果你的探索策略只是把结果记录到日志里却没有人、没有流程去消费这些日志那探索就是在烧预算。一个合格的探索机制至少要配套一个“探索结果分析任务”定期查看哪些内容被尝试过、哪些内容显著优于当前最优、哪些内容被证明无效需要下线。第三个坑是“把探索和业务规则隔离”。搜索系统里通常已经有大量业务规则比如类目兜底、新品保护、风险内容过滤。探索策略不应该脱离这些规则独立运行。如果一条内容因为合规原因不能被展示那么任何探索策略都不应该尝试它。探索的边界必须由业务规则定义而不是由数学公式定义。9. 最佳实践预算分配、日志埋点与安全边界聊完了机制和排错最后给出一套可以落地的工程规范。这些规范来自我参与过的搜索策略类项目不一定适合所有团队但方向是通用的。9.1 预算分配先给下限再给上限预算分配是预算受限场景的第一步也是最容易被忽略的一步。我的建议是不要直接把总预算除以天数得出“每天固定流量”而是把预算拆成两层。第一层是“探索下限”。这个下限保证每一个候选内容、每一个新策略在最坏情况下也能获得最小可用的尝试次数。没有这个下限冷启动问题就永远解决不了。第二层是“探索上限”。这个上限保护线上指标防止探索流量过度挤占核心收益。常见做法是设置一个动态上限它与当前策略的总收益挂钩收益越差探索上限越低收益越好探索上限可以适度放宽。一句话总结下限用来保证“有机会发现更好的”上限用来保证“不会因为探索而翻车”。9.2 日志埋点必须记录决策原因探索策略上线后日志系统要能从一次曝光记录里还原出“当时为什么选了这个 item”。这不是简单的请求参数而是决策过程本身的记录。建议至少埋以下字段请求 ID、用户 ID、时间戳候选列表和最终返回列表本次决策使用的是哪个策略ucb1 / epsilon_greedy / thompson_sampling当前探索概率或不确定性分数每个候选的均值估计、尝试次数和上界分数。有了这些数据你就可以在事后复盘时回答一个核心问题某一次探索是合理的尝试还是策略 bug 导致的选择错误。没有决策日志的探索系统出了问题只能靠猜。{ request_id: req_20250101_001, ts: 1735689600, user_id: u_1001, strategy: ucb1, candidates: [ {doc_id: d_01, estimate: 0.052, tries: 120, ucb_score: 0.087}, {doc_id: d_05, estimate: 0.183, tries: 30, ucb_score: 0.191} ], selected: d_05 }上面的 JSON 是一个简化示例实际生产环境字段会更多但核心是同一个你要能证明每一次决策都是“有依据的探索”而不是随机乱试。9.3 安全边界探索不能绕过权限与合规这一点必须单独强调。探索机制最容易出现的失控是“为了获取数据而忽略了业务红线”。在实际项目中至少要建立三个安全边界内容安全所有候选内容在进入探索池之前必须通过合规审核探索机制不能绕过内容过滤、权限校验、频控策略用户隐私探索日志中的数据要按最小化原则收集涉及用户行为的数据必须脱敏操作安全探索策略的更新和回滚必须走配置中心或灰度发布流程不能在线上直接改代码。如果你的探索策略需要在生产环境上直接调整参数请务必先在测试环境用离线模拟验证再通过配置中心灰度发布。9.4 迭代流程小步快跑持续收集反馈探索策略本身也需要迭代。我建议采用下面这种循环节奏设定一个明确的业务目标比如“新内容冷启动成功率提升 10%”“策略探索成本下降 20%”选择一种合适的策略上线记录基线和探索日志每 2-3 天做一次探索日志分析重点看探索比例、尝试次数分布、探索到的最优项根据分析结果微调 epsilon、置信区间参数或候选过滤规则每 1-2 周做一次完整的策略评审决定是继续放量、收缩还是回滚。这套循环的核心不是“找到最优算法”而是“让探索过程变成团队可观测、可控制、可改进的工程流程”。10. 总结与延伸从“调参”到“建立探索机制”这篇文章从“预算受限下的智能体搜索”这个题目切入重点讲了三件事第一智能体搜索的探索与利用本质是一个预算分配问题而不是模型精度问题。系统每一次决策都在“已知的收益”和“未知的信息”之间做选择预算决定了这个选择的空间有多大。第二Epsilon-Greedy、UCB、Thompson Sampling 这些经典策略提供了不同风格的回答。UCB 偏向有方向的确定性探索Epsilon-Greedy 偏向简单稳重的随机探索Thompson Sampling 偏向概率化的平滑探索。在实际工程里没有“万能策略”只有“适合当前约束的策略”。第三探索策略要真正落地必须配套完整的预算分配、决策日志、安全边界和迭代流程。数学上再漂亮的算法如果没有日志、没有回滚方案、没有合规边界都只能停在离线实验阶段。下一步你可以做这样几件事拿一份真实的搜索或推荐日志统计一下当前系统的“探索覆盖率”用第 6 节的代码框架跑一组对比实验看看 UCB 和 Epsilon-Greedy 在你自己的数据分布下表现如何最后从最小的探索比例开始把它接入到你的策略评测系统里观察它是否改变了团队的决策方式。预算受限不是一个需要绕开的障碍它就是智能体搜索最现实的约束条件。理解了这一点你就能在每次“到底是继续吃老本还是试点新东西”的纠结里找到一个可以量化、可以执行、可以复盘的回答。