写在前面：AI 进入生产，不等于 AI 接管生产

     大模型已经能够理解需求、生成代码和解释错误，但数据生产的难点从来不只是“写出一段 SQL”。一项真实需求还要经过数据源确认、口径澄清、加工编排、资源规划、任务提交、调度运行、结果交付和故障处置。任何一步缺少确定性约束，都可能让“看起来正确”的答案变成生产风险。

     因此，本文讨论的不是让模型绕过平台直接操作生产，而是建立一条受控链路：Forge Agent 作为统一 AI 门面，Sindri Plugin/MCP 作为确定性工具面，Sindri 后端负责权威规划与提交，ADF 承载 DAG、调度、状态和生命周期。

     这四者不是彼此替代，而是把智能决策与确定性执行分层：模型负责理解、澄清和组织过程；工具与平台负责校验、规划、授权、执行和留痕。这条边界，正是我们想在本文里分享的核心设计取向。

一、为什么“生成任务代码”还不等于“完成数据研发”

     主搜、推荐、垂站、营销等链路长期独立演进，容易形成多头接入、多套配置、多处产出和分散运维。一个需求看似只是加工逻辑，实际可能横跨消息、表、UDF、项目空间、账号、队列、执行引擎、索引构建和发布流程。

单纯生成 SQL 或脚本，无法独立回答以下问题：

• 数据对象、运行环境和业务口径是否准确；
• 语义结构能否通过编译、拓扑和依赖检查；
• 应创建哪些执行节点、选择何种资源与执行形态；
• 谁可以提交，写操作是否经过预览与确认；
• DAG 创建后如何调度、回查状态、定位失败并继续处理。

底池平台真正需要统一的，是从意图到数据产物的生产过程，而不是某一种代码入口。Agent 的价值也不在于替代底层平台，而在于把平台能力组织成更自然、更连续、更可解释的研发体验。

二、系统全景：一张图看清各层协作与质量贯穿

     在展开每一层细节之前，先把整体规划摆出来。我们希望的不是给旧链路加一个聊天入口，而是让智能入口、领域语义、统一底座与质量保障各归其位、协同成一个系统。

这张总览可以从两个方向读：

• 横向的主链路：Forge Agent 在最上层组织研发过程；往下是领域数据研发平台，它以特征加工（特征定义、计算圈选、发布应用）与底池加工（领域 DSL、语义编译与规划、任务提交与管理）两条主线沉淀业务语义；再往下 ADF 作为统一数据与计算底座，承载算子体系、连接与适配、数据与元信息、多引擎执行；产物最终服务搜索、推荐、重点场景与在线应用。自然语言意图经由领域语义、执行 DAG、数据产物，最终回到业务反馈。
• 纵向的质量贯穿：最左侧的数据质量系统不属于某一层，而是纵向贯穿全链路——数据核对、数据质量、血缘追踪、监控大盘分别从一致性、达标度、可溯源与可观测四个角度，为整条链路托底可信。

接下来就逐层展开：先看智能入口 Forge Agent，再看领域后端 Sindri，然后是执行底座 ADF 与统一底池，最后回到纵向贯穿的质量、血缘与自愈。

三、从工具化、DSL 化到 Agentic 化

数据研发智能化可以看作三层能力的叠加。

1. 工具化：把查询、校验、规划、预览、提交和状态回查封装为参数明确、结果结构化的操作。
2. DSL 化：以领域语义描述数据来源、转换关系和交付目标，由编译与规划链路完成确定性转换。
3. Agentic 化：由 Forge Agent 理解自然语言目标，路由 Skill 和工具，并依据真实返回结果持续修正步骤。

这里的关键不是“Agent 更自由”，而是“不确定性被压缩到可控边界”。越接近生产写操作，越需要稳定接口、结构化错误、权限门禁、显式确认和平台事实。

四、四层协作：一个入口，三层确定性承载

     这一分层必须保持稳定：Forge 不自由推断底层状态，Plugin/MCP 不取代权威规划，Sindri 不绕过 ADF 自建通用调度，ADF 也不承担业务口径推理。

五、Forge Agent：统一 AI 门面，而不是“超级组件”

      Forge Agent System 面向组织级 Agent 工程化，目标是把分散在个人环境中的模型、Skill、Plugin/MCP、权限和轨迹纳入统一 Harness。它解决的是“如何稳定使用 Agent”，而不是把所有领域能力重新实现一遍。

在这套分工中：

• Skill 固化单一职责的领域流程与知识，避免一个大而全的提示承担全部逻辑；
• Plugin/MCP 执行编译、校验、生成、提交、查询等确定性动作；
• Hook 在关键节点施加权限、审计和流程约束；
• Trace/Trajectory 记录真实调用过程，为回归评测和能力优化提供证据；
• Golden Case/Eval 界定能力边界，支持版本演进后的持续验证。

      这套 Harness 的设计取向很清晰：模型负责理解，确定性工具负责保障；Tool Call 把流程节点固化下来，关键动作设置 Hook 和人工确认点。它把“如何稳定地使用 Agent”这件事本身工程化，从而让同一套 Agentic 研发方法可以从特征场景延伸到更广的底池研发。

六、Sindri：从领域语义到权威执行计划

      Forge Agent 面向人组织研发过程，Sindri 则面向平台解释“这项数据加工究竟要如何执行”。二者之间通过确定性工具交互，而不是让模型直接拼装 ADF 请求。

一次典型链路可以概括为：

需求澄清 → 上下文获取 → DSL 构造 → 结构校验 → Sindri 权威规划 → 提交预览 → 显式确认 → Sindri 提交 → ADF 生命周期 → 状态反馈。

6.1 DSL 表达“要做什么”

     领域 DSL 用稳定语义描述数据对象、转换算子、过滤、关联、聚合、UDF/UDTF 与输出目标。它首先形成语义结构，而不是提前绑定某一种引擎或资源配置。

6.2 Plugin/MCP 提供确定性操作

     工具面负责读取上下文、构造或校验 DSL、调用后端规划、展示提交预览以及查询任务状态。它可以做前置检查和友好诊断，但不能以本地启发式结果替代 Sindri 后端的权威计划。

6.3 后端规划并提交

     Sindri 后端完成语义解析、对象绑定、逻辑计划和物理计划生成，再构建 ADF 可承载的 DAG 请求。在这个分层里，规则优化、成本优化与执行器选择自然落在 Planner 这一层：语义表达与执行策略解耦后，优化空间才有稳定的施展位置，也才便于随场景持续演进。

     规划与提交应分离：先返回节点、执行形态、资源和影响范围供确认，再由显式写操作触发提交。最终的任务归属、执行计划和提交结果以后端为准。

七、ADF：承载 DAG、调度、状态和生命周期

     ADF 是通用执行与管控底座。它接收领域后端物化后的任务请求，组织 DAG 节点和依赖，管理调度、运行、发布及状态回查，使上层领域语义不必重复建设通用执行基础设施。

     ADF 可以承载 Spark、Flink、Shell、JDOS 等任务形态，并通过适配机制持续扩展。这种“多形态承载”的设计价值在于：领域后端只描述执行意图，具体在哪种引擎上落地由适配层决定，从而把执行引擎的多样性隔离在 ADF 之内。

     这一点也决定了引擎接入的方式。如果未来引入 Daft 等新的执行引擎，同样应通过统一契约和适配层进入 ADF，而不是由 Forge 或 Sindri Plugin/MCP 直接控制。执行引擎的选择与扩展，始终收敛在执行底座这一层。

八、统一底池：稳定语义连接多样执行与交付

     统一底池不是把所有任务改写成同一种代码，而是建立稳定中间层：上游来源可以变化、下游产物可以变化、执行形态也可以变化，但领域语义、规划接口、提交边界和状态模型保持一致。

九、质量、血缘与自愈：先建立证据，再扩大自动化

     质量检查、核对、血缘、监控和恢复是可信数据生产不可缺少的方向。回到开篇的系统总览，数据质量系统当前聚焦在"把质量保障做扎实"这件事上，它由四类能力构成：

• 数据核对：跨源比对、全量与抽样校验、差异归因，确认多处产出在口径上真正一致；
• 数据质量：规则校验、完整性与一致性检查、阈值告警，把"数据是否达标"变成可度量的约束；
• 血缘追踪：字段级血缘、影响分析与溯源定位，让每一处产物都能回答"从哪来、影响谁"；
• 监控大盘：链路健康、SLA 与时效、异常观测，把运行态的可信度实时呈现出来。

     需要说明的是，数据质量系统当前的定位是保障质量——把核对、质量、血缘与监控这四类能力做扎实，而不是已经做到面向全链路的自动赋能与自愈。往后看，我们希望它进一步演进为贯穿全链路的可信底座：把质量能力沉淀出的证据，逐步开放给自动化去消费。

     因此，这里更想分享的是一个规划方向上的判断：自愈闭环不应该一开始就以"全自动"为目标，而应该先把证据打通，再让自动化在有证据支撑的范围内逐步扩大。核对、质量、血缘与监控产出的，正是支撑这一方向的证据基础。

沿着这个方向，可行的第一步是先打通三类证据：

1. 规划证据：记录目标环境、语义结构、执行节点、资源方案和确认结果；
2. 提交证据：记录预览、权限判断、提交结果以及 Sindri 与 ADF 对象标识；
3. 运行证据：回传 DAG、任务、实例、日志和结构化错误，让 Agent 基于事实继续处理。

     在这些基础上，局部校验、诊断建议和有限重试可以逐步接入。真正的自愈还需要稳定状态机、幂等机制、风险分级、重试上限、结果复核和人工接管——这也是为什么“先证据、后自动化”更稳妥：证据链越完整，可以安全交给自动化的动作就越多。

十、演进路线：从可调用，到可验证，再到可自治

第一阶段是能力原语化：把查询、校验、规划、预览、提交和状态回查收敛为稳定工具，让 Forge Agent 不需要拼接底层接口。

第二阶段是流程契约化：明确输入输出、错误分类、权限等级、人工确认点和恢复边界，使长流程可中断、可续接、可审计。

第三阶段是证据贯通：关联需求、DSL、计划、Sindri 任务、ADF DAG、实例和数据产物，为质量、血缘和评测提供可信标识。

第四阶段才是受控自治：对低风险、可逆、可验证的动作逐步开放自动处理；高风险操作继续保留方案预览与人工确认。

     这条路线的核心不是追求一次性“全自动”，而是逐步提升可验证范围。只有平台事实能够稳定返回，Agent 才可能稳定决策；只有每次动作都可追踪、可复核，自动化权限才有扩大空间。

结语

     数据涅槃，不是给旧链路增加一个聊天入口，而是重塑从业务意图到数据价值的生产方式。

     Forge Agent 作为统一 AI 门面，把需求、知识、流程和反馈组织起来；Sindri Plugin/MCP 把确定性能力变成可发现、可组合的工具；Sindri 后端守住权威规划与提交边界；ADF 负责 DAG、调度、状态和生命周期。四者共同构成“智能组织、确定性规划、受控提交、稳定执行”的协作链路。

     当职责边界被清晰划分，当每一次规划有依据、每一次提交有确认、每一次运行有状态，AI 才不只是生成内容，而是成为可信的数据生产力。

作者

付剑生、曹安富、王浩、高佳伟、黄一洋、秦丽佳 京东集团-京东零售-平台产品与研发中心-AI Infra与大数据计算部-搜推特征研发技术部