الانتقال إلى المحتوى الرئيسي

السياق المشترك مشكلة اتساق، لا مشكلة تخزين

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

تجسيد تجريدي لعقد وحواف متصلة تشكل رسمًا بيانيًا شبكيًا على خلفية داكنة

لماذا يُعاد اختراع السياق المشترك مرارًا

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

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

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

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

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

سلطة الكتابة: كل حافة تحتاج إلى مالك

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

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

Empty tunnel with a patterned ceiling of lights casting shadows

edge_types:
  - name: service_owns_database
    subject: service
    object: database
    writers:
      - agent: inventory-agent
        task: reconcile-service-topology
    cardinality: many-to-many
    conflict_policy: quarantine

  - name: deployment_target
    subject: service
    object: environment
    writers:
      - agent: release-agent
        task: promote-release
    cardinality: one-to-one
    conflict_policy: last-write-wins-with-timestamp

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

لا يتطلب هذا سلطة مركزية لكل كتابة. بل يتطلب أن تكون السلطة معلنة وقابلة للتحقق. يمكن منح وكيل نطاق كتابة واسع لمهمة، لكن المنح سجل، لا تعليمة في system prompt.

حل التعارض: الحواف المتناقضة أمر طبيعي

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

يجب تحديد الأولوية مسبقًا، لكل نوع حافة. ثلاثة خيارات عملية:

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

بالنسبة للحقائق التي سيتصرف الوكلاء بناءً عليها، يكون الحجر عادة صحيحًا. الثمن هو زمن الاستجابة: يصبح الرسم البياني غير مكتمل مؤقتًا لتلك الحافة، وأي وكيل يحتاج الحقيقة يجب أن ينتظر أو يمضي بمجهول صريح. هذه مقايضة حقيقية. آخر كتابة تفوز تبقي الرسم البياني قابلًا للقراءة باستمرار بثمن نشر اعتقاد خاطئ أحيانًا. الحجر يبقي الرسم البياني موثوقًا بثمن الإتاحة. يجب أن يتبع الاختيار نتيجة التصرف بناءً Close-up of moss-covered brutalist concrete structure with geometric designa/server-rack-closeup-5ed2bb-8c3175.jpg)

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

اتساق القراءة للخطوات اللاحقة

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

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

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

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

ما يعنيه هذا للتصميم

الرسم البياني المعرفي المشترك لنظام متعدد الوكلاء ليس خيار تخزين. إنه مجموعة سياسات حول السلطة والتعارض والاتساق تُعبَّر عنها في رسم بياني. طبقة التخزين هي الجزء السهل.

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

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

مشاركةXLinkedInرابط دائم6 دقيقة قراءة

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

الأسئلة التي يجيب عنها هذا

Why is a vector store insufficient as shared context for multi-agent systems?

A vector store shares recall, not state. It returns ranked chunks by similarity and has no representation of agreement or contradiction, so two agents can hold incompatible beliefs indefinitely without the system detecting it.

Where should write authority be enforced in a multi-agent graph?

In the schema attached to each edge type, not in an agent's prompt. Schema-level policy is enforced by the write path and rejects assertions that do not match a declared writer; prompt-level rules are advisory and cannot block a write.

When should conflicting edges be quarantined rather than merged?

Quarantine is usually correct for facts other agents will act on, because it prevents a wrong belief from propagating. The cost is latency and a temporarily incomplete graph for that edge, so the choice should follow the consequence of acting on a wrong edge.

Why do agents need a graph snapshot instead of a live view?

If the graph changes between reads within one agent trajectory, the trajectory is not reproducible. Pinning reads to a graph version and recording that version in the run's trajectory makes replay and debugging possible.