# استراتيجية الجدولة للوكلاء: المناطق الزمنية والإرسال المتدرّج، ولا لإغراق أربعين صفحة في التاسعة صباحًا

_2026-09-18 · كيف يجدول وكيل الذكاء الاصطناعي المنشورات على حسابات كثيرة: إزاحات ISO 8601، والمناطق الزمنية والتوقيت الصيفي، وحساب التدرّج، وتقسيم المجموعات، والإلغاء الآمن._

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

كل ما يلي يحوّل هذه القواعد إلى خطوات عملية، مع الحقول التي يتوقعها Shager بالضبط.

## لماذا يخطئ الوكلاء في الوقت؟

النماذج اللغوية سيئة مع الساعات. لا تعرف كم الساعة ما لم تخبرها، وتكتب بلا تردد `2026-11-02T09:00:00` من دون إزاحة، وتحوّل بين المناطق الزمنية في ذهنها. وكل واحدة من هذه سبب لخروج منشورات في السابعة بدل التاسعة.

يغلق Shager بابًا واحدًا برفض الغموض: يجب أن يكون `schedule_at` بصيغة ISO 8601 مع إزاحة، مثل `2026-10-20T09:00:00+03:00`. والطابع الزمني الذي يخلو من `Z` أو من إزاحة يفشل في التحقق. هذه الصيغة هي الملف المعرَّف في [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339)، ومن المفيد أن تذكرها لوكيلك بالاسم في تعليماته.

أما الباب الآخر فهو الإزاحة نفسها. `+03:00` صحيحة لإسرائيل في أكتوبر وخاطئة في ديسمبر. فالإزاحات تتغير مع التوقيت الصيفي، وتواريخ التغيير تختلف بين إسرائيل والاتحاد الأوروبي والولايات المتحدة. لا ينبغي للوكيل أن يثبّت إزاحة في الكود أبدًا، بل أن يحدد منطقة العميل باسمها عبر [قاعدة بيانات المناطق الزمنية IANA](https://www.iana.org/time-zones)، المتوفرة في كل لغة برمجة شائعة، ثم يحسب الإزاحة لذلك التاريخ تحديدًا.

```python
from datetime import datetime
from zoneinfo import ZoneInfo

local = datetime(2026, 11, 2, 9, 0, tzinfo=ZoneInfo("Europe/Berlin"))
print(local.isoformat())   # 2026-11-02T09:00:00+01:00
```

لكل مساحة عمل في Shager أيضًا `timezone`، وهو اسم منطقة بصيغة IANA يُضبط عند إنشاء مساحة العمل (الافتراضي `Asia/Jerusalem`). اجعل الوكيل يقرؤه ويستخدمه. فحين تشغّل [وكيلًا واحدًا لعملاء كثيرين](/ar/blog/one-agent-many-clients)، لن يشترك كل العملاء في منطقة واحدة، ومساحة العمل هي المكان الوحيد الذي يسجّل منطقة كل عميل.

## المسودة أولًا ثم الجدولة

يستطيع `create_post` الجدولة فورًا إن مرّرت `schedule_at`. ونادرًا ما أسمح للوكلاء بذلك في عمل العملاء. النمط الأكثر أمانًا يتكون من استدعاءين:

1. `create_post` من دون `schedule_at`، فيُحفظ المنشور مسودة.
2. `schedule_post` مع معرّف المنشور والوقت، بعد أن يجيزه إنسان أو قاعدة.

```json
{
  "tool": "schedule_post",
  "arguments": {
    "workspace_id": "ws_example",
    "post_id": "pst_example",
    "schedule_at": "2026-10-20T09:00:00+03:00"
  }
}
```

هناك سبب يتعلق بالصلاحيات أيضًا. في Shager، تتطلب الجدولة صلاحية `publish` على مفتاح API، بينما تكفي `write` لكتابة المسودات. يمنح الإنسان `publish` صراحة عند تولّي ملكية بيئة اختبار الوكيل، ويستطيع إنشاء مفاتيح من دونها. هذا الفصل يتيح لك منح وكيل الكتابة حرية واسعة، وإبقاء الخطوة الأخيرة بيد شخص. التفاصيل في [مفاتيح API والصلاحيات والتدقيق](/ar/blog/api-keys-scopes-and-audit).

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

## كم يستغرق الإطلاق المتدرّج فعلًا؟

ينشر Shager حسابًا تلو الآخر مع توقف عشوائي بين حسابات الشبكة نفسها. يحدد الحقل `stagger_seconds` هذا النطاق، وقيمته الافتراضية `[30, 90]`. وتعمل الشبكات بالتوازي، فتتحدد مدة الإطلاق بالشبكة التي تضم أكبر عدد من الحسابات.

الحساب بسيط بما يكفي ليجريه الوكيل قبل أن يختار الوقت:

| الحسابات في الشبكة الأكبر | التدرّج | متوسط الفاصل | المدة التقريبية للإطلاق |
|---|---|---|---|
| 10 | [30, 90] | 60 ث | نحو 9 دقائق |
| 40 | [30, 90] | 60 ث | نحو 39 دقيقة |
| 40 | [60, 180] | 120 ث | نحو 78 دقيقة |
| 120 | [30, 90] | 60 ث | نحو ساعتين |

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

لا ترد على الموعد النهائي بتقليص التدرّج إلى `[0, 5]`. التوقف موجود كي لا يبدو الإطلاق الجماعي دفعة صادرة من مصدر واحد. ويشرح مقالنا عن [النشر على نطاق واسع دون أن تُحظر](/ar/blog/avoid-spam-blocks-when-posting-at-scale) لماذا يهم الإيقاع أكثر من أي نص منفرد.

## قسّم حسب المجموعة، لا حسب الساعة

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

```json
{
  "tool": "create_post",
  "arguments": {
    "workspace_id": "ws_example",
    "group_ids": ["grp_north"],
    "caption": "Winter hours start Sunday at every northern branch.",
    "per_channel": [
      { "channel_id": "ch_fb_haifa", "caption": "Haifa branch: winter hours start Sunday. We open at 8:30." }
    ],
    "campaign": "winter-hours",
    "stagger_seconds": [60, 150]
  }
}
```

تُنشأ المجموعات عبر `create_group`، الذي يأخذ اسمًا وقائمة `channel_ids`. وحين تستهدف المجموعة، يُضاف كل حساب نشط فيها.

## حدود الشبكات التي يجب أن يحترمها الوكيل

الشبكات نفسها تحدّ مما يستطيع الحساب نشره عبر واجهاتها. توثّق Meta حدًا لكل حساب لمنشورات Instagram عبر API خلال نافذة متحركة مدتها 24 ساعة، وتتيح [نقطة الوصول content_publishing_limit](https://developers.facebook.com/docs/instagram-platform/content-publishing) لمعرفة الاستخدام الحالي. وتخصص YouTube حصة API لكل مشروع، [افتراضيًا 10,000 وحدة يوميًا](https://developers.google.com/youtube/v3/getting-started)، والرفع من أغلى العمليات.

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

## التقويم والأعياد والأيام الهادئة

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

## الإلغاء والنقل

يلغي `cancel_post` جدولة منشور لم يبدأ نشره بعد. لا يحذفه، بل يعود المنشور مسودة موافَقًا عليها، فيستطيع الوكيل استدعاء `schedule_post` مجددًا بوقت جديد. الإلغاء للمنشورات التي ما زالت تنتظر، فبمجرد أن يبدأ النشر لا يعود `cancel_post` ساريًا.

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

## أسئلة شائعة

### أي منطقة زمنية يستخدمها Shager إذا أرسل الوكيل الوقت بتوقيت UTC؟

الطابع الزمني الذي يحمل `Z` لا لبس فيه، فيجدوله Shager في تلك اللحظة بالضبط. تهم المنطقة الزمنية لمساحة العمل في طريقة عرض الجدول للناس في التقويم وفي تفكير الوكيل نفسه. وإرسال الوقت المحلي مع الإزاحة الصحيحة يُبقي سجلات الوكيل مقروءة للبشر الذين يراجعونها.

### هل يستطيع الوكيل جدولة حسابات مختلفة في أوقات مختلفة ضمن منشور واحد؟

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

### ما التدرّج الافتراضي المعقول؟

القيمة الافتراضية `[30, 90]` مناسبة لمعظم الإطلاقات. أما للفيديو وللإطلاقات التي تتجاوز نحو 50 حسابًا على شبكة واحدة، فأوسّعه إلى شيء مثل `[60, 150]` وأبدأ أبكر. الثمن هو الوقت، لا الوصول.

## إلى أين بعد ذلك

ضع هذه القواعد في التعليمات الثابتة لوكيلك بدل تكرارها في كل مهمة. يتضمن مقال [تعليمات وكيل المحتوى](/ar/blog/prompts-for-a-content-agent) كتلة جدولة يمكنك لصقها كما هي.

---
Source: https://shager.ai/ar/blog/scheduling-strategy-for-agents