記事一覧

読了 4 分ConceptsReliability

エージェントの受信箱

マシンがスリープしているとき、daemon の再起動中、あるいはエージェントがビジーなとき、リクエストはどうなるのか。受信箱が順序、ID、承認状態を保持し、daemon が復帰したときに順番に処理します。失われるリクエストも、2度実行されるリクエストもありません。

執筆:Noah· Product at Muti AI

エージェントの受信箱は、マシンがスリープ中、daemon がオフライン、またはエージェントがすでにビジーな場合にリクエストが待機する、エージェントごとのキューです。各リクエストは ID、リクエスト送信者、承認状態を保持して待機し、daemon が復帰したときに順番に受信箱を処理します。ノートPCの蓋を閉じたからといってリクエストが失われることはなく、daemon が再起動したからといって同じリクエストが2度実行されることもありません。

ローカルファーストのエージェントは、その利点と引き換えに可用性の課題を抱えています。受信箱は、そのコストを最小限に抑えるための仕組みです。

受信箱に入るもの

常に、すべてのリクエストが入ります。マシンがオンラインのときでも、リクエストはランタイムに向かう途中で受信箱を通過します。キューがたまたま空であるだけにすぎません。受信箱はエージェント単位です。1台のマシンに2つのエージェントがあれば2つの受信箱が存在し、並行して実行されます。1つのエージェントはその受信箱を1回に1つのリクエストずつ直列に実行するため、同じ作業ディレクトリが同時に2つの実行によって編集されることはありません。

夜間の受信箱:承認済みの3つのリクエストが順番に待機し、1つはまだオーナーの承認待ちです。マシンが起動し、順番に処理していきます。夜間の受信箱:承認済みの3つのリクエストが順番に待機し、1つはまだオーナーの承認待ちです。マシンが起動し、順番に処理していきます。

順序と状態

リクエストは、送信された順序ではなく、承認された順序で実行されます。恒久的な権限(standing grant)を持つユーザーからのリクエストは到着時に承認されてキューに入ります。オーナーの承認待ちのリクエストはその位置を保持しますが、承認されるまではスキップされます。オーナーは実行前に受信箱内のアイテムを削除したり、並べ替えたりできます。

各アイテムは待機中もその状態を保持します。pending(承認待ち)、approved(マシンの待機中)、または running(マシンがスリープした時点で実行中だった)。詳細はリクエストIDと再開可能な実行を参照してください。

復帰時の動作

daemon が復帰すると、処理すべきタスクをポーリングし、受信箱を順番に受け取って以下を行います。

  1. マシンがスリープしたときに実行中だったリクエストを、保存されているランタイムセッションの参照を使って再開します。同じID、同じセッションのまま、重複実行されるのではなくタイムラインに空白期間ができる形になります。
  2. 承認済みのリクエストを1つずつ実行します。
  3. 保留中のリクエストは、オーナーが応答するまでその場に残します。

TTL(デフォルトは24時間)を超えて応答がなかった承認はすでに期限切れになっており、リクエストは古いまま実行されるのではなく expired としてマークされます。

マシンへの接続性を維持する

受信箱はオフライン期間を安全なものにしますが、処理を速くするわけではありません。3つの習慣でオフライン期間を短縮できます。

  • muti service install で daemon をサービスとしてインストールする。ログイン時に自動起動し、クラッシュ後も再起動するため、「daemon が動いていない」という理由で待たされることがなくなります。
  • デスクトップでは業務時間中のスリープを無効化し、ノートPCでは電源に接続して給電時はスリープしないよう設定する。蓋を閉じるということは、エージェントがオフラインになるということです。
  • 迷ったら muti status を確認する。daemon が接続されているか、最後にポーリングされた時刻が表示されます。

リクエスト送信者に見えるもの

ルーム内に自分のリクエストがIDおよび状態(「キューに追加済み、マシンは22:00からオフライン」や「Noahの承認待ち」など)とともに表示されます。リクエストをキャンセルしたり、メッセージを追加したりすることも可能です。リクエストが実行されると、タイムラインは通常どおりストリーミングされます。再送する必要はありません。

よくある質問

受信箱はローカルマシンとルームのどちらに存在しますか? ルームのサービス側です。これにより、マシンがオフの間もリクエストを受け付けられ、オーナーがスマートフォンから並べ替えることができます。

受信箱をクリアできますか? はい。アイテムを削除するとそれらのリクエストはキャンセルされ、リクエスト送信者側には cancelled と表示されます。

マシンが数日間オフのままの場合はどうなりますか? リクエストは待機します。承認はそれぞれのTTLで期限切れになりますが、承認済みのリクエストは期限切れになりません。ただし、長期不在の前にオーナーが整理したほうがよい場合もあります。

チャットプラットフォームからのリクエストにも同じことが適用されますか? はい。Feishu や Slack のメンションも他のリクエストと同様に扱われ、同じ受信箱で待機します。詳細は Feishu との設計を参照してください。

ノートPCの蓋を閉じて問題ありません。リクエストは翌朝まで保持されます。エージェント用のルームを作成しましょう。

公開日

あなたのエージェントにルームを。

muti はプライベートベータ期間中は無料です。エージェントが動いているマシンを接続し、信頼できる人を招待してください。

はじめる

続けて読む

読了 6 分Comparison

QoderWake and muti

Of every agent product launched in 2026, Alibaba's QoderWake is the closest in shape to muti. Both run on your own machine, and both let a group send it work, through a chat that has to be paired first. They split on whose agent it is, what it runs, and who approves when a colleague's request reaches a delete.

読了 9 分Comparison

WorkBuddy, QwenWork and QoderWake

Tencent's WorkBuddy lets you drive the agent on your own computer from WeChat and WeCom. Alibaba's QwenWork merges desktop, cloud and DingTalk agents into one product. QoderWake runs a team of digital employees on your machine behind a single bot the whole group can mention. All three let colleagues use the agent. They answer how in very different ways.

読了 5 分Personal agents

An agent with its own phone number

Manus Cue gives each personal agent an email address, a phone number, a wallet and a computer. That makes the agent reachable by anyone who has the number, which changes the permission question from "what may my agent do" to "what may a stranger make it do". What Manus 2.0 shipped, and what reachability asks of an agent.