نقطة
الكتابات/blog/2026/07
● Blog10 يوليو 2026·6 دقيقة

مشروع Think: بيئة تشغيل وكلاء الذكاء الاصطناعي المستدامة من Cloudflare

مشروع Think من Cloudflare يحوّل وكلاء الذكاء الاصطناعي إلى بنية تحتية مستدامة: ألياف تنجو من الأعطال، ووكلاء يسبتون بلا تكلفة، وتنفيذ كود معزول بالكامل.

AI Bot
AI Bot
Author
·EN · FR · AR
تصور تجريدي لبيئة تشغيل موزّعة لوكلاء مستدامين مع مسارات تنفيذ محفوظة بنقاط تفتيش

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

جواب Cloudflare، الذي أُعلن باسم مشروع Think في 15 أبريل 2026 وتوسّع خلال أسبوع الوكلاء (Agents Week)، هو التوقف عن معاملة الوكلاء كتطبيقات والبدء بمعاملتهم كبنية تحتية. الوعد: وكلاء ينجون من الأعطال، ولا يكلّفون شيئًا وهم خاملون، ويفرضون الأمان عبر المعمارية لا عبر حسن السلوك.

هذا تحوّل مهم، ويستحق أن نفهم ما هو جديد فعلًا وما هو مجرد إعادة تغليف.

مشكلة نموذج العملية

السحابة التي بين أيدينا صُمّمت حول افتراض بسيط: تطبيق واحد يخدم مستخدمين كثيرين. خادم الويب يعالج آلاف الطلبات المتزامنة لأن كل طلب قصير وعديم الحالة وقابل للتبديل.

الوكلاء يكسرون كل جزء من هذا الافتراض.

جلسة الوكيل طويلة — استدعاء نموذج لغوي واحد يستغرق نحو 30 ثانية، وحلقة وكيل متعددة الأدوار قد تعمل لساعات. وهي ذات حالة — الوكيل يراكم الذاكرة ونتائج الأدوات وسجل المحادثة، ولا يمكن إعادة بناء ذلك من الطلب التالي. وهي لكل مستخدم — فإن شغّل كل موظف معرفي ثلاثة أو أربعة وكلاء، فعلى البنية التحتية أن تستوعب عشرات الملايين من الجلسات المتزامنة، لا عشرات الملايين من الطلبات المتتابعة.

الحل الساذج هو حاوية لكل وكيل. وهو أيضًا الحل المكلف. فإن كان لديك 10,000 وكيل وكل واحد نشط فعليًا 1% من الوقت، فأنت تدفع ثمن 10,000 حاوية دائمة التشغيل لتؤدي عمل 100.

الألياف: التنفيذ المستدام كبنية لغوية أولية

الفكرة التقنية المركزية في مشروع Think هي الليف (fiber) — استدعاء مستدام يسجّل تقدّمه بنقاط تفتيش في قاعدة بيانات SQLite مجاورة له.

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

async startResearch(topic: string) {
  void this.runFiber("research", async (ctx) => {
    const findings = [];
    for (let i = 0; i < 10; i++) {
      const result = await this.callLLM(`Research step ${i}: ${topic}`);
      findings.push(result);
      ctx.stash({ findings, step: i, topic });
      this.broadcast({ type: "progress", step: i });
    }
    return { findings };
  });
}

استدعاء ctx.stash() هو الحيلة كلها. فكل دورة تكتب الحالة المتراكمة إلى SQLite قبل المضي قدمًا. وإن طُرد العامل عند الخطوة السابعة، فإن خطّاف onFiberRecovered يعيد إحياء الوكيل وتستمر الحلقة من الخطوة السابعة — لا من الصفر، ولا بإعادة تشغيل سبعة استدعاءات مكلفة للنموذج.

إن سبق أن استخدمت Temporal أو Inngest فسيبدو هذا مألوفًا، وهذا هو المقصود. الفارق هو أين يسكن. Temporal يمنحك التنفيذ المستدام كخدمة تستدعيها من الخارج. مشروع Think يمنحك إياه كدالة على الصنف الذي يرث منه وكيلك أصلًا، ومخزن نقاط التفتيش يجلس في العزلة ذاتها التي تحوي ذاكرة الوكيل. تناولنا المنسّقات المستقلة في التنفيذ المستدام لوكلاء الذكاء الاصطناعي؛ ومشروع Think هو الفكرة نفسها مطويّة داخل بيئة التشغيل.

السبات واقتصاديات الخمول

كل وكيل Think هو Durable Object — بنية Cloudflare الأولية للفاعل (actor)، حيث لكل نسخة هوية ثابتة، وقاعدة بيانات SQLite خاصة بها، وقدرة على الاستيقاظ عند وصول رسالة.

النتيجة أن الوكيل المنتظر لخطّاف ويب أو موافقة بشرية أو نبضة مجدولة لا يعمل. إنه يسبت: حالته محفوظة، وعنوانه صالح، ولا يستهلك أي حوسبة. وصياغة Cloudflare للحساب هي أن 10,000 وكيل نشط كلٌّ منهم 1% من الوقت يحتاجون نحو 100 نسخة نشطة، لا 10,000.

لمن راقب فاتورة حاويات الوكلاء الخاملة، هذا هو الرقم الذي يهم أكثر من أي معيار أداء. فهو يحوّل استضافة الوكلاء من مسألة تخطيط سعة إلى مسألة فوترة استخدام.

وكلاء فرعيون بعزل حقيقي

الأنظمة متعددة الوكلاء تتفكك عادةً إلى مشرف وبعض العمّال. والتنفيذ المعتاد يتشارك عملية واحدة ومساحة ذاكرة واحدة، ما يعني أن «العزل» بين الوكلاء مجرد اصطلاح تسمية.

يستخدم مشروع Think أوجه Durable Object (Facets) بحيث يكون كل وكيل ابن كائنًا مستدامًا منفصلًا فعلًا بقاعدة بيانات SQLite خاصة، يُخاطَب عبر RPC مُنمَّط تتحقق منه TypeScript وقت الترجمة.

const researcher = await this.subAgent(ResearchAgent, "research");
const reviewer = await this.subAgent(ReviewAgent, "review");
const [research, review] = await Promise.all([
  researcher.search(task),
  reviewer.analyze(task)
]);

يترتب على ذلك أمران. أولًا، لا يستطيع وكيل فرعي أن يقرأ حالة شقيقه بالخطأ، لأنه لا يوجد مخزن مشترك ليقرأ منه — وهذا جواب حقيقي على أعطال تسرّب السياق التي ناقشناها في تماسك الوكلاء على المدى الطويل. ثانيًا، سطح RPC واجهة مُنمَّطة، فعقد الوكيل الفرعي يفرضه المترجم لا انضباط التلقين.

سُلّم التنفيذ

الوكلاء الذين يكتبون كودهم ويشغّلونه هم الأكثر نفعًا والأكثر خطرًا. ويبني مشروع Think ذلك على هيئة سُلّم تنفيذ من خمس درجات، من الدرجة صفر (مساحة العمل — عمليات نظام ملفات بسيطة) مرورًا بالدرجة الأولى (العمّال الديناميكيون — عزلات V8 جديدة) وصولًا إلى الدرجة الرابعة (الصناديق الرملية — وصول كامل لنظام التشغيل مع صدفة وعمليات خلفية).

يستحق نموذج الأمان تسمية دقيقة، لأنه يقلب النموذج المعتاد. فالعمّال الديناميكيون يبدأون بلا أي سلطة محيطة، ولا ينالون القدرات إلا عبر روابط صريحة. أنت لا تُحكم إغلاق آلة عامة الأغراض؛ أنت تسلّم صندوقًا مقفلًا المفاتيح التي يحتاجها بالضبط.

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

الجلسات والذاكرة وميزانية الرموز

تُخزَّن المحادثات في Think على هيئة أشجار، لا قوائم. فالرسائل تحمل مراجع لأصولها، ما يعني أنك تستطيع تفريع محادثة لتجريب اتجاه مختلف دون تدمير الفرع الأصلي.

والذاكرة تُعلَن بدل أن تُقلَّم يدويًا:

configureSession(session: Session) {
  return session
    .withContext("memory", {
      description: "Important facts learned during conversation.",
      maxTokens: 2000
    })
    .withCachedPrompt();
}

ميزانية maxTokens هي التفصيل المهم. فكتل السياق تُضغط لتلائم الحد، وتدعم الجلسات بحث FTS5 النصي الكامل، فيستطيع الوكيل استرجاع معلومة قديمة دون حمل السجل كاملًا في تلقينه. هذه هي المعمارية ذاتها التي أوصينا بها في ذاكرة الوكلاء المستمرة، لكن بيئة التشغيل توفّرها الآن بدل تجميعها يدويًا.

البداية العملية

أصغر وكيل Think صالح للعمل صغير فعلًا. ثبّت الحزم:

npm install @cloudflare/think @cloudflare/ai-chat agents ai @cloudflare/shell zod workers-ai-provider

ثم ورّث الصنف الأساس وزوّده بنموذج. هذه هي الدالة الوحيدة المطلوبة — إذ يتولى Think بروتوكول محادثة WebSocket، وحفظ الرسائل، وحلقة الوكيل، وتنقية الرسائل، واستئناف البث، وأدوات ملفات مساحة العمل:

import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";
 
export class MyAgent extends Think<Env> {
  getModel() {
    return createWorkersAI({ binding: this.env.AI })(
      "@cf/moonshotai/kimi-k2.6",
    );
  }
}

ثم اربط الـ Durable Object وهجرة SQLite في wrangler.jsonc:

{
  "compatibility_date": "2026-07-10",
  "compatibility_flags": ["nodejs_compat"],
  "ai": { "binding": "AI" },
  "durable_objects": {
    "bindings": [
      { "class_name": "MyAgent", "name": "MyAgent" }
    ]
  },
  "migrations": [
    { "new_sqlite_classes": ["MyAgent"], "tag": "v1" }
  ]
}

تُقبل الأدوار عبر runTurn() في واحد من ثلاثة أنماط. استخدم "wait" حين ينتظر المستدعي نتيجة، و"submit" للعمل المستدام «أطلق وانسَ» مع مفتاح عدم تكرار، و"stream" حين تريد دفع الأحداث إلى دالة رد نداء:

const result = await this.runTurn({ input: "Your prompt" });
 
const submission = await this.runTurn({
  mode: "submit",
  input: "Process webhook",
  idempotencyKey: eventId
});

نمط "submit" مع مفتاح عدم التكرار هو ما تلجأ إليه حين يُشغَّل الوكيل بخطّاف ويب. فإعادة التسليم لن تبدأ دورًا ثانيًا.

موقع Think في الحزمة

في 17 يونيو 2026 نشرت Cloudflare متابعة أوضحت فيها الطبقات، وهي أوضح بيان للاستراتيجية حتى الآن. المنصّة الآن ثلاث طبقات صراحةً:

Agents SDK هو بيئة التشغيل — الحوسبة والحالة والتخزين وبنى الألياف الأولية. وفوقه يجلس الحامل (harness) الذي يدير حلقة الوكيل والأدوات والسياق؛ ومشروع Think هو حامل Cloudflare الرأيوي الخاص، وPi حامل آخر. وفوق ذلك يجلس إطار العمل لتجربة المطور والتكاملات؛ وأول إطار خارجي هو Flue، وهو إطار مفتوح المصدر من فريق Astro يأتي بتكاملات Slack وGitHub وLinear وDiscord إضافة إلى خطاطيف React عبر @flue/react.

هذا الترتيب مهم لأنه يعني أن Cloudflare لا تراهن حصرًا على تبنّي المطورين لـ Think. بل تفتح البنى المستدامة تحته لأي حامل، وهذا موقع أفضل بكثير من إطار وحيد ينافس LangGraph وحزمة Claude Agent SDK على الأناقة وحدها.

حدود ينبغي قولها بصراحة

مشروع Think في معاينة تجريبية. سطح الواجهة سيتغيّر، وبناء نظام إنتاجي على بنى معاينة قرارٌ لا وضع افتراضي.

والارتباط بالمزوّد حقيقي وينبغي تسعيره. فالألياف والأوجه والعمّال الديناميكيون خاصون بـ Cloudflare على نحو لا ينطبق على تطبيق LangGraph أو Pydantic AI. لا توجد قصة قابلية نقل ذات معنى هنا — أنت تختار معمارية، وتكلفة الخروج إعادة كتابة.

أخيرًا، نموذج الفاعل يكافئ شكلًا معيّنًا من المسائل. فالوكلاء الطويلو العمر، الخاملون غالبًا، لكل مستخدم، وذوو الحالة، ينطبقون على Durable Objects انطباقًا جميلًا. أما خط تصنيف قصير عديم الحالة وعالي الإنتاجية فلا، والأفضل له عامل عادي أو مهمة دفعية.

الخلاصة

الادعاء المثير في مشروع Think ليس أي بنية أولية بمفردها. فالتنفيذ المستدام موجود في غيره. والعزل الرملي موجود في غيره. والذاكرة المستمرة موجودة في غيره.

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

وهل تستطيع Cloudflare الحفاظ على هذا الموقع مع تكتّل الأُطر فوقه؟ ذلك هو السؤال المفتوح. لكن الاتجاه صحيح، وهو أوضح صياغة حتى الآن لما يُفترض أن يعنيه «الوكلاء كبنية تحتية».

تبني وكلاء للإنتاج؟ نقطة تساعد فرق منطقة الشرق الأوسط وشمال أفريقيا على تصميم ونشر وحوكمة بنية تحتية لوكلاء الذكاء الاصطناعي تصمد أمام المستخدمين الحقيقيين. تحدّث مع فريقنا.

المصادر