Arm the target button in the composer and the next prompt becomes a goal: the server keeps the session working toward it (idle tick -> small-model audit -> continuation) until the objective is verifiably complete, blocked, or out of budget — even with the UI closed. Server (packages/web/server/lib/session-goal): - event-driven loop on the global SSE hub; goal state lives in session.metadata.openchamber.goal (merge-safe patches, stale-write guard by goal id), so it survives restarts and syncs to every client for free - the small-model audit (objective + last assistant turn only, language pinned to the objective) is the sole termination authority; blocked needs 3 consecutive verdicts, audit outages tolerate one unaudited continuation then stop the goal as resumable-blocked - hard stops: optional token budget, auto-continuation cap (Resume grants a fresh allowance), turn errors; user abort pauses the goal instead of blocking it, and resuming over an aborted tail nudges immediately - token accounting as a snapshot of the latest turn (input + cache.read + output), goal-relative via a creation baseline and segmented across compactions; a compaction summary skips the audit and continues - continuations reuse the session's own provider/model/agent/variant UI: - three-mode target button (arm / disarm / manage dialog), informational goal strip with inline pause/resume and an Evaluating indicator, sidebar state glyph, objective length counter (2000-char server clamp), read-only completed goals - goal entry points: composer (sessions and drafts), start-new-session- from-answer dialog, plan implement dialog (plan content becomes the objective), scheduled tasks (Run as goal + budget) - Settings -> Chat -> Goal: feature toggle + default token budget with three-layer parity (web server, client persistence, VS Code bridge); VS Code renders goal state but hides the entry points (the loop runs in the web server only) Notifications: per-turn "ready" notifications are suppressed while a goal is active; settling sends one final notification (desktop, web-push, APNs generic titles with the session name as body) honoring the completion toggle. Error/question/permission notifications are untouched. Docs: user guide (session-goals) in all 9 locales + sidebar entry, scheduled-tasks cross-reference, server module DOCUMENTATION.md.
74 lines
7.1 KiB
Plaintext
74 lines
7.1 KiB
Plaintext
---
|
|
title: セッションゴール
|
|
description: プロンプトをゴールに変え、エージェントが自動的に取り組み続けます。
|
|
---
|
|
|
|
# セッションゴール
|
|
|
|
ゴールは、1つのプロンプトをゴールラインに変えます。返信のたびに「続けて」と促す代わりに、ゴールを一度設定するだけ — OpenChamber がセッションを自動的にゴールへ向かわせ、各ターンの後に独立した監査モデルで進捗を確認します。離席中でも動き続けます。
|
|
|
|
## ゴールを開始する
|
|
|
|
1. コンポーザーのターゲットボタンを押します。点灯すればゴールモードが準備完了です。
|
|
2. プロンプトを書いて送信します。そのメッセージがゴールの目標になります。
|
|
|
|
既存のセッションでも新規セッションの下書きでも同じように機能します。ターゲットを有効にして最初のメッセージを書いて送信すれば、新しいセッションは最初からゴールが有効な状態で始まります。
|
|
|
|
### ゴールを開始する他の方法
|
|
|
|
- **エージェントの返信から**:「Start new session from this answer」ダイアログで **ゴールとして実行** にチェック — 返信が課題として引き継がれ、新しいセッションが完了まで実行します(**Create worktree** と組み合わせれば隔離された実行になります)。
|
|
- **プランから**:保存したプランを新しいセッションや worktree で実装するとき、ダイアログの **ゴールとして実行** にチェック。ゴールの目標にはプランの内容が入るため、監査はプランそのものに照らして進捗を判定します。
|
|
- **スケジュールで**:[スケジュールタスク](/scheduled-tasks/)の **ゴールとして実行** にチェックすると、定期実行がプロンプトを完了まで追求します。
|
|
|
|
## 自己完結した目標を書く
|
|
|
|
進捗の監査モデルが見るのは、あなたの目標とエージェントの最新の返信だけです — チャット履歴は見ません。会話の文脈を知らない人でも完成状態がわかるように、ゴールのメッセージを書いてください。
|
|
|
|
- 良い例:「エクスポートモジュールのテストを追加し、テストスイート全体を通るようにして。」
|
|
- 良くない例:「直して」「さっきのアイデアで続けて」
|
|
|
|
ちょっとした文脈依存の指示にはゴールは不要です — 普通のメッセージを送りましょう。
|
|
|
|
## 仕組み
|
|
|
|
エージェントが停止してセッションがしばらく静かになると、OpenChamber は:
|
|
|
|
1. 小型で安価なモデルに、最新のターンを目標と照らして監査させます:続行、完了、それとも行き詰まり?
|
|
2. 判定が「続行」なら、継続プロンプトを送り、エージェントが作業を再開します。
|
|
3. 目標が検証可能な形で達成されていればゴールは完了し、通知が届きます。
|
|
4. エージェントが本当に行き詰まっている(あなたの入力が必要な)場合、ゴールはブロックとして停止します — ただし監査が3回連続でそう判定した場合のみ。一度のつまずきでゴールが終わることはありません。
|
|
|
|
ハードな安全装置もあります:オプションのトークン予算、自動継続の上限、ターンエラー時の停止です。作業中にセッションのコンテキストが圧縮されても、ゴールはそのまま続行します — コンテキストウィンドウに達したこと自体が、作業が終わっていない証拠だからです。
|
|
|
|
### 停止と再開
|
|
|
|
- **停止ボタン**は実行中のターンを中断し、ゴールを一時停止します — あなたの明示的な「止めて」は常にループより優先されます。
|
|
- ストリップの**一時停止**は逆方向から同じことをします:ゴールを一時停止し、実行中のターンを止めます。
|
|
- 一時停止中は普通にチャットできます — ループは邪魔をしません。
|
|
- **再開**はループを再始動します:アイドルなセッションでは継続プロンプトが即座に送られ、エージェントが作業中なら次の停止時にループが静かに再接続します。
|
|
|
|
## 確認と管理
|
|
|
|
- コンポーザー上部のストリップに、最新の進捗メモ、ステータス、トークン使用量が表示され、一時停止/再開ボタンも組み込まれています。エージェントが停止していてゴールがアクティブなときは、回転する**評価中…**が表示されます — 静止ウィンドウと監査が動いている印です。
|
|
- ターゲットボタンはゴール実行中は点灯し(青)、完了で緑、ブロックや予算切れで赤になります。押すとゴールのダイアログが開き、目標や予算の編集、ゴールの削除ができます。完了したゴールは読み取り専用です — 削除してから新しいゴールを開始してください。
|
|
- セッションサイドバーでは、セッションの日付の横にゴールの状態色の小さなターゲットが表示されます。
|
|
|
|
## 通知
|
|
|
|
ゴールがアクティブな間、ターンごとの「エージェント準備完了」通知は抑制されます — ループ自身の継続をなぞるだけだからです。ゴールが確定すると(完了、ブロック、予算到達)、代わりに最終通知が1件、デスクトップとモバイルプッシュで届きます。「完了時に通知」と同じ設定に従います。権限リクエスト、質問、エラー通知は通常どおり機能し続けます。
|
|
|
|
## トークン予算
|
|
|
|
**設定 → チャット → ゴール** で、新しいゴールのデフォルトトークン予算を設定できます。予算に達するとゴールは「予算上限に到達」として停止し、それ以上消費しません — 予算を上げてゴールのダイアログから再開できます。
|
|
|
|
## 留意点
|
|
|
|
- ゴールのループはブラウザのタブではなく OpenChamber サーバーで動きます。タブを閉じても、スマホをロックしても — エージェントは働き続け、ゴールが確定すると通知が届きます。サーバー(デスクトップアプリまたは `openchamber` プロセス)は起動したままにしてください。
|
|
- ゴールはセッション自身のプロバイダーとモデルを使います。監査の呼び出しも同様です — 既に使っているプロバイダーの外にデータが出ることはありません。
|
|
- ゴールは1セッションにつき同時に1つです。
|
|
|
|
## 関連
|
|
|
|
- [スケジュールタスク](/scheduled-tasks/) — スケジュールでプロンプトを実行。「ゴールとして実行」を有効にすると、スケジュール実行がプロンプトを完了まで追求します
|
|
- [通知](/notifications/) — 完了したゴールを知る方法
|