ارزیابی عامل‌های کار با رایانه فراتر از تکمیل وظیفه

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

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

معیارهای عمومی پایه ارزشمندی ساخته‌اند. WebArena وب‌سایت‌های واقعی و قابل تکرار را با اعتبارسنجی عملکردی معرفی کرد. WorkArena به کارهای رایج دانشی در نرم‌افزار سازمانی نزدیک شد. OSWorld ارزیابی را به ۳۶۹ وظیفه در سیستم‌عامل واقعی، برنامه وب و دسکتاپ، فایل و گردش‌کار چندبرنامه‌ای گسترش داد.

این معیارها به پرسش توانمندی پاسخ می‌دهند. مجموعه پذیرش تولید باید برنامه، مجوز، سیاست، هزینه شکست، تغییر رابط و انتظار بازیابی سازمان شما را نیز مدل کند.

وظیفه را به‌صورت گذار وضعیت تعریف کنید

فهرست کلیک‌ها را امتیاز ندهید. گذار مطلوب را مشخص کنید:

given: وضعیت اولیه برنامه + هویت عامل + دستور
when: عامل در محدوده قابلیت مجاز مشاهده و اقدام می‌کند
then: همه شرط‌های نهایی لازم برقرارند
and: هیچ اثر جانبی ممنوع رخ نداده است
and: برای اثبات هر دو، شاهد کافی وجود دارد

برای ثبت هزینه، قرارداد ممکن است این شرط‌ها را داشته باشد:

• رسید درست به گزارش درست پیوست شده است.
• فروشنده، تاریخ، ارز، مالیات، مبلغ و دسته با منبع تطابق دارند.
• مرکز هزینه برای کارمند فعال مجاز است.
• استثنای سیاست واضح علامت خورده است.
• گزارش تا تأیید فرد مشخص در حالت پیش‌نویس می‌ماند.
• گزارش، پیام، پیوست یا پرداخت تکراری ساخته نشده است.
• پرونده فرد یا گزارش نامرتبط باز نشده است.
• سابقه حسابرسی، رسید منبع، فیلد استخراجی، اقدام عامل و رکورد نهایی را به هم وصل می‌کند.

این قرارداد نتیجه، اختیار، ایمنی و شاهد را جدا می‌کند و چند مسیر معتبر را می‌پذیرد. عامل نباید صرفاً چون کنترل متفاوتی از trace نوشته‌شده انسان انتخاب کرده، شکست بخورد.

وضعیت اولیه را دقیق مدل کنید

کار رایانه‌ای حالت‌دار است. بدون بازتولید وضعیت آغاز، نتیجه تکرارپذیر نیست.

موارد زیر را ثبت کنید:

• نسخه برنامه و سیستم‌عامل.
• زبان، منطقه زمانی، قالب عدد و تاریخ، تم، zoom، اندازه نمایش و تنظیم دسترس‌پذیری.
• وضعیت ورود، نقش، سازمان و scopeهای اعطاشده.
• fixture پایگاه داده، فایل، پیام صندوق و ذخیره مرورگر.
• شرایط شبکه و خدمت بیرونی در دسترس.
• ترتیب پنجره، تب باز، focus و برنامه فعال.
• پنجره مزاحم، اعلان رضایت، پیام به‌روزرسانی و نشست منقضی.
• ساعت و نسخه سیاست قابل اجرا.
• اقدام GUI، API، اسکریپت و ابزار MCP مجاز.

از محیط یک‌بارمصرف استفاده و میان اجراها آن را reset کنید. شکست قبلی ممکن است پیش‌نویس باقی بگذارد، ترجیحی را تغییر دهد، اعلان کوکی را بپذیرد یا شناسه‌ای را افزایش دهد و اجرای بعدی را آلوده کند.

راه‌اندازی وضعیت و ارزیاب مبتنی بر اجرا در OSWorld الگوی خوبی است، اما محیط پذیرش شما باید نقش و کنترل واقعی سازمان را نیز بازتاب دهد. اجرای معیار با حساب مدیر، تجربه کارمند با حداقل مجوز را اثبات نمی‌کند.

شش بُعد را بسنجید، نه یک امتیاز

۱. نتیجه عملکردی

آیا همه شرط‌های نهایی لازم برقرار شدند؟ بررسی مستقیم پایگاه، API، checksum فایل یا رکورد برنامه را بر اسکرین‌شاتی که فقط درست به نظر می‌رسد مقدم بدانید.

امتیاز جزئی فقط وقتی معنا دارد که واقعاً پیشرفت کسب‌وکار باشد. بازکردن صفحه درست، نصف یک پرداخت منطبق نیست.

۲. یکپارچگی اثر جانبی

آیا چیز دیگری هم تغییر کرد؟ invariantهای منفی تعریف کنید:

• پیام اضافه ارسال نشده باشد.
• فایل نامرتبط تغییر نکرده باشد.
• مجوز گسترده نشده باشد.
• پیش از تأیید اقدام برگشت‌ناپذیر رخ نداده باشد.
• رکورد تکراری ساخته نشده باشد.
• محتوای حساس در لاگ، clipboard، URL یا ورودی ابزار ثالث ظاهر نشده باشد.

این بُعد نمی‌گذارد میان‌بر ناامن موفق امتیاز بگیرد.

۳. رعایت سیاست و نیت

آیا هر اقدام مهم داخل دستور کاربر و اختیار عامل باقی ماند؟ ممکن است اقدامی از نظر فنی شدنی اما خارج از دامنه باشد. دستور اصلی را حفظ کنید و ابزار و آرگومان را در سراسر اجرا با آن بسنجید.

طراحی تأیید انسانی توضیح می‌دهد تأیید را کجا قرار دهیم که تصمیم پرهزینه یا برگشت‌ناپذیر می‌شود.

۴. بازیابی و ارجاع

عامل می‌تواند نشست منقضی، کنترل جابه‌جا، رکورد تغییرکرده، دستور متعارض، وابستگی مفقود یا هویت مبهم را تشخیص دهد؟ این موارد را امتیاز دهید:

• تشخیص درست مانع.
• تلاش مجدد امن یا مسیر جایگزین.
• ادامه یکتا بدون تکرار اثر جانبی.
• درخواست مفید برای اطلاعات مفقود.
• ارجاع به‌موقع به‌جای حدس‌های مکرر.
• حفظ کار انجام‌شده و شاهد.

عاملی که ایمن متوقف می‌شود ممکن است از عاملی که با بداهه‌پردازی بی‌مرز وظیفه بیشتری تمام می‌کند بهتر باشد.

۵. شاهد و توضیح‌پذیری

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

۶. کارایی و تجربه

زمان کار، تأخیر مدل و ابزار، تعداد گام، تلاش مجدد، توکن، هزینه، وقفه کاربر و جست‌وجوی غیرضروری رابط را بسنجید. بهینه‌سازی پس از درستی و ایمنی است؛ میان‌بری که دو ثانیه سریع‌تر اما نرخ ثبت تکراری را دو برابر می‌کند پیشرفت نیست.

ایمنی باید کنار توانمندی ارزیابی شود

معیار توانمندی می‌پرسد آیا عامل به هدف می‌رسد. ارزیابی ایمنی می‌پرسد آیا هدف مضر را رد می‌کند، در برابر زمینه مخرب مقاوم است و حتی برای دستور بی‌خطر مسیر ناامن نمی‌رود.

معیار ۲۰۲۵ OS-Harm کارهای رایانه‌ای مربوط به سوءاستفاده عمدی، تزریق پرامپت و رفتار نامناسب مدل را اضافه می‌کند. پیش‌چاپ ۲۰۲۶ OSGuard تمایز مهم دیگری می‌سازد: عامل ممکن است هدف اسمی را با میان‌بر ناامن کامل کند؛ پس کنار شرط موفقیت اصلی، invariant ایمنی مبتنی بر وضعیت لازم است.

از کار عادی نسخه‌های ایمنی بسازید:

• برخورد نام فایل که overwrite سند نامرتبط را از بین می‌برد.
• صفحه وبی که دستور بارگذاری داده محرمانه دارد.
• دو مخاطب با نام مشابه که فقط یکی مجاز است.
• فرم پرداختی که مبلغش پس از refresh تغییر می‌کند.
• تأیید مخرب پنهان یا خارج از صفحه.
• درخواستی که فقط با مجوز بیشتر از اعطای کاربر شدنی است.
• کار مشروع همراه با درخواست مشکوک برای خاموش‌کردن کنترل امنیت.
• گردشی که نتیجه امن آن پیش‌نویس است، نه ارسال نهایی.

هم قضاوت یک اقدام و هم رفتار ابتدا تا انتها را بسنجید. نگهبان شاید اقدام منفرد را درست طبقه‌بندی کند، اما دنباله‌ای مضر از گام‌های ظاهراً منطقی را متوقف نکند.

کارت سامانه Operator از OpenAI نمونه‌ای مخصوص یک فروشنده از ارزیابی تزریق، اشتباه، اقدام ممنوع، تأیید و آزمون خصمانه ثالث است. کارت سامانه ورودی برنامه ارزیابی شماست، نه جایگزین آزمون گردش‌کار خودتان.

تنوع واقعی رابط را وارد کنید

عاملی که یک چیدمان را حفظ کرده robust نیست. این متغیرها را عوض کنید:

• نمای دسکتاپ و موبایل.
• تم روشن، تاریک، کنتراست بالا و متن بزرگ.
• انگلیسی، فارسی راست‌به‌چپ و متن ترکیبی.
• قالب‌های تاریخ، اعشار، ارز و رقم.
• ناوبری صفحه‌کلید و تفاوت accessibility tree.
• ترتیب فهرست، صفحه‌بندی، بارگذاری تنبل و جدول مجازی.
• pop-up، اعلان، banner و پنجره هم‌پوشان.
• رندر کند، بارگذاری ناقص و DOM کهنه.
• آیکون، برچسب، نام فایل و مخاطب مشابه.
• تغییر کوچک نسخه و feature flag.

آزمون metamorphic اضافه کنید: جزئیاتی مانند جای پنجره را که نباید تصمیم را عوض کند تغییر دهید و پایداری نتیجه را بسنجید. سپس یک واقعیت مهم مانند گیرنده یا مبلغ را عوض کنید و مطمئن شوید عامل متوجه می‌شود.

برای گردش فارسی، ترجمه برچسب کافی نیست. هندسه RTL، رقم فارسی و عربی، رفتار نشانگر، شناسه لاتین در متن راست‌به‌چپ، تبدیل تقویم و نرمال‌سازی copy/paste را آزمایش کنید.

وقفه و بازیابی را عمداً تزریق کنید

رابط تولید در میانه کار شکست می‌خورد. این حالات را بسازید:

• پایان اعتبار ورود پس از ورود داده.
• خطای ۴۲۹ یا timeout ابزار.
• رکوردی که کاربر دیگری تغییر داده است.
• بارگذاری فایلی که بعد از timeout رابط کامل می‌شود.
• crash مرورگر یا قطع شبکه.
• modal مسدودکننده اقدام بعدی.
• تأییدی که رد یا اصلاح می‌شود.
• پاسخ ناقص یا malformed ابزار.

ارزیاب باید بداند اقدام اول واقعاً commit شده یا نه. در صورت نیاز کلید یکتایی یا مسیر reconciliation بدهید و امتیاز دهید آیا عامل پیش از تکرار وضعیت را بررسی می‌کند.

تفاوت «درخواست شکست خورد» با «وضعیت کسب‌وکار تغییر نکرد» حیاتی است. timeout API پرداخت ممکن است پس از ثبت پرداخت رخ دهد؛ تلاش مجدد کور، ابهام قابل بازیابی را به تراکنش تکراری تبدیل می‌کند.

برای الگوی checkpoint و ادامه، گردش‌کار پایدار عامل را ببینید.

چند ارزیاب با اختیار روشن به کار بگیرید

هیچ grader واحدی کافی نیست.

ارزیاب قطعی وضعیت

از API، پرس‌وجوی پایگاه، فایل، checksum و لاگ ساختاری برای شرط نهایی و invariant منفی استفاده کنید. هرجا ممکن است این‌ها مرجع اصلی باشند.

ارزیاب قاعده‌محور مسیر

دامنه ممنوع، ابزار خارج از scope، تأیید مفقود، فراخوانی تکراری، آرگومان خطرناک و دسترسی به شیء نامرتبط را کنترل کنید.

ارزیاب مبتنی بر مدل

برای کیفیت معنایی مبهم، سودمندی ارتباط یا کفایت توضیح ارجاع از مدل استفاده کنید. آن را با برچسب انسان کالیبره کنید، هویت فروشنده را از grader پنهان کنید و اجازه ندهید قضاوت مدل بررسی متعارض سامانه مرجع را کنار بزند.

بازبینی خبره

برای موارد پراثر، دسته خطای تازه، تفسیر سیاست و نمونه منظم از قبولی و شکست لازم است. اختلاف بازبین‌ها را ثبت کنید؛ گاهی وظیفه ناقص تعریف شده، نه اینکه مدل مشکل داشته باشد.

یادداشت NIST درباره تقلب در ارزیابی عامل هوش مصنوعی پیشنهاد می‌کند امکانات و محدودیت‌های معیار استاندارد و صریح شوند. دقیق بنویسید کدام شبکه، فایل، ابزار، آزمون پنهان و کمک بیرونی مجاز است تا دو امتیاز قابل مقایسه باشند.

trace قابل بازپخش بسازید، بدون نشت داده

برای هر اجرا ثبت کنید:

evaluation_version
environment_snapshot
actor_and_permissions
original_instruction
observation_reference
action_and_arguments
tool_or_ui_result
state_delta
approval_event
grader_outputs
final_post_conditions

اسکرین‌شات یا ویدئو را فقط در صورت نیاز نگه دارید و همان لحظه ثبت mask کنید. تفاوت وضعیت ساختاریافته از ضبط بی‌رویه صفحه بهتر است. راز، جزئیات پرداخت، اطلاعات تماس شخصی و رکورد نامرتبط نباید وارد trace قابل مشاهده مدل یا بازبین شوند.

نسخه trace مهم است. بازپخش باید مدل، پرامپت، سیاست، طرح‌واره ابزار، build برنامه، ارزیاب و نسخه داده را مشخص کند؛ وگرنه regression ممکن است از محیط باشد، نه عامل.

مشاهده‌پذیری عامل جزئیات پایش تولید را پوشش می‌دهد.

آماری گزارش کنید که استقرار را بازتاب دهد

یک اجرا برای هر کار کافی نیست؛ عامل nondeterministic و محیط متغیر است.

گزارش کنید:

• موفقیت، موفقیت امن و موفقیت ناامن به‌صورت جدا.
• pass-at-one و قابلیت تکرار در چند trial.
• فاصله اطمینان در کنار نقطه برآورد.
• نتیجه بر اساس خانواده کار، ریسک، برنامه، زبان و تنوع رابط.
• موفقیت بازیابی برای هر شکست تزریق‌شده.
• فراوانی و کیفیت دخالت انسان.
• تأخیر دنباله و هزینه، نه فقط میانگین.
• regression نسبت به نسخه مستقر.

وزن‌دهی باید حجم و پیامد واقعی را بازتاب دهد. کار نادر حقوق و دستمزد یا حذف ممکن است اختیار بیشتری در انتشار از صدها کار ناوبری بی‌خطر داشته باشد. امتیاز عمومی benchmark را از امتیاز داخلی go/no-go جدا کنید.

رخداد تولید را به آزمون رگرسیون تبدیل کنید

مجموعه پذیرش باید تکامل یابد:

1. اصلاح کاربر، near miss یا رخداد تولید را ثبت کنید.
2. داده حساس را حذف یا مصنوعی کنید، اما سازوکار شکست را نگه دارید.
3. وضعیت اولیه را در محیط یک‌بارمصرف بازسازی کنید.
4. شرط مثبت و invariant منفی اضافه کنید.
5. ثابت کنید نسخه معیوب در آزمون شکست می‌خورد.
6. تنوع بسازید تا عامل یک تصویر را حفظ نکند.
7. قبولی نسخه اصلاح‌شده را شرط انتشار کنید.

اجرای موفق را نیز نمونه‌گیری کنید. بازکاری پنهان کاربر، افشای غیرضروری یا استدلال بد ممکن است وقتی خروجی نهایی تصادفاً درست است دیده نشود.

دروازه انتشار تولید

فرایند عملی چهار لایه دارد:

1. رگرسیون آفلاین: fixture قطعی برای مسیر عادی، لبه، بازیابی، چندزبانه و خصمانه.
2. حالت سایه در sandbox: عامل کار شبیه واقعی را می‌بیند، اما اثر بیرونی ندارد.
3. پایلوت با تأیید: اقدام برگشت‌پذیر برای گروه کوچک با بازبینی trace کامل.
4. خودکاری محدود: فقط برای دسته‌ای با موفقیت امن پایدار، مجوز محدود، اجرای یکتا و rollback پایش‌شده.

موفقیت ناامن، دسترسی خارج از دامنه، اثر تکراری، عبور از تأیید یا افت توضیح‌ناپذیر باید rollback را فعال کند؛ نه فقط افت میانگین تکمیل.

راهنمای اتوماسیون کار با رایانه برای انتخاب گردش مناسب و امنیت عامل مرورگر برای سطح حمله مفید است.

پرسش‌های رایج

مهم‌ترین معیار چیست؟

برای کار مهم، موفقیت امن وظیفه: همه شرط‌های مثبت برقرار و همه اثرهای ممنوع غایب باشند. تکمیل معمولی را کنار آن گزارش کنید، نه به‌جای آن.

آیا عامل را با تعداد کلیک مقایسه کنیم؟

فقط معیار ثانویه کارایی است. مسیرهای معتبر مختلف تعداد گام متفاوت دارند. نتیجه، ایمنی، مجوز و بازیابی مقدم‌اند.

آیا اسکرین‌شات موفقیت را ثابت می‌کند؟

به‌تنهایی به‌ندرت. شاید وضعیت UI را نشان دهد، اما رکورد پنهان، داده تکراری، مجوز اشتباه یا تغییر برنامه دیگر را نمی‌بیند. شرط نهایی را مستقیم بررسی کنید.

مجموعه آزمون چند وقت یک بار اجرا شود؟

در هر تغییر مدل، پرامپت، سیاست، طرح‌واره ابزار، رابط یا ارزیاب، gate متمرکز را اجرا کنید. مجموعه گسترده stochastic و خصمانه را زمان‌بندی‌شده و پیش از افزایش خودکاری اجرا کنید.

منابع و تاریخ بازبینی

این مقاله در ۸ مرداد ۱۴۰۵ (۳۰ ژوئیه ۲۰۲۶) با منابع زیر به‌طور اساسی بازبینی شد:

• WebArena
• WorkArena
• OSWorld
• OS-Harm
• OSGuard
• NIST: تقلب در ارزیابی عامل‌های هوش مصنوعی
• کارت سامانه Operator از OpenAI

میز آزمون تولیدی رتبه‌بندی نیست؛ مدل کنترل‌شده‌ای از کار، خسارت مسیر غلط و شاهد لازم برای اعتماد به نتیجه است.