1. مقدمة
يرشدك هذا الدرس التطبيقي حول الترميز إلى خطوات إنشاء أنظمة وكلاء من الجيل التالي باستخدام مهام سير العمل والرسومات البيانية في "حزمة تطوير الوكلاء" (ADK). ستنفّذ أنماطًا معمارية شائعة، وتنسّق تفاعلات "المشاركة البشرية"، وتتعامل مع عمليات التنفيذ غير المتزامنة التي تستغرق وقتًا طويلاً. ستدمج أيضًا قواعد بيانات المؤسسة المعرفية والذاكرة الثابتة لتخصيص سلوك الوكيل وتطويره. أخيرًا، ستربط هذه الإمكانات لإنشاء مسار مبرمَج لإنشاء الفيديوهات.
السيناريو
تدير قناة رقمية على VibeTube تضمّ جمهورًا نشطًا ولديها قائمة متزايدة من الأفكار الإبداعية. يتطلّب إنتاج كل فيديو تنفيذًا مستمرًا على مستوى مراحل متعددة: البحث عن أشكال المحتوى الرائجة، وتجميع ملاحظات المشاهدين، وكتابة النصوص، والتحقّق من الامتثال للسياسات، وإنشاء مقاطع الفيديو. يمكن للنماذج التوليدية إنشاء مسودات لأصول فردية، ولكنّ تقديم إصدارات متسقة يتطلّب بنية منظَّمة للوكيل.
لأتمتة دورة الحياة هذه، عليك إنشاء VibeStudio. ينفّذ مسار المعالجة المستنِد إلى الذكاء الاصطناعي الوكيل عمليات البحث الروتينية بالتوازي، ويعرض خيارات منتقاة للمراجعة البشرية، ويطبّق بوابات السياسات المبرمَجة قبل إنشاء الفيديو، ويحافظ على السياق في جميع عمليات الإنتاج.
ما ستتعلمه
- أساسيات تصميم الرسوم البيانية: تتطلّب بنى الوكلاء المتعدّدة الخطوات مسار تحكّم واضحًا ومسارات تنفيذ منظَّمة. يمكنك إنشاء
WorkflowADK باستخدام مجموعات الحواف، ونقطة الدخولSTART، وJoinNodeلتوزيع موسَّع متوازٍ، وعُقد التوجيه الحتمية لتوجيه التنفيذ استنادًا إلى الحالة. - أوضاع الوكيل وعمليات الرجوع عند انتهاء مراحل النشاط: تتطلّب المهام المتخصّصة سلوكيات تشغيلية مميّزة وضوابط محدّدة. يمكنك ضبط مثيلات ADK
Agentباستخدام أوضاعchatوsingle_turnوtaskالمفعّلة للأدوات كعُقد لسير العمل، وتطبيق أدوات الاعتراض باستخدامbefore_model_callbackوafter_agent_callback. - التنسيق مع الإشراف البشري: يتم إيقاف خطوط الإنتاج مؤقتًا للحصول على تقييم بشري عند نقاط التحقّق الإبداعية المهمة. يمكنك تنفيذ
RequestInputلتعليق تنفيذ سير العمل، وفرض مخططات الاستجابة المنظَّمة، واستئناف التنفيذ بدون إبقاء عمليات وقت التشغيل غير النشطة قيد التشغيل. - ذاكرة الوكيل الهرمية: تفصل أنظمة الإنتاج حالة التنفيذ المؤقتة عن السياق الدائم. يمكنك إدارة حالة الجلسة القصيرة الأمد باستخدام
Event(state=...)وربط المَعلمات، وربط "بنك الذاكرة" في GEAP لاستخراج إعدادات المفضّلة لصنّاع المحتوى وتوحيدها والاحتفاظ بها في جميع عمليات التشغيل. - الاستناد إلى قواعد المعرفة الخاصة بالمؤسسة: تحتاج الوكلاء المستقلون إلى سياق نطاق ديناميكي وآراء الجمهور. يمكنك ربط مجموعة مستندات RAG Engine في GEAP كعقدة استرجاع مخصّصة ضمن التوزيع الموسَّع المتوازي لتحديد المصدر الدلالي لمخرجات الوكيل.
- عمليات النشر وسير العمل الطويل الأمد: يتم عرض الفيديو المتعدد الوسائط بشكل غير متزامن على مدى فترات طويلة. يمكنك تنفيذ
LongRunningFunctionToolباستخدام إيصالات المكالمات المعلّقة لتعليق سير العمل واستئنافه حسب معرّف المكالمة، ونشر المسار المكتمل باستخدامRunnerفي "حزمة تطوير التطبيقات" على Cloud Run.
طريقة تنظيم هذا الدرس التطبيقي حول الترميز
يشكّل هذا الدرس التطبيقي حول الترميز مرجعًا مفاهيميًا ومعماريًا. يشرح كل قسم بنى ADK التي تم تنفيذها في خطوة ورشة العمل المقابلة، ويقدّم رمزًا مرجعيًا، ويضع مبادئ التصميم الأساسية. راجِع كل قسم قبل إكمال التمرين المناسب في مساحة العمل.
يتم تنفيذ العمل العملي في VibeStudio Workbench، وهي واجهة ويب مصاحبة تتضمّن محرّر رموز تفاعليًا وأدوات تحقّق من وقت التشغيل وأداة فحص مدمجة لحزمة تطوير الوكلاء (ADK). تتوافق أرقام الخطوات في مساحة العمل مباشرةً مع هذا الدرس التطبيقي حول الترميز للحفاظ على مزامنة مستوى تقدّمك. تظل تعديلات الرسم البياني الأساسي محفوظة في جميع الخطوات، مع تحقّق "بيئة العمل" تلقائيًا من المتطلبات الأساسية أثناء تقدُّمك.
بعد إكمال تمارين Workbench، ستتمكّن من تجميع مسار آلي شامل قائم على الوكلاء ونشر تطبيق VibeStudio قيد التشغيل على Cloud Run لإنشاء محتوى فيديو.
تتكوّن البيئة من ثلاثة مكونات أساسية: VibeStudio Workbench (واجهة الويب المحلية لتعديل الرموز والتحقّق من وقت التشغيل)، والخادم الخلفي (حزمة تطوير التطبيقات Workflow ومساحات الاختبار المؤقتة في agent/)، وGoogle Cloud (نماذج Gemini وGEAP Memory Bank وRAG Engine وإنشاء فيديوهات Veo).
2. الإعداد
المطالبة برصيد ورشة العمل
إذا كنت تحضر مختبرًا بإشراف معلّم، سيوزّع المعلّم الأرصدة على مشروعك على Google Cloud. اتّبِع تعليمات المدرّب لتحصيل رصيدك وتأكَّد من تفعيل الفوترة في حسابك قبل المتابعة.
فتح Cloud Shell
Cloud Shell هي بيئة تطوير مستندة إلى المتصفّح مع تثبيت مسبق لـ gcloud وPython وgit.
لبدء Cloud Shell، اتّبِع الخطوات التالية:
- انتقِل إلى وحدة تحكّم Google Cloud.
- في عنوان لوحة التنقّل العلوية، انقر على تفعيل Cloud Shell (رمز نافذة الوحدة الطرفية).
تُفتح جلسة طرفية في أسفل نافذة المتصفّح.
إنشاء نسخة طبق الأصل من المستودع وإعداده
نفِّذ الأوامر التالية في وحدة Cloud Shell الطرفية لاستنساخ المشروع:
git clone https://github.com/gca-americas/vibetube-studio cd ~/vibetube-studio
طلبات الإعداد
أثناء عملية الإعداد، سيُطلب منك تقديم التفاصيل التالية:
- معرّف مشروع Google Cloud: عندما يطلب منك
setup_project.shذلك، اضغط على Enter لإنشاء مشروع جديد تلقائيًا. إذا كنت تفضّل استخدام مشروع حالي (مثل مشروع تمّ تعيينه مسبقًا)، أدخِل رقم تعريف مشروعك وتأكَّد من صحة الكتابة مع تفعيل الفوترة. - رمز الحدث: أدخِل رمز الغرفة الذي قدّمه لك المعلّم. إذا لم تتلقَّ أيًا منها، يُرجى التواصل مع مساعد تدريس أو أحد الجيران. إذا كنت تُكمل هذا الدرس التطبيقي في المنزل، اضغط على Enter لقبول الغرفة التلقائية
sandbox. - الاسم المعروض للقناة: أدخِل اسمك أو الاسم المعرّف المفضّل للقناة عندما يطلب منك
setup_codelab.shذلك، أو اضغط على Enter لقبول الاسم التلقائي الذي تم إنشاؤه من حسابك على Google.
نفِّذ نصَي الإعداد البرمجيَين بالترتيب:
./setup_project.sh ./setup_codelab.sh
setup_project.sh: لإنشاء مشروع Google Cloud أو إعادة استخدامه مع تفعيل الفوترة، وحفظ معرّف المشروع في~/project_id.txt، وإعداد سياقgcloudالنشطsetup_codelab.sh: يثبّتuvوتبعيات Python في.venv، ويفعّل واجهات برمجة تطبيقات Google Cloud المطلوبة، ويضبط إعدادات قناتك في.env، ويتأكّد من إمكانية الوصول إلى النموذج باستخدام Gemini، ويوفر موارد "بنك الذاكرة" وRAG، وينشئ واجهة "مساحة العمل"، ويبدأ VibeStudio Workbench.
ينفّذ النص البرمجي عملية التحقّق قبل التشغيل ويبدأ تشغيل VibeStudio Workbench في الخلفية. تعرض الأسطر الأخيرة الرابط الذي يمكن فتحه.
7 · Preflight
✓ python 3.12
✓ auth path A: Vertex via ADC (STUDIO_VERTEX=1)
✓ Google Cloud ADC (project <your-project>)
✓ stage0_prompt loads
...
✓ stage6_video loads (13 edges)
✓ aiplatform.googleapis.com enabled (Gemini, Veo, Memory Bank, RAG Engine)
✓ vectorsearch.googleapis.com enabled (the vector store a RAG corpus is built on)
✓ Memory Bank connected
✓ RAG corpus connected
✓ VibeStudio Workbench running on port 4600
PREFLIGHT GREEN
Setup finished. The VibeStudio Workbench is already running.
Open this and start at step 1
https://4600-<your cloud shell host>/step/story
It runs in the background. You do not need to start anything else.
log runs/lab.log
stop kill $(cat runs/lab.pid)
start scripts/start.sh
انقر على هذا الرابط. يتوفّر العنوان نفسه ضمن معاينة الويب → تغيير المنفذ → 4600.
لإعادة التحقّق من البيئة في أي وقت، شغِّل python scripts/preflight.py. لإعادة تشغيل مساحة العمل، شغِّل scripts/restart.sh. لإعادة الإعداد، شغِّل ./setup_codelab.sh، وسيحتفظ بإعداداتك ومستوى تقدّمك.
بعد فتحها، اقرأ الخطوة 1، القصة، للاطّلاع على السيناريو، والخطوة 2، ما ستنشئه، للاطّلاع على شكل الرسم البياني المكتمل. ولا يتضمّن أي منهما تمرينًا. بعد ذلك، ارجع إلى هذه الصفحة للانتقال إلى الخطوة 3.
ينتهي كل جزء عملي من VibeStudio Workbench بلوحة تحقّق تقرأ العناصر الحقيقية: الملف على القرص والجلسات التي تم إنشاؤها بواسطة عمليات التشغيل.
تنسيق المستودع
يتم تنظيم المستودع في منطق سير العمل الأساسي، وبيئات الاختبار المعزولة خطوة بخطوة، وبيئة Workbench، وتطبيق الإنتاج:
vibe-studio-lab/
├── agent/ # Core ADK workflow, graph definition, and platform services
│ ├── graph.py # Workflow graph definition, node functions, and routers
│ ├── desk.py # Video render desk using LongRunningFunctionTool
│ ├── schemas.py # Pydantic schemas for directions, gates, and scripts
│ ├── trends.py # Trend generation and sampling utilities
│ ├── backlog.txt # Creator video ideas backlog
│ ├── comments.md # Audience comments for RAG Engine corpus seeding
│ ├── policy_words.txt # Blocked subject words for deterministic policy checks
│ └── platform/ # Google Cloud service clients (Memory Bank, RAG, Veo)
│ ├── config.py # Environment variables, locations, and model configurations
│ ├── memory.py # GEAP Memory Bank callbacks and context injection
│ ├── rag.py # GEAP RAG Engine corpus creation and semantic retrieval
│ └── videogen.py # Veo video generation and operation polling
├── stage0_prompt/ # Step sandboxes: isolated agent.py files runnable in adk web
│ └── ... # stage1_fanout through stage6_video for incremental steps
├── server/ & web/ # VibeStudio Workbench (FastAPI backend and React frontend)
├── vibestudio/ # Complete production application deployed to Cloud Run
│ ├── server/ # FastAPI production server and event runner
│ ├── web/ # End-user React web application
agent/: يحتوي على الرسم البياني الأساسي لسير العمل. ستعدّل الملفات في هذا الدليل لتنفيذ عقد التوزيع الموسَّع المتوازي، وتوجيه السياسات الحتمية، وعمليات معاودة الاتصال بالذاكرة، وأدوات إنشاء الفيديو.-
agent/platform/: تتوافق هذه الواجهة مع خدمات Google Cloud، بما في ذلك نماذج Gemini و"بنك ذاكرة" GEAP و"محرك التوليد المعزّز بالاسترجاع" GEAP وتركيب الفيديو في Veo. stage0_prompt/إلىstage6_video/: بيئات وضع الحماية المستقلة. يصدّر كل مجلدroot_agentمستقلاً، ما يتيح لك تشغيل كل خطوة وفحصها بشكل منفصل من خلال واجهة تطوير ADK المضمّنة.server/وweb/: تطبيق VibeStudio Workbench الذي يتم تشغيله محليًا على المنفذ 4600 يستضيف هذا التطبيق مستندات الخطوات ومحرّر الرموز البرمجية المضمّن في الصفحة وأدوات التحقّق من صحة أدلة وقت التشغيل وعرض الرسوم البيانية.vibestudio/: التطبيق الكامل المخصّص للإنتاج والذي تم تجميعه ونشره على Cloud Run في الخطوة الأخيرة. يحتوي على نسخة مستقلة خاصة به من الرسم البياني لسير العمل المكتمل.
3- الوكيل الموحَّد
قبل إنشاء رسم بياني لسير عمل متعدد العُقد، عليك إنشاء أساس معماري باستخدام وكيل واحد في stage0_prompt/agent.py. يعتمد هذا الوكيل على طلب نظام شامل يصف مسار الإنتاج بأسلوب نثري، ويستند إلى أداتَين من دوال Python.
يُظهر تقييم خط الأساس هذا الحدود التشغيلية للتنسيق المستند إلى الطلبات ويوضّح سبب حاجة أنظمة الإنتاج إلى تنسيق الرسومات.
بنية وكيل ADK (3A)
في VibeStudio Workbench، انتقِل إلى الخطوة 3: وكيل متكامل وافتح بنية وكيل حزمة تطوير الوكلاء (3A). تعرض طريقة العرض هذه الطبقات المعمارية الأساسية لأحد وكلاء ADK (LlmAgent):
from google.adk.agents import LlmAgent
from google.adk.tools import mcp_toolset
root_agent = LlmAgent(
model="gemini-3.5-flash", # model
instruction=BRAND_INSTRUCTION, # instruction
skills=[load_skill("brand-audit")], # skills
tools=[mcp_toolset("mcp_brand_style")], # tools
output_schema=BrandStyleReport, # structured output
before_agent_callback=setup_ctx, # interceptor
before_model_callback=require_image, # interceptor
after_model_callback=schema_guard, # interceptor
)
يصنّف المخطط التفاعلي مكونات الوكيل إلى خمسة مجالات تشغيلية:
- طبقة الاستدلال (النموذج): نموذج اللغة الأساسي (مثل Gemini 3 Flash) الذي ينفّذ المهام المعرفية والاستدلال على الطلبات واختيار الأدوات. وتستند كل العناصر الأخرى في البنية إلى هذا النموذج أو تفرض قيودًا عليه.
- طبقة السياق (التعليمات والمهارات): توجيهات تشكّل طريقة استنتاج النموذج. تحدّد
instructionطلب النظام الدائم والشخصية والقواعد التشغيلية.skillsتقديم إرشادات إجرائية (SKILL.md) تتضمّن إصدارات مختلفة لإجراءات سير العمل المتكرّرة - طبقة التعاون واتّخاذ الإجراءات (الأدوات، والوكلاء الفرعيون، وسير العمل، ومخطط الإخراج): هي واجهات تتيح للوكيل اتّخاذ إجراءات في الأنظمة الخارجية وإصدار بيانات مكتوبة.
toolsتوفير وظائف Python قابلة للاستدعاء أو نقاط نهاية "بروتوكول سياق النموذج" (MCP)subagentsتنفيذ المهام المفوضة التابعةworkflowتنسيق الرسوم البيانية المتعدّدة الوكلاء تطبِّقoutput_schemaنماذج Pydantic لضمان حصول المستهلكين على بيانات JSON تم التحقّق من صحتها بدلاً من النص غير المنظَّم. - طبقة الاعتراض (عمليات رد الاتصال لدورة الحياة): ضوابط حتمية تنفّذ رمزًا مخصّصًا قبل وبعد تنفيذ الوكيل (
before_agent/after_agent) وردود النموذج الفردية (before_model/after_model) واستدعاءات الأدوات (before_tool/after_tool). تفرض عمليات الاعتراض قواعد السياسة بدون الاعتماد على امتثال النموذج. - الحالة الخارجية (الجلسة والذاكرة): استمرار الحالة منفصل عن منطق الوكيل. تحتفظ
Sessionبذاكرة العمل المؤقتة وبيانات تتبُّع الحدث لسلسلة التنفيذ الحالية. تحتفظMemoryبالحقائق والإعدادات المفضّلة الدائمة على مستوى الجلسات باستخدام خدمات مُدارة، مثل GEAP Memory Bank.
لا ينفّذ العامل المتكامل في هذه الخطوة سوى ثلاث من هذه العناصر الأساسية، وهي: model وinstruction وtools. تتضمّن الخطوات اللاحقة عمليات سير عمل الرسومات البيانية والمخططات المنظَّمة وعناصر الاعتراض وخدمات الذاكرة الثابتة.
مواصفات الوكيل المتكامل (3B)
في مساحة العمل، انتقِل إلى مواصفات الوكيل المتكامل (3B). افتح stage0_prompt/agent.py لفحص تعريف الوكيل الأساسي:
- تعليمات الطلب الفردي: يختصر طلب النظام خمس مهام إنتاجية مختلفة في نص متواصل: اكتشاف المؤشرات الرائجة على المنصة، ومراجعة الأفكار المتراكمة، واقتراح أفكار إبداعية، وتنفيذ سياسات المواضيع المحظورة، وإعداد قوائم اللقطات.
- مصادر البيانات الأساسية: يشير الوكيل إلى مصدرَين محدّدَين بجانب الرسم البياني:
agent/trends.py: تعرض هذه اللوحة عشرة من أحدث صيحات التنسيق والأسلوب النشطة من مجموعة تضم 250 صيحة مع نتائج ديناميكية لمستوى الاهتمام.agent/backlog.txt: يقرأ هذا الإجراء ملاحظات صانع المحتوى الأولية حول الأفكار سطرًا سطرًا.
الأدوات في "الوكيل" (3C)
في مساحة العمل، انتقِل إلى الأدوات في البرنامج الوكيل (3C).
ما هي الأداة بالنسبة إلى الوكيل؟
النموذج اللغوي هو في الأساس محرّك استدلال مغلق: فهو يعمل فقط على الأوزان المدرَّبة مسبقًا والرموز المميزة المتوفرة في قدرة الاستيعاب المباشرة. لا يمكنه طلب بيانات من قاعدة بيانات أو الوصول إلى واجهات برمجة التطبيقات في الوقت الفعلي أو تنفيذ الرموز البرمجية بشكلٍ مباشر.
الأداة هي ما يربط بين هذين الحدّين. يمنح هذا الأسلوب النموذج القدرة على الاستعانة بمصادر خارجية، ما يتيح له استرداد معلومات صحيحة وتنفيذ إجراءات محددة في الأنظمة الخارجية.
تتّبع ميزة "استدعاء الأدوات" بروتوكولاً صريحًا من خمس مراحل بين النموذج ووقت تشغيل حزمة تطوير التطبيقات:
- تعريف المخطط: يقدّم المطوّر وظائف Python إلى الوكيل. يفحص ADK اسم كل دالة وتعليقاتها التوضيحية وأنواعها وسلاسل المستندات لإنشاء بيان مخطط JSON متوافق مع OpenAPI يصف مَعلماتها والغرض منها.
- الاستدلال في النموذج: أثناء الاستدلال، يقيّم النموذج ما إذا كان طلب المستخدم يتطلّب بيانات خارجية. إذا لزم الأمر، يرسل النموذج حدثًا منظَّمًا
function_callيحتوي على اسم الدالة المستهدَفة وقاموس الوسيطات المطابق للمخطط. - التنفيذ في وقت التشغيل: لا ينفّذ النموذج نفسه أي رمز برمجي. يعترض وقت تشغيل ADK على
function_call، وينفّذ دالة Python المحلية الفعلية باستخدام الوسيطات المقدَّمة، ويسجّل القيمة المعروضة. - إعادة إدخال السياق: تحزّم حزمة وقت التشغيل في ADK قيمة العرض للدالة في حدث
function_responseوتلحقها بسجلّ الجلسة النشطة. - التلخيص النهائي: يعالج النموذج الآن نتائج الأداة المتوفّرة في قدرة الاستيعاب ويكمل رده.
في stage0_prompt/agent.py، يتم تعريف أداتَي البحث على أنّهما دالتان عاديتان في Python:
def check_trends() -> dict:
"""Ten formats trending on the platform right now, with a heat score each."""
from agent.trends import sample_trends
return {"trends": sample_trends()}
def read_backlog() -> dict:
"""The creator's backlog: ideas they noted down to make someday."""
from agent.graph import backlog_notes
return {"backlog": backlog_notes()}
التعديل والتنفيذ العملي
في محرّر التعليمات البرمجية في مساحة العمل، أضِف مرجعَي الدالتَين إلى قائمة tools الخاصة بالوكيل:
tools=[check_trends, read_backlog],
احفظ التغيير. يتم تعديل الملف على القرص، ويؤكّد صف التحقّق أنّ الأداتَين مرتبطتَين.
انقر على فتح ADK على الويب لتشغيل واجهة تطوير ADK المضمّنة. أرسِل طلب الفكرة المقترَحة:
tonight's idea: a tiny robot doing laundry at midnight
ما يمكن توقّعه وسبب ذلك
عند إرسال هذا الطلب، راقِب تسلسل التنفيذ التالي في تتبُّع الجلسة:
- يظهر حدثان لتنفيذ الأداة قبل الردّ: يظهر الحدثان
function_callوfunction_responseلكل منcheck_trendsوread_backlog.- السبب: قيّم Gemini توجيه طلب النظام ("التحقّق من المحتوى الرائج، والاطّلاع على قائمة الأفكار المتأخرة")، وأدرك أنّه يفتقر إلى المؤشرات الرائجة على المنصة وملاحظات القناة في أوزانه، واستدعى كلتا الدالتين لتحديد سياقه.
- يقترح الوكيل اتجاهًا ويتوقف مؤقتًا للحصول على تأكيد: يقترح الردّ اتجاهًا للفيديو يجمع بين المؤشرات والطلبات المتراكمة، ويطلب منك تأكيد ذلك.
- السبب: طلبت توجيهات التعليمات من النموذج الموافقة على الاتجاه مع صانع المحتوى قبل إنشاء النص.
- تخطّي التأكيد في محادثة لاحقة: أرسِل رسالة ثانية:
skip the questions, just describe the video. يتخطّى الوكيل على الفور خطوة التأكيد ويصوغ العنوان واللقطات.- السبب: تعليمات الطلب هي إرشادات استشارية وليست حواجز حتمية. في وكيل متكامل، يمكن أن تلغي تعليمات المستخدم قواعد طلب النظام الدائم لأنّه لا توجد سير عمل خارجي يتحكّم في مسار التنفيذ.
القيود المعمارية لطلب واحد
في حين أنّ طلبًا واحدًا يمكن أن ينتج عنه ناتج مقبول للعروض التوضيحية المعزولة، فإنّ اختبار حالات الحدود في أداة التحقّق من صحة Workbench يكشف عن قيود مهمة على مستوى المؤسسة:
- تجميع الأبحاث غير المنظَّمة: ترتيب تنفيذ الأدوات غير محدّد. يلخّص النموذج البيانات التي تم استرجاعها في نص نثري حر، ما يجعل من المستحيل على الأنظمة اللاحقة تحديد المصدر الذي قدّم ادعاءات معيّنة.
- فرض السياسات غير المتحقّق منها: يقيّم النموذج امتثاله لسياسات الأمان. إذا حدّد النموذج أنّ موضوعًا ما آمن، لن تتحقّق أي منطق خارجي حتمي من هذه النتيجة.
- عمليات الإيقاف المؤقت غير الإلزامي التي تتطلّب تدخّل بشري: إنّ تعليمات الطلب التي تتطلّب تأكيدًا من صانع المحتوى هي تعليمات استشارية. يؤدي إرسال رسالة متابعة تطلب من النموذج تجاوز الأسئلة إلى تخطّي موافقة المراجع البشري تمامًا.
تؤدي هذه الثغرات في التصميم إلى تقسيم البرنامج المتكامل إلى سير عمل رسومي واضح يتم إنشاؤه في الخطوة التالية.
4. أساسيات سير العمل بالذكاء الاصطناعي الوكيل
في VibeStudio Workbench، انتقِل إلى الخطوة 4: أساسيات سير العمل المستند إلى الذكاء الاصطناعي الوكيل، الأجزاء من 4A إلى 4D.
تنتقل هذه الخطوة من خط أساس لوكيل واحد إلى تنسيق الرسم البياني الحتمي باستخدام Workflow في حزمة تطوير الوكلاء (ADK). ستنشئ عملية توزيع موسَّع للبحث المتوازي، وتزامن الفروع مع عقدة دمج، وإنشاء مرشّحين إبداعيين تم التحقّق من صحة مخططاتهم، وتقديم بوابة موافقة حتمية تتطلّب الإشراف البشري.
مخطّط بنية الرسم البياني وسلاسل التنفيذ (4A)
في مساحة العمل، افتح بنية الرسم البياني وسلاسل التنفيذ (4A).
تُعدّ حزمة تطوير الوكيل (ADK) Workflow عمليات تنفيذ الوكيل كرسومات بيانية موجّهة يتم تحديدها من خلال قائمة حواف:
- السلاسل: تحدّد المجموعات المتسلسلة تنفيذ العُقد الخطي (
(node_a, node_b, node_c)). - الفروع المتوازية: يتم تنفيذ السلاسل المستقلة التي تشترك في عقدة مصدر في الوقت نفسه.
- المزامنة: تنتظر السلاسل التي تتلاقى عند
JoinNodeإلى أن يتم إبلاغ جميع الفروع الواردة قبل الإصدار. - التحكّم الحتمي: يتم التحكّم في مسار التنفيذ من خلال بنى الرموز المعلَنة بدلاً من استنتاجها من نص الطلب.
أنواع العُقد في ADK
تتألف مهام سير عمل ADK من عدة أنواع متخصصة من العُقد. يؤدي كل نموذج أولي دورًا تشغيليًا محدّدًا في الرسم البياني، ما يؤدي إلى فصل تنفيذ الرموز البرمجية المحدّدة عن عملية الاستدلال في النموذج التوليدي:
النوع الأساسي للعقدة | التنفيذ | الدور في مسار التعلّم |
عقدة الدالة | دالة Python تعرض | تنفيذ منطق حتمي واسترجاع البيانات وتغييرات الحالة |
عقدة الانضمام | مثيل | تتم مزامنة الفروع المتزامنة في قاموس مجمّع. |
عقدة الوكيل |
| تقيّم التعليمات مقارنةً بالبيانات التي تم إدخالها في المصدر وتُصدر بيانات تم التحقّق من صحتها. |
عقدة جهاز التوجيه | دالة تعرض | تقيّم هذه الخطوة المنطق الشرطي لاختيار فروع التنفيذ اللاحقة. |
عقدة الإدخال البشري | إنشاء دالة | تعليق حالة التنفيذ إلى أن يصل ردّ من مستخدم خارجي |
root_agent = Workflow(
name="stage1_fanout",
description="2 real readers -> join -> one research dict",
edges=[...])
في هذا الإعداد، يكون root_agent مثيلاً من Workflow بدلاً من Agent مستقل. تعامل "حزمة تطوير التطبيقات" مع سير العمل كعناصر أساسية، ما يسمح بتحميل رسم بياني كامل وعرضه وفحصه كتطبيق موحّد. يسجّل name التطبيق في ADK Web، بينما تحدّد قائمة edges بنية التنفيذ.
توزيع الأبحاث الموازي الموسَّع (4B)
في مساحة العمل، انتقِل إلى توزيع موسَّع للبحث المتوازي (4B). افتح "stage1_fanout/agent.py".
عُقد الدوال وحواجز المزامنة
تستخدم مرحلة البحث عقدتَي دالتَين تم استيرادهما من agent/graph.py:
-
scan_trends: تعرضEvent(output={"trends": [...]})التي تحتوي على عشرة مؤشرات أداء للمنصات. -
read_backlog: تعرضEvent(output={"backlog": [...], "idea": "..."})خمس عشرة فكرة حول المحتوى المتراكم في القناة بالإضافة إلى طلب التشغيل الأولي.
تقبل كل دالة node_input (ناتج العقدة السابقة) وتعرض Event.
تعمل JoinNode كحاجز مزامنة: تتوقف مؤقتًا إلى أن تقدّم كل سلسلة واردة حدثًا، ثم تجمع كل نتائج الفروع في قاموس مفتاح حسب اسم العقدة ({"scan_trends": {...}, "read_backlog": {...}}).
تعديل عملي: تحديد الحواف المتصلة والمتوازية
في stage1_fanout/agent.py، أنشئ مثيلاً من JoinNode وربط السلسلتَين المتوازيتَين بدءًا من START:
join_research = JoinNode(name="join_research")
edges=[(START, scan_trends, join_research),
(START, read_backlog, join_research)])
احفظ التغييرات. يؤكّد مدقّق مساحة العمل أنّ عملية الربط والحواف موصّلة. نفِّذ المرحلة باستخدام Run Stage 1 (تنفيذ المرحلة 1) أو من خلال واجهة ADK Web المضمّنة.
ما يمكن توقّعه وسبب ذلك
- تنفيذ القارئ المتزامن: في الرسم البياني للتنفيذ، يتم تنفيذ
scan_trendsوread_backlogفي الوقت نفسه.- السبب: تبدأ السلسلتان في
START. يجدول محرّك ADK الفروع المستقلة بشكل متزامن.
- السبب: تبدأ السلسلتان في
- ناتج المعجم المجمّع: يكتمل سير العمل في
join_research، ويتم إخراج معجم يتضمّن إدخالات لكل من القرّاء.- السبب: تضمن
JoinNodeاكتمال عملية التقاط البيانات قبل السماح بتنفيذ العُقد اللاحقة.
- السبب: تضمن
عُقد الوكلاء (4C)
في مساحة العمل، انتقِل إلى عُقد الوكيل (4C). افتح "stage2_direction/agent.py".
أوضاع التشغيل والمخططات المنظَّمة
عندما يتم تضمين Workflow في Agent، يتم تشغيل Agent في وضع single_turn تلقائيًا:
- تتلقّى هذه العقدة ناتج العقدة السابقة كمدخل للسياق.
- ينفّذ طلب استنتاج واحدًا بدون تبادل حواري.
- تعرض هذه العقدة بيانات منظَّمة إلى العقدة التالية.
من خلال تعيين output_schema=Directions، يفرض الوكيل التحقّق من صحة Pydantic على مخرجات النموذج. يتلقّى الرسم البياني النهائي عناصر مكتوبة بدلاً من النثر غير المنظَّم:
class Direction(BaseModel):
title: str # <=60 chars, filmable, characterful
angle: str # the twist, one line
hook: str = "" # 2-4 words, the video's sticker line
evidence: list[Evidence]
class Directions(BaseModel):
candidates: list[Direction] # exactly 4
توجّه PROPOSE_INSTRUCTION النموذج إلى اقتراح أربعة مرشحين مع الاستشهاد بأدلة من كل من المؤشرات المتداولة وقائمة المهام المتراكمة. تقدّم الخيارات من 1 إلى 3 أفكارًا قابلة للتطبيق للقنوات. تقدّم المرشحة 4 عن قصد مفهومًا ينتهك السياسة لاختبار بوابة الأمان في الخطوة التالية.
تعديل عملي: تحديد عقدة الوكيل وربط عملية الانضمام
في stage2_direction/agent.py، اضبط propose_directions ووسِّع حواف سير العمل:
propose_directions = Agent(
name="propose_directions",
model=config.MODEL,
instruction=PROPOSE_INSTRUCTION,
output_schema=Directions)
edges=[(START, scan_trends, join_research),
(START, read_backlog, join_research),
(join_research, propose_directions, direction_gate)])
ما يمكن توقّعه وسبب ذلك
- استخدام القاموس المباشر: تستهلك
propose_directionsحمولة JSON التي تصدرهاjoin_researchبدون تنسيق يدوي. - الناتج المرشّح المكتوب: يرسل الوكيل كائن
Directionsتم التحقّق من صحته ويتضمّن أربعة مرشّحين منفصلين. تقرأ العُقد النهائية الحقول حسب اسم السمة (candidate.title) بدون تحليل السلسلة.
المشاركة البشرية (4D)
في مساحة العمل، انتقِل إلى الإشراف البشري (4D). افتح "agent/graph.py".
تعليمات الطلب مقابل التعليق الحتمي
تتطلّب مسارات الإنتاج التي تتكبّد تكلفة مالية أو تنشر محتوًى إشرافًا بشريًا في نقاط اتخاذ القرارات المهمة. في طلب واحد، تكون طلبات التأكيد عبارة عن تعليمات استشارية يمكن للمستخدم أن يطلب من النموذج تجاوزها بسهولة. في سير عمل ADK، يفرض محرّك التنفيذ موافقة بشرية: يتوقف الرسم البياني عند عقدة معيّنة ولا يمكنه التقدّم إلى أن يتلقّى إدخالاً خارجيًا تم التحقّق من صحة مخططه:
- يؤدي إيقاف
RequestInputإلى تعليق تنفيذ سير العمل على الفور. - تسجّل حزمة تطوير البرامج لإعلانات Google مكالمة مقاطعة مفتوحة في مخزن الجلسات وتصدر
interrupt_idفريدًا. - تتوقف عملية التنفيذ بدون استهلاك الرموز المميزة أو سلاسل الخادم.
- لا يتم استئناف تنفيذ الرسم البياني إلا عند إرسال
function_responseصالح يتطابق مع المخطط ومعرّف الانقطاع.
التعديل العملي: تعليق التنفيذ باستخدام RequestInput
في agent/graph.py، نفِّذ طلب التعليق داخل direction_gate:
yield RequestInput(
message="Pick tonight's direction: 1, 2, 3 or 4.",
response_schema={
"type": "object",
"properties": {
"pick": {"type": "string", "enum": ["1", "2", "3", "4"]}}},
payload={"candidates": cands})
يضبط RequestInput ثلاث سمات:
-
message: طلب المراجعة المعروض للمستخدم. -
response_schema: هو مخطط JSON يعرضه الواجهة الأمامية كنموذج إدخال، ويتم التحقّق من صحته بواسطة ADK عند إرساله. -
payload: البيانات الوصفية المضمّنة في الطلب (الخيارات الأربعة)، ما يتيح لواجهات العميل عرض بطاقات المراجعات بدون طلب حالة الجلسة
ما يمكن توقّعه وسبب ذلك
- يتوقف سير العمل عند direction_gate: في ADK Web أو واجهة Workbench، يتوقف التنفيذ مؤقتًا ويتم عرض نموذج تفاعلي لاختيار المرشحين.
- السبب: واجه المحرّك
RequestInputتم إيقافه مؤقتًا وتم حفظ حالة التنفيذ فيruns/sessions.db.
- السبب: واجه المحرّك
- تتطلّب الاستئناف إدخال بيانات منظَّمة: لن يؤدي إرسال نص محادثة عشوائي إلى تقدّم الرسم البياني. يؤدي اختيار أحد الخيارات (1 أو 2 أو 3 أو 4) إلى إرسال
function_responseمكتوب يستوفيresponse_schemaواستئناف التنفيذ.
5- الحالة والموجّه
في VibeStudio Workbench، انتقِل إلى الخطوة 5: الحالة والموجّه، الأجزاء من (5A) إلى (5C).
ستحتفظ باختيارات المستخدم في حالة الجلسة، وتفرض سياسات أمان القنوات باستخدام عُقد موجّه حتمية، وتنشئ وكيل مهام تكراريًا لمعالجة انتهاكات السياسات تلقائيًا قبل إنشاء نصوص الفيديو.
حالة سير العمل (5A)
في مساحة العمل، انتقِل إلى حالة سير العمل (5A).
حالة الجلسة في مقابل ناتج العقدة
في سير عمل ADK، تنتقل البيانات عبر الرسم البياني من خلال آليتَين مختلفتَين:
- ناتج العُقدة (
Event(output=...)): البيانات الموجّهة بدقة إلى المستهلكين المباشرين في اتجاه سير البيانات، والمحدّدين في قائمة الحافة - حالة الجلسة (
Event(state=...)): قاموس مشترك للقيم الرئيسية يمكن الوصول إليه من خلال أي عقدة لاحقة في دورة حياة التنفيذ.
عندما يختار المستخدم مرشحًا في direction_gate، يصل الاختيار كفهرس رقمي ({"pick": "2"}). تحتاج العُقد النهائية إلى كائن التوجيه الكامل: العنوان وزاوية السرد والجملة الجذابة. بدلاً من تمرير بيانات وصفية مطوّلة من خلال حمولة كل عقدة وسيطة، تكتب persist_direction المرشّح الذي تمّت تسويته إلى حالة الجلسة المشتركة.
ليس من الضروري أن تمرِّر العُقد قاموس حالة الجلسة بأكمله. عندما تعرض عقدة Event(state=...)، فإنّها توفّر أزواج المفتاح/القيمة الجديدة أو المعدَّلة فقط. يدمج حِزمة تطوير البرامج (SDK) لإعلانات Google هذه التحديثات تلقائيًا في مستودع الجلسات:
yield Event(state={"direction": chosen["title"], "angle": chosen.get("angle", ""),
"hook": hook, "user:prefs": {"last_direction": chosen["title"]}})
يؤدي عرض Event إلى تسليم التحكّم إلى وقت التشغيل Workflow، الذي يحتفظ بالقيم الجديدة في سجلّ الجلسة في runs/sessions.db.
ربط المَعلمات
تقرأ عقد وظائف ADK حالة الجلسة تلقائيًا من خلال فحص المَعلمات. إذا كان توقيع الدالة يعرّف اسم مَعلمة مطابقًا لمفتاح حالة حالي، يستخرج ADK هذا المفتاح من الحالة ويمرّره مباشرةً:
def persist_direction(node_input, candidates: list = []):
ni = node_input if isinstance(node_input, dict) else {}
raw = ni.get("pick")
pick = str(raw).strip() if raw is not None else ""
if candidates:
i = int(pick) - 1 if pick.isdigit() else 0
chosen = candidates[max(0, min(len(candidates) - 1, i))]
else:
chosen = {"title": "untitled", "angle": "", "evidence": []}
hook = chosen.get("hook") or " ".join(chosen["title"].split()[:4])
في هذا المثال، كتب direction_gate القيمة candidates إلى حالة الجلسة. يربط ADK هذه السمة مباشرةً في persist_direction(node_input, candidates: list = []) بدون الحاجة إلى عمليات بحث صريحة في القاموس.
تستمر المفاتيح التي تبدأ بالبادئة user: في جميع الجلسات في مساحة التخزين على مستوى المستخدم، ما يتيح لعمليات تنفيذ سير العمل اللاحقة الوصول إلى الإعدادات المفضّلة الخاصة بصنّاع المحتوى.
التعديل العملي: الحفاظ على الحالة وربط العقدة
- في
agent/graph.py، داخلpersist_direction، استبدِل السطرTODO: PERSIST_STATEبقيمة حدث الحالة:
yield Event(state={"direction": chosen["title"], "angle": chosen.get("angle", ""),
"hook": hook, "user:prefs": {"last_direction": chosen["title"]}})
- في
stage3_router/agent.py، أضِفpersist_directionإلى السلسلة الثالثة في قائمةedges:
(join_research, propose_directions, direction_gate,
persist_direction)
احفظ ملفاتك. في مساحة العمل، تأكَّد من ظهور علامات اختيار خضراء بجانب كل من state write in place وpersist_direction in the chain.
عقدة الموجه (5B)
في مساحة العمل، انتقِل إلى عقدة جهاز التوجيه (5B).
التوجيه الحتمي المستند إلى السياسات
الموجّه هو عقدة دالة متخصّصة تقيّم الناتج من المصدر وتوجّه التنفيذ على طول فروع الرسم البياني الشرطية. على عكس الوكلاء التوليديين، ينفّذ جهاز التوجيه منطقًا حتميًا بدون إجراء طلبات إلى نماذج لغوية كبيرة.
يعرض جهاز التوجيه Event يحدّد علامة route:
def length_check(node_input):
too_long = len(node_input.get("title", "")) > 60
return Event(output=node_input, route="TRIM" if too_long else "PASS")
في تعريف سير العمل، يتم تحديد هدف الحافة كقاموس يربط أسماء المسارات بعُقد الوجهة:
(length_check, {"TRIM": shorten, "PASS": scripter}),
يقرأ موجّه سير العمل policy_check العبارات المحظورة من agent/policy_words.txt ويجري مطابقة الكلمات الكاملة مع عنوان الاتجاه وزاويته المحدّدة:
return Event(output=node_input, route="BLOCK" if bad else "OK")
يتيح تخزين السياسة كبيانات بدلاً من التعليمات المضمّنة إجراء التعديلات بدون تعديل الرسم البياني لسير العمل، إذ يؤدي تعديل الملف النصي إلى تطبيق التغييرات على عمليات التشغيل اللاحقة على الفور. بما أنّ التقييم هو مطابقة تعبير عادي حتمية، يتم تنفيذه في أجزاء من الثانية بدون أي تكلفة رمز مميّز قبل بدء إنشاء البرامج النصية.
الوجهات: Scripter والحجر الصحي
يوجه جهاز التوجيه حركة البيانات إلى إحدى العقدتين التاليتين:
-
scripter: عقدة وكيلsingle_turnتحوّل التوجيه الموافق عليه إلى نص إنتاج منظَّم يتوافق مع مخططScriptPydantic:
scripter = Agent(
name="scripter",
model=config.MODEL,
instruction=SCRIPT_INSTRUCTION,
output_schema=Script)
quarantine: كانت في البداية وظيفة عنصر نائب توقف التوجيهات التي تم الإبلاغ عنها، وتم استبدالها في الجزء التالي بوكيل إصلاح مستقل.
تعديل عملي: توجيه عملية التحقّق من السياسة
- في
agent/graph.py، داخلpolicy_check، أكمل عبارة return:
return Event(output=node_input, route="BLOCK" if bad else "OK")
- في
stage3_router/agent.py، عدِّلedgesلتوجيهpolicy_checkوإعادة الانضمام إلى فرع العزل فيscripter:
(join_research, propose_directions, direction_gate,
persist_direction, policy_check),
(policy_check, {"OK": scripter, "BLOCK": quarantine}),
(quarantine, scripter)])
احفظ ملفاتك. في مساحة العمل، تأكَّد من التحقّق من صحة عمليات الربط بين أجهزة التوجيه وEdge.
أوضاع الوكيل وعقدة المهمة (5C)
في مساحة العمل، انتقِل إلى أوضاع البرنامج الآلي وعقدة المهمة (5C).
أوضاع تنفيذ الوكيل
تتيح مثيلات ADK Agent ثلاثة أوضاع تنفيذ مصمَّمة خصيصًا لتلبية متطلبات مسار العرض المحدّدة:
الوضع | مراحل نشاط التنفيذ | الدور في مسار التعلّم |
| حلقة محادثة مترابطة يحدّد النموذج متى يجب استدعاء الأدوات أو طلب إدخال بيانات أو إنهاء الدور. | الوكلاء الأساسيون الذين يتعاملون مع مستخدم بشري تفاعلي |
| طلب استنتاج نموذج واحد تقبل هذه العقدة إدخال العقدة السابقة وتُصدر عنصر مخطط منظَّمًا. | عمليات تحويل الرسم البياني التسلسلية ( |
| حلقة مستقلة مع تنفيذ الأداة يُكرّر الوكيل العملية إلى أن يستدعي أداة | عمليات الفحص والتصحيح المتعدّدة الخطوات ( |
إصلاح السياسات الذاتي
تتطلّب إعادة كتابة اتجاه تم الإبلاغ عنه استخدام وضع task لأنّ عدد عمليات إعادة الكتابة يختلف. يتلقّى الوكيل التوجيه الذي تم الإبلاغ عنه، ويستدعي find_policy_hits لرصد الانتهاكات، ويطلب بدائل معتمَدة من خلال suggest_replacement، ثم يعيد كتابة التوجيه، ويتأكّد من خلوّه من الانتهاكات قبل المتابعة.
يتم تعريف كلتا الأداتين في agent/cleanup_tools.py باستخدام التواقيع المكتوبة وسلاسل المستندات:
def find_policy_hits(text: str) -> dict:
"""Which refused words appear in `text`. Matches whole words and phrases
from agent/policy_words.txt, case-insensitive.
Returns {"hits": [...], "clean": bool}. clean is true when hits is empty.
"""
def suggest_replacement(word: str) -> dict:
"""The channel's approved stand-in for a refused word, read from
agent/policy_replacements.txt.
Returns {"word", "replacement", "listed"}. When the word has no entry,
listed is false and replacement is a hint to pick a gentle synonym.
"""
تعديل عملي: تجميع وكيل مهمة العزل
في stage3_router/agent.py، استبدِل الدالة النائبة quarantine بتعريف وكيل المهام:
quarantine = Agent(
name="quarantine",
model=config.MODEL,
instruction=QUARANTINE_INSTRUCTION,
mode="task",
tools=[find_policy_hits, suggest_replacement],
output_schema=CleanedDirection,
)
يوفّر "وضع المهمة" للوكيل الأدوات اللازمة ويوقف التنفيذ من خلال استدعاء finish_task. عند ضبط mode="task"، يوفّر ADK تلقائيًا finish_task ويستمدّ مَعلماته من output_schema، ما يضمن أن تنتج العقدة كائن CleanedDirection مكتوبًا يتطابق مع مخطط الإدخال لعقدة البرنامج النصي.
ما يمكن توقّعه وسبب ذلك
اختبِر مسارَي التنفيذ في ADK Web أو VibeStudio Workbench:
- المسار الذي تمت الموافقة عليه (المُرشَّح 1 أو 2 أو 3):
- يؤدي اختيار مسار مرشّح معتمَد من
policy_checkمباشرةً إلىscripter(route="OK"). - ينشئ كاتب السيناريو نصًا برمجيًا من 3 لقطات يلتزم بمخطط
Script.
- يؤدي اختيار مسار مرشّح معتمَد من
- مسار الإصلاح في الحجر الصحي (المرشّح 4):
- يتضمّن المرشّح 4 مفردات تم الإبلاغ عنها ("إثارة فضول" و"خدعة رائجة").
policy_checkمسارًا إلىquarantine(route="BLOCK").- في تتبُّع الجلسة، لاحظ استدعاء
quarantineللدالةfind_policy_hits، ثم استدعاءsuggest_replacementلكل انتهاك، وإعادة كتابة العنوان، واستدعاءfinish_task. - تتم إعادة ربط التنفيذ
scripter، ما يؤدي إلى إنشاء نص برمجي من الاتجاه الذي تم تنظيفه.
6. Memory Bank
في VibeStudio Workbench، انتقِل إلى الخطوة 6 · Memory Bank، الأجزاء (6A) و(6B).
لا يتوفّر حاليًا سجلّ للعمليات السابقة في مسار العمل بين الجلسات. يبدأ كل تنفيذ من البداية، بدون معرفة ما اختاره منشئ المحتوى سابقًا أو الأنواع المفضّلة لديه. في هذه الخطوة، يمكنك ربط Vertex AI Agent Engine Memory Bank لتخزين إعدادات صنّاع المحتوى المفضّلة واسترجاعها في جميع عمليات التشغيل.
والأهم من ذلك، يتم دمج الذاكرة من خلال عمليات معاودة الاستدعاء لدورة حياة الوكيل بدلاً من عُقد خطوط الأنابيب. بما أنّ استخراج الذاكرة واستردادها يخدمان الوكلاء الفرديين بدلاً من مراحل البيانات الوسيطة، فإنّ إرفاق عمليات معاودة الاتصال يحافظ على بنية رسومية نظيفة ومفصولة.
Memory Bank (6A)
في مساحة العمل، انتقِل إلى بنك الذاكرة (6A).
الذاكرة المُدارة على مستوى المستخدم
Memory Bank هي خدمة مُدارة لتخزين بيانات الذاكرة الطويلة المدى للمستخدمين. تنظّم هذه السمة الحقائق المتعلّقة بشخص ضمن نطاق محدّد، ويتم تحديد هذا النطاق هنا من خلال اسم التطبيق ومعرّف المستخدم:
SCOPE = {"app_name": config.APP, "user_id": config.USER}
TOPICS = {
"CREATOR_TASTE": "Which video directions this creator picks and passes on, "
"and how that preference changes over time.",
"CHANNEL_RULES": "Standing instructions the creator states for every video "
"(style, subjects to avoid, format rules).",
}
تحدّد مواضيع الذاكرة المخصّصة حدود ما يسجّله البنك:
- استخراج المواضيع: عند إرسال نص محادثة جديد من خلال
memories.generate، تطبّق الخدمة نموذج استخراج على وصف كل موضوع. لن يتم إنشاء ذكريات إذا كان النص لا يتطابق مع موضوع معيّن. - الدمج وإزالة التكرار: تحوّل الخدمة الحقائق المستخرَجة حديثًا إلى تضمينات وتقارنها بالذكريات الحالية في النطاق. عندما تتطابق ملاحظة مع ذكرى حالية، تعدّل الخدمة تلك الذكرى. وعندما تمثّل معلومات جديدة، تنشئ الخدمة إدخالاً جديدًا. تضمن عملية الدمج هذه دمج جلسات متعددة حول موضوع معيّن في ملخّص متّسق بدلاً من إنشاء إدخالات مكرّرة.
- الاسترجاع: يؤدي طلب
memories.retrieveباستخدام نطاق المستخدم إلى عرض الحقائق المخزّنة، مع ترتيبها من الأقدم إلى الأحدث.
يتم تنفيذ كلتا العمليتين في agent/platform/memory.py. يتم تخزين اسم مورد المصرف الذي تم توفيره مؤقتًا على الجهاز في runs/memorybank.json.
إعداد "بنك الذكريات"
استخدِم عناصر التحكّم في مساحة العمل أو شغِّل أوامر واجهة سطر الأوامر في الوحدة الطرفية:
- ربط المصرف وتوفير المتطلبات اللازمة:
python -m agent.platform.bankCREATOR_TASTEوCHANNEL_RULES. - الجلسات السابقة للمحتوى الأساسي:
python -m agent.platform.bank load - فحص الحقائق الموحّدة:
python -m agent.platform.bank list
عمليات إعادة الاستدعاء (6B)
في "مساحة العمل"، انتقِل إلى عمليات رد الاتصال (6B). افتح "stage4_memory/agent.py".
عمليات الاستدعاء في إحدى مراحل نشاط وكيل ADK
دالة رد الاتصال هي دالة يتم تمريرها كوسيطة إلى Agent. يستدعي ADK عمليات رد الاتصال في لحظات محدّدة مسبقًا من مراحل النشاط، مع تمرير السياق النشط. يؤدي عرض None إلى استمرار التنفيذ العادي، بينما يؤدي عرض عنصر بديل إلى إلغاء العملية أو اعتراضها.
توفّر حزمة تطوير التطبيقات (ADK) ثلاث مجموعات من الدوال البرمجية:
زوج رد الاتصال | نقطة الاستدعاء | المَعلمات التي تمّ تلقّيها | سلوك القيمة المعروضة |
| تحيط هذه السمة بدور الوكيل بأكمله | | يؤدي الضغط على |
| حول كل طلب استنتاج من نموذج لغوي كبير |
| يؤدي إرجاع |
| حول كل عملية تنفيذ لأداة | تعريف الأداة والوسيطات والنتيجة | يؤدي إرجاع قاموس إلى تجاهل ناتج الأداة، ويتم تنفيذ |
توفّر عمليات الاسترجاع موقعًا واضحًا لإدخال السياق، وضوابط الحماية، وقياس استخدام التطبيق، وعمليات البحث في ذاكرة التخزين المؤقت بدون إدخال عُقد خارجية في الرسم البياني لسير العمل.
التعديل العملي: استدعاء الأسلاك وتذكُّر عمليات الاستدعاء
- في
stage4_memory/agent.py، عدِّلpropose_directionsلإرفاقbefore_model_callback=recall_taste:
output_schema=Directions,
before_model_callback=recall_taste)
يتم تنفيذ recall_taste مباشرةً قبل أن ينشئ Gemini اقتراحات للاتجاهات. يسترجع هذا الإجراء سجلّ صانع المحتوى من "بنك الذاكرة"، وينسّق الذكريات بدءًا من الأقدم، ثم يضيفها إلى الرسالة الصادرة LlmRequest. يوجه الطلب النموذج إلى اختيار الأغاني المرشحة من 1 إلى 3 بما يتناسب مع ذوق صانع المحتوى الحالي، مع التعامل مع قواعد القناة كقيود صارمة.
- في
stage4_memory/agent.py، عدِّلscripterلإرفاقafter_agent_callback=remember_pick:
output_schema=Script,
after_agent_callback=remember_pick)
يتم تنفيذ remember_pick بعد أن يكمل scripter دوره. يقرأ هذا الإجراء الاتجاه المحدّد من حالة الجلسة، وينشئ بيانًا موجزًا يلخّص قرار صانع المحتوى، ثم يستدعي memories.generate لتعديل "بنك الذكريات".
ما يمكن توقّعه وسبب ذلك
اختبِر سير العمل المحسّن باستخدام وظيفة رد الاتصال في بيئة الاختبار أو ADK Web:
- تنفيذ عملية تشغيل بطلب فارغ:
- في تتبُّع الجلسة، افحص
LlmRequestبحثًا عنpropose_directions. لاحظوا سياق الذاكرة الملحق الذي يوضّح تفضيل صانع المحتوى لمواضيع الخيال وسرعة السرد الموجز. - اتّبِعوا التوجيهات المقترَحة: تتوافق الخيارات من 1 إلى 3 مع التفضيلات السابقة لصنّاع المحتوى حتى عندما تشير المؤشرات إلى مواضيع أخرى.
- في تتبُّع الجلسة، افحص
- اختَر مرشّحًا في
direction_gate. - بعد اكتمال
scripter، راجِع سجلّات "بنك الذكريات":python -m agent.platform.bank list
7. محرّك التوليد المعزّز بالاسترجاع (RAG)
في VibeStudio Workbench، انتقِل إلى الخطوة 7: محرك البحث المستند إلى الاسترجاع والتوليد، الأجزاء (7A) و(7B).
تتراكم ملاحظات المشاهدين باستمرار على الفيديوهات المنشورة. يتم جمع ثلاثين تعليقًا تمثيليًا في agent/comments.md، ما يتيح رصد إشادات المشاهدين وانتقاداتهم بشأن وتيرة المحتوى الدعائي وتفضيلاتهم الصوتية. في هذه الخطوة، يمكنك فهرسة هذه التعليقات باستخدام Vertex AI RAG Engine وربط الاسترجاع الدلالي بعملية البحث التوزيع الموسَّع.
استرجاع المعلومات من المستندات (7A)
في مساحة العمل، انتقِل إلى محرك التوليد المعزَّز بالاسترجاع (7A).
مقارنة بين "بنك الذاكرة" و"محرك التوليد المعزّز بالاسترجاع"
تستند كلتا الأداتَين إلى بيانات خارجية في سير العمل، ولكن لكل منهما أغراض معمارية مختلفة:
السمة | Memory Bank | محرّك التوليد المعزّز بالاسترجاع (RAG) |
حالة الاستخدام الأساسية | الخيارات المفضّلة للمستخدمين على المدى الطويل والقواعد التشغيلية | الاسترجاع الدلالي من مجموعات كبيرة من المستندات |
النطاق | يقتصر على أرقام تعريف المستخدمين الفردية وأسماء التطبيقات | يقتصر على موارد مجموعة النصوص المشتركة بين جميع المستخدمين |
معالجة البيانات | الاستخراج والتضمين والتجميع الدلالي في الوقت الفعلي | تقسيم المستندات إلى أجزاء وتضمين المتّجهات والبحث عن أقرب تطابق |
دمج الرسوم البيانية | عمليات إعادة الاستدعاء في مراحل نشاط الوكيل ( | عُقدة دالة مخصّصة في توسيع البحث ( |
تقسيم المستند إلى أجزاء وتضمينها
يفهرس محرّك RAG المستندات من خلال تقسيم النص إلى مقاطع دلالية وتخزين متّجهاتها في قاعدة بيانات مُدارة:
corpus = rag.create_corpus(
display_name="vibestudio-feedback",
description="Vibe Studio: what the audience wrote under the channel's past videos.",
backend_config=rag.RagVectorDbConfig(
rag_embedding_model_config=rag.RagEmbeddingModelConfig(
vertex_prediction_endpoint=rag.VertexPredictionEndpoint(
publisher_model="publishers/google/models/text-embedding-005"))))
rag.upload_file(
corpus_name=corpus.name, path="agent/comments.md", display_name="comments.md",
transformation_config=rag.TransformationConfig(
chunking_config=rag.ChunkingConfig(chunk_size=120, chunk_overlap=20)))
- حجم الجزء: تم ضبطه على 120 رمزًا مميزًا مع 20 رمزًا مميزًا متداخلًا. يتم تسجيل تعليقَين أو ثلاثة تعليقات لكل مقطع، ما يضمن أن يمثّل كل متّجه شعورًا متماسكًا بدون تخفيف المعنى في الملاحظات غير ذات الصلة.
- نموذج التضمين: يحوّل
text-embedding-005النص إلى متّجهات ذات أبعاد عالية. عند إرسال طلب بحث، يحوّل النموذج طلب البحث إلى متّجه ويعثر على أقرب النتائج المطابقة استنادًا إلى المسافة الدلالية. يتطابق تعليق حول تنين صغير يحرس الجوارب مع طلب حول المخلوقات السحرية بدون الحاجة إلى تطابق الكلمات الرئيسية تمامًا.
إعداد مجموعة مستندات RAG
ابدأ بإنشاء مجموعة النصوص باستخدام أزرار مساحة العمل أو أوامر الوحدة الطرفية:
- إنشاء مجموعة النصوص:
python -m agent.platform.ragruns/ragcorpus.json. - تحميل التعليقات وفهرستها: يتم تحميل
agent/comments.mdمع إعدادات التقسيم إلى أجزاء والانتظار إلى حين اكتمال الفهرسة. - طلب البحث في مجموعة النصوص: اختبِر استرجاع المحتوى المشابه باستخدام طلبات بحث لا تتضمّن الكلمات نفسها الواردة في التعليقات (مثلاً، ابحث عن "مخلوقات سحرية صغيرة" لاسترجاع التعليقات حول التنانين).
عقدة الاسترجاع (7B)
في مساحة العمل، انتقِل إلى القارئ الثالث (7B). افتح "stage5_rag/agent.py".
استرداد البيانات كعقدة رسم بياني
تمثّل ملاحظات الجمهور بيانات الأبحاث التي تتم مشاركتها في سير العمل. على عكس ذاكرة صنّاع المحتوى الشخصية، يتم إدخال آراء المشاهدين مباشرةً إلى join_research إلى جانب البيانات المتعلقة بالمواضيع الرائجة والمحتوى القديم. لذلك، يتم تنفيذه كعقدة دالة:
def read_feedback(node_input):
"""The third reader (step 7): what the audience wrote under past videos,
the passages nearest to tonight's idea. Retrieval, not a model call."""
from .platform import rag
idea = idea_text(node_input)
query = idea or "what viewers liked and what they complained about"
try:
hits = rag.retrieve(query)
except Exception as e:
print(f" [rag] feedback unavailable ({str(e)[:80]})")
return Event(output={"query": query, "feedback": [],
"note": "no corpus connected - run: python -m agent.platform.rag"})
return Event(output={"query": query, "feedback": [h["text"] for h in hits]})
تستخرج read_feedback فكرة المستخدم الأولية وتنفّذ طلب بحث متّجهي مقابل مجموعة مستندات "محرك التوليد المعزّز بالاسترجاع". يتم عرض التعليقات التي تم استردادها في Event(output=...) حمولة.
تعديل عملي: ربط القارئ الثالث بعملية التوزيع الموسَّع
في stage5_rag/agent.py، عدِّل edges لإضافة read_feedback كفرع ثالث متوازٍ يدخل join_research:
(START, read_backlog, join_research),
(START, read_feedback, join_research),
بما أنّ join_research هي JoinNode، فإنّها تزامن جميع الفروع الواردة، وتنتظر إلى أن تُصدر scan_trends وread_backlog وread_feedback جميع الأحداث قبل تمرير الحزمة المجمّعة إلى أسفل السلسلة.
ما يمكن توقّعه وسبب ذلك
تشغيل سير العمل في مساحة العمل:
- أرسِلوا طلبًا للحصول على أفكار (مثل "تنين صغير يحرس طاولة المطبخ").
- في تتبُّع التنفيذ، تأكَّد من تنفيذ جميع عُقد القارئ الثلاث في الوقت نفسه.
- لاحظ
join_research: يحتوي قاموس الإخراج الآن علىtrendsوbacklogوfeedback. - افحصوا المرشّحين الذين تم إنشاؤهم من
propose_directions: يدمج النموذج تعليقات المشاهدين في اقتراحاته ويشير إلى آراء الجمهور في حقول الأدلة. - يُرجى العِلم أنّ عملية الاسترجاع في RAG هي عملية حتمية (تؤدي طلبات البحث المتطابقة إلى عرض مقاطع تعليقات متطابقة)، في حين أنّ عقدة الاقتراح التوليدي تنتج أشكالاً إبداعية مختلفة.
8. إنشاء الفيديوهات بشكل غير متزامن باستخدام Veo
في VibeStudio Workbench، انتقِل إلى الخطوة 8 · الفيديو، الأجزاء (8A) و(8B).
يتطلّب إنشاء فيديو عالي الدقة باستخدام Google Veo عدة دقائق لكل عملية عرض. يؤدي حظر تنفيذ الرسم البياني خلال هذه الفترة إلى إهدار موارد الحوسبة، وإغلاق مجموعات سلاسل المحادثات، وتعريض عملية التشغيل لانقطاع الاتصال عبر HTTP. في هذه الخطوة، يمكنك جعل عرض الفيديو غير متزامن باستخدام LongRunningFunctionTool في "حزمة تطوير البرامج الإعلانية".
الأدوات التي تستغرق وقتًا طويلاً (8A)
في مساحة العمل، انتقِل إلى أداة تعمل لفترة طويلة (8A). افتح stage6_video/agent.py وagent/deliver.py.
الأدوات المتزامنة مقابل الأدوات التي تستغرق وقتًا طويلاً
يتم تنفيذ أدوات وظائف ADK العادية بشكل متزامن داخل دورة الوكيل: يستدعي النموذج الأداة، وينتظر حمولة الإرجاع، ويدمج النتيجة في الدورة الجارية.
لا يمكن إكمال عرض الفيديو في دورة واحدة. بدلاً من ذلك، يبدأ render_submit مهمة الإنشاء ويعرض على الفور إيصالاً تشغيليًا بالحالة "pending":
def render_submit(prompt: str) -> dict:
"""Submit one Veo render of `prompt`. Returns at once with a pending
receipt; the clip is delivered later, to this call, by id."""
receipt = videogen.start(f"{prompt} {videogen.NO_TEXT}")
return {"status": "pending", "operation": receipt["operation"], "prompt": receipt["prompt"]}
عند تضمينها في LongRunningFunctionTool، يعترض ADK على الحالة "pending". تنتهي نوبة الموظف، ويتم تعليق سير العمل عند العقدة، ويتم تسجيل البيانات الوصفية للمكالمة المعلّقة (بما في ذلك رقم تعريف المكالمة والإيصال) في runs/sessions.db. يتم إنهاء عملية التنفيذ بشكل سليم بدون الحفاظ على اتصالات الشبكة النشطة أو سلاسل العاملين.
تعديل عملي: تغليف أداة العرض
في stage6_video/agent.py، عدِّل render_desk لتضمين render_submit في LongRunningFunctionTool:
tools=[LongRunningFunctionTool(render_submit)])
استئناف المكالمة باستخدام رقم تعريف المكالمة
نمط الاستئناف العام
تطبِّق "حزمة تطوير التطبيقات" آلية مماثلة لتعليق عمليات سير العمل واستئنافها لكل من المستخدمين والأدوات الخارجية:
مشغّل التعليق | بدء الإنشاء | حالة التعليق المخزّنة | حدث الاستئناف |
قرار بشري |
| فتح طلب الإدخال في "متجر الجلسات" |
|
أداة تستغرق وقتًا طويلاً |
| فتح طلب استخدام الأداة في متجر الجلسات |
|
في كلتا الحالتين، يتوقف سير العمل تمامًا ولا يستأنف إلا عند وصول حدث يحمل FunctionResponse مطابق من مصدر خارجي: واجهة مستخدم أو خطاف ويب أو عملية تعمل في الخلفية.
التعديل العملي: إكمال الردّ بشأن التسليم
في agent/deliver.py، أنشئ جزء الاستئناف FunctionResponse:
part = Part(function_response=FunctionResponse(
id=row["call_id"], name=row["name"], response=response))
يطلب برنامج التشغيل من Veo بشكل متكرر إلى أن يتم إنشاء ملف الفيديو، ثم يرسل هذا الملف FunctionResponse إلى الجلسة. تطابق حزمة تطوير التطبيقات رقم تعريف المكالمة وتستأنف سير العمل مباشرةً عند العُقدة التالية. لا يتم إعادة تنفيذ العُقد المكتملة، ولا يتخذ الوكيل خطوة توليدية أخرى.
يؤدي ضبط STUDIO_REAL_VIDEO=0 في .env إلى تفعيل العرض التجريبي: تعرض الدالة start إيصال اختبار فوري، وتحاكي الدالة check عملية الإكمال في غضون خمس ثوانٍ بدون إجراء طلبات من واجهة Veo API قابلة للفوترة.
دمج مسار الإجراءات (8B)
في مساحة العمل، انتقِل إلى render_desk في الرسم البياني (8B). افتح "stage6_video/agent.py".
العقدة النهائية في سلسلة المعالجة هي store_video. يقرأ هذا الإجراء معلومات العرض المكتملة من runs/state.json (حيث سجّلتها عملية التسليم) ويحفظ عنوان URL للفيديو وحالة الإنشاء في حالة الجلسة المشترَكة.
تعديل عملي: ربط مسار الفيديو الكامل
في stage6_video/agent.py، عدِّل edges لإضافة render_desk وstore_video:
(quarantine, scripter),
(scripter, render_desk, store_video)])
ما يمكن توقّعه وسبب ذلك
اختبِر سير عمل الإنشاء غير المتزامن في مساحة العمل:
- تنفيذ سير العمل من خلال اختيار المرشّحين وإنشاء النصوص
- في
render_desk، راقِب الوكيل وهو يستدعيrender_submit. - يتم تعليق سير العمل على الفور. في "مساحة العمل" أو ADK Web، راقِب الحالة "في انتظار المراجعة": تحتفظ الجلسة بمعرّف المكالمة المفتوحة، ولا تستهلك أي عمليات في الخلفية الموارد.
- نفِّذ برنامج التشغيل الخاص بالتسليم باستخدام وحدة تحكّم Workbench أو في الوحدة الطرفية:
python -m agent.deliver - في ADK Web، أعِد تحميل الجلسة: يتم استئناف التنفيذ عند
store_video، ويتم إرسال عنوان URL للفيديو إلى حالة الجلسة، ويكتمل سير العمل.
9. النشر على Cloud Run
في VibeStudio Workbench، انتقِل إلى الخطوة 9: النشر.
لقد طوّرت كل مكوّن من مكونات سلسلة المعالجة وأثبتّ صحته في بيئات وضع الحماية المخصّصة. في هذه الخطوة، يمكنك تجميع خط الإنتاج الكامل ونشره على Google Cloud Run.
The ADK Runner
في مرحلة التطوير، adk web نظّم الرسم البياني. في مرحلة الإنتاج، يستضيف التطبيق سير العمل باستخدام فئة Runner في حزمة تطوير التطبيقات (ADK):
self._svc = DatabaseSessionService(db_url=config.DB_URL)
self._runner = Runner(app_name=config.APP, agent=wf, session_service=self._svc)
async for ev in self._runner.run_async(user_id=config.USER, session_id=run_id, new_message=message):
self._absorb(ev) # fold the ADK event into the run state, publish one app event
# the gate's answer and the render's delivery are the same call, with a function_response part
part = Part(function_response=FunctionResponse(id=call_id, name=name, response=response))
run_async: يؤدي إلى تنفيذ سير العمل، ما يؤدي إلى إنشاء الأحداث بالتسلسل أثناء تنفيذ العُقد، ويؤدي إلى استمرار التعديلات في خدمة الجلسة.- الاستئناف الموحّد: يتم استئناف تنفيذ كلّ من قرارات المستخدم في
direction_gateوعمليات تسليم الفيديو المكتملة من Veo من خلال عناصرFunctionResponseمتطابقة يتم إرسالها إلىrun_async.
بنية تطبيق الإنتاج
يتضمّن تطبيق الإنتاج في vibestudio/ مسار العمل الكامل:
vibestudio/
server/
main.py FastAPI: application server, REST routes, static assets
api.py REST API endpoints: run, pick, publish, backlog, profile, history
runner.py Runner orchestration over the workflow, background render poller
platform/ Event bus (SSE stream), file storage, publishing, telemetry
agent/ Production agent package, verified by checks/verify_app.py
graph.py The complete workflow graph and node definitions
desk.py render_desk and render_submit wrapped with LongRunningFunctionTool
schemas.py Pydantic schemas: Directions, CleanedDirection, Script
cleanup_tools.py Deterministic policy tools: find_policy_hits, suggest_replacement
platform/ Memory Bank, RAG Engine, and Veo integrations
web/ Production React user interface
Dockerfile · deploy.py · run.sh
- بث مباشر لحدث واحد: ينشر خادم FastAPI الخلفي الأحداث عبر بث مباشر واحد من أحداث Server-Sent Events (SSE). تعرض واجهة React الأمامية تقدّم الرسم البياني في الوقت الفعلي وتتعامل مع الاتصالات المتأخرة بدون فقدان الحالة.
- التنفيذ غير المرتبط: يدير التطبيق حلقة معالجة الأحداث. يركّز الرسم البياني لسير العمل بالكامل على منطق التنفيذ، ولا يدرك واجهة العرض الأمامية.
تجمع قائمة حواف سير العمل الكاملة في agent/graph.py كل أنماط التصميم التي تم إنشاؤها خلال هذا الدرس العملي:
(START, scan_trends, join_research),
(START, read_backlog, join_research),
(START, read_feedback, join_research),
(join_research, propose_directions, direction_gate,
persist_direction, policy_check),
(policy_check, {"OK": scripter, "BLOCK": quarantine}),
(quarantine, scripter),
(scripter, render_desk, store_video),
النشر على Cloud Run
توفّر خدمة Google Cloud Run استضافة بدون خادم مع إمكانية التوسّع التلقائي وتوجيه الطلبات وإنشاء الحاويات المدمجة:
gcloud run deploy vibestudio --source vibestudio \
--project $GOOGLE_CLOUD_PROJECT --region us-central1 \
--labels dev-tutorial-codelab=vibetube --allow-unauthenticated \
--memory 2Gi --cpu 2 --timeout 3600 --concurrency 40 \
--max-instances 1 --min-instances 1 --session-affinity \
--set-env-vars GOOGLE_CLOUD_PROJECT=...,STUDIO_VERTEX=1,STUDIO_MEMORY_BANK=...,STUDIO_RAG_CORPUS=...,VIBETUBE_URL=...,VIBETUBE_EVENT=...,VIBETUBE_NAME=...,VIBETUBE_PROJECT=...
- إنشاء الحاوية: تحزِّم
gcloud run deploy --sourceالدليلvibestudio/، وتنشئ صورة الحاوية باستخدام Cloud Build، وتنفّذ عملية نشر الخدمة في خطوة واحدة. - ربط الجلسة: يوجّه الطلبات من المستخدم نفسه إلى مثيل الحاوية نفسه، مع الحفاظ على حالة الجلسة المحلية في جميع الخطوات التكرارية.
- إمكانية المراقبة: يسجّل تكامل Cloud Trace النطاقات الموزّعة لكل عقدة ومكالمة نموذج لغوي كبير وتنفيذ أداة، ويمكن الوصول إليها في Google Cloud Console ضمن Trace Explorer.
انقر على الزر نشر في مساحة العمل لتنفيذ نص النشر البرمجي. عند اكتمال عملية الإنشاء، تعرض نافذة الوحدة الطرفية عنوان URL للخدمة المباشرة.
10. ملخّص
في VibeStudio Workbench، انتقِل إلى الخطوة 10: الملخّص لمراجعة البنية المكتملة.
الخطوة | البنية والمفاهيم | نمط التنفيذ |
طلب واحد | طلب واحد، وأدوات الدوال، وحلقة محادثة تسلسلية | |
أساسيات سير العمل بالذكاء الاصطناعي الوكيل | سير عمل الرسم البياني، والبحث المتوازي، ومخرجات المخطط، وبوابة التحقّق البشري |
|
الحالة والموجّه | حالة الجلسة المشتركة، وربط المَعلمات، والتوجيه الحتمي، ووكيل المهام |
|
Memory Bank | الذاكرة الطويلة الأمد على مستوى المستخدم، والدمج الدلالي، وخطوات مراحل النشاط | |
محرّك التوليد المعزّز بالاسترجاع (RAG) | استرداد المستندات من خلال تعليقات الجمهور، وعمليات التضمين الدلالي | عقدة |
إنشاء الفيديوهات بشكل غير متزامن باستخدام Veo | الأدوات التي تعمل لفترة طويلة، والإيصالات المعلّقة، وبرنامج خفي لتسليم الرسائل الخارجية |
|
النشر على Cloud Run | التنظيم الآلي، وأحداث Server-Sent Events، والحاويات بدون خادم | |
المبادئ الأساسية للتصميم
- التعليق بدلاً من الانتظار: يتم إيقاف مهام سير العمل مؤقتًا بشكل سلس لانتظار إدخال من المستخدم (
RequestInput) أو عمليات تستغرق وقتًا طويلاً (LongRunningFunctionTool). ولا تنتظر العمليات بدون نشاط على سلاسل المحادثات أو مآخذ الشبكة. - الاستئناف العام: يتم استئناف كل عملية تعليق من خلال آلية مماثلة:
function_responseواحد يحمل معرّف المكالمة للعقدة المعلّقة. - إدارة الحالة المنفصلة: تشارك العُقد البيانات من خلال مفاتيح حالة الجلسة المسماة وربط المَعلمات بدلاً من الحمولات الوسيطة المطوّلة والمترابطة بإحكام.
- التوجيه الحتمي قبل التكلفة التوليدية: تقيّم موجّهات التوجيه المستندة إلى القواعد وفلاتر التعبيرات العادية السياسة بتكلفة صفرية للرموز المميزة قبل تشغيل النماذج التوليدية.
- فصل الاهتمامات: يجب أن يكون السياق الخاص بعميل فردي ضمن عمليات رد الاتصال لدورة الحياة، بينما يجب أن تكون تبعيات البيانات المشتركة
