اگر امروز برای مدیریت دادهها در چندین پلتفرم مختلف از عاملهای هوش مصنوعی استفاده میکنید، احتمالاً با مشکل «تورم توکنها» دستوپنجه نرم کردهاید. گلوگاه اصلی این سیستمها استدلال نیست، بلکه هزینهٔ دانستنِ نحوهٔ استفاده از ابزارهاست.
aclif، یک چارچوب جدید برای رابط خط فرمان (CLI) عاملها، این مشکل را با حذف لیستهای ثابت ابزارها و جایگزینی آنها با یک سیستم کشف پویا (Dynamic Discovery) حل کرده است. در مدلهای فعلی، اکثر عاملها به سرورهای پروتکل زمینهٔ مدل (MCP) متکی هستند که لیستی ثابت از ابزارها را منتشر میکنند. این رویکرد در حالی است که پروتکل MCP به عنوان یک مرز امنیتی جدید شناخته میشود که چالشهای خاصی مانند تزریق پرامپت را در ابزارهای خارجی به همراه دارد. این وضعیت یک موازنهٔ دشوار ایجاد میکند: یا توسعهدهنده تمام عملیات API را منتشر میکند — که در یک API معمولی صدها تعریف وجود دارد و در هر نوبت مقدار زیادی توکن مصرف میکند — یا تنها چند ابزار کلی را ارائه میدهد که باعث میشود بخش بزرگی از قدرت API از دسترس عامل خارج شود. در واقع، نویسندهٔ سرور در زمان ساخت، پوشش عملیاتی را فدای هزینه میکند.
تصور کنید عاملی را در نظر بگیرید که باید دادهها را در Salesforce، ServiceNow و DocuSign مدیریت کند. در حالت عادی، این عامل به سرورهای مجزا، ورودهای متفاوت، دستور زبانهای خاص، فرمتهای خطای متنوع و مجموعهای از نامهای منحصربهفرد برای هر کدام نیاز دارد. این وضعیت باعث اشباع پنجرهٔ زمینه (Context Window) — شبیه میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — شده و احتمال توهم (Hallucination) — وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد — در نحو دستورات را افزایش میدهد.
مکانیسم کشف بر اساس نیاز (On-Demand Discovery)
همانطور که در تحلیلهای پیشین ما دربارهی بهینهسازی مصرف توکنها در مدلهای زبانی اشاره کردیم، کاهش حجم دادههای ورودی مستقیماً بر دقت خروجی اثر میگذارد. aclif با بارگذاری تعاریف دستورات تنها در زمانی که عامل صراحتاً آنها را درخواست میکند، این جریان کاری را تغییر میدهد. به این ترتیب، کل API هر ارائهدهنده بدون هیچ هزینهٔ ثابتی در پنجره متنی در دسترس است. این رویکرد در واقع پاسخی به نیاز تفکیک مهارتهای عامل از سرورهای MCP برای بهینهسازی فضای پنجرهٔ زمینه است.
طبق مستندات aclif.ai، این چارچوب از یک دستور زبان واحد، ساختار دستوری یکپارچه، یک پاکت JSON (JSON envelope) و یک واژگان خطای مشترک برای تمام ارائهدهندگان استفاده میکند. یک عامل تنها یک بار نحوه استفاده از ابزار را میآموزد و افزودن پلتفرمهای جدید، تنها دستورات جدیدی را اضافه میکند، نه دستور زبانهای پیچیده را. حتی یک مانیفست JSON میتواند دستوری را روی یک نقطه انتهایی (Endpoint) HTTP با همان دستور زبان اضافه کند، بدون اینکه نیازی به نوشتن کد باشد.
برای تعامل با یک سیستم، عامل یک توالی «ابتدا بررسی» (Introspection-first) را طی میکند که در آن هیچ درخواستی تا مرحله نهایی به API نمیرسد:
aclif discover --json: لیست تمام ارائهدهندگان، سطح (Tier) آنها و اینکه آیا اعتبارنامهها پیکربندی شدهاند یا خیر را برمیگرداند.aclif learn [provider] --json: خلاصهای شامل موضوعات، فیلدهای کلیدی، نحو پرسوجو و مسیرهای احراز هویت را ارائه میدهد.aclif [provider] data query --schema: پرچمها، آرگومانها و متادیتای ایمنی را بدون اجرای دستور بازمیگرداند.aclif [provider] data query --examples: نمونههای قابل اجرا و پاسخهایی که تولید میکنند را نمایش میدهد.
این بررسیها بسیار بهینه هستند؛ زیرا پرچمهایی مثل --schema، --examples و --shape پیش از اجرای دستور بازگردانده میشوند، نیازی به اعتبارنامه ندارند و از سهمیه API کم نمیکنند. یک عامل میتواند در حالی که هیچ هزینهای نمیکند، در برابر یک نمونه با محدودیت نرخ (Rate-limited)، عملیات کشف، یادگیری و پیشنمایش را انجام دهد.
نامگذاری استاندارد و بازیابی از خطا
یکی از کاربردیترین ویژگیهای این چارچوب، استفاده از نامهای استاندارد (Canonical Names) است. aclif از مجموعهای از نامهای مستعار برای نگاشت اصطلاحات مختلف پلتفرمها به یک مفهوم واحد استفاده میکند. برای مثال، میتواند واژه «مشتری» در یک نمونه از Salesforce را به «Account» و در ServiceNow به «core_company» متصل کند. برای پشتیبانی از این قابلیت، یک کاتالوگ مستاجر (Tenant Catalog) در زمان استقرار از هر نمونه ثبت میشود تا اشیاء و فیلدهای سفارشی هر نمونه بدون تغییر در ارائهدهنده، به CLI آموزش داده شود.
مدیریت خطا نیز از مدل به چارچوب منتقل شده است تا عامل بتواند در یک نوبت خطا را جبران کند. هر خطا، نام شکست، دستوری که آن را اصلاح میکند و — در صورتی که طبقهبندیکنندهٔ ارائهدهنده دارای قانون بازنویسی برای آن اشتباه باشد — ورودی اصلاحشده را برای ارسال مجدد ارائه میدهد. این طبقهبندیکننده، کدهای سادهای است و هیچ مدلی پشت آن نیست. از آنجایی که کلاسهای دستوری یکسانی هم در شل (Shell) زمان طراحی و هم در زمان اجرا تحت هر میزبان اجرا میشوند، دستوری که در شل اعتبارسنجی شده است، در زمان اجرا همان خطا را برمیگرداند.
سه معماری استقرار
aclif برای اجرا در سه محیط مختلف طراحی شده است تا نیازهای امنیتی سازمانها را پوشش دهد. برخلاف CLIهای سازندگانی که برای یک استقرار ساخته شدهاند (نصب روی ماشین و ورود توسط شخص)، کلاسهای دستوری aclif بدون تغییر در سه مکان اجرا میشوند:
۱. اجرای توسط عامل (Agent-Run): فرآیند عامل مستقیماً فایل باینری را اجرا کرده، دستور را اجرا میکند و خروجی JSON را میخواند. اعتبارنامهها از طریق پرچمها، متغیرهای محیطی یا یک پروفایل در محیط خود عامل تأمین میشوند. این حالت برای محیطهای تککاربره که یک عامل، یک اپراتور و یک مجموعه اعتبارنامه در یک مرز اعتماد مشترک هستند، ایدهآل است.
۲. برنامه میزبان (Host-Application): یک برنامه میانافزار بین مدل و CLI قرار میگیرد و اعتبارنامهها را نگه میدارد. مدل ابزاری را فراخوانی میکند که برنامه تعریف کرده است و برنامه دستور را در داخل فرآیند یا با ارسال رشته دستور به CLI اجرا میکند. این مورد اصلی برای اعتبارسنجی جریانهای کاری در زمان طراحی است؛ این ساختار تضمین میکند که مدل هرگز اعتبارنامهها را در اختیار ندارد و تعاریف ابزارها از پنجره متنی آن خارج میمانند.
۳. اجرای در درگاه (Gateway-Run): یک فرآیند دائمی برای چندین عامل سرویسدهی میکند. درگاه، اعتبارنامهها را برای هر درخواست از یک خزانه سازمانی (Enterprise Vault) دریافت کرده، سیاستها را بر اساس کاربر فعال بررسی میکند، هر فراخوانی را ثبت میکند و اتصالات را گرم (Warm) نگه میدارد. عاملها هیچ اعتبارنامهای از ارائهدهنده ندارند و نمیتوانند محدوده دسترسی خود را گسترش دهند.
مقایسه محیطهای زمان اجرا (Runtime)
- اعتبارنامهها: در حالت Agent-run از پرچمها/env/config.yaml استفاده میشود؛ در Host-run از یک حلکننده (Resolver) ارائهشده توسط میزبان؛ و در Gateway-run از یک حلکننده متکی به خزانه برای هر درخواست.
- سیاستها: حالت Agent-run به
config.yamlمتکی است؛ Host-run از یک قلابcapabilityGateاستفاده میکند؛ و Gateway-run از ترکیبcapabilityGateو میانافزار میزبان بهره میبرد. - هویت: در Agent-run از توکنهای شناسایی یا env استفاده میشود؛ در Host-run از کاربر فعال در زمان فراخوانی؛ و در Gateway-run از کاربر فعال و ادعاهای SSO (SSO claims) موجود در درخواست.
- حسابرسی (Audit): حالت Agent-run برای هر اجرا یک خط در stderr مینویسد؛ حالتهای Host و Gateway از رویدادهای گزارشدهنده (Reporter events) استفاده میکنند که توسط میزبان ثبت میشود.
- اتصالات: حالت Agent-run از یک حافظه پنهان نشست (Session cache) فایلی استفاده میکند؛ حالتهای Host و Gateway از یک استخر زمان اجرا (Runtime pool) استفاده میکنند که برای درگاهها بر اساس نمونه و هویت کلیدگذاری شده است.
ایمنی و حاکمیت
امنیت در متادیتای دستورات نهفته است. ویژگیهایی مثل قابلیت تغییر (Mutability)، شعاع اثر (Blast Radius)، بازگشتپذیری (Reversibility) و یکتا-بودن (Idempotency) برای هر دستور تعریف شده است. این ساختار اجازه میدهد یک بررسی سیاستی، تغییرات پرریسک را پیش از بارگذاری کد متوقف کند.
تمام دستورات تغییردهنده از پرچم --dry-run پشتیبانی میکنند. این امر به عاملها اجازه میدهد پیش از تغییر واقعی دادهها، اثر تغییر را پیشبینی کنند. علاوه بر این، چارچوب برای عملیاتی که متادیتای آنها ضرورت آن را نشان میدهد، پرچم --confirm را الزامی میکند. هر اجرا با نوشتن یک خط حسابرسی به پایان میرسد.
پشتیبانی بومی از ارائهدهندگان و توسعه
در حال حاضر، aclif به صورت بومی از Salesforce، ServiceNow، DocuSign و Agentforce پشتیبانی میکند و Google Workspace (Gmail و Calendar) نیز به عنوان یک ارائهدهنده مشارکتشده در دسترس است. این چارچوب همچنین از یک سطح خصوصی (Private tier) برای ارائهدهندگانی پشتیبانی میکند که یک فورک (Fork) آنها را در مسیری نگه میدارد که هرگز به مخزن اصلی ارسال نمیشود.
نوشتن ارائهدهندههای جدید به گونهای طراحی شده که تلاشی اندک باشد. این کار در واقع ترجمه مستقیم مشخصات API پلتفرم به سطح دستورات است. یک عامل کدنویس میتواند این کار را با استفاده از یک پرامپت نمونه در مخزن انجام دهد و یک مجموعه تطبیق (Conformance suite) نتیجه را بررسی میکند.
برای توسعهدهندگان، فایل باینری انعطافپذیر است. یک دستور scaffold، یک CLI با نام اختصاصی، دایرکتوری پیکربندی، متغیرهای محیطی و مجموعهای از ارائهدهندگان منتخب تولید میکند. این باینری به Node 22 یا نسخههای جدیدتر نیاز دارد و تحت لایسنس MIT است.
این تغییر معماری به این معناست که اندازه پنجره متنی عامل، چه با یک پلتفرم تعامل داشته باشد و چه با پنج پلتفرم، ثابت میماند. با انتقال «دانش» API از پرامپت به یک CLI قابل کشف، aclif توانمندی عامل را از محدودیتهای پنجره متنی جدا میکند. این رویکرد در راستای نقشه راه تبدیل چتباتها به عاملهای صنعتی است که بر ساختارهای مقیاسپذیر تأکید دارد. حتی بلوک _context در پاکت JSON خروجی، اطلاعات صفحهبندی (Pagination) را به همراه دستور دقیق بعدی، فیلدهای موجود و دستورات مرتبطی که ارزش اجرا دارند، نگه میدارد. کدهای خروج نیز استاندارد شدهاند: 0 برای موفقیت، 1 برای خطای API، 2 برای خطای نحوه استفاده (Usage) و 3 برای خطای احراز هویت.
گام بعدی شما
- اگر از MCP برای اتصال عاملهای خود به APIهای حجیم استفاده میکنید، ساختار کشف پویا (Discovery) را برای کاهش هزینه توکنها بررسی کنید.
- برای محیطهای سازمانی، مدل استقرار Gateway-Run را برای جداسازی کامل اعتبارنامهها از مدل زبانی پیادهسازی کنید.
- از پرچم
--dry-runدر دستورات تغییردهنده استفاده کنید تا از خطاهای جبرانناپذیر در دادههای عملیاتی جلوگیری شود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو