
یک عامل نمیتواند ناظر خودش باشد: تفکیک وظایف در هوش مصنوعی
معماری کنترلی برای جداسازی پیشنهاد، تأیید، اجرا و تطبیق در فرایندهایی که هوش مصنوعی میتواند اقدام پرپیامد کسبوکار را آغاز کند.
ادامه مطلبپژوهش ژرف
میز پژوهش سامانههای عاملمحور

مفیدترین ایده در نوشته «معماری دفترکل» NO1ennn این نیست که یک نفر با هفت ربات شش کسبوکار را اداره کند. ایده اصلی این است که هر مسیر عملیاتی مالک یک دفترکل باشد، هر نقش ممنوعیتهای روشن داشته باشد، هر تحویل با شاهد حرکت کند و هر اقدام پرپیامد پیش از اجرا مقابل انسان متوقف شود.
این نسخه طرح کامل را بازسازی میکند، هر چهار تصویر درون نوشته منبع را نگه میدارد و ادعاهای محصول را با مستندات جاری Kimi و SpaceXAI میسنجد. همچنین معماری کنترلی قابلاجرا را از الگوی درآمدی نویسنده جدا میکند. ماهانه ۱۰۲٬۸۷۰ دلار فقط محاسبه یک سناریو است، نه رسید درآمد؛ بازه هزینه نیز ثابت نمیکند که شش کسبوکار را میتوان با ده دقیقه کار انسانی روزانه سودآور اداره کرد.
پرسش عملی ارزشمندتر است: چگونه یک اپراتور کوچک کار را میان عاملهای پایدار تقسیم کند، بیآنکه یک عامل بتواند اقدام پرپیامد را هم بسازد، هم تأیید و اجرا کند و هم نتیجهاش را درست اعلام کند؟
موضوع شش پنجره گفتوگوی عمومی نیست؛ یک میز کنترل است که بر شش ماشین وضعیت کسبوکار نظارت میکند. هر دفترکل ثبت میکند چه چیزی وارد شد، چه کاری در جریان است، چه چیزی تحویل شد، کدام وضعیت بیرونی تغییر کرد، چه وجهی پرداخت شد، چه خطایی رخ داد و کدام استثنا به انسان نیاز دارد.
نام کسبوکارها فقط مثال است. ساختار تکرارپذیر پنج جزء دارد:
نکته آخر حیاتی است. راهنمای تفکیک وظایف توضیح میدهد چرا چند برچسب نقش در یک مسیر اختیار، کنترل مستقل نمیسازد. دو ربات با اعتبارنامه، وضعیت نوشتنی و دامنه شکست مدل مشترک، ظاهراً جدا اما در عمل یک کنشگر مؤثرند.
میز عملیاتی شش دفترکل با WARDEN در مرکز و صف تأیید در پایین.
تصویر سازنده از نوشته منبع؛ عددهای عملیاتی آن نمونه نمایشیاند، نه نتیجه راستیآزماییشده کسبوکار.
نوشته منبع دو لایه متفاوت را کنار هم میگذارد، نه روبهروی هم.
Grok Bot سطح کار مدیریتشده است. معرفی رسمی SpaceXAI میگوید رباتهای نامدار یک کاربر، یک رایانه ابری پایدار و فایلها، نشست مرورگر و ورودهای برنامه را مشترک دارند. هر ربات صفحه خودش را دارد و میتواند همزمان کار کند؛ اما این صفحهها مرز امنیتی جدا نیستند. بنابراین نمایش گردشکار، نشست پایدار و تحویل میان برنامهها آسان میشود، ولی اعتبارنامه و دامنه آسیب متمرکز میماند.
Kimi K3 مدل و پشته برنامهپذیر عامل است. مخزن رسمی Kimi K3 آن را مدل MoE با ۲٫۸ تریلیون پارامتر کل، ۱۰۴ میلیارد پارامتر فعال برای هر توکن، انتخاب ۱۶ متخصص از ۸۹۶، چندوجهی بومی و پنجره بافت ۱٬۰۴۸٬۵۷۶ توکن معرفی میکند. Kimi Code ابزار ترمینال، مهارت، اتصال MCP و عامل فرعی میدهد؛ Kimi Agent SDK همین محیط اجرا را در اختیار برنامه میگذارد.
پس تقسیم منطقی چنین است:
| لایه | کاربرد مناسب | محدودیت اصلی |
|---|---|---|
| Grok Bot | کار پایدار در مرورگر و برنامه، روال و نمونهسازی سریع عملیات | رباتها یک رایانه و ورودهایش را مشترک دارند |
| رابط Kimi K3 | استدلال با بافت بلند، استخراج، برنامهریزی و راستیآزمایی | هزینه، تأخیر و شاهد همچنان کنترل میخواهد |
| Kimi Code | اجرای کار مخزن، ترمینال، فایل و گردشکار اسکریپتی | پوشه کار و مجوز فرمان باید محدود باشد |
| Kimi Agent SDK | نشست، تأیید، ابزار و هماهنگی برنامهنویسیشده | وضعیت پایدار و سیاست باید در خود برنامه نگهداری شود |
این ترکیب خودبهخود شرکت نمیسازد. دفترکل، هویت، اتصال، طرحواره، پوش تأیید و فرایند تطبیق خود سامانهاند.
منبع شش مسیر کسبوکار و یک توزیعکننده پیشنهاد میکند. آنچه اهمیت دارد عدد تحت مالکیت و ممنوعیت نقش است، نه نام نمایشی آن.
| دفترکل | عامل | مالک چیست | چه کاری نمیکند |
|---|---|---|---|
| استودیوی محتوا | ECHO | محتوای پذیرفته و منتشرشده، دامنه دسترسی و تقاضای واجدشرایط پاییندست | معرفی فروش یا صدور فاکتور |
| تجارت الکترونیکی | CRATE | سفارش تحویلشده، پوشش موجودی و حاشیه مشارکت هر کالا | تغییر قیمت یا لغو سفارش تأمینکننده بدون تأیید |
| آژانس خدماتی | PITCH | تماس واجدشرایط، پیشنهاد و قرارداد ماهانه امضاشده | تحویل کار مشتری یا تغییر دفترکل دیگر |
| محصول دیجیتال | VAULT | واحد فروختهشده، نرخ بازپرداخت و استثنای پشتیبانی | اجرای تبلیغ پولی یا تأیید تغییر قیمت خودش |
| تولید سرنخ | BEACON | سرنخ واجدشرایط و شاهددار تحویلشده | مذاکره نرخ یا تماس با فهرست تأییدنشده |
| عضویت | HEARTH | عضو فعال، ریزش و مسئله حلنشده اعضا | صدور اعتبار یا تغییر صورتحساب |
| میز مسیریابی | WARDEN | اولویت، نمای وجه، اعتبار تحویل و صف تأیید | نوشتن، فروش، انجام سفارش، پشتیبانی یا جابهجایی پول |
هر دفترکل به تاریخچه رویداد فقطافزودنی و یک نمای وضعیت جاری نیاز دارد. خانهای از صفحهگسترده که میگوید «حاشیه = ۳۱٪» کافی نیست. رویداد منبع، نسخه محاسبه، زمان مشاهده، استثنا و کنشگر تولیدکننده وضعیت باید باقی بماند.
WARDEN عمداً کماختیار است. میتواند تحویل ناقص را رد کند، پیشنهاد را با وضعیت دفترکل بسنجد و کار را به مالک درست بفرستد. نمیتواند عدد گمشده را بسازد، کار ردشده را خودش انجام دهد یا پیشنویس اپراتور را به مجوز تبدیل کند.
منبع یک روز عملیاتی سهضربی دارد:
ارزش انباشته از تحویل کنترلشده میان دفترکلها میآید. محتوایی با ترافیک واجدشرایط نامعمول میتواند بسته سرنخ BEACON بسازد؛ حساب مناسب به PITCH برود؛ مشتری امضاشده وارد پذیرش HEARTH شود؛ پرسش تکراری فرضیه محصول VAULT را بسازد؛ سپس ECHO پیشنویس معرفی را آماده کند. CRATE وضعیت تأییدشده وجه و موجودی را میدهد، نه داده مشتری که به آن نیاز ندارد.
بستن شب با شش خط وضعیت دفترکل و سه کارت تصمیم انسانی.
تصویر سازنده از نوشته منبع؛ این داشبورد رابط مفهومی است، نه تصویر سامانه تولیدی.
تحویل باید داده باشد، نه اشاره در گفتوگو:
{
"handoff_id": "beacon-pitch-20260830-0042",
"from": "beacon",
"to": "pitch",
"ledger": "leadgen",
"kind": "qualified_lead",
"payload": {
"account_id": "acct_741",
"trigger": "چهار فرصت شغلی تأییدشده عملیات در چهارده روز",
"fit_score": 0.81
},
"evidence": [
"mcp://jobs/account/acct_741?window=14d",
"mcp://crm/account/acct_741/history"
],
"created_at": "2026-08-30T07:12:00Z",
"expires_at": "2026-08-31T07:12:00Z",
"idempotency_key": "sha256:..."
}
نقش گیرنده پیش از اقدام، طرحواره، مقصد، انقضا، دسترسپذیری شاهد و کلید جلوگیری از تکرار را میسنجد. مجوز فرستنده نیز به او ارث نمیرسد.
قاعده «دو کلید» منبع نقطه شروع خوبی است: یک نقش پیشنهاد میدهد، کنترل دیگری راستیآزمایی میکند و انسان تصمیم میگیرد. این قاعده باید انتشار، پیام بیرونی، تغییر قیمت، بازپرداخت، لغو سفارش، دسترسی، حذف، تغییر تولید و پذیرش حقوقی را نیز پوشش دهد.
برای اقدام پرپیامد، سه پیام گفتوگو کافی نیست. تأیید را به شیء اقدام معیارشده شامل مقصد دقیق، مبلغ یا مقدار، مرجع شاهد، نسخه سیاست، انقضا و هش متصل کنید. اجراکننده پوش تغییرکرده، منقضی، استفادهشده یا خودتأیید را رد کند. راهنمای طراحی تأیید انسانی اطلاعات لازم برای یک کارت تصمیم واقعی را شرح میدهد.
منبع اقدامها را نیز رنگبندی میکند:
| رده | معنا | نمونه |
|---|---|---|
| سبز | آمادهسازی برگشتپذیر در فضای محدود | خواندن منبع مجاز، محاسبه، پیشنویس، دستهبندی و ساخت فایل موقت |
| زرد | اجرا فقط در قاعده باریک و گزارش پیش از نهاییشدن | تغییر مرحله غیرحساس، زمانبندی پیشنویس تأییدشده، آمادهسازی پاسخ پشتیبانی |
| قرمز | توقف برای تصمیم آگاهانه و مشخص انسان | ارسال، انتشار، پرداخت، بازپرداخت، تغییر قیمت، لغو، حذف، اعطای دسترسی و استقرار |
رنگ باید در سازگارکننده ابزار به سیاست قابلاعمال «اجازه، نیازمند تأیید یا رد» تبدیل شود. مستند تأیید SpaceXAI همین محدودیت را روشن میکند: Auto Review بر مدل تکیه دارد و مکمل حداقلسازی اختیار و مرز صریح تأیید است، نه جایگزین آن.
دو ظرافت منبع ارزش نگهداشتن دارد. لغو یک اقدام بیرونی تازه است، نه بازگردانی بیخطر. خواندن نیز وقتی خراشگر سهمیه مشترک را میسوزاند، رکورد محدود را نمایان میکند یا رایانه موردنیاز دیگر دفترکلها را اشغال میکند، میتواند پرپیامد شود.
سامانه چندعاملی میتواند عدد ساختگی را سریعتر از تیم انسانی جابهجا کند. منشأ را الزام طرحواره کنید:
{
"claim": "نرخ فروش SKU-118 در سی روز",
"value": 0.712,
"unit": "ratio",
"source": "mcp://store/reports/sellthrough?sku=118&window=30d",
"observed_at": "2026-08-30T06:14:02Z",
"produced_by": "crate",
"ledger": "ecommerce",
"calculation_version": "sellthrough-v3"
}
نبود منبع اجازه نمیدهد WARDEN در وب بگردد تا عدد دلخواه پیدا کند. تحویل با دلیل قابلخواندن ماشین به مبدأ برمیگردد. دو منبع معتبر ناسازگار نیز با هم بهصورت استثنا حرکت میکنند؛ عامل حق ندارد عددی را برگزیند که پیشنهادش را قبولپذیر میکند.
دامنه شاهد هم مهم است. رکورد CRM میتواند زمان آخرین تماس را پشتیبانی کند، اما توان مالی شرکت را ثابت نمیکند. توضیح مدل میتواند محاسبه را شرح دهد، اما رسید زیربنایی نیست. هویت منبع، زمان دریافت، نسخه، تبدیل و در صورت امکان مرجع پایدار یا هش را ثبت کنید.
Kimi K3 وزنباز است، اما ایستبازرسی کامل نصب معمول لپتاپ نیست. دستور اجرای رسمی vLLM حدود ۱٫۶۸ ترابایت وزن MXFP4، حداقل هشت GB300 یا هشت MI355X/MI350X برای چیدمان تکگره تأییدشده و نیاز بسیار بزرگتر H100 را شرح میدهد. برای بیشتر تیمها، دسترسی میزبانیشده مسیر نخست عملی است.
Kimi Code لایه اجرای در دسترس است. راهنمای شروع جاری این نصبکنندهها را مستند میکند:
# macOS / Linux
curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash
# Windows PowerShell
irm https://code.kimi.com/kimi-code/install.ps1 | iex
فرمان kimi را اجرا کنید، با /login وارد شوید و سپس /model را بزنید. پیکربندی مدل جاری شناسههای k3 و k3-256k را فهرست میکند؛ دسترسی و پنجره کامل یکمیلیونتوکنی به طرح Kimi Code بستگی دارد. عملیات فقطخواندنی ممکن است خودکار اجرا شود، ولی تغییر فایل و فرمان پوسته بهطور پیشفرض تأیید میخواهد. با تأیید خودکار فراگیر این مرز را حذف نکنید.
Kimi Code CLI در حال کار داخل پوشه یک پروژه.
تصویر محصول در نوشته منبع. برچسب مدل تصویر پیش از انتخابگر جاری K3 است؛ نصب و انتخاب مدل را از مستند روز دنبال کنید.
برای هماهنگی، Kimi Agent SDK کلاینت Python، Node.js و Go دارد و نشست، فراخوانی ابزار و تأیید را نمایان میکند. نمونه کوتاه Python در نوشته منبع بیشتر مفهومی است تا رابط جاری آماده اجرا. با راهنمای نسخهدار SDK بسازید و دفترکل، صف، جلوگیری از تکرار، سیاست و سابقه حسابرسی را در برنامه نگه دارید؛ نشست مدل سامانه مرجع نیست.
SpaceXAI Grok Bot را ۱۱ اوت در بتای اولیه عرضه کرد و در ۲۶ اوت دسترسی را گسترش داد تا SuperGrok، Cursor Pro و همه طرحهای Cursor Teams نیز کنار ردههای بالاتر آن را داشته باشند. دسترسی، مصرف گنجاندهشده و قیمت در بتا تغییر میکند؛ پیش از خرید صفحه جاری محصول را بررسی کنید.
مرز مهم معماری ثابت است: همه رباتهای یک حساب یا عضو، یک رایانه ابری پایدار را مشترک دارند. با وجود صفحه جدا، فایل، نشست و ورود مشترک است. این ویژگی تحویل میان عاملها در منبع را شدنی میکند؛ اما ECHO و CRATE فقط با نام متفاوت از هم جدا نمیشوند.
صفحه رسمی Grok Bot و فضای کار چندرباتی.
تصویر محصول در نوشته منبع. دسترسی و جزئیات طرح باید در صفحههای جاری رسمی سنجیده شود.
هویت کاری اختصاصی، نقش محدود برنامه، اتصال ویژه هر دفترکل و راز دامنهبندیشده بهکار ببرید. نشست پرامتیاز بانک، تبلیغ، ایمیل، فروشگاه و CRM را روی یک رایانه مشترک قرار ندهید و پرامپت نقش را جداسازی ننامید. راهنمای مهارت و روال SpaceXAI توصیه میکند پیش از خودکارسازی، کار یکباره اثبات شود؛ ارسال، خرید، حذف، انتشار و تغییر تولید پشت تأیید بماند؛ و سیاست داده کهنه و تکرار تعریف شود.
روز نخست هر هفت نقش را نسازید. توالی مرحلهای منبع اگر به دروازه پذیرش تبدیل شود، منطقی است:
| هفته | ساخته شود | شرط خروج |
|---|---|---|
| ۱ | یک دفترکل متصل به تقاضای واقعی | ده کار مشاهدهشده؛ هر توقف، حدس و اصلاح ثبت شود |
| ۲ | رده اقدام و سیاست ابزار | اقدام قرمز اجرا نشود؛ اقدام سبز محدود و ثبت شود |
| ۳ | دفترکل دوم و WARDEN | تحویل ناقص و بیشاهد بهطور قطعی برگردد |
| ۴ | یک تحویل یکطرفه میان دفترکل | تکرار، انقضا و شاهد گمشده آزموده شود |
| ۵ و ۶ | دفترکل سوم و چهارم | هر منشور سنجه مالک، ممنوعیت و رفتار بازیابی داشته باشد |
| ۷ | پوش SDK، زمانبندی و صف تأیید | کار قطعشده امن ادامه یابد و تأیید منقضی اجرا نشود |
| ۸ | دفترکل پنجم و ششم | چهار دفترکل یک هفته در بودجه خطا و بازبینی کار کرده باشند |
پیش از گسترش، سامانه را عمدی بشکنید: اتصال را باطل کنید، عدد متناقض برگردانید، ورود را منقضی کنید، رویداد تکراری بسازید، صفحه آلوده بدهید، قیمت را پس از تأیید عوض کنید و وقفه با نتیجه نامعلوم شبیهسازی کنید. نتیجه امن اغلب توقف آشکار است، نه بازیابی قهرمانانه.
منبع این شکل نمونه درآمد ماهانه را میدهد:
| دفترکل | محاسبه سناریو |
|---|---|
| آژانس خدماتی | ۸ قرارداد × ۴٬۵۰۰ دلار = ۳۶٬۰۰۰ دلار |
| محصول دیجیتال | ۶۲۰ واحد × ۳۹ دلار = ۲۴٬۱۸۰ دلار |
| تجارت الکترونیکی | ۱٬۴۰۰ سفارش × ۱۴ دلار حاشیه مشارکت = ۱۹٬۶۰۰ دلار |
| تولید سرنخ | ۳ مشتری × ۳٬۵۰۰ دلار = ۱۰٬۵۰۰ دلار |
| عضویت | ۴۱۰ عضو × ۱۹ دلار = ۷٬۷۹۰ دلار |
| محتوا | فرض حمایت مالی و همکاری فروش = ۴٬۸۰۰ دلار |
| جمع | ۱۰۲٬۸۷۰ دلار |
منبع همچنین ماهانه ۹۰۰ تا ۱٬۶۰۰ دلار مصرف مدل و ۴۰۰ تا ۷۰۰ دلار ابزار، میزبانی، داده و اشتراک برآورد میکند. این رقمها مستقل اثبات نشدهاند و هزینه جذب، نیروی انسانی، مالیات، کارمزد پرداخت، مرجوعی، سرمایه موجودی، طلب سوختشده، حقوق و انطباق، زمان بازبینی، اختلال و ارزش دانش تخصصی اپراتور را حذف یا نامطمئن میگذارند.
جدول را مدل حساسیت بدانید. حجم، قیمت، حاشیه، تبدیل، ریزش، بازپرداخت و هزینه را با داده مشاهدهشده جایگزین کنید. نخستین سنجه اقتصادی باید هزینه هر کار نهایی پذیرفتهشده همراه با دقیقه بازبین و اصلاح باشد، نه تعداد توکن هر اجرا. این تحلیل معماری کسبوکار است، نه توصیه مالی یا سرمایهگذاری.
شش عدد جادویی نیست. نقش تازه فقط وقتی اضافه شود که مرز پیشین پایدار و دفترکل جدید مالک، دامنه داده، دامنه ابزار و نتیجه قابلسنجش جدا داشته باشد.
هر دفترکل و خود میز را مانند سامانه عملیاتی اندازه بگیرید:
صف دهدقیقهای روزانه هدف آزمایش است، نه الزام طراحی. اگر تصمیم آگاهانه مرتب زمان بیشتری میخواهد، کوچککردن بسته از پنهانکردن بافت امنتر است. اگر تأیید به کلیک خودکار بدل شد، شمار تصمیمها را کم کنید، کنترل قطعی را خودکار کنید یا اختیار عامل را کاهش دهید.
دستاورد ماندگار نوشته منبع یک قانون اساسی کوچک عملیاتی است: یک مالک دفترکل برای هر مسیر، ممنوعیت روشن، تحویل شاهددار، توزیعکنندهای که اجرا نمیکند و کنترل انسان بر اقدام پرپیامد. Grok Bot میتواند سطح کار پایدار و مشترک را بدهد؛ Kimi K3، Kimi Code و Kimi Agent SDK استدلال و اجرای برنامهپذیر را فراهم کنند.
نمودار سازمانی فقط وقتی قابلاعتماد میشود که مرز محصول به هویت جدا، اعتبارنامه محدود، رویداد تغییرناپذیر، طرحواره نوعدار، تأیید متصل به اقدام، اجرای بدون تکرار و تطبیق مستقل تبدیل شود. یک دفترکل بسازید و حلقه کنترلش را ثابت کنید، سپس دومی را اضافه کنید. کشیدن نمودار هفت عامل آسان است؛ میزی که بتواند خودش را متوقف کند محصول واقعی است.

معماری کنترلی برای جداسازی پیشنهاد، تأیید، اجرا و تطبیق در فرایندهایی که هوش مصنوعی میتواند اقدام پرپیامد کسبوکار را آغاز کند.
ادامه مطلب
راهنمای عملی رایانه مشترک، منشور نقش، روال، تحویل چندعاملی، قیمت، شاهد تکمیل و مرزهای ایمنی در Grok Bot.
ادامه مطلب
راهنمای رزرو اتمیک بودجه، مهار خرج همزمان، اتصال تأیید به مبلغ و تطبیق تعهدهای مالی عاملهای هوش مصنوعی.
ادامه مطلباگر این مطلب به یک سامانه واقعی در سازمان شما مربوط است، از خدمات و مطالعه موردی شروع کنید.