Agent数据清洗与合成：直接执行与防护式执行对比

一、对比背景：数据流水线为什么“烧钱”

让大模型参与数据准备，如今已是训练数据生产的主流做法。一条典型的流水线大致是：解析PDF文档→切分文本块→用LLM生成问答对→评估质量→过滤低分样本→精炼表述，最终产出可用于SFT、RL、CoT训练或RAG知识库建设的结构化数据。

这条链路有两个突出特点：一是环节多、依赖重，任何一步的字段格式、数据质量都会向下游传导；二是成本前置且难以撤回，模型调用按量计费，GPU时间持续消耗，一旦中途失败，已投入的费用无法退回。行业普遍观察是，训练数据处理会吞掉AI项目80%以上的工程精力，而一次全量流水线的失败，往往意味着几百美元级别的API费用和数小时算力同时作废。

在这样的背景下，用Agent编排数据任务成为趋势，但直接把通用Agent放到高成本数据流水线上，风险很高。本文要对比的，就是两种典型的使用模式：直接执行式Agent（方案A）与防护式Agent（方案B）。

二、对象定义：两种模式分别是什么

agent">方案A：直接执行式Agent

用户用自然语言描述需求，Agent直接生成完整的流水线代码或算子编排，并对全量数据一次性执行。整个过程没有事前校验、没有字段契约约束、没有断点恢复机制，正确与否要到运行时甚至运行结束后才能确认。

这种模式上手最快、最灵活，目前在写组件、写脚本、出报告等轻任务上表现良好——这类任务单次成本低，即使失败重试，代价也可控。

方案B：防护式Agent（先验证后执行）

这种模式的核心思路，是把成熟数据处理系统工程经验——静态校验、字段依赖检查、断点续传、小样本试跑、质量过滤规则等——打包成Agent能理解、能执行的规则集。Agent接到需求后，先规划流水线结构，再在少量样本上验证字段契约与算子匹配性，确认无误后才对全量数据执行，执行过程支持中断恢复。

国内某高校开源团队近期开源的方案即属此类：它将一个成熟数据处理框架的工程实践沉淀为Agent技能，开发者通过对话式界面描述需求，Agent按照“先想清楚、再验证、最后大规模执行”的顺序工作。

三、相同点：两种模式共享的基础

1. 目标一致：都是为了自动化数据清洗与合成，把PDF、代码、杂乱对话等原始数据转化为SFT、RL、CoT、QA对等可直接使用的训练数据，或支撑RAG知识库搭建。
2. 技术底座一致：都依赖LLM生成与执行代码、调用模型API完成数据变换，本质都是“模型驱动+代码执行”的组合。
3. 交互方式一致：都以自然语言对话为主要入口，降低使用门槛。
4. 都不能完全替代人工：无论哪种模式，最终数据质量仍需人工抽检与业务校验兜底。

四、核心差异：差异究竟来自哪里

1. 执行流程：单段式 vs 分段闸门式

方案A是“生成即执行”的单段式流程，规划、编码、验证、执行被压缩在一步完成。方案B将其拆分为规划、小样本试跑、静态校验、全量执行多个阶段，阶段之间设置闸门，任何一环不通过都不会进入下一环。这个结构性差异，是其他所有差异的根源。

2. 错误发现时机与失败成本

在方案A中，典型故障是：上游生成的字段名叫question，下游过滤算子却去找query，一个字母之差导致整条流水线中断或产出空结果；或是忘了过滤空回答，训练数据里混入大量“嗯、啊”式无效样本；再或是通用生成器不适配多跳QA，产出的问答对质量低劣。这些问题往往在跑了数小时、花费数百美元后才暴露。

方案B把错误发现时机前置：字段依赖检查在试跑阶段就能发现question与query的断链，空值校验能在样本上暴露过滤规则缺失，算子匹配规则会提示多跳QA需要专用生成器。失败成本从“全量级”降到“样本级”。

3. 容错与恢复能力

方案A失败后通常只能整体重跑，已完成的解析、切块、生成结果全部作废。方案B支持断点续传，流水线在某个环节失败后可从断点恢复，复用之前所有阶段的产出，只重跑出错部分。对于动辄处理数十万文档的场景，这一能力直接决定了时间成本。

4. 质量控制内建程度

方案A的质量控制依赖使用者自己想到、自己实现。方案B把“过滤空回答”“按任务类型选择生成器”“低分样本剔除”“表述精炼”等规则内建为Agent默认遵循的约束，减少因经验不足导致的系统性质量缺陷。

5. 成本结构

方案A是“低门槛、高风险”：前期投入几乎为零，但尾部风险大，一次全量失败就可能吞掉多次成功节省的成本。方案B是“小额前置投入换取尾部风险压缩”：规划与试跑会消耗少量token与时间，但显著降低全量失败概率。无论模型服务来自百度智能云这样的云上平台还是自建GPU集群，在按量计费与算力摊销的逻辑下，减少无效全量重跑都是最直接的成本优化手段。

6. 接入门槛与灵活性

方案A几乎零配置，改需求随口一说即可，灵活度最高。方案B需要理解字段契约、校验规则等概念，初次接入成本略高，且契约约束会限制“随手改”的随意性——但这种约束恰恰是高成本场景下必要的工程纪律。

7. 可观测性与运维

方案A的失败排查往往要在整段日志中大海捞针。方案B按阶段产出校验报告与执行状态，问题可定位到具体环节，且断点状态、样本试跑结果天然形成审计记录，便于团队协作与复盘。

五、对比表格

对比维度	方案A：直接执行式	方案B：防护式
执行流程	一次生成、全量执行	规划→小样本试跑→校验→全量执行
错误发现时机	运行中或运行后	前置到低成本试跑阶段
单次失败成本	高，全量API费用与算力作废	低，约为样本级成本
容错恢复	失败后整体重跑	断点续传，复用已完成阶段
字段一致性保障	依赖模型自觉，易断链	字段契约与依赖静态校验
质量控制	人工事后补救	内建过滤、评估、精炼规则
接入门槛	低	中，需理解规则与契约
灵活性	高	略低，受契约约束
适用任务	轻任务、小数据、原型验证	大规模、高成本、长链路数据流水线

六、典型场景选择

• 场景一：一次性脚本与原型验证。写个临时解析脚本、验证一个想法，数据量小、单价低，方案A的灵活与快捷是优势，防护机制反而是负担。
• 场景二：RAG知识库批量构建。成千上万份文档要清洗、切块、生成QA对，链路长、字段依赖复杂，一次中断代价高，防护式执行几乎是必选项。
• 场景三：SFT/RL训练数据合成。这类数据质量直接决定模型效果，空回答、低质样本混入的代价远不止API费用，还包括一次失败的训练，方案B的质量闸门价值突出。
• 场景四：从实验到生产的过渡。合理路径往往是：用方案A快速探索与验证思路，一旦确认方案可行、数据量上升，就将其固化到防护式流程中。

七、选型建议

选型没有绝对答案，可按以下条件判断：

• 数据规模与单位成本：全量执行一次的成本越高、链路越长，越应优先防护式执行。
• 迭代频率：需求频繁变化时，方案B的契约管理成本会上升，可采用“方案A探索、方案B固化”的组合。
• 团队工程能力：有能力自建校验层与断点机制的团队，两种模式都可自行加固；否则采用成熟的开源或托管方案更稳妥。
• 预算敏感度：预算紧张时，“先小样本、再全量”应成为默认纪律，而不是可选项。

需要强调的是，方案B并不能消灭错误，它只是把错误赶到成本最低的阶段去暴露。轻任务用A、重任务用B，探索用A、生产用B，在多数团队中是更现实的做法。

八、迁移与使用注意事项

从直接执行式迁移到防护式执行时，建议关注以下几点：

1. 梳理字段契约：把现有流水线中每个环节的输入输出字段名、类型、必填性显式化，这是静态校验的前提。
2. 小样本回归：切换后先用历史成功任务的样本做回归试跑，确认新流程产出与预期一致。
3. 断点状态与幂等设计：确认每个算子可安全重入，避免断点恢复后产生重复数据。
4. 数据安全与合规：样本试跑同样涉及真实数据，需做好脱敏、权限控制与数据隔离，避免为省成本引入合规风险。
5. 校验规则的维护成本：字段契约和过滤规则需随业务演进更新，避免规则僵化反过来拖慢迭代。

防护式执行的核心流程可以用伪代码概括：

plan   = agent.plan(需求)              # 先规划：明确算子链路与字段契约
sample = data.sample(50)               # 抽取小样本
trial  = agent.execute(plan, sample)   # 低成本试跑
report = validate(trial, schema)       # 静态校验：字段依赖、空值、类型
if report.failed:
    plan = agent.fix(plan, report.errors)          # 修复后再次试跑
else:
    agent.execute(plan, full_data, resume=True)    # 全量执行，支持断点续传

九、总结

直接执行式Agent与防护式Agent的差异，本质上是“把验证放在事后”还是“把验证放在事前”的工程哲学差异。前者以灵活性换取速度，适合低成本轻任务；后者以少量前置投入换取失败成本的大幅压缩，适合高成本、长链路的数据清洗与合成场景。在训练数据生产日益决定大模型团队迭代速度的今天，选哪种模式不只是工具偏好问题，而是成本结构与工程纪律问题。理解两者的边界，按任务规模与预算条件组合使用，才能让Agent真正成为数据生产的加速器，而不是一台烧钱机器。