1. 为什么我们要让 AI agent 来碰 Elasticsearch 的查询优化
Elasticsearch 的性能调优这件事，做过的人都知道，它属于那种"看起来有章可循，实际上处处是坑"的活。官方文档给了一堆参数，什么refresh_interval、translog.durability、indexing_pressure、search.thread_pool，但真正落到一个具体的业务查询上，到底该调哪个、调到多少，往往靠的是老司机的直觉加反复试错。我在过去几年里接手过不少"查询慢得离谱"的集群，排查下来十有八九不是硬件不够，而是查询 DSL 写得有问题——要么是wildcard前缀通配把倒排索引当成了全文扫描器，要么是聚合层级嵌套太深导致global_ordinals爆内存，要么是分片数拍脑袋定了个 50，结果每个分片就那么点数据，协调节点光做 merge 就累死了。
问题在于，人工调优的迭代速度太慢了。你改一个参数，重启或者等_settings生效，跑一轮压测，看_nodes/stats和_search的 profile 输出，分析瓶颈，再改下一个。一轮下来半小时没了，一天能试的方案也就十来个。而 Elasticsearch 的调优空间是组合爆炸的——光是查询层面的bool子句顺序、filter与must的取舍、track_total_hits的开关、size与from的分页策略，再加上索引层面的 mapping 设计、分片路由、段合并策略，组合起来轻松上千种。人工试，试到明年也试不完。
所以让 AI agent 来干这件事，逻辑上非常顺：agent 可以 7x24 小时不间断地生成查询变体、跑基准测试、读指标、根据反馈调整下一轮方案。它不会累，不会因为连续失败十次就心态崩了，也不会因为"我觉得这个参数应该行"而产生确认偏误。但这里有个致命的前提——你必须给它一套可信的基准测试框架。否则 agent 会陷入一种很危险的状态：它优化的是它自己以为的指标，而不是你真正关心的延迟和吞吐。这就是标题里那句话的由来："信任，但要进行基准测试"。信任 agent 的探索能力，但绝不信任它未经基准验证的结论。
这篇文章适合两类人看：一类是正在被 Elasticsearch 查询性能折磨、想引入自动化手段的后端或搜索工程师；另一类是对 AI agent 落地感兴趣、想看看 agent 在真实基础设施优化场景里到底怎么搭、怎么用、会踩什么坑的开发者。我会把整个项目的设计思路、基准测试框架的搭建、agent 的循环逻辑、以及我们实际跑下来遇到的坑，全部摊开讲。代码和配置能给全的我都给全，你可以直接抄。
2. 整体架构设计：agent 负责探索，基准测试负责裁决
2.1 核心设计原则：把"生成"和"评判"彻底分开
这个项目最重要的一条设计原则，就是生成查询方案的 agent 和评判方案好坏的基准测试，必须是两套独立的东西。听起来像废话，但很多人在做 agent 优化时会不自觉地让 agent 自己"感觉"哪个方案好——比如让 LLM 读一下 profile 输出，然后说"嗯，这个看起来更快"。这是灾难的开始。LLM 对数字的敏感度远不如它对文本流畅度的敏感度，它很容易被一段看起来合理的解释带偏。
我们的做法是：agent 只负责提出假设和生成候选方案，所有的裁决权交给一个确定性的基准测试 harness。这个 harness 做的事情很纯粹——给定一个查询 DSL 和一组参数，在固定的数据集上跑 N 轮，收集 P50、P95、P99 延迟、吞吐量、CPU 使用率、堆内存峰值、段文件数量变化，然后输出一个结构化的 JSON 报告。agent 拿到这个 JSON，才能决定下一步怎么走。
提示：基准测试 harness 必须是确定性的。同样的输入，跑十次，结果应该高度一致。如果你的测试环境有噪声（比如共享 CPU、后台有别的任务在跑），那 agent 的优化方向会被噪声带偏，最后优化出来的方案在你的生产环境上可能完全不 work。
2.2 为什么选 CLI 而不是 Web 界面或 SDK
热词里出现了codex cli、claude cli、trae cli、deveco cli这些，说明大家现在对 CLI 形态的 agent 工具接受度很高。我们这个项目也是 CLI 优先的，原因有几个。
第一，Elasticsearch 的运维和调优本身就是命令行驱动的。你要看集群状态，curl -XGET 'localhost:9200/_cluster/health?pretty'；要看慢查询日志，tail -f logs/elasticsearch_index_search_slowlog.log；要跑压测，esrally或者自己写的wrk脚本。整个工作流天然在终端里。如果 agent 是个 Web 应用，你还得在中间做一层命令封装和结果解析，多此一举。
第二，CLI agent 更容易被脚本化和编排。你可以用cron定时跑，可以用systemd管起来，可以塞进 CI/CD 流水线里做回归测试。我们实际跑的时候，就是让 agent 在一个tmuxsession 里持续跑，我该干别的干别的，偶尔tmux attach看一眼进度。
第三，CLI 的输入输出是纯文本，对 LLM 极其友好。agent 读_search的 profile 输出、读_nodes/stats的 JSON、读基准测试的报告，全是文本，不需要处理什么图形界面状态。这一点在 agent 开发里很关键——输入输出的模态越简单，agent 的可靠性越高。
2.3 整体数据流：从查询模板到优化报告
整个系统的数据流大概是这样：
- 你提供一个查询模板（带占位符的 DSL）和一个参数空间定义（哪些参数可以调、取值范围是多少）。
- agent 根据当前轮次的反馈，从参数空间里采样出一组具体参数，填入模板，生成一个完整的查询 DSL。
- 基准测试 harness 接收这个 DSL，在预置的数据集上跑压测，收集指标，输出 JSON 报告。
- agent 读取报告，对比历史最优，决定是接受这个方案、还是回退、还是继续探索邻近参数。
- 重复 2-4，直到达到停止条件（比如连续 20 轮没有改进，或者总轮次达到上限）。
- 输出最终的最优参数组合和完整的优化轨迹。
这个循环里，第 3 步是基石。如果基准测试本身不可信，后面全是空中楼阁。所以下一节我会花很大篇幅讲基准测试怎么搭。
3. 基准测试框架搭建：让每一次测量都可信
3.1 数据集准备：别拿生产数据直接测
第一件事，准备一个固定的、有代表性的、大小适中的数据集。我们当时用的是某个日志场景的样本，大概 500 万条文档，每条文档有 20 来个字段，包括时间戳、服务名、日志级别、消息体、几个数值型指标。这个规模的好处是：单机就能跑，一轮压测几分钟出结果，同时又能暴露出分片、段合并、缓存这些层面的问题。太小了（比如几万条）测不出问题，太大了（几亿条）迭代速度跟不上。
数据集准备好之后，冻结它。不要一边测一边往里面写新数据，那样你的基线一直在变，根本没法比较。我们的做法是建好索引之后，把index.refresh_interval设成-1，number_of_replicas设成 0，然后_forcemerge到每个分片一个段，之后就不再写入。这样每次压测面对的都是完全相同的段结构，测量结果才有可比性。
注意：如果你要测的是写入性能优化，那数据集策略完全不同——你需要一个持续写入的负载生成器，而且要控制写入速率恒定。我们这个项目主要针对查询优化，所以用的是只读数据集。这一点在项目开始前就要想清楚，别做到一半发现测的方向不对。
3.2 压测工具选型：为什么最后用了自研的轻量 harness
压测工具我们试过几个。esrally是官方出的，功能全，但太重了——它自带一堆 track 定义，配置起来很繁琐，而且它的报告格式对 agent 不够友好，解析起来费劲。wrk和hey这类 HTTP 压测工具倒是轻，但它们不理解 Elasticsearch 的查询语义，你只能测一个固定的 URL，没法方便地参数化 DSL。
最后我们写了一个大概 300 行的 Python harness，核心逻辑很简单：
import time import json import statistics import requests from concurrent.futures import ThreadPoolExecutor def run_single_query(es_url, index, dsl, warmup=False): start = time.perf_counter() resp = requests.post( f"{es_url}/{index}/_search", json=dsl, headers={"Content-Type": "application/json"} ) elapsed = (time.perf_counter() - start) * 1000 # ms resp.raise_for_status() return elapsed, resp.json() def benchmark(es_url, index, dsl, rounds=50, concurrency=4, warmup_rounds=10): # 预热，让文件系统缓存和 ES 的 query cache 进入稳定状态 for _ in range(warmup_rounds): run_single_query(es_url, index, dsl, warmup=True) latencies = [] with ThreadPoolExecutor(max_workers=concurrency) as executor: futures = [ executor.submit(run_single_query, es_url, index, dsl) for _ in range(rounds) ] for f in futures: elapsed, _ = f.result() latencies.append(elapsed) latencies.sort() return { "p50_ms": statistics.median(latencies), "p95_ms": latencies[int(len(latencies) * 0.95)], "p99_ms": latencies[int(len(latencies) * 0.99)], "mean_ms": statistics.mean(latencies), "min_ms": min(latencies), "max_ms": max(latencies), "rounds": rounds, "concurrency": concurrency, }这个 harness 有几个关键设计点值得说。预热轮次是必须的，因为 Elasticsearch 的查询缓存、文件系统缓存、JIT 编译都需要时间进入稳态，你不预热直接测，前几轮的延迟会高得离谱，把 P99 拉爆。并发度要固定，因为不同并发下的最优参数可能不同，你如果这一轮用 4 并发、下一轮用 8 并发，那比较就没有意义了。百分位数比平均值重要得多，用户感知的是 P99，不是 mean。
3.3 指标采集：光看延迟是不够的
延迟只是表象，要理解为什么快为什么慢，必须采集更细的指标。我们在每轮压测前后各采一次_nodes/stats，重点看这几个：
| 指标路径 | 含义 | 关注点 |
|---|---|---|
indices.search.query_total | 查询总次数 | 确认压测确实打进去了 |
indices.search.query_time_in_millis | 查询总耗时 | 算平均单次耗时 |
indices.search.fetch_total | fetch 阶段次数 | fetch 多说明返回文档多 |
indices.query_cache.hit_count | 查询缓存命中 | 命中率高说明查询可缓存 |
jvm.mem.heap_used_percent | 堆使用率 | 超过 75% 要警惕 GC |
indices.segments.count | 段数量 | 段太多影响查询 |
thread_pool.search.queue | 搜索队列积压 | 有积压说明并发不够 |
这些指标和延迟一起打包成 JSON，交给 agent。agent 看到"延迟高 + query_cache 命中率低"，就知道该往缓存友好的方向调；看到"延迟高 + 堆使用率高 + GC 频繁"，就知道该减少聚合的内存占用。给 agent 的上下文越丰富，它的优化方向就越准。
3.4 基线建立：没有基线就没有优化
在让 agent 跑之前，你必须先手工跑出一个基线。这个基线就是你当前生产环境在用的那套查询和参数。所有 agent 提出的方案，都要和这个基线比。我们当时定的接受标准是：P95 延迟降低 15% 以上，且 P99 不劣化超过 5%，才算有效改进。为什么 P99 要单独卡？因为有些优化是"牺牲尾部换平均"——比如加大size让单次返回更多、减少请求次数，平均延迟降了，但单次请求变重，P99 反而涨了。这种方案在生产上是要出事的。
提示：基线不是测一次就完事。每次你改了测试环境（比如重启了 ES、换了 JVM 参数、系统更新了），都要重新测基线。我们吃过这个亏——有一次系统自动更新了内核，文件系统缓存行为变了，基线整体偏移了 20%，结果 agent 之前"优化"出来的方案全都不准了，白跑了两天。
4. Agent 的循环逻辑：怎么让它越跑越聪明
4.1 Agent 的输入输出契约
Agent 每一轮接收的输入是一个结构化的 JSON，包含：
- 当前轮次和历史最优方案的参数
- 最近 K 轮（我们用的 K=10）的完整报告，包括参数和指标
- 当前基线指标
- 参数空间的约束（哪些参数可以动、范围是多少）
Agent 输出的也是一个 JSON，包含：
- 下一轮要试的参数组合
- 它对这组参数的假设（为什么觉得这组会更好）
- 如果这组参数验证有效，它建议的下一步探索方向
这个"假设"字段很重要。它逼着 agent 做有根据的探索，而不是随机乱试。而且当优化失败时，这个假设能帮你复盘——是假设本身错了，还是假设对但参数没调到位。
4.2 探索策略：从粗到细，从单变量到组合
Agent 的探索策略我们设计成三个阶段。
第一阶段：单变量扫描。对每个可调参数，在它的取值范围内均匀取 5-7 个点，其他参数固定在基线值，逐个测。这一阶段的目的不是找到最优，而是搞清楚每个参数的大致影响方向和敏感度。比如我们发现track_total_hits从true改成10000，P95 直接降了 30%，那这个参数就是高优先级。而preference参数怎么调都没啥变化，那就先放一边。
第二阶段：局部搜索。在第一阶段找到的每个参数的较优区间内，做更细的采样。同时开始尝试两两组合。这里 agent 会用到第一阶段学到的"参数敏感度"来决定组合的优先级——敏感度高的参数优先组合。
第三阶段：贝叶斯式微调。到这一阶段，agent 已经积累了几十轮的数据，它会用一个简单的代理模型（我们用的是高斯过程，也可以用随机森林）来预测哪些参数组合可能更好，然后优先测这些预测值高的点。这一步能显著加快收敛。
4.3 反馈信号的设计：别让 agent 只看一个数
如果只给 agent 一个"延迟"数字，它会陷入局部最优——比如把所有能减少返回数据量的参数都拉满，延迟是降了，但查询结果的完整性没了。所以我们的反馈信号是一个加权评分：
score = 0.5 * (baseline_p95 / current_p95) + 0.3 * (baseline_p99 / current_p99) + 0.2 * (baseline_throughput / current_throughput) - penalty_for_correctness_loss其中penalty_for_correctness_loss是关键。我们在 harness 里加了一个正确性校验：每轮压测时，除了跑性能测试，还会跑一次"结果校验"——用优化后的查询和基线查询分别查同一批样本，对比返回的文档 ID 集合和聚合结果是否一致。如果不一致，直接判负，不管延迟多低。这一条卡死了很多"作弊式优化"，比如偷偷把minimum_should_match调低、把fuzziness关掉之类的。
注意：正确性校验的样本要覆盖各种边界情况——空结果、单结果、大量结果、聚合为空、聚合有大量桶。我们一开始只测了"有结果"的情况，结果 agent 优化出一个方案，在空结果时直接报错，差点漏过去。
4.4 停止条件与回滚机制
Agent 不能无限跑下去。我们设了三个停止条件，满足任一就停：
- 连续 20 轮没有产生新的最优方案。
- 总轮次达到 200 轮。
- 单轮压测耗时超过 10 分钟（说明环境出问题了）。
停止之后，agent 输出最终方案和完整的优化轨迹。但最终方案不会自动上线，而是进入一个人工审核环节。审核的内容包括：参数是否在合理范围内、正确性校验是否全部通过、有没有引入新的风险（比如把refresh_interval设得过大导致数据可见性延迟）。审核通过后，才通过配置中心推送到生产。
回滚机制也很简单：所有参数变更都走配置中心，配置中心保留版本历史，出问题一键回滚到上一个版本。我们实际跑的时候，有一次 agent 优化出一个方案，在测试环境 P95 降了 40%，但上线后发现，在真实流量下（查询模式比测试集复杂得多）P99 反而涨了。还好有回滚，五分钟就恢复了。
5. 实操过程：从零搭起这套系统
5.1 环境准备：单机 ES 加 Python 就够了
你不需要一个庞大的集群来跑这套东西。我们整个项目就是在一台 16 核 64G 的机器上跑的，ES 单节点，堆内存给了 16G，剩下的留给文件系统缓存。Python 环境就是标准的 3.10，依赖只有requests、numpy、scikit-learn（用于第三阶段的代理模型）和openai（或者你用的任何 LLM 的 SDK）。
ES 的安装这里不展开，网上教程很多。关键配置就几条：
# elasticsearch.yml node.name: bench-node path.data: /data/es-bench path.logs: /var/log/es-bench bootstrap.memory_lock: true discovery.type: single-node# jvm.options -Xms16g -Xmx16gbootstrap.memory_lock: true这条很重要，它防止 ES 的堆内存被换到磁盘上，否则压测时延迟会莫名其妙地抖动。对应的，你需要在系统层面给 ES 用户解锁内存锁定的权限，在limits.conf里加elasticsearch - memlock unlimited。
5.2 查询模板与参数空间定义
假设我们要优化的查询是"按服务名过滤 + 时间范围过滤 + 按日志级别聚合 + 返回最近 N 条"。模板大概长这样：
{ "query": { "bool": { "filter": [ {"term": {"service": "{{service}}"}}, {"range": {"@timestamp": {"gte": "{{start_time}}", "lte": "{{end_time}}"}}} ], "must": [ {"match": {"message": "{{keyword}}"}} ] } }, "aggs": { "by_level": { "terms": { "field": "level", "size": {{agg_size}} } } }, "size": {{page_size}}, "track_total_hits": {{track_total_hits}} }参数空间定义：
{ "track_total_hits": [true, 10000, 1000, false], "page_size": [10, 20, 50, 100], "agg_size": [5, 10, 20, 50], "query_rewrite": ["constant_score", "scoring_boolean", "top_terms_boost_1024"] }注意query_rewrite这个参数，它对应的是match查询的rewrite选项，对性能影响很大。constant_score会跳过打分，最快；top_terms_boost_1024会保留打分但做优化。这个参数很多人不知道，但在我们的测试里，它带来的差异能到 20% 以上。
5.3 Agent 主循环的实现
主循环的骨架大概是这样：
def agent_loop(es_url, index, template, param_space, baseline, max_rounds=200): history = [] best = {"params": baseline, "score": 1.0} no_improve_count = 0 for round_num in range(max_rounds): # 1. 让 agent 决定下一组参数 next_params = agent_propose(history, best, param_space) # 2. 渲染查询 dsl = render_template(template, next_params) # 3. 正确性校验 if not correctness_check(es_url, index, dsl, baseline_dsl): history.append({"params": next_params, "score": -1, "reason": "correctness_failed"}) continue # 4. 跑基准测试 report = benchmark(es_url, index, dsl) # 5. 计算评分 score = compute_score(report, baseline) # 6. 更新历史 history.append({"params": next_params, "score": score, "report": report}) # 7. 更新最优 if score > best["score"]: best = {"params": next_params, "score": score} no_improve_count = 0 else: no_improve_count += 1 # 8. 检查停止条件 if no_improve_count >= 20: break return best, historyagent_propose这个函数是核心，它把历史数据整理成 prompt，发给 LLM，解析返回的 JSON。这里有个工程细节：LLM 返回的 JSON 经常不合法，比如多一个逗号、少一个引号、或者把数字写成字符串。我们加了一个重试机制，解析失败就重新请求，最多重试 3 次，还失败就回退到随机采样。这个兜底很重要，否则 agent 会因为一次解析失败就卡住。
5.4 实际跑一轮的记录
我们实际跑的时候，第一轮 agent 就提出了一个有意思的方案：把track_total_hits从true改成10000，同时把page_size从 20 降到 10。它的假设是"减少返回数据量和总数统计开销"。结果 P95 从 340ms 降到了 210ms，降幅 38%。这个方案我们之前人工调优时也想到过，但没敢改，因为担心业务方需要精确的总数。后来和业务方确认，他们其实只需要知道"有没有超过 1 万条"，不需要精确值，这个优化就顺利落地了。
第二轮 agent 尝试了query_rewrite: constant_score，P95 又降了 15ms。但正确性校验发现，改成constant_score后，match查询的打分变了，导致返回结果的排序和基线不一致。虽然文档 ID 集合一样，但顺序不同。这个方案被我们判为"部分有效"——如果业务不关心排序，可以用；如果关心，就不能用。最后我们没采用这个参数。
到第 30 轮左右，agent 找到了一个组合方案：track_total_hits: 10000+page_size: 10+agg_size: 10+query_rewrite: top_terms_boost_1024，P95 稳定在 180ms 左右，比基线降了 47%。这个方案通过了所有正确性校验，最终上线。
6. 常见问题与排查技巧实录
6.1 压测结果抖动大，怎么办
这是最常见的问题。表现是同一组参数，跑两次，P95 能差 30%。原因通常有几个：文件系统缓存没预热够、后台有别的进程在抢 CPU、ES 在做段合并、JVM 在 GC。排查顺序是：先看_nodes/stats里的jvm.gc.collectors计数，如果压测期间 GC 次数明显增加，那就是堆内存不够或者查询太吃内存；再看indices.segments.count，如果段数量在变化，说明有后台合并，等合并完再测；最后看系统top，确认没有别的进程在抢资源。
我们的经验是，预热轮次至少 10 轮，压测轮次至少 50 轮，而且压测期间不要做任何其他操作。如果还是抖，就把并发降到 1，先测单线程延迟，排除并发干扰。
6.2 Agent 陷入局部最优，怎么破
Agent 跑着跑着，连续很多轮都在一个小范围内微调，分数上不去。这时候需要给它"踹一脚"。我们的做法是：当连续 10 轮没有改进时，强制 agent 做一次"随机重启"——从参数空间里完全随机采一组，不管历史。这一组大概率很差，但它能把 agent 带出当前的局部区域。实测下来，随机重启之后，agent 往往能在接下来的 20 轮里找到新的改进方向。
另一个技巧是扩大参数空间。有时候不是 agent 不行，是你能调的参数太少了。我们一开始只调了 4 个参数，agent 很快就摸到了天花板。后来把refresh_interval、preference、batched_reduce_size这些也加进去，搜索空间一下子大了很多，agent 又找到了新的优化点。
6.3 正确性校验误报，怎么处理
正确性校验有时候会误报。比如浮点数的聚合结果，由于计算顺序不同，最后一位小数可能有差异。我们的处理方式是：对于数值型聚合，允许 0.1% 的相对误差；对于文档 ID 集合，要求完全一致；对于排序，如果业务不关心，可以放宽。这些规则要提前和业务方对齐，别自己拍脑袋定。
还有一个坑：样本选择偏差。如果你只用"有结果"的查询做校验，agent 可能会优化出一个在空结果时行为异常的方案。我们的做法是，校验样本里必须包含至少 20% 的空结果查询、10% 的单结果查询、10% 的超大结果查询（超过 1 万条）。
6.4 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决 |
|---|---|---|---|
| 压测结果抖动大 | 缓存未预热/GC/段合并 | 看 GC 计数、段数量、系统负载 | 增加预热轮次，等合并完再测 |
| Agent 连续无改进 | 局部最优/参数空间太小 | 看历史参数分布 | 随机重启，扩大参数空间 |
| 正确性校验失败 | 查询语义变了 | 对比返回结果差异 | 调整校验规则或放弃该方案 |
| 延迟突然飙升 | 环境变化/资源竞争 | 看系统指标 | 重新测基线，隔离环境 |
| Agent 输出 JSON 解析失败 | LLM 输出不稳定 | 看原始输出 | 加重试和兜底逻辑 |
6.5 几个我踩过的坑
第一个坑：别在压测机上跑 agent 的 LLM 调用。LLM 调用是网络 IO，虽然不占 CPU，但它的 Python 进程会占内存，而且网络抖动可能影响压测的稳定性。我们后来把 agent 和压测 harness 分到两台机器上，agent 通过 HTTP 调用压测机的 API，稳定多了。
第二个坑：ES 的查询缓存会骗你。同一个查询跑第二遍，因为缓存命中，延迟会低很多。如果你不控制这一点，agent 会倾向于生成"可缓存"的查询，而不是"本身快"的查询。我们的做法是，每轮压测前清一次查询缓存（POST /index/_cache/clear?query_cache=true），确保测的是冷查询性能。当然，如果你的生产场景就是热查询为主，那不清缓存也是合理的，关键是要和实际场景一致。
第三个坑：别忽略写入放大。有些查询优化方案会改变索引的 mapping 或者 doc_values 配置，这些改动可能需要重建索引。重建索引期间，集群的写入压力会很大，可能影响线上服务。我们的做法是，任何涉及 mapping 变更的方案，都必须在独立的索引上验证，确认没问题后再走重建流程，而且重建要在业务低峰期做。
7. 这套系统还能怎么扩展
跑完这个项目之后，我觉得这套"agent 探索 + 基准测试裁决"的框架，其实不局限于 Elasticsearch 查询优化。任何有明确指标、有参数空间、有可重复测试环境的优化问题，都可以套这个模式。比如 JVM 参数调优、数据库索引设计、甚至前端构建配置优化。
扩展方向有几个。一是多目标优化，现在我们的评分是加权求和，其实可以用帕累托前沿的方式，同时优化延迟、吞吐、资源占用，让业务方自己选。二是在线学习，把生产环境的真实指标也反馈给 agent，让它不仅优化测试环境，还能感知生产环境的变化。三是跨集群迁移，把在一个集群上学到的最优参数，作为另一个集群的初始搜索起点，加速收敛。
不过这些都是后话。眼下最重要的，还是那句话：信任 agent 的探索能力，但永远用基准测试来裁决。Agent 可以帮你把搜索空间从一千种方案压缩到十种值得人工看的方案，但它不能替你做最终决策。最终上线的参数，必须经过正确性校验、人工审核、灰度发布这一整套流程。这不是对 agent 的不信任，而是对生产环境的敬畏。
