論文の概要: AOS-Bench: Can LLM Agents Manage Dynamic Workloads?

• arxiv url: http://arxiv.org/abs/2610.33178v2
• Date: Tue, 27 Oct 2026 04:20:10 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-10-28 21:04:31.339583
• Title: AOS-Bench: Can LLM Agents Manage Dynamic Workloads?
• Title（参考訳）: AOS-Bench: LLMエージェントは動的ワークロードを管理することができるか?
• Abstract要約: コーディングエージェントは、一度にひとつのリクエストを処理するものから、ユーザが作業ストリームを渡す永続的なアシスタントとして機能するものへと移行している。 既存のベンチマークでは、各タスクを独立して評価するため、これを測定することはできない。 本稿では,エージェントシステムをワークロードマネージャとして評価するAOS-Benchを紹介する。
• 参考スコア（独自算出の注目度）: 34.49392463658206
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: Coding agents are moving from handling one request at a time to serving as persistent assistants to which users hand a stream of work: a build, a data-processing job and a bug fix may all be pending on the same machine at once. Such an agent must decide when to take on new tasks, how to delegate and overlap them, and how to stay within the machine's CPU and memory. Existing benchmarks cannot measure this, because they evaluate each task in isolation. We introduce AOS-Bench, which evaluates an agent system as a workload manager: verified tasks arrive over time and must be delivered under shared CPU and memory limits, and the same tasks run one at a time serve as a per-system reference. Across five model--harness pairs, isolated task success does not carry over evenly. On heavy workloads every system loses 13 to 23 points. On medium workloads, systems span 11 points in isolated success but 26 points in stream success, and two systems 0.6 points apart in isolation deliver 54\% and 68\% of the same tasks. Execution-policy interventions trace much of this gap to task intake: serial dispatch leaves 73\% of heavy-workload tasks unclaimed. Yet more elaborate management does not necessarily help. A fixed concurrency of two comes within four points of the best agent-managed policy on both medium and heavy workloads, and under every policy median CPU use stays below 30\% of the provisioned cores while tasks wait. These results identify workload management as a distinct capability for agents, and AOS-Bench as a way to measure it.
• Abstract（参考訳）: コーディングエージェントは、一度にひとつのリクエストを処理することから、ユーザが作業ストリームを渡す永続的なアシスタントとして機能する — ビルド、データ処理ジョブ、バグフィックスはすべて、同じマシンで同時に保留される可能性がある。 そのようなエージェントは、いつ新しいタスクを引き受けるか、どのようにデリゲートし、重複するか、マシンのCPUとメモリ内に留まるかを判断する必要がある。 既存のベンチマークでは、各タスクを独立して評価するため、これを測定することはできない。 我々は、エージェントシステムをワークロードマネージャとして評価するAOS-Benchを紹介した: 検証されたタスクは時間とともに到着し、共有CPUとメモリ制限の下で配信されなければならない。 5つのモデル-ハーネスペア、孤立したタスクの成功は均等に行われない。 重いワークロードでは、すべてのシステムが13から23ポイントを失う。 中規模ワークロードでは、システムは分離された成功で11ポイント、ストリーム成功で26ポイント、分離された2つのシステム 0.6ポイントは同じタスクの54セントと68セントを提供する。 実行とポリティクスの介入は、タスクの取り込みにこのギャップの多くを辿る: シリアルディスパッチは、未解決の重負荷タスクの73.5%を残している。 しかし、より精巧なマネジメントは必ずしも役に立たない。 2つの固定並行処理は、中程度のワークロードと重いワークロードの両方において、最高のエージェント管理ポリシの4ポイント以内で、各ポリシの下では、タスクが待機している間に、プロビジョニングされたコアの30%未満のCPU使用が保たれます。 これらの結果は、ワークロード管理をエージェントの別個の能力とみなし、AOS-Benchはそれを測定する方法である。

関連論文リスト

• SkillGLoW: Procedural-Family Skill Consolidation for Self-Improving Agents on Long-Horizon Task Streams [55.90739575113059]
  再利用の欠如は、関連するタスクのクラスタによって共有される解決手順であり、その周りでSkillGLoWを構築している、と我々は主張する。 4つのベンチマーク(数学的推論、端末の自動化、ソフトウェア修復、実施制御)と3つのモデルで、前者は平均17.2ポイント(ハード)を獲得している。
  論文  参考訳（メタデータ） (2026-09-02T07:31:18Z)
• Spine-Branch Coordination for Multi-agent Computer Use [9.350953491372094]
  重要な物理的ボトルネックは、2つのシステムの状態がマージできないことである。 マルチエージェントコンピュータ用Spine-Branch Coordinationを提案する。 タスクを "spine-branch" グラフに分解し,メインタスクフローを連続したVM状態とブランチタスクを並列に実行する。
  論文  参考訳（メタデータ） (2026-08-22T18:48:37Z)
• ClawArena-Team: Benchmarking Subagent Orchestration and Dynamic Workflows in Language-Model Agents [61.184954205350984]
  ClawArena-Teamは、41のマルチターン、マルチモーダル、マルチエージェントシナリオのベンチマークである。 全体的なスコア -- Subagent-Management Score (SMS) -- は、タスクの正しさを最小限のプライマリとモダリティのルーティング因子によって乗算する。
  論文  参考訳（メタデータ） (2026-06-30T06:06:08Z)
• ChainWorld: Composing Long-Horizon Desktop Workloads from Atomic OSWorld Tasks [43.05751848688531]
  ChainWorldは、アトミックOSWorldタスクを長期のデスクトップワークロードに構成する。 単ターン評価では、全てのタスクが1つのプロンプトでまとめられる。 マルチターン評価では、タスクが一度にひとつ明らかにされる。
  論文  参考訳（メタデータ） (2026-06-19T18:00:14Z)
• Multi-Agent Computer Use [72.79887808312706]
  我々はマルチエージェント・コンピュータ・ユース(MACU)システムの評価・構築に向けて進むべきであると論じる。 本稿では、マネージャモデルがコンピュータ使用タスクを有向非巡回グラフ(DAG)として分解する汎用マルチエージェント構成を提案する。 各イテレーションで、マネージャは並列CUAサブエージェントをディスパッチし、DAGの準備ができているフロンティアでノードを実行する。
  論文  参考訳（メタデータ） (2026-06-01T01:29:36Z)
• A Policy-Driven Runtime Layer for Agentic LLM Serving [6.975319765760388]
  マルチエージェント LLM システムはプロダクションワークロードの主流となっているが、サービススタックは構築されなかった。 このシームは、ポイント修正よりもアーキテクチャの変更によって対処されるのが最善である、と私たちは主張する。 5つの実マルチエージェントワークロードの予備的な結果は、+13から+37ppキャッシュヒットレートリフト、12%から29%低い平均TTFT、6%から14%高いスループットを示す。
  論文  参考訳（メタデータ） (2026-05-26T22:38:34Z)
• ClawMark: A Living-World Benchmark for Multi-Turn, Multi-Day, Multimodal Coworker Agents [77.22389710754452]
  マルチターンマルチデイタスクを中心に構築された同僚エージェントのベンチマークであるベンチを紹介する。 現在のリリースには、13のプロのシナリオにわたる100のタスクが含まれており、5つのステートフルなサンドボックスサービスに対して実行される。 最強のモデルは75.8の重み付きスコアに達するが、最も厳格なタスク成功率は20.0%に過ぎず、部分的な進歩が一般的であることを示している。
  論文  参考訳（メタデータ） (2026-04-26T16:05:02Z)
• On the Reliability of Computer Use Agents [47.20065484006984]
  コンピュータ利用エージェントの信頼性の低下の原因を3つの要因から検討する。 信頼性は、タスクの指定方法と、エージェントの動作が実行毎に変化する方法の両方に依存します。
  論文  参考訳（メタデータ） (2026-04-20T05:59:04Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。