)
Hill Climbing Loop1、引言2、Hill Climbing Loop 到底在爬什么山3、Hill Climbing Loop 核心原理3.1 六步闭环Trace → 分析 → 诊断 → 优化 → 上线 → 再 Trace3.2 优化的四个抓手Prompt / Tool / Memory / Workflow4、生产级实现Trace 分析 DSPy 自动优化5、2026 年的关键改进点5.1 从人肉改 Prompt到优化器搜 Prompt5.2 失败聚类别在一个 case 上改一百遍5.3 Golden Dataset 回归别改好一个 case改崩十个6、适用场景与性能基准7、总结Loop Stack 全景回顾1、引言小屌丝鱼哥我那 Agent 上线仨月了。刚上线的时候爽得不行写东西又快又准。结果最近我越用越不对劲——同样是写周报上周它开始把同比写成环比昨天连DAU是啥都不知道了。小鱼喝了口茶你换模型了小屌丝没换啊还是那 gpt-5。我还专门把系统提示词原样复制回来对了一遍一个字没动。小鱼兄弟这不是模型变蠢了是你的世界变了。用户输入分布在变、数据在变、工具返回格式在变你那套三个月前调优的 Prompt 当然就慢慢退化了。这就是为什么光有前三个 Loop 不够——你得有一个 Loop专门盯着 Agent 自己把它越用越聪明。小屌丝你的意思是……让 Agent 自己改自己小鱼对Hill Climbing Loop。名字来自爬山算法每次看一眼当前在哪往高的方向迈一步重复。对应到 Agent 上就是——跑一批任务把每一步的 Trace 记下来分析哪里出错了针对性地改 Prompt、改工具、改记忆、改流程然后再跑一批看是不是真的变好了。小屌丝听着就费钱。我总不能天天人工看 Trace 吧小鱼2026 年不用你看。Trace 系统自动拉、失败自动聚类、优化器自动搜更好的 Prompt你只需要在它上线前点个批准。今天这是本系列收官我给你把这套AI 优化 AI的闭环讲清楚。2、Hill Climbing Loop 到底在爬什么山对应素材里的循环 4六个步骤转成一个环┌──────────────────────────────────────────┐ ↓ │ 1. Agent 运行执行任务 │ ↓ │ 2. 产生 Trace每一步都记录 │ ↓ │ 3. 分析 Trace统计指标、失败率 │ ↓ │ 4. 发现问题聚类、定位根因 │ ↓ │ 5. 优化改进 ──┬─ 优化 Prompt │ ├─ 优化 Tool │ ├─ 优化 Memory │ └─ 优化 Workflow │ ↓ │ 6. 更新 Agent应用新配置 ────────────────────┘它跟前三个 Loop 的分工Loop关心的问题时间尺度Agent Loop这一次任务怎么干完秒分钟Verification Loop这一次产出能不能用秒分钟Event-Driven Loop谁来触发、怎么写回外部世界分钟小时Hill Climbing Loop这个 Agent 整体怎么越变越好天周前三个 Loop 让系统跑起来Hill Climbing Loop 让系统跑上去。这就是素材里那句 slogan 的分量下一代软件的核心竞争力不是模型而是循环。而 Hill Climbing Loop是那个让循环本身不断变强的元循环。一句话总结Hill Climbing Loop Trace 数据 → 失败诊断 → 四维优化Prompt/Tool/Memory/Workflow→ 灰度上线 → 再 Trace让 Agent 从自动化工作进化到自动化改进。3、Hill Climbing Loop 核心原理3.1 六步闭环Trace → 分析 → 诊断 → 优化 → 上线 → 再 Trace这六步里前三步是看清楚病后三步是开药方。1Agent 运行就是第 1 篇那个 Agent Loop只不过每一步都被完整记录。2产生 Trace每一次工具调用、每一段 Thought、每一个 Observation、每次 retry、每次 grader 打分全部结构化落库。2026 年这一层基本被 LangSmith / Langfuse / OpenTelemetry GenAI Semantic Conventions 标准化了你只要在代码里加几行 decorator不用自己写存储。3分析 Trace看几个核心指标——任务成功率、平均步数、平均 token 成本、各工具调用失败率、grader 通过率、人工接管率。哪个指标掉了问题就出在哪。4发现问题把失败的 case 拉出来不是一个一个看而是聚类——“哦最近 30 个失败里有 22 个都是工具search返回了空结果然后 Agent 硬编了一个答案”。根因一聚类优化方向就出来了。5优化改进四个抓手下面单独讲。6更新 Agent改完不能直接全量上线要先在 golden dataset 上回归再灰度 10% 流量观察一天指标没问题再全量。3.2 优化的四个抓手Prompt / Tool / Memory / Workflow抓手什么时候动它典型动作Prompt模型理解错了任务、格式漂移、语气不对加 few-shot 例子、改系统提示、拆指令Tool工具调用参数错、选错工具、工具返回没用改工具描述、加参数校验、拆/合并工具Memory长任务里忘事、跨会话记不住用户偏好改记忆摘要策略、改检索 top-k、改过期策略Workflow单 Loop 兜不住、步骤顺序错了加 Plan-and-Execute 子图、加 HITL 节点、加并行分支一个经验法则先动 Prompt最便宜再动 Tool次便宜再动 Memory要数据最后才动 Workflow最贵。一上来就重构图往往是没看清病就开刀。4、生产级实现Trace 分析 DSPy 自动优化下面这套骨架展示自动优化 Prompt这一段——其他三个抓手思路类似只是改的对象不同。# hill_climbing_loop.py Hill Climbing Loop 骨架 1. 从 Trace 系统拉一批失败 case 2. 聚类挑出最高频的失败模式 3. 用 DSPy 优化器在 golden dataset 上自动搜更好的 Prompt 4. 跑回归过了才把新 Prompt 推到 Prompt Hub fromdatetimeimportdatetime,timedeltafromcollectionsimportCounter# ---------- 1. 拉最近 7 天失败的 Trace ----------defpull_failed_traces(days:int7):# 真实项目里替换成 langsmith.list_runs / langfuse.clientsincedatetime.utcnow()-timedelta(daysdays)runstrace_client.list_runs(filter{status:error,started_at:{gte:since}},limit500,)returnruns# ---------- 2. 失败聚类按最后一次工具调用 报错信息分桶 ----------defcluster_failures(runs:list[dict])-Counter:bucketsCounter()forrinruns:last_toolr.get(last_tool_call,unknown)err_typeclassify_error(r.get(error,))# 用小模型分个类buckets[(last_tool,err_type)]1returnbuckets# 典型输出# {(search, empty_result_then_hallucinate): 22,# (db.query, wrong_parameter_type): 8, ...}# ---------- 3. 拿最高频的那一类构造优化集 ----------defbuild_golden_set(top_cluster,runs):# 把这类失败 case 变成 (输入, 期望输出) 的评测集return[dspy.Example(inputr[input],expectedr[golden_output])forrinrunsifbelongs_to(r,top_cluster)].with_inputs(input)# ---------- 4. 用 DSPy 优化器自动搜 PromptMIPRO / GEPA 思路 ----------defoptimize_prompt(golden_set,student_module):importdspy# 优化器不是让你写 Prompt而是给它几个候选指令种子# 它自动组合 few-shot 例子 指令在 golden_set 上挑最优。optimizerdspy.MIPROv2(metricrubric_metric,autolight)optimizedoptimizer.compile(student_module,trainsetgolden_set,valsetgolden_set[:30],)returnoptimized# ---------- 5. 回归新 Prompt 不能把别的 case 改崩 ----------defregression_test(new_program,full_eval_set):score_newevaluate(new_program,full_eval_set)score_oldevaluate(prod_program,full_eval_set)# 硬规则新方案在目标聚类上必须提升且在全集上不能倒退超过 1%ifscore_new.target_clusterscore_old.target_cluster0.05\andscore_new.overallscore_old.overall-0.01:returnTruereturnFalse# ---------- 6. 推上线灰度 ----------defrollout(new_program):prompt_hub.publish(nameissue_triage_agent_prompt,bodynew_program.dump_jinja2(),tags[candidate],)# 接 10% 灰度流量观察 24h 指标人工批准后全量if__name____main__:runspull_failed_traces(7)clusterscluster_failures(runs)topclusters.most_common(1)[0][0]goldbuild_golden_set(top,runs)new_progoptimize_prompt(gold,student_module...)ifregression_test(new_prog,full_eval_set):rollout(new_prog)这套东西在 2026 年已经是很多 AI 团队的周会仪式每周一自动跑一遍本周哪个失败模式最高、优化器找到什么新 Prompt、回归过没过全部自动出报告。人只做最后一步批准。5、2026 年的关键改进点5.1 从人肉改 Prompt到优化器搜 Prompt2024 年调 Agent 就是个玄学产品经理说再加一句’要严谨’“工程师说加个 few-shot 吧”上线一看哎好像好点了。2026 年的做法是把 Prompt 当超参数来搜DSPy把 Prompt 写成 Python 模块优化器MIPROv2 / GEPA自动搜指令和 few-shotPromptHub 版本管理每个 Prompt 像 Git commit 一样有版本、有 diff、有对应的 eval 分数自动 few-shot 选择来了一个新 case从历史成功案例里自动挑最像的 2–3 个塞进上下文比手写固定 few-shot 泛化好得多。人从写 Prompt 的人变成设计 metric 和 dataset 的人。5.2 失败聚类别在一个 case 上改一百遍新人最容易犯的错看到一个 case 翻车就围着这一个 case 改 Prompt改到它过了结果另外十个本来能过的 case 被改崩了。2026 年的标准动作是拉最近 N 天所有失败 trace用一个小模型把每个失败归到一个类别“工具空返回后幻觉”、“参数类型错”、“上下文截断”……按类别计数只动最高频的那一两类改完在全量 golden set 上回归不允许按下葫芦浮起瓢。这本质上是把炼丹变成数据驱动——你优化的不是一个 case是一个失败分布。5.3 Golden Dataset 回归别改好一个 case改崩十个没有 golden dataset 的 Prompt 优化就是耍流氓。2026 年的标配Golden Dataset 怎么来每一次 Verification Loop 里被人工标过的 case、每一次 HITL 里人批准/拒绝的 case、每一次线上被用户差评的 case全部自动进 golden set每次改 Prompt / Tool / Memory / Workflow都必须在 golden set 上跑一遍整体分数不许掉灰度上线新配置先接 5%–10% 流量盯 24 小时关键指标没掉再放量一键回滚Prompt 是版本化的出问题秒切回上一个版本。这一层做扎实了你才敢让 Hill Climbing Loop 自己跑——因为它就算改错了也改不出大事。6、适用场景与性能基准场景推荐度说明长期运行的生产 Agent⭐⭐⭐⭐⭐不上 Hill Climbing三个月后必然退化高频、高价值任务客服、编码、销售⭐⭐⭐⭐⭐一点点成功率提升都值大钱一次性脚本 / PoC⭐花在 trace 和 eval 上的成本不划算强合规、强审计场景⭐⭐⭐⭐自动优化前必须人审不能黑盒上线模型每周都在换的团队⭐⭐⭐⭐⭐模型一变 Prompt 就得跟着重搜优化器自动化救命一组 2026 年参考数字Trace 存储成本约 LLM 调用成本的5%–15%结构化后远小于原始日志每周自动优化一轮典型成功率提升3–8 个百分点基线 ~70% 时DSPy 类优化器一次 compile跑几百个 eval成本 $10–$50回归测试集规模成熟项目一般几百到几千条golden case从失败聚类到新 Prompt 上线1–3 天含灰度观察。7、总结Loop Stack 全景回顾四篇写完把整张图收一下。2026 年的 Agent 系统底下是四层互相咬合的循环┌─────────────────────────────┐ 第4层 │ Hill Climbing Loop │ 持续改进分析 Trace优化 Prompt/Tool/Memory/Workflow │ AI 优化 AI │ └────────────┬────────────────┘ ↑ ┌────────────┴────────────────┐ 第3层 │ Event-Driven Loop │ 事件驱动Webhook/Cron/Slack/GitHub 触发写回真实世界 │ AI 融入世界 │ └────────────┬────────────────┘ ↑ ┌────────────┴────────────────┐ 第2层 │ Verification Loop │ 验证反馈LLM as Judge Rubric Feedback Retry │ AI 检查 AI │ └────────────┬────────────────┘ ↑ ┌────────────┴────────────────┐ 第1层 │ Agent Loop │ 执行任务观察 → 决策 → 调工具 → 回灌 → 自判完成 │ AI 完成任务 │ └─────────────────────────────┘再往上就是素材里那条演进线Prompt → Skill → Workflow → Agent → Loop → Self-Evolving System模型本身会一年比一年强但真正拉开差距的是你在模型外面包了几层循环、这些循环转得有多稳。这就是为什么 2026 年大家开始说下一代软件的核心竞争力不是模型而是循环。核心记忆点Hill Climbing Loop 是元循环——它不直接干活它让其他三个 Loop 越变越好没有 Trace 就没有优化前三层一定要把每一步结构化记下来优化顺序Prompt → Tool → Memory → Workflow从便宜到贵失败要聚类着改别盯着单个 case 调参Golden Dataset 灰度 一键回滚是敢让 Loop 自动优化的前提四层 Loop 全转起来你的系统就从一个会聊天的模型长成了一个会自己进化的软件。—— 全系列完 ——我是小鱼CSDN 博客专家AIGC 技术MVP专家阿里云 专家博主51CTO博客专家企业认证金牌面试官多个名企认证特邀讲师等名企签约职场面试培训、职场规划师多个国内主流技术社区的认证专家博主多款主流产品(阿里云等)评测一等奖获得者关注小鱼学习【人工智能与大模型】最新最全的领域知识。