تصور کنید هر روز صبح، یک ویراستار سخت‌گیر تمام تغییرات فنی پروژه شما را بخواند و آن‌ها را به متنی جذاب تبدیل کند، اما هر کلمه را با خط‌کش اندازه بگیرد تا هیچ اشتباهی رخ ندهد. این دقیقاً همان چیزی است که تیم Agenthood در ۱۹ اوت ۲۰۲۶ با اجرای PR #64 به دست آورد تا فرآیند دستی و زمان‌بر انتشار خبرنامه‌ها را جایگزین کند. در واقع، آن‌ها یک اتوماسیون خاص را برای جایگزینی فرآیندی دستی پیاده کردند که با رشد پروژه، دیگر قابلیت مقیاس‌پذیری نداشت. اکنون، یک عامل (Agent) خبرنامه روزانه، وظیفه خسته‌کننده خلاصه کردن تغییرات (changelogs) را بر عهده دارد تا اطمینان حاصل شود که یادداشت‌های انتشار بدون نیاز به پیش‌نویس دستی منتشر می‌شوند.
بیشتر اتوماسیون‌های هوش مصنوعی به دلیل نبود حفاظ‌ها (Guardrails) شکست می‌خورند و منجر به تولید ویژگی‌های خیالی (Hallucinations) یا به‌هم‌ریختگی فرمت متن می‌شوند. این چالش‌ها یادآور اهمیت استقرار گیره‌های ایمنی در گیت‌هاب است که برای جلوگیری از اشتباهات احتمالی عامل‌های هوش مصنوعی طراحی شده‌اند. Agenthood برای حل این مشکل، خروجی مدل زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — را به عنوان یک ورودی غیرقابل‌اعتماد می‌بیند. به جای تکیه بر «حس کلی» (Vibe) مدل، این سامانه یک قرارداد ماشین‌خوان را تحمیل می‌کند که هر پیش‌نویس باید پیش از رسیدن به چشم انسان، از آن عبور کند.
زمینه و معماری
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی مدل‌ها بزرگ‌ترین ریسک استقرار است. در این معماری، خط لوله بر دو رکن استوار است: اسکریپت scripts/generate-news-digest.mjs برای منطق نویسندگی و ورک‌فلو .github/workflows/news-digest.yml برای زمان‌بندی و مدیریت درخواست‌های ادغام (PR).
طبق گزارش منتشر شده در dev.to، این ورک‌فلو هر روز ساعت ۰۶:۰۰ UTC فعال می‌شود، هرچند که از طریق workflow_dispatch امکان اجرای دستی آن نیز وجود دارد. برای حفظ خاصیت Idempotency (یکسان‌سازی نتیجه در اجراهای مکرر)، سامانه از یک سیستم مبتنی بر slug استفاده می‌کند؛ یعنی اگر اسکریپت در یک روز چند بار اجرا شود، در دفعات دوم به بعد هیچ عملیاتی انجام نمی‌دهد (no-op). عامل از طریق یک پروتکل ماشین‌خوان بسیار کوچک — با استفاده از دستورات WROTE <path> یا NOOP <reason> — ارتباط برقرار می‌کند. این رویکرد ساختاریافته به مدیریت تاریخچه تعاملات شباهت دارد، مشابه آنچه در سیستم کنترل نسخه Gitlord برای گفتگوهای AI مشاهده می‌کنیم. این طراحی اجازه می‌دهد تا تست‌ها بتوانند نتایج را بدون نیاز به تجزیه و تحلیل (Parsing) متن واقعی مقالات، تایید کنند.
در گام اول، این ورک‌فلو بازه زمانی مورد نظر را محاسبه می‌کند. این کار از طریق دریافت لیست انتشارها (Releases) از مخزن Agenthood انجام می‌شود که تاریخ انتشار آن‌ها بعد از جدیدترین تاریخ ثبت شده در فایل content/news/manifest.json باشد. اگر هیچ مورد جدیدی یافت نشود، فرآیند بلافاصله متوقف شده و هیچ PRای ایجاد نمی‌شود.
جزئیات فنی خط لوله
جزئیات فنی این خط لوله به شرح زیر است:
- مدل مورد استفاده: سیستم از مدل OpenCode Go (نسخه deepseek-v4-flash) با دمای (Temperature) ۰.۳ و محدودیت ۸,۱۹۲ توکن استفاده می‌کند.
- اعتبارسنجی سخت‌گیرانه: پیش‌نویس‌ها در برابر یک قرارداد سخت‌گیرانه بررسی می‌شوند. برای مثال، عنوان باید دقیقاً با اولین تیتر H1 مطابقت داشته باشد تا از این اتفاق جلوگیری شود که سیستم یک چیز را تبلیغ کند اما در متن درباره چیز دیگری بنویسد. همچنین، خلاصه متن نباید از ۱۶۰ کاراکتر بیشتر شود تا از قطع شدن متن (Truncation) در کارت‌های صفحه خبر جلوگیری شود.
- یکپارچگی متادیتا (Front Matter): برای جلوگیری از خرابی فایل‌ها، سیستم اجبار می‌کند که عنوان، نویسنده و خلاصه با فرمت YAML اسکیپ (Escape) شوند. این کار تضمین می‌کند که وجود یک علامت نقل‌قول یا خط جدید در متن، باعث تخریب ساختار Front Matter نشود.
- مدیریت خطا: در صورت رد شدن پیش‌نویس در مرحله اعتبارسنجی، اسکریپت یک بار دیگر تلاش می‌کند. در این مرحله، دلایل دقیق رد شدن (مثلاً: "پیش‌نویس شما رد شد زیرا: فیلد title در front matter با تیتر # مطابقت ندارد") به مدل بازگردانده می‌شود تا اصلاحات لازم را اعمال کند.
- دروازه ایمنی: عامل به طور کامل از Push مستقیم به شاخه main منع شده است. او تنها مجاز است یک Pull Request در شاخه‌ای با نام
news-digest/<date>باز کند و برچسب "automation" را به آن بزند تا در نهایت توسط یک انسان تایید و ادغام شود.
مشخصات لحن (Tone Specification)
در مورد لحن نوشته‌ها، Agenthood به جای توصیفات کلی، یک «مشخصات فنی» (Spec) را در پرامپت سیستم کدگذاری کرده است. مدل موظف است لحنی گرم، حرفه‌ای و دقیق با استفاده از ضمیر جمع اول شخص («ما منتشر کردیم...») داشته باشد.
برای دوری از «زبان بازاری» (Marketing Speak)، این مشخصات صراحتاً استفاده از ایموجی‌ها، علامت تعجب و عباراتی مانند «تحول‌آفرین» (game-changing) را ممنوع کرده است. به عامل دستور داده شده است که جزئیات عینی — مانند محدودیت‌ها، زمان‌های انتظار (Timeouts) و نام فایل‌ها — را بر ترجیحات مبهم و ستایش‌آمیز مقدم بداند. همچنین، مدل اکیداً از اختراع ویژگی‌ها، اصلاحات، لینک‌ها یا نقل‌قول‌های خبری منع شده است.
یافته‌های «بازبین» (Reviewer)
این اتوماسیون پیش از اجرا، تحت همان خط لوله بازبینی سخت‌گیرانه‌ای قرار گرفت که هر کد دیگری در این پروژه می‌بیند. این فرآیند منجر به شناسایی چهار باگ بحرانی پیش از فعال شدن نهایی عامل شد:
- صفحه‌بندی (Pagination): لیست انتشارها صفحه‌بندی نشده بود. اگر فاصله زمانی به گونه‌ای بود که بیش از ۱۰۰ انتشار وجود داشت، موارد جدیدتر به طور بی‌صدا حذف می‌شدند. این مشکل با ایجاد یک حلقه صفحه‌بندی (تا ۱۰ صفحه در هر کدام ۱۰۰ مورد) اصلاح شد.
- تداخل PRها: اجراهای متوالی می‌توانستند برای یک بازه زمانی یکسان، چندین PR متداخل ایجاد کنند. راه حل این بود که اگر هر PR با الگوی
news-digest/*در حالت باز (Open) بود، اجرای جدید نادیده گرفته شود. - خطاهای گذرا: یک خطای تک ۵۰۳ می‌توانست کل اجرای روزانه را متوقف کند. تیم برای بازتلاش‌های HTTP در کدهای ۵xx، مکانیزم عقب‌نشینی نمایی (Exponential Backoff) با توالی ۱ ثانیه $\rightarrow$ ۲ ثانیه $\rightarrow$ ۴ ثانیه را پیاده کرد.
- تزریق YAML: متوجه شدند که فیلد نویسنده در Front Matter اسکیپ نشده است. یک خط جدید یا یک نقل‌قول می‌توانست کل متادیتا را خراب کند؛ این یک باگ کلاسیک از نوع تزریق (Injection) بود که تنها از طریق بازبینی انسانی کشف شد.
تحلیل اعداد و ارقام
- تست‌های خبرنامه: ۱۷ مورد (از مجموع ۸۰ تست در مخزن)
- تلاش‌های LLM در هر اجرا: حداکثر ۲ بار
- تعداد بازتلاش HTTP برای خطای 5xx: ۳ بار
- سقف تعداد کاراکتر خلاصه: ۱۶۰ کاراکتر
- زمان رسیدن به اولین خبرنامه: همان روزی که عامل ادغام شد
این رویکرد نقش انسان را از «نویسنده» به «سردبیر» تغییر می‌دهد. برای توسعه‌دهندگان، این یک درس مهم است: راه رسیدن به جریان‌های کاری قابل‌اعتماد، مهندسی پرامپت بهتر نیست، بلکه ایجاد دروازه‌های اعتبارسنجی سخت‌گیرانه‌تر است. سیستم به «خلبان خودکار» اعتماد نمی‌کند، بلکه به «قراردادی» اعتماد می‌کند که کار خلبان خودکار را اعتبارسنجی می‌کند.
تیم قصد دارد این خط لوله را گسترش دهد و دو عامل جدید معرفی کند: The Herald برای پیش‌نویس یادداشت‌های انتشار و The Mailman برای بازنشر مطالب در پلتفرم‌های مختلف، تا بخش توزیع ارتباطات خود را نیز کاملاً خودکار کند. این توسعه در راستای استانداردهایی است که پلاگین‌های عامل‌های هوش مصنوعی را برای جابجایی بین پلتفرم‌های مختلف تسهیل می‌کنند.
گام بعدی شما
- اگر از عامل‌های هوش مصنوعی استفاده می‌کنید، خروجی آن‌ها را به جای بررسی بصری، با اسکریپت‌های اعتبارسنجی (Validation Scripts) چک کنید.
- برای مدل‌های تولید محتوا، فهرستی از «کلمات ممنوعه» (Banned Words) تعریف کنید تا از لحن تبلیغاتی فاصله بگیرند.
- هرگز اجازه دسترسی مستقیم (Direct Push) به شاخه‌های اصلی کد را به عامل‌های AI ندهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو