لقد أصبح OpenClaw واحدًا من أكثر أطر العمل الوكلاءية اعتماداً على نطاق واسع، لكنه لم يثبت نفسه بعد على مستوى المؤسسات. يحتاج الوكلاء إلى بيانات اعتماد حقيقية – مفاتيح API، ورموز OAuth المميزة، وحسابات الخدمة – للعمل بفعالية، وقد وجدت Brex أن حواجز الحماية التقليدية لا يمكن أن تحتوي على ما كان يفعله هؤلاء الوكلاء معهم.
شرعت شركة Brex في التغلب على هذه القيود من خلال بناء منصة داخلية تسمى CrabTrap. يعترض وكيل HTTP/HTTPS مفتوح المصدر كل حركة مرور الشبكة، ويفحص قواعد السياسة، ويستخدم LLM-as-a-قاضيًا لتحديد ما إذا كان ينبغي الموافقة على طلبات الوكيل أو رفضها.
وقال بيدرو فرانشيسكي، المؤسس المشارك والرئيس التنفيذي لشركة Brex، لـ VentureBeat: “ما لاحظناه هو أن طبقة الشبكة كانت نقطة إنفاذ غير مستغلة”. “كل طلب يقدمه الوكيل يمثل فرصة للاعتراض والتفكير واتخاذ قرار سياسي.”
يريد فرانشيسكي من قادة تكنولوجيا المعلومات أن يرسموا الفكرة الجاهزة: يجب أن تتحول حوكمة الوكيل من الأذونات على مستوى SDK وحواجز الحماية النموذجية إلى مستوى تحكم مركزي في الشبكة يفرض سلوك الوكيل الحقيقي ويتعلم منه.
كيف استهدف بريكس طبقة النقل
كان “الحل الواضح” (على الأقل في البداية) للفجوة الأمنية للعميل هو حواجز الحماية، وقد ركز الكثير من العمل المبكر على الأدوات المحددة النطاق، وأذونات كل إجراء، والموافقات البشرية في الحلقة. ولكن مع تطور العملاء، فإن كل قدرة جديدة تعني أن هناك واجهة برمجة تطبيقات أخرى يجب ضبطها أو عرضها للتدقيق، كما أشار فرانشيسكي.
وقال: “إن أي نظام وكيل يحتوي على أدوات متعددة وإمكانية الوصول إلى الإنترنت المفتوح يخلق توترًا فوريًا للبنائين: كلما زادت قدرتك على إنشاء عميل، أصبح أكثر خطورة، وكلما جعلته أكثر أمانًا، قلت فائدته”.
كانت الحلول الحالية لهذه المقايضة “ضعيفة”: تساعد الرموز المميزة لواجهة برمجة التطبيقات (API) الدقيقة على الهوامش ولكن لا يزال من الممكن إساءة استخدامها وتقييد الوظائف. يمكن تجاوز حواجز الحماية الدلالية (مثل السياق أو المهارات أو التوجيه الفوري) بسهولة عن طريق الحقن الفوري، خاصة بالنسبة للعملاء المتصلين بالإنترنت.
وقال فرانشيسكي إنه يمكن “تشويه سمعة” الوكلاء عندما يتم منحهم حق الوصول للقراءة فقط أو مجموعة أدوات محدودة، لكنهم لا يستطيعون القيام بعمل ذي معنى. من ناحية أخرى، فإن منح حق الوصول للكتابة على نطاق واسع وسطح أداة كبير يمكن أن يؤدي إلى الهلوسة وعواقب الإنتاج الحقيقية.
تفرض بوابات بروتوكول السياق النموذجي (MCP) السياسة في طبقة البروتوكول – ولكن فقط لحركة المرور التي تستخدم MCP. وفي الوقت نفسه، ترتبط حواجز الحماية المقدمة من مزودي LLM بنموذج واحد ويمكن أن تكون “غامضة” لتخصيصها مع السياسات الخاصة بالمؤسسة. وتوفر الأدوات القوية مثل Nvidia OpenShell المزيد من “التحكم في الخروج لكل صندوق رمل”.
وقال فرانشيسكي: “عندما بدأنا، لم نجد حلاً لنشر أدوات مثل OpenClaw بشكل آمن”. “بدلاً من انتظار أن تلحق الصناعة بركبها، قررنا أن نمتلك المشكلة ونبتكر الأدوات اللازمة.”
وعلى وجه الخصوص، كانوا بحاجة إلى منصة تقع بين كل وكيل وكل طلب للشبكة، ويمكنها اتخاذ “قرارات دقيقة بشأن ما يجب السماح به”، على حد قوله.
وقال إن هذا جعل طبقة النقل مكونًا معماريًا أساسيًا ونقطة انطلاق طبيعية.
من خلال العمل في هذه الطبقة، يعتبر CrabTrap حياديًا لإطار العمل، وحياديًا للغة، وواجهة برمجة التطبيقات (API). لا يتطلب الأمر أغلفة SDK أو تكاملًا لكل أداة. تعيين المستخدمين HTTP_PROXY و HTTPS_PROXY في بيئة الوكيل، ويتم توجيه كل طلب صادر عبر الوكيل قبل أن يصل إلى الوجهة.
ومع ذلك، أكد فرانشيسكي أن بريكس لم يبدأ من طبقة النقل لأنه اعتقد أنها كانت الإجابة الوحيدة؛ بل إنهم يؤمنون بـ “الأمن عبر الطبقات”.
وقال: “كانت طبقة النقل ببساطة طبقة غير مستثمرة بشكل كافٍ، وقد رأينا فرصة لإضافة إنفاذ ذي معنى هناك إلى جانب كل شيء آخر”.
حلقة تدريب LLM كقاض
وأوضح فرانشيسكي أن CrabTrap يجمع بين القواعد الثابتة الحتمية وLLM كقاضي للطلبات التي تقع خارج الأنماط المعروفة. يقوم القاضي فقط “بالإشارة إلى الذيل الطويل لنقاط النهاية غير المألوفة أو أشكال الطلبات غير العادية”، والتي عادة ما تكون أقل من 3% من الطلبات بالنسبة للوكيل الناضج.
وكانت المشكلة الأكثر إلحاحا هي كيفية معرفة ما إذا كانت السياسة هي السياسة الصحيحة؟ مع القواعد الثابتة، يكون من السهل نسبيًا التفكير بشأن الدقة. ولكن مع وجود قاضي LLM، يكون النظام غير حتمي، ويحتاج المستخدمون إلى الثقة في أن السياسة توافق على الطلبات الصحيحة وتمنع الباقي.
وقال فرانشيسكي: “كانت رؤيتنا الرئيسية هي بناء السياسة على السلوك المرصود بدلاً من كتابتها من الصفر”. تبين أن البدء بالسلوك الحقيقي والتعديل بناءً على ما تعلمناه من العالم الحقيقي هو “أكثر فعالية بشكل كبير من البدء من صفحة فارغة”.
قام فريق بريكس ببناء أداة إنشاء السياسات (في حد ذاتها عبارة عن حلقة وكيلة) التي تدير الوكلاء الأساسيين في وضع الظل، وتحلل حركة مرور الشبكة التاريخية، وتأخذ عينات من المكالمات التمثيلية، وتصوغ سياسة اللغة الطبيعية التي تتطابق مع ما يفعله الوكيل بالفعل.
ومن هناك، قاموا ببناء نظام تقييم يختبر تغييرات السياسة قبل نشرها. يقوم CrabTrap بمقارنة إدخالات التدقيق التاريخية مع مسودة السياسة ويبلغ عن التغييرات الدقيقة التي سيتم إجراؤها. يمكن للمستخدمين تقسيم النتائج حسب الطريقة وعنوان URL والقرار الأصلي وحالة الاتفاقية.
وقال فرانشيسكي إن كل هذا يتم من خلال استدعاءات متزامنة للقضاة، لذا فإن إعادة آلاف الطلبات “تستغرق دقائق، وليس ساعات”. طورت Brex أيضًا حلقة تعليقات مباشرة: يتم تخزين مسارات التدقيق الكاملة في PostgreSQL ويمكن الاستعلام عنها من خلال واجهة برمجة تطبيقات المشرف ولوحة المعلومات. في الحالات التي يتم فيها رفض المورد بشكل مستمر، يمكن للنظام إخطار الإنسان أو الوكيل لاقتراح تحديث السياسة للمراجعة.
وقال فرانشيسكي: “هذا يغلق الحلقة بين الإنكار الملحوظ وصقل السياسة”.
التحديات الأساسية والحواجز
وبطبيعة الحال، لم يكن البناء خاليا من التحديات. أحد أهم هذه العوامل كان زمن الاستجابة: “يبدو أن وضع LLM بين الوكيل وكل طلب واجهة برمجة التطبيقات (API) الصادر قد يؤدي إلى توقف الأمور”.
ومع ذلك، لم يتبين أنها مشكلة كبيرة كما كان متوقعا. كان هذا لسببين: يتم تفعيل قاضي LLM فقط بناءً على جزء صغير من الطلبات (3٪ المذكورة أعلاه). يستقر الوكلاء بسرعة في أنماط حركة المرور التي يمكن التنبؤ بها؛ بمجرد ملاحظتها، تصبح الأنماط ذات الحجم الكبير قواعد ثابتة. ثانياً، باستخدام نماذج صغيرة وسريعة مثل كلود هايكو، كان ذلك يعني أنه حتى عندما يطرد القاضي، فإن الكمون الإضافي “لا يكاد يذكر”. وقال فرانشيسكي إنه يمكن تقليل ذلك بشكل أكبر باستخدام النماذج المحلية والتخزين المؤقت السريع.
وقال إن التحدي الأصعب والأقل وضوحا هو الحقن الفوري. يتلقى القاضي طلب HTTP الكامل ويخضع كل المحتوى لتحكم المستخدم، لذلك من المحتمل أن يتلاعب عنوان URL أو الرأس أو نص الطلب بقرار القاضي.
قال فرانشيسكي إن شركة Brex عالجت هذه المشكلة من خلال تنظيم الطلب ككائن JSON قبل إرساله إلى النموذج، بحيث يتم “تهرب” كل المحتوى الذي يتحكم فيه المستخدم بدلاً من استيفاءه كنص خام.
النتائج وأين قد يتطور CrabTrap
يتتبع Brex بعض العوامل لقياس التأثير الداخلي لـ CrabTrap: التفاعل مع الوكلاء، وأنماط حركة مرور الشبكة، وصافي نتائج المروجين (NPS). وقال فرانشيسكي إن النتيجة الأكثر أهمية لـ CrabTrap كانت “الثقة التنظيمية”.
في السابق، كان لدى الفريق “تردد حقيقي” عندما يتعلق الأمر بنشر عملاء مستقلين على نطاق واسع عبر العمليات التجارية، لأن خيارات الدرابزين الحالية لم توفر ضمانًا كافيًا.
وقال فرانشيسكي: “لقد غيّر CrabTrap حسابات التفاضل والتكامل هذه”. لديهم الآن طبقة تنفيذية يثقون بها، مما يزيد من الثقة حول توسيع نطاق نشر الوكيل في المزيد من أجزاء الأعمال وتفويض المزيد من تكوين الوكيل وإدارته للمستخدمين.
ووصف فرانشيسكي السياسات المستمدة من حركة المرور بأنها “قوية بشكل مدهش”. وتوقع الفريق أن يقوم منشئ السياسات بإنتاج “نقطة بداية تقريبية” تتطلب تحريرًا يدويًا مكثفًا. ولكن من الناحية العملية، أدى توجيه المنصة إلى بضعة أيام من حركة المرور الحقيقية إلى إنتاج سياسات تتوافق مع الحكم البشري على “الغالبية العظمى من الطلبات المعلقة”.
بالإضافة إلى ذلك، كشف CrabTrap عن مقدار عوامل الضوضاء التي تولدها. قال فرانشيسكي: “لقد أوضحت عملية التدقيق هذا الأمر للمرة الأولى”. لقد استخدموا سجلات الرفض وتحليل حركة المرور ليس فقط لضبط السياسات، بل أيضًا لتشديد الوكلاء أنفسهم، وإزالة الأدوات، واستبعاد فئات كاملة من الطلبات التي كانت تهدر الوقت والرموز.
وقال: “أصبح الوكيل أداة اكتشاف، وليس مجرد أداة إنفاذ”.
مجالات النمو (والمدخلات من مجتمع المصادر المفتوحة)
تتوقع شركة Brex أن يستمر CrabTrap في التطور، خاصة وأنها أصدرته كمصدر مفتوح. قال فرانشيسكي: “نأمل أن يساعد المجتمع في تشكيلها”.
تشمل مجالات التحسين وظائف مصادقة أعمق مثل تسجيل الدخول الموحد (SSO)، والتحكم الدقيق في الوصول المستند إلى الأدوار (RBAC)؛ سير عمل التصعيد الذي يسمح للوكلاء بطلب أذونات إضافية؛ وتوصيات السياسة على أساس أنماط الرفض.
وقال فرانشيسكي إن التكوين البرمجي، أو تطوير نقاط نهاية واجهة برمجة التطبيقات من أجل “إنشاء السياسات وتقسيمها وتطبيقها” على الوكلاء، يمكن أن يسمح بأتمتة دورة حياة السياسة بأكملها بدلاً من إدارتها يدويًا.
أما بالنسبة للتصعيد، إذا تم رفض الوكيل بشكل مستمر لمورد معين أو نقطة نهاية معينة، فيجب أن يكون قادرًا على توجيه الطلبات إلى البشر أو وكلاء الذكاء الاصطناعي الآخرين للمراجعة ودعم ذلك بمبرر منطقي لسبب حاجته إلى الوصول.
وقال فرانشيسكي: “هذا يحول CrabTrap من حدود التنفيذ الصارمة إلى شيء أشبه بنظام الأذونات المُدارة”.
بالإضافة إلى ذلك، تم إنشاء السياسة للتمهيد من حركة مرور الشبكة، ولكن هناك فرصة لدمج إشارات إضافية حول تتبعات الوكيل واستدعاء الموارد، بالإضافة إلى سياق أوسع حول ما يحاول العملاء تحقيقه في النهاية. وهذا يمكن أن يساعد في إنتاج سياسات أكثر دقة ودقة.
أخيرًا، هناك “سؤال فلسفي مفتوح” حول الوضع الصحيح لـ CrabTrap: هل يجب أن تكون طبقة شفافة بالكامل لا يعرفها الوكيل نفسه، أم يجب أن يعمل مثل “مدير حسن النية”؟ (أي أن الوكيل يعرف عن الطبقة ويمكنه التفاعل معها).
وقال فرانشيسكي إن مجتمع المصادر المفتوحة يمكن أن يساعد في تشكيل هذه التطورات، ولن يتحسن CrabTrap إلا مع المزيد من المستخدمين. يتحدث وكلاء Brex إلى مجموعة محددة من واجهات برمجة التطبيقات؛ ستعرض الفرق التي تستخدم CrabTrap مع وكلاء وخدمات ومتطلبات سياسة مختلفة “الحالات والأنماط المتطورة التي لا يمكننا التغلب عليها بمفردنا”.
وقال فرانشيسكي: “لدينا خطط طموحة بشأن المكان الذي يمكن أن نصل إليه، ونفضل البناء في العراء”.
ما الذي يمكن للبناة الآخرين تعلمه من CrabTrap
وكان الرد أقوى مما كان متوقعا. لدى CrabTrap أكثر من 700 نجمة على GitHub. وقال فرانشيسكي إن بريكس سمعت أيضًا من OpenAI، والرئيس التنفيذي لشركة Y Combinator Garry Tan، والمبرمج Pete Steinberger، وجميعهم يعبرون عن اهتمامهم بنشر بنية تحتية داخلية مماثلة.
والدرس الأوسع نطاقاً هو: “لا تدعوا الفجوات في البنية الأساسية تصبح أعذاراً للانتظار،" نصح فرانشيسكي. هناك “عوائق حقيقية” لكل مؤسسة تتطلع إلى نشر عملاء الذكاء الاصطناعي بشكل جدي، بما في ذلك المخاوف الأمنية، أو نقص الأدوات، أو حواجز الحماية غير الواضحة.
وقال: “من المغري أن تظل مكتوفي الأيدي حتى تلحق الصناعة بركبها”. “الدرس المستفاد من CrabTrap هو أنه يمكنك امتلاك تلك المشكلات بشكل مباشر.”
