باكلوج مشترك لفريق من وكلاء البرمجة بالذكاء الاصطناعي

بدأت بوكيل برمجة واحد وقائمة مهام بصيغة Markdown. الآن لديك ثلاثة وكلاء: ‏Claude Code يعمل على الواجهة الخلفية، وCursor يعيد هيكلة الواجهة، وCodex يلتهم حزمة الاختبارات، بينما تحولت القائمة نفسها بهدوء إلى عنق الزجاجة. وكيلان يعدلان ملف tasks.json نفسه في الثانية نفسها، فتفوز إحدى الكتابتين بصمت وتختفي الأخرى. لا تستطيع معرفة أي وكيل أغلق WEB-142، ولا إن كان أنجز العمل فعلًا أم اكتفى بوضع علامة الإنجاز. ولا أحد يراقب الحالات التي ينبغي أن يتدخل عندها إنسان.

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

لماذا تنهار قائمة المهام الملفية لحظة تشغيل وكيلين

قائمة المهام الملفية أداة جيدة بحق. ‏claude-task-master، وهي الأوسع استخدامًا، تخزن مهامك كملفات داخل مجلد .taskmaster/ في المشروع (وثيقة المتطلبات في .taskmaster/docs/prd.txt والمهام إلى جوارها)، لا في قاعدة بيانات ولا في خدمة مشتركة. هذا هو جوهر فكرتها، وهو قرار سليم لما صُممت له: ذكاء اصطناعي واحد، محرر واحد، مستودع واحد، ومهام تخضع لإدارة الإصدارات إلى جانب الكود. يذكر ملف README فيها أنها تتصل بـ Cursor وLovable وWindsurf وRoo وVS Code وClaude Code وAmazon Q CLI وغيرها عبر MCP. لوكيل يعمل وحده، هذا إعداد نظيف.

المشكلة ليست في الملف. المشكلة في الوكيل الثاني. ثلاثة أشياء تنكسر لحظة الانتقال إلى الجمع.

أولها الإسناد. يسجل الملف أن المهمة أُنجزت، لكنه لا يسجل أي وكيل أنجزها. حين يعمل وكيل واحد لا بأس، لأن الفاعل المحتمل واحد. أما حين يعمل ثلاثة، فكلمة "منجزة" بلا مؤلف معلومة لا تستطيع البناء عليها. أردت أن تعرف من أغلق WEB-142 لتطلب من ذلك الوكيل شرح منطقه، والملف عاجز عن إخبارك.

ثانيها التزامن. لا شيء في وثائق claude-task-master يذكر قفل ملفات أو أي ضبط للتزامن حول ملفات المهام. مع كاتب واحد لا تظهر المشكلة أبدًا. مع وكيلين يكتبان في الثانية نفسها، تهبط كتابة فوق الأخرى وتضيع الأولى. لا خطأ، لا علامة تعارض، لا إعادة محاولة. تنحرف القائمة بهدوء عن الواقع، وتكتشف ذلك لاحقًا حين يلتقط وكيل مهمة أنهاها وكيل آخر بالفعل.

ثالثها التسليم. لا يوجد إسناد ولا هوية لكل وكيل، فلا سبيل إلى قول "‏Claude Code يملك هذه المهمة، وسلّمها إلى Cursor حين تكتمل واجهة API". الملف يحوي مهام وحالات، لكنه لا يحوي فاعلين يتنقل العمل بينهم. وبحسب وثائقها، لا توجد حالة مراجعة أو موافقة بشرية قبل انتقال المهمة إلى "منجزة"، ولا مصادقة لكل مستخدم أو وكيل، ولا لوحة تحكم على الويب. فهي بالتصميم أداة تعمل من سطر الأوامر وMCP والمحرر.

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

ما الذي تبحث عنه في باكلوج مشترك لوكلاء الذكاء الاصطناعي

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

1. خادم مرجعي مشترك. مكان واحد يقرأ منه كل وكيل ويكتب فيه، لا نسخة من ملف في كل استنساخ. إذا عاشت الحالة داخل المستودع، صار لكل وكيل نسخته الخاصة، وصار "الباكلوج" تعارض دمج ينتظر وقوعه.
2. هوية لكل وكيل. كل تغيير موقّع باسم وكيل محدد، فتجيب "منجزة" دائمًا عن سؤال "على يد من؟".
3. الإسناد والتسليم. طريقة لنقل مهمة من وكيل إلى آخر بحيث يراها الطرفان.
4. حواجز حماية لكل وكيل. تحكم فيما يُسمح لكل وكيل بتغييره، حتى لا يعيد وكيل سريع في إعادة الهيكلة كتابة الأولويات أو إسناد العمل بصمت.
5. حالات تستدعي الإنسان. حالات تُشعر شخصًا في اللحظات التي يجب أن يقرر فيها إنسان، بدل الرهان على أن تلاحظ بنفسك.
6. رؤية الأسطول كاملًا. عرض واحد لما يفعله كل وكيل الآن، لأن ستة وكلاء يعملون في العتمة أسوأ من وكيل واحد.

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

ما تحتاجه	قائمة مهام ملفية	باكلوج مشترك للوكلاء
الخادم المرجعي	ملفات محلية في كل استنساخ	خادم مشترك واحد
هوية لكل وكيل	لا (تصميم أحادي الفاعل)	كل تغيير مُسند
الإسناد والتسليم	لا	إسناد وتسليم بين الوكلاء
حواجز حماية لكل وكيل	لا	صلاحيات حقول لكل وكيل
حالة مراجعة بشرية	لا	حالات مراجعة + إشعارات
رؤية الأسطول كاملًا	لا توجد لوحة تحكم	خريطة حية لكل وكيل
يعيش داخل المستودع	نعم	لا، يُوصل إليه عبر API/MCP

الوكلاء أعضاء حقيقيون، فكل تغيير مُسند

هكذا يجيب Taskfolk عن مشكلة الإسناد، وهي إجابة بنيوية لا مجرد ملصق فوق السطح.

وكيل البرمجة المتصل في Taskfolk عضو حقيقي في مساحة العمل. عمليًا، هذا يعني صف مستخدم وعضو مع is_agent=1، وملف تعريف في workspace_agents، ومفتاح API يشير حقله created_by إلى مستخدم الوكيل نفسه. هذه التفصيلة الأخيرة هي الآلية كلها. المفتاح ملك للوكيل، فكل كتابة يجريها المفتاح تُوقّع باسم ذلك الوكيل المحدد. لا توجد دفاتر منفصلة لتتبع "من فعل هذا" يجب إبقاؤها متزامنة، لأن الهوية التي تُجري التغيير هي الهوية المسجلة. قارن ذلك بالقائمة الملفية، حيث يسجل ملف المهام اكتمال المهمة دون الفاعل الذي يقف خلفها.

عند ربط وكيل، تختار نوعه من المزودين المدعومين: ‏Claude Code أو Codex أو Cursor أو Copilot أو Gemini CLI أو DeepSeek أو Kimi أو Perplexity، أو وكيل Custom عام لأي شيء آخر. هذا النوع يرافق ملف تعريف الوكيل، فتحمل قائمة الوكلاء وكل تغيير يجريه اسم الأداة الحقيقي، لا كلمة "bot" عامة.

نقطة صريحة تهم الفاتورة: الأعضاء الوكلاء مجانيون. عدّاد المقاعد في Taskfolk ‏(countEditorSeats) يقتصر على is_agent=0، فلا يضيف الوكلاء المتصلون شيئًا أبدًا إلى كمية المقاعد في Stripe. المشاهدون مجانيون وغير محسوبين أيضًا. مقاعد المنفّذين المدفوعة هي البشر في فريقك من مالكين ومشرفين وأعضاء. يمكنك تشغيل عشرة وكلاء والدفع عن الأشخاص الثلاثة الذين يشرفون عليهم. لا شيء في مبدأ "الوكلاء أعضاء حقيقيون" يتحول خلسة إلى "الوكلاء يُحاسبون كأعضاء حقيقيين".

بروتوكول التسليم عبر الحالات ينسّق الأسطول

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

توجد سبع حالات: pending وrunning وneeds_input وreview وdone وfailed وcancelled. دورة الحياة بسيطة: يبدأ الوكيل جلسة حين يلتقط جزءًا من العمل، ويرسل PATCH على الجلسة كنبض حياة وكتغيير حالة أثناء العمل، ثم ينهيها في حالة نهائية (done أو failed أو cancelled) مع رابط طلب السحب في external_url، فيسافر رابط المراجعة مع السجل بدل أن يضيع في محادثة.

التفويض يجعل التسليم مرئيًا قبل أن يبدأ الوكيل أصلًا. إسناد مهمة إلى وكيل ينشئ تلقائيًا جلسة pending، فلحظة تسليم WEB-142 إلى Cursor تظهر جلسة معلقة في المركز وعلى بطاقة المهمة. حالة pending ينشئها النظام وتسير باتجاه واحد: يخرج الوكيل منها (نداء startAgentSession هو ما يحجز العمل) ولا يدخل إليها أبدًا. وإذا لم يلتقط وكيل مهمة فُوّضت إليه، يلغي عامل الخلفية الجلسة المعلقة بعد سبعة أيام، فتنظف التسليمات الراكدة نفسها بنفسها بدل أن تبقى إلى الأبد.

الحيوية تُستنتج ولا تُؤخذ على الثقة. جلسة running بلا نبض حياة لمدة 30 دقيقة تُعرض على أنها متوقفة. يُحسب ذلك عند القراءة ولا يُخزن أبدًا، فالوكيل المنهار الذي توقف عن إرسال النبضات يظهر متوقفًا من تلقاء نفسه دون أن يعلّمه أحد. كما يدفع Taskfolk العمل إلى الوكلاء بدل أن يجبرهم على الاستطلاع المتكرر: لكل وكيل تدفق SSE حي (الموضوع agent:<userId>)، وقاعدة أتمتة notify_agent يمكنها إيقاظ وكيل محدد حين تدخل بطاقة عمودًا معينًا. انقل تذكرة إلى "جاهز للاختبارات" فيصل التنبيه إلى Codex عبر تدفق أحداثه.

flowchart LR
  A[Human assigns issue to agent] --> B[pending session auto-created]
  B --> C[Agent claims: running]
  C --> D[Heartbeat PATCH keeps it alive]
  D --> E{Outcome}
  E -->|needs a human| F[needs_input]
  E -->|ready to check| G[review]
  E -->|shipped PR| H[done]
  E -->|broke| I[failed]
  F --> C
  G --> C

والآن الحدود الصريحة، لأن كلمة "بروتوكول" ثقيلة وهذا الشيء ليس ثقيلًا. بروتوكول التسليم عبر الحالات في Taskfolk يعني أن الوكلاء ينسّقون من خلال حالة المهمة المشتركة والإسناد وحالات الجلسات وقواعد notify_agent. إنه ليس بروتوكول تفاوض مخصصًا يتجادل فيه الوكلاء على من يأخذ ماذا. فئات الحالة الثابتة هي العمود الفقري ذو القيم السبع، وأعمدتك المخصصة تُبنى فوقه. والتنسيق يعيش في طبقة المهام فقط: يتتبع Taskfolk من يملك أي مهمة وفي أي حالة كل جلسة، لكنه لا يقفل فروع git الفعلية للوكلاء ولا يدمجها. ذلك يبقى في نظام إدارة الإصدارات لديك، حيث ينبغي له تمامًا. هذا يحل "أي وكيل يعمل على ماذا وأين يُسلَّم العمل"، لا "حلّ تعارض الدمج بين فرع Claude Code وفرع Cursor".

صلاحيات الحقول لكل وكيل تُبقي الوكيل السريع في مساره

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

يرسم Taskfolk ذلك الخط لكل وكيل على حدة. يمكن أن يحمل ملف تعريف كل وكيل field_policy_json، وهي قائمة سماح تغطي 14 رمزًا من حقول المهمة:

‏title وdescription وstatus وpriority وassignee وlabels وmilestone وsprint وrelease وestimate وspent وcompletion وstart_at وdue_at.

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

سبب صمود هذا الضبط أن الإنفاذ يحدث عند نقطة اختناق واحدة. كل كتابة عبر API على مهمة تمر من updateIssueViaApi، الذي يغطي REST ونقطة نهاية الانتقالات وMCP، إضافة إلى نقطة نهاية تتبع الوقت المخصصة. لا يوجد باب جانبي يستطيع الوكيل من خلاله كتابة حقل تمنعه السياسة على مسار دون آخر. موضع البطاقة على اللوحة (rank) وأعمدة السجلات الداخلية لا تُقيد أبدًا، لأن منع وكيل الفرز من إعادة ترتيب البطاقات ليس هدف الميزة.

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

حالات المراجعة وشارة "غير موثّق" تُبقيان البشر في موقع التحكم

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

الأولى حالات المراجعة مع الإشعارات. حين تدخل جلسة needs_input أو review أو done أو failed، يوزع Taskfolk إشعارًا داخل التطبيق على البشر المعنيين: مالك الوكيل، والمُبلّغ عن المهمة، والمُسند إليه، والمراقبون. فتُستدعى بالضبط عند الحالات الأربع التي يحتاج فيها شخص إلى التصرف، سواء كان وكيلًا عالقًا يطرح سؤالًا، أو وكيلًا جاهزًا للمراجعة، أو وكيلًا يدّعي الإكمال، أو وكيلًا تعطّل. لست مضطرًا إلى تحديث اللوحة على أمل التقاط اللحظة؛ اللحظة تأتي إليك.

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

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

شاهد الأسطول كاملًا على خريطة الوكلاء

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

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

كيف يقود الوكلاء الباكلوج عبر MCP أو REST

هذا هو الجزء العملي، للقارئ الذي يريد أن يعرف بالضبط كيف يخاطب الوكيل هذا النظام.

يشحن Taskfolk خادم MCP رسميًا، وأدواته مولّدة من سجل OpenAPI نفسه الذي يعرّف مسارات REST في الإصدار v1. هذه التفصيلة هي ما يُبقي الاثنين صادقين: يحصل الوكلاء على قدرات متطابقة سواء تحدثوا MCP أو REST، لأن كليهما مشتق من مواصفة واحدة. المصادقة للبشر بالرابط السحري (بلا كلمات مرور)، أما الوكلاء فيصادقون بمفاتيح API.

النداء الرئيسي هو بدء جلسة، وهو الطريقة التي يقول بها الوكيل "التقطت WEB-12". إنه POST إلى /v1/workspaces/{slug}/agent-sessions مع عنوان ومفتاح مهمة اختياري. النداء نفسه بثلاث طرق:

curl -X POST https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions \
  -H "Authorization: Bearer $TASKFOLK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"Refactor auth middleware","issue_key":"WEB-12"}'

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.TASKFOLK_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      title: "Refactor auth middleware",
      issue_key: "WEB-12",
    }),
  },
);
const session = await res.json();

import os, requests

res = requests.post(
    "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions",
    headers={"Authorization": f"Bearer {os.environ['TASKFOLK_API_KEY']}"},
    json={"title": "Refactor auth middleware", "issue_key": "WEB-12"},
)
session = res.json()

والاستجابة هي مورد الجلسة:

{
  "id": "0192f8c2-7a3e-7b21-9e44-2c1d5f6a8b90",
  "agent_id": "0192f8b0-1c2d-7e3f-8a90-b1c2d3e4f5a6",
  "agent_name": "Claude Code",
  "agent_kind": "claude",
  "state": "running",
  "title": "Refactor auth middleware",
  "note": null,
  "external_url": null,
  "issue_id": "0192f8b4-5d6e-7f80-9a1b-2c3d4e5f6a7b",
  "issue_key": "WEB-12",
  "started_at": "2026-07-16T09:12:44.000Z",
  "last_activity_at": "2026-07-16T09:12:44.000Z",
  "ended_at": null
}

من هناك، نبض الحياة والتسليم نقطة نهاية واحدة: ‏PATCH /v1/workspaces/{slug}/agent-sessions/{id} مع قيمة state الجديدة، وعند شحن العمل، ضبط external_url على رابط طلب السحب. كل PATCH يحدّث last_activity_at (وهذا ما يمنع الجلسة من الظهور متوقفة)، والانتقال إلى حالة نهائية يختم ended_at.

المقارنة الصادقة، ومتى تبقى على القائمة الملفية

هذه هي المصفوفة المنصفة. كل ما يخص البدائل مأخوذ من وثائق علنية، والأسعار كما هي في يوليو 2026.

	claude-task-master	TaskPeace	Taskfolk
أين تعيش المهام	ملفات في .taskmaster/	خدمة مبنية على MCP	باكلوج مستضاف عبر MCP + REST
الترخيص / الكلفة	MIT + Commons Clause، بلا رسوم ترخيص	مستوى مجاني؛ Pro بـ 10 دولارات شهريًا	Free بـ 0 دولار؛ Pro بـ 3 دولارات للمقعد شهريًا؛ Business بـ 6 دولارات للمقعد شهريًا
كلفة النموذج	تحضر مفتاح API بنفسك (تدفع ثمن النموذج)	بحسب صفحتها	الباكلوج غير محاسَب بالنموذج
الإسناد لكل وكيل	لا	غير موثّق	نعم (الوكلاء أعضاء)
الإسناد + التسليم	لا	غير موثّق	آلة حالات للجلسات
صلاحيات لكل وكيل	لا	غير موثّق	سياسة حقول تغطي 14 رمزًا
قفل الملفات / التزامن	ليس في الوثائق	غير موثّق	خادم مشترك (لا سباق ملفات)
حالة مراجعة بشرية	لا	غير موثّق	حالات مراجعة + شارة "غير موثّق"
لوحة تحكم على الويب	لا (CLI/MCP/محرر)	غير موثّق	لوحة + خريطة وكلاء حية
الوكلاء كمقاعد مدفوعة	لا ينطبق	غير موثّق	لا، الوكلاء مجانيون

بضعة أمور تستحق قراءتها بوضوح من ذلك الجدول. ‏claude-task-master بلا رسوم ترخيص، لكنه يتطلب إحضار مفتاح API لمزود ذكاء اصطناعي خاص بك (Anthropic أو OpenAI أو Google Gemini أو Perplexity أو xAI أو ما شابه)، فكلفتك الحقيقية هي ما يتقاضاه النموذج الأساسي. ‏Claude Code هو الاستثناء، إذ يستخدم نسختك المحلية بلا مفتاح منفصل. ‏TaskPeace يقع في الخانة نفسها، "مدير مهام لوكلاء البرمجة بالذكاء الاصطناعي مبني على MCP"، وهو نقطة بيانات منصفة هنا (مستوى مجاني، وPro بـ 10 دولارات شهريًا بحسب صفحته في يوليو 2026)، لكنني لم أتحقق من آلياته الداخلية متعددة الوكلاء فلن أدّعيها. على جانب Taskfolk، خطة Free مكتملة الميزات: السبرنتات والجدول الزمني والتكاملات والتقارير ورصيد الذكاء الاصطناعي كلها متاحة على Free، والسقف هو السعة لا الميزات (128 MB مساحة تخزين، 5 مشاريع نشطة، قاعدتا أتمتة، 25 وحدة رصيد ذكاء اصطناعي شهريًا). ما بعد ذلك من أتمتة، والأدوار، وSSO، وسجل التدقيق هي الإضافات المدفوعة. الوكلاء مجانيون على كل المستويات.

والآن الجزء المنصف حقًا، لأنني لا أريدك أن تشتري خادمًا لا تحتاجه. ابقَ على القائمة الملفية حين تشغّل وكيلًا واحدًا، في مستودع واحد، وكل شيء داخل المحرر، وتريد مهامك خاضعة لإدارة الإصدارات في المستودع بجانب الكود مباشرة. في ذلك العالم، القائمة الملفية أبسط، وتعيش حيث يعيش الكود، ولا خادم تصل إليه ولا حساب تحمله. ليست لديك مشكلة تزامن لأن الكاتب واحد، ولا مشكلة إسناد لأن الفاعل واحد، ولا تحتاج التسليم لأنه لا أحد تسلّم إليه. ‏claude-task-master مناسب تمامًا لذلك الشكل، وإضافة خادم مشترك ستكون عبئًا لن تستخدمه.

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

إن كنت قد تجاوزت ذلك الخط بالفعل، فربط وكلائك هو الجزء السريع. وجّه Claude Code وCursor وCodex إلى مساحة عمل Taskfolk واحدة، وامنح كلًا منهم مفتاح API وسياسة حقول، ودع حالات الجلسات تتولى التنسيق.

وللآليات الأعمق، تشرح هذه المقالات القطع واحدة تلو الأخرى: تنسيق وكيلين عبر التسليم بحالات المهام، وإدارة فريق من وكلاء الذكاء الاصطناعي، وضبط صلاحيات الحقول لكل وكيل، ورسم خريطة فريق الوكلاء، وإدارة المهام مع Claude Code.