تقود مهارات الوكيل العمل المتكرر في تدريب GPU وتقييمه وضبطه. أما الإنسان فيقدّم الهدف فقط عبر مطالبة.

ما هو Cosmos 3، وما هي مهارات الوكيل (TAO Agent Skills)؟

Cosmos 3 هو نموذج أساسي طورته NVIDIA للتعامل مع العالم الفيزيائي. يستخدم بنية Mixture-of-Transformers التي تجمع النص والصورة والفيديو والصوت المحيط وتتبع الحركة في كيان واحد، ويضم برجاً استدلالياً ذاتي الانحدار (autoregressive) مسؤولاً عن المنطق والتخطيط إلى جانب محول انتشار (diffusion transformer) يتنبأ بالحالات المستقبلية. أعلنت NVIDIA أن هذا النموذج يتصدر عدة معايير قياسية منها VANTAGE-Bench وPAI-Bench وPhysics-IQ وRoboLab وRoboArena. يأتي النموذج بحجمين هما Cosmos 3 Super بسعة 64B وCosmos 3 Nano بسعة 16B، وتستخدم هذه الحالة نسخة Nano.

لكن الجوهر ليس النموذج بل مهارة وكيل TAO (TAO Agent Skill) المرفقة به. مهارة وكيل TAO هي حزمة معرفة تُؤتمت سير عمل التدريب اللاحق لنماذج الرؤية. فهي تغلف معرفة خاصة بالمهمة مثل تفاصيل الإطار البرمجي، وسلوك المُشغِّل (launcher)، وبنية ملفات الإعداد (config)، وطريقة تحميل البيانات، وسير عمل التقييم، بحيث يستطيع وكيل برمجي مثل Codex أو Claude أن ينسق خط أنابيب التدريب بنفسه بأقل قدر ممكن من تدخل الإنسان. بعبارة أخرى، المهارة ليست سطر مطالبة واحداً، بل وحدة قابلة لإعادة الاستخدام تغلف إجراءً قابلاً للتنفيذ إلى جانب آليات التعافي من الفشل.

المطالبتان الاثنتان اللتان تنهيان التدريب اللاحق

سبب لفت هذه الحالة للانتباه هو أن كل ما أدخله الإنسان كان مطالبتين بلغة طبيعية لا أكثر.

المطالبة الأولى توجه بإجراء تدريب لاحق بأسلوب LoRA. وهي طلب لتدريب nvidia/Cosmos3-Nano بأسلوب LoRA على مجموعة بيانات Woven Traffic Safety الخاصة بشركة Toyota، مع إجراء تقييم أساسي (baseline) أولاً لأغراض المقارنة.

Perform LoRA post-training of the Cosmos 3 model on the Woven Traffic
Safety dataset. Training data: /home/.../WTS_dataset/wts_data_train
Validation data: /home/.../WTS_dataset/wts_data_val
Base model on Hugging Face: nvidia/Cosmos3-Nano
Also perform a baseline evaluation first, to compare with the post-trained model.

بمطالبة واحدة فقط، عالج الوكيل عدة مهام بالتتابع: اكتشف بنفسه معامل FPS المفقود في خط أنابيب البيانات وأصلح الخطأ، ثم خزّن النموذج مؤقتاً باستخدام رمز Hugging Face، وقاس دقة الأساس بأسلوب zero-shot قبل التدريب فسجّلت 54.41%، ثم شغّل تدريب LoRA. النقطة الجديرة بالملاحظة هنا هي التوجيه القائل “أجرِ تقييم الأساس أولاً”. فبدلاً من الثقة بنتيجة يبلغ عنها النموذج بنفسه بعد التدريب، جرى تثبيت رقم ما قبل التدريب كخط أساس للقياس، وقيس التحسن فعلياً. هذا المبدأ مطابق تماماً للدرس الذي استخلصناه من تجربتنا في الأسبوع الماضي.

المطالبة الثانية هي عملية مسح AutoML. وهي طلب لترك استراتيجية البحث وتحديد المعاملات الفائقة الواجب ضبطها لـ TAO، مع تحسين دقة التحقق (validation accuracy) ثم تلخيص أفضل النماذج.

Run an AutoML sweep to improve the LoRA result. Let TAO choose suitable
search strategies and tune the important training hyperparameters. Optimize
validation accuracy and summarize the best models.

عند رسم سير العمل بأكمله كمخطط، يظهر الإنسان عند الطرفين فقط، بينما تملأ المهارة العمل المتكرر في المنتصف.

flowchart TB
    A["مطالبة بلغة طبيعية<br/>(تدريب LoRA + تقييم الأساس)"] --> B["وكيل برمجي<br/>(Codex / Claude)"]
    B --> C["مهارة وكيل TAO<br/>تغليف معرفة الإطار والمُشغِّل وconfig<br/>وتحميل البيانات والتقييم"]
    C --> D["إصلاح تلقائي للأخطاء<br/>(تصحيح معامل FPS المفقود)"]
    C --> E["تخزين النموذج مؤقتاً<br/>(Cosmos3-Nano عبر رمز HF)"]
    C --> F["تقييم الأساس<br/>(zero-shot بنسبة 54.41%)"]
    F --> G["التدريب اللاحق بأسلوب LoRA<br/>(8×A100، نحو 30 دقيقة لكل حقبة)"]
    G --> H["مسح AutoML<br/>(43 محاولة متوازية، 19.5 ساعة)"]
    H --> I["خدمة أفضل مهايئ (adapter)<br/>عبر Cosmos 3 Reasoner NIM<br/>(نقطة نهاية متوافقة مع OpenAI)"]

تحضير البيئة يتطلب ثلاثة رموز (tokens) وسطراً واحداً من نص التثبيت. تُدخل HUGGINGFACE_TOKEN وNGC_API_KEY وAUTOML_LLM_API_KEY في الطرفية، ثم تُثبَّت مهارة الوكيل بالنص البرمجي أدناه.

export HUGGINGFACE_TOKEN="your_hf_token"
export NGC_API_KEY="your_ngc_key"
export AUTOML_LLM_API_KEY="your_llm_key"

curl -fsSL https://raw.githubusercontent.com/NVIDIA-TAO/tao-skills-bank/main/scripts/install-codex-agents.sh | bash

بيانات التدريب هي مجموعة بيانات Woven Traffic Safety الخاصة بشركة Toyota، وهي مهمة أسئلة وأجوبة على مقاطع فيديو تضم أكثر من 8,000 عينة تدريب وتحقق. تتألف من أسئلة اختيار من متعدد (أربعة خيارات) تتناول بنية الطرق وأنواعها وحالات السلامة المرورية.

الأرقام التي أنتجتها المطالبتان

ارتفع الأداء بوضوح. جميع الأرقام أدناه هي قيم أعلنتها NVIDIA، وليست نتائج أعدنا إنتاجها بأنفسنا.

ارتفعت دقة التحقق من 54.41% إلى 93.35% بمطالبتين فقط. أرقام معلنة من NVIDIA.

بلغ الأساس بأسلوب zero-shot نسبة 54.41%، ورفعته مطالبة LoRA الواحدة إلى 87.14%، أي بزيادة قدرها 32.73 نقطة. وفوق ذلك، ضبط مسح AutoML المعاملات الفائقة عبر التحسين البايزي (Bayesian optimization) ليصل إلى 93.35%، بزيادة قدرها 38.94 نقطة عن الأساس. والنقطة الجوهرية هنا أن هذه الأرقام تحققت دون أن يلمس إنسان المعاملات الفائقة بيده، بل باختيار الوكيل لاستراتيجية البحث وتشغيله التدريب بشكل متكرر.

من الأمانة النظر أيضاً إلى أرقام التكلفة. استغرق تدريب LoRA نحو 30 دقيقة لكل حقبة (epoch) على 8 وحدات A100 80GB، بينما استغرق مسح AutoML، الذي شغّل 43 محاولة متوازية عبر عدة عُقد A100، مدة 19.5 ساعة. أما التدريب الدقيق الكامل المعاملات (full-parameter SFT) الذي شُغِّل كمجموعة مقارنة فقد استغرق 3 ساعات و34 دقيقة على H100، وأعلنت NVIDIA أن LoRA خفّض زمن استخدام GPU إلى نحو سُبع الزمن مقارنة بهذا التدريب الكامل. وبعد انتهاء التدريب، تتولى Cosmos 3 Reasoner NIM خدمة مهايئ LoRA عبر نقطة نهاية متوافقة مع OpenAI، ضمن بنية تُنشر مباشرة كخدمة مصغّرة (microservice) مبنية مسبقاً، دون الحاجة إلى ضبط تبعيات vLLM أو إعدادات CUDA يدوياً.

هل جربنا هذا بأنفسنا؟

بصراحة، لم نتمكن من إعادة إنتاج سير العمل هذا في بيئتنا. أوزان عائلة Cosmos 3 محفوظة في مستودع Hugging Face مُقيَّد بالوصول (gated)، وتحتاج العملية إلى 8 وحدات A100 ومفاتيح NGC وAutoML LLM، كما أن المسح المتوازي المستخدم في هذه الحالة يفترض وجود عدة عُقد GPU. لم نؤمّن مجموعة الموارد هذه لأجل هذا المقال. لذلك فإن جميع الأرقام أعلاه مقتبسة من قيم أعلنتها NVIDIA، ولا نقدمها كما لو كانت نتائج قسناها بأنفسنا. نلتزم بمبدأ عدم إنشاء معايير قياسية دون إعادة إنتاج فعلية. ما يمكننا فعله بدلاً من ذلك هو تشريح بنية هذه الحالة، ومقارنتها بدقة بما يعمل بالفعل على منصتنا، لتحديد أوجه التشابه والاختلاف.

الدلالات على منتجات ThakiCloud

هذه الحالة موضوع نادر تتقاطع فيه وجهتا نظر منتجَينا معاً.

من زاوية Paxis، هذه الحالة تحقق خارجي لأطروحتنا القائلة بأن المهارات يجب أن تُعامل كموارد من الدرجة الأولى. Paxis هو مستوى التحكم الخاص بـ ThakiCloud للسحابة الأصيلة الوكيلة (Agent-Native Cloud)، ويعامل Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. يختار Skill Harness من بين أكثر من 960 مهارة باستخدام BM25 وينفذها في صندوق رملي معزول، ويمرر كل سلوك عبر بوابات السياسات (policy gates) وسجلات التدقيق. ما أثبتته مهارة وكيل TAO التابعة لـ NVIDIA هو أن وجود مهارة تغلف تفاصيل الإطار البرمجي وحتى آليات التعافي من الفشل يجعل الوكيل البرمجي يكرر سير عمل معقداً بثبات. وهذا يطابق تماماً التوجه الذي اعتمدناه في تعريف المهارة بوصفها وحدة تنفيذ لا مجرد مطالبة. غير أن الفرق واضح أيضاً: مهارات TAO مرتبطة بشدة بمنظومة NVIDIA، بحيث يصعب استخدامها كما هي خارج مُشغِّل TAO ونماذج Cosmos وNGC وNIM. أما حاضنة مهارات Paxis فتستهدف عدم الارتباط بمزود أو نموذج بعينه، وهذه النقطة هي جوهر القيمة التي نريد تقديمها في البيئات المحلية (on-premises) والبيئات السيادية.

ومن زاوية ai-platform، هذه الحالة هي بعينها تدريب وخدمة GPU الذي نجدوله يومياً. إرسال 43 محاولة AutoML متوازية عبر عدة عُقد يتطابق مباشرة مع طريقة إدارة Kueue لطوابير GPU في منصتنا. وخدمة مهايئ LoRA عبر نقطة نهاية متوافقة مع OpenAI بواسطة NIM تحل المشكلة ذاتها التي نحلها عبر مسار الخدمة القائم على vLLM. كما أن كون LoRA يقلل زمن استخدام GPU بشكل كبير مقارنة بالتدريب الكامل SFT يدعم أطروحتنا القائلة بأن الخدمة منخفضة التكلفة والتدريب منخفض التكلفة يصنعان في النهاية جدوى اقتصادية للوكيل. عندما يريد عميل إجراء تدريب لاحق لنموذج أساسي على بياناته الخاصة، فإننا نوفر له مساراً يقسّم GPU عبر Kueue ويخدم المهايئ عبر vLLM فوق عنقوده (cluster) الخاص، بدلاً من سحابة خارجية مقيدة الوصول.

بجمع الزاويتين معاً تكتمل الصورة. تسند ai-platform التدريب والخدمة منخفضي التكلفة، وفوقهما يقود Paxis الوكيل بالمهارات والسياسات والتدقيق. وحالة NVIDIA أظهرت، عبر معيار قياس لجهة أخرى، أن هذا التركيب يؤدي فعلاً إلى تحسن حقيقي في الأداء.

الحدود والاعتراضات

لتجنب المبالغة في تقدير هذه الحالة، ينبغي النظر في أربع نقاط معاً. أولاً، عبارة “في يوم واحد” مقياسها الزمن الفعلي (wall clock) لا زمن GPU. فمسح استغرق 19.5 ساعة عبر 8 وحدات A100 وعدة عُقد ليس رخيصاً بأي حال، والنسبة “سُبع الزمن” قيمة نسبية مقارنة بالتدريب الكامل SFT، لا تعني رخصاً مطلقاً. ثانياً، نسبة 93.35% رقم يخص مهمة ضيقة هي أسئلة وأجوبة فيديو للسلامة المرورية من نوع الاختيار من أربعة بدائل، ولا ينبغي تعميمها على أنها ارتفاع مماثل في القدرة العامة على الاستدلال الفيزيائي. ثالثاً، الأتمتة تُخفي التبعية للمزود. السبب في قدرة الوكيل على إصلاح الخطأ “بنفسه” هو أن بنك المهارات كان يعرف مسبقاً نمط الخطأ الخاص بذلك الإطار البرمجي بالضبط، وهذه السلاسة تختفي بمجرد الخروج من تلك المنظومة. رابعاً، “الحد الأدنى من التدخل” لا يعني تدخلاً معدوماً. فلا تبدأ العملية إلا بعد أن يُدخل الإنسان مفاتيح API، ويحدد مسارات مجموعة البيانات، ويثبت أصلاً بنك المهارات المناسب لتلك المهمة. ما ألغاه الوكيل هو العمل المتكرر، لا الحكم البشري نفسه.

ومع ذلك فإن الاتجاه واضح. إن تجميد معرفة سير العمل في هيئة مهارة، وتكرار الوكيل تنفيذها، والتحقق من التحسن عبر بوابة قياس فعلية لا عبر تقرير ذاتي من النموذج، ليست استراتيجية خاصة بمزود واحد، بل تصميم مشترك لعصر الوكلاء. وهذا بالضبط ما نسعى إلى بنائه عبر Paxis وai-platform.

المصادر

• NVIDIA Developer Blog, “Post-Train NVIDIA Cosmos 3 in One Day Using Agent Skills” (https://developer.nvidia.com/blog/post-train-nvidia-cosmos-3-in-one-day-using-agent-skills/)
• GitHub: NVIDIA/cosmos, NVIDIA-TAO/tao-skill-bank
• Hugging Face: nvidia/Cosmos3-Nano, nvidia/Cosmos3-Super
• مجموعة البيانات: Woven Traffic Safety (WTS)، Toyota

نظرة عامة

عنوان الورقة البحثية هو “Harness Updating Is Not Harness Benefit”، أي أن تحديث الأداة والاستفادة منها أمران مختلفان. معظم الأنظمة التي تتعامل مع الوكلاء ذاتية التطور قاست هذين الأمرين ككتلة واحدة. يحل الوكيل مهمة، ثم يستخرج من سجل التنفيذ تعديلات على الموجّهات أو المهارات، ثم يُعاد تشغيل المهمة التالية بالأداة المعدَّلة، وإذا ارتفعت الدرجة النهائية، يُعلَن أن “التطور نجح”.

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

ما الذي تسأله هذه الدراسة

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

تقسّم الدراسة عملية التطور هذه إلى قدرتين.

الأولى هي قدرة تحديث الأداة (harness-updating): القدرة على النظر إلى أدلة مهمة منجَزة وإنتاج تحديث دائم وقابل لإعادة الاستخدام. استخلاص درس من حالة فاشلة وتدوينه في وثيقة مهارة، أو ملاحظة نمط متكرر وترسيخه كقاعدة في الموجّه، كلاهما يندرج تحت هذه الفئة.

الثانية هي قدرة الاستفادة من الأداة (harness-benefit): القدرة، عند توفّر أداة محدَّثة، على استدعائها فعليًا واتباعها لرفع أداء المهمة. مهارة جيدة تجلس دون استخدام في المكتبة، أو مهارة يتم استدعاؤها لكن لا تُتَّبع تعليماتها حتى النهاية، كلتاهما تنتج استفادة تساوي صفرًا.

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

flowchart TB
    A[تنفيذ المهمة] --> B[جمع أدلة التنفيذ]
    B --> C{قدرة تحديث الأداة<br/>إنتاج تحديثات دائمة من الأدلة}
    C --> D[أداة محدَّثة<br/>موجّهات، مهارات، ذاكرة، أدوات]
    D --> E{قدرة الاستفادة من الأداة<br/>استدعاء التحديثات واتباعها بأمانة}
    E --> F[أداء حل المهمة]
    F -.تُقاس معًا في الحلقة نفسها.-> G[المكسب المقاس<br/>القدرتان متشابكتان]
    C -.نتيجة القياس المنفصل.-> H[ثابتة<br/>متشابهة بصرف النظر عن فئة النموذج]
    E -.نتيجة القياس المنفصل.-> I[غير رتيبة<br/>النماذج متوسطة الفئة تستفيد أكثر]

ما الذي يكشفه فصل القدرتين

تتلخّص نتيجة التجربة المنفصلة في جملتين، وكلتاهما تخالف الحدس العملي.

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

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

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

لماذا لا تستفيد النماذج الضعيفة

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

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

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

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

دلالات على منتجات ThakiCloud

خلاصة هذه الدراسة تتطابق تمامًا مع الانضباط الذي بنيناه في تشغيل Paxis. Paxis هو Agent-Native Cloud من ThakiCloud، ويعامل المهارات والأدوات والسياسات كموارد من الدرجة الأولى. نختار من أكثر من 960 مهارة باستخدام BM25 وننفّذها في بيئات معزولة (sandboxes)، وحلقة التطور الذاتي للمهارات لدينا تستخلص الدروس من الإخفاقات وتعدّل وثائق المهارات. بعبارة أخرى، نحن نُشغّل بالفعل حلقة “تحديث الأداة” كل يوم.

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

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

هناك أيضًا دلالة على مستوى البنية التحتية. تُشغّل ai-platform عدة فئات من النماذج فوق K8s وKueue. تشير هذه الدراسة إلى أنه من المنطقي، عند نشر خط أنابيب ذاتي التطور، وضع فئات نماذج مختلفة في أدوار مختلفة للمطوِّر وحلّ المهمة. النشر المختلط، نموذج رخيص كمطوِّر ونموذج متوسط الفئة كحلّال للمهمة، تصميم يمكنه توفير تكلفة كبيرة في جدولة GPU متعددة المستأجرين مع الحفاظ على الجودة.

حدود الدراسة وحجج مضادة

قبل نقل هذه الدراسة مباشرة إلى الممارسة، تستحق بضع تحفّظات الذكر.

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

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

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

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

المصادر

• Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents، arXiv 2605.30621: arxiv.org/abs/2605.30621
• صفحة Hugging Face Papers: huggingface.co/papers/2605.30621
• خلفية ذات صلة: Agentic Harness Engineering، arXiv 2604.25850: arxiv.org/html/2604.25850v3

نظرة عامة

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

يمثّل MCP خط الأنابيب خلف هذه الصورة. MCP بروتوكول مفتوح يتيح لـ Claude التحدث مع أدوات خارج نافذة المحادثة، والموصلات هي التكاملات بنقرة واحدة التي بنتها Anthropic وشركاؤها فوق هذا البروتوكول. حين يستدعي عمل موصلًا، فهذا يعني أن العمل أصبح قادرًا الآن على قراءة وكتابة البيانات مباشرة في الأنظمة الخارجية المرتبطة بخادم MCP ذاك.

ما هي أعمال Claude Code وموصلات MCP

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

الموصلات هي طبقة التكامل المبنية فوق خوادم MCP. تُضاف موصلات المكتبة بنقرة واحدة وتسجيل دخول عبر OAuth من قسم Connectors تحت Customize. من بينها Notion وGmail وSlack وHubSpot وLinear وCanva وAtlassian وMicrosoft 365. يضم دليل الموصلات أكثر من 375 تكاملًا يغطي الملفات والبريد الإلكتروني وإدارة المشاريع والتحليلات والتصميم والمبيعات وأدوات المطورين.

يوضّح المخطط أدناه الفرق في تدفق البيانات بين عمل ثابت وعمل حي.

flowchart TB
    U[المستخدم يفتح العمل] --> Q{هل هو عمل حي}
    Q -- لا --> S[عرض اللقطة<br/>المأخوذة عند الإنشاء]
    Q -- نعم --> M[إعادة استعلام موصلات MCP]
    M --> C1[المصادر المتصلة:<br/>Notion وSlack وHubSpot وغيرها]
    C1 --> R[العرض بالحالة الراهنة]
    R --> W{هل هو إجراء كتابة أو حذف}
    W -- نعم --> A[طلب موافقة المستخدم]
    W -- لا --> D[اكتمال تحديث الشاشة]
    A --> D

كيف يعمل

تتلخص الآلية في ثلاث قواعد.

أولًا، يعيد الاستعلام في كل مرة يُفتح فيها. يعيش العمل الحي في تبويب منفصل داخل الشريط الجانبي لـ Cowork، وفي كل مرة يُفتح فيها يعيد استعلام موصلاته ويرسم الحالة الراهنة. يمكن ربطه بموصل واحد فقط، أو دمج عدة موصلات معًا في شاشة واحدة. ومن هنا تأتي فكرة لوحة معلومات موحّدة تسحب من مصادر متعددة.

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

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

من زاوية إدارة المؤسسات، أُضيف أيضًا مسار لتوفير الموصلات على مستوى المؤسسة. بمجرد أن يسجّل المسؤول موصلًا عبر مزوّد هوية مثل Okta، يحصل المستخدمون على وصول الموصل تلقائيًا عند تسجيل الدخول الأول دون أي إعداد إضافي. يُهيَّأ التوثيق مركزيًا على مستوى المؤسسة، وتُشارك هذه الصلاحية عبر محادثة Claude وClaude Code وCowork.

مثال إعداد عملي

إضافة خادم MCP في Claude Code تتطلب أمرًا واحدًا وملف إعدادات واحدًا. إليك الأمر الفعلي لإضافة خادم MCP محلي.

# تسجيل خادم MCP في Claude Code
claude mcp add my-metrics --command "python3" --args "servers/metrics_mcp.py"

# التحقق من الخوادم المسجَّلة
claude mcp list

يمكن الإعلان عن خوادم MCP المرتبطة بمشروع في .mcp.json في جذر المستودع ومشاركتها مع الفريق. البنية كالتالي.

{
  "mcpServers": {
    "my-metrics": {
      "command": "python3",
      "args": ["servers/metrics_mcp.py"],
      "env": { "METRICS_DB_URL": "postgres://..." }
    }
  }
}

بالنسبة للموصلات البعيدة، يُستخدم نقطة نهاية MCP بعيدة وتدفق OAuth. أما موصلات المكتبة فهي أبسط: انتقل إلى قسم Connectors تحت Customize في الواجهة، اضغط زر الإضافة، وابحث عن التطبيق الذي تريد ربطه. داخل العمل، يُستدعى الموصل المرتبط كأنه دالة لجلب البيانات، وتُعرض النتيجة كمكوّن في لوحة المعلومات. ما نحتاج إلى كتابته ليس خط أنابيب نشر لواجهة أمامية، بل تعليمات بلغة طبيعية تحدد أي الموصلات نستعلم عنها وبأي ترتيب، وماذا نرسم بالنتيجة.

دلالات على منتجات ThakiCloud

هذه الميزة هي النسخة الموجّهة للمستهلك من مشكلة نعمل عليها منذ فترة طويلة في Paxis. Paxis هو Agent-Native Cloud الخاص بـ ThakiCloud، ويتعامل مع المهارات والأدوات والسياسات كموارد من الدرجة الأولى. من أهم أجزاء طبقة الأدوات تلك خط الأنابيب الذي يدير موصلات MCP مع إعادة اتصال OAuth تلقائية. خطوة Anthropic في السماح للأعمال باستدعاء الموصلات تشير بالضبط إلى النقطة ذاتها التي يستهدفها تصميمنا: الوكلاء الذين يتحدثون مع أنظمة خارجية يحتاجون إلى ترقية الموصلات لتصبح موارد من الدرجة الأولى.

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

من الناحية التحتية، تمثّل ai-platform الطبقة التي تخدم خوادم MCP التي يستعلم عنها عمل حي، بشكل موثوق فوق K8s. حين يعرض فريق ما البيانات التي يراجعها كثيرًا كخوادم MCP، مثل MCP للمؤشرات الداخلية أو MCP لحالة النشر أو MCP للتكلفة، يستطيع المطورون تجميع لوحات تشغيل خاصة بهم عبر أعمال حية دون كتابة سطر واحد من الواجهة الأمامية. كون خلفية MCP موثوقة ومنخفضة التكلفة هو ما يجعل اقتصاديات الوكلاء ممكنة، ولهذا تتحرك طبقة الخدمة في ai-platform وطبقة الموصلات في Paxis ككيان واحد.

القيود والحجج المضادة

هناك بضع نقاط يجب توضيحها قبل التبني.

أولًا، جزء كبير من هذه الميزة مرتبط بخطتي Team وEnterprise، وببيئة Cowork. لا تُستنسخ الأعمال الحية والموصلات المُدارة على مستوى المؤسسة كما هي في الخطط الفردية، لذا يجب أن يفترض حساب القيمة تبنّيًا على مستوى المؤسسة كخط أساس.

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

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

المصادر

• Claude Code now supports artifacts, Anthropic: claude.com/blog/artifacts-in-claude-code
• Connect Claude Code to tools via MCP, Claude Code Docs: code.claude.com/docs/en/mcp
• Get started with custom connectors using remote MCP, Claude Help Center: support.claude.com/en/articles/11175166
• Anthropic Claude Code Artifacts update, VentureBeat: venturebeat.com/data/anthropics-claude-code-artifacts-update-brings-live-shared-dashboards-and-interactive-workspaces-to-enterprises

Agent skills conduct the repetitive labor of GPU training, evaluation, and tuning. The human only supplies the goal through a prompt.

What Cosmos 3 and Agent Skills Are

Cosmos 3 is a foundation model NVIDIA built to handle the physical world. It uses a Mixture-of-Transformers architecture that unifies text, images, video, ambient sound, and motion tracking, combining an autoregressive reasoning tower responsible for logic and planning with a diffusion transformer that predicts future states. NVIDIA states that this model ranks first on multiple benchmarks including VANTAGE-Bench, PAI-Bench, Physics-IQ, RoboLab, and RoboArena. It comes in two sizes, the 64B Cosmos 3 Super and the 16B Cosmos 3 Nano, and this case study uses Nano.

The key here is not the model but the TAO agent skill attached alongside it. A TAO agent skill is a bundle of knowledge that automates the post-training workflow for vision models. It encapsulates task-specific knowledge such as framework details, launcher behavior, config structure, data loading conventions, and evaluation workflows, so that a coding agent like Codex or Claude can orchestrate a training pipeline on its own with minimal human intervention. In other words, a skill is not a single-line prompt but a reusable unit that packages an executable procedure together with failure recovery.

Post-Training That Finishes with Two Prompts

What makes this case study striking is that the only human input was two natural-language prompts.

The first prompt instructs LoRA post-training. It asks the agent to train nvidia/Cosmos3-Nano with LoRA on Toyota’s Woven Traffic Safety dataset, but to run a baseline evaluation first for comparison.

Perform LoRA post-training of the Cosmos 3 model on the Woven Traffic
Safety dataset. Training data: /home/.../WTS_dataset/wts_data_train
Validation data: /home/.../WTS_dataset/wts_data_val
Base model on Hugging Face: nvidia/Cosmos3-Nano
Also perform a baseline evaluation first, to compare with the post-trained model.

With this single prompt, the agent handled several tasks in sequence. It found and patched a missing FPS parameter in the data pipeline on its own, cached the model using a Hugging Face token, measured a pre-training zero-shot baseline of 54.41%, and then ran LoRA training. What stands out here is the instruction to “run a baseline evaluation first.” Instead of trusting a self-reported result after training, the agent pinned down a pre-training number as a measured baseline and actually measured the improvement. This is exactly the same principle we learned from our experiment last week.

The second prompt is an AutoML sweep. It leaves the search strategy and which hyperparameters to tune up to TAO, and asks the agent to optimize validation accuracy and summarize the best models.

Run an AutoML sweep to improve the LoRA result. Let TAO choose suitable
search strategies and tune the important training hyperparameters. Optimize
validation accuracy and summarize the best models.

Looking at the overall flow as a diagram, the human appears only at both ends, while the skill fills in the repetitive work in between.

flowchart TB
    A["Natural-language prompt<br/>(LoRA training + baseline eval)"] --> B["Coding agent<br/>(Codex / Claude)"]
    B --> C["TAO agent skill<br/>encapsulates framework, launcher, config,<br/>data loading, and evaluation knowledge"]
    C --> D["Automatic error patching<br/>(fixing missing FPS parameter)"]
    C --> E["Model caching<br/>(Cosmos3-Nano via HF token)"]
    C --> F["Baseline evaluation<br/>(zero-shot 54.41%)"]
    F --> G["LoRA post-training<br/>(8x A100, ~30 min/epoch)"]
    G --> H["AutoML sweep<br/>(43 parallel trials, 19.5 hours)"]
    H --> I["Serving the best adapter<br/>Cosmos 3 Reasoner NIM<br/>(OpenAI-compatible endpoint)"]

Environment setup is three tokens and one install script line. Set HUGGINGFACE_TOKEN, NGC_API_KEY, and AUTOML_LLM_API_KEY in the terminal, then install the agent skill with the script below.

export HUGGINGFACE_TOKEN="your_hf_token"
export NGC_API_KEY="your_ngc_key"
export AUTOML_LLM_API_KEY="your_llm_key"

curl -fsSL https://raw.githubusercontent.com/NVIDIA-TAO/tao-skills-bank/main/scripts/install-codex-agents.sh | bash

The training data is Toyota’s Woven Traffic Safety dataset, a video question-answering task with over 8,000 training and validation samples. It consists of four-choice questions about road structure, road type, and traffic safety situations.

The Numbers Two Prompts Produced

Performance improved clearly. All the figures below are values NVIDIA published, not results we reproduced.

Two prompts raised validation accuracy from 54.41% to 93.35%. NVIDIA published figures.

The zero-shot baseline was 54.41%, and the single-prompt LoRA run raised it by 32.73 points to 87.14%. On top of that, the AutoML sweep tuned hyperparameters with Bayesian optimization and pushed it to 93.35%, a gain of 38.94 points over the baseline. The key point is that these numbers came without a human touching a single hyperparameter by hand; the agent chose the search strategy and ran the repeated training itself.

To be honest about it, we also need to look at the cost numbers. LoRA training took about 30 minutes per epoch on 8x A100 80GB GPUs, and the AutoML sweep ran 43 trials in parallel across multiple A100 nodes, taking 19.5 hours. A full-parameter SFT run used as a comparison took 3h34m on H100, and NVIDIA states that LoRA cut GPU time to roughly one-seventh of that full SFT run. Once training finishes, Cosmos 3 Reasoner NIM serves the LoRA adapter through an OpenAI-compatible endpoint, a structure that deploys directly as a prebuilt microservice without requiring manual setup of vLLM dependencies or CUDA configuration.

Did We Run This Ourselves

To be honest, we did not reproduce this workflow in our own environment. The Cosmos 3 family of weights sits behind a gated Hugging Face repository, it requires 8 A100 GPUs plus NGC and AutoML LLM keys, and the parallel sweep used in the case study assumes multiple GPU nodes. We did not secure this combination of resources for this post. So every number above is a quote of a value NVIDIA published, and we do not present it as something we measured ourselves. We hold to the principle of never fabricating a benchmark without reproducing it. What we can do instead is dissect the structure of this case study and precisely contrast it with what is already running on our own platform, noting what matches and what differs.

Implications for ThakiCloud Products

This case study is a rare topic where the perspectives of both our products interlock.

From the Paxis lens, this is external validation of our thesis that skills should be treated as first-class resources. Paxis is ThakiCloud’s Agent-Native Cloud control plane, and it treats Skills, Tools, Policies, and Audit Logs as first-class resources. The Skill Harness selects from over 960 skills using BM25, runs them in an isolated sandbox, and routes every action through policy gates and audit logs. What NVIDIA’s TAO agent skill proves is that when a skill encapsulates framework details all the way down to failure recovery, a coding agent can reliably repeat a complex workflow. This is exactly the direction we have been defining skills in: not as prompts, but as units of execution. The difference is just as clear, though. TAO skills are tightly bound to the NVIDIA stack, so they are hard to use as-is outside the TAO launcher, Cosmos models, NGC, and NIM. The Paxis skill harness is designed to avoid dependency on any specific vendor or model, and that is exactly the core of the value we aim to deliver in on-premises and sovereign environments.

From the ai-platform lens, this is exactly the GPU training and serving we schedule every day. Throwing 43 AutoML trials in parallel across multiple nodes directly overlaps with how Kueue manages the GPU queue on our platform. NIM serving a LoRA adapter through an OpenAI-compatible endpoint solves the same problem our vLLM serving path solves. And the fact that LoRA cuts GPU time substantially compared to full SFT supports our thesis that low-cost serving and low-cost training are ultimately what make agent economics work. When a customer wants to post-train a foundation model on their own data, we offer a path where they slice GPUs with Kueue and serve adapters with vLLM on their own cluster, rather than going through a gated external cloud.

Put the two lenses together and the picture is complete. ai-platform underpins low-cost training and serving, and on top of that Paxis drives the agent with skills, policies, and audit. NVIDIA’s case study, using someone else’s benchmark, shows that this combination actually leads to real performance gains.

Limits and Counterarguments

To avoid overstating this case study, four things need to be kept in view together. First, “in one day” is a wall-clock measure, not a GPU-time measure. A 19.5-hour sweep across 8 A100 GPUs and multiple nodes is by no means cheap, and one-seventh is a relative figure against full SFT, not a claim of absolute cheapness. Second, 93.35% is a number from a narrow task: four-choice traffic-safety video QA. It should not be inflated into a claim that general physical reasoning ability improved by that much. Third, automation hides vendor lock-in. The reason the agent could patch errors “on its own” is that the skill bank already knew that exact framework’s error patterns in advance. That smoothness disappears once you step outside the stack. Fourth, “minimal intervention” is not zero intervention. A human still has to enter API keys, specify dataset paths, and install a skill bank suited to that task in the first place before the flow can begin. What the agent removed is repetitive labor, not judgment itself.

Even so, the direction is clear. Hardening workflow knowledge into a skill, having an agent execute that skill repeatedly, and confirming improvement through a measured gate rather than a self-report is not one vendor’s strategy but a common design pattern of the agent era. That structure is exactly what we are building with Paxis and ai-platform.

Sources

• NVIDIA Developer Blog, “Post-Train NVIDIA Cosmos 3 in One Day Using Agent Skills” (https://developer.nvidia.com/blog/post-train-nvidia-cosmos-3-in-one-day-using-agent-skills/)
• GitHub: NVIDIA/cosmos, NVIDIA-TAO/tao-skill-bank
• Hugging Face: nvidia/Cosmos3-Nano, nvidia/Cosmos3-Super
• Dataset: Woven Traffic Safety (WTS), Toyota

Overview

The paper is titled “Harness Updating Is Not Harness Benefit.” Read literally, updating a harness and benefiting from a harness are two different things. Most systems that work with self-evolving agents have measured these two as a single blob. An agent solves a task, extracts prompt or skill edits from the execution trace, runs the next task with the revised harness, and if the final score goes up, the system declares that “evolution worked.”

The problem is that this verdict conflates two distinct abilities: the ability to produce a useful, durable update from execution evidence, and the ability to actually put that updated harness to work when solving a task. Both abilities live inside the same model, but they are fundamentally different in character. And because prior evaluations measured both inside the same execution loop at once, looking at the final score alone could not tell you where the improvement came from. The authors propose an experimental design that untangles this conflation, and the result runs directly against conventional wisdom in the field.

What This Research Asks

First, some terminology. Here, a harness refers to the entire set of editable, external components that shape an agent’s behavior without touching the model’s parameters. Prompts, skills, memory, and tool definitions are all part of the harness. Self-evolution is the process by which an agent reviews its own execution outcomes and revises this harness on its own. The model stays fixed; only the surrounding knowledge and tooling change.

The study splits this evolution process into two abilities.

The first is harness-updating: the ability to look at evidence from a completed task and produce a useful, reusable, persistent update. Extracting a lesson from a failed case and writing it into a skill document, or noticing a recurring pattern and hardening it into a prompt rule, both fall under this category.

The second is harness-benefit: the ability, given an updated harness, to actually retrieve it and follow it to raise task performance. A good skill sitting unused in the library, or a skill that gets invoked but whose instructions are not followed through to the end, both produce zero benefit.

The key insight is that these two abilities must be measured separately. If you pair the model that produced the update with a different model that uses the update, you can tell whether an improvement came from the quality of the update or the quality of how it was used. The diagram below shows the structure of the conflation and where the separation happens.

flowchart TB
    A[Task Execution] --> B[Collect Execution Evidence]
    B --> C{Harness-Updating Capability<br/>Generate persistent updates from evidence}
    C --> D[Updated Harness<br/>Prompts, Skills, Memory, Tools]
    D --> E{Harness-Benefit Capability<br/>Invoke and faithfully follow updates}
    E --> F[Task-Solving Performance]
    F -.Measured together in the same loop.-> G[Measured Gain<br/>Two capabilities entangled]
    C -.Separated measurement.-> H[Flat<br/>Similar regardless of model tier]
    E -.Separated measurement.-> I[Non-monotonic<br/>Mid-tier models benefit most]

What Separating the Two Abilities Reveals

The result of the separated experiment comes down to two sentences. Both run against practical intuition.

First, harness-updating capability is flat across model tiers. Harness updates produced by models of very different capability tiers delivered surprisingly similar gains. In the authors’ own words, updates produced by a small 9B-scale model matched the gains delivered by updates from a top-tier frontier model. In other words, “who wrote the skill” barely moved the quality of the update. Extracting a rule and hardening it into documentation turns out to be a cheaper cognitive task than expected.

Second, harness-benefit capability is non-monotonic across tiers. Given the same updated harness, weak-tier models saw almost no gain, mid-tier models gained the most, and top-tier models gained less than the mid-tier models did. Rather than a curve that keeps climbing as you move up, it is a curve that bulges in the middle.

Overlay these two results and the picture flips. Assigning an expensive frontier model to the evolver role, the one that produces updates, in a self-evolving system is close to wasted budget, since update quality is flat regardless. Assigning an expensive model to the agent that actually solves tasks is not necessarily optimal either, since benefit is non-monotonic. A strong model already has its own habits set, and tends to follow an external harness’s instructions less closely.

Why Weaker Models Don’t Benefit

The most practically useful part of the paper analyzes why weak-tier models fail to benefit. The authors point to two failure modes.

The first is activation failure. Even when a skill in the library is a perfect match, the model fails to retrieve it. The judgment required to connect a relevant harness artifact to the current situation simply does not fire. The skill exists, but gets dropped at the retrieval and selection stage, so no amount of accumulated updates helps.

The second is unfaithful execution. The model successfully retrieves the skill, but fails to follow its multi-step instructions through to the end. When the ability to hold a long chain of instructions is weak, a good harness gets derailed into a partial, drifted execution partway through.

This diagnosis points to a clear prescription. To raise self-evolution performance, don’t raise the evolver’s intelligence, target harness invocation (activation) and faithful execution of long instructions. Your capability budget buys more when spent on the side that uses updates, specifically on these two bottlenecks, rather than on the side that produces them.

Implications for ThakiCloud Products

This study’s conclusion lines up closely with the discipline we’ve built running Paxis. Paxis is ThakiCloud’s Agent-Native Cloud, and it treats skills, tools, and policies as first-class resources. We select from more than 960 skills using BM25 and execute them in isolated sandboxes, and our self-evolving skill loop extracts lessons from failures and revises skill documentation. In other words, we already run a “harness-updating” loop every day.

The first lesson this study offers is: don’t attach an expensive model to the evolver. A nightly evolution loop that improves skills and logs retrospectives can run on a low-cost tier under the premise that update quality is flat. In fact, our skill model policy already starts evolution and orchestration stages on sonnet by default, pinning a higher-tier model only for the small set of skills where content quality is itself the deliverable. This study gives that choice an evidentiary basis: it was optimization with no quality loss, not just cost savings.

The second lesson is the diagnosis that the bottleneck is “activation and execution.” In our environment, this is precisely the problem of skill routing and gate compliance. No matter how many skills exist, if the right one is not retrieved at request time, that is activation failure, and if a skill is invoked but its deterministic gates are not honored, that is unfaithful execution. Paxis’s decision to strengthen skill retrieval with a BM25 router, and to have format and validation owned by code gates rather than the model’s own prose judgment, targets exactly these two bottlenecks. Performance is decided less by piling on more good skills and more by the plumbing that retrieves the right skill precisely and enforces its instructions to the end.

There is an infrastructure implication too. ai-platform serves multiple model tiers on top of K8s and Kueue. This study suggests that when deploying a self-evolving pipeline, it is reasonable to place different model tiers in different roles for the evolver and the task solver. A mixed deployment, a cheap model as evolver and a mid-tier model as the task solver, is a design that can save substantial cost in multi-tenant GPU scheduling while holding quality steady.

Limitations and Counterarguments

Before carrying this study straight into practice, a few caveats are worth naming.

First, the conclusions of “flat” and “non-monotonic” are tied to the task distribution and harness types the experiments covered. Rule-extraction work like revising skill documentation may show flat updating capability, but updates that involve implementing complex tools or generating long orchestration code may well reopen the gap between model tiers. Whether our own updates lean toward the former or the latter is something each team has to measure for itself.

Second, the finding that top-tier models benefit less from an external harness can also be read as a ceiling effect: a strong model is already good, so there is less room left to improve. This does not mean the harness is useless. Absolute performance can still be higher for a strong model; the harness is simply a marginal gain layered on top.

Third, for an organization like ours that already practices “evolve cheap, gate expensive,” this study reads less like a new direction and more like quantitative backing for an existing discipline. For a team that has been reflexively raising the evolver model’s tier whenever self-evolution performance stalls, on the other hand, this data is a clear signal to reallocate budget.

In the end, this study leaves us with one practical rule. Don’t look at a self-evolving harness’s performance as a single score. Decompose it into two axes, updating and benefit, and measure each separately. Only once you separate them does it become clear where your capability budget should actually go.

Sources

• Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents, arXiv 2605.30621: arxiv.org/abs/2605.30621
• Hugging Face Papers page: huggingface.co/papers/2605.30621
• Related background: Agentic Harness Engineering, arXiv 2604.25850: arxiv.org/html/2604.25850v3

Source: RT @kimmonismus: NVIDIA says Codex post-trained Cosmos 3 Nano from 54.41% to 93.35% accuracy in one day - with two prompts · twitter

What this means for ThakiCloud

The catch with a self-improving loop isn’t the accuracy, it’s the meter. Every round of getting smarter is another stretch of GPUs running flat out, and on a rented cloud that stretch shows up as a line item. Run the loop on someone else’s hardware and the model improves while the invoice does too. ThakiCloud’s Metis keeps training and inference inside your own walls (on-prem), so both the smarter model and the compute that made it stay under your control. Let Paxis’s agents refine the model and Metis absorb the training, on your racks, not a landlord’s counter.

An auto-generated comic riffing on this week’s industry news.

Overview

The core shift is that artifacts moved from “read-only output” to “executable client.” Where an old artifact rendered a snapshot of data, a live artifact sends queries to the actual source through a connector. The use cases this unlocks are obvious: CRM pipeline views, project trackers, morning briefings, weekly metrics boards, anything where the underlying data keeps changing. Because it pulls fresh data on every open, nobody has to hit refresh, and no separate backend has to push data in on a cron.

MCP is the plumbing behind this picture. MCP is an open protocol that lets Claude talk to tools outside the chat window, and connectors are the one-click integrations that Anthropic and its partners have built on top of it. When an artifact calls a connector, it means the artifact can now directly read and write data in the external systems attached to that MCP server.

What Claude Code Artifacts and MCP Connectors Are

Let’s start with artifacts. An artifact turns the work from a Claude Code session into a living, shareable visual page. A pull request description with an annotated diff, a dashboard assembled from session data, a timeline that fills in as an investigation progresses: all of these can be artifacts. A live artifact goes one step further and refreshes itself. Every time it opens, it re-queries the connectors it’s wired to and shows the current state.

Connectors are the integration layer built on top of MCP servers. Library connectors attach with a single click and an OAuth login from the Connectors section under Customize. Notion, Gmail, Slack, HubSpot, Linear, Canva, Atlassian, and Microsoft 365 all live there. The connector directory lists 375+ integrations spanning files, email, project management, analytics, design, sales, and developer tools.

The diagram below shows the difference in data flow between a static artifact and a live artifact.

flowchart TB
    U[User opens the artifact] --> Q{Is it a live artifact}
    Q -- No --> S[Render the snapshot<br/>from creation time]
    Q -- Yes --> M[Re-query MCP connectors]
    M --> C1[Connected sources:<br/>Notion/Slack/HubSpot etc.]
    C1 --> R[Render with current state]
    R --> W{Is it a write/delete action}
    W -- Yes --> A[Ask user for approval]
    W -- No --> D[Screen refresh complete]
    A --> D

How It Works

The mechanics come down to three rules.

First, it re-queries every time it opens. A live artifact lives in its own tab in the Cowork sidebar, and every time it opens it re-queries its connectors and draws the current state. You can wire it to a single connector or stitch several together into one screen. That’s where a unified dashboard pulling from multiple sources comes from.

Second, writes and deletes go through an approval gate. When a connector doesn’t just read data but actually performs an action that changes data at the connected source, Claude is required to ask the user for approval first. It’s a safeguard against automation quietly touching the source of truth. When you’re configuring a tool, the first thing to check is whether approval is required for the Write and Delete tool categories.

Third, access scope is tied to the individual. In Team or Enterprise organizations, only owners can add a connector to the organization, but the actual connection and activation happen per user. So Claude only accesses the tools and data that user already has permission for. A notable Team and Enterprise feature: when a shared artifact is used by a teammate, no extra cost hits the person who created it.

From an enterprise administration angle, there’s also a flow for provisioning connectors at the organization level. Once an admin registers a connector through an identity provider like Okta, users get connector access automatically on first login with no extra setup. Authentication is configured centrally at the organization level, and this access is shared across Claude chat, Claude Code, and Cowork.

A Practical Setup Example

Attaching an MCP server in Claude Code takes one command and one config file. Here’s the actual command for adding a local MCP server.

# Register an MCP server with Claude Code
claude mcp add my-metrics --command "python3" --args "servers/metrics_mcp.py"

# Check registered servers
claude mcp list

MCP servers attached to a project can be declared in .mcp.json at the repository root and shared with the team. The structure looks like this.

{
  "mcpServers": {
    "my-metrics": {
      "command": "python3",
      "args": ["servers/metrics_mcp.py"],
      "env": { "METRICS_DB_URL": "postgres://..." }
    }
  }
}

For remote connectors, you use a remote MCP endpoint and an OAuth flow. Library connectors are even simpler: go to the Connectors section under Customize in the UI, click the plus button, and search for the app you want to connect. Inside the artifact, that attached connector gets called like a function to fetch data, and the result gets rendered as a dashboard component. What we need to write isn’t a frontend deployment pipeline, it’s a natural language instruction for which connectors to query in what order and what to draw with the result.

Implications for ThakiCloud’s Product Line

This feature is the consumer-facing version of a problem we’ve been working on for a long time at Paxis. Paxis is ThakiCloud’s Agent-Native Cloud, and it treats skills, tools, and policies as first-class resources. One of the core pieces of that tool layer is the plumbing that manages MCP connectors with automatic OAuth reconnection. Anthropic’s move to let artifacts call connectors points at exactly the same spot our own design already aims at: agents that talk to external systems need connectors promoted to first-class resources.

What catches our attention in particular is the approval gate and access scope. The way live artifacts require approval for write and delete actions and tie access to individual permissions comes from the same underlying concern as Paxis’s discipline of routing every agent action through a policy gate and audit log. As connectors get more powerful, the control plane that logs what a connector touched and when, and defers risky actions behind human approval, has to get stronger right along with them. The moment an artifact becomes a live app, a single dashboard turns into an execution path toward production data.

On the infrastructure side, ai-platform is the layer that serves the MCP servers a live artifact queries, reliably, on top of K8s. Once a team exposes the data it checks often, an internal metrics MCP, a deployment status MCP, a cost MCP, as MCP servers, developers can assemble their own ops dashboards with live artifacts without writing a single line of frontend code. A low-cost, reliably served MCP backend is what makes the agent economics work, which is why ai-platform’s serving layer and Paxis’s connector layer move as one.

Limitations and Counterarguments

A few things need to be clear before adoption.

First, a large part of this feature is tied to Team and Enterprise plans, and to the Cowork environment. Live artifacts and organization-managed connectors don’t carry over to individual plans as-is, so the value calculation should assume org-level adoption as the baseline.

Second, the fact that a live artifact re-queries connectors every time it opens means every view generates a request against an external system. If several people are frequently opening a dashboard with heavy queries, you need to watch rate limits and cost on the source system too. There are still screens where a static snapshot is the better choice.

Third, approval gates are powerful but not a cure-all. A query that looks read-only can still pull sensitive data onto a shareable surface like an artifact. An organizational policy on what’s allowed to be exposed in a shared artifact needs to come before the approval gate, not after it. The more convenient this feature gets, the more worth asking what control that convenience is bypassing. That’s the safe way to use it.

Sources

• Claude Code now supports artifacts, Anthropic: claude.com/blog/artifacts-in-claude-code
• Connect Claude Code to tools via MCP, Claude Code Docs: code.claude.com/docs/en/mcp
• Get started with custom connectors using remote MCP, Claude Help Center: support.claude.com/en/articles/11175166
• Anthropic Claude Code Artifacts update, VentureBeat: venturebeat.com/data/anthropics-claude-code-artifacts-update-brings-live-shared-dashboards-and-interactive-workspaces-to-enterprises

에이전트 스킬은 GPU 학습·평가·튜닝의 반복 노동을 지휘합니다. 사람은 프롬프트로 목적만 줍니다.

Cosmos 3와 에이전트 스킬은 무엇인가

Cosmos 3는 NVIDIA가 물리 세계를 다루기 위해 만든 파운데이션 모델입니다. 텍스트와 이미지, 영상, 주변 소리, 동작 추적을 하나로 묶는 Mixture-of-Transformers 구조를 쓰고, 논리와 계획을 담당하는 자기회귀 추론 타워와 미래 상태를 예측하는 디퓨전 트랜스포머를 함께 갖습니다. NVIDIA는 이 모델이 VANTAGE-Bench, PAI-Bench, Physics-IQ, RoboLab, RoboArena 여러 벤치마크에서 1위라고 밝혔습니다. 크기는 64B의 Cosmos 3 Super와 16B의 Cosmos 3 Nano가 있고, 이번 사례는 Nano를 씁니다.

핵심은 모델이 아니라 그 옆에 붙은 TAO 에이전트 스킬입니다. TAO 에이전트 스킬은 비전 모델의 포스트트레이닝 워크플로를 자동화하는 지식 묶음입니다. 프레임워크 세부, 런처 동작, config 구조, 데이터 로딩 방식, 평가 워크플로 같은 태스크별 지식을 캡슐화해서, Codex나 Claude 같은 코딩 에이전트가 사람의 개입을 최소한으로 하고도 학습 파이프라인을 스스로 조율하게 만듭니다. 다시 말해 스킬은 프롬프트 한 줄이 아니라, 실행 가능한 절차와 실패 복구까지 포장한 재사용 단위입니다.

두 개의 프롬프트로 끝나는 포스트트레이닝

이 사례가 인상적인 이유는 사람이 입력한 것이 자연어 프롬프트 두 개뿐이라는 점입니다.

첫 번째 프롬프트는 LoRA 포스트트레이닝을 지시합니다. Toyota의 Woven Traffic Safety 데이터셋으로 nvidia/Cosmos3-Nano를 LoRA로 학습하되, 비교를 위해 베이스라인 평가를 먼저 하라는 요청입니다.

Perform LoRA post-training of the Cosmos 3 model on the Woven Traffic
Safety dataset. Training data: /home/.../WTS_dataset/wts_data_train
Validation data: /home/.../WTS_dataset/wts_data_val
Base model on Hugging Face: nvidia/Cosmos3-Nano
Also perform a baseline evaluation first, to compare with the post-trained model.

이 프롬프트 하나로 에이전트는 여러 일을 순서대로 처리했습니다. 데이터 파이프라인에서 누락된 FPS 파라미터를 스스로 찾아 오류를 패치하고, Hugging Face 토큰으로 모델을 캐싱하고, 학습 전 zero-shot 베이스라인을 54.41%로 측정한 다음, LoRA 학습을 돌렸습니다. 여기서 눈여겨볼 대목은 “베이스라인 평가를 먼저 하라”는 지시입니다. 학습 후 결과를 자기 보고로 믿는 대신, 학습 전 숫자를 측정 기준선으로 박아 두고 개선을 실제로 잰 것입니다. 지난주 우리 실험에서 얻은 교훈과 정확히 같은 원리입니다.

두 번째 프롬프트는 AutoML 스윕입니다. 탐색 전략과 어떤 하이퍼파라미터를 튜닝할지는 TAO에게 맡기고, 검증 정확도를 최적화한 뒤 가장 좋은 모델을 요약하라는 요청입니다.

Run an AutoML sweep to improve the LoRA result. Let TAO choose suitable
search strategies and tune the important training hyperparameters. Optimize
validation accuracy and summarize the best models.

전체 흐름을 도식으로 보면 사람은 양 끝에만 있고, 가운데의 반복 작업은 스킬이 채웁니다.

flowchart TB
    A["자연어 프롬프트<br/>(LoRA 학습 + 베이스라인 평가)"] --> B["코딩 에이전트<br/>(Codex / Claude)"]
    B --> C["TAO 에이전트 스킬<br/>프레임워크·런처·config·<br/>데이터로딩·평가 지식 캡슐화"]
    C --> D["자동 오류 패치<br/>(누락된 FPS 파라미터 보정)"]
    C --> E["모델 캐싱<br/>(HF 토큰으로 Cosmos3-Nano)"]
    C --> F["베이스라인 평가<br/>(zero-shot 54.41%)"]
    F --> G["LoRA 포스트트레이닝<br/>(8×A100, 에폭당 ~30분)"]
    G --> H["AutoML 스윕<br/>(43개 병렬 시도, 19.5시간)"]
    H --> I["최적 어댑터 서빙<br/>Cosmos 3 Reasoner NIM<br/>(OpenAI 호환 엔드포인트)"]

환경 준비는 토큰 세 개와 설치 스크립트 한 줄입니다. 터미널에 HUGGINGFACE_TOKEN, NGC_API_KEY, AUTOML_LLM_API_KEY를 넣고, 아래 스크립트로 에이전트 스킬을 설치합니다.

export HUGGINGFACE_TOKEN="your_hf_token"
export NGC_API_KEY="your_ngc_key"
export AUTOML_LLM_API_KEY="your_llm_key"

curl -fsSL https://raw.githubusercontent.com/NVIDIA-TAO/tao-skills-bank/main/scripts/install-codex-agents.sh | bash

학습 데이터는 Toyota의 Woven Traffic Safety 데이터셋으로, 8,000개가 넘는 학습·검증 샘플을 가진 영상 질의응답 과제입니다. 도로 구조, 도로 유형, 교통 안전 상황을 묻는 4지선다 문제로 구성됩니다.

두 프롬프트가 만든 숫자

성능은 명확하게 올랐습니다. 아래 수치는 전부 NVIDIA가 공개한 값이며, 우리가 재현한 결과가 아닙니다.

프롬프트 두 개로 검증 정확도가 54.41%에서 93.35%까지 올랐습니다. NVIDIA 공개 수치.

zero-shot 베이스라인은 54.41%였고, 단일 프롬프트 LoRA가 87.14%로 32.73포인트 올렸습니다. 여기에 AutoML 스윕이 베이지안 최적화로 하이퍼파라미터를 조율해 93.35%까지, 베이스라인 대비 38.94포인트를 끌어올렸습니다. 사람이 손으로 하이퍼파라미터를 만지지 않고, 에이전트가 탐색 전략을 고르고 반복 학습을 돌려서 얻은 숫자라는 점이 핵심입니다.

비용 쪽 숫자도 함께 봐야 정직합니다. LoRA 학습은 8장의 A100 80GB에서 에폭당 약 30분이 걸렸고, AutoML 스윕은 여러 A100 노드에 걸쳐 43개 시도를 병렬로 돌려 19.5시간이 걸렸습니다. 비교군으로 돌린 풀 파라미터 SFT는 H100에서 3시간 34분이 걸렸는데, LoRA는 이 풀 SFT 대비 GPU 시간을 약 7분의 1로 줄였다고 NVIDIA는 밝혔습니다. 학습이 끝난 뒤에는 Cosmos 3 Reasoner NIM이 LoRA 어댑터를 OpenAI 호환 엔드포인트로 서빙합니다. vLLM 의존성이나 CUDA 설정을 손으로 맞출 필요 없이 사전 빌드된 마이크로 서비스로 바로 배포되는 구조입니다.

우리는 이것을 직접 돌려봤나

정직하게 밝히면, 이 워크플로를 우리 환경에서 재현하지는 못했습니다. Cosmos 3 계열 가중치는 게이트가 걸린 Hugging Face 저장소이고, 8장의 A100과 NGC 및 AutoML LLM 키가 필요하며, 사례가 쓴 병렬 스윕은 여러 GPU 노드를 전제로 합니다. 우리는 이 자원 조합을 이 글을 위해 확보하지 않았습니다. 그래서 위의 모든 숫자는 NVIDIA 공개 값을 인용한 것이고, 우리가 측정한 결과처럼 제시하지 않습니다. 재현 없이 만든 벤치마크는 만들지 않는다는 원칙을 지킵니다. 대신 우리가 할 수 있는 것은 이 사례의 구조를 뜯어보고, 우리 플랫폼에서 이미 돌고 있는 것과 무엇이 같고 무엇이 다른지 정확히 대조하는 일입니다.

ThakiCloud 제품 적용 시사점

이 사례는 우리 두 제품의 관점이 모두 맞물리는 드문 주제입니다.

Paxis 렌즈에서 보면, 이것은 스킬을 일급 리소스로 다룬다는 우리 명제의 외부 검증입니다. Paxis는 ThakiCloud의 Agent-Native Cloud 제어 평면으로, Skills와 Tools, Policies, Audit Logs를 일급 리소스로 취급합니다. Skill Harness는 960개가 넘는 스킬을 BM25로 골라 격리된 샌드박스에서 실행하고, 모든 행동을 정책 게이트와 감사 로그로 통과시킵니다. NVIDIA의 TAO 에이전트 스킬이 증명한 것은, 프레임워크 세부와 실패 복구까지 캡슐화한 스킬이 있으면 코딩 에이전트가 복잡한 워크플로를 안정적으로 반복한다는 사실입니다. 이는 우리가 스킬을 프롬프트가 아니라 실행 단위로 정의해 온 방향과 정확히 같습니다. 다만 차이도 분명합니다. TAO 스킬은 NVIDIA 스택에 강하게 묶여 있어 TAO 런처와 Cosmos 모델, NGC와 NIM을 벗어나면 그대로 쓰기 어렵습니다. Paxis의 스킬 하네스는 특정 벤더나 모델에 종속되지 않는 것을 목표로 하며, 이 지점이 우리가 온프렘과 소버린 환경에서 제공하려는 가치의 핵심입니다.

ai-platform 렌즈에서 보면, 이것은 우리가 매일 스케줄링하는 GPU 학습·서빙 그 자체입니다. 43개의 AutoML 시도를 여러 노드에 병렬로 던지는 일은 우리 플랫폼에서 Kueue가 GPU 큐를 관리하는 방식과 직접 겹칩니다. LoRA 어댑터를 OpenAI 호환 엔드포인트로 서빙하는 NIM은 우리가 vLLM으로 제공하는 서빙 경로와 같은 문제를 풉니다. 그리고 LoRA가 풀 SFT 대비 GPU 시간을 크게 줄인다는 사실은, 저비용 서빙과 저비용 학습이 결국 에이전트 경제성을 만든다는 우리 논지를 뒷받침합니다. 고객이 자기 데이터로 파운데이션 모델을 포스트트레이닝하려 할 때, 우리는 게이트가 걸린 외부 클라우드가 아니라 자기 클러스터 위에서 Kueue로 GPU를 나누고 vLLM으로 어댑터를 서빙하는 경로를 제공합니다.

두 렌즈를 합치면 그림이 완성됩니다. 저비용 학습·서빙을 ai-platform이 받치고, 그 위에서 Paxis가 스킬과 정책과 감사로 에이전트를 운전합니다. NVIDIA 사례는 이 조합이 실제 성능 개선으로 이어진다는 것을 남의 벤치마크로 보여 준 셈입니다.

한계 및 반론

이 사례를 과장하지 않으려면 네 가지를 함께 봐야 합니다. 첫째, “하루 만에”는 벽시계 기준이지 GPU 시간 기준이 아닙니다. 8장의 A100과 여러 노드에 걸친 19.5시간 스윕은 결코 저렴하지 않으며, 7분의 1은 풀 SFT 대비 상대값이지 절대적으로 싸다는 뜻이 아닙니다. 둘째, 93.35%는 4지선다 교통 안전 영상 QA라는 좁은 과제의 숫자입니다. 일반적인 물리 추론 능력이 그만큼 올랐다는 주장으로 확대하면 안 됩니다. 셋째, 자동화는 벤더 종속을 감춥니다. 에이전트가 “스스로” 오류를 패치할 수 있었던 이유는 스킬 뱅크가 정확히 그 프레임워크의 오류 패턴을 미리 알고 있었기 때문입니다. 스택을 벗어나면 이 매끄러움은 사라집니다. 넷째, “최소한의 개입”이 개입 제로는 아닙니다. 사람이 API 키를 넣고, 데이터셋 경로를 지정하고, 애초에 그 태스크에 맞는 스킬 뱅크를 설치해야 흐름이 시작됩니다. 에이전트가 지운 것은 반복 노동이지 판단 자체가 아닙니다.

그럼에도 방향은 분명합니다. 워크플로 지식을 스킬로 굳히고, 그 스킬을 에이전트가 반복 실행하며, 개선을 자기 보고가 아니라 측정된 게이트로 확인하는 구조는 특정 벤더의 전략이 아니라 에이전트 시대의 공통 설계입니다. 우리가 Paxis와 ai-platform으로 만들려는 것도 바로 그 구조입니다.

출처

• NVIDIA Developer Blog, “Post-Train NVIDIA Cosmos 3 in One Day Using Agent Skills” (https://developer.nvidia.com/blog/post-train-nvidia-cosmos-3-in-one-day-using-agent-skills/)
• GitHub: NVIDIA/cosmos, NVIDIA-TAO/tao-skill-bank
• Hugging Face: nvidia/Cosmos3-Nano, nvidia/Cosmos3-Super
• 데이터셋: Woven Traffic Safety (WTS), Toyota

개요

이 연구의 제목은 「Harness Updating Is Not Harness Benefit」입니다. 직역하면 “하네스를 갱신하는 것과 하네스로 이득을 보는 것은 다르다”입니다. 자가진화 에이전트를 다루는 대부분의 시스템은 이 둘을 한 덩어리로 측정해 왔습니다. 에이전트가 과제를 풀고, 그 실행 기록에서 프롬프트나 스킬을 고치고, 고쳐진 하네스로 다음 과제를 다시 푸는 루프를 돌린 뒤, 최종 점수가 올랐으면 “진화가 작동했다”고 판정하는 식입니다.

문제는 이 판정에 두 개의 서로 다른 능력이 섞여 있다는 점입니다. 하나는 실행 증거에서 쓸 만한 영구적 갱신을 만들어 내는 능력이고, 다른 하나는 그렇게 갱신된 하네스를 과제 해결에 실제로 활용하는 능력입니다. 두 능력은 같은 모델 안에 있지만 성격이 완전히 다릅니다. 그리고 지금까지의 평가는 이 둘을 같은 실행 루프 안에서 한꺼번에 측정했기 때문에, 최종 점수만 봐서는 향상이 어디에서 왔는지 알 수 없었습니다. 저자들은 이 뒤섞임을 풀어내는 실험 설계를 제안하고, 그 결과가 실무의 통념과 정반대라는 것을 보입니다.

이 연구는 무엇을 묻는가

먼저 용어를 정리합니다. 여기서 하네스는 모델 파라미터를 건드리지 않고 에이전트의 행동을 바꾸는 편집 가능한 외부 구성 요소 전체를 말합니다. 프롬프트, 스킬, 메모리, 도구 정의가 모두 하네스입니다. 자가진화란 에이전트가 자기 실행 결과를 보고 이 하네스를 스스로 고쳐 나가는 과정입니다. 모델은 그대로 두고 그 주변의 지식과 도구만 바뀝니다.

연구는 이 진화 과정을 두 개의 능력으로 쪼갭니다.

첫째는 하네스 갱신 능력(harness-updating)입니다. 과제를 실행한 증거를 보고, 다음에 재사용할 수 있는 유용한 영구 갱신을 만들어 내는 능력입니다. 실패한 케이스에서 교훈을 뽑아 스킬 문서에 박거나, 반복되는 패턴을 발견해 프롬프트에 규칙으로 굳히는 일이 여기에 해당합니다.

둘째는 하네스 효용 능력(harness-benefit)입니다. 그렇게 갱신된 하네스가 주어졌을 때, 그것을 실제로 불러오고 따라서 과제 성능을 끌어올리는 능력입니다. 좋은 스킬이 라이브러리에 있어도 그것을 호출하지 않거나, 호출해 놓고 지시를 끝까지 지키지 못하면 효용은 0입니다.

핵심 통찰은 이 두 능력을 분리해서 측정해야 한다는 것입니다. 갱신을 만든 모델과 그 갱신을 사용하는 모델을 서로 다르게 짜맞추면, 향상이 갱신의 질에서 왔는지 활용의 질에서 왔는지 구분할 수 있습니다. 아래 다이어그램이 뒤섞임의 구조와 분리의 지점을 보여 줍니다.

flowchart TB
    A[과제 실행] --> B[실행 증거 수집]
    B --> C{하네스 갱신 능력<br/>증거에서 영구 갱신 생성}
    C --> D[갱신된 하네스<br/>프롬프트·스킬·메모리·도구]
    D --> E{하네스 효용 능력<br/>갱신을 불러오고 끝까지 따름}
    E --> F[과제 해결 성능]
    F -.같은 루프서 한꺼번에 측정.-> G[측정된 이득<br/>두 능력이 뒤섞임]
    C -.분리 측정 결과.-> H[평면적<br/>모델 등급과 무관하게 비슷]
    E -.분리 측정 결과.-> I[비단조<br/>중간 등급이 최대 수혜]

두 능력을 분리하면 무엇이 보이는가

분리 실험의 결과는 두 문장으로 요약됩니다. 그리고 두 문장 모두 실무 직관과 어긋납니다.

첫째, 하네스 갱신 능력은 모델 등급에 대해 평평합니다. 서로 다른 능력 등급의 모델들이 만들어 낸 하네스 갱신이 놀라울 만큼 비슷한 이득을 냈습니다. 저자들의 표현을 빌리면, 9B 규모의 소형 모델이 만든 갱신조차 최상위 프런티어 모델이 만든 갱신에 필적하는 이득을 냈습니다. 다시 말해, “누가 스킬을 쓰느냐”는 갱신 품질을 거의 가르지 않았습니다. 규칙을 뽑아 문서로 굳히는 일은 생각보다 저렴한 인지 작업이라는 뜻입니다.

둘째, 하네스 효용 능력은 등급에 대해 비단조입니다. 갱신된 하네스를 쥐여 주었을 때, 약한 등급의 모델은 이득을 거의 못 봤고, 중간 등급의 모델이 가장 크게 이득을 봤으며, 최상위 등급의 모델은 중간 등급보다 오히려 이득이 작았습니다. 위로 갈수록 좋아지는 단조 곡선이 아니라 가운데가 봉긋한 곡선이었습니다.

이 두 결과를 겹쳐 놓으면 그림이 뒤집힙니다. 자가진화 시스템에서 값비싼 프런티어 모델을 갱신을 만드는 진화자(evolver) 자리에 앉히는 것은 예산 낭비에 가깝습니다. 갱신 품질은 어차피 평평하기 때문입니다. 반대로 값비싼 모델을 과제를 실제로 푸는 에이전트 자리에 앉히는 것도 효용이 비단조라 반드시 최선은 아닙니다. 강한 모델은 이미 자기 방식이 굳어 있어 외부 하네스의 지시를 덜 따르는 경향이 있습니다.

약한 모델이 못 얻는 이유

가장 실무적인 대목은 약한 등급 모델이 왜 이득을 못 보는지에 대한 분석입니다. 저자들은 두 가지 실패 모드를 짚습니다.

첫 번째는 활성화 실패입니다. 라이브러리에 딱 맞는 스킬이 있는데도 그것을 불러오지 못하는 경우입니다. 관련 하네스 아티팩트를 상황에 연결하는 판단 자체가 안 되는 것입니다. 스킬은 존재하지만 검색과 선택 단계에서 누락되므로, 아무리 좋은 갱신을 쌓아도 소용이 없습니다.

두 번째는 불충실한 이행입니다. 스킬을 불러오는 데는 성공했지만, 그 안의 여러 단계 지시를 끝까지 정확히 따르지 못하는 경우입니다. 긴 호흡의 지시를 지키는 능력이 부족하면, 좋은 하네스가 중간에 어긋난 실행으로 흘러가 버립니다.

이 진단이 향하는 처방은 분명합니다. 자가진화의 성능을 끌어올리려면 진화자의 지능을 올리는 것이 아니라, 하네스 호출(활성화)과 긴 지시의 충실한 이행을 겨냥해야 합니다. 능력 예산은 갱신을 만드는 쪽이 아니라 갱신을 쓰는 쪽, 그중에서도 이 두 병목에 투자하는 편이 이득이 큽니다.

ThakiCloud 제품 적용 시사점

이 연구의 결론은 우리가 Paxis를 운영하며 쌓아 온 규율과 정확히 맞물립니다. Paxis는 ThakiCloud의 Agent-Native Cloud로, 스킬과 도구와 정책을 일급 리소스로 다룹니다. 960개가 넘는 스킬을 BM25로 선택해 격리 샌드박스에서 실행하고, 자가진화 스킬 루프가 실패에서 교훈을 뽑아 스킬 문서를 고쳐 나갑니다. 즉 우리는 이미 “하네스를 갱신하는” 루프를 매일 돌리고 있습니다.

이 연구가 우리에게 주는 첫 번째 교훈은 진화자에 비싼 모델을 붙이지 말라는 것입니다. 스킬을 개선하고 회고를 기록하는 야간 진화 루프는 갱신 품질이 평평하다는 전제 아래 저비용 티어로 돌려도 됩니다. 실제로 우리 스킬 모델 정책은 진화·오케스트레이션 단계를 기본 sonnet으로 시작하고, 콘텐츠 품질 자체가 산출물인 소수 스킬에만 상위 모델을 핀으로 고정합니다. 이 연구는 그 선택이 비용 절감을 넘어 품질 손실 없는 최적화였다는 근거를 줍니다.

두 번째 교훈은 병목이 “활성화와 이행”이라는 진단입니다. 우리 환경에서 이는 곧 스킬 라우팅과 게이트 준수의 문제입니다. 스킬이 아무리 많아도 요청 시점에 맞는 스킬이 검색되지 않으면 활성화 실패이고, 스킬을 불러 놓고 그 안의 결정론적 게이트를 지키지 못하면 불충실한 이행입니다. Paxis가 스킬 검색을 BM25 라우터로 강화하고, 포맷과 검증을 모델의 산문 판단이 아니라 코드 게이트가 소유하도록 설계한 것은 바로 이 두 병목을 겨냥한 조치입니다. 좋은 스킬을 더 쌓는 것보다, 있는 스킬을 정확히 불러오고 그 지시를 끝까지 강제하는 배관이 성능을 가릅니다.

인프라 관점에서도 함의가 있습니다. ai-platform은 K8s와 Kueue 위에서 여러 등급의 모델을 서빙합니다. 이 연구는 자가진화 파이프라인을 배치할 때 진화자와 과제 해결자에 서로 다른 등급의 모델을 서로 다른 자리에 배치하는 것이 합리적임을 시사합니다. 값싼 모델을 진화자로, 중간 등급 모델을 과제 해결자로 두는 혼합 배치는 멀티테넌트 GPU 스케줄링에서 비용을 크게 아끼면서 품질은 지킬 수 있는 설계입니다.

한계 및 반론

이 연구를 실무에 그대로 옮기기 전에 몇 가지를 짚어야 합니다.

첫째, “평평하다”와 “비단조”라는 결론은 실험이 다룬 과제 분포와 하네스 종류에 묶여 있습니다. 스킬 문서 갱신처럼 규칙을 뽑아내는 작업에서는 갱신 능력이 평평할 수 있지만, 복잡한 도구 구현이나 긴 오케스트레이션 코드를 생성하는 갱신에서는 모델 등급이 다시 벌어질 여지가 있습니다. 우리 환경의 갱신이 어느 쪽에 가까운지는 각자 측정해야 합니다.

둘째, 최상위 모델이 외부 하네스의 이득을 덜 본다는 결과는 “강한 모델은 이미 잘하니까 개선 여지가 작다”는 천장 효과로도 해석됩니다. 이것이 하네스가 무용하다는 뜻은 아닙니다. 절대 성능은 여전히 강한 모델이 높을 수 있고, 하네스는 그 위에 얹히는 한계 이득의 문제일 뿐입니다.

셋째, 우리처럼 “진화는 싸게, 게이트는 비싸게”를 이미 실천하는 조직에는 이 연구가 새로운 방향 전환이라기보다 기존 규율의 정량적 뒷받침에 가깝습니다. 반대로 자가진화의 성능이 안 나올 때 반사적으로 진화자 모델을 올려 온 팀이라면, 이 데이터는 예산을 다시 배치하라는 분명한 신호입니다.

결국 이 연구가 남기는 실천 규칙은 하나입니다. 자가진화 하네스의 성능을 하나의 점수로 보지 말고 갱신과 효용, 두 축으로 분해해서 측정하라는 것입니다. 그렇게 분리해야 어디에 능력 예산을 써야 하는지가 비로소 보입니다.

출처

• Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents, arXiv 2605.30621: arxiv.org/abs/2605.30621
• Hugging Face Papers 페이지: huggingface.co/papers/2605.30621
• 관련 배경: Agentic Harness Engineering, arXiv 2604.25850: arxiv.org/html/2604.25850v3

디인포메이션 보도에 따르면 애플의 차세대 시리는 자사 서버가 아니라 구글 클라우드의 엔비디아 칩을 임차해 구동되고 있습니다. 자체 개발한 M2 울트라 칩의 성능이 기대에 못 미쳤고, 뒤를 잇기로 한 서버칩 ‘발트라’의 출시마저 밀렸기 때문입니다. 심지어 그 시리를 고도화하는 두뇌는 애플이 아니라 구글의 제미나이 모델입니다. 세계에서 가장 폐쇄적으로 자기 실리콘을 설계해온 회사의 대표 서비스가, 지금은 라이벌의 칩 위에서 라이벌의 모델로 작동합니다.

이 장면이 오늘 뉴스 전체를 읽는 렌즈가 됩니다. 애플은 올초 이스라엘 스타트업을 20억달러, 약 3조원에 사들였고, 반도체 스타트업 추가 인수까지 저울질하고 있습니다. CFO 케반 파레크는 그동안 고수해온 ‘순현금 중립’ 기조를 접겠다는 신호를 보냈습니다. M시리즈 로드맵도 손봤습니다. M6는 기본형만 내고, AI에 특화된 M7 프로와 맥스와 울트라에 개발을 몰아줍니다. 정작 AI 서버칩의 자체 출시 시점은 2029년으로 미뤄졌고, 브로드컴과의 협력은 2031년까지 연장했습니다. 올가을 팀 쿡이 물러나면 하드웨어 전문가 존 터너스가 지휘봉을 잡습니다.

가장 많이 소유한 회사가 가장 먼저 빌리기 시작했습니다

애플의 신화는 ‘전부 직접 만든다’였습니다. 칩과 운영체제와 기기와 스토어를 한 몸으로 묶어 통제력을 무기로 삼았습니다. 그 통제가 곧 우위였습니다. 그런데 생성형 AI 추론이라는 벽 앞에서, 가장 많이 소유해온 회사가 가장 먼저 소유를 내려놓기 시작했습니다. 자체 칩만으로는 대규모 추론 수요를 감당할 수 없다는 판단을, 다른 곳도 아닌 애플이 공개적으로 인정한 셈입니다.

여기서 더 흥미로운 대목은 중국입니다. 같은 날 애플은 중국 당국의 승인을 받아 현지 AI 서비스를 출시했는데, 탑재 모델이 구글이 아니라 알리바바의 큐원이었습니다. 지역에 따라 전혀 다른 회사의 모델을 얹어 규제를 통과한 것입니다. 미국에서는 제미나이, 중국에서는 큐원, 그리고 자체 칩은 구글 GPU로 대체합니다. 하나의 제품 안에 세 개의 서로 다른 공급자가 들어와 있습니다. 애플조차 이제는 무엇을 소유하느냐가 아니라, 소유하지 않은 것들을 어떻게 조합하고 다스리느냐로 경쟁의 축을 옮기고 있습니다.

물리 계층은 소유하려 하고, 지능 계층은 빌리려 합니다

같은 날 한국 뉴스는 정반대 방향으로 달렸습니다. SK텔레콤은 CEO 직속으로 ‘AI DC 통합추진단’을 신설했습니다. 정석근 CTO가 단장을 맡고 임원 16명이 사업개발과 엔지니어링 두 축으로 배치돼, 부지 선정부터 설계와 구축과 고객 확보까지 전 과정을 직접 관리합니다. 2029년부터 5GW로 시작해 2035년까지 최대 15GW로 키운다는 계획입니다. 데이터센터 시공 시장은 MW당 100억원을 넘기며 56조원 규모의 경쟁으로 열렸고, 정부의 ‘모두의 AI’ 사업은 엔비디아 B200을 최대 512장 지원하며 국산 모델 비중 80% 이상을 조건으로 걸었습니다. GIST는 750억원 규모의 AI 국가거점을 확보했습니다. 전력과 부지와 GPU라는 물리 계층을 저마다 ‘소유’하겠다는 경쟁입니다.

두 방향은 모순처럼 보이지만 사실 한 그림의 앞뒤입니다. 물리 계층, 즉 전기와 건물과 칩은 여전히 누가 얼마나 확보하느냐의 소유 싸움입니다. 반면 그 위에서 돌아가는 지능 계층, 즉 모델과 도구는 점점 빌려 쓰는 쪽으로 기웁니다. 애플이 제미나이와 큐원을 지역별로 갈아 끼우듯, 앞으로 대부분의 기업은 여러 모델과 도구를 상황에 맞게 섞어 쓰게 됩니다. 문제는 소유 계층을 아무리 두껍게 쌓아도, 그 위의 이종 스택을 다스리지 못하면 통제력은 사라진다는 점입니다.

인프라 계층에서도 같은 신호가 읽힙니다. 마이크로소프트는 3M과 손잡고 애저 데이터센터에 차세대 광연결 기술을 도입하기로 했습니다. GPU 클러스터를 아무리 크게 쌓아도 내부 대역폭에서 병목이 생기면 소유한 자원이 제 성능을 못 냅니다. 결국 물리 계층의 승부조차 ‘얼마나 많이 가졌나’에서 ‘가진 것을 얼마나 잘 잇고 다루나’로 옮겨가고 있습니다. 규모를 소유하는 일과 그 규모를 다스리는 일은 이제 별개의 역량입니다.

현장으로 내려온 AI는 저마다 남의 능력을 빌립니다

이 흐름은 실리콘밸리와 대형 통신사만의 이야기가 아닙니다. 오늘 국내 뉴스는 AI가 전통 산업의 현장으로 내려오는 장면을 여럿 담았습니다. 삼성물산은 새벽 2시에는 자율 지게차가 움직이고 해가 뜨면 로봇이 일하는 ‘AI 공사현장’을 그리고 있습니다. SK에코플랜트는 반도체와 AI 스타트업의 혁신 기술 6건을 선별해 사업화에 나섰고, GS네오텍은 구글 클라우드 행사에서 제미나이 엔터프라이즈를 기반으로 한 AX 전략을 제시했습니다.

이 사례들의 공통점은 분명합니다. 누구도 AI 능력을 스스로 처음부터 만들지 않습니다. 건설사는 로봇과 모델을 외부에서 들여오고, 대기업은 스타트업의 기술을 선별해 얹으며, MSP는 하이퍼스케일러의 모델을 자사 고객에 접목합니다. 각자 잘하는 본업 위에 남의 능력을 빌려 결합하는 방식입니다. 이때 승부를 가르는 것은 어떤 기술을 소유했느냐가 아니라, 빌려온 여러 조각을 자기 업무 흐름 안에서 얼마나 안전하고 일관되게 엮느냐입니다.

모델은 하나로 수렴하지 않습니다

빌려 쓰는 시대가 성립하려면 빌릴 대상이 여럿이어야 합니다. 그리고 오늘 뉴스는 모델 세계가 하나로 수렴하기는커녕 더 잘게 갈라지고 있음을 보여줍니다. 앤트로픽은 기업공개를 앞두고 오픈AI 대비 우위를 부각하며 프런티어 모델 벤더의 재편을 예고했습니다. 상하이에서 개막한 세계인공지능대회는 미중 경쟁 속에서 중국이 AI 자립을 과시하는 무대가 됐고, 기술 블록이 지역별로 나뉘는 흐름은 더 뚜렷해졌습니다.

한국의 ‘모두의 AI’ 사업은 이 파편화를 아예 규칙으로 못 박았습니다. 참여 기업은 자사 국산 모델을 50% 이상, 타사 국산 모델을 30% 이상 조합해 국산 비중을 80% 넘게 유지해야 합니다. 하나의 모델로 서비스를 채우는 것이 아니라, 여러 모델을 정해진 비율로 섞어야 사업 자격이 생기는 구조입니다. 게다가 발표평가에서 절반의 배점이 자체 모델 성능이 아니라 서비스 운영 역량에 걸려 있습니다. 무엇을 소유했느냐보다 빌려온 것들을 어떻게 운영하느냐를 국가가 먼저 평가 기준으로 삼은 셈입니다. 통신사와 포털과 AI 기업의 합종연횡이 활발한 것도, 혼자 모든 모델을 갖는 대신 서로의 능력을 엮으려는 움직임입니다.

통치는 새로운 역량입니다

빌려 쓰는 순간 세 가지 질문이 따라옵니다. 어떤 작업에 어떤 모델을 붙일 것인가, 그 작업이 넘지 말아야 할 선을 누가 지킬 것인가, 그리고 나중에 무엇이 왜 일어났는지 어떻게 증명할 것인가. 소유의 시대에는 이 질문들이 하나의 벽 안에 갇혀 있어 굳이 물을 필요가 없었습니다. 빌려 쓰는 시대에는 이 질문에 답하는 능력 자체가 곧 경쟁력이 됩니다. 소유가 아니라 통치입니다.

오늘 뉴스 속 국내 스타트업 리콘랩스의 젠프레소 개편이 이 변화를 작게 압축해 보여줍니다. 프롬프트와 사용 모델과 생성 결과를 맥락째 저장해 재사용 가능한 ‘스킬’로 축적하고, 자동 검수와 사람 승인 절차를 결합하며, 결과물에는 C2PA 서명을 붙입니다. 여러 모델을 갈아 끼우면서도 무엇을 썼고 누가 승인했는지 추적 가능하게 만드는 구조입니다. 리콘랩스가 “AI는 누구나 쓰지만 제작 문법은 자산”이라고 말한 이유가 여기에 있습니다. 규모는 다르지만 애플이 지역별로 모델을 바꾸며 마주한 과제와 본질이 같습니다. 이종 스택을 다스리는 문법이 곧 자산이 되는 것입니다.

세 번째 질문, 즉 나중에 무엇이 왜 일어났는지 증명하는 문제는 특히 무겁습니다. AI 포렌식 기업 유락의 유봉석 대표는 “증거는 현장에 있다”며 AI로 데이터의 무결성을 지키는 일을 강조했습니다. AI가 스스로 판단하고 실행하는 범위가 넓어질수록, 그 행위의 기록을 신뢰할 수 있게 남기는 일은 선택이 아니라 전제 조건이 됩니다. 빌려 쓰는 능력이 늘어날수록 감사 가능성은 통치의 마지막 자물쇠가 됩니다.

앤트로픽이 IPO를 앞두고 오픈AI 대비 우위를 부각한 것도, 상하이 세계인공지능대회에서 중국이 AI 자립을 과시한 것도 같은 흐름 위에 있습니다. 프런티어 모델은 여러 갈래로 나뉘고, 지역별 규제와 주권 요구는 더 강해집니다. 어느 한 모델에 전부를 맡길 수 있는 시대는 지나갑니다. 남는 질문은 늘 통치입니다. 흩어진 능력을 어떻게 안전하게 엮을 것인가.

ThakiCloud가 준비해온 자리

바로 이 지점이 ThakiCloud의 Agent-Native Cloud인 Paxis가 서 있는 자리입니다. Paxis는 Skills와 Tools와 Policies와 Audit Logs를 일급 리소스로 다룹니다. 오늘 뉴스가 드러낸 기업의 통증을 하나씩 짚어 보면 왜 이 구조가 필요한지가 선명해집니다.

먼저 비용입니다. 애플이 자체 칩과 임차 GPU 사이에서 저울질하듯, 모든 작업에 가장 비싼 모델을 붙이면 감당이 안 됩니다. 작업마다 알맞은 모델을 고르는 CostRouter는 제미나이와 큐원을 지역별로 갈아 끼우는 애플의 선택을 조직 차원의 정책으로 만들어 줍니다. 다음은 안전한 실행입니다. L0부터 L3까지의 자율도 다이얼과 정책 게이트는 에이전트가 넘지 말아야 할 선을 코드로 못 박고, 격리 샌드박스는 빌려온 도구의 실행을 안전하게 가둡니다. 삼성물산의 현장 로봇처럼 실물을 움직이는 자동화일수록 이 경계는 더 엄격해야 합니다. 그리고 감사입니다. 유락 대표가 강조한 무결성처럼, 모든 실행은 감사 로그로 남아 나중에 무엇이 왜 일어났는지 증명합니다. 마지막으로 주권입니다. MCP 커넥터와 스킬 마켓은 빌려 쓰는 능력을 한곳에서 엮고, 소버린과 온프렘 K8s 위에서 돌아가므로 물리 계층의 주권을 지키려는 국내 수요와도 맞물립니다.

애플이 남의 칩과 남의 모델 위에서 자기 서비스를 돌리는 오늘의 풍경은, 앞으로 대부분의 기업이 마주할 내일입니다. 무엇을 소유했느냐로는 더 이상 우위가 갈리지 않습니다. 빌려온 것들을 얼마나 잘 다스리느냐가 다음 승부를 가릅니다.

SKT가 15GW를 향해 달리고 정부가 512장의 GPU를 나누는 소유의 경쟁은 이미 뜨겁습니다. 그러나 그 위에서 여러 모델과 도구를 안전하게 엮어 낼 통치의 역량은 아직 대부분의 조직에 준비돼 있지 않습니다. 애플조차 이제 막 그 문제와 씨름하기 시작했습니다. 먼저 통치의 골격을 갖춘 쪽이 소유의 경쟁에서도 자기 자원을 제값으로 굴리게 됩니다. 통치의 준비는 지금 시작할 때입니다.