تیم openJiuwen مقاله پژوهشی تازهای منتشر کرده که harness عامل کدنویسی را نه یک wrapper ساده دور مدل، بلکه یک لایه مستقل در معماری سیستم میداند. اهمیت کار از اینجا میآید که عملکرد عاملهای long-horizon فقط به مدل وابسته نیست و نحوه مدیریت context، ابزارها، ادامه task، diagnostic، delegation و stopping نیز روی نتیجه اثر میگذارد. مقاله یک execution substrate مشترک برای عامل منفرد، sub-agent و جریانهای چندعاملی تعریف میکند و مخزن JiuwenSwarm نیز مسیر پیادهسازی قابل بازرسی آن را نشان میدهد.
نویسندگان 82.6 درصد روی SWE-bench Verified و 87.19 درصد روی Terminal-Bench 2.1 گزارش میکنند. این اعداد جالباند، اما سؤال مهندسی مهمتر این است که دقیقاً چه چیزی را ثابت میکنند. خود مقاله تأکید میکند که سیستمهای leaderboard از نظر مدل، prompt، ابزار و implementation با هم تفاوت دارند. بنابراین نتیجه مفید این نیست که یک harness قطعاً دیگری را شکست داده، بلکه این است که orchestration حالا بخشی قابل اندازهگیری از کل agent system است و باید جداگانه و کنترلشده ارزیابی شود.
Harness به یک control plane تبدیل میشود
openJiuwen اجرا را به Inner Loop برای تعامل مدل و ابزار و Outer Loop برای ادامه و کنترل سطح task تقسیم میکند. قابلیتهای cross-cutting از طریق مکانیزمی به نام Rail و lifecycle hookهای مرتبشده اضافه میشوند، بهجای اینکه هر capability مسیر اجرایی جداگانهای در core loop بسازد. همین semantics بین عامل منفرد، sub-agent و Swarm Flow بازاستفاده میشود.
این طراحی به یک مسئله واقعی مهندسی پاسخ میدهد. عاملهای کدنویسی امروز planning، memory، context management، security check، human intervention، retry و delegation را با هم دارند. اگر اضافهشدن هر capability هسته execution loop را تغییر دهد، harness بهسرعت پیچیده و سختتست میشود. substrate مشترک میتواند composition را سادهتر کند، ولی همزمان configuration خود harness را به یک سطح کنترلی تبدیل میکند که باید versioning، observability و regression test داشته باشد.
مخزن پروژه نشان میدهد موضوع فقط یک معماری روی کاغذ نیست. JiuwenSwarm قابلیت multi-agent collaboration، workflowهای deterministic با Swarmflow، tool permission، اجرای distributed و Auto Harness برای بهینهسازی harness بدون تغییر وزن مدل را ارائه میکند. مخزن با مجوز Apache-2.0 منتشر شده و قابل نصب است، بنابراین امکان بررسی و reproduction از یک مقاله صرفاً benchmarkمحور بیشتر است.
Runtime adaptivity وضعیت framework را تغییر میدهد، نه وزن مدل را
ایده دوم مقاله runtime adaptivity است. بهجای retrain کردن مدل، openJiuwen state کنترلشده توسط framework را حین اجرای task تغییر میدهد. Context Management اطلاعات قدیمی را compress، reduce یا offload میکند؛ Goal Mode روی acceptance و stopping اثر میگذارد؛ feedback مبتنی بر LSP diagnosticهای semantic را وارد اجرا میکند؛ و Self-Reflection تجربه trajectoryهای قبلی را برای taskهای بعدی نگه میدارد.
این تمایز برای تیمهایی که از مدلهای third-party استفاده میکنند مهم است. بخشی از بهبود long-horizon میتواند از control plane اطراف یک مدل ثابت بیاید، که از نظر iteration سریعتر از fine-tuning است. اما این لایه failure surface جدید هم میسازد. context manager ممکن است evidence مهم را حذف کند، stopping rule ممکن است زود متوقف شود و diagnostic loop ممکن است به static signalهایی بیش از حد وزن بدهد که architecture یا business correctness را پوشش نمیدهند.
در production، بنابراین نباید harness را زیرساخت نامرئی فرض کرد. تست باید retention context، stop condition، permission ابزار، retry behavior و diagnostic injection را نیز کنار خود مدل پوشش دهد.
ادعای benchmark به claim audit نیاز دارد
مقاله گزارش میکند openJiuwen با GPT-5.6 Sol در Terminal-Bench 2.1 به 87.19 درصد میرسد، در حالی که یک نتیجه انتخابشده برای Claude Code برابر 83.8 درصد است. اگر فقط همین اعداد دیده شوند، اختلاف 3.39 percentage point شبیه برتری مستقیم harness به نظر میرسد. اما این یک estimate کنترلشده از اثر harness نیست، چون backbone model متفاوت است و prompt، ابزار و implementation هم میتوانند فرق داشته باشند.
مقاله یک مقایسه مفیدتر با Fable 5 نیز دارد. در مدل یکسان، openJiuwen امتیاز 84.04 درصد و Claude Code امتیاز 83.8 درصد گزارش کردهاند، یعنی فقط 0.24 percentage point اختلاف. نویسندگان خودشان میگویند model matching فقط یک confounder را کاهش میدهد و تفاوت prompt، ابزار و agent implementation همچنان باقی میماند.
در SWE-bench Verified مقایسه کمی تمیزتر است، چون openJiuwen و قویترین نتیجه انتخابشده هر دو Claude 4.5 Opus دارند و امتیازها 82.6 در برابر 79.2 گزارش شده است. با این حال این هم comparison در سطح کل سیستم است، نه ablation کنترلشده از harness. مقاله صریحاً میگوید برای جداکردن contribution مکانیزمهای مختلف به مطالعه و ablation بیشتری نیاز است.
پس شواهد فعلی نشان میدهد openJiuwen بهعنوان یک agent system کامل رقابتی است، اما هنوز ثابت نمیکند Rail، Goal Mode، context adaptation یا هر مکانیزم منفرد علت مستقیم اختلاف benchmark است.
تیمهای مهندسی واقعاً چه چیزی را باید benchmark کنند
یک ارزیابی مفید باید model، reasoning effort، tool set، token budget و environment را تا حد ممکن ثابت نگه دارد و سپس اجزای harness را یکییکی تغییر دهد. در این صورت میتوان دید context adaptation، LSP feedback، stopping logic، reflection یا multi-agent coordination واقعاً چه اثری روی completion rate، latency، cost و reliability دارند.
همچنین failure behavior باید کنار pass rate سنجیده شود. عامل long-horizon میتواند loop شود، constraint را فراموش کند، budget را تمام کند، ابزار را بیش از حد صدا بزند، قبل از رسیدن به acceptance criteria متوقف شود یا context منقضی را حمل کند. این failure modeها مستقیماً به control mechanismهایی مربوطاند که openJiuwen تلاش میکند formalize کند.
نتیجه عملی فراتر از خود این پروژه است. ارزیابی agent دارد به یک discipline تمامپشته تبدیل میشود. وقتی harness تعیین میکند مدل چه چیزی میبیند، چه ابزاری دارد، چه زمانی retry میکند و کجا متوقف میشود، یک model score بهتنهایی کافی نیست. برای ادعاهای مربوط به orchestration، model-matched comparison و harness ablation باید بخشی از standard evaluation باشند.
چرا این مقاله ارزش دنبالکردن دارد
openJiuwen هنوز یک preprint است و evaluation فعلی فقط SWE-bench Verified و Terminal-Bench 2.1 را پوشش میدهد. خود نویسندگان نیز خواهان مطالعههای کنترلشده بیشتر روی benchmarkها، مدلها و configurationهای دیگر هستند. بنابراین فعلاً مبنایی برای ادعای superiority عمومی یا production readiness وجود ندارد.
ارزش خبری کار از ترکیب implementation متنباز قابل بررسی، معماری مشخص harness و benchmarkهایی میآید که میتوان ادعاهایشان را audit کرد. contribution مهمتر این است که runtime control بهعنوان لایهای مهندسی مطرح میشود که مستقل از model weights قابل تغییر است.
برای developer و architect، سؤال دقیقتر این میشود: نه «بهترین coding model کدام است؟»، بلکه «کدام ترکیب model و harness در یک budget و control boundary ثابت، نتیجه قابل اعتمادتر میدهد؟» اجرای چنین benchmarkی سختتر است، اما به رفتار واقعی agent systemهای production نزدیکتر است.