درون سازوکار حذف لبه‌های فنی هنگام انتقال مهارت‌های عامل‌های هوشمند

تصور کنید برنامه‌نویسی هستید که یک باگ پیچیده را پس از ساعت‌ها کلنجار رفتن با یک عامل هوش مصنوعی حل کرده، اما وقتی می‌خواهد این تجربه را برای تیمش مستند کند، نیمی از جزئیات حیاتی را فراموش می‌کند. این دقیقاً همان جایی است که «دانش سازمانی» تبدیل به یک خروجی ناقص و دارای فقدان (Lossy Export) می‌شود. در واقع، یک پرامپت با «قصد» شروع می‌شود، اما یک مهارت باید با «شواهد» آغاز شود. نوشتن مهارت‌های عامل (Agent) — که می‌توان آن‌ها را شبیه به دستورالعمل‌های گام‌به‌گام برای یک دستیار دیجیتال دانست — بر اساس حافظه را می‌توان نسخه‌ای برای از دست رفتن دانش سازمانی دانست.

طبق گزارش‌های فنی، وقتی توسعه‌دهندگان مهارت‌ها را بر اساس آنچه «فکر می‌کنند» جواب داده است می‌نویسند، لبه‌های تیزِ موارد خاص (Edge Cases) و پیکربندی‌های دقیقی که واقعاً مشکل را حل کرده بود، حذف می‌شوند. در حقیقت، آن‌ها یک خروجی ناقص خلق می‌کنند که تمام جزئیات فنی و تنظیمات خاصی که منجر به حل مسئله شد را حذف می‌کند.

این چرخش به سمت مهندسی عامل‌محور (Agentic) به‌سرعت در حال رخ دادن است. تقریباً تمام پلتفرم‌های بزرگ فعلاً در حال عرضه «مهارت‌ها» به‌عنوان لایه‌ی انتزاعی جدید در پشته‌ی هوش مصنوعی هستند و هر تیمی در حال ایجاد پوشه‌ای برای ذخیره این مهارت‌هاست. اما مشکل اینجاست که اکثر تیم‌ها با این مهارت‌ها مانند کتابخانه‌های پرامپت سال ۲۰۲۴ رفتار می‌کنند؛ یعنی مجموعه‌ای از متون هوشمندانه که توسط کسی به‌صورت دستی نوشته شده که «تقریباً مطمئن است» چه چیزی جواب داده است، بدون اینکه هیچ پیشینه‌ی عملیاتی متنی (Operational Provenance) داشته باشد. این رویکرد سطحی یادآور آن است که چرا برخی متخصصان توصیه می‌کنند به جای تکیه بر معماری پیچیده، با ابزارهای دستیار کد به عنوان مهندسان جونیور رفتار کنیم تا انتظارات از خروجی آن‌ها واقع‌بینانه باشد.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، نبودِ مستندات دقیق در لایه‌های زیرین، ریسک‌های عملیاتی را افزایش می‌دهد. در مارس ۲۰۲۶، یک مقاله پژوهشی درباره‌ی دانش سازمانی در توسعه‌ی هوش مصنوعی، مفهوم «سایه تصمیم» (Decision Shadow) را معرفی کرد. بر اساس این پژوهش، توسعه هوش مصنوعی از این بیماری رنج می‌برد؛ در حالی که یک Commit در کد، تغییرات (Diff) را ثبت می‌کند، اما دلیل آن تصمیم — یعنی محدودیت‌ها، جایگزین‌های رد شده و زمینه‌های آینده‌نگر که شکل‌دهنده تصمیم بودند — را به کلی حذف می‌کند.

فایل‌های مربوط به مهارت‌ها نیز دچار همین نقص هستند. اگر یک هفته پس از یک جلسه موفق، بخواهید آن مهارت را بازسازی کنید، احتمالاً تنها یک نسخه ۸۰ درصدی از واقعیت را تولید خواهید کرد. شما با اعتمادبه‌نفس عمل می‌کنید اما ناقص هستید. شما پیام خطای خاص، تنظیماتی که در نهایت جواب داد یا تغییر کوچک در پیکربندی (Config tweak) که واقعاً تفاوت را ایجاد کرد، فراموش می‌کنید. چون فراموش کرده‌اید که این جزئیات را می‌دانستید، آن‌ها را حذف می‌کنید و مهندس بعدی را مجبور می‌کنید تا این قطعات گمشده را حدس بزند. این پدیده با تله‌ی بازنویسی سوابق که منجر به افت شدید دقت عامل‌ها شده است شباهت دارد و نشان می‌دهد چگونه فقدان حافظه دقیق می‌تواند منجر به شکست عملیاتی شود.

سیلوهای دانش (Knowledge Silos) همیشه بلای جان مهندسی بوده‌اند؛ جایی که اطلاعات فقط در ذهن یک نفر یا در یک رشته‌توییک (Thread) قدیمی در Slack است که دیگر از دید خارج شده است. طبق نظرسنجی توسعه‌دهندگان Stack Overflow در سال ۲۰۲۴، حدود ۴۵ درصد از برنامه‌نویسان گزارش دادند که این سیلوهای دانشی سه بار یا بیشتر در هفته بر بهره‌وری آن‌ها ضربه می‌زند.

عامل‌های هوش مصنوعی این مشکل را تشدید کرده‌اند. پژوهش‌ها روی تیم‌های کدنویسی با AI نشان می‌دهد که وقتی ابزارهای هوشمند میانجیِ حل مسئله می‌شوند، سازمان‌ها با ریسک واقعیِ کاهش اعتماد متقابل و تقویت سیلوهای دانش مواجه می‌شوند. پیش از این، حل مسئله بین آدم‌ها رخ می‌داد و دیگران می‌توانستند آن را بشنوند؛ اما حالا حل مسئله بین یک مهندس و یک عامل در جلسه‌ای رخ می‌دهد که هیچ‌کس دیگر آن را نمی‌بیند.

این وضعیت، نه تنها سیلویی بین افراد، بلکه سیلویی بین «جلسات» ایجاد می‌کند. هر اجرای عاملی که بدون ثبت (Capture) انجام شود، دانشی سازمانی است که پیش از رسیدن به هر کسی، حتی خودِ اجراکننده، تبخیر می‌شود. اگر تیم شما بدون تاریخچه جلسات، مهارت‌ها را دستی می‌نویسد، در واقع در حال سیستماتیک کردنِ «حدس‌ها با فرمت بهتر» است، نه آنچه واقعاً کار کرده است.

پلتفرم Paper Console تلاش می‌کند با تبدیل تاریخچه جلسات به یک مخزن ماندگار، این چرخه را بشکند. این اقدام ضروری است زیرا پژوهشگران حوزه مهندسی نرم‌افزار تأکید می‌کنند که داشتن مخازنی از الزامات، دستورالعمل‌های عامل و منطق طراحی در کنار پیاده‌سازی‌ها، تنها راه کاهش «بهای شناختی» (Cognitive Debt) است.

به جای نوشتن دستی مهارت‌ها، این پلتفرم یک حلقه بهبود مستمر را پیشنهاد می‌کند که در آن مهارت، خروجیِ حلقه است، نه ورودی آن:

• اجرای عامل: شروع تکلیف و ثبت کامل جلسه.
• بازرسی: بررسی مسیر واقعی طی شده، نه یک خلاصه سطحی، بلکه مسیر دقیق اتفاقات.
• استخراج: شناسایی الگوهای تکرار شونده از دل شواهد.
• تولید: ایجاد مهارت بر اساس دستورات واقعی، خطاهای واقعی و راهپاله‌ای که جواب داد.
• بازبینی و بازاستفاده: تکرار روند و شروع جلسه بعدی.

این رویکرد شواهد-محور، مهارت‌ها را از «حدس‌های خوش‌فرمات» به مصنوعات عملیاتی تبدیل می‌کند. برای مثال، توسعه‌دهنده‌ای به نام برایان از این روش برای حل یک باگ تکراری در دو مخزن مختلف استفاده کرد. او به‌جای دیباگ کردن از صفر برای بار دوم، راهکار را مستقیماً از جلسات ضبط‌شده‌اش استخراج کرد. او توانست داستان کامل را بنویسد، از جمله یک جدول عیب‌یابی که مهارت به‌صورت خودکار ثبت کرده بود، زیرا او واقعاً با تک‌تک ردیف‌های آن جدول در طول مسیر مواجه شده بود.

اشتراک‌گذاری آگاهانه دانش صرفاً یک تجمل نیست، بلکه یک ضرب‌کننده عملکرد است. طبق گزارش‌های صنعتی، ابتکار شرکت Code Climate برای ترویج اشتراک‌گذاری آگاهانه دانش — به‌ویژه ثبت تصمیمات کلیدی و مستندسازی مسیرهای جدید کاری — باعث شد توان عملیاتی (Throughput) تیم‌ها تقریباً ۷۰ درصد افزایش یابد.

تیم‌هایی که بیشترین بهره را از هوش مصنوعی می‌برند، لزوماً کسانی نیستند که پرامپت‌های بهتری می‌نویسند؛ بلکه کسانی هستند که هر چه عامل‌هایشان انجام می‌دهند را «ارزش نگهداری» می‌دانند. هدف این است که دانش از تاریخچه ترمینال یک نفر یا یک تب بسته شده، به جایی منتقل شود که کل تیم بتواند آن را ببیند، اجرا کند و روی آن بسازد.

تیم‌ها می‌توانند با استفاده از paper CLI تضمین کنند که مهارت‌هایشان با شواهد آغاز می‌شود. با این ابزار، جلسه دیباگ تک‌نفره‌ی یک مهندس در روز سه‌شنبه، به مهارتی تبدیل می‌شود که هر کسی در روز چهارشنبه می‌تواند آن را فراخوانی کند. این کار با انتقال دانش از یک تاریخچه خصوصی به یک کنسول مشترک، سیلوهای دانشی را می‌شکند.

برای شروع انتقال از حافظه به شواهد، ابزار paper CLI را نصب کنید:
curl -fsSL https://download.papercompute.com/install | sh

سپس دستور paper start claude را اجرا کرده و ثبت جلسات را آغاز کنید. اولین جلسه‌ای که نگه می‌دارید، اولین جلسه‌ای است که تیم شما واقعاً می‌تواند از آن درس بگیرد. نوشتن مهارت‌ها از روی حافظه را متوقف کنید؛ حافظه شما یک خروجی ناقص (Lossy export) است، اما جلسه ثبت شده نیست.

گام بعدی شما

• نصب ابزار paper CLI با دستور curl -fsSL https://download.papercompute.com/install | sh برای شروع ثبت جلسات.
• جایگزینی نوشتن دستی مهارت‌ها با متد «اجرا $\rightrightarrows$ بازرسی $\rightrightarrows$ استخراج» برای حذف خطاهای حافظه.
• ایجاد یک مخزن مشترک از تاریخچه جلسات عامل‌ها برای تبدیل تجربیات فردی به دارایی‌های تیم.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.