هر سیستم عاملی (agent system) با همان سبکسنگین کردن (trade-off) دشوار روبرو است. شما یک پایگاه دانش عمیق و سازمانیافته میخواهید که در بررسیهای کد (code reviews) و تاریخچه git دوام بیاورد. اما در عین حال نیاز دارید که زمان اجرا (runtime) سریع عمل کرده و متمرکز بماند. این دو نیاز با هم در تضاد هستند. هرچه دستورالعملهای بیشتری را حفظ کنید، وسوسه بیشتری ایجاد میشود که همه آنها را در پرامپت (prompt) بریزید و به بهترین نتیجه امیدوار باشید. این امید، هزینهبر است.
در اکوسیستم Agent Project Context، این تنش به طور مشخص بین دو لایه تقسیم میشود. APC مسئول پایداری (durability) است و APX مسئول سرعت. درک نحوه تعامل آنها — و اینکه چرا APX از بارگذاری پیشفرض (preload) تمام تعاریف مهارتها خودداری میکند — بیش از آنچه اکثر راهنماهای بهینهسازی به شما میگویند، درباره مهندسی پرامپت (prompt engineering) حقایق را آشکار میکند.
آرشیو و موتور
وظیفه APC ماندگاری است. این سیستم فایلهای مهارت قابل استفاده مجدد را در مسیر .apc/skills/ به صورت اسناد ساده Markdown ذخیره میکند. از آنجایی که این فایلها درون مخزن (repository) شما قرار دارند، همراه با کنترل نسخه (version control) مدیریت میشوند. شما میتوانید یک pull request باز کنید که یک فرآیند استقرار (deployment) را تغییر دهد. میتوانید یک بازگشت (rollback) سیاست امنیتی مربوط به شش هفته پیش را با دستور diff بررسی کنید. میتوانید دقیقاً ممیزی (audit) کنید که عامل قرار بود چه چیزی را در چه زمانی بداند. این قابلیت بازبینی زمانی اهمیت پیدا میکند که یک استقرار اشتباه عملیاتی شود یا یک ممیز انطباق (compliance auditor) شروع به پرسیدن سوال کند.
از سوی دیگر، APX در لحظه زندگی میکند. این سیستم مکالمه واقعی بین شما و مدل را مدیریت میکند. هدف آن آرشیو کردن دانش نیست، بلکه استفاده دقیق از آن است. وقتی APX با مهارتها مانند یک بار اضافی همیشگی برخورد میکند، کل سیستم کند میشود. پنجره بافت (context window) پر میشود. هزینههای توکن (token) بالا میرود. بدتر از آن، توجه مدل میان دستورالعملهایی که هیچ ارتباطی با درخواست فعلی ندارند، پراکنده میشود.
به همین دلیل است که بدنه مهارتها به صورت درخواستی (on demand) بارگذاری میشوند.
هزینه واقعی یک پرامپت حجیم
اکثر تیمها میدانند که توکنها هزینه دارند. اما تیمهای کمتری متوجه هستند که توکنهای بیربط، دقت را قربانی میکنند.
وقتی APX هر مهارت موجود را در هر مرحله (turn) تزریق میکند، پرامپت پر از نویز میشود. مدل همزمان دفترچه راهنمای استقرار (deployment runbook)، راهنمای امنیتی، مرجع سبک API، چکلیست تست و سوالات متداول (FAQ) مربوط به آشنایی با سیستم را دریافت میکند. حتی با یک پنجره بافت بزرگ، وقتی مدل مجبور است ابتدا میان نویزها جستجو کند تا سیگنال (اطلاعات مفید) را پیدا کند، کیفیت استدلال کاهش مییابد. ممکن است هنگام پاسخ به سوالی درباره تنظیمات تست محلی، به یک الزام امنیتی که برای استقرار در محیط عملیاتی (production) در نظر گرفته شده، چسبیده و آن را ملاک قرار دهد. ممکن است مراحل یک چکلیست انتشار را در یک رفع باگ ساده، توهم (hallucinate) بزند. هر پاراگراف اضافی از متن بیربط، یک عامل حواسپرتی است که منتظر وقوع است.
محاسبات ساده است. اکثر مراحل به اکثر مهارتها نیاز ندارند. اگر شما درخواست یک اصلاح سریع برای یک لاگ خطا را دارید، نیازی به متن کامل دفترچه راهنمای استقرار یا راهنمای مقاومسازی امنیتی ندارید. شما نیاز دارید که مدل خطا را ببیند، قراردادهای پروژه شما را درک کند و فایل درست را ویرایش کند. بارگذاری بدنه مهارتهای بیربط به مدل در انجام این کار کمکی نمیکند؛ بلکه مدل را مجبور میکند تا قبل از شروع کار روی مشکل اصلی شما، دادههای بیاستفاده را فیلتر کند.
نحوه عملکرد بارگذاری درخواستی
این مکانیسم ساده اما هوشمندانه است. APC همچنان مرجع اصلی (ground truth) را نگه میدارد. تعاریف مهارتهای شما در جای خود باقی میمانند: در .apc/skills/<name>.md.
APX آن فایلها را در حافظه فعال کپی (mirror) نمیکند. در عوض، یک فهرست فشرده از نام مهارتها تهیه میکند. مدل این لیست را میبیند و درک میکند که یک کاتالوگ وجود دارد. اگر نیاز داشته باشد قابلیتهای موجود را مرور یا تأیید کند، میتواند یک فراخوانی list_skills انجام دهد. این کار به مدل دید (visibility) میدهد بدون اینکه حجم دادهها را بالا ببرد.
زمانی که وظیفه واقعاً به نحو نگارش دقیق، مراحل جزئی یا محدودیتهای خاص کدگذاری شده در یک فایل مهارت نیاز داشته باشد، مدل load_skill را فراخوانی میکند. در آن لحظه، و فقط در آن لحظه، APX بدنه کامل Markdown را از APC میگیرد و آن را به بافت (context) تزریق میکند. دستورالعمل به صورت آماده (hot) وارد میشود، یک بار برای هدف مورد نظر استفاده میشود و سیستم از حمل کردن آن به عنوان بار اضافی جلوگیری میکند.
تفاوت بین وارد کردن (import) یک کتابخانه و کپی کردن تمام تعاریف توابع در فایل اصلی خود را در نظر بگیرید. یک روش باعث میشود کد شما قابل پیمایش باقی بماند، اما روش دیگر آشفتگیای ایجاد میکند که فقط از روی شانس کامپایل میشود.
چه کسی پیروز است وقتی مهارتها با هم تداخل پیدا میکنند
APX همچنین هنگام بارگذاری مهارتها، یک ترتیب اولویت مشخص را اعمال میکند. هر محیطی یکسان نیست و توصیههای عمومی هرگز نباید جایگزین دانش محلی شوند.
مهارتهای پروژهای (Project skills) در اولویت اصلی قرار دارند. این فایلها در مخزن فعلی شما در مسیر .apc/skills/ قرار دارند. آنها قراردادهای خاص تیم شما، پوششهای سفارشی (custom wrappers)، استانداردهای نامگذاری قدیمی و زنجیره ابزار (toolchain) خاص شما را ثبت میکنند. اگر پروژه شما روش خاص خود را برای مدیریت مهاجرتهای پایگاه داده (database migrations) تعریف کرده باشد، آن تعریف اولویت دارد.
مهارتهای سراسری (Global skills) در مرحله بعد قرار دارند. اینها الگوهای در سطح سازمان را پوشش میدهند که در صورتی که خودِ پروژه سکوت کرده باشد، اعمال میشوند. آنها مانند یک کتابخانه استاندارد عمل میکنند.
مهارتهای زمان اجرای داخلی (Built-in runtime skills) در پایینترین سطح به عنوان گزینه جایگزین (fallback) قرار میگیرند. آنها قابلیتهای عمومی را مدیریت میکنند که هر عاملی (agent) باید درک کند، اما هیچ پروژه خاصی برای بازتعریف آنها زحمتی به خود نداده است.
این رویکرد لایهبندی شده به این معناست که مخزن شما کنترل رفتار خود را حفظ میکند. یک مهارت سراسری یا داخلی نمیتواند بهطور تصادفی گردش کاری (workflow) را که تیم شما تعمداً سفارشیسازی کرده است، مختل کند.
این موضوع در عمل چگونه به نظر میرسد
یک وظیفه نگهداری معمولی را تصور کنید. یکی از همکاران یک گزارش خطا (error log) را در چت میچسباند. ردپای خطا (traceback) به یک مرجع تهی (null reference) واحد در یک ماژول کمکی اشاره دارد. اصلاح آن احتمالاً دو خط کدنویسی دفاعی است.
در سیستمی بدون بارگذاری در لحظه (on-demand loading)، APX تمام مهارتهایی را که میشناسد در بافتار (context) میریزد. اکنون مدل باید چهل صفحه متن را قبل از دست زدن به آن دو خط بررسی کند. چکلیست انتشار را میبیند و از خود میپرسد که آیا باید نسخه را ارتقا دهد یا خیر. راهنمای امنیتی را میبیند و به اعتبارسنجی ورودی در تابعی فکر میکند که فقط به یک بررسی تهی (null check) نیاز دارد. دستورالعمل استقرار (deployment runbook) را میبیند و شروع به فکر کردن درباره محیطهای مرحلهای (staging environments) میکند. مدل از مسیر اصلی منحرف میشود. پاسخ طولانیتر میشود. شمارشگر توکنها به سرعت بالا میرود.
با طراحی در لحظه (on-demand) در APX، مدل فقط نامها را میبیند. میداند که [release-checklist]، [security-guide]، [deployment-runbook] و [error-handling] وجود دارند. سه مورد اول را نادیده میگیرد. اگر قراردادهای پروژه شما برای ایمنی تهی (null safety) خاص باشد، ممکن است [error-handling] را بارگذاری کند. باگ را اصلاح میکند. مهارتهای بیربط هرگز وارد پنجره بافتار (context window) نشدند. مدل متمرکز ماند زیرا دستور (prompt) تمیز باقی ماند.
همین منطق زمانی که وظیفه واقعاً پیچیده باشد نیز صادق است. اگر بعداً از عامل بخواهید یک استقرار در محیط عملیاتی (production deployment) را آماده کند، میتواند دستورالعمل استقرار را بارگذاری کند، با راهنمای امنیتی مشورت کند و دقیقاً زمانی که آن مراحل مرتبط میشوند، از چکلیست انتشار پیروی کند. دانش همیشه آنجا بود؛ فقط منتظر لحظه مناسب ماند.
انضباط در دستور (Prompt Discipline) به عنوان معماری
جدایی بین APC و APX صرفاً یک جزئیات پیادهسازی نیست؛ بلکه فلسفهای از انضباط در دستور (prompt discipline) است. APC دانش را برای همیشه حفظ میکند و آن را قابل بازبینی، دارای نسخه و ایمن میسازد. APX تصمیم میگیرد چه مقدار از آن دانش در حال حاضر جایگاهی در بافتار فعال داشته باشد.
یک کاتالوگ مهارت غنی، یک دارایی است. یک دستور (prompt) حجیم، یک بدهی است. هدف این است که بافتار خود را قابل حمل نگه دارید بدون اینکه همیشه فعال باشد. مخزن شما باید شامل تمام دستورالعملهایی باشد که تیم شما تا به حال نوشته است، اما عامل باید فقط مواردی را بخواند که به وظیفه فوری کمک میکنند.
اگر سیستم شما مدل را مجبور کند که بدنه هر مهارت را در هر مرحله با خود حمل کند، شما در حال ساخت یک دستیار هوشمند نیستید. شما در حال ساخت کتابداری هستید که کل آرشیو را به هر میز پرسش و پاسخ میکشاند. همه چیز را ذخیره کنید. آنچه مهم است را بارگذاری کنید. اینگونه است که عاملها را سریع، بافتار را تمیز و استدلال را دقیق نگه میدارید.