تصور کنید یک برنامهنویس است از عاملهای هوش مصنوعی برای مدیریت فایلهای سیستم استفاده میکند، اما مدل بهجای شناسایی درست یک پوشه، آن را با یک فایل متن اشتباه میگیرد. این اتفاق به دلیل ماهیت «خواندنی برای انسان» در خط فرمان رخ میدهد؛ جایی که مدل باید حدس بزند هر ستون از خروجی چه معنایی دارد.
بر اساس مستندات پروژه aict، وقتی یک عامل دستوری مثل ls را اجرا میکند، با متنی مواجه میشود که موقعیت فیلدها در آن مشخص نیست. برای مثال، خروجی استاندارد ls مدل را در این مورد به شک در میاندازد که کدام ستون نشاندهنده اندازه فایل است یا آیا سطری که با drwxr-xr-x شروع میشود واقعاً یک دایرکتوری است یا خیر. این فرآیند شکننده باعث هدررفت توکن (Token) — تکههای کوچکی از متن، شبیه برشهای یک کیک طولانی که مدل تکهتکه میخورد — و در نهایت منجر به توهم (Hallucination) میشود؛ یعنی وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد، شبیه دوستی که خاطرهای را اشتباه تعریف میکند.
همانطور که در تحلیل قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، واسطهای غیردقیق میتوانند منجر به رفتارهای پیشبینیناپذیر شوند. ابزارهای سنتی یونیکس برای چشم انسان طراحی شدهاند، نه برای مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد. یک عامل برای بهدست آوردن اطلاعات کامل یک فایل، مجبور است چندین دستور را زنجیرهوار اجرا کند؛ ابتدا ls برای دیدن فایل، سپس file برای بررسی زبان و در نهایت stat برای تاریخ تغییر. هر یک از این مراحل، تأخیر را افزایش داده و پنجره متنی (Context Window) — میزان متنی که مدل همزمان در ذهن نگه میدارد، شبیه میز کاری که جا برای چند ورق دارد — را اشغال میکند.
aict با بازپیادهسازی ۳۳ ابزار ضروری یونیکس، این مشکل را حل کرده است. بهجای رشتههای متنی، این ابزار خروجیهای ساختاریافته XML (پیشفرض) یا JSON برمیگرداند. در این حالت، هر فیلد صریحاً برچسبگذاری شده، مسیرها همیشه مطلق هستند و برچسبهای زمانی بهصورت اعداد صحیح یونیکس ارائه میشوند تا محاسبات نسبی سادهتر شود. برای نمونه، اجرای aict ls src/ یک المان <file> شامل نام، مسیر مطلق، اندازه، زبان شناساییشده، نوع MIME و وضعیت اجرایی فایل را بازمیگرداند.

قابلیتهای فنی و مجموعه ابزار
طبق اعلام توسعهدهنده، کتابخانه aict ابزارها را در شش دسته اصلی سازماندهی کرده و هر کدام از حالتهای خروجی --xml، --json و --plain پشتیبانی میکنند:
- بررسی فایل: نسخههای بازطراحیشده از
cat،head،tail،file،statوwc. - جستوجو و مقایسه: نسخههای ساختاریافته از
ls،find،grepوdiff. - ابزارهای مسیر:
realpath،basename،dirnameوpwd. - پردازش متن:
sort،uniq،cut،tr،sedوawk. - دادهها و آرشیوها:
jq(با پشتیبانی از پرسوجوهای JSON) وtar. - سیستم و محیط:
env،system،ps،df،duو ابزارهای Checksum مثلmd5sumوsha256sum.
علاوه بر این، دسترسی ساختاریافته به عملیات git (شامل status ،diff و log) فراهم شده و دستوری برای عیبیابی خودکار (doctor) در کنار تکمیل خودکار برای bash، zsh و fish قرار گرفته است.
جزئیات پیادهسازی
برای تضمین امنیت و قابلیت انتقال، کل این مجموعه با استفاده از کتابخانه استاندارد Go ساخته شده است. این تصمیم به عنوان یک محدودیت سخت در مستندات پروژه ذکر شده است.
- امنیت: ابزار کاملاً Read-only است؛ هیچ درخواست شبکهای، تلهمتری یا جمعآوری دادهای ندارد. شناسایی MIME-type بهجای استفاده از HTTP، از طریق کتابخانه استاندارد Go انجام میشود.
- وابستگیها: تنها وابستگی این پروژه، SDK رسمی پروتکل زمینهٔ مدل (MCP) است که منحصراً توسط زیردستور
aict mcpاستفاده میشود. - پشتیبانی از پلتفرمها: اکثر ابزارها در ویندوز کار میکنند، اما ابزار
systemبرای لینوکس/مک وpsفقط برای لینوکس (به دلیل خواندن/proc) است. در پلتفرمهای پشتیبانینشده، بهجای کرش کردن، یک المان<error>ساختاریافته بازگردانده میشود.
ادغام از طریق MCP
یکی از کلیدیترین ویژگیهای aict، پشتیبانی بومی از پروتکل زمینهٔ مدل (MCP) است. با اجرای زیردستور aict mcp ،تمام ۳۳ ابزار بهصورت توابع قابل فراخوانی از طریق stdio در دسترس قرار میگیرند. این یعنی دستیارهای هوش مصنوعی مثل Claude Code یا Claude Desktop میتوانند این ابزارها را بهعنوان توابع بومی با آرگومانهای تایپشده و نتایج JSON دریافت کنند.
پیکربندی این سیستم ساده است؛ کاربران Claude Desktop باید دستور را به فایل claude_desktop_config.json و کاربران Claude Code آن را به ~/.claude.json اضافه کنند.
موازنه بین توکن و عملکرد
بر اساس بنچمارکهای اندازهگیری شده با tiktoken o200k_base ،خروجی aict پرحجمتر از خروجیهای GNU است و مصرف توکن را بین ۱.۱ تا ۷.۸ برابر افزایش میدهد. جزئیات این افزایش عبارتند از:
- لیست دایرکتوریها: ۲۴۶ $\rightarrow$ ۸۲۰ توکن (۳.۳ برابر)
- خواندن فایل + تعداد خط + نوع: ۱۷۳ $\rightarrow$ ۲۷۴ توکن (۱.۶ برابر)
- یافتن فایلهای .go: ۴۷ $\rightarrow$ ۳۶۷ توکن (۷.۸ برابر)
- Grep با کانتکست: ۱۴۱ $\rightarrow$ ۳۲۶ توکن (۲.۳ برابر)
- Diff با انواع تغییرات: ۱۶۷ $\rightarrow$ ۱۹۲ توکن (۱.۲ برابر)
با این حال، این هزینه بابت دقت پرداخت میشود. در حالی که یک عامل مبتنی بر GNU ممکن است برای جمعآوری دادهها چهار بار درخواست بفرستد، aict همه را در یک درخواست ارائه میدهد. در ارزیابیهای عملی (opencode)، عاملهای مجهز به aict بهطور کلی ۴۶٪ توکن خروجی کمتری تولید کردند (میانگین ۲۶۵ در برابر ۴۸۷) و به نرخ موفقیت ۱۰۰٪ رسیدند. در مقابل، عامل GNU در یک مورد شکست خورد زیرا ابزار file(1) یک فایل Go را بهاشتباه «کد C» شناسایی کرد.
بنچمارکها و سرعت اجرا
این ابزار غنای معنایی را به قیمت سرعت اجرای خام توسعه داده است. هزینه راهاندازی پایه برای هر فراخوانی حدود ۳.۶ میلیثانیه است.
ls(۱۰۰۰ فایل): GNU حدود ۴ میلیثانیه وaict --xmlحدود ۷۰ میلیثانیه زمان میبرد (۱۷.۷ برابر)، که دلیلش شناسایی نوع MIME برای هر فایل است.cat(۱۰۰ هزار خط): GNU حدود ۱.۴ میلیثانیه وaict --xmlحدود ۳۱ میلیثانیه زمان میبرد (۲۱.۶ برابر).grep(۱۰۰ هزار خط): GNU حدود ۱.۳ میلیثانیه وaict --xmlحدود ۱۳۰ میلیثانیه زمان میبرد (۹۶ برابر).find(درخت عمیق): GNU حدود ۱.۹ میلیثانیه وaict --xmlحدود ۱۵ میلیثانیه زمان میبرد (۸ برابر).
برای جستوجوهای سنگین، همچنان ripgrep سریعترین گزینه است، اما aict بهعنوان یک تأمینکننده زمینه (Context Provider) طراحی شده است. کاربران میتوانند با پرچم --plain غنیسازی را حذف کرده و تأخیر را کاهش دهند. انتخاب XML بهعنوان پیشفرض به دلیل تراکم بیشتر است؛ اتریبیوتهای XML (مثل <file size="1024"/>) کوتاهتر از جفتهای کلید-مقدار در JSON هستند.
این تغییر از «استخراج متن» به «مصرف داده»، نشاندهنده گذاری در نحوه ساخت رابط بین سیستمعامل و مدلهای زبانی است. توسعهدهندگان میتوانند این ابزار را از طریق Homebrew یا Go نصب کنند.
گام بعدی شما
- اگر از Claude Code استفاده میکنید،
aictرا نصب کرده و در فایل تنظیمات ادغام کنید تا نرخ خطای عامل در مدیریت فایلها را تست کنید. - برای کارهای حساس به سرعت، از پرچم
--plainاستفاده کنید تا تأخیر شناسایی MIME را حذف کنید. - ساختار XML این ابزار را با مدلهای مختلف مقایسه کنید تا ببینید کدام یک در استخراج دادههای ساختاریافته دقیقتر عمل میکند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.




گفتگو