Source: RT @dailyonjeje: 의사 협회에서 뽑은 최고의 아침식사래. · twitter

What this means for ThakiCloud

A healthy breakfast comes down to who holds the fridge key, not the ingredients. AI infrastructure is no different. Paxis lets you deploy as many agents as you need inside your own facility, instead of a public cloud that meters every bot that boils an egg. Metis runs inference and training on your own GPUs rather than someone else’s fridge, so you skip the per-berry billing. With an on-prem, sovereign stack you pick the menu and you can actually predict the check. What ThakiCloud sells isn’t a lease on someone else’s kitchen. It’s the kitchen, with no invoice attached.

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

이 한 문장이 왜 오늘의 뉴스 묶음을 관통하는지, 지금부터 하나씩 풀어보겠습니다.

“우리 모델”이라는 착시

소버린 AI라고 하면 대부분 같은 그림을 떠올립니다. 우리 손으로 만든 파운데이션 모델입니다. 실제로 정부는 5,300억 원 규모의 독자 파운데이션 모델 사업을 추진하고 있습니다. LG AI연구원, SK텔레콤, 업스테이지, 모티프테크놀로지스 네 팀이 6개월 단위로 경쟁하고, 8월 2차 평가를 거쳐 오픈소스로 전면 공개될 예정입니다. 목표는 2027년까지 세계 10위권 모델을 확보하는 것입니다.

여기까지만 보면 주권의 문제는 곧 모델의 문제처럼 보입니다. 그런데 오늘 다이제스트는 정반대 방향을 가리킵니다. 최 교수의 진단이 날카로운 지점이 바로 여기입니다. 모델을 국산화해도, 그 모델을 돌리는 학습 데이터와 GPU, 클라우드, 에이전트 도구가 전부 외부 생태계에 묶여 있다면 주권은 절반짜리라는 것입니다. 그는 기존 SBOM이나 SCA 같은 보안 도구가 모델 가중치처럼 코드가 아닌 자산을 읽지 못하는 가시성 공백을 지적하면서, 가중치와 학습 데이터셋, 하이퍼파라미터, 에이전트 도구 명세까지 담는 AI 자재명세서(AIBOM)를 대안으로 제시했습니다.

정리하면 이렇습니다. 모델은 화려한 간판이지만, 주권이 실제로 결정되는 곳은 그 모델이 살아 움직이는 바탕, 즉 실행 계층입니다. 오늘 뉴스에 등장한 여러 기업의 선택이 약속이라도 한 듯 이 지점을 향합니다.

한컴은 왜 ‘모델’이 아니라 ‘OS’라고 말했나

가장 상징적인 사건은 한컴입니다. 창립 36년 만인 지난 7월 2일 임시 주주총회에서 ‘한글과컴퓨터’라는 이름을 ‘한컴’으로 바꾸는 정관 개정안을 의결했습니다. 단순한 리브랜딩이 아닙니다. 문서 소프트웨어 회사에서 여러 AI 에이전트를 하나의 환경에서 연결하고 통제하는 ‘소버린 에이전틱 OS’ 기업으로 정체성을 옮기겠다는 선언이었습니다.

주목할 단어는 ‘OS’입니다. 한컴은 자기들이 만들 것을 ‘모델’이라 부르지 않았습니다. 운영체제라고 불렀습니다. 여러 에이전트를 안전하게 구동하고 통제하는 바탕을 겨냥한다는 뜻입니다. 하반기 베타를 예고했고, 폴란드 국가공인 연구센터와 유럽 현지화 공동연구에도 착수했습니다. 이 전환은 숫자로도 뒷받침됩니다. 지난해 89억 원으로 전체 매출의 5% 수준이던 AI 패키지 매출이 올해 1분기에는 52억 원, 비중 11.52%로 뛰었습니다.

같은 결의 움직임이 KT에서도 보입니다. KT는 서빙 로봇 약 4,000대를 통째로 매각하고 재임대하는 구조로 바꾸며 하드웨어 소유에서 손을 뗐습니다. 대신 제조사가 다른 로봇들을 한 화면에서 통합 제어하는 클라우드 운영 플랫폼에 베팅했습니다. 로봇을 파는 대신, 로봇들이 함께 돌아가는 바탕을 장악하겠다는 계산입니다. 파는 물건은 다르지만 방향은 같습니다. 개별 제품이 아니라 오케스트레이션 계층에서 가치가 나온다고 본 것입니다.

모델은 들어왔는데, 왜 여전히 불안한가

바탕이 왜 중요한지는 그 바탕이 흔들릴 때 가장 선명해집니다. 오늘 다이제스트의 두 기사가 그 장면을 보여줍니다.

먼저 금융권입니다. 지난해 은행권 금융사고 규모는 4,318억 원으로 역대 최고를 기록했습니다. 부천의 한 새마을금고에서는 242억 원 규모 불법 대출이 수년간 잡히지 않았습니다. 그래서 은행들은 앞다퉈 AI 이상거래탐지시스템을 도입하고 있습니다. 카카오뱅크는 시퀀스 탐지 모델을 적용한 뒤 금융사기 예방 건수가 월평균 4.4배 늘었다고 합니다. 여기까지는 성공담입니다.

문제는 그다음입니다. 국내 금융사 중 AI 모델을 자체 개발한 곳은 10%에 불과하고, 그중 다시 3분의 1은 클라우드 인프라와 모델, 데이터를 전부 외부 공급자에 의존합니다. 민감한 거래 데이터를 다루는 이상탐지 시스템이 정작 남의 바탕 위에서 돌아가는 셈입니다. 모델을 도입하는 것과 그 모델을 내 통제 아래 두는 것은 전혀 다른 문제입니다.

애플 협력사 사고는 이 불안의 극단을 보여줍니다. 아이폰 협력사 타타 일렉트로닉스가 랜섬웨어 공격을 받아 630GB, 20만여 개 파일이 다크웹에 공개됐습니다. 아이폰 신제품 공급업체 목록과 프로토타입 시험 사진까지 포함됐다고 합니다. 인도 정부의 침해대응팀이 조사에 착수했습니다. 눈여겨볼 대목은 이 패턴이 처음이 아니라는 점입니다. 2023년 TSMC의 IT 협력사, 2022년 도요타의 부품 협력사가 똑같이 뚫렸습니다. 본사가 아니라 협력사가 통로가 됩니다. 데이터가 여러 곳에 흩어져 협업 시스템에 얹혀 있는 한, 아무리 좋은 모델을 국산으로 만들어도 정보는 가장 약한 연결 고리에서 새어 나갑니다. 상반기 가상자산 해킹 피해의 66%가 북한 소행이었다는 오늘의 또 다른 기사는, 실행 계층의 취약성이 이미 국가 단위 위협의 표적이 되었음을 확인해 줍니다.

통제할 수 있는 것은 바탕뿐입니다

이 지점에서 최 교수의 문장으로 돌아가 봅니다. 통제 가능한 것은 남의 모델이 아니라, 어떤 모델을 쓰든 공급망을 검증하고 차단할 수 있는 인프라입니다. 뉴스가 던진 기업의 통증을 정리하면 네 가지로 좁혀집니다. 무엇이 실행되는지 감사할 수 있는가, 데이터와 실행을 내 주권 아래 둘 수 있는가, 한 곳이 뚫려도 전체로 번지지 않게 격리되는가, 그리고 이 모든 것을 감당 가능한 비용으로 운영할 수 있는가.

ThakiCloud가 Paxis를 Agent-Native Cloud로 설계한 이유가 바로 이 네 가지 질문에 있습니다. Paxis는 스킬과 도구, 정책, 감사 로그를 일급 리소스로 다룹니다. 에이전트가 무엇을 실행하는지 정책 게이트가 사전에 거르고, 실제로 무엇을 했는지 감사 로그가 사후에 남깁니다. 최 교수가 말한 AIBOM식 공급망 투명성이 지향하는 그림과 같은 방향입니다. 에이전트의 자율도를 L0에서 L3까지 등급으로 나눠 거버넌스를 거는 구조는, 금융권이 요구하는 통제 가능성을 계층 그 자체로 구현한 것입니다. 협업 워크로드를 격리 샌드박스에서 실행하는 방식은 애플 협력사 사고 같은 연쇄 유출을 물리적으로 끊어냅니다. 그리고 소버린 온프렘 쿠버네티스 위에서 돌아가기에, 민감 데이터를 외부 네트워크로 내보내지 않고 폐쇄망 안에 둘 수 있습니다. 작업마다 최적의 모델을 고르는 비용 라우팅은 네 번째 질문, 즉 지속 가능성에 대한 답입니다.

한컴이 굳이 사명을 바꿔가며 ‘OS’라는 단어를 고른 것도, KT가 로봇을 팔지 않고 플랫폼에 건 것도 결국 같은 통찰의 다른 표현입니다. 에이전트 시대의 가치는 개별 모델이 아니라, 에이전트가 살고 일하는 바탕에서 나옵니다. Paxis는 그 바탕을 감사 가능하고 주권적인 형태로 제공하는 제품입니다.

화려한 것은 모델, 결정되는 것은 바탕

오늘 하루에도 D램 슈퍼사이클과 1천조 원 데이터센터 전쟁, 빅테크의 자체 칩 경쟁 같은 굵직한 뉴스가 쏟아졌습니다. 헤드라인은 언제나 모델과 칩이 가져갑니다. 그러나 기업의 실무자가 밤에 잠 못 이루는 이유는 조금 다릅니다. 우리 에이전트가 지금 무엇을 하고 있는지 설명할 수 있는가, 사고가 나면 어디서 시작됐는지 추적할 수 있는가, 이 데이터가 정말 우리 손 안에 있는가 하는 질문입니다.

주권은 선언으로 완성되지 않습니다. 우리 모델을 만들었다는 사실만으로도 완성되지 않습니다. 그 모델이 어디서 실행되고, 무엇을 하도록 허락받았으며, 무슨 일을 했는지 언제든 열어볼 수 있을 때 비로소 주권이라 부를 수 있습니다. 오늘 뉴스가 조용히 가리키는 곳은 화려한 모델이 아니라, 그 아래 놓인 바탕입니다. 그리고 그 바탕을 먼저 다지는 쪽이 다음 라운드의 주도권을 쥐게 될 것입니다.

원 뉴스: RT @dailyonjeje: 의사 협회에서 뽑은 최고의 아침식사래. · twitter

ThakiCloud 제품 적용 시사점

건강한 아침의 핵심은 재료가 아니라 냉장고 열쇠를 누가 쥐느냐에 있습니다. AI 인프라도 다르지 않습니다. 파시스는 달걀 삶는 봇 하나까지 과금하는 퍼블릭클라우드 대신, 필요한 에이전트를 우리 시설 안에서 마음껏 풀도록 설계됐습니다. 메티스는 추론과 학습을 외부 냉장고가 아니라 자체 GPU 위에서 돌려, 블루베리 한 줌 클릭당 과금 같은 종량 폭탄에서 벗어나게 합니다. 온프렘 주권형 스택이라면 메뉴도 내가 정하고 계산서도 내가 예측합니다. ThakiCloud가 파는 건 남의 부엌 사용권이 아니라, 청구서가 붙지 않는 내 부엌 그 자체입니다.

이 만화는 업계 뉴스를 바탕으로 자동 생성된 초안입니다.

يكفي أن تقرأ أخبار الذكاء الاصطناعي المحلية ليوم واحد من النصف الأول من هذا العام حتى يتّضح المسار. تدفع شركات التأمين الذكاء الاصطناعي إلى ما هو أبعد من الردّ على الاستفسارات، نحو أعمال جوهرية مثل تقدير نسبة الخطأ في حوادث السيارات والاكتتاب. وانتقلت شركة Korea Midland Power إلى ما وراء الذكاء التوليدي، إلى ذكاء اصطناعي وكيلي ذاتيّ ينفّذ العمل فعلياً في تشغيل المحطة. فهو يعمل على شبكة معزولة، ويجمع تلقائياً حالات الشذوذ في المعدّات ويقدّم عنها إحاطة كل صباح. أمّا Microsoft وAmazon Web Services فتبني كلٌّ منهما تنظيماً مخصّصاً بآلاف الأفراد لإدماج الوكلاء داخل مواقع العملاء.

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

عنق الزجاجة ليس النموذج

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

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

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

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

لا يزول أيٌّ من هذه الجدران الثلاثة بترقية النموذج درجةً واحدة، لأنّها جميعاً مسألة أين تضع التشغيل.

لماذا تعجز السُّحُب التقليدية عن حلّها

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

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

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

التحكّم بوصفه منصّة، لا عُرفاً

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

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

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

وبإسقاط ذلك على الجدران الثلاثة، يتّسق الأمر هكذا:

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

بإسقاطه مباشرةً على أخبار اليوم

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

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

السؤال الباقي

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

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

المصادر

• Korea Midland Power تقدّم إحاطة صباحية يومية عن شذوذ المعدّات عبر HI-KOMI، وهو ذكاء اصطناعي وكيلي ذاتيّ يعمل على شبكة معزولة: Hankyung
• DB Insurance تحدّد نسبة الخطأ في حوادث السيارات من فيديو كاميرا لوحة القيادة بالذكاء الاصطناعي، بمتوسّط 5 ثوانٍ ودقّة 92.4%: Ajunews
• AWS تُدمِج نشر الوكلاء داخل مواقع العملاء عبر تنظيم Forward Deployed Engineering باستثمار مليار دولار: About Amazon
• Microsoft تؤسّس تنظيماً مخصّصاً لنشر الذكاء الاصطناعي (Microsoft Frontier) بالتزام قدره 2.5 مليار دولار و6,000 شخص: TechCrunch

انتشرت مؤخراً بين المطورين عبارة أثارت نقاشاً واسعاً: “لم أعد أُدخل موجّهات (Prompts) في Claude Code. أُشغّل حلقة تُدخل الموجّهات في Fable، ومهمتي الوحيدة هي كتابة تلك الحلقة.” العبارة استفزازية، لكن إذا نزعنا عنها المبالغة التسويقية، نجد فيها ملاحظة عملية ذات معنى حقيقي: وحدة العمل تنتقل من موجّه واحد إلى حلقة كاملة.

هذا التحول مختلف تماماً عن الحديث عن تحسّن النماذج. مهما كان النموذج قوياً، فإنه لا يستطيع إنجاز مهمة معقدة حتى النهاية من خلال طلب واحد ينتهي بموجّه واحد. لكن الأمر يتغير عندما يُبنى فوق بنية تكرارية يستدعي فيها النموذج أداة، ثم يستقبل نتيجتها كمُدخل جديد ليقرر الخطوة التالية. تُشغّل ThakiCloud مثل هذه الحلقات فعلياً في تطويرها الداخلي، إلى جانب تشغيل منصة AI/ML كخدمة (SaaS) قائمة على Kubernetes. لذلك فإن عبارة “كتابة حلقة” ليست بالنسبة لنا جملة رائجة، بل مهمة هندسية يومية. يستعرض هذا المقال ما تتكون منه هذه الحلقة فعلياً، وما الذي يجعلها موثوقة.

من الموجّه إلى الحلقة: ما الذي تغيّر

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

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

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

تشريح الحلقة: تكرار الملاحظة والحكم والتنفيذ

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

flowchart TB
    A[اقتراح النموذج للتغيير<br/>Act] --> B[التطبيق على قاعدة الكود]
    B --> C[تشغيل أداة خارجية<br/>اختبارات·مُجمّع·مدقق لغوي<br/>Observe]
    C --> D[تحليل المخرَج<br/>رسالة الخطأ·السطر·سبب الفشل<br/>Learn]
    D --> E{هل اجتازت<br/>بوابة الإنهاء؟}
    E -- "لا" --> F[إعادة حقن السياق في النموذج<br/>Repeat]
    F --> A
    E -- "نعم" --> G[إنهاء الحلقة<br/>تقارب]
    D -.استنفاد الميزانية.-> H[توقف·تسليم للإنسان]

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

البوابات الحتمية هي إشارة المكافأة

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

رسّخت ThakiCloud هذا المبدأ فعلياً في حلقاتها الداخلية. مثال بارز هو pge-loop، الذي يُطبّق الفروقات (diff) التي يقترحها النموذج على الخلفية البرمجية المبنية بلغة Go، ثم يُشغّل الأمر make test-short، ويُعيد تغذية كامل مخرَج stderr كسياق للاقتراح التالي. شرط الإنهاء هنا ليس حكماً ذاتياً من النموذج، بل رمز خروج الاختبار. وبالمثل، يسعى Goal Mode بشكل مستقل نحو تحقيق الهدف حتى شرط الإنجاز، لكنه يتحقق من تقدّم كل خطوة عبر أمر تحقق محدد مسبقاً، وتشكّل الميزانية (عدد التكرارات والتكلفة والمهلة الزمنية) سقفاً أعلى. فهو لا يدور إلى ما لا نهاية، بل يتوقف عند التقارب أو عند استنفاد الميزانية. من دون هاتين الآليتين، أي بوابة الإنهاء الحتمية وسقف الميزانية، تصبح الحلقة أداة لا يمكن الوثوق بها.

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

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

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

من هذا المنظور، تقابل البوابة الحتمية بوابة السياسات في Paxis بشكل طبيعي، ويقابل تنفيذ الأداة التنفيذ المعزول في الصندوق الرملي، ويقابل سجل ملاحظة الحلقة سجل التدقيق. والبنية التي تُحقّق فيها الحلقة من نفسها هي نفس المبدأ الذي تؤكد عليه Paxis تحت مسمى “إغلاق fan-out بالتحقق”.

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

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

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

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

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

وخلاصة القول، عبارة “لا أكتب موجّهات بل أكتب حلقات” استفزازية، لكنها تحمل مضموناً حقيقياً. غير أن هذا المضمون لا ينبع من نموذج مبهر، بل من تصميم مُملّ ولكنه دقيق يجعل الجهاز قادراً على الحكم بنفسه على ما يُعدّ نجاحاً. الدرس نفسه استخلصته ThakiCloud من pge-loop وGoal Mode: الحلقة الجيدة تنبع من شرط إنهاء جيد.

المصادر

• ميلز دويتشر (Miles Deutscher)، منشور على X (تويتر سابقاً)، رأي حول حلقات وكلاء البرمجة
• ممارسات ThakiCloud الداخلية في هندسة الحلقات: pge-loop، Goal Mode (بوابة تحقق + سقف ميزانية)

نظرة عامة

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

في أوائل يوليو 2026، شارك Theo مبتكر حزمة T3 كيف يشغّل Claude Fable 5 طوال اليوم دون بلوغ حدود المعدّل. الفكرة بسيطة. بدلاً من تكديس كل شيء على نموذج واحد، قسّم النموذج والجهد بحسب طبيعة العمل. في هذه المقالة نستعرض استراتيجياته الأربع مع اقتباسات حقيقية، ونضعها بجانب انضباط توجيه النماذج الذي تطبّقه ThakiCloud بالفعل في تشغيل Paxis وai-platform.

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

المشكلة: حدود المعدّل مسألة تخصيص لا جودة

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

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

استراتيجيات Theo الأربع

1. اجعل الجهد الافتراضي high واحتفظ بـ xhigh وmax

يقول Theo إنه يستخدم Fable على جهد “high” فقط في الوقت الحالي. بكلماته، xhigh “نهم للرموز”، وmax وextra هما “فرن بمخرجات أسوأ من الخيارات الأدنى”.

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

2. نسّق Codex كمنفّذ فرعي

الاستراتيجية الثانية هي جعل النماذج طبقات. علّم Theo نظام Claude Code أن يستدعي Codex (GPT-5.5) كمنفّذ فرعي لعمل التنفيذ. وبحسب ملاحظته، فإن GPT-5.5 قابل للتوجيه بدرجة عالية، لذا يستطيع Fable تعلّم كيفية توجيهه.

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

3. أعلن أولوية النماذج في CLAUDE.md

الثالثة هي تصليب هذا التوجيه كعقد لا كارتجال. كتب Theo قسماً كبيراً في ملف CLAUDE.md حول أي نموذج يُقدَّم لأي عمل، وكيفية التخصيص عند تنسيق الوكلاء الفرعيين وسير العمل.

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

4. أسنِد العمل كثيف الرموز واستردّ النتائج فقط

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

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

مرسومة كتدفّق واحد، تبدو الاستراتيجيات الأربع هكذا.

flowchart TB
    A[وصول المهمة] --> B{تصنيف نوع المهمة}
    B -->|الحكم التفرّع التنسيق| C[Fable 5 قائد بجهد high]
    B -->|البحث grep قراءة الملفات| D[منفّذ منخفض الكلفة]
    B -->|التنفيذ بالجملة| E[Codex GPT-5.5 منفّذ]
    D -->|إعادة الملخّص فقط| C
    E -->|إعادة المنتَج| C
    C --> F{هل يلزم استدلال عميق؟}
    F -->|نعم| G[الترقية إلى xhigh max باعتدال]
    F -->|لا| H[الإبقاء على high]
    G --> I[تركيب النتائج]
    H --> I

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

تُقرأ نصائح Theo كتأكيد مرحّب به لأن منصة الوكلاء Paxis من ThakiCloud تقف بالفعل على المبدأ نفسه. Paxis هي مستوى تحكّم Agent-Native Cloud يعمل فوق ai-platform، ويتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. وضمنها، توجيه النماذج ليس زينة بل عمود التكلفة الفقري.

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

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

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

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

القيود والاعتراضات

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

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

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

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

المصادر

• Theo (@theo)، “I’ve been getting a TON done with Fable today and I’m not hitting rate limits”: x.com/theo/status/2072481845363822914
• “T3 Stack creator Theo shares Fable AI workflow”، digg.com: digg.com/tech/wmowks0x
• “Fable Is Back. Here’s How to Actually Code With It”، Wavect: wavect.io/blog/coding-with-claude-fable-5

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

ما هذه التقنية

المستودع في قلب النقاش هو autonomous-ai/autonomous-computer، وهو دليل مفتوح المصدر صادر برخصة MIT لبناء حاسوب ذكاء اصطناعي في المنزل من الصفر. ما يميزه أنه لا يشرح بالنص وحده. يأتي كل بناء مع قائمة مواد (BOM) تحمل الأسعار وروابط الشراء، وملفات ثلاثية الأبعاد (STL و STEP) لطباعة الهيكل أو تصنيعه، ومخطط أسلاك، وقيم ضبط BIOS، وصور تجميع خطوة بخطوة. أما جانب البرمجيات فيمتد من تثبيت نظام التشغيل وبرامج تعريف NVIDIA، مرورًا بثلاثة محركات استدلال (Ollama و vLLM و llama.cpp)، وصولًا إلى ربط وكيل محلي.

تُقدَّم ثلاثة تكوينات.

• Home: بطاقتا RTX 5090، بإجمالي 64GB من VRAM
• Business: تكوين من 8 بطاقات GPU، بإجمالي نحو 256GB من VRAM
• Team: أربع بطاقات RTX PRO 6000 Blackwell، بإجمالي 384GB من VRAM

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

يبدو التدفق الكلي على النحو التالي.

flowchart TB
    A[تحديد الميزانية والنموذج المستهدف] --> B[تقدير ميزانية VRAM]
    B --> C{أي تكوين بناء}
    C -->|64GB| D[Home<br/>بطاقتا RTX 5090]
    C -->|256GB| E[Business<br/>8 بطاقات GPU]
    C -->|384GB| F[Team<br/>4 RTX PRO 6000]
    D --> G[اختيار محرك الاستدلال]
    E --> G
    F --> G
    G -->|تشغيل محلي بسيط| H[Ollama / llama.cpp]
    G -->|خدمة عالية الإنتاجية| I[vLLM]
    H --> J[ربط الوكيل المحلي]
    I --> J

ذاكرة VRAM تحدد الجدوى

أيّ نموذج يعمل محليًا يعود عمليًا إلى ذاكرة VRAM وحدها. القاعدة التقريبية التي استقر عليها المجتمع واضحة. عند FP16 (نصف الدقة) تحتاج إلى نحو 2GB لكل مليار معامل؛ وعند التكميم من فئة INT4 (Q4) نحو 0.5GB؛ وفوق ذلك تضيف 15 إلى 20 بالمئة لذاكرة KV cache والتنشيطات وحمل إطار العمل. بعبارة أخرى، عند Q4 يكون الحد الأدنى من VRAM تقريبًا “عدد المعاملات (B) × 0.5 × 1.2”.

يعطي تطبيق هذه الصيغة على أحجام نماذج تمثيلية الجدول أدناه. وتتضمن هذه القيم حمل الـ 20 بالمئة.

هذا الحساب ليس اختراعًا اعتباطيًا؛ بل يتقاطع مع أدلة منشورة. فتشغيل Llama 3 70B عند Q4_K_M يُبلَّغ عنه بأنه يحتاج نحو 40 إلى 43GB، وهو ما يطابق القيمة المحسوبة 42GB. ويُقال إن نموذجًا من فئة 122B مثل Qwen 3.5 122B يحتاج 70 إلى 81GB عند Q4، والقيمة المحسوبة 73GB تقع ضمن هذا النطاق. أما Llama 3.1 405B فيصل إلى 243GB عند Q4، وهو ما يطابق الجدول تمامًا. وللإشارة، فإن Q4_K_M هو المعيار المجتمعي الذي يكاد لا يُميَّز عن Q8 في معظم المهام، مع ارتفاع في الحيرة (perplexity) بنحو 0.2 إلى 0.5 فقط مقارنةً بـ FP16.

ما الذي يشغّله كل بناء فعليًا

بمطابقة متطلبات VRAM المحسوبة على خطوط السعة للتكوينات الثلاثة، تتضح الصورة.

يعمل النموذج على تكوين معيّن حين يقع عموده تحت خط سعة ذلك التكوين. وباختصار:

• Home (64GB): يستوعب بأريحية 70B عند Q8 و 122B عند Q4. وهذا يكفي للتجارب الشخصية ومساعدة البرمجة لفريق صغير.
• Business (256GB): يمكنه دفع نموذج من فئة 235B قريبًا من Q8، وهو مناسب لإبقاء عدة نماذج متوسطة مقيمة في آنٍ واحد لأغراض التوجيه.
• Team (384GB): يحمّل 405B عند Q4 (243GB) ويبقى لديه 141GB. وهذا الفائض هو ما يمتص فعليًا ذاكرة KV cache للسياقات الطويلة والطلبات المتزامنة.

هناك نقطة يسهل إغفالها هنا. الأرقام في الجدول ليست سوى “الحد الأدنى اللازم لتحميل الأوزان”. في الاستخدام الفعلي، ومع نمو طول السياق وعدد المستخدمين المتزامنين، تتضخم ذاكرة KV cache بأسرع من الخطي وتلتهم ميزانية VRAM. فتكوين “يكاد يتسع” فيه 405B وآخر “يخدمه بمساحة فائضة” قصتان مختلفتان تمامًا.

دلالات لـ ThakiCloud

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

تصف منصة ai-platform وحدات GPU وتجدولها باستخدام Kueue فوق Kubernetes، وتخدم النماذج بتعدد المستأجرين عبر vLLM. في البناء الشخصي يحتكر شخص واحد أربع بطاقات GPU، أما في المؤسسة فتتنافس فرق متعددة ونماذج متعددة على مجمّع GPU نفسه. وما يلزم حينها هو عزل المستأجرين، والاصطفاف العادل، والجدولة القائمة على الأولوية، ومراقبة الاستخدام والتكلفة. فالقرار اليدوي في البناء الشخصي بـ”تحميل هذا النموذج فقط الآن” هو ما تُؤتمِته المنصة عبر السياسة والمجدول.

وتشير الاقتصاديات في الاتجاه نفسه. فإذا كان “امتلك ذكاءك” في البناء الشخصي هو منطق تأمين سيادة البيانات والتحكم عبر العتاد، فإن منصة ai-platform تحقق المنطق نفسه على نطاق المؤسسة. إن النشر داخل المؤسسة والسيادي، وانخفاض تكلفة الخدمة لكل وحدة، والتحكم في البيانات عبر الاستضافة الذاتية، أمور تحمل وزنًا خاصًا في بيئات العملاء التي يجب أن تلبي المتطلبات التنظيمية المحلية. كما أن رفع معدل استغلال وحدات GPU من فئة RTX PRO 6000، التي يصعب على فرد تبريرها، عبر مشاركتها بين أعباء عمل كثيرة، هو أمر لا تقدر عليه سوى منصة.

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

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

قبل تبنّي رومانسية البناء الشخصي، تستحق بعض الحقائق الانتباه.

أولًا، تكلفة العتاد نفسه وعبء تشغيله. فتكوين من أربع بطاقات RTX PRO 6000 Blackwell يحمل نفقات رأسمالية أولية كبيرة، وتتبعه باستمرار الطاقة والحرارة والضوضاء والصيانة. كما أن الجهاز الواحد هو نقطة فشل واحدة.

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

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

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

المصادر

• autonomous-ai/autonomous-computer (GitHub)
• Autonomous Computer: Build Your Own Home AI (writeup)
• Best Local AI Models by VRAM: 8GB to 384GB (2026)
• GPU Memory Requirements for LLMs (Spheron)
• Build an AI PC in 2026: Complete Hardware Guide (Local AI Master)
• شارَكه أصلًا @tom_doerr، أدلة بناء حاسوب الذكاء الاصطناعي الشخصي

تُعد المراجعة العلمية من الأقران (peer review) عنق زجاجة منذ زمن طويل. حجم الأبحاث المقدمة يتضخم كل عام، بينما لا يزداد الوقت المتاح للمراجعين. والنتيجة أن أخطاء مهمة تمر عبر المراجعة وتُنشر، ثم يُصار لاحقا إلى تصحيحها أو سحبها. أداة Paper Assistant Tool (PAT) التي كشفت عنها جوجل مؤخرا تستهدف هذه المشكلة مباشرة. تستقبل PAT الورقة العلمية الكاملة بعد اكتمالها، وتفحص النتائج النظرية، وتتحقق من التجارب، وتقترح تحسينات، وتشير إلى العيوب المحتملة، ضمن إطار مراجعة قائم على العملاء (agentic).

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

ما هو هذا البحث

الخيار التصميمي الجوهري في PAT هو توسيع الاستدلال (inference scaling). وبشكل ملموس، تستخدم الأداة Gemini Deep Think لتقوم باستدلال عميق عبر مراحل متعددة بدلا من إعطاء إجابة من طلب واحد. مراجعة الأبحاث في جوهرها عملية تحليل معقدة تمتد لوقت طويل. فللحكم على ما إذا كان إثبات نظرية (theorem) صحيحا فعلا، وما إذا كان إعداد التجربة يدعم النتائج، وما إذا كانت هناك تناقضات مع الأبحاث السابقة المستشهد بها، لا تكفي استجابة واحدة. تنفذ PAT هذا الحكم عبر تقسيمه إلى مراحل استدلال متعددة.

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

flowchart TB
    A[إدخال الورقة العلمية الكاملة] --> B[Gemini Deep Think<br/>توسيع الاستدلال]
    B --> C[التحقق من النتائج النظرية<br/>فحص الإثباتات والمعادلات]
    B --> D[التحقق من التجارب<br/>اتساق الإعداد والنتائج]
    B --> E[مقارنة الأبحاث السابقة<br/>كشف التناقض والتكرار]
    C --> F[تحديد العيوب + اقتراح تحسينات]
    D --> F
    E --> F
    F --> G{مرحلة التعاون}
    G -- "مساعدة أولية" --> H[ملاحظات للمؤلف<br/>تعديل قبل التقديم]
    G -- "مساعدة في المراجعة" --> I[ملخص وعيوب للمراجعين<br/>القرار النهائي للإنسان]

النتائج الأساسية

قيست أداء PAT على معيار SPOT، وهو مجموعة بيانات مكونة من أوراق علمية سُحبت أو تأكد وجود أخطاء فيها. في هذا المعيار، سجلت PAT دقة كشف بلغت 89.7% للأخطاء الرياضية والمنطقية، وهو تحسن بنحو 34% مقارنة بخط الأساس بدون تدريب مسبق (zero-shot). وهذا يعني أن توسيع الاستدلال التقط جزءا كبيرا من الأخطاء التي كانت تفوت الطلب الواحد.

الأكثر إثارة للإعجاب هو نتائج النشر الفعلي. استُخدمت PAT في تجربتين تجريبيتين ضمن مؤتمري STOC 2026 وICML 2026، وراجعت أكثر من 4,700 ورقة مقدمة. وخلال هذه العملية، اكتُشفت أخطاء نظرية ذات دلالة في أكثر من ثلث أوراق ICML، ويُذكر أن 31% من المؤلفين دُفعوا لإجراء تجارب جديدة [تقديري: بحسب ما أعلنته الورقة البحثية]. إذا صحت هذه الأرقام، فهذا يعني أن المراجعة الآلية تجاوزت بالفعل مرحلة العرض التجريبي في المختبر وبدأت تؤثر في عمليات المؤتمرات الفعلية.

بطبيعة الحال، هذه الأرقام مقدمة من جهة مؤلفي الورقة نفسها، لذا ينبغي قراءتها بحذر إلى أن تُؤكد بإعادة إنتاج مستقلة. ومع ذلك، فإن تقديم كل من المعيار (SPOT) والنشر الفعلي (STOC/ICML) معا، إضافة إلى قياس ليس فقط اكتشاف الأخطاء بل أيضا تغيّر سلوك المؤلفين (إجراء تجارب جديدة)، يعكس منهجية جادة.

تصنيف التعاون بين الذكاء الاصطناعي والإنسان في أربع مراحل

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

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

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

ترتبط فلسفة التصميم في هذا البحث ارتباطا مباشرا بـ Paxis من ThakiCloud. Paxis هي مستوى تحكم للسحابة الأصلية للعملاء (Agent-Native Cloud) يعمل فوق ai-platform، ويتخذ من إغلاق تفرع المهام (fan-out) بالتحقق مبدأ جوهريا. رفض PAT للطلب الواحد ورفعها لمعدل كشف الأخطاء عبر توسيع الاستدلال ينبع من نفس الوعي الذي يقوم عليه أسلوب Paxis في عدم دمج نتائج العملاء الفرعيين المتوازيين مباشرة، بل تصفيتها عبر مرحلة تحقق خصومية (adversarial). فبنية إطلاق عدة مدققين متشككين من زوايا مختلفة ثم حسم العيوب بالتصويت تتطابق تماما مع فحص PAT المتقاطع للإثباتات والتجارب عبر مراحل استدلال متعددة.

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

من الناحية البنيوية، تكمل عدسة ai-platform هذه الصورة. توسيع الاستدلال يعني بالضرورة زيادة تكلفة الاستدلال. فمراجعة ورقة واحدة بعمق عبر مراحل متعددة تتطلب كما أكبر من الرموز (tokens) والحوسبة. تستوعب ai-platform هذا الحمل الاستدلالي المتكرر بكفاءة اقتصادية عبر جدولة وحدات معالجة الرسوميات (GPU) القائمة على كوبرنيتس وKueue، وخدمة النماذج عبر vLLM، والعزل متعدد المستأجرين. تشغيل حمل عمل يراجع كميات كبيرة من الأبحاث بشكل مستمر واقتصادي يتطلب هذه البنية التحتية للخدمة كشرط مسبق. وبالنسبة للمؤسسات البحثية ذات المتطلبات المحلية (on-premises) والسيادية، فإن القدرة على مراجعة الأبحاث الحساسة غير المنشورة داخل بنيتها التحتية الخاصة دون إرسالها إلى جهة خارجية تشكل ميزة تنافسية مهمة أيضا.

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

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

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

ثالثا، كلما تعمقت أتمتة المراجعة، قد ينشأ تراخ إدراكي (cognitive complacency) لدى المراجعين يجعلهم يقبلون حكم الذكاء الاصطناعي دون تمحيص. الموقف القائل “الذكاء الاصطناعي راجعه بالفعل، فلا بد أنه سليم” هو نمط الفشل الأكثر خفاء. المراجعة الآلية أداة تساعد الحكم البشري ولا تحل محله، ويبقى الحكم الجوهري مسؤولية الإنسان في نهاية المطاف. يبدو أن إبقاء PAT مرحلة التعاون محافظة وترك سلطة القرار النهائي للإنسان تصميم واعٍ لهذا الخطر.

باختصار، تُعد PAT مثالا مهما يُظهر أن المراجعة العلمية الآلية بدأت تتجاوز مرحلة العرض التجريبي لتدخل عمليات المؤتمرات الفعلية. غير أن قوتها لا تأتي من نموذج واحد لامع، بل من تصميم حذر يوسّع الاستدلال عبر مراحل متعددة ويترك الحكم النهائي للإنسان. وهذا يتفق مع الدرس الذي تعلمته ThakiCloud من خط أنابيب مراجعة الأبحاث وحلقة التحقق في Paxis. التحقق الجيد ينبع من البنية الجيدة.

المصادر

• Towards Automating Scientific Review with Google’s Paper Assistant Tool، arXiv:2606.28277: arxiv.org/abs/2606.28277
• Hugging Face Papers: huggingface.co/papers/2606.28277

نظرة عامة

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

تحتفظ Anthropic بمستند رسمي لأفضل ممارسات الموجّهات لنماذجها الأحدث. يغطّي هذا الدليل النماذج الحالية بما فيها Claude Fable 5 وClaude Sonnet 5 وClaude Opus 4.8، ويفصل أين يتصرّف كل نموذج بشكل مختلف، وأي التقنيات تنطبق عموماً على كل النماذج، وما ينبغي إصلاحه عند الانتقال من جيل أسبق. في هذه المقالة نعرض بنيته وتقنياته الأساسية، ونربطه بكيفية تعامل ThakiCloud مع الموجّهات كعقود لا كارتجال داخل منصة الوكلاء Paxis.

ما هذا الدليل

مستند الموجّهات من Anthropic منظّم في ثلاثة أجزاء كبيرة.

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

مرسومة كصورة، تبدو هذه البنية الثلاثية هكذا.

flowchart TB
    A[دليل الموجّهات] --> B[إرشاد خاص بالنماذج]
    A --> C[تقنيات مشتركة]
    A --> D[الترحيل]
    B --> B1[فروق سلوك Fable 5 Sonnet 5 Opus 4.8]
    C --> C1[تعليمات واضحة]
    C --> C2[أمثلة متعددة]
    C --> C3[سلسلة التفكير CoT]
    C --> C4[البنية بوسوم XML]
    C --> C5[موجّهات الأدوار]
    C --> C6[تسلسل الموجّهات]
    C --> C7[التفكير الممتد استخدام الأدوات]
    D --> D1[ترحيل موجّهات الجيل الأسبق]

بمعزل عن المستند، تنشر Anthropic أيضاً دليلاً تفاعلياً لهندسة الموجّهات في تسعة فصول، لتتعلّم بتشغيل الأمثلة والتمارين مباشرة.

التقنيات الأساسية

التقنيات التي يشدّد عليها الدليل ليست حيلاً برّاقة بل أساسيات مكرّرة. مرتّبة بحسب الأثر العملي:

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

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

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

البنية بوسوم XML رابعاً. فصل التعليمات والسياق والأمثلة وبيانات الإدخال بوسوم يمنع النموذج من الخلط بين دور كل جزء. الأثر كبير بخاصة عند التعامل مع سياق طويل.

موجّهات الأدوار خامساً. إعطاء النموذج منظوراً محدّداً أو دور خبير ينتج مفردات وحكماً يلائمان ذلك السياق. وهو مفيد للمراجعة والتدقيق وتحليل مجال محدّد.

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

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

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

هذا الدليل عملي لنا لأن منصة الوكلاء Paxis من ThakiCloud تتعامل مع الموجّهات بهذه الطريقة بالضبط. Paxis مستوى تحكّم Agent-Native Cloud يعمل فوق ai-platform، ويدير المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. وضمنها، الموجّه ليس شيئاً مرتجلاً يُؤلَّف من جديد كل مرة بل عقد مُحزَّم في مهارة وخاضع للتحكّم في الإصدارات.

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

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

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

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

القيود والاعتراضات

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

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

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

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

المصادر

• “Prompting best practices”، Claude Platform Docs: platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• “Prompt engineering overview”، Anthropic Docs: docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• “Anthropic’s Interactive Prompt Engineering Tutorial”، GitHub: github.com/anthropics/prompt-eng-interactive-tutorial

Read a single day of domestic AI news from the first half of this year and the pattern is clear. Insurers are pushing AI past chat support into core work like accident fault assessment and underwriting. Korea Midland Power has moved beyond generative AI to an autonomous, agentic AI that actually executes work across plant operations. Running on an air-gapped network, it automatically compiles equipment anomalies and briefs them every morning. Microsoft and Amazon Web Services are each building dedicated organizations, thousands of people strong, to embed agents inside customer sites.

They share one thing: the question has changed. Until last year the question in the meeting room was “should we adopt this.” The question practitioners are wrestling with now is “how do we run this safely.” As agents step off the demo stage and take the night shift, the center of gravity has shifted from performance to operations.

The Bottleneck Is Not the Model

Let me clear away the common misconception first: the idea that a better model will solve it. Put an agent in the field and the thing that blocks it is not the model’s reasoning ability. It is three operational walls.

The first is unauditability. If you cannot reconstruct after the fact why the agent made a decision, and which tools it called in what order, then in heavily regulated domains like finance or the public sector, production approval simply never comes. Insurance underwriting automation stands exactly on this line. Right or wrong, a system that cannot explain its decision path will not survive in front of a supervisor.

The second is sovereignty and supply chain. The point that recent sovereign-AI coverage drives home is the core issue: model sovereignty alone is no longer enough. You must also verify the provenance and integrity of the open-source packages, datasets, and agent tooling layer on which the model actually runs. The more a financial firm handles sensitive medical and personal data, the more network isolation and on-prem become preconditions rather than negotiating points.

The third is safe execution. The moment an agent runs code and calls external tools, an unisolated execution environment is itself a seed of incident. A single wrong tool call can lead to data exfiltration or an irreversible change.

None of these three walls disappears by scaling the model one notch. They are all questions of where you place operations.

Why Conventional Clouds Cannot Solve It

Over the last fifteen years, the cloud succeeded at abstracting virtual machines, databases, and networks into first-class resources. Spinning up a server on demand, attaching permissions, and leaving logs became standardized at the platform level. But put an agent on top and the story changes.

The core concepts of an agent are not servers. They are: which capability it uses, which tools it can access, under which policy it operates, and what it did. In conventional clouds these four remain not first-class resources but side effects scattered through application code. Audit logs are left to each team, policy is buried in prompt sentences, and tool permissions are managed through API keys scattered here and there.

The result is that control rests on practice rather than on the platform. When teams change and people leave, that practice leaves with them. “We do it that way by convention” is not an answer that holds up in front of a regulator. Control has to be reproducible and enforced, and that is the platform’s responsibility, not that of individual code.

Control as Platform, Not Practice

The premise Paxis chose is simple: the first-class resources of the agent era are not virtual machines but Skills, Tools, Policies, and Audit Logs. Just as conventional clouds handle servers and networks, Paxis raises these four into resources the platform manages directly.

Skills treats an agent’s capabilities as versioned resources. Registering, verifying, and revoking a capability happens at the platform level, not inside an individual project. Tools defines tool access declaratively. Which agent may call which tool and when is judged by policy up front. Policies specifies autonomy explicitly. Because execution proceeds only through a defined approval gate, the line an agent must not cross is embedded in the execution path rather than in a document. Audit Logs is the default gateway every action passes through. Reconstruction after the fact is the default, not the exception.

Every agent action is checked at the policy gate against autonomy and approval rules; only allowed execution proceeds through skills, tools, and an isolated sandbox. Regardless of the outcome, every action is recorded in the audit log, and the whole process runs on top of sovereign Kubernetes that is on-prem and air-gapped.

Mapped onto the three walls, it lines up like this:

The point is that when an agent schedules its own work, runs code in an isolated sandbox, and pulls knowledge from a team wiki, every one of those actions must pass through the policy gate and the audit log. Control rests on the structure of the platform, not on the diligence of a person.

Mapping It Straight Onto Today’s News

For an insurer, underwriting automation makes auditable execution a condition of approval. If no decision path remains, it will not clear the regulatory bar, and Audit Logs fills that requirement. The argument that sovereign AI must widen into supply-chain sovereignty reads as a demand to verify the provenance and integrity of not just the model but the skill and tool layers in the deployment pipeline. The network isolation and on-prem that financial firms require connect directly to the premise of running agents on sovereign K8s infrastructure.

You can read the same news two ways. One is the surface: “agent adoption is accelerating.” The other is the question: “is the operational foundation ready to carry that speed.” Now that the adoption bottleneck has moved from performance to operations, whoever answers the second question takes the next step.

The Question That Remains

Infrastructure competitiveness in the agent era is not decided by one faster GPU. It is decided by whether there is a control plane you can trust to hand work to. Adoption has already begun, and the choice left to practitioners is whether to leave operations to practice or to a platform. Paxis chose the latter. An Agent-Native Cloud that treats an agent’s capabilities, tools, policies, and audits as first-class resources from the start is the answer.

If you are weighing how to put agents into production in a field with strong audit and sovereignty requirements, like finance or the public sector, you can validate it together with ThakiCloud at the pilot stage. Laying the control plane from the start, instead of bolting it on later, turns out to be the faster path.

Sources

• Korea Midland Power briefs equipment anomalies every morning with HI-KOMI, an autonomous agentic AI on an air-gapped network: Hankyung
• DB Insurance determines automobile accident fault from dashcam video with AI, averaging 5 seconds at 92.4% accuracy: Ajunews
• AWS embeds agent deployment inside customer sites with a $1 billion Forward Deployed Engineering organization: About Amazon
• Microsoft stands up a dedicated AI deployment organization (Microsoft Frontier) with a $2.5 billion, 6,000-person commitment: TechCrunch