العودة إلى المكتبة
المعمارية

المستودع يحصل على سطح تحكّم للوكلاء: الأداتان thinking_effort وstage_mounts من Snowflake وAgents Schema من dbt

بقلم آخر تحديث: 2026年10月29日

في 28 أكتوبر 2026، أصدرت Snowflake ثلاثة ضوابط جديدة على واجهة agent:run في Cortex Agents: thinking_effort وinstructions.system وstage_mounts (ملاحظات إصدار Snowflake). بيئة تشغيل المستودع تكشف الآن عن الأشياء الثلاثة التي كانت منصات الوكلاء تحتكرها تقليديًا لنفسها — مدى تفكير النموذج، وقواعد المنشأة التي تفرضها بيئة التشغيل، وأي المقتنيات المُحكمة بالإصدارات يمكن للوكيل تثبيتها. وفي الشهر نفسه، أكملت Fivetran وdbt Labs اندماجهما «لخلق البنية التحتية للبيانات لعملاء ذكاء اصطناعي موثوقين»، وتحمل المنصة المدمجة Agents Schema التي تمنح الوكلاء سياقًا أصيلًا من المستودع بدلًا من الاستخراجات العابرة (البيان الصحفي لـ Fivetran).

هذا المقال يرسم أسطح التحكم الثلاثة من Snowflake، وطبقة السياق التي تصل بجانبها، والحدّ الذي لا تغلقه: الموافقات والسياسة عبر الأدوات وخط التدقيق تبقى مع طبقة التنسيق فوق المستودع. لفريق نحيف — حساب Snowflake واحد، ومطوّرَان بـ dbt، ووكلاء بدأوا في تنفيذ أعمال مجدولة — هذه أول الأدوات التي يمكنك ضبطها داخل المستودع نفسه، وتمييز ما تقيّده وما لا تقيّده هو الخط الفاصل بين الحوكمة والمسرح.

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

  • أصدرت Snowflake ثلاثة ضوابط للوكلاء في 28 أكتوبر 2026 — thinking_effort (من minimal إلى xhigh، مجموعات فرعية لكل نموذج) وinstructions.system (تعليمات نظام تُلحق داخل بيئة التشغيل) وstage_mounts (تثبيتات stage مُحكمة بالإصدارات) على واجهة agent:run في Cortex (ملاحظات إصدار Snowflake).
  • stage_mounts يربط المقتنيات بالإصدار لا بالفرع — دفاتر الملاحظات وتطبيقات Streamlit ومساحات العمل والوكلاء أنفسهم تُثبَّت كـ stage مُحكمة بالإصدارات؛ أما workspace_mounts القابلة للكتابة فتبقى دون تغيير على الإصدار live (ملاحظات إصدار Snowflake).
  • اندماج dbt وFivetran المكتمل يُطلق Agents Schema — الغرض المعلن للمنصة المدمجة هو «البنية التحتية للبيانات لوكلاء ذكاء اصطناعي موثوقين»، فيضع صفوف سياق محوكمة في المكان الذي يستهلكها فيه الوكلاء (البيان الصحفي لـ Fivetran).
  • مشاركة البيانات بين dbt × Amazon Redshift (وثّقتها dbt في 9 أكتوبر وAWS في مدونة البيانات الضخمة) تُشغّل خطوط أنابيب متعددة العناقيد دون تحريف بايت واحد — أسهم محوكمة مع واجهات SVV_* للبيانات الوصفية وإعداد datasharing تحل محل النسخ بعد الاستخراج (مدونة dbt؛ مدونة البيانات الضخمة في AWS).
  • الأدوات تقيّد الجهد والتعليمات والتثبيتات — لا السياسة — الموافقات والإبطال والتدقيق عبر المستودع وNetSuite وHubSpot وبقية مدى الوكيل تبقى مع طبقة التنسيق.

ما صدر في 28 أكتوبر، وأين يجلس كل ضابط

thinking_effort هو أداة جهد التفكير: مدى من minimal إلى xhigh، مع مجموعات فرعية لكل نموذج تقيّد القيم التي يقبلها نموذج معيّن. عمليًا، إنها الاستدعاء الذي ينقل جهد النموذج من قيمة افتراضية على جانب الواجهة إلى إعداد لكل تشغيل يسجّله المستودع. الوكيل المجدول الذي يقرأ جدول الطزاجة لا يحتاج ميزانية الجهد نفسها لمن يطابق بنود الفواتير؛ قبل 28 أكتوبر كان هذا التمييز يسكن في الإطار الذي يستدعي النموذج، والآن ينفّذه المستودع كمعامل معلَن للتشغيل.

instructions.system يُلحق تعليمات النظام داخل بيئة التشغيل. هذا هو خانة سياسة المنشأة: قواعد التشغيل التي تريد مؤسستك إلحاقها بكل تشغيل للوكيل — ما يمكن للوكيل تلخيصه، وما يجب عليه رفعه إلى إنسان، وكيف يتعامل مع السياق المفقود — تسافر مع الاستدعاء بدلًا من أن تسكن في قالب توجيه يصونه من بنى الوكيل. علامة الصدق مهمة هنا: التعليمات المُلحقة ليست نظام صلاحيات. فهي تشكّل السلوك داخل بيئة التشغيل؛ ولا تُبطل شيئًا.

stage_mounts هو حدّ المقتنيات. واجهة agent:run تقبل الآن تثبيتات stage مُحكمة بالإصدارات — دفاتر الملاحظات وتطبيقات Streamlit ومساحات العمل والوكلاء أنفسهم — بينما تبقى workspace_mounts القابلة للكتابة دون تغيير على الإصدار live. الوكيل المربوط بـ stage مُحكمة بالإصدارات يرى مجموعة مقتنيات مثبّتة عليها، لا أيّ شيء على الفرع في تلك اللحظة. هذا هو الحسّ نفسه وراء تثبيت خطوط الأنابيب وتثبيت البيان في مواضع أخرى من حزمة الوكلاء، معبَّرًا عنه عند حدّ المستودع حيث تعيش المقتنيات فعلًا.

المخطط أدناه يقابل أسطح التحكم الثلاثة بالطبقات فوقها وتحتها — طبقة التنسيق حيث تبقى السياسة، وطبقتا السياق والحركة القادمتان أسفلها.

المستودع يحصل على سطح تحكّم للوكلاء ضوابط agent:run من Snowflake في 28 أكتوبر، وAgents Schema من dbt، وأين تبقى السياسة السياسة — المنسّق الجهد · التعليمات · التثبيتات — المستودع السياق — Agents Schema الحركة — أسهم محوكمة عبر الأنظمة طبقة تنسيق الوكلاء حيث تبقى الموافقات والإبطال وخط التدقيق عبر الأدوات MCP · A2A موطن السياسة الموافقات · الإبطال · التدقيق عبر الأدوات مُعلَن في بيان وحدات المنسّق — لا في المستودع 2 بيئة تشغيل وكلاء المستودع — Snowflake Cortex ثلاثة ضوابط صدرت في 28 أكتوبر 2026 على واجهة agent:run Oct 28, 2026 الضابط 1 · الجهد thinking_effort minimal ← xhigh، مجموعات فرعية لكل نموذج الضابط 2 · سياسة المنشأة instructions.system تعليمات نظام تُلحق في الاستدعاء الضابط 3 · حدّ المقتنيات stage_mounts — stage مُحكمة بالإصدارات دفاتر ملاحظات · تطبيقات Streamlit · مساحات عمل · وكلاء — workspace_mounts قابلة للكتابة على الإصدار live 3 طبقة السياق — dbt Agents Schema سياق أصيل من المستودع لعملاء الوكلاء، تحت اندماج Fivetran + dbt Fivetran + dbt السياق صفوف سياق محوكمة بدلًا من الاستخراجات العابرة الغرض المعلن للاندماج: «البنية التحتية للبيانات لوكلاء ذكاء اصطناعي موثوقين» 4 حركة بيانات محوكمة — مشاركة البيانات dbt × Redshift خطوط أنابيب متعددة العناقيد دون تحريف بايت — وُثّقت في 9 أكتوبر (dbt) و14 أكتوبر (AWS) Oct 9 · Oct 14 الحركة أسهم محوكمة، لا استخراجات واجهات SVV_* للبيانات الوصفية + إعداد datasharing — بيئة الوكيل تُجمَّع من الأسهم 5 أنظمة وراء المستودع كل حدّ يعبره الوكيل يحمل ضوابطه الخاصة ERP · CRM المدى عبر الأنظمة NetSuite · HubSpot · Shopify خط تدقيق واحد عبر كل أداة يلمسها الوكيل — السياسة تبقى مع المنسّق Oct 28 Snowflake تُصدر الجهد · التعليمات · التثبيتات Oct 9 مشاركة البيانات dbt × Redshift — صفر بايت منقول 4 4 أنواع من stage تُثبَّت مُحكمة بالإصدارات — الإصدار live أعلن الأدوات في بيان المنسّق الموافقات والإبطال والتدقيق عبر الأدوات تبقى فوق المستودع المستودع لم يعد مجرد مخزن بيانات — ideabosque.com/library

طبقة السياق وصلت أولًا

الضوابط لا تعني شيئًا إلا في مقابل شيء ما، وذاك الشيء وصل أولًا من جهة السياق. أكملت Fivetran وdbt Labs اندماجهما بأطروحة صريحة: الشركة المدمجة موجودة لتبني «البنية التحتية للبيانات لعملاء ذكاء اصطناعي موثوقين» (البيان الصحفي لـ Fivetran). وAgents Schema يحمل تلك الأطروحة إلى المستودع — صفوف محوكمة ومهيكلة يستهلكها الوكيل كما تستهلك لوحة القياس جدول المقاييس، لا الاستخراج العابر الذي يجمّعه الوكيل بالتجربة والخطأ على نقطة نهاية SQL.

وسؤال الحركة نال المعاملة ذاتها. تدعم dbt الآن مشاركة بيانات Amazon Redshift، ووثّقت مدونة البيانات الضخمة في AWS النمط متعدد العناقيد — واجهات SVV_* للبيانات الوصفية وإعداد datasharing يبنيان خطوط أنابيب متعددة العناقيد دون نسخ بايت واحد (مدونة dbt؛ مدونة البيانات الضخمة في AWS). بالنسبة للوكيل، هذا هو الفرق بين بيئة تُجمَّع من أسهم محوكمة — حيث يصمد lineage وقواعد الوصول — وبيئة تُجمَّع من استخراجات، حيث كل نسخة سؤال وصول جديد. وإعادة تموضع Dagster حول الأطروحة ذاتها («Data your team trusts. AI that runs on it.») تقول الشيء نفسه من جهة المنسّق في السياج (Dagster).

والمقروءة معًا، تشكّل الأسطح الثلاثة نمطًا واحدًا: السياق يُحكم حيث يُهيكل، والحركة تُحكم حيث تُشارَك، والجهد والتعليمات والتثبيتات تُحكم حيث يقع التشغيل. هذه إجابة «المستودع أولًا» على سؤال كانت منصات الوكلاء تجيب عنه برمز مخصص لكل منها.

ما الذي تتركه الأدوات مفتوحًا

ما لا تقيّده الضوابط هو السياسة عبر الأنظمة. الوكيل الذي يقرأ نماذج تسعير المستودع، ويفحص مخزون BigCommerce، ويكتب عروض الأسعار المعتمدة عائدًا إلى NetSuite يعبر ثلاثة حدود للموردين وحدًّا واحدًا للبروتوكول. معاملات Snowflake تحكم واحدة من تلك الحدود بالضبط؛ لا شيء في ملاحظات الإصدار يُبطل رمز BigCommerce، ولا شيء في instructions.system ينشئ سجل تدقيق في NetSuite. الموافقات والإبطال وخط التدقيق الوحيد عبر الأدوات لا بد أن يسكنوا طبقة التنسيق — نمط الوحدات الذي يغلّف كل نظام كأدوات مُنمَّطة بتحقق وتسجيل خاصين بها (معيار كود وحدات MCP).

وهناك حد صادق يجب قوله بوضوح: ملاحظات الإصدار توثّق معاملات، لا ضمانات. سلوك التدقيق لاستدعاءات agent:run — ما يُسجَّل وما يُحتفَظ به وما يُستعلم عنه — ليس أمرًا تحدده الملاحظات التي راجعناها، ودعم المجموعات الفرعية لكل نموذج يعني أن xhigh لفريق ما هو الإعداد غير المتاح لفريق آخر. عامل الضوابط الثلاثة كمدخلات معلنة، وتحقق من خط التدقيق على حسابك، وأبقِ مفتاح الإيقاف فوق المستودع (قائمة مراجعة حوكمة الذكاء الاصطناعي).

قراءة لفريق نحيف

للمنصة متوسطة السوق التي بدأت بتشغيل أوائل وكلائها المجدولين على المستودع، يغيّر 28 أكتوبر حديث الانطلاق في خمسة مواضع. اجرد الوكلاء الذين يلمسون المستودع أصلًا — المجدولون أولًا. اضبط thinking_effort بوعي لكل عبء عمل: فحص الطزاجة على minimal، والمطابقة بجهد أعلى، وسجّل أي مهمة حصلت على أي ميزانية — لأن هذا المسار هو قصّة تشغيلك للكلفة المفصلة. ضع سياسة المنشأة في instructions.system مرة واحدة بدلًا من صيانتها عبر كل قالب توجيه. اربط الوكلاء المجدولين بتثبيتات stage مُحكمة بالإصدارات، ليكون لوح Streamlit الذي يقرأه الوكيل هو الإصدار الذي اختبره أحد، لا الذي تغيّر صباح اليوم. واحفظ الموافقات والإبطال في بيان المنسّق — المستودع يتحكم بشكله التشغيل؛ والمنسّق يتحكم بما يُسمح للتشغيل فعله وما يتركه خلفه.

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

موزّع معدات يضم 400 موظف، بحساب Snowflake واحد ومطوّرَين بـ dbt، كان يوصّل وكيل عروض الأسعار بنماذج التسعير التي يحكمها المستودع. وحدة منسّقة أعلنت الضوابط الثلاثة لـ Snowflake — جهد مُموَّل لكل عبء عمل، وسياسة منشأة تُلحق في كل تشغيل، وتثبيتات stage مُحكمة بالإصدارات للمقتنيات التي يقرأها الوكيل — بينما بقيت الموافقات والإبطال وخط التدقيق عبر الأدوات في البيان فوق المستودع. أصبحت كلفة وكيل عروض الأسعار قابلة للإسناد لكل مهمة، ولم تعد بيئة بياناته تنجرف مع الفرع.

اطلب بناءً بنطاق محدد

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

هل تريد هذا مبنياً لأنظمتك؟

كل وثيقة هنا من عمل إنتاجي حقيقي. إذا كان لديك نظام مُستهدَف وسير عمل في الذهن، نستطيع تحديد نطاق بناء في أسبوع واحد.

اطلب بناءً محدد النطاق

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