ACP مصفوفة الاختبار والدعم

ACP ثنائي الاتجاه. يجب أن يحافظ اختبار التوافق التشغيلي المفيد على اتصال واحد مفتوحًا بينما تصل الإشعارات والطلبات المتداخلة؛ إذ إن سلسلة من JSON المنفصلة لا يمكنها إثبات سلوك الجلسة.

الاختبارات التي تم التحقق منها

تتصل حزمة adk-acp بـ SDK الرسمي Client إلى ADK-Rust SDK Agent عبر ناقل في الذاكرة وتختبر:

initialize
  → session/new
  → session/prompt
  ← session/update
  ← PromptResponse(end_turn)
  → session/close
  → session/list
  → session/resume
  → session/close
  → session/delete

تغطي اختبارات منفصلة إلغاء الجلسة، وإلغاء الطلبات والاسترداد بين JSON-RPC، وتعيين الأحداث، وقوائم أذونات الرفض أولًا، ومعرّفات الخيارات الغامضة، والاختيارات المصطنعة، ولوكاء القرار البشري، وسلوك السماح مرة واحدة للاستدعاء الدقيق، والتحقق من صحة إعدادات MCP، ومخرجات التصحيح المنزوعة الأسرار. تضيف المرحلة 2 اختبارات ترتيب إعادة التشغيل لـ session/load (تطابق session/update المعاد تشغيلها الترتيب الزمني للأحداث المخزنة)، واختبارات تعيين المطالبات متعددة الوسائط ورفضها (تُقبل الصور والصوت؛ ويُرفض المحتوى غير المعلن)، واختبارات approve/deny/cancel لجسر أذونات الخادم (يُطابق الإلغاء الرفض، مع الربط بواسطة معرّف استدعاء الدالة)، واختبارات موثوقية العميل التي تثبت ظهور واجهتي ToolCallUpdate وUsageUpdate دون إرجاع سطح النص الخاص بالوكيل. تضيف المرحلة 3 اختبارات وضع الجلسة وخيارات الإعدادات (تسجل set_mode / set_config_option القيم المعلنة وترفض غير المعروفة منها، وتستمر عملية الاختيار عبر session/load)، واختبار عزل session/fork (يكون سجل الشعبة مساويًا لسجل المصدر ويظل المصدر دون تغيير)، واختبارات تفعيل الأوامر المتاحة ومعلومات الجلسة (لا تُرسل التحديثات إلا عندما يعلن الوكيل عن الأوامر أو يسجل عنوانًا)، واختبار دقة القدرات الذي يؤكد أن القدرات المعلنة تطابق تمامًا المعالجات المسجلة وتعيينات المحتوى الممكّنة — بما في ذلك أن الأوضاع وخيارات الإعدادات لا تُعلن إلا عند وجود موفر SessionControls.

تبدأ بوابة دورة حياة MCP الحية طفل MCP حقيقيًا عبر stdio، وتكمل المصافحة، وتكتشف أدواته من خلال نفس McpToolset المستخدم بواسطة جلسات ACP.

تشغيل البوابات

cargo test -p adk-acp --all-features
cargo test -p adk-agent --test tool_confirmation_tests
cargo test -p adk-tool --features mcp --test mcp_server_lifecycle_integration_tests test_tool_aggregation -- --ignored --exact

cargo test --manifest-path examples/acp_client_host/Cargo.toml
cargo check --manifest-path examples/acp_kiro/Cargo.toml
cargo check --manifest-path examples/acp_server/Cargo.toml
cargo test --manifest-path examples/acp_full_protocol/Cargo.toml

بوابة acp_full_protocol هي شبكة الأمان القابلة للتشغيل في المرحلة 2: API-key، Runner-backed AcpServer يُدار عبر SDK الرسمي خلال قناة داخل العملية، مع التحقق من سطح المرحلة 2 الكامل باتجاه الخادم (مطالبات الموارد المضمّنة والصور/الصوت، وجسر الأذونات، وترتيب إعادة التشغيل لـ session/load، وإظهار UsageUpdate / ToolCallUpdate) دون عملية فرعية أو بيانات اعتماد النموذج.

الدعم الحالي

اختبار المحرر اليدوي

قم ببناء examples/acp_server، ثم اضبط عميل ACP لبدء ذلك الملف الثنائي مع مسار بيان مطلق وبيانات اعتماد النموذج. تحقّق مما يلي:

1. تعرض استجابة التهيئة إصدار البروتوكول 1؛
2. تقبل جلسة جديدة دليل المشروع المطلق المقصود؛
3. يظهر النص كتحديثات حيّة قبل الاستجابة النهائية؛
4. تبدأ أداة القراءة وتظهر الإكمالات في العميل؛
5. يؤدي الإلغاء إلى إغلاق الجولة دون إغلاق الاتصال؛
6. تنجح مطالبة لاحقة في الجلسة نفسها؛
7. يحافظ الإغلاق والاستئناف على السجل عندما تكون خدمة الجلسة دائمة.

لا تستخدم echo | cargo run لهذا الاختبار. كل أنبوب يبدأ عملية مختلفة ولا يمكنه الحفاظ على الاتصال أو الجلسة.

أمثلة ذات صلة

• acp_client_host
• acp_kiro
• acp_server
• acp_full_protocol — مرجع اتجاه الخادم للمرحلة 2 بلا مفتاح API، ومدعوم بـ Runner مع اختبار تحققي شامل من البداية إلى النهاية