الانتقال إلى المحتوى الرئيسي
وكلاء البحث مفيدون عندما تريد أكثر من نتيجة بحث واحدة أو إجابة سريعة من نموذج. وكيل البحث الجيد يستطيع تحويل موضوع واسع إلى استعلامات بحث، وجمع المصادر، واستخراج الأدلة المهمة، ومتابعة الفجوات، وكتابة موجز مع استشهادات يمكنك فحصه لاحقًا. في هذا الدرس، سنبني وكيل بحث خاصًا باستخدام Python و Venice API. بنهاية الدرس، ستملك CLI يستطيع البحث في موضوع، وتحويل صفحات عامة إلى Markdown عبر scrape، وتلخيص مقاطع المصادر، وتشغيل تمريرات بحث متابعة واعية بالفجوات، وتوليد تقرير مع استشهادات إضافة إلى مخرجات JSONL محلية اختيارية. هل تهتم بالتنفيذ الكامل للكود؟ راجع مستودع GitHub. قبل المتابعة، ستحتاج إلى مفتاح Venice API:

ما الذي سنبنيه

التنفيذ المرجعي مشروع Python صغير ببضعة أجزاء واضحة: يبدو التدفق هكذا: خط أنابيب وكيل البحث الخاص
  1. اطلب من Venice توليد استعلامات بحث متنوعة للموضوع.
  2. ابحث في الويب مع مزوّد واحد أو أكثر.
  3. أزل تكرار الروابط قبل قراءتها.
  4. استخدم نقطة نهاية scrape من Venice لتحويل كل صفحة مصدر عامة إلى Markdown.
  5. قسّم الصفحات الطويلة إلى مقاطع.
  6. اطلب من Venice استخراج الأدلة من كل مقطع.
  7. اطلب من Venice تحويل أدلة المقاطع إلى ملاحظات مصدر.
  8. حدّد فجوات البحث ومشكلات توازن المصادر قبل توليد استعلامات متابعة.
  9. اطلب من Venice تركيب التقرير النهائي باستشهادات على شكل حواشٍ.
هذا «خاص» بالمعنى العملي بأن الوكيل يبقي التنسيق وملاحظات المصدر والمخرجات والتقارير النهائية على جهازك. ويتولى Venice استدعاءات النماذج والـ scrape عبر واجهته. التنفيذ المرجعي الافتراضي لا يزال يرسل استعلامات البحث إلى DuckDuckGo أو arXiv، لذا اعتبر اختيار المزوّد جزءًا من تصميم الخصوصية لديك.

إعداد المشروع

يستخدم المشروع المرجعي Python 3.13 وuv، لكن نفس الكود يعمل أيضًا مع بيئة افتراضية عادية. أنشئ مشروعًا جديدًا:
ثبّت التبعيات:
إذا فضّلت pip، أنشئ بيئة افتراضية وثبّت نفس الحزم:
أنشئ ملف .env للتطوير المحلي:
نستخدم VENICE_MODEL لتتمكن من تغيير النموذج دون تعديل الكود. التنفيذ المرجعي حاليًا افتراضيًا openai-gpt-55، لكن يمكنك استبداله بأي نموذج محادثة آخر متاح لحسابك في Venice.

إنشاء نماذج البيانات

قبل كتابة منطق الوكيل، سنُعرّف الكائنات التي تتحرّك عبر خط الأنابيب. تُسهّل هذه النماذج فهم باقي الكود لأن كل مصدر يحمل أصله: من أين أتى، وأي استعلام عثر عليه، ومتى تم استرجاعه، وكيف تم تقسيمه. أنشئ research_agent/models.py:
الحقول المهمة هنا هي canonical_url وcontent_hash وchunks. يتيح canonical_url للوكيل تجنّب قراءة نفس المصدر مرارًا عندما تختلف نتائج البحث فقط في معاملات التتبّع أو الشظايا. ويساعد content_hash على التقاط الصفحات المكررة حتى عندما تكون عند روابط مختلفة. ويسمح لنا chunks بتلخيص الصفحات الطويلة في قطع أصغر بدلًا من فقد أدلة مفيدة بسبب حدود السياق. أضف الدوال المساعدة أسفل dataclasses:
التقسيم هنا بسيط عمدًا: قطع بحجم حرفي ثابت مع تداخل. هذا يكفي لوكيل بحث تجريبي لأن نقطة نهاية scrape في Venice تُرجع Markdown، وهي عادةً أنظف بكثير من HTML الخام. للبحث الإنتاجي في مستندات تقنية طويلة، يمكنك تحسين هذا بالتقسيم على الترويسات أو الفقرات أو عدد الرموز.

بناء عميل Venice

بعدها، سننشئ عميل Venice صغيرًا. يمكنك استخدام OpenAI Python SDK لإكمالات المحادثة لأن Venice متوافق مع OpenAI، لكن التنفيذ المرجعي يستخدم httpx مباشرة بحيث يستطيع نفس العميل استدعاء نقطة نهاية POST /augment/scrape من Venice. أنشئ research_agent/venice.py:
تُبقي from_env() الأسرار خارج كود المصدر. كما تُسهّل التطوير المحلي لأن python-dotenv يستطيع تحميل VENICE_API_KEY وVENICE_MODEL من .env. الآن أضف إكمالات المحادثة:
للتقرير النهائي، نريد استخدام التدفق لأن التقارير العميقة قد تستغرق وقتًا أطول بكثير (لأنها ستنتج نصًا أكثر بكثير). يمكن أن يسبّب هذا مشكلات انقضاء مهلة الطلب الذي قد يستغرق وقتًا طويلًا جدًا لإنتاج الإخراج النهائي. باستخدام التدفق، يمكننا التخلص من هذه المشكلة وجعل الطلب أكثر مقاومة لأخطاء انقضاء المهلة:
ثم أضف الـ scrape:
تقبل نقطة نهاية scrape من Venice رابطًا متاحًا للعامة وتُرجع الصفحة بصيغة Markdown. هذا يعني أن النموذج لا يحتاج إلى تحليل HTML خام، ويمكن لاستخراج المصادر العمل بنص أنظف. تتولى الدالة المساعدة المتبقية إعادة المحاولات وتحليل الاستجابة:
يتضمن المستودع الكامل أيضًا مساعد _post_chat_stream() متين يقرأ server-sent events من إكمالات المحادثة المتدفقة. يمكنك البدء بدون تدفق، ثم إضافته بمجرد عمل بقية تدفق البحث.

إضافة مزوّدي البحث

طبقة البحث لها وظيفتان: العثور على روابط المصادر وجلب تلك الروابط عبر scrape من Venice. يستخدم التنفيذ المرجعي نقطة نهاية HTML من DuckDuckGo للبحث العام في الويب وApi Atom من arXiv للأوراق. أنشئ research_agent/web.py:
الآن أضف DuckDuckGo:
وarXiv:
تنسّق الفئة WebSearch المزوّدين وتجلب الصفحات:
يضيف التنفيذ المرجعي الكامل إعادات محاولة وتأخيرات طلبات على مستوى المضيف وأخطاء أوضح. هذه أمور يستحقّ الاحتفاظ بها لأن وكلاء البحث يقضون وقتًا طويلًا في التعامل مع صفحات تحجب الأتمتة، أو تُعيد التوجيه بشكل غير متوقع، أو تُرجع أخطاء عابرة. أضف الدوال المساعدة الصغيرة للمزوّدين في الأسفل:

كتابة المخرجات المحلية

في تدفقات البحث، يهمّ القابلية للتدقيق. إذا قال التقرير النهائي شيئًا مفاجئًا، ينبغي أن تكون قادرًا على فحص أي مصدر أدّى إليه. أنشئ research_agent/artifacts.py:
يكتب هذا كائن JSON واحدًا لكل سطر، مما يجعل المخرجات سهلة الإلحاق والفحص والمعالجة لاحقًا بأدوات سطر الأوامر.

بناء وكيل البحث

الآن وقد أصبح لدينا Venice والبحث والنماذج والمخرجات، يمكننا بناء الوكيل الفعلي. أنشئ research_agent/agent.py:
تعليمة النظام هي الضامن السلوكي الأساسي. لا نريد أن يُنتج النموذج تقريرًا يبدو مبهرًا من الذاكرة. نريده أن يستخدم المواد المصدرية ويُعلن عن عدم اليقين عندما تكون الأدلة شحيحة. نحتاج أيضًا إلى dataclasses نهائيتين في models.py إذا لم تضفهما بعد:
بعد ذلك، عرّف ResearchAgent:
تنسّق الطريقة run() تمريرات البحث:
المجموعتان seen_* هما ما يمنع الوكيل من إضاعة الوقت على مصادر مكرّرة. إزالة تكرار الروابط يلتقط الروابط المتكرّرة. وإزالة تكرار content_hash تلتقط المرايا والمنشورات المتعدّدة والصفحات التي تُعيد التوجيه إلى نفس المحتوى النهائي.

تخطيط عمليات البحث الأولية والمتابعة

استدعاء النموذج الأول يحوّل الموضوع إلى استعلامات بحث:
بعد كل تمريرة بحث، ينفّذ الوكيل المُحدَّث خطوة تحليل فجوات أكثر تأنّيًا. ينظر إلى الملاحظات الحالية، ويُحصي تجمعات المصادر حسب النطاق، ويسأل Venice عن التغطية المفقودة، ويكتب تلك الفجوات إلى المخرجات، ثم يستخدم الاستعلامات الناتجة للتمريرة التالية. حلقة تحليل الفجوات ابدأ بتتبّع توازن المصادر:
يمنح هذا الوكيل طريقة بسيطة لملاحظة احتجاز تجمعات المصادر. إذا كانت كل المصادر تأتي من شركة واحدة أو إطار عمل واحد أو نطاق واحد، فيجب أن توسّع استعلامات المتابعة مجموعة المصادر عمدًا بدلًا من جمع المزيد من نفس الشيء. الآن استخدم معلومات التوازن هذه عند إنشاء عمليات بحث المتابعة:
يلفّ التنفيذ المرجعي الأحدث هذا في _gap_follow_up_queries()، الذي يطلب من Venice إرجاع كل من سجلات الفجوات والاستعلامات:
عندما يكون --artifacts مُمكَّنًا، تُكتب هذه السجلات إلى research_gaps.jsonl. ذلك يمنحك أثر تدقيق مفيدًا لسبب بحث الوكيل عن استعلام تمريرة ثانية معيّن. ينبغي أن يكون المحلّل متسامحًا. إذا أعاد النموذج JSON مشوّهًا، يلجأ الوكيل إلى الموضوع الأصلي:
هذا النمط يستحق الاستخدام في كامل كود الوكيل: اطلب إخراجًا مُهيكلًا، حلّله، وقدّم بديلاً بسيطًا عندما لا يكون الإخراج صالحًا.

قراءة المصادر وتلخيصها

الآن نجمع ملاحظات المصدر. يبحث الوكيل عن كل استعلام، ويجلب كل نتيجة عبر scrape من Venice، ويقسّم Markdown، ويُلخّص الأدلة المفيدة.
يجب ألّا تُوقف إخفاقات البحث والجلب الفردية التشغيل بأكمله. الويب العام فوضوي. بعض الصفحات تحجب الـ scraping، وبعضها يُرجع PDF، وبعضها معطّل، وبعضها يُعيد التوجيه إلى أماكن غير متوقعة. ينبغي لوكيل البحث الاستمرار في التحرّك وتسجيل ما فشل. فيما يلي طريقة قراءة المصدر:
لكل مقطع مصدر، اطلب من Venice ملخصًا قصيرًا للأدلة واقتباسات حرفية:
ثم اطوِ ملخصات المقاطع في ملاحظة مصدر:
هذا التلخيص ذو الخطوتين هو الجزء الذي يجعل الوكيل يبدو أكثر موثوقية من سكربت «لخّص هذه الروابط» الأساسي. يقرأ النموذج مقاطع المصادر أولًا، ثم يكتب ملاحظة على مستوى المصدر من تلك الأدلة المستخرجة.

كتابة التقرير النهائي

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

إضافة واجهة CLI

الآن نحتاج إلى نقطة دخول من سطر الأوامر. أنشئ main.py:
تكشف الواجهة المفاتيح التي ستضبطها فعلًا أثناء البحث: الآن اربط كل شيء معًا:
يمنحنا هذا واجهة CLI بحث محلية تعمل.

تشغيل الوكيل

نفّذ تمريرة بحث سريعة:
اكتب التقرير إلى ملف Markdown:
استخدم مصادر أكثر ومزوّدين متعددين:
اختر أسلوب التقرير النهائي:
استخدم brief لملخص موجز مدعوم بالمصادر، وstandard لدراسة أوسع، وdeep لتدفق المخطط/الأقسام/المحرر المرحلي. احفظ مخرجات قابلة للتدقيق:
عندما تُمكَّن المخرجات، سترى ملفات مثل:
هذه الملفات مفيدة عندما تريد فهم كيف وصل الوكيل إلى استنتاج. مثلًا، يُظهر source_notes.jsonl أدلة المصدر المُلخّصة، ويُظهر research_gaps.jsonl لماذا وُلِّدت عمليات بحث المتابعة، ويُظهر errors.jsonl الصفحات التي فشلت أثناء البحث أو الـ scraping أو التلخيص.

ملاحظات الخصوصية والموثوقية

يلامس وكيل البحث عدة أنظمة، لذا يساعد أن تكون دقيقًا حول ما يذهب إلى أين: حدود بيانات وكيل البحث الخاص إذا أردت إبقاء المزيد من مسار البحث داخل Venice، يمكنك تكييف طبقة المزوّد لاستدعاء نقطة نهاية POST /augment/search من Venice بدلًا من الاستعلام من DuckDuckGo مباشرة. يستخدم التنفيذ المرجعي مزوّدين عامين بسيطين كي يبقى التجريب سهل التشغيل والفهم. من أجل الموثوقية، أبقِ هذه الإعدادات الافتراضية متحفظة:
  • استخدم إعادات محاولة لاستدعاءات Venice وطلبات الويب.
  • أضف --request-delay صغيرًا إذا كنت تقرأ صفحات كثيرة من نفس المضيف.
  • ضع حدًا أعلى لـ --max-sources كي لا تستمر المواضيع الواسعة إلى ما لا نهاية.
  • احفظ --artifacts للتقارير المهمة كي تستطيع تدقيق الإخراج النهائي.
  • اعتبر التقرير ملخصًا، لا حقيقة مطلقة. اتبع الاستشهادات إلى المصدر الأصلي حين تكون الدقة مهمة.

اختبار القطع

لا تحتاج إلى طلبات ويب حية أو استدعاءات Venice لاختبار معظم النظام. يستخدم المستودع المرجعي فئات Venice و web وهمية لاختبار حلقة البحث وسلوك إزالة التكرار والمخرجات وتعليمات التقرير. اختبار أول مفيد هو معايرة الروابط:
ثم اختبر أن المحتوى المكرّر يُتخطّى:
تجعل البدائل الوهمية اختبارات الوكيل أسرع بكثير وأقل تذبذبًا. يمكنك التحقق من منطق التنسيق دون الاعتماد على نتائج بحث حية، أو ظروف الشبكة، أو مخرجات النموذج.

القياس المرجعي (Benchmarking)

كثير من مزوّدي الذكاء الاصطناعي لديهم الآن تدفقات بحث عميق خاصة بهم، لذا يتضمن المستودع المرجعي قياسًا مرجعيًا بسيطًا مقابل أداة Deep Research من Perplexity. طُلب من كلا الوكيلين كتابة تقرير عن هندسة أُطر وكلاء الذكاء الاصطناعي، ثم أُودِعت التقارير المُولَّدة في مستودع GitHub. هذا ليس قياسًا رسميًا. إنه طريقة عملية لفحص هيكل التقرير وتغطية المصادر وجودة الاستشهادات وما إذا كان الوكيل يركّز فرطًا على تجمع مصدر واحد. ولهذا أيضًا يتتبّع التنفيذ المُحدَّث research_gaps.jsonl وتوازن المصادر قبل عمليات بحث المتابعة.

توسيع هذا المثال

بمجرد عمل الوكيل الأساسي، إليك طرقًا عملية لتحسينه:
  • أضف مزوّد بحث Venice باستخدام POST /augment/search.
  • خزّن التقارير والمخرجات في قاعدة بيانات SQLite صغيرة بدلًا من ملفات JSONL.
  • أضف قوائم بيضاء أو سوداء للنطاقات البحثية الموثوقة.
  • أضف دعم PDF بدمج Venice scrape مع تحليل المستندات للمصادر التي لا تكشف HTML نظيفًا.
  • أضف مجموعة تقييم من المواضيع وأنواع المصادر المتوقعة لتتمكن من مقارنة جودة البحث بعد تغييرات التعليمات.
  • أضف خطوة مراجعة تطلب من Venice إيجاد ادعاءات غير مدعومة في التقرير النهائي قبل حفظه.
أكبر ترقية هي عادةً اختيار مصادر أفضل. توليد الاستعلامات يساعد، لكن يمكنك أيضًا تحسين الجودة بتفضيل المصادر الأولية ومستندات المعايير والوثائق الرسمية والأوراق وسجلات التغيير وصفحات مجموعات البيانات على الملخصات منخفضة الإشارة.

الختام

شكرًا لقراءتك! آمل أن يكون هذا قد ساعدك على بناء وكيل بحث خاص عملي باستخدام Python و Venice API. النمط المفيد هنا ليس فقط «اطلب من نموذج البحث عن شيء». بل تقسيم البحث إلى خطوات قابلة للتدقيق: خطّط للبحث، اجمع المصادر، استخرج الأدلة، اكتب ملاحظات المصدر، تابع الفجوات، وركّب مع استشهادات. بإبقاء تلك الخطوات صريحة، نحصل على تدفق بحث أسهل في الفحص والاختبار والتحسين بمرور الوقت.