この実験の発想はとてもシンプルです。もし単一の意図をAgentに実行させるのが問題なくできるなら、互いに衝突し得る複数の意図を同時に入れた場合、Newtonはどう処理するのだろうか？私のテスト用の組み合わせは次のとおりです——
意図A：「ETHが2900を下回ったら、2000 USDCでETHを買う。」
意図B：「私のETH保有の総時価が5000 USDCを超えたら、10%を売却してUSDCに換え、これを貯蓄プールに入れる。」
意図C：「AaveにおけるETHの預金利率が3%を超えたら、ウォレット内のすべての余剰ETHをAaveに預ける。」
この3つの意図はいずれも単独で見ると非常に合理的です。しかし、ETHの価格が2950から2890へ下落している最中に、Aが先に発火し、ETHを買い入れることで保有の時価が直ちに5000を超えてしまいます。するとBが発火し、10%を売却します。ところがBがETHをUSDCに換えた直後、Cは金利条件も同時に満たしたため、「保有している余剰のすべてのETH」をAaveに預けようとします——しかし、この時点では財布内のETHの一部がBによって売却中で、さらに一部はpendingの可能性があります。3つの意図が同一の時間枠の中で互いに資産を奪い合うため、オンチェーン上の競合が発生し、3つの取引はいずれも失敗し、しかもかなりのGasを消費してしまいました。
事後の振り返りとして言うと、これは所謂「並行の競合（コンカレンシー競合）」という技術用語で済ませられる話ではありません。Newtonが現時点で、意図間の状態管理にグローバルな視点を欠いていることを露呈しています。各意図は、孤立したユニットとしてAgentに解析・実行されており、複数の稼働中の意図が時間軸上でどのように相互干渉するかをシミュレートする全局のマネージャが存在しません。これは、単一ユーザー・単一意図のシーンでは問題ありません。しかし、ユーザーが複数の自動戦略を搭載することを想定した将来版では、これは体系的な欠陥になります。
Newtonのチームは遅かれ早かれこの問題に直面すると思います。なぜなら、「多意図の並列」が意図経済の中核となる体験だからです。誰も、1つの自動バックアップ用ロボットに満足するだけではありません。ユーザーが欲しいのは、財布全体の自動化された管理です。ですが、複数の意図が共存するとなると、リソースロックと優先度の裁定メカニズムを導入しない限り、意図同士が「飢餓ゲーム」モードに入ってしまいます。先にGasを奪った者が走り、残りはめちゃくちゃで後始末が一帯に散らばる——そんな状態になります。
この問題の解法は、コードを1行増やすだけでは到底済みません。NewtonはAgent層の上に、さらに抽象化された「意図の執事」層を設ける必要があります。そこで行うのは主に4つです。1つ目は、新しい意図が作成されたときに衝突の事前検査を行うこと。2つ目は、各意図に優先度を設定すること（ユーザーが調整可能）。3つ目は、現在の稼働中の意図が将来の可能なシーンでどう連動し得るかをシミュレーションすること。4つ目は、意図の衝突が起きた際に関係する意図を一時停止し、ユーザーに裁定を促すことです。自動的にどれかを選ぶのではなく、必ずユーザーの判断が入るようにします。作業量は小さくありませんが、「意図の実行ツール」から「意図の資産管理プラットフォーム」へ進化するための必須の関門です。$BTC
公式が多意図の衝突処理メカニズムを提示する前に、まずはNewtonをシングルスレッドのツールとして使うことをおすすめします。つまり、一度に1本の意図だけを実行し、完了後に状態を確認してから次の意図へ進む。積み重ね（スタッキング）戦略は魅力的ですが、混乱の中でのGasのロスや意図しない露出（予期せぬリスク）が、先に小さくない授業料として請求されることになります。