وضع الـ agent في DuckDB يخفض tokens المخرجات 59% دون أن تنخفض التكلفة الكلية
المغزى: تقليم مخرجات الأدوات يحسن دقة الموديل وتركيزه، لكن فاتورة الـ agent تتحدد في ما يُعاد إرساله في كل دور، لا في ما تطبعه الأداة مرة واحدة.
أعلن فريق DuckDB في 9 أكتوبر 2026 وضعًا جديدًا في DuckDB v2.0 CLI يكتشف أن من يقرأ المخرجات agent لا إنسان، فيغير شكلها. ويتفعل الوضع بثلاثة شروط معًا: وجود متغير بيئة يخص أحد الـ agents، مثل CLAUDECODE أو CODEX_CI أو CURSOR_AGENT أو GEMINI_CLI، وألا يكون stdout طرفية، وألا يحدد المستخدم صيغة إخراج بنفسه.
ويغير الوضع أشياء محددة. فالجداول المرسومة بالصناديق وحشو المحاذاة تصبح جداول Markdown مضغوطة، بأنواع الأعمدة في الترويسة، وحجمها أصغر بنسبة 25 إلى 65%. والأخطاء تخرج بصيغة JSON على stderr، مع حذف قائمة الاقتراحات التي بلغ حجمها 2.7 كيلوبايت في خطأ واحد من نوع “no matching function”. والنتائج الكبيرة يُطبع منها أول 20 صفًا وآخر 20 صفًا، مع عدد الصفوف وhash لا يتأثر بترتيبها. وبهذا يستطيع الـ agent أن يقارن نتيجتين بعد تعديل الاستعلام دون أن يقرأ كل الصفوف.
ولقياس الأثر، أجابت Claude Code عن 22 سؤالًا من TPC-H عند scale factor 100، ثلاث مرات في كل وضع. وجاءت الإجابات الـ 132 كلها صحيحة. ونزلت tokens مخرجات DuckDB التي قرأها الـ agent من 123.6 ألفًا إلى 50.8 ألفًا، أي بنسبة 59%.
لكن الفريق يقول بوضوح إن التكلفة الكلية وزمن التشغيل لم يتحسنا بشكل ملحوظ. والسبب أن إعادة قراءة الـ system prompt في كل دور هي التي تهيمن على المدخلات، لا مخرجات الأداة. كما احتاجت تشغيلات وضع الـ agent أدوارًا أكثر قليلًا: 237 مقابل 224.
وتكشف هذه النتيجة أين تقع تكلفة الـ agents فعلًا. فتنظيف مخرجات الأدوات مكسب في الدقة والتركيز، لكنه ليس الطريق إلى خفض الفاتورة. فالجزء الأكبر منها في السياق الذي يُرسل من جديد مع كل دور.