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 能在一套协议下调用。我们第一批封装了下面这些工具工具名称功能说明对应原有人工操作日志探查器读取指定时间窗口的原始行为日志输出 schema、枚举值分布、异常值检测写临时 SQL 查数据特征注册器在特征平台注册新特征配置计算逻辑和存储位置手工在平台上填配置样本构建器执行正负样本生成作业支持自定义比例、过滤规则改 Python 脚本跑数数据质检器生成样本质量报告包括缺失率、分布漂移、标签一致性手动跑质检脚本血缘登记器记录数据的上下游依赖更新元数据系统手工维护 Excel 血缘表封装过程中有个比较重要的设计决定所有工具都必须是有状态且幂等的。有状态是为了让 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 试点跑起来。数据涅槃的起点往往不是一个宏大的架构而是某一天你发现那个半夜还在收到告警的任务居然自己搞定了还写了一份像模像样的复盘报告。 
长河君 · 2026/11/4 9:13:25 · 阅读 1.2k Agentic数据生产体系：从特征到样本的智能自动化实践
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 能在一套协议下调用。我们第一批封装了下面这些工具工具名称功能说明对应原有人工操作日志探查器读取指定时间窗口的原始行为日志输出 schema、枚举值分布、异常值检测写临时 SQL 查数据特征注册器在特征平台注册新特征配置计算逻辑和存储位置手工在平台上填配置样本构建器执行正负样本生成作业支持自定义比例、过滤规则改 Python 脚本跑数数据质检器生成样本质量报告包括缺失率、分布漂移、标签一致性手动跑质检脚本血缘登记器记录数据的上下游依赖更新元数据系统手工维护 Excel 血缘表封装过程中有个比较重要的设计决定所有工具都必须是有状态且幂等的。有状态是为了让 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 试点跑起来。数据涅槃的起点往往不是一个宏大的架构而是某一天你发现那个半夜还在收到告警的任务居然自己搞定了还写了一份像模像样的复盘报告。