duoduo-loop

Duoduo Loop

/loop は、1行のリクエストを定期的に実行するバックグラウンドタスクに変換します。フォアグラウンドの duoduo チャットならどこでも、/loop <実行してほしい内容を自分の言葉で> と入力できます。Feishu の DM、stdio CLI、エディター（ACP）セッションが対象です。エージェントは、実行頻度、エンジン、結果の受け取り方についての希望を、入力された文章から直接読み取り、実行プランを作成します。確認後、タスクが作成されます。ループは専用のバックグラウンドジョブセッションで実行されます。チャットは人との会話のまま保たれ、結果はメッセージとして届きます。

確認フロー

すべての /loop は、プランを提示してから進みます。

あなた：/loop 20分ごとにステージング環境へのデプロイを確認し、問題が発生したらすぐに知らせて エージェント：プラン — バックグラウンドタスクで20分ごとに確認し、異常があった場合のみあなたにメッセージを送信します。タスク ID は staging-watch です。終了するには「stop staging-watch」と言ってください。確認しますか？ あなた：確認しました

プランには、実行頻度、エンジン／モデル、結果の受け取り方、停止方法が必ず表示されます。承諾する前に、費用の確認書としてお読みください。1ステップで作成するには、リクエスト自体に確認不要の旨を含めます。 /loop 確認は不要 — 20分ごとに、…。

例で見る3種類のループ

1. 固定頻度 — 毎回、同じ軽作業を実行します（ダイジェスト、スキャン、稼働状況の確認など）。

/loop 毎朝8時にHacker Newsのダイジェストを送って

実行のたびに新しいセッションが開始され、タスクを実行して結果をメッセージで送信します。特定の時刻と間隔のどちらも指定できます（「毎週月曜の9時」「2時間ごと」など）。間隔は、スペースを入れずに複数の単位を組み合わせられます（2h30m、1d6h4m。単位：s／m／h／d／w）。無効または実行不可能なスケジュールは、受け付けたまま実行されない状態になるのではなく、ループの作成時に拒否されます。

2. 自分で間隔を調整するループ — 次回の確認タイミングを自分で決める、短期間のミッションです。

/loop example/repo#123 の CI を監視し、失敗したら再実行して、成功してマージされたら知らせて — ペースは任せます

ループは、直前に確認した内容に基づいて次回の起動時刻を決めます。状況が動いている間は頻繁に確認し、落ち着いているときは間隔を空けます。目標が達成されると、最終レポートを送って自ら終了します。

3. 長期トラッカー — 数か月にわたるテーマ、綿密な調査、蓄積される判断が必要な場合に使います。

/loop <topic> の動向を長期的に追跡して。重要な注目点がある場合のみ毎日知らせ、手間のかかる調査はバックグラウンドのヘルパーに任せて

長期間稼働するコーディネーターが数週間にわたって判断を引き継ぐ一方、短期間のヘルパーが大量の情報収集と読解を担当します。エージェントが、それらの並行処理、各ラウンドの品質確認、結果の送信を調整します。自然な言葉で指定できるのは、通知の頻度、本当に重要な注目点の基準、手間のかかる作業をヘルパーに任せることです。各ラウンドの結果は、完了した状態で届くか、未解決の点を隠さずに明示した状態で届きます。トラッカーは無期限に休止し、再び起動することもできます。下記の「一時停止」をご覧ください。

自然な言葉でエンジンとモデルを選ぶ

リクエストで指定すると、そのまま引き継がれます。

/loop codex と gpt-5.4-mini を使って、<site> が稼働しているか1時間ごとに確認して

高頻度の確認には低コストのモデルが向いています。強力なモデルは、日次の情報統合ループのために取っておきましょう。タスクの作成前に、プランで指定内容が再度示されます。

実行中のループを管理する

管理はすべてチャット内で行えます。また、各操作は自分で実行できるホストコマンドとしても用意されています。

• 一覧表示 — 「自分のループを表示して」→ 各ループの ID、スケジュール、最後の結果が表示されます。ホストでは duoduo job list を実行します。各ループは <runtime_dir>/var/jobs/active/ 内の Markdown ファイルでもあります。
• 個別に確認 — 「 の状態は？」→ スケジュール、最後の実行、最後の結果、与えられたミッションが表示されます。ホストでは duoduo job read <id> を実行します。
• 停止 — 「 を停止して」→ duoduo job archive <id> を実行します。スケジュールから外され、ファイルは復元可能な <runtime_dir>/var/jobs/archive/ に移動します。すでに実行中の処理は完了まで続きます。
• 進行中の実行を終了 — duoduo job interrupt <id> -r "<reason>" を実行すると、現在の実行に停止を要求します。その後の動作はループの種類によって異なります。定期ループはスケジュールを維持し、指定した理由を把握した状態で次の実行を開始します。一方、次の確認をまだ予約していない自律ペースのループはそこで終了し、担当者に失敗を報告します。ループを完全に停止するには archive を実行します。操作は2つあり、停止したループが応答しなくなっている場合は、両方が必要になることもよくあります。
• 一時停止／再開（トラッカー） — 長期トラッカーは、次の起動時刻を過ぎてもそのまま待機させることで一時停止できます。チャットで「その トラッカーを再開して」と伝えると、記憶を保持したまま再開します。
• 頻度の変更 — 「 を毎日にして」→ エージェントがループのスケジュールをその場で変更します。長期トラッカーに依頼する前に、コストを把握しておきましょう。ループの会話はスケジュールに紐づいているため、頻度を変更すると新しい会話で始まり、蓄積された判断は以前のセッションに残ります。
• 頻度は変えずに、もう一度だけ実行 — ホストで duoduo job reschedule <id> "@in 30m" を実行します。単発の実行を1回追加し、スケジュールは変更しません。「今夜もう一度だけ確認して」に適した操作であり、頻度の変更には適していません。

コストに関する注意

実行間隔がコストの発生ペースを決めます。実行のたびにモデルが実際に処理を行います。確認計画を立てる段階で、実行間隔を調整し、より安価なモデルを選びましょう。「完了まで監視する」用途では、自律ペースの形式をおすすめします。必要なタイミングで確認を行い、自動的に停止するためです。

シナリオ別のトラブルシューティング

• 「スケジュールの時刻を過ぎたのに、何も起きなかった」 — まず duoduo daemon status を実行します。スケジューラーはデーモン内で動作するため、デーモンが停止していると、スケジュールが実行されません。次にジョブを確認します。duoduo job read <id> を実行するか、エージェントに「 の状態は？」と尋ねてください。最後の結果と最後のエラーから、直近の実行で何が起きたかがわかります。
• 「同じ実行が何時間も続いている」 — duoduo job read <id> を実行すると、開始したまま完了していない実行が表示されます。duoduo job interrupt <id> -r "<what went wrong>" で終了してください。ループに次の実行が予約されている場合、その実行は中断された理由を把握した状態で開始します。ランタイムには停止が要求されます。これはモデルとそのツールには届きますが、実行からバックグラウンドに切り離されたプロセスには届きません。
• 「通知が多すぎる」 — 必要な情報だけを通知するよう依頼します。「そのループは異常がある場合だけ通知するようにして」と伝えてください。計画を通じて作成された監視ループは、デフォルトで必要な情報だけを通知します。毎回の実行報告を受け取るには、明示的な設定が必要です。
• 「一度失敗してから、何も通知されなくなった」 — 一時的な起動エラーは自動的に再試行されます。実際のエラーに遭遇したループは、その旨を通知して停止します。いずれの場合も、「再開して」と返信すれば、エージェントが再設定するか、ループを作り直します。
• 「過去に何をしたか知りたい」 — アーカイブ済みのループも引き続き確認できます。「 のアーカイブ記録を読んで」と尋ねるか、<runtime_dir>/var/jobs/archive/ 内のファイルを開いてください。