فصل منطق الوكيل عن وقت التشغيل: مبررات طبقة الوكيل المدارة

تلاحظ العديد من الفرق التي تطلق وكيلها الإنتاجي الثالث أو الرابع النمط نفسه: جزء كبير من الكود في كل ملف وكيل هو بنية تحتية، وليس منطق وكيل. أغلفة إعادة المحاولة، تحميل بيانات الاعتماد، سجلات الأدوات، حالة الجلسة، العزل (sandboxing) — يتم نسخها ولصقها من الوكيل السابق مع اختلافات طفيفة. أحد الحلول الشائعة بشكل متزايد هو طبقة وكيل مُدارة تتولى هذه المهام مرة واحدة، وتكشف عن واجهة برمجة تطبيقات (API) ضيقة لكود الوكيل، وتوجه العمل الفعلي عبر البوابات التي تشغلها المنصة بالفعل. تحدد هذه المقالة الطبقة، وتستعرض مكوناتها الخمسة، وتوضح كيف تتكامل بوابة الذكاء الاصطناعي (AI gateway) وبوابة MCP معها — وتتوج بإصدار Anthropic لوكلاء مُدارين في أبريل 2026 كمثال على نفس الفصل العام.

الأربعاء في نورثويند. تفتح ديفي، مهندسة أولى في فريق المنصة، طلب السحب (PR) للوكيل الرابع الذي أطلقه فريقها هذا الربع — وهو مولد لملاحظات الإصدار متصل بروبوت النشر. الفرق هو 312 سطرًا. وهي تعلم من التجربة أن حوالي 30 سطرًا من هذه الأسطر هي حلقة التفكير الفعلية للوكيل. أما الأسطر الـ 280 المتبقية فهي نفس الأشياء الخمسة التي كتبتها الآن أربع مرات: سجل أدوات يقوم بتحميل إعدادات خادم MCP من مكانين، ومنطق إعادة محاولة مع تراجع أسي لا يتطابق تمامًا مع إصدار الوكيل السابق، وتحميل بيانات الاعتماد من مزيج من متغيرات البيئة ومدير الأسرار، وحالة الجلسة المدفوعة إلى Redis مع TTL تم ضبطه بالتخمين، وتسلسل try/except يميز حدود المعدل عن أخطاء المصادقة عن انقطاعات المزود.

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

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

1. مشكلة التشابك: منطق الوكيل مدفون تحت كود البنية التحتية

إليك كيف تبدو النسخة المتشابكة لأحد وكلاء ديفي، باختصار. الملف الكامل حوالي 200 سطر؛ وما يلي هو أول 35 سطرًا.

بايثون — وكيل ساذج، بنية تحتية ممزوجة بالمنطق (مختصر)

import os, time, random, json, yaml, redis
import anthropic, openai
from github import Github

class CodeReviewAgent:
    def __init__(self):
        # Credential loading — three different patterns across our four agents
        self.anthropic_key = os.environ.get("ANTHROPIC_API_KEY") \
            or self._load_from_vault("anthropic")
        self.openai_key = os.environ.get("OPENAI_API_KEY") \
            or self._load_from_vault("openai")
        self.github_token = self._load_from_vault("github-pat")  # different vault path

        # Tool registry — drifted from review-agent-v2's version
        with open("mcp_servers.yaml") as f:
            self.tools = self._build_tool_registry(yaml.safe_load(f))

        # State store — TTL was 30min in v2, 1h here, nobody remembers why
        self.redis = redis.Redis.from_url(os.environ["REDIS_URL"])
        self.session_ttl = 3600

        self.anthropic = anthropic.Anthropic(api_key=self.anthropic_key)

    def run(self, pr_id):
        # Retry loop — slightly different in every agent file we own
        for attempt in range(5):
            try:
                response = self.anthropic.messages.create(...)
                break
            except anthropic.RateLimitError:
                time.sleep(2 ** attempt + random.random())
            except anthropic.APIStatusError as e:
                if e.status_code >= 500:
                    time.sleep(2 ** attempt + random.random())
                else:
                    raise
        # ... 170 more lines like this. The actual reasoning loop starts around line 130.

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

2. تعريف طبقة الوكيل المُدار

طبقة الوكيل المُدار هي التجريد الذي يمتلك الركيزة. وهي تكشف عن ثلاث واجهات برمجة تطبيقات (APIs) ضيقة لكود الوكيل، ولا شيء غير ذلك:

بايثون — سطح واجهة برمجة التطبيقات (API) الذي تكشفه الطبقة المُدارة لكود الوكيل

class ManagedAgent:
    # Tool invocation — routes through the MCP gateway, handles auth/RBAC/audit.
    # Credentials are fetched from the secret store and injected by the runtime
    # at call time; agent code references tools by logical name, never by token.
    async def call_tool(self, name: str, **args) -> dict: ...

    # Model inference — routes through the AI gateway, handles routing/guardrails/cost
    async def llm(self, messages: list, **opts) -> str: ...

    # Session state — keyed under the conversation ID, runtime owns persistence
    async def save_state(self, key: str, value: object) -> None: ...
    async def load_state(self, key: str) -> object | None: ...

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

إليك نفس وكيل مراجعة الكود على الطبقة المُدارة. طلب السحب (PR) الآن أصغر من ملف الاختبار القديم الخاص به:

بايثون — نفس الوكيل على الطبقة المُدارة، منطق خالص

from truefoundry.agent import ManagedAgent

class CodeReviewAgent(ManagedAgent):
    """Reviews a pull request against the repo's style guide."""

    async def run(self, pr_id: str):
        diff = await self.call_tool("github.get_pr_diff", pr_id=pr_id)
        review = await self.llm([
            {"role": "system", "content": REVIEW_PROMPT},
            {"role": "user", "content": diff},
        ])
        await self.call_tool("github.post_review", pr_id=pr_id, body=review)
        return {"status": "ok", "review_length": len(review)}

لا توجد بيانات اعتماد. لا توجد حلقة إعادة محاولة. لا يوجد كود حالة. لا يوجد SDK للمزود. البنية التحتية التي كانت موجودة في كل ملف وكيل أصبحت الآن موجودة مرة واحدة، في بيئة التشغيل، حيث يمكن اختبارها وتحديد إصداراتها ونشرها بشكل مستقل.

3. المكونات الخمسة: التنسيق، العزل (Sandboxing)، الحالة، بيانات الاعتماد، إعادة المحاولة

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

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

إدارة الحالة. بين الدورات، يجب أن يكون سجل المحادثة، ومساحة عمل الوكيل المؤقتة، ونتائج الأدوات الوسيطة، وأي مؤشرات تقدم موجودة في مكان ما. يوفر وقت التشغيل وظيفتي save_state و load_state المرتبطتين بمعرف الجلسة، مع وقت بقاء (TTL) مناسب لحمل العمل.

حقن بيانات الاعتماد. لا يرى كود الوكيل سرًا خامًا أبدًا. يستجلب وقت التشغيل بيانات الاعتماد من مخزن الأسرار ويحقنها لحظة استدعاء الأداة — عادةً كرأس تفويض (Authorization header) لا يتمكن كود الوكيل من قراءته أبدًا. تتعامل نفس الآلية مع التدوير: عندما يتم تدوير بيانات اعتماد، يستخدم استدعاء الأداة التالي القيمة الجديدة دون أي تغيير في كود الوكيل.

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

4. بوابة الذكاء الاصطناعي كوقت تشغيل للاستدلال

لا تستدعي واجهة برمجة تطبيقات llm() للطبقة المُدارة حزمة تطوير برامج المزود (SDK) مباشرة. بل توجه عبر بوابة الذكاء الاصطناعي، التي تتولى مشكلة ربط المزود نيابة عن الوكيل.

بايثون — ما لا يفعله الوكيل، مقابل ما يفعله وقت التشغيل له

# What agent code looks like with the managed layer:
review = await self.llm(messages, model="claude-sonnet-4-6")

# What the runtime does on the agent's behalf, via the gateway:
#   1. Resolves "claude-sonnet-4-6" through the virtual-model config — could
#      be routed to a different provider entirely based on cost or availability.
#   2. Applies the team's input guardrails (PII scrubbing, prompt-injection
#      detection) before the call leaves the platform.
#   3. Picks an upstream account by load and rate-limit headroom; falls
#      back to a configured alternate on provider outage.
#   4. Streams the response back; applies output guardrails and emits OTel
#      spans with the team/app metadata from the previous post in this series.
#   5. Computes per-trace cost at span close, books it against the team budget.

الفصل هيكلي. لا يعرف كود الوكيل — ولا يحتاج إلى معرفة — ما إذا كان استدعاؤه قد ذهب إلى OpenAI أو Anthropic أو نموذج مستضاف ذاتيًا. عندما يضيف فريق المنصة مزودًا جديدًا، أو يغير نموذجًا، أو يطرح حاجز حماية جديدًا، لا تتطلب أي طلبات سحب من الوكيل. عقد الوكيل هو واجهة برمجة التطبيقات، وليس المصدر الأصلي.

5. بوابة MCP كوقت تشغيل للأدوات

ينطبق نفس النمط على الأدوات. يستدعي كود الوكيل call_tool() باسم منطقي؛ تقوم بوابة MCP بتحويله إلى خادم MCP محدد، وتحقن رمز OAuth الصحيح، وتطبق التحكم في الوصول المستند إلى الدور (RBAC)، وتشغل حواجز الحماية قبل التنفيذ، وتسجل الاستدعاء، وتعيد النتيجة.

بايثون — كود الوكيل يستدعي أداة عبر بوابة MCP

diff = await self.call_tool("github.get_pr_diff", pr_id="4127")
issues = await self.call_tool("linter.check", diff=diff, ruleset="strict")
await self.call_tool("slack.post_message", channel="#code-review", text=summary)

خلف تلك الواجهة، تحتفظ البوابة برموز OAuth لكل خادم MCP تدعمه المنصة، وهي مربوطة بهوية المستخدم أو الخدمة المستدعية. تقوم بتحديثها عند انتهاء صلاحيتها. تفرض RBAC على مستوى دقة الأداة — "يمكن لهذا الوكيل استدعاء github.get_pr_diff ولكن ليس github.create_pr" — بغض النظر عما يقوله كود الوكيل. تسجل كل استدعاء مع الوسائط والقيم المرجعة ومعرفات الوكيل والجلسة المستدعية، مما ينشئ سجل تدقيق مركزي لاستخدام الأدوات عبر المنصة (مع مراعاة الحقائق المعتادة — قد تسقط مسارات السجل أو تأخذ عينات أو تتأخر). تضيف بوابة MCP الخاصة بـ TrueFoundry تجريد خادم MCP افتراضيًا فوق ذلك: نقطة نهاية منطقية واحدة تجمع الأدوات من عدة خوادم MCP فعلية، بحيث لا تتغير قائمة أدوات الوكيل عند تغيير تطبيقات الواجهة الخلفية.

عقد كود الوكيل هو نفسه عقد بوابة الذكاء الاصطناعي: استدعِ واجهة برمجة التطبيقات باسم منطقي، واحصل على نتيجة، ودع وقت التشغيل يتعامل مع بيانات الاعتماد.

6. عزل تنفيذ الكود: مفاضلات Docker و gVisor و WebAssembly

عندما يقوم الوكيل بتنفيذ التعليمات البرمجية — سواء كان وكيل برمجة يُجري اختبارات، أو وكيل بيانات يُشغّل بايثون على ملف CSV، أو وكيل أدوات يُنفّذ أمر shell عشوائي — يجب أن تعمل هذه التعليمات البرمجية في بيئة معزولة عن المضيف. فيما يلي الخيارات الجادة الثلاثة المتاحة في مايو 2026، مع أرقام البدء البارد كتقدير تقريبي للحجم (تعتمد الأرقام الحقيقية بشكل كبير على حجم الصورة، ومجموعات التشغيل الساخنة، واللقطات، وحالة العقدة):

يعتمد الاختيار على طبيعة الاستئجار وزمن الاستجابة. الوكيل أحادي المستأجر الذي يُشغّل جلسة برمجة طويلة لكل مهمة يستخدم Docker — حيث يتم دفع تكلفة البدء البارد مرة واحدة وتُستهلك على مدى مئات عمليات تنفيذ التعليمات البرمجية. المنصة متعددة المستأجرين التي تخدم تعليمات برمجية لوكيل غير موثوق بها تستخدم gVisor — حيث يمثل النواة المشتركة للحاويات العادية مصدر قلق حقيقي عندما تكون التعليمات البرمجية عشوائية. عبء العمل الحساس لزمن الاستجابة الذي يُشغّل بيئة معزولة لكل استدعاء أداة (مثل أداة حاسبة، أو أداة تعبيرات نمطية) يستخدم Wasm — فدفع ثانية واحدة للبدء البارد لكل استدعاء أمر لا يُطاق عندما يكون الاستدعاء نفسه يستغرق عشرين مللي ثانية.

لا شيء من هذا يخص الوكيل. بيئة التشغيل تُظهر "نفّذ هذا الكود، وها هي النتيجة" وتختار البيئة المعزولة المناسبة لفئة عبء العمل.

7. أنماط إدارة الحالة: في السياق مقابل التخزين الخارجي مقابل جلسة البوابة

المكان الذي تعيش فيه ذاكرة عمل الوكيل بين الأدوار لديه ثلاثة خيارات حقيقية:

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

8. الاتصال بوكلاء Anthropic المُدارين

أنثروبيك الوكلاء المُدارون، في مرحلة البيتا العامة منذ 9 أبريل 2026 (رأس البيتا: managed-agents-2026-04-01)، يمكن قراءتها كمثال على نفس الفصل العام بين منطق الوكيل وبنية التنفيذ التحتية. تكشف بنية "الميتا-هارنس" الخاصة بهم عن مكونات تتوافق مع معظم ما يصفه هذا المنشور: حلقة وكيل منسقة، تنفيذ التعليمات البرمجية في بيئة معزولة (استضافتها Anthropic في البداية، مع إضافة بيئات معزولة ذاتية الاستضافة في إصدار لاحق)، استمرارية الجلسة مع إيقاف مؤقت واستئناف يحافظ على الحالة، إدارة بيانات الاعتماد للأنظمة الخارجية، والمراقبة عبر التتبع. تأطير Anthropic الخاص هو "العقل والأيدي": كلود بالإضافة إلى الهارنس يعملان على بنية Anthropic التحتية (العقل)؛ والبيئة المعزولة حيث تُنفّذ أوامر shell والتعليمات البرمجية هي الأيدي.

للفرق التي تبني وكلاء على مزود واحد، منتج Anthropic هو المسار الأبسط — الهارنس مُفعّل افتراضيًا لكل حساب Claude API، وواجهة برمجة التطبيقات هي رأس البيتا الجديد managed-agents. أما للفرق التي تُشغّل وكلاء عبر مزودين متعددين، أو لديها متطلباتها الخاصة للبيئات المعزولة والأدوات، فيمكن تجميع نفس النمط من بدائيات البوابة: بوابة ذكاء اصطناعي كبيئة تشغيل الاستدلال (متعددة المزودين، مع إسناد التكلفة وتطبيق الميزانية المنقول من المنشورات السابقة في هذه السلسلة)، وبوابة MCP كبيئة تشغيل الأدوات، وطبقة بيئة معزولة ومخزن حالة يمتلكها فريق المنصة. TrueFoundry's بوابة الذكاء الاصطناعي و بوابة MCP هما اثنتان من تلك الطبقات التي نقدمها كمنتجات؛ طبقات التنسيق والبيئة المعزولة فوقهما قابلة للتوصيل عمدًا، لأنها المكان الذي تتخذ فيه القرارات الخاصة بعبء العمل.

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

هل طبقة الوكيل المُدار مجرد إطار عمل مثل LangGraph أو AutoGen؟

أطر العمل مثل LangGraph و AutoGen هي مكتبات حلقات وكيل — وهي تمتلك مكون التنسيق لما يسميه هذا المنشور الطبقة المُدارة، لكنها عادة ما تترك بيانات الاعتماد، والبيئات المعزولة، واستمرارية الحالة، وتوجيه المزود للتطبيق. طبقة الوكيل المُدار بالمعنى المستخدم هنا تمتلك كل هذه الأمور، وتُشغّلها كبنية تحتية للمنصة بدلاً من كونها تعليمات برمجية داخل عملية الوكيل.

ما هي بدائل بيئة التشغيل المُدارة، ومتى تكون أفضل؟

البدائل الرئيسية، بترتيب تقريبي لمدى اختلافها:

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

يدعو هذا المنشور إلى بنية معمارية واحدة. لا يوجد خطأ في أي من هذه؛ فهي تقع عند نقاط مختلفة على نفس منحنى المرونة مقابل الاتساق التشغيلي.

ما هي سلبيات وقت التشغيل المدار؟

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

إذا قدمت أنثروبيك وكلاء مُدارة كمنتج، فلماذا تبني وكيلك الخاص؟

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

كيف يعمل هذا للوكلاء الذين لا ينفذون تعليمات برمجية؟

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

كيف يبدو وقت التشغيل للاستجابات المتدفقة أو المخرجات الجزئية؟

تعرض واجهة برمجة التطبيقات llm() كلاً من المتغيرات المجمعة والمتدفقة. بالنسبة للتدفق، يتلقى رمز الوكيل مكررًا غير متزامن للكتل؛ يتعامل وقت التشغيل مع تدفق المزود الأساسي، ويطبق حواجز حماية المخرجات عند وصول الكتل، ويصدر امتدادات OTel لكل دور عند إغلاق التدفق.

كيف يتم اختبار هذا؟ لا يمكنك اختبار وحدة شيء يعتمد على نموذج لغوي كبير (LLM) وبيئة اختبار معزولة.

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

أين يكمن دور TrueFoundry؟

الـ بوابة TrueFoundry للذكاء الاصطناعي و بوابة MCP توفران طبقات وقت تشغيل الاستدلال والأدوات للبنية الموضحة هنا — توجيه النماذج مع استعادة المزود، وضوابط الحماية، وتحديد التكلفة، والميزانيات على جانب الذكاء الاصطناعي؛ ومعالجة OAuth، والتحكم في الوصول المستند إلى الدور (RBAC)، وخوادم MCP الافتراضية، وتسجيل التدقيق على جانب الأدوات. طبقات التنسيق والبيئة المعزولة (sandbox) ومخزن الحالة التي تعلوها مملوكة عمدًا لفريق المنصة، لأن هذا هو المكان الذي تتخذ فيه القرارات الخاصة بأعباء العمل. بالنسبة للفرق التي ترغب في منتج مُدار رأسي بالكامل على Claude، تُعد وكلاء Anthropic المدارة هي المقارنة الصحيحة.

الخطوة العملية الأولى، لفريق قام بكتابة وكيله الثالث أو الرابع وأدرك النمط في طلب سحب ديفي (Devi's PR)، هي استخلاص سطح call_tool / llm / save_state في مكتبة مشتركة صغيرة وتوجيه كل منها عبر البوابات التي تشغلها المنصة بالفعل. يتم امتلاك بيانات الاعتماد والمصادقة لكل أداة بواسطة وقت التشغيل منذ البداية، ولا يتم تمريرها أبدًا عبر كود الوكيل. كل شيء آخر يتبع هذا العقد.

المراجع

• Anthropic — وكلاء Claude المدارة (إصدار تجريبي عام في 9 أبريل 2026)
• Anthropic — آليات فعالة للوكلاء طويلة الأمد
• بروتوكول سياق النموذج — المواصفات
• بوابة TrueFoundry للذكاء الاصطناعي — نظرة عامة
• بوابة TrueFoundry MCP — نظرة عامة
• gVisor — نواة تطبيق للحاويات
• WebAssembly — نموذج الأمان

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

‍