خطوط أنابيب بيانات منسقة بوكلاء: بناء حزمة Dagster + dbt + MCP

النقاط الرئيسية

• أكملت Fivetran وdbt Labs اندماجًا في 1 يونيو 2026 (~600 مليون دولار ARR مجتمع، أكثر من 100,000 فريق بيانات) وأطلقتا Agents Schema — معيارًا مفتوحًا يحول مخطط المستودع إلى طبقة سياق مشتركة ومحوكمة للوكلاء.
• تفيد Databricks بأن أكثر من 80% من قواعد البيانات على وحدة Neon التابعة لها يوفرها وكلاء الذكاء الاصطناعي، لا البشر — المستهلك الأساسي لحزمة البيانات تحول بالفعل من المحلل إلى الوكيل.
• ثلاثة أنماط وكيلية تحدد خط الأنابيب الجديد — الوكلاء يكتبون ويؤسسون كود خط الأنابيب، وخطوط الأنابيب تشفى ذاتيًا باقتراح وتطبيق إصلاحات، والوكلاء يفرزون أعطال التشغيل في الدردشة — كل منها يحتاج إلى Lineage قابل للقراءة آليًا، لا لوحة بيانات مُصيَّرة.
• الحزمة ثلاث طبقات محوكمة — Dagster لتتبع نسب الأصول (lineage)، وdbt للتحويلات المختبرة والسياق المشترك، ووحدة MCP للوصول المحدد بالسياسات — بحيث يقرأ الوكيل بنية خط الأنابيب تحت نفس الضوابط التي يخضع لها الإنسان.

بُنيت حزمة البيانات للمحللين البشريين: تشغيل خط الأنابيب طوال الليل، وقراءة لوحة بيانات في الصباح، وتقديم تذكرة عندما يبدو رقم خاطئًا. وكلاء الذكاء الاصطناعي يستهلكون البيانات بشكل مختلف. كما تقول الشركة المندمجة Fivetran + dbt Labs، فإن الوكلاء «يعملون باستمرار، بالتوازي، وبسرعة الآلة» — ويحتاجون إلى بنية خط الأنابيب (lineage، الاختبارات، التعريفات)، لا مخرجاته فقط. في ربع واحد، أعاد أكبر موردي نقل البيانات وتحويلها بناء أنفسهم حول هذه الحقيقة: اندماج Fivetran + dbt أطلق Agents Schema وفتح مصدر محرك dbt Fusion كـ dbt Core v2.0، واستحوذت Databricks على Electric لمنح كل وكيل قاعدة Postgres قابلة للتخلص خاصة به.

يبني هذا الدليل النمط في سياق مشتريات B2B: خط أنابيب يستوعب كتالوجات الموردين والأسعار والمخزون ويعرضها لوكيل RFQ. يغطي الطبقات الثلاث — Dagster للتنسيق المرتكز على الأصول، وdbt للتحويل المحوكم، ووحدة MCP لوصول وكيل محدد النطاق — والأنماط الوكيلية الثلاثة التي تجعل خط الأنابيب يصون نفسه. ستنتهي وأنت تعرف ما تسهم به كل طبقة، ولماذا يعد lineage الأصول الخيار الحامل، وأين يبقى الإنسان في الحلقة.

لماذا التنسيق المرتكز على الأصول هو الأساس

معظم إخفاقات التنسيق بالنسبة للوكلاء تبدأ بالنموذج الذهني الخاطئ. المجدولات المرتكزة على المهام (التصميم الكلاسيكي cron-plus-DAG) تجيب على «هل تم تشغيل هذه المهمة؟» أما الوكيل الذي يسأل «لماذا سعر Acme قديم؟» فيحتاج إجابة مختلفة: «أي أصل بيانات قديم، وعلى ماذا يعتمد، وماذا يغذيه؟» هذا سؤال عن الأصول، ولهذا فإن نموذج Dagster المرتكز على الأصول هو الأساس هنا لا مجرد تفضيل.

في Dagster، تُعرِّف الشيء الذي تنتجه — supplier_catalog، وnormalized_prices، وavailability_snapshot — وتبعياته. عندئذ يعرف المنسق رسم Lineage الكامل. تتيح Declarative Automation الخاصة بـ Dagster تحديث أصل عند تغير مصدره الأعلى بدلاً من وفق ساعة ثابتة، بحيث تصبح كلمة «قديم» خاصية يمكن للنظام التفكير فيها. رسم Lineage هذا هو بالضبط ما يحتاجه الوكيل لتتبع رقم خاطئ إلى مصدره دون تخمين.

import dagster as dg

@dg.asset(group_name="procurement")
def supplier_catalog(context: dg.AssetExecutionContext) -> dg.MaterializeResult:
    rows = fetch_supplier_feed()  # NetSuite, EDI, CSV drop, etc.
    write_bronze("supplier_catalog", rows)
    return dg.MaterializeResult(metadata={"row_count": len(rows)})

@dg.asset(deps=[supplier_catalog], group_name="procurement",
          automation_condition=dg.AutomationCondition.eager())
def normalized_prices() -> None:
    # dbt owns the transformation logic; Dagster owns the lineage + trigger
    run_dbt(select="normalized_prices")

deps وautomation_condition هما بيت القصيد: يمكن للوكيل (وحلقة الشفاء الذاتي أدناه) قراءة هذا الرسم كبيانات. توصلت Airflow إلى الاستنتاج ذاته من الجهة الأخرى — أضافت Airflow 3.2 موفر ذكاء اصطناعي مشتركًا وجدولة واعية بالأصول — والتوحيد حقيقي: استحوذت Prefect على Dagster في يوليو 2026. أيًا كان المنسق الذي توحّد عليه معاييرك، فالمتطلب واحد: أصول ذات lineage معلن، لا مهام مبهمة.

لماذا تمتلك dbt التحويل والسياق المحوكم

تُطلق Dagster العمل وتتبع lineage؛ ولا ينبغي أن تحتوي منطق أعمالك. هذا مكانه في dbt، حيث كل تحويل هو نموذج SQL خاضع للتحكم في الإصدارات مع اختبارات وتوثيق وتعريف دلالي مرفق. بالنسبة للوكلاء، هذا ليس رفاهية — إنه حد الثقة. موقف dbt نفسها هو أن طبقة التحويل هي ما يجعل خطوط الأنابيب الوكيلية جديرة بالثقة: وكيل يكتب SQL ضد جداول غير معرّفة وغير مختبرة يُؤتمت الفوضى بسرعة أكبر فحسب.

الإضافة الأهم بعد الاندماج هي Agents Schema: مخطط مستودع مخصص يخزن تعريفات المقاييس والنماذج الدلالية وlineage الخاص بـ dbt والتوثيق التجاري كجداول SQL عادية. بدلاً من أن يعيد كل وكيل اشتقاق معنى «التوفر في المخزون»، يعيش التعريف في مكان واحد محوكم ومملوك للعميل يقرأ منه الوكيل. إنه النظير الجانب-بياناتي لوحدة موصل محوكمة — مصدر واحد محدد بالسياسات للسياق المشترك بدلاً من نسخة لكل وكيل تنجرف بمرور الوقت.

-- models/marts/availability_snapshot.sql
select
    sku,
    warehouse_id,
    on_hand - allocated as available_qty,   -- the governed definition
    updated_at
from {{ ref('normalized_inventory') }}

-- schema.yml: the test that gates the agent's trust
-- - name: available_qty
--   tests: [not_null, {dbt_utils.accepted_range: {min_value: 0}}]

الاختبار الذي يفشل هو إشارة إلى أن الوكيل يجب ألا يقتبس سعرًا استنادًا إلى تلك الصف. وهذه الحقيقة الواحدة — نجاح/فشل قابل للقراءة آليًا لكل نموذج — هي ما يتيح للنمطين التاليين العمل دون أن يراقب إنسان كل خطوة.

أين يتصل الوكيل: وحدة MCP، لا تسجيل دخول لقاعدة بيانات

يجب ألا يحمل الوكيل أبدًا بيانات اعتماد خام للمستودع. بل ينبغي أن يستدعي وحدة MCP محوكمة تعرض مجموعة صغيرة من الأدوات المكتوبة — get_availability(sku, warehouse)، وget_tier_price(sku, customer_tier)، وlist_substitutes(sku) — كل منها مرتبط بنموذج dbt مختبر وكل منها يحمل نطاق سياسة وحدود معدل وتسجيل تدقيق. هذا نفس نمط الوحدات المستخدم لموصلات ERP والتجارة، مطبقًا على مخرجات خط الأنابيب نفسها. يبقي نطاق الانفجار صغيرًا: يمكن للوكيل قراءة availability_snapshot لكن لا يمكنه تشغيل SQL عشوائي، وكل استدعاء مُسجَّل.

هذا الحد هو أيضًا حيث تناسب الحالة الخاصة بكل وكيل. استحواذ Databricks على Electric — WASM Postgres (PGlite) داخل صندوق حماية الوكيل، متزامن مع حالة مركزية محوكمة — موجود لأن الوكلاء «يحتاجون آلاف قواعد البيانات الصغيرة القابلة للتخلص» لسياق العمل، مفصولة عن الجداول الدائمة المحوكمة. القاعدة العامة: البيانات الدائمة والمشتركة والمحوكمة تعيش خلف وحدة MCP؛ والسياق المؤقت السريع لكل تشغيل يعيش في صندوق حماية الوكيل الخاص.

الأنماط الوكيلية الثلاثة التي تتيحها هذه الحزمة

مع وجود lineage (Dagster) وتعريفات مختبرة وسياق مشترك (dbt + Agents Schema) ووصول محدد النطاق (MCP)، تصبح ثلاثة أنماط عملية:

• التطوير الوكيلي. يؤسس الوكلاء أصولًا وتحويلات جديدة — يصوغون نموذج dbt، ويقترحون اختبار المخطط، ويوصلون أصل Dagster — مقابل رسم lineage القائم. تطلق Dagster dagster-io/skills لـ Claude Code وCodex ومساعد Compass على Slack؛ وتعرض Bruin خادم MCP لنفس الغرض. يراجع الإنسان طلب سحب (pull request)، لا ملفًا فارغًا.
• خطوط الأنابيب الشافية ذاتيًا. عندما يفشل اختبار مخطط أو يتعطل أصل أعلى، يقرأ الوكيل lineage، ويعزل النموذج الفاشل، ويقترح إصلاحًا، ثم إما يطبقه في تشغيل تجريبي (canary) أو يقدم طلب سحب. لأن Dagster يعرف رسم التبعيات وdbt يعرف أي اختبار فشل، يكون الإصلاح واعيًا بـ lineage بدلاً من إعادة محاولة عمياء.
• حل المشكلات الوكيلي. عند الفشل، يقرأ الوكيل سجلات التشغيل والبيانات الوصفية ويستجيب في Slack أو Teams بالسبب المحتمل وإصلاح مقترح — النمط الذي بُني حوله Dagster Compass وSnowflake Cortex. يتحول تصحيح النظام أثناء المناوبة من قراءة لوحات البيانات إلى مراجعة تشخيص وكيل.

لا يزيل أي من هذه الإنسان. كل تغيير مطبق يمر عبر بوابة اختبار أو تشغيل تجريبي أو مراجعة — نفس الانضباط الذي وصفته كلمات افتتاح دبت سميت 2026 بأنه ثمن السماح للوكلاء بلمس بيانات الإنتاج.

الحزمة في لمحة واحدة

بناء تمثيلي

أراد موزع يشغّل NetSuite ومستودعين وثلاثة كتالوجات موردين وكيل RFQ يمكنه تقديم عروض أسعار دون أن يسحب إنسان التوفر يدويًا. كان خط الأنابيب هو العائق، لا النموذج. عرّفنا أصول الكتالوج والسعر والمخزون في Dagster مع lineage صريح؛ ونقلنا منطق التسعير والتوفر إلى نماذج dbt مختبرة مع Agents Schema يثبّت تعريف «متاح للوعد به»؛ وعرضنا ثلاث أدوات مكتوبة عبر وحدة MCP محددة بالقراءة فقط. حلقة الشفاء الذاتي تلتقط الآن تغذية مورد معطلة وتقدم طلب سحب بالإصلاح قبل تشغيل عروض الأسعار الصباحي؛ وانخفض وقت التصحيح أثناء المناوبة عند عطل خط الأنابيب لأن الاستجابة الأولى للوكيل تشخيص، لا تنبيه استدعاء. يقدم الوكيل عروض أسعار استنادًا إلى بيانات مختبرة أو يرفض ذلك — فهو لا يقتبس سعرًا استنادًا إلى صف فشل اختباره أبدًا.

قراءات ذات صلة

• أعطال خط الأنابيب المتسلسلة: كيف يقلل وكيل تصحيح النظام بنسبة 75% — نمطا الشفاء الذاتي وحل المشكلات الوكيلي كحالة استخدام تشغيلية مع أرقام المناوبة
• معيار كود وحدة MCP — النمط البنيوي خلف وحدة MCP المحوكمة والمحددة بالسياسات التي تتقدم خط الأنابيب
• مراقبة وكلاء الذكاء الاصطناعي: ما لا تراه سيؤذيك — لماذا تُعد سجلات التشغيل وبيانات lineage الوصفية الركيزة التي يعتمد عليها حل المشكلات الوكيلي

بناء خط أنابيب منسق بوكلاء على حزمتك الخاصة — NetSuite، مستودع، تغذيات موردين — يبدأ بمعرفة الأصول الموجودة وأين تعيش تعريفاتها.

اطلب بناءً محدد النطاق. اكتشاف لمدة أسبوع واحد. تحصل على جرد للأنظمة، وخريطة لسير العمل، ونطاقًا ثابتًا — سواء بنيت معنا أم لا.