وكلاء الذكاء الاصطناعي في Claude: مسار مراجعة عملي للإعدادات

في 3 سبتمبر 2026، حصل Claude Managed Agents على تغيير تشغيلي عملي: أصبح بإمكان ant apply تحويل ملفات المستودع إلى موارد حية تشمل وكلاء الذكاء الاصطناعي والبيئات والمهارات ومخازن الذاكرة وعمليات النشر. أما التحول الأهم، فهو أن إعداد الوكلاء بات يمر بالمراجعة نفسها التي تمر بها الشيفرة قبل وصوله إلى بيئة الإنتاج.

ما الذي تغيّر في وكلاء الذكاء الاصطناعي؟ حالة قابلة للمراجعة، لا اختصار CLI آخر

Claude Managed Agents هو نظام الوكلاء المستضاف من Anthropic والمخصص للأعمال طويلة المدة وغير المتزامنة. يحدد الوكيل النموذج والتعليمات والأدوات والمهارات، وتحدد البيئة مكان تشغيله، فيما تتيح عملية النشر تشغيله وفق جدول زمني.

وهذا يختلف عن وكيل فرعي في Claude Code محفوظ داخل .claude/agents/. فالتغيير هنا يخص الموارد التي تقف خلف خدمة الوكلاء المُدارين ضمن Claude API.

عندما ينشئ الفريق هذه الموارد عبر Console أو من خلال استدعاءات API منفردة، تتوزع الحالة المهمة بين مكانين: تحتفظ الخدمة البعيدة بالمورد الفعلي، بينما يشرح سكربت أو مستند أو ذاكرة أحد الزملاء كيف وصل المورد إلى حالته الحالية. وعند تسليم المسؤولية، لا بد من إعادة وصل الجانبين.

يضع ant apply هذه المهمة على عاتق المستودع. تصف الموارد بصيغة Markdown أو YAML أو JSON، ثم تقارن أداة CLI الملفات بالموارد البعيدة، وتعرض خطة، وتطلب الموافقة، وبعدها تطبق التغيير.

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

هذا دليل عملي للفرق التي تدرس بالفعل استخدام Managed Agents. أما إذا كان استخدامك مقتصرًا على تطبيق Claude أو Claude Code أو حلقة خاصة مبنية على Messages API، فلن يغير ant apply إعدادك الحالي.

ملف القفل هو مفتاح تسليم المسؤولية

الملف المهم ليس تعريف الوكيل وحده، بل claude-lock.json أيضًا.

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

يسجل ملف القفل مصدر API والمؤسسة ومساحة العمل والمعرّف البعيد الذي أُنشئ من كل ملف محلي. كما يخزن بصمة محلية وأخرى بعيدة؛ تكشف الأولى تغيّر الملف، بينما تكشف الثانية أن شخصًا عدّل المورد عبر Console أو مسار API آخر.

يمكن النظر إليه كدفتر عناوين مرفق بإيصال. يوضح ملف المورد ما تريده، بينما يحدد ملف القفل الكائن الحي الذي يملكه ذلك الملف، وما كانت عليه حالتا الطرفين بعد آخر عملية تطبيق.

وهنا يصبح تسليم المسؤولية أوضح. لن يحتاج المشغّل التالي أو منفّذ CI إلى تخمين معرّف الوكيل المرتبط بـ agents/reviewer.md؛ إذ يقرأ الربط ويحدّث المورد نفسه بدلًا من إنشاء نسخة أخرى.

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

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

الجدوى الاقتصادية هنا هي تكلفة تسليم المسؤولية

لا يجعل ant apply عمل الوكلاء مجانيًا؛ بل ينقل بند التكلفة من مكان إلى آخر.

البند القديم هو تكرار أعمال الإعداد والتحقق وتسليم المسؤولية. أما الجديد، فهو تجهيز المستودع، ومراجعة طلبات السحب، وتحديد ملكية CI، وصيانة ملف القفل. ويتوقف انخفاض التكلفة على وتيرة تغيّر الإعداد وعدد الأماكن التي يجب أن يصل إليها التغيير نفسه.

فيما يلي مثال موضح، وليس اختبار أداء ولا ادعاءً من Anthropic بشأن التوفير.

لنفترض أن فريقًا يجري أربعة تغييرات في الإعداد شهريًا عبر ثلاث بيئات مستهدفة، وأن كل تسليم يدوي يستغرق 15 دقيقة لكل تغيير في كل بيئة.

يصبح العمل اليدوي الشهري:

4 changes × 3 environments × 15 minutes = 180 minutes

ولنفترض الآن أن مسار المستودع يحتاج إلى 30 دقيقة لمراجعة كل تغيير، إضافة إلى 10 دقائق لتطبيقه والتحقق منه في كل بيئة.

يصبح العمل الشهري عبر المستودع:

4 changes × (30 review minutes + 3 × 10 apply minutes) = 240 minutes

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

تقع نقطة التعادل عند 20 دقيقة لكل تسليم يدوي، قبل احتساب الإعداد والصيانة. وإذا استغرق التسليم اليدوي المقاس 30 دقيقة، يرتفع المسار اليدوي نفسه إلى 360 دقيقة، بينما يبقى مسار المستودع عند 240 دقيقة. الفارق هو 120 دقيقة، لكنه يظل مجرد نتيجة في جدول حسابات إلى أن يقيس الفريق العمل الفعلي.

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

من يستفيد من سير العمل هذا؟

فريق المنصة يحصل على واجهة مراجعة واحدة

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

العائد هنا هو قابلية التتبع؛ إذ يمكن للفريق الربط بين تغيير دُمج وبين خطة الموارد وحالة ملف القفل التي نتجت عنه.

الوكالة تحصل على تسليم أوضح للعميل

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

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

فريق العمليات يحصل على خطوة نشر محددة

يستطيع قائد العمليات معاينة التغيير داخل طلب سحب، ثم تطبيق المجلد المدمج على الفرع الافتراضي باستخدام ant apply --yes .. والنقطة الأخيرة مهمة، لأن تشغيل Apply من دونها لا يطابق إلا الموارد المتتبعة مسبقًا في ملف القفل، وقد يفوّت ملفًا أُضيف حديثًا.

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

مسؤول الأمن يحصل على حاجز أمام الانحراف

يستطيع مسؤول الأمن استخدام البصمة البعيدة لإظهار أي تعديل تم عبر Console قبل أن تستبدله حالة المستودع. ويوقف Apply التنفيذ عندما يتعرض مورد مُدار للتعديل أو الأرشفة أو الحذف من خارج الملفات.

العائد هو فرض قرار صريح: إما فحص التغيير البعيد وتسويته، وإما استخدام --force لاستبداله عن قصد. أما الفرق التي تشترط Zero Data Retention أو تغطية HIPAA Business Associate Agreement، فعليها انتظار Managed Agents نفسه، لأن الخدمة غير مؤهلة حاليًا لأي منهما.

الحد الأدنى لمستودع يمكنك تطبيقه

يتطلب ant apply إصدار CLI 1.30.0 أو أحدث. ويوثّق دليل البدء السريع الرسمي التثبيت عبر Homebrew وتسجيل الدخول من خلال المتصفح.

1. 1

   ثبّت الأداة وسجّل الدخول

   ثبّت CLI، وتحقق من الإصدار، ثم سجّل الدخول:

   brew install anthropics/tap/ant
   ant --version
   ant auth login

2. 2

   أنشئ ملفًا لوكيل واحد

   أنشئ agents/summarizer.md بالتعريف الأدنى الموثق:

   ---
   name: Summarizer
   model: claude-opus-5
   tools:
     - type: agent_toolset_20260401
   ---
   
   You are a helpful assistant that writes concise summaries.

3. 3

   طبّقه مرة واحدة من جذر المستودع

   شغّل أمر الملف الواحد الموثق:

   ant apply agents/summarizer.md

   راجع الخطة، واطلب التفاصيل إذا احتجت إلى الفروق حقلًا بحقل، ثم وافق عليها. سينشئ التشغيل الناجح الوكيل البعيد ويكتب claude-lock.json بجوار مشروعك.

4. 4

   افصل المعاينة عن التطبيق في مهمتين

   استخدم أمر المعاينة الموثق في طلبات السحب:

   ant apply --dry-run .

   بعد الدمج، اجعل مهام النشر متسلسلة وطبّق المجلد المحدد:

   ant apply --yes .

   أضف ملف القفل المحدّث إلى الالتزام في النهاية، حتى بعد فشل جزئي في Apply، لأن التشغيل الجزئي قد يكون أنشأ موارد بالفعل وسجّلها.

انتبه إلى رمز الخروج في CI

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

استخدم Workload Identity Federation في مهمة التطبيق بدلًا من مفتاح API مخزن. واربط المهمة بالمؤسسة ومساحة العمل المسجلتين في ملف القفل، ولا تسمح بأكثر من عملية تطبيق واحدة في الوقت نفسه.

الحدود التي يجب قولها بوضوح

لا تعني إدارة الملفات بصفتها شيفرة أن كل مورد بعيد أصبح قابلًا للإدارة.

لا يستطيع ant apply تبنّي وكيل أُنشئ بصورة مستقلة في Console أو باستخدام ant beta:agents create. وإذا كانت الملفات وملف القفل ناتجة من خيار Export as code في Console، فيمكن لـ Apply تحديث تلك الموارد المصدّرة. خلاف ذلك، يؤدي تطبيق ملف مطابق إلى إنشاء مورد آخر.

الحذف متحفظ أيضًا. فإزالة ملف تُبقي المورد البعيد في مكانه وتعرض تحذيرًا. يحذف --prune المورد البعيد، بينما تُعرّف إعادة تسمية ملف موردًا جديدًا وتترك القديم إلى أن تحذفه باستخدام Prune.

لذلك يُعد كل من --force و--prune عنصر تحكم في الإنتاج، لا أداة مريحة للتنظيف. ضع كليهما خلف المراجعة؛ إذ قد تؤدي إعادة تسمية خاطئة يتبعها Prune تلقائي إلى حذف المورد الذي لا تزال عملية النشر تعتمد عليه.

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

وأخيرًا، لا تزال هذه خدمة تجريبية. يُفعّل Claude Managed Agents افتراضيًا لحسابات Claude API، لكن الفرق التي تتطلب Zero Data Retention أو HIPAA BAA تواجه عائقًا على مستوى المنتج لن تحله مراجعة المستودع.

ما الذي ينبغي فعله يوم الاثنين؟

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

انتظر إذا كان مشغّل واحد يدير تجربة مستقرة، أو إذا كانت تكلفة التسليم المقاسة أقل من تكلفة المراجعة الجديدة، أو إذا كانت سياسة البيانات لديك تفرض Zero Data Retention أو تغطية HIPAA BAA.

لن تتأثر إذا كان وكلاؤك يعملون فقط عبر Claude Code أو تطبيق Claude أو حلقة مخصصة تستخدم Messages API من دون موارد Claude Managed Agents.

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

احصل على التحليل العملي التالي لسير عمل الذكاء الاصطناعي عبر النشرة البريدية.