ما هو Agent Harness؟ تشغيل الوكلاء المُدارين والمحكومين في بيئة الإنتاج

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

صوفيا، مهندسة منصات، ورثت وكلاء ثلاثة فرق وطلبًا لجعلهم جاهزين للإنتاج. كان كل فريق قد بنى بيئة التشغيل الخاصة به حول النموذج. قام أحدهم بإنشاء حلقة تنسيق يدويًا في بايثون؛ بينما قام آخر بتغليف إطار عمل؛ وقام الثالث باستدعاء النموذج مباشرة في مهمة كرون. تم لصق مفاتيح API للمزودين في تكوينات الوكيل وتم الالتزام بها في المستودعات. تراوحت الموافقات على الإجراءات الحساسة من رسالة Slack إلى لا شيء على الإطلاق. لم يكن لدى اثنين من الفرق الثلاثة أي تتبع قابل للاستخدام لما فعله الوكيل بالفعل في تشغيل معين. لم تكن مهمة صوفيا هي تزويد هؤلاء الوكلاء بنماذج أفضل أو أدوات أكثر — فقد كانوا يمتلكون ذلك. بل كانت مهمتها تزويدهم بالشيء الذي لم يبنه أي منهم بشكل جيد: بيئة تشغيل مشتركة ومحكومة. كانت تفتقر إلى نظام تسخير.

هذا هو المكان الذي تصل إليه معظم الفرق بعد نجاح العرض التوضيحي الأول للوكيل. يثبت العرض التوضيحي النموذج والأدوات؛ بينما يتطلب الإنتاج بيئة التشغيل المحيطة بها — وهذه البيئة كبيرة، وحساسة أمنيًا، وغير متمايزة تقريبًا من وكيل لآخر. بناءها بثلاث طرق مختلفة، كما فعلت فرق صوفيا، هو كيف ينتهي بك الأمر بثلاث مجموعات مختلفة من المشاكل. تتناول هذه المقالة الطبقة التي تحل المشاكل الثلاثة دفعة واحدة.

1. ما هو نظام تسخير الوكيل

نظام تسخير الوكيل هو طبقة وقت التشغيل المحيطة بنموذج اللغة الكبير (LLM) التي تحوله من مولد نصوص إلى وكيل موثوق به وطويل الأمد. بدلاً من استدعاء نموذج واحد، يدير نظام التسخير حلقة التنفيذ الكاملة: فهو يخطط، يستدعي أداة، يراقب النتيجة، ويقرر ما إذا كان سيستمر أو يتوقف — ويكرر ذلك حتى يتم تحقيق الهدف أو الوصول إلى حد معين. حول هذه الحلقة يوجد كل ما تحتاجه الحلقة لتكون آمنة ومفيدة: توجيه الأدوات وتنفيذها لواجهات برمجة التطبيقات (APIs)، وأدوات MCP، والتعليمات البرمجية؛ ضوابط الذاكرة والسياق للمهام الطويلة؛ حدود الأمان مثل بيئة الاختبار المعزولة (sandboxing)، وبيانات الاعتماد، والأذونات؛ بوابات التدخل البشري للإجراءات الحساسة؛ والتتبع، والسجلات، والمقاييس، ورؤية التكلفة.

كلمة "تسخير" مختارة بعناية: إنها المعدات التي تسمح لك بتسخير شيء قوي وغير متوقع إلى حد ما للعمل دون أن يفلت. لا شيء من هذه الأجزاء هو النموذج، ولا شيء منها هو الأداة — إنها السقالات التي تجعل تركيبة النموذج بالإضافة إلى الأدوات موثوقة. هذه السقالات هي ما أعادت فرق صوفيا بناءه، بشكل سيء، وبمعزل عن بعضها البعض.

2. لماذا يُعد قرار "البناء مقابل الشراء" لنظام التسخير هو القرار الحقيقي

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

هذا هو الفخ الذي وقعت فيه فرق صوفيا الثلاثة بشكل مستقل. قضى كل منهم جهدًا حقيقيًا في بنية وقت التشغيل بدلاً من التركيز على الوظيفة الفعلية للوكيل، وأنتج كل منهم نسخة مختلفة وجزئية مع ثغراتها الخاصة — مفتاح API الملتزم به، وبوابة الموافقة المفقودة، والتتبع الغائب. شراء نظام التسخير (أو اعتماد نظام مدار) هو القرار بوقف إعادة بناء البنية التحتية وتوحيدها مرة واحدة، بحيث تركز الفرق جهودها على التعليمات والأدوات والمهارات — الأجزاء التي تخصهم بالفعل.

3. نظام تسخير وكيل TrueFoundry: النموذج + MCP + المهارات + التعليمات

نظام تسخير وكيل TrueFoundry هو نظام تسخير مُدار مبني على أساس بوابة الذكاء الاصطناعي و بوابة MCP. النموذج الذهني للمطور صغير عمدًا: تختار نموذجًا، تربط خوادم MCP، تضيف مهارات، وتكتب تعليمات. توفر TrueFoundry الباقي كقدرات مُدارة — التنسيق، دورة حياة بيئة الاختبار المعزولة، تنفيذ الأدوات، سير عمل الموافقات، الحوكمة، وقابلية المراقبة — بينما تظل الفرق تمتلك تعليمات الوكيل، وأدواته، وسياساته، ووضعية النشر. يوجد منشئ بدون تعليمات برمجية في وحدة التحكم لغير المطورين، ومجموعة تطوير برامج بايثون (Python SDK) وواجهة برمجة تطبيقات REST لنفس تعريف الوكيل، لذا فإن المسار من "اختيار نموذج" إلى "وكيل عامل" قصير، ويمكن تشغيل نفس التعريف من التعليمات البرمجية.

وكيل مُعرّف بشكل تصريحي — نموذج، أدوات، مهارات، تعليمات (توضيحي)

name: refund-assistant
model: claude-sonnet-4-6          # a name, not a key — credentials live in the gateway
mcp_servers:
  - zendesk                       # governed tools, referenced by name
  - payments
skills:
  - refund-policy@v4              # versioned SKILL.md from the Skills Registry
instructions: |
  Resolve refund requests within policy. Confirm any refund over $100 with the user.

لاحظ ما هو ليس في هذا التعريف: أي سر. النموذج هو اسم، وخوادم MCP هي أسماء، والمهارة هي مرجع ذو إصدار. هذا الغياب هو جوهر القسم التالي، وهو الفرق بين تعريف الوكيل الذي يمكنك الالتزام به بأمان في مستودع وآخر لا يمكنك ذلك.

4. لا توجد مفاتيح في تعريفات الوكيل: بيانات الاعتماد كمسألة تخص المنصة

الخيار التصميمي الأكثر أهمية في نظام التحكم هو مكان تخزين بيانات الاعتماد. الإجابة المغرية — لصق مفتاح المزود ورموز الأدوات في تعريف الوكيل — هي بالضبط ما وضع مفاتيح صوفيا في مستودع. هذا لا يتوسع (كل وكيل وكل مستخدم يعيد تسجيل الأسرار)، ولا يتم تدويره بسلاسة (تغيير المفتاح يؤثر على كل تعريف)، ولا يبقى آمنًا (تنتشر الأسرار أينما يتم تخزين التعريفات).

يتبع نظام TrueFoundry المسار الآخر: لا يتم أبدًا لصق مفاتيح API أو بيانات الاعتماد في تعريفات الوكيل. تُخزّن بيانات اعتماد المزود في بوابة الذكاء الاصطناعي (AI Gateway)، وتشير الوكلاء إلى أسماء النماذج بينما يتم فرض التحكم في الوصول المستند إلى الدور (RBAC) والميزانيات والضوابط الوقائية عند البوابة. تتم مصادقة MCP — رموز OAuth، ومفاتيح API — في بوابة MCP (MCP Gateway)، التي تتعامل مع حقن بيانات الاعتماد، وتحديث الرموز، وتفويض كل مستخدم على حدة، بحيث يقوم المستخدمون بالمصادقة مباشرة ويستدعي الوكيل الأدوات بالاسم. تُنشر المهارات في سجل المهارات (Skills Registry) مع تحديد الإصدار والتحكم في الوصول المستند إلى الدور (RBAC)، بحيث يختار الوكلاء من كتالوج محكوم. تقوم فرق المنصة بتكوين الوصول مرة واحدة؛ ولا يتعامل بناة الوكلاء مع الأسرار أبدًا.

5. القدرات التي تجعله جاهزًا للإنتاج

الحلقة وحدها ليست جاهزة للإنتاج؛ فالقدرات المحيطة بها هي ما يفصل العرض التوضيحي عن النظام. يجمع نظام TrueFoundry بين عدة قدرات، تعالج كل منها نمط فشل تناولته هذه السلسلة.

يمنح صندوق رمل الوكيل بيئة آمنة لتشغيل التعليمات البرمجية، والتعامل مع الملفات، وتنفيذ المهام طويلة الأمد دون أن تلامس هذه التعليمات البرمجية المضيف أو الأنظمة الحساسة مباشرة. هندسة السياق يساعد في الحفاظ على نافذة النموذج خفيفة — من خلال الوكلاء الفرعيين الذين يعزلون المهام الفرعية، ووضع التعليمات البرمجية الذي يسمح للوكيل بمعالجة البيانات برمجيًا بدلاً من حشوها في المطالبة، وتفريغ النتائج الكبيرة بحيث لا تؤدي نتيجة أداة ضخمة إلى تجاوز السياق، والضغط للتشغيلات الطويلة (النظير لحلقة الوكيل لإدارة الجلسات من جانب البوابة في منشور هندسة السياق). التدخل البشري في الحلقة توقف البوابات استدعاءات الأدوات الحساسة وتتطلب موافقة صريحة قبل تنفيذها. طلب من المستخدم يسمح للوكيل بطلب توضيح أو تقديم خيارات أثناء التشغيل بدلاً من التخمين. و واجهة المستخدم التوليدية يتيح للوكيل بث كتل منظمة — بطاقات، جداول، رسوم بيانية — يعرضها العميل، بدلاً من إرجاع كتلة نصية ضخمة.

كل من هذه يتوافق مع فشل محدد يهدف الحزام إلى منعه — وهي أوضح طريقة لمعرفة سبب كونها ليست مجرد تحسينات اختيارية:

تشغيل الوكيل وبث تقدمه عبر واجهة برمجة التطبيقات (توضيحي)

session = harness.sessions.create(agent="refund-assistant",
                                  input="Refund order #8842, $240")

for event in session.stream():                  # SSE stream of run events
    if event.type == "tool_call":
        log(event.tool, event.args)              # each step is traced
    elif event.type == "approval_required":      # HITL gate fired
        decision = ask_human(event)              # pause for explicit approval
        session.respond(event.id, decision)
    elif event.type == "final":
        return event.output

تستحق بوابة الموافقة نظرة فاحصة، لأنها النقطة التي تلتقي فيها الحوكمة بحرية الوكيل في التصرف. بدلاً من أن يتذكر كل مطور وكيل وضع علامة على كل أداة حساسة، يتيح الحزام وضع علامة على الأداة كمدمرة مرة واحدة، وبشكل مركزي، بحيث يتم فرض متطلب الموافقة على كل وكيل يستخدمها — حوكمة لا تعتمد على إتقان كل مطور.

الأدوات المدمرة محصورة مرة واحدة، مركزياً — مفروضة على كل وكيل (توضيحي)

# Set at the MCP Gateway, not in each agent definition:
tools:
  payments.issue_refund:
    destructive: true            # every agent calling this must get approval
    approval: require_user        # harness pauses the run and waits
  payments.read_balance:
    destructive: false            # read-only — runs without a gate

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

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

6. قابلية المراقبة: لوحة تحكم واحدة عبر حركة مرور النموذج والأداة والوكيل

لم يتمكن اثنان من فرق صوفيا الثلاثة من إعادة بناء ما فعله الوكيل في تشغيل معين، وهي فجوة قابلية المراقبة التي تعود إليها هذه السلسلة بأكملها مرارًا وتكرارًا — الآن على مستوى الوكيل. يجب أن يصدر الحزام تتبعًا شاملاً لكل تشغيل: كل استدعاء لنموذج لغوي كبير (LLM)، واستدعاء أداة، وتنفيذ بيئة اختبار (sandbox)، ووكيل فرعي، مع تخصيص التكلفة والرموز والكمون لكل خطوة. بدون ذلك، يكون الوكيل الذي يتصرف بشكل خاطئ صندوقًا أسود، والإشارة الوحيدة التي تحصل عليها هي الفاتورة أو الشكوى.

ما يحمله التتبع لا يقل أهمية عن وجوده. يربط سجل مفيد لكل خطوة بين هوية التشغيل والخطوة، والنموذج والأداة المعنية، وقرار الموافقة، وجلسة بيئة الاختبار (sandbox)، وتكلفة الخطوة ورموزها وكمونها — ما يكفي لإعادة بناء أي تشغيل وتحديد مصدره وتكلفته بعد وقوعه:

سجل تتبع توضيحي لكل خطوة (الشكل خاص بالبوابة)

{
  "agent.run_id": "run_abc123",
  "agent.name": "refund-assistant",
  "agent.step.type": "tool_call",
  "agent.step.name": "payments.issue_refund",
  "model": "claude-sonnet-4-6",
  "mcp.server": "payments",
  "approval.required": true,
  "approval.status": "approved",
  "sandbox.session_id": "sbx_7f1c",
  "tokens.input": 1842,
  "tokens.output": 391,
  "latency_ms": 2200,
  "cost_usd": 0.0142
}

التشغيل هو ببساطة المجموعة المرتبة من هذه السجلات تحت معرف تشغيل واحد (run_id) — وهو ما يحول "الوكيل قام بشيء مكلف" إلى "الخطوة 4 استدعت استرداد_المبلغ بعد بوابة موافق عليها، بتكلفة كذا."

نظرًا لأن حزام TrueFoundry يعمل على نفس مستوى البوابة مثل حركة مرور النموذج وMCP، فإنه يرث تحليلات بوابة الذكاء الاصطناعي، وسجلات الطلبات، وتصدير OpenTelemetry، وتكامل Prometheus و Grafana — لوحة تحكم واحدة عبر حركة مرور النموذج وMCP والوكيل بدلاً من ثلاث لوحات معلومات منفصلة

7. كيف تتم المقارنة: فلسفات تصميم الأحزمة المدارة

TrueFoundry ليس الحزام المدار الوحيد، والبدائل جيدة. وكلاء Claude المدارون من Anthropic ووكلاء LangSmith المدارون بعمق من LangChain كلاهما بيئات تشغيل قوية مستضافة، وبالنسبة للعديد من الفرق، فهي مناسبة تمامًا. الطريقة المفيدة لمقارنتها ليست لوحة نتائج؛ إنها اختلاف في فلسفة التصميم، وأي فلسفة تناسب يعتمد على وضعك.

كما هو موثق وقت كتابة هذا النص، تميل العديد من بيئات التشغيل السحابية المدارة إلى البرمجة الاحترافية (pro-code) وواجهة برمجة التطبيقات أولاً (API-first): تقوم بتعريف الوكلاء والجلسات والبيئات عبر SDK أو واجهة برمجة تطبيقات REST، وتسجيل بيانات الاعتماد لكل وكيل أو مساحة عمل (معرفات الخزنة، مصفوفات الرأس)، وتعيين سياسات الموافقة على الأدوات لكل وكيل، والتشغيل في السحابة المدارة للمزود. هذا نموذج نظيف ومتكامل بإحكام — خاصة إذا كنت قد قمت بالفعل بالتوحيد القياسي على مزود نموذج واحد أو إطار عمل تنسيق واحد وكان فريقك مرتاحًا لتعريف الوكلاء في التعليمات البرمجية. فلسفة TrueFoundry مختلفة: منشئ بدون تعليمات برمجية أولاً (مع نفس التعريف المتاح عبر SDK و REST)، بيانات الاعتماد مركزية في مستوى التحكم بالبوابة بدلاً من تسجيلها لكل وكيل، الموافقة على الأدوات المدمرة يتم وضع علامة عليها مرة واحدة على مستوى المؤسسة، الوصول إلى النموذج محكوم بـ RBAC والميزانيات عبر أي مزود، والنشر متاح كخدمة (SaaS) أو مستضاف ذاتيًا أو في الموقع. المقايضة هي بين بساطة التكامل داخل نظام بيئي واحد مقابل الحوكمة المركزية عبر العديد من الأنظمة.

8. أين يتناسب الحزام: قمة مكدس البوابة

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

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

9. الأسئلة الشائعة

أليس الإطار التشغيلي مجرد إطار عمل للوكيل مثل LangChain أو CrewAI؟

ذات صلة ولكن ليست متطابقة. إطار العمل هو مكتبة تستخدمها لبناء منطق الوكيل؛ أما الإطار التشغيلي فهو بيئة التشغيل المدارة التي تقوم بتشغيله — حلقة التنسيق، بيئة الاختبار المعزولة، حقن بيانات الاعتماد، الموافقات، والتتبع كقدرات تشغيلية. يضيف الإطار التشغيلي من TrueFoundry بيئة التشغيل المدارة وطبقة الحوكمة حول النماذج، وأدوات MCP، والمهارات، وبيئة الاختبار المعزولة، والموافقات، والتتبعات. يمكنك اعتبار إطار العمل هو كيفية كتابة منطق الوكيل، والإطار التشغيلي هو المكان الذي يعمل فيه الوكيل المحكوم بأمان.

لماذا يُعد "عدم وجود مفاتيح في تعريفات الوكيل" أمرًا بالغ الأهمية؟

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

هل يجب علي استخدام منشئ بدون تعليمات برمجية؟

لا. يعرض الإطار التشغيلي من TrueFoundry نفس تعريف الوكيل من خلال منشئ بدون تعليمات برمجية، وحزمة تطوير برمجيات (SDK) بلغة بايثون، وواجهة برمجة تطبيقات (REST API)، بحيث يمكن لغير المطورين النشر من وحدة التحكم بينما يقوم المهندسون بتشغيل التعريف المتطابق من التعليمات البرمجية ودمج عمليات التشغيل في التطبيقات. المنشئ يسهل البدء؛ وحزمة تطوير البرمجيات وواجهة برمجة التطبيقات تحافظان على إمكانات التوسع عالية.

كيف تختلف هندسة السياق في الإطار التشغيلي عن منشور جلسة البوابة؟

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

هل يمكنني تشغيل إطار تشغيلي مُدار محليًا؟

مع TrueFoundry، نعم — يتم نشره كخدمة برمجية (SaaS)، أو مستضاف ذاتيًا، أو محليًا في سحابتك ومنطقتك الخاصة، وهو غالبًا ما يكون العامل الحاسم للبيئات المنظمة أو المعزولة. هذه قابلية النقل هي إحدى الفروق المعمارية عن بيئات التشغيل السحابية المدارة فقط؛ تأكد من الخيارات الحالية بمراجعة وثائق كل بائع، حيث تتغير نماذج النشر.

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

المراجع

• TrueFoundry — الإطار التشغيلي للوكيل (وثائق)
• TrueFoundry — بوابة الذكاء الاصطناعي و بوابة MCP
• TrueFoundry — سجل مهارات الوكيل
• TrueFoundry — هندسة السياق وإدارة الجلسات و OpenTelemetry للنماذج اللغوية الكبيرة
• Anthropic — وكلاء كلود المُدارون، و LangChain — وكلاء LangSmith العميقون المُدارون (يرجى الرجوع إلى الوثائق الحالية لكل بائع)

صوفيا هي مثال توضيحي. يتم تلخيص قدرات TrueFoundry Agent Harness من وثائق المنتج العامة اعتبارًا من منتصف عام 2026 وستتطور؛ وقد تكون بعض القدرات قيد التطوير النشط. تصف المقارنات مع وكلاء كلود المُدارين ووكلاء LangSmith العميقين المُدارين فلسفات التصميم كما هي موثقة وقت الكتابة — هذه منتجات قوية وسريعة التطور تتغير تفاصيلها (النماذج، المناطق، آليات الاعتماد والموافقة، توفر حزم تطوير البرامج (SDK)، خيارات النشر) بشكل متكرر، لذا يرجى التحقق من الوثائق الحالية لكل بائع. عينات التعليمات البرمجية والتكوين هي أمثلة توضيحية للأنماط الموثقة، وليست منسوخة من تطبيق مرجعي.