→ المدونةأدلة عملية

توقف وكيل الذكاء الاصطناعي في منتصف العمل، واللوحة ما زالت تقول قيد التنفيذ

مات وكيل الذكاء الاصطناعي عند 60 بالمئة، والتذكرة ما زالت تقول قيد التنفيذ. كيف تستأنف من حيث توقف الوكيل، وتمنع اللوحة من الكذب عليك.

The Taskfolk team

11 د قراءة13 مشاهدة

XLinkedIn

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

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

الساعة التي تضيعها في معرفة ما الذي فعله الوكيل أصلًا

تفتح فروق الكود (diff). ثم تحاول أن تتذكر أي الاختبارات قال إنه أجراها، وهل كان يعني بـ"أجرى" أنه نفّذها فعلًا أم توقّع نتيجتها. تتحقق هل طُبِّق الترحيل محليًا. تبحث عن طلب سحب. تقرأ آخر ثلاثة تعليقات على أمل أن يكون أحدها حالة، ثم تعود إلى الملفات.

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

النسخة الآلية من هذه الساعة قِيست فعلًا. ورقة صدرت في يونيو 2026 عن دَين التسليم بنت 181 نقطة تسليم من 75 مهمة برمجية، وسلّمت كل واحدة إلى ثلاثة نماذج. الملاحظات المنظَّمة، بدل المستودع وحده، خفضت وسيط أحداث الوكيل بنسبة 20 إلى 59 بالمئة، ورموز الطلب (tokens) بنسبة 42 إلى 63 بالمئة. وحدة القياس عندك دقائق لا رموز، لكن الشكل واحد: كلفة الاستلام معظمها إعادة اكتشاف.

وهذه المقالة عن الشق الآخر، شق الملكية: اللوحة تكذب وعلى أحدهم أن يصلحها. أما هل يستحق العمل الناقص أن يُبقى عليه، فذاك سؤال مراجعة.

هل مات، أم أنه صامت فحسب؟

في أول 30 دقيقة لا تستطيع التمييز، ونحن كذلك.

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

تحفّظ واحد: نبضة الحياة لا تتحرك إلا حين يلمس الوكيل الجلسة نفسها، بـPATCH أو بتقرير استخدام. أما التعليقات على المهمة فلا تُحتسب. فالوكيل الذي يثرثر على التذكرة ساعة كاملة دون أن يحدّث جلسته يظل يُقرأ متوقفًا.

وعند الساعتين، تحوّل مهمة دورية تعمل كل 15 دقيقة الجلسة الصامتة من running إلى cancelled وتختم وقت انتهائها، فتتوقف قوائم الجلسات وتجميعات الكلفة عن عدّها عملًا حيًا. ولا تُشعر أحدًا بذلك.

ثلاثون دقيقة أقصى ما نستطيع، لسبب بنيوي: ‏Taskfolk لا يشغّل وكيلك. يستطيع Linear أن يصف جلسة بأنها لا تستجيب بعد عشر ثوانٍ، لأنه هو من سلّم الـ webhook وهو يقيس رحلته الخاصة (توثيق Linear، مراجَع في يوليو 2026). أما نحن فنجلس عند الطرف البعيد من عملية تجري على جهاز لا نراه أبدًا، فلا دليل عندنا سوى نبضة غائبة. والتقاط التوقف وقت حدوثه هو موضوع المقالة السابقة لهذه.

قائمة الجلسات في Agent Hub داخل Taskfolk، وكل سطر يعرض الوكيل وحالة جلسته وآخر ملاحظة له

التشغيلة الميتة تترك كذبتين على اللوحة

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

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

هذا التفاوت هو المشكلة كلها. الجلسة تموت وفق جدولها الخاص. أما التذكرة فلا تموت أبدًا.

flowchart TD
    A["Agent process dies"] --> B["Session still says running"]
    B --> C["At 30 minutes it renders as stalled"]
    C --> D["At 2 hours the sweep cancels it"]
    A --> E["Work item still says In Progress"]
    E --> F["Work item still assigned to the agent"]
    F --> G["It moves only if a person or a rule moves it"]

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

الحلول المتداولة، ومن تفترض أنه سيقرأ

الحل ماذا يفترض أين تستقر الحالة
claude --resume أنك أنت من شغّله هنا ملف JSONL في مجلدك الشخصي
ملف HANDOFF.md في المستودع أن القارئ يصل إلى ذلك القرص الجهاز الذي شغّل الوكيل
تعليق على التذكرة أن أحدهم سيفتح المهمة غدًا أداة التتبع التي يقرؤها الفريق

claude --resume أداة جيدة فعلًا، لكنها للاعب واحد. البحث بمعرّف الجلسة محصور في مجلد المشروع الحالي وأشجار عمل git التابعة له، والتشغيلات التي بدأت بـclaude -p أو بـAgent SDK لا تظهر في المنتقي أصلًا، وإن كان بإمكانك استئناف واحدة بمعرّفها من المجلد الذي بدأت فيه (توثيق Claude Code، مراجَع في يوليو 2026). كل قيد من هذه يفترض أن من يستأنف العمل هو من شغّله.

وملف HANDOFF.md يعيش أطول من العملية. لكنه ما زال يفترض أن القارئ التالي يصل إلى القرص الذي كُتب عليه، وإن جرى التشغيل في CI أو في حاوية أُعيد تدويرها بعدها، فقد ذهب الملف معها. وأفضل صياغة لهذه القائمة هي قائمة تسليم الجلسة على hermes-agent.ai، وهي سبعة بنود: الهدف والحالة، مصدر الحقيقة، الملفات المتغيرة، الأوامر التي نُفِّذت ومخرجاتها، ثغرات التحقق، الافتراضات والمخاطر، الخطوة الآمنة التالية. البنود صحيحة. العنوان خطأ.

عقد الخروج، وأين يجب أن يهبط

غيّر شيئًا واحدًا في تلك البنود السبعة: هي دَين للتذكرة، لا لملف جانبي. ينشرها الوكيل تعليقًا على المهمة، عبر خادم MCP الرسمي أو /api/v1، بمفتاح API خاص به، فيحمل التعليق وأثره في سجل النشاط اسمه هو لا اسمك أنت. وسجل التدقيق يأتي مجانًا.

الشكل الذي تطلبه منه:

**Checkpoint 3.** Goal: theme cookie survives a hard refresh (WEB-142).
Done: token map, ThemeProvider, cookie write on toggle.
Not verified: auth suite has not run since the provider change.
Risk: SSR reads the cookie before hydration, untested in Safari.
Next: `npm test -- auth` on branch theme-cookie.
curl -X POST \
  "https://taskfolk.ai/api/v1/workspaces/acme/projects/WEB/issues/WEB-142/comments" \
  -H "Authorization: Bearer tfk_live_a1b2c3d4e5f6" \
  -H "Content-Type: application/json" \
  -d "$(jq -Rs '{body_md: .}' checkpoint.md)"
{
  "issue_key": "WEB-142",
  "author": {
    "email": "[email protected]",
    "name": "Codex Bot"
  }
}

أما الجلسة فتحمل النسخة القصيرة. ونداء PATCH هو نبضة الحياة، فالذي يقول "ما زلت حيًا" يحدّث الملاحظة في الوقت نفسه ويعلّق رابط طلب السحب على external_url. سقف الملاحظة 2000 حرف. أما السجل الحقيقي فسلسلة التعليقات.

PATCH /api/v1/workspaces/acme/agent-sessions/0198f2b7-9a44-7c31-8f10-2d4e6a8b1c05
Authorization: Bearer tfk_live_a1b2c3d4e5f6
Content-Type: application/json

{
  "state": "needs_input",
  "note": "Migration 0031 local only. Auth suite not run.",
  "external_url": "https://github.com/acme/web/pull/812"
}

ما لا نستطيعه هو إجبار وكيل على كتابة هذا. ‏Taskfolk يحفظ العقد ويضعه حيث ينظر الإنسان. أما تعبئته فمهمتك أنت: في AGENTS.md، أو في ملف المهارة، أو في الطلب نفسه.

مهمة في Taskfolk نقل فيها الوكيل Codex Bot الحالة وترك تعليقًا منسوبًا إليه في سجل النشاط

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

sequenceDiagram
    participant A as Agent
    participant T as Taskfolk
    participant H as Teammate
    A->>T: Checkpoint comment on the issue
    A->>T: Patch the session note and PR link
    A->>T: Move status and reassign to a person
    Note over A: Process dies
    H->>T: Opens the ticket
    T->>H: Last checkpoint, note, PR link

التوجيه: الحالة والمُسند إليه يتحركان معًا

أعمدة اللوحة تخص كل مشروع على حدة، وأنت من يسمّيها. وكل عمود يرتبط بواحدة من سبع فئات ثابتة: backlog، todo، in_progress، in_review، done، failed، cancelled. فيصير "بحاجة إلى إنسان" عمودًا حقيقيًا لا وسمًا يتظاهر بأنه عمود، وربطه بـin_progress يُبقي التقارير تعدّه عملًا مفتوحًا. والحالات المخصصة هي أيضًا الطريقة التي يسلّم بها وكيلان العمل لبعضهما.

نافذة إضافة حالة على لوحة Taskfolk، وفيها حقول اسم العمود وفئته ولونه

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

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

اختار Linear العكس، وفي هذا العطل تحديدًا اختياره أفضل. إسناد مهمة إلى وكيل في Linear يجعله مفوَّضًا ويبقي الإنسان مُسندًا إليه، فلا تغادر الملكية شخصًا أبدًا ولا شيء يحتاج إلى إرجاع حين تموت التشغيلة. الثمن مساءلة أضعف: وكيل لا يكون مُسندًا إليه أبدًا لا يملك شيئًا تمامًا. أما Jira وGitHub فذهبا في الاتجاه الآخر، وفي Jira تضيف الوكيل من حقل المُسند إليه (دعم Atlassian، مراجَع في يوليو 2026).

الأداة أين يجلس الوكيل حين تموت التشغيلة
Jira حقل المُسند إليه غير موثّق
GitHub Issues المُسند إليه، مع حالة حية queued/working/completed لا حالة موثّقة لتشغيلة ميتة
Linear مفوَّض، والإنسان يبقى المُسند إليه الجلسة تصير قديمة، والمُسند إليه لا يتغير
Taskfolk المُسند إليه، مع جلسة مسجّلة الجلسة تلغي نفسها عند الساعتين، والبطاقة لا تتحرك

ولا واحدة منها توثّق ماذا تعرض التذكرة حين لا تنتهي التشغيلة.

متحقَّق مقابل مُدَّعى، وأنت غائب

كنت في اجتماع، فرواية الوكيل هي الرواية الوحيدة التي بحوزتك. لا أداة تتبع تصلح هذا. وما نفعله نحن أضعف، ويستحق أن يُقال بدقة.

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

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

بطاقة نشاط وكيل تعرض جلسة منجزة تحمل شارة Unverified الوردية بجوار سجل التغييرات

تعليمة واحدة، وعمود واحد، وقاعدة واحدة

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

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

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

صفحة الأتمتة في Taskfolk وقواعدها معروضة صفوفًا من شرائح WHEN وIF وTHEN فوق وصفات جاهزة للبدء

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

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

أسئلة شائعة

ماذا ينبغي أن يكتب وكيل الذكاء الاصطناعي على التذكرة قبل أن يتوقف؟

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

هل ينقل الوكيل التذكرة خارج قيد التنفيذ، أم يفعل ذلك إنسان؟

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

كيف أعرف هل أجرى الوكيل فعلًا الاختبارات التي يقول إنه أجراها؟

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

هل يكفي ملف HANDOFF.md لفريق كامل؟

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

كم يبقى إسناد لم يلتقطه الوكيل قبل أن يُلغى؟

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

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

أضف تعليقًا

ابدأ النقاش.