كيفية الضغط التلقائي لسياق الوكيل: شرح مفصل لثلاثة توقيتات للتفعيل واستراتيجية تلخيص من خمس خطوات

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

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

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

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

أبرز نقاط الضغط التلقائي لسياق الوكيل

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

لماذا يحتاج الوكيل إلى الضغط التلقائي للسياق؟

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

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

لماذا لم يعد Codex يعرض استخدام السياق؟

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

3 أوقات يمكن فيها تفعيل الضغط التلقائي لسياق الوكيل

يفترض كثيرون أن «السياق يُضغط عند استهلاك 80% منه»، لكن هذه ليست قاعدة رسمية. تحدد وثائق API الرسمية شروط التفعيل أساسًا باستخدام حد لعدد رموز Token، وليس نسبة ثابتة من نافذة السياق. كذلك، لا يلزم انتظار الاقتراب من الحد الأقصى للضغط؛ فكل من OpenAI وAnthropic تدعم الضغط الاستباقي.

مقارنة قواعد التفعيل في التطبيقات الرسمية

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

التوقيت الأول: التفعيل عند بلوغ عتبة الرموز

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

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

التوقيت الثاني: الضغط الاستباقي عند حدود مراحل المهمة

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

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

التوقيت الثالث: ترك إطار العمل يدير الضغط حسب امتلاء السياق

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

🎯 نصيحة تقنية: لا تتعارض التوقيتات الثلاثة مع بعضها. يُنصح بالاعتماد أساسًا على «الضغط الاستباقي عند حدود المراحل، مع استخدام عتبة الرموز كإجراء احتياطي». وإذا أردت التحقق من ملاءمة إعدادات العتبة مع نماذج مختلفة، يمكنك استخدام مفتاح API واحد عبر APIYI على apiyi.com للتبديل بين نماذج OpenAI وClaude وGemini وغيرها وإجراء اختبارات مقارنة.

استراتيجية التلخيص للضغط التلقائي لسياق الوكيل

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

ما الذي يجب الاحتفاظ به أو استبعاده من الملخص؟

تطبيق استراتيجية التلخيص في 5 خطوات

1. الاحتفاظ بموجه النظام دائمًا: لا يخضع موجه النظام للضغط، ويظل دائمًا في بداية قائمة messages.
2. الاحتفاظ بآخر N جولات كما هي: غالبًا ما ترتبط الجولات الأخيرة ارتباطًا وثيقًا بالعملية الحالية، لذا تُحفظ بنصها الأصلي ويُضغط الجزء الأقدم فقط.
3. استخدام قالب ملخص منظم: يُطلب من نموذج التلخيص إخراج الملخص ضمن خمسة أقسام: «الهدف / التقدم / الحقائق / القرارات / الخطوة التالية»، لتجنب الإغفال الناتج عن التلخيص الحر.
4. اختصار نتائج الأدوات أولًا: عند إرجاع أداة لنتائج طويلة جدًا، يُحتفظ بالمقاطع الأساسية فقط، مثل الأسطر الأولى والأخيرة من رسالة الخطأ، أو عناوين نتائج البحث وخلاصاتها.
5. حفظ نص المستخدم الأصلي بشكل منفصل: يُنصح بالاحتفاظ بالقيود الصريحة التي يضعها المستخدم حرفيًا، مثل «لا تعدّل الواجهة العامة»، بدلًا من ترك النموذج يعيد صياغتها.

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

البدء السريع بضغط سياق الوكيل تلقائيًا

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

مثال مبسط

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 兼容接口
)

messages = [{"role": "system", "content": "你是一个编码助手。"}]
messages.append({"role": "user", "content": "帮我检查这个函数的边界条件"})

resp = client.chat.completions.create(model="gpt-4o-mini", messages=messages)
messages.append({"role": "assistant", "content": resp.choices[0].message.content})

# 每轮记录输入 Token,作为是否压缩的判断依据
print("本轮输入 Token:", resp.usage.prompt_tokens)

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

MAIN_MODEL = "gpt-4o-mini"      # 主任务模型,可按需替换
SUMMARY_MODEL = "gpt-4o-mini"   # 摘要模型,可用更便宜的模型
TOKEN_THRESHOLD = 100_000       # 输入 Token 阈值,兜底触发
KEEP_RECENT = 6                 # 保留最近 N 条消息原文

SUMMARY_PROMPT = """请把以下 Agent 对话历史压缩为任务状态摘要,严格按五个栏目输出:
【任务目标】用户原始需求与硬性约束(约束请逐字保留)
【当前进度】已完成的步骤与当前阶段
【关键事实】文件路径、函数名、配置值、关键报错
【已做决策】采用的方案及原因
【下一步行动】待办事项与未解决问题
不要记录寒暄和推理过程,不要编造历史中没有的信息。"""


def compact(messages: list) -> list:
    """把早期历史压缩为一条摘要消息,保留系统提示与最近对话。"""
    system_msg = messages[0]
    old = messages[1:-KEEP_RECENT]
    recent = messages[-KEEP_RECENT:]
    if not old:
        return messages

    history_text = "\n".join(f"[{m['role']}] {m['content']}" for m in old)
    resp = client.chat.completions.create(
        model=SUMMARY_MODEL,
        messages=[
            {"role": "system", "content": SUMMARY_PROMPT},
            {"role": "user", "content": history_text},
        ],
    )
    summary = resp.choices[0].message.content
    summary_msg = {"role": "user", "content": f"(以下为之前对话的压缩摘要)\n{summary}"}
    return [system_msg, summary_msg] + recent


class CompactingAgent:
    def __init__(self, system_prompt: str):
        self.messages = [{"role": "system", "content": system_prompt}]
        self.last_prompt_tokens = 0

    def chat(self, user_input: str) -> str:
        # 时机一:上一轮输入 Token 超过阈值时先压缩
        if self.last_prompt_tokens > TOKEN_THRESHOLD:
            self.messages = compact(self.messages)

        self.messages.append({"role": "user", "content": user_input})
        resp = client.chat.completions.create(model=MAIN_MODEL, messages=self.messages)
        reply = resp.choices[0].message.content
        self.messages.append({"role": "assistant", "content": reply})
        self.last_prompt_tokens = resp.usage.prompt_tokens
        return reply

    def finish_stage(self):
        # 时机二:完成一个任务阶段后主动压缩
        self.messages = compact(self.messages)
        self.last_prompt_tokens = 0


agent = CompactingAgent("你是一个严谨的编码助手。")
print(agent.chat("帮我定位登录接口偶发 500 的原因"))
agent.finish_stage()  # 修复完成后,在阶段边界主动压缩

🚀 البدء السريع: سجّل عبر APIYI على apiyi.com للحصول على رصيد تجريبي مجاني. يكفي استبدال مفتاح API لتشغيل الشفرة أعلاه. توفر المنصة واجهة متوافقة مع OpenAI، ويمكن اختيار النموذج الرئيسي ونموذج التلخيص من مزوّدين مختلفين لتسهيل التحكم في التكلفة.

مقارنة طرق الضغط التلقائي لسياق الوكيل

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

العلاقة بين الضغط التلقائي لسياق الوكيل وتكلفة التخزين المؤقت

قد يبدو أن الضغط يوفر المال دائمًا، لكن من المهم أيضًا مراعاة التخزين المؤقت للموجهات (Prompt Caching). وفقًا لتوضيحات APIYI بشأن تسعير التخزين المؤقت لدى OpenAI، تُحتسب تكلفة الجزء المسترجع من ذاكرة التخزين المؤقت بنسبة 10% من سعر الإدخال. وفي المحادثات الطويلة، يسهل الاستفادة من التخزين المؤقت عندما تظل بداية سجل المحادثة دون تغيير، فلا يكون عدد الرموز الجديدة المحاسبة بالسعر الكامل في كل جولة كبيرًا.

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

الأسئلة الشائعة FAQ

أهم النقاط حول الضغط التلقائي لسياق الوكيل

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

الخلاصة

أهم النقاط حول الضغط التلقائي لسياق الوكيل (Agent):

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

إذا كنت تستخدم Codex يوميًا، يمكنك اعتماد أسلوب يدوي للضغط: «لخّص ما أُنجز عند اكتمال كل مرحلة وافتح نافذة جديدة». وإذا كنت تطوّر وكيلًا بنفسك، يمكنك تعديل الشفرة الواردة في هذا المقال مباشرة. نوصي باستخدام APIYI عبر apiyi.com لاختبار النتائج بسرعة؛ إذ توفر المنصة رصيدًا مجانيًا للتجربة وواجهة موحدة لعدة نماذج، كما تتيح لك سجلات الاستدعاء رؤية التغير في عدد الرموز قبل الضغط وبعده بوضوح.

📚 المراجع

1. توثيق OpenAI Responses API: شرح ضغط السياق وإعداد compact_threshold
2. الرابط: platform.openai.com/docs/api-reference/responses

3. الوصف: التوثيق الرسمي للضغط التلقائي على جانب الخادم وإدارة الحالة

4. توثيق OpenAI Agents SDK: استراتيجيات إدارة السياق أثناء تشغيل الوكيل

5. الرابط: openai.github.io/openai-agents-python

6. الوصف: كيفية إعداد استراتيجيات الضغط التلقائي والضغط عند عتبة ثابتة والضغط الإجباري

7. توثيق Anthropic لضغط السياق: إعدادات تفعيل الضغط في Messages API وTool Runner

8. الرابط: docs.anthropic.com
9. الوصف: القيم الافتراضية لكل من trigger.value وcontext_token_threshold وكيفية الضغط عند الطلب

الكاتب: الفريق التقني في APIYI
التواصل التقني: يسعدنا تواصلكم معنا عبر الصفحة الرئيسية لموقع APIYI. ولمزيد من المعلومات حول إعداد Codex والمحادثات متعددة الجولات وفوترة التخزين المؤقت، يمكنكم زيارة مركز التوثيق على docs.apiyi.com.

مقالات ذات صلة

• استخدم سجلات الاستدعاء في APIYI لمعرفة استهلاك Codex للرموز في كل جولة: احسب تكلفة المحادثات الطويلة بدقة في 5 خطوات: إذا لم يظهر استخدام السياق في مربع إدخال Codex، فستجده عبر /status؛ تشرح هذه المقالة كيفية حساب استهلاك الرموز وتكلفتها لكل جولة في Codex من سجلات استدعاءات APIYI في 5 خطوات، وتقدم جدولًا لتحديد ما إذا كان ينبغي ضغط السياق أو بدء محادثة جديدة.
• فرق سعر قراءة التخزين المؤقت يبلغ 67 ضعفًا: فاتورة وكيل كتابة الأكواد، التكلفة الأعلى تكمن في هذا العمود: تعد قراءة الذاكرة المؤقتة أغلى بند في فاتورة وكيل كتابة الأكواد: فبمقارنة الأسعار الرسمية بتاريخ 2026-10-26 بين Opus 5.5 وGPT-6.1 Sol وKimi K3.1 Pro وDeepSeek V4.1 Flash يبلغ الفارق 67 ضعفاً، مع الإشارة إلى أن 96% مجرد تقدير من طرف ثالث.
• دليل خطوة بخطوة: اربط جميع الوكلاء بمفتاح واحد عبر بوابة API موحّدة باستخدام Magpie مفتوح المصدر (مع Claude Code وCodex وPi وHermes أمثلةً): دليل عملي خطوة بخطوة: في نحو 30 دقيقة، اجعل جميع وكلاء البرمجة على جهازك (مثل Claude Code وCodex وPi وHermes) يستخدمون مفتاح API واحدًا وعنوان بوابة واحدًا، مع لقطات شاشة لواجهة magpie، وخطوات الربط، ومقارنة بالإعدادات الأصلية، وجدول لاستكشاف الأخطاء وإصلاحها.