写在前面：AI 进入生产，不等于 AI 接管生产
当前大模型已经能够理解需求、生成代码和解释错误，但数据生产的难点并不只是"写出一段 SQL"。一个需求还要经过数据源确认、口径澄清、加工编排、资源规划、任务提交、调度运行、结果交付和故障处置。任何一步缺少都可能让"看起来正确"的任务变成生产事故。
因此，我们的目标不是让模型绕过平台直接操作生产，而是建立一条受控链路：Forge Agent 作为统一 AI 门面，Sindri Plugin/MCP 作为确定性工具开发及约束，Sindri 后端负责核心链路规划与提交（包含DSL解析、执行计划生成、执行计划优化等），ADF 辅助上游系统屏蔽大数据平台操作并承载 DAG、调度、状态和生命周期。
一、为什么要开发这套系统
当前各业务场景缺少一套统一、完整的数据研发平台，数据接入、清洗、业务加工、索引构建与运行维护等环节仍高度依赖人工，研发链路割裂且难以复用。
•主站：当前没有专门的平台承载完整的数据研发流程，数据接入、加工和索引构建等工作仍然依靠人工维护。
•推荐：有对应相对完善的索引构建系统，但系统定制化程度较高，数据接入、清洗和业务加工仍需人工在接入系统前完成。
•垂站：目前以配置管控系统为主，但各垂站内部流程和加工环节存在差异，仍然需要针对具体业务进行人工开发。
这些问题不仅带来了重复建设和较高的人力成本，也使研发标准、流程衔接、质量保障和运行维护难以统一。因此，我们希望建设一套统一的数据研发系统，将数据接入、清洗、业务加工、索引构建、任务提交、调度运行和故障处置串联起来，在保留不同业务场景灵活性的同时，沉淀可复用的平台能力，减少重复开发和人工操作，同时通过系统化能力提升数量质量。
二、系统全景设计
我们希望的不是给旧链路加一个聊天入口，而是让智能入口、领域语义、统一底座与质量保障各归其位、协同成一个系统。系统架构如下：
•横向的主链路 ：Forge Agent 组织研发全过程；领域数据研发平台以特征加工 （特征定义、计算圈选、发布应用）与底池加工（领域 DSL、语义编译与规划、任务提交与管理）两条主线沉淀业务语义； ADF 作为统一数据与计算底座，承载算子体系、连接与适配、数据与元信息、多引擎执行；产物最终服务搜索、推荐、重点场景与在线应用。自然语言意图经由领域语义、执行 DAG、数据产物，最终回到业务反馈。
•纵向的质量贯穿：数据质量系统不属于某一层，而是纵向贯穿全链路------数据核对、数据质量、血缘追踪、监控大盘分别从一致性、达标度、可溯源与可观测四个角度，为整个系统托底可信。
三、Forge Agent 组织数据研发流程
这套方案不是在现有平台上增加一个对话入口，而是将数据研发过程中分散的能力重新组织起来。查询、校验、规划、预览、提交和状态回查先被封装为参数明确、返回结果稳定的工具；数据来源、转换关系和交付目标通过领域 DSL 统一表达；Forge Agent 再根据用户需求调用这些能力，串联完整的研发流程。
各层职责如下：
| 层次 | 核心角色 | 职责边界 |
|---|---|---|
| 研发入口 | Forge Agent | 需求澄清、任务拆解、Skill 路由、工具选择、结果解释与人工交接 |
| 工具接口 | Sindri Plugin/MCP | 将上下文查询、DSL 构造、校验、规划、提交和状态查询封装为稳定工具 |
| 领域后端 | Sindri 后端 | 解析领域语义、绑定平台对象、生成执行计划、构建请求并提交 |
| 执行底座 | ADF | 创建 DAG、组织节点依赖、调度运行、维护任务与实例状态 |
为了让这套流程能够稳定用于生产，Forge Agent 配套实现了以下机制：
•Skill：沉淀具体场景的操作流程和领域知识；
•Plugin/MCP：执行编译、校验、生成、提交和查询等标准操作；
•Hook：在提交等关键节点执行权限校验、审计和人工确认；
•Trace/Trajectory：记录实际调用过程，便于定位问题和复盘；
•Golden Case/Eval：通过固定案例验证版本变更是否影响已有能力。
通过上述分工，模型只负责需求理解和流程组织，生产操作仍由平台接口、权限规则和执行结果约束。这样既能减少人工在多个系统之间反复操作，也能保留现有平台在规划、调度、权限和审计方面的确定性。
四、Sindri：从领域语义到可信执行计划
Forge Agent 面向人组织研发过程，Sindri 则面向平台解释"这项数据加工究竟要如何执行"。二者之间通过确定性工具交互，而不是让模型直接拼装 ADF 请求。
一次典型链路可以概括为：
需求澄清 → 上下文获取 → DSL 构造 → 结构校验 → Sindri 权威规划 → 提交预览 → 显式确认 → Sindri 提交 → ADF 生命周期 → 状态反馈。
4.1 DSL 表达"要做什么"
领域 DSL 用稳定语义描述数据对象、转换算子、过滤、关联、聚合、UDF/UDTF 与输出目标。它不关注某一种引擎或资源配置。
下面截取并简化了超星索引 Pipeline 的核心拓扑。这个任务同时处理实时商品变更、实时价格变更和离线全量商品数据，并形成实时、离线两条输出分支：
ini
def build_dsl():
ctx = SemanticContext(
name="chaoxing_hk_pipeline",
owner="<owner>"
)
# 两路实时变更和一路离线全量数据；具体 SQL 独立维护
sku_changes = ctx.sql(build_sku_change_stream_sql())
price_changes = ctx.sql(build_price_change_stream_sql())
full_skus = ctx.sql(build_full_sku_batch_sql())
# 实时分支：合并商品与价格变更，并与 HBase 中的宽表状态合并
realtime = (
ctx.union(sku_changes, price_changes)
.merge("wide_table_chaoxing_hk")
.on("rowkey")
.alias("realtime_sku")
)
# 关联主站商品数据，补全索引所需的扩展属性
main_skus = ctx.from_table("hbase_main_search_data").alias("main_sku")
enriched = (
realtime.left_join(main_skus)
.on("realtime_sku.sku_id" = main_sku.rowkey")
.columns("sku_union_expand_ids")
)
# 离线分支：全量数据合并历史宽表
full_snapshot = (
full_skus.merge("wide_table_chaoxing_hk")
.on("rkey")
.alias("full_snapshot")
)
# 两个终止分支分别投递实时消息和离线索引数据
enriched.to("jdq_search_index_event")
full_snapshot.to("search_index_chaoxing_snapshot")
return ctx这个示例不只是串联 Source 和 Sink，而是在一个 SemanticContext 中表达了多源输入、union、状态 merge、跨域 left_join 和多分支输出。DSL 只描述数据依赖与业务拓扑：实时分支应落到哪类 Flink 任务、离线分支如何拆分、需要哪些算子和资源，都由 Sindri 后端结合表类型及运行配置生成计划。
4.2 如何提高 DSL 生成的准确性
DSL 开发目前最突出的问题不是"能不能生成代码"，而是输出是否稳定、是否符合当前 SDK 和后端规则。
•需求信息不完整：源表、字段映射、输出目标或运行方式没有确认时，容易自行补全业务参数；
•多个 Skill 职责重叠：需求提炼、DSL 开发、故障诊断和提交同时介入，容易答非所问，甚至在开发阶段提前执行提交操作；
•依赖已有记忆生成：SDK 接口、表类型和后端规划规则变化后，语法看似正确，但拓扑或执行形态已经不符合当前实现。
Sindri Plugin 没有只靠提示词约束这些问题，而是把开发流程拆成场景路由、需求契约、模板选择和逐级校验。职责如下：
本地校验只能证明 DSL 结构基本成立，最终任务拆分、引擎选择和资源规划以后端优化为准。提交同样采用两阶段门禁：先生成预览，只有用户明确确认后才执行真实提交。通过"单场景路由---需求契约---标准示例---SDK 事实---本地校验---后端规划---人工确认"这条链路，将 DSL 的准确性从一次生成问题转化为可检查、可回退的工程流程。
五、ADF：承载 DAG、调度、状态和生命周期
ADF 作为通用执行与管控底座。接收领域后端物化后的任务请求，组织 DAG 节点和依赖，管理调度、运行、发布及状态回查，使上层领域语义不再需要重复建设。
ADF 承载 Spark、Flink、Shell、JDOS 等任务形态，并通过适配机制持续扩展。领域后端只描述执行意图，具体在哪种引擎上落地由适配层决定，从而把执行引擎的多样性隔离在 ADF 之内。
六、统一底池：稳定语义连接多样执行与交付
统一底池不是把所有任务改写成同一种代码，而是建立稳定中间层：上游来源可以变化、下游产物可以变化、执行形态也可以变化，但领域语义、规划接口、提交边界和状态模型保持一致。
七、质量、血缘与自愈：先建立证据，再扩大自动化
质量检查、核对、血缘、监控和恢复是可信数据生产不可缺少的模块。数据质量系统当前聚焦在"把质量保障做扎实"，它由四类能力构成：
•数据核对：全量与抽样校验、差异归因，确认多处产出在口径上真正一致；
•数据质量：规则校验、完整性与一致性检查、阈值告警，把"数据是否达标"变成可度量的约束；
•血缘追踪：字段级血缘、影响分析与溯源定位，让每一处产物都能回答"从哪来、影响谁"；
•监控大盘：链路健康、SLA 与时效、异常观测，把运行态的可信度实时呈现出来。
需要说明的是，数据质量系统当前的定位是保障质量------把核对、质量、血缘与监控这四类能力做扎实。我们希望进一步演进为贯穿全链路的可信底座：把质量能力沉淀出的证据，逐步开放给自动化去消费。
这里想分享一个规划方向上的判断：自愈闭环不应该一开始就以"全自动"为目标，而应该先把证据打通，再让自动化在有证据支撑的范围内逐步扩大。核对、质量、血缘与监控产出的，正是支撑这一方向的证据基础。
沿着这个方向：
1.规划证据：记录目标环境、语义结构、执行节点、资源方案和确认结果；
2.提交证据：记录预览、权限判断、提交结果以及 Sindri 与 ADF 对象标识；
3.运行证据：回传 DAG、任务、实例、日志和结构化错误，让 Agent 基于事实继续处理。
在这些基础上，局部校验、诊断建议和有限重试可以逐步接入。真正的自愈还需要稳定状态机、幂等机制、风险分级、重试上限、结果复核和人工接管------这也是为什么"先证据、后自动化"更稳妥：证据链越完整，可以安全交给自动化的动作就越多。
八、部分效果展示
任务生产只需要一个描述文档或者提示需要生成个底池任务，会自动化生成对应的执行链路，并在执行过程中严卡关键数据避免用户错误。
任务生成后会产出对应的执行文件，当用户提交后会同步进行资源归档，用于后续迭代开发以及后续整体系统回测。
在数据质量系统中会将底池任务血缘自动化绘制（当前会将单个环节任务关联的其他任务进行同步绘制），同时点开某个环节也会同步展示单个环节下的详细信息便于用户全链路追踪及排查问题
结语
数据涅槃，不是给旧链路增加一个聊天入口，而是重塑从业务意图到数据价值的生产方式。
Forge Agent 作为统一 AI 门面，把需求、知识、流程和反馈组织起来；Sindri Plugin/MCP 把确定性能力变成可发现、可组合的工具；Sindri 后端守住规划与提交边界；ADF 负责 DAG、调度、状态和生命周期。四者共同构成"智能组织、确定性规划、受控提交、稳定执行"的协作链路。
当职责边界被清晰划分，当每一次规划有依据、每一次提交有确认、每一次运行有状态，AI 才不只是生成内容，而是成为可信的数据生产力。