بودجهٔ زمینه، سیگنال و فرسایش

پس از دفتر تصمیمِ فصل قبل، تیم booking-platform می‌خواهد Agent قابلیت reschedule را بررسی کند. اگر همهٔ مخزن، ۴۰۰ خط دستور، logهای یک اجرای ناموفق و هر تصمیم باز را یک‌جا paste کند، مدل ظاهراً «اطلاعات بیشتری» دارد اما فرصت توجه به شرط مهمِ tenant و پنجرهٔ لغو را کمتر می‌کند. مسئلهٔ Context Engineering کمبود فایل نیست؛ انتخابِ کمینهٔ اطلاعاتی است که گام بعدی را درست می‌کند.

## اهداف یادگیری

پس از این درس می‌توانی اجزای پنجرهٔ زمینه و سهم هر جزء را نام ببری، برای یک وظیفهٔ مشخص بودجهٔ Context بسازی، تفاوت دادهٔ شاهددار با متن پرنویز را تشخیص دهی، اثر موقعیت اطلاعات را به‌عنوان یافتهٔ تجربی—not قانون ثابت—تفسیر کنی، و پیش از پرشدن Context، خروجی ابزار و تاریخچه را فشرده کنی.

## جای درس در چرخهٔ سرتاسری

خروجی فصل ۲ یک Problem brief، Factهای شاهددار و Decision ledger است. در گذار از Elicit به Specify و Observe، این درس تعیین می‌کند کدام‌یک در نوبت Agent حاضر باشد. Context خوب جای تصمیم مالک محصول را نمی‌گیرد: ledgerِ باز هنوز `DECIDE` است. ولی با آوردن هدف، Scope، مسیرهای معلوم و معیار توقف، Agent می‌تواند مشاهدهٔ بعدی را کم‌خطر و قابل‌بررسی انتخاب کند.

## زمینه یک بودجه است، نه انبار

زمینه، همهٔ tokenهایی است که هنگام پاسخ‌دادن در دسترس مدل‌اند: دستورهای همیشه‌فعال، هدف مکالمه، فایل‌های باز، پیام‌های پیشین، نتیجهٔ ابزارها، تعریف ابزار و متن بازیابی‌شده. ظرفیت بزرگ‌تر به‌معنای بازیابی یا استدلال بی‌نقص نیست. برای هر token یک هزینهٔ فرصت وجود دارد: token تازه ممکن است توجه را از acceptance criterion، خروجی test یا restriction امنیتی بردارد. بنابراین سؤال عملی «چه چیزهای دیگری ممکن است مفید باشند؟» نیست؛ «برای تصمیم بعدی، چه شاهدی لازم است و چه چیزی فقط احتمالاً مفید است؟» است.

*نمودار، پنجرهٔ محدود را میان دستور، هدف وظیفه، فایل‌های just-in-time، خروجی ابزار و فضای کار تقسیم می‌کند؛ فضای خالی، ظرفیت تصمیم است نه اتلاف.*

یک بودجهٔ قابل‌نوشتن برای بررسی conflict در reschedule چنین است:

همیشه‌فعال: ۳۰ خط قرارداد پروژه و policy امن
وظیفه: رفتار موردنظر، non-goal، معیار پذیرش و stop condition
شواهد اولیه: ledgerِ timezone/cancellation + نقشهٔ مسیرها
فقط هنگام نیاز: handler تغییر رزرو، schema، integration test و git log نزدیک
خروجی ابزار: فقط matchها، خطا و خلاصهٔ فرمان؛ نه transcript کامل
ذخیره: بخشی از پنجره برای مقایسهٔ شاهدها، فرض و تصمیم بعدی

این اعداد اندازهٔ universal یا درصد token نیستند؛ مدل، Host و کار تغییر می‌کنند. ارزششان در تقسیم آگاهانه است. اگر دستور ۵۰۰ خط است، چارهٔ فنی افزایش Context نیست: canonical ruleها را کوتاه، path-scoped و غیرتکراری کنید و جزئیات را با ارجاع قابل‌بازیابی نگه دارید.

## سیگنال، تازگی و منشأ

اطلاعات پُرسیگنال مستقیماً قید یا پرسش جاری را حل می‌کند و منشأ آن روشن است. `apps/api/.../reschedule.test.ts` با نام test و فرمان اجرا، سیگنال است؛ paste کردن کل history گفت‌وگو نیست. برای هر قطعه Context سه سؤال بپرسید: کدام تصمیم آن را مصرف می‌کند؟ چه مسیر/commit/URL آن را تأیید می‌کند؟ تا چه زمانی تازه است؟ پاسخ سوم مهم است: یک ADR ممکن است تصمیم معتبر باشد، اما خروجی CI دیروز دربارهٔ شاخهٔ دیگر فقط شاهد تاریخی است.

**Context Rot** در این درس نام گزارش فنی فروشندهٔ [Chroma](https://research.trychroma.com/context-rot) است که افت عملکرد را هنگام رشد طول ورودی در ارزیابی‌های خود بررسی می‌کند. نتیجهٔ آن برای مدل‌ها، taskها و روش آزمایشِ گزارش‌شده محدود است؛ از آن نرخ خرابی جهانی یا آستانهٔ token برای همهٔ Agentها نمی‌سازیم. در مقابل، گزارش Anthropic با عنوان [Effective context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) راهنمای فروشنده دربارهٔ انتخاب Context کم‌حجم، بازیابی just-in-time و compaction است، نه همان مطالعهٔ Chroma. پژوهش **Lost in the Middle** نیز اثر محل اطلاعات را در taskهای retrieval بررسی کرده و نشان می‌دهد عملکرد مدل‌های آزموده‌شده می‌تواند با قرارگرفتن دادهٔ مرتبط در میانهٔ Context افت کند. این یافتهٔ تجربی است، نه حکم اینکه هر متن وسطی نادیده گرفته می‌شود یا قانون بودجهٔ ثابت برای همهٔ مدل‌ها.

پس اطلاعات حکم‌کننده را کوتاه و نزدیک به کار جاری نگه دارید، اما برای آن صرفاً به «اول و آخر prompt» تکیه نکنید. یک معیار پذیرش باید در artifact canonical باشد، با نام و مسیر به Agent داده شود، و در پایان دوباره در checklist Verification خوانده شود. تکثیر ناسازگار همان معیار در سه prompt، احتمال تضاد را بیشتر می‌کند.

## Context stuffing در برابر بازیابی هدفمند

Stuffing می‌گوید: «برای اطمینان، همهٔ docs، testها، logها و PRهای سال قبل را بده.» هزینهٔ آن فقط token نیست؛ Agent نمی‌داند کدام نسخه authority دارد، متن حساس ناخواسته وارد نوبت می‌شود، و نتیجهٔ جست‌وجوهای طولانی به شاهد کاذب تبدیل می‌شود. بازیابی هدفمند با یک نقشهٔ سبک آغاز می‌کند: هدف، مسیرهای محتمل، commandهای verify و سؤال باز. سپس هر مشاهده باید retrieval بعدی را توجیه کند.

برای reschedule، نخست `docs/decisions/cancellation.md` و Factهای ledger را بخوانید، سپس فقط route و test نزدیک را retrieve کنید. اگر test می‌گوید پایان `10:30` و شروع `10:30` conflict نیست، این رفتار موجود است؛ اگر ledger می‌گوید policy باز است، Agent آن را Decision نگه می‌دارد. Context هدفمند «فایل کمتر به هر قیمت» نیست: وقتی query database یا قرارداد API مرز را تعیین می‌کند، حذف آن context ناقص می‌سازد. کمینه یعنی کمینهٔ کافی برای ادعای قابل‌آزمون.

مثال ضعیف در booking-platform

کل repo، تمام .git و تمام logهای CI را بخوان.
بعد بهترین راه reschedule را بساز و هر چیزی را که لازم است تغییر بده.

این درخواست هدف قابل‌مشاهده، Scope، authority و معیار پایان ندارد. خروجی‌های بسیار بزرگِ ابزار به جای Evidence در Context می‌مانند؛ Agent شاید Policy لغو را از یک comment قدیمی حدس بزند یا از میان صد خط log، failure نامربوط را دنبال کند. «بهترین» نیز اختیار محصول را مخفیانه به Agent می‌دهد.

مثال اصلاح‌شده

هدف: فقط مسیر conflict در reschedule را بشناس.
Context اولیه: brief، Decision ledger (timezone/cancellation باز)، و نقشهٔ زیر.
مجاز: handler، service، schema و testهای appointment؛ read-only.
بازیابی مرحله‌ای: ابتدا نام فایل/فرمان، بعد فقط فایل مرتبط با هر Fact.
خروجی: Fact | شاهد | تازگی | اطمینان | سؤال باز.
توقف: policy لغو/بازهٔ چسبیده را حدس نزن؛ DECIDE کن.
Verification بعدی: فرمان test و معیار عدم تغییر رزرو قبلی.

این prompt به Agent نمی‌گوید نتیجه چیست؛ مسیر کشف و حد تصمیم را روشن می‌کند. ledgerِ فصل قبل، پیامد و owner تصمیم‌های باز را می‌آورد، نه transcript جلسه را.

## فشرده‌سازی بدون پاک‌کردن حقیقت

Compaction خلاصه‌سازی وضعیت برای Context تازه است، نه خلاصهٔ ادبی. پیش از reset یا handoff، raw outputهایی را که دوباره قابل‌اجرا هستند حذف کنید و حقیقت‌های نیازمند ادامه را بیرون از session ثبت کنید. قالب کوچک زیر traceability را حفظ می‌کند:

هدف/Scope: جلوگیری از conflict در reschedule؛ migration و refund خارج از Scope.
تصمیم‌های معتبر: timezone=کلینیک (ADR-014، 2026-09-05).
تصمیم باز: بازه‌های چسبیده؛ owner محصول، deadline فردا، default DECIDE.
Facts: route X → service Y؛ test Z با command `pnpm test ...` پاس/خطا.
شاهد: مسیرها، commit یا timestamp نتیجه؛ confidence.
کار بعدی: test concurrency را بخوان؛ سپس فقط با criterion تأییدشده برنامه بنویس.

خلاصه نباید «همه‌چیز درست است» یا «تصمیم گرفته شد» بنویسد مگر با مسیر و صاحب authority. تست سبز بدون command، revision و Scope، evidence کافی نیست. برای اطلاعاتی که احتمالاً بعداً لازم می‌شود، identifier نگه دارید، نه محتوای ۲۰۰ خطی: path، query ذخیره‌شده، SHA یا URL مستقیم. سپس در Context بعدی همان منبع را دوباره retrieve کنید.

## آزمایشگاه: بودجهٔ بررسی conflict بساز

**ورودی:** brief reschedule، ledger فصل ۲ و یک checkout ساختگی از booking-platform. **گام‌ها:** ۱) هدف یک‌جمله‌ای و سه non-goal بنویس. ۲) فهرست Context را در چهار ستون همیشه‌فعال، اولیه، just-in-time و حذف‌شدنی تقسیم کن. ۳) برای هر مورد اولیه، تصمیم مصرف‌کننده و منشأ را بنویس. ۴) فقط نام و مسیر handler، test و schema را پیدا کن؛ محتوا را یک‌جا paste نکن. ۵) یک خلاصهٔ شش‌خطی با Fact، Decision و فرمان Verification بساز.

**فرمان نمونه:** `rg -n "reschedule|conflict" apps/api packages apps/web`؛ در مخزن واقعی فرمان معادل package manager را از manifest کشف کن، نه حدس.

**خروجی مورد انتظار:** نقشه‌ای که مسیرهای محتمل، یک Decision بازِ مالک‌دار و یک فرمان محدود دارد؛ raw logهای طولانی، secret و policy حل‌نشده در آن نیست.

**Recovery:** اگر خروجی `rg` صدها match دارد، آن را به module یا test محدود و فقط چند match لازم را باز کن. اگر خلاصه owner یا مسیر شاهد ندارد، نتیجه را Fact قطعی نام نده و retrieval را تکرار کن. اگر Context پر شد، tool output قابل‌بازتولید را حذف کن، اما criterion، تصمیم معتبر و سؤال باز را در durable state نگه دار.

## خطاهای رایج و نشانه‌ها

• **پنجره را با repository یکی می‌گیریم:** prompt شامل archive و log است اما هدف یک test محلی است.
• **دستورهای متناقض همیشه‌فعال‌اند:** Agent یک‌بار test می‌زند و بار دیگر آن را ممنوع می‌داند.
• **تازگی فراموش می‌شود:** نتیجهٔ branch قدیمی مثل وضعیت فعلی گزارش می‌شود.
• **فشرده‌سازی authority را حذف می‌کند:** «لغو مجاز است» می‌ماند، اما owner و ADR حذف شده‌اند.
• **فضای کاری صفر است:** هر ابزار خروجی بزرگی برمی‌گرداند و جایی برای مقایسهٔ Factها نمی‌ماند.

## چک‌لیست Verification

• [ ] هر Context اولیه مصرف‌کننده، منشأ و تاریخ/commit لازم دارد.
• [ ] دستور، هدف، شواهد و فضای کار در بودجه جدا شده‌اند.
• [ ] Lost in the Middle را پژوهش تجربی، Context Rot را گزارش فنی Chroma و راهنمای Context Anthropic را گزارش جداگانهٔ فروشنده برچسب زده‌ام.
• [ ] policy باز با `DECIDE` مانده و به Fact تبدیل نشده است.
• [ ] خلاصه شامل مسیر، فرمان و محدودیت Evidence است.
• [ ] اطلاعات حساس و raw output غیرضروری وارد Context نشده است.

## تمرین مستقل

برای بررسی bug «گاهی دو رزرو هم‌زمان تأیید می‌شوند»، Context budget یک نوبت Agent را طراحی کن: پنج مورد برای بارگذاری اولیه، سه مورد just-in-time و یک قالب compaction.

**Rubric پاسخ:** پاسخ پذیرفتنی هدف و criterion مشاهده‌پذیر، مسیرهای service/test/schema، Scope read-only یا دلیل write، و تصمیم‌های بازِ tenant/timezone را جدا می‌کند. برای هر Fact شاهد و تازگی دارد، log خام را Evidence نهایی نمی‌نامد، و خلاصهٔ آن command یا مسیر بازیابی دارد. پاسخی که تمام repo یا policy بی‌مالک را در Context می‌ریزد مردود است.

## جمع‌بندی

پنجرهٔ بزرگ جای انتخاب مهندسی را پر نمی‌کند. Context پُرسیگنال، هدف، authority، شاهد و فضای کار را نگه می‌دارد و دادهٔ قابل‌بازیابی را با identifier به بیرون منتقل می‌کند. درس بعد از همین نقشهٔ سبک استفاده می‌کند تا Agent پیش از تغییر، مخزن را مرحله‌به‌مرحله بشناسد.

## منابع مستقیم

• [Anthropic — Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) — گزارش فنی فروشنده؛ توصیهٔ Context کم‌حجم و بازیابی just-in-time، نه قانون عمومی.
• [Chroma — Context Rot](https://research.trychroma.com/context-rot) — گزارش فنی فروشنده دربارهٔ افت عملکرد در ارزیابی‌های طول ورودیِ خود؛ نه آستانهٔ عمومی برای همهٔ مدل‌ها.
• [Liu et al. — Lost in the Middle](https://aclanthology.org/2024.tacl-1.9/) — پژوهش تجربی دربارهٔ اثر موقعیت اطلاعات در Context بلند.
• [Claude Code best practices](https://www.anthropic.com/engineering/claude-code-best-practices) — راهنمای رسمی فروشنده برای workflow و Context ابزار.

به زبان ساده

Context انبار همهٔ فایل‌ها نیست؛ بودجه‌ای برای اطلاعاتی است که تصمیم بعدی را بهتر می‌کنند. شواهد دارای مسیر، منشأ و تازگی از transcript طولانی ارزش بیشتری دارند.

مثال واقعی

پژوهش «Lost in the Middle» اثر جایگاه اطلاعات در Context را در ارزیابی‌های خود بررسی کرد؛ این نتیجهٔ تجربی است و قانون ثابتی برای همهٔ مدل‌ها یا اندازه‌های prompt نیست.