1. 旧范式之困搜推数据生产为什么成了“手工作坊”先说个现象。你去问任何一家中大型平台的搜推团队数据生产体系里的“手工感”都重得吓人。特征上线要排期样本拼接要盯调度AB实验跑完要人工复盘数据质量出问题要靠值班同学半夜爬起来看告警。这套东西运转了好多年稳定是稳定但效率账越算越亏。我复盘过自家搜推数据链路的真实成本一个常规的特征接入需求从提需求到全量上线涉及特征口径确认、ETL脚本开发、离线校验、线上回放对齐、灰度观测五六个环节跨了算法、数据、工程三个团队。纯开发工时可能只要两天但端到端耗时通常按周计。瓶颈不在单点能力而在环节之间的衔接——每个人都在等上游的产出每个人都要手动确认下游的输入没问题。更扎心的是数据质量事故。搜推数据链条长源头日志一个字段解析错了下游样本、特征、模型全部被污染。传统做法是事后发现、事后排查、事后补偿。凌晨两点被电话叫醒的经历做过搜推数据的人应该都有。问题是这类事故的排查路径高度相似——先定位哪一层数据开始异常再回溯是哪条规则、哪个解析逻辑出了问题最后手动补数、重跑、对齐。这套“标准动作”本可以自动化但过去没人觉得能做到。也不是没有尝试过优化。平台化、配置化、元数据中心、数据质量监控这些概念行业内喊了好几年也确实解决了一部分问题。但本质上它们解决的是“被定义好的问题”规则是人事先配好的监控阈值是人事先设好的流程编排是人事先画好的。真正的痛点在于搜推数据生产里大量工作需要的是“根据上下文做判断”的能力——这个字段异常是源头问题还是解析问题这次失败该重试还是该告警这个特征口径变了下游哪些任务要同步调整这些判断逻辑很难用固定规则穷举过去只能靠人来兜底。所以当Agentic智能体化的概念开始在数据工程领域落地时我第一反应是搜推数据生产可能是最适合也最需要被它重塑的场景。原因很简单这个领域有高频重复的确定性劳动有低频但高成本的异常判断有跨系统、跨团队的信息孤岛有清晰的链路拓扑和可观测性基础。这些条件凑齐了就是Agentic落地的理想土壤。2. Agentic 重塑搜推数据生产整体设计与核心思路坦白讲刚开始聊Agentic改造数据生产的时候团队内部争议不小。算法同学担心“智能体”不可控数据同学担心又多了一层黑盒工程同学则直接灵魂拷问这东西和以前的自动化脚本到底有什么区别区别确实要讲清楚。传统自动化脚本是“if-then”的确定性执行——输入固定规则固定输出可预期。Agentic的核心差异在于它是一个“感知-决策-执行-校验”的闭环而且决策依据不是写死的规则是基于当前上下文动态生成的行动计划。放到搜推数据生产的语境里就是它能看懂当前链路的状态感知判断该做什么、按什么顺序做决策调用对应的工具去执行执行再确认执行结果是否符合预期校验不符合就调整策略再来一次。2.1 为什么是搜推数据生产先跑通搜推数据生产有个天然的Agentic友好特性链路拓扑清晰且结构化。从埋点日志、业务库数据到数据清洗、特征计算、样本拼接、模型训练、线上推理每一层都有明确的输入输出有血缘关系有调度依赖。这意味着Agentic所需的“环境感知”有现成的基础设施支撑——元数据中心、血缘系统、调度平台、监控告警这些在搜推领域基本是标配。另一个原因是搜推数据生产的“判断动作”高度密集。举几个每天都发生在我们身边的例子新特征上线要检查覆盖率和分布是否符合预期某个上游表的分区延迟了要不择等待、补数还是跳过样本拼接后正负样本比异常要定位是采样逻辑问题还是数据源问题。这些动作的共同点是知道“怎么做”的人很多但把“怎么做”固化成可执行流程的很少因为每个案例的细节都不一样。2.2 方案的四个核心模块我们最终落地了一套“四层架构”每层解决一类问题第一层感知层。负责全面感知搜推数据生产链路的状态。这一层接入了调度平台的实例运行状态、数据质量监控的告警事件、血缘系统的元数据变更、甚至包括线上推理服务的性能指标。感知层输出的是统一的“环境快照”供上层Agentic系统做推理决策。第二层决策层。这是Agentic的核心由一个主Agent加若干专业子Agent组成。主Agent负责理解用户意图、拆解任务、编排子Agent协作子Agent则聚焦特定域比如数据质量诊断Agent、特征工程Agent、调度运维Agent。每个子Agent都封装了对应该域的领域知识和决策逻辑。第三层执行层。Agent决策的落地依赖一套工具集包括ETL脚本执行器、数据校验器、调度操作器、Notebook执行环境等。所有工具都通过标准的工具接口暴露Agent通过“规划-调用-观察结果”的方式使用它们。第四层校验层。每次执行动作之后系统会触发自动校验数据量级是否合理、字段分布是否符合预期、任务状态是否恢复正常。校验结果会反馈给决策层形成一个闭环。这四层说起来抽象实际跑起来的效果是数据同学提了一个“接入新用户活跃特征”的需求主Agent拆解任务后调度特征工程Agent生成特征计算逻辑调用执行层跑数再由校验层检查覆盖率、分布、空值率是否符合阈值全部通过后自动提交上线评审。全程人工参与度极低但每一步都有迹可循、有日志可查。2.3 为什么选择Agentic而不是LLM直接生成代码这里有一个容易被误解的点Agentic不是让大模型直接写代码、直接改配置。搜推数据生产对准确性要求极高一个错误的特征逻辑上线直接影响线上模型效果伤害的是真实用户体验和商业指标。LLM直接生成代码的风险在于它不了解这个特定业务场景的上下文很容易“一本正经地胡说八道”。Agentic的解法是给LLM装上“眼睛”和“手”——眼睛是感知层提供的真实链路状态手是执行层提供的受控工具。LLM负责的是“理解和规划”不是“直接操作”。所有高危动作改生产表、动调度配置、发上线单都经过工具层的一层额外校验确保Agent的行为在可控范围内。打个比方传统方式是“让人去操作工具”LLM直出代码是“让AI当人”Agentic更像是“让AI当操作员但操作面板上有安全锁”。安全和效率之间Agentic找到了一个当前技术条件下最务实的平衡点。3. 核心环节拆解从需求理解到任务编排的实操细节前面讲了整体架构这一节落到实操聊聊我们在每个核心环节踩过的坑和总结出的关键细节。3.1 意图理解怎么让Agent准确get到数据同学的需求Agentic系统的第一个入口是意图理解。数据同学不可能都用精确的指令格式跟Agent对话真实场景里的需求往往是口语化的“帮我看看用户点击特征那边的数据有没有问题”、“新客推荐场景的特征覆盖咋这么低”、“明天要用的训练集还缺哪些分区”。我们第一版只做了关键词匹配加简单模板效果惨不忍睹。同样是“特征覆盖”既可能指特征在样本中的覆盖度也可能指特征在线上请求中的覆盖率还可能是特征上线时默认值填充的覆盖规则。同一个词在不同语境下含义完全不同关键词匹配根本搞不定。后来改成基于LLM的意图解析加槽位填充效果好了很多但依然有坑。最典型的一个问题是“隐含约束”的识别。数据同学说“把点击特征的样本延迟降低”隐含的诉求可能是要改样本拼接的时间窗口也可能是要优化上游任务的调度依赖还可能是要调整特征的计算时效。Agent如果只是按字面执行很可能改错了方向。我们的解法是“多轮澄清优先于直接执行”。当Agent识别到意图存在歧义时不会直接调用工具而是先向用户提出澄清问题“你说的降低延迟是指样本拼接的窗口还是上游特征计算的调度频率”这样虽然牺牲了一点点交互效率但换来了执行准确率的大幅提升。3.2 任务拆解与链路规划从目标到可执行步骤意图理解之后进入任务拆解阶段这是Agentic系统的关键环节也是最难做好的部分。搜推数据生产任务的链路通常不是线性的而是一个有并行、有条件分支、有回退路径的DAG。举个例子“评估新特征对搜索排序模型效果的影响”这个任务拆解出来至少包含确认特征定义和数据来源、计算特征在训练样本中的覆盖率、统计分析特征分布和异常值、基于历史数据做特征有效性回测、输出评估报告。这些步骤中“计算覆盖率”和“做回测”是可以并行的但“确认特征定义”是前置条件。我们让LLM基于工具列表和链路元数据生成候选计划再用一个独立的“计划校验器”去检查计划的有效性——是不是有缺失的前置依赖是不是有循环引用是不是有些步骤其实可以并行执行以节省时间计划校验器是规则模型混合实现的规则部分保证DAG的拓扑正确性模型部分评估计划的合理性。实操中的一个经验是不要把任务拆得太细。刚开始设计Agent时我们倾向于把所有粒度都拆到最小——每个字段的计算单独成为一个步骤。结果计划冗长、执行缓慢、出错概率高。后来调整策略只拆到“任务级”粒度比如“计算用户活跃度特征”作为一个整体内部的字段逻辑由子Agent自行处理。整体效率和可维护性反而更好。3.3 子Agent的协同机制数据质量、特征工程、调度的分工搜推数据生产涉及的领域太杂单一大Agent什么都干反而什么都干不好。我们按领域分了三个子Agent数据质量Agent、特征工程Agent、调度运维Agent。每个子Agent有独立的知识库和工具集。数据质量Agent负责监控和诊断数据异常。它的知识库里存了常见的搜推数据质量问题类型——字段解析错误、上游数据延迟、分区数据缺失、口径变更未同步。出现告警时数据质量Agent会先做基础诊断定位异常层级和影响范围。特征工程Agent负责特征的新增、修改、下线全流程。它的核心能力是理解特征口径和业务语义能自动生成特征计算逻辑的草稿并且会检查新特征与现有特征之间的相关性防止重复建设。调度运维Agent负责任务实例的运维操作。上游表分区延迟了它会评估是等待、补数还是跳过任务失败了它会判断是重试还是告警升级到人工。三个子Agent不是孤立的它们之间通过一个“事件总线”通信。典型场景是调度运维Agent发现某个上游任务失败产生了一个事件数据质量Agent订阅到该事件后自动排查该任务产出的数据是否已经污染了下游如果有影响则触发补偿流程。这种协同机制让整个系统有了“组织性”而不是一堆功能孤岛。3.4 知识注入把老师傅的经验变成Agent的“肌肉记忆”Agentic系统能不能产生真实价值很大程度取决于知识注入的质量。LLM本身的知识是通用性的它知道“数据质量”这个概念但不了解你们平台特有的“A表B字段在C场景下可能有D问题”这种具体经验。我们做法是“知识库案例库”双轨注入。知识库存的是领域规则和操作规范比如“样本拼接必须使用T-1的数据”、“特征上线前必须校验空值率低于X%”。案例库存的是历史问题的复盘记录每条案例包含问题现象、定位过程、根因、解决方案、预防措施。案例库的价值在多轮对话场景下特别明显。用户描述一个新问题时Agent先在案例库中检索相似历史案例基于历史经验给出初步判断。比如用户反馈“搜索CTR今天掉了2个点”Agent检索到历史上有过类似问题那次根因是某个热门短视频的标题字段解析异常导致特征值偏高Agent就会优先排查这个方向而不是漫无目的地做全链路扫描。知识注入的工作量确实不小但收益也直接。上线案例库后我们Agent的首次诊断准确率提升了接近一倍很多高频问题可以做到秒级定位。4. 实操过程与核心环节实现链路编排、质量校验与自治闭环前面讲的是设计思路这部分讲落地实现——我们具体是怎么把Agentic系统搭起来的里面有哪些关键实现值得参考。4.1 链路编排把“人肉排期”变成“动态规划”传统的数据生产任务编排是静态的——调度平台配好依赖关系后每天按部就班地跑。Agentic带来的变化是编排从“静态配置”变成“动态规划”每个任务实例运行时Agent会基于当前环境动态决定执行策略。我们实现了一个“动态任务规划器”。它接收三类输入任务目标、环境快照、可用工具。任务规划器首先生成候选执行计划然后基于预估时间和资源消耗做排序选出最优路径执行。执行过程中如果发现环境变化比如某个数据源临时不可用规划器会重新规划寻找替代路径。举一个具体例子。每天凌晨的“用户画像特征全量计算”任务正常情况下需要累计跑40分钟。某天我们监控到其中一个中间表产出晚了20分钟按静态依赖的逻辑整个任务链都会被推迟。但动态规划器识别到这个中间表只影响3个下游特征其他17个特征不依赖它于是自动调整了执行计划——把不受影响的特征先跑完受影响的特征等数据到位后再补跑。最终整体任务只推迟了5分钟而不是20分钟。这个能力的实现依赖精细的“数据依赖血缘”解析。我们把任务的依赖精确到“字段级”而不只是“表级”这样Agent才能判断一个上游异常到底影响哪些下游。字段级血缘的维护成本不低但回报是动态编排的精准性大幅提升。4.2 数据质量校验从“事后告警”到“事前预防事中控制”搜推数据生产的数据质量管控过去最常用的是“阈值告警”——监控指标超过阈值就报警。这种模式的问题很明显阈值设宽松了问题发现太晚阈值设严格了误报率飙升值班同学很快产生告警疲劳。Agentic系统把质量管控分成了三层防线。第一层是事前校验任务执行前Agent自动校验上游数据是否就绪、字段完整性是否达标、数据量级是否在合理区间。不满足条件就不启动任务从源头避免“垃圾进垃圾出”。第二层是事中控制任务执行过程中阶段性校验中间结果。比如特征计算跑了三分之一Agent抽样检查中间结果的特征分布如果异常可以提前终止避免浪费时间跑完一个注定失败的任务。第三层是事后复核任务完成后做全量质量校验包括数据完整性、一致性、分布合理性。实操中有个做得比较细的点Agent的校验项不是固定写死的而是根据任务类型动态生成。同样的“数据完整性校验”对核心业务表会检查“分区是否全部产出、行数是否匹配昨日、关键字段空值率是否低于0.5%”对辅助表则只检查“分区是否产出、行数量级是否正常”。校验规格的动态适配既保证了核心链路的高标准又避免了辅助任务被过度校验拖慢。4.3 自治执行与人工介入的边界安全护栏设计Agentic系统一旦具备执行能力安全边界就变得极其重要。我们的设计原则是“分级别授权”——不同动作类型对应不同的审批要求。第一级别是“自动执行”信息查询、诊断分析、低危操作比如查看任务日志、统计特征覆盖率、生成诊断报告。这些动作Agent可以直接执行不需要人工介入。第二级别是“自动执行但留痕”有一定影响的操作比如重跑失败任务、调整调度优先级、修改特征计算逻辑的草稿。执行前Agent会记录操作原因和预期影响执行后自动同步结果给相关人员。第三级别是“人工审批后执行”高危操作比如修改生产表结构、变更线上特征口径、下线正在使用的特征、调整核心调度依赖。Agent会生成完整的操作方案和风险评估发送给负责人审批审批通过后才执行。这个分级授权机制上线后团队的心态发生了明显变化。最开始大家对“Agent能直接操作生产”这件事是极度警惕的但看到所有动作都有清晰的授权等级和审计日志且高危操作依然需要人工审批接受度就慢慢建立起来了。我们在护拦上还做了一个细节设计Agent执行动作前会自动做一次“影响面预估”。比如Agent想重跑某条ETL任务它会先查一下这个任务的下游依赖图预估影响的数据表和任务范围然后在操作记录中注明“本次重跑可能影响X张下游表、Y个下游任务”。如果影响范围超出预设阈值即使动作本身是第二级授权也会自动升级到人工审批。4.4 关键技术选型Agent框架、模型选择与工具封装技术选型上我们没有盲目追新。Agent框架层面最初考察了当时社区讨论较多的几个主流方案最后自研了轻量编排层核心原因是我们搜推数据链路里“工具调用”的形态太特殊了——既有SQL执行、Python脚本运行又有调度平台API调用、监控系统事件订阅通用框架的工具抽象能力覆盖不了这些场景。自研编排层可以更好地贴合内部基建。模型层面我们没有只用单一模型。核心决策用更强的大模型保证复杂推理的准确性高频、低风险的判断用轻量模型控制成本。比如“识别用户意图中的业务关键词”这种任务用轻量模型就够而“综合链路状态推理问题根因”这种任务必须用强模型。模型路由规则我们跑了一段时间后沉淀成了一个配置化模块支持按任务类型灵活调整。工具封装是个容易被低估的工作量点。每个工具的输入输出都必须标准化Agent才能流畅地串联调用。我们定义了一个统一的“工具协议”每个工具有明确的参数schema、执行超时、输出格式、错误码约定。工具有执行失败时返回结构化错误信息Agent才能基于错误信息做下一步判断而不是面对一坨日志干瞪眼。5. 落地效果复盘从效率提升到质量改进的真实数据讲了这么多设计最终还是要看效果说话。目前这套Agentic搜推数据生产体系已经在我们的核心业务链路上稳定运行了几个月几个维度的变化比较明显。5.1 提效端到端交付周期从“按周计”到“按天计”最直观的变化是数据需求的交付周期。过去一个常规的特征接入需求从提需求到上线的端到端周期通常需要3到5个工作日主要耗时在跨团队沟通、排期等待和手动校验。现在Agent可以在需求提出后自动完成大部分链路工作——意图解析、数据探查、特征逻辑生成、覆盖率校验、上线方案输出人工只需要在最后确认一下。我们统计了最近两个月的数据需求交付记录平均端到端周期缩短到了1.5个工作日左右。部分标准化程度高的需求甚至可以在几个小时之内走完流程。这种效率提升不是压榨出来的而是省掉了大量因为“等人”和“等确认”产生的等待时间。5.2 质量主动发现代替被动响应数据事故率下降数据质量层面的变化更值得关注。过去的数据质量保障是“被动响应式”的——系统先出现问题用户或监控先发现然后值班同学介入排查。Agentic系统上线后大量的数据问题在“萌芽期”就被识别和处理掉了。典型场景是数据口径变更。搜推业务迭代快埋点字段经常调整。过去一个字段口径变了如果没通知到位下游所有用这个字段的特征都会默默“带病运行”好几天。现在Agent在元数据变更事件触发后会主动检索下游影响面自动通知相关任务负责人并给出调整建议。我们已经有几次案例是Agent在数据真正出问题之前就把变更影响处理掉了。季度维度看搜推核心链路的数据质量事故数量下降了明显更关键的是“影响时长”大幅缩短——很多原本需要人工熬夜排查的场景现在Agent可以在分钟内完成初步定位并给出处理方案。5.3 体验从抵触到依赖团队协作模式的变化还有一个值得说的变化是团队协作模式。最开始推广Agentic系统时团队内部有不少观望情绪担心Agent不可靠、担心自己的工作被替代、担心操作失控。但实际跑了一个月后态度发生明显反转。原因在于Agent解决的是大家最烦的“琐碎杂活”。数据同学不用再每天盯着调度看板做人工巡检算法同学不用再花半天时间等特征数据产出值班同学不用再半夜爬起来做初级诊断。人从重复劳动中解放出来去做更有创造性的工作——设计新的特征体系、优化样本策略、分析用户行为模式。现在团队的日常协作模式已经是“人负责定义目标和审核结果Agent负责执行过程和细节确认”。这跟“人做所有事”的效率差异是用过就回不去的。6. 踩坑实录那些文档里不会写的教训实施过程中踩的坑不少挑几个有代表性的整理出来给准备做同类改造的团队一些参考。6.1 大模型幻觉在数据生产场景是“致命伤”第一个绕不开的坑是大模型幻觉。Agent在生成特征计算逻辑时可能会“编造”不存在的字段或表名。这在通用场景里可能只是答案不够准确在数据生产场景里可能导致任务直接失败甚至产出错误数据。我们的教训是必须在工具调用层和校验层做双重拦截。工具调用层Agent生成SQL或代码后先做“静态语法检查元数据比对”核对引用的表名、字段名是否真实存在。校验层任务跑完后做“数据合理性校验”检查产出数据的量级、分布是否符合预期。这两层缺一不可单靠提示工程约束效果有限。6.2 工具的“副作用”比想象中多Agent调用工具时容易忽略工具的“副作用”。比如重跑一条ETL任务表面上是重新计算一份数据但副作用是它会占用计算资源、可能锁定表、可能触发下游任务的级联启动。Agent如果只看目标不看副作用很容易在资源紧张的时候“好心办坏事”。后来我们在工具定义里增加了“副作用说明字段”让Agent在决策时能考虑操作的间接影响。同时做了资源配额管理Agent触发的任务有一套独立的资源池和人工触发的任务物理隔离避免互相挤兑。6.3 历史经验的“保鲜期”问题知识库和案例库上线初期效果很好但运行一段时间后我们发现一些历史案例的判断已经“过期”了。业务变了、数据链路变了、口径变了老经验不再适用Agent还在按旧逻辑判断反而造成误导。这个问题我们花了不少力气解决。现在的做法是“知识动态化”——知识库和案例库的内容不是一次灌进去就完事而是有定期刷新机制。每次Agent执行完任务系统自动评估“本次执行相关的知识是否仍然有效”过期的知识会被标记下架。6.4 可观测性可能是最容易忽视的“隐性工程”Agentic系统自身的可观测性建设是我们前期忽视后来痛补的一块。Agent的执行链路本来就比传统系统复杂——有意图理解、任务规划、工具调用、结果校验多个环节如果不做专门的日志和追踪出问题根本无从排查。现在我们对Agent的每个环节都打点记录输入是什么、模型是怎么推理的、选择了什么工具、工具返回了什么、校验是否通过。有一次线上Agent误操作我们就是靠完整链路日志快速定位到了模型推理环节的上下文误解问题。没有这些可观测性数据那一次排查可能要折腾一整天。7. 常见问题与排查技巧实录把这段时间维护Agentic搜推数据生产体系遇到的高频问题整理成一份速查表给遇到类似困扰的同行参考。问题一Agent意图理解错误执行了非用户本意的操作排查思路先看意图解析环节的日志确认用户原始输入和解析后的结构化意图。大概率是隐含约束没被识别。解决方法是增强多轮澄清机制在意图不确定时先问清楚再行动不要贸然执行。实操技巧给Agent预设“不确定性阈值”——当解析置信度低于阈值时强制进入澄清流程。宁可多问一句不要做错一步。问题二Agent生成的执行计划存在循环依赖或缺失前置排查思路检查计划校验器的输出日志。循环依赖一般是因为子任务的依赖关系描述不清晰缺失前置则是因为信息感知不全。实操技巧计划校验器里加“前置条件自动补全”逻辑。Agent生成计划后校验器自动比对依赖关系发现缺失的前置条件自动补充而不是直接报错。问题三知识库中的历史案例误导了Agent的判断排查思路检查案例检索环节看Agent是基于哪条历史经验做的判断。这类问题通常出在“表面相似但本质不同”的案例匹配上。实操技巧案例库中增加“使用有效期”和“适用条件”元数据。检索时不仅看相似度还会校验当前场景是否满足案例的适用条件。问题四Agent操作导致资源竞争影响核心链路任务排查思路查看调度平台的资源水位监控确认Agent触发任务的时间和资源峰值是否重叠。实操技巧给Agent触发的任务设置独立的资源池和优先级确保它不会挤占核心链路任务的计算资源。这属于架构层面的规避方案比事后处理更可靠。问题五模型升级后Agent行为发生漂移排查思路对比升级前后的Agent决策日志。模型升级后同样的输入可能产生不同的推理结果这是正常的模型行为漂移。实操技巧每次模型升级前先在测试环境跑一遍完整回归测试覆盖核心场景的输入样例。线上环境和测试环境之间做模型灰度而不是一次性全量切换。8. Agentic 搜推数据生产的边界与下一步演进说句实在话Agentic重塑搜推数据生产这件事目前也只走到了“从0到1”的阶段距离真正意义上的“数据自治”还有很长的路。有些事情是当前Agent做起来很吃力的这些边界值得冷静看待。当前最大的瓶颈在于长链路多跳任务的错误累积。一个任务的执行链条一旦超过五六跳每跳都有一定的失败率或误差率累积起来就容易出现无法收敛的情况。更麻烦的是上层Agent对底层执行细节的感知是有限的链路深处的偶发问题很难被准确归因只能通过对外层的表现逆推原因。多智能体协作的一致性也需要解决。不同子Agent可能因为各自的局部视角做出互相冲突的决策比如调度Agent想重跑任务数据质量Agent却判断这个数据源本身有问题两者会互相干扰。目前我们是靠较重的协调机制兜底——主Agent集中裁决所有争议代价是效率受损在实时性要求高的场景下感觉特别明显。未来演进方向上我们在重点探索“面向搜推场景的轻量Agent框架”和“经验持续沉淀机制”。用一套足够好的基础模型配合搜推数据生产的专用工具集让智能体在中小团队里也能快速搭建起来而不是每个团队都要从头造一套定制化的Agent体系。这条路很宽但也很长。回到开头那个判断Agentic确实是搜推数据生产体系的一次重要重塑机会。它是把“数据生产从人力驱动转向智能驱动”的一个具体解法不是概念炒作是真能落地、真能带来效率和质量提升的工程实践。 
长河君 · 2026/11/4 23:59:53 · 阅读 1.2k Agentic重塑搜推数据生产：从手工作坊到智能自治
1. 旧范式之困搜推数据生产为什么成了“手工作坊”先说个现象。你去问任何一家中大型平台的搜推团队数据生产体系里的“手工感”都重得吓人。特征上线要排期样本拼接要盯调度AB实验跑完要人工复盘数据质量出问题要靠值班同学半夜爬起来看告警。这套东西运转了好多年稳定是稳定但效率账越算越亏。我复盘过自家搜推数据链路的真实成本一个常规的特征接入需求从提需求到全量上线涉及特征口径确认、ETL脚本开发、离线校验、线上回放对齐、灰度观测五六个环节跨了算法、数据、工程三个团队。纯开发工时可能只要两天但端到端耗时通常按周计。瓶颈不在单点能力而在环节之间的衔接——每个人都在等上游的产出每个人都要手动确认下游的输入没问题。更扎心的是数据质量事故。搜推数据链条长源头日志一个字段解析错了下游样本、特征、模型全部被污染。传统做法是事后发现、事后排查、事后补偿。凌晨两点被电话叫醒的经历做过搜推数据的人应该都有。问题是这类事故的排查路径高度相似——先定位哪一层数据开始异常再回溯是哪条规则、哪个解析逻辑出了问题最后手动补数、重跑、对齐。这套“标准动作”本可以自动化但过去没人觉得能做到。也不是没有尝试过优化。平台化、配置化、元数据中心、数据质量监控这些概念行业内喊了好几年也确实解决了一部分问题。但本质上它们解决的是“被定义好的问题”规则是人事先配好的监控阈值是人事先设好的流程编排是人事先画好的。真正的痛点在于搜推数据生产里大量工作需要的是“根据上下文做判断”的能力——这个字段异常是源头问题还是解析问题这次失败该重试还是该告警这个特征口径变了下游哪些任务要同步调整这些判断逻辑很难用固定规则穷举过去只能靠人来兜底。所以当Agentic智能体化的概念开始在数据工程领域落地时我第一反应是搜推数据生产可能是最适合也最需要被它重塑的场景。原因很简单这个领域有高频重复的确定性劳动有低频但高成本的异常判断有跨系统、跨团队的信息孤岛有清晰的链路拓扑和可观测性基础。这些条件凑齐了就是Agentic落地的理想土壤。2. Agentic 重塑搜推数据生产整体设计与核心思路坦白讲刚开始聊Agentic改造数据生产的时候团队内部争议不小。算法同学担心“智能体”不可控数据同学担心又多了一层黑盒工程同学则直接灵魂拷问这东西和以前的自动化脚本到底有什么区别区别确实要讲清楚。传统自动化脚本是“if-then”的确定性执行——输入固定规则固定输出可预期。Agentic的核心差异在于它是一个“感知-决策-执行-校验”的闭环而且决策依据不是写死的规则是基于当前上下文动态生成的行动计划。放到搜推数据生产的语境里就是它能看懂当前链路的状态感知判断该做什么、按什么顺序做决策调用对应的工具去执行执行再确认执行结果是否符合预期校验不符合就调整策略再来一次。2.1 为什么是搜推数据生产先跑通搜推数据生产有个天然的Agentic友好特性链路拓扑清晰且结构化。从埋点日志、业务库数据到数据清洗、特征计算、样本拼接、模型训练、线上推理每一层都有明确的输入输出有血缘关系有调度依赖。这意味着Agentic所需的“环境感知”有现成的基础设施支撑——元数据中心、血缘系统、调度平台、监控告警这些在搜推领域基本是标配。另一个原因是搜推数据生产的“判断动作”高度密集。举几个每天都发生在我们身边的例子新特征上线要检查覆盖率和分布是否符合预期某个上游表的分区延迟了要不择等待、补数还是跳过样本拼接后正负样本比异常要定位是采样逻辑问题还是数据源问题。这些动作的共同点是知道“怎么做”的人很多但把“怎么做”固化成可执行流程的很少因为每个案例的细节都不一样。2.2 方案的四个核心模块我们最终落地了一套“四层架构”每层解决一类问题第一层感知层。负责全面感知搜推数据生产链路的状态。这一层接入了调度平台的实例运行状态、数据质量监控的告警事件、血缘系统的元数据变更、甚至包括线上推理服务的性能指标。感知层输出的是统一的“环境快照”供上层Agentic系统做推理决策。第二层决策层。这是Agentic的核心由一个主Agent加若干专业子Agent组成。主Agent负责理解用户意图、拆解任务、编排子Agent协作子Agent则聚焦特定域比如数据质量诊断Agent、特征工程Agent、调度运维Agent。每个子Agent都封装了对应该域的领域知识和决策逻辑。第三层执行层。Agent决策的落地依赖一套工具集包括ETL脚本执行器、数据校验器、调度操作器、Notebook执行环境等。所有工具都通过标准的工具接口暴露Agent通过“规划-调用-观察结果”的方式使用它们。第四层校验层。每次执行动作之后系统会触发自动校验数据量级是否合理、字段分布是否符合预期、任务状态是否恢复正常。校验结果会反馈给决策层形成一个闭环。这四层说起来抽象实际跑起来的效果是数据同学提了一个“接入新用户活跃特征”的需求主Agent拆解任务后调度特征工程Agent生成特征计算逻辑调用执行层跑数再由校验层检查覆盖率、分布、空值率是否符合阈值全部通过后自动提交上线评审。全程人工参与度极低但每一步都有迹可循、有日志可查。2.3 为什么选择Agentic而不是LLM直接生成代码这里有一个容易被误解的点Agentic不是让大模型直接写代码、直接改配置。搜推数据生产对准确性要求极高一个错误的特征逻辑上线直接影响线上模型效果伤害的是真实用户体验和商业指标。LLM直接生成代码的风险在于它不了解这个特定业务场景的上下文很容易“一本正经地胡说八道”。Agentic的解法是给LLM装上“眼睛”和“手”——眼睛是感知层提供的真实链路状态手是执行层提供的受控工具。LLM负责的是“理解和规划”不是“直接操作”。所有高危动作改生产表、动调度配置、发上线单都经过工具层的一层额外校验确保Agent的行为在可控范围内。打个比方传统方式是“让人去操作工具”LLM直出代码是“让AI当人”Agentic更像是“让AI当操作员但操作面板上有安全锁”。安全和效率之间Agentic找到了一个当前技术条件下最务实的平衡点。3. 核心环节拆解从需求理解到任务编排的实操细节前面讲了整体架构这一节落到实操聊聊我们在每个核心环节踩过的坑和总结出的关键细节。3.1 意图理解怎么让Agent准确get到数据同学的需求Agentic系统的第一个入口是意图理解。数据同学不可能都用精确的指令格式跟Agent对话真实场景里的需求往往是口语化的“帮我看看用户点击特征那边的数据有没有问题”、“新客推荐场景的特征覆盖咋这么低”、“明天要用的训练集还缺哪些分区”。我们第一版只做了关键词匹配加简单模板效果惨不忍睹。同样是“特征覆盖”既可能指特征在样本中的覆盖度也可能指特征在线上请求中的覆盖率还可能是特征上线时默认值填充的覆盖规则。同一个词在不同语境下含义完全不同关键词匹配根本搞不定。后来改成基于LLM的意图解析加槽位填充效果好了很多但依然有坑。最典型的一个问题是“隐含约束”的识别。数据同学说“把点击特征的样本延迟降低”隐含的诉求可能是要改样本拼接的时间窗口也可能是要优化上游任务的调度依赖还可能是要调整特征的计算时效。Agent如果只是按字面执行很可能改错了方向。我们的解法是“多轮澄清优先于直接执行”。当Agent识别到意图存在歧义时不会直接调用工具而是先向用户提出澄清问题“你说的降低延迟是指样本拼接的窗口还是上游特征计算的调度频率”这样虽然牺牲了一点点交互效率但换来了执行准确率的大幅提升。3.2 任务拆解与链路规划从目标到可执行步骤意图理解之后进入任务拆解阶段这是Agentic系统的关键环节也是最难做好的部分。搜推数据生产任务的链路通常不是线性的而是一个有并行、有条件分支、有回退路径的DAG。举个例子“评估新特征对搜索排序模型效果的影响”这个任务拆解出来至少包含确认特征定义和数据来源、计算特征在训练样本中的覆盖率、统计分析特征分布和异常值、基于历史数据做特征有效性回测、输出评估报告。这些步骤中“计算覆盖率”和“做回测”是可以并行的但“确认特征定义”是前置条件。我们让LLM基于工具列表和链路元数据生成候选计划再用一个独立的“计划校验器”去检查计划的有效性——是不是有缺失的前置依赖是不是有循环引用是不是有些步骤其实可以并行执行以节省时间计划校验器是规则模型混合实现的规则部分保证DAG的拓扑正确性模型部分评估计划的合理性。实操中的一个经验是不要把任务拆得太细。刚开始设计Agent时我们倾向于把所有粒度都拆到最小——每个字段的计算单独成为一个步骤。结果计划冗长、执行缓慢、出错概率高。后来调整策略只拆到“任务级”粒度比如“计算用户活跃度特征”作为一个整体内部的字段逻辑由子Agent自行处理。整体效率和可维护性反而更好。3.3 子Agent的协同机制数据质量、特征工程、调度的分工搜推数据生产涉及的领域太杂单一大Agent什么都干反而什么都干不好。我们按领域分了三个子Agent数据质量Agent、特征工程Agent、调度运维Agent。每个子Agent有独立的知识库和工具集。数据质量Agent负责监控和诊断数据异常。它的知识库里存了常见的搜推数据质量问题类型——字段解析错误、上游数据延迟、分区数据缺失、口径变更未同步。出现告警时数据质量Agent会先做基础诊断定位异常层级和影响范围。特征工程Agent负责特征的新增、修改、下线全流程。它的核心能力是理解特征口径和业务语义能自动生成特征计算逻辑的草稿并且会检查新特征与现有特征之间的相关性防止重复建设。调度运维Agent负责任务实例的运维操作。上游表分区延迟了它会评估是等待、补数还是跳过任务失败了它会判断是重试还是告警升级到人工。三个子Agent不是孤立的它们之间通过一个“事件总线”通信。典型场景是调度运维Agent发现某个上游任务失败产生了一个事件数据质量Agent订阅到该事件后自动排查该任务产出的数据是否已经污染了下游如果有影响则触发补偿流程。这种协同机制让整个系统有了“组织性”而不是一堆功能孤岛。3.4 知识注入把老师傅的经验变成Agent的“肌肉记忆”Agentic系统能不能产生真实价值很大程度取决于知识注入的质量。LLM本身的知识是通用性的它知道“数据质量”这个概念但不了解你们平台特有的“A表B字段在C场景下可能有D问题”这种具体经验。我们做法是“知识库案例库”双轨注入。知识库存的是领域规则和操作规范比如“样本拼接必须使用T-1的数据”、“特征上线前必须校验空值率低于X%”。案例库存的是历史问题的复盘记录每条案例包含问题现象、定位过程、根因、解决方案、预防措施。案例库的价值在多轮对话场景下特别明显。用户描述一个新问题时Agent先在案例库中检索相似历史案例基于历史经验给出初步判断。比如用户反馈“搜索CTR今天掉了2个点”Agent检索到历史上有过类似问题那次根因是某个热门短视频的标题字段解析异常导致特征值偏高Agent就会优先排查这个方向而不是漫无目的地做全链路扫描。知识注入的工作量确实不小但收益也直接。上线案例库后我们Agent的首次诊断准确率提升了接近一倍很多高频问题可以做到秒级定位。4. 实操过程与核心环节实现链路编排、质量校验与自治闭环前面讲的是设计思路这部分讲落地实现——我们具体是怎么把Agentic系统搭起来的里面有哪些关键实现值得参考。4.1 链路编排把“人肉排期”变成“动态规划”传统的数据生产任务编排是静态的——调度平台配好依赖关系后每天按部就班地跑。Agentic带来的变化是编排从“静态配置”变成“动态规划”每个任务实例运行时Agent会基于当前环境动态决定执行策略。我们实现了一个“动态任务规划器”。它接收三类输入任务目标、环境快照、可用工具。任务规划器首先生成候选执行计划然后基于预估时间和资源消耗做排序选出最优路径执行。执行过程中如果发现环境变化比如某个数据源临时不可用规划器会重新规划寻找替代路径。举一个具体例子。每天凌晨的“用户画像特征全量计算”任务正常情况下需要累计跑40分钟。某天我们监控到其中一个中间表产出晚了20分钟按静态依赖的逻辑整个任务链都会被推迟。但动态规划器识别到这个中间表只影响3个下游特征其他17个特征不依赖它于是自动调整了执行计划——把不受影响的特征先跑完受影响的特征等数据到位后再补跑。最终整体任务只推迟了5分钟而不是20分钟。这个能力的实现依赖精细的“数据依赖血缘”解析。我们把任务的依赖精确到“字段级”而不只是“表级”这样Agent才能判断一个上游异常到底影响哪些下游。字段级血缘的维护成本不低但回报是动态编排的精准性大幅提升。4.2 数据质量校验从“事后告警”到“事前预防事中控制”搜推数据生产的数据质量管控过去最常用的是“阈值告警”——监控指标超过阈值就报警。这种模式的问题很明显阈值设宽松了问题发现太晚阈值设严格了误报率飙升值班同学很快产生告警疲劳。Agentic系统把质量管控分成了三层防线。第一层是事前校验任务执行前Agent自动校验上游数据是否就绪、字段完整性是否达标、数据量级是否在合理区间。不满足条件就不启动任务从源头避免“垃圾进垃圾出”。第二层是事中控制任务执行过程中阶段性校验中间结果。比如特征计算跑了三分之一Agent抽样检查中间结果的特征分布如果异常可以提前终止避免浪费时间跑完一个注定失败的任务。第三层是事后复核任务完成后做全量质量校验包括数据完整性、一致性、分布合理性。实操中有个做得比较细的点Agent的校验项不是固定写死的而是根据任务类型动态生成。同样的“数据完整性校验”对核心业务表会检查“分区是否全部产出、行数是否匹配昨日、关键字段空值率是否低于0.5%”对辅助表则只检查“分区是否产出、行数量级是否正常”。校验规格的动态适配既保证了核心链路的高标准又避免了辅助任务被过度校验拖慢。4.3 自治执行与人工介入的边界安全护栏设计Agentic系统一旦具备执行能力安全边界就变得极其重要。我们的设计原则是“分级别授权”——不同动作类型对应不同的审批要求。第一级别是“自动执行”信息查询、诊断分析、低危操作比如查看任务日志、统计特征覆盖率、生成诊断报告。这些动作Agent可以直接执行不需要人工介入。第二级别是“自动执行但留痕”有一定影响的操作比如重跑失败任务、调整调度优先级、修改特征计算逻辑的草稿。执行前Agent会记录操作原因和预期影响执行后自动同步结果给相关人员。第三级别是“人工审批后执行”高危操作比如修改生产表结构、变更线上特征口径、下线正在使用的特征、调整核心调度依赖。Agent会生成完整的操作方案和风险评估发送给负责人审批审批通过后才执行。这个分级授权机制上线后团队的心态发生了明显变化。最开始大家对“Agent能直接操作生产”这件事是极度警惕的但看到所有动作都有清晰的授权等级和审计日志且高危操作依然需要人工审批接受度就慢慢建立起来了。我们在护拦上还做了一个细节设计Agent执行动作前会自动做一次“影响面预估”。比如Agent想重跑某条ETL任务它会先查一下这个任务的下游依赖图预估影响的数据表和任务范围然后在操作记录中注明“本次重跑可能影响X张下游表、Y个下游任务”。如果影响范围超出预设阈值即使动作本身是第二级授权也会自动升级到人工审批。4.4 关键技术选型Agent框架、模型选择与工具封装技术选型上我们没有盲目追新。Agent框架层面最初考察了当时社区讨论较多的几个主流方案最后自研了轻量编排层核心原因是我们搜推数据链路里“工具调用”的形态太特殊了——既有SQL执行、Python脚本运行又有调度平台API调用、监控系统事件订阅通用框架的工具抽象能力覆盖不了这些场景。自研编排层可以更好地贴合内部基建。模型层面我们没有只用单一模型。核心决策用更强的大模型保证复杂推理的准确性高频、低风险的判断用轻量模型控制成本。比如“识别用户意图中的业务关键词”这种任务用轻量模型就够而“综合链路状态推理问题根因”这种任务必须用强模型。模型路由规则我们跑了一段时间后沉淀成了一个配置化模块支持按任务类型灵活调整。工具封装是个容易被低估的工作量点。每个工具的输入输出都必须标准化Agent才能流畅地串联调用。我们定义了一个统一的“工具协议”每个工具有明确的参数schema、执行超时、输出格式、错误码约定。工具有执行失败时返回结构化错误信息Agent才能基于错误信息做下一步判断而不是面对一坨日志干瞪眼。5. 落地效果复盘从效率提升到质量改进的真实数据讲了这么多设计最终还是要看效果说话。目前这套Agentic搜推数据生产体系已经在我们的核心业务链路上稳定运行了几个月几个维度的变化比较明显。5.1 提效端到端交付周期从“按周计”到“按天计”最直观的变化是数据需求的交付周期。过去一个常规的特征接入需求从提需求到上线的端到端周期通常需要3到5个工作日主要耗时在跨团队沟通、排期等待和手动校验。现在Agent可以在需求提出后自动完成大部分链路工作——意图解析、数据探查、特征逻辑生成、覆盖率校验、上线方案输出人工只需要在最后确认一下。我们统计了最近两个月的数据需求交付记录平均端到端周期缩短到了1.5个工作日左右。部分标准化程度高的需求甚至可以在几个小时之内走完流程。这种效率提升不是压榨出来的而是省掉了大量因为“等人”和“等确认”产生的等待时间。5.2 质量主动发现代替被动响应数据事故率下降数据质量层面的变化更值得关注。过去的数据质量保障是“被动响应式”的——系统先出现问题用户或监控先发现然后值班同学介入排查。Agentic系统上线后大量的数据问题在“萌芽期”就被识别和处理掉了。典型场景是数据口径变更。搜推业务迭代快埋点字段经常调整。过去一个字段口径变了如果没通知到位下游所有用这个字段的特征都会默默“带病运行”好几天。现在Agent在元数据变更事件触发后会主动检索下游影响面自动通知相关任务负责人并给出调整建议。我们已经有几次案例是Agent在数据真正出问题之前就把变更影响处理掉了。季度维度看搜推核心链路的数据质量事故数量下降了明显更关键的是“影响时长”大幅缩短——很多原本需要人工熬夜排查的场景现在Agent可以在分钟内完成初步定位并给出处理方案。5.3 体验从抵触到依赖团队协作模式的变化还有一个值得说的变化是团队协作模式。最开始推广Agentic系统时团队内部有不少观望情绪担心Agent不可靠、担心自己的工作被替代、担心操作失控。但实际跑了一个月后态度发生明显反转。原因在于Agent解决的是大家最烦的“琐碎杂活”。数据同学不用再每天盯着调度看板做人工巡检算法同学不用再花半天时间等特征数据产出值班同学不用再半夜爬起来做初级诊断。人从重复劳动中解放出来去做更有创造性的工作——设计新的特征体系、优化样本策略、分析用户行为模式。现在团队的日常协作模式已经是“人负责定义目标和审核结果Agent负责执行过程和细节确认”。这跟“人做所有事”的效率差异是用过就回不去的。6. 踩坑实录那些文档里不会写的教训实施过程中踩的坑不少挑几个有代表性的整理出来给准备做同类改造的团队一些参考。6.1 大模型幻觉在数据生产场景是“致命伤”第一个绕不开的坑是大模型幻觉。Agent在生成特征计算逻辑时可能会“编造”不存在的字段或表名。这在通用场景里可能只是答案不够准确在数据生产场景里可能导致任务直接失败甚至产出错误数据。我们的教训是必须在工具调用层和校验层做双重拦截。工具调用层Agent生成SQL或代码后先做“静态语法检查元数据比对”核对引用的表名、字段名是否真实存在。校验层任务跑完后做“数据合理性校验”检查产出数据的量级、分布是否符合预期。这两层缺一不可单靠提示工程约束效果有限。6.2 工具的“副作用”比想象中多Agent调用工具时容易忽略工具的“副作用”。比如重跑一条ETL任务表面上是重新计算一份数据但副作用是它会占用计算资源、可能锁定表、可能触发下游任务的级联启动。Agent如果只看目标不看副作用很容易在资源紧张的时候“好心办坏事”。后来我们在工具定义里增加了“副作用说明字段”让Agent在决策时能考虑操作的间接影响。同时做了资源配额管理Agent触发的任务有一套独立的资源池和人工触发的任务物理隔离避免互相挤兑。6.3 历史经验的“保鲜期”问题知识库和案例库上线初期效果很好但运行一段时间后我们发现一些历史案例的判断已经“过期”了。业务变了、数据链路变了、口径变了老经验不再适用Agent还在按旧逻辑判断反而造成误导。这个问题我们花了不少力气解决。现在的做法是“知识动态化”——知识库和案例库的内容不是一次灌进去就完事而是有定期刷新机制。每次Agent执行完任务系统自动评估“本次执行相关的知识是否仍然有效”过期的知识会被标记下架。6.4 可观测性可能是最容易忽视的“隐性工程”Agentic系统自身的可观测性建设是我们前期忽视后来痛补的一块。Agent的执行链路本来就比传统系统复杂——有意图理解、任务规划、工具调用、结果校验多个环节如果不做专门的日志和追踪出问题根本无从排查。现在我们对Agent的每个环节都打点记录输入是什么、模型是怎么推理的、选择了什么工具、工具返回了什么、校验是否通过。有一次线上Agent误操作我们就是靠完整链路日志快速定位到了模型推理环节的上下文误解问题。没有这些可观测性数据那一次排查可能要折腾一整天。7. 常见问题与排查技巧实录把这段时间维护Agentic搜推数据生产体系遇到的高频问题整理成一份速查表给遇到类似困扰的同行参考。问题一Agent意图理解错误执行了非用户本意的操作排查思路先看意图解析环节的日志确认用户原始输入和解析后的结构化意图。大概率是隐含约束没被识别。解决方法是增强多轮澄清机制在意图不确定时先问清楚再行动不要贸然执行。实操技巧给Agent预设“不确定性阈值”——当解析置信度低于阈值时强制进入澄清流程。宁可多问一句不要做错一步。问题二Agent生成的执行计划存在循环依赖或缺失前置排查思路检查计划校验器的输出日志。循环依赖一般是因为子任务的依赖关系描述不清晰缺失前置则是因为信息感知不全。实操技巧计划校验器里加“前置条件自动补全”逻辑。Agent生成计划后校验器自动比对依赖关系发现缺失的前置条件自动补充而不是直接报错。问题三知识库中的历史案例误导了Agent的判断排查思路检查案例检索环节看Agent是基于哪条历史经验做的判断。这类问题通常出在“表面相似但本质不同”的案例匹配上。实操技巧案例库中增加“使用有效期”和“适用条件”元数据。检索时不仅看相似度还会校验当前场景是否满足案例的适用条件。问题四Agent操作导致资源竞争影响核心链路任务排查思路查看调度平台的资源水位监控确认Agent触发任务的时间和资源峰值是否重叠。实操技巧给Agent触发的任务设置独立的资源池和优先级确保它不会挤占核心链路任务的计算资源。这属于架构层面的规避方案比事后处理更可靠。问题五模型升级后Agent行为发生漂移排查思路对比升级前后的Agent决策日志。模型升级后同样的输入可能产生不同的推理结果这是正常的模型行为漂移。实操技巧每次模型升级前先在测试环境跑一遍完整回归测试覆盖核心场景的输入样例。线上环境和测试环境之间做模型灰度而不是一次性全量切换。8. Agentic 搜推数据生产的边界与下一步演进说句实在话Agentic重塑搜推数据生产这件事目前也只走到了“从0到1”的阶段距离真正意义上的“数据自治”还有很长的路。有些事情是当前Agent做起来很吃力的这些边界值得冷静看待。当前最大的瓶颈在于长链路多跳任务的错误累积。一个任务的执行链条一旦超过五六跳每跳都有一定的失败率或误差率累积起来就容易出现无法收敛的情况。更麻烦的是上层Agent对底层执行细节的感知是有限的链路深处的偶发问题很难被准确归因只能通过对外层的表现逆推原因。多智能体协作的一致性也需要解决。不同子Agent可能因为各自的局部视角做出互相冲突的决策比如调度Agent想重跑任务数据质量Agent却判断这个数据源本身有问题两者会互相干扰。目前我们是靠较重的协调机制兜底——主Agent集中裁决所有争议代价是效率受损在实时性要求高的场景下感觉特别明显。未来演进方向上我们在重点探索“面向搜推场景的轻量Agent框架”和“经验持续沉淀机制”。用一套足够好的基础模型配合搜推数据生产的专用工具集让智能体在中小团队里也能快速搭建起来而不是每个团队都要从头造一套定制化的Agent体系。这条路很宽但也很长。回到开头那个判断Agentic确实是搜推数据生产体系的一次重要重塑机会。它是把“数据生产从人力驱动转向智能驱动”的一个具体解法不是概念炒作是真能落地、真能带来效率和质量提升的工程实践。