OpenHands: پلتفرم باز برای عامل‌های نرم‌افزاری هوش مصنوعی و معنای آن برای اتوماسیون مالی

من بارها با OpenHands به عنوان لایه زیرساختی زیر مجموعه‌هایی مانند TheAgentCompany، InvestorBench و لیست در حال رشدی از مقالات ارزیابی روبرو شده‌ام — با این حال هنوز مقاله اصلی را نخوانده بودم. این همان زیرساختی است که بقیه فعالان این حوزه در سکوت بر روی آن بنا می‌کنند، بنابراین درک آنچه واقعاً ارائه می‌دهد و نقاط ضعف آن، فراتر از هر نتیجه بنچمارک واحدی که روی آن ساخته شده، اهمیت دارد.

مقاله

OpenHands (Wang et al., 2024; ICLR 2025) یک پلتفرم متن‌باز برای ساخت و ارزیابی عامل‌های LLM است که به عنوان توسعه‌دهندگان نرم‌افزار عمومی عمل می‌کنند. این مقاله که توسط Xingyao Wang و Graham Neubig در یک تیم ۲۴ نفره رهبری شده است، ادعا می‌کند که اکثر فریم‌ورک‌های عامل فعلی یا برای کارهای تحقیقاتی بیش از حد محدود هستند (حلقه‌های وظیفه سخت‌کد شده) یا برای تولید بیش از حد محدودند (متن‌بسته یا تک‌منظوره) و نمی‌توانند به عنوان یک پایه مشترک برای جامعه تحقیقاتی خدمت کنند. OpenHands سعی می‌کند این مشکل را با ارائه یک زمان‌اجرای استاندارد، یک انتزاع تمیز از عامل و ۱۵ بنچمارک ارزیابی یکپارچه تحت یک مخزن با لایسنس MIT حل کند.

زمان‌اجرا (Runtime) یک محیط ایزوله Docker شامل یک Bash Shell، یک سرور Jupyter IPython و یک مرورگر Chromium تحت کنترل Playwright است. عامل‌ها از طریق سه نوع اکشن اصلی تعامل دارند: IPythonRunCellAction برای پایتون، CmdRunAction برای دستورات شل، و BrowserInteractiveAction برای پیمایش وب. یک ابتدایه‌ی هماهنگی چند-عاملی به نام AgentDelegateAction به یک عامل اصلی اجازه می‌دهد تا عامل‌های فرعی تخصصی ایجاد کند. ستون فقرات پیش‌فرض CodeAct است — که در ابتدا به عنوان یک مقاله مستقل منتشر شد و استدلال می‌کرد که کد بهترین فضای اکشن یکپارچه برای عامل‌های LLM است — و پلتفرم چندین پیاده‌سازی عامل از جمله یک CodeActAgent عمومی و یک BrowsingAgent تخصصی را ارائه می‌دهد.

ایده‌های کلیدی

• کد به عنوان فضای اکشن جهانی: CodeAct تمام اکشن‌های عامل (ویرایش فایل، فراخوانی API، تبدیل داده‌ها) را در پایتون یا Bash تجمیع می‌کند و به LLM اجازه می‌دهد در همان رسانه‌ای که به شدت روی آن آموزش دیده، استدلال کند. این کار باعث دور زدن شکنندگی طرحواره‌های JSON می‌شود که عامل‌های فراخوان تابع (Function-calling) را دچار مشکل می‌کند.
• زمان‌اجرای ایزوله Docker: هر عامل در یک کانتینر مجزا اجرا می‌شود، بنابراین عامل‌ها می‌توانند آزادانه کد دلخواه را بدون به خطر انداختن ماشین میزبان اجرا کنند؛ این یک پیش‌نیاز برای هر عامل مالی در محیط تولید است که ممکن است اعتبارنامه‌های واقعی به آن سپرده شود.
• ۱۵ بنچمارک در یک مهار: SWE-Bench Lite (ترمیم کد)، HumanEvalFix (رفع باگ)، WebArena (پیمایش وب)، GPQA (استدلال سطح فارغ‌التحصیلی)، GAIA (حل وظایف عمومی) و ده مورد دیگر. تجمیع این‌ها در یک مکان از ارزیابی‌های گزینشی (Cherry-picked) جلوگیری می‌کند.
• CodeActAgent + claude-3.5-sonnet به امتیاز ۲۶٪ در SWE-Bench Lite و ۷۹.۳٪ در HumanEvalFix دست می‌یابد؛ BrowsingAgent به ۱۵.۵٪ در WebArena می‌رسد — رقابت در سطح Zero-shot بدون هیچ آموزش خاصِ وظیفه.
• عملکرد GAIA: ۳۲.۱٪ با GPTSwarm، که بسیار پایین‌تر از خط پایه ۹۲ درصدی انسانی است — همسو با هر بنچمارک عامل عمومی دیگر که شکاف ۶۰ تا ۷۰ امتیازی بین انسان و عامل را نشان می‌دهد.
• مقیاس جامعه: ۷۱.۴ هزار ستاره در گیت‌هاب و بیش از ۱۸۸ مشارکت‌کننده در زمان ارسال به ICLR؛ TheAgentCompany از OpenHands به عنوان مهار ارزیابی خود استفاده کرد و به آن جایگاه دوفاکتوی زیرساخت بنچمارک را بخشید.

چه چیزی پابرجا می‌ماند — و چه چیزی نه

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

با این حال، پوشش بنچمارک‌ها بیشتر آرمانی است تا سیستماتیک. این ۱۵ بنچمارک انواع وظایف و سطوح دشواری بسیار متفاوتی را بدون یک چارچوب مشخص برای نحوه تجمیع یا مقایسه نتایج در بر می‌گیرند. گزارش ۲۶٪ در SWE-Bench Lite در کنار ۷۹.۳٪ در HumanEvalFix در همان مقاله، این خطر را دارد که این تصور را ایجاد کند که یک عامل به طور همزمان متوسط و عالی است — در حالی که وظایف به سادگی قابل مقایسه نیستند. نویسندگان روش‌شناسی اصولی برای تجمیع بنچمارک‌های چندگانه ارائه نمی‌دهند.

فرض CodeAct — مبنی بر اینکه کد قالب اکشن جهانیِ درستی است — مورد مناقشه است. این روش برای وظایف توسعه خوب عمل می‌کند، اما یک لایه میانجی پایتون/Bash را بر هر اکشنی تحمیل می‌کند که باعث افزایش تأخیر می‌شود و زمانی که معنای اکشن به وضوح به کد نگاشت نمی‌شود (دستورات مبهم کاربر، APIهای صرفاً مبتنی بر زبان طبیعی) با شکست مواجه می‌شود. مقاله در برابر فضاهای اکشن غیر-کد بنچمارک نمی‌گیرد تا ثابت کند این مزیت واقعی است و نه صرفاً ناشی از قدرت مدل LLM زیربنایی.

شاید مهم‌ترین شکاف، شکاف بین ارزیابی و استقرار (Deployment) باشد. عدد ۲۶٪ در SWE-Bench از یک بنچمارک نسبتاً تمیز و با مشخصات دقیق به دست آمده است. گزارش‌های جامعه و رشته‌های مسائل گیت‌هاب به طور مداوم قابلیت اطمینان بسیار پایین‌تری را در وظایف دنیای واقعی مبهم یا طولانی‌مدت توصیف می‌کنند — همان حالت شکستی که TheAgentCompany مستند کرده بود. مقاله به چگونگی اندازه‌گیری یا بهبود استحکام تحت نویزِ مشخصات وظایف واقع‌گرایانه نمی‌پردازد.

چرا این برای هوش مصنوعی مالی مهم است

OpenHands نزدیک‌ترین چیز به یک زیربستر عامل مشترک است که جامعه در اختیار دارد. اگر Bean Labs زیرساخت ارزیابی برای عامل‌های Beancount بسازد، معماری زمان‌اجرا در اینجا — سندباکس Docker، اکشن‌های پایتون/Bash، بک‌اندهای LLM قابل تعویض — به جای بازسازی، ارزش پذیرش دارد. ابتدایه‌ی AgentDelegateAction به طور طبیعی با یک خط لوله عامل مالی نگاشت می‌شود که در آن یک هماهنگ‌کننده سطح بالا وظایف را به عامل‌های فرعی تخصصی واگذار می‌کند: یکی برای خواندن دفتر کل، یکی برای نشانه‌گذاری موارد غیرعادی، و یکی برای پیشنهاد ثبت در دفتر کل (write-back) که یک انسان آن را بازبینی می‌کند.

اعداد SWE-Bench و TheAgentCompany با هم یک پیش‌فرض تأمل‌برانگیز را ایجاد می‌کنند: حتی بهترین عامل‌های موجود، تقریباً ۲۶ تا ۳۰ درصد از وظایف نرم‌افزاری واقع‌گرایانه و بدون ابهام را کامل می‌کنند. اتوماسیون دفتر کل مالی سخت‌تر است — تراکنش‌ها اغلب مبهم هستند، شعاع تخریب خطاها واقعی است و قصد کاربر مکرراً به طور ناقص مشخص می‌شود. استنتاج درست این نیست که عامل‌ها آماده نیستند، بلکه این است که اولین استقرارهای مولد باید گردش‌کارهای «یک‌بار نوشتن» با محدوده دقیق (پیشنهادات دسته‌بندی، نشانه‌گذاری مغایرت‌ها) باشند، نه ویرایش‌های چندمرحله‌ای و خودمختار دفتر کل.

چه چیزی را در ادامه بخوانیم

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — یک مدل ارزان را با یک مدل گران جفت می‌کند و تنها زمانی که عدم قطعیت بالا باشد به مدل گران ارجاع می‌دهد؛ مستقیماً به این موضوع می‌پردازد که یک عامل به سبک OpenHands چگونه باید تصمیم بگیرد که چه زمانی یک ثبت در Beancount را برای بازبینی به انسان ارجاع دهد.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — شامل ۸۰۰ توالی وظیفه با برچسب‌گذاری کارشناسی در ۳۴ سناریوی مالی؛ روش ارزیابی که OpenHands برای استفاده از ابزارهای طولانی‌مدت خاصِ حوزه مالی فاقد آن است.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — ۶۱۳ نمونه در ۶۵ ابزار مالی واقعی MCP؛ مستقیماً با نحوه ارزیابی یک عامل Beancount ساخته شده بر روی زمان‌اجرای OpenHands در یک استقرار واقعی MCP مرتبط است.