Agentic重塑搜推数据生产体系：从规则引擎到智能体编排

1. 凌晨两点的告警背后：搜推数据生产体系正在换引擎

上周四凌晨一点四十七分，我被一条任务失败告警吵醒。点开日志看了十分钟，原因照旧是老朋友：某个分类模型上线时改了类目标签的口径，下游三张宽表的两亿条样本全部错位。当晚值班的同学拿着大模型生成的口径对比文档蹲在屏幕前，一条一条核对新旧类目映射关系，直到天亮才把数据任务重跑完。

这不是偶发事件。凡是在搜索、推荐领域深度做过流量增长和用户体验优化的团队，几乎都熟悉这种循环：需求评审——写SQL——调脚本——产出特征和样本——上线之后发现线下指标和线上对不上——人工排查口径——再补一轮数据。日复一日，数据生产体系逐渐变成一张由规则脚本、临时任务和人工巡检拼成的巨型蜘蛛网。表面看起来每天都在产出数据，实质上每一次口径变更，每一轮样本重构，都在消耗大量的人力。

搜索推荐系统是强数据驱动的产品。用户点击行为、商品/内容属性、类目层级、特征拼接、样本生成，这些环节构成了搜推体系的“数据生产链”。过去我们用稳定的规则、模板化的Pipeline、经验丰富的数据工程师来维护这条链。但随着业务迭代越来越快，规则开始失灵，脚本开始腐化，链路开始难以追溯。问题说来也简单：决策的责任全压在人身上，而执行工具只是被动完成命令。

这两年“Agentic”成了技术社区的高频词。从Karmada正式毕业、云厂商在共建Agentic Cloud底座，到Agentic RAG逐渐成为检索架构的新范式——大家都在谈智能体如何接管复杂工作流。很多人以为Agentic只是聊天机器人的进阶版，能够多轮对话、调用几个API而已。但在接触搜推数据生产体系之后，我的观点变了：Agentic真正能解决的是“数据生产决策链的转移”。它让执行单元具备了判断能力、自我纠错能力和跨任务协作能力，这使得数据生产不再依赖人的逐级指令，而是由智能体自主规划、执行、校验、修正。

这篇文章我想完整地复盘一下，基于Agentic思路重塑搜推数据生产体系的全过程。包括传统数据链路到底痛在哪，Agentic在哪些环节真正产生价值，落地的架构长什么样，以及我在方案设计和上线过程中踩过的坑。如果你也在做搜索推荐系统的数据建设，或者正在琢磨怎么给团队的数据Pipeline引入智能化能力，这篇内容值得花二十分钟读完。

2. 从规则引擎到智能体编排：换的不是工具，是决策链

2.1 传统搜推数据生产线的决策模式

先看传统模式的核心逻辑。搜推数据生产通常包括这样几个环节：

• 物品内容结构化：对新增商品/内容做类目映射、属性抽取、标签打标。比如一条短视频进来，需要判断它属于“知识科普”还是“搞笑段子”，适用年龄层是什么，是否包含商业植入。
• 用户行为数据清洗：从用户点击流日志中抽取有效行为，剔除异常流量、内部测试流量、爬虫请求，并根据业务逻辑划分Session。
• 特征样本拼接：将用户行为、物品属性、上下文特征拼接成一条完整的训练样本。正样本怎么定义，负样本怎么采样，特征时间窗口怎么对齐，每条细节都影响模型效果。
• 质量校验与指标口径管理：检查产出数据是否符合预期，监控离线指标与线上指标是否一致，处理下游任务对数据的投诉。

传统Pipeline里，每个环节的执行逻辑是预先写死的一组规则。类目映射靠词典匹配，属性抽取靠正则表达式和少量NLP模型，样本正负例的判断靠一串if-else条件，质量校验靠别人反馈问题之后被动补丁。

这套模式的决策权全部集中在“规则编写者”手里。系统本身没有判断能力——同一件商品只因为标题写法变化，就可能匹配不到任何类目规则，被错误地丢进默认分类。等到模型训练时发现该分类样本稀疏，才有人去查为什么当初没有打上正确的类目标签。

说白了，传统搜推数据生产的脆弱性来自一个根本错配：**数据世界的变化速度远超规则更新的速度。**而Agentic模式恰恰把“决策能力”从中心化的人，下放到了分布式的执行节点身上。每个Agent可以在执行任务时根据当前的数据内容、上下文环境、历史经验，自主决定下一步怎么走。当一个“类目映射Agent”拿到的商品不在词典里，它不会直接判为未知类目，而是会尝试多步推理：读取商品标题、关键图片描述、当前类目分布、历史相似商品，最后给出置信度最高的类目结果，同时把低置信度的样本标记为“待人工确认”。

2.2 决策链重构之后，数据生产发生了什么

我见过不少团队在尝试Agentic改造时陷入一个误区：以为只要把原来的Python脚本外面套一层大模型API，让大模型输出JSON结果，就算“Agent化”了。其实不是。真正的变化不在工具形态，而在决策链的位置。

传统模式下，数据工程师接到需求后，把决策逻辑写入代码，然后交给调度系统定时执行。系统不“理解”数据，只知道跑任务。而Agentic模式里，决策逻辑被拆解为可组合的推理单元，每个Agent都拥有明确的“职责描述”和“工具箱”，它可以自主规划完成任务的步骤，并在执行过程中根据中间结果动态调整。

举个具体例子。做商品类目映射时，传统做法是维护一张“关键词—类目”映射表，再加一层文本分类模型兜底。但是新商品如果使用了全新的商品属性组合，比如“折叠式太阳能充电背包”，词典里没有“太阳能充电”这种词条，分类模型也会因为训练集覆盖不足而给出一个模糊的结果。而类目映射Agent在遇到这条数据时，会先把“折叠式”“太阳能充电”“背包”三个关键词拆出来，分别检索知识库，再判断这个组合最可能归属的父类目是“户外装备”还是“数码配件”，最终输出“户外装备—功能性背包—太阳能系列”。整个推理过程会以结构化日志的形式留痕，方便回溯。

这种从“静态规则”到“动态推理”的变化，本质上把数据生产的决策链路从人挪到了系统内部。于是数据规模越大、业务变化越快，Agentic体系的相对优势就越明显——因为每一次规则更新不再需要等人写完代码再发布，而是让Agent根据最新的业务知识库自行调整行为。

3. 重塑搜推数据生产体系的四个关键落点

在确定了决策链重构的思路之后，我们没有立刻全面替换所有Pipeline，而是挑选了四个最痛、最能体现Agentic价值的场景，逐步验证、逐步铺开。这四条线做下来，搜推数据生产体系才真正有了“涅槃”的味道。

3.1 物品类目挖掘Agent：从标签匹配升级为语义推理

搜索推荐场景里，类目体系是数据生产的骨架。用户搜索“轻薄本办公推荐”，搜索侧需要知道哪些商品属于“轻薄本”，同时还需要理解“办公”这一场景属性和“轻薄”这一产品特性。传统类目体系往往只解决“是什么品类”的问题，对“适合什么场景”“具备什么特性”这类复合语义无能为力。

我们把类目体系相关的数据生产任务重构为一个独立的“类目挖掘Agent”。它不再是一张规则表，而是一个具备多步骤推理能力的系统。具体执行流程如下：

1. 接收新增商品/内容的原始数据（标题、描述、图片特征向量、价格等）。
2. 调用实体识别工具，抽取核心实体与属性词。
3. 在类目知识库中检索最接近的父类目和兄弟类目。
4. 如果存在歧义，则同时读取搜索结果页的行为数据，看同类商品在线上是怎么被用户点击和转化的。
5. 输出类目路径、场景标签、置信度，并自动判断是否需要进入人工复核队列。

这套改造落地后，最明显的变化是类目标签的覆盖率提升了，低置信度样本的人工处理量并没有同比增加。因为Agent会先把逻辑上能确定的样本处理掉，只把那些真正需要业务判断的边界case留给人工。这让数据团队从“每天几千条无脑打标”变成“每天只看几十条高价值判断”，人的时间花在更有价值的地方。

3.2 用户行为样本生产链路：基于MCP协议让Agent互相协作

样本生产是搜推数据体系里最容易被忽视、但影响面最大的一环。一条训练样本的诞生，需要行为清洗Agent、特征对齐Agent、样本拼接Agent共同协作。这和过去由一个调度脚本依次调用各模块有本质区别。

我在方案中采用了基于MCP（Model Context Protocol）的Agent协作方式。每个Agent都是独立部署的服务，通过MCP工具调用的方式暴露能力，并遵循统一的上下文协议进行信息交换。

在样本拼接环节，实际效果非常直观。过去，用户行为数据与物品特征数据的时间窗口不一致是常态。比如行为日志记录的是“用户在21点32分点击了商品A”，而特征表在21点30分生成，恰好没有包含用户最近2分钟的浏览信息。传统脚本只会硬生生地把这条样本拼接成“特征缺失”。改进之后的样本拼接Agent会在发现时间窗口不匹配时，自动重新拉取增量行为数据，确认用户点击前是否存在其他关键行为，再决定这条样本的特征字段是否补全、是否标记为低置信度样本、或者丢弃。

这套协作机制的稳定运行，关键在于两点：

• 所有Agent之间的信息传递都带上下文标识。比如行为清洗Agent在传递用户行为数据时会带上采集时间、设备类型、行为类型等元信息，下游特征对齐Agent不需要重新解析日志，直接按标准协议读取。
• 每个Agent都有独立的记忆存储。当发现某类商品在拼接过程中经常出现特征缺失时，Agent会记录这个规律，下一次遇到同类商品时自动提前检查对应特征是否已生成。这种“经验积累”在传统Pipeline里需要通过人工巡检和代码修改来实现，而Agent体系通过记忆机制天然支持。

3.3 数据质量稽核：从被动响应到多Agent交叉验证

让模型训练团队最头疼的事情之一，是发现线上效果波动的原因竟然来自训练数据的质量问题。而且这类问题往往无法通过调度监控发现——因为数据任务跑得“很成功”，只是跑出来的数据逻辑上不对。

我们做了一个数据质量稽核Agent群，包含若干个角色分工不同的稽核Agent：

• 规则稽核Agent：负责对照既有的数据质量规则，比如字段非空率、唯一性、值域范围。
• 逻辑一致性稽核Agent：负责检查跨表数据是否自洽，比如“点击量不应该大于曝光量”“用户活跃时间不应该早于注册时间”。
• 分布漂移稽核Agent：负责对比当前产出样本的分布与历史分布的差异，一旦发现某类目样本比例异常下降，立刻触发告警并自动排查。

这三类Agent之间会互相验证结果。假设逻辑一致性稽核Agent发现某天的曝光数据异常，它不会直接判定数据存在问题，而是会发起一次自动排查请求，调取对应的日志样本，交叉验证是上游日志缺失、数据重复写入还是拼接逻辑出错。这一层“侦查”能力是传统质量监控完全不具备的。

上线这个Agent群之后，我们有一个非常强烈的感受：**数据团队的核心工作发生了迁移。**以前大家80%的时间花在帮下游解释数据和排查问题上，现在这些工作由Agent完成初筛，人的精力转向处理Agent提交上来的深层问题报告和制定新的数据治理策略上。

3.4 元数据与口径治理：让源头数据自己说明白自己

搜推数据生产体系长期混乱的根源，是口径不一致。同一个“点击率”，在搜索侧的计算逻辑是“点击UV除以搜索UV”，在推荐侧可能是“点击PV除以曝光PV”。两组数据在报表里都叫“点击率”，但含义完全不同。等到两个团队对齐指标时才发现口径差了几倍，轻则浪费讨论时间，重则导致业务决策失误。

口径治理是个典型的Agentic应用场景，因为它不是一个一次性梳理项目，而是需要持续维护的动态过程。

我们的方案是构建一个“口径治理Agent”，它持续扫描各个数据任务和数据表的元数据信息，自动生成口径描述文档，并与已注册的口径知识库进行比对。当发现新的数据表或字段没有口径说明时，Agent不会放任不管，而是自动调用Schema解析工具、SQL血缘分析工具，推断该字段的生产逻辑，生成一份初步的口径说明草案，再递交给数据负责人审核确认。

这套系统解决了两个大问题。第一，数据字段的“历史欠账”被逐步清零。Agent会优先处理那些被下游引用次数最多、但口径描述缺失的字段。第二，新口径在诞生之初就会被Agent捕获并记录，不再依赖某位工程师主动提交元数据信息。

我在搭建这个Agent时用到的核心思路是“让数据生产过程中的每一步都留下结构化足迹”。搜索推荐数据生产体系之所以难治理，很大程度上是因为历史任务在运行时就只关注产出结果，忽略了过程信息。Agent化改造之后，从数据接入、处理到产出，全程都有Agent记录执行逻辑和决策依据，这些信息天然构成元数据体系的一部分。口径治理从“事后补文档”变成了“事中自动生成文档”，效果完全不一样。

4. 搜推数据生产Agent的实用架构：我实际搭建的方案

前面讲的都是功能和场景，这一节说一下支撑这些场景的底层架构。很多人觉得Agent系统很玄乎，实际落到工程上，它就是一个“规划器+一组具备工具调用能力的执行单元+共享知识库+可观测性组件”的组合。

4.1 整体架构分层

我在生产环境搭建的搜推数据生产Agent体系分为四层：

• 接入层：接收数据生产任务请求，包括定时任务触发、告警事件触发、下游系统的即席请求。接入层负责将请求转换为标准的Agent任务描述。
• 规划层：由一个中心规划Agent完成。它的职责是根据任务描述拆解步骤，决定需要调用哪些执行Agent，按什么顺序调用，以及在哪些环节设置人工确认点。
• 执行层：由多个专用Agent构成，包括类目挖掘Agent、样本拼接Agent、质量稽核Agent、口径治理Agent等。每个执行Agent内部包含“推理模块+工具集+记忆模块”。
• 支撑层：包括元数据中心、样本工具库、模型服务、知识库RAG服务、人工复核平台。支撑层为Agent提供必要的“手脚”和“知识”。

在规划层和执行层之间，我们定义了标准化的任务协议。规划Agent下发的不是具体代码，而是一份结构化的任务描述，包括目标、输入数据地址、产出要求、约束条件、超时时间。执行Agent拿到任务后自行决定调用哪些工具、如何实现目标。

这个设计有一个显著好处：规划Agent不依赖具体执行细节，执行Agent不依赖全局上下文。当新增一个业务需求时，不需要改动规划层，只需要在知识库中补充新场景的规则说明，规划Agent就能判断出该调用哪些执行Agent。

4.2 工具调用与知识注入的两个关键设计

第一个关键设计是：**所有Agent对数据的操作都通过工具层完成，而不是让Agent直接读写数据库。**为了安全起见，Agent不能直接执行任意SQL，而是通过一组被封装的工具接口来操作数据。例如查询工具只接收表名、筛选条件、返回字段等参数，并在执行前自动做权限校验。这既保证了灵活性，也保证了数据安全边界。

第二个关键设计是：**知识库RAG是Agent推理的核心支撑之一。**执行Agent在做出判断时，会先从知识库中检索相关历史案例和规则说明，再把检索结果作为推理上下文的一部分。相比完全依赖大模型的“自由发挥”，这种设计让Agent的输出更可控、更符合业务约束。

我这里放一段简化版的Agent规划逻辑伪代码，方便理解整个协作过程：

class PlanningAgent: def plan(self, task_description): # 检索相关业务知识 knowledge = self.knowledge_base.retrieve(task_description) # 拆解任务步骤 steps = self.llm_planning( task_description, knowledge ) # 为每个步骤分配执行Agent assigned = [] for step in steps: agent = self.router_agent.select_executor(step) assigned.append({ "agent": agent, "step": step, "confirm_point": step.need_manual_confirm() }) return assigned def execute(self, task_description): steps = self.plan(task_description) results = [] for item in steps: result = item["agent"].run(item["step"]) if item["confirm_point"] and result.confidence < 0.9: result = self.human_review_submit(result) results.append(result) return results

实际生产里，这个流程会更复杂，会加入重试机制、错误回滚、超时降级等工程细节。但整体思路就是：中心规划、分布执行、关键节点人审。

4.3 可观测性是Agent体系的“安全气囊”

把决策权交给Agent之后，最让人担心的就是“系统有自己的想法了，但我们看不见”。所以我在搭建架构时，把可观测性设计放到了和功能实现同等重要的位置。

每个Agent的执行过程都会产生结构化的Trace日志，包含以下内容：

• 收到了什么任务，基于什么上下文做了规划。
• 执行过程中检索了哪些知识，调用了哪些工具。
• 工具返回了什么结果，Agent基于该结果做了什么判断。
• 最终输出结果是什么，置信度多少，是否需要人工复核。

这些Trace日志会统一汇入一个日志分析平台。我们甚至做了一个内部专用的“Agent行为看板”，可以按时间线回放某个Agent处理某批数据时的全部决策过程。一旦线上数据出现异常，不再是无从查起的黑盒，而是可以像看监控录像一样逐帧回溯。

这也回答了很多人的疑问：让Agent自主决策是不是太冒险？我认为，冒险与否不在于“是否让AI做判断”，而在于“你是否具备完整观察AI决策过程的能力”。只要Trace做得足够细，即便Agent判断失误，也能快速定位原因、纠正知识库、重放任务，风险是可控的。

5. 数据涅槃路上踩过的坑：成本、幻觉、黑盒，以及我的取舍

Agentic重塑搜推数据生产体系并不是一帆风顺的。我在落地过程中遇到三类问题，几乎每个准备做类似改造的团队都会遇到。

5.1 模型调用成本：聪明是好事，但钱包不答应

Agent化改造直接带来一个现实问题：相比原来跑规则脚本，Agent体系每执行一个环节都要调用大模型，成本高出一个数量级。

以类目挖掘任务为例。原来跑一次全量商品的类目映射，用规则脚本的成本几乎可以忽略不计，主要是占一点CPU。Agent化改造之后，每件商品都要经过多次推理，按每百万token的计费标准，全量商品跑一轮的费用非常可观。

我最终的取舍是“分层处理”：对于历史行为稳定、类目归属明确的存量数据，仍然走规则脚本；只有新增数据、规则难以判定的边界数据，才交给Agent处理。这既控制了成本，又让Agent专注于真正需要智能的环节。

在Agent内部，我也设定了模型的“按需升级”策略。简单的字段抽取任务调用小模型，复杂的跨表逻辑推理才调用大模型。这个分层策略最终让整体成本控制在可接受范围内，而智能化的覆盖率并没有明显下降。

5.2 Agent幻觉：用工具约束代替自由发挥

大模型天然有幻觉问题。在搜推数据生产里，幻觉的代价非常高——一个不存在的属性、一个错误的类目判断，都可能导致真实的样本被污染。

我的经验是：**不要让Agent“记住”事实，而要让Agent“查到”事实。**这是RAG架构的核心意义所在。类目映射Agent在做判断时，知识库检索结果是第一参考信息，大模型的推理能力是第二参考。两者结果冲突时，Agent必须输出低置信度标记，而不是强行给出答案。

此外，我还要给Agent加上了“工具前置”的约束。在执行任何判断前，Agent必须先去元数据中心确认表和字段是否存在，先去类目知识库确认类目路径是否有效。所有关键事实都从工具返回，而不是从模型权重里直接生成。这套约束下来，幻觉发生的比例大幅下降，即使偶尔出现，也会被质量稽核Agent交叉验证时发现。

5.3 黑盒焦虑：让Agent“会解释”比“会做事”更重要

在实际推进过程中，我遇到的最大阻力不是技术问题，而是团队的信任问题。数据工程师看见Agent自动修改了某个字段的归类逻辑，第一反应是“它凭什么这么改”。如果系统解释不了，团队成员是不敢让Agent直接上生产的。

所以我在设计时强行要求：任何Agent在做出一个“重要决策”时，必须附带决策理由，说明它基于什么知识、什么数据做了这个判断。类目映射Agent输出“户外装备—太阳能充电背包”之后，会附带一条说明：根据商品标题关键词“太阳能充电”检索到历史类目知识库中相关商品的归属记录，参考了3个相似商品样本的类目路径，综合判断归入该节点。

这个“解释机制”消耗了一些额外的token，但换来的收益远超成本。团队对Agent的信任度建立起来之后，数据生产的整体效率才真正提升。

5.4 什么时候不该用Agent

最后说一个听起来不太“Agentic”的结论：不是所有数据生产环节都适合Agent化。

那些极稳定、极频繁、且逻辑完全清晰的任务，比如固定格式的日志清洗、固定的时间窗口聚合计算，继续用确定性脚本就好。Agent在这类场景里没有优势，反而会带来不必要的成本和延迟。

我认为合理的判断标准是：**该环节是否存在频繁的业务变化，是否需要跨知识领域的判断，是否容忍一定的不确定性。**这三个条件满足程度越高，越适合Agent介入。反之，继续用传统Pipeline更合适。

Agent化改造不是“用智能替换所有脚本”，而是“把智能放在最需要判断力的地方”。这个边界想清楚了，整个体系的重构才会顺畅。

6. 分阶段推进的实施路线与最终体会

如果看完前面的内容，你准备在自己的搜推数据体系里做Agent化改造，我给一个可以落地的行动路线，避免一上来就发散。

第一阶段，先选一个瓶颈最明显、人工投入最大、且判断逻辑相对清晰的场景做试点。类目挖掘和样本质量稽核都是不错的切入点，这两个环节的业务规则相对明确，Agent的效果容易通过覆盖率、准确率等指标衡量。

第二阶段，搭建底层支撑能力。包括元数据中心的完善、知识库的初始化、Agent执行Trace体系的上线。没有这三样东西，Agent化改造大概率会变成一盘散沙。

第三阶段，把试点场景跑通，并以“影子模式”与现有Pipeline并行一段时间。影子模式的意思是Agent的正常输出不会直接影响线上数据生产，而是与既有结果进行对比，发现差异后人工评审谁更合理。

第四阶段，在差异收敛、业务方认可之后，逐步切换线上链路。切换顺序上，建议先切换辅助性的环节，比如口径治理、质量稽核中的自动排查部分，再切换直接影响训练样本的核心环节。

第五阶段，建立Agent体系的持续反馈闭环。业务规则变化时，更新知识库而不是重写代码，定期复盘Agent的错误决策案例，将这些案例沉淀回知识库和Prompt示例中，让体系越用越准。

这套路线走完之后，搜推数据生产体系并不会变成一个完全无人值守的“黑灯工厂”。我的体会是，它更像是从“手工作坊”变成了“智能工厂”：确定性工作交给机器，判断性工作交给Agent，战略性工作留给人类专家。数据工程师的角色从“写SQL的人”变成了“定义Agent行为规则的人”，工作价值上升了一个台阶。

我也建议团队在启动这类改造时，不要过早追求“全链路Agent化”。先从一两个场景拿到成效，让团队成员真正感受到AI对数据生产效能的提升，再逐步扩展。数据涅槃不是一次推倒重来的革命，而是一场持续迭代的进化。每一次Agent任务的完成，每一条数据质量的提升，都是这场进化中坚实的一步。