كيف بنت ShipStation Global مكتب مساعدة تقني يعمل بالذكاء الاصطناعي باستخدام Amazon Bedrock AgentCore

هذه التدوينة من تأليف مشترك مع Kenneth Salmon وEdward Boswell وJack Armstrong وRobert Bahn وNick Ciubotariu من ShipStation Global.

الإجابة عن نفس أسئلة تقنية المعلومات ومعالجة التذاكر الروتينية تستهلك وقتًا يمكن لفرق تقنية المعلومات تخصيصه لأمور أخرى. ولاستعادة هذا الوقت، قام فريق ShipStation Global Engineering ببناء بحّار سطح السفينة، وهو وكيل مكتب مساعدة لتقنية المعلومات مدعوم بالذكاء الاصطناعي لـ Slack، على Amazon Bedrock AgentCore.

ShipStation Global هي المنصة الرائدة في الشحن والخدمات اللوجستية الذكية للشاحنين الصغار والمتوسطين، وتعمل على اعتقاد بسيط: كلما كانت فرقها أكثر كفاءة، كان تقديمها للعملاء أفضل. يضع Deckhand ذلك الاعتقاد موضع التنفيذ، فهو يجيب على الأسئلة الروتينية المتعلقة بتقنية المعلومات والشركة من قاعدة معرفية منسقة، ويقرأ لقطات الشاشة لرسائل الخطأ، وينشئ تذاكر Jira Service Management ويحدّثها.

في هذه المقالة، نناقش كيف قامت ShipStation بتصميم Deckhand، الأمر الذي أدى إلى حل 97.5 بالمئة من استفسارات القناة الواردة مع الحصول على تقييم رضا إيجابي بنسبة 96 بالمئة من الموظفين (Figure 1).

الشكل 1: تغطية القناة لمدة 3 أشهر والتغذية الراجعة الإيجابية

التحدّي التجاري

يحل Deckhand مشكلة سيتعرف عليها كل فريق تقنية معلومات: تُطرح الأسئلة نفسها بشكل روتيني، وتُنشر رسائل الخطأ خارج ساعات العمل، وتحتاج المعلومات إلى جمعها من فرق مختلفة. في ShipStation Global، كانت تلك المحادثات تجري في قناة Slack مزدحمة لمكتب المساعدة، حيث يطرح الموظفون أسئلتهم ويجيب فريق تقنية المعلومات، موضوعًا تلو الآخر. وكانت الإجابات موجودة عادةً بالفعل في مقال إرشادي على Confluence، أو في صفحة على شبكة الإنترانت الداخلية للشركة، أو في نقاش يعود إلى ثمانية أشهر سابقة. أما العثور عليها فهو الجزء الصعب.

جعلت بيانات القناة الحجم ملموسًا. في الأشهر الـ12 السابقة للإطلاق:

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

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

— كريس كولينز، المدير الأول لتقنية المعلومات في ShipStation Global

نظرة عامة على الحل

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

يتكوّن الحل من أربعة مكونات رئيسية، موضحة في الشكل 2:

1. خدمة Slack: تطبيق FastAPI وSlack Bolt، مستضاف على AWS App Runner. يستقبل أحداث Slack، ويقرر ما إذا كان يجب على الروبوت الاستجابة، ويبني حمولة سياق المستخدم من ملف طالب الطلب الشخصي على Slack، بما في ذلك الاسم والبريد الإلكتروني والمنطقة الزمنية والمدير.
2. خدمة الوكيل: وكيل Strands، منشور كحاوية على Amazon Bedrock AgentCore runtime, يدير حلقة الوكيل متعددة الأدوار باستخدام Claude من Anthropic في Amazon Bedrock.
3. الأدوات والمعرفة: دالة واحدة AWS Lambda مكشوفة كأدوات Model Context Protocol (MCP) من خلال AgentCore Gateway، وهي إحدى إمكانيات Amazon Bedrock AgentCore، تصنّف الطلبات، وتنشئ تذاكر Jira وتحدّثها، وتحلّل الصور. أما قاعدة معارف Amazon Bedrock فتفهرس المحتوى من Confluence وشبكة الشركة الداخلية وSlack وصفحات التسويق، وتخزّنه في Amazon Simple Storage Service (Amazon S3).
4. العمليات والملاحظات. Amazon DynamoDB يخزّن الملاحظات، AWS X-Ray يتتبع مسارات الطلبات باستخدام OpenTelemetry، وتسجّل الخدمات سجلاتها إلى Amazon CloudWatch.

الشكل 2: مخطط معماري يوضح دخول أحداث Slack إلى خدمة Slack ووقت تشغيل Amazon Bedrock AgentCore، مع مسارات منفصلة إلى قاعدة معرفة في Amazon Bedrock وأدوات Lambda مدعومة بـ AgentCore Gateway وJira Service Management وملاحظات DynamoDB.

عندما ينشر أحد الموظفين في قناة يكون Deckhand عضوًا فيها، تجمع خدمة Slack سجل المحادثة الكامل وسياق المستخدم. ثم تستدعي الوكيل عبر واجهة برمجة تطبيقات وقت تشغيل AgentCore. يبحث الوكيل في قاعدة المعرفة ويستدعي الأدوات حسب الحاجة. عندما يجد إجابة، يعيد ردًا نهائيًا (الشكل 3). وعندما لا يجدها، يطرح سؤالًا للتوضيح أو يعرض إنشاء تذكرة (الشكل 4).

الشكل 3: Deckhand يستجيب بخطوات الخدمة الذاتية

الشكل 4: Deckhand يعرض إنشاء تذكرة

سير عمل Deckhand

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

المتطلبات الأساسية

لتنفيذ هذا النمط، تحتاج إلى ما يلي:

• حساب AWS مع صلاحية الوصول إلى Amazon Bedrock ووقت تشغيل AgentCore وAgentCore Gateway.
• تطبيق Slack مع اشتراكات الأحداث، ومفتاح توقيع (signing secret)، ورمز بوت (bot token) محدد النطاق لحالة الاستخدام الخاصة بك.
• سجل صور حاويات مثل Amazon Elastic Container Registry (Amazon ECR).
• حاوية Amazon S3 وقاعدة معرفة في Amazon Bedrock.
• أدوار AWS Identity and Access Management (IAM) محددة النطاق لكل وقت تشغيل وأداة، وإدخالات في AWS Secrets Manager لبيانات الاعتماد الخاصة بالجهات الخارجية.

بناء الوكيل باستخدام Strands Agents وAgentCore

الوكيل خفيف الوزن بشكل مقصود. باستخدام Strands Agents SDKمفتوح المصدر، يتكون الوكيل من نموذج ومجموعة من الأدوات ورسالة نظام (system prompt). تدير حزمة SDK حلقة الاستدلال، مما يتيح للنموذج اختيار الأدوات ومعالجة النتائج والتكرار حتى يصل إلى إجابة. خدمة الوكيل في Deckhand مُنفّذة في بضعة أسطر من Python.

from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient
from strands_tools import retrieve
from mcp.client.streamable_http import streamablehttp_client

model = BedrockModel(
    model_id=MODEL_ID,
    max_tokens=2048,
    temperature=0.3,
)

gateway = MCPClient(lambda: streamablehttp_client(url=GATEWAY_URL))

agent = Agent(
    model=model,
    tools=[gateway, retrieve],
    system_prompt=SYSTEM_PROMPT,
)

يتم تعيين معرّف النموذج من خلال متغير بيئة، مما يسمح بتبديل النماذج دون تعديل كود التطبيق.

تُدمج الأدوات مع الوكيل بطريقتين. استرداد Amazon Bedrock Knowledge Bases هو أداة Strands أصلية تدعم البحث في قاعدة المعرفة باستيراد واحد. أما الدوال الأخرى، بما في ذلك التصنيف وإدارة التذاكر وتحديد هوية المستخدم وتحليل الصور، فتُعالج عبر دالة Lambda مسجلة على AgentCore Gateway. يعرض Gateway هذه الدوال كأدوات MCP، وتوجّه Lambda كل استدعاء حسب اسم الأداة. يتيح هذا الفصل تحديث منطق الأدوات بشكل مستقل، ويمكن للوكيل الوصول إلى أدوات جديدة من Gateway دون الحاجة إلى إعادة بناء.

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

تصميم قاعدة المعرفة وتوجيه الإجابات

يجيب Deckhand من قاعدة معرفة واحدة في Amazon Bedrock تضم مصادر بيانات أساسية مدعومة بـ S3:

• مقالات متزامنة من Confluence.
• صفحات داخلية وملفات PDF وأحداث متزامنة من شبكة الشركة الداخلية.
• سلاسل دعم تم حلها ومستخرجة من Slack (يُغطى ذلك في القسم التالي).

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

استخراج سجل Slack باستخدام نماذج اللغة التكرارية (RLMs)

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

تتبع عملية الاستخراج خط أنابيب من ثلاث مراحل (الشكل 5):

1. يقوم سكربت بتصدير السجل الكامل للقناة عبر Slack API، مسترجعًا الردود الكاملة لكل سلسلة وكاتبًا ملف تفريغ منظّم يتضمن علامات السلاسل والطوابع الزمنية وأعداد الردود.
2. يتعامل نموذج اللغة التكراري (RLM) من DSPy، الذي يشغّل Claude على Amazon Bedrock، مع ذلك الملف المصدَّر بوصفه فضاء ذاكرة قابلًا للتنقل داخل حلقة قراءة-تقييم-طباعة بايثون معزولة (REPL) وليس بوصفه مطالبة واحدة. ويعمل بشكل تكراري على البيانات، فيصنّف كل سلسلة على أنها محلولة أو غير محلولة أو مُحوّلة لجهة أعلى، ويفلتر الإعلانات وغير الأسئلة. وتُبقي المعايير الصارمة الجودة مرتفعة: لا تُعتبر السلسلة محلولة إلا عندما يكون الإصلاح الكامل والقابل للتطبيق ظاهرًا في السلسلة نفسها.
3. لكل محادثة محلولة، ينسّق نموذج RLM استدعاءات متكررة لنماذج لغوية فرعية (LLM) لاستخراج حقول منظمة، يُتحقق من صحة كل منها مقابل نموذج Pydantic. تشمل الحقول ملخص المشكلة، والسؤال الأصلي، والحل. كما تسجل ما إذا كان الإصلاح ذاتي الخدمة أو يتطلب تذكرة، وخطوات الخدمة الذاتية، والتطبيق والنظام المعنيين، ورسائل الخطأ، والوسوم. عندما يعيد استدعاء نموذج LLM فرعي نتيجة لا تتوافق مع المخطط، تلتقط حلقة RLM القائمة على الشيفرة خطأ التحقق في المفسّر وتعيد المحاولة. تُكتب النتائج كمستند markdown منظَّم حسب المشكلة. يرفع خط الأنابيب المستند إلى Amazon S3 ليفهرسه أساس المعرفة.

الشكل 5: سير عمل تصدير التصنيف والاستخراج لمحادثة Slack

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

معرفة متى لا يجب الإجابة

ي fails الروبوت الذكي في قناة مشتركة اجتماعيًا قبل أن يفشل تقنيًا. إن أكثر منطق Deckhand تطورًا يقرر متى يبقى صامتًا:

1. أول قرار يتخذه الوكيل بشأن كل رسالة هو ما إذا كانت إعلانًا أو رسالة اجتماعية أو محادثة بين أشخاص. إذا كان الأمر كذلك، يُخرج "SKIP"، وتمنع خدمة Slack الرد.
2. في المحادثات المترابطة، يرد فقط على الناشر الأصلي.
3. إذا كان آخر رد جاء من مساعد بشري آخر، يبقى صامتًا، لأن شخصًا ما قد تولى الأمر.
4. إذا بدأ ردٌ ما بذكر اسم شخص عبر @، فإن الرسالة ليست موجهة إلى الروبوت.

جمع الملاحظات

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

الملاحظات السلبية هي مجموعة بيانات قيّمة تُستخدم لتحسين موجه النظام وسلوك الوكيل، وتحديث معلومات أساس المعرفة غير الصحيحة.

الأمن والتحقق من الصحة

قواعد الموجِّه تعزّز السلوك لكنها لا تحل محل ضوابط الوصول. تتم إدارة التنفيذ عبر الشيفرة والبنية التحتية:

• يتطلب إنشاء التذاكر تأكيدًا صريحًا. عندما يعرض Deckhand إنشاء تذكرة، تضيف خدمة Slack زر Create Ticket ، ويؤدي اختياره إلى إرسال التأكيد عبر الوكيل. تقبل تحديثات التذاكر فقط المفاتيح الصالحة المطابقة لنمط مشروع مكتب المساعدة وترفض التعليقات الفارغة.
• يُتحقق من صحة التصنيف قبل تنفيذ أي إجراء. يعمل تصنيف الطلب كاستدعاء منفصل لـ Amazon Bedrock Converse API يعيد حقول تذكرة منظمة، يُتحقق من صحتها باستخدام Pydantic قبل وصول أي شيء إلى Jira.
• أداة الصور مقيّدة بالتنزيل من مضيف ملفات Slack فقط. تُصادق باستخدام رمز الروبوت، وتحد كل طلب بـ 5 صور بحجم يصل إلى 5 MB لكل منها، وترسل الملفات إلى نموذج رؤية باستخدام واجهة Converse API.
• تبقى بيانات الاعتماد خارج الشيفرة. تُخزَّن رموز Slack وسر التوقيع وبيانات اعتماد Jira في AWS Secrets Manager، وتعمل كل خدمة وأداة تحت دور IAM خاص بها بمحددات نطاق.
• يفرض الموجِّه ضمانات سلوكية: عدم طلب كلمات المرور أو رموز المصادقة متعددة العوامل (MFA) أبدًا، وعدم كتابة بيانات الاعتماد في تعليقات التذاكر أبدًا، وعدم كشف البيانات الوصفية للملف الشخصي المستخدمة في حقول التذاكر أبدًا.

النتيجة

أُطلق Deckhand في أبريل 2026. بدأ بنحو 30 رسالة يوميًا ووصل إلى 100 رسالة بحلول أوائل الصيف. في أول ثلاثة أشهر تعامل مع 1,935 رسالة، وبدأ 1,221 محادثة وكيل، وفتح 409 تذكرة Jira. رد على 97.5 في المائة من الرسائل. جاء ثلث الأسئلة خارج ساعات العمل، عندما لا يكون أحد من فريق تقنية المعلومات يعمل، وأجاب Deckhand على 94 في المائة منها. الأشخاص الذين كانوا سينتظرون حتى صباح الغد حصلوا على إجابتهم في تلك الليلة.

تحسّنت الملاحظات مع عمل الفريق على النظام. ارتفعت التقييمات الإيجابية من 82 في المائة في أبريل إلى 96 في المائة في يونيو، بعد أن راجعوا موجِّه النظام وأساس المعرفة لإصلاح ما اشتكى منه الناس.

كان النجاح الأوضح هو تحويل التذاكر عن المسار. محادثة الوكيل هي سؤال كان سيصبح في غير ذلك تذكرة Jira. من بين 1,221 محادثة، تحولت 409 فقط إلى تذاكر. أما الـ 812 الأخرى فتم التعامل معها في الدردشة. تستغرق عملية إيداع تذكرة ثم العمل عليها وإغلاقها نحو 30 دقيقة. تلك المحادثات الـ 812 تُعادل ما مجموعه نحو 406 ساعات على مدى ثلاثة أشهر، أو حوالي 1,600 ساعة في السنة. احتفظ الموظفون بذلك الوقت لأعمالهم الخاصة، ولم تنفقه تقنية المعلومات أبدًا على الاستلام.

الخاتمة

تولّى Deckhand الأسئلة التقنية المتكررة بدلاً من الموظفين، وأعاد الوقت إلى الموظفين وفريق تقنية المعلومات. وهو يعمل لأن كل مكوّن في الحزمة لديه مهمة واحدة ويعمل كخدمة مُدارة: فبيئة AgentCore runtime تستضيف الوكيل، وبوابة AgentCore Gateway تحوّل دالة Lambda إلى أدوات MCP يمكن للوكيل استدعاءها، وتتولى Amazon Bedrock Knowledge Bases عملية الاسترجاع. وأطلق الفريق الحل دون الحاجة إلى إعداد خوادم أو صيانة كود التنسيق.

ل构建 حل مماثل، ابدأ بمصدر معرفة تتم صيانته جيدًا وإجراء محدد بوضوح. راجع وثائق Amazon Bedrock AgentCore و Strands Agents SDK لتطوير الوكلاء، و وثائق Amazon Bedrock Knowledge Bases لربط مصادر المحتوى.

لمناقشة حالة استخدام للذكاء الاصطناعي الوكيل لمؤسستك، تواصل مع فريق حساب AWS الخاص بك.

نبذة عن المؤلفين