من البيانات إلى القرارات: ذكاء تحادثي لسلاسل التوريد باستخدام Amazon Quick و Amazon Bedrock AgentCore

منح فرق سلاسل التوريد وصولاً مباشراً إلى الأنظمة التي تقوم قراراتها عليها.

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

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

هل يمكن بدلاً من ذلك أن يسأل هذا المدير بلغة طبيعية ويحصل على إجابة قابلة للتنفيذ وعبر الأنظمة في ثوانٍ؟ يعمل Amazon Bedrock AgentCore كطبقة الذكاء، حيث يعرض خوادم Model Context Protocol (MCP) للمؤسسة كطبقة أدوات قابلة للتركيب. ويحوّل Amazon Quick ذلك إلى إجراء لشخصيات الاستخدام دون أي إعداد. تأتي الإجابات من أنظمة السجلات الحية ومن الوثائق المستندية، لا من ذاكرة النموذج، وكل تغيير ينتظر موافقة شخص محدد بالاسم. في هذا المقال، نستعرض هذا النمط من البداية إلى النهاية، من استعراض تحادثي في Amazon Quick إلى طبقة أدوات AgentCore خلفه، ونوضح لك كيفية نشره بنفسك.

المشكلة: غنى بالبيانات، فقر بالرؤى

الشكل 1: تتمثل الخبرة المختصة لدى المستخدمين بينما تكون البيانات التشغيلية مجزأة بين ERP والمراقبة والمشتريات والبريد الإلكتروني

يتطلب كل سؤال أداة خاصة به: المخزون من نظام تخطيط موارد المؤسسات (ERP)، والاضطرابات من البريد الإلكتروني أو الأخبار، وطلب عرض أسعار (RFQ) من المشتريات، والامتثال من قائمة تحقق. وترتبط هذه العناصر يدوياً.

يوم في حياة العمل

يمتد صباح المدير تقليدياً عبر نظام ERP (استثناءات المخزون)، وأداة المراقبة (التنبيهات)، والمشتريات (البديلة)، والبريد الإلكتروني (RFQ)، وجدول متابعة: من 45 إلى 60 دقيقة عبر خمسة أنظمة مع أكثر من عشر انتقالات بين السياقات.

وبشكل تحادثي، الأمر ثلاث مطالبات في أداة واحدة: "هل هناك أي اضطرابات حرجة تؤثر على أصناف SKU الأعلى إيراداً لديّ؟" → "قيّم توقف TechComp وأصدر RFQ طارئاً إلى البدائل المعتمدة" → "يبدو جيداً. أرسله."، وذلك في دقائق.

الشكل 2: التدفق التقليدي متعدد الأدوات مقابل خيط تحادثي واحد تنسّقه AgentCore

تعمق: استعراض سيناريو سلسلة التوريد

تتبع الخطوات الخمس التالية اضطراباً واحداً من الاكتشاف حتى RFQ طارئ معتمد، وذلك كله في محادثة واحدة على Amazon Quick.

الخطوة 1: الاكتشاف – "ما الأدوات المتاحة لديّ؟"

يسأل المستخدم "ما أدوات سلسلة التوريد المتاحة لديّ؟" فيعرض Amazon Quick خوادم سلسلة التوريد MCP المنشورة في AWS Agent Registry. ونظراً لأن أحد المسؤولين قد فعّل تكامل السجل، تظهر خوادم MCP الأربعة الخاصة بالأعمال بالفعل كبطاقات موصلات، مع تفاصيل الاتصال معبأة مسبقاً ودون الحاجة لإدخال أي عناوين URL يدوياً. ويُضاف وكيل التنسيق كموصل MCP مستقل بذاته.

الخطوة 2: الاستعلام – "أرني الاضطرابات النشطة"

يستدعي أمر "تحقق من اضطرابات التوريد النشطة" خادم Disruption Alerts MCP (assess_disruption_impact): ثلاثة اضطرابات مع درجة الخطورة والمنطقة وأعداد أصناف SKU. كيف نحل المشكلة: يوجّه Quick الطلب عبر AgentCore إلى خادم MCP، الذي يستعلم أنظمة المراقبة الخلفية ويعيد نتيجة منظمة، دون لوحة معلومات أو تصدير.

الخطوة 3: التعمق – "قيّم الحالة الحرجة"

يفتح المستخدم TechComp Production Halt. assess_disruption_impact(disruption_id="DISR-002") يربط بيانات الطلبات والعملاء والمخزون ببعضها: 750K دولار معرضة للخطر، 23 طلباً، وثلاثة أيام من التوريد. كيف نحل المشكلة: استدعاء واحد لأداة MCP يتفرع عبر أنظمة السجلات، فيحصل المدير على قراءة موحدة للأثر دون لمس نظام ERP.

الخطوة 4: الإجراء – "احصل على توصيات التخفيف"

يطلب المستخدم توصيات للتخفيف. recommend_mitigation(disruption_id="DISR-002") يربط Governance MCP (التحقق من البدائل المعتمدة) و Quoting MCP (عرض سعر متوافق مع العقود)، في تدفق واحد من طلب واحد. كيف نحل المشكلة: يخطط الوكيل ويسلسل الاستدعاءات، بحيث يمتد طلب واحد عبر الاضطراب والحوكمة وعروض الأسعار دون أي تمرير يدوي.

الخطوة 5: المتابعة الآلية

ثم يهيئ المستخدم مراقبة استباقية ("نبّهني كل صباح إذا ظهر اضطراب حرج جديد"). ويمكن تشغيل التدفق نفسه دون تدخل بشري من بريد إلكتروني وارد من مورد. كيف نحل المشكلة: يعمل الوكيل نفسه والأدوات نفسها وفق جدول زمني أو مشغل بريد إلكتروني، مع نشر بطاقات جاهزة للمراجعة في Activity Feed ليقوم شخص ما بالموافقة عليها.

وإذا وضعناها من البداية إلى النهاية، فإن تلك الخطوات الخمس تشكل تسلسل تشغيل واحدًا:

الشكل 3: تسلسل التشغيل للاستعراض التوضيحي، حيث تعود كل نتيجة إلى Amazon Quick للموافقة عليها

معمارية الحل

تلك هي التجربة. أما كيف تم بناؤها فهذا ما يلي: يفصل النمط بين طبقة الذكاء وطبقة الواجهة، بحيث تتطور كل منهما بشكل مستقل، مع Amazon Quick كواجهة وAgentCore كطبقة الذكاء.

الشكل 4: المعمارية من البداية إلى النهاية من Amazon Quick إلى AgentCore (Gateways وRuntime وIdentity وPolicy) إلى الأنظمة الخلفية، مع AWS Agent Registry إلى جانبها

Amazon Bedrock AgentCore: طبقة الذكاء

Amazon Bedrock AgentCore هي منصة وكلاء معيارية لبناء ونشر وتشغيل الوكلاء بأمان وعلى نطاق واسع. وهي تقدم أكثر مما نستخدمه هنا. أربع خدمات منها ذات صلة بنمط التصميم هذا:

• Runtime – استضافة بلا خوادم لخوادم MCP والوكلاء، مع عزل الجلسات وهوية مدمجة.
• Gateway – يحوّل واجهات API ووظائف AWS Lambda والخدمات إلى أدوات متوافقة مع MCP خلف نقطة نهاية مُدارة وآمنة، مما يوحّد الوصول إلى الأدوات. الاستدلال من مسؤولية الوكيل المستدعي.
• Identity – المصادقة وإدارة بيانات الاعتماد، مع توافق مع موفري الهوية الحاليين.
• Policy – قواعد تفويض حتمية، تُكتب باللغة الطبيعية أو بلغة Cedar، تتدخل في كل استدعاء أداة قبل التنفيذ، مما يُبقي الوكيل ضمن نطاقه فيما يتعلق ببيانات المشتريات والمالية.

بروتوكول MCP: كيف تتواصل الأدوات

MCP هو معيار مفتوح لكيفية تفاعل نماذج الذكاء الاصطناعي مع الأدوات الخارجية. يعرّض كل خادم أدوات بمعاملات مُنمّطة:

{
  "server_name": "sc-disruption-alert-gateway",
  "tools": [{
    "name": "assess_disruption_impact",
    "parameters": {
      "disruption_id": {"type": "string"},
      "context": {"type": "object"} // order, inventory, revenue data
    }
  }] // plus classify_severity, recommend_mitigation, get_escalation_chain
}

هذا يعني:

• يمكن لعملاء الذكاء الاصطناعي (Quick، ووكلاء مخصصون، وتطبيقات MCP أخرى) استهلاك نفس الخوادم.
• يمكن تغليف الأنظمة الخلفية (SAP وOracle والخدمات المصغرة المخصصة) كخادم MCP.
• اكتشاف الأدوات تلقائي. يستعلم العملاء عن المخططات من السجل وقت التشغيل.

AWS Agent Registry: طبقة الاكتشاف

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

الشكل 5: نشر سجل خادم MCP إلى AWS Agent Registry، وموافقة أمين التحريرو ربطه من قبل مسؤول إلى Quick، وتحوّل السجلات المعتمدة إلى بطاقات موصلات

التنسيق متعدد الخطوات

طبقة الاستدلال هي وكيل على AgentCore Runtime، وهو سجل وكيل عبر عنوان الاستدعاء المباشر الخاص به من خلال موصل MCP مخصص، دون Lambda أو بوابة. هنا، إنه وكيل تنفيذ الطلبات (Order Fulfillment Agent). عند تلقي طلب واحد، يخطط لأي الأدوات سيستدعي وبأي ترتيب:

User: "A supplier just went down. Find alternatives, verify compliance, issue an emergency RFQ."
Disruption Alerts MCP -> identify the disruption
Governance MCP -> approved alternatives + compliance + budget authority
Quoting MCP -> contract-aligned quote
-> one consolidated recommendation

معمارية الأمان والحوكمة

كل استدعاء أداة يمر عبر نفس مجموعة ضوابط AgentCore قبل أن يصل إلى النظام الخلفي.

الشكل 6: مجموعة ضوابط AgentCore الموحدة أمام النظام الخلفي (مصادقة IAM، وتفويض لكل أداة، والتحقق من المدخلات، وتقييم السياسات، وتحديد المعدل، وفرض حدود البيانات، وتسجيل التدقيق)

خوادم MCP في هذا النمط

Amazon Quick: المساعد الذكي للمؤسسات

يضع Amazon Quick أدوات AgentCore بين يدي مستخدمي الأعمال من خلال الدردشة والوكلاء وخيار Activity Feed وسير العمل المؤتمتة، دون أي إعداد تقني.

المكونات الرئيسية المستخدمة

خلاصة النشاط الآلية والمراقبة الاستباقية

إن Activity Feed هي الواجهة الاستباقية لـ Amazon Quick، وهي صندوق وارد موحّد ينشر فيه الوكلاء النتائج والتنبيهات والتوصيات. عناصر الخلاصة هي:

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

كيف تعمل المراقبة الآلية

أدوات AgentCore مع القدرات الاستباقية لـ Amazon Quick توفر مسارين، قائم على الوقت وآخر مدفوع بالبريد الإلكتروني، عبر خط أنابيب مشترك: مُحفِّز ← وكيل ← مخرجات.

الشكل 7: خط أنابيب من ثلاث مراحل من المُحفِّز (جدولة أو بريد إلكتروني) إلى وكيل مستقل (assess_disruption_impact، check_supplier_approval، apply_approval_rules، validate_quote) إلى بطاقة جاهزة للمراجعة

حالة الاستخدام: التحقق من ردود الموردين من البريد الإلكتروني

يرد الموردون على طلب تسعير عاجل (RFQ) عبر البريد الإلكتروني مع الأسعار. يتحقق الوكيل من كل رد (هل المورد معتمد؟ هل هو ضمن الإرشادات؟) ويجهز النتيجة. لا يقوم الوكيل بإعداد عرض سعر، ولا اختيار فائز، ولا إصدار أمر شراء (PO).

المرحلة 1: الإعداد (مرة واحدة، حوالي 5 دقائق)

1. ربط Outlook: في Amazon Quick، اختر Settings → Connections → Add Outlook.
2. تكوين Activity Feed: فعّل مراقبة البريد الإلكتروني في تفضيلات الخلاصة.
3. إنشاء SC Agent: ابنِ وكيلاً بهذه التعليمات:

Supply chain procurement assistant. On a supplier RFQ reply with pricing: 1) extract SKU(s), quantities, pricing; 2) validate approved vendor (Governance MCP); 3) check pricing within guidelines (Quoting MCP); 4) post a review-ready card (approved-supplier, within-guidelines); do NOT draft a PO or select a supplier.

1. إنشاء جدولة: "كل 2 ساعة خلال ساعات العمل، تحقق من ردود الموردين الجديدة وتحقق من صحتها."

المرحلة 2: وقت التشغيل (مؤتمتة بالكامل)

Schedule -> email from "TechSupply Co" (MCU-7200, 10,000 units @ $2.45/unit) -> Governance MCP: approved? | Quoting MCP: within guidelines? -> "Supplier Response - Ready for Review" card

تحمل بطاقة الموجز نتائج التحقق والحقائق ذات الصلة بالقرار:

المرحلة 3: الإنسان في حلقة القرار

يقارن المراجع الردود المعتمدة ثم إما يختار أحد الموردين ويصدر أمر الشراء، أو يرفض مع تسجيل السبب. يبقى الاختيار وأمر الشراء بيد شخص.

حالة الاستخدام: المراقبة الاستباقية للاضطرابات

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

أين يتناسب هذا مع ذكاء الأعمال التقليدي

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

الشخصيات المستهدفة وحالات الاستخدام

يخدم One Quick Agent الشخصيات الثلاث جميعًا: المدير يحافظ على الاستمرارية، والمشتريات تحصل على المصادر بوعي بالامتثال، والمحلل يربط الإشارات ببعضها. كما تُقيّد الشخصية نطاق الوصول، عبر الأمان على مستوى الصفوف/الأعمدة وتحديد نطاق أدوات MCP لكل شخصية، بحيث لا تصل المشتريات إلى بيانات المالية.

البداية

نشر النمط يتم على ثلاث مراحل: توفير البنية التحتية، وربط Amazon Quick ببياناتك وبالسجل، ثم تشغيل المراقبة.

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

قبل أن تبدأ:

• حساب AWS مع Amazon Bedrock AgentCore وAWS Agent Registry.
• واجهة سطر أوامر AWS (AWS CLI) الإصدار v2، وواجهة سطر أوامر AWS Serverless Application Model (AWS SAM)، وDocker (يعمل الوكيل كحاوية arm64).
• Python 3.12 أو أحدث، مع Boto3 1.43.94 أو أحدث لخطوة السجل.
• بيانات اعتماد نشطة مع أذونات AWS Identity and Access Management (IAM) للنشر والتسجيل (aws sts get-caller-identity يُرجع الحساب الهدف).
• طبقة البيانات: قاعدة بيانات (Snowflake أو PostgreSQL/RDS أو محرك SQLAlchemy)، ودلو Amazon S3، واختياريًا مؤسسة Salesforce.
• Amazon Quick مُهيأ لمؤسستك.
• (اختياري) حساب Outlook لأتمتة البريد الإلكتروني.

تتم عملية الإعداد على واجهتين، لذا تُسمّي كل خطوة من الخطوات التالية المكان الذي تحدث فيه: وحدة ويب Amazon Quick في المتصفح (أذونات Amazon Quick Sight، وربط Agent Registry، والموصلات، وإعدادات الوكيل) وتطبيق Quick Desktop App (ربط Outlook لأتمتة البريد الإلكتروني). التجربة الحوارية في Desktop App تأتي في الأخير، بعد اكتمال الإعداد.

نشر البنية التحتية

كل شيء مفتوح المصدر ومُبرمَج نصيًا: استنسخ مثال quick-for-supply-chain في مستودع aws-samples/sample-amazon-quick-suite-knowledge-hub واتبع README.md، أو وجّه إليه وكيل برمجة مثل Kiro.

تغطي README.md ثلاث مراحل. المرحلة 1 تنشر حزمة AgentCore: طبقة الهوية (مجموعة مستخدمي Amazon Cognito وعميل تطبيق، وتدفق OAuth برمز التفويض، بالإضافة إلى مستخدم تجريبي)، وأربعة خوادم MCP لقواعد العمل (كل منها وظيفة AWS Lambda مدعومة ببوابة AgentCore Gateway خاصة بها، وهي إحدى إمكانات Amazon Bedrock AgentCore، باستخدام CUSTOM_JWT للتفويض)، وأهداف البوابات التي تربط أدوات كل وظيفة Lambda، و sc-order-fulfillment-agent على AgentCore Runtime كحاوية، مع أدوار IAM ذات الامتيازات الأقل. المرحلة 2 ترفع مجموعة البيانات الاصطناعية إلى Amazon S3. المرحلة 3 تتحقق من أن البوابات وRuntime في حالة Ready. ويتم اعتماد ستة سجلات في Agent Registry.

الشكل 8: وحدة تحكم AWS Agent Registry مع ستة سجلات معتمدة (أربعة MCP Server، وواحد Agent، وواحد Skills)

منح Amazon Quick صلاحية الوصول إلى بياناتك

في وحدة ويب Amazon Quick (المتصفح): امنح Amazon Quick صلاحية الوصول من صفحة إدارة Amazon Quick Sight (Manage Quick Sight ← Security and permissions) إلى كلٍ من دلو S3 وAmazon Athena، نظرًا لأن كل جدول يُقدَّم عبر مصدر Athena فوق قاعدة بيانات AWS Glue. بدون منح صلاحية Athena، يفشل إنشاء مجموعة البيانات.

الشكل 9: Security and permissions في Amazon Quick Sight، مع Amazon Athena بجانب Amazon S3

ربط السجل وإنشاء الموصلات

ربط السجل إجراء يُنفَّذ مرة واحدة وعلى مستوى المسؤول. أما إنشاء موصل فهو لكل مستخدم. وكلاهما يتم في وحدة تحكم Amazon Quick. انظر دليل تكامل AWS Agent Registry.

ربط السجل (مسؤول، لمرة واحدة)

يقوم المسؤول بربط سجل واحد من Agent Registry بحساب Quick. في وحدة تحكم الويب Amazon Quick (المسؤول): انتقل إلى Manage account ← Permissions ← AWS Agent Registry وفعّل السجل (sc-supply-chain-registry، واحد لكل حساب). تظهر فقط السجلات الموجودة في حسابك ومنطقتك، في نطاق الأسماء agent-registry، مع تفويض AWS_IAM (SigV4)، وحالة READY. يقوم دور الخدمة المُدار من Quick بربطه.

الشكل 10: ربط السجل، حيث لا يمكن اختيار إلا السجلات ذات الحالة READY و AWS_IAM

إنشاء موصل (connector)

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

في وحدة تحكم الويب Amazon Quick (لكل مستخدم): تظهر البطاقات الأربع في صفحة Connectors (sc-quoting-mcp, sc-governance-mcp, sc-invoice-processing-mcp, sc-disruption-alert-mcp). قم بالمصادقة عبر مسار رمز التفويض OAuth (OAUTH2_AUTHORIZATION_CODE) باستخدام معرّف العميل والسر ومعرّف التوكن وعناوين URL للتفويض وإعادة التوجيه الواردة من سكربت النشر. سجّل الدخول كمستخدم الاختبار، وفعّل الأدوات، وأنشئ وشارك.

الشكل 11: بطاقات موصلات MCP الأربعة للأعمال، مع إضافة وكيل تنفيذ الطلبات يدويًا

الموصلات المستمدة من السجل هي موصلات Custom MCP (وهذا مهم لأذونات custom). إزالة الربط لاحقًا لا يؤدي إلى حذف الموصلات التي تم إنشاؤها مسبقًا.

الشكل 12: خطوة Authenticate باستخدام مسار OAuth لرمز التفويض (OAUTH2_AUTHORIZATION_CODE)

إضافة موصل وكيل تنفيذ الطلبات

في وحدة تحكم الويب Amazon Quick: لأنه سجل وكيل، أنشئ موصله يدويًا (Connectors ← Create for your team ← Model Context Protocol ← Create new): سمّه sc-order-fulfillment-agent، ووجّهه إلى عنوان URL للاستدعاء المباشر لـ AgentCore Runtime الوارد من سكربت النشر، وأكمل نفس تسجيل الدخول عبر OAuth، ثم أنشئ وشارك.

الشكل 13: إنشاء موصل sc-order-fulfillment-agent، موجّهًا إلى عنوان URL للاستدعاء في AgentCore Runtime

قم بتوصيل الموصلات بوكيلك

ينشئ هذا النشر وكيل سلسلة التوريد: مساحة Quick Space، ومجموعات بيانات مستوردة وقاعدة معرفة S3، والوكيل مع التعليمات والبدء السريع والرسالة الترحيبية. ما يتبقى هو ربط الموصلات.

في وحدة تحكم Amazon Quick على الويب (إعدادات الوكيل): افتح وكيل Supply Chain الذي أنشأته عملية النشر (المعرّف الافتراضي sc-supply-chain-agent) وقم بتوصيل جميع الموصلات الخمسة (أربعة MCPs للأعمال بالإضافة إلى sc-order-fulfillment-agent")، أو مرر معرّفات الموصلات الخمسة إلى سكربت الإعداد.

إعداد المراقبة الاستباقية

ولجعله استباقياً، يشغّل Quick الوكيل نفسه وفق جدول زمني أو عند وصول بريد إلكتروني، وينشر النتائج في Activity Feed. وكلا المسارين يعيد استخدام الوكيل والأدوات التي قمت بإعدادها.

في تطبيق Quick Desktop (الإعدادات ← الاتصالات): قم بربط Outlook وتفعيل مراقبة البريد الإلكتروني. ثم، في Quick Chat، أنشئ جدولين باللغة الطبيعية: جدول زمني ("كل صباح، تحقق من الانقطاعات الحرجة الجديدة") وجدول مدفوع بالبريد الإلكتروني ("كل ساعتين خلال ساعات العمل، تحقق من ردود الموردين وتحقق من صحتها"). يستخرج الوكيل الأسعار، ويجري الفحوصات، وينشر بطاقة.

جرّبه في Amazon Quick

بعد أن يصبح الوكيل والموصلات جاهزين، اسأل بلغة طبيعية في Amazon Quick Chat. كل مطالبة توضح نمط البيانات-ثم-القواعد.

الخلاصة

يشكّل AgentCore وAmazon Quick نمطًا قابلًا للتكرار للذكاء الاصطناعي المؤسسي: فصل الذكاء عن الواجهة. يحوّل AgentCore الأنظمة الخلفية المجزأة إلى طبقة مركّبة قابلة للحوكمة ويمكن للذكاء الاصطناعي الوصول إليها من خلال واجهات MCP القياسية. ويعمّم Amazon Quick الوصول باللغة الطبيعية.

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

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

عن المؤلفين