كيف يتجاوز الوكلاء العاملون لفترات طويلة نافذة السياق: 3 أسئلة تصميمية حول نمط ملخص التسليم + استرجاع الأرشيف

ملاحظة الكاتب: نستعرض آلية تبديل السياق في openJiuwen WorkSwarm مثالًا على نمط «ملخص التسليم + استرجاع الأرشيف»، ونوضح خيارات التصميم والمفاضلات المتاحة للوكلاء طويلة التشغيل عند الاقتراب من حد نافذة السياق.

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

هذه ليست مجرد شائعة. فقد أُطلقت هذه الإمكانية ضمن openJiuwen WorkSwarm، وأُتيح كودها مفتوح المصدر على GitHub باسم JiuwenSwarm. نتناول هذه الآلية مثالًا لمناقشة ثلاثة أسئلة تصميمية: ما الذي ينبغي أن يتضمنه ملخص التسليم؟ ومتى يجب تفعيل الانتقال؟ ومتى ينبغي الرجوع إلى الأرشيف؟ ونقارن أيضًا بين المفاضلات في نهجين: «الاعتماد على سياق أطول» و«تسليم الملخص + الاسترجاع».

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

ملخص التسليم + البحث في الأرشيف: نظرة سريعة على المعلومات الأساسية

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

لماذا يحتاج الوكيل الذكي المستمر إلى معالجة حد نافذة السياق؟

تقوم فكرة WorkSwarm على تحرير الوكيل الذكي من جلسة محادثة واحدة، ليبقى حاضرًا على المدى الطويل بوصفه «موظفًا رقميًا» في مجموعات العمل على منصات مثل Feishu وDingTalk. ويمكن للوكيل نفسه متابعة مهام متعددة في عدة محادثات جماعية على منصات خارجية، وتلقي الطلب في قناة وتسليم النتيجة في أخرى. وتربط بوابة النظام تطبيقات المراسلة الفورية وواجهة الويب، بينما يتولى AgentServer جدولة الوكلاء وجلسات العمل.

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

الجلسة موردًا: أساس ملخص التسليم

لفهم آلية ملخص التسليم، من المهم معرفة أن WorkSwarm يفصل بين «الوكيل» و«الجلسة». تظل هوية الوكيل وحالته قائمتين، بينما الجلسة مجرد مورد يخصصه النظام، ويجدوله للتنفيذ المتزامن، ويمكن استئنافه بسياقه. وبما أن الجلسة قابلة للاستبدال، يصبح «فتح نافذة جديدة عندما تمتلئ النافذة الحالية» خيارًا طبيعيًا في التصميم.

ينقل ملخص التسليم الحد الأدنى الكافي من حالة العمل بين الجلسة القديمة والجديدة. أما التاريخ المؤرشف فيضمن عدم ضياع تفاصيل الجلسة القديمة؛ فهي تنتقل فقط من كونها «حاضرة دائمًا» إلى كونها «متاحة عند الطلب».

مسألة تصميم ملخص التسليم الأولى: ما الذي ينبغي أن يتضمنه؟

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

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

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

مسألة تصميم ملخص التسليم الثانية: متى يُفعّل تبديل السياق؟

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

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

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

كيفية تنفيذ ملخص التسليم والبحث في الأرشيف: نموذج أولي مبسط

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

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # واجهة APIYI المتوافقة مع OpenAI
)

HANDOFF_PROMPT = "请将以上工作记录整理为交接摘要，包含：目标、进展、下一步、约束、关键信息索引。"

def make_handoff(messages, model="gpt-4o-mini"):
    resp = client.chat.completions.create(
        model=model,
        messages=messages + [{"role": "user", "content": HANDOFF_PROMPT}]
    )
    return resp.choices[0].message.content

import openai
from typing import List, Dict

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

MODEL = "gpt-4o-mini"
CONTEXT_LIMIT = 100_000      # قيمة توضيحية، عدّلها حسب نافذة السياق الفعلية للنموذج المستخدم
SWITCH_RATIO = 0.7           # حجز مساحة لتوليد الملخص
HANDOFF_PROMPT = (
    "请将以上工作记录整理为交接摘要，分为五部分："
    "1.目标 2.进展（含关键决策及理由）3.下一步 4.用户约束 5.关键信息索引（关键词列表）"
)

class LongRunningAgent:
    def __init__(self, system_prompt: str):
        self.system_prompt = system_prompt
        self.messages: List[Dict] = [{"role": "system", "content": system_prompt}]
        self.archive: List[Dict] = []   # سجل الأرشيف؛ يمكن استبداله بقاعدة بيانات أو قاعدة بيانات متجهات في بيئة الإنتاج

    def estimate_tokens(self) -> int:
        # تقدير تقريبي؛ ينبغي استخدام مُجزّئ الرموز الخاص بالنموذج في بيئة الإنتاج
        return sum(len(m["content"]) for m in self.messages)

    def maybe_switch(self):
        if self.estimate_tokens() < CONTEXT_LIMIT * SWITCH_RATIO:
            return
        resp = client.chat.completions.create(
            model=MODEL,
            messages=self.messages + [{"role": "user", "content": HANDOFF_PROMPT}]
        )
        summary = resp.choices[0].message.content
        self.archive.extend(self.messages[1:])      # حفظ المحادثة القديمة في الأرشيف
        self.messages = [
            {"role": "system", "content": self.system_prompt},
            {"role": "system", "content": f"【交接摘要】\n{summary}"}
        ]

    def search_archive(self, keyword: str, top_k: int = 5) -> str:
        hits = [m["content"] for m in self.archive if keyword in m["content"]]
        return "\n---\n".join(hits[-top_k:]) or "归档中未找到相关记录"

    def chat(self, user_input: str) -> str:
        self.maybe_switch()
        self.messages.append({"role": "user", "content": user_input})
        resp = client.chat.completions.create(model=MODEL, messages=self.messages)
        answer = resp.choices[0].message.content
        self.messages.append({"role": "assistant", "content": answer})
        return answer

agent = LongRunningAgent("你是负责跟进项目周报的数字员工。")
print(agent.chat("请记录：本周报告不要超过一页。"))

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

🚀 البدء السريع: عند بناء نموذج أولي من هذا النوع، يمكن استخدام نموذجين مختلفين لإنشاء الملخص وتنفيذ المهمة الرئيسية؛ مثل نموذج خفيف لإنشاء الملخص ونموذج أقوى لتنفيذ المهمة. عبر APIYI ‏apiyi.com، يمكنك استخدام مفتاح API واحد لاستدعاء نماذج OpenAI وClaude وGemini وغيرها، مما يسهل التبديل بينها ومقارنتها ضمن قاعدة الشفرة نفسها. ويحصل المستخدمون الجدد على رصيد مجاني للتجربة.

المسألة الثالثة في تصميم ملخص التسليم: متى نعود إلى الأرشيف؟

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

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

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

الاعتماد على سياق أطول أم ملخصات التسليم: تحليل الأثر

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

💡 نصيحة للاختيار: إذا كان بالإمكان عادةً إنجاز المهمة ضمن نافذة سياق طويلة واحدة، فالانتقال إلى نموذج بسياق أطول هو الخيار الأسهل. أما إذا كان الوكيل بحاجة إلى العمل لفترة طويلة مثل الموظفين الرقميين في WorkSwarm، فملخصات التسليم تكاد تكون ضرورية. يمكنك أولًا تشغيل المهمة نفسها باستخدام نماذج ذات نوافذ سياق مختلفة على APIYI عبر apiyi.com، ثم مراقبة الاستهلاك الفعلي قبل اتخاذ قرار تطوير آلية للتلخيص.

التأثير على المطورين

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

التأثير على القطاع

• من الوكلاء المرتبطين بالجلسات إلى الوكلاء الدائمين: تنتقل الوكلاء من نمط «سؤال وجواب» إلى العمل باستمرار ضمن فرق، وستصبح قدرتها على نقل السياق بين النوافذ جزءًا أساسيًا من البنية التحتية لهذه المنتجات.
• التنفيذ مفتوح المصدر يوفر مرجعًا: بعد إتاحة JiuwenSwarm مفتوح المصدر، يمكن للمطورين دراسة عتبات التبديل وآليات إنشاء الملخصات وتنفيذ الاسترجاع مباشرةً، بدلًا من استكشافها من الصفر.

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

أبرز النقاط حول ملخص التسليم ونافذة السياق

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

الخلاصة

تقدم آلية تبديل السياق في openJiuwen WorkSwarm نموذجًا واضحًا يمكن الاسترشاد به للوكـلاء الذين يعملون لفترات طويلة:

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

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

📚 المراجع

1. تقرير Pandaily: بنية مجموعة openJiuwen Hyper-Agent والموظفون الرقميون في WorkSwarm
2. الرابط: pandaily.com/openjiuwen-hyper-agent-swarm-architecture-persistent-agents-workswarm-digital-employees

3. الوصف: تقرير باللغة الإنجليزية يشرح الوكلاء الدائمين وآليات تبديل السياق وملخصات التسليم.

4. شفرة JiuwenSwarm مفتوحة المصدر: تنفيذ مفتوح المصدر لـ openJiuwen WorkSwarm

5. الرابط: github.com (ابحث عن JiuwenSwarm)
6. الوصف: للاطلاع على التنفيذ التفصيلي لعتبات التبديل، وإنشاء الملخصات، والبحث في الأرشيف.

الكاتب: الفريق التقني في APIYI
للتواصل التقني: يسعدنا تواصلكم معنا عبر الصفحة الرئيسية لموقع APIYI على apiyi.com، ولمزيد من المعلومات يمكنكم زيارة مركز التوثيق على docs.apiyi.com.

مقالات ذات صلة

• هل يمكن لشخص واحد متابعة 5 جلسات كحد أقصى؟ تحليل الوحدات الخمس لوكيل DeepSeek الذكي الفائق: تحليل مقال فريق DeepSeek Harness عن بنية الوكيل فائق الذكاء (Super-agent): الوحدات الخمس، وظروف التجربة وبياناتها، وأربعة أسئلة مفتوحة، وقائمة تطبيق للفرق الصغيرة، واختيار نماذج Router وWorker وتقدير التكلفة.
• أنشئ وكيلًا لتلخيص المراقبة يعمل وفق جدول زمني: دليل المكونات الأربعة واختيار الواجهات: حلّل المكونات الأربعة لوكيل ملخصات المراقبة الذي يعمل وفق جدول زمني، ووضّح كيف تنفصل طبقة استدعاء النموذج عن حزمة تطوير برمجيات محددة باستخدام واجهة متوافقة مع OpenAI، وقدّم مثالًا قابلًا للتشغيل بلغة Python.