العامل البرمجي هو نظام ذكاء اصطناعي يستخدم نموذج لغة كبير (LLM) كنواة استدلال له لكتابة وتنفيذ وتكرار الكود بشكل ذاتي. على عكس مساعد الكود الذي يقترح عمليات الإكمال في محررك، يقوم العامل البرمجي بتشغيل حلقة كاملة من المراقبة-اتخاذ القرار-التنفيذ: فهو يقرأ الملفات، ويكتب التغييرات، وينفذ الأوامر، ويتحقق من المخرجات، ويُراجع حتى اكتمال المهمة.
تشرح هذه المقالة كيفية عمل هذه الحلقة - المُخطط، وطبقة استدلال LLM، والأدوات، وبيئة التنفيذ المعزولة - ثم توضح كيفية تجميع واحدة باستخدام API LLM من Novita و Agent Sandbox. إذا كنت تبحث عن طبقة الأدوات الجاهزة بدلاً من طبقة العامل، فراجع أفضل أدوات البرمجة بالذكاء الاصطناعي في 2026. إذا كنت تبحث عن المتغير الخاص بـ Claude لهذه الحلقة، فاقرأ ما هو عامل برمجة Claude؟.
للحصول على نظرة أعمق حول اختيارات النماذج العملية داخل هذه البنية، اقرأ حالات استخدام نموذج اللغة الكبير للعوامل البرمجية.
إذا كنت تريد النسخة العملية لسير العمل من نفس هذه الحلقة، فانظر كيفية أتمتة المهام بالذكاء الاصطناعي.
إذا كنت تقارن أدوات المصدر المفتوح تحديدًا، فانظر عوامل البرمجة مفتوحة المصدر: أفضل الأدوات وكيفية بناء واحدة.
ما الذي يجعل الشيء عاملاً برمجياً
الفرق بين مساعد الكود والعامل البرمجي هو التنفيذ. مساعد الكود يُنشئ اقتراحًا ويتوقف. عامل البرمجة بالذكاء الاصطناعي يُنشئ كودًا، ويُشغله، ويقرأ النتيجة، ويستمر حتى يتم تحقيق الهدف - أو حتى يتعثر.
قدرة التنفيذ هذه لها ثلاثة متطلبات ملموسة:
- الوصول إلى الأدوات — القدرة على قراءة الملفات وكتابة الملفات وتشغيل أوامر الصدفة
- بيئة معزولة (صندوق رمل) — مكان لتنفيذ الكود دون الإضرار بالنظام المضيف في حالة حدوث خطأ
- سياق مستمر — تُغذى مخرجات الأدوات مرة أخرى في سياق النموذج حتى يتمكن من التفكير فيما حدث
بدون هذه العناصر الثلاثة، يكون لديك روبوت محادثة يمكنه كتابة الكود. مع هذه العناصر الثلاثة، يكون لديك عامل.
يُستخدم مصطلح “عامل برمجي” بشكل فضفاض ليشمل كل شيء من اقتراحات IDE المضمنة إلى الأنظمة المستقلة تمامًا التي يمكنها أخذ مهمة محددة بشكل غامض، ومعرفة الملفات المعنية، وإجراء التغييرات، والتحقق من أنها تعمل - دون تدخل بشري في كل خطوة. عندما يقارن المطورون خيارات “أفضل عامل برمجي”، فإنهم عادةً ما يقصدون الأخير: الأنظمة التي تكمل مهام البرمجة متعددة الخطوات بشكل موثوق مع الحد الأدنى من التوجيه.
الطبقات الأربع لعامل برمجي
يحتوي كل عامل برمجي بالذكاء الاصطناعي من فئة الإنتاج على أربعة مكونات يمكن التعرف عليها. تختلف تفاصيل التنفيذ - أطر عمل مختلفة، نماذج LLM مختلفة، مزودو صناديق رمل مختلفة - لكن البنية متسقة.
1. المُخطط
يتلقى المُخطط وصف المهمة ويقسمها إلى خطوات سينفذها العامل. بالنسبة للمهام البسيطة، يحدث هذا ضمنيًا داخل استدلال النموذج. بالنسبة للمهام المعقدة - “قم بترحيل هذه الخدمة لاستخدام مكتبة المصادقة الجديدة” - تنتج خطوة تخطيط صريحة قائمة مهام مرقمة يعمل من خلالها النموذج، محدثًا الحالة بعد كل خطوة.
يحدد التخطيط أيضًا متى يتوقف. العامل الذي لا يحتوي على معيار إكمال سيستمر في إضافة تحسينات إلى أجل غير مسمى أو، الأسوأ من ذلك، سيتكرر في حلقة على خطوة فاشلة. تقوم معظم التطبيقات بتشفير شرط نجاح المهمة في رسالة النظام وتدع النموذج يقرر متى ينتهي.
2. طبقة استدلال LLM
نموذج LLM هو نواة الاستدلال لأي عامل برمجة بالذكاء الاصطناعي. يقرر أي أداة يجب استدعاؤها بعد ذلك، وما الوسائط التي يجب تمريرها، وكيفية تفسير المتيجة. يتم التعبير عن ذلك القررار كاستدعاء أداة منظم - كائن JSON مع اسم الوظيفة والمعلمات - والذي يقوم الإطار بصرفه إلى طبقة التنفيذ الفعلية.
بالنسبة للعوامل البرمجية، يحتاج نموذج LLM إلى التعامل مع السياقات الطويلة بشكل موثوق (تتراك مخرجات الأدوات بسمرعة)، وإعادة استدعاءات الأدوات جيدة التكوين بشكل متسق (JSON غير منظم بشكل جيد في الخطوة 6 من سير عمل من 10 خطوات يكمل التشغيل بالكامل)، والتفكير في تغييرات الحالة عبر العديد من استدعاءات الأدوات المتسلسلة.
مزود الاستدلال مهم هنا. تحتاج إلى API يدعم استدعاء الوظائف بصيغة متوافقة مع OpenAI، ومخرجات منظمة لفرد صحة JSON على مستو النموذج، وحدود كافية للتزامن لأحمال العوامل التي تنتج مهما فرعية متوازية. يغطي API LLM من Novita AI هذه الثلاثة جميعًا مع نقطة نهاية متوافقة مع OpenAI، مما يعني أنه يمكنك تبديل النماذج دون إعادة كتابة منطق تحليل استدعاء الأداة.
3. طبقة الأداة
الأدوات هي واجهة العامل مع العالم. يحتاج العامل البرمجي الأدنى إلى أربعة:
| الأداة | وظيفتها |
|---|---|
read_file |
إعادة محتويات ملف في مسار معين |
write_file |
كتاة سلسلة نصية إلى مسار ملف |
run_command |
تنفيذ أمر صدفي وإعادة stdout + stderr |
list_directory |
سرد الملفات والدلائل في مسار |
يجب أن تعيد كل أداة مخرجات كاملة. النتائج المقطوعة أو الإخفاقات الصامتة تفسد نموذج العامل لقاعدة الأكواد وتتسبب في أخطاء متراكمة لحقًا. تحتاج أداة run_command خاصة إلى التقاط كل من stdout و stderr - غالبًا ما يتعلم العامل من مخرجات الخطأ أكثر من مخرجات النجاح.
يضيف البعض أداة search_files للبحث بنمط grep عبر قاعدة الأكواد، أو أداة fetch_url لقراءة الوثائق الخارجية. المجموعة المناسبة تعتمد على مجال المهمة. للعمل البرمجي البحت، الأربعة أعلاه تغطي معظم الحالات.
4. الصندوق الرملي (Sandbox)
الصندوق الرملي هو بيئة لينكس معزولة تمامًا حيث يتم تشغيل أوامر العامل فعلًا. هذا مهم لسببين.
أولاً، الأمان. العوامل تنشئ كودًا من استفسارات المستخدم، والوثائق المستردة، والأنماط المستنتجة. حتى العامل حيس النية يمكنه إنتاج كود يمحو الملفات، أو يفتح اتصالات الشبةكة، أو يستهلك موارا غير محدودة. يحافظ الصندوق الرملي على أي ضرر محصورًا داخل بيئة معزولة.
ثانيًا، الحالة. صندوق رملي جيد يحافظ على حالة نظام الملفات عبر استدعاءات الأدوات داخل الجلسة. إذا أنشأ العامل ملقًا في الخطوة 2، يج أن يكون مازال موجودًا في الخطوة 8. طرق الحاويات عديمة الحالة - حيث يتم تشغيل كل أمر في بيئة جديدة - لا تنجح للمها البرمجية الحقيقية.
صندوق رمل عوامل Novita مبني على أجهزة Firecracker microVM الدقيقة، مما يمنحك عزلاً على مسوو النواة أقوو من الحاويات القياسية. يمكن للجلسات التشغيل لمدة تصل إلى 24 سااعة، وتستمر حالة نظام الملفات عبر الأوامر، ويكون بدء التشغيل البارد أقل من 200 مللي ثانية. هذا سريع بما يكفي بحيث لا يؤدي انتظار تشغيل الصندوق الرملي إلى مقاطعة سير العمل التفاعلي.
كيف تعمل حلقة التنفيذ
مثال ملموس يجعل من الأسهل متابعة الحلقة. افترض أن المهمة هي: “إضافة تحديد معدل إلى نقطة النهاية /login.”
-
خطّط — يقرأ النموذج المهمة ويحدد ما يحتاجه: ابحث عن مسار تسجيل الدخول، افهم المعالج الحالي، أضف وسبة متوسطة لتحديد المعدل، تحقق من خلاختبار تجريبي.
-
لاحظ — ياستدعي العامل
list_directoryللعثور على ملفات المسار، ثمread_fileعلى معالج تسجيل الدخول. يتم إلحاق محتويات الملف بسياق النموذج. -
قرر — يسبب النموذج في الكود الحالي ويقرر ما سيفعله: قم بتثبيت مكتبة تحديد المعدل، قم بتعديل المعالج، أضف اختبارًا.
-
تصرف — ياستدعي العامل
run_command("pip install slowapi")، ثمwrite_fileمع المعالج المعدل، ثمrun_command("pytest tests/test_login.py"). -
لاحظ مرة أخرى — تُغذى مخرجات الاختبار مرة أخرى في السياق. إذا فشلت الاختبارات، يقرأ النموذج تتبع الأخطاء، ويحدد الخطأ، ويكتب ملفًا مصححًا.
-
أكمل — عندما تنجح الاختبارات وليس لدى النموذج خطوات معلقة، يُرجع ملخصًا نهائيًا.
هذه الحلقة تعمل داخل جلسة واحدة. نافذة السياق هي ذاكرة العمل للعامل - كل ملف يُقرأ، كل مخرجات أمر، كل استدعاء أداة يتراكم هناك. لهذا السبب يهم طول السياق كثيرًا للعوامل البرمجية: مهمة إعادة هيكلة حقيقية يمكنها بسهولة مأ 100K توكن بحلول ال خطةوة 15. انظر كيية تضغط العوامل مزودي الاستدلال بشكل مختلف عن الدردشة ذات الدورة الواحدة.
بناء عامل برمجي مع Novita
يصل المثال التالي بين API LLM من Novita و Agent Sandbox. يسختم حزمة Python OpenAI SDK موجهة إلى نقطة نهاية Novita - تسخدم نماذج Novita نفا واجهة استدعاء الوظائف مثل API OpenAI، لذلك لا يتطلب التكامل تحليلاً مخصصًا.
import os
import json
from openai import OpenAI
from novita_sandbox.code_interpreter import Sandbox
client = OpenAI(
base_url="https://api.novita.ai/openai",
api_key=os.environ["NOVITA_API_KEY"],
)
sandbox = Sandbox.create(timeout=1800)
def read_file(path: str) -> str:
try:
return sandbox.files.read(path)
except Exception as e:
return f"Error: {e}"
def write_file(path: str, content: str) -> str:
try:
sandbox.files.write(path, content)
return f"Written to {path}"
except Exception as e:
return f"Error: {e}"
def run_command(cmd: str) -> str:
try:
result = sandbox.commands.run(cmd)
return str(result)
except Exception as e:
return f"Error: {e}"
tools = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Read the contents of a file",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "write_file",
"description": "Write content to a file",
"parameters": {
"type": "object",
"properties": {
"path": {"type": "string"},
"content": {"type": "string"}
},
"required": ["path", "content"],
},
},
},
{
"type": "function",
"function": {
"name": "run_command",
"descripton": "Run a shell command in the sandbox and return output",
"parameters": {
"type": "object",
"properties": {"cmd": {"type": "string"}},
"required": ["cmd"],
},
},
},
]
dispatch = {
"read_file": read_file,
"write_file": write_file,
"run_command": run_command,
}
def run_agent(task: str, model: str) -> str:
messages = [
{
"role": "system",
"content": {
"You are a coding agent with access to a Linux sandbox. "
"Complete tasks by calling tools. When done, return a plain-text summary."
},
},
{"role": "user", "content": task},
]
while True:
response = client.chat.completions.create(
model=model,
messages=messages,
tools=tools,
tool_choice="auto",
)
msg = response.choices[0].message
messages.append(msg)
if not msg.tool_calls:
return msg.content
for call in msg.tool_calls:
fn = dispatch[call.function.name]
args = json.loads(call.function.arguments)
result = fn(**args)
messages.append(
{
"role": "tool",
"tool_call_id": call.id,
"content": result,
}
)
# Replace <model-id> with a function-calling model from novita.ai/docs
result = run_agent(
task="Write a Python script that counts words in a text file and run it on a sample input",
model="<model-id>",
)
print(result)
sandbox.kill()
بعض الملاحظات حول هذا التنفيذ:
- تعمل حلعة
while Trueحتى يعد النموذج رسالة بدون استدعاءات أداوة - هذا هو الإشارة إلى أن العامل يعتبر المهمة منجزة. - يتم إضافة نتائج الأدوات إلى
messagesكمدخلاتrole: tool. هذا ما يبني السياق المشترك عبر الخطوات. sandbox.kill()تحرر موارا الحوسبة. اسدعها دائمًا عنمد انتهاء الجلسة.
لمعرفة أيدي نماذج استدعاء الوظائف المدعومة، راجع وثائق استدعاء وظائف Novita. للحصول على شرح أكثر اكتمالاً بما في ذلك واجهة Gradio، انظر بناء عامل برمجي مع صندوق رمل عوامر Novita.
اختيار نموذج LLM المناس للعوامر البرمجية
تقيس HumanEval و SWE-bench توليد الكود لمرة واحدة. أعمال العوامل مختلفة - ما يكسر فعليًا عوامل الكود الإنتاجية هو فشل تنسيق استدعاء الأداة. النموذج الذي يسجل درجات عالية في المقاييس ولكن يُرجع أحيانًا JSON غير منظم في جلسات معقدة متعددة الأدوار سيفشل بطرق يصعب تصحيحها.
معايير التقييم العملية لعوامر البرمجة بالذكاء الاصطناعي:
- موثوقية استدعاء الأداة — ما مدى اتساق عودة النموذج لاستدعاءات أدوات جيدة التكوين عبر جلسات من 20+ خطوة؟
- الاحتفاظ بالسياق — هل يشير النموذج بشكل صحيح إلى ملف قرأه قبل 40 خطوة؟
- اتباع التعليمات — هل يبقى العامل على المهمة أم يبدأ في تعديل ملفات غير ذات صلة؟
- صحة الكود — هل يعمل الكود المولد بالفعل أم يتطلب حلقات تصحيح متعددة؟
تشغيل مجموعة ممثلة من مهام البرمجة الحقيقية وقياس معدل إنجاز المهمة أكثر إفادة من أي مقياس عام. اختر 20-30 مهمة من قاعدة الأكواد الخاصة بك، شغلها ضد النماذج المرشحة، واحسب عدد المهام التي تكتمل دون تدخل بشري.
تتراكم أسعار الاستدلال بسرعة على نطاق العوامل. قد تستهلك جلسة واحدة 200K-500K توكن عبر جميع الأدوار. المزودون الذين يقدمون التخزين المؤقت للاستفسارات ومعدلات تنافسية لكل توكن يغيرون الاقتصاديات بشكل كبير عندما تدير مئات جلسات العوامل يوميًا.
النماذج مفتوحة المصدر كمسار فعال من حيث التكلفة
قادت النماذج الحدودية المغلقة في مقاييس البرمجة، لكن الفجوة مع النماذج الرفيعة مفتوحة المصدر قد تضيقت بشكل كبير. نماذج مثل DeepSeek V3 و Qwen3 تقدم أداءً تنافسيًا الآن في توليد الكود واستخدام الأدوات - و لأنه يتم تقديمها من خلال واجهات API متوافقة مع OpenAI، فالتغيير يكو تغيير سطر واح في المعامل model.
كلاهما متاح من خلال API LLM من Novita. تحصل على نفس نقطة النهاية، نفس واجهة استدعاء الوظائف، ونفس تكامل صندوق الرمل للعوامل - دون إدارة البنية التحتية ل GPU بنفسك. هذا مهم لأن تنسيق GPU والتجميع وهندسة الموثوقية غير تافهة؛ تفويضها إلى API مدار يسمح لك بالتركيز على منطق العامل.
لماذا يهم هذا للعوامل البرمجية تحديدًا: تكاليف التوكن لكل جلسة تقود اقتصاديات أعباء عمل العوامل أكثر من رسوم الترخيص. فريق يدير 200 جلسة عامل برمجي يوميًا ويحقق معدلات إكمال مهام قابلة للمقارنة مع نموذج مفتوح المصدر يمكنه تقليل إنفاق الاستدلال بشكل كبير دون تغيير كود التكامل على الإطلاق.
الاختبار العملي: شغل 50 مهمة برمجة ممثلة مع النموذج المستهدف، وقياس معدل نجاح استدعاء الأداة ومعدل إنجاز المهمة، ثم قرن مع التكلة لكل جلسة. لن تجيب أرقام المقاييس على هذا السؤال - عبء العمل الفعلي سيفعل.
الأسئلة الشائعة
ما الفر بي العامل البرمجي ومساعد الكود؟
مساعد الكود (مثل اقتراحات GitHub Copilot المضمنة) ينشئ اكتمالات ويتوقف. العامل البرمجي ينفذ الكود، ويقرأ المخرجات، ويكرر. السمة المميزة هي حلقة التنفيذ: اقرأ، قرر، تصرف، لاحظ، كرر. انظر CLI مقابل IDE Coding Agent لمقارنة كيفية استخدام عوامل الشكل المختلفة لهذه الحلقة.
هل أحتاج إلى صندوق رملي لبناء عامل برمجي؟
نعم، إذا كا العامل سيصشغيل كودًا مولدًا من إدخال المستخدم أو مصادر خارجية. بدون عزلة، يمكن لتوليد الكود المعطل إتلاف نظام ملفات المضيف أو استهلاك موارد غير محدودة. حتى لحالات الاستخدام الداخلي فقط، يمنع الصندوق الرملي العمليات الجامحة من التأثير على المضيف. توفر الحاويات عزلًا أساسيًا؛ تقدم صناديق الرمل المبنية على الأجهزة الافتراضية الدقيقة مثل Novita فصلًا أقوى على مستوى النواة لأعباء العمل متعددة المستأجرين أو الحساسة أمنيًا.
هل يمكن للعامل البرمجي العمل دون اتصال بالإنترنت؟
بالنسبة لمعظم مهام البرمجة البحتة، نعم. قراءة/كتابة الملفات وتنفيذ الأوامر المحلية تغطي معظم سير العمل. تقييد الصادر داخل الصندوق الرملي هو في الواقع افراض جيد - فهو يمنع الكود المولد من إجراء طلبات خارجية غير متوقعة ويبسط نمذجج التهديد الخاص بك.
ما الذي يحدد أفضل عامل برمجي لمهمة معينة؟
موثوقية استدعاء الأداة ومعدل إكمال المهمة على عبء العمل الفعلي. تصنيفات المقاييس العاامة هي نقطة بداية لقائمة النماذج المختصرة، لالإجابة النهائية. شغل مهماك الممثلة، قس معدل الإكمال، وضع في الاعتبار تكلفة التوكن لكل جلسة. قد يكون أفضل عامل برمجي لشركة ناشئة صغيرة تقوم بإعادة هيكلة خفيفة مختلفًا جدًا عن الخيار الأفضل لفريق مؤسسي يدير مراجعة تلقائية لطلبات السحب على نطاق واسع.
كم من الوقت يمكن أن تعمل جلسة عامل برمجي؟
هذا يعتمد على مزود الصندوق الرملي. يدعم صندوق رمل عوامل Novita جلسات حتى 24 ساعة مع الحفاظ على حالة نظام الملفات عبر الأوامر، مما يغطي حتى مهام إعادة الهيكلة أو الترحيل الممتدة دون الحاجة إلى منطق حفظ/استعادة في كود العامل.
