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

نظرة عامة

وسّعت Anthropic نطاق Claude Code من مجرّد واجهة سطر أوامر تفاعلية إلى بيئة تشغيل أتمتة. يتتبّع هذا المسارَ الإعلانُ المرتبط (“Enabling Claude Code to work more autonomously”)، ومقالة تصميم الوضع التلقائي (“How we built Claude Code auto mode”)، ومدوّنة التوجيه (“Steering Claude Code”). الرسالة الجوهرية واحدة: تشغيل Claude Code ذاتياً ليس مسألة انتظار نموذج أذكى، بل مسألة كيف تصمّم التجهيزة المحيطة به.

تتوافق هذه الرؤية تماماً مع مبدأ ThakiCloud التشغيلي: القدرة لا تأتي من النموذج نفسه بل من بنية العقد المحيطة به، أي موجّه النظام وتعريفات الأدوات وبوابات التحقّق وقواعد التوجيه. والمحاور الأربعة أدناه هي الأجزاء التي تشكّل تلك التجهيزة.

المشكلة: وكلاء يحتاجون إنساناً في كل مرة

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

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

1. الوضع الرأسي: نفّذ مرةً واحدة دون إنسان

يشغّل الوضع الرأسي Claude Code كعملية سطر أوامر واحدة دون TTY. استدعِه بصيغة claude -p "<موجَّه>" فينفّذ المهمة ويخرج، دون محادثة. تتيح هذه الخاصية البسيطة تكاملات غير مراقَبة مثل المهام المجدولة وأنابيب CI وفحوص ما قبل الالتزام. والأهمّ أن الوضع الرأسي يعيد استخدام الإعدادات والخطّافات وقواعد الأذونات نفسها الخاصة بالواجهة التفاعلية. أي إن تجهيزة تحقّقت منها تفاعلياً تنتقل مباشرةً إلى بيئة غير مراقَبة.

تشغّل ThakiCloud هذا على نطاق واسع بالفعل. فتحت scripts/launchd/ يوجد 35 ملف launchd plist، يستدعي كلٌّ منها مشغّل مهارة عبر claude -p في وقت محدّد. والأنبوب نفسه الذي يُنتج هذا المقال هو مثال على مشغّل رأسي. فالتدفّق كلّه، من سحب مرشّحي المدوّنة من الخطّ الزمني في تويتر إلى طابور، وصياغة كلٍّ منها، وتمريرها عبر بوابات التحقّق، وصولاً إلى النشر، يجري دون تدخّل إنسان في كل خطوة.

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

2. الخطّافات: تحكّم حتمي بدورة الحياة

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

يربط .claude/hooks/ في ThakiCloud 12 خطّافاً. يحقن خطّاف بدء الجلسة التعلّم السابق كموجز مقيم كي لا تبدأ كل جلسة من صفحة بيضاء. ويطفو خطّاف تقديم الموجَّه مرشّحي المهارات ذوي الصلة تلقائياً بعد تحليل الطلب. ويكتشف خطّاف الخروج ملف علَم ويشغّل المعالجة اللاحقة اللازمة، مثل تصريف مرشّحي المدوّنة المتراكمين في الطابور أو إعادة تجميع قاعدة المعرفة. وهذا الخطّاف الأخير خصوصاً يستخدم نمطاً تتقارب فيه الكلفة إلى صفر إن غاب العلَم، ويشغّل العمل الثقيل فقط عند وجوده. وإطلاق العمل المكلف فقط بعد دور مُنتِج، لا في كل دور، محوريٌّ في التحكّم بكلفة أنبوب ذاتي.

3. الوكلاء الفرعيون: تفويض خبير معزول

الوكلاء الفرعيون مساعدون معزولون لمهام محدّدة. تعرّفهم كملفات markdown تحت .claude/agents/، محدّداً النموذج المستخدَم ونطاق الوصول للأدوات إلى جانب اسم ووصف. يمكن للوكيل الرئيسي بناء الواجهة الأمامية بينما يقيم وكيل فرعي واجهة API الخلفية بالتوازي. العزل مهمّ لسببين: يركّز الوكيل الفرعي على مهمته وحدها دون تلويث السياق الرئيسي، ويعيد ملخّص نتيجته فقط.

تعرّف ThakiCloud 63 وكيلاً فرعياً متخصّصاً وتستدعيها حسب طبيعة المهمة. ويُضاف فوق ذلك توجيه النموذج. فالعمل الخفيف مثل الاستكشاف والبحث وقراءة الملفات يذهب إلى haiku؛ والتنفيذ والمراجعة وكتابة الاختبارات إلى sonnet؛ وقرارات المعمارية والاستدلال المتعدّد الخطوات المعقّد إلى opus. من دون هذا التوجيه، يعمل كل وكيل فرعي على نموذج الجلسة الافتراضي وتنفجر الكلفة. في تجهيزة ذاتية، الوكلاء الفرعيون ليسوا مجرّد أداة توازٍ بل أيضاً أداة تحكّم بالكلفة تختار نقطة الكلفة-الجودة المناسبة لكل مهمة.

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

4. المهارات: خبرة تُحمَّل عند الحاجة فقط

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

يضمّ .claude/skills/ في ThakiCloud 1751 مهارة. عند هذا الحجم، أيّ مهارة تُستدعى ومتى هو ما يحدّد الجودة. لذلك يربط موجِّه الطلبات باللغة الطبيعية بمرشّحي المهارات عبر بحث معجمي من صنف BM25 ويطفو المرشّحين الأعلى فقط إلى السياق. فبتجاوز 1700 مهارة، لا يستطيع إنسان انتقاء كلٍّ منها، فمن دون خطوة تضييق المرشّحين هذه يصبح نظام المهارات نفسه ضجيجاً. المهارة ليست موجَّهاً بل منتَج قدرة مُدار الإصدارات، يتمايز عن الموجَّه العادي بأنه يُعاد استخدامه عبر تجهيزات متعددة.

دلالات لـ ThakiCloud

هذا الموضوع هو تنسيق الوكلاء بعينه، فعدسة Paxis تناسب مباشرةً. Paxis هو مستوى التحكّم Agent-Native Cloud لدى ThakiCloud، يعامل Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. وتتطابق المحاور الأربعة أعلاه واحداً لواحد مع القدرات التي يهدف Paxis لتوفيرها على مستوى المنتج. يتطابق التنفيذ الرأسي مع تشغيلات غير مراقَبة مجدولة بـ NL Cron، والخطّافات مع بوابات السياسة وسجلّات التدقيق، والوكلاء الفرعيون مع تنسيق DAG متعدّد الوكلاء، والمهارات مع Skill Harness الذي يختار بين أكثر من 960 مهارة عبر BM25.

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

على جانب البنية التحتية، تناسب عدسة ai-platform أيضاً. فالمشغّلات الرأسية وتوسّع الوكلاء الفرعيين هي في النهاية أحمال تعمل على K8s، واستدعاءات haiku وsonnet وopus المدفوعة بتوجيه النموذج تتحوّل إلى كلفة خدمة. ولا تصمد اقتصاديات تشغيل الوكلاء الذاتيين باستمرار (Paxis) إلا مع أساس خدمة منخفض الكلفة (ai-platform).

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

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

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

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

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

المصادر

• Enabling Claude Code to work more autonomously (Anthropic)
• How we built Claude Code auto mode (Anthropic Engineering)
• Steering Claude Code: skills, hooks, rules, subagents and more (مدوّنة Claude)
• claude-code-action (GitHub, Anthropic)

نظرة عامة: من سباق الاختبارات المعيارية إلى سباق الجدوى الاقتصادية

طوّرت SpaceXAI، إحدى شركات مجموعة xAI، نموذج Grok 4.5، وهو متاح فوراً عبر Grok Build وCursor وكونسول xAI. وصف إيلون ماسك هذا النموذج بأنه “نموذج بمستوى Opus”، وقد تفوّق فعلاً على Opus 4.8 وGPT-5.5 في بعض الاختبارات. لكن أبرز ما يميز هذا الإصدار ليس الأداء بل جدول الأسعار. يبلغ سعر Grok 4.5 دولارين لكل مليون رمز إدخال، وستة دولارات لكل مليون رمز إخراج. وبالمقارنة مع GPT-5.5 وGPT-5.6 اللذين يُصنّفان في فئة مماثلة بسعر خمسة دولارات للإدخال و30 دولاراً للإخراج، يصبح Grok 4.5 أرخص بنحو خمس المرات من حيث تكلفة الإخراج.

يتضح سبب أهمية هذا الهيكل السعري عند النزول إلى مستوى وحدة العمل الفعلية. تحمل نتائج الاختبارات المعيارية معنى على لوحات الصدارة، لكن ما يحدد الفاتورة فعلياً هو عدد الرموز المستهلكة فعلاً لكل مهمة مضروباً في سعر الوحدة. وهنا بالتحديد يوسّع Grok 4.5 الفجوة بشكل كبير.

ما هو هذا النموذج: أداء متقارب وتكلفة متباعدة

لنكن صريحين بشأن الأداء أولاً. لا يتفوّق Grok 4.5 في كل الاختبارات المعيارية. فيما يلي الأرقام المعلنة كما وردت:

• في اختبار Terminal Bench 2.1، سجّل Grok 4.5 نسبة 83.3 بالمئة، وهي متساوية تقريباً مع نسبة GPT-5.5 البالغة 83.4 بالمئة.
• في مؤشر Coding Agent Index، سجّل 76 نقطة، وهو مستوى مطابق لـ GPT-5.5 عند تشغيله في بيئة Codex.
• في اختبار DeepSWE 1.1، سجّل 53 بالمئة، متأخراً بفارق كبير عن نسبة GPT-5.5 البالغة 67 بالمئة.
• في مؤشر الذكاء الخاص بـ Artificial Analysis، سجّل 54 نقطة، وهو رقم قريب من نقاط GPT-5.5 البالغة 55.

باختصار، يقف Grok 4.5 نداً لأفضل النماذج في مهام البرمجة ووكلاء الطرفية، لكنه ما زال متأخراً في المهمة الهندسية البرمجية الصعبة الممثلة باختبار DeepSWE. أي أن Grok 4.5 ليس “النموذج الذي يتفوّق على الجميع”، بل هو “النموذج الذي ينجز معظم المهام العملية قريباً من القمة”.

وهنا يدخل عنصر الجدوى الاقتصادية إلى المشهد. فيما يلي الأرقام المعلنة لمهمة وكيلية فعلية واحدة:

• تكلفة المهمة الواحدة: 2.49 دولار لـ Grok 4.5 على Grok Build، مقابل 5.07 دولار لـ GPT-5.5 على Codex.
• متوسط الرموز المستهلكة لكل مهمة: 1.9 مليون رمز لـ Grok 4.5، مقابل 6.2 مليون رمز لـ GPT-5.5.

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

flowchart TB
  T["مهمة وكيلية واحدة"] --> R{"اختيار النموذج"}
  R -->|"Grok 4.5"| G["1.9 مليون رمز<br/>تكلفة 2.49 دولار"]
  R -->|"GPT-5.5"| P["6.2 مليون رمز<br/>تكلفة 5.07 دولار"]
  G --> S["أداء متقارب<br/>تفوّق في بعض الاختبارات"]
  P --> S
  S --> D["القرار العملي:<br/>النتيجة نفسها بنصف التكلفة"]

لماذا يهم هذا التوجه الآن

الإشارة التي يحملها هذا الإصدار بسيطة. مع تقارب أداء النماذج المتقدمة نحو سقف مشترك، ينتقل معيار اختيار النموذج من “الأذكى” إلى “الذكاء الكافي بأقل تكلفة”. وكما أشارت The Decoder، فحين تضيق الفجوة في الاختبارات المعيارية إلى هذا الحد، قد تفقد الفجوة نفسها أهميتها في الاختيار العملي.

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

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

الأثر على منتجات ThakiCloud

منصة ai-platform التابعة لـ ThakiCloud هي منصة استدلال متعددة المستأجرين، تخدم النماذج لبيئات عملاء متنوعة فوق جدولة موارد GPU المبنية على K8s وKueue. ويحمل إصدار مثل Grok 4.5 دلالة على مستويين بالنسبة لنا.

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

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

أما المستوى الثالث فيتصل بمنظور الوكلاء عبر Paxis. Paxis هي مستوى التحكم الخاص بالسحابة الأصلية للوكلاء (Agent-Native Cloud) الذي يعمل فوق ai-platform، وينفّذ المهارات في بيئات معزولة، ويمرّر كل إجراء عبر بوابات سياسات وسجلات تدقيق. وتنحصر جدوى الوكلاء الاقتصادية في النهاية بـ “تكلفة النموذج اللازمة لإنجاز مهمة واحدة”، وظهور نموذج منخفض التكلفة وعالي الكفاءة يحسّن مباشرة الميزانية التشغيلية لكل تدفق عمل وكيلي. وهذا يؤكد مجدداً الفرضية القائلة إن الاستضافة الرخيصة هي ما يصنع جدوى اقتصادية للوكلاء.

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

قبل الانجراف نحو التفاؤل المطلق، لا بد من النظر إلى الجانب الآخر. أولاً، معظم هذه الأرقام صادرة عن الشركة المزوّدة وعن جهات تحليل مبكّرة. ومعايير مثل Terminal Bench أو Coding Agent Index لا ترتبط ارتباطاً كاملاً بأعباء العمل الإنتاجية الفعلية. وكما توضّح الفجوة بين 53 بالمئة و67 بالمئة في اختبار DeepSWE 1.1، ما زالت النماذج الأعلى تحتفظ بتفوّقها في المهام الصعبة. وإذا دُفعت المهام الاستدلالية الصعبة نحو نموذج رخيص لمجرد رخص سعره، فقد ترتفع تكلفة إعادة المحاولة واستعادة الفشل إلى درجة تقلب المعادلة الإجمالية للتكلفة.

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

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

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

المصادر

• Introducing Grok 4.5 · Cursor
• SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’ · TechCrunch
• Grok 4.5 is so cheap compared to Fable 5 and GPT 5.5 that benchmark gaps may not matter much · The Decoder
• Grok 4.5 (high): Intelligence, Performance & Price Analysis · Artificial Analysis

نظرة عامة: تحول جيلي في تجربة الصوت الافتراضية

GPT-Live نموذج صوتي من جيل جديد يحل محل تجربة الصوت الافتراضية في ChatGPT. جوهره بنية الاتصال الثنائي الكامل (full-duplex). فإذا كان وضع الصوت السابق نصف ثنائي، أي يستمع ثم يتحدث، فإن GPT-Live يستطيع الاستماع والحديث في الوقت نفسه. فبينما يتحدث المستخدم، يعبّر النموذج عن أنه يستمع بردود تفاعلية قصيرة مثل “همم” أو “نعم”، ويشارك في تبادل سريع للحديث، وينتظر بصمت حين يحتاج الطرف الآخر إلى وقت للتفكير. وتصف OpenAI هذه التجربة بأنها أقرب بكثير إلى محادثة حقيقية مع شخص آخر.

ينقسم الطرح إلى نسختين. GPT-Live-1 هو الافتراضي لمستخدمي Go وPlus وPro، بينما GPT-Live-1 mini هو الافتراضي للمستخدمين المجانيين. وقد بدأ طرح كلا النموذجين تدريجيًا لمستخدمي ChatGPT حول العالم على iOS وأندرويد والويب.

ما الذي تغير تقنيًا بالفعل

التغيير الأكبر يكمن في طريقة التعامل مع المحور الزمني للمحادثة. تعتمد أنظمة الصوت نصف الثنائية على كشف نهاية الدور (end-of-turn detection): حين يقرر النظام أن المستخدم توقف عن الكلام، يبدأ عندها فقط في توليد الرد. هذا الأسلوب بسيط في التنفيذ، لكنه لا يستطيع التعبير عن التداخل الطبيعي والمقاطعة والردود التفاعلية القصيرة التي تحدث في المحادثة الحقيقية.

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

من التصاميم اللافتة أيضًا آلية التفويض (delegation). يُقدَّم GPT-Live بوصفه أذكى نموذج صوتي حتى الآن، لكن الأسئلة التي تحتاج إلى بحث على الويب أو استدلال أعمق أو مهام معقدة تُحال في الخلفية إلى أحدث نموذج متقدم (frontier model). وحين تجهز النتيجة، تُعاد إلى مسار المحادثة. بعبارة أخرى، هذه بنية طبقية: نموذج صوتي سريع وخفيف يتولى الطابع الفوري للمحادثة، بينما يعالج نموذج منفصل الاستدلال الثقيل بشكل غير متزامن.

flowchart TB
  U["صوت المستخدم<br/>تدفق إدخال مستمر"] --> L["GPT-Live<br/>نموذج صوتي ثنائي الاتجاه كامل"]
  L -->|"رد فوري، رد تفاعلي قصير، صمت"| U
  L --> Q{"هل يلزم<br/>استدلال عميق؟"}
  Q -->|"نعم"| F["نموذج متقدم<br/>تفويض غير متزامن"]
  Q -->|"لا"| L
  F -.إعادة النتيجة.-> L

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

دلالات التطبيق على منتجات ThakiCloud

GPT-Live نفسه منتج مغلق تابع لـ OpenAI، لكن المتطلبات التي تفرضها بنيته ترتبط مباشرة بالبنية التحتية التي نشغّلها.

من منظور ai-platform، يمثل الصوت ثنائي الاتجاه الكامل حالة صعبة من حالات الاستدلال الفوري المتدفق (streaming inference). تشغّل منصة ai-platform التابعة لـ ThakiCloud نطاقًا واسعًا من النماذج فوق جدولة GPU القائمة على K8s وKueue، وبخلاف الاستدلال الدفعي (batch inference)، تتطلب المحادثة الصوتية زمن استجابة منخفضًا وثابتًا. والتعامل مع تدفقات صوتية ثنائية الاتجاه في الوقت نفسه يتطلب من طبقة الخدمة أن تحافظ على استقرار الإدخال والإخراج المتدفقين وحالة الجلسة، كما يتطلب من موارد GPU إدارة ليس فقط الإنتاجية بل أيضًا زمن الاستجابة الأقصى (tail latency). هذا المتطلب المتعلق بزمن الاستجابة المنخفض مهم بوجه خاص في البيئات المحلية (on-premise) والسيادية. فالعملاء الذين لا يستطيعون إرسال بياناتهم إلى الخارج ويريدون تشغيل واجهة صوتية باستضافة ذاتية (self-hosting) يحتاجون، كشرط أساسي، إلى حزمة خدمة قادرة على التعامل مع البث الفوري.

من منظور الوكلاء، يرتبط الأمر بـ Paxis. Paxis هو مستوى التحكم الخاص بـ Agent-Native Cloud الذي يعمل فوق ai-platform، حيث يشغّل المهارات (skills) داخل بيئات معزولة (sandboxes) ويمرر كل إجراء عبر بوابات سياسات وسجلات تدقيق. وبنية التفويض في GPT-Live، أي أن الطبقة الأمامية الخفيفة تحيل الاستدلال الثقيل إلى الخلف، تتبع المبدأ نفسه الذي تقوم عليه طبقية تصميم الوكلاء. وحين يصبح الصوت واجهة إدخال جديدة للوكلاء، نحتاج إلى مسار يفسر ما قصده المستخدم، ويختار المهارة المناسبة، وينفذها بمعزل، ثم يعيد النتيجة إلى المحادثة. ويمكن لبنية المهارات وموصلات MCP وبوابات السياسات في Paxis أن تتولى بالضبط هذا الجزء الخلفي من خط أنابيب الوكيل الصوتي: الصوت الفوري يتولى الواجهة الأمامية، بينما تنفيذ الوكيل المضمون بسياسات وتدقيق يتولى الخلفية.

القيود ووجهات النظر المضادة

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

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

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

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

المصادر

• Introducing GPT-Live · OpenAI
• OpenAI releases new voice models for more natural live conversations · TechCrunch
• OpenAI Introduces GPT-Live to Make ChatGPT Voice Feel Like a Real Conversation · MacRumors

تصوير لإدارة ذاكرة موحّدة تتلاقى فيها عمليات التخزين والاسترجاع والتلخيص والحذف في فضاء أفعال واحد.

نظرة عامة

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

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

المشكلة: كلفة الذاكرة المفصولة

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

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

الذاكرة كفضاء للأفعال: الفكرة الجوهرية في AgeMem

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

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

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

التدريب: تعلّم معزّز تدريجي ثلاثي المراحل وstep-wise GRPO

التحدي هو كيفية تدريب مثل هذا السلوك الموحّد. عمليات الذاكرة أفعال ذات مكافآت شائكة. فصواب قرار تخزين شيءٍ ما لا ينكشف إلا لاحقاً بكثير، عند اللحظة التي تُحتاج فيها تلك المعلومة فعلاً مجدداً. تصل المكافآت متفرّقة (sparse)، والفجوة بين الفعل والمكافأة متقطّعة (discontinuous). وهذه ظروف لا يعالجها التعلّم المعزّز القياسي جيداً.

يستجيب AgeMem بآليتين. الأولى استراتيجية تعلّم معزّز تدريجي ثلاثي المراحل لا تدرّب سلوكيات الذاكرة الموحّدة دفعةً واحدة بل ترفعها على مراحل. والثانية step-wise GRPO. فبتصميم GRPO (Group Relative Policy Optimization) على مستوى الخطوة، يواجه مباشرةً المكافآت المتفرّقة والمتقطّعة التي تحدثها عمليات الذاكرة. ويمكن فهمه كنهج يفكّك المكافأة المؤجّلة إلى إسهام كل خطوة، ما يجعل إشارة التعلّم أكثف.

هذا الجزء مثير للاهتمام من زاوية ThakiCloud أيضاً. فبالنسبة لفريق يشغّل بنية تدريب RL post-training مباشرةً، لا يعمل مثل هذا الشكل المخصّص من GRPO إلا إذا دعم إطار التدريب بمرونة تشكيل المكافأة وحساب الأفضلية على مستوى الخطوة. أي إن منهجية الورقة تُترجَم مباشرةً إلى متطلبات على أنبوب التدريب.

النتائج والدلالة

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

تستحقّ الأرقام المحدّدة حذراً. فقد وصفت ملخّصات ثانوية متوسط الدرجة على نواة Qwen2.5-7B بأنه أعلى بوضوح من خطوط أساس من صنف Mem0، مع اتّساع الفجوة على الأنوية الأصغر [تقديري]. لكن لأن تلك الأرقام لم تُعَد التحقّق منها مقابل المصدر الأصلي، ننصح بمراجعة الدرجات الدقيقة لكل معيار في الرابط الأصلي أدناه. وما يمكننا تأكيده بثقة هو المنهجية والخلاصة النوعية: أفضلية متّسقة عبر خمسة معايير وأنوية متعددة، وأن الأفضلية ظهرت لا في أداء المهمة فحسب بل في جودة الذاكرة وكفاءة السياق أيضاً.

وفي سياق المنظومة، صارت أنظمة ذاكرة الوكلاء ساحة تنافس محتدم في 2026. فقد أبرز Mem0 درجات نحو 67.13 بالمئة على أساس LLM-as-a-Judge على معيار الذاكرة الحوارية طويلة المدى LOCOMO مع زمن بحث منخفض، وتتفاخر أنظمة مثل Zep وLetta بنقاط قوتها. يكمن تميّز AgeMem لا في تنافس أداء على مستوى المكوّنات بل في تحوّل تأطيري يعيد تعريف إدارة الذاكرة كمشكلة تعلّم سياسة.

دلالات لـ ThakiCloud

تقدّم هذه الورقة دلالات عبر عدسة البنية التحتية وعدسة الوكيل معاً. ولأن الموضوع هو ذاكرة الوكيل، فعدسة Paxis محورية، لكن عدسة ai-platform تناسب أيضاً على جانب بنية تدريب RL.

Paxis هو مستوى التحكّم Agent-Native Cloud لدى ThakiCloud، يعامل Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. ومن بينها، يقع محرّك المعرفة (HKE wiki) وطبقة الذاكرة تماماً على المشكلة التي يلمسها AgeMem. وكما لدى منصّات وكلاء كثيرة اليوم، يدير Paxis الذاكرة في طبقات، والسؤال الذي يطرحه AgeMem واضح: هل يمكن معالجة الحركة بين تلك الطبقات، أي ما يُرقّى من ذاكرة الجلسة إلى المعرفة طويلة المدى وما يُحذَف، بحكم متعلَّم بدل قواعد ثابتة؟ إن تصميماً يكشف التخزين والاسترجاع والتلخيص والحذف كأفعال أدوات ينسجم طبيعياً مع بنية Paxis التي تعامل المهارات والأدوات أصلاً كموارد من الدرجة الأولى. وبمعاملة عمليات الذاكرة كفعل آخر خاضع لبوابات السياسة وسجلّات التدقيق، تكسب قابلية تتبّع ما تذكّره الوكيل ونسيه.

على عدسة ai-platform، بنية التدريب هي الجوهر. فتشغيل شكل مخصّص من RL مثل step-wise GRPO فعلياً يتطلّب أنبوب تدريب يدعم تشكيل المكافأة وحساب الأفضلية على مستوى الخطوة فوق جدولة GPU المبنية على Kueue. توفّر ai-platform من ThakiCloud الأساس لتشغيل أحمال RL post-training هذه في بيئة K8s متعددة المستأجرين. ومكاسب كفاءة السياق التي تبرزها الورقة ترتبط مباشرةً بكلفة خدمة vLLM، فالخدمة منخفضة الكلفة (ai-platform) تسند اقتصاديات الوكلاء (Paxis).

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

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

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

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

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

المصادر

• Agentic Memory: Learning Unified Long-Term and Short-Term Memory Management for Large Language Model Agents (arXiv:2601.01885)
• صفحة Hugging Face Papers (2601.01885)
• Mem0 AI Memory Benchmarks 2026 (سياق LOCOMO)

A rendering of four axes, headless, hooks, subagents, and skills, overlapping into an autonomous harness that runs without a human.

Overview

Anthropic has extended Claude Code beyond an interactive CLI into an automation runtime. The related announcement (“Enabling Claude Code to work more autonomously”), the auto-mode design piece (“How we built Claude Code auto mode”), and the steering blog (“Steering Claude Code”) trace that flow. The core message is singular: running Claude Code autonomously is not a matter of waiting for a smarter model, but a question of how you design the surrounding harness.

That view lines up exactly with ThakiCloud’s operating principle: capability comes not from the model itself but from the contract structure wrapping it, the system prompt, tool definitions, verification gates, and routing rules. The four axes below are the parts that make up that harness.

The Problem: Agents That Need a Human Every Time

The limits of a single-shot response agent are clear. As soon as a task grows even a little, a human has to stand in for the judgment and approval at every step, and even repetitive work must be triggered by hand each time. What is needed here is three things. First, a way to start and finish execution once, without a human. Second, a way to force a certain action to always happen at a certain point. Third, a way to divide complex work among specialized workers and let each pull in only the knowledge it needs. The four axes each satisfy one of these demands.

The four axes overlap into one autonomous harness. Headless opens execution, hooks enforce the lifecycle, subagents divide the work, and skills supply expertise on the fly.

1. Headless Mode: Execute Once, Without a Human

Headless mode runs Claude Code as a single CLI process without a TTY. Invoke it as claude -p "<prompt>" and it performs the task and exits, without a conversation. This simple property enables unattended integrations like scheduled jobs, CI pipelines, and pre-commit checks. Crucially, headless mode reuses the same settings, hooks, and permission rules as the interactive CLI. In other words, a harness you validated interactively transfers directly to an unattended environment.

ThakiCloud already operates this broadly. Under scripts/launchd/ there are 35 launchd plists, each invoking a skill runner via claude -p at a set time. The very pipeline that produces this blog post is one example of a headless runner. The whole flow, pulling blog candidates from the Twitter timeline into a queue, drafting each, passing it through verification gates, and going all the way to deployment, proceeds without a human intervening at each step.

The one thing you must handle in unattended execution is authentication. Rather than committing a metered API key to disk, keep a subscription OAuth token in a separate file that the runner loads, which is safer. Anthropic’s docs likewise recommend, for unattended environments, using a helper that pulls the API key from a secret manager. Design the auth path for an unattended premise from the start, so the convenience of automation does not leak into secret exposure.

2. Hooks: Deterministic Lifecycle Control

Hooks run code at specific points in Claude Code’s lifecycle. Auto-formatting after a file edit, linting before a commit, injecting context at session start, post-processing at exit: they force actions that must happen rather than leaving them to the model’s choice. The value of hooks is in determinism. Instead of the model deciding on a whim whether to run something, a rule-fixed action always occurs.

ThakiCloud’s .claude/hooks/ wires in 12 hooks. The session-start hook injects prior learning as a resident brief so each session does not begin from a blank slate. The prompt-submission hook analyzes the request and automatically surfaces relevant skill candidates. The exit hook detects a flag file and runs needed post-processing, such as draining queued blog candidates or recompiling the knowledge base. This exit hook in particular uses a pattern where cost converges to zero if the flag is absent, running heavy work only when the flag is present. Triggering expensive work only right after a producer turn, rather than every turn, is central to controlling the cost of an autonomous pipeline.

3. Subagents: Isolated Expert Delegation

Subagents are isolated assistants for specific tasks. You define them as markdown files under .claude/agents/, specifying the model to use and tool-access scope alongside a name and description. The main agent can build the frontend while a subagent stands up the backend API in parallel. Isolation matters for two reasons: a subagent focuses only on its own task without polluting the main context, and returns only a summary of its result.

ThakiCloud defines 63 specialized subagents and calls them by task nature. Model routing is layered on top. Lightweight work like exploration, search, and file reading goes to haiku; implementation, review, and test writing to sonnet; architecture decisions and complex multi-step reasoning to opus. Without this routing, every subagent runs on the session default model and cost explodes. In an autonomous harness, subagents are not merely a parallelization tool but also a cost-control device that picks the right cost-quality point per task.

To add one discipline: before merging the results of a fanned-out subagent, you must close the loop with a verification stage. If you launched several parallel agents, run an adversarial verification once rather than merging results straight to the user. A fanout without a verification gate accumulates hallucination.

4. Skills: Expertise Loaded Only When Needed

Skills package a reusable expert workflow. They bundle domain knowledge, templates, verification scripts, and failure cases, loading only when a request triggers them. The key is that they are not always loaded. Keeping them resident in every session’s context pays a continuous token cost, but loading on demand supplies expertise only at the moment it is needed.

ThakiCloud’s .claude/skills/ holds 1,751 skills. At that scale, which skill to call when is what determines quality. So a router maps natural-language requests to candidate skills via BM25-style lexical search and surfaces only the top candidates into context. Past 1,700 skills, a human cannot pick each one, so without this candidate-narrowing step the skill system itself becomes noise. A skill is not a prompt but a version-controlled capability product, distinct from a plain prompt in that it is reused across multiple harnesses.

Implications for ThakiCloud

This subject is agent orchestration itself, so the Paxis lens fits head-on. Paxis is ThakiCloud’s Agent-Native Cloud control plane, treating Skills, Tools, Policies, and Audit Logs as first-class resources. The four axes above map one-to-one onto the capabilities Paxis aims to provide at the product level. Headless execution maps to unattended runs scheduled by NL Cron, hooks to policy gates and audit logs, subagents to DAG multi-agent orchestration, and skills to the Skill Harness that selects among 960-plus skills via BM25.

The point is that Paxis unifies the four axes Anthropic introduces as individual features into one control plane and productizes them. It takes the headless runners, hooks, routing, and skill selection that individual developers wired by hand, and lifts them into a governable form wrapped in isolated-sandbox execution, policy gates, and audit logs. For domestic customers demanding on-premise and sovereign environments, that governance layer is especially important. Only when everything an autonomous agent executed and every secret it accessed remains in audit logs can you actually turn autonomy on in a regulated environment.

On the infrastructure side, the ai-platform lens fits too. Headless runners and subagent fanout are ultimately workloads running on K8s, and the haiku, sonnet, and opus calls driven by model routing convert into serving cost. Only with a low-cost serving foundation (ai-platform) does the economics of running autonomous agents continuously (Paxis) hold.

Limitations and Counterarguments

You must face the fact that as you raise autonomy, the burden of control and verification grows. First, headless unattended execution risks silently accumulating failures. Because no human watches, problems like auth expiry or quota overrun can hit multiple runners at once. Without post-processing that detects failure immediately and sends an alert, autonomy quickly turns into silent breakage.

Second, poorly designed hooks and routing make per-turn cost grow linearly. If always-loaded rules bloat, or you put polling work into the agent’s hot loop, autonomy comes back as a cost explosion. Repetitive monitoring belongs in cron, not in the agent, as a principle.

Third, do not forget that automation is a tool that assists thinking, not replaces it. The deeper the loop, the more humans tend to trust results and stop reviewing. Core outputs must be sampled and reviewed periodically by a human, and verification gates must be designed to refute rather than to pass. A verifier that filters out nothing should be treated as a failure signal.

In conclusion, autonomous execution of Claude Code comes not from a stronger model but from a well-designed harness. The four axes, headless, hooks, subagents, and skills, respectively handle execution, enforcement, division of labor, and expertise supply, and only when wrapped in verification gates and audit logs do they become autonomy you can switch on even in a regulated environment.

Sources

• Enabling Claude Code to work more autonomously (Anthropic)
• How we built Claude Code auto mode (Anthropic Engineering)
• Steering Claude Code: skills, hooks, rules, subagents and more (Claude blog)
• claude-code-action (GitHub, Anthropic)

Overview: From a Benchmark Race to an Economics Race

Grok 4.5 comes from SpaceXAI, part of the xAI family, and is available immediately through Grok Build, Cursor, and the xAI console. Elon Musk called it an “Opus-class model,” and on several benchmarks it does edge out Opus 4.8 and GPT-5.5. But the most striking part of this release is not the performance, it is the price tag. Grok 4.5 costs $2 per million input tokens and $6 per million output tokens. Compare that to GPT-5.5 and GPT-5.6, priced at $5 input and $30 output for a comparable tier, and Grok 4.5 comes in at roughly a fifth of the output cost.

Why this pricing structure matters becomes clear once you break it down to the level of an actual unit of work. Benchmark scores mean something on a leaderboard, but what determines the invoice is tokens actually consumed per task, multiplied by the unit price. And this is exactly where Grok 4.5 opens up a large gap.

What This Model Is: Performance Close, Cost Far Apart

Let’s be honest about performance first. Grok 4.5 does not lead on every benchmark. Here are the published numbers as reported:

• On Terminal Bench 2.1, Grok 4.5 scores 83.3%, essentially tied with GPT-5.5’s 83.4%.
• On the Coding Agent Index, it scores 76, matching GPT-5.5 running in the Codex environment.
• On DeepSWE 1.1, it scores 53%, well behind GPT-5.5’s 67%.
• On Artificial Analysis’s Intelligence Index, it scores 54, close to GPT-5.5’s 55.

In short, Grok 4.5 stands shoulder to shoulder with top-tier models on coding and terminal-agent work, but still trails on the harder software engineering benchmark (DeepSWE). Grok 4.5 is not “the model that beats everything.” It is “the model that handles most real-world tasks near the top tier.”

This is where economics enters the picture. Below are the published numbers for a single real agentic task.

• Cost per task: $2.49 for Grok 4.5 on Grok Build, versus $5.07 for GPT-5.5 on Codex.
• Average tokens consumed per task: 1.9 million for Grok 4.5, versus 6.2 million for GPT-5.5.

If performance differs by a few percentage points, cost differs by more than double, and token consumption by more than triple. That looks like a single line in a benchmark table, but in an operation processing thousands of tasks a day, it changes the order of magnitude on the monthly bill.

flowchart TB
  T["One agentic task"] --> R{"Model choice"}
  R -->|"Grok 4.5"| G["1.9M tokens<br/>$2.49 cost"]
  R -->|"GPT-5.5"| P["6.2M tokens<br/>$5.07 cost"]
  G --> S["Performance close<br/>Wins on some benchmarks"]
  P --> S
  S --> D["Practical call:<br/>same result, half the cost"]

Why This Shift Matters Now

The signal from this release is simple. As frontier performance converges toward a common ceiling, the deciding factor in model choice is shifting from “the most intelligent model” to “intelligent enough, at a lower price.” As The Decoder pointed out, once benchmark gaps narrow this much, the gap itself may stop mattering much for real-world choices.

This view lines up precisely with a principle we covered in an earlier post. Most agentic work is not a creative hard problem, it is a structured task: classification, summarization, routing, rendering. The quality of this kind of work is governed more by code-level guardrails than by model intelligence. If that is true, routing structured tasks to a cheaper model and reserving the top-tier model for genuinely hard reasoning is the rational move. Grok 4.5 widens the field of “cheap but smart enough” options available for that routing.

At the same time, there is a point worth flagging. Consuming a third of the tokens per task is not only a matter of unit price, it may also mean the model finishes the same job in fewer round trips. That works in favor of latency and throughput too. Still, this figure comes from one specific benchmark environment (Grok Build versus Codex), so it needs to be confirmed with your own measurements on your own workload.

Implications for ThakiCloud’s Products

ThakiCloud’s ai-platform is a multi-tenant inference platform, serving models to a range of customer environments on top of K8s and Kueue-based GPU scheduling. A release like Grok 4.5 matters to us on two levels.

The first is model routing economics. We already split model tiers by the nature of the work: cheap tiers for exploration and classification, mid tiers for implementation and review, top tiers for architecture and complex reasoning. When a model appears that gets close to frontier performance at less than half the price, the coverage of the “cheap but smart enough” tier expands, and the range of situations requiring the top-tier model shrinks. The outcome is the same quality at a lower total cost. The key is that this decision has to be made from actual output quality measured by code, not from human intuition.

The second is the cost logic of on-premises and sovereign environments. For customers who cannot move data outside their own environment, such as Korean public sector, financial, or NIS-mandated deployments, self-hosting is a precondition. In these environments GPU capacity is finite, so a model that consumes fewer tokens per task lets the same hardware handle more concurrent requests. Token efficiency is not just an API billing issue, it is also a real throughput issue for on-prem clusters. Low serving cost is exactly where ai-platform is competitive, and a token-efficient model amplifies that edge directly.

Third, from an agent perspective, this connects to Paxis. Paxis is the Agent-Native Cloud control plane running on top of ai-platform, executing skills in isolated sandboxes and routing every action through policy gates and audit logs. Agent economics ultimately come down to “the model cost of finishing one task,” and a low-cost, high-efficiency model improves the unit economics of each agentic workflow. This confirms once again the thesis that cheap serving is what makes agent economics work.

Limitations and Counterarguments

Before getting too optimistic, it is worth looking at the other side. First, most of these numbers come from the vendor and early analysis outlets. Metrics like Terminal Bench or the Coding Agent Index do not correlate perfectly with real production workloads. As the 53% versus 67% gap on DeepSWE 1.1 shows, top-tier models still hold the advantage on hard problems. If teams push hard reasoning onto a cheap model purely because it is cheap, the cost of retries and failure recovery can rise enough to flip the total cost equation.

Second, the efficiency figure of 1.9 million tokens per task was measured in one specific harness (Grok Build). It may not reproduce in a different agent framework or a different prompt structure. Plugging a vendor-published number directly into your own invoice is risky, and it needs to be verified through your own A/B measurement on a golden set.

Third, Grok 4.5 is not an open-weight model, it is a closed model served through an API. That means it cannot be deployed directly in on-prem environments where data sovereignty is the whole point. Sovereign customers still need a self-hostable open-weight model, and Grok 4.5’s economics story is limited to cloud API workloads.

In conclusion, Grok 4.5 is a striking illustration of a broader trend: once frontier performance converges, the next battlefield is economics. Rather than chasing another point or two on a benchmark, the teams that win this phase are the ones who actually measure cost per task and token efficiency on their own workload, and route models based on that data. Automating that measurement and that routing is the work we do every night.

Sources

• Introducing Grok 4.5 · Cursor
• SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’ · TechCrunch
• Grok 4.5 is so cheap compared to Fable 5 and GPT 5.5 that benchmark gaps may not matter much · The Decoder
• Grok 4.5 (high): Intelligence, Performance & Price Analysis · Artificial Analysis

Overview: A Generational Shift in the Default Voice Experience

GPT-Live is a new generation of voice model that replaces ChatGPT’s default voice experience. At its core is a full-duplex structure. Where the previous voice mode was half-duplex, meaning it listened and then spoke, GPT-Live can listen and speak at the same time. While the user is talking, it signals that it is listening with backchannels like “mm” or “yeah,” takes part in quick back-and-forth exchanges, and waits quietly when the other person needs a moment to think. OpenAI describes this experience as much closer to talking with an actual person.

The rollout comes in two variants. GPT-Live-1 is the default for Go, Plus, and Pro users, while GPT-Live-1 mini is the default for free users. Both models have begun rolling out gradually to users worldwide across ChatGPT on iOS, Android, and the web.

What Actually Changed Technically

The biggest change is in how the system handles the timing of conversation. Half-duplex voice systems rely on end-of-turn detection: once the system judges that the user has stopped talking, it starts generating a response. This approach is simple to implement, but it cannot express the overlap, interruption, and backchanneling that happen naturally in conversation.

Full-duplex confronts this constraint head-on. To keep receiving an input audio stream while generating output audio at the same time, the model and its serving layer must process bidirectional streams simultaneously at low latency. Even while the user keeps talking, the model has to decide in real time when to backchannel, when to interject, and when to stay silent. This is not simply a matter of speech-synthesis quality; it is a matter of modeling the timing of conversation itself.

Another notable design choice is delegation. GPT-Live is introduced as the smartest voice model to date, yet questions that need web search, deeper reasoning, or complex tasks are quietly delegated to the latest frontier model behind the scenes. Once the result is ready, it is brought back into the flow of conversation. In other words, this is a layered architecture in which a fast, lightweight voice model handles the real-time feel of the conversation while heavier reasoning is processed asynchronously by a separate model.

flowchart TB
  U["User voice<br/>continuous input stream"] --> L["GPT-Live<br/>full-duplex voice model"]
  L -->|"real-time response, backchannel, silence"| U
  L --> Q{"Deep reasoning<br/>needed?"}
  Q -->|"Yes"| F["Frontier model<br/>async delegation"]
  Q -->|"No"| L
  F -.returns result.-> L

This kind of layering is a common pattern in real-time system design: separate the path that needs low latency from the path that needs high accuracy, and run the latter asynchronously to preserve the responsiveness of the front end. GPT-Live can be read as an application of this pattern to voice conversation.

Implications for ThakiCloud’s Products

GPT-Live itself is a closed OpenAI product, but the requirements its architecture raises connect directly to the infrastructure we operate.

From the ai-platform perspective, full-duplex voice is a demanding case of real-time streaming inference. ThakiCloud’s ai-platform serves a range of models on top of K8s and Kueue-based GPU scheduling, and unlike batch inference, voice conversation demands low and consistent latency. Handling bidirectional audio streams at the same time requires the serving layer to keep streaming input and output and session state stable, and GPU resources have to be managed not just for throughput but for tail latency as well. This low-latency serving requirement matters especially in on-premise and sovereign environments. For customers who cannot send data outside their own infrastructure and want to self-host a voice interface, a serving stack that can handle real-time streaming is a precondition.

From an agent perspective, this connects to Paxis. Paxis is the Agent-Native Cloud control plane that runs on top of ai-platform, executing skills in isolated sandboxes and routing every action through policy gates and audit logs. GPT-Live’s delegation structure, where a lightweight front end hands heavy reasoning to the back, follows the same principle as layering in agent design. As voice becomes a new input surface for agents, we need a flow that interprets what the user meant, selects the right skill, executes it in isolation, and returns the result to the conversation. Paxis’s skill harness, MCP connectors, and policy gates can handle exactly this back end of a voice agent pipeline: real-time voice owns the front end, while agent execution backed by policy and audit owns the back end.

Limitations and Counterpoints

Full-duplex does not automatically guarantee a better experience. Listening and speaking at the same time increases naturalness, but it also opens up more room for things to go wrong. The system might misread a brief pause as the end of a turn and interrupt, or backchannel so much that it actually disrupts the conversation. Modeling natural timing is a far more subtle problem than speech-synthesis quality, and judgment should be withheld until it is validated by real user reactions.

The delegation structure has its own shadow side. If the front-end voice model misjudges when to hand off to the frontier model, a simple question could get an excessive delay, or a hard question could get a shallow answer. The accuracy of this routing decision determines the overall experience, and that is something a vendor announcement cannot confirm; it only shows up in real use.

Finally, the architectural interpretation in this piece is based on OpenAI’s public statements and early reporting, and the internal implementation details have not been disclosed. The direction toward full duplex and delegation is clear, but specific latency figures or model structures have not been independently verified by us and should be treated as estimates.

In short, GPT-Live is a release that shows voice interfaces moving from a “tool that takes commands” toward a “conversation partner.” And what actually carries that shift is not flashy voice quality but the infrastructure that serves bidirectional streams at low latency and safely delegates heavy reasoning. That back end, on both the real-time serving side and the agent execution side, is exactly what we are building toward.

Sources

• Introducing GPT-Live · OpenAI
• OpenAI releases new voice models for more natural live conversations · TechCrunch
• OpenAI Introduces GPT-Live to Make ChatGPT Voice Feel Like a Real Conversation · MacRumors

A rendering of unified memory management where store, retrieve, summarize, and discard converge into one action space.

Overview

The one-line summary of this paper is that “memory becomes an action space.” Instead of an external pipeline deciding by fixed rules whether to store, retrieve, update, summarize, or discard, the agent decides directly at each step, as if calling a tool. It looks simple, but the shift topples two long-standing assumptions at once. First, the assumption that long-term and short-term memory must be fundamentally different mechanisms. Second, the assumption that what to remember and what to forget should be decided by human-authored policies. AgeMem absorbs both into a learnable policy.

There is a specific reason this matters for teams deploying agents into on-premise or sovereign environments. When memory-management logic is scattered across an external rule set, you have to re-tune those rules every time the domain changes, and any mismatch between rules and model becomes a quality regression. When memory management moves into the policy, you gain room to adapt to multiple domains with the same training procedure.

The Problem: The Cost of Separated Memory

Unpack the existing approach and the structure of the problem becomes clear. Short-term memory usually keeps recent conversation in context and then truncates or compresses it once it hits a limit. Long-term memory chunks the conversation, embeds it, and splices it back in when needed. These two paths do not know about each other. Long-term memory does not know what short-term memory discarded, and short-term memory does not care what long-term memory has already stored. The result is that the same information gets stored twice, or a needed fact disappears somewhere along the boundary between the two.

The more fundamental problem is that none of these decisions are learned. What to summarize and promote to long-term memory, when to discard stale memory, is typically handled by fixed thresholds and rules. Because the reward signal for whether the task actually succeeded never flows back into these decisions, the system cannot improve itself. AgeMem takes exactly this point, making memory operations rewardable, learnable actions, as its core contribution.

Memory as an Action Space: AgeMem’s Core Idea

AgeMem integrates long-term memory (LTM) and short-term memory (STM) management directly into the agent’s policy. The core design is to expose memory operations as tool-based actions. At each step, alongside ordinary reasoning and response generation, the agent chooses whether to store, retrieve, update, summarize, or discard information. It decides for itself what and when to remember and forget, according to the demands of the task.

In AgeMem, memory operations are not a separate pipeline but actions the policy chooses. Store, retrieve, update, summarize, and discard form one action space, and task-success reward flows back into the policy.

The benefits of this unification are clear. Because short- and long-term sit under one policy, the agent can focus on the conversation in front of it while deciding, with consistent judgment, when to promote that content to long-term memory. The summarize action becomes the bridge from short-term to long-term, and the discard action keeps context light. Above all, every one of these choices aligns toward a single goal: task success.

Training: Three-Stage Progressive RL and Step-Wise GRPO

The challenge is how to train such unified behavior. Memory operations are actions with awkward rewards. Whether a decision to store something was right is only revealed much later, at the moment that information is actually needed again. Rewards arrive sparsely, and the gap between action and reward is discontinuous. These are conditions standard reinforcement learning does not handle well.

AgeMem responds with two mechanisms. The first is a three-stage progressive reinforcement learning strategy that does not train the unified memory behaviors all at once but ramps them up in stages. The second is step-wise GRPO. By designing GRPO (Group Relative Policy Optimization) at the step level, it confronts head-on the sparse and discontinuous rewards that memory operations induce. It can be understood as an approach that decomposes delayed reward into each step’s contribution, making the learning signal denser.

This part is interesting from ThakiCloud’s vantage as well. For a team operating RL post-training infrastructure directly, a custom GRPO variant like this only runs if the training framework flexibly supports reward shaping and step-level advantage computation. In other words, the paper’s methodology translates directly into requirements on the training pipeline.

Results and Significance

The paper evaluates AgeMem on five long-horizon benchmarks. Across multiple LLM backbones, it reports consistently outperforming strong memory-augmented baselines. Improvement shows up in three directions: task performance rises, long-term memory quality improves, and context is used more efficiently. That last item matters most in practice. Using context more efficiently means handling the same task with fewer tokens, which translates directly into lower inference cost.

Specific numbers deserve caution. Secondary summaries described the average score on a Qwen2.5-7B backbone as clearly higher than Mem0-class baselines, with the gap widening on smaller backbones [estimated]. But because those figures were not re-verified against the primary source, we recommend checking the exact per-benchmark scores in the original link below. What we can state with confidence is the methodology and the qualitative conclusion: a consistent advantage across five benchmarks and multiple backbones, and that the advantage appeared not only in task performance but also in memory quality and context efficiency.

For ecosystem context, agent-memory systems have become a fiercely contested area in 2026. Mem0 has emphasized scores around 67.13 percent on an LLM-as-a-Judge basis on the conversational long-term memory benchmark LOCOMO along with low search latency, and systems like Zep and Letta each tout their own strengths. AgeMem’s differentiator lies not in a component-level performance contest but in a framing shift that redefines memory management as a policy-learning problem.

Implications for ThakiCloud

This paper offers implications through both an infrastructure lens and an agent lens. Because the subject is agent memory, the Paxis lens is central, but the ai-platform lens fits too on the RL-training-infrastructure side.

Paxis is ThakiCloud’s Agent-Native Cloud control plane, treating Skills, Tools, Policies, and Audit Logs as first-class resources. Among these, the knowledge engine (HKE wiki) and the memory layer sit exactly on the problem AgeMem touches. Like many agent platforms today, Paxis manages memory in layers, and the question AgeMem raises is clear: can the movement between those layers, what to promote from session memory into long-term knowledge and what to discard, be handled by learned judgment rather than fixed rules? A design that exposes store, retrieve, summarize, and discard as tool actions meshes naturally with a Paxis structure that already treats skills and tools as first-class resources. Treat memory operations as another action subject to policy gates and audit logs, and you gain traceability over what the agent remembered and forgot.

On the ai-platform lens, training infrastructure is the crux. Actually running a custom RL variant like step-wise GRPO requires a training pipeline that supports reward shaping and step-level advantage computation on top of Kueue-based GPU scheduling. ThakiCloud’s ai-platform provides the foundation to operate such RL post-training workloads in a multi-tenant K8s environment. And the context-efficiency gains the paper emphasizes tie directly into vLLM serving cost, so low-cost serving (ai-platform) underpins agent economics (Paxis).

Limitations and Counterarguments

For balance, we should raise the opposite direction too. First, integrating memory operations into the policy raises training complexity substantially. The very fact that three-stage training and a custom GRPO were needed to handle sparse, discontinuous rewards is evidence that this approach is far from cheap. A well-tuned rule-based pipeline may still be more stable and predictable in specific domains.

Second, questions of reproducibility and generalization remain. Whether an advantage on five benchmarks holds in real production traffic, especially in environments with mixed languages and constantly shifting domains, needs separate verification. Benchmark improvement failing to transfer to operations is common.

Third, the interpretability of a learned memory policy. A rule-based system can explain why it discarded a particular piece of information by pointing to a rule, but a learned policy may leave that decision opaque. In heavily regulated domains or environments with strong audit demands, that opacity becomes a barrier to adoption. That said, this point is substantially mitigated when combined with a structure like Paxis that logs every action.

In conclusion, AgeMem achieves a framing shift by redefining agent memory from a per-component performance problem into a policy-learning problem. Even teams not adopting the method right away would do well to pose one question early in design: can memory-management decisions be treated as something to learn?

Sources

• Agentic Memory: Learning Unified Long-Term and Short-Term Memory Management for Large Language Model Agents (arXiv:2601.01885)
• Hugging Face Papers page (2601.01885)
• Mem0 AI Memory Benchmarks 2026 (LOCOMO context)

오늘 뉴스는 두 방향으로 갈렸습니다

한쪽은 지능과 컴퓨트가 흔해지는 이야기였습니다. 중국 앤트그룹은 유리와 거울 같은 반사면까지 인식하는 비전 AI를 공개하며 12개 벤치마크를 석권했는데, 놀라운 대목은 성능이 아니라 규모였습니다. 단 11억 개 매개변수로 70억 급 모델을 능가했습니다. 엔비디아 고성능 GPU 접근이 제한된 환경에서 나온 효율 중심 전략이 어디까지 왔는지를 보여준 셈입니다. 같은 날 오픈AI와 앤트로픽은 최고 성능 모델을 무료 토큰으로 풀며 초기 스타트업을 자기 생태계에 붙잡으려 경쟁했고, 퀄컴은 HBM 자체를 우회한 저전력 데이터센터 칩으로 엔비디아 독점에 균열을 시도했습니다. 앤트로픽은 아마존 트레이니엄과 구글 TPU, 엔비디아 GPU를 워크로드별로 나눠 쓰는 멀티칩 전략을 확대했습니다. 지능도, 그 지능을 돌릴 실리콘도 이제 한 곳에 매이지 않습니다.

다른 한쪽은 조용했지만 방향이 분명했습니다. IT조선은 “알아서 일하는 AI 에이전트, 행동 기록이 신뢰를 좌우한다”는 진단을 내놨습니다. 마이크로소프트와 유아이패스 같은 플랫폼 기업들이 앞다퉈 강화하는 것은 더 큰 모델이 아니라, 에이전트의 모든 실행 단계를 로그와 지표와 추적 정보로 남기는 관측가능성 도구였습니다. 생성형 AI 시절의 단순 응답 로그를 넘어, 에이전트가 스스로 판단하고 행동한 흔적 자체를 기록으로 붙잡으려는 흐름입니다.

지능은 상향 평준화되고, 병목은 옮겨갔습니다

두 방향을 겹쳐 보면 통념 하나가 흔들립니다. 우리는 오랫동안 “더 똑똑한 모델이 더 나은 에이전트를 만든다”고 믿어 왔습니다. 그런데 앤트그룹 사례처럼 지능이 작고 저렴해지고, 무료 토큰 경쟁처럼 최고 모델의 접근 장벽마저 낮아지면, 지능은 더 이상 차별화 요소가 아니게 됩니다. 누구나 쓸 수 있는 것은 누구의 경쟁력도 아니기 때문입니다.

그래서 기업이 실제로 멈칫하는 지점은 성능표의 마지막 소수점이 아니었습니다. 자율적으로 움직이는 에이전트가 무엇을 했는지, 왜 그랬는지를 사후에 증명할 수 있느냐는 물음이었습니다. 국내 사정은 이 물음을 더 무겁게 만듭니다. 2026년 1월 시행된 AI 기본법 아래에서 금융과 공공 부문은 에이전트의 의사결정 과정을 사후 검증할 수 있는 로그 체계를 규제 대응 차원에서 갖춰야 합니다. 행동 기록의 미비가 곧 책임 소재 분쟁과 감사 리스크로 직결되는 국면입니다.

같은 날 하나금융융합기술원이 기업여신과 상담을 지원하는 금융 업무용 AI 모델을 공개한 것도 이 맥락에서 읽힙니다. 케이뱅크와 신한은행, KB국민은행이 이미 자체 도메인 모델로 방향을 튼 데는 망분리 규제와 고객 데이터 외부 반출 제한이라는 국내 특유의 환경이 자리합니다. 은행권이 범용 초거대 모델 대신 내부망에서 돌아가는 경량 특화 모델로 수렴하는 이유는 성능이 아니라 통제 가능성입니다. 어디서 돌아가고 무엇을 남기는지를 스스로 쥐고 있어야 규제를 통과할 수 있습니다.

흔해지는 것의 폭이 넓어지고 있습니다

지능만 흔해지는 것이 아닙니다. 그 지능을 떠받치는 하드웨어 우위도 한 지점에 머물지 않고 흩어지는 중입니다. 글로벌이코노믹은 AI 주도권이 GPU 독점에서 인프라 수요 확산으로 넘어가고 있다고 짚었습니다. GPU 품귀는 2026년 하반기부터 점진적으로 풀릴 전망이고, TSMC의 첨단 패키징 생산능력과 HBM 공급이 안정화되면서 투자 초점이 CPU와 메모리, 서버, 전력, 냉각, 네트워크로 번지고 있습니다. 병목이 GPU 한 곳에 있을 때는 GPU를 확보하는 것이 곧 경쟁력이었지만, 병목이 여러 갈래로 퍼지면 어느 한 자원의 우위만으로는 격차를 벌리기 어려워집니다.

슈퍼마이크로가 70억 달러를 조달하며 엣지부터 초대형 데이터센터까지 공급을 넓히고, 통신사들이 대규모 데이터센터 용량 경쟁에 뛰어드는 것도 같은 방향입니다. 공급이 넓어질수록 하드웨어를 얼마나 확보했느냐보다, 그 위에서 워크로드를 어떻게 배치하고 어떻게 운영하며 무엇을 기록하느냐가 진짜 변별점으로 남습니다. 자원이 귀할 때는 소유가 경쟁력이지만, 자원이 흔해지면 운영이 경쟁력입니다. 그리고 자율 에이전트 시대의 운영은 곧 통제와 기록의 다른 이름입니다.

결과가 아니라 과정을 본다는 신호

흥미롭게도 같은 전환이 사람을 뽑는 자리에서도 나타났습니다. 크래프톤과 CJ올리브영이 공동 개최한 AI 네이티브 해커톤에서 쓰인 평가 방식은, 완성된 결과물만 보지 않았습니다. 지원자가 문제를 어떻게 구조화했고 AI 에이전트를 어떤 방식으로 활용해 반복 개선했는지, 그 과정을 함께 채점했습니다. 결과물의 겉모습은 AI 코딩 도구가 보편화되면서 상향 평준화됐기 때문입니다. 변별력은 결과가 아니라 과정의 기록에서 나온다는 판단이, 채용 시장에서도 똑같이 작동하기 시작했습니다.

에이전트에게 요구되는 것도 다르지 않습니다. 자율성이 커질수록 신뢰의 근거는 매끈한 최종 출력이 아니라, 그 출력에 이르기까지의 검증 가능한 궤적으로 옮겨갑니다. 지능이 흔해진 세계에서 남는 질문은 언제나 같습니다. 이 에이전트가 한 일을, 나중에 다른 사람이 되짚을 수 있습니까.

기록은 나중에 붙이는 기능이 아닙니다

여기서 흔한 오해를 짚고 넘어가야 합니다. 감사 추적을 잘 만든 에이전트에 나중에 덧붙이는 부가 기능쯤으로 여기기 쉽습니다. 그러나 행동 기록은 실행 계층 바깥에서 관찰만으로 완성되지 않습니다. 에이전트가 어떤 스킬을 호출했고, 격리된 실행 환경 안에서 어떤 도구를 어떤 권한으로 건드렸으며, 외부 시스템과 어떻게 연동했는지는 실행 구조 자체가 남겨줘야 하는 정보입니다. 실행과 기록이 분리되어 있으면, 로그는 언제나 실제 행동보다 성기고 늦습니다.

문제는 오늘날 에이전트가 자기 안에서만 움직이지 않는다는 점입니다. 표준 커넥터를 통해 사내 데이터베이스를 조회하고, 외부 API를 부르고, 다른 에이전트에게 작업을 넘깁니다. 실행이 여러 시스템을 가로지르는 만큼, 기록도 그 경계를 함께 넘어야 합니다. 한 시스템 안의 로그만 남기고 연동 지점을 놓치면, 사고가 났을 때 정작 책임이 갈리는 접점이 공백으로 남습니다. 관측가능성이 응답 로그를 넘어 행동 신호로 확장되고 있다는 오늘의 진단은 바로 이 공백을 메우려는 움직임입니다.

그렇다면 처음부터 실행 계층이 기록을 소유하도록 설계된 플랫폼은 어떤 모습이어야 할까요. ThakiCloud의 Agent-Native Cloud인 Paxis는 이 질문을 제품의 뼈대로 삼았습니다. Paxis에서 Skills와 Tools, Policies, Audit Logs는 나중에 얹는 옵션이 아니라 일급 리소스입니다. 에이전트가 스킬을 호출하는 순간과 도구를 실행하는 순간이 곧 감사 로그로 남고, 정책 게이트가 그 실행을 사전에 승인하거나 차단합니다. MCP 표준 커넥터로 외부 시스템과 연동하는 지점까지 같은 궤적 위에 얹히기 때문에, 시스템 경계를 넘나드는 행동도 하나의 기록으로 이어집니다. 무엇을 했는지를 사후에 복원하는 것이 아니라, 하는 동안 기록이 함께 자라는 구조입니다.

이 구조가 특히 값어치를 갖는 곳이 제조와 공공, 금융 같은 규제 산업입니다. 같은 날 네이버클라우드는 유럽의 미스트랄AI와 손잡고 제조 특화 소버린 AI를 공동 개발하겠다고 밝혔습니다. 데이터를 외부로 내보내기 어려운 제조 기업의 특성에 맞춘 접근입니다. 정부는 2030년까지 민관 20조원을 투입해 국가 제조데이터 라이브러리를 구축하고 명장의 암묵지까지 데이터로 남기는 K-피지컬 AI 전략에 시동을 걸었고, LG씨엔에스는 금융과 피지컬 AI로 사업 축을 옮기고 있습니다. 이 현장들의 공통점은 데이터가 밖으로 나갈 수 없다는 제약과, 자동화된 판단이 남긴 흔적을 반드시 붙잡아야 한다는 요구입니다. 소버린과 감사 추적은 별개의 요구가 아니라 하나의 요구를 앞뒤에서 본 것입니다.

자율성 역시 흑백이 아니라 눈금으로 다룹니다. Paxis는 에이전트의 자율도를 L0에서 L3까지 단계로 나눠 거버넌스합니다. 여신 심사처럼 민감한 작업은 사람의 승인을 끼운 낮은 자율도로 두고, 위험이 낮은 반복 작업은 높은 자율도로 열어두는 식입니다. AI 기본법이 요구하는 사후 검증 가능성과 금융권이 필요로 하는 통제 가능성은, 정책과 감사 로그와 자율도 눈금이 한 몸으로 움직일 때 비로소 현실이 됩니다. 격리 샌드박스 안에서 실행이 이뤄지고, 그 실행이 소버린 온프렘 쿠버네티스 위에서 돌아간다면, 데이터를 외부로 내보내지 않으면서도 모든 궤적을 국내 인프라 안에 남길 수 있습니다. 망분리 환경을 벗어나지 못하는 금융과 공공 고객이 정작 필요로 하는 그림입니다.

흔해진 것과 귀해진 것

오늘 시장은 지능과 컴퓨트가 얼마나 빠르게 흔해지는지를 여러 각도에서 보여줬습니다. 작은 모델이 큰 모델을 이기고, 최고 모델이 공짜로 풀리고, 칩은 벤더를 갈아탑니다. KT는 1GW, SKT는 15GW 규모의 데이터센터를 예고하며 인프라 공급도 넓혀갑니다. 이 모든 것이 지능의 값을 떨어뜨리는 방향으로 작동합니다.

값이 떨어진 것 옆에는 늘 값이 오른 것이 있습니다. 지능이 흔해질수록, 그 지능이 자율적으로 한 일을 증명하는 능력은 귀해집니다. 서울에서 처음 열린 ICML 2026의 화두가 에이전틱 AI였다는 사실은, 연구의 최전선조차 이 문제로 수렴하고 있음을 시사합니다. 기업이 에이전트에게 진짜로 던지는 질문은 이제 “얼마나 똑똑하냐”가 아니라 “네가 한 일을 내가 되짚을 수 있느냐”입니다. 그 물음에 실행 계층 스스로가 답하도록 만드는 일, 그것이 지능의 시대가 지나간 자리에 남은 진짜 과제입니다.

헤드리스·훅·서브에이전트·스킬 네 축이 겹쳐 사람 없이 도는 자율 하네스를 형상화했습니다.

개요

Anthropic은 Claude Code를 대화형 CLI를 넘어 자동화 런타임으로 확장해 왔습니다. 관련 발표(“Enabling Claude Code to work more autonomously”)와 자동 모드 설계 글(“How we built Claude Code auto mode”), 그리고 조종 방법을 종합한 블로그(“Steering Claude Code”)가 그 흐름을 보여 줍니다. 핵심 메시지는 하나입니다. Claude Code를 자율적으로 굴리는 것은 더 똑똑한 모델을 기다리는 문제가 아니라, 주변 하네스를 어떻게 설계하느냐의 문제라는 것입니다.

이 관점은 ThakiCloud의 운영 원칙과 정확히 겹칩니다. 능력은 모델 자체가 아니라 그 모델을 감싸는 계약 구조, 즉 시스템 프롬프트·도구 정의·검증 게이트·라우팅 규칙에서 나온다는 것입니다. 아래 네 가지 축은 바로 그 하네스를 구성하는 부품들입니다.

무엇이 문제인가: 사람이 매번 붙어 있어야 하는 에이전트

단발 응답 에이전트의 한계는 명확합니다. 작업이 조금만 길어지면 사람이 매 스텝의 판단과 승인을 대신해야 하고, 반복 작업조차 매번 손으로 트리거해야 합니다. 여기서 필요한 것은 세 가지입니다. 첫째, 사람 없이 한 번에 실행을 시작하고 끝내는 방법. 둘째, 특정 시점에 반드시 어떤 동작이 일어나도록 강제하는 방법. 셋째, 복잡한 작업을 전문화된 일꾼에게 나눠 맡기고, 그 일꾼이 필요한 지식만 골라 쓰게 하는 방법입니다. 네 가지 축은 각각 이 요구를 하나씩 충족합니다.

네 가지 축은 서로 겹쳐 하나의 자율 하네스를 이룹니다. 헤드리스가 실행을 열고, 훅이 생명주기를 강제하며, 서브에이전트가 작업을 나누고, 스킬이 그때그때 전문성을 공급합니다.

1. 헤드리스 모드: 사람 없이 한 번에 실행

헤드리스 모드는 Claude Code를 TTY 없이 한 번의 CLI 프로세스로 실행하는 방식입니다. claude -p "<프롬프트>" 형태로 호출하면 대화 없이 작업을 수행하고 종료합니다. 이 단순한 성질이 예약 작업, CI 파이프라인, 커밋 전 검사 같은 무인 통합을 가능하게 만듭니다. 중요한 점은 헤드리스 모드가 대화형 CLI와 동일한 설정·훅·권한 규칙을 그대로 재사용한다는 것입니다. 즉 대화형에서 검증한 하네스를 그대로 무인 환경으로 옮길 수 있습니다.

ThakiCloud는 이 방식을 이미 광범위하게 운용합니다. scripts/launchd/에는 35개의 launchd plist가 있고, 각 plist는 정해진 시각에 claude -p로 스킬 러너를 호출합니다. 지금 이 블로그 글을 만드는 파이프라인 자체가 헤드리스로 도는 러너의 한 예입니다. 트위터 타임라인에서 블로그 후보를 뽑아 큐에 넣고, 후보마다 초안을 쓰고 검증 게이트를 통과시켜 배포까지 이어지는 전 과정이 사람의 매 스텝 개입 없이 진행됩니다.

ThakiCloud에서 무인 자동화로 도는 launchd 스크립트는 35개입니다. 대화형 TTY 없이 claude -p 단일 프로세스로 실행하며, 종량 API 키 대신 구독 OAuth 토큰을 로드해 시크릿 노출을 막습니다.

무인 실행에서 반드시 챙겨야 할 것은 인증입니다. 종량 API 키를 디스크에 커밋하는 대신, 구독 OAuth 토큰을 별도 파일에 두고 러너가 이를 로드하는 방식이 안전합니다. Anthropic 문서 역시 무인 환경에서는 API 키를 시크릿 매니저에서 꺼내 오는 헬퍼를 쓰라고 권합니다. 자동화의 편리함이 곧 시크릿 노출로 새지 않도록, 인증 경로를 처음부터 무인 전제에 맞춰 설계하는 것이 핵심입니다.

2. 훅: 결정론적 생명주기 제어

훅은 Claude Code 생명주기의 특정 지점에서 코드를 실행하는 장치입니다. 파일 편집 후 자동 포매팅, 커밋 전 린트, 세션 시작 시 컨텍스트 주입, 종료 시 후처리처럼, 모델의 선택에 맡기지 않고 반드시 일어나야 하는 동작을 강제합니다. 훅의 가치는 결정론에 있습니다. 모델이 그때그때 기분에 따라 실행할지 말지를 정하는 것이 아니라, 규칙으로 못 박힌 동작이 항상 발생합니다.

ThakiCloud의 .claude/hooks/에는 12개의 훅이 배선돼 있습니다. 세션 시작 훅은 직전까지의 학습을 상주 브리프로 주입해 매 세션이 백지에서 시작하지 않게 합니다. 프롬프트 제출 훅은 요청을 분석해 관련 스킬 후보를 자동으로 띄웁니다. 종료 훅은 플래그 파일을 감지해 필요한 후처리, 예컨대 큐에 쌓인 블로그 후보 드레인이나 지식 베이스 재컴파일을 실행합니다. 특히 이 종료 훅은 플래그가 없으면 즉시 종료해 비용이 0에 수렴하고, 플래그가 있을 때만 무거운 작업을 도는 패턴을 씁니다. 매 턴이 아니라 생산자 턴 직후에만 비싼 작업을 트리거하는 이 구조가 자율 파이프라인의 비용을 통제하는 핵심입니다.

현재 배선된 생명주기 제어 훅은 12개입니다. 시작 훅은 컨텍스트를 주입해 백지 상태를 막고, 제출 훅은 스킬 후보를 띄우며, 종료 훅은 플래그가 있을 때만 무거운 작업을 돌려 불필요한 비용을 0에 수렴시킵니다.

3. 서브에이전트: 격리된 전문가 위임

서브에이전트는 특정 작업을 위한 격리된 보조 에이전트입니다. .claude/agents/의 마크다운 파일로 정의하며, 이름·설명과 함께 사용할 모델과 도구 접근 범위를 지정합니다. 메인 에이전트가 프런트엔드를 만드는 동안 서브에이전트가 백엔드 API를 병렬로 세우는 식의 분업이 가능합니다. 격리가 중요한 이유는 두 가지입니다. 서브에이전트는 자신의 작업에만 집중하므로 메인 컨텍스트를 오염시키지 않고, 결과만 요약해 되돌립니다.

ThakiCloud는 63개의 전문 서브에이전트를 정의해 두고 작업 성격에 맞춰 호출합니다. 여기에 모델 라우팅 규칙이 결합됩니다. 탐색·검색·파일 읽기처럼 가벼운 작업은 haiku로, 구현·리뷰·테스트 작성은 sonnet으로, 아키텍처 결정이나 복잡한 다단계 추론은 opus로 보냅니다. 이 라우팅이 없으면 모든 서브에이전트가 세션 기본 모델로 돌아 비용이 폭증합니다. 자율 하네스에서 서브에이전트는 단순한 병렬화 수단이 아니라, 작업마다 적절한 비용-품질 지점을 고르는 비용 통제 장치이기도 합니다.

정의된 전문 서브에이전트는 63개입니다. 메인 에이전트가 프런트엔드·백엔드·API로 팬아웃하되, 결과를 사용자에게 합치기 전 반드시 검증 게이트로 닫습니다. 검증 없는 병렬화는 환각을 누적합니다.

한 가지 규율을 덧붙이면, 팬아웃한 서브에이전트의 결과를 합치기 전에는 반드시 검증 스테이지로 닫아야 합니다. 병렬 에이전트를 여러 개 띄웠으면, 그 결과를 그대로 사용자에게 합치는 대신 적대적 검증을 한 번 거치는 것입니다. 검증 게이트 없는 팬아웃은 환각을 누적합니다.

4. 스킬: 필요할 때만 불러오는 전문성

스킬은 반복 가능한 전문 워크플로를 패키지로 묶은 것입니다. 도메인 지식·템플릿·검증 스크립트·실패 사례를 함께 담아, 요청이 트리거할 때만 로드합니다. 항상 로드하지 않는다는 점이 핵심입니다. 매 세션 컨텍스트에 상주시키면 토큰 비용을 계속 지불하지만, 온디맨드로 불러오면 필요한 순간에만 전문성을 공급합니다.

ThakiCloud의 .claude/skills/에는 1,751개의 스킬이 있습니다. 이 규모에서는 어떤 스킬을 언제 부를지가 곧 품질을 좌우합니다. 그래서 자연어 요청을 BM25 계열 어휘 검색으로 후보 스킬에 매핑하고, 상위 후보만 컨텍스트에 띄우는 라우터를 둡니다. 스킬이 1,700개를 넘어가면 사람이 일일이 고를 수 없으므로, 검색으로 후보를 좁히는 이 단계가 없으면 스킬 시스템 자체가 노이즈가 됩니다. 스킬은 프롬프트가 아니라 버전 관리되는 능력 상품이며, 여러 하네스를 가로질러 재사용된다는 점에서 단순 프롬프트와 구별됩니다.

ThakiCloud에 등록된 반복 가능한 전문 워크플로 패키지는 1,751개입니다. 이 규모를 매 세션에 상주시키면 토큰이 낭비되므로, BM25 검색으로 후보를 좁혀 필요할 때만 온디맨드로 불러옵니다.

ThakiCloud 제품 적용 시사점

이 주제는 에이전트 오케스트레이션 그 자체이므로 Paxis 렌즈가 정면으로 맞습니다. Paxis는 ThakiCloud의 Agent-Native Cloud 제어 평면으로, Skills·Tools·Policies·Audit Logs를 일급 리소스로 다룹니다. 위 네 가지 축은 Paxis가 제품 차원에서 제공하려는 능력과 일대일로 대응합니다. 헤드리스 실행은 NL Cron으로 예약된 무인 실행에, 훅은 정책 게이트와 감사 로그에, 서브에이전트는 DAG 멀티에이전트 오케스트레이션에, 스킬은 960개 이상 스킬을 BM25로 선택하는 Skill Harness에 각각 대응합니다.

Anthropic이 개별 기능으로 소개한 네 축은 Paxis에서 NL Cron, 정책 게이트와 감사 로그, DAG 오케스트레이션, 960개 이상 스킬을 BM25로 선택하는 Skill Harness로 각각 제품화됩니다.

핵심은 Anthropic이 개별 기능으로 소개한 네 축을 Paxis가 하나의 제어 평면으로 통합해 제품화한다는 점입니다. 개별 개발자가 손으로 배선하던 헤드리스 러너·훅·라우팅·스킬 선택을, 격리 샌드박스 실행과 정책 게이트·감사 로그로 감싸 거버넌스 가능한 형태로 올리는 것입니다. 온프레미스와 소버린 환경을 요구하는 국내 고객에게는 이 거버넌스 계층이 특히 중요합니다. 자율 에이전트가 무엇을 실행하고 어떤 시크릿에 접근했는지 전부 감사 로그로 남아야, 규제 환경에서 자율성을 실제로 켤 수 있기 때문입니다.

인프라 측면에서 ai-platform 렌즈도 함께 맞습니다. 헤드리스 러너와 서브에이전트 팬아웃은 결국 K8s 위에서 도는 워크로드이고, 모델 라우팅에 따른 haiku·sonnet·opus 호출은 서빙 비용으로 환산됩니다. 저비용 서빙 기반(ai-platform)이 있어야 자율 에이전트를 상시로 굴리는 경제성(Paxis)이 성립합니다.

한계 및 반론

자율성을 높일수록 통제와 검증의 부담이 커진다는 점을 직시해야 합니다. 첫째, 헤드리스 무인 실행은 실패가 조용히 누적될 위험이 있습니다. 사람이 지켜보지 않으므로, 인증 만료나 한도 초과 같은 문제가 여러 러너에 걸쳐 동시에 터질 수 있습니다. 실패를 즉시 감지해 알림을 보내는 후처리가 없으면, 자율성은 곧 조용한 고장으로 이어집니다.

둘째, 훅과 라우팅을 잘못 설계하면 매 턴 비용이 선형으로 늘어납니다. 상시 로드되는 규칙이 비대해지거나, 폴링성 작업을 에이전트 핫루프에 넣으면 자율화가 오히려 비용 폭증으로 돌아옵니다. 반복 모니터링은 에이전트가 아니라 cron으로 빼는 것이 원칙입니다.

셋째, 자동화가 사고를 대체하는 것이 아니라 보조하는 도구라는 점을 잊으면 안 됩니다. 루프가 깊어질수록 사람이 결과를 신뢰하고 검토를 멈추는 경향이 생깁니다. 핵심 산출물은 주기적으로 사람이 표본 검토해야 하고, 검증 게이트는 통과 편향이 아니라 반증 지향으로 설계해야 합니다. 아무것도 걸러 내지 못하는 검증기는 고장 신호로 봐야 합니다.

결론적으로 Claude Code의 자율 실행은 더 강한 모델이 아니라 잘 설계된 하네스에서 나옵니다. 헤드리스·훅·서브에이전트·스킬이라는 네 축은 각각 실행·강제·분업·전문성 공급을 담당하며, 이들을 검증 게이트와 감사 로그로 감쌀 때 비로소 규제 환경에서도 켤 수 있는 자율성이 됩니다.

출처

• Enabling Claude Code to work more autonomously (Anthropic)
• How we built Claude Code auto mode (Anthropic Engineering)
• Steering Claude Code: skills, hooks, rules, subagents and more (Claude 블로그)
• claude-code-action (GitHub, Anthropic)