كيفية بناء مسارات عمل كلود المؤتمتة

هناك مقولة متداولة تلخص اتجاه الترميز القائم على الوكلاء: الهدف ليس موجهًا (prompt) أفضل، بل سير عمل يعمل بدون إشرافك. يستخدم معظم الناس كلود كما يستخدمون نافذة الدردشة. تكتب، تنتظر، تقرأ، ثم تكتب مرة أخرى. هذا يعمل، لكنه يحد من إنتاجيتك بوكيل واحد تشرف عليه بنشاط. قام المهندسون الذين يستفيدون حقًا من كلود ببناء شيء آخر: سير عمل يبدأ بناءً على جدول زمني أو محفز، ويقوم بالمهمة، ويتحقق من نتائجه الخاصة، ولا ينبه الإنسان إلا عندما يتطلب الأمر اتخاذ قرار.

خلاصة القول (TL;DR)

سير عمل كلود الذي يعمل بدون إشرافك يحتاج إلى خمسة أجزاء: مواصفات مكتوبة دقيقة، تنفيذ بدون واجهة مستخدم (غير تفاعلي)، بوابة تحقق حتمية تحدد النجاح أو الفشل، حواجز حماية صارمة (قوائم سماح الأذونات، تكرارات محدودة، حدود للتكلفة، مفتاح إيقاف)، وتسليم ينبه الإنسان أو يرفع مستوى المشكلة عند الفشل. يمنحك وضع كلود كود بدون واجهة مستخدم (`claude -p`)، وحزمة SDK لوكيل كلود، والخطاطيف (hooks)، ومجدول المهام (cron أو launchd) كل هذه الأجزاء الخمسة. الوكيل ليس الجزء المحفوف بالمخاطر. تشغيله بدون إشراف وبدون بوابة حماية وحواجز حماية هو كذلك. ابنِ تلك أولاً، ثم ارفع يديك.

لماذا "يعمل بدونك" هو الهدف الحقيقي

للدردشة تحت الإشراف سقف قاسٍ: أنت. كل تكرار ينتظر إنسانًا ليقرأ المخرجات ويقرر الخطوة التالية. يُنشئ النموذج في ثوانٍ، ثم يتوقف لدقائق بينما تنتقل أنت بين السياقات. أنت عنق الزجاجة في نظام سريع بخلاف ذلك.

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

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

الأجزاء الخمسة التي يحتاجها كل سير عمل غير مراقب

تجاهل أيًا من هذه، وسيقوم سير العمل إما بفعل الشيء الخاطئ بثقة أو لن يتوقف أبدًا.

1. مواصفات دقيقة. وصف مكتوب للعمل المنجز يقرأه الوكيل في بداية كل تشغيل. المواصفات الغامضة تنتج عملًا غامضًا. "إصلاح واجهة برمجة التطبيقات (API)" يفشل؛ بينما "نقطة النهاية POST /orders تعيد 201، وتتحقق من الجسم مقابل المخطط، وترفض الحقول المفقودة بـ 422" تنجح.
2. تنفيذ بدون واجهة مستخدم (Headless). يجب أن يعمل كلود بدون تدخل بشري عند لوحة المفاتيح. وهذا يعني الوضع غير التفاعلي، وليس واجهة المستخدم الخاصة بالدردشة.
3. بوابة تحقق. فحص حتمي يعيد النجاح أو الفشل مع سبب ملموس: اختبارات، فحص نوع، تحقق من المخطط، اختبار عقد. هذا هو ما يسمح لسير العمل بتحديد ما إذا كان قد تم بالفعل بدلاً من الاعتماد على كلام النموذج.
4. حواجز حماية. قوائم سماح الأذونات، وعدد تكرارات أقصى، وحد أقصى للتكلفة، وتسجيل الدخول، ومفتاح إيقاف. هذه تمنع التشغيل المربك من إحداث ضرر بينما أنت نائم.
5. تسليم. عندما ينتهي سير العمل أو يستسلم، فإنه يخبر شخصًا ما. إشعار، مسودة للمراجعة، تنبيه بالفشل. الصمت ليس نجاحًا.

الأجزاء الثلاثة الوسطى هي حيث تكون معظم الإعدادات ضعيفة. لنبنِ كل منها بالأدوات التي يوفرها كلود.

مكونات كلود الأساسية

وضع بدون واجهة مستخدم (headless mode) (claude -p)

يقوم وضع الطباعة (print mode) في كلود كود بتشغيل موجه (prompt) بشكل غير تفاعلي ثم يخرج. هذا هو أساس كل سير عمل غير مراقب. تسلمه مهمة، وتقيد أدواته، وتلتقط المخرجات، وتنتقل.

claude -p "Implement the orders endpoint per spec.md, then run the test suite" \
  --allowedTools "Edit,Write,Bash" \
  --output-format json \
  >> run.log 2>&1

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

حزمة SDK لوكيل كلود (Claude Agent SDK)

عندما لا يكون أمر shell كافيًا، تتيح لك حزمة SDK لوكيل كلود تشغيل كلود برمجيًا من Python أو TypeScript. تحصل على الحلقة في التعليمات البرمجية: ترسل مهمة، تبث النتيجة، تفحص استدعاءات الأدوات، تقرر ما إذا كنت ستستمر. هذه هي الطريقة التي تحيط بها الوكيل بسير تحكم حقيقي.

import { query } from "@anthropic-ai/claude-agent-sdk";

const MAX_ITERATIONS = 8;
let feedback = "";

for (let attempt = 0; attempt < MAX_ITERATIONS; attempt++) {
  for await (const msg of query({
    prompt: `${task}\n\nPrevious failures:\n${feedback}`,
    options: { allowedTools: ["Edit", "Write", "Bash"] },
  })) {
    // stream/log messages as the agent works
  }

  const gate = runVerification();      // your deterministic check
  if (gate.passed) break;              // done
  feedback = gate.failures;            // the next prompt writes itself
}

التوقيعات الدقيقة موجودة في الوثائق، لكن الشكل هو المهم: حلقة تعيد تشغيل الوكيل مع الفشل الأخير كموجه (prompt) تالٍ. إذا كنت تقرر بين بناء حلقتك الخاصة وخيار مستضاف، فإن مقارنتنا بين الوكلاء المدارين مقابل حزمة SDK للوكيل توضح متى يكون كل خيار منطقيًا.

الخطاطيف (Hooks) لحواجز الحماية الحتمية

تقوم الخطاطيف (Hooks) بتشغيل أوامرك الخاصة في نقاط ثابتة من دورة حياة كلود، بدون تدخل النموذج. إنها الطريقة التي تفرض بها قواعد لا يمكن للوكيل التحايل عليها. هل تريد تشغيل مجموعة الاختبار بعد كل تعديل ملف؟ يقوم خطاف `PostToolUse` بذلك بشكل حتمي.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npm test --silent" }]
      }
    ]
  }
}

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

مجدول مهام لتشغيل الدورات

سير العمل الذي يعمل بدونك يحتاج إلى شيء لبدئه بدونك. على الخادم يكون ذلك cron؛ على جهاز Mac يكون launchd. في كلتا الحالتين، تقوم بتشغيل الأمر بدون واجهة مستخدم (headless command) وفقًا لجدول زمني.

# كل يوم عمل في الساعة 7 صباحًا: تشغيل سير عمل الصيانة، وتسجيل كل شيء
0 7 * * 1-5  cd /srv/api && claude -p "$(cat tasks/nightly-maintenance.md)" \
  --allowedTools "Edit,Bash" >> logs/run-$(date +\%F).log 2>&1

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

صمم الحلقة، وليس الموجه (prompt)

إليك العقلية التي تربط كل ذلك معًا. توقف عن السؤال "ماذا يجب أن أخبر كلود؟" وابدأ بالسؤال "ما هي الحلقة التي ستجعل كلود يخبر نفسه؟" الوكيل هو مولد سريع ليس لديه إحساس موثوق بما إذا كان على صواب. توفر الحلقة هذا الإحساس من خلال البوابة. تعمقنا في هذا في توقف عن توجيه وكيل الترميز الخاص بك، ابنِ الحلقة بدلاً من ذلك، وهي الفكرة الأساسية للعمل غير المراقب: تتوقف ثقة النموذج عن الأهمية، فقط حكم البوابة هو المهم.

هذا هو السبب أيضًا في أن المواصفات الواضحة تتفوق على الموجه الذكي. نفس المواصفات تدفع كل تكرار وتعمل كوثائق. ملف design.md أو AGENTS.md الذي يلتقط القصد والقيود وتعريف الإنجاز يمنح الوكيل هدفًا مستقرًا في كل تشغيل، بدلاً من أن تعيد شرح السياق في كل مرة.

مثال عملي: صيانة واجهة برمجة تطبيقات (API) غير مراقبة

لنجعل الأمر ملموسًا. لنفترض أنك تريد سير عمل يحافظ على تزامن مجموعة من نقاط نهاية واجهة برمجة التطبيقات (API) مع مواصفات OpenAPI الخاصة بها، ويعمل كل صباح، ولا ينشر أبدًا نقطة نهاية معطلة. إليك الشكل.

1. المواصفات. يعيش العقد في ملف OpenAPI؛ ويعيش السلوك في حالات الاختبار. يقرأ الوكيل كلاهما في بداية التشغيل.
2. المحفز. يقوم تشغيل cron في الساعة 7 صباحًا بتشغيل كلود بدون واجهة مستخدم (headless Claude) مع مهمة الصيانة.
3. التوليد. يقوم الوكيل بتسوية التنفيذ مع المواصفات: يضيف نقاط النهاية المفقودة، ويصلح أشكال الاستجابة غير المتطابقة، ويشدد التحقق.
4. البوابة. يقوم سير العمل بتشغيل مجموعة اختبار API مقابل الخدمة قيد التشغيل. تأكيدات الحالة، التحقق من مخطط JSON على كل استجابة، فحوصات العقد مقابل المواصفات. تعود الأخطاء منظمة: "توقعنا 422 عند فقدان customer_id، حصلنا على 500." "حقل الاستجابة total هو سلسلة نصية، المخطط يقول رقم."
5. حلقة أو تصعيد. بوابة حمراء (فشل)؟ يصبح الفشل المنظم هو الموجه (prompt) التالي ويقوم الوكيل بتصحيح الثغرة المحددة، حتى حد التكرار. بوابة خضراء (نجاح)؟ يفتح طلب سحب (PR) مسودة. نفدت المحاولات؟ يرفع تنبيهًا بالخطأ الأخير ويتوقف.
6. تسليم. يحصل الإنسان إما على طلب سحب نظيف للمراجعة أو تقرير فشل دقيق. لا يوجد التزام صامت أبدًا.

البوابة في الخطوة 4 هي ما يجعل كل هذا آمنًا للتشغيل بدون إشراف. بدونها، يقوم الوكيل بتحرير التعليمات البرمجية ويبلغ عن النجاح بناءً على قراءته الخاصة، وهذا بالضبط كيف تصل نقاط النهاية المعطلة إلى الإنتاج. هنا يتناسب Apidog مع سير العمل المستقل: تصميم API، المخطط، الخادم الوهمي (mock server)، والاختبارات الآلية تعيش في مساحة عمل واحدة، لذا تبقى البوابة والمواصفات متزامنة بشكل افتراضي. توجه التشغيل إلى سيناريو اختبار Apidog ويحصل الوكيل على نجاح/فشل متحقق من المخطط في كل تكرار. يعمل الخادم الوهمي كبديل للاعتمادات غير النشطة، لذلك لا يتعطل تشغيل الساعة 3 صباحًا بانتظار طرف ثالث متذبذب. تتيح الفرق التي تربط وصول الوكيل إلى نقاط النهاية عبر مصمّم أخطاء وكيل Apidog AI للوكيل الوصول إلى نقاط النهاية وفحصها بنفس الطريقة التي يقوم بها المختبر البشري. حمل Apidog إذا كنت تفضل بناء البوابة بصريًا بدلاً من بناء مشغل يدويًا.

حواجز حماية تجعل التشغيل غير المراقب آمنًا

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

• قوائم سماح أذونات ضيقة. في الوضع بدون واجهة مستخدم (headless)، قائمة السماح هي بوابتك الوحيدة لما يمكن للوكيل فعله. امنح الحد الأدنى من الأدوات التي تحتاجها المهمة. لا تسلم أبدًا تشغيلًا غير مراقب لأوامر shell غير مقيدة أو أوامر مدمرة بدون صندوق حماية (sandbox).
• تكرارات محدودة. ضع حدًا للحلقة. يجب أن يتوقف التشغيل الذي لا يستطيع الوصول إلى بوابة خضراء في N محاولة ويرفع المشكلة، بدلاً من أن يستمر إلى الأبد.
• سقف للتكلفة. تحرق الحلقات غير المراقبة الرموز (tokens) دون أن يلاحظها الإنسان. حدد حدًا للإنفاق وسجل الإنفاق لكل تشغيل. يجب أن تتجاوز الحلقة التي لا تتقارب الحد وتتوقف. تنطبق ملاحظاتنا حول تقليل تكاليف رموز الوكيل مباشرة هنا.
• حماية البوابة. أبقِ ملفات الاختبار والمواصفات خارج مجموعة الملفات التي قد يقوم الوكيل بتعديلها. إذا كان بإمكانه إعادة كتابة الاختبار لتمريره، فقد بنيت آلة لتزييف التقدم.
• صندوق حماية (Sandbox). قم بتشغيل العمل غير المراقب في مساحة عمل معزولة أو حاوية، وليس على الفرع الرئيسي. يحتوي git worktree أو فرع يمكن التخلص منه على نطاق تأثير التشغيل السيئ.
• تسجيل ومفتاح إيقاف. سجل كل تشغيل في سجل تقرأه بالفعل، واحتفظ بطريقة لإيقاف مهمة في منتصف الطريق. لا يمكنك تصحيح ما لم تسجله.
• موافقة بشرية في الحدود. "بدونك" لا تعني "بدون أي أحد، أبدًا". ضع شخصًا في البداية (للموافقة على المهمة) أو في النهاية (للموافقة على طلب السحب)، ولكن ليس في الحلقة الداخلية. تتوافق أنماط التوصيل وأنماط الفشل هنا مع توصيل أدوات سير عمل الوكلاء.

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

أخطاء شائعة

بعض الأنماط تغرق سير العمل المستقل بسرعة.

• لا بوابة، مجرد انطباعات. إذا كان الفحص الوحيد هو "وكيل، هل انتهيت؟" فليس لديك سير عمل، بل لديك روبوت دردشة غير مراقب. يجب أن تكون البوابة خارجية عن الوكيل.
• مهمة عملاقة واحدة. التشغيل الذي يطلب "صيانة الخدمة بأكملها" نادرًا ما يتقارب. قسّم المهام إلى مهام بحجم نقاط النهاية، لكل منها بوابتها الخاصة. المهام الصغيرة تنتهي؛ المهام الكبيرة تتخبط.
• أذونات مفتوحة على مصراعيها. منح كل أداة لأنها مريحة يحول خطأً صغيرًا إلى حادث كبير عندما لا يراقب أحد. استخدم قائمة السماح (allowlist) بصرامة.
• نجاح صامت أو فشل صامت. سير العمل الذي يلتزم (commits) دون إخبار أحد، أو يموت دون تنبيه، أسوأ من عدم وجود سير عمل على الإطلاق. قم دائمًا بالتسليم.
• الثقة في تقارير النموذج الذاتية. سيقول الوكيل إنه انتهى. البوابة هي التي تقرر ما إذا كان قد انتهى أم لا. ابنِ لسد الفجوة بين "يبدو منتهيًا" و "منتهي بالفعل"، لأنه في العمل غير المراقب، لا يوجد أحد ليكتشف ذلك.

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

الخلاصة

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

ابدأ بسير عمل واحد. اكتب مواصفات دقيقة، شغله بدون واجهة مستخدم (headless) مقابل بوابة تحقق سريعة، اسمح بالأدوات (allowlist)، حدد التكرارات، اعزل مساحة العمل، واجعله يخطرك عند الانتهاء أو الفشل. لأي شيء يتعلق بواجهات برمجة التطبيقات (APIs)، فإن مجموعة اختباراتك هي البوابة التي تجعل التشغيل غير المراقب آمنًا، ويوفر لك Apidog التصميم، والمحاكاة، والاختبار الآلي في مساحة عمل واحدة لبنائه. حمله، اربط البوابة، ودع سير العمل يكمل دوراته بينما تقوم أنت بشيء آخر.