ماذا فعل وكيل الذكاء الاصطناعي الخاص بي؟ أربعة أسئلة تجيب عنها بالدليل

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

نحن من يصنع Weft. والمعلومات عن المنتجات الأخرى مأخوذة من صفحاتها الرسمية، وقد راجعناها في 27 أكتوبر 2026.

لماذا لا يكفي تعليق يقول «تم»؟

التعليق هو الوكيل يصف عمله بنفسه. قد يكون دقيقًا تمامًا، لكن التعليق لا يستطيع إثبات ذلك، لأن كاتبه هو الطرف الذي تحاول التحقق منه. ومعرفة أن وكيلًا لمس مهمة تجيب عن سؤال «من». لكنها لا تجيب عمّا إذا كان العمل هو ما تظنه.

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

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

ما الأسئلة الأربعة؟

اختر أي مهمة أنهاها وكيل الأسبوع الماضي. ينبغي أن تستطيع الإجابة عن كل واحد من هذه الأسئلة في أقل من دقيقة دون أن تسأل الوكيل أو تفتح محادثته:

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

كيف أعرف أي وكيل نفّذها؟

يتصل Weft بعملاء الذكاء الاصطناعي عبر بروتوكول Model Context Protocol على نقطة نهاية واحدة، https://letsweft.com/api/mcp. وكل عميل OAuth وكل رمز وصول شخصي فاعل مستقل. وتسجّل المهمة أي عميل أنشأها، وتُظهر اللوحة الاسم الذي سجّل به ذلك العميل عند تسجيل الدخول، مع أيقونة. وكل حدث في سجل المهمة يحفظ هل جاء من شخص أم عبر MCP، وأي عميل أرسله.

ويُظهر السجل الكامل (get_task_history في وضع full) معرّف العميل الخام لكل حدث: معرّف عميل OAuth، أو mcp-token متبوعًا بمعرّف الرمز. ليس اسمًا ودودًا، لكنه دقيق، ويفصل بين اتصالين حتى حين يأتيان من المنتج نفسه.

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

قاعدة عملية واحدة: أعطِ كل أداة اتصالها الخاص. فإن تقاسم عميلان رمز وصول واحدًا، رأت اللوحة فاعلًا واحدًا، وفقد سؤال «من» جوابه.

ما الذي تغيّر، وهل أستطيع التحقق منه دون سؤال الوكيل؟

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

• outcome: حتى 1,000 حرف عمّا أُنجز وأين توجد النتيجة.
• artifacts: حتى 20 مدخلًا، لكل منها نوع (url أو file أو message أو commit وغيرها)، وموضع، واختياريًا بصمة sha256.
• claims: ما يؤكد الوكيل أنه فعله، ويُحفظ ادّعاءاتٍ لا حقائق متحقَّقًا منها.
• notDone وunknowns: في القسم التالي.
• nextStep: ما سيفعله الوكيل بعد ذلك إن قبلت.

complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

سطر النتيجة يظل رواية. أما المخرجات فهي الجزء الذي تستطيع التحقق منه. فبصمة الإيداع إما موجودة في مستودعك أو لا. والرابط إما يُفتح أو لا. وبصمة sha256 للملف إما تتطابق أو لا. وإن كان في الإيصال نتيجة دون مخرجات، فعامله عملًا بإفادة الوكيل، لأن هذا ما هو عليه. وعلى الويب، تُظهر بطاقات Done هل المهمة «متحقَّق منها» أم «بإفادة الوكيل».

ما الذي لم يفعله الوكيل؟

هذا هو السؤال الذي تتخطّاه معظم السجلات، وهو الذي يلدغك بعد أسبوعين. لدى complete_task قائمتان له، كلٌّ منهما حتى 20 مدخلًا من 500 حرف: notDone لما تركه الوكيل عمدًا، وunknowns لما ليس متأكدًا منه. ووصف الأداة نفسه يطلب من الوكلاء أن يصرّحوا بما لم يفعلوه. وهذا ما يفصل نتيجة تستطيع الاعتماد عليها عن نتيجة يتعيّن عليك إعادة استنتاجها.

اقرأ هاتين القائمتين أولًا. فعبارة «لم أشغّل الاختبارات على قاعدة بيانات staging» تغيّر ما تفعله بعد ذلك. والإيصال الخالي من أي مدخل في notDone على مهمة كبيرة يستحق بحد ذاته سؤالًا.

ما الذي تقرّر، ولماذا؟

القرارات المتخذة في المحادثة تختفي حين تمرّ المحادثة. وتحفظها record_decision بطريقتين:

• سجل قرار مستقل: عنوان، والنتيجة، والسياق، والخيارات التي وُزنت فعلًا، والعواقب، والشرط الذي يُعاد عنده النظر. والسجلات غير قابلة للتعديل؛ فتغيير واحد منها يعني تسجيل قرار جديد يحلّ محله، ويبقى القديم موسومًا بأنه مُستبدَل.
• نقل حكم: حين تقول لوكيل في المحادثة «مقبول» أو «أعده مع X» أو «أسقطه» أو «ليس الآن»، يسجّل ذلك الحكم على المهمة، مع ملاحظتك.

وتقرؤها get_task_history بثلاثة أوضاع: summary (البطاقة، وآخر إيصال لها، والأعداد)، وdecisions (كل قرار يخص المهمة، بما فيه سبب إعادتها، ويبقى حتى بعد قبول لاحق)، وfull (السجل الخام، بحد أقصى 100 حدث). وتسلّم get_context القرارات السارية إلى الوكيل التالي ضمن ميزانية من الرموز، فيبدأ التشغيل التالي مما تقرّر لا من الصفر. المزيد في لماذا تضيع القرارات في محادثات الذكاء الاصطناعي.

أين أراجعها، وعلامَ أنقر؟

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

وإن مرّر الوكيل nextStep، فإنها تظهر فوق زر «قبول»، والقبول يوافق على تلك الخطوة بالضبط. وتظل الموافقة صالحة 72 ساعة وتعود إلى الوكيل عبر get_my_work أو start_task بوصفها الخطوة الوحيدة التالية. والأسئلة التي يطرحها الوكيل بـ request_input تصل إلى صندوق الوارد نفسه، على الويب وفي تطبيقات iOS وAndroid، مع إشعار على الهاتف.

ولصندوق الوارد حدّ مقصود: 5 بنود منتظرة لمساحة عمل لشخص واحد، و10 للفريق، أو 45 دقيقة من وقت المراجعة المقدّر، أيها يأتي أولًا. وحين يمتلئ، ترفض start_task بـ attention_queue_full، فينهي الوكلاء العمل أو يوضّحونه بدل تكديس المزيد لتتحقق منه.

ما الأدلة التي أطلبها حسب نوع المهمة؟

اكتبها في وصف المهمة ليعرف الوكيل أي دليل تتوقعه:

• الشيفرة: بصمة الإيداع ورابط PR مخرجاتٍ. وينبغي أن تسمّي notDone الاختبارات التي لم تُشغَّل، والترحيلات التي لم تُطبَّق، والملفات التي تُركت عمدًا.
• المحتوى: الرابط المنشور، أو ملف المسودة مع sha256 الخاص به إن لم يُنشر بعد. وينبغي أن تسرد unknowns الحقائق التي لم يستطع الوكيل تأكيدها.
• البحث: رابط مصدر لكل ادّعاء رئيسي، وملف الملاحظات. وينبغي أن تفصل unknowns بين ما يقوله المصدر وما استنتجه الوكيل.
• التواصل: معرّف كل رسالة مُرسلة، وقائمة المستلمين ملفًّا. وينبغي أن تسرد notDone من لم يُتواصل معهم ولماذا.

كيف أتحكّم فيما يستطيع الوكيل فعله من الأساس؟

النسبة بعد وقوع الفعل تعمل أفضل مع حدود قبله. في Weft، لكل اتصال OAuth مستوى واحد من ثلاثة مستويات للصلاحيات، يُضبط في شاشة الموافقة أو لاحقًا في الإعدادات، عملاء الذكاء الاصطناعي المتصلون:

• full (الافتراضي): كل الأدوات الـ32.
• write: كل شيء عدا الأدوات المدمّرة الثلاث (trash_task وarchive_done_tasks وcomplete_sprint).
• read: الأدوات الـ11 للقراءة فقط وحدها.

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

ما الذي لا يفعله Weft هنا؟

• لا تكامل لديه مع GitHub أو Slack، فلا يبحث Weft عن إيداعاتك أو رسائلك نيابة عنك. أنت من يفتح المخرج.
• لا REST API عامة لديه ولا webhooks ولا CLI لدفع الإيصالات إلى أنظمة أخرى. وهناك تصدير إلى JSON وMarkdown.
• لا يتتبّع خطوات النموذج. فالأدوات التي تسجّل الموجّهات والرموز وزمن الاستجابة على مستوى النموذج تؤدي وظيفة مختلفة، وقد تريد واحدة منها أيضًا.
• الوكلاء يكتبون إيصالاتهم بأنفسهم. يجعل Weft الفجوة بين الادّعاء والدليل مرئية؛ لكنه لا يستطيع أن يجعل الوكيل صادقًا.

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

أليس سجل git كافيًا لأعرف ماذا فعل وكيلي؟

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

ألا يستطيع الوكيل ببساطة اختلاق مخرج؟

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

هل تنتظر كل مهمة منجزة مراجعتي؟

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

أي عملاء الذكاء الاصطناعي يستطيعون كتابة إيصالات في Weft؟

أي عميل MCP. لدى ChatGPT تطبيق Weft منشورًا على كل الخطط، بما فيها المجانية. ويتصل Claude Code بـ claude mcp add --transport http weft https://letsweft.com/api/mcp. ويستخدم claude.ai وClaude Desktop موصّلًا مخصّصًا. وهناك صفحات إعداد لـ 33 عميلًا، مثل Claude Code وChatGPT وCursor وCodex.

كم يكلّف هذا؟

تغطي الخطة المجانية 50 مهمة و200 استدعاء للذكاء الاصطناعي شهريًا. وPro بسعر $7 للمقعد شهريًا أو $60 للمقعد سنويًا. ولا أرصدة ذكاء اصطناعي في Weft: فالتفكير يجري في عميل الذكاء الاصطناعي الخاص بك. انظر الأسعار.