من «جلسات الدردشة» إلى «موظف رقمي دائم»: 5 تغييرات رئيسية في بنية openJiuwen Hyper-Agent

ملاحظة الكاتب: يشرح هذا المقال بنية الوكلاء الدائمين في openJiuwen Hyper-Agent، لمساعدة مصممي سير العمل على تقييم مدى ملاءمة هذا النموذج لفرقهم.

أطلق مجتمع الوكلاء مفتوح المصدر openJiuwen، المدعوم من هواوي، بنية سرب Hyper-Agent، ليخرج الوكلاء من نطاق جلسة الدردشة الواحدة وينضموا إلى مجموعات العمل الفعلية بوصفهم «موظفين رقميين دائمين». ووفقًا لما نقلته Pandaily في 5 نوفمبر 2026 عن مقال للمجتمع نشره موقع IT之家، تتوفر هذه الإمكانات في openJiuwen WorkSwarm، وقد أُتيح الكود مفتوح المصدر على GitHub تحت اسم JiuwenSwarm.

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

القيمة الأساسية: يجمع هذا المقال المزايا المتفرقة في صورة معمارية متكاملة، ليساعدك على فهم ما يغيّره openJiuwen Hyper-Agent، وما ينبغي لفريقك التحقق منه قبل اعتماده.

نظرة سريعة على openJiuwen Hyper-Agent

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

كيف يحوّل openJiuwen Hyper-Agent المحادثات إلى موارد

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

يتبع Hyper-Agent نهجًا معاكسًا. يتمتع Persistent Agent بهوية وحالة مستقلتين، ويمكنه تلقّي المهام باستمرار. أما المحادثات فتصبح موارد في الطبقة الأساسية يتولى النظام توزيعها وجدولتها بالتوازي، مع استعادة سياقها عند استئنافها. وبحسب المجتمع، يستند هذا التصميم إلى العمل السابق على Persistent Session، ويتيح لوكيل واحد متابعة مهام متعددة في محادثات جماعية مختلفة تابعة لجهات خارجية.

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

المكونات الخمسة الرئيسية لمعمارية openJiuwen Hyper-Agent

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

مركز موظفي Hyper-Agent وتسليم السياق

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

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

الوضع السلبي والوضع التكيفي في Hyper-Agent

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

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

import openai

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

message = "接口今天下午还没联调通，明天的发布可能有风险。"
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "你是项目助理。只输出 ignore、respond 或 intervene。"},
        {"role": "user", "content": message}
    ]
)
print(response.choices[0].message.content)

import json
import openai

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

def create_handoff_summary(history: list[str], model: str = "gpt-4o-mini") -> dict:
    """اختصار سجل العمل إلى أهداف وتقدم وخطوات تالية، لمحاكاة تسليم السياق."""
    prompt = (
        "请根据工作记录输出 JSON，字段为 goals、progress、next_steps。"
        "不要输出 JSON 以外的内容。\n\n" + "\n".join(history)
    )
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"}
    )
    return json.loads(response.choices[0].message.content)

records = [
    "产品经理：周五前完成客户周报。",
    "智能体：已汇总销售数据，等待客服数据。",
    "客服主管：今天下班前提供工单统计。"
]
print(create_handoff_summary(records))

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

التعاون عبر المجموعات والأجهزة المحلية في openJiuwen Hyper-Agent

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

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

بالنسبة إلى المهام الأكبر، يمكن لمحادثة جماعية في SwarmEngine أن تجمع المستخدم وPersistent Agent وخبراء منفردين وفرق خبراء في مساحة واحدة. يتولى مسؤول فريق الخبراء استلام المهمة وإعداد تقارير التقدم وتنظيم التسليم، بينما يعمل الأعضاء في الخلفية. ويمكن أن يأتي الخبراء أيضًا من وكلاء تابعين لجهات خارجية مثل Codex وClaude Code، وأن يعملوا جنبًا إلى جنب مع موظفين رقميين طوّرهم الفريق بنفسه.

تحليل تأثير openJiuwen Hyper-Agent

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

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

التأثير على طريقة تعاون الفرق

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

نقاط ينبغي للفرق مراعاتها عند تقييم Hyper-Agent

الأسئلة الشائعة حول openJiuwen Hyper-Agent

أبرز النقاط حول openJiuwen Hyper-Agent

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

الخلاصة: الدروس المعمارية من openJiuwen Hyper-Agent

ما يستحق الاهتمام في openJiuwen Hyper-Agent ليس مجرد دخول الوكلاء إلى Feishu أو DingTalk، بل تحويل فكرة «الجلسة من حاوية إلى مورد» إلى تصميم عملي للنظام:

1. هوية مستمرة: لم يعد الوكيل المستمر (Persistent Agent) يفقد استمرارية عمله بانتهاء جلسة واحدة.
2. الجدولة هي المحور: يتولى AgentServer التنسيق بين الوكلاء وجلسات العمل المتعددة.
3. الحوكمة تحدد قابلية التطبيق: تحدد الموافقة على الصلاحيات، والتحكم في المشاركة، ومراقبة الاستخدام مدى ملاءمة النظام لفرق العمل الفعلية.

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

📚 المراجع

1. Pandaily – openJiuwen’s Hyper-Agent Swarm Puts Persistent AI Agents Into Work Chats as Digital Employees: المصدر الرئيسي للحقائق الواردة في المقال
2. الرابط: pandaily.com/openjiuwen-hyper-agent-swarm-architecture-persistent-agents-workswarm-digital-employees
3. التفاصيل: يستعرض بنية Hyper-Agent ووظائف WorkSwarm وخطط المجتمع المستقبلية، وهو تقرير ثانوي يستند إلى مادة صادرة عن المجتمع.

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