خريطة قاعدة الشيفرة لوكلاء البرمجة عبر MCP

خريطة قاعدة الشيفرة لوكلاء البرمجة

خريطة قاعدة الشيفرة لوكلاء البرمجة هي فهرس دائم لمستودعك، يرجع إليه الوكيل للبحث بدلاً من استعراض المستودع باستخدام grep من الصفر في كل جلسة جديدة. يُعد Graft أحد تطبيقات هذه الفكرة. فهو يحلل الشيفرة باستخدام tree-sitter، وينشئ مجلداً من عُقد Markdown المترابطة، بالإضافة إلى رسم بياني يوضح ترابط كل رمز، ثم يوفّر أدوات الاسترجاع عبر MCP (model context protocol، وهي الواجهة القياسية التي يستخدمها وكلاء البرمجة لاستدعاء الأدوات الخارجية).

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

هذه التقنية أقدم من هذه الأداة، وستستمر بعد زوالها. تعلّم التقنية أولاً، ثم تعلّم آلياتها.

لماذا تهدر وكلاء البرمجة سياقها في إعادة اكتشاف بنية المستودع

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

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

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

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

ما الذي ينشئه Graft فعلياً

ينشئ Graft مخرَجين، وكلاهما داخل مجلد graft/ واحد في جذر المستودع.

المخرج الأول هو رسم بياني للعُقد مكتوب بصيغة Markdown مترابطة، مع ملف واحد لكل عقدة. تحتوي كل عقدة على ملخص بلغة إنجليزية واضحة، و«خلاصة» لأسطر المنطق المهمة المستخرجة من المصدر، وملفات المصدر الدقيقة مع تجزئة للمحتوى، وروابط ويكي ذات أنواع إلى العقد الأخرى (depends_on، part_of، uses، implements)، وقسم للملاحظات يبقى بعد إعادة الإنشاء، بحيث يمكنك تسجيل السياق الذي لا يستطيع المحلل استنتاجه.

المخرج الثاني هو graft/.graph/wiring.json، وهو الرسم البياني البنيوي لكل رمز الذي يستخرجه tree-sitter: التعريفات والمراجع وحواف الاستدعاء التي تصل بينها.

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

دعم اللغات مقسّم إلى مستويات، ويحدد المستوى مدى الثقة في رسم الاستدعاءات. تحصل TypeScript وJavaScript وPython وGo وJava على حل واعٍ بالنطاق للمراجع عبر الملفات. أما Rust وC وC++ وC# وRuby وPHP وKotlin وScala وSwift وElixir وSolidity وOCaml وZig وDart فتحصل على الرموز وحواف الاستدعاء العامة، ما يعني أن الحافة قد تستند إلى تطابق اسم بدلاً من مرجع محلول. ويمكن تفعيل الحواف بمستوى المترجم اختيارياً باستخدام --lsp وخادم لغة مثل rust-analyzer أو gopls.

ثبّت Graft وحدد الإصدار

يحتاج Graft إلى Node.js 20 أو إصدار أحدث، وهو مرخّص بموجب MIT. اعتباراً من أغسطس 2026، الإصدار الحالي هو 0.10.1، بينما يعود تاريخ نشر الإصدار الأول، 0.1.0، إلى يوليو 2026. تعامل معه باعتباره برنامجاً حديثاً.

npm install -g @nanonets/graft@0.10.1
npm ls -g @nanonets/graft

يجب أن يطبع npm ls -g القيمة @nanonets/graft@0.10.1. حدّد هذا الإصدار عمداً. يحلّ npm install -g @nanonets/graft المجرد الوسم latest عند لحظة تشغيله، وعندما يطلق المشروع عدة إصدارات فرعية كل شهر، ستحصل يوم الثلاثاء على أداة مختلفة عن تلك التي ثبّتها زميلك يوم الاثنين. يحافظ الإصدار المحدد على ثبات خيارات CLI وتنسيق الرسم البياني لدى الجميع، لذلك تجري الترقية عندما تقرر ذلك.

بعد ذلك، اربطه بمستودع تملكه:

cd /path/to/your/repo
graft init --dry-run
graft init

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

اعتباراً من أغسطس 2026، يشمل الربط Claude Code وCursor وCodex وGitHub Copilot وGoogle Gemini وKiro وWindsurf وAdaL. يحصل Claude Code على أعمق تكامل: إدخال لخادم MCP، وسطر حالة يعرض حجم الرسم البياني ومدى تقادمه، وخطافات بعد التعديل تعيد إنشاء الرسم البياني، وملف مهارة ضمن .claude/. أما البقية فتحصل على ملف تعليمات أو قواعد يخبر الوكيل بوجود هذه الأدوات. لذلك يعني مصطلح «مدعوم» أن Graft يكتب إعدادات الربط، ومن ثم فإن الوكيل الذي يتجاوز ملف قواعده الخاص سيتجاوز الخريطة أيضاً. وهذا هو السبب المعتاد في تجاهل الوكلاء للتعليمات التي تكتبها لهم، وينطبق هنا كما ينطبق في أي موضع آخر.

ما الذي يدخل إلى مستودعك، وما الذي يبقى خارج git

بعد graft init، توقّع العناصر التالية:

• graft/: الرسم البياني لعُقد Markdown وgraft/.graph/wiring.json. تتم إضافته إلى .gitignore نيابةً عنك.
• .mcp.json: يسجّل خادم graft MCP لكي يشغّله Claude Code.
• .claude/settings.json: يُدمج في موضعه، ويضيف statusline وpost-edit hooks.
• AGENTS.md وGEMINI.md و.github/copilot-instructions.md و.cursor/rules/graft.mdc و.kiro/steering/graft.md و.windsurf/rules/graft.md و.adal/skills/graft/SKILL.md: أقسام محاطة بعلامات خاصة تُلحق بالملفات المطابقة للوكلاء الذين اخترتهم.
• ~/.codex/config.toml و~/.codex/hooks.json و~/.codex/hooks/graft/graft-hooks.cjs: على مستوى الجهاز بالكامل، ولا تُكتب إلا عند اختيار Codex. يتجاوزها graft init --no-global، ويتجاوز graft init --no-hooks وحده hook shim.

الرسم البياني عبارة عن ذاكرة تخزين مؤقت، مثل node_modules. لا ترسله إلى المستودع. يُعاد توليده من الشيفرة خلال ثوانٍ، ويتغير مع كل تعديل تقريباً، وإرساله إلى المستودع يحوّل إصلاحاً من سطر واحد إلى فرق يتضمن عدة مئات من الملفات لن يراجعه أي مراجع. أرسل بدلاً من ذلك ملفات الربط، ومنها AGENTS.md و.mcp.json. يستنسخ زميلك المستودع، ويشغّل graft build، ويحصل على رسم بياني محلي خاص به.

تحقق من إضافة قاعدة التجاهل قبل أول commit:

grep -n graft .gitignore
git status --short

يجب أن يطبع grep سطراً يتضمن graft/، ويجب ألا يعرض git status --short أي شيء ضمن graft/. ظهور ملفات ضمن graft/ في ذلك الناتج يعني أن إدخال التجاهل مفقود أو أن هناك قاعدة أخرى تتجاوزه. أصلح ذلك قبل إجراء commit، لأن git يواصل تتبع الملف بعد إضافته، ولن يؤدي تعديل .gitignore لاحقاً إلى إلغاء تتبعه.

إذا كنت تفضّل تسجيل خادم MCP يدوياً، أو تثبيته على الإصدار نفسه الذي ثبّتَّه، فالإدخال صغير:

{
  "mcpServers": {
    "graft": {
      "command": "npx",
      "args": ["-y", "@nanonets/graft@0.10.1", "mcp"]
    }
  }
}

أدوات الاسترجاع التي يستدعيها وكيلك بدلاً من grep

يوفّر Graft ست أدوات عبر MCP. تعيد graft_find_code العقد المرتبة حسب الصلة بوصف المهمة، مع الملف ورقم السطر. تعيد graft_file_api كل توقيع في ملف من دون الأجسام. تتتبع graft_trace_calls المستدعين أو الدوال المستدعاة عبر عدة مستويات. تعيد graft_find_all النتائج المطابقة لتعبير نمطي، مجمّعة حسب الرمز. تمنح graft_repo_map نظرة أولية على مستودع غير مألوف. وتبلغ graft_check_freshness ما إذا كانت الخريطة لا تزال تطابق الشفرة.

لكل أداة نظير عبر CLI. وهذه هي الطريقة التي تتحقق بها مما يتلقاه وكيلك فعلياً:

graft map .
graft ask "where do we validate the refresh token"
graft skeleton src/auth/session.ts
graft callers validateRefreshToken
graft callers validateRefreshToken --direction out
graft grep "refresh_token" --json

من المفترض أن تطبع graft ask العقد المرتبة مع مراجع file:line، بدلاً من محتويات الملفات. هذه هي الآلية كلها: يتلقى الوكيل مؤشراً ويفتح ملفاً واحداً، بدلاً من قراءة عشرة ملفات للعثور على الملف الصحيح. تفتح graft viz عارضاً تفاعلياً على localhost إذا أردت فحص الخريطة بنفسك. إذا لم تُرجع graft ask شيئاً مفيداً لسؤال يمكنك الإجابة عنه خلال ثلاثين ثانية، فإما أن الخريطة قديمة أو أن لغتك تقع ضمن المستوى العام، وعندها لن تساعد الخريطة وكيلك أيضاً.

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

ماذا يحدث للرسم البياني عند تغيّر الشيفرة

تحديث البنية سريع وتلقائي. يقرأ Graft شجرة العمل لديك بدلاً من git، لذلك تظهر له التعديلات التي لم تلتزم بها والتعديلات التي أضفتها إلى منطقة التجهيز بالطريقة نفسها. تعيد الاستعلامات تحليل الملفات التي تغيّرت قيمة stat الخاصة بها فقط. توثّق المشروع أن الحمل الإضافي يبلغ نحو 3 ms. وعند نهاية الجولة، لا تعيد عملية البناء فحص إلا الملفات التي نُقلت فيها الشيفرة. استخدم GRAFT_NO_REFRESH=1 أو مرّر --no-refresh للإجابة من الرسم البياني الموجود على القرص دون إعادة التحليل. مرّر --no-reuse لفرض إعادة تحليل كاملة من الحالة الباردة. استخدم ذلك بعد ترقية Graft نفسه.

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

اجعل حالة القِدم ظاهرة:

graft check .
echo $?

تعني حالة الخروج 0 أن الرسم البياني يطابق الشيفرة. وتعني حالة الخروج 1 وجود انحراف. شغّل الأمر من hook ‏pre-push، أو على الفرع ضمن CI، حتى لا تجيب خريطة عمرها ستة أشهر بثقة عن شيفرة أُعيدت كتابتها في مارس.

اقرأ أرقام الاختبارات المنشورة بعناية

الادعاء الرئيسي لـGraft هو «أقل تكلفة بما يصل إلى 4x وأسرع 3x، مع دقة أفضل أو من دون فقدان للدقة». تستند هذه الأرقام إلى الاختبارات التي أجراها المشروع نفسه ونشرها في README. فيما يلي التشغيلان اللذان يوردهما بالتفصيل.

[
  {
    "label": "Controlled sweep",
    "run_count": 162,
    "token_saving_pct": 42,
    "tool_call_saving_pct": 46,
    "correctness_pct": 93,
    "baseline_correctness_pct": 93
  },
  {
    "label": "SWE-bench Verified",
    "run_count": 50,
    "token_saving_pct": 23,
    "tool_call_saving_pct": 25,
    "correctness_pct": 66,
    "baseline_correctness_pct": 54
  }
]

يتضمن الاختبار المنضبط 162 تشغيلات عبر مستودعين، أحدهما Graft نفسه، مع 3 تجارب لكل مهمة. ويذكر استخدام رموز أقل بنسبة 42%، واستدعاءات أدوات أقل بنسبة 46%. أما اختبار SWE-bench Verified فيتضمن 50 مثيلات، مع استخدام النموذج نفسه في طرفي المقارنة، ويذكر وفراً أقل: 23% من الرموز و25% من استدعاءات الأدوات. وأعاد تشغيل ثالث إنتاج 5 طلبات سحب مدمجة من PocketBase، بتكلفة بلغت 11.02 دولاراً أمريكياً مقابل 13.91 للاختبار الأساسي.

تعامل مع هذه الأرقام كلها على أنها اختبار أداء من الجهة المورّدة. هناك عاملان يحدّان مما يمكن استنتاجه منها. يتضمن الاختبار المنضبط مستودع Graft نفسه، أي قاعدة الشيفرة التي ضبط مؤلفو الأداة أداءها عليها. أما SWE-bench Verified فهو مجموعة بيانات عامة لمشكلات من مشاريع Python مفتوحة المصدر معروفة، والمجموعات العامة هي التي تُحسَّن الأدوات من أجلها، سواء كان ذلك مقصوداً أم لا. لا يمثل أي من الاختبارين مستودعك الأحادي الخاص، الذي يستخدم عادات التسمية الخاصة به ويحتوي على شيفرة ميتة خاصة به.

تستحق الدقة قراءة ثانية. لم تتغير في الاختبار المنضبط: 93% مع الخريطة، مقابل 93% من دونها. ويظهر الارتفاع إلى 66% مقارنةً بـ54% في اختبار SWE-bench Verified فقط. إذا خفّضت أداة فاتورة الرموز لديك وأبقت الجودة ثابتة، فذلك يظل مقايضة جيدة. لكن لا تنقل نتيجة الدقة من SWE-bench إلى نتيجة الرموز في الاختبار المنضبط، ثم تقتبس النتيجتين على أنهما ادعاء واحد.

قِسّ فرق الرموز الخاص بك قبل أن تصدّق أياً من ذلك

الرقم الوحيد المهم هو الرقم القادم من مستودعك. تستغرق هذه الطريقة فترة بعد الظهر.

اختر مهمة يمكنك تكرارها حرفياً. السؤال أفضل من التعديل، لأن التعديل يغيّر المستودع، وبالتالي لا تعود الجولة الثانية التجربة نفسها. السؤال «أي وحدة تفرض حد المعدل على مسار تسجيل الدخول؟» له الصيغة المناسبة.

فعّل القياس عن بُعد وأرسله إلى طرفيتك:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
claude

يطبع مُصدِّر وحدة التحكم سجلات المقاييس عند جمعها. السجل المطلوب هو claude_code.token.usage، ويحمل سمة type بقيمة input أو output أو cacheRead أو cacheCreation. يظهر أثر التوجيه في input وcacheRead، لأن محتوى الملفات يُدرج هناك. اجمع هاتين القيمتين.

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

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

متى تتوقف خريطة قاعدة الشيفرة عن تقديم فائدة؟

• المستودع يدخل بالكامل في سياق الطلب. لا تحتاج خدمة صغيرة واحدة إلى خريطة، وستدفع مقابل ستة مخططات لأدوات في كل طلب. إذا عثر وكيلك اليوم على أي ملف خلال استدعاء أداة واحد أو اثنين، فتجاوزها.
• لغتك ضمن الفئة العامة. قد تؤدي حواف الاستدعاء العامة إلى أن يفوّت graft callers مستدعياً، أو ينشئ مستدعياً بسبب تطابق أسماء. أكّد ذلك باستخدام graft grep قبل أن تثق في نطاق التأثير.
• أصبحت الخريطة قديمة ولم يلاحظ أحد ذلك. ينتهي graft check بالحالة 1 عند اكتشاف الانحراف، ولا يفيد ذلك إلا إذا شغّله شيء ما. استخدم hook أو خطوة في CI، ولا تعتمد على التشغيل اليدوي.
• يحتاج المستودع الأحادي إلى تحديد النطاق. يُقسَّم المستودع الأحادي الذي يستخدم Git تلقائياً وفق ملف مساحة العمل أو go.mod أو pyproject.toml أو Cargo.toml، ويضيّق graft ask "..." --in services/billing/ نطاق الاستعلام إلى مشروع فرعي واحد. ينطبق على الخريطة الدافع نفسه الذي يؤدي إلى استخدام ملفات AGENTS.md متداخلة لكل حزمة.
• يتجاهل الوكيل آلية الربط. راقب استدعاءات الأدوات في جلسة فعلية قبل أن تستنتج أن الخريطة قيد الاستخدام. إذا كان الوكيل لا يزال يشغّل grep، فهذا يعني أنه لم يقرأ ملف القواعد مطلقاً.

FAQ

هل يجب أن أضمّن مجلد graft/ في git؟

لا. يضيف graft build الإدخال graft/ إلى .gitignore تلقائياً، لأن الرسم البياني ذاكرة مؤقتة يمكن إعادة إنشائها مثل node_modules. يتغير هذا المجلد تقريباً مع كل تعديل، ولذلك يؤدي تضمينه إلى إخفاء الفروقات الفعلية بين مئات الملفات المُنشأة. ضمّن في commit إعداد الربط الذي يعرّف الوكلاء بوجود الخريطة، ومن ضمنه AGENTS.md و.mcp.json، واترك لكل عضو في الفريق تشغيل graft build محلياً. تحقّق باستخدام grep -n graft .gitignore وgit status --short قبل أول commit، لأن git يواصل تتبع الملف بعد إضافته، وتعديل .gitignore لاحقاً لا يوقف تتبعه.

هل يتطلب تشغيل Graft دفع رسوم؟

لا يتطلب الجزء البنيوي ذلك. إنّ graft build وgraft ask وgraft check وأدوات MCP الست لاسترداد البيانات هي عمليات tree-sitter ولا تستدعي أي نموذج. أما graft build --deep فهو الجزء المدفوع؛ إذ يكتب الملخصات باللغة الإنجليزية الواضحة والخلاصات الجوهرية لكل رمز عبر LLM، مع ضبطه باستخدام GRAFT_PROVIDER وGRAFT_API_KEY وGRAFT_MODEL، إضافة إلى GRAFT_BASE_URL لأي endpoint متوافق مع OpenAI. يمكنك تشغيل Graft بالهيكل فقط، ولن تنفق أي token على الرسم البياني نفسه.

كم سيوفّر رسم خريطة لقاعدة الشيفرة فعلياً في مستودعي؟

لا يمكن لأحد إخبارك بذلك من دون قياس. يذكر المشروع انخفاضاً بنسبة 42% في عدد tokens ضمن اختباراته التي شملت 162 تشغيلات، وانخفاضاً بنسبة 23% في SWE-bench Verified، وكلاهما مقارنة بخط أساس لا يتضمن خريطة. هذه نتائج قياس يوردها المورّد، وقد أُجري أحد الاختبارين جزئياً على مستودع Graft نفسه، كما أن أياً منهما لا يصف شيفرتك الخاصة. نفّذ سؤالاً قابلاً للتكرار 3 مرات مع الخريطة و3 مرات من دونها، مع ضبط CLAUDE_CODE_ENABLE_TELEMETRY=1 وOTEL_METRICS_EXPORTER=console، ثم قارن الوسيط الخاص بـclaude_code.token.usage لنوعي input وcacheRead.

ماذا يحدث للرسم البياني عند إعادة هيكلة الشيفرة؟

يعيد الجزء البنيوي تحليل نفسه. يفحص Graft شجرة العمل ويعيد تحليل الملفات التي تغيرت فقط، ولذلك يلتقط إعادة التسمية عند الاستعلام التالي مع كلفة إضافية تقارب 3 ms، كما أنه يرى العمل غير المُثبت في commit لأنه يقرأ الملفات لا سجل git. أما الملخصات التي كتبها النموذج فهي التي تصبح قديمة؛ إذ تخزّن كل عقدة hash لمحتوى مصادرها، ويؤدي تغيّر المصدر إلى تعليم العقدة بأنها قديمة بدلاً من إعادة كتابتها. شغّل graft check . لرؤية التباين، ثم graft build --deep لتحديث الجزء المكتوب.

ما وكلاء البرمجة القادرون على استخدام Graft حالياً؟

اعتباراً من August 2026، يربط graft init كلاً من Claude Code وCursor وCodex وGitHub Copilot وGoogle Gemini وKiro وWindsurf وAdaL. ويحصل Claude Code على أكبر قدر من التكامل: إدخال لخادم MCP في .mcp.json، وسطر حالة، وخطافات بعد التعديل، وملف مهارة ضمن .claude/. ويحصل Codex على قسم AGENTS.md، إضافة إلى إدخالات على مستوى الجهاز ضمن ~/.codex/، والتي يتجاوزها graft init --no-global. أما الآخرون فيحصلون على ملف قواعد أو توجيه. ويمكن لأي عميل MCP آخر استخدام الخادم مباشرةً عبر تسجيل الأمر npx -y @nanonets/graft@0.10.1 mcp.