Transcript · English → Arabic
Building AI Agents with Google's ADK
في هذا الفيديو، ستتعلم ما هي وكلاء الذكاء الاصطناعي،
ليس نظريًا فحسب، بل عمليًا أيضًا.
سنلقي نظرة على الأفكار الكامنة وراء الوكلاء الحديثين،
ثم سنقوم ببناء أول وكيل ذكاء اصطناعي لك خطوة بخطوة باستخدام ADK من Google.
وفي النهاية، ستفهم كيف يستنتج الوكلاء،
ويتصرفون، ويتكيفون، وسيكون لديك كود يمكنك تشغيله بنفسك بالفعل.
إذًا، ما هي وكلاء الذكاء الاصطناعي؟
في أبسط المستويات، الوكيل هو برنامج لا يكتفي بالإجابة فحسب،
بل يمكنه اتخاذ القرار والتصرف.
بدلًا من إنشاء استجابة واحدة مثل روبوتات الدردشة التقليدية،
فإنه ينظر في طلبك،
ويحدد الخطوات التي يجب اتخاذها،
وربما يستدعي واجهة برمجة التطبيقات،
ويشغل الكود،
وينظر في النتائج، ثم يقرر ما يجب فعله بعد ذلك.
أحد أوضح التفسيرات
يأتي من الورقة البحثية REACT،
التآزر بين التفكير والعمل في النماذج اللغوية.
كانت الفكرة في تلك الورقة البحثية بسيطة ولكنها قوية.
لا ينبغي للنماذج اللغوية أن تولد النصوص دفعة واحدة فحسب، بل يمكنها في الواقع التفكير خطوة بخطوة، واتخاذ إجراء مثل استدعاء أداة أو واجهة برمجة التطبيقات،
ومراقبة النتائج، ومن ثم تقرير ما يجب فعله بعد ذلك.
إن دورة التفكير تلك،
والعمل،
والمراقبة، والتعديل هي الأساس لكيفية عمل وكلاء الذكاء الاصطناعي الحديثين.
وهذا يتماشى مع طريقة تعريفها.
أنظمة تتمتع بالتفكير،
والتخطيط، والذاكرة،
وبقدر كافٍ من الاستقلالية للتكيف واتخاذ القرارات نيابة عن المستخدم.
والآن، لا تتصرف جميع الوكلاء بالطريقة نفسها.
وهناك طريقة مفيدة للتفكير فيها وهي تقسيمها إلى ثلاثة أنماط عامة.
أولاً، لدينا الوكلاء المتسلسلون.
هؤلاء يعملون خطوة بخطوة مثل خط التجميع.
الخطوة الأولى، ثم الخطوة الثانية، ثم الخطوة الثالثة. إنها قابلة للتنبؤ، لكنها جامدة.
ثانيًا، لدينا الوكلاء التفاعليون.
هؤلاء يقررون في اللحظة ذاتها، ينظرون إلى الحالة الراهنة ويتساءلون: ماذا علي أن أفعل بعد ذلك؟
ربما الأداة (أ) في المرة الأولى، والأداة (ب) في المرة التالية.
إنهم مرنون، لكنهم لا يخططون مسبقًا.
أخيرًا، لدينا الوكلاء المتعمدون أو المخططون.
هؤلاء يتوقفون مؤقتًا لرسم خطة،
ثم ينفذون.
فكر في حجز رحلة سفر.
أنت لا تشتري تذكرة طيران بشكل عشوائي فحسب.
بل تختار التواريخ، والفنادق، ثم يكون هذا هو ترتيب الخطوات التي تتبعها.
إذن، أي من هذه الخيارات هو الأنسب لك؟
هذا يعتمد على المشكلة.
بالنسبة لتدفقات العمل البسيطة والقابلة للتنبؤ، فإن الأسلوب المتسلسل يعد جيدًا.
أما بالنسبة للتدفقات الديناميكية، فالتفاعلي يعمل بشكل أفضل.
وبالنسبة للأهداف متعددة الخطوات ذات الارتباطات المشتركة،
فأنت بحاجة إلى وكلاء التخطيط.
حسنًا، هذه هي النظرة العامة الشاملة.
الآن لنقم ببناء عميل بالفعل حتى تتمكن من رؤية هذه الأفكار قيد التطبيق.
سنقوم ببناء عميل لكتابة المدونات.
تمنحه موضوعًا، وسيقوم بإنشاء مخطط تفصيلي منظم، وتحويل ذلك المخطط إلى منشور مدونة كامل، ثم يقترح عناوين وجملًا جاذبة بديلة.
هنا يأتي دور فئات ADK.
بينما نستعرض الكود، لاحظ كيف أن عميل التخطيط وعميل الكتابة هما عميلا نماذج لغوية كبيرة (LLM)، واللذان يعملان بواسطة نموذج.
إنهما مغلفان في عملاء تكراريين، والذين يمثلون عملاء سير العمل في ADK.
يتعامل هؤلاء مع عمليات إعادة المحاولة تلقائيًا إذا فشل التحقق من الصحة.
وإذا أردنا شيئًا يتجاوز ذلك، فإن ADK سيسمح لنا أيضًا بتوسيع عميل مخصص من خلال إنشاء فئة فرعية من العميل الأساسي.
لذا دعونا نعد البيئة ثم نمر سطرًا بسطر عبر الكود.
أولًا، تحتاج إلى تثبيت UV.
يمكنك القيام بذلك عن طريق تشغيل الأمر هنا تمامًا.
ثانيًا، تحتاج إلى تثبيت Google ADK لأننا بحاجة بالطبع إلى استخدام ADK في هذا.
وبعد ذلك، لننشئ ملفًا باسم agent.py في بيئة التطوير المتكاملة الخاصة بك.
نحن بحاجة إلى استيراد هذه المكتبات الرئيسية ومن ثم يمكننا البدء في بناء عميلنا الأول على الإطلاق.
إذن، العميل الأول الذي نقوم ببنائه يسمى مخطط المدونة.
مهمته الوحيدة هي أخذ موضوع ما وتحويله إلى مخطط تفصيلي منظم.
لقد أطلقنا عليه اسم مخطط المدونة ليسهل التعرف عليه ونخبره بالنموذج الذي يجب استخدامه، والذي يأتي من ملف البيئة الخاص بنا.
الوصف هو مجرد ملاحظة يمكن للإنسان قراءتها.
الجزء المهم من المقدمة
هو أننا هنا نخبره بالفعل بما يجب إنتاجه، وهو مخطط تفصيلي بتنسيق markdown مع عنوان ومقدمة قصيرة،
أربعة إلى ستة أقسام مع نقاط رئيسية وخاتمة.
بتوضيح ذلك بالتفصيل، نجعل المخرجات أكثر موثوقية بكثير.
أخيرًا، انظر إلى مفتاح المخرجات.
لقد قمنا بضبطه على مخطط المدونة.
هذا يعني أن كل ما يكتبه هذا العميل سيتم تخزينه في الحالة المشتركة
تحت هذا الاسم حتى يتمكن العميل
التالي الذي يمكنه استلامه من القيام بذلك تلقائيًا.
بعد ذلك، نضيف عميلاً ثانيًا،
مدقق التحقق من صحة المخطط.
هذا العميل لا يكتب أي شيء جديد.
إنه يتحقق فقط من المخطط.
تعليماته صارمة.
إذا كان المخطط في الحالة يحتوي على عنوان،
ومقدمة، وأربعة إلى ستة أقسام، وخاتمة،
يجب أن يجيب بكلمة موافق.
إذا كان هناك شيء مفقود،
يجب أن يجيب بكلمة إعادة المحاولة ويشرح الخطأ.
وبهذه الطريقة، يمكننا تلقائيًا تحديد ما إذا كنا سنقبل
المخطط أو نحاول مرة أخرى.
لربط المخطط والمدقق،
قمنا بتغليفهما داخل عميل حلقة تكرارية يُدعى مخطط المدونة القوي.
تقوم الحلقة أولاً بتشغيل المخطط،
ثم المدقق.
إذا قال المدقق موافق، نكون قد انتهينا.
إذا قال المدقق أعد المحاولة، تقوم الحلقة بتشغيل المخطط مجددًا بنفس التعليمات.
يمكنها القيام بذلك حتى ثلاث مرات.
هذا يمنحنا شبكة أمان بحيث
إذا نسي النموذج شيئًا ما، فستكون لديه فرصة أخرى لتصحيحه.
الآن نقوم بإنشاء عميل آخر يُدعى كاتب المدونة.
يأخذ هذا العميل المخطط التفصيلي الذي حفظناه للتو في blog underscore outline و
ويحوله إلى منشور مدونة كامل بصيغة markdown.
تخبره التعليمات بكيفية الكتابة.
يجب أن يفترض أن الجمهور هم مهندسو برمجيات،
وأن يتخطى الأساسيات، ويركز على الرؤى العملية،
اشرح كلاً من الكيفية والسبب، و أدرج مقتطفات برمجية قصيرة حيثما كان ذلك مفيدًا.
يجب أيضًا أن يتبع هيكل المخطط التفصيلي مع عناوين مناسبة.
يتم حفظ المسودة النهائية تحت blog_post في الحالة المشتركة،
جاهزة للخطوة التالية.
بعد ذلك، سنقوم بإضافة مدقق آخر، هذه المرة للمنشور.
يطلق عليه مدقق التحقق من صحة منشور المدونة.
ينظر إلى blog_post و يتحقق مما إذا كان المقال يحتوي على مقدمة،
وأقسام تطابق المخطط التفصيلي،
وخاتمة، وتفسيرات واضحة.
إذا نجح، يقول المدقق، حسنًا.
وإذا لم ينجح، فإنه يقول أعد المحاولة ويذكر الإصلاحات المطلوبة.
تمامًا كما هو الحال مع التخطيط، ندمج الكاتب و مدققه في وكيل حلقي يسمى كاتب المدونة القوي.
هذا يجعل النظام يعيد محاولة خطوة الكتابة تلقائيًا حتى ينجح التحقق، بحد أقصى ثلاث مرات.
الآن، نقوم بتغليف كل حلقة، RobustBlogPlanner و RobustBlogWriter كأدوات.
هذا هو ما يسمح للعميل الجذري باستدعائهما مباشرة دون القلق بشأن ما يحدث في الداخل.
أخيرًا، نجمع كل شيء معًا مع العميل الجذري المسمى Blogger.
التعليمات الخاصة بـ Blogger بسيطة.
عندما يعطيه المستخدم موضوعًا، فإنه أولاً يستدعي أداة المخطط لإنشاء مخطط تفصيلي،
ثم يستدعي أداة الكاتب لصياغة المنشور الكامل،
وأخيرًا يضيف ثلاثة عناوين بديلة وجاذبين بطول التغريدة.
يمتلك العميل الجذري فقط إمكانية الوصول إلى الأداتين اللتين كشفناهما،
المخطط والكاتب.
لذا فإن سير عمله واضح ومتحكم فيه.
تمنحه موضوعًا، فيخطط، ويكتب، ويدقق، ثم يمنحك منشور مدونة مصقولًا.
لقد كتبت الآن بنجاح أول نص برمجي للعميل الخاص بك.
الخطوة التالية هي تشغيله بالفعل.
توجه إلى واجهة الأوامر وشغّله باستخدام هذا الأمر مع ADKWeb
حتى تتمكن من عرض كل شيء داخل واجهة مستخدم بسيطة.
بمجرد تشغيله،
افتح رابط ADKWeb المحلي في متصفحك وابدأ في التفاعل مع العميل مباشرةً.
لبدء الأمر، سأطلب منه إنشاء مدونة حول أفضل 10 حالات استخدام لعملاء الذكاء الاصطناعي.
دعنا نرى كيف يخطط،
ويكتب، ويقدم النتائج.
سيعمل عملاؤك الفرعيون معًا بعد ذلك لإنشاء منشور مدونة.
وهذا كل شيء!
لقد قمت ببناء وتشغيل أول عميل ذكاء اصطناعي لك باستخدام ADK من Google.
لقد بدأنا من فكرة ماهية الوكلاء، ثم استعرضنا الكود خطوة بخطوة، وفي النهاية رأيناه ينبض بالحياة في Terminal.
شكراً لكم على المشاهدة.
تحقق من صندوق الوصف للحصول على جميع المصادر والكود المذكورة في هذا الفيديو.
شاهد الفيديو التالي لتتعلم كيفية ربط وكيل الذكاء الاصطناعي الخاص بك بخادم MCP.
شكراً لكم على المشاهدة.
End of transcript · 1,205 words · machine translated
Original transcript (English)
In this video, you're going to learn what AI agents are, not just in theory, but in practice. We'll look at the ideas behind modern agents, and then we'll build your very first AI agent step-by-step using Google's ADK. By the end, you'll understand how agents reason,
act, and adapt, and you'll have code that you can actually run yourself. So what are AI agents? At the simplest level, an agent is software that doesn't just answer, it can decide and take action. Instead of generating a single response like a traditional chatbot,
it looks at your request, figures out what steps need to be taken, maybe calls an API, runs code, looks at the results, and then decides what to do next.
One of the clearest explanations comes from the research paper REACT, Synergizing Reasoning and Acting in Language Models. The idea in that paper was simple but powerful. Language models shouldn't just generate text in one go, they can actually reason step-by-step, take an action like calling a tool or API,
observe the results, and then decide what to do next. That cycle of reasoning, acting, observing, and adjusting is the foundation of how modern AI agents work. And it lines up with how it's defined.
Systems with reasoning, planning, and memory, with enough autonomy to adapt and make decisions on behalf of the user. Now, not all agents behave the same way. A useful way to think about them is in three broad patterns.
First, we have sequential agents. These run step-by-step like an assembly line. Step one, then step two, then step three. They're predictable, but rigid. Second, we have reactive agents. These decide in the moment, they look at the current state and ask, what should I do next?
Maybe tool A one time, tool B the next. They're flexible, but they don't plan ahead. Lastly, we have deliberate or planning agents. These pause to sketch a plan, then execute.
Think about booking travel. You don't just buy a flight randomly. You pick dates, hotels, and then that's the order of steps that you follow through. So which of these is the right one for you? It depends on the problem.
For simple, predictable flows, sequential is fine. For dynamic, reactive works better. And for multi-step goals with dependencies, you want planning agents. Okay, that's the high-level view.
Now let's actually build an agent so you can see these ideas in action. We'll build a blog writing agent. You give it a topic. It will generate a structured outline, turn that outline into a full blog post, and then suggest alternative titles and hooks. This is where ADK's categories comes in. As we walk through the code, notice how the planner and writer agent are LLM agents, which are powered by a model.
They're wrapped in loop agents, which are workflow agents in ADK. These handle retries automatically if validation fails. And if we ever wanted something beyond that, ADK would also let us extend a custom agent by subclassing the base agent. So let's set up the environment and then go line by line through the code. First off, you need to install UV.
You can do that by running the command right here. Secondly, you need to install Google ADK because we need to obviously use ADK in this. And then let's create a file called agent.py in your IDE. We need to import these key libraries and then we can start building out our very first agent. So the first agent that we're building out is called the blog planner.
Its only job is to take a topic and turn it into a structured outline. We give it the name blog planner so it's easy to identify and we tell it which model to use, which comes from our environment file. The description is just a human readable note. The important part of the introduction is here we actually tell it what to produce, which is a markdown outline with a title, a short introduction,
four to six sections with bullet points and a conclusion. By spelling that out, we make the output much more reliable. Finally, look at the output key. We set it to blog outline. This means whatever this agent writes will be stored in shared state
under that name so that the next agent that can pick it up can do it automatically. Next, we add a second agent, the outline validation checker. This one doesn't write anything new.
It just checks the outline. Its instruction is strict. If the outline in state has a title, an intro, four to six sections, and a conclusion, it must answer with the word okay.
If something is missing, it must answer with the word retry and explain what's wrong. That way, we can automatically decide whether to accept the outline or try again. To connect the planner and the checker,
we've wrapped them inside a loop agent called robust blog planner. The loop first runs the planner, then the checker. If the checker says okay, we're done. If the checker says retry, the loop runs the planner again with the same instructions.
It can do this up to three times. This gives us a safety net so if the model forgets something, it has another chance to get it right. Now we create another agent called blog writer. This one takes the outline we just saved in blog underscore outline and
turns it into a full markdown blog post. The instruction tells it how to write. It should assume the audience is software engineers, skip the basics, and focus on practical insights, explain both the how and the why, and include short code snippets where helpful.
It should also follow the structure of the outline with proper headings. The finished draft is saved under blog underscore post in shared state, ready for the next step. Next up, we're gonna add another checker, this time for the post. It's called blog post validation checker.
It looks at blog underscore post and checks if the article has an introduction, as sections that match the outline, a conclusion, and clear explanations. If it passes, the checker says, okay. If not, it says retry and list the fixes which are needed.
Just like with planning, we combine the writer and its checker into a loop agent called robust blog writer. This makes the system automatically retry the writing step until the validation passes, up to three times. Now, we wrap each loop, the RobustBlogPlanner and the RobustBlogWriter as tools. This is what lets the root agent call them directly without worrying about what's happening inside. Finally, we put it all together with the root agent called Blogger.
The instructions for Blogger are simple. When a user gives it a topic, first it calls the Planner tool to make an outline, then it calls the Writer tool to draft the full post, and finally it adds three alternative titles and two tweet-length hooks. The root agent only has access to the two tools we exposed,
the Planner and the Writer. So its workflow is clear and controlled. You give it a topic, it plans, it writes, it checks, and then it gives you a polished blog post. You've now successfully written your first agent script. The next step is to actually run it.
Head into your terminal and launch it using this command with ADKWeb so you can view everything inside a simple UI. Once that's running, open the local ADKWeb link in your browser and start interacting with the agent directly. To kick things off, I'm going to ask it to generate a blog on the top 10 use cases for AI agents.
Let's see how it plans, writes, and delivers the results. Your sub-agents will then work together to create a blog post. And that's it! You've built and run your first AI agent with Google's ADK.
We started from the idea of what agents are, then walked through the code step by step, and finally saw it come to life in Terminal. Thank you for watching. Check out the description box for all the resources and code mentioned in this video. Check out this next video to learn how to connect your AI agent to an MCP server. Thanks for watching.