تصور کنید تمام هوش عملیاتی شرکتتان در اختیار شرکتی باشد که هر لحظه می‌تواند قیمت‌ها را تغییر دهد یا دسترسی شما را قطع کند؛ در واقع شما در حال اجاره کردن هوش خود هستید. ریسک تکیه بر پلتفرم‌های بسته برای عامل‌های هوش مصنوعی دقیقاً همین است. Kortix با معرفی یک سامانه مدیریت هوش مصنوعی (AI Management System)، این معادله را تغییر می‌دهد و کل پشتهٔ عامل‌ها — شامل تعاریف، حافظه و رابط‌های اتصال — را به یک مخزن git واحد منتقل می‌کند که مالکیت آن کاملاً در دست کاربر است. این لایه نرم‌افزاری به شرکت‌ها اجازه می‌دهد تا عامل‌های هوش مصنوعی خود را اجرا کنند و مالکیت مطلق آن‌ها را در اختیار داشته باشند.
بسیاری از تیم‌ها امروز بین دو راه سخت گیر کرده‌اند: یا از فریم‌ورک‌های توسعه استفاده کنند که نیاز به مهندسی سنگین و کدنویسی گسترده دارد، یا پلتفرم‌های بصری (Visual Application Platforms) که داده‌ها را در ابرِ تامین‌کننده حبس می‌کنند. این وضعیت یک آسیب‌پذیری حیاتی ایجاد می‌کند؛ اگر تامین‌کننده قیمت‌گذاری خود را تغییر دهد یا APIهای خود را تغییر دهد، شرکت سیستم تولید خروجی‌های عملیاتی خود را از دست می‌دهد. پلتفرمی که عامل‌ها را اجرا می‌کند، در واقع زمینه (Context) پیرامون آن‌ها را نیز جمع‌آوری می‌کند؛ این بدان معناست که انتخاب پلتفرم، چیزی فراتر از انتخاب یک محیط اجرا (Runtime) برای این فصل است و در واقع تصمیم درباره نحوه ذخیره دانش سازمانی است. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل روی زیرساخت تنها راه تضمین تداوم کسب‌وکار است. یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در این سیستم دیگر یک جعبه سیاه اجاره‌ای نیست، بلکه بخشی از دارایی شرکت است.
سه شکل مختلف پلتفرم
برای درک جایگاه Kortix، باید سه محصولی که همگی به اشتباه «پلتفرم» نامیده می‌شوند را از هم تفکیک کنیم:
- فریم‌ورک توسعه (Developer Framework): یک کتابخانه زمان اجرا (Runtime Library) است که مهندس آن را وارد یک اپلیکیشن می‌کند. این گزینه برای تیم‌های مهندسی که در حال ساخت رفتارهای سفارشی برای عامل‌ها هستند و خروجی نهایی آن‌ها یک اپلیکیشن واحد است، بهترین انتخاب است.
- پلتفرم اپلیکیشن (Application Platform): یک سازنده بصری برای گردش‌کارها (Workflows) و خط لوله‌های بازیابی داده (Retrieval Pipelines) است. این ابزار معمولاً توسط تیم‌های محصول یا عملیات برای عرضه یک گردش‌کار واحد استفاده می‌شود.
- سامانه مدیریت هوش مصنوعی (AI Management System): سیستمی است که شرکت آن را اداره می‌کند و در آن عامل‌ها، مهارت‌ها، حافظه، رابط‌های اتصال (Connectors)، تریگرها و مجوزها، همگی به صورت پیکربندی‌هایی (Configuration) هستند که شرکت مالک آن‌هاست. این سیستم برای شرکت‌هایی طراحی شده است که اجرای عامل‌ها را به عنوان بخش اصلی عملیات خود می‌بینند.
Kortix در دسته سوم قرار می‌گیرد. در حالی که فریم‌ورک‌ها و پلتفرم‌های اپلیکیشن تنها ابزارهای اولیه (Primitives) را فراهم می‌کنند و مسیر بررسی و زمینه شرکت را به عهده کاربر می‌گذارند، یک سامانه مدیریت هوش مصنوعی وظیفه گسترده‌تری را بر عهده می‌گیرد: این سیستم عامل‌ها را اجرا می‌کند، زمینه مشترک را نگه می‌دارد، به ابزارهای موجود متصل می‌شود و یک انسان را به عنوان دروازه‌بان در مسیر قرار می‌دهد.
چهار ستون مالکیت واقعی
طبق مستندات Kortix، برای اینکه بفهمیم یک پلتفرم واقعاً باز است یا فقط برچسب «باز» خورده، باید چهار آزمون مشخص را پاس کند. پلتفرمی که پاسخ هر چهار مورد را به نفع شرکت دهد، پلتفرمی است که شما مالک آن هستید؛ در غیر این صورت، شما در حال اجاره هستید.
- محل پیکربندی (Configuration Location): از تامین‌کننده بخواهید فایل‌ها را به شما نشان دهد. در Kortix، عامل‌ها به صورت فایل‌های markdown تعریف می‌شوند و حافظه به صورت پوشه‌ای از فایل‌های متنی ساده (Plain Files) وجود دارد. تمام پیکربندی‌های رابط اتصال، تریگرها و تصاویر ماشین (Machine Images) در یک فایل
kortix.yamlدر داخل یک مخزن git تعریف شده‌اند. این ساختار به تیم‌ها اجازه می‌دهد تا کل منطق هوش مصنوعی شرکت را grep کنند، هر تغییری را diff کنند و نسخه‌ها را از طریق git بازگردانند. در پلتفرم‌های بسته، این پیکربندی‌ها داخل محصول تامین‌کننده زندگی می‌کنند؛ یعنی شما می‌توانید خروجی را صادر کنید، اما سیستمی که آن خروجی را تولید کرده است، در اختیار شما نیست. - کنترل مدل و کلیدها (Model and Key Control): انتخاب مدل در Kortix صرفاً یک پیکربندی است که وقتی مدل بهتری عرضه شد، آن را تغییر می‌دهید. این پلتفرم از طیف وسیعی از مدل‌ها پشتیبانی می‌کند، از جمله Anthropic، OpenAI، Google، Groq، xAI، DeepSeek، Mistral، Bedrock و OpenRouter، و همچنین هر نقطه انتهایی (Endpoint) که با OpenAI سازگار باشد. مدل‌ها را می‌توان برای هر عامل، هر جلسه (Session) یا حتی هر پیام به صورت مجزا تغییر داد. کاربران کلیدهای API خود را می‌آورند یا از اشتراک موجود ChatGPT استفاده می‌کنند. در مقابل، جایگزین‌های بسته، مدل را به تامین‌کننده گره می‌زنند — مثلاً Claude Cowork فقط مدل‌های Claude یا ChatGPT Work فقط مدل‌های OpenAI را اجرا می‌کنند — و اگر بخواهید مدل را عوض کنید، مجبور به بازنویسی کامل عامل‌ها هستید.
- جداسازی محیط اجرا (Runtime Isolation): عاملی که فایل‌ها را ویرایش می‌کند و APIها را فراخوانی می‌کند، به یک کامپیوتر نیاز دارد. هر جلسه در Kortix روی ماشین لینوکس ایزوله خود در یک شاخه (Branch) اختصاصی اجرا می‌شود. یک تیم می‌تواند هزاران مورد از این‌ها را به صورت موازی روی یک پیکربندی واحد اجرا کند. عامل می‌تواند بسته‌ها را نصب کند، کد اجرا کند و در داخل آن ماشین همه چیز را خراب کند، اما فقط کارهای Commit شده باقی می‌مانند. اجرای عامل‌ها روی یک سرور مشترک یا لپ‌تاپ توسعه‌دهنده، این مرز را از بین می‌برد و اجازه می‌دهد یک اجرای بد، به هر چیزی که میزبان به آن دسترسی دارد، آسیب بزند.
- دروازه نظارت انسانی (Human-in-the-Loop Gating): کارهای تکمیل شده در Kortix به صورت یک درخواست تغییر (Change Request) روی شاخه پیش‌فرض می‌نشیند که انسان آن را به صورت یک diff می‌خواند. در Kortix، ادغام (Merge) به صورت پیش‌فرض برای عامل‌ها ممنوع (Deny-by-default) است. مجوز برای هر فراخوانی ابزار می‌تواند روی حالت «اجازه» (Allow)، «پرسش» (Ask) یا «مسدود» (Block) تنظیم شود، حتی تا سطح یک دستور shell واحد. پلتفرمی که این دروازه را ندارد، از شما می‌خواهد به خروجی عامل اعتماد کنید؛ اما یک درخواست تغییر، این اعتماد را به یک تصمیم تبدیل می‌کند.
جزئیات معماری و یکپارچه‌سازی
Kortix به عنوان یک سامانه مدیریت، کل شرکت را در یک مخزن git نگه می‌دارد و بخش‌هایی را که اکثر پلتفرم‌ها پشت API پنهان می‌کنند، به صورت شفاف نمایش می‌دهد.
اجزای اصلی در مخزن:
- عامل‌ها (Agents): تعریف شده در فایل‌های markdown.
- مهارت‌ها (Skills): دانش‌های قابل استفاده مجدد که یک بار نوشته شده و بین تمام جلسات به اشتراک گذاشته می‌شوند.
- حافظه (Memory): فایل‌های ساده‌ای که آنچه شرکت می‌آموزد را جمع‌آوری می‌کنند.
- پیکربندی (Configuration): فایل
kortix.yamlکه اتصال‌ها، تریگرها و تصویر ماشین را مدیریت می‌کند. این باعث می‌شود تغییر مدل به یک diff تک‌خطی و ایجاد یک شغل زمان‌بندی شده جدید به یک commit بررسی شده تبدیل شود.
اتصال و امنیت:
لایه رابط اتصال (Connector Layer) بسیار گسترده است و به بیش از ۳۰۰۰ اپلیکیشن دسترسی دارد. این لایه از MCP، OpenAPI، Postman، GraphQL و نقاط انتهایی HTTP خام پشتیبانی می‌کند. برای حفظ امنیت، اعتبارنامه‌ها (Credentials) در سمت سرور مدیریت می‌شوند تا کلیدهای خام هرگز وارد ماشین ایزوله عامل نشوند. این موضوع زمانی که عامل‌ها روی صورت‌حساب‌ها، تیکت‌ها و کدها عملیاتی می‌شوند، حیاتی است؛ زیرا پلتفرم باید کنترل کند که کدام عامل مجاز به فراخوانی کدام ابزار است و انسان قبل از وقوع اتفاق، چه چیزی را می‌بیند.
استقرار و لایسنس
استقرار این سیستم برای انعطاف‌پذیری حداکثری طراحی شده است. یک تیم می‌تواند با یک پشته Docker Compose شروع کند یا از CLI از طریق دستور curl -fsSL https://kortix.com/install | bash استفاده کند. پس از نصب، کاربران می‌توانند با دستور kortix init یک پروژه را ایجاد کرده و با kortix ship آن را فعال کنند. پروژه‌های ایجاد شده در اپلیکیشن وب نیازی به نصب محلی ندارند. این سیستم روی لپ‌تاپ، سرور مجازی (VPS)، شبکه خصوصی مجازی (VPC)، سخت‌افزار درون‌سازمانی (On-prem) یا ابر مدیریت شده به صورت یکسان اجرا می‌شود. کدها تحت لایسنس Elastic License 2.0 منتشر شده‌اند که به تیم‌ها اجازه می‌دهد سیستم را به صورت شخصی میزبانی کنند، کدها را بخوانند و از طریق مخزن Kortix در GitHub آن‌ها را تغییر دهند.
عملیاتی کردن چرخه
برای تیم‌هایی که تازه شروع کرده‌اند، مسیر پیشنهادی این است که یک تسک دستی را که تیم در حال حاضر به صورت دستی انجام می‌دهد — مانند بررسی خطاهای سیستمی، گزارش هفتگی یا تطبیق حساب‌ها — انتخاب کنند. عامل را در markdown تعریف کنید، تنها ابزاری که نیاز دارد را متصل کنید و اجازه دهید جلسه در ماشین ایزوله خود اجرا شود.
وقتی درخواست تغییر (Change Request) رسید، diff را بخوانید و تصمیم بگیرید. این چرخه واحد، بیشتر از هر جدول مقایسه‌ای (Feature Matrix) آموزش می‌دهد، زیرا ثابت می‌کند که آیا پلتفرم می‌تواند زمینه شرکت را حفظ کند، مدل انتخابی را اجرا کند و کار را قبل از نهایی شدن برای تایید یک انسان متوقف کند یا خیر.
این چرخش به سمت «مالکیت» به این معناست که پشته هوش مصنوعی به جای یک اشتراک ماهانه، به یک دارایی شرکت تبدیل شود. وقتی منطق عامل یک commit در git است، مالکیت معنوی اتوماسیون متعلق به شرکت است، نه تامین‌کننده‌ای که رابط کاربری را فراهم کرده است. برای کسانی که به دنبال پیاده‌سازی این سیستم هستند، گام بعدی ارزیابی این است که آیا گردش‌کارهای فعلی آن‌ها قابل استخراج به صورت متن ساده هستند یا در یک سازنده بصری اختصاصی حبس شده‌اند.
گام بعدی شما
- بررسی کنید آیا گردش‌کارهای فعلی شما قابل استخراج به متن ساده هستند یا در یک ابزار بصری بسته حبس شده‌اند.
- یک تسک دستی کوچک را انتخاب کرده و آن را در قالب یک فایل markdown برای تست در Kortix تعریف کنید.
- مطالعه مستندات MCP برای گسترش ابزارهای قابل دسترسی عامل‌های خود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو