مکانیزم «هارنس»؛ عامل‌های هوش مصنوعی برای مقیاس سازمانی چه می‌خواهند؟

تفاوت بین یک دموی جذاب و سیستمی که مدیر امنیت اطلاعات (CISO) آن را تأیید کند، در یک کلمه خلاصه می‌شود: مهندسی. باید بدانید در سیستم‌های پیشرفته، مدل تنها بخشی از معادله است و لایه‌های پیرامونی — شامل پرامپت‌های سیستمی، ابزارها، سندباکس‌ها و لایه‌های نظارتی — در واقع حدود ۸۰٪ از عملکرد واقعی یک سیستم را تعیین می‌کنند.

به نقل از یک راهنمای میدانی مفصل که در ۲۷ ژوئیه ۲۰۲۶ منتشر شد، این موضوع آشکار می‌کند که قابلیت اطمینان در عامل‌های هوش مصنوعی (AI Agents) نه یک مشکل مدل‌محور، بلکه یک مشکل «هارنس» (Harness) است. معادله حاکم بر این سیستم‌ها چنین است: قابلیت اطمینان ≈ توانایی مدل × کیفیت هارنس.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی ابزارهای بدون کد (no-code) برای استقرار سریع عامل‌ها اشاره کردیم، صنعت اکنون از مهندسی پرامپت ساده به سمت مهندسی پیچیده قابلیت اطمینان حرکت می‌کند. در حالی که یک دمو را می‌توان در عرض چند ساعت ساخت، اما سیستمی که یک CISO واقعاً آن را امضا و تأیید کند، نیازمند حل مسئله «مالیات سازمانی» است؛ یعنی همان کنترل‌های حاکمیت، امنیت و هزینه‌ای که یک «اسباب‌بازی» را از یک «ابزار کاربردی» جدا می‌کند.

برای درک بهتر، مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — را به عنوان موتور قدرتمند ماشین تصور کنید؛ در این میان، هارنس همان شاسی، ترمزها و فرمان است که مانع از تصادف ماشین در سرعت‌های بالا می‌شود. برای سازمان‌ها، این معادله گسترده‌تر می‌شود: آمادگی سازمانی ≈ کیفیت هارنس × سطح اعتماد (امنیت + حاکمیت + نظارت).

معماری هسته و هارنس

هر عامل موفق در محیط عملیاتی از یک معماری مرجع خاص پیروی می‌کند. در مرکز این ساختار، یک حلقه هسته (Kernel) کوچک و قابل اعتماد قرار دارد که یک چرخه سخت‌گیرانه «مشاهده $
ightarrow$ تفکر $
ightarrow$ اقدام $
ightarrow$ مشاهده» را اجرا می‌کند. این هسته توسط یک صفحه کنترل (Control Plane) احاطه شده است که پیش از رسیدن درخواست به زمان اجرای عامل (Runtime)، مواردی چون احراز هویت (از طریق SSO/SAML/OIDC)، کنترل دسترسی نقش‌محور (RBAC)، محدودیت نرخ (Rate Limiting) و بررسی بودجه را مدیریت می‌کند.

برای تضمین پایداری، این راهنما استفاده از «وضعیت رویداد فقط-افزودنی» (Append-only event state) را توصیه می‌کند. به جای تغییر یا جهش (Mutate) در تاریخچه گفتگو، سیستم رویدادها را می‌پذیرد و به انتهای لیست اضافه می‌کند؛ این کار باعث می‌شود مسیر حرکت (Trajectory) عامل قابل بازپخش، عیب‌یابی و حسابرسی باشد. این روش از «حلقه‌های استدلالی فرار» که در محیط‌های شرکتی رایج است و باعث می‌شود عامل خارج از وظیفه تعریف‌شده خود پرسه بزند، جلوگیری می‌کند.

برای فرآیندهای تجاری ثابت مانند تأیید هزینه‌ها، پذیرش کارکنان جدید، فرآیندهای KYC و جریان‌های بازپرداخت وجه، راهنما پیشنهاد می‌کند که این‌ها به صورت ماشین‌های وضعیت صریح (Explicit State Machines) یا جریان‌های کاری بادوام (Durable Workflows) تعریف شوند (با استفاده از ابزارهایی مانند LangGraph برای گراف‌ها یا Temporal برای اجرای بادوام). در این حالت، مدل LLM تنها در زیر-وظایف محدودی مانند پیش‌نویس یک خلاصه یا طبقه‌بندی یک تیکت انعطاف‌پذیری دارد.

طراحی هسته قابل اطمینان

عامل‌های عملیاتی معمولاً به جای شبکه‌ای پیچیده از فراخوان‌ها (Callbacks)، بر روی ۴ تا ۵ مرحله متمرکز می‌شوند. طبق این مستندات، سه الگوی اثبات‌شده برای این حلقه‌ها وجود دارد:

• مولدهای ناهمگام (Async Generators): توسط Claude Code و OpenHands برای بازگرداندن هر گام به صورت مجزا استفاده می‌شود، که به فراخوان‌کننده اجازه می‌دهد فشار برگشتی (Backpressure) و لغو عملیات را کنترل کند.
• اتحادهای تایپ‌شده (Typed Unions): در SWE-agent و GoClaw به کار می‌رود که از یک پوشش (Wrapper) حدوداً ۳۰ خطی به نام forward_with_handling() استفاده می‌کند تا در صورت بروز خطای فرمت، حداکثر ۳ بار پرس‌وجوی مجدد انجام دهد.
• صف‌های هدایت FIFO: در nanobot و PicoClaw استفاده می‌شود تا کاربر بتواند در میانه حلقه، اصلاحات را تزریق کند. اگر ابزاری به دلیل پیام کاربر نادیده گرفته شود، یک نتیجه مصنوعی با متن "Skipped due to user message" به آن داده می‌شود تا مدل بتواند بستر متن (Context) را حفظ کند.

برای جلوگیری از هزینه‌های سرسام‌آور و شکست‌های رفتاری، راهنما تأکید می‌کند که بودجه‌ها باید صریح و عددی باشند، نه بر اساس «حس کلی» (Vibes). استانداردهای آزمایش‌شده در پروژه‌هایی چون Hermes، Claude Code و OpenHands شامل موارد زیر است:

• محدودیت تکرار: حداکثر ۲۰ تا ۲۵ تکرار برای هر وظیفه جهت محدود کردن حلقه‌های فرار.
• سقف هزینه: یک سقف مالی سخت (مثلاً ۲ تا ۳ دلار برای هر تسک)، زیرا هزینه قابل‌اعتمادترین سیگنال برای توقف است.
• تلاش مجدد تجزیه (Parsing): حداکثر ۳ تلاش برای خروجی‌های بدشکل پیش از توقف کامل (Hard-abort).
• آستانه زمان پایان (Timeout): ۵ مورد متوالی منجر به توقف سخت می‌شود.

همچنین سرریز شدن بستر متن (Context Overflow) باید در صورتی که بودجه به حدود ۸۰٪ رسید، باعث تحریک «فشرده‌سازی» (Compaction) شود تا از خطاهای سخت ۴۰۰ جلوگیری شود. تحقیقات آنتروپیک نشان می‌دهد که میزان استفاده از توکن‌ها به تنهایی حدود ۸۰٪ از تغییرات عملکرد در وظایف دشوار وب‌گردی را توضیح می‌دهد.

حل «مالیات سازمانی»

انتقال از یک پروژه آزمایشی (Pilot) به یک سازمان ۵۰-هزار نفره نیازمند حل مسئله جداسازی سخت (Hard Isolation) است. این راهنما الزام می‌کند که چندماندگی (Multi-tenancy) در سطح پایگاه داده پیاده شود — یعنی استفاده از امنیت سطح ردیف در پستگرس (Postgres RLS) یا عبارت‌های شرطی سخت‌گیرانه tenant_id در WHERE — و نباید صرفاً به بررسی‌ها در سطح برنامه اکتفا کرد.

امنیت در اینجا بر محور شکستن «تک‌سه‌گانه مرگبار» است: ترکیب ورودی‌های نامعتبر، دسترسی به داده‌های خصوصی و وجود راهی برای خروج (Exfiltrate) آن داده‌ها. راهنما استدلال می‌کند که حفاظ‌های مبتنی بر تشخیص (Detection-based guardrails) کافی نیستند، زیرا مهاجمان تطبیق‌پذیر می‌توانند با موفقیت بیش از ۹۰٪ آن‌ها را دور بزنند.

پژوهشی از Anthropic، OpenAI و Google DeepMind در سال ۲۰۲۵ با عنوان The Attacker Moves Second نشان داد که تیم‌های قرمز انسانی تقریباً به ۱۰۰٪ موفقیت در برابر دفاع‌هایی دست یافتند که پیش‌تر به عنوان «امن» گزارش شده بودند.

پاسخ به این تهدید، اجرای فیزیکی شکستن یکی از پاهای این تک‌سه‌گانه است. این موضوع از طریق «قانون دو» (Meta, 2025) عملیاتی می‌شود: یک اجرای بدون نظارت باید در هر بار، حداکثر دو مورد از سه مورد زیر را داشته باشد: {پردازش ورودی نامعتبر، دسترسی به داده‌ها/سیستم‌های خصوصی، یا توانایی تغییر وضعیت و ارتباط خارجی}. اگر یک جریان کاری به هر سه نیاز داشته باشد، باید حتماً یک گیت تأیید انسانی (Human Approval Gate) در میان قرار گیرد.

دفاع در عمق و حاکمیت

برای ایمن‌سازی کامل عامل، یک استراتژی دفاع شش‌لایه (مشابه آنچه در ZeroClaw و GoClaw دیده می‌شود) توصیه می‌شود:

• لایه کانال: لیست‌های مجاز (Allowlists) برای کاربران، چت‌ها یا IPهای خاص پیش از رسیدن ورودی به حلقه.
• لایه خودمختاری: حالت‌های کلی (فقط خواندنی، نظارت‌شده، کامل) همراه با باز definitionهای اختصاصی برای هر ابزار.
• لایه فضای کاری: استفاده از پرچم‌های workspace_only=true و تحلیل Symlink برای جلوگیری از حملات پیمایش دایرکتوری (Directory Traversal).
• لایه فرمان: لیست‌های مجاز/ممنوع برای Shell و تطبیق الگو (Pattern Matching) برای لوله‌های (Pipes) خطرناک.
• لایه سندباکس: جداسازی سیستم‌عامل با استفاده از Landlock، Bubblewrap، Seatbelt یا Docker/microVMها برای هر مستاجر.
• لایه حسابرسی: رسیدهای ابزاری غیرقابل تغییر با استفاده از HMACهای مربوط به جلسه، آرگومان‌ها و برچسب‌های زمانی.

در مورد انطباق قانونی، الزامات معمولاً شامل SOC 2 Type II، ISO 27001، GDPR/CCPA و قوانین بخش‌های خاص مانند HIPAA، PCI-DSS و FINRA است. برای قانون هوش مصنوعی اتحادیه اروپا (EU AI Act)، ارائه‌دهندگان باید توجه داشته باشند که تعهدات شفافیت GPAI و جریمه‌های مربوط به آن از ۲ آگوست ۲۰۲۶ لازم‌الاجرا می‌شوند.

ابزارها و استاندارد MCP

پروتکل زمینه مدل (MCP) به عنوان «USB-C دنیای هوش مصنوعی» ظهور کرده است تا راهی استاندارد برای اتصال عامل‌ها به داده‌های سازمانی فراهم کند. برای جلوگیری از «مسمومیت زنجیره تأمین» (Supply-chain poisoning) ناشی از سرورهای شخص ثالث تأییدنشده، استفاده از یک کاتالوگ MCP بازبینی‌شده — شامل Registry رسمی MCP که در سپتامبر ۲۰۲۵ raunch شد — توصیه می‌شود. استقرارهای سازمانی MCP اکنون OAuth 2.1 / OpenID Connect و اعتبارسنجی صادرکننده (iss) مطابق RFC 9207 را برای جلوگیری از حملات Mix-up الزامی می‌دانند.

ابزارهای مؤثر باید «ضدخطا» (Poka-yoke) طراحی شوند. برای مثال، SWE-agent با اجبار به استفاده از مسیرهای مطلق (Absolute Paths) پس از آنکه مدل با مسیرهای نسبی شکست خورد، قابلیت اطمینان خود را افزایش داد. راهنما تأکید می‌کند که استفاده از ابزار باید از یک اصل تغییرناپذیر پیروی کند: هر tool_use باید پیش از فراخوان بعدی مدل، یک tool_result جفت‌شده داشته باشد. در صورت لغو یا خطا، یک نتیجه مصنوعی (مثلاً "Cancelled: Bash(mkdir) errored") باید صادر شود.

استراتژی‌های ابزارمند عبارتند از:

• فراخوانی‌های ادغام‌شده: یک ابزار واحد schedule_event (برای یافتن و رزرو هم‌زمان) برتر از سه فراخوان جداگانه است و توکن‌ها و خطاهای رفت‌وبرگشت را کاهش می‌دهد.
• افشای تدریجی: به جای بارگذاری صدها طرح‌واره (Schema) ابزار در پرامپت، عامل باید تنها تعاریف مرتبط را در هر درخواست کشف و بارگذاری کند. آنتروپیک گزارش داده که این رویکرد باعث افزایش قابل‌توجه نرخ «باید-فراخوان» (Should-call rates) می‌شود.
• خروجی‌های معنایی: بازگرداندن داده‌های معنایی مانند name و image_url به جای داده‌های نویزی مانند uuid یا 256px_image_url.
• کتابخانه‌های مهارت: دارایی‌های بادوامی که به صورت فایل‌های SKILL.md (شامل YAML frontmatter و دستورالعمل‌های مارک‌داون) ذخیره می‌شوند و عامل می‌تواند پس از حل مسائل سخت، آن‌ها را بنویسد و به‌روز کند (مانند Hermes و Multica).

مهندسی زمینه و اقتصاد توکن

در کارهای عامل‌محور، توکن‌های ورودی معمولاً ۹۰٪ صورت‌حساب را تشکیل می‌دهند. برای مقابله با این موضوع، راهنما مفهوم «پایداری حافظه پنهان» (Cache Stability) را معرفی می‌کند. با ثابت نگه داشتن پرامپت سیستمی و طرح‌های ابزار به عنوان یک پیشوند بایت-پایدار، توسعه‌دهندگان می‌توانند ۹۹.۹٪ پیشوند را با قیمت ۰.۱ برابر قیمت پایه سرویس دهند. بزرگ‌ترین اشتباه رایج، تخریب این کش با ویرایش پرامپت در میانه جلسه است.

مدیریت حافظه در سه سطح انجام می‌شود:

• L0 حافظه کاری: رویدادهای جلسه جاری در بستر متن (فقط-افزودنی).
• L1 حافظه اپیزودیک: خلاصه‌های جلسه با ماندگاری حدود ۹۰ روزه که از طریق ابزارهای memory_search دسترسی پیدا می‌کنند.
• L2 حافظه معنایی: موجودیت‌های گراف دانش برای داده‌های رابطه‌ای (مانند چارت‌های سازمانی یا وابستگی‌ها) که از طریق ابزارهای memory_expand دسترسی می‌یابند.

برای بازیابی، ترکیب جست‌وجوی برداری، کلمات کلیدی (BM25) و بازرتبه‌بندی (Reranking) برای اسناد عمومی توصیه می‌شود. Graph-RAG باید تنها برای پرسش‌های رابطه‌ای (مثلاً «چه کسی مالک سرویس‌هایی است که به X وابسته هستند؟») رزرو شود. برای مدیریت زمینه، توصیه می‌شود وقتی بودجه به ۸۰٪ رسید، فشرده‌سازی آغاز شود؛ به طوری که ۷۰٪ قدیمی‌ترین بخش‌ها در یک چک‌پوینت تایپ‌شده خلاصه شوند و ۴ تا ۱۲ پیام اخیر به صورت کلمه به کلمه باقی بمانند. خروجی‌های حجیم ابزاری باید به فایل‌های فضای کاری منتقل شده و از طریق مسیر (Path) ارجاع داده شوند تا پرامپت سبک بماند.

قابلیت اطمینان و طبقه‌بندی شکست‌ها

آنتروپیک هشدار می‌دهد: «در سیستم‌های عامل‌محور، مسائل جزئی که در نرم‌افزارهای سنتی بدیهی هستند، می‌توانند کل مسیر یک عامل را منحرف کنند». قابلیت اطمینان نیازمند طبقه‌بندی شکست‌ها پیش از تلاش مجدد است:

• محدودیت نرخ پاسخ: تلاش مجدد با تأخیر نمایی و Jitter.
• جریان‌های بدشکل: حذف پاکیزه در میانه جریان و پرس‌وجوی مجدد (حداکثر ۳ بار).
• توقف‌ها (Stalls): اگر پس از K قدم هیچ تغییر خالصی رخ نداد، زمان پایان فعال شده و الگو شکسته شود.
• خطاهای دائمی: خطاهای احراز هویت یا درخواست‌های نادرست باید فوراً به انسان ارجاع شوند و در حلقه نمانند.

برای جلوگیری از شروع مجدد هزینه‌بر، اجرای بادوام (Durable Execution) توصیه می‌شود تا وضعیت در پایگاه داده یا git worktree ذخیره شود. این امکان را فراهم می‌کند تا دستورات --continue تاریخچه را بارگذاری کرده و از آخرین گام موفق ادامه دهند. استقرار به‌روزرسانی‌ها نیز باید به صورت «استقرار رنگین‌کمان» (Rainbow Deployments) باشد تا نسخه‌های قدیمی و جدید هم‌زمان اجرا شوند و عامل‌های فعال در میانه یک تسک طولانی قطع نشوند.

توپولوژی‌های مقیاس‌دهی و استقرار

مقیاس‌دهی باید با تبدیل اجرای عامل‌ها به کارهای ناهمگام در یک صف بادوام (مانند SQS، NATS یا Temporal) به جای رشته‌های درخواست هم‌گام صورت گیرد. این کار اجازه می‌دهد تعداد ورکرها بر اساس عمق صف — که تنها سیگنال قابل اعتماد در کارهای I/O-bound است — مقیاس یابد. برای جلوگیری از تداخل تاریخچه (History Races)، سیستم از مدل قفل‌گذاری «سریال در هر جلسه / هم‌زمان بین جلسات» استفاده می‌کند که کلید جلسه (session_key) را به پارتیشن‌های خاصی هش می‌کند.

سازمان‌ها می‌توانند از چهار توپولوژی استقرار استفاده کنند:

۱. SaaS چندمستاجری: کمترین هزینه، جایی که مستاجران برش‌های منطقی هستند و سهمیه‌های ارائه‌دهنده مشترک است.
۲. SaaS تک‌مستاجری: پشته‌های اختصاصی با پایگاه داده‌های مجزا و استخرهای سندباکس برای جلوگیری از اثر «همسایه پرصدا».
۳. میزبانی شخصی/BYOC: اقامت کامل داده‌ها در VPC مشتری؛ شما یک ایمیج OCI امضا شده و Helm chart ارسال می‌کنید.
۴. ترکیبی: صفحه کنترل میزبانی‌شده (احراز هویت، صورت‌حساب، کاتالوگ‌ها) در کنار صفحه داده خصوصی (زمان اجرا، سندباکس‌ها، حافظه) در VPC مشتری.

زیرساخت برای مقیاس افقی

برای مدیریت هزاران جلسه هم‌زمان، صفحه داده باید بهینه شود. این شامل استفاده از PgBouncer برای جلوگیری از فشار به Postgres و انتقال آرتیفکت‌های حجیم به object storage است.

از آنجا که سقف‌های TPM/RPM ارائه‌دهندگان اغلب گلوگاه واقعی هستند، راهنما محدودیت نرخ توکن-باکت (Token-bucket rate limiting) در صفحه کنترل را برای هر مستاجر توصیه می‌کند. همچنین استفاده از Failover بین ارائه‌دهندگان (مثلاً از Anthropic native $
ightarrow$ Bedrock $
ightarrow$ Vertex) به عنوان اهرم افزایش ظرفیت برای ضرب کردن TPM موثر پیشنهاد می‌شود. کارهای غیرتعاملی مانند فشرده‌سازی حافظه باید به لایه‌های ارزان‌تر Batch منتقل شوند تا با جلسات زنده رقابت نکنند.

مسیر رسیدن به تولید

پذیرش این سیستم‌ها باید در پنج مرحله رخ دهد تا تلاش مهندسی با مرحله فعلی مطابقت داشته باشد:

• مرحله ۰ (نمونه اولیه): ۱ تیم/مورد کاربردی. تمرکز بر APIهای خام و یک مجموعه ارزیابی ۲۰ موردی.
• مرحله ۱ (پایلوت): ۱ دپارتمان. تمرکز بر بودجه‌ها، سندباکس‌ها، لاگ‌های حسابرسی و نظارت انسانی (HITL).
• مرحله ۲ (تولید): ۱ سازمان. تمرکز بر چندماندگی، استقرار رنگین‌کمان و سقف‌های هزینه.
• مرحله ۳ (پلتفرم): بسیاری از تیم‌ها. تمرکز بر کاتالوگ مشترک MCP و کتابخانه مهارت‌ها.
• مرحله ۴ (سطح سازمان): کل شرکت. تمرکز بر SOC2/ISO، تعیین منطقه داده (Region Pinning) و ایجاد تیم AgentOps.

گیت‌های حیاتی برای «راه‌اندازی نهایی» (Go-Live) عبارتند از:

• لاگ‌های حسابرسی تغییرناپذیر: هر عمل باید به یک کاربر/مستاجر نسبت داده شود.
• رمزهای ذخیره شده در Vault: رمزها در زمان اجرا تزریق شوند و هرگز توسط مدل دیده نشوند.
• تأییدات انسانی (HITL): تأیید اجباری برای پرداخت‌ها، حذف‌ها یا تغییرات در محیط تولید.
• طبقه‌بندی شکست‌ها: مدیریت متمایز برای محدودیت نرخ (Backoff)، توقف‌ها (شکستن حلقه) و خطاهای دائمی (ارجاع به انسان).
• حاکمیت داده: تضمین‌های تأییدشده «عدم آموزش» (no-train) و محدودیت‌های مستند شده برای نگهداری داده‌ها.

تحلیل‌ها نشان می‌دهد «اثر هارنس» محرک اصلی کارایی است. در یک مطالعه، بهبود ارکستراسیون در حالی که مدل ثابت بود، هزینه‌ها را ۴۱٪ و تأخیر را ۴۴٪ کاهش داد و موفقیت در تسک‌ها را از ۷۸٪ به ۸۱٪ رساند. این ثابت می‌کند مدل یک کالای عمومی (Commodity) است و مزیت رقابتی در مهندسی هارنس نهفته است.

برای توسعه‌دهندگان، این یعنی تغییر تمرکز از «کدام مدل بهتر است» به «چگونه یک حلقه قابل اطمینان‌تر بسازم». اثر ثانویه این روند، ظهور AgentOps است؛ دیسیپلینی جدید در SRE که بر پاسخ به حوادث رفتاری و تشخیص مسیرهای شکست از طریق بازپخش لاگ‌های رویداد تمرکز دارد.

گام بعدی شما

• تحلیل کنید کدام بخش از سیستم شما «تک‌سه‌گانه مرگبار» (ورودی نامعتبر + داده خصوصی + خروجی) را ایجاد کرده و یک گیت تأیید انسانی اضافه کنید.
• اگر از سیستم‌های عامل‌محور استفاده می‌کنید، استراتژی لایه‌بندی حافظه (L0 تا L2) را برای کاهش هزینه‌های توکن پیاده‌سازی کنید.
• بررسی کنید آیا می‌توانید با استفاده از پیشوندهای بایت-پایدار، نرخ命中 کش (Cache Hit) خود را به ۹۹٪ برسانید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.