سازمانی که سه ایجنت از سه پیمانکار دارد، سه در ورودی و سه مدل امنیتی دارد. سؤال درست این نیست که کدامشان را نگه داریم — این است که چطور هر سه را بدون بازنویسی زیر یک سقف بیاوریم.
ایجنت موجود پیمانکار دور ریخته نمیشود: اگر پیمانکار یک فایل معرفی و یک آدرس HTTP بدهد، همان ایجنت بدون تغییر زبان یا فریمورک زیر پلتفرم میآید.
این اصل اول محصول است و همهی بقیه از آن بیرون میآید: به سازنده تحمیل نمیکنیم با چه زبان، چه کتابخانه یا چه معماریای ایجنتش را بنویسد. چیزی که استاندارد میشود فقط لبه است — یعنی فایل معرفی و قرارداد HTTP. پایتون، سیشارپ، پیاچپی، Go، Node.js یا حتی یک گردشکار n8n؛ از این طرفِ مرز فرقی نمیکند.
ایجنتهای ساخت خود آرتین هیچ امتیازی ندارند: همان فایل معرفی، همان قرارداد، همان اعتبارسنجی. دلیلش اخلاقی نیست، فنی است — اگر برای ایجنت خودمان مسیر میانبری بسازیم، ناشر بیرونی به همان دیواری میخورد که ما دورش زدهایم و خبردار نمیشویم.
پیمانکار برای هر کاری که ایجنتش بلد است، یک توصیف کوتاه میدهد بهعلاوهی چهار فیلد. این چهار فیلد اجباریاند و در زمان پذیرش بررسی میشوند، چون هر کدام یک تصمیم پلتفرمی را ممکن میکنند.
| فیلد | چه میگوید | پلتفرم با آن چه میکند |
|---|---|---|
| عبارتهای نمونه | کاربر معمولاً این کار را چطور میخواهد | نمایهسازی برای پیدا کردن گزینهی درست |
| سطح اثر | خواندنی، نوشتنی یا برگشتناپذیر | تعیین اینکه تأیید انسانی لازم است یا نه |
| سطح محرمانگی | چه حساسیتی از داده را لمس میکند | تعیین اینکه کدام مدل مجاز است این داده را ببیند |
| نوع اجرا | همزمان یا طولانی | انتخاب مسیر اجرا و شکل اطلاعرسانی به کاربر |
نوشتن عبارتهای نمونه کمهزینهترین کاری است که ناشر برای کیفیت مسیریابی انجام میدهد و بیشترین اثر را دارد. یک ایجنت خوب با عبارتهای نمونهی ضعیف، پیدا نمیشود.
بعد از فایل معرفی، تنها چیزی که باقی میماند یک آدرس است که پلتفرم آن را صدا میزند. سه قاعده روی این تماس ثابتاند و مذاکرهپذیر نیستند.
ایجنت با تصمیم یک نفر وارد کاتالوگ نمیشود. فایل معرفی از یک اعتبارسنجی خودکار عبور میکند و تا وقتی همهی موارد سبز نشوند، منتشر نمیشود.
مورد آخر چیزی است که مارکتپلیسهای ایجنت معمولاً دیر کشفش میکنند: دو ایجنت که هر دو ادعای «رزرو» دارند، مسیریابی را خراب میکنند بدون اینکه هیچکدام بهتنهایی معیوب باشند.
خیر؛ چیزی که لازم است یک فایل معرفی و یک آدرس HTTP است، نه تغییر زبان یا معماری.
کاری که معمولاً واقعاً لازم میشود این است که ایجنت موجود، ورودیاش را به شکل ساختاریافته بپذیرد و هویت را از توکن بخواند بهجای اینکه از پارامتر بگیرد. این دو تغییر کوچکاند ولی صفر نیستند و باید در برآورد دیده شوند.
بله؛ هر چیزی که یک آدرس HTTP قابل فراخوانی داشته باشد میتواند ایجنت باشد.
ابزارهای اتوماسیون رقیب پلتفرم نیستند. برای فرایند مشخص و تکراری ابزار خوبیاند و گردشکاری که با آنها ساخته شده میتواند بهعنوان یک ایجنت منتشر شود. چیزی که آن ابزارها نمیدهند، لایهی مشترک هویت، سیاست داده و ممیزی روی دهها ایجنت از سازندههای مختلف است.
ایجنتی که فایل معرفی ندارد وارد پلتفرم نمیشود، ولی میتواند مثل هر سامانهی دیگری در سازمان به کارش ادامه دهد.
در عمل، این معمولاً اهرم مذاکرهی سازمان است نه بنبست: فایل معرفی کار چند ساعته است و پیمانکاری که آن را ندهد، از فهرست ایجنتهای در دسترس کارکنان بیرون میماند. تصمیمش با سازمان است، نه با ما.
ایجنت سازمانی ایجنتی است که با هویت واقعی کارمند اجرا میشود، مجوزهای موجود سامانهها را دور نمیزند، و هر فراخوانیاش در لاگ ممیزی قابل استخراج ثبت میشود.
ارکستراسیون ایجنت یعنی تصمیمگیری دربارهی اینکه کدام ایجنت درخواست کاربر را بگیرد، با چه ورودیهایی و با چه هویتی اجرا شود — لایهای بالای خود ایجنتها.
MCP یا Model Context Protocol یک استاندارد باز است که به مدل زبانی اجازه میدهد ابزارها و دادههای بیرونی را به شکل یکسان صدا بزند.
حاکمیت ایجنت یعنی اینکه هر ایجنت با هویت واقعی همان کارمند اجرا شود، مجوز نهاییاش هرگز از مجوز خود او فراتر نرود، و هر فراخوانی در یک رکورد قابل استخراج ثبت شود.
بگویید همین حالا چند ایجنت یا اتوماسیون در سازمان دارید و هر کدام از کجا آمدهاند. همین فهرست معمولاً نشان میدهد نقطهی شروع کجاست.
شروع گفتگو