几个月前我尝试搭一个自动化的数据科学助手最初模型的代码生成能力确实让我兴奋了很久——让它写个缺失值处理函数、画个分布图几乎是一句话的事。但随着任务链逐渐拉长从数据清洗、探索性分析、特征工程到建模调参问题开始暴露它做着做着就忘了自己在干什么。清洗阶段改过的字段逻辑到建模阶段还在用旧字段探索性分析做了一半直接跳到建模遇到数据异常也不回头校验而是想当然地补一个值。最让我头疼的是同一个任务跑两次中间步骤的差异大到让我怀疑跑的是不是两个程序。这让我意识到一个关键问题在数据科学场景里LLM Agent 最大的瓶颈不是单步能力而是长链路下的过程失控。围绕这个痛点我研究和实验了 MOSAIC 这样的思路——用案例检索给 Agent 提供经验参照用 Blueprint 组合把任务拆成可复用的积木再用离线 RL 对中间决策做精细打磨。这篇文章想把这些工程化经验完整地梳理一遍讲讲每个组件解决什么问题、为什么这么设计、实操中哪些细节最容易被忽略希望对做 LLM Agent 应用的朋友有帮助。1. 数据科学 Agent 的真正痛点不是模型不够聪明而是中间步骤失控1.1 长链路任务中的目标漂移现象数据科学建模天然是一个多阶段任务从数据接入、质量探查、清洗、特征构造、模型选择、训练评估到结果解释中间要经历十几个甚至几十个决策点。每个决策点单看都不难但连在一起就非常考验 Agent 对全局目标的把握能力。我在项目中总结过一个很典型的目标漂移模式当任务进行到第五步或第六步时模型对最初任务描述的记忆已经变得模糊它开始根据当前的局部上下文自由发挥而不是严格对齐最初的目标。比如一个客户流失预测任务原始需求里明确要求对类别不平衡做处理但 Agent 在建模阶段直接用了默认参数训练完全没做采样或加权再比如一个时序预测任务需求里强调要保留时间顺序做切分但 Agent 在特征工程阶段自作主张做了随机打乱。这种漂移不是模型能力不够而是长上下文下的注意力衰减加上中间状态过多导致的。数据科学任务尤其容易触发这个问题因为它每一步的产物都是高结构化的数据对象中间状态一多模型就容易被最近的局部信息带走。1.2 为什么调 Prompt 给工具解决不了根本问题我见过不少团队的第一反应是优化 Prompt把任务描述写得更详细加上各种请务必按照以下步骤执行的强调。坦白说这种做法在任务只有两三个步骤时有效一旦步骤超过五六个Prompt 就成了一种软约束——模型不是不遵守而是遵守着遵守着就偏了。工具调用比如给 Agent 挂上 Python 执行环境、SQL 查询接口能解决问题吗能解决一部分。但工具越多中间状态就越多每一个工具调用都会产生新的上下文进一步加剧注意力衰减。而且工具调用本身也有失败率一旦某个中间环节报错模型需要停下来排查、修改、重试这个时候它能不能找到正确的修复方向又变成了一个新的不确定因素。问题的本质是在复杂任务里我们不能依赖模型的临场发挥来保证过程可控。我们需要把任务结构化把经验显性化把决策策略变成一个可以学习和优化的对象。这就是我研究和实验案例检索 Blueprint 组合 离线 RL 精修这套组合拳的初衷。1.3 数据科学任务对 Agent 提出了哪些特殊要求和通用的任务型 Agent比如让它订个餐厅、查个天气相比数据科学建模任务有几个非常特殊的性质。第一中间产物高度结构化。每一步操作都会产生 DataFrame、Schema、模型指标、特征重要性列表这样的对象这些对象之间往往存在依赖关系一个环节出错下游所有环节都会受影响。第二中间步骤缺乏明确的对错标准。代码语法对错是容易判断的但这个特征工程方案是否合理这个缺失值处理策略是否恰当很难用静态规则衡量更多要靠经验判断。第三迭代成本高。跑一轮完整的建模实验可能需要几分钟甚至更久如果 Agent 在中途走偏了等跑到最后发现指标不对再回退浪费的时间和算力是实打实的成本。这三点决定了我们需要的不是一个更会写代码的模型而是一套能让 Agent 沿着合理路径前进的机制。MOSAIC 的设计思路刚好对应了这三个特殊要求案例检索解决经验参照的问题Blueprint 组合解决结构控制的问题离线 RL 精修解决决策质量的问题。2. 案例检索先给 Agent 找一个过来人的经验副本2.1 为什么选检索而不是把历史案例全塞进上下文最早我做原型实验的时候确实想过把历史项目的完整记录直接拼到 Prompt 里让模型参照着做。结果很快碰壁一个稍微完整的数据科学项目光是代码就有几百行再加上每一步的文字记录、中间产物的描述轻松超过上下文窗口限制。即便是勉强塞进去模型处理长上下文的效率也急剧下降反而干扰了当前任务。检索的核心价值在于按需获取。要解决这一步的问题就只把最相关的历史经验拿出来做参照而不是让模型对着整本百科全书做当前这道题。这和 RAG 的基本思想是一致的但在数据科学场景里检索的对象不是普通文档而是带有明显流程性和结构性的项目经验。还有一个更微妙的好处检索回来的案例不只是给模型看的它还会影响模型的决策风格。实验里我发现当 Agent 看到相似历史项目的处理方式后它的行为会明显向那个案例靠拢包括特征工程的手法、缺失值处理的策略、模型选择的倾向。这就相当于给 Agent 配了一个行为锚点。2.2 案例库怎么建从历史项目中沉淀可复用的经验这是整个方案里最耗功夫但是最值得投入的部分。我前期的做法是从内部积累的历史数据科学项目中抽取案例而不是去网上找公开资料因为内部项目的数据形态、行业背景和任务类型才和真实使用场景最匹配。一个案例要能被有效检索和利用不能只存一份代码文件了事。我的做法是为每个历史项目生成一份结构化摘要包含几个关键维度任务类型二分类、多分类、回归、时序预测等、数据特点样本量级、特征维度、缺失率水平、类别分布、数据类型构成、关键难点比如某些字段语义含糊、某些特征和目标的关联性极弱、整体处理思路的概括以及最重要的——指向对应 Blueprint 的引用。在实际操作中一个案例对应一个结构化摘要加一个 Blueprint 引用。摘要负责检索时的匹配Blueprint 负责执行时的参考两者配合既保证检索效率又保证参考内容的完整性。2.3 检索粒度任务级检索和步骤级检索要混着用刚开始做的时候我把整个项目当一个整体去检索后来发现粒度不够用。一个数据科学项目中不同阶段的关注点差异很大拿一个整体任务去匹配检索出来的案例可能大方向对但具体到当前这一小步参考价值有限。后来我把检索拆成了两层。第一层是任务级检索在任务开始之前做目标是找到两到三个整体相似的样板项目用来帮助 Agent 制定整体思路。第二层是步骤级检索在任务执行到某个具体环节时触发比如 Agent 正在纠结怎么处理一个缺失率高达百分之六七十的特征这时检索的目标就是历史项目中和当前数据形态最接近的那一小段处理经验。步骤级检索对 Embedding 的要求更高它需要把步骤摘要描述得很精确比如不能只写处理缺失值而要写缺失率超50%的分类特征是否保留及填充方式这样检索匹配的时候才能命中真正有价值的参考。2.4 检索相关度怎么判定不能只靠语义相似我试过纯靠 Embedding 做语义相似度检索效果只能说一般。原因很现实数据科学任务里表面语义相似的任务底层数据形态可能差很远。比如预测用户会不会流失和预测患者会不会复发语义上高度相似但前者可能是千万级样本、上百维特征后者可能只有几千样本、几十维特征完全不是一个打法。所以我的做法是 Embedding 相似度加上结构化过滤规则两层结合。先过滤掉数据结构差异过大的案例比如样本量级差两个数量级以上、特征维度差好几倍、任务类型不一致的直接扔掉。然后在剩下的候选集里按语义相似度排序取 Top-K。这样既能保证语义上的相关性又能保证数据形态上的匹配度。在工程实现上我当时是用一套轻量的向量库来存 Embedding加上一层规则过滤器整体效果比较稳。建议做类似项目的朋友不要把检索算法想得太复杂先把案例库的质量和覆盖度做上去检索效果自然水涨船高。3. Blueprint 组合把成功案例拆成可复用的积木块再拼装3.1 Blueprint 是什么一份可执行的任务规划模板如果说案例检索解决的是该参考谁的问题那 Blueprint 解决的就是该按什么路径走的问题。Blueprint 本质上是一份结构化的任务规划模板它把一个数据科学项目拆成带依赖关系的节点每个节点包含三部分输入数据的描述、要执行的操作、期望的输出产物。举个直观的例子一个常规的表格分类任务Blueprint 可能是这样的数据探查节点 → 缺失值处理节点 → 类别特征编码节点 → 特征选择节点 → 模型选择节点 → 训练评估节点。每个节点都定义了输入的字段要求和输出产物的格式。我在实验里养成的一个习惯是把 Blueprint 表示成 JSON 结构这样既方便程序解析也方便模型理解和生成。一份 Blueprint 里除了节点定义还要标明节点之间的数据流方向和每个节点的验收条件这直接关系到后面要说的检查点机制。3.2 组合规则串行、并行、条件分支单个 Blueprint 是线性模板但真实的数据科学任务往往不是一条直线走到底的所以 Blueprint 之间的组合需要支持三种基本结构串行、并行和条件分支。串行是最常见的前一个节点的输出是后一个节点的输入比如先做数据清洗再做特征工程。并行适用于互相独立的处理流程比如同时构造几个不同来源的特征组最后再合并。条件分支则根据当前数据的状态决定下一步往哪走比如数据质量检查通过就走快速建模路径不通过就先进深度清洗路径。三种结构组合起来Blueprints 就不只是模板而是一棵可以灵活组装的流程树。我在实践里发现一个很重要的细节组合 Blueprints 时节点之间的接口兼容性必须明确校验。前一个节点输出的是一个没有缺失值的 DataFrame后一个节点却在等一个带有缺失率统计的报告这种接口不匹配在自动搭建流程时非常容易出现一旦出现后面全乱。所以在每个节点的定义里输入输出 Schema 必须写清楚组合时做一次自动校验。3.3 状态检查点与回退机制把失败的成本降到最低这是整套机制里性价比最高的设计。我在 Blueprint 执行过程中引入了一个强制要求每个节点执行完毕必须保存一份状态快照包括当前的数据 Schema、节点执行的日志、产物的摘要信息。这些快照不只是为了审计更重要的是为了支持回退。数据科学任务失败是常态关键是失败之后怎么恢复。没有检查点的话Agent 在第 N 步发现前面某一步有问题只能从头再来成本极高。有了检查点机制Agent 可以精准地定位到问题节点回退到该节点之前的最近一个快照替换掉这个节点之后再往下走。这个机制也直接改变了 Agent 的行为方式。实验中统计下来加了检查点和回退机制之后因为中间步骤失控导致整个任务重跑的比例大幅下降。原因很好理解模型知道错了可以低成本回退就不会在错误的路上硬着头皮往下走。3.4 Blueprint 的来源自动生成与人工沉淀两条腿走路Blueprint 从哪来我试过两条路线各有优劣。一条是让 LLM 从检索到的历史案例里自动提取和抽象节点生成 Blueprint优点是完全自动化缺点是生成的 Blueprint 质量波动较大偶尔会有漏节点或者节点不连贯的情况。另一条是让有经验的数据分析师手动总结常见任务的 Blueprint优点是质量稳定、逻辑清晰缺点是覆盖度有限冷门任务类型还是需要临时生成。我的建议是初期阶段两条腿走路以人工沉淀为主、自动生成为辅。先把团队内最高频的二三十类任务整理成标准 Blueprint形成一个质量可靠的基础库。然后在这个基础上运行自动生成能力新任务来了先检索最接近的 Blueprint再通过 LLM 做调整和扩展。运行一段时间之后把效果稳定且经过验证的自动生成结果人工确认为新的标准 Blueprint沉淀回库里。这样 Blueprint 库就形成了一个持续进化的闭环越用越丰富越用越贴近真实业务场景。早期可能比较费人力但这一步的投入带来的回报非常直接——后续所有任务的执行稳定性和速度都会有明显提升。4. 离线 RL 精修让 Agent 在历史数据里学会更稳的决策4.1 为什么需要 RL从能走通变成选得好案例检索给了 Agent 经验参照Blueprint 给了 Agent 流程框架到这一步Agent 已经能走通一个数据科学任务了。但能走通和走得好之间还有一道坎。我做过一个很直观的测试用同一份数据、同一个任务描述让同一个 Agent 跑十次观察它中间步骤的决策差异。结果发现即使有了案例参考和 Blueprint 约束模型在一些开放性的决策点上仍然表现得不稳定。比如同样是处理一个类别很多且分布极不均匀的分类特征这次它选择做频率编码下次可能就选择独热编码再降维。单次结果可能是合理的但整体来看决策的波动性明显偏高。这种波动在数据科学任务里代价很大。因为你不知道某一轮的灵光一现是稳定的好策略还是碰运气碰出来的好结果。所以我开始用离线 RL 对 Agent 的中间决策做精修目标是让策略分布更集中、更稳定、更倾向于在历史数据中被验证过的优质决策。4.2 离线 RL 的核心优势不需要在线交互也能优化策略传统强化学习要跟环境在线交互通过试错来学策略这在数据科学任务里很难落地。一次建模实验动辄几分钟探索阶段还要故意走一些可能失败的路径成本太高而且真实业务数据经不起这么反复折腾。离线 RL 的思路完全不同。它不跟环境交互而是从历史数据中学习。我们的历史项目日志里记录了大量决策序列 → 最终结果的样本哪些决策产生了好的指标哪些决策导致任务失败这些都是现成的训练素材。离线 RL 直接用这些历史样本训练策略让模型学到面对这个状态历史上成功经验是这么干的。和在线 RL 相比离线 RL 还有一个工程上的好处数据可以反复使用训练过程可以随时重跑实验对比很方便。我当时在训练设置上走了不少弯路最大的教训是数据覆盖度必须够广不能只喂成功案例。后来我把失败案例也纳入训练集模型才知道哪些动作是要刻意避免的决策质量才真正上来。4.3 奖励怎么设定结果指标和过程约束都要有奖励函数的设计直接决定了策略优化的方向这一块我迭代了很多版最后沉淀下来的经验是多层级奖励结构。第一层是结果性奖励也是最核心的。任务跑完之后的最终指标——比如分类任务的 AUC、回归任务的 RMSE——直接映射成一个奖励值。这是策略优化的主目标没有结果性奖励模型很容易学着学着就偏了。第二层是过程性奖励。中间步骤是否合法、检查点是否通过、产物 Schema 是否正确、是否有明显的重复劳动这些都应该给一个或正或负的奖励。过程性奖励的目的不是取代结果性奖励而是引导模型在走向好结果的路途上走得更稳、更规范。第三层是效率性奖励。步数越少、耗时越短的任务轨迹给予一个小的增量奖励。数据科学任务里时间和算力都是成本这一步奖励能让模型逐渐学会减少不必要的试探和重复计算。我个人的建议是从结果性奖励开始跑通训练流程再逐步加入过程和效率奖励。一上来就把三块都加进去奖励信号互相干扰训出来的策略经常行为异常。4.4 策略坍缩问题离线 RL 最容易踩的坑离线 RL 有一个著名的风险叫策略坍缩就是在离线数据有限的情况下策略会快速收敛到少数几个固定动作上。表面上看模型变稳定了实际上是僵化了一旦遇到离线数据里没覆盖到的情况模型就不知道怎么办了。这个问题我在实验里确实撞上过。训完一版策略之后做测试发现 Agent 在特征工程阶段几乎只愿意做频率编码其他方案一概不碰原因就是离线数据集里频率编码成功的样本太多了策略被带偏了。解决思路有两个方向一个是在训练目标里加入不确定性约束另一个更实用——把离线 RL 和行为克隆混合起来。行为克隆负责让模型保持从原始数据里学到的广泛行为模式离线 RL 负责在这个基础上有倾向性地优化决策。两者按比例混合之后策略既保持了灵活性又学会了偏向优质决策实测下来稳定性和泛化能力都比之前好不少。4.5 离线数据的组织从项目日志到训练样本最后说一下训练数据的具体组织方式。我前期的做法是从每次任务运行日志中自动抽取状态-动作对和整条轨迹的结果评估。具体来说是三个步骤。第一步把 Agent 的每一步决策记录下来包括输入状态摘要当前的数据特征、上下文信息和采取的动作比如选择了哪种缺失值策略、调用了哪个模型。第二步把整条轨迹的最终指标和人工评估结果整理出来作为这条轨迹的标签。第三步把轨迹切分成状态-动作-结果的样本对同时保留完整的轨迹结构方便做轨迹级别的偏好学习。数据组织完成之后训练阶段我还额外做了一件事构建成功轨迹-失败轨迹的对比对。同样的任务类型有一条成功的轨迹和一条失败的轨迹通过偏好优化的方式让模型学会向好的轨迹靠拢、远离坏的轨迹。这个做法比单纯给每个动作打分更稳定模型学起来也更自然。5. 三者协同运作MOSAIC 的一次完整任务流程复盘5.1 三件工具的分层关系很多初次接触 MOSAIC 思路的朋友会问一个问题案例检索、Blueprint 组合、离线 RL 精修这三者是不是三个并列的模块哪个先哪个后我的理解是它们不是并列关系而是分层分工的关系。案例检索在最外层负责在任务开头和关键节点提供经验参照Blueprint 组合在中间层为整个任务提供流程骨架和状态管理离线 RL 精修在最底层负责优化模型在每一个决策点上的微操选择。三者覆盖了不同尺度的问题宏观方向靠案例检索中观流程靠 Blueprint微观决策靠离线 RL。用一个不太严谨但很好懂的类比案例检索相当于一位经验丰富的前辈告诉你这类数据我之前做过整体是这么个思路Blueprint 相当于一份标准作业指导书告诉你每一步做什么、产出什么、怎么检查离线 RL 精修相当于你在大量实操之后内化成肌肉记忆的判断力看到某个数据分布就知道该往哪个方向处理。5.2 一趟完整的数据科学任务是怎么跑起来的我拿自己实验时的一个场景来做完整推演一个电商场景下的用户流失预测任务数据集有几十个特征、几万条样本、目标变量存在一定的不平衡。这个场景在 MOSAIC 框架下大概经历了这么几个阶段。任务输入之后首先触发的是案例检索。系统用任务描述和数据集的元信息去检索历史案例库过滤掉数据结构差异大的候选按语义相似度召回了两到三个参考案例。Agent 看完这些案例的摘要对整个任务有了一个以前别人是这么解的的整体认知。接着进入 Blueprint 生成阶段。基于检索回的案例引用和任务本身的描述LLM 生成了一份新的 Blueprint。这份 Blueprint 在前半部分基本沿用了历史项目里验证过的成功路径在模型选择的节点上则做了一些针对当前数据规模的调整。生成之后经过接口校验开始逐节点执行。执行过程中每一步都会做状态快照和校验。在特征工程这一步Agent 遇到一个类别取值极多且部分类别样本量极小的特征触发了步骤级检索找到历史案例里类似特征的编码策略参考之后做了目标编码加平滑处理。这一步在纯 LLM 场景下经常会犹豫很久但在有参照的情况下决策速度快了很多而且方案稳定。任务跑到建模节点执行了一次快速基线验证发现当前特征方案下线性模型的指标已经能到预期下限于是按 Blueprint 的条件分支走了一条先快速出基线、再做迭代优化的路径。最终任务完成各项指标达到预期整个过程中没有出现需要人工介入的环节。5.3 和只靠 LLM Agent的结果对比过程可控性的变化我把自己跑过的一组内部基准测试做了个对比展示一下这套机制带来的变化。测试用的是同一批数据科学任务集对比对象是一个纯 LLM Agent只有工具调用能力和加了 MOSAIC 机制的 Agent。对比维度纯 LLM AgentLLM 案例检索 Blueprint 离线RL任务整体完成率约六成任务能跑通九成以上任务能跑通中间步骤失败率约三成的任务在中途出现步骤回退回退主要集中在可恢复的节点级错误重复实验稳定性同一任务多次执行中间路径差异大同一任务多次执行路径高度接近平均执行时长长且波动大明显缩短且更稳定人工介入频率经常需要人工判断是否走偏明显减少这个对比数据来自我自己的内部实验环境不是行业基准但趋势很有代表性。最大的变化不是指标变好了多少而是过程变得可控了。做数据科学的人都知道过程可控是一切优化的前提如果每次跑的路径都不一样后续的调试和优化根本没有抓手。5.4 落地这套机制需要重点关注的工程问题最后聊几个落地时特别容易被忽视的工程问题。第一个是案例库的更新维护。历史项目会不断产生新的成功经验案例库不能只建不养要定期把验证过的新项目整理成新案例入库同时给旧案例做质量评估效果不好的案例要降权甚至淘汰。第二个是 Blueprint 库的去重和版本管理。多个数据科学家各自沉淀的 Blueprint 很容易出现功能重叠但结构不一致的情况时间一长管理成本会很高。最好有一个统一的评审入库流程和版本号管理机制确保库里的 Blueprint 是干净且可追溯的。第三个是离线 RL 训练算力的投入产出平衡。离线 RL 训练是有算力成本的不是所有任务都需要精修。我的做法是优先对最高频的任务类型做策略精修低频或一次性任务用基础策略直接跑就行。第四个是评估指标的设置。不能只盯着速度或者某一个业务指标要多维度做评估。我在内部会同时看任务完成率、中间步骤合规率、重复实验稳定性、业务指标达成率四个维度任何一个维度出现明显下滑都要回到案例库或者训练数据里找原因。一些实际操作后的体会整套机制从想法到跑通我踩过不少坑但回头看最核心的收获只有一个不要指望模型一次生成完美的执行流程真正的稳定性和质量要靠机制来保证。案例检索把历史经验固化成了可检索的知识Blueprint 把过程变成了可校验的结构离线 RL 把决策变成了可优化的对象三层机制叠加Agent 才真正从能写代码的模型变成了能可靠完成任务的系统。最后分享一个很实用的小技巧在 Blueprint 的每一个节点上都保存当时的数据 Schema 快照。这种看似不起眼的设计在后续排查问题时帮了我大忙。Agent 跑出异常结果的时候我能精准地知道是哪一步改变了数据结构而不用拿着整个日志大海捞针。如果你打算自己实现类似机制我建议从这一步开始成本极低收益却非常直接。