التجارة الوكيلية: كيف تخلي وكلاء الذكاء الاصطناعي يشترون بأمان

ليش هذا الموضوع مهم هلق

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

بس لحظة ما الوكيل يقدر يصرف مصاري، كل شي يتغير. وكيل دعم عملاء يحجز العرض الغلط. وكيل سفر يحجز 50 مقعد بدال 5. مساعد تسوق يطلب منتج المورد ما عاد يوفره. هذي مش سيناريوهات خيالية. هذي النتيجة المتوقعة لما تربط LLM بـ API دفع بدون حوكمة.

بنينا بروتوكول لهذا الموضوع. سميناه بروتوكول الدفع الوكيلي (ACP). يحكم كيف وكلاء الذكاء الاصطناعي يبدأون ويتحققون ويكملون معاملات التجارة ضمن منصة متعددة المستأجرين. هذا المقال يشرح البنية من الصفر.

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

المشكلة الأساسية

تدفقات الدفع التقليدية تفترض إن بشري هو اللي ياخذ القرار. الباكند حق التاجر يستدعي API الدفع بـ API key، الطلب يتحقق منه، الدفع يتأكد. البشري هو المسؤول.

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

الحل مش "لا تخلي الوكلاء يشترون شي." الحل هو بروتوكول يحكم كل خطوة.

بروتوكول الدفع الوكيلي

الـ ACP يجمع خمس أنظمة في إطار ثقة واحد:

┌─────────────────────────────────────────────────────────┐
│                   تدفق ACP                               │
│                                                          │
│  المستخدم: "احجز الأسد الملك لشخصين بالغين يوم السبت"   │
│                         │                                │
│                         ▼                                │
│  ┌─────────────────────────────────┐                    │
│  │  1. طبقة أدوات MCP              │                    │
│  │  الوكيل يستدعي createCheckout()│                    │
│  │  عبر Model Context Protocol    │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  2. محرك السياسات               │                    │
│  │  تحقق: هل هذا الوكيل مسموح    │                    │
│  │  له يحجز من هذا المورد؟        │                    │
│  │  هل القيمة ضمن الحدود؟         │                    │
│  │  النتيجة: سماح أو رفض          │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│            سماح │         رفض ──▶ خطأ للوكيل            │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  3. بوابة الموافقة البشرية      │                    │
│  │  إذا قيمة الطلب > الحد:        │                    │
│  │  تعليق سير العمل، إشعار العمليات│                   │
│  │  انتظار موافقة بشرية           │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│              موافقة                                      │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  4. تنفيذ المورد                │                    │
│  │  حجز المخزون                    │                    │
│  │  تأكيد الحجز عبر المورد         │                    │
│  │  توليد إيصال HMAC               │                    │
│  └──────────────┬──────────────────┘                    │
│                 │                                        │
│                 ▼                                        │
│  ┌─────────────────────────────────┐                    │
│  │  5. سجل التدقيق                 │                    │
│  │  كتابة سجل غير قابل للتغيير    │                    │
│  │  actor_type: "agent"            │                    │
│  │  thread_id, tenant_id, receipt  │                    │
│  └─────────────────────────────────┘                    │
│                                                          │
└─────────────────────────────────────────────────────────┘

كل مكون له قيمة مستقلة. مع بعض، يشكلون إطار حوكمة كامل للتجارة المبدوءة بالذكاء الاصطناعي.

المكون 1: طبقة أدوات MCP

الوكيل ما يستدعي الـ APIs مباشرة. يستخدم أدوات MCP (Model Context Protocol) مسجلة مع إطار عمل الوكيل. كل أداة هي نقطة دخول محكومة بتحقق المدخلات وتطبيق السياسات وتسجيل التدقيق.

// تعريف أداة MCP لإنشاء عملية دفع
const createCheckoutTool = createTool({
    id: 'createCheckout',
    description: 'Create a checkout for a product booking',
    inputSchema: z.object({
        productId: z.string(),
        date: z.string().datetime(),
        persons: z.array(z.object({
            type: z.enum(['adult', 'child', 'senior']),
            count: z.number().int().positive(),
        })),
    }),
    execute: async ({ productId, date, persons }, ctx) => {
        // 1. تحقق إن المنتج موجود في فهرس البحث
        const product = await searchApi.getProduct(ctx.tenantId, productId);
        if (!product) throw new ToolError('Product not found');

        // 2. تحقق من السياسة
        const policy = await policyEngine.evaluate(
            ctx.tenantId, ctx.channelId, 'create_order',
            { productId, supplierId: product.supplierId, estimatedValue: product.price }
        );
        if (!policy.allowed) throw new ToolError(`Policy denied: ${policy.reason}`);

        // 3. ابدأ سير عمل الدفع
        return checkoutWorkflow.start({ productId, date, persons, ctx });
    },
});

الأداة تتحقق إن المنتج موجود فعلاً (تمنع الحجوزات المهلوسة)، تفحص السياسة قبل أي إجراء مالي، وتوجه لسير عمل محكوم. الوكيل ما عنده وصول مباشر لـ API المورد أبداً.

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

المكون 2: محرك السياسات

قبل أي إجراء مالي، محرك السياسات يقيّم قواعد خاصة بكل مستأجر. القواعد مخزنة لكل مستأجر ومحفوظة بالكاش مع TTL خمس دقائق.

interface PolicyRule {
    action: string;                    // "create_order", "cancel_order", "search"
    effect: "allow" | "deny";
    conditions: {
        max_order_value?: number;          // سقف صارم، رفض فوق هذا
        allowed_suppliers?: string[];      // تقييد أي موردين مسموحين
        require_human_approval_above?: number;  // حد HITL
        max_items_per_order?: number;      // منع الاحتيال بالجملة
    };
}

قواعد التقييم

1. قواعد الرفض لها الأولوية. إذا أي قاعدة رفض تطابقت، الإجراء يُرفض فوراً.
2. قواعد السماح مع شروط. إذا قاعدة سماح تطابقت، شروطها تُقيّم مقابل الطلب.
3. ما في قاعدة مطابقة = رفض. رفض افتراضي. الوكيل ما يقدر يسوي أي شي مش مسموح فيه بشكل صريح.

مثال على سياسة

{
    "tenant_id": "tenant_acme",
    "rules": [
        {
            "action": "create_order",
            "effect": "allow",
            "conditions": {
                "max_order_value": 5000,
                "allowed_suppliers": ["supplier_alpha", "supplier_beta"],
                "require_human_approval_above": 500,
                "max_items_per_order": 10
            }
        },
        {
            "action": "cancel_order",
            "effect": "allow",
            "conditions": {}
        },
        {
            "action": "search",
            "effect": "allow",
            "conditions": {}
        }
    ]
}

وكلاء هذا المستأجر يقدرون يبحثون بحرية، يسوون طلبات لحد 5,000 يورو (بس الطلبات فوق 500 يورو تحتاج موافقة بشرية)، يحجزون بس من موردين اثنين معتمدين، ويسوون طلبات بحد أقصى 10 عناصر. يقدرون يلغون طلبات بدون قيود. أي شي ثاني مرفوض.

محرك السياسات مقيد بالمستأجر. تجار مختلفين يحصلون على قواعد مختلفة. شركة كبيرة ممكن تحط حد الـ HITL عند 2,000 يورو. مشغل صغير ممكن يطلب موافقة لكل شي فوق 100 يورو. مشغل المنصة يحط سياسات افتراضية، والمستأجرين يقدرون يخصصون ضمن النطاق المسموح لهم.

المكون 3: بوابات الموافقة البشرية (HITL)

لما طلب يتجاوز حد require_human_approval_above، سير عمل الدفع يتعلق وينتظر موافقة بشرية.

// داخل سير عمل الدفع
async function checkoutWorkflow(ctx, params) {
    // الخطوة 1: حجز المخزون
    const reservation = await supplierAdapter.reserveInventory(
        ctx.tenantId, params.productId, params.date, params.persons
    );

    // الخطوة 2: تحقق إذا تحتاج موافقة بشرية
    if (reservation.totalPrice > policy.require_human_approval_above) {
        // تعليق سير العمل، إشعار لوحة العمليات
        const approval = await workflow.suspend({
            reason: 'Order exceeds approval threshold',
            totalPrice: reservation.totalPrice,
            threshold: policy.require_human_approval_above,
            productName: reservation.productName,
            reservationExpiresAt: reservation.expiresAt,
        });

        if (!approval.approved) {
            await supplierAdapter.cancelReservation(reservation.id);
            return { status: 'REJECTED', reason: approval.rejectionReason };
        }
    }

    // الخطوة 3: تأكيد الحجز
    const booking = await supplierAdapter.confirmBooking(reservation);

    // الخطوة 4: توليد الإيصال
    const receipt = generateHmacReceipt(booking, ctx.tenantId);

    // الخطوة 5: سجل التدقيق
    await auditLog.write({
        action: 'order_completed',
        actor_type: 'agent',
        thread_id: ctx.threadId,
        tenant_id: ctx.tenantId,
        order_id: booking.orderId,
        receipt_hmac: receipt.hmac,
    });

    return { status: 'COMPLETED', orderId: booking.orderId, receiptHmac: receipt.hmac };
}

سير العمل يستخدم suspend() و resume() من إطار عمل الوكيل. لما يتعلق، لوحة العمليات تعرض الطلب المعلق بكل تفاصيله. المشغل يقدر يوافق أو يرفض مع سبب. سير العمل يستأنف تلقائياً لما يتم القرار.

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

لمزيد عن الإشراف البشري في أنظمة الذكاء الاصطناعي، شوف دليلنا عن الذكاء الاصطناعي بإشراف بشري.

المكون 4: إيصالات HMAC

كل طلب مكتمل يولد إيصال مقاوم للتلاعب باستخدام HMAC-SHA256. هذا يوفر إثبات تشفيري لشو صار.

مواصفات الإيصال

حمولة الإيصال

interface ReceiptPayload {
    order_id: string;
    tenant_id: string;
    products: Array<{
        id: string;
        date: string;
        total_price: number;
    }>;
    total_price: number;
    currency: string;
    booker_email: string;
    created_at: string;  // ISO 8601
}

التوقيع

function generateHmacReceipt(order: Order, tenantId: string): Receipt {
    const payload: ReceiptPayload = {
        order_id: order.id,
        tenant_id: tenantId,
        products: order.items.map(item => ({
            id: item.productId,
            date: item.date,
            total_price: item.totalPrice,
        })),
        total_price: order.totalPrice,
        currency: order.currency,
        booker_email: order.bookerEmail,
        created_at: order.createdAt.toISOString(),
    };

    // JSON قانوني: مفاتيح مرتبة لمخرج حتمي
    const canonical = JSON.stringify(payload, Object.keys(payload).sort());
    const secret = await secretsManager.getTenantSecret(tenantId);
    const hmac = crypto.createHmac('sha256', secret).update(canonical).digest('hex');

    return { payload, hmac, signedAt: new Date().toISOString() };
}

التحقق

GET /v1/order/{orderId}/verify
Response: { valid: true, signed_at: "2026-06-15T14:30:00Z" }

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

المكون 5: سجل تدقيق غير قابل للتغيير

كل إجراء ACP يولد إدخال تدقيق. نظام التدقيق يستخدم بنية من مستويين:

المستوى 1: سجل تشغيلي (قاعدة بيانات، قابل للاستعلام، احتفاظ 90 يوم)

{
    action: 'order_completed',
    actor_type: 'agent',           // "agent" | "human" | "system"
    thread_id: 'thread_abc123',    // أي محادثة
    tenant_id: 'tenant_acme',
    channel_id: 'ch_web_en',
    order_id: 'ord_xyz789',
    total_price: 450,
    currency: 'EUR',
    supplier_id: 'supplier_alpha',
    receipt_hmac: 'a1b2c3...',
    policy_evaluated: true,
    hitl_required: false,
    created_at: '2026-06-15T14:30:00Z',
}

المستوى 2: أرشيف غير قابل للتغيير (تخزين كائنات مع كتابة مرة واحدة/قراءة متعددة، احتفاظ 7 سنوات)

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

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

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

ACP مقابل الدفع التقليدي

الـ Idempotency

المعاملات المبدوءة من الوكيل تحتاج idempotency على مستوى البروتوكول. إعادة محاولات الشبكة وإعادة محاولات الوكيل وإعادة تشغيل سير العمل ما لازم تسوي طلبات مكررة.

// مفتاح idempotency لعمليات الدفع المبدوءة من الوكيل
const idempotencyKey = `${tenantId}:${threadId}:${productId}:${date}`;

// تحقق قبل المعالجة
const existing = await idempotencyStore.get(idempotencyKey);
if (existing) {
    return existing.result;  // أرجع النتيجة المحفوظة
}

// عالج واحفظ
await idempotencyStore.acquire(idempotencyKey);
const result = await processCheckout(params);
await idempotencyStore.complete(idempotencyKey, result);
return result;

مفتاح الـ idempotency يجمع المستأجر، خيط المحادثة، المنتج، والتاريخ. نفس الوكيل في نفس المحادثة يحجز نفس المنتج في نفس التاريخ دائماً يرجع نفس النتيجة. خيط محادثة مختلف يحصل على مفتاح جديد.

المخزن يستخدم كتابات شرطية لمنع حالات السباق. إذا عاملين حاولوا يحجزون نفس المفتاح بنفس الوقت، بس واحد ينجح.

عزل المستأجرين

كل عملية ACP محدودة بمستأجر وقناة. التسلسل الهرمي للهوية يضمن عزل البيانات في كل طبقة:

Tenant (منظمة التاجر)
  └── Channel (واجهة المتجر أو قناة البيع)
       └── Customer (المستخدم النهائي)
            └── Session (جلسة المتصفح/الجهاز)
                 └── Agent Thread (محادثة واحدة)

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

هذا نفس نمط العزل متعدد المستأجرين اللي نوصفه في دليل بنية الأنظمة. الفرق في ACP إن الوكيل يضيف مستوى نطاق آخر: الخيط. ذاكرة الوكيل وسياقه محدودين بـ tenant_id + session_id + thread_id. وكيل A في مستأجر ما يقدر يشوف محادثة وكيل B في مستأجر ثاني.

شو ممكن يصير غلط

حتى مع ACP، في أوضاع فشل لازم نتعامل معها:

اعتبارات التنفيذ

متى تقدم ACP

مش كل تكامل تجارة بالذكاء الاصطناعي يحتاج البروتوكول الكامل. فكر بمستوى الاستقلالية:

ابدأ بالبحث فقط. أضف بناء السلة لما تتأسس الثقة. انتقل للدفع المساعد مع HITL على كل طلب. تخرج للدفع المستقل مع حدود HITL مبنية على السياسات بس بعد ما يكون عندك بيانات عن دقة الوكيل ومعدل الأخطاء يكون مقبول.

اختيارات التقنية

الـ ACP على مستوى البروتوكول، مش مربوط بتنفيذ معين. المكونات ممكن تُبنى بتقنيات مختلفة:

تصميم البروتوكول أهم من الأدوات المحددة. إذا نفذت المكونات الخمسة (حوكمة الأدوات، تقييم السياسات، بوابات الموافقة البشرية، إيصالات مقاومة للتلاعب، وتدقيق غير قابل للتغيير)، النظام آمن بغض النظر عن التقنية تحته.

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

الأخطاء الشائعة

1. تخلي الوكلاء يستدعون APIs الموردين مباشرة. طبقة أدوات MCP هي حدود الثقة. بدونها، ما عندك تطبيق سياسات ولا سجل تدقيق ولا idempotency.

2. سياسة السماح الافتراضي. الـ ACP يستخدم الرفض الافتراضي. إذا ما في قاعدة سماح صريحة لإجراء، يُرفض. السماح الافتراضي مع تجاوزات رفض أضعف لأنك لازم تتوقع كل إجراء سيء مسبقاً.

3. تخطي إيصالات HMAC. بدون إيصالات مقاومة للتلاعب، ما تقدر تثبت للتاجر أو الجهة التنظيمية إن الطلب ما تم تعديله بعد الحقيقة.

4. نفس صيغة مفتاح idempotency لكل العمليات. المفتاح لازم يتضمن السياق (الخيط، المنتج، التاريخ). مفتاح عام مثل order:123 ما يمنع وكيل مختلف في محادثة مختلفة من حجز نفس المنتج.

5. ما في انتهاء للحجز. إذا موافقة HITL أخذت وقت طويل، الحجز يحتفظ بالمخزون للأبد. دائماً حط وقت انتهاء وتعامل مع حالة انتهاء الوقت.

6. الثقة ببيانات المنتج اللي يوفرها الوكيل. الأداة لازم تتحقق إن المنتج موجود في فهرس البحث. الوكيل ممكن يهلس ID منتج أو سعر أو تاريخ توفر.

7. عدم عزل ذاكرة الوكيل لكل مستأجر. وكيل يخدم المستأجر A ما لازم يكون عنده وصول لسجل محادثات المستأجر B أو كتالوج منتجاته أو قواعد سياساته.

8. التعامل مع الدفع الوكيلي كميزة، مش بروتوكول. الـ ACP مش ميزة تضيفها فوق. هو إطار ثقة لازم يُصمم في النظام من البداية.

النقاط الرئيسية

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

• أداة MCP هي حدود الثقة. الوكيل ما عنده وصول مباشر للـ API أبداً. كل إجراء يمر عبر أداة محكومة تتحقق وتفحص السياسة وتسجل.

• سياسة الرفض الافتراضي غير قابلة للتفاوض. إذا ما في قاعدة سماح صريحة، الإجراء يُرفض. قواعد الرفض دائماً تتغلب على قواعد السماح.

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

• إيصالات HMAC تثبت شو صار. مفاتيح توقيع لكل مستأجر، تسلسل JSON قانوني، HMAC-SHA256 مشفر بالـ hex. قابل للتحقق من أي طرف عنده المفتاح السري.

• الـ Idempotency يمنع الطلبات المكررة. المفتاح لازم يتضمن سياق المحادثة (thread ID)، مش بس بيانات الطلب.

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

التجارة الوكيلية حتمية. السؤال هو إذا بتبني الحوكمة أول أو بتنظف الأضرار بعدين. بنينا ACP لأننا احتجناه لمنصة تجارة حقيقية متعددة المستأجرين مع موردين متعددين ووكلاء حجز مدعومين بالذكاء الاصطناعي. البروتوكول يشتغل. البنية مثبتة في الإنتاج.

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