نظرة عامة

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

في يوليو 2026، وسّعت Anthropic ميزة Artifacts في Claude Code لتشمل خطتي Pro وMax. فقدرة كانت محصورة في خطتي Team وEnterprise باتت متاحة الآن للمطورين الأفراد. الفكرة بسيطة: حين تطلب artifact، يكتب Claude الشيفرة وينشرها مباشرةً على claude.ai، ويواصل تحديث تلك الصفحة في الوقت الفعلي بينما تستمر الجلسة. الصفحة خاصة بحسابك ومكتفية ذاتياً بالكامل.

يشرح هذا المقال ما هي Artifacts في Claude Code بدقة، ولماذا يهمّ توسّعها إلى Pro وMax، وكيف يمكن استيعاب هذا النمط من منظور منصة الوكلاء Paxis وبنية الذكاء الاصطناعي ai-platform لدى ThakiCloud.

ما هي Artifacts في Claude Code

كانت Artifacts في الأصل تعرض الشيفرة أو المستندات في لوحة منفصلة داخل محادثة claude.ai. أما Artifacts التي وصلت للتو إلى Claude Code فمختلفة قليلاً. فبدلاً من مخرَج تبادل واحد، تحوّل تقدّم جلسة برمجية كاملة إلى صفحة بصرية حية واحدة.

تسرد Anthropic أربعة استخدامات نموذجية: شروحات طلبات الدمج (PR walkthroughs)، وصفحات شرح النظام، ولوحات المعلومات، وقوائم مراجعة الإصدار. القاسم المشترك بينها أن كلّاً منها ملخّص يقرأه الإنسان لما يجري الآن. وبينما تواصل الجلسة عملها، تحدّث تلك الصفحة نفسها.

يبدو المسار من العمل إلى النشر على النحو التالي.

flowchart TB
    A[المطور يطلب artifact] --> B[Claude Code يكتب الشيفرة]
    B --> C[النشر المباشر على claude.ai]
    C --> D{الجلسة تستمر}
    D -->|تغيّر حالة العمل| E[تحديث الصفحة في الوقت الفعلي]
    E --> D
    D -->|اكتمال| F[تثبيت صفحة مكتفية ذاتياً]
    F --> G[مشاركة رابط النشر]
    G --> H[المتلقّي يطّلع دون حساب]
    G --> I[صاحب الحساب ينسخ عبر remix]

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

لماذا يهمّ التوسّع إلى Pro وMax

كانت الميزة نفسها متاحة على Team وEnterprise منذ بضعة أشهر. التغيير الأساسي الآن هو أن حدّ الخطة انخفض.

بدقّة: كانت Artifacts العادية المُنشأة في محادثة claude.ai قابلة للنشر أصلاً على كل الخطط بما فيها Free وPro وMax. أما Artifacts التي تحوّل جلسة Claude Code إلى صفحة حية فكانت حصراً على Team وEnterprise. وقد امتدّ هذا الحدّ الآن إلى Pro وMax. فبدون مقعد مؤسسي، يستطيع المطور الفرد تحويل جلسته إلى صفحة قابلة للمشاركة.

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

ملاحظة إضافية: خلال الفترة نفسها، رفعت Anthropic مؤقتاً الحدود الأسبوعية لاستخدام Claude Code لخطط Pro وMax وTeam. فُتح الوصول والهامش معاً، ما يمنح المطورين الأفراد مساحة حقيقية لتجربة الميزة.

كيف تعمل عملياً

استخدامها أقرب إلى المحادثة. أثناء الجلسة، حين تقول “حوّل هذا العمل إلى artifact”، يولّد Claude Code صفحة تلتقط التقدّم الحالي وينشرها على claude.ai. افتح الرابط المُعاد وسترى صفحة بصرية تلخّص العمل حتى الآن، وبينما تستمر الجلسة تتحدّث الصفحة دون إعادة تحميل.

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

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

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

ماذا يعني ذلك لـ ThakiCloud

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

عدسة Paxis (مخرَج الوكيل كمورد من الدرجة الأولى). إن Paxis من ThakiCloud هي مستوى تحكّم Agent-Native Cloud يعمل فوق ai-platform ويتعامل مع Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. وما تُظهره Artifacts في Claude Code هو طريقة لكشف مخرَج الوكيل الوسيط والنهائي كقناة مراقبة منفصلة. فحين تنفّذ شبكة DAG من وكلاء متعددين في Paxis مهمة طويلة، يتيح تكثيف تقدّم كل عقدة في صفحة حية يقرأها الإنسان للمشغّل أن يستوعب المسار دون تمرير السجلات. وبدمج ذلك مع بوابات السياسات وسجلات التدقيق في Paxis، يصبح الأثر مخرَجاً محكوماً يمكن تتبّعه حتى “مَن أنشأ وشارك ماذا ومتى”. وبالروح نفسها لأثر Anthropic الخاص افتراضياً، يمكن لـ Paxis إضافة تحكّم بالوصول قائم على السياسات لمشاركة المخرَجات وتوسيعه إلى مستوى المؤسسة.

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

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

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

هناك نقاط واضحة ينبغي فيها تعديل التوقعات.

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

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

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

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

المصادر

• منشور إعلان ClaudeDevs (@ClaudeDevs)
• Publish and share artifacts (Claude Help Center)
• What are artifacts and how do I use them? (Claude Help Center)

Overview

When a coding agent finishes hours of work, showing the result to someone else is still surprisingly clumsy. You capture terminal logs and paste them, summarize the changes by hand, or build a separate dashboard. Explaining the work often takes more effort than the work itself.

In July 2026, Anthropic expanded the Artifacts feature in Claude Code to the Pro and Max plans. A capability that had been limited to Team and Enterprise is now open to individual developers. The idea is simple. When you ask for an artifact, Claude writes the code, publishes it live to claude.ai, and keeps updating that page in real time while the session runs. The page is private to your account and fully self-contained.

This post explains exactly what Claude Code artifacts are, why the Pro and Max expansion matters, and how the pattern can be absorbed from the perspective of ThakiCloud’s agent platform Paxis and its AI infrastructure ai-platform.

What Claude Code Artifacts Are

Artifacts originally rendered code or documents in a separate panel inside a claude.ai conversation. The artifacts that just arrived in Claude Code are a little different. Instead of the output of a single exchange, they turn the progress of an entire coding session into one living visual page.

Anthropic lists four example uses: PR walkthroughs, system explainer pages, dashboards, and release checklists. What they share is that each is a human-readable summary of what is happening right now. And while the session continues its work, that page updates itself.

The flow from work to publication looks like this.

flowchart TB
    A[Developer requests an artifact] --> B[Claude Code writes the code]
    B --> C[Publish live to claude.ai]
    C --> D{Session keeps running}
    D -->|work state changes| E[Page updates in real time]
    E --> D
    D -->|complete| F[Self-contained page finalized]
    F --> G[Share the published link]
    G --> H[Recipient views without an account]
    G --> I[Account holder remixes an editable copy]

Two design decisions stand out here. First, the page is self-contained. Without an external build pipeline or hosting setup, everything it needs lives in the single published page. Second, the default is private. The page belongs to your account, and nobody else can see it until you press publish and share the link.

Why the Pro and Max Expansion Matters

The feature itself had been available on Team and Enterprise for a few months. The key change now is that the plan boundary has moved down.

To be precise: regular artifacts created in a claude.ai conversation could already be published on every plan, including Free, Pro, and Max. The artifacts that turn a Claude Code session into a live page, on the other hand, were Team and Enterprise only. That boundary has now extended to Pro and Max. Without an organization seat, an individual developer can turn their own session into a shareable page.

Why this matters becomes clear when you look at how individual developers actually work. When an open-source contributor finishes a long refactor, they need a way to convey the context of the change to a reviewer. The same holds for a solo developer running a side project who wants to track their own progress or demo it to a peer. Until now, these users could not touch the feature unless they were tied to an organization plan. The Pro and Max expansion closes that gap.

One more note: over the same period, Anthropic also temporarily raised the weekly Claude Code usage limits for Pro, Max, and Team. Access and headroom opened together, which gives individual developers real room to try the feature.

How It Works in Practice

Using it feels conversational. During a session, when you say “turn this work into an artifact,” Claude Code generates a page capturing the current progress and publishes it to claude.ai. Open the returned link and you see a visual page summarizing the work so far, and as the session keeps running, the page updates without a refresh.

Sharing happens through the publish button at the bottom of the artifact panel. Whoever receives the link can view the page without a Claude account. Someone who does have an account can use remix to make their own editable copy. In other words, a single artifact is both a read-only shared object and a starting point that someone else can pick up and develop.

The privacy model is also clear. A page created in Claude Code is private to your account by default. It is exposed externally only the moment you publish and hand over a link, and until then only you can see it. For developers handling sensitive internal work, this default matters, because there is no path to accidental exposure.

The most practical combination in this flow is the PR walkthrough. After finishing a long change, requesting an artifact yields a page covering what changed and why, which files are affected, and how it was verified. The reviewer can grasp the context from this page before reading the diff. Incident response pages and release checklists work the same way, letting the agent maintain a human-readable summary on its own.

What It Means for ThakiCloud

The real implication of this feature goes beyond the convenience of a single tool. The pattern itself, “keep an agent’s work output as a human-readable, shareable artifact, and keep it live,” is a core challenge for any agent platform.

The Paxis lens (agent output as a first-class resource). ThakiCloud’s Paxis is an Agent-Native Cloud control plane that runs on top of ai-platform and treats Skills, Tools, Policies, and Audit Logs as first-class resources. What Claude Code artifacts demonstrate is a way to expose an agent’s intermediate and final output as a separate observation channel. When a DAG of multiple agents in Paxis performs a long task, condensing each node’s progress into a human-readable live page lets an operator grasp the flow without scrolling logs. Combine that with Paxis’s policy gates and audit logs, and the artifact becomes a controlled output that is traceable down to “who made and shared what, and when.” In the same spirit as Anthropic’s default-private artifacts, Paxis can layer policy-based access control onto output sharing and scale it to the organization level.

The ai-platform lens (internal operations pages). On the infrastructure side, self-contained pages fit internal dashboards and incident pages well. ThakiCloud’s ai-platform runs K8s, Kueue GPU scheduling, and multi-tenant vLLM serving, and the batch and serving workloads that run on it need a channel to convey state to people. If you let an agent maintain a release checklist or a deployment progress page on its own, you gain operational visibility in on-prem and sovereign environments without adding a separate observability stack. Because self-containment reduces the dependence on external hosting, it is a light burden even in customer environments with strong air-gap requirements.

The two lenses complement each other. If ai-platform runs agent workloads at low cost and Paxis treats their output as shareable artifacts under policy and audit, you can reproduce the experience of “an agent works and its result immediately becomes something a human can read” on your own platform.

Limitations and Counterpoints

There are clear points where expectations should be tempered.

First, the feature is tied to publishing on claude.ai. Because the page is hosted on Anthropic infrastructure, it is hard to use as-is in a fully air-gapped environment or where data exfiltration is prohibited. Customers with strong sovereignty requirements need a self-hosted alternative, and that is precisely the gap an on-prem-oriented platform like ThakiCloud can fill.

Second, self-contained pages are excellent for simple summaries and dashboards, but they are limited for complex interactions or large-scale data integration. A published artifact is essentially a lightweight frontend and does not replace heavy backend logic.

Third, real-time updates hold only while the session is alive. Once the session ends, the page freezes as a snapshot from that moment. If you need a continuously updating operations dashboard, you still need a separate pipeline.

In short, the Pro and Max expansion of Claude Code artifacts significantly lowers the barrier for individual developers to turn agent work into shareable output. The constraints of hosting and persistence remain, and that is exactly where an agent platform with policy, audit, and on-prem capabilities offers complementary value. Absorb the convenience of the tool, and fill the areas that require control and sovereignty with your own platform. That is the realistic approach.

Sources

• ClaudeDevs (@ClaudeDevs) announcement post
• Publish and share artifacts (Claude Help Center)
• What are artifacts and how do I use them? (Claude Help Center)

개요

코딩 에이전트가 몇 시간짜리 작업을 끝냈을 때, 정작 그 결과를 남에게 보여주는 일은 여전히 번거롭습니다. 터미널 로그를 캡처해 붙이거나, 변경 사항을 손으로 요약하거나, 별도로 대시보드를 만들어야 했습니다. 작업 자체보다 작업을 설명하는 데 시간이 더 드는 경우도 적지 않았습니다.

2026년 7월, Anthropic은 Claude Code의 아티팩트(Artifacts) 기능을 Pro와 Max 요금제까지 확대했습니다. 그동안 Team과 Enterprise에서만 쓸 수 있던 기능이 개인 개발자에게도 열린 것입니다. 핵심은 단순합니다. 아티팩트를 요청하면 Claude가 코드를 작성해 claude.ai에 라이브로 게시하고, 세션이 계속 돌아가는 동안 그 페이지를 실시간으로 갱신합니다. 페이지는 계정에 비공개로 귀속되며 완전히 자기완결적(self-contained)입니다.

이 글에서는 Claude Code 아티팩트가 정확히 무엇인지, Pro·Max 확대가 왜 의미가 있는지, 그리고 ThakiCloud가 운용하는 에이전트 플랫폼 Paxis와 AI 인프라 ai-platform의 관점에서 이 패턴을 어떻게 흡수할 수 있는지 살펴봅니다.

작업 자체보다 “지금 무슨 일이 벌어지고 있는지”를 설명하는 데 더 많은 에너지가 소모되던 문제.

Claude Code 아티팩트란 무엇인가

아티팩트는 원래 claude.ai 대화 안에서 코드나 문서를 별도 패널로 렌더링하는 기능이었습니다. 이번에 Claude Code로 들어온 아티팩트는 성격이 조금 다릅니다. 대화 한 번의 산출물이 아니라, 코딩 세션 전체의 진행 상황을 하나의 살아있는 시각 페이지로 만듭니다.

대화 한 번의 산출물이 아니라 세션 전체의 진행 상황을 실시간으로 렌더링하는 살아있는 페이지입니다.

Anthropic이 예시로 든 용도는 네 가지입니다. 풀 리퀘스트 설명(PR walkthrough), 시스템 동작을 설명하는 페이지(system explainer), 대시보드, 그리고 릴리스 체크리스트입니다. 공통점은 모두 “지금 무슨 일이 벌어지고 있는지”를 사람이 읽을 수 있게 정리한 산출물이라는 점입니다. 그리고 세션이 작업을 이어가는 동안 이 페이지가 스스로 갱신됩니다.

작업에서 게시까지의 흐름은 다음과 같습니다.

flowchart TB
    A[개발자: 아티팩트 요청] --> B[Claude Code가 코드 작성]
    B --> C[claude.ai에 라이브 게시]
    C --> D{세션 계속 진행}
    D -->|작업 상태 변화| E[페이지 실시간 갱신]
    E --> D
    D -->|완료| F[자기완결 페이지 확정]
    F --> G[게시 링크 공유]
    G --> H[수신자: 계정 없이 열람]
    G --> I[계정 보유자: 리믹스로 사본 편집]

여기서 두 가지 설계 결정이 눈에 띕니다. 첫째, 페이지가 자기완결적입니다. 외부 빌드 파이프라인이나 호스팅 설정 없이, 게시된 페이지 하나에 필요한 것이 다 들어갑니다. 둘째, 기본값이 비공개입니다. 페이지는 계정에 귀속되고, 게시 버튼을 눌러 링크를 공유하기 전까지는 남이 볼 수 없습니다.

자기완결성(외부 호스팅 불필요)과 기본 비공개(게시 전까지 계정에 귀속)라는 두 축.

Pro·Max 확대가 의미하는 것

기능 자체는 몇 달 전부터 Team과 Enterprise에서 쓸 수 있었습니다. 이번 변화의 핵심은 요금제 경계가 내려왔다는 것입니다.

정확히 구분하면 이렇습니다. claude.ai 대화에서 만드는 일반 아티팩트는 이전부터 Free·Pro·Max를 포함한 모든 요금제에서 게시할 수 있었습니다. 반면 Claude Code 세션을 라이브 페이지로 바꾸는 아티팩트는 Team·Enterprise 전용이었습니다. 이번에 그 경계가 Pro와 Max까지 확대됐습니다. 조직 단위 좌석 없이도 개인 개발자가 자기 세션을 공유 가능한 페이지로 만들 수 있게 된 것입니다.

일반 대화형 아티팩트 게시는 이전부터 전 요금제 가능. 이번 변화는 Code 세션 라이브 페이지가 Pro·Max로 내려온 것입니다.

이것이 왜 중요한지는 개인 개발자의 실제 작업 패턴을 보면 드러납니다. 오픈소스 기여자가 긴 리팩터링을 끝냈을 때, 리뷰어에게 변경의 맥락을 전달할 방법이 필요합니다. 사이드 프로젝트를 돌리는 1인 개발자가 진행 상황을 스스로 추적하거나 동료에게 데모를 보여줄 때도 마찬가지입니다. 지금까지 이런 사용자는 조직 요금제에 묶이지 않으면 이 기능을 쓸 수 없었습니다. Pro·Max 확대는 이 격차를 메웁니다.

한 가지 덧붙이면, Anthropic은 같은 기간 Pro·Max·Team의 Claude Code 주간 사용 한도를 한시적으로 상향하기도 했습니다. 기능 접근성과 사용량 여유가 함께 열린 셈이라, 개인 개발자가 실제로 이 기능을 시험해 볼 여지가 커졌습니다.

실제 사용 흐름

사용 방법은 대화에 가깝습니다. 세션 중에 “이 작업을 아티팩트로 만들어 줘”라고 요청하면, Claude Code가 현재 진행 상황을 담은 페이지를 생성해 claude.ai에 게시합니다. 반환된 링크를 열면 지금까지의 작업이 정리된 시각 페이지가 보이고, 세션이 계속 돌아가면 이 페이지가 새로고침 없이 갱신됩니다.

공유는 아티팩트 패널 하단의 게시 버튼을 통해 이뤄집니다. 링크를 받은 사람은 Claude 계정이 없어도 페이지를 열람할 수 있습니다. 계정이 있는 사람은 리믹스(remix) 기능으로 자기만의 편집 가능한 사본을 만들 수 있습니다. 즉 하나의 아티팩트가 읽기 전용 공유물이자 다른 사람이 이어받아 발전시킬 수 있는 출발점이 됩니다.

요청(Prompt) → 실시간 갱신(Live Update) → 링크 게시(Publish) → 리믹스(Remix)로 이어지는 흐름.

프라이버시 모델도 명확합니다. Claude Code에서 만든 페이지는 기본적으로 계정에 비공개입니다. 게시해 링크를 넘기는 순간에만 외부에 노출되며, 그전까지는 본인만 볼 수 있습니다. 민감한 내부 작업을 다루는 개발자에게는 이 기본값이 중요합니다. 실수로 공개되는 경로가 없기 때문입니다.

이 흐름에서 특히 실용적인 조합은 PR 설명입니다. 긴 변경을 마친 뒤 아티팩트를 요청하면, 무엇을 왜 바꿨는지, 어떤 파일이 영향을 받는지, 어떻게 검증했는지를 담은 페이지가 나옵니다. 리뷰어는 diff를 읽기 전에 이 페이지로 맥락을 먼저 잡을 수 있습니다. 인시던트 대응 페이지나 릴리스 체크리스트도 같은 방식으로, 사람이 읽을 요약을 에이전트가 스스로 유지하게 만드는 용도입니다.

ThakiCloud 제품 적용 시사점

이 기능의 진짜 함의는 단일 도구의 편의를 넘어섭니다. “에이전트의 작업 산출물을 사람이 읽을 수 있는 공유 가능한 아티팩트로, 그것도 실시간으로 유지한다”는 패턴 자체가 에이전트 플랫폼의 핵심 과제이기 때문입니다.

Paxis 관점 (에이전트 산출물의 일급 자원화). ThakiCloud의 Paxis는 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, Skills·Tools·Policies·Audit Logs를 일급 리소스로 다룹니다. Claude Code 아티팩트가 보여주는 것은 에이전트의 중간·최종 산출물을 별도 관측 채널로 노출하는 방식입니다. Paxis에서 DAG 멀티에이전트가 긴 작업을 수행할 때, 각 노드의 진행 상황을 사람이 읽을 수 있는 라이브 페이지로 응축하면 운영자는 로그를 스크롤하지 않고도 흐름을 파악할 수 있습니다. 여기에 Paxis의 정책 게이트와 감사 로그를 결합하면, 아티팩트가 “누가 무엇을 언제 만들고 공유했는가”까지 추적되는 통제된 산출물이 됩니다. Anthropic의 기본 아티팩트가 계정 비공개인 것과 같은 맥락에서, Paxis는 산출물 공유에 정책 기반 접근 제어를 얹어 조직 단위로 확장할 수 있습니다.

Paxis는 에이전트 산출물을 정책 게이트와 감사 로그 아래 두어 통제된 공유 아티팩트로 격상합니다.

ai-platform 관점 (내부 운영 페이지). 인프라 측면에서는 자기완결 페이지가 내부 대시보드와 인시던트 페이지에 잘 맞습니다. ThakiCloud의 ai-platform은 K8s·Kueue GPU 스케줄링·vLLM 멀티테넌트 서빙을 운용하며, 이 위에서 도는 배치·서빙 작업은 상태를 사람에게 전달할 채널이 필요합니다. 에이전트가 릴리스 체크리스트나 배포 진행 페이지를 스스로 유지하게 만들면, 온프렘·소버린 환경에서 별도 관측 스택을 늘리지 않고도 운영 가시성을 확보할 수 있습니다. 자기완결이라는 성질은 외부 호스팅 의존을 줄이므로, 폐쇄망 요구가 강한 고객 환경에서도 부담이 적습니다.

자기완결 페이지는 외부 호스팅 의존을 줄여, 온프렘·소버린 환경의 운영 가시성 확보에 유리합니다.

두 관점은 서로를 보완합니다. ai-platform이 낮은 비용으로 에이전트 워크로드를 실행하고, Paxis가 그 산출물을 정책과 감사 아래 공유 가능한 아티팩트로 다룬다면, “에이전트가 일하고 그 결과가 곧바로 사람이 읽을 산출물이 되는” 경험을 자체 플랫폼 위에서 재현할 수 있습니다.

한계 및 반론

기대를 조정할 지점도 분명합니다.

호스팅 종속·프런트엔드 한계·지속성 부재라는 제약과, 그것을 메우는 온프렘·상태 지속성·통제 접근.

첫째, 이 기능은 claude.ai 게시에 묶여 있습니다. 페이지가 Anthropic 인프라에 호스팅되므로, 완전한 폐쇄망이나 데이터 반출이 금지된 환경에서는 그대로 쓰기 어렵습니다. 소버린 요구가 강한 고객에게는 자체 호스팅 대안이 필요하며, 이것이 오히려 ThakiCloud 같은 온프렘 지향 플랫폼이 채울 수 있는 공백입니다.

둘째, 자기완결 페이지는 단순 요약과 대시보드에는 훌륭하지만, 복잡한 상호작용이나 대용량 데이터 연동에는 한계가 있습니다. 게시된 아티팩트는 본질적으로 가벼운 프런트엔드이며, 무거운 백엔드 로직을 대체하지 않습니다.

셋째, 실시간 갱신은 세션이 살아 있는 동안에만 유효합니다. 세션이 끝나면 페이지는 그 시점의 스냅샷으로 고정됩니다. 지속적으로 갱신되는 운영 대시보드가 필요하다면 별도 파이프라인이 여전히 필요합니다.

정리하면, Claude Code 아티팩트의 Pro·Max 확대는 개인 개발자가 에이전트 작업을 공유 가능한 산출물로 바꾸는 문턱을 크게 낮춘 변화입니다. 다만 호스팅과 지속성의 제약은 남아 있으며, 바로 그 지점에서 정책·감사·온프렘을 갖춘 에이전트 플랫폼이 보완적 가치를 가집니다. 도구의 편의를 흡수하되, 통제와 주권이 필요한 영역은 자체 플랫폼으로 메우는 것이 현실적인 접근입니다.

출처

• ClaudeDevs (@ClaudeDevs) 발표 게시물
• Publish and share artifacts (Claude Help Center)
• What are artifacts and how do I use them? (Claude Help Center)

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

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

ما هذا النهج

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

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

flowchart TB
    A[طلب مهمة الوكيل] --> B{تصنيف نوع المهمة}
    B -->|استدلال واتخاذ قرار عالي المستوى| C[نماذج الحدود المميزة]
    B -->|توليد الشيفرة| D[نماذج مفتوحة الأوزان - فئة البرمجة]
    B -->|استدعاء أدوات وخطوط أنابيب| E[نماذج مفتوحة الأوزان - فئة الوكلاء<br/>Gemma 4]
    B -->|استخراج وتصنيف ضخم| F[نماذج مفتوحة الأوزان - الفئة الاقتصادية]
    C --> G[بوابة السياسة + سجل التدقيق]
    D --> G
    E --> G
    F --> G
    G --> H[إرجاع النتيجة + تسجيل التكلفة]

التثبيت والتكامل

بدأنا بالتحقق من قدرة النماذج مفتوحة الأوزان على أداء المهمة الجوهرية للوكيل، وهي تحويل الطلبات اللغوية الطبيعية إلى استدعاءات أدوات منظمة. كان الهدف التحقق من Gemma 4 بحجم 26 مليار معامل عبر واجهة برمجة تطبيقات مُدارة. صُممت التجربة باستخدام المكتبات القياسية فقط (urllib) دون أي تبعيات إضافية.

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

TOOL_SPEC = """You are an operations automation agent. Convert the user request into a single tool-call JSON.
Output only the JSON object, with no explanation or markdown fences.

Available tools and required parameters:
- query_metrics: {metric, window_days, threshold?, region?}
- restart_pods: {region, selector, only_failed(bool)}
- aggregate_cost: {group_by, month, service?}
- scale_deployment: {name, region, replicas}
- rotate_secret: {name, namespace}

Output schema: {"tool": "<name>", "params": { ... }}"""

def call(prompt):
    body = {
        "contents": [{"role": "user",
                      "parts": [{"text": TOOL_SPEC + "\n\nRequest: " + prompt}]}],
        "generationConfig": {"temperature": 0.0, "maxOutputTokens": 1024},
    }
    # call gemma-4-26b-a4b-it via generateContent, capture latency, tokens, and output

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

أما جانب المنصة فتتولاه كتالوج نماذج Paxis. تتيح Paxis إدارة النموذج المستخدم من أي مزود في ملف تعريفي واحد (models.yaml) يتضمن سعر الإدخال والإخراج لكل رمز مميز إلى جانب الدرجة، وهو الأساس الذي يقوم عليه التوجيه.

# models.yaml: tier and actual cost per token are the basis for routing (USD / 1M tokens)
- id: claude-opus-4-8      # premium
  tier: premium
  costInput: 5.0
  costOutput: 25.0
- id: claude-sonnet-5      # standard (default)
  tier: standard
  costInput: 3.0
  costOutput: 15.0
# Add open-weight providers (Ollama, vLLM, etc.) with the same schema
# and CostRouter will automatically route tasks to the matching tier.

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

نتائج التجربة الفعلية

قدمنا ستة طلبات تشغيل حقيقية إلى Gemma 4 وقيّمنا النتائج مباشرة بمعيارين: هل الإخراج JSON صالح، وهل يتضمن الأداة الصحيحة مع المعاملات الإلزامية كاملة؟

نجحت الحالات الست جميعها في تحديد الأداة الصحيحة واستكمال المعاملات الإلزامية كاملة. على سبيل المثال، للطلب “أظهر العقد التي تجاوزت فيها نسبة استخدام GPU 80% خلال الأيام السبعة الماضية” أنتج النموذج:

{"tool": "query_metrics", "params": {"metric": "gpu_utilization", "window_days": 7, "threshold": 80}}

كان threshold معاملاً اختيارياً في المخطط، لكن النموذج استخلص قيمة “80%” من الطلب ووضعها في موضعها الصحيح. وللطلب “زد نسخ نشر inference-api في منطقة ap-northeast إلى 6”، ربط scale_deployment بالاسم والمنطقة وعدد النسخ بدقة تامة. هذا قياس نظيف يثبت أن نماذج مفتوحة الأوزان قادرة فعلاً على أداء المهمة الجوهرية لأتمتة الوكلاء، وهي استدعاء الأدوات وتنفيذ خطوط الأنابيب.

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

الآن نصل إلى التكلفة. انطلاقاً من ملف تعريف الرموز المميزة المقاسة، افترضنا أن كل مهمة تستهلك 1000 رمز إدخال و300 رمز إخراج وهو سيناريو واقعي لجولة واحدة تشمل موجه النظام ومخطط الأدوات والسياق، مع أسطول وكلاء يعالج 10000 مهمة يومياً على مدى 30 يوماً. استخدمنا أسعار نماذج الحدود من models.yaml الفعلي في Paxis، وأسعاراً تقديرية تمثيلية للاستدلال المُدار بالنماذج مفتوحة الأوزان في منتصف عام 2026.

نفس عبء العمل يكلف $3,750 شهرياً مع النماذج المميزة، مقابل $86 شهرياً مع نماذج مفتوحة الأوزان من مستوى Gemma، أي فارق يبلغ نحو 44 مرة. وكما أثبتت التجربة، بلغت جودة هذه الفئة مفتوحة الأوزان في مهام استدعاء الأدوات 100%. بمعنى آخر، هذا التوفير لم يأتِ على حساب الجودة بل من إزالة المواصفات الفائضة عن الحاجة. قد تتفاوت أسعار النماذج مفتوحة الأوزان بحسب المزود وما إذا كانت ذاتية الاستضافة أم مُدارة، لذلك أشرنا إليها صراحةً بوصفها تقديرية، إلا أن الاتجاه الجوهري، أي وفورات تغير رتبة كاملة، يبقى راسخاً.

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

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

• التوجيه حسب المهمة وظيفة أساسية. يمثل models.yaml مصدر الحقيقة الوحيد لتحديد المزود والنموذج. بمجرد تسجيل مزودي النماذج مفتوحة الأوزان بالمخطط ذاته، تتدفق مهام استدعاء الأدوات والمعالجة الضخمة تلقائياً إلى الفئة الأرخص. يبقى النموذج القياسي هو الافتراضي، ولا يُستدعى المميز إلا باختيار صريح، مما يمنع التوجيه المفرط من الوقوع بالخطأ.
• العزل والحوكمة مدمجان. بصرف النظر عن الفئة الموجه إليها، تمر النتائج جميعها عبر بوابة السياسة وسجل التدقيق. استخدام نموذج أرخص لا يعني إرخاء الرقابة. بل على العكس، يُسجَّل النموذج والرموز المميزة والتكلفة لكل مهمة، مما يتيح تحديد أي المهام تستنزف فئة مكلفة دون مبرر وإعادة توجيهها لاحقاً.
• التوافق مع متطلبات الاستضافة الذاتية والسيادة الرقمية. يمكن تشغيل النماذج مفتوحة الأوزان على GPU داخلي، مما يتيح للعملاء الذين لا يمكنهم إخراج البيانات خارجياً تحقيق التوفير والتحكم في آن واحد. تدير منصة ai-platform في ThakiCloud هذه الفئة مفتوحة المصدر بصورة متعددة المستأجرين عبر جدولة GPU المبنية على Kueue وخدمة vLLM، مما يعني أن الكفاءة البنية التحتية لـ ai-platform تدعم كفاءة التوجيه الاقتصادي في Paxis.

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

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

لهذا النهج حدود واضحة لا يمكن إغفالها.

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

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

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

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

المصادر

• كود التجربة وسجلات النتائج: تجربة Gemma 4 لاستدعاء الأدوات (6/6 نجاح) موثقة في سجلات قياسية حقيقية ضمن outputs/blog-impl/open-weight-agent-cost-routing/.
• أسعار نماذج الحدود: Paxis models.yaml (costInput/costOutput، USD لكل مليون رمز مميز).
• أسعار النماذج مفتوحة الأوزان: تقديرات تمثيلية للاستدلال المُدار في منتصف عام 2026 [تقديري].

إذا أمكنك خدمة نموذج من فئة 27B على GPU واحدة وبدقة شبه خالية من الخسارة، يتغير اقتصاد الاستدلال في البيئات المحلية. تعيد نقطة التحقق nvidia/Qwen3.6-27B-NVFP4 تكميم Qwen3.6-27B إلى نوع بيانات NVFP4 ليعمل على vLLM حديث دون أي إعداد إضافي. هذه هي خلفية إعلان مشروع vLLM أن نقطة التحقق هذه جاهزة للاستدلال على وحدات Blackwell.

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

ما هذا

NVFP4 صيغة عائمة بأربع بتات تخفض عدد البتات لكل معامِل من 16 إلى 4، فتقلّص متطلبات القرص وذاكرة GPU بنحو 2.5 مرة. لكن التصميم الفعلي لـ nvidia/Qwen3.6-27B-NVFP4 لا يسحق كل شيء إلى 4 بت. فإعادة تكميم NVIDIA ModelOpt تخفض طبقات MLP الخطية فقط إلى NVFP4 (W4A16)، مع إبقاء طبقات الانتباه الخطية وذاكرة KV بصيغة FP8. ونتيجة لذلك تتّسع نحو 22GB من الأوزان على GPU واحدة من Blackwell. وتُبلّغ NVIDIA بأن هذا التكوين شبه خالٍ من الخسارة في الدقة مقارنةً بخط أساس FP8.

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

flowchart TB
    A[أوزان Qwen3.6-27B الأصلية FP16] --> B[إعادة تكميم NVIDIA ModelOpt]
    B --> C[طبقات MLP الخطية<br/>NVFP4 W4A16]
    B --> D[طبقات الانتباه الخطية<br/>تبقى FP8]
    B --> E[ذاكرة KV<br/>تبقى FP8]
    C --> F[نحو 22GB من الأوزان]
    D --> F
    E --> F
    F --> G[تُحمَّل على GPU واحدة من Blackwell]
    G --> H[vLLM يكتشف تلقائيًا<br/>quantization modelopt]
    H --> I[نقطة استدلال متوافقة مع OpenAI]

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

التثبيت والخدمة

يكتشف vLLM تكميم ModelOpt تلقائيًّا من نقطة التحقق، فلا حاجة صارمة لتمرير راية تكميم. لكنك تحتاج vLLM حديثًا يدعم NVFP4/W4A16، وتوصي NVIDIA بإصدار nightly أو بناء من المصدر يتضمن دعم ModelOpt. شغّل صورة nightly عبر Docker وقدّم الخدمة كالتالي.

# vLLM حديث بدعم NVFP4/ModelOpt (صورة nightly)
docker run --gpus all -p 8000:8000 \
  vllm/vllm-openai:nightly \
  vllm serve nvidia/Qwen3.6-27B-NVFP4 \
    --port 8000 \
    --quantization modelopt \
    --max-model-len 262144 \
    --reasoning-parser qwen3

تستخدم --max-model-len 262144 السياق الطويل لعائلة Qwen3.6 كما هو، وتتولى --reasoning-parser qwen3 تحليل رموز الاستدلال. والنقطة متوافقة مع OpenAI، فتتصل بها العملاء القائمة دون تغيير.

نتائج التجربة

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

• تُبلّغ NVIDIA بأن تكوين NVFP4 المُعاد تكميمه شبه خالٍ من الخسارة في الدقة مقارنةً بخط أساس FP8 (بحسب بطاقة النموذج).
• حجم الأوزان نحو 22GB، يتّسع على GPU واحدة من Blackwell (بحسب بطاقة النموذج).
• يُبلّغ أحد المعايير الخارجية (loFT LLC) بنحو 190 tok/s من إنتاجية التوليد بتكوين NVFP4+MTP على RTX PRO 6000 Blackwell Max-Q مزدوجة. وهذا قياس خارجي بدرجة [تقديري]، لا قيمة بيئتنا.

ما أمكننا التحقق منه هو حقائق مسار الخدمة. فكون vLLM يكتشف تكميم ModelOpt تلقائيًّا، وأن التكوين مختلط الدقة (MLP بصيغة NVFP4 والانتباه وKV بصيغة FP8)، وأن نحو 22GB من الأوزان تتّسع على GPU واحدة من Blackwell، كلها مؤكدة في بطاقة النموذج العامة ووصفة vLLM. أما الإنتاجية والكمون الفعليان فيبقيان مسألة تُقاس حين يتوفر العتاد.

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

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

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

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

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

أولًا، الاعتماد على العتاد صارخ. فمنفعة NVFP4 تبلغ ذروتها على وحدات GPU من جيل Blackwell، ولا ينبغي للأجيال الأسبق توقع الكفاءة نفسها. وجاذبية الخدمة على GPU واحدة لا تصمد إلا على فرض تأمين Blackwell. وفي بيئة يكون فيها توريد GPU نفسه هو عنق الزجاجة، لا تتحول “GPU واحدة تكفي” فورًا إلى وفر في التكلفة.

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

ثالثًا، رقم الإنتاجية في هذا المقال ليس قياسنا. فالمعايير الخارجية تعتمد بشدة على تكوين العتاد (RTX PRO 6000 مزدوجة، واستخدام MTP من عدمه) وعلى حجم الدفعة وطول السياق، لذا تبقى قيمة عنقودنا الفعلية غير محددة حتى نقيسها مباشرةً. وتبلغ خلاصة هذا المقال فقط “الخدمة على GPU واحدة بصيغة NVFP4 تملك إمكان تحويل اقتصاد الخدمة”؛ أما “كم tok/s في بيئتنا” فمسألة تُقال بعد تحقق منفصل.

المصادر

• nvidia/Qwen3.6-27B-NVFP4 بطاقة النموذج، Hugging Face (https://huggingface.co/nvidia/Qwen3.6-27B-NVFP4)
• Qwen/Qwen3.6-27B، vLLM Recipes (https://recipes.vllm.ai/Qwen/Qwen3.6-27B)
• Measuring Qwen3.6-27B NVFP4+MTP on vLLM، loFT LLC (https://loftllc.dev/en/docs/tech/llm-research/qwen3-6-27b-nvfp4-mtp-vllm-benchmark/)

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

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

تستعرض هذه المقالة خريطة هذا التحول بالاعتماد على أبحاث موثّقة، وتُختتم بربط هذا التوجه البحثي بأسلوب Paxis، السحابة الأصيلة للوكلاء (Agent-Native Cloud) التابعة لـThakiCloud، التي تتعامل مع المهارات بوصفها موارد من الدرجة الأولى وتُجسّد بذلك هذا التوجه البحثي عملياً.

ما هي الذاكرة الإجرائية

من منظور معرفي، تُقسَّم الذاكرة عادة إلى ثلاثة أنواع: الذاكرة الدلالية (semantic) التي تحفظ الحقائق، والذاكرة العرضية (episodic) التي تحفظ الأحداث، والذاكرة الإجرائية (procedural) التي تحفظ الطرق. وفي أدبيات الوكلاء، تتولى الذاكرة الإجرائية مسؤولية الإجابة عن سؤال “كيف يُنفَّذ الأمر”، إذ تُجرّد تسلسلات الحركة المعقّدة إلى أنماط قابلة لإعادة الاستخدام، بما يتيح التنفيذ دون تخطيط من الصفر في كل مرة.

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

flowchart TB
    A[مسارات التنفيذ السابقة] --> B[استخلاص الإجراء<br/>Build]
    B --> C{شكل التخزين}
    C --> D[غير بارامتري<br/>نص برمجي]
    C --> E[بارامتري<br/>سياسة عصبية]
    D --> F[الاسترجاع والاختيار<br/>Retrieval]
    E --> F
    F --> G[تنفيذ المهمة]
    G --> H[التحديث وفق التغذية الراجعة<br/>إضافة وتعديل وحذف Update]
    H --> B

ما وراء استرجاع المطالبات: فصل التخزين والاسترجاع والتحديث

أبرز الأبحاث التي تناولت هذا التوجه بشكل مباشر هي Memp: Exploring Agent Procedural Memory (arXiv 2508.06433). يضع Memp الذاكرة الإجرائية كهدف تحسين من الدرجة الأولى، ويقطّر المسارات السابقة إلى طبقتين: تعليمات دقيقة خطوة بخطوة من جهة، وإجراءات عالية المستوى أشبه بنص برمجي من جهة أخرى. كما يفصل حلقة الذاكرة إلى ثلاث مراحل هي البناء (build) والاسترجاع (retrieval) والتحديث (update). وفي مرحلة التحديث، تُضاف العناصر أو تُعدَّل أو تُحذف وفق التغذية الراجعة من التنفيذ.

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

لماذا يهم هذا الآن: صعوبة التقييم

لم يُفهم بعد بشكل كافٍ ما إذا كانت الذاكرة الإجرائية تُنتج فعلاً مهارات صالحة للاستخدام. والبحث الذي يستهدف هذه الفجوة هو Managing Procedural Memory in LLM Agents (arXiv 2606.23127)، الذي يقترح معياراً بعنوان AFTER. يتألف هذا المعيار من 382 مهمة مؤسسية واقعية موزعة على 6 أدوار وظيفية، و22 مهارة إجرائية، ويقيس مدى قابلية انتقال المهارات عبر المهام والأدوار وبنية النماذج الأساسية.

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

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

يتخذ هذا التوجه البحثي شكله العملي بالكامل في Paxis التابعة لـThakiCloud. Paxis سحابة أصيلة للوكلاء (Agent-Native Cloud) تتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق بوصفها موارد من الدرجة الأولى. وهنا تُعد بيئة المهارات (Skill Harness) بمثابة الذاكرة الإجرائية الإنتاجية فعلياً.

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

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

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

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

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

المصادر

• Memp: Exploring Agent Procedural Memory (arXiv 2508.06433)
• Managing Procedural Memory in LLM Agents: Control, Adaptation, and Evaluation (arXiv 2606.23127)
• Rethinking Memory Mechanisms of Foundation Agents in the Second Half: A Survey (arXiv 2602.06052)

يبدو أن منح الوكيل مزيدًا من المهارات ينبغي أن يجعله أكثر كفاءة، لكن الأبحاث الحديثة تُبلّغ بالعكس. فكلما كبرت مكتبة المهارات، قد ينخفض فعليًا معدل نجاح الوكيل في المهام نفسها. تواجه الورقة arXiv 2605.24050 بعنوان “More Skills, Worse Agents?” هذه المفارقة مباشرة، وتُبلّغ بأن معدل اجتياز المهام يتراجع بنسبة تصل إلى 21% عند التوسع من مجموعة صغيرة من المهارات المفيدة إلى مكتبة من 202 مهارة.

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

ما هو تظليل المهارات

تتيح مكتبة المهارات لوكيل نموذج اللغة تحميل تعليمات خاصة بالمهمة عند الطلب. والهدف تمكين مستخدم غير خبير من حل مهام في مجاله بلغة طبيعية دون معرفة أي المهارات موجودة أو كيف تعمل داخليًا. تبدأ المشكلة كلما كبرت المكتبة.

المساهمة الجوهرية في arXiv 2605.24050 هي تفكيك تراجع الأداء إلى أثرين. الأول هو تظليل المهارات (skill shadowing): مع كبر المكتبة تتصادم المهارات المتشابهة في وصفها فيختار الوكيل المهارة الخاطئة أكثر. والثاني هو عبء السياق (context overhead): تملأ أوصاف المهارات السياق فتتدهور جودة التنفيذ حتى حين يكون الاختيار صحيحًا.

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

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

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

لماذا يهم هذا الآن

مشكلة الحجم لا تقتصر على ورقة واحدة. فمعيار SkillRet (arXiv 2605.05726) الصادر في الفترة نفسها يجمع 17,810 مهارة وكيل عامة في معيار استرجاع واسع النطاق منظَّم ضمن تصنيف من مستويين يضم 6 فئات رئيسية و18 فئة فرعية. صارت المهارات تتراكم بمقياس عشرات الآلاف، وأصبح استرجاع المهارة الصحيحة من هذا المجمع مسألة بحثية قائمة بذاتها.

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

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

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

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

تُظهر قياسات Skill Harness الفعلية أن التصميم يعمل. ففي معيارنا الداخلي SRA (63 حالة) بلغ Recall@5 نسبة 82.2%، وبلغت الدقة المُبوَّبة مع تطبيق بوابة الامتناع 66.7%، وبلغ Top-1 نسبة 40.0%، وكانت الهلوسة (اختلاق مهارة غير موجودة للمطابقة) 0%. وتحديدًا فإن الهلوسة 0% أثر مباشر لبوابة الامتناع: فمهما كبرت المكتبة، لا تختلق مهارة غائبة ولا تفرض مطابقة دون العتبة.

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

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

للبحث ولتصميمنا حدود واضحة. أولًا، نسبة التراجع 21% في arXiv 2605.24050 قيمة ضمن إعداد محدد (مكتبة من 202 مهارة) وتتباين كثيرًا بحسب جودة أوصاف المهارات وتداخلها ومجال المهمة. فإذا وُصفت المهارات جيدًا وحُفظت من التداخل، تقلّ نسبة التراجع عند المقياس نفسه. الدرس الدقيق ليس “لا تُضِف مهارات” بل “أدِر جودة الوصف والاسترجاع معًا”.

ثانيًا، استرجاع BM25 المعجمي ليس دواءً لكل داء. فمع الاستعلامات بمصطلحات كورية صرفة تفتقر إلى مفردات توسعة إنجليزية، قد يعجز عن إظهار المهارة الصحيحة، ونسبة Top-1 البالغة 40.0% في معيارنا تترك مجالًا واسعًا للتحسين. وثمة تعزيزات مثل مجاميع التضمين مطروحة، لكن هل تبرر التخلي عن حتمية إشارة واحدة وكلفتها المنخفضة فمسألة منفصلة. وقبل تثقيل الاسترجاع، غالبًا ما يمنح تحسين أوصاف المهارات نفسها المكسب الأكبر.

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

المصادر

• More Skills, Worse Agents? Skill Shadowing Degrades Performance When Expanding Skill Libraries, arXiv 2605.24050 (https://arxiv.org/abs/2605.24050)
• SkillRet: A Large-Scale Benchmark for Skill Retrieval in LLM Agents, arXiv 2605.05726 (https://arxiv.org/abs/2605.05726)

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

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

ما هي مهارة /dataviz

/dataviz هي مهارة مرجعية يُفترض قراءتها قبل بناء أي رسم بياني أو رسم أو لوحة معلومات، في أي وسيط إخراج. لا يهم إن كانت الوجهة عنصر HTML أو React، أو SVG مضمّن، أو كوداً في مكتبة مثل matplotlib أو plotly أو d3 أو Recharts، أو صورة PNG سيتم عرضها ورفعها، أو رسماً بياناً سيُشارَك في Slack. صُممت لتُحمَّل قبل كتابة أول سطر من كود الرسم، وقبل اختيار ألوان الرسم، وقبل ترتيب بطاقة مؤشر أداء أو مقياس أو صف من المؤشرات.

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

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

ما الذي تحمّله هذه المهارة إلى السياق

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

flowchart TB
    A["طلب التصور<br/>(رسم بياني، لوحة معلومات، مؤشر أداء)"] --> B["قاعدة الشكل<br/>شكل البيانات ← شكل الرسم"]
    B --> C["صيغة اللون<br/>تخصيص فئوي، تدرجي، متباين"]
    C --> D["تشغيل مدقق لوحة الألوان<br/>فحص التباين وإمكانية الوصول"]
    D --> E{"هل اجتاز التحقق؟"}
    E -->|"لا"| C
    E -->|"نعم"| F["مواصفات العلامات + قواعد التفاعل<br/>المحاور، وسيلة الإيضاح، التلميحات"]
    F --> G["تصور متسق<br/>نفس النظام في الوضعين الفاتح والداكن"]

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

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

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

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

كيف تُستخدم فعلياً

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

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

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

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

الرسالة التي تحملها /dataviz تتطابق تماماً مع المبدأ الذي تمارسه ThakiCloud بالفعل في منتجَين: عدم ترك التنسيق والجودة لارتجال النموذج، بل جعله يملأ هيكلاً مُتحقَّقاً منه.

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

من زاوية Paxis، تمثل /dataviz بحد ذاتها نموذجاً مصغراً لما نبنيه من سحابة أصيلة للعملاء الوكلاء. Paxis هو مستوى تحكم الوكلاء الذي يعمل فوق ai-platform، يعامل المهارات كموارد من الدرجة الأولى ويختار من بين نحو 960 مهارة باستخدام BM25 لتشغيلها في بيئة معزولة. الطريقة التي تحزم بها /dataviz “القدرة على رسم رسم بياني” في مهارة واحدة وتحمّلها إلى السياق عند الحاجة هي البنية نفسها التي يعتمدها Skill Harness في Paxis، والذي يجمع المعرفة والانضباط في وحدات مهارات قابلة لإعادة الاستخدام. ومدقق لوحة الألوان القابل للتشغيل تحديداً هو النسخة الخاصة بتصور البيانات من مبدأ حافظنا عليه عبر عدة مهارات دفعية: الأرقام والأحكام لا يدّعيها النموذج، بل يملكها الكود الحتمي. النموذج يقترح لوناً، والكود يفحص ما إذا كان هذا اللون يُقرأ فعلياً. من دون هذا الفصل، لا يمكن للمخرجات التي ينتجها أشخاص متعددون ووكلاء متعددون أن تتقارب في نظام واحد.

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

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

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

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

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

المصادر

• سجل تغييرات Claude Code CLI 2.1.198 (ClaudeCodeLog على X)
• وصف مهارة dataviz المدمجة في Claude Code وملف references/palette.md

عندما تشغّل خدمة LLM لفترة طويلة، تصل إلى نقطة غريبة. تنشر vLLM، وتراقب استخدام GPU، وتضبط حجم الدفعات (batch size)، لكنك في لحظة ما لا تستطيع أن تشرح بجملة واحدة “لماذا يستهلك هذا الطلب هذا القدر من KV Cache”، أو “ما الذي يقلّصه GQA بالضبط ليوفّر عرض النطاق الترددي للذاكرة”. تعرف كيف تستخدم الأدوات، لكن المبادئ التي تقوم عليها تبقى ضبابية. هذه الفجوة تجعل التحسين يعتمد على الحدس، وتمنعك من استنتاج السبب الجذري عندما يحدث عطل.

المصدر التعليمي amitshekhariitbhu/llm-internals يستهدف هذه المشكلة مباشرة. إنه مستودع تعلّم متدرج يجمع مقالات ومقاطع فيديو بترتيب يبدأ من التوكنة ويمر بالانتباه وبنية الترانسفورمر وKV Cache وصولاً إلى تحسين الاستدلال. المؤلف الأصلي هو Amit Shekhar، وقد رتّب المواضيع بحيث تبني نموذجاً ذهنياً واحداً متماسكاً بدلاً من مجموعة دروس متفرقة وعابرة.

تشغّل ThakiCloud منصة ai-platform لتقديم النماذج لعملاء متنوعين فوق Kubernetes. معظم العوامل التي تحدد تكلفة الخدمة وزمن الاستجابة تنبع من هذه البنية الداخلية التي يتناولها هذا المستودع. لذلك، هذا المقال ليس مجرد تعريف بمصدر تعليمي، بل محاولة لتوضيح لماذا يشكّل كل موضوع منها سلاحاً مباشراً لمهندس البنية التحتية.

ما هو هذا المصدر

llm-internals ليس إطار عمل لتشغيل الكود، بل هو مسار تعلّم (learning path). يتتبع خط الأنابيب الذي يمر به LLM من استقبال المدخل حتى إنتاج التوكن التالي، ويعرض المفاهيم اللازمة في كل مرحلة بترتيب مدعوم بمصادر خارجية. جوهر المستودع هو تصميم المنهج نفسه: “ما الذي يجب فهمه، وبأي ترتيب، حتى تكتمل الصورة الكاملة”.

المواضيع الرئيسية التي يغطيها المستودع تتبع التدفق التالي.

flowchart TB
    A[النص المدخل] --> B[التوكنة<br/>BPE Byte Pair Encoding]
    B --> C[التضمين<br/>تحويل التوكن إلى متجه]
    C --> D[الانتباه<br/>Query Key Value]
    D --> E[كتلة الترانسفورمر<br/>الانتباه + FFN بشكل متكرر]
    E --> F[KV Cache<br/>تسريع التوليد]
    E --> G[MoE<br/>توجيه الخبراء]
    D --> H[GQA<br/>مشاركة رؤوس KV]
    F --> I[تحسين الاستدلال<br/>كفاءة الخدمة]
    G --> I
    H --> I

أهمية هذا الترتيب تكمن في أن المواضيع اللاحقة لا يمكن فهمها دون المواضيع السابقة. فـ KV Cache لا يكتسب معناه إلا بعد فهم ما هما Key وValue في الانتباه، وGQA لا يظهر معناه إلا بعد فهم بنية الرؤوس في الانتباه متعدد الرؤوس، أي “ما الذي يتم مشاركته بالضبط”. قيمة هذا المستودع لا تكمن في عمق كل مصدر على حدة، بل في هذا الترتيب الذي لا يكسر سلسلة الاعتماد بين المفاهيم.

استعراض المواضيع الأساسية

التوكنة: نقطة البداية لكل شيء

لا يتعامل LLM مباشرة مع الحروف أو الكلمات، بل يعالج النص على شكل توكنات. تستخدم معظم النماذج الحديثة عائلة BPE (Byte Pair Encoding)، وهي طريقة تدمج بشكل متكرر أزواج البايتات الأكثر تكرراً معاً لبناء المفردات. قد تبدو التوكنة أمراً بسيطاً، لكنها من منظور الخدمة عامل تكلفة مباشر. نفس الجملة يمكن أن يختلف عدد توكناتها اختلافاً كبيراً باختلاف اللغة والمُرمِّز (tokenizer)، وعدد التوكنات ينعكس مباشرة على استهلاك KV Cache وحجم العمليات الحسابية. ظاهرة استهلاك اللغات غير الإنجليزية مثل الكورية والعربية عدداً أكبر من التوكنات مقارنة بالإنجليزية هي نقطة يجب مراعاتها بالضرورة عند احتساب تكلفة الخدمة.

الانتباه: Query وKey وValue

قلب الترانسفورمر هو الانتباه الذاتي (self-attention). يُسقَط كل توكن إلى ثلاثة متجهات. Query يمثل “ما الذي أبحث عنه”، وKey يمثل “ما الذي أقدّمه”، وValue يمثل “المحتوى الفعلي الذي سيُنقل”. يُحسب مقياس الانتباه عبر الضرب الداخلي بين Query وKey، ثم يمرّ عبر عملية القياس (scaling) والدالة softmax لإنتاج مجموع مرجّح لـ Value.

Attention(Q, K, V) = softmax( (Q · Kᵀ) / √d_k ) · V

هذه المعادلة بسيطة في ظاهرها، لكن حقيقة أن عملية الانتباه تنمو بمعدل O(n²) بالنسبة لطول التسلسل n هي ما ينتج عنه كل عمليات التحسين اللاحقة. من هنا تبدأ الإجابة عن سبب ارتفاع تكلفة السياقات الطويلة، وسبب حساسية بنية الخدمة لطول السياق.

كتلة الترانسفورمر وKV Cache

الترانسفورمر هو بنية من طبقات متعددة، تجمع كل طبقة منها الانتباه مع شبكة تغذية أمامية (FFN). في التوليد ذاتي الانحدار (autoregressive)، يُنتج التوكن واحداً تلو الآخر، وإعادة حساب Key وValue لكل التوكنات السابقة في كل خطوة يمثل هدراً كبيراً. KV Cache يخزّن قيم Key وValue التي حُسبت سابقاً ويعيد استخدامها، مما يرفع سرعة التوليد.

المشكلة هي أن هذه الذاكرة المؤقتة تستهلك ذاكرة كبيرة. يتناسب حجم الذاكرة المؤقتة تقريباً مع 2 × عدد الطبقات × عدد رؤوس KV × أبعاد الرأس × طول التسلسل × حجم الدفعة. السياقات الطويلة وكثرة الطلبات المتزامنة تضخّم هذه القيمة بشكل انفجاري. هذا هو بالضبط الضغط البنيوي الذي يجعل تقنية PagedAttention في vLLM تدير KV Cache على شكل صفحات لتقليل التجزئة.

MoE وGQA: تغييرات بنيوية لأجل الكفاءة

مزيج الخبراء (Mixture of Experts، MoE) يقسّم شبكة FFN إلى عدة “خبراء”، ويقوم موجّه (router) بتفعيل جزء فقط من الخبراء لكل توكن. إجمالي عدد المعاملات كبير، لكن حجم العمليات الحسابية الفعلي لكل توكن يصبح صغيراً. في المقابل، يفرض هذا على الخدمة تحديات جديدة: التوازي بين الخبراء، وعدم توازن التوجيه، وتوزيع الذاكرة.

الانتباه المُجمَّع الاستعلام (Grouped-Query Attention، GQA) هو حل وسط بين الانتباه متعدد الرؤوس (MHA) والانتباه متعدد الاستعلامات (MQA). في MHA، يملك كل رأس Key وValue خاصين به، بينما في MQA تشترك جميع الرؤوس في Key وValue واحد. أما GQA فيجمّع الرؤوس في عدد قليل من المجموعات، وتشترك كل مجموعة في KV خاص بها. والنتيجة أن حجم KV Cache وعرض النطاق الترددي للذاكرة ينخفضان بينما يبقى فقدان الجودة عند حدّه الأدنى. فهم GQA يوضّح لماذا تعتمد النماذج مفتوحة الأوزان الحديثة هذه البنية، ولماذا تختلف موازنة الذاكرة عند الخدمة تبعاً لذلك.

لماذا تهم هذه المعرفة مهندس البنية التحتية

المواضيع أعلاه ليست موضع فضول أكاديمي، بل هي السبب المباشر لتكلفة الخدمة. فهم معادلة حجم KV Cache يتيح توقّع كيف يصطدم عدد الطلبات المتزامنة وطول السياق بذاكرة GPU. وفهم GQA يفسّر لماذا يستطيع بعض النماذج معالجة عدد أكبر من الطلبات على نفس GPU. وفهم MoE يسمح بالاستعداد لسبب تعقيد الجدولة الناتج عن التوزيع المتوازي للخبراء.

على النقيض، غياب هذه المعرفة يعني أنك ستكتفي، عند حدوث عطل، بملاحظة عرض “نفدت الذاكرة” فقط، وتكرر الاستجابة المكلفة المتمثلة في تقليل حجم الدفعة عشوائياً أو إضافة المزيد من وحدات GPU. المهندس الذي يعرف البنية الداخلية يملك رافعات أدق: ترقيم KV Cache، وسقف طول السياق، والتكميم (quantization)، واختيار نماذج تعتمد GQA.

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

تقدّم منصة ai-platform من ThakiCloud استدلالاً قائماً على vLLM لعدة مستأجرين فوق Kubernetes وجدولة GPU عبر Kueue. تنعكس البنية الداخلية التي استعرضناها في هذا المقال مباشرة على رافعات التشغيل الفعلية.

• KV Cache: استناداً إلى PagedAttention ومعادلة حجم KV Cache، نحدّد سقف طول السياق وميزانية التزامن لكل مستأجر. توقّع استهلاك الذاكرة المؤقتة يتيح رفع الإنتاجية دون الإفراط في حجز ذاكرة GPU.
• GQA والتكميم: من أجل استيعاب عدد أكبر من الطلبات على نفس العتاد، نُعطي الأولوية في المراجعة للنماذج مفتوحة الأوزان التي تعتمد GQA، وندمج ذلك مع التكميم بهدف تحقيق تكلفة خدمة منخفضة في البيئات المحلية (on-premise) والسيادية.
• خدمة MoE: نراعي مسبقاً أن نماذج MoE التي تحتاج توازياً بين الخبراء تتطلب معاملة خاصة في تصميم طوابير Kueue وتوزيع العُقد.

من منظور الوكلاء الذكيين (agents)، فإن Paxis، السحابة الأصيلة للوكلاء (Agent-Native Cloud) من ThakiCloud، توفّر بيئة مواتية لتراكم هذه المعرفة الداخلية كأصل جماعي للفريق. بما أن Paxis تتعامل مع المهارات (skills) كموارد من الدرجة الأولى، يمكن تحويل قرارات متكررة مثل “حساب ميزانية KV Cache” إلى مهارة موثّقة يُعاد استخدامها داخل بيئة معزولة (sandbox) وتُتبَّع عبر سجل تدقيق. هذا يوفّر قناة لتحويل خبرة الخدمة، التي غالباً ما تظل معرفة ضمنية لدى مهندس بعينه، إلى معرفة إجرائية على مستوى المؤسسة.

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

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

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

المصادر

• amitshekhariitbhu/llm-internals (GitHub)
• التغريدة الأصلية المُوصية: Dan Kornas, “Stop learning LLM internals from random one-off tutorials”

في كل مرة يصدر فيها نموذج جديد، نميل إلى نقل التعليمات ذاتها التي بنيناها للنموذج القديم. لكن دليل التوجيه الرسمي الذي نشرته Anthropic لنموذج Claude Fable 5 يوصي بعكس ذلك تماماً. فالتعليمات التي كانت تجعل النماذج السابقة تتصرف بشكل جيد قد تُضعف فعلياً جودة مخرجات Fable 5. وبكلمات الدليل نفسه، فإن المهارات المبنية للنماذج السابقة تكون غالباً “مُفصّلة أكثر من اللازم بالنسبة لـ Claude Fable 5، ما قد يُضعف جودة المخرجات”.

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

ما الذي تغيّر

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

flowchart TB
    A["Fable 5<br/>استقلالية عالية"] --> B["1. التخفيف<br/>إزالة التعليمات الزائدة"]
    A --> C["2. مراجعة عبر نتائج الأدوات<br/>ممنوع التقرير الذاتي"]
    A --> D["3. الاعتماد على الوكلاء الفرعيين<br/>تفويض غير متزامن"]
    A --> E["4. التعلم من التشغيلات السابقة<br/>تسجيل الدروس"]
    A --> F["5. تحديد القيود<br/>ما يجب وما لا يجب فعله"]
    B --> G["توجيهات تحدد الاتجاه<br/>وتترك الحكم للنموذج"]
    C --> G
    D --> G
    E --> G
    F --> G

المبدأ الأول: خفّف التعليمات

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

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

المبدأ الثاني: راجع التقدم عبر نتائج الأدوات

خلال التشغيلات الطويلة المستقلة، ينبغي توجيه Fable 5 لمراجعة تقدمه بنفسه بالاستناد إلى نتائج الأدوات الفعلية. التوجيه المثال الذي يقدمه الدليل هو التالي.

Before reporting progress, audit each claim against a tool result
from this session. Only report work you can point to evidence for.

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

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

المبدأ الثالث: اعتمد بثقة على الوكلاء الفرعيين

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

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

المبدأ الرابع: تعلّم من التشغيلات السابقة

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

Store one lesson per file with a one-line summary at the top.
Record corrections and confirmed approaches alike, including why
they mattered.

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

المبدأ الخامس: حدّد القيود بوضوح

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

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

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

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

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

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

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

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

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

المصادر

• Prompting Claude Fable 5، الوثائق الرسمية لشركة Anthropic (platform.claude.com)
• Redeploying Claude Fable 5، أخبار Anthropic