1. 搜推数据生产的旧账，翻出来有多扎心

干了几年搜索推荐的人其实都有个共同体会：模型结构迭代的速度，远远赶不上数据生产的返工速度。大家天天在说“数据决定上限，模型逼近上限”，可在实际业务里，数据这条链路往往是最没“人样”的——不是缺字段，就是样本延迟，要么标签口径对不上，最后线上效果出了问题，排查三天发现是特征拼接时踩空了。

我所在的团队过去一年就在反复处理这类事。我们维护的这套搜推数据生产体系，覆盖用户行为日志清洗、实时特征计算、离线样本生成、正负样本采样、标签回填这几个核心环节。听起来就是一套标准流程，但真正跑起来，问题全藏在细节里。

先说日志清洗。用户的曝光日志、点击日志、时长日志来自不同客户端版本，字段命名不统一，有的上报 timestamp 用毫秒，有的用秒，有的直接带时区偏移。过去我们靠人肉写 Spark 任务去对齐，每次上线新业务线，就要改一遍清洗逻辑，代码越堆越厚，注释却越来越没有人敢动。

再说特征生产。搜推特征分实时和离线两套，实时特征走 Flink，离线特征走 Hive/Spark。同一特征，比如“用户近7天点击品类分布”，在实时链路上要维护一套 Redis 存储加维度拼接逻辑，离线链路上要维护一套 Hive SQL。两套逻辑的字段口径稍微不一致，模型训练出来的权重就是歪的。这种事情发生多了，团队内部就开始流传一句话：“模型效果不好，先查数据，再查特征，最后才查模型结构。”

样本管理更是重灾区。正负样本的采样比例、去重策略、时效窗口，三天两头变化。每次实验要重新生成一份样本集，跑一次全量要四五个小时，中间某个环节报错，又得从头再来。再加上数据版本管理基本靠文件名和时间戳——sample_dump_20250115_v3_final_2.parquet——这种命名我看着就头大，但当时也没有更好的办法。

所以当 Agentic 这个概念开始在圈子里发酵时，我最关心的不是它能写代码、能问答，而是它能不能把这套乱成一锅粥的数据生产体系重新梳理清楚。我花了大半年时间在团队内部做小规模验证，今天这篇就把整个过程、架构设计、落地效果和踩过的坑一次说清楚，想改造搜推数据链路的朋友可以参考一下。

2. Agentic 到底改变了什么：从“定时跑的脚本”到“会自己想办法的工人”

在动手改造之前，团队里有个很现实的争论：我们已经有 Airflow 调度、有监控告警、有数据质量规则，再上一套 Agentic 的东西，是不是重复造轮子？这个问题问得特别好，我也借这个机会把 Agentic 和传统自动化的本质区别讲明白。

2.1 传统调度系统是“按剧本演戏”，Agentic 是“带着目标上场”

传统的数据生产系统，不管调度工具多么先进，本质都是“把预先定义好的 DAG 按顺序跑完”。你写死每一步做什么、输入输出是什么、失败重试多少次。它的优点是稳定、可控、易排查，缺点也很明显：一旦上游数据格式变了、某个字段语义换了、或者业务规则调整了，整个 DAG 需要人工介入去改代码、改配置、重新发布。

Agentic 体系最大的不同，是它可以接受一个相对模糊的目标，而不是一串固定的指令。比如你可以对数据生产 Agent 说：“今天需要生成双十一大促场景的搜索正样本，负样本比例参考上周均值，注意过滤掉羊毛党账号。”这个任务在传统体系里需要你手动去改 SQL、调采样参数、配置过滤规则，但在 Agentic 体系里，智能体可以自己拆解任务、选择合适的工具、执行数据查询、验证结果，甚至发现自己拆解得不对的时候重新调整策略。

我用一个生活化的例子来解释：传统调度系统像一台全自动洗衣机，你设定好程序，它就按部就班洗。Agentic 更像一个家政阿姨，你跟她说“把家里收拾一下，我下午有客人来”，她自己判断是先扫地还是先擦桌子，如果发现吸尘器坏了，她会换扫帚或者手擦，而不是停下来等你修机器。这种“遇到问题自己想办法”的能力，是传统脚本给不了的。

2.2 搜推数据生产为什么特别适合引入 Agentic

不是所有行业的数据体系都适合 Agentic，但搜推这个领域有它独特的适配性。

第一，搜索推荐的业务规则变化极其频繁。运营活动、节假日、热点事件、新品首发、用户分层策略，都会直接影响正负样本定义和特征计算逻辑。如果每次变化都要靠算法工程师改代码，一个团队一周能改三回就不错了，但业务一天能变十个花样。Agentic 至少能把“解读规则、修改配置、验证产出”这个闭环自动化。

第二，搜推数据链路本质上是“多工具协作”。你离不开 Hive、Spark、Flink、Redis、Kafka、特征平台、样本平台。传统方式下这些工具靠人串起来，Agentic 可以用工具调用的方式把整个链路编排起来，每个步骤由合适的工具完成，智能体负责决策和衔接。这个模式天然适合大模型驱动的 Agent。

第三，增量构建的场景非常多。搜推样本很少做全量重建，更多是每天增量补数据、回填异常时段、修正口径错误。这类“局部手术”式的操作，过去需要工程师临时写脚本处理，做完就扔。Agentic 可以把这些高频操作沉淀成可复用的能力，下次遇到类似问题，直接交给智能体处理。

当然也要泼一盆冷水：不要指望一上来就让智能体接管全流程。我们的策略是先挑几个痛点最明确、边界最清晰的场景切入，跑通之后再逐步扩大范围。这个节奏问题我会在第六部分专门展开。

3. 整套体系的架构设计：编排层、工具层、记忆层三件套

我在设计这套 Agentic 数据生产体系时，没有追求特别复杂的架构，核心是三件套：一个调度大脑（编排层）、一组可被调用的数据工具（工具层）、以及一套记录上下文和决策历史的记忆机制（记忆层）。这三层配合，基本覆盖了搜推数据生产的日常需求。

3.1 编排层：谁来当这个“大脑”

编排层是整个体系的中枢，负责理解任务、拆解步骤、选择工具、检查结果。我们最后选用了一套基于 LangGraph 改造的 Agent 框架，没有直接用 LangChain 的默认 AgentExecutor，主要是看中了它对状态机的控制能力——数据生产的每个步骤都必须有明确状态，不能像聊天 Agent 那样想到哪算哪。

在编排层内部，我们定义了几类角色：

• 调度 Agent：接收用户或上游系统的任务请求，把模糊需求转成具体的执行计划。它负责判断任务类型、预估耗时、分配资源。
• 执行 Agent：负责具体的数据加工动作，比如拉取一份日志、算一个特征、生成一版样本。它不自己做决策，只执行调度 Agent 分配下来的子任务。
• 校验 Agent：负责检查执行结果。它看得懂数据质量报告，知道样本分布是否合理、特征缺失率是否超标，不合规就拒绝入库并打回重做。

这三个角色合在一起，正好对应搜推数据生产的“计划、执行、检查”循环。有人可能会问，为什么不让一个 Agent 全干了？实测下来，角色混在一起容易导致一个动作既当运动员又当裁判——数据质量校验这种环节必须独立出来，哪怕它只是同一个模型的不同 System Prompt。

3.2 工具层：把数据能力封装成 Agent 能用的 API

工具层的设计是整个体系能不能落地的关键。别把工具想复杂了，它就是把我们平时手动操作封装成标准接口，让 Agent 能在一套协议下调用。

我们第一批封装了下面这些工具：

封装过程中有个比较重要的设计决定：所有工具都必须是有状态且幂等的。有状态是为了让 Agent 知道这个工具上次执行到哪一步，幂等是为了让同一个任务重复执行不会产生重复数据。特别是样本构建器，如果 Agent 因为网络超时重试了两次，出来的样本不能多一倍，否则你会在训练模型时发现 loss 莫名奇妙的异常。

3.3 记忆层：让每一条生产经验都变成下一次的依据

搜推数据生产有个很特别的地方：很多“经验”是没法写进规则引擎的。比如某个渠道的日志在每年大促期间会出现 30 分钟延迟，这是运维同事从监控图上肉眼看出来的，不是哪个配置能定义的东西。

Agentic 体系的记忆层就是为了承接这类经验。我们把 Agent 每次执行任务的关键信息——输入参数、使用工具、执行结果、人工修正意见——全部记录下来，形成一条条“生产记忆”。下次 Agent 接到类似任务时，可以同时参考规则库和记忆库，回想上次是怎么处理的、有没有坑。

记忆层我们用了向量数据库存语义记忆，用关系表存结构化决策记录。比如样本构建器执行失败后，人工介入把负样本比例从 1:3 调成 1:2，这个修正动作会作为一条反馈记录写进记忆库。下一次 Agent 看到类似场景，会自动优先尝试 1:2 做基本配置，再根据实时数据分布做微调。这种能力听起来玄乎，其实实现不复杂，核心就是让每次人工兜底的操作都沉淀成系统能力。

4. 最先落地的三个场景：特征生产、样本治理、质量巡检

架构搭好之后，最关键的其实是选试点场景。我们的原则是：找那些“痛感最强、边界最清晰、容错性尚可”的场景，避开“一次错误就造成线上事故”的强风险场景。

4.1 特征生产 Agent：把“对口径”变成一个自动完成的动作

特征生产是搜推数据体系里最繁琐的一环。团队里光维护特征定义文档就有两百多页，什么样的特征在什么场景下用、口径是什么、更新频率多高，全靠文档和人脑同步。

我们做的特征生产 Agent，核心工作是处理两类任务。第一类是新增特征的全链路注册：当算法同学在需求文档里写“需要用户对价格敏感度的近30天均值特征”，Agent 会先解析这个自然语言需求，拆解出数据源（用户行为日志）、计算逻辑（近30天均值）、存储要求（在线 Redis + 离线 Hive），然后调用日志探查器验证数据源是否齐备，调用特征注册器完成配置，最后生成一份特征验证报告。

第二类是存量特征的口径核对。我们的做法是定期让 Agent 随机抽一批特征，自动从实时链路和离线链路各算一遍结果，然后比对差异。如果连续三天差异超过阈值，Agent 会定位到具体是哪个环节引入的偏差——可能是实时窗口和离线窗口不一致，也可能是维度拼接字典没有同步更新。过去这类排查需要经验丰富的工程师花半天时间，现在 Agent 能在一小时内给出排查链路和修复建议。

这里有个经验值得分享：特征生产 Agent 不要直接赋予“修改线上特征配置”的权限。我们一开始开放了写权限，结果有一次 Agent 误解了需求文档中的“近30天”指的是自然月，把一批特征的窗口配置全改错了。后来设置成“修改必须经过人工审批流”，成本增加了一点，但安全性提升了一大截。

4.2 样本治理 Agent：把“临时脚本”沉淀成“体系能力”

样本治理这个环节，过去最痛苦的就是“一次性脚本满天飞”。算法同学做实验，临时写个 PySpark 脚本，定义自己的正样本规则，跑完就走。等到下次其他人需要类似样本，找不到脚本，或者脚本依赖的数据源已经变了，只能重写。

样本治理 Agent 的思路是：把样本生成过程变成一个“半参数化”的标准流程。用户在界面上选择任务类型、输入时间范围、配置正负样本比例和过滤条件，Agent 负责把这些配置翻译成具体的执行作业，并且把整个配置和产出物的关系记录下来。

实际使用中，我们发现 Agent 最出彩的能力不是生成代码，而是自动补齐默认参数。新人做样本实验时，经常忘记设置曝光去重策略，或者不知道某些用户群体需要过滤。Agent 因为有记忆层，会结合历史生产记录自动补上这些默认参数，并在最终样本报告里明确标注“本次自动添加了以下规则，如有异议请调整配置”。这个设计极大降低了新人的上手门槛。

不过这里也有个大坑：样本治理 Agent 对正负样本比例的理解必须被严格约束。大模型对数字的解读偶尔会有偏差，比如你说“负样本比例提高到1.5”，它可能在配置里写成0.15。我们的解决办法是在工具层加入值域校验，凡是采样比例、时间窗口这类关键参数，必须在工具层强校验，Agent 给的值超出合理范围就拒绝执行。

4.3 质量巡检 Agent：不再等人报障，而是主动发现问题

搜推数据质量问题的发现往往是滞后的。通常是线上模型效果出现波动，反查数据和特征才发现问题。我们引入质量巡检 Agent 后，把发现问题的时机提前了很多。

巡检 Agent 的工作模式是昼夜轮巡，定时扫描各个数据表的健康度指标，包括延迟时间、完成率、主键唯一性、字段合法性、分布漂移等。发现问题时，它不是只发一条告警，而是会先做一次初步诊断，尝试判断问题根因，并把诊断结论附在告警后面一起推送给人。

有一次巡检 Agent 发现某张实时行为宽表的曝光字段枚举分布出现异常，某个新上线的页面类型占了80%。它自动排查后发现是前端埋点新增了一个枚举值，而原有的清洗任务不认识这个值，全部归到了“其他”类别。Agent 没有直接改清洗逻辑，而是生成了完整的诊断报告和修复建议，我们复核后一条命令就把修复逻辑发布上线。整个过程从发现到修复，不到两个小时，换作以前至少要大半天。

这种“诊断报告+修复建议+人工确认”的模式，是我们反复磨合后确定的。不要试图让 Agent 什么都自己干，数据生产这种强依赖业务理解的场景，人工确认关卡不能省。

5. 踩坑实录：Agent 幻觉、工具调用失控、成本黑洞

Agentic 体系并不是一上就顺，我们这半年踩过的坑，比前面写的架构还值得一看。每个坑都对应一次架构或流程上的调整，记录下来给后面的人少走点弯路。

5.1 幻觉问题：Agent 一本正经地编造数据路径

第一次遇到 Agent 幻觉引发的问题，是在管控流里升级：当时让特征生产 Agent 排查某个特征的离线数据延迟，它给出的诊断报告写得很完整——原因、影响范围、修复建议都齐全。团队里的新同学准备照单执行，幸好老工程师多看了一眼，发现 Agent 引用的“上游数据表名”根本不存在——那是它根据以往经验“脑补”出来的路径。

这个事件让我意识到，大模型在生成诊断报告时，擅长把不合理的内容写得非常合理。在数据生产这种场景里，幻觉的代价极高：轻则浪费时间，重则污染样本、影响模型训练。

我们采用的应对方案有两层。第一层是强制工具验证：Agent 生成的每个断言，凡是涉及数据表、字段、任务名称的，都必须调用对应的探查工具验证一遍，验证通过才能写进报告。这一条直接掐断了“编造数据路径”的可能。第二层是事实与建议分离：报告模板强制区分“已验证事实”和“拟采取措施”两个区块，事实区块必须附上工具查询截图式的结构化证据，建议区块允许模型自由发挥，但在前端展示时必须显著标注“未经验证”。

5.2 工具调用失控：强循环停不下来，白白烧了一堆计算资源

Agent 的另一个典型问题是强循环。我们的执行 Agent 在调样本构建器时，如果遇到数据产出质量不达标，会按设计自动调整参数重新运行。这个设计本意是好的，但有一次它陷入了无意义的循环：因为上游 Hive 表本身数据不全，无论怎么调整采样参数，质量报告都不达标。Agent 连续重试了14次，把集群资源耗尽，导致其他正常任务排队。

这个问题靠模型本身解决不了，必须在框架层面加控制。我们后来在编排层增加了三层防护：

• 执行次数上限：每个子任务最多重试3次，超过后必须转为人工处理。
• 资源预算制：每个 Agent 任务申请的计算资源有上限，用尽即熔断。
• 变化率检测：如果 Agent 连续两次调整参数的方向一致但结果没有改善，自动判定为无效循环，停止并上报。

这套机制上线后，类似的问题再没有发生过。我特别想提醒的是：Agent 框架里“保底机制”的优先级，永远要高于 Agent 的“聪明才智”。

5.3 成本黑洞：Token 消耗和计算费用，涨得比想象中快

Agentic 体系的成本是个不能回避的问题。我们在试点初期没有做严格的成本核算，第一个月账单出来时，团队负责人差点以为系统被刷了。

成本的大头其实不在大模型调用的 Token 费，而在 Agent 引发的底层计算消耗。因为 Agent 会反复探查数据、试运行任务，每一次探查背后的 Spark/Hive 查询都要花钱。尤其是日志探查器，Agent 为了确认一个字段格式，可能连续发起多次扫表查询，一次全表 scan 的成本就够跑几十个正常任务。

应对措施是给工具调用加“缓存”和“预算”双重约束。缓存很容易理解，相同查询在有效期内直接返回上次结果。预算则是对每个 Agent任务关联一个预估消耗金额，接近上限时自动切换为“低成本模式”——比如把全表探查改成采样探查，把精确统计改成估算。这两个机制搭配起来，系统运行成本降到了原来的三分之一左右。

6. 落地节奏与评估机制：怎么确保不是“为了 Agent 而 Agent”

最后这部分，聊聊管理层面的问题。Agentic 这种新技术，很容易让大家陷入“为了 AI 而 AI”的兴奋感，反而忽略了它到底有没有产生业务价值。我们团队摸索了一套务实的落地节奏和评估方法，分享出来供参考。

6.1 三阶段推进：试点、并行、接管

我没有采用一步到位的“大爆炸式”切换，而是分了三步，每一步都有明确的验收标准。

第一步是试用期，拿真正的业务问题喂给 Agent，但所有产出必须经过人工二次核验。这个阶段的目的不是提升效率，而是收集 Agent 的错误模式、摸清它的能力边界。我们有个专门的文档记录每个错误案例，这个文档后来成为调 Prompt、调工具、调流程的重要依据。

第二步是人机并行期，Agent 和原有流程同时跑，两边结果做对比。这个阶段最考验耐心，因为人工流程又慢又费人力，很容易出现“反正还要人工做一遍，Agent 就是多余的”这种声音。这时候必须让团队看到 Agent 的独特价值——它能发现问题、能给出建议、能沉淀经验，这些是纯人工流程做不到的。

第三步是接管期，经过前两步验证，确认某个场景的错误率已经低于人工水平、并且兜底机制完备的情况下，才允许 Agent 独立执行。到目前为止，我们真正放开独立执行的只有质量巡检和特征口径核对这些低风险场景，样本构建、规则修改等高风险动作仍然保留人工审批环节。

6.2 评估指标体系：效率、质量、安全三角

评估 Agentic 体系不能只看“节省了多少人天”，我建议从三个维度建指标体系。

效率维度包括：平均任务处理时长、免人工干预比例、资源利用率。质量维度包括：产出数据准确率、返工率、口径一致性。安全维度包括：高危操作拦截数、幻觉断言检出率、人工介入响应时长。这三个维度要综合看，单看任何一个都会被带偏——比如效率很高但质量不稳，或者质量很好但一次安全事故就归零。

我们在实践中还发现一个很有意思的指标：人工介入的“质量”。过去人工介入是救火式的，谁有空就谁上；现在人工介入更像 Code Review，是在 Agent 的产出上做确认和修正。这个转变本身，说明系统在成长。

6.3 关于 Agentic 搜推数据生产，我的几点真实体会

做了大半年，最后说几句掏心窝子的话。

第一，Agentic 不是银弹，数据生产体系里那些脏活累活，还得靠扎实的元数据管理、数据质量规范、可观测性建设打底。如果底层的数据本来就烂，AGN 再聪明也只会在烂数据上输出漂亮的错误结果。

第二，刚开始做的时候，一定要选准种子场景。我们是从质量巡检切入的，因为它容错率最高、人工兜底容易、业务影响可控。等团队对 Agent 的行为模式有感觉了，再逐步往特征生产和样本治理这些更核心的环节扩展。

第三，不要迷信“全自动”。搜推数据生产牵扯太多业务判断，完全去掉人工不现实，也不应该。我们的定位是：Agent 当排头兵，人当最终决策者。这样 Agent 能力越强，人的产能释放得越多，而不必担心哪天 Agent 失控了，整条链路跟着遭殃。

如果你也在搜推数据生产线上挣扎，建议先别急着上大模型，把当前链路的痛点列表拉出来，找那个最痛、最重复、最不刺激的点，拿一个 Agent 试点跑起来。数据涅槃的起点，往往不是一个宏大的架构，而是某一天你发现：那个半夜还在收到告警的任务，居然自己搞定了，还写了一份像模像样的复盘报告。