زوهـو نسخه ۳.۰ پلتفرم کاتالیست را با تمرکز بر عاملهای برنامهنویسی عرضه کرده است؛ عاملهایی که دیگر فقط کد تولید نمیکنند و میتوانند مستقیماً روی زیرساخت ابری کار انجام دهند. این نسخه یک سرور زنده MCP، مجموعه مهارتهای مخصوص عاملها، رابط خط فرمان غیرتعاملی و اتصال به ابزارهایی مانند Claude، Cursor، Codex و Gemini دارد. نکته اصلی، اضافهشدن یک دستیار دیگر نیست؛ عامل میتواند در همان محیطی که برنامه به تولید میرود جدول بسازد، احراز هویت را تنظیم کند و سرویس را مستقر کند.
با این تغییر، مسئله کنترل هم جدیتر میشود. وقتی یک عامل اجازه تغییر زیرساخت را دارد، کافی نیست فقط بدانیم کدی که نوشته درست بوده است. باید مشخص باشد عامل با چه هویتی وارد شده، چه مجوزی داشته، کدام ابزارها را فراخوانی کرده و در صورت خطا چه چیزی را میتوان بازسازی یا برگرداند. کاتالیست ۳.۰ این کنترلها را به خود فرایند اجرای عامل نزدیک کرده است.
عامل از ویرایش کد فراتر میرود
زوهـو میگوید سرور MCP کاتالیست به عاملهای پشتیبانیشده اجازه میدهد مستقیماً با زیرساخت ارتباط بگیرند و کارهایی مانند ساخت جدول، تنظیم احراز هویت و استقرار برنامه را انجام دهند. مخزن رسمی افزونه Cursor نیز همین الگو را نشان میدهد: مهارتهای جداگانه برای سرویسهای مختلف، اطلاعات زمینهای پروژه و دسترسی به عملیات مربوط به پایگاه داده، حافظه نهان و فضای ذخیرهسازی در اختیار عامل قرار میگیرد.
این مدل با حالتی فرق دارد که عامل فقط مخزن کد را تغییر میدهد و سامانه جداگانهای مسئول استقرار است. اینجا رابط عامل تا منابع ابری امتداد پیدا میکند. چنین کاری میتواند فاصله میان تولید کد و عملیات پلتفرم را کمتر کند، اما در صورت اشتباه عامل، دامنه آسیب احتمالی نیز بزرگتر میشود.
هویت و سطح دسترسی بخشی از طراحی عامل است
در مستندات کاتالیست آمده است که عامل با حساب و مجموعه مجوزهای قابل تنظیم خودش وارد میشود. همچنین فرمانهای مخرب در حالت غیرتعاملی غیرفعال هستند. این تفکیک مهم است، چون عاملی که بدون حضور مستقیم کاربر اجرا میشود نباید بهطور پیشفرض همان اختیار توسعهدهنده را داشته باشد.
نتیجه عملی برای تیمها روشن است: هویت عامل باید مانند حساب یک سرویس مستقل مدیریت شود. سطح دسترسی باید تا حد لازم محدود بماند، اختیار محیط توسعه از تولید جدا شود و تغییرات حساس زیرساختی همچنان پشت تأیید انسانی یا کنترلهای خط لوله باقی بمانند. در چنین معماریای MCP فقط راهی برای اتصال ابزارها نیست؛ بخشی از مرز مجوزدهی سامانه است.
ثبت دقیق اجرا دیگر یک قابلیت جانبی نیست
کاتالیست لاگهای برنامه، پلتفرم و فراخوانی ابزارهای MCP را ثبت میکند و زوهـو میگوید تغییرات پس از راهاندازی نسخهبندی میشوند، قابل انتساب هستند و امکان بازگردانی دارند. این ویژگیها کمک میکنند بعد از یک خطا بتوان پرسید کدام عامل، با چه هویتی، چه ابزاری را اجرا کرده و چه تغییری ایجاد شده است.
این امکانات تضمین نمیکنند که هر اقدام عامل ایمن باشد، اما مسیر اجرای آن را قابل بررسی میکنند. برای تیمهای مهندسی، مقایسه پلتفرمهای آماده برای عاملها باید فراتر از فهرست مدلهای پشتیبانیشده برود و کیفیت کنترل هویت، مجوزها، ثبت رویداد و بازگردانی تغییرات را هم دربر بگیرد.
ادعای کارایی زوهـو هنوز مستقل تأیید نشده است
زوهـو در آزمایشهای خودش اعلام کرده استفاده از مهارتهای عامل و زمینه MCP نرخ تکمیل کار را برای مدلهای آزمایششده به حدود ۹۰ تا ۹۵ درصد رسانده است. این اعداد حاصل ارزیابی خود شرکت هستند و نباید بهعنوان نتیجه مستقل در نظر گرفته شوند.
آنچه آسانتر قابل بررسی است، قابلیتهای عرضهشده است: صفحه محصول وجود سرور MCP، مجوزهای محدودشونده، ثبت فراخوانی ابزار و نسخهبندی تغییرات را توضیح میدهد و مخزن رسمی نیز افزونه Cursor و مهارتهای مربوط به سرویسهای کاتالیست را نشان میدهد. بنابراین میتوان معماری اجرا و کنترل را جدا از ادعاهای بنچمارک ارزیابی کرد.
تصمیم مهمتر: اختیار عامل کجا قرار بگیرد؟
کاتالیست ۳.۰ نمونهای از تغییری بزرگتر در مهندسی نرمافزار عاملمحور است: ارائهدهندگان زیرساخت به عاملهای برنامهنویسی امکان انجام عملیات واقعی میدهند و همزمان باید کنترلهای لازم برای محدودکردن این اختیار را فراهم کنند.
تیمها اکنون باید تصمیم بگیرند اختیار عامل در یک چارچوب اجرایی مستقل باقی بماند که از مسیرهای معمول خودکارسازی به ابر متصل میشود، یا به رابط بومی خود پلتفرم منتقل شود؛ جایی که مجوزها و ردپای اجرا با زیرساخت یکپارچهاند. مسیر دوم میتواند کار را سادهتر کند، اما وابستگی به مدل کنترلی پلتفرم را هم بیشتر میکند. بهتر است قابلیت جابهجایی فرایند عامل جدا از قابلیت جابهجایی خود برنامه سنجیده شود.