OpenManusのコア作者が共有：3時間でAgentフレームワークを完成させる方法！

エージェント（知的身体）技術は今週、かつてない勢いで技術界を席巻しているが、このブームの背景には、推論モデリング能力の飛躍的進歩がある。

月5日夜、マヌスはパワフルなデモで鮮烈なデビューを飾り、瞬く間にインターネットを炎上させた。そのわずか2日後、国内チームDeepWisdomは メタGPT とCAMEL AIはそれぞれ、オープンソースプロジェクトOpenManusとOWLを立ち上げ、迅速にその複製を作成した。 マヌス のコア機能は再びウェブとGitHubコミュニティに火をつけ、広く深い議論を巻き起こした。

特に注目すべきは、MetaGPTが長年培ってきた技術的バックグラウンドを持つOpenManusチームが、わずか1時間で基幹システムの構築を完了し、わずか3時間でプロジェクトをオンライン化したことだ。この驚異的なスピードにより、OpenManusはGitHubで10,000以上のスターを獲得しただけでなく、業界内外の注目を集めることになった。

3月8日の午前中、JQFはOpenManusチームの3人のコアメンバーを招き、OpenManusの技術的実装の原則を分析し、エージェント技術の将来の開発動向について議論することを目的とした詳細な共有セッションを行いました。

MetaGPT論文（ICLR 2024 Oral）とData Interpreter論文の筆頭著者であり、AFLOW論文（ICLR 2025 Oral）の著者の一人であるSiren Hong氏の研究成果は、TPAMIやICLRなどのトップ国際学会で何度も発表されている、彼の研究成果は、TPAMI、ICLRなどのトップ国際会議や学術誌に掲載されている。リャン・シンビン、OpenManusのコア開発者。OpenManusの共著者であり、AFlowとSPOの筆頭著者。

3人のゲストは、エージェント・テクノロジーの今後の方向性と業界が直面する課題について、次のような前向きな考えを披露した：

• 大規模言語モデル(LLM)の能力が向上し続けるにつれて、エージェント・アプリケーションの成功率は、多くのドメイン、特にQAクイズ、HumanEvalコード習熟度評価、MBPP Pythonプログラミング問題のような比較的標準化されたタスクにおいて、単一のモデルが優れた解答能力を実証した場合に飛躍的に向上するでしょう。
• しかし、複雑な機械学習タスク、コードのバグ修正、ユーザーに効果的な回答を提供するために複数の情報を統合する必要がある検索組み合わせ問題など、複雑でロングテール効果を持つ実世界の問題は数多く存在する。これらの問題は、エージェントのパフォーマンスを向上させるために、特にモデルの「錯覚」問題を解決するために、依然として大きな技術革新を必要としている。
• タスクプランニング能力におけるエージェントの進歩は、モデル自身の能力の向上と外部アーキテクチャの支援の両方に依存する。より洗練されたアーキテクチャ設計は、エージェントが複雑なタスクをよりよく理解し、分解するのに役立ちます。
• エージェントが利用できるツールの種類が増えるにつれ、エージェントが同じタスクに直面したときに、同じような機能を持つ多数のツールから的確な判断を下し、最も適切なツールを選択し、誤った選択を回避できるようにすることが、新たな技術的課題となる。
• エージェントのメモリ管理の核となる問題は、コストと効率のバランスをどうとるかである。完全なメモリ情報を直接使用することは、現在のモデルで扱うことができるものの、処理時間とコストの大幅な増加につながり、パフォーマンスの低下というよりも、ユーザーエクスペリエンスに深刻な影響を与える。
• 現在、メモリ管理問題を解決する効果的なアプローチは、マルチインテリジェントボディアーキテクチャを採用するか、ツール支援戦略を採用することである。例えば、OpenManusのようなフレームワークは、通常、計画ツールを使用して、タスク計画を事前に生成し、複雑なタスクを複数のサブタスクに分解し、各サブタスク間でメモリを不完全に共有し、タスク実行後にプロセスを要約または圧縮し、計算コストを削減する。
• ベンチマークテストでは、エージェントがタスクを正しく完了したかどうかを明確に判断できますが、実際のアプリケーションシナリオでタスクを完了する際のエージェントの精度や品質を定量的に評価することはまだ困難です。
• エージェントを商品化する鍵は、高度にパーソナライズされた機能の提供を含め、実世界のシナリオにおけるタスクとユーザーニーズを最大限に引き出すことであり、これがエージェントを使い続けるユーザーを惹きつける唯一の方法である。
• 多くのアプリ開発者が積極的に模索している。 トークン 各APIコールで渡される必要のあるコンテキストの長さを最小化し、コストを削減するための、エンジニアリングレベルでのキャッシュメカニズムやメモリ圧縮技術などの消費最適化スキーム。
• 将来的には、複数の小さなモデルの能力を統合することで、大きなモデルに匹敵する、あるいはそれを凌駕する結果を達成し、推論速度、トークン消費量、コストにおいて大きな優位性を獲得することが期待される。

以下、このシェアリングの内容について詳しく説明する。

01 一晩でGitHubをヒットさせた、オープンマーナスのテクニカル・ファストレーン

梁心冰："3月6日のグループミーティングの後、午後5時過ぎに翔金宇が、いくつかの重要なステップを踏めば、マヌスでの効果を再現できるかもしれないと提案した。"

オープンマナス・プロジェクトを始めるきっかけを振り返り、梁信炳氏は次のように語った。「マナスのデモビデオを初めて見たとき、そのスムーズなインタラクション体験に感銘を受けた。マナスのデモ映像を初めて見たとき、彼は映像の中のスムーズなインタラクション体験に感銘を受け、直感的にマナスは単一知性体システムであるべきだと判断した。 「単一の知性体がどのようにしてこのような優れた結果を達成し、どのようにしてタスクを計画し実現するのか？これは私にとって非常に衝撃的なことです"

その後の会話の中で、チームは、印象的なユーザー体験を持つ汎用AIスマートボディ製品であるマヌスの技術的ソリューションを探求し始めた。しかし、技術的な観点から見ると、マヌスは実際には、業界で合意されている多くの中核的な基本技術を巧みに統合したものである。最終的にチームは、マヌスには複数のインテリジェンスの作業を調整するための外部計画メカニズムが採用されていると推論した。

夕食後、オープンマーナスの開発は正式に開始され、その全工程は約3時間で終了した。 "その時は、OpenManusがこんなに早く人気になるとは予想していませんでした。" とLiang Xinbingは認める。

マヌス・マルチ・インテリジェンス・アーキテクチャーの説明：計画と実行の微妙な相乗効果

Manusの中核は、マルチ・インテリジェンス・システム・アーキテクチャである。プランニングツールPlanningToolを使用したユーザー要件のタスク分解から始まり、複数の線形サブタスクを含む詳細なプランを生成します。その後、システムは各サブタスクを順次実行し、最適なエージェントに動的に割り当てます。 リ・アクト タスクを完了させるためにツールを継続的に呼び出す、循環型（Reason and Act）モデル。

プランニング能力とツール使用能力は、マヌスの2本柱である。 計画ツールPlanningToolをマルチ・インテリジェンス・フレームワークに導入するというManusの革新は非常に重要であった。SWEBenchのコード能力評価でClaude-3.7モデルが躍進したことからも明らかなように、性能の向上はモデル自体の進歩によるところもあれば、より効果的なタスクプランニングによるところもある。MetaGPTチームのData Interpreterプロジェクトでの先行研究は、プランニングが現実世界の複雑な問題を解決するために重要かつ効果的であることを示している。MetaGPTチームのData Interpreterプロジェクトにおけるこれまでの研究でも、現実世界における複雑な問題を解決するためにはプランニングが重要かつ効果的であることが示されています。その結果、プランニング機能をマルチインテリジェンス、さらにはシングルインテリジェンスのフレームワークに統合することが、エージェント技術の開発における重要な方向性となりました。

研究チームは、マヌス氏は次のように推測している。 クロード モデルと、独自のポストトレーニングモデルを組み合わせ、エンジニアリングレベルで多くの最適化を行うことで、さまざまなシナリオでツールを使用する能力を大幅に向上させている。

OpenManusの設計哲学：ミニマリズム、プラグイン性、強力なプランニング機能

OpenManusの設計コンセプトは、"ミニマリスト "と "プラガブル "という2つのキーワードで要約できる。 Liang Xinbing氏によると、最初の設計コンセプトは、プラグイン可能なツールとプロンプトを柔軟に組み合わせることで、エージェントのさまざまな機能を実現する、非常にシンプルなエージェントフレームワークを構築することでした。このアイデアに基づいて、チームはすぐに完全なAgentのミニフレームワークを開発しました。

プロンプトガイダンスとツールの使用は、ReAct エージェントの有効性を決定する重要な要素です。 オープンマナスでは、プロンプトがエージェントの全体的な動作ロジックを制御し、ツールがエージェントのアクションスペースを定義します。ReActエージェントの上に、OpenManusチームはファンクションコール技術に基づく軽量のToolCallエージェントを実装しました。OpenManus は ToolCall エージェント上に構築されています。

開発者は、異なるシナリオのツールを組み合わせて、新しいエージェントを素早く作成することができます。 開発者は異なるシナリオからのツールを自由に組み合わせて新しいエージェントを素早く作成することができます。ツールの定義は非常に簡単で、複雑な内部ロジックを書く必要はなく、エージェントのアクションスペース（ツール）を変更するだけです。豊富なツールセットを提供し、複数のエージェントが異なるツールの組み合わせを柔軟に装備できるようにサポートすることで、OpenManus は様々なアプリケーションシナリオにおいてその機能を容易に拡張することができます。

プランニング機能も重要です。 OpenManusはManusのプランニングの強みをベースに、PlanningToolを通じてタスクの分解を可能にし、実世界の複雑な問題に効果的に対処します。

OpenManusワークフロー: 動的タスク処理と共同実行

オープンマーナスのワークフローは明確で効率的です。ユーザーのリクエストを受け取ると、システムはまずプランニングツールを使って線形サブタスクを含むプランを生成し、プランをマークダウン ファイルに書き込みます。次にOpenManusは計画を解析し、各サブタスクを順番に取り出します。各サブタスクが実行されると、システムはタスクを処理するのに最適なエージェントに動的に割り当てます。

エージェントの動的割り当てはOpenManusのハイライトの1つです。 この柔軟な割り当てメカニズムにより、システムはタスクの特定のニーズとコンテキストに従ってタスクを実行するのに最適なエージェントを選択することができ、タスク処理の効率と品質が向上します。現在、OpenManus は正規表現マッチングを使用してタスクをエージェントに割り当てています。タスクが特定のエージェントにマッチできない場合、デフォルトで設定されたエージェントを使用して実行されます。

将来的には、オープンマーナス・チームはタスクからエージェントへの割り当てを担当する大規模言語モデル（LLM）の導入も検討しています。しかし、タスクの実行ごとにLLMをインテント認識とエージェント割り当てに使用することは、間違いなく計算コストと待ち時間を増加させます。

オープンマーナスの未来：継続的な最適化とコミュニティ構築

OpenManusのパフォーマンスとユーザーエクスペリエンスをさらに向上させるため、チームは以下の優先事項に取り組む予定です：

• プランニング機能の強化：PlanningToolは、より複雑なタスク分解やプランニングシナリオに対応できるよう、継続的に最適化されています。
• 標準化されたレビューの導入：GAIA/TAU-Bench/SWE-Benchなどの業界ベンチマークセットは、オープンマーナスのパフォーマンスを継続的に評価し最適化するために使用されます。
• 拡張モデル適応：クロード-3-5から次のモデルへのサポートを拡張する。 ディープシーク V2.5をはじめとする多くのモデルで、低コストのアプリケーションシナリオを最適化します。
• コンテナ化されたデプロイが可能：OpenManusのインストールと使用が簡素化され、ユーザーの参入障壁が低くなります。
• 豊富なサンプル ライブラリ: ユーザーが OpenManus をよりよく理解し、使用できるように、より実用的な例と、成功と失敗の詳細な分析が追加されました。
• フロントエンドとバックエンドの開発：ユーザーフレンドリーなウェブUIインターフェイスを開発し、ユーザーとのインタラクション体験を向上させる。
• ラグ モジュールの統合：RAG（Retrieval Augmentation Generation）モジュールを統合して、エージェントに外部知識ベースを提供し、知識獲得と推論能力を強化する。

梁信炳氏は、Manusは製品の相互作用において非常に良い仕事をしており、そこから学ぶべきことがたくさんあると述べた。現在、OpenManusの効果はまだ比較的限られており、チームは特別な効果のチューニングを行っていない。

OpenManusの最初の目標は、オリジナルのManusと同じ結果を達成することである。長期的には、チームは大規模なオープンソースコミュニティに依存して、継続的に最適化することを望んでいる。 コンピューター コンピュータの使用、ブラウザの使用、プランニングの使用などのコア機能とツールの呼び出し機能が、オープンマーナスをより高いレベルのインテリジェンス出現へと導く。

02 MetaGPTチーム：数年にわたる技術的降水量、マヌス再現に3時間。

サイレン・ホン："実際、私たちのチームは、オートメーションとAIシナリオのためのインテリジェントなボディフレームワークの分野で長年の技術経験を蓄積してきました。"

MetaGPTチームは、エージェント技術研究とオープンソースに長年取り組んでおり、過去2年間、チームの研究成果をオープンソース化し、質の高い学術論文や技術報告書を作成し、コミュニティに積極的に貢献してきました。これらの成果には以下が含まれます：

• MetaGPT：マルチ・インテリジェント・ボディ・メタプログラミングの先駆的フレームワーク。
• Data Interpreter：データ分析分野におけるLLMの大きな可能性を示す強力なデータサイエンス・エージェント。
• AFlow: エージェントの組み合わせの自動探索と最適化を可能にするエージェントワークフロー自動生成フレームワーク。
• FACT：マルチファクト検索の精度を効果的に向上させるコンテキスト書き換え技術。
• SELA：AutoMLのパフォーマンスを大幅に向上させる、自動機械学習のための木探索拡張LLMエージェント。
• Self-Supervised Prompt Optimization（自己監視型プロンプト最適化）：プロンプトエンジニアリングの効率と効果を向上させる自己監視型プロンプト最適化手法。
• SPO (https://www.modelscope.cn/studios/AI-ModelScope/SPO): オープンソースのキューワード最適化ツールで、サンプル数が少ないシナリオや明示的なスコアリングがないシナリオに対応。
• マルコフLLMテスト時間スケーリングのための思考の原子：マルコフ決定過程におけるLLM推論を強化する思考の原子アプローチ.

MetaGPTフレームワーク：マルチインテリジェンス・コラボレーションの礎石

2023年にオープンソース化されたMetaGPTフレームワークは、多知能体メタプログラミングの分野におけるパイオニアであった。MetaGPTチームは、当時の大規模モデルが汎用的なタスクに対して大きな力を発揮していた一方で、人間社会における複雑な問題を効果的に解決するには、依然として問題を原子論的に解体し、人間の問題解決の習慣に沿ったプロセスを取り入れる必要があると感じていた。

"標準作業手順書（SOP）という概念をご存知でしょうか。SOPを異なる役割に割り当て、各役割の専門知識とツールの能力を活用することで、複雑な問題に対する大規模モデルのパフォーマンスを大幅に向上させることができます。" MetaGPTフレームワークはこのコンセプトに基づいており、SOPを組み込んだマルチインテリジェント体アーキテクチャを提案し、インテリジェンスのメタ学習またはメタプログラミング能力を実現することを目指しています」とサイレン・ホンは説明する。

このアプローチは、HumanEvalやMBPPなどのベンチマークで、当時のGPT-4モデルを上回る大幅な改善を達成し、MetaGPTチームは、古典的な2048ミニゲームやスネークゲームなど、いくつかの典型的なソフトウェア開発シナリオでもこのアイデアを検証しました。MetaGPTの全体的な成功率は、同時期の他のオープンソースフレームワークよりも著しく高い。

データ・インタープリター：データ・サイエンスの知的アシスタント

MetaGPTフレームワークとインテリジェンスの設計に基づき、チームはインテリジェンスにも、特に機械学習やデータモデリングの問題を解く際に、よりロバストなプランニング機能とツールの利用が必要であることに気づいた。

一方では、機械学習／データモデリング・プロセスは、多くの場合、大規模モデルの能力を使って計画することができ、タスクの実行と実装により集中することができる。一方、大規模な表形式データを扱う場合、大規模モデルのコンテキスト長の制限により、すべてのデータを直接入力することは不可能である。そのため、インテリジェンスはコードフォームを通じてデータと対話する必要がある。これらの考察に基づき、MetaGPTチームは、2023年後半にData Interpreterというイノベーションにより、プランニング能力とツール使用能力の探求を開始した。

ある デヴィン このようなプロジェクトが広く注目された時期に、MetaGPTチームはData Interpreterがデータモデリング／機械学習などのタスクにおいて、ジュニア・データアナリストのレベルに達していることを発見した。ユーザーはData Interpreterにデータを渡すだけで、データの前処理からNLP/CVモデルのトレーニングまで、複雑なAIタスクを独立してこなすことができる。

SELA：エージェントのデバッグとフィードバック機能の強化

MetaGPTチームは、Data Interpreterの性能をさらに向上させるため、知能体のデバッグ機能と実験結果のフィードバック機構を強化する必要性を感じていた。SELAでは、モンテカルロ木探索（MCTS）法をData Interpreterの上に導入することで、知的生命体が自律的な実験を通じて機械学習を行うことを可能にする。タスクの最適化を行い、推論プロセスにおける多様性を探索し、実行結果のフィードバックに基づいて戦略と解決ステップを調整することで、タスク全体のパフォーマンスを大幅に向上させる。

SELAによって強化されたData Interpreterの機械学習タスクにおける能力は大幅に向上し、自動機械学習（AutoML）ツールに匹敵するレベルに達し、当時の最高のオープンソースプロジェクト（AIDEなど）を凌駕した。

AFlow: エージェントワークフローの自動生成

一方、MetaGPTチームは、モンテカルロ木探索（MCTS）技術に基づく大規模モデルの推論能力の向上も探求し、AFlow作業を開発した。AFlowは、固定的なSOPを持つソリューションとは異なり、タスクごとに最適なソリューションフローを自動的に探索することができる。

AFlowの革新的な点は、さまざまな問題に対する解決策をいかに改善するかということである。AFlowは、問題からのフィードバックに基づいて、システムがインテリジェンスの最適な組み合わせ（トポロジー）を探索できるようにすることを目指しており、最終的には、問題を解決するためのインテリジェンスの組み合わせを、事前に規模を設定する必要なく、よりダイナミックなものにすることを目指している。

AFlowは、問題の原子化のための探索空間を定義し、モンテカルロ法を用いることで、複数の知能の組み合わせトポロジーを探索し、最適化する。この研究は、6つのデータセットすべてでSOTA（State-of-the-art）結果を達成し、ICLR 2025のOralに認定されており、技術的リーダーシップの証となっている。

FACT: エージェントのメモリ管理機能の強化

MetaGPTチームはまた、知的体の問題解決ステップ数が増えるにつれて、その記憶（Memory）の容量も増えることに気づいた。そのため、問題解決プロセスを通じて、知的体の文脈情報をいかに効果的に管理するかが喫緊の課題となっている。

この目的のために、研究チームは「FACT」と呼ばれる研究を発表している。この研究は、マルチニードル発見メカニズムを通じて、ファクト発見における大規模モデルの精度を向上させるもので、質問と回答（QA）タスクにおいて重要な結果を示している。この研究はNAACLにも採択されている。

さらに昨年9月頃、MetaGPTチームはSWE-Benchのコード能力評価プラットフォームも調査した。彼らは、コード修復のような問題では、エージェントはファイルの検索や発見、コンピュータの使用能力に依存する必要がある一方で、ツールの使用能力や計画能力にも高い要求があることを発見した。多くの研究努力は、このような複雑な推論プロセスの長い連鎖を解決するために、マルチインテリジェンス・アプローチを使用してきました。その結果、MetaGPTチームは、OpenManusコードの基礎となるSWE-Benchタスクにファイルロケーションとファイル検索機能を追加し、最適化しました。OpenManusのコードを見ると、ツールの多くがコードの修復とロケーションに関連していることがわかります。

SPO：キュー・ワードの最適化のための強力なツール

SPOは、キュー・ワードの最適化のための強力なツール・セットである。大規模なデータセットを必要とする従来の最適化手法とは異なり、SPOは正確な評価が得られない、あるいはデータセットが限られているシナリオに適しています。例えば、Xiaohongshuのコピーを書いたり、SEO最適化を行う場合、ユーザーは満足のいく少数のサンプルしか持っていない可能性があり、SPOはそのような限られたサンプルの条件下で効果的なキューワードの最適化を行うことができます。このツールはオープンソース化され、中国のMagic HitchプラットフォームやHugging Faceでユーザーから高い評価を得ています。

AOT：原子的思考が情報推論を促進する

AOT (Atomic Thinking) アプローチは、主に質問と答えによる情報推論や、読解のための異なる文章からの情報の統合などの統合タスクに使用される。この研究はこれまでに35万ビューを獲得しており、今後MetaGPTフレームワークに統合され、情報処理能力がさらに強化される予定です。

03 エージェントの真の課題：10の核心的課題の解剖

Q1: 大規模なモデリング能力が向上した後、複雑な問題を完全に解決することは可能ですか？

サイレーン・ホン：「大規模なモデルの能力が高まるにつれて、多くの問題を解決する成功率が高まるのは事実ですが、問題そのものがなくなるわけではありません。 例えば、QA Q&A、HumanEval、MBPPのような比較的標準化された単一機能のコード生成問題では、単一のモデルで非常に優れた性能を発揮できるようになりました。

昨年から今年にかけて、これらの問題に対する大規模モデルの成功率は、実社会での応用レベルに近づいている。しかし一方で、機械学習やコード修正、ユーザーに提供するまでに結果の組み合わせを検索する必要がある問題など、ロングテール効果を持つ極めて複雑な問題が、人類社会にはまだ数多く存在していることにも留意する必要がある。これらの分野では、大規模モデルの性能を向上させるための技術革新、特にモデルの「錯覚」問題を解決するための技術革新がまだまだ必要である。

Q2：大規模モデルの能力向上とエージェント技術の進歩の関係は？

エージェントと大規模モデルは、垂直的あるいは直交的な関係にある。フレームワーク自体の強化は、モデル能力の強化によってより多くの機能を得ることになり、両者は対立するものではありません。"

エージェントフレームワークは、より多くのツールで拡張することにより、大規模なモデルが物理的な世界やより広い環境と相互作用することを可能にする。同時に、大規模モデル自体の進歩により、推論と計画の能力が強化される。この2つは、互いに連携して使用することも、独立して開発することもできます。

「この関係は相反するものではなく、補完し合うものだ」。 翔金宇はこう締めくくった。

Q3.ファウンデーション・エージェント・モデルの現在の開発レベルは？

翔金宇："最近、たまたま関連する研究を追っているんですが、正確にはファウンデーション・エージェント・モデルのカテゴリーには属さないかもしれません。"

同氏は、コードベースの修復問題を解決することを目的としたSWE-GYMプロジェクトにおけるPan Jiayi氏のチームの試みについて言及した。彼らは、ClaudeやGPT-4oに基づくモデルを実行した後に生成されるデータを使用し、Openhandsなどのフレームワークの助けを借りてAgent動作中の軌跡データを収集した。軌跡データには成功事例と失敗事例の両方が含まれている。収集した軌跡データをQwenオープンソースモデルの学習に再利用し、この学習後にQwenモデルのコード修復能力が大幅に向上することを確認した。研究の詳細は論文で詳しく説明されており、研究は確かで信頼できるものである。

"この種の作業を一般化することの現在の難しさは、例えばSWE-Benchの評価では、タスクが正しく完了したかどうかを明示的に判断することができるが、実世界の応用シナリオでは、多くの場合（例えば、小説やジョークを書くこと）、タスク完了の正確さや質を定量的に評価することが非常に難しいことである。" Xiang Jinyu氏は次のように指摘する。"実際の仕事のシナリオと同じように、インターンとシニア社員が同時にタスクを完了するよう求められたとき、彼らのパフォーマンスを評定することになると、客観的な判断を下すことは実際には難しく、多くの主観的なビジネスロジックと基準に基づいて決定する必要がある。このようなオープンタスクにおける評価フィードバックの自動設計も、今後の重要な方向性です。"

Q4.エージェントのプランニング能力の進歩は、大規模モデルそのものに大きく依存するのでしょうか？

Xiang Jinyu: "現在のプランニングの進歩は、一方ではモデル自身の能力の向上に依存しており、他方では、外部構造の支援、すなわち、プランニングを支援するためにエージェントのレベルでより複雑な構造を含めることと切り離すことはできない。" 例えば、Tree of Thought（TOT、思考ツリー）に関する初期の研究は、付加的な構造を導入することで、タスク推論中のモデルのパフォーマンスを大幅に向上させた。外部構造補助に関連する同様の研究は、計画領域にも存在する。

Q5.Agentに外部ツールを使うことの難しさは何ですか？

Xinbing Liang：「現在OpenManusでは、Cloud ComputerやBrowserといった既存のオープンソースツールを主に使用しています。Browserの使用に関する他のチームの研究により、これら2つのツールだけでも基本的に多くのタスクを達成できることが分かっており、当初はManusのプロトタイプを形成していました。"

さらに、「エージェントがツールを使いたいが、現在そのようなツールが存在しない場合」という疑問について、Liang氏は、将来的にエージェントが独自のツールを作成する機能を追加する可能性も想定していると述べた。 「Agentがタスクを完了するためにツールを必要とするとき、現在の環境に適切なツールがなければ、Agentは自分でツールを作成して使用することができます。これにより、Agentはさらに力を得ることができます。"

サイレン・ホン：「大規模なモデルやエージェントにツールを使うこと自体は、目新しいことではないと思います。しかし、ツールの数が徐々に増えるにつれて、技術的な困難が生じます。同じような機能を持つツールが大量に存在する場合、エージェントはどのようにして正確な判断を下し、最も適切なツールを選択し、同じタスクを解決する際の判断ミスを避けることができるのでしょうか？"

さらに、標準化されたツールインターフェイスを使用する代わりに、カスタムツールを使用する場合、別の問題に直面する可能性がある：ツールのパラメータが合理的または明確に定義されていないため、大規模なモデルでは、ツールを呼び出す際の決定を生成する際にエラーが発生しやすくなり、その結果、ツールの実装の有効性に影響する。これらは、ツールの使用チェーンにおいて対処すべき重要な問題である。

"もう一つの困難は、ツールの選択と使用そのものだけでなく、多くの詳細情報を含む可能性のあるコンテキストである。例えば、ユーザが複数のウェブページを同時に開いた場合、エージェントがそれらを統合して最終的な結果を生成する際に、これらのページ上の情報やデータ（例えば、特定のCVの時刻や、別のウェブページで言及されているイベントの開始時刻など）が混乱したり、間違っていたりする可能性があります。ツールを使用する際、エージェントがこのような詳細な情報をいかに正確に扱うようにするかは、実用化に向けて注力すべき問題でもあります。" とHong Siruiは付け加えた。

Q6.MCPのようなプロトコルは、ツール使用の主流になるのでしょうか？

リャン・シンビン：「MCPプロトコルは今や主流になりつつある。

道具を使いこなせるかどうかは、実はそのモデル自身に道具を使いこなす能力があるかどうかにかかっている。モデルによっては、ツールを使用する能力を持っていなかったり、この点で弱かったりするため、ツールの使用における有効性は制限される。したがって、ツーリングプロトコルの人気は、モデル自身の強力なツーリング能力と密接に関係している。

Q7.巨大なコンテクスト（メモリ管理）を扱う上で、エージェントの進歩や困難はどのようなものがありますか？

サイレン・ホン："もうすでに、MemoryGPTやオープンソースプロジェクトMem0など、関連する研究成果をご存じかもしれません。"これらはどちらも、より長いコンテキストとAgentのメモリ管理のために、いくつかの最適化と処理を施しています。

例えば、MemoryGPTは一定の長さのコンテキストを要約する。これは非常に平易だが効果的な考え方であり、Mem0はメモリ更新プロセスでツールを積極的に使用する。メモリ削除、メモリ更新、追加といった操作を伴う。

"現在のところ、複雑で長距離のタスク（例えば、情報量が非常に長くなるウェブページの閲覧など）を扱う際に、コンテキストを圧縮してメモリに保存し、圧縮後に重要な情報が変更されたり省略されたりしないようにすることは、エージェントにとって難しい問題である。" サイレン・ホンは、"初期の研究では、時間やタスクのステップによって記憶が薄れていくことが示されている "と指摘する。

一方、人間の記憶にはさまざまなタイプがあり、意味情報の記憶だけでなく、道具を使うことで生まれる手続き記憶や、出来事に関連した関係の記憶もある。学問の世界でも、記憶のタイプ別に最適化が行われてきた。

以上の議論は、単一のエージェントにおけるメモリー管理についてである。しかし、マルチ・インテリジェント・システムでは、記憶をより巧みに利用することができる。ある程度記憶を分離するだけでなく、問題解決の過程で他のエージェントが生成した記憶を再利用して、特定のタスクを処理する際の自分の経験を高めたい。さらに、エージェントはグループの問題解決経験を再利用するように進化し、最終的には一種のグループ知能を形成することができる。

梁信炳："メモリ管理の核心的な問題はコストだ" もしメモリ管理を考慮せず、圧縮やいかなる処理も行わず、完全なメモリを直接使用するのであれば、現在の大規模モデルでも処理は可能だが、これがもたらす問題は性能の低下ではなく、処理時間とコストの大幅な増加であり、ユーザーエクスペリエンスに深刻な影響を与える。

そのため、メモリー管理の問題は、エンジニアリング・レベルでの最適化が必要となる。メモリー管理ソリューションを最適化しようとする企業や組織はすでに数多く存在する。

「メモリ管理問題を解決するための現在のアプローチの1つは、マルチインテリジェンスまたはツール支援型アプローチを使用することである。例えば、OpenManusのようなフレームワークでは、タスクプランは通常、プランニングツールによって最初に生成される。プランニングツールは、複雑なタスクを複数のサブタスクに分解し、各サブタスク間でメモリを不完全に共有し、タスク実行後にプロセスを要約または圧縮する。" とリャン・シンビンは説明した。

Q8.現地での商業化という点で、エージェントは最終的に何と競合するのでしょうか？

サイレン・ホン："最も重要なことは、パーソナライズ機能を含め、実際のシナリオでタスクと効果を最大限に引き出すことだと思います。" SWEBench、GAIA、その他のAgentテストタスクに関わらず、アカデミアにおける現在の研究努力の多くは、まだタスクの成功率が限られています。この比較的小さなタスク基準を実際のビジネスシナリオに適用した場合、異なるユーザや異なる難易度の問題に直面した場合、現在のAgentの成功率はまだかなり限定的です。

"プログラミング作業であれ、データ収集やレポート作成作業であれ、幅広いユーザーの問題やシナリオからベストを引き出し、成功率を満足のいくレベルまで高め、エージェントが今日人々が期待するアクションが可能であることを真に実現できれば、ユーザーはエージェントを日々のアシスタントやツールとして使い続けてくれると確信しています。" と洪思瑞は強調した。

Q9.現在、Manus、OpenManus、その他のエージェントのコストが高い。

サイレン・ホン：「まず第一に、私たちを含む多くのアプリケーション・ベンダーが、トークンの消費を最適化しています。エンジニアリング・レベルでのキャッシングであれ、メモリ圧縮技術であれ、ゴールは各APIコールのコンテキスト長を最小化することであり、それがアプリケーション・レベルでの継続的な最適化の方向性です。"

「さらに将来的には、特定のノードやツールの使用能力を最適化することに重点を置き、既存のデータに基づいて微調整や強化学習を行うために、多数の小型モデルを導入することが考えられる。複数の小型モデルの能力を統合することで、大型モデルを補完、あるいは凌駕することが期待される。これは、推論速度、トークンの消費量、経費の面で大きなコスト優位性につながります。" とSiren Hongは付け加えた。

Q10.マルチインテリジェンスのビジネス的な将来性はどのように評価できるのか？

サイレン・ホン：「まず、コード生成の分野では、シングル・エージェントとマルチ・インテリジェント・ボディ・システムの両方が、かなり早い段階で実用化されると考えています」。

"プログラミングのレベルは平均的だが、基本的なコンセプトは理解している "というユーザーの多くが、個人的なウェブサイトや簡単なアプリケーションを自力で構築しようとする場合、インテリや大型モデルの支援を非常に必要としていることがわかった。ユーザが直接大規模なモデルを使用する場合、何度もやり取りが必要になり、退屈なデバッグプロセスが必要になることがあります。しかし、製品化されたインテリジェンス・システムを使えば、そのプロセスはずっと簡単になる。ユーザーは、その後の要件の変更を含めても、15分から30分程度を費やすだけで、満足のいくウェブサイトやアプリケーションを素早く手に入れることができる。"

「したがって、マルチインテリジェンシアは、ユーザーの実際のニーズを本当に効果的に解決するという点で、明確かつ強力なビジネス展望を持っていると思いますし、コード生成は、Agentテクノロジーが現在よりよく解決できるシナリオでもあります。現時点では、この点に関するユーザーの支払い意欲も比較的高い。" 洪思瑞はこう締めくくった。

04 エージェントの商業化：コード・ジェネレーションが地歩を固める主導権を握る

Q1.マルチインテリジェンス製品であるMGXについて簡単に紹介してください。

サイレーン・ホン：「MetaGPTをご存知の方なら、ご理解いただけると思います。 MGX 複数の知能がオンラインで同時にコラボレーションし、ユーザーの問題解決を手助けする製品だ。ユーザーは次のような使い方をするだけだ。 チャットGPT 要件が入力されるとすぐに、強力なインテリジェンスがタスクを分解し、それを実行するためにさまざまなインテリジェンスに分配する」。

「製品全体は現在、コード生成の分野に集中しています。例えば、ユーザーが個人的なウェブサイト、ゲーム、データ分析アプリケーションなどを作成したい場合、私たちのインテリジェントボディはそのタスクを非常にうまくこなすことができます。開発プロセス中、ユーザーはフロントエンド・プロジェクトのスタイル、タイポグラフィ、レイアウトの調整など、いつでも要件を変更することができます。"このようなことも、私たちの知的体は自然に行うことができるため、開発コストを大幅に削減することができます。

ManusやOpenManusなどの製品とは異なり、MGXには自動デプロイメント機能があります。開発プロセス中、ソフトウェアは自動的にデプロイされ、ユーザーはリアルタイムで結果をプレビューし、調整することができる。さらに、MGX製品の各インテリジェンスには、先に述べたコンピュータツールコール、ブラウザツールコール、プランニングおよびコード実行機能があります。

「将来的には、大規模なモデルやエージェントが、生成されたページやデータ・ダッシュボードがユーザーの期待や美的基準を満たすかどうかを評価できるよう、対応するベンチマークを作成する可能性もあります」。 とホン・シルイは語った。

以下は、MGXが作成したウェブサイトの例です：

個人ウェブサイト

• https://alex-portfolio-yhx5c3-v1.mgx.world/
• https://photographer-portfolio-myuf2t-v1.mgx.world

個人ブログ

• https://personal-blog-v7amdv-v2.mgx.world
• https://cute-cartoon-blog-p58801-v1.mgx.world

個人の名刺：

• https://portfolio-dveerm-v1.mgx.world
• https://emma-anderson-homepage-8rnqm6-v1.mgx.world

Q2. MGX DEVは新しいタイプのAgentのフォローアップをしてくれるのでしょうか？

サイレン・ホン：「MGXは今後も新しいエージェントタイプを追加していきます。現在、User Agentと呼ばれる新しいタイプのインテリジェンスを社内で実験しています。" ユーザーのプロジェクトがデプロイされると、直接実行できなかったり、欠陥があったりして、ページが真っ白になったりすることがあります。User Agentは、ページのスクリーンショットを撮ったり、ウェブページと積極的にインタラクトしたり、生成されたソフトウェアの実現可能性や実行可能性をテストしたりするなど、プロジェクトデプロイの影響を積極的に検出し、さらに、プロジェクトをより完璧に完成させるために、開発を担当する他のインテリジェンスに通知して修正させます。 "さらに、デザインやデータ視覚化の効果を審美的に評価するために、内部でベンチマークを沈殿させることもあります。" エージェントは、ページやデータダッシュボードの品質や審美的なパフォーマンスが期待に応えているかどうかを判断することができます。 とHong Sirenは付け加えた。