做这个项目之前我一直觉得“AI Agent 能跑起来”才是最难的部分后来真正上了线才发现让一个 Agent 稳定、可靠地持续变好才是真正烧脑的环节。尤其是当你面对的是 Harness 这种既要约束模型行为、又要应对复杂真实请求的框架时最直接的痛点其实是用户的每一条不满意反馈都在“白给”而我们的系统却始终反应迟钝。于是我们做了这样一套基于用户反馈的模型微调加 Prompt 优化双轨流程把 Agent Harness 变成一个有自我进化能力的闭环系统。这篇文章就是把整个流程的设计思路、数据管道、迭代方法、踩坑记录都摊开来讲适合那些正在做 Agent 类产品、被线上反馈淹没却不知道如何下手的工程师参考。1. 为什么需要自我进化机制先看清 Harness 的定位1.1 Agent Harness 在系统里到底管什么很多同学第一次听到“Harness Engineering”会以为是什么花哨的装备其实它就是把 Agent 框在一个可控的执行环境里。通俗点说Harness 就像给一个能力很强但性格不稳定的员工配了一位资深项目经理——模型负责出主意Harness 负责让主意在正确的轨道上落地。它管理的内容包括会话状态、工具调用路由、上下文管理、权限边界、以及策略注入。换句话说模型是大脑Harness 是神经系统和四肢。在实际项目里Harness 层做的事情非常琐碎但关键。例如用户问“帮我把这份列表按时间排序再汇总一下”模型本身可能只会回答“好的我可以这样做”但如果 Harness 没有正确解析工具调用、没有把排序结果包装成用户可以理解的摘要整个交互就是失败的。我们初期踩过很多坑以为是模型能力不够后来发现大部分问题其实出在 Harness 的编排策略上——比如工具返回结果太长直接把上下文塞爆比如多个工具并行调用时结果顺序错乱。Harness 的核心价值在于“可控”。模型是概率输出的同一个 Prompt 每次生成的内容都可能不同而 Harness 能把这种行为框在一个可接受范围内。比如规定模型必须按照某个 JSON Schema 输出工具调用参数如果不符合就解析失败重试比如设置上下文窗口的使用上限超出就做压缩或摘要。这些规则保障了 Agent 在大多数场景下不会彻底放飞自我。但是问题也来了这些规则是谁定的答案通常是工程师在开发阶段拍脑袋定的。一旦上线用户请求的分布千变万化静态规则很快就会和真实场景脱节。1.2 静态编排撑不住动态场景自我进化不是锦上添花我见过不少 Agent 项目的做法是上线后发现某个问题就由开发手动修改一段 Prompt 或者加一条 Harness 规则然后重新发版。这种做法在 Demo 阶段没问题但在真实业务里完全不可持续。用户反馈是 7×24 小时不断流入的靠人工盯帖子、盯工单、盯系统日志来定位问题存在三个致命缺陷。第一响应速度太慢。一个反馈从用户提交到被工程师看到再到修改 Prompt、测试、发版往往需要好几天。这段时间内大量同类用户持续遭遇同样糟糕的体验。第二人工修改的覆盖度极其有限。线上不断出现新类型的失败很多是极其小众的长尾场景开发团队根本不可能为每一种情况都手工设计规则。第三人工优化缺乏统一衡量标准。每个人改 Prompt 都有自己的偏好可能某次修改让 A 类请求变好了却让 B 类请求变差了而这种副作用往往要等上线很久之后才暴露。自我进化机制的意义就在于把整个改进过程从“人工驱动”变成“数据驱动”。用户反馈本身就是天然的、免费的标注数据它直接告诉我们模型在哪些地方让用户不满意了。把这些反馈结构化、标签化之后既可以用来看清楚问题的分布也可以通过两种路径去消耗数据一种是快速路径通过自动化的 Prompt 优化去修正 Harness 层的指令策略另一种是深度路径通过模型微调去修改模型本身的行为偏好。两条路径的结合让整条链路不再依赖人的实时介入而是形成一条“感知-分析-优化-验证”的自动闭环。想强调的是自我进化不等于让 Agent 完全自治地乱改自己。进化必须在受控的 Harness 框架里进行每一轮优化都要有明确的触发条件、实验验证和回滚机制否则很容易出现“越改越歪”的失控状态。我们后面所有内容都是围绕“可控地进化”这一点展开的。2. 反馈信号的设计与采集进化机制的燃料2.1 显式反馈与隐式反馈怎么分工自我进化机制的起点不是模型也不是 Prompt而是反馈信号。没有高质量且持续稳定的反馈流后面的优化全部是无源之水。反馈从采集方式上可以分成显式和隐式两类两者必须配合使用。显式反馈指的是用户主动表达态度的信号。最典型的就是聊天气泡下面的点赞/点踩按钮或者用户在对话框旁边输入一条简短评价比如“回答不对”“太啰嗦了”。显式反馈的优点在于意图明确可靠性高缺点是覆盖率低大多数用户根本懒得点。尤其是一个 Agent 回答得中规中矩时用户基本不会给出任何积极反馈导致正样本稀疏。隐式反馈则是从用户行为里“猜”出来的态度信号。举例来说用户复制了 Agent 的某段回答很可能是这段内容对他有用用户点击了 Agent 推荐的工具或内容说明这条推荐是对的用户在一次回答后立刻关闭了对话窗口可能就是不满意用户连续两次编辑同一个回复说明生成内容不符合他的需求。这些信号不需要用户主动操作覆盖率高但噪声也大需要仔细定义阈值和结合上下文判断。在实际项目中我们同时采集这两类信号但采用的处理策略完全不同。显式反馈直接进入高优先级处理队列因为它的置信度最高隐式反馈则会先做一轮规则过滤和交叉验证例如“复制行为”这个信号只有在上下文窗口确实包含 Agent 生成的代码或地址时才被记为正面反馈。“重新生成”这个信号我们同时结合其后的最终采纳结果如果用户点了重新生成之后没有继续操作则记为中性的体验差信号。2.2 构建可用的反馈标签体系原始反馈只是零散的满意/不满意但如果你想把反馈用于 Prompt 优化和模型微调就必须把“不满意”拆解成可操作的具体问题。我们在项目里设计了一套轻量标签体系核心是回答“用户到底对什么不满意”。这套标签体系分成了几个大类。意图理解错误Agent 没有正确理解用户的目的回答方向跑偏了。信息缺失回答内容不够完整用户需要的信息没有被覆盖。事实错误或幻觉生成的内容和客观事实不一致或干脆编造信息。格式不合格用户要求表格Agent 给了一段长文本用户要 JSONAgent 回了 Markdown。工具调用失败Harness 没能正确触发、解析或执行工具调用导致任务中断。风格与态度问题语气、详细度不符合用户预期。标签怎么打我们采用三层策略。第一层规则打标。比如检测到输出格式不符合要求、工具返回 error 状态码这类问题可以直接用确定性规则标记。第二层模型自动打标也就是用一个独立的小模型对反馈样本进行多标签分类这里不需要特别复杂的模型普通的分类模型或者当前的基模就好。第三层用户主动表态。如果用户点踩时选了“回答错误”等预置原因直接采用。这套标签体系是整个进化机制的关键因为后续的 Prompt 优化和微调都需要“带有明确问题类型”的样本而不是笼统的坏样本。还有一个容易被忽略的点每条反馈需要带上对应的会话上下文快照至少要包含完整的用户问题、Agent 当时的回复、Harness 输入给模型的那份 Prompt 片段、以及工具调用的过程记录。没有上下文标签做得再准也无法用于后续优化。2.3 反馈质量管理清洗与去重反馈信号天然带着大量噪声尤其是隐式反馈。直接拿脏数据去做优化轻则浪费计算资源重则把模型带偏。反馈质量管理这步做不好后面所有环节都是失衡的。首先要过滤掉的是“无效反馈”。有些用户会连续在同一轮对话里点多次踩可能只是手滑有些用户根本不使用 Agent 的核心能力只是单纯地乱输入还有一些反馈内容长度不足、与对话主题毫无关联。我们用一套简单的规则做初筛反馈文本长度不低于一定阈值且不能只包含表情符号同一会话内短时间内重复性质相同的反馈只保留一条对话轮的上下文缺失超过一半的丢弃。其次要做内容脱敏和合规处理。用户反馈里可能包含电话号码、地址、姓名等私人信息。这些数据在进入训练管道之前必须经过脱敏处理。我们直接采用实体识别加替换的方式把所有手机号、邮箱、身份证号、地址替换为占位符。这里提醒一句这一步千万不要省因为微调数据一旦把用户隐私带进去模型生成时可能把这些信息“背”出来这是重大安全事故。最后是去重。线上会遇到大量近似重复的反馈例如几十个用户都在问同一种报表导出的问题回答都是格式不对。如果不做去重模型会严重偏向这些高频问题导致长尾能力退化。我们的做法是做语义聚类去重用嵌入向量对反馈样本做粗聚类再限制同一个簇在一个训练批次中的样本数量上限。这样既保留了高频问题的代表性也不至于让它彻底淹没低频问题。3. 从反馈到训练数据数据管道的具体做法3.1 反馈如何转化为训练样本反馈经清洗和标签化之后还只是“问题描述”距离模型训练数据的标准格式还有一步。这条转化管道的核心是把用户反馈变成模型能学的东西。不同路径需要不同格式的样本这里重点说三种最常用的。第一种是偏好对样本也是直接偏好优化或奖励模型最常用的数据形态。一个样本包含同一个用户问题下的两个回答一个是被用户嫌弃的“拒绝回答”一个是经过验证的“偏好回答”。挑战在于用户往往只给出了负面反馈偏好回答从哪来我们通常从两个渠道获取一是其他真实用户对同类问题的满意回答二是让更擅长该任务的模型针对失败原因进行修正生成。对于后者我们还会加入人工抽检确保修正后的回答没有引入新的错误。第二种是修正样本主要服务于监督微调。它的核心思路是把“失败案例”变成“修正案例”。具体操作方式是拿到一条失败对话保留原始用户问题用人工或更强模型重写一遍完整的期望回答然后把重写后的回答作为监督目标。修正样本的优点是简单直接易于大规模生成缺点是如果重写质量参差不齐会让模型学到不稳定的输出风格。第三种是行为轨迹样本专门用于 Harness 层的优化。这一类的特点在于重写目标不是最终回答文本而是模型决策的过程比如正确的工具调用顺序、正确的参数提取方式、正确的上下文取舍。我们会在反馈样本中标记工具调用失败类标签然后重跑一遍该任务记录新的正确轨迹形成“用户问题期望工具调用序列期望最终输出”的三元组。这些样本统一进入数据仓库记录来源、标签、时间、所属模型版本等元信息。别小看这一步后续做效果归因时数据来源不明会造成极大的排查困难。3.2 数据配比与采样策略训练数据不是把反馈样本一股脑丢给模型就完事数据配比直接决定了优化后模型的实际表现。我们最早犯过一个错误把大量反馈修正样本堆在一起微调结果模型在反馈密集的类型上表现大幅提升但在普通业务请求上却出现了明显的退化说话方式也变了。后来我们引入了严格的数据配比策略。第一基础能力数据必须占大头。无论反馈样本多么珍贵模型自身的通用能力不能被破坏。我们在微调数据里保留了大量的通用指令数据、领域常识数据这部分通常占整体训练数据量的 60% 以上。第二反馈相关数据控制在合理份额。我们把所有反馈修正样本和偏好对放在一起整体占 25% 左右并确保其中每个细分问题类型不超过整体 5%。第三任务特定正样本占到剩余份额。这里的正样本来自历史表现优秀的高满意度对话它的作用是稳住模型在某些优秀场景的表现防止微调过程把这些能力冲淡。采样策略上也有一些细节值得分享。高频问题我们要控制住数量低频长尾问题要保证至少出现若干次。我们的做法是基于标签体系做分层采样每个标签类别内保证最小样本数量类别内再按语义多样性排序采样。这样处理后的训练集在业务分布上会比原始反馈集健康得多。3.3 质量门槛与人工抽检自动化的数据管道产出的训练样本质量一定不是均衡的必须设置质量门槛。我们的做法是双重过滤加人工抽检。双重过滤的第一重是规则过滤主要检查格式和内容完整性。比如偏好对中两个回答完全一致或者修正样本重写后的回答仍然包含明显幻觉内容的直接丢弃。第二重是模型过滤用一个质量评估模型对所有训练样本打分评估维度包括回答是否完整、是否忠于上下文、是否符合用户意图。只有分数超过阈值的样本才进入最终训练集。人工抽检的比例虽然不能太高但绝对不能没有。我们保持每周抽检一批新增样本按问题类型分层抽取 100 到 200 条由团队内不同角色分别看然后对“该样本是否可用于训练”和“重写答案是否比原始答案更优”两个问题做标注。如果某类标签下人工认可率低于 85%我们就认为这一类样本的质量不可靠会暂时关闭该标签的数据流入并排查原因。很多人会忽略抽检的价值觉得有自动化过滤就够了。但我的经验是自动过滤只能挡住明显的坏样本却挡不住“看起来没问题但隐含文化偏见”或“重写风格与产品调性不一致”的软性问题这些只能靠人眼判断。4. Prompt 优化的自动迭代轻量进化路径4.1 自动 Prompt 优化的核心逻辑Prompt 优化和模型微调并不是非此即彼的关系。在实际工程节奏里我们通常优先做 Prompt 优化因为它的成本低、周期短、可解释性强而且可以直接作用在 Harness 层不需要重新部署模型。自动 Prompt 优化的核心思想可以用一个循环来概括给定一个固定的评估集让一个“优化器模型”分析当前 Prompt 在评估集上的失败案例生成若干候选 Prompt 变体然后在评估集上对全部候选 Prompt 做一次批量评估保留效果最好、且未引入明显副作用的一个进入下一轮迭代。这个思路听起来很朴素但实际落地时有几个关键细节决定了成败。第一评估集必须固定且具有代表性。如果评估集不稳定每一轮之间就没有对比基础你根本无法判断是 Prompt 变好还是运气变好。第二优化器模型不能只盲目改写它必须能够获得“当前 Prompt 的失败样本 失败原因分析”的信息否则它只会做一些同义替换式的无效改写。第三候选 Prompt 必须保留一定随机性每次生成多个变体从中选择最优而不是只生成一个。在实际项目里我们会在每一次迭代循环中做如下操作先把评估集上的失败样本汇总按照问题类型分组然后构造一段“反思输入”包含当前 Prompt 全文、失败案例、失败原因分析、历史优化记录交给优化模型生成 5 到 10 个 Prompt 变体接着并发生成所有变体在评估集上的输出结果用多维度评分函数打分最后选择得分最高且与当前 Prompt 差异可控的变体作为新的候选。4.2 实现一个可落地的 Prompt 迭代循环这里用一个简化的伪代码来描述我们的 Prompt 自动迭代循环方便没有接触过类似机制的同学理解整个流程# 简化版 Prompt 自动优化循环 def auto_optimize_data_flow(initial_prompt, eval_set, optimizer_model, scorer, max_iterations10): current_prompt initial_prompt for step in range(max_iterations): # 1. 在当前 Prompt 下评估 results run_evaluation(current_prompt, eval_set) failures filter_failures(results) # 2. 如果失败样本过少则停止 if len(failures) threshold: break # 3. 构造反思输入并生成候选 Prompt reflection build_reflection(current_prompt, failures, history) candidates optimizer_model.generate_candidates(reflection, num8) # 4. 批量评估候选 Prompt best_candidate None best_score -inf for candidate in candidates: cand_results run_evaluation(candidate, eval_set) score scorer.evaluate(cand_results) if score best_score and not has_regression(cand_results, results): best_candidate candidate best_score score # 5. 收效显著则更新否则提前终止 if best_candidate and best_score - scorer.baseline(results) min_gain: current_prompt best_candidate else: break return current_prompt这个循环的关键在于has_regression这步它比较候选 Prompt 评估结果和历史基线如果某个类别的得分明显下降即使总分提升也不采纳。这一步能防止 Prompt 为了在总体上拿高分而牺牲特定用户群体。在工程实现上评估集的规模不需要很大我们一般在 200 到 500 条之间关键是覆盖面广每条样本都要有明确的问题分类。跑一轮循环大概只需要几百次模型调用成本可控。Prompt 优化的一个天然优势是它在 Harness 内部完成不涉及模型权重变化所以回滚极其容易——只要把 Prompt 恢复成上一个 commit 就行了。4.3 评估指标怎么选才不会走偏Prompt 优化的效果好不好评估指标说了算。指标设计不当很容易出现“跑分很漂亮上线却很惨”的情况。我们实践下来评估体系必须是多层次、多维度的不能只看单一指标。首先是任务成功率。这个指标最直接Agent 是否完成了用户的目标。在一些工具调用场景可以用“是否在限定步骤内成功执行工具并返回结果”来判定。其次是输出格式合规率。Harness 对输出格式有硬性要求格式不合格就可能导致下游解析失败。然后是用户可见的质量维度包括信息完整性、事实一致性、语气合理性。这部分我们用一个大模型评估下游模型输出用 1 到 5 分制打分。有一点必须提醒大模型评估员也就是 LLM-as-Judge并不是万能的。它在对比两个回答时经常更倾向于“更长、更像人”的那个哪怕事实上另一个更简洁准确。我们在评估维度里加入了“简洁性”这一项并且明确要求评估模型先给理由、再给分数。还有评估模型本身也会偏袒某些表达风格因此我们会定期更换评估模型的版本并用人工标注校正分数。最重要的是评估集不能一成不变。每当发现某类新问题开始频繁出现我们就往评估集里添加对应样本。这样评估集本身也会随系统进化而更新避免整个优化过程陷入“自我感觉良好”的状态。最终我们知道 Prompt 到了什么水平是否该启动下一层级的模型微调。5. 模型微调路径重度进化手段5.1 选 LoRA 还是全参微调Prompt 优化能够修正一部分行为但遇到真正需要“模型自身能力”的场景它就会撞到天花板。比如某个领域的专有术语和表达偏好靠一段 Prompt 是没法真正内化到模型行为里的。这时候就必须启动模型微调。模型微调的第一步是选择微调方式。全参数微调在数据不足、算力有限、且希望频繁回滚的场景下显得过于笨重——每次都要训练一个新完整模型存储成本高、迭代周期长。因此我们通常选择 LoRA 这类参数高效微调方法。LoRA 的核心思想是在原始权重旁边加一圈低秩矩阵训练时只更新这圈小矩阵最终推理时把矩阵合并回原始权重或者动态加载不对原模型带来不可逆的修改。LoRA 的好处非常直观。第一训练成本极低在先前的大模型上做一次 LoRA 微调用少量显卡就能跑完第二可插拔性极强同一个底座模型可以同时挂多个不同的 LoRA 分支按业务场景自由切换也就是说同一套基础设施可以服务多个定制能力第三回滚极其方便不满意就换回原来的基底模型。LoRA 的关键参数也在这里集中说一下。秩和缩放系数的组合是最主要的影响因素秩一般在 8 到 64 之间我们需要根据数据量做选择。数据量小时用较小的秩比如 16数据量大时可以用较大的秩比如 32 或 64。缩放系数一般设置为秩的 2 倍或与秩相同典型配置是r16, alpha32。学习率我们常用 1e-4 到 2e-4 之间。训练轮数则更敏感LoRA 特别容易过拟合常规是 1 到 3 轮跑完每轮都存一个 checkpoint方便后续选最优。5.2 微调训练集的构建与配比模型微调数据的构建方式与 Prompt 优化不同它不依赖线上实时信号而是把之前积累的反馈样本重新组织成标准训练格式。这里说的标准格式是指符合模型训练模板的对话格式。我们以 ChatML 风格为例每个训练样本包含system、user、assistant三种角色完整地还原一段对话上下文。配比上要非常小心。我特别提醒一下偏好对与修正样本的配比。纯粹使用修正样本模型会学会“复述标准答案”但面对开放式问题时可能缺少判断力。纯粹使用偏好对则训练信号相对稀疏且不稳定。我们的做法大致是 70% 修正样本、20% 偏好对、10% 真实优秀对话样本。这个比例不是拍脑袋而是经过多组实验比较后得出的相对均衡值既能让模型快速学会新行为又不至于丢掉原有能力。微调时还有一个容易忽视的问题灾难性遗忘。模型在专门数据上训练太猛它会产生“回灌效应”把源领域的能力压下去。具体表现可以是通用对话能力下降或基础常识出错。我们解决这个问题的方法有三个。第一在训练数据中加入 10% 到 20% 的通用指令数据作为“记忆锚点”。第二采用较小的学习率和较少的训练轮数用保守训练策略。第三在训练过程中保留每个 epoch 的 checkpoint评估时重点关注基准通用能力指标是否下降一旦下降超过阈值就停止训练选择上一个 checkpoint。5.3 微调上线后的回滚与灰度微调版本上线不能一上来就全量放量。我们通常会把一个 LoRA 训练产物挂在 Harness 后面采用灰度的方式逐渐放量。灰度切分的维度可以按用户 ID 分流也可以按请求类型或业务场景切分。这里有一个具体的实践流程。假设我们合并出一个微调后的模型权重我们在网关层配置权重切换10% 的请求流量走新模型90% 走旧模型并实时对比两边的关键指标。这里的关键指标不是泛泛的“用户满意度”而是更细的任务完成率、工具调用成功率、单轮平均交互次数、驳回和重试比例、以及用户显式差评比例。只有这些指标都优于旧模型我们才会逐步把流量从 10% 提高到 30%、50%、再全量。全量放量后也不等于万事大吉。我们会保留一个新版本和旧版本的双通道日志拉取能力持续观察一个自然周左右确认没有明显回退后才把旧线路的权重彻底删除。如果中途发现问题立刻把流量切回旧模型。整个操作在设计上要足够轻量因为模型优化是一个反复迭代的过程每一次失败后的回滚都要做到分钟级完成。LoRA 微调同时还要考虑线上推理的工程实现。合并权重的推理方式耗时更短适合高并发场景但代价是每次切换版本都要重新加载参数。我们团队自己的选择是短路径直接合并中路径采用动态挂载具体要看你们的推理框架支持程度灵活取舍。6. 双轨合并Prompt 优化与模型微调如何协同6.1 两条路径的边界与叠加风险很多团队在推进时容易陷入一个误区就是认为 Prompt 优化和微调可以同时进行、并行迭代、快速叠加收益。但实际做下来这两条路径同时放开往往会让你难以判断效果到底来自哪边甚至会造成行为冲突。举例来说你在 Prompt 中加入了“回答前先确认用户意图”的规则同时在微调数据里也大量强化了这类行为。结果就是模型在大部分请求中都会先做一轮冗长的确认哪怕有些请求意图已经非常明确反而破坏体验。这其实是“过度纠正”的典型表现。更隐蔽的冲突是风格上的Prompt 要求简洁作答但微调数据里的人工重写答案偏偏是细致风格模型内部可能会分裂。因此我们制定了一条原则同一时期只放开一条优化路径。如果当前问题更偏向 Harness 和指令层面的错误比如输出格式、工具调用步骤、上下文理解那就先做 Prompt 优化。如果当前问题更偏向模型的事实性、风格、领域偏好那就停下来固定 Prompt切到微调路径。等微调收敛、稳定上线后再重新审视 Prompt 是否需要跟着微调结果做一次适配。这条策略让整个系统的变化保持“单变量”也让效果归因变得简单。否则当线上指标波动时你根本说不清是 Prompt 的问题还是微调权重的问题。工程迭代最怕不是没有改进方向而是不知道问题出在哪一环。6.2 版本管理与效果归因双轨机制下的版本管理远比直接训练模型要复杂。我们为每一轮迭代建立了一条完整的版本链记录了当时的 Prompt 版本、模型版本、训练数据集版本、评估集版本以及评测结果。这个版本链直接决定你是否能“回到昨夜那个运行良好的状态”。实际操作中我们把 Prompt、模型、数据集每一份都当成独立的可回滚文件看待。Prompt 存入代码仓库跟踪每次提交的差异。数据集用数据版本管理工具管理每一个训练集都有唯一的哈希标识。模型自然不用多说每一个 checkpoint 都会带上对应的训练元信息。线上跑的是哪一套组合对应的是哪个版本链全部在配置清单里写清楚。一旦线上出现明显的指标回退我们的排查流程是先看最近 24 小时内哪些版本组合发生了变化再把变化前后两组配置放到在线的影子评估集上去对跑一遍定位到具体哪个组件引起回退。如果没有严格的版本管理这一步几乎不可能快速完成你可能需要同时排查几个月来所有改动那种场面非常痛苦。效果归因还有一个技巧每次只调整一个维度。比如这一轮我们只动 Prompt微调版本保持不动那么线上效果若有变化就基本可以归因到 Prompt 层面上。这种谨慎归因的方式牺牲了一些迭代速度但大大提升了系统的稳定性和可持续演进能力。在整个自我进化机制中稳定性比短期刷分重要得多因为进化是一个长期过程你不可能每次都在一团乱麻里缝缝补补。7. 常见问题与排查实录7.1 问题速查表这里把我们在项目实战中遇到的高频问题归纳成一张速查表按照“现象—可能原因—排查方法—解决方案”的格式组织方便大家直接对照。现象可能原因排查方向解决方案Prompt 优化后线上好评率下降评估集与线上分布不一致对比评估集与线上请求语义分布按线上采样扩充评估集补充新问题类型微调后模型通用能力下降数据配比失衡或训练轮数过多检查训练集配比观察通用评估集得分加入通用数据锚点降低 epoch退回前一个 checkpoint同一条用户问题出现不同回复未约束解码参数或 Prompt 过拟合检查 temperature 设置和 Prompt 中是否过度指定细节增加解码参数确定性精简 Prompt 冗余内容用户点踩但无法定位具体原因标签体系覆盖不足反馈信息过少分析反馈文本与对话上下文相关性细化标签增加人工复核流程工具调用失败问题反复出现Prompt 和微调同时围绕该行为叠加修正查看版本链中两边变更时间点固定单一路径迭代另一条路径保持冻结优化后长尾场景反而变差高频问题样本占据训练集中过大比例检查反馈采样和去重参数使用分层采样加聚类约束控制类别比例评估模型打分与用户感受不一致评估维度不完整或评估模型版本过旧人工抽样对比评估输出和用户反馈增加人工校正集升级评估模型并校正分数这张表并不能覆盖所有问题但它提供了一个通用排查框架。遇到问题时不要只盯着模型输出本身更要去检查整个反馈链路和数据管道是否健康。7.2 避坑经验与实录最后聊几个我花了不少学费才换来的经验希望能帮后来的人少走弯路。第一个经验是不要迷信自动优化循环的“自动”二字。自动 Prompt 优化看起来可以完全无人值守地迭代但实际上它需要非常频繁的人工干预只不过干预点从“改 Prompt”变成了“审查数据质量和评估结果”。我们没有让循环完全自动运转几周不闻不问而是在每轮迭代后强制加入一个人工确认环节确认当前最优 Prompt 是否真的符合产品语义。经过一段时间后这个确认成本会随着数据质量提升而慢慢降低。第二个经验是用户反馈里的“坏样本”比例比你想象的高得多。我们发现线上点踩的样本中有相当一部分其实并不是 Agent 答错了而是用户自己诉求表达不清、或用户对产品预期有偏差。这类样本如果进入训练集会让模型变得越来越“顺从”甚至开始迎合用户的不合理要求。我们后来专门加了一个类别标签叫作“无法判定的反馈”这类样本只做存档不参与任何训练。第三个经验是评估模型自身的漂移问题。我们早期一直使用同一个小版本评估模型做评分后来发现它给出的分数越来越高但人工抽查却发现生成质量并没有同步提升最后调查确认是评估模型偏好发生了变化导致同样的输出在新旧版本上得分差异明显。自那以后每当我们替换评估模型都会在固定的黄金测试集上重新校准打分确保前后对比口径一致。还有一个值得记录的细节是几次迭代之后我们把“Prompt 回滚”做成了非常快速的动作复杂度缩小到一个配置文件切换这带来的收益远远超出想象。曾经有一次线上新 Prompt 虽然平均分提升了但在某个用户群体中引发了严重误解我们在一分钟内就完成了回滚几乎没有造成任何实际损失。做进化机制最重要的不是每次都确认进化方向正确而是确保一旦发现自己走错方向能以最低代价退回来。进化动力小的退路没有保障大胆尝试也会变成一场豪赌。在实际操作中我也越来越感受到所谓自我进化机制并不是一个花里胡哨的“全自动 AI”它更像是一套精心设计的工程流程把人类反馈、数据治理、模型训练、在线实验这几块有机地串联起来让每一次模型的进步都是建立在可量化、可解释、可回退的基础上。这条路需要持续打磨反馈质量需要克制地选择优化路径更需要敬畏线上系统的稳定性。如果你也正准备在自己的 Agent 系统中搭建这样一套反馈闭环希望这些踩坑经验和代码思路能帮你节省几周的调研时间让你的进化机制一开始就站在稳妥的地基上。
做这个项目之前我一直觉得“AI Agent 能跑起来”才是最难的部分后来真正上了线才发现让一个 Agent 稳定、可靠地持续变好才是真正烧脑的环节。尤其是当你面对的是 Harness 这种既要约束模型行为、又要应对复杂真实请求的框架时最直接的痛点其实是用户的每一条不满意反馈都在“白给”而我们的系统却始终反应迟钝。于是我们做了这样一套基于用户反馈的模型微调加 Prompt 优化双轨流程把 Agent Harness 变成一个有自我进化能力的闭环系统。这篇文章就是把整个流程的设计思路、数据管道、迭代方法、踩坑记录都摊开来讲适合那些正在做 Agent 类产品、被线上反馈淹没却不知道如何下手的工程师参考。1. 为什么需要自我进化机制先看清 Harness 的定位1.1 Agent Harness 在系统里到底管什么很多同学第一次听到“Harness Engineering”会以为是什么花哨的装备其实它就是把 Agent 框在一个可控的执行环境里。通俗点说Harness 就像给一个能力很强但性格不稳定的员工配了一位资深项目经理——模型负责出主意Harness 负责让主意在正确的轨道上落地。它管理的内容包括会话状态、工具调用路由、上下文管理、权限边界、以及策略注入。换句话说模型是大脑Harness 是神经系统和四肢。在实际项目里Harness 层做的事情非常琐碎但关键。例如用户问“帮我把这份列表按时间排序再汇总一下”模型本身可能只会回答“好的我可以这样做”但如果 Harness 没有正确解析工具调用、没有把排序结果包装成用户可以理解的摘要整个交互就是失败的。我们初期踩过很多坑以为是模型能力不够后来发现大部分问题其实出在 Harness 的编排策略上——比如工具返回结果太长直接把上下文塞爆比如多个工具并行调用时结果顺序错乱。Harness 的核心价值在于“可控”。模型是概率输出的同一个 Prompt 每次生成的内容都可能不同而 Harness 能把这种行为框在一个可接受范围内。比如规定模型必须按照某个 JSON Schema 输出工具调用参数如果不符合就解析失败重试比如设置上下文窗口的使用上限超出就做压缩或摘要。这些规则保障了 Agent 在大多数场景下不会彻底放飞自我。但是问题也来了这些规则是谁定的答案通常是工程师在开发阶段拍脑袋定的。一旦上线用户请求的分布千变万化静态规则很快就会和真实场景脱节。1.2 静态编排撑不住动态场景自我进化不是锦上添花我见过不少 Agent 项目的做法是上线后发现某个问题就由开发手动修改一段 Prompt 或者加一条 Harness 规则然后重新发版。这种做法在 Demo 阶段没问题但在真实业务里完全不可持续。用户反馈是 7×24 小时不断流入的靠人工盯帖子、盯工单、盯系统日志来定位问题存在三个致命缺陷。第一响应速度太慢。一个反馈从用户提交到被工程师看到再到修改 Prompt、测试、发版往往需要好几天。这段时间内大量同类用户持续遭遇同样糟糕的体验。第二人工修改的覆盖度极其有限。线上不断出现新类型的失败很多是极其小众的长尾场景开发团队根本不可能为每一种情况都手工设计规则。第三人工优化缺乏统一衡量标准。每个人改 Prompt 都有自己的偏好可能某次修改让 A 类请求变好了却让 B 类请求变差了而这种副作用往往要等上线很久之后才暴露。自我进化机制的意义就在于把整个改进过程从“人工驱动”变成“数据驱动”。用户反馈本身就是天然的、免费的标注数据它直接告诉我们模型在哪些地方让用户不满意了。把这些反馈结构化、标签化之后既可以用来看清楚问题的分布也可以通过两种路径去消耗数据一种是快速路径通过自动化的 Prompt 优化去修正 Harness 层的指令策略另一种是深度路径通过模型微调去修改模型本身的行为偏好。两条路径的结合让整条链路不再依赖人的实时介入而是形成一条“感知-分析-优化-验证”的自动闭环。想强调的是自我进化不等于让 Agent 完全自治地乱改自己。进化必须在受控的 Harness 框架里进行每一轮优化都要有明确的触发条件、实验验证和回滚机制否则很容易出现“越改越歪”的失控状态。我们后面所有内容都是围绕“可控地进化”这一点展开的。2. 反馈信号的设计与采集进化机制的燃料2.1 显式反馈与隐式反馈怎么分工自我进化机制的起点不是模型也不是 Prompt而是反馈信号。没有高质量且持续稳定的反馈流后面的优化全部是无源之水。反馈从采集方式上可以分成显式和隐式两类两者必须配合使用。显式反馈指的是用户主动表达态度的信号。最典型的就是聊天气泡下面的点赞/点踩按钮或者用户在对话框旁边输入一条简短评价比如“回答不对”“太啰嗦了”。显式反馈的优点在于意图明确可靠性高缺点是覆盖率低大多数用户根本懒得点。尤其是一个 Agent 回答得中规中矩时用户基本不会给出任何积极反馈导致正样本稀疏。隐式反馈则是从用户行为里“猜”出来的态度信号。举例来说用户复制了 Agent 的某段回答很可能是这段内容对他有用用户点击了 Agent 推荐的工具或内容说明这条推荐是对的用户在一次回答后立刻关闭了对话窗口可能就是不满意用户连续两次编辑同一个回复说明生成内容不符合他的需求。这些信号不需要用户主动操作覆盖率高但噪声也大需要仔细定义阈值和结合上下文判断。在实际项目中我们同时采集这两类信号但采用的处理策略完全不同。显式反馈直接进入高优先级处理队列因为它的置信度最高隐式反馈则会先做一轮规则过滤和交叉验证例如“复制行为”这个信号只有在上下文窗口确实包含 Agent 生成的代码或地址时才被记为正面反馈。“重新生成”这个信号我们同时结合其后的最终采纳结果如果用户点了重新生成之后没有继续操作则记为中性的体验差信号。2.2 构建可用的反馈标签体系原始反馈只是零散的满意/不满意但如果你想把反馈用于 Prompt 优化和模型微调就必须把“不满意”拆解成可操作的具体问题。我们在项目里设计了一套轻量标签体系核心是回答“用户到底对什么不满意”。这套标签体系分成了几个大类。意图理解错误Agent 没有正确理解用户的目的回答方向跑偏了。信息缺失回答内容不够完整用户需要的信息没有被覆盖。事实错误或幻觉生成的内容和客观事实不一致或干脆编造信息。格式不合格用户要求表格Agent 给了一段长文本用户要 JSONAgent 回了 Markdown。工具调用失败Harness 没能正确触发、解析或执行工具调用导致任务中断。风格与态度问题语气、详细度不符合用户预期。标签怎么打我们采用三层策略。第一层规则打标。比如检测到输出格式不符合要求、工具返回 error 状态码这类问题可以直接用确定性规则标记。第二层模型自动打标也就是用一个独立的小模型对反馈样本进行多标签分类这里不需要特别复杂的模型普通的分类模型或者当前的基模就好。第三层用户主动表态。如果用户点踩时选了“回答错误”等预置原因直接采用。这套标签体系是整个进化机制的关键因为后续的 Prompt 优化和微调都需要“带有明确问题类型”的样本而不是笼统的坏样本。还有一个容易被忽略的点每条反馈需要带上对应的会话上下文快照至少要包含完整的用户问题、Agent 当时的回复、Harness 输入给模型的那份 Prompt 片段、以及工具调用的过程记录。没有上下文标签做得再准也无法用于后续优化。2.3 反馈质量管理清洗与去重反馈信号天然带着大量噪声尤其是隐式反馈。直接拿脏数据去做优化轻则浪费计算资源重则把模型带偏。反馈质量管理这步做不好后面所有环节都是失衡的。首先要过滤掉的是“无效反馈”。有些用户会连续在同一轮对话里点多次踩可能只是手滑有些用户根本不使用 Agent 的核心能力只是单纯地乱输入还有一些反馈内容长度不足、与对话主题毫无关联。我们用一套简单的规则做初筛反馈文本长度不低于一定阈值且不能只包含表情符号同一会话内短时间内重复性质相同的反馈只保留一条对话轮的上下文缺失超过一半的丢弃。其次要做内容脱敏和合规处理。用户反馈里可能包含电话号码、地址、姓名等私人信息。这些数据在进入训练管道之前必须经过脱敏处理。我们直接采用实体识别加替换的方式把所有手机号、邮箱、身份证号、地址替换为占位符。这里提醒一句这一步千万不要省因为微调数据一旦把用户隐私带进去模型生成时可能把这些信息“背”出来这是重大安全事故。最后是去重。线上会遇到大量近似重复的反馈例如几十个用户都在问同一种报表导出的问题回答都是格式不对。如果不做去重模型会严重偏向这些高频问题导致长尾能力退化。我们的做法是做语义聚类去重用嵌入向量对反馈样本做粗聚类再限制同一个簇在一个训练批次中的样本数量上限。这样既保留了高频问题的代表性也不至于让它彻底淹没低频问题。3. 从反馈到训练数据数据管道的具体做法3.1 反馈如何转化为训练样本反馈经清洗和标签化之后还只是“问题描述”距离模型训练数据的标准格式还有一步。这条转化管道的核心是把用户反馈变成模型能学的东西。不同路径需要不同格式的样本这里重点说三种最常用的。第一种是偏好对样本也是直接偏好优化或奖励模型最常用的数据形态。一个样本包含同一个用户问题下的两个回答一个是被用户嫌弃的“拒绝回答”一个是经过验证的“偏好回答”。挑战在于用户往往只给出了负面反馈偏好回答从哪来我们通常从两个渠道获取一是其他真实用户对同类问题的满意回答二是让更擅长该任务的模型针对失败原因进行修正生成。对于后者我们还会加入人工抽检确保修正后的回答没有引入新的错误。第二种是修正样本主要服务于监督微调。它的核心思路是把“失败案例”变成“修正案例”。具体操作方式是拿到一条失败对话保留原始用户问题用人工或更强模型重写一遍完整的期望回答然后把重写后的回答作为监督目标。修正样本的优点是简单直接易于大规模生成缺点是如果重写质量参差不齐会让模型学到不稳定的输出风格。第三种是行为轨迹样本专门用于 Harness 层的优化。这一类的特点在于重写目标不是最终回答文本而是模型决策的过程比如正确的工具调用顺序、正确的参数提取方式、正确的上下文取舍。我们会在反馈样本中标记工具调用失败类标签然后重跑一遍该任务记录新的正确轨迹形成“用户问题期望工具调用序列期望最终输出”的三元组。这些样本统一进入数据仓库记录来源、标签、时间、所属模型版本等元信息。别小看这一步后续做效果归因时数据来源不明会造成极大的排查困难。3.2 数据配比与采样策略训练数据不是把反馈样本一股脑丢给模型就完事数据配比直接决定了优化后模型的实际表现。我们最早犯过一个错误把大量反馈修正样本堆在一起微调结果模型在反馈密集的类型上表现大幅提升但在普通业务请求上却出现了明显的退化说话方式也变了。后来我们引入了严格的数据配比策略。第一基础能力数据必须占大头。无论反馈样本多么珍贵模型自身的通用能力不能被破坏。我们在微调数据里保留了大量的通用指令数据、领域常识数据这部分通常占整体训练数据量的 60% 以上。第二反馈相关数据控制在合理份额。我们把所有反馈修正样本和偏好对放在一起整体占 25% 左右并确保其中每个细分问题类型不超过整体 5%。第三任务特定正样本占到剩余份额。这里的正样本来自历史表现优秀的高满意度对话它的作用是稳住模型在某些优秀场景的表现防止微调过程把这些能力冲淡。采样策略上也有一些细节值得分享。高频问题我们要控制住数量低频长尾问题要保证至少出现若干次。我们的做法是基于标签体系做分层采样每个标签类别内保证最小样本数量类别内再按语义多样性排序采样。这样处理后的训练集在业务分布上会比原始反馈集健康得多。3.3 质量门槛与人工抽检自动化的数据管道产出的训练样本质量一定不是均衡的必须设置质量门槛。我们的做法是双重过滤加人工抽检。双重过滤的第一重是规则过滤主要检查格式和内容完整性。比如偏好对中两个回答完全一致或者修正样本重写后的回答仍然包含明显幻觉内容的直接丢弃。第二重是模型过滤用一个质量评估模型对所有训练样本打分评估维度包括回答是否完整、是否忠于上下文、是否符合用户意图。只有分数超过阈值的样本才进入最终训练集。人工抽检的比例虽然不能太高但绝对不能没有。我们保持每周抽检一批新增样本按问题类型分层抽取 100 到 200 条由团队内不同角色分别看然后对“该样本是否可用于训练”和“重写答案是否比原始答案更优”两个问题做标注。如果某类标签下人工认可率低于 85%我们就认为这一类样本的质量不可靠会暂时关闭该标签的数据流入并排查原因。很多人会忽略抽检的价值觉得有自动化过滤就够了。但我的经验是自动过滤只能挡住明显的坏样本却挡不住“看起来没问题但隐含文化偏见”或“重写风格与产品调性不一致”的软性问题这些只能靠人眼判断。4. Prompt 优化的自动迭代轻量进化路径4.1 自动 Prompt 优化的核心逻辑Prompt 优化和模型微调并不是非此即彼的关系。在实际工程节奏里我们通常优先做 Prompt 优化因为它的成本低、周期短、可解释性强而且可以直接作用在 Harness 层不需要重新部署模型。自动 Prompt 优化的核心思想可以用一个循环来概括给定一个固定的评估集让一个“优化器模型”分析当前 Prompt 在评估集上的失败案例生成若干候选 Prompt 变体然后在评估集上对全部候选 Prompt 做一次批量评估保留效果最好、且未引入明显副作用的一个进入下一轮迭代。这个思路听起来很朴素但实际落地时有几个关键细节决定了成败。第一评估集必须固定且具有代表性。如果评估集不稳定每一轮之间就没有对比基础你根本无法判断是 Prompt 变好还是运气变好。第二优化器模型不能只盲目改写它必须能够获得“当前 Prompt 的失败样本 失败原因分析”的信息否则它只会做一些同义替换式的无效改写。第三候选 Prompt 必须保留一定随机性每次生成多个变体从中选择最优而不是只生成一个。在实际项目里我们会在每一次迭代循环中做如下操作先把评估集上的失败样本汇总按照问题类型分组然后构造一段“反思输入”包含当前 Prompt 全文、失败案例、失败原因分析、历史优化记录交给优化模型生成 5 到 10 个 Prompt 变体接着并发生成所有变体在评估集上的输出结果用多维度评分函数打分最后选择得分最高且与当前 Prompt 差异可控的变体作为新的候选。4.2 实现一个可落地的 Prompt 迭代循环这里用一个简化的伪代码来描述我们的 Prompt 自动迭代循环方便没有接触过类似机制的同学理解整个流程# 简化版 Prompt 自动优化循环 def auto_optimize_data_flow(initial_prompt, eval_set, optimizer_model, scorer, max_iterations10): current_prompt initial_prompt for step in range(max_iterations): # 1. 在当前 Prompt 下评估 results run_evaluation(current_prompt, eval_set) failures filter_failures(results) # 2. 如果失败样本过少则停止 if len(failures) threshold: break # 3. 构造反思输入并生成候选 Prompt reflection build_reflection(current_prompt, failures, history) candidates optimizer_model.generate_candidates(reflection, num8) # 4. 批量评估候选 Prompt best_candidate None best_score -inf for candidate in candidates: cand_results run_evaluation(candidate, eval_set) score scorer.evaluate(cand_results) if score best_score and not has_regression(cand_results, results): best_candidate candidate best_score score # 5. 收效显著则更新否则提前终止 if best_candidate and best_score - scorer.baseline(results) min_gain: current_prompt best_candidate else: break return current_prompt这个循环的关键在于has_regression这步它比较候选 Prompt 评估结果和历史基线如果某个类别的得分明显下降即使总分提升也不采纳。这一步能防止 Prompt 为了在总体上拿高分而牺牲特定用户群体。在工程实现上评估集的规模不需要很大我们一般在 200 到 500 条之间关键是覆盖面广每条样本都要有明确的问题分类。跑一轮循环大概只需要几百次模型调用成本可控。Prompt 优化的一个天然优势是它在 Harness 内部完成不涉及模型权重变化所以回滚极其容易——只要把 Prompt 恢复成上一个 commit 就行了。4.3 评估指标怎么选才不会走偏Prompt 优化的效果好不好评估指标说了算。指标设计不当很容易出现“跑分很漂亮上线却很惨”的情况。我们实践下来评估体系必须是多层次、多维度的不能只看单一指标。首先是任务成功率。这个指标最直接Agent 是否完成了用户的目标。在一些工具调用场景可以用“是否在限定步骤内成功执行工具并返回结果”来判定。其次是输出格式合规率。Harness 对输出格式有硬性要求格式不合格就可能导致下游解析失败。然后是用户可见的质量维度包括信息完整性、事实一致性、语气合理性。这部分我们用一个大模型评估下游模型输出用 1 到 5 分制打分。有一点必须提醒大模型评估员也就是 LLM-as-Judge并不是万能的。它在对比两个回答时经常更倾向于“更长、更像人”的那个哪怕事实上另一个更简洁准确。我们在评估维度里加入了“简洁性”这一项并且明确要求评估模型先给理由、再给分数。还有评估模型本身也会偏袒某些表达风格因此我们会定期更换评估模型的版本并用人工标注校正分数。最重要的是评估集不能一成不变。每当发现某类新问题开始频繁出现我们就往评估集里添加对应样本。这样评估集本身也会随系统进化而更新避免整个优化过程陷入“自我感觉良好”的状态。最终我们知道 Prompt 到了什么水平是否该启动下一层级的模型微调。5. 模型微调路径重度进化手段5.1 选 LoRA 还是全参微调Prompt 优化能够修正一部分行为但遇到真正需要“模型自身能力”的场景它就会撞到天花板。比如某个领域的专有术语和表达偏好靠一段 Prompt 是没法真正内化到模型行为里的。这时候就必须启动模型微调。模型微调的第一步是选择微调方式。全参数微调在数据不足、算力有限、且希望频繁回滚的场景下显得过于笨重——每次都要训练一个新完整模型存储成本高、迭代周期长。因此我们通常选择 LoRA 这类参数高效微调方法。LoRA 的核心思想是在原始权重旁边加一圈低秩矩阵训练时只更新这圈小矩阵最终推理时把矩阵合并回原始权重或者动态加载不对原模型带来不可逆的修改。LoRA 的好处非常直观。第一训练成本极低在先前的大模型上做一次 LoRA 微调用少量显卡就能跑完第二可插拔性极强同一个底座模型可以同时挂多个不同的 LoRA 分支按业务场景自由切换也就是说同一套基础设施可以服务多个定制能力第三回滚极其方便不满意就换回原来的基底模型。LoRA 的关键参数也在这里集中说一下。秩和缩放系数的组合是最主要的影响因素秩一般在 8 到 64 之间我们需要根据数据量做选择。数据量小时用较小的秩比如 16数据量大时可以用较大的秩比如 32 或 64。缩放系数一般设置为秩的 2 倍或与秩相同典型配置是r16, alpha32。学习率我们常用 1e-4 到 2e-4 之间。训练轮数则更敏感LoRA 特别容易过拟合常规是 1 到 3 轮跑完每轮都存一个 checkpoint方便后续选最优。5.2 微调训练集的构建与配比模型微调数据的构建方式与 Prompt 优化不同它不依赖线上实时信号而是把之前积累的反馈样本重新组织成标准训练格式。这里说的标准格式是指符合模型训练模板的对话格式。我们以 ChatML 风格为例每个训练样本包含system、user、assistant三种角色完整地还原一段对话上下文。配比上要非常小心。我特别提醒一下偏好对与修正样本的配比。纯粹使用修正样本模型会学会“复述标准答案”但面对开放式问题时可能缺少判断力。纯粹使用偏好对则训练信号相对稀疏且不稳定。我们的做法大致是 70% 修正样本、20% 偏好对、10% 真实优秀对话样本。这个比例不是拍脑袋而是经过多组实验比较后得出的相对均衡值既能让模型快速学会新行为又不至于丢掉原有能力。微调时还有一个容易忽视的问题灾难性遗忘。模型在专门数据上训练太猛它会产生“回灌效应”把源领域的能力压下去。具体表现可以是通用对话能力下降或基础常识出错。我们解决这个问题的方法有三个。第一在训练数据中加入 10% 到 20% 的通用指令数据作为“记忆锚点”。第二采用较小的学习率和较少的训练轮数用保守训练策略。第三在训练过程中保留每个 epoch 的 checkpoint评估时重点关注基准通用能力指标是否下降一旦下降超过阈值就停止训练选择上一个 checkpoint。5.3 微调上线后的回滚与灰度微调版本上线不能一上来就全量放量。我们通常会把一个 LoRA 训练产物挂在 Harness 后面采用灰度的方式逐渐放量。灰度切分的维度可以按用户 ID 分流也可以按请求类型或业务场景切分。这里有一个具体的实践流程。假设我们合并出一个微调后的模型权重我们在网关层配置权重切换10% 的请求流量走新模型90% 走旧模型并实时对比两边的关键指标。这里的关键指标不是泛泛的“用户满意度”而是更细的任务完成率、工具调用成功率、单轮平均交互次数、驳回和重试比例、以及用户显式差评比例。只有这些指标都优于旧模型我们才会逐步把流量从 10% 提高到 30%、50%、再全量。全量放量后也不等于万事大吉。我们会保留一个新版本和旧版本的双通道日志拉取能力持续观察一个自然周左右确认没有明显回退后才把旧线路的权重彻底删除。如果中途发现问题立刻把流量切回旧模型。整个操作在设计上要足够轻量因为模型优化是一个反复迭代的过程每一次失败后的回滚都要做到分钟级完成。LoRA 微调同时还要考虑线上推理的工程实现。合并权重的推理方式耗时更短适合高并发场景但代价是每次切换版本都要重新加载参数。我们团队自己的选择是短路径直接合并中路径采用动态挂载具体要看你们的推理框架支持程度灵活取舍。6. 双轨合并Prompt 优化与模型微调如何协同6.1 两条路径的边界与叠加风险很多团队在推进时容易陷入一个误区就是认为 Prompt 优化和微调可以同时进行、并行迭代、快速叠加收益。但实际做下来这两条路径同时放开往往会让你难以判断效果到底来自哪边甚至会造成行为冲突。举例来说你在 Prompt 中加入了“回答前先确认用户意图”的规则同时在微调数据里也大量强化了这类行为。结果就是模型在大部分请求中都会先做一轮冗长的确认哪怕有些请求意图已经非常明确反而破坏体验。这其实是“过度纠正”的典型表现。更隐蔽的冲突是风格上的Prompt 要求简洁作答但微调数据里的人工重写答案偏偏是细致风格模型内部可能会分裂。因此我们制定了一条原则同一时期只放开一条优化路径。如果当前问题更偏向 Harness 和指令层面的错误比如输出格式、工具调用步骤、上下文理解那就先做 Prompt 优化。如果当前问题更偏向模型的事实性、风格、领域偏好那就停下来固定 Prompt切到微调路径。等微调收敛、稳定上线后再重新审视 Prompt 是否需要跟着微调结果做一次适配。这条策略让整个系统的变化保持“单变量”也让效果归因变得简单。否则当线上指标波动时你根本说不清是 Prompt 的问题还是微调权重的问题。工程迭代最怕不是没有改进方向而是不知道问题出在哪一环。6.2 版本管理与效果归因双轨机制下的版本管理远比直接训练模型要复杂。我们为每一轮迭代建立了一条完整的版本链记录了当时的 Prompt 版本、模型版本、训练数据集版本、评估集版本以及评测结果。这个版本链直接决定你是否能“回到昨夜那个运行良好的状态”。实际操作中我们把 Prompt、模型、数据集每一份都当成独立的可回滚文件看待。Prompt 存入代码仓库跟踪每次提交的差异。数据集用数据版本管理工具管理每一个训练集都有唯一的哈希标识。模型自然不用多说每一个 checkpoint 都会带上对应的训练元信息。线上跑的是哪一套组合对应的是哪个版本链全部在配置清单里写清楚。一旦线上出现明显的指标回退我们的排查流程是先看最近 24 小时内哪些版本组合发生了变化再把变化前后两组配置放到在线的影子评估集上去对跑一遍定位到具体哪个组件引起回退。如果没有严格的版本管理这一步几乎不可能快速完成你可能需要同时排查几个月来所有改动那种场面非常痛苦。效果归因还有一个技巧每次只调整一个维度。比如这一轮我们只动 Prompt微调版本保持不动那么线上效果若有变化就基本可以归因到 Prompt 层面上。这种谨慎归因的方式牺牲了一些迭代速度但大大提升了系统的稳定性和可持续演进能力。在整个自我进化机制中稳定性比短期刷分重要得多因为进化是一个长期过程你不可能每次都在一团乱麻里缝缝补补。7. 常见问题与排查实录7.1 问题速查表这里把我们在项目实战中遇到的高频问题归纳成一张速查表按照“现象—可能原因—排查方法—解决方案”的格式组织方便大家直接对照。现象可能原因排查方向解决方案Prompt 优化后线上好评率下降评估集与线上分布不一致对比评估集与线上请求语义分布按线上采样扩充评估集补充新问题类型微调后模型通用能力下降数据配比失衡或训练轮数过多检查训练集配比观察通用评估集得分加入通用数据锚点降低 epoch退回前一个 checkpoint同一条用户问题出现不同回复未约束解码参数或 Prompt 过拟合检查 temperature 设置和 Prompt 中是否过度指定细节增加解码参数确定性精简 Prompt 冗余内容用户点踩但无法定位具体原因标签体系覆盖不足反馈信息过少分析反馈文本与对话上下文相关性细化标签增加人工复核流程工具调用失败问题反复出现Prompt 和微调同时围绕该行为叠加修正查看版本链中两边变更时间点固定单一路径迭代另一条路径保持冻结优化后长尾场景反而变差高频问题样本占据训练集中过大比例检查反馈采样和去重参数使用分层采样加聚类约束控制类别比例评估模型打分与用户感受不一致评估维度不完整或评估模型版本过旧人工抽样对比评估输出和用户反馈增加人工校正集升级评估模型并校正分数这张表并不能覆盖所有问题但它提供了一个通用排查框架。遇到问题时不要只盯着模型输出本身更要去检查整个反馈链路和数据管道是否健康。7.2 避坑经验与实录最后聊几个我花了不少学费才换来的经验希望能帮后来的人少走弯路。第一个经验是不要迷信自动优化循环的“自动”二字。自动 Prompt 优化看起来可以完全无人值守地迭代但实际上它需要非常频繁的人工干预只不过干预点从“改 Prompt”变成了“审查数据质量和评估结果”。我们没有让循环完全自动运转几周不闻不问而是在每轮迭代后强制加入一个人工确认环节确认当前最优 Prompt 是否真的符合产品语义。经过一段时间后这个确认成本会随着数据质量提升而慢慢降低。第二个经验是用户反馈里的“坏样本”比例比你想象的高得多。我们发现线上点踩的样本中有相当一部分其实并不是 Agent 答错了而是用户自己诉求表达不清、或用户对产品预期有偏差。这类样本如果进入训练集会让模型变得越来越“顺从”甚至开始迎合用户的不合理要求。我们后来专门加了一个类别标签叫作“无法判定的反馈”这类样本只做存档不参与任何训练。第三个经验是评估模型自身的漂移问题。我们早期一直使用同一个小版本评估模型做评分后来发现它给出的分数越来越高但人工抽查却发现生成质量并没有同步提升最后调查确认是评估模型偏好发生了变化导致同样的输出在新旧版本上得分差异明显。自那以后每当我们替换评估模型都会在固定的黄金测试集上重新校准打分确保前后对比口径一致。还有一个值得记录的细节是几次迭代之后我们把“Prompt 回滚”做成了非常快速的动作复杂度缩小到一个配置文件切换这带来的收益远远超出想象。曾经有一次线上新 Prompt 虽然平均分提升了但在某个用户群体中引发了严重误解我们在一分钟内就完成了回滚几乎没有造成任何实际损失。做进化机制最重要的不是每次都确认进化方向正确而是确保一旦发现自己走错方向能以最低代价退回来。进化动力小的退路没有保障大胆尝试也会变成一场豪赌。在实际操作中我也越来越感受到所谓自我进化机制并不是一个花里胡哨的“全自动 AI”它更像是一套精心设计的工程流程把人类反馈、数据治理、模型训练、在线实验这几块有机地串联起来让每一次模型的进步都是建立在可量化、可解释、可回退的基础上。这条路需要持续打磨反馈质量需要克制地选择优化路径更需要敬畏线上系统的稳定性。如果你也正准备在自己的 Agent 系统中搭建这样一套反馈闭环希望这些踩坑经验和代码思路能帮你节省几周的调研时间让你的进化机制一开始就站在稳妥的地基上。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
