تصور کنید می‌خواهید یک دستیار هوش مصنوعی عمومی را به یک متخصص سخت‌گیر در مهندسی انتشار (Release Engineering) تبدیل کنید، اما نمی‌خواهید حتی یک خط کد بنویسید. حالا با نسخه ۰.۵.۰ ابزار CodeSmith (کامیت 3a74c82f)، این تغییر تنها با ویرایش یک فایل TOML و دو سند Markdown امکان‌پذیر است. این ابزار با جداسازی «مغز» (پرامپت) از «عضلات» (موتور اجرا)، اجازه می‌دهد توسعه‌دهندگان بدون یادگیری زبان‌های پیچیده، عامل‌های خود را بازطراحی کنند.
اکثر عامل‌های هوش مصنوعی فعلی، کاربر را در وضعیتی قرار می‌دهند که باید بین سهولت در استفاده و کنترل عمیق، یکی را انتخاب کند. شما یا باید از رابط‌های خشک و محدود شرکت‌های ارائه‌دهنده استفاده کنید یا کدهای پیچیده بک‌اند بنویسید تا فراخوانی ابزارها (Tool Calls) و پرامپت‌های سیستمی را مدیریت کنید. CodeSmith این الگو را می‌شکند و به جای اینکه عامل را به عنوان یک اپلیکیشن سخت‌کد شده (Hard-coded) ببیند، آن را به عنوان مجموعه‌ای ماژولار از فایل‌های تنظیمات در نظر می‌گیرد.
معماری پرامپت سه لایه
در CodeSmith، پرامپت سیستمی یک بلوک متنی ایزوله و ساده نیست. در واقع، این پرامپت اولین مورد از پنج لایه‌ای است که به صورت دترمینستیک (قطعی) اسمبل می‌شوند (که در مسیر crates/agent-runtime/src/prompts.rs:873-887 قابل مشاهده است). ترتیب اسمبل شدن این لایه‌ها ثابت است و هر لایه مسئولیت واحدی را بر عهده دارد:
۱. تاکسونومی ابزارها (Tool Taxonomy): تعریف پایه از ابزارهای در دسترس برای مدل.
۲. قانون اساسی (The Constitution): قوانین حاکم اصلی که در یک سند ۲۹۷ خطی تدوین شده است.
۳. شخصیت (Personality): حالت خاص تعامل (که در آن متغیر {model_id} پیش از ارسال جایگزین شده است).
۴. تغییرات حالت (Mode Delta): جزئیات مربوط به حالت‌های Plan، Agent یا YOLO.
۵. سیاست تأیید (Approval Policy): سیاست‌های مربوط به تأیید اجرای دستورات بر اساس هر حالت.
کاربران می‌توانند طبق تعاریف موجود در config.example.toml:125-158 در سه سطح مختلف روی این رفتار اثر بگذارند:
- سطح اول (لحن - Tone): این سطح شخصیت مدل را تغییر می‌دهد (مثلاً
personality = "calm"یا"playful"). در جدول سلسله‌مراتب قانون اساسی، این مورد در سطح ۸ قرار دارد که به معنای «فقط ارائه» (Presentation Only) است. این لایه بر ریتم صحبت و جملات آغازین اثر می‌گذارد اما هرگز نمی‌تواند به «آنچه باید انجام شود» دست بزند. در مستندات این پروژه، دادن شخصیت جدید به مدل را به این مثال تشبیه کرده‌اند: شبیه به این است که به یک وکیل کراوات جدیدی بدهید؛ کراوات او تغییر می‌کند اما صلاحیت او برای حضور در دادگاه هیچ تغییری نمی‌کند. - سطح دوم (قوانین - Rules): در این سطح، قوانین خاص پروژه از طریق فایل‌های
.mdو با استفاده ازinstructionsوappend_system_promptاضافه می‌شوند. دستورالعمل‌ها (که در سطح ۵ سلسله‌مراتب یا «قانون محلی» قرار دارند) اسناد را به ترتیب اعلام شده در پرامپت تزریق می‌کنند. قوانین پروژه رتبه بالاتری نسبت به حافظه‌ها (Memories) دارند اما رتبه‌شان از قوانین حالت (Mode Rules) پایین‌تر است. توصیه رسمی در تنظیمات نمونه این است که «ترجیحاً از ترکیب instructions + append_system_prompt استفاده کنید». همچنین تنظیمات در سطح پروژه، این موارد را به طور کامل جایگزین می‌کنند تا محیط‌های خانه و کار با یکدیگر تداخل پیدا نکنند. این رویکرد در واقع پاسخی به چالش‌های مدیریت پرامپت در محیط‌های عملیاتی است، چرا که جدا نکردن پرامپت‌ها از سیستم کنترل نسخه (Git) می‌تواند به مرور زمان به یک بدهی فنی تبدیل شود. - سطح سوم (جایگزینی کامل - Full Override): این مورد «گزینه هسته‌ای» است که از طریق
system_promptیاsystem_prompt_fileاعمال می‌شود. در این حالت، قانون اساسی، تاکسونومی ابزارها و لایه‌های حالت به طور کامل دور ریخته می‌شوند. مستندات رسمی هشدار می‌دهند که این گزینه «تنها زمانی استفاده شود که واقعاً به آن نیاز دارید»، زیرا این درگاه ورود برای ساخت گونه‌ای کاملاً جدید از عامل‌های هوش مصنوعی است.
برای تأیید این تغییرات، دستور /system (که در crates/tui/src/commands/mod.rs:420 با نام مستعار /xitong تعریف شده) به کاربران اجازه می‌دهد پرامپت نهایی اسمبل‌شده را به طور کامل مشاهده کنند. این شفافیت تضمین می‌کند که کاربر دقیقاً بداند هر سفارشی در کدام لایه قرار گرفته و چگونه رندر شده است. این تجربه دیباگینگ، یک تمایز کلیدی با محصولات شرکت‌های بزرگ است که معمولاً درباره پرامپت نهایی صادق نیستند.
سفیدلیست دستورات با هدایت دقیق
امنیت در CodeSmith توسط پرامپت مدیریت نمی‌شود، بلکه توسط یک هارنس اجرای سخت‌کد شده (Hard-coded Execution Harness) کنترل می‌شود. جایگزین کردن پرامپت سیستمی نمی‌تواند گیت‌های تأیید یا محیط سندباکس را حتی یک حرف جابجا کند. سیستم از یک «دیکشنری تعداد آرگومان‌های بش» (crates/execpolicy/src/bash_arity.rs) استفاده می‌کند تا از نشت‌های امنیتی رایج که با تطبیق ساده پیشوندها (Prefix Matching) رخ می‌دهد، جلوگیری کند. این لایه امنیتی در کنار استفاده از میکرو-ماشین‌های مجازی برای ایزوله‌سازی وضعیت عامل‌ها، محیطی را فراهم می‌کند که در آن اجرای کد توسط هوش مصنوعی ریسک سیستمیک نداشته باشد.
تطبیق ساده در هر دو انتها شکست می‌خورد: برابری کامل رشته (Whole-string equality) باعث مسدود شدن فلگ‌های بی‌ضرر می‌شود (مثل git status --porcelain)، در حالی که تطبیق پیشوند اجازه می‌دهد دستورات خطرناک «سوار» شوند (مثلاً git stash ممکن است از فیلتر پیشوند git sta عبور کند). این موضوع به‌ویژه در مورد npm run خطرناک است، زیرا اگر از تطبیق پیشوند خالص استفاده شود، هر اسکریپتی می‌تواند بدون بررسی عبور کند.
CodeSmith «پیشوند دستور» را به عنوان تعداد ثابتی از آرگومان‌های موقعیتی تعریف می‌کند، به طوری که فلگ‌ها (توکن‌هایی که با - شروع می‌شوند) هرگز در شمارش تعداد آرگومان‌ها (Arity) حساب نمی‌شوند. جدول استاتیک سیستم شامل ورودی‌هایی برای بیش از ۳۰ ابزار رایج است (bash_arity.rs:36-43):
git status(تعداد ۲): دستوراتgit status -sوgit status --porcelainرا تطبیق می‌دهد اماgit pushرا مسدود می‌کند.npm run(تعداد ۳): کلمه سوم اسکریپت متغیر است، اما پیشوند ثابت می‌ماند.make(تعداد ۱): خود دستور به تنهایی کل پیشوند را تشکیل می‌دهد.
لایه گذاری قوانین از اولویت BuiltinDefault < Agent < User پیروی می‌کند و در سطوح اولویت برابر، طولانی‌ترین پیشوند برنده است. این فلسفه حاکمیتی تضمین می‌کند که پیش‌فرض‌های محتاطانه داخلی توسط طرف‌هایی که اطلاعات بیشتری دارند (کاربر یا عامل)، بازنویسی شوند.
تزریق قابلیت‌ها از طریق مهارت‌ها و قلاب‌ها
CodeSmith برای قابلیت‌ها از فلسفه «حافظه مجازی» استفاده می‌کند. به جای پر کردن بیش از حد پنجره متنی (Context Window)، از یک کاتالوگ مهارت‌ها استفاده می‌کند که مجموعاً به ۱۲,۰۰۰ کاراکتر محدود شده است.
مهارت‌ها (Skills) به صورت فایل‌های Markdown مجزا در دایرکتوری‌هایی مانند .claude/skills یا .cursor/skills ذخیره می‌شوند. هر مهارت شامل یک بخش YAML (شامل نام، توضیحات، when_to_use یا «چه زمانی استفاده شود»، allowed-tools یا «ابزارهای مجاز» و model) و یک بدنه به زبان طبیعی است. وقتی مدل با وظیفه‌ای مطابقت پیدا می‌کند، دستور load_skill را برای فراخوانی متن کامل مهارت اجرا می‌کند. مهارت‌های جامعه (Community Skills) را می‌توان با یک دستور ساده نصب کرد: /skill install github:owner/repo.
قابلیت‌ها در این سیستم در یک طیف قرار دارند:
- ابزارهای اختصاصی (Dedicated Tools): فراخوانی‌های تابعی ساختاریافته با پارامترهای محدود شده توسط اسکیما. این‌ها دترمینستیک و امن هستند اما هر کدام چندین صد توکن هزینه دارند.
- مهارت‌ها (Skills): دستورالعمل‌های عملیاتی به زبان طبیعی. این‌ها ارزان‌تر هستند (فقط چند ده توکن برای ورودی کاتالوگ) و ویرایش آن‌ها برای انسان راحت‌تر است. برای مثال، «استقرار اپلیکیشن» می‌تواند یک مهارت باشد که توالی
npm run build$ \rightarrow $docker build$ \rightarrow $kubectl applyرا می‌خواند، به جای اینکه یک ابزار اختصاصی پیچیده باشد. - مجریان همه‌منظوره (General-Purpose Executors): یک مفسر کد که می‌تواند جایگزین ده‌ها ابزار اختصاصی شود. این کار مصرف توکن را تقریباً دو مرتبه کاهش می‌دهد، زیرا اجازه می‌دهد کد، فراخوانی ابزارها را سازماندهی کند و متغیرهای میانی را در محیط اجرا نگه دارد.
توسعه‌دهندگان تنها در چهار مورد باید به سراغ ابزارهای اختصاصی بروند:
۱. امنیت و حسابرسی: نوشتن در دیتابیس تولید (Production) نیاز به سطح دسترسی دقیقی دارد که فقط ابزار اختصاصی فراهم می‌کند.
۲. پوشاندن تفاوت‌های پلتفرم: ابزارهایی مثل grep یا find اختصاصی شده‌اند تا بازخوردهای شماره خط و آرگومان‌ها در پلتفرم‌های مختلف یکسان باشد.
۳. عملیات با فرکانس بالا: این عملیات‌ها برای بهره‌وری بیشتر به یک نقطه ورود اختصاصی نیاز دارند.
۴. پارامترهای پیچیده: یک اسکیمای JSON برای جلوگیری از خطاهای Escaping، قابل‌اعتمادتر از زبان طبیعی است.
قلاب‌ها (Hooks) اجازه بازنویسی عمیق رفتار را در ۱۴ رویداد چرخه حیات می‌دهند. مثال‌هایی از این قلاب‌ها:
shell_env: به صورت سنکرون قبل از هرexec_shellاجرا می‌شود. یک دستور مثلaws-vault export my-profile --format=envتضمین می‌کند که اعتبارنامه‌های موقت در محیط زیرپردازش ادغام شوند، بنابراین رمزهای طولانی‌مدت هرگز در فایل‌های تنظیمات ظاهر نمی‌شوند.pre_compact: قبل از فشرده‌سازی متن (Context Compaction) اجرا می‌شود تا محتویات فایلDECISIONS.mdرا در خلاصه نهایی تزریق کند و تضمین نماید که تصمیمات کلیدی پس از دستور/compactاز بین نروند.
جایگزینی ابزارها و ارکستراسیون
کاربران می‌توانند از طریق بخش [tools.overrides] در تنظیمات (config.example.toml:1028-1039) عملیات «قطع و جایگزینی» را روی ابزارهای داخلی انجام دهند. یک ابزار داخلی را می‌توان با یک اسکریپت شل جایگزین کرد، به شرطی که پروتکل را رعایت کند: دریافت JSON از stdin و خروجی {"content": ..., "success": ...} در stdout.
مثال‌هایی از این جایگزینی‌ها:
- جایگزینی
exec_shellبا یک Wrapper برای ثبت لاگ‌های حسابرسی در مسیر~/.codesmith/audit/exec_shell.log. - جایگزینی
read_fileبا ابزارbatبا استفاده از آرگومان--paging=never. - جایگزینی
fetch_urlبا یک اسکریپتcached-fetch.shکه دارای TTL ۳۰۰ ثانیه‌ای است.
سیستم همچنین از ارکستراسیون تیمی پشتیبانی می‌کند (crates/agent-runtime/src/team/team_file.rs:65-85). کاربران می‌توانند تیمی تشکیل دهند که هر عضو آن پرامپت، مدل و worktree_path مخصوص به خود را داشته باشد. برای یک تیم انتشار، می‌توان از یک Implementer برای افزایش نسخه (Version Bump)، یک Reviewer برای بازبینی فقط-خواندنیِ تغییرات (Changelog) و یک Verifier برای چک‌لیست پیش از انتشار استفاده کرد. کاربران می‌توانند در [subagents.models] تنظیم کنند که از مدل Flash برای شناسایی اولیه و از مدل Pro برای بازبینی نهایی استفاده شود.
تغییر بین محیط‌های مختلف از طریق پروفایل‌ها (config.example.toml:823-835) مدیریت می‌شود. یک پروفایل [profiles.work] ممکن است به گیت‌وی شرکت اشاره کند، در حالی که [profiles.dev] محدودیت‌های allow_shell را کاهش می‌دهد و [profiles.nvidia-nim] ارائه‌دهنده مدل را تغییر می‌دهد. کاربران با دستور codesmith --profile <name> بین این‌ها جابجا می‌شوند.
تحلیل: تغییر حاکمیت
این معماری، پویایی قدرت را از ارائه‌دهنده مدل به کاربر نهایی منتقل می‌کند. با انتقال «هوش» به فایل‌های Markdown و TOML که تحت کنترل ورژن (Version-controlled) هستند، CodeSmith با LLM به عنوان یک کالای جایگزین‌پذیر برخورد می‌کند. موتور سیستم تضمین می‌کند که جریان شواهد توسط پرامپت مدیریت نشود؛ عامل می‌تواند هر شخصیتی داشته باشد، اما همچنان باید از گیت‌های امنیتی برای اجرای یک دستور خطرناک عبور کند.
برای یک توسعه‌دهنده، این یعنی هزینه آزمایش به شدت کاهش می‌یابد. دیگر نیازی نیست برای تست یک شخصیت جدید برای عامل، یک باینری Rust را دوباره کامپایل کنید. برای آن ۱٪ از سناریوهایی که نیاز به تغییرات عمیق‌تر دارند، یک راه خروج (Escape Hatch) از طریق اکستنشن‌های dylib وجود دارد. توسعه‌دهندگان می‌توانند trait مربوط به Extension را پیاده‌سازی کنند، ابزارها را ثبت کنند و از HandlerOutcome::{Continue, Cancel, Block, Transform} برای بازنویسی رفتار در لایه‌های ورودی، درخواست‌ها و فشرده‌سازی استفاده کنند. این اکستنشن‌ها از طریق /extension install git:<repo> به صورت Hot-load نصب می‌شوند.
کاربرد عملی: مهندس انتشار
برای ساخت «متخصص مهندسی انتشار» که در ابتدا ذکر شد، دستورالعمل به شرح زیر است:
۱. تنظیمات: مقدار system_prompt_file = "~/.codesmith/release-engineer.md" (سطح ۳) و auto_allow = ["git status", "git log", "git tag", "cargo check"] را قرار دهید. دقت کنید که cargo release در سفیدلیست قرار نمی‌گیرد تا گیت تأیید انسانی برای انتشار نهایی حفظ شود.
۲. اعتبارنامه‌ها: یک قلاب shell_env اضافه کنید: gh auth token | sed 's/^/GH_TOKEN=/'.
۳. دستورات: فایل .codesmith/commands/release-notes.md را برای تولید یادداشت‌های انتشار با یک کلید بسازید. دستورات اسلش سفارشی را می‌توان در .claude/commands/ قرار داد.
۴. مهارت‌ها: فایل .codesmith/skills/changelog-lint/SKILL.md را با توضیحات «استفاده هنگام ویرایش CHANGELOG.md یا آماده‌سازی انتشار» ایجاد کنید.
گام بعدی
این سیستم تعادلی بین دو وجه ایجاد می‌کند: وجه محدودیت در برابر مدل (دیسیپلین پیشوند در سطح بایت، مدل‌های فرعی پین شده و خروجی‌های متنی محدود) و وجه آزادی در برابر کاربر (پرامپت‌های سه لایه، سفیدلیست‌های دقیق Arity و ابزارهای جایگزین‌پذیر). همان‌طور که در ماده ۳ قانون اساسی آمده است: «کاربر، حاکم این نشست است» (prompts/base.md:23-27).
توسعه‌دهندگانی که قصد پیاده‌سازی این سیستم را دارند، می‌توانند با بررسی گردش‌کارهای فعلی شل خود شروع کنند تا شناسایی کنند کدام دستورات با مدل سفیدلیست مبتنی بر Arity سازگار هستند. منتظر تحلیل عمیق آینده درباره «آناتومی یک عامل» باشید تا پنج موج تکامل عامل‌های هوش مصنوعی را درک کنید.
گفتگو